Назад | Перейти на главную страницу

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

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

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

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

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

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

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

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

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

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

Номер 1 настолько прост, насколько это звучит - купите два одинаковых сервера.

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

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

Номер 4 может быть получен с помощью приложения сердцебиения.

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

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

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

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

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

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

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

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

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

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

HA-Примеры:

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

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

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

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

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

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