Настройка виртуализированной среды высокой доступности

Для проекта у меня есть задача планирования настройки высокой доступности для интернет-магазина и системы CMS. Однако, конечно, у проекта ограниченный бюджет. Таким образом, решение высокого уровня может быть не в бюджете.

Будет два компьютера с веб-сервером (CMS, магазин), один компьютер с базой данных и один компьютер для работы с факс-сервером, необходимым для доставки заказов партнерам. Все системы работают под управлением Linux. Все эти компоненты должны быть высокодоступными и поддерживать прозрачное переключение при сбое.

Чтобы снизить затраты на оборудование, я думаю о виртуализированной среде. Там много информации, но я не знаю, с чего именно начать. Кажется очевидным, что, по крайней мере, серверы необходимы в качестве хоста для виртуальных машин, чтобы не было единой точки отказа.

Какой лучший способ поддержать высокую доступность?

Первый вопрос: какое решение для виртуализации является лучшим в этой ситуации. Там должен быть какой-то интерфейс управления. Должен быть способ перемещения работающей виртуальной машины с одного хоста на другой, чтобы можно было выполнить обслуживание хоста. Должен быть какой-то механизм, чтобы виртуальные машины все еще были доступны в случае отказа одного хоста. Не могли бы вы посоветовать правильное решение здесь?

Совместное хранение файлов, по-видимому, является предпосылкой высокой доступности в большинстве случаев (ожидайте, что VMware vSphere будет довольно дорогим). Однако лучше добавить больше денег на хосты виртуальных машин, чем добавить еще два сервера в настройку, чтобы обеспечить избыточное хранилище файлов NFS. Есть ли возможность ужиться только с двумя хостами виртуальных машин? Решением может быть использование двух в качестве хостов NFS. Есть ли большая потеря производительности, чтобы сделать это?

РЕДАКТИРОВАТЬ: Я стремлюсь к доступности 99,9%. Тем не менее, круглосуточная доступность не требуется, поскольку есть обычные рабочие часы, что дает пространство для маневра. Период доступности, который должен быть каким-то образом гарантирован, составляет от 10 до полуночи.

Как общий обзор, для достижения высокой доступности вам необходимо:

1. Несколько серверов
2. Несколько постоянных копий данных
3. Консистентные данные, которые могут быть доступны между несколькими серверами
4. Способ автоматической загрузки второго экземпляра на резервный сервер

Номер 1 так же прост, как кажется - купите два одинаковых сервера.

Номер 2 может быть достигнут с помощью реплицируемой SAN (дорогой, очень быстрый, очень надежный) или реплицированной файловой системы на каждом из серверов (дешевизна, скорость и надежность могут зависеть от ваших знаний о выбранной технологии).

Число 3 может быть достигнуто с помощью SAN (один LUN хранилища, к которому получают доступ два сервера) или реплицированной файловой системы (две отдельные области хранения, каждый сервер может видеть только свою собственную).

Число 4 может быть достигнуто путем применения сердцебиения.

Чтобы сделать это с небольшим бюджетом, скажем, VMWare vSphere, вы можете использовать либо SAN, либо VMWare теперь предложить самореплицирующееся устройство хранения, которое предлагает два отдельных хранилища данных на двух серверах, которые можно использовать для обеспечения высокой доступности. vSphere также предлагает встроенные контрольные сигналы и конфигурации высокой доступности.

Чтобы сделать это без бюджета, вы можете пойти по пути Xen и использовать DRBD для репликации хранилища между двумя узлами. Затем вы настраиваете пульс для переключения активного узла хранения DRBD и экземпляра Xen для загрузки виртуальных машин на 2-м хосте, когда первый отключается.

Вы не получите 5-9 (99,999%) безотказной работы, используя эти базовые рекомендации, но вы можете легко получить 3 9 (99,9%), используя самые дешевые методы, если знаете, что делаете.

Вы говорите о «расходах» в терминах «сколько денег будет стоить эта покупка» при обсуждении общего хранилища. Конечно, это абсолютно верный аргумент, деньги везде туго .

Но если вы говорите о высокой доступности, то вам также нужно спросить: « Почему мы хотим высокой доступности?» и если ответ, например, «потому что бизнес превращается в более чем 2000 долларов в час в онлайн-продажах, поэтому, если мы уходим на час, то мы потеряли 2000 долларов», тогда вопрос стоимости и доступности может стать «Можем ли мы позволить себе не покупать то, что позволяет или значительно улучшает наше развертывание высокой доступности? "

Это важная деталь, и она играет на ваш комментарий о бюджете - ИТ-хвост не должен вилять деловой «собакой», настаивая на слишком сложном и дорогостоящем решении небольшой проблемы, но в то же время, если бизнес имеет определенные требования его ИТ-инфраструктуры, то он должен быть готов либо бюджет для них должным образом или скорректировать свои требования.

Я думаю, что виртуализация имеет большой потенциал в улучшении доступности систем, но это не волшебная палочка. Аппаратная сторона вещей, хотя и важна, очень вторична по отношению к требованиям к программному обеспечению - бесполезно иметь кластер базы данных SQL, который без проблем перебивается в случае сбоя одного из серверов SQL, если переднее приложение, которое говорит к дросселям базы данных, потому что это не может обработать аварийное переключение.

И два «высокодоступных» сервера, расположенные рядом друг с другом в центре обработки данных, по-прежнему подвержены сбоям питания, краже и т. Д. Опять же, в зависимости от ответа на вопрос « почему мы это делаем?», Вам может потребоваться рассмотреть этот аспект довольно тщательно, поскольку это может добавить затраты и сложность довольно многим частям вашего проекта.

Не зная, какую БД и сервер приложений вы используете, я бы порекомендовал:

• Используйте XEN> 3.2 в режиме PV для виртуальных машин (просто мой личный фаворит) - отсеки или другие решения для виртуализации lightwight также могут подойти (OpenVZ, чтобы назвать одно).
• Построить четыре виртуальных машины на каждом физическом узле
• Используйте локальный RAID 5 с 3,5-дюймовыми дисками SAS - максимально возможное количество дисков (5 - это хорошо)
• Используйте 15k RPM дисков (это понадобится вашим БД)
• Используйте DRBD и OCFS2 для предоставления дешевого «общего» хранилища, используйте быструю, безопасную и надежную локальную сеть для этого соединения (соединение прямых межсоединений довольно быстро и хорошо).
• Сделайте HA на уровне приложения
• Используйте балансировку нагрузки между парами машин, чтобы вы получили 8 машин, выполняющих параллельные задачи

HA-Примеры:

• Сервер приложений: использование Tomcat в кластерном активном / активном режиме
• LVS: использовать параллельную подчиненную и основную репликацию lvs
• Oracle-DB: используйте RAC (я не знаю, есть ли эквивалентное решение для баз данных OpenSource)

Если вы выполняете HA на уровне приложений, этот уровень лучше знает, как реплицировать сеансы. Если один узел выйдет из строя (запланированный или незапланированный), то выживший узел вступит во владение - включая сеансы.

Почему вы хотите купить свои собственные хосты? Почему бы вам не найти поставщика Enterprise Cloud / IaaS, такого как BlueLock или Terremark , который обеспечит необходимую инфраструктуру. Они будут предоставлять такие сервисы, как vSphere HA (скорее сокращение времени простоя, чем сервис HA, но это экономичное решение), межсетевой экран, LTM / SSL Offloader, SAN (с резервными полками), мониторинг / оповещение и т. Д. Обратите внимание, что мы не Говоря о потребительских облачных решениях, будьте готовы заплатить за это.

Вы можете взглянуть на универсальное решение для виртуализации и репликации хранилищ.

Файловая система ZFS делает это возможным, как описано в этом сообщении в блоге .

Другой вариант - следовать руководству, в котором подробно описано решение с Red Hat KVM .