В настоящее время мы находимся на стадии исследования создания «главной» базы данных для нашего бизнеса электронной коммерции, которая будет централизовать все данные, включая информацию о продукте, информацию о поставщиках, информацию Magento, Amazon и т. Д. Мы рассмотрели как «физические данные»). аппаратное обеспечение »(две машины RAID 5, главный / подчиненный, с резервной копией жесткого диска с подчиненного устройства - и отдельный сервер приложений) .... Или мы могли бы создать« облачную »систему.
Суть вопроса в том, есть ли польза от репликации в облаке? Вся суть облака заключается в масштабируемости и «отсутствии простоев оборудования», следовательно, отсутствии потери данных из-за неисправного оборудования. Потеря данных, которая может произойти, если таковая произойдет, в облачной системе будет программной. С учетом сказанного, поскольку проблема связана с программным обеспечением, которая может вызвать потерю данных, эта проблема, скорее всего, будет воспроизведена, верно? Значит, у нас будет 2 машины с одинаковыми поврежденными данными?
Мы пытаемся проанализировать соотношение затрат и преимуществ любого решения. Конечно, если репликация в облаке не дает преимуществ, то преимущества, которые может предложить облако, перевешивают аппаратное решение. Однако, если реплицируемое решение в облаке является лучшим вариантом, тогда аппаратное решение будет намного дешевле, включая время физического управления.
Есть ли здесь у кого-нибудь опыт или идеи?
Самое главное, что нужно помнить о виртуальных машинах (которые, по сути, вы получите от «облачного» провайдера) - это то, что ничего волшебного не произошло просто потому, что кто-то сказал «Виртуальный». Или «Облако».
Вам по-прежнему нужно планировать и тестировать высокую доступность, а не просто предполагать, что это сработает. Вам все еще нужно беспокоиться о повреждении данных при записи в реплики и т. Д.
По сути, все, что вы получите от перехода к облаку, - это меньшая видимость платформы - соблазнительно рассматривать это как меньшую ответственность, но если вашему бизнесу нужны облачные ресурсы, а они недоступны (например, представьте себе компанию в Нью-Йорке с локальный сервер и переключение облака на центр обработки данных в Нью-Джерси несколько месяцев назад), а затем возможность указать на поставщика облачных услуг и сказать: «Это ваша вина» не поможет вашему веб-сайту возобновить прием заказов быстрее.
Компьютеры до сих пор ломаются, даже те, на которых работают «облака».
Это не значит, что вам не следует этого делать. Там являются преимущества наличия сторонней реплики, готовой вмешаться, если у вас возникнут проблемы, и там являются преимущества передачи всей инфраструктуры поставщику облачных услуг, поэтому оба подхода допустимы. Вам просто нужно четко понимать, что именно вы покупаете (вы не покупаете какое-то «облако», вы покупаете услугу, и вам нужно точно указать, какие услуги у вас будут и с каким SLA они будут под.)
Здесь важно прояснить пару моментов:
Некоторые облачные архитектуры могут «не допускать простоев для планового обслуживания» - из-за использования VMotion и т.п.
Системы, работающие с VMWare Fault Tolerance или аналогичными, могут обеспечить устойчивость к неожиданным аппаратным сбоям, но существуют значительные ограничения для настройки (с VMWare FT защищенные виртуальные машины могут иметь только одно ядро ЦП).
Ни один из них не является автоматическим только потому, что вы купили что-то с пометкой «Облако».
Таким образом, для масштабируемости вы, вероятно, захотите использовать репликацию главный / подчиненный; это работает так же хорошо в облачной настройке, как и в настройке выделенного оборудования.
Поскольку базы данных особенно чувствительны к производительности дисков, вам следует убедиться, что вы понимаете параметры IO QoS вашего облачного провайдера и коэффициент избыточной подписки.
Хотя некоторые считают RAID5 решением для резервирования дисков для бедняков, для вашей безопасности и здравомыслия, пожалуйста, избавьтесь от RAID5 как можно скорее. Зачем ???
Теперь обсудим InnoDB и MyISAM
Если вы не используете innodb_file_per_table, OMG, вся деятельность будет сосредоточена только на одном файле ibdata1. Что содержится в ibdata1 InnoDB?
Даже операции чтения в InnoDB имеют тенденцию покрывать строки защитой MVCC, чтобы обеспечить возможность повторяемого чтения и разрешить транзакциям попадать в те же считываемые строки. Таким образом, чтение и запись производят дисковый ввод-вывод в ibdata1.
С помощью innodb_file_per_table может уменьшить часть дискового ввода-вывода, разделив страницы данных таблицы и индекса из ibdata1 на .ibd файлы. Тем не менее, я бы ожидал некоторого заметного улучшения производительности только в течение ограниченного времени в среде RAID5. Взаимодействие с таблицами осталось прежним. Каждый доступ к .ibd file всегда предшествует проверка ссылок на ibdata1.
Хотя разделение может привести к значительным изменениям производительности, RAID5 будет тем, что в мире химии называют ограничивающим реагентом. Любые выгоды, ожидаемые от изменений компоновки InnoDB, будут нейтрализованы внешними факторами, такими как RAID5. Наличие дополнительных файлов табличного пространства из-за innodb_file_per_table со временем ничего не покупает, кроме наличия дополнительных файлов табличных пространств.
Когда дело доходит до MyISAM, RAID5 подходит в среде с интенсивным чтением и низкой записью. при условии, что вы сопоставите все временные таблицы (используя tmpdir) на другой диск, отдельный от RAID5. (Похоже на поражение цели RAID5, а?)
Помните, что страницы данных таблицы находятся в .MYD файлы и соответствующие им индексные страницы живут в .MYI файлы. Среда с большим объемом записи (INSERT, UPDATE, DELETE) заставит RAID5 замедлить работу. Учитывая поведение блокировки MyISAM (полная блокировка таблицы с каждым INSERT, UPDATE и DELETE) в среде с большим объемом записи, постоянный поток DML будет держать RAID5 довольно загруженным и заставит пользователей БД войти в краткую, но раздражающую временную деформацию в ожидании DML. завершить.
Под капотом RAID5 имеет следующие характеристики для записи с четностью
Если на любом из этих шагов наблюдается малейшая прерывистость, набор RAID5 входит в краткую, но досадную деформацию времени. Умножьте это на огромное количество операций записи, и вы почувствуете это по производительности базы данных. Каждый из этих шагов может стать точкой отказа. Зачем?
В соответствии с Википедия о RAID5
В случае сбоя системы при активной записи четность полосы может стать несовместимой с данными. Если это не обнаружено и не устранено до того, как диск или блок выйдет из строя, может произойти потеря данных, поскольку для восстановления отсутствующего блока в этой полосе будет использована неправильная четность. Эта потенциальная уязвимость иногда называется отверстием для записи. Кэш с резервным питанием от батареи и аналогичные методы обычно используются, чтобы уменьшить окно возможности для этого.
RAID10 не только обеспечивает стабильность, но и дает некоторую свободу действий в обслуживании дисков, в большинстве случаев не прерывая работу mysql. Когда данные зеркалируются, вы знаете, куда они направляются, и откуда они читаются.
Я бы посоветовал использовать RAID10. Если вы не возражаете против длительных периодов простоя, вы не можете позволить себе обслуживание диска RAID5 вместо необходимой синхронизации диска. Фактически, чем меньше размер дисков в RAID10, тем быстрее будет время синхронизации после обслуживания диска RAID 10.
Другие вещи, которые следует учитывать
Что касается Master и Slave в VMWare, убедитесь, что Master и Slave находятся на отдельных физических дисках. Если диски в VMWare являются RAID5, подготовьте еще один кластер VMWare прямо сейчас, используя RAID10, пожалуйста.
Если вам нужна надежность, выберите RAID 10, а не RAID 5, и настройку master / slave (RAID 10 дает вам производительность, а также надежность). Я сомневаюсь, что вы можете получить производительность ввода-вывода физического сервера (RAID 10) с любым облачным провайдером. Использование облака очень полезно, когда ваша нагрузка / трафик непостоянны или у вас есть всплески трафика 2-3 раза в день. В таких случаях вы создаете новые веб-сервер и экземпляры базы данных и отбрасываете их, когда трафик идет нормально.
Регулярно выполняйте резервное копирование данных, независимо от того, находитесь ли вы в облаке, на физическом сервере с RAID 10 / RAID 5 или репликации master / slave. И самое главное, часто проверяйте работоспособность резервных копий.
Вся суть облака - в масштабируемости и «отсутствии простоев оборудования», следовательно, без потери данных из-за плохого оборудования.
Вы понимаете, что «Облако» - это просто обычные серверы с виртуализированными операционными системами. Это может и страдает больше (обычно намного больше) простоев и потерь данных, чем обычный выделенный сервер.
В настоящее время мы находимся на стадии исследования создания "главной" базы данных для нашего бизнеса электронной коммерции.
Это предприятие исключительно для базы данных вашего магазина Magento или для более широкой реализации ERP?
Если первое, то начните исследование снова. Magento не привязан к своей БД - вы столкнетесь с множеством других узких мест, прежде чем MySQL станет проблемой. То есть, если вы не размещаете свой сервер MySQL на удаленном «облачном» VPS, подключенном к глобальной сети с высокой задержкой, плохо маршрутизируемым, перегруженным, высококонкурентным и малополосным подключением.
Я видел больше потерь данных и ненадежных хранилищ из-за попыток самостоятельной работы по обеспечению высокой доступности, чем при использовании простого односерверного решения.
Глядя на твою другой вопрос. Вы тратите 14 тысяч долларов в год на лицензию Magento EE, но пытаетесь управлять своим собственным сервером?
Есть веская причина, по которой существуют специализированные хостинг-провайдеры Magento - и это для того, чтобы вы не тратили и потенциально теряли небольшое состояние, принимая неправильные решения, пытаясь сделать DIY. Вы должны сосредоточиться на управлении своим магазином и делать то, что у вас хорошо получается, а не пытаться быть системным администратором.