У нас есть следующие серверы:
A. 1 веб-сервер под управлением MySQL (форум).
Б. 1 веб-сервер под управлением RT с Postgres.
C. 1 веб-сервер, на котором запущено собственное приложение с MonetDB в качестве серверной части.
Теперь, конечно, мы хотим добавить здесь немного надежности, добавив дополнительный сервер к каждому веб-серверу на случай, если 1 сервер выйдет из строя и т. Д. Но как это сделать лучше и относительно дешевле?
Почему мне это не нравится: возможное повреждение данных из-за проблем с синхронизацией, то есть временный сбой питания может привести к записи данных на ведомое устройство, затем возвращается мастер, а затем репликация прерывается. В случае со Slony вы даже не можете этого сделать, вы должны сначала продвинуть подчиненное устройство до мастера и т.д., AFAIK.
Другая вещь, которая мне не нравится в этом, - это необходимость вручную продираться через все это и выяснять, кто что делает сейчас, синхронизировать вещи и т. Д.
2. Получите 2 сервера с приличным объемом хранилища и настройте DRBD на них.
Поскольку у них будет один общий IP-адрес, поместите все БД, например MySQL, Postgres и Monet в хранилище DRBD. Преимущество DRBD в том, что у нас не будет единой точки отказа, поскольку даже если мы потеряем часть кластера, другой сервер может взять на себя управление, поэтому он будет намного более устойчивым. И я понимаю, что веб-серверы выше этого уровня могут просто переключаться и возвращаться, не беспокоясь о репликации, синхронизации и т. Д.
3.ВМ?
Как лучше всего использовать виртуальные машины для настройки чего-то подобного?
С точки зрения высокой доступности виртуальные машины не так сильно помогут вам, хотя они могут быть полезны для упрощения консолидации.
На ваш вопрос нельзя ответить без двух важных данных: вашего бюджета и нагрузки. Если у вас ограниченный бюджет, но ваша нагрузка достаточно низкая, вы можете легко перенести все это на два сервера в режиме активной / пассивной настройки.
Если ваш бюджет позволяет, вы можете рассмотреть возможность приобретения SAN (или, желательно, двух для HA). В этом случае вы все равно можете иметь базы данных, возможно виртуализированные, на том же сервере, что и приложения, но с данными, записанными в SAN. Базы данных в основном привязаны к вводу-выводу.
Другой путь действительно состоит в том, чтобы иметь двухузловой отказоустойчивый кластер для БД и реплицировать разделы БД через DRBD, это работает довольно хорошо. Однако вы хотите, чтобы у каждого был свой диск; для этого я бы рекомендовал использовать что-то вроде машины 2U с 6 дисками с аппаратным рейдом с батарейным питанием.
Если у вас еще больше трафика, но вы все еще хотите сохранить небольшой бюджет, вы можете попробовать следующее:
Однако остерегайтесь нагрузки; если один из узлов выходит из строя, когда вы находитесь на пике использования, у вас будут большие проблемы, но это может быть хорошим способом справиться с случайным появлением косой черты.
Не используйте drbd для отработки отказа mysql. Используйте репликацию мастер-мастер и поместите перед ними haproxy для балансировки нагрузки соединения mysql и обеспечения аварийного переключения. Затем установите сердцебиение на серверах haproxy. Полная отработка отказа с балансировкой нагрузки.
drbd хорош для таких вещей, как веб-файлы, поверх которых работает nfs.
Для решения, которое существует «на случай» отказа ваших основных параметров, а не для балансировки / частого переключения при отказе, комбинация пунктов №2 и №3 будет работать хорошо. Получите ящик с разумными ресурсами для хранения и запуска виртуальных машин для каждой из основных систем. Используйте DRBD для упрощения репликации данных. Для дополнительных наворотов вы можете добавить сердцебиение для автоматического переключения при отказе - или нет. И конечно же репликация! = Бэкап.
Почему бы не использовать VMWare / виртуализацию для создания кластера из двух серверов + БД, каждый из которых запускает все ваши различные БД, и второй кластер из двух серверов + веб-сервер, каждый из которых обслуживает все ваши различные веб-приложения.
Таким образом, вам нужно как можно меньше серверов, иметь встроенное решение для масштабирования, которое позволит вам увеличивать / перемещать ваши горячие точки по мере их возникновения, а также наилучшим образом использовать ваши активы.