Поиск по сайту:

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

На этой странице

  1. Предисловие
  2. Постоянная доступность
  3. Высокая доступность
    1. Облако VMmanager
    2. Первый байт
    3. Первый VDS

    Некоторые компании не могут допустить отключения своих услуг. В случае сбоя сервера сотовый оператор может столкнуться с отключением биллинговой системы, что приведет к потере связи со всеми его клиентами. Признание потенциального воздействия таких ситуаций приводит к мысли всегда иметь план Б.

    В этой статье мы освещаем различные способы защиты от сбоев сервера, а также архитектуры, используемые для развертывания VMmanager Cloud — панели управления для построения кластера высокой доступности.

    Предисловие

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

    • Отказоустойчивость (FT) — это способность системы продолжать свою работу после отказа одного из ее компонентов.
    • Кластер — это группа серверов (узлов кластера), связанных коммуникационными каналами.
    • Отказоустойчивый кластер (FTC) — это кластер, в котором сбой одного сервера не приводит к полной недоступности всего кластера. Функции вышедшего из строя узла автоматически перераспределяются между оставшимися узлами.
    • Непрерывная доступность (CA) означает, что пользователь может использовать службу без каких-либо тайм-аутов. Неважно, сколько времени прошло с момента отказа узла.
    • Высокая доступность (HA) означает, что пользователь может столкнуться с тайм-аутом обслуживания в случае выхода из строя одного из узлов; однако система будет восстановлена автоматически с минимальным временем простоя.
    • Кластер ЦС — это кластер непрерывной доступности.
    • Кластер высокой готовности — это кластер высокой доступности.

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

    На первый взгляд, наиболее привлекательным вариантом для компании является развертывание кластера Continuous Availability, когда служба все еще предоставляется после отказа оборудования. Действительно, непрерывная доступность необходима, если вам необходимо поддерживать работу биллинговой системы или автоматизировать непрерывный производственный процесс. Однако у этого подхода также есть свои ловушки и подводные камни, которые описаны ниже.

    Непрерывная доступность

    Непрерывность службы возможна только в том случае, если создана точная копия физической или виртуальной машины с этой службой, которая доступна в любой момент времени. Такая модель резервирования называется 2N. Создание копии сервера после отказа оборудования заняло бы время, что привело бы к тайм-ауту службы. Кроме того, в этом случае будет невозможно получить дамп оперативной памяти с отказавшего сервера, а значит, вся содержащаяся там информация будет потеряна.

    Для предоставления CA используются два метода: на аппаратном и программном уровне. Остановимся на каждом из них подробнее.

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

    Stratus, производитель серверов ЦС, гарантирует, что общее время простоя системы не превышает 32 секунд в год. Таких результатов можно добиться, используя специальное оборудование. По словам представителей Stratus, стоимость одного сервера CA с двумя процессорами для каждого синхронизируемого модуля составляет около $160 000 в зависимости от спецификации. Расширенная цена всего кластера CA в этом случае составит $1 600 000.

    Программный метод

    Самым популярным программным инструментом для развертывания кластера Continuous Availability на момент написания статьи является VMware vSphere. Технология непрерывной доступности этого продукта называется отказоустойчивостью.

    В отличие от аппаратного метода, эта технология имеет определенные требования, такие как:

    • ЦП на физическом хосте:
      • Intel с архитектурой Sandy Bridge (или новее). Авотон не поддерживается.
      • AMD Bulldozer (или новее).

      Полный список ограничений и несовместимостей можно найти в официальной документации.

      Лицензирование vSphere основано на физических процессорах. Цена начинается от 1750 долларов за лицензию + 550 долларов за годовую подписку и поддержку. Для автоматизации управления кластером также требуется сервер VMware vCenter, стоимость которого превышает 8000 долларов США. Модель 2N используется для обеспечения непрерывной доступности, поэтому необходимо приобрести 10 реплицированных серверов с лицензиями на каждый из них, чтобы построить кластер из 10 узлов с виртуальными машинами.

      Общая стоимость программного обеспечения составит 2[Количество ЦП на сервер]*(10[Количество узлов с виртуальными машинами]+10[Количество реплицированных узлов])*(1750+550)[Стоимость лицензии на каждый ЦП]+8000 [Стоимость сервера VMware vCenter]=$100 000. Все цены округлены.

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

      Также важно упомянуть продукты, которые больше не разрабатываются и не поддерживаются.

      Продукт под названием Remus основан на виртуализации Xen. Это бесплатное решение с открытым исходным кодом, использующее технологию микромоментальных снимков. К сожалению, его документация давно не обновлялась: руководство по установке содержит инструкции для Ubuntu 12.10, о завершении срока службы которой было объявлено в 2014 году. Даже поиск Google не нашел ни одной компании, использующей Remus для своей деятельности.

      Были предприняты попытки модифицировать QEMU для построения кластеров Continuous Availability на этой технологии. Есть два проекта, заявивших о своей работе в этом направлении.

      Первый — это Kemari, продукт с открытым исходным кодом, которым руководит Йошиаки Тамура. Этот проект предназначен для использования живой миграции QEMU. Последний коммит был сделан в феврале 2011 года, что говорит о том, что разработка зашла в тупик и продолжения не будет.

      Второй продукт — Micro Checkpointing, проект с открытым исходным кодом, основанный Майклом Хайнсом. В его журнале изменений за последний год не было обнаружено никакой активности, что напоминает проект Kemari.

      Эти факты позволяют сделать вывод, что возможности Continuous Availability на виртуализации KVM на сегодняшний день просто нет.

      Несмотря на все преимущества систем Continuous Availability, на пути развертывания и эксплуатации таких решений существует множество препятствий. Тем не менее, в некоторых случаях отказоустойчивость может потребоваться, но без необходимости быть постоянно доступной. Такие сценарии позволяют использовать кластеры с высокой доступностью.

      Высокая доступность

      Кластер высокой доступности обеспечивает отказоустойчивость, автоматически определяя отказ оборудования и запуская службу на доступном узле.

      High Availability не поддерживает синхронизацию процессоров, запущенных на узлах, и не всегда позволяет синхронизировать локальные диски. Имея это в виду, рекомендуется размещать диски, используемые узлами, в отдельном независимом хранилище, таком как сетевое хранилище.

      Причина ясна: к узлу невозможно получить доступ после его отказа, а информацию с его запоминающего устройства невозможно получить. Система хранения данных также должна быть отказоустойчивой, иначе невозможна High Availability. В результате кластер высокой доступности состоит из двух подкластеров:

      • Вычислительный кластер, состоящий из узлов с виртуальными машинами
      • Кластер хранения с дисками, которые используются вычислительными узлами.

      На данный момент для реализации кластеров High Availability с виртуальными машинами на узлах кластера используются следующие решения:

      • Heartbeat, версия 1.? с ДРБД;
      • Кардиостимулятор;
      • VMware vSphere;
      • Proxmox VE;
      • XenServer;
      • OpenStack;
      • oVirt;
      • Red Hat Enterprise Virtualization;
      • Отказоустойчивая кластеризация Windows Server с ролью сервера Hyper-V;
      • Облако VMmanager.

      Давайте подробнее рассмотрим VMmanager Cloud.

      Облако VMmanager

      VMmanager Cloud — продукт, который позволяет развертывать кластеры высокой доступности и использует виртуализацию QEMU-KVM. Эта технология была выбрана потому, что она активно развивается и поддерживается и позволяет установить любую операционную систему на виртуальную машину. Продукт использует Corosync для определения доступности кластера. Если один из серверов вышел из строя, VMmanager поочередно распределяет свои виртуальные машины между оставшимися узлами.

      В упрощенном виде этот механизм работает следующим образом:

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

      Тестирование нескольких аппаратных конфигураций и опрос многих текущих пользователей VMmanager Cloud показало, что обычно на распределение и восстановление работы всех ВМ с вышедшего из строя узла уходит 45-90 секунд, в зависимости от производительности оборудования.

      Рекомендуется выделить одну или несколько нод для защиты от внештатных ситуаций и не разворачивать виртуальные машины на этих нодах во время рутинной работы. Это сводит к минимуму вероятность нехватки ресурсов на действующих узлах кластера для добавления виртуальных машин с неисправного узла. В случае, если используется только один резервный узел, такая модель безопасности называется N+1.

      VMmanager Cloud поддерживает следующие типы хранилищ: файловая система, LVM, Network LVM, iSCSI и Ceph [в частности RBD (RADOS Block Device), одна из реализаций Ceph]. Последние три используются для высокой доступности.

      Одна пожизненная лицензия на десять рабочих узлов и один резервный узел стоит 3520 евро или 3865 долларов на сегодняшний день (одна лицензия стоит 320 евро на узел независимо от количества процессоров). Лицензия включает один год бесплатных обновлений; начиная со второго года обновления предоставляются по модели подписки по цене 880 евро в год за весь кластер.

      Давайте проверим, как VMmanager Cloud уже использовался для развертывания кластеров высокой доступности.

      Первый байт

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

      1. Возможность развертывания виртуальных машин KVM.
      2. Интеграция с Ceph.
      3. Интеграция с биллинговой системой для предоставления существующих услуг.
      4. Доступная стоимость лицензии.
      5. Поддержка разработчика программного обеспечения.

      VMmanager Cloud соответствует всем требованиям.

      Отличительные особенности кластера FirstByte:

      • Передача данных основана на технологии Ethernet и оборудовании Cisco.
      • Маршрутизация выполняется с помощью Cisco ASR9001. Кластер использует около 50000 адресов IPv6.
      • Скорость соединения между вычислительными узлами и коммутаторами составляет 10 Гбит/с.
      • Скорость передачи данных между коммутаторами и узлами хранения составляет 20 Гбит/с, с двумя объединенными каналами по 10 Гбит/с каждый.
      • Отдельный канал 20 Гбит/с используется между стойками с узлами хранения для репликации.
      • Диски SAS в сочетании с твердотельными накопителями устанавливаются на все узлы хранения.
      • Тип хранилища — RBD.

      Схема системы представлена ниже:

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

      ПервыйVDS

      FirstVDS предоставляет услуги отказоустойчивого кластера, запущенного в сентябре 2015 года.

      Для этого кластера было выбрано VMmanager Cloud по следующим причинам:

      1. Большой опыт использования панелей управления ISPsystem.
      2. Интеграция с BILLmanager по умолчанию.
      3. Высокое качество технической поддержки.
      4. Интеграция с Ceph.

      Их кластер имеет следующие особенности:

      • Передача данных осуществляется по сети Infiniband со скоростью соединения 56 Гбит/с;
      • Сеть Infiniband построена на оборудовании Mellanox;
      • На узлах хранения установлены SSD-накопители;
      • Тип хранилища — RBD.

      Система может быть организована следующим образом:

      В случае отказа сети Infiniband связь между дисковым хранилищем ВМ и вычислительными серверами устанавливается по сети Ethernet, развернутой на оборудовании Juniper. Новое соединение устанавливается автоматически.

      Благодаря высокой скорости связи с хранилищем этот кластер идеально подходит для размещения сайтов со сверхвысоким трафиком, потоковой передачей видео и контента, а также большими данными.

      Заключение

      Подведем основные итоги статьи.

      Кластер Continuous Availability просто необходим, когда каждая секунда простоя приносит существенные убытки. Если разрешено отключение в течение 5 минут, пока виртуальные машины развертываются на резервном узле, кластер высокой доступности может стать хорошим вариантом для снижения затрат на оборудование и программное обеспечение.

      Также важно напомнить, что единственный способ добиться отказоустойчивости — это чрезмерность. Обязательно реплицируйте свои серверы, оборудование и каналы передачи данных, каналы доступа в Интернет и питание. Повторяйте все, что можете. Такие меры позволяют устранить узкие места и потенциальные точки отказа, которые могут привести к простою всей системы. Приняв вышеуказанные меры, вы можете быть уверены, что у вас есть отказоустойчивый кластер, устойчивый к сбоям.

      Если вы считаете, что модель высокой доступности соответствует вашим требованиям и VMmanager Cloud — хороший инструмент для ее реализации, обратитесь к документации, чтобы узнать больше о системе. Желаю вам безаварийной и непрерывной работы!