Отказоустойчивость для Hyper-V VM и MSSQL

    Вместо предисловия


    Отказоустойчивость понимается — в рамках одного дата-центра – то есть защита от выхода из строя 1-2 физических серверов.
    Реализация у нас будет недорогая с точки зрения «железа», а именно то, что дает в аренду один известный немецкий хостер.
    С точки зрения стоимости программного обеспечения оно либо бесплатное, либо уже имеется. Партнерская программа Microsoft, так сказать, в действии.
    С появлением на рынке Windows Server 2012 было много рекламы «От сервера до облака», «Ваши приложения работают всегда». Именно это мы и попробуем реализовать.

    Конечно, есть тема для «холиваров»: что лучше VMWare или Hyper-V – но это тема не этого поста. Спорить не буду. На вкус и цвет — все фломастеры разные.
    Наверное, некоторые скажут, что это дело можно отправить в Azure – возможно окажется, что это даже дешевле, но мы параноики и хотим свое «облако» свой кластер с фэйловером и виртуалками. Кстати, ничего потом не мешает отправить наше хозяйство туда, при желании.

    image

    Требования к решению


    Есть некий проект который использует:
    1. База данных – MSSQL
    2. backend – IIS
    3. frontend – некое приложение на PHP


    Необходимо реализовать:
    1. Данная связка работала «всегда».
    2. Выход из строя «железного» сервера не вызывал простоев в работе.
    3. Данные не терялись.
    4. Была некая балансировка нагрузки.
    5. Масштабируемость.
    6. Для осуществления вышеперечисленного не приходилось городить огород программными средствами (например Identity для MSSQL).

    Все это хозяйство будет размещаться на одном известном немецком хостинге.

    Реализация


    Разобьем реализацию на логические части:
    1. Требования к аппаратной части.
    2. Подготовительные действия
    3. Отказоустойчивость MSSQL (с элементами балансировки).
    4. Отказоустойчивость backend и frontend
    5. Настройка сети
    6. Отказоустойчивость: еще один рубеж.


    Требования к аппаратной части

    Для задуманного нам потребуется минимум 4 сервера. Крайне желательно, что бы они находились в одном дата центре, а лучше в одном свитче. В нашем случае у нас будет отдельная стойка. А раз стойка одна, то как нам объяснили, свитч у нее тоже выделенный.

    Сервера

    2 сервера – процессор с поддержкой виртуализации, 32ГБ ОЗУ, 2HDD X 3TB (RAID 1)
    2 оставшихся – пойдут под SQL, поэтому в них будем использовать маленькое изменение (в конфигурации один жесткий диск заменим на RAID контроллер и 3 SAS диска по 300ГБ (они пойдут в RAID 5 – быстрое хранилище для MSSQL)).
    В принципе это делать не обязательно. Отказоустойчивость, конечно, снижается, но скорость важнее.
    Так же понадобится флэшка (но об этом ниже.)
    Опционально: отдельный свитч для организации локальной сети, но это можно сделать и позже по мере роста проекта.

    Подготовительные действия

    Так как мы поднимаем Failover Cluster нам будет необходим домен Active Directory.
    Он же потом упростит нам задачу авторизации нашего backend на SQL сервере.
    Поднимаем контроллер домена в виртуальной машине.
    Так же необходимо определится с адресацией локальной сети.
    Наш DC (Domain Controller), понятное дело, не будет иметь белого ip адреса и будет выходить «наружу» через NAT.
    В настройках всех машин виртуальных и не очень Primary DNS: наш контроллер домена.
    Вторыми ip адресами, помимо белых выданных, необходимо прописать адреса нашей локальной сети.
    Идеальный вариант описан в части масштабируемость ниже.

    Отказоустойчивость MSSQL.

    Будем использовать кластеризацию MSSQL, но не в классическом понимании, то есть будем кластеризовывать не все службу, а только Listener. Кластеризация всего MSSQL требует общего хранилища, которое будет являться точкой отказа. Мы же идем по пути минимизации точек отказа. Для этого мы воспользуемся новой возможностью MSSQL Server 2012 — Always On.
    Ода этой фишке неплохо описана SQL Server 2012 – Always On by Andrew Fryer. Там же подробно расписано как настроить.
    Если вкратце объединение двух технологий репликации и мирроринга. Оба экземпляра базы данных содержат идентичную информацию, но при этом используют каждый свое хранилище.
    Так же имеется возможность использовать балансировку нагрузки, применением read-only реплик. Предварительно настроив маршруты для чтения, подробнее — Read-Only Routing with SQL Server 2012 Always On Database Availability Groups
    Вообще Best Practice по этому вопросу подробно освещены в Microsoft SQL Server AlwaysOn Solutions Guide for High Availability and Disaster Recovery by LeRoy Tuttle
    Заострю внимание только на том, что конфигурация путей в установках MSSQL должна быть идентичной.

    Отказоустойчивость backend и frontend.

    Данный функционал мы будем реализовывать кластеризацией виртуальных машин.
    Что бы кластеризовать виртуальные машины, нам понадобится Cluster Shared Volume (CSV).
    А что бы создать CSV нам понадобиться SAN, причем он должен проходить валидацию кластером и быть бесплатным. Оказывается, не такая простая задача. Было перебрано десяток решений (Open Source и не очень). В итоге искомый продукт был обнаружен. Зовется он NexentaStor
    18 TB raw space бесплатно, куча протоколов и фишечек.
    Единственное что, при развёртывании, необходимо учитывать опыт и рекомендации ULP Опыт эксплуатации Nexenta, или 2 месяца спустя
    Мы к сожалению, по этим граблям прошлись самостоятельно.

    Так же у Nexenta переодически бывает «болезнь» — перестает отвечать Web-интерфейс, при этом все остальные сервисы функционируют нормально. Решение имеется http://www.nexentastor.org/boards/2/topics/2598#message-2979
    Итак. Подробнее об установке.
    Пытаемся поставить Nexenta, установка проходит успешно. Заходим в систему и удивляемся – все свободное место ушло под системный пул и данные нам размещать негде. Казалось бы решение очевидно — дозаказываем жесткие диски в сервер и создаем пул для хранения данных, но есть другое решение. Для этого то, мы и воспользуемся флэшкой.
    Ставим систему на флэшку (данный процесс занимает около 3 часов).
    После установки создаем системный пул и пул для данных. К системному пулу прицепляем флэшку и синхронизируем. После этого флэшку из пула можно убрать. Подробно описано на http://www.nexentastor.org/boards/1/topics/356#message-391.
    И получаем такую картинку.

    image

    Создаем zvol. После создания привязываем его к target и публикуем через ISCSI.
    Подключаем его к каждой ноде нашего кластера. И добавляем его в Cluster Shared Volume.

    image

    Соответственно, в настройках Hyper-V на каждой ноде кластера указываем расположение конфигураций виртуальных машин и файлов жестких дисков именно на нем.
    Так же не маловажно – имена виртуальных свитчей на каждой ноде тоже должно быть одинаковым.

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

    Так же не забываем добавить наш контроллер домена в Hyper-V кластер.

    Настройка сети

    У нас уже есть отказоустойчивый SQL, у нас есть отказоустойчивые frontend и backend.
    Осталось сделать так, что бы они были доступны из внешнего мира.
    У нашего хостинг провайдера есть 2 услуги для реализации данного функционала:
    1. Есть возможность запросить дополнительный IP адрес для нашего сервера и привязать его к MAC адресу.
    2. Так же есть возможность запросить целую подсеть /29 или /28 и попросить смаршрутизировать ее на адрес из 1 пункта.

    Создаем в нашем Hyper-v кластере еще одну виртуальную машину. Для этой цели мы будем использовать ClearOS. Выбор на нее пал, сходу, потому, что она построена на базе CentOS и поэтому на нее можно поставить службы интеграции.
    Не забываем после установки их поставить, а то могут быть проблемы с пропаданием сетевых интерфейсов.

    У нее будут 3 интерфейса:
    1. Локальная сеть
    2. DMZ
    3. Внешняя сеть


    Внешеняя сеть – это тот дополнительный адрес который мы попросили у провайдера
    DMZ – подсеть которую нам выдал провайдер.

    image

    Так же данная машина будет выпускать наши виртуальные машины (не имеющий белого ip адреса) наружу через NAT.
    Таким образом мы сделали нашу маршрутизацию так же отказоустойчивой. Маршрутизатор кластеризован и тоже может перемещаться с ноды на ноду.
    На самих же нодах не забываем настроить файервол (блокируем на опасных портах доступ со всех ip, кроме доверенных и локальных). А лучше, отключить белые ip адреса.
    Конечно, если нет необходимости больше чем в одном белом адресе, то целую подсеть выделять смысла нет и доступ снаружи можно реализовать через Port Forwarding и Reverse Proxy.

    Отказоустойчивость: еще один рубеж

    Как уже говорилось раньше, мы идем по пути уменьшения точек отказа. Но одна точка отказа у нас все-таки осталась – это наш SAN. Так как все кластеризованные виртуальные машины лежат на нем, в том числе и наш контроллер домена, исчезновение данного ресурса не только приведет к пропаданию backend и frontend, но и приведет к разваливанию кластера.
    У нас остался еще один сервер. Его мы будем использовать как последний рубеж.
    Мы создадим на нашем резервном сервере виртуальную машину со вторым контроллером домена и настроим на нем репликацию AD.
    Не забываем вторичным DNS сервером на всех наших машинах прописать именно его. В таком случае, когда пропадет CSV, те службы, которые от CSV не зависят, а именно наш кластеризованный SQL-listener, продолжат функционировать.
    Для того что бы backend и frontend, после падения CSV, могли вернуться в строй, мы воспользуемся новой функцией Windows Server 2012 – репликацией Hyper-V. Критичные для проекта машины мы будем реплицировать на наш 4 сервер. Минимальный период репликации 5 минут, но это не настолько важно, т.к. frontend и backend содержат статические данные, которые обновляются очень редко.
    Для того, что бы это осуществить, необходимо добавить кластерную роль «Hyper-V Replica Broker». И в его свойствах настроить свойства репликации. Подробнее о репликации:
    Обзор реплики Hyper-V
    Windows Server 2012 Hyper-V. Hyper-V Replica
    И, конечно же, не забываем про бэкап.

    Немного про масштабируемость

    Это решение в перспективе можно масштабировать, добавлением серверов-нод.
    MSSQL сервер масштабируется добавлением нод-реплик, доступных для чтения и балансировкой маршрутов чтения.
    Виртуальные машины можно «раздувать» до размеров ноды по ресурсам, без привязки к «железу».
    В целях оптимизации трафика, можно добавить дополнительные интерфейсы к серверам-нодам и подключения виртуальных свитчей Hyper-V к этим интерфейсам. Это позволит отделить внешний трафик от внутреннего.
    Можно реплицировать виртуальные машины в Azure.
    Можно добавить SCVMM и Orchestrator и получить «частное облако».

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

    image

    P.S. Три месяца — полет нормальный. Количество кластерных нод и виртуальных машин растет. На скриншоте видно, что система уже несколько больше описываемой.

    Пост, наверное, не раскрывает всех деталей настройки, да такой задачи и не было. Я думаю, все детали будет читать утомительно. Если вдруг, кому будут интересны подробности – милости прошу. Критика приветствуется.
    Share post

    Similar posts

    Comments 21

      0
      (андрюх, привет!) а как подмонтировали флешку? nexenta дает примаунтить через интерфейс?
        0
        Немного не понял вопроса, но nexenta встала на флэшку. А танцы с бубном через командную строку.
          +2
          Главный вопрос, почему не встроенный функционал ws2012? scale-out file server + asynchronous cluster? зачем отдавать 2 сервера под sql? глупо ведь. кто вам сказал что рейд 5 — быстр?
          Асинхронный кластер фактически убирает точку отказа из системы (разве только свитч, но поставьте 2 и все).
            –1
            RAID 5 на SAS — быстро и безопасно.
            2 сервера под SQL — для распределения нагрузки на чтение, автоматического фэйловера и потери максимум одной транзакции? Глупо? Возможно.
            А вы про асинхронный кластер, про Hyper-V или MSSQL, если про Hyper-V? То каким образом он убирает точку отказа?
              0
              RAID 5 на SAS — быстро и безопасно.

              Не на трёхтерабайтных монстрах, максимально рекомендуемый объем составляет 600 Гб. Для больших дисков надо использовать RAID6/10/DP/DDP.
                0
                Полностью поддерживаю. У нас 300 Гб.
                  0
                  Меня сбил с толку скриншот Nexenta, на котором ST33000650NS.
              0
              А вот про SoFS я честно не совсем понял, куда вы его собираетесь вставлять? Поднимать его на кластерном диске который уже используется? Добавлять еще одну службу прослойкой?
                0
                Стандартная реализация подразумевает JBOD, подключенный к двум нодам SoFS:

                image
                  0
                  Я в курсе. А так как возможности поставить туда JBOD нет — такой услуги у хостера нет, а везти свой в Германию не целесообразно, то мы и используем Nexenta. И подцепляем CSV по iSCSI. Поэтому мне было непонятно, как предалагает использовать уважаемый 4c74356b41
                  встроенный функционал ws2012
                  .
                    0
                    Вопрос про SQL Вы не совсем поняли, почему Вы сделали это на физических серверах, а не на виртуальных?
                    Про функционал ws2012… картинка не вставляется habrastorage.org/storage2/488/00b/813/48800b8135b558718170a62683297517.jpg
                    Это разве не sofs?
                    Про кластер, я не вполне пойму где точка отказа если все дублированно, 2 хоста 2 для виртуальных машин и 2 для сторейджа?
                      +1
                      По картинке.
                      Кластеризуется только доступ по SMB.
                      В нашем случае мы можем через SoFS опубликовать папку c нашего CSV.
                      Он подключен к кластеру по iSCSI. Такое тоже может быть, на вашей картинке внизу этот случай тоже имеется или как проиллюстрировал navion — JBOD, но смысла в этом особого нет. Так как, этот диск и так подцеплен к каждой ноде.

                      Почему SQL на физических серверах?
                      А вы пробовали размещать базу размером порядка 40Гб, к которой идет порядка 3000 запросов в секунду в виртуальной машине? Проект неплохо нагружен.
                      Как скорость работы?
                      Если размещать подобную базу в виртуальной машине, то нужно ооочень быстрое хранилище.
                      Конечно, как вариант, создать на той же nexenta еще один LUN и разместить базу в нем, а к серверу подцеплять по iSCSI, но скорость, все равно, будет в разы меньше, чем на SAS дисках.

                      Точка отказа — это SAN, nexenta. Она является единственным «строайджем». Именно поэтому в системе предусмотрено резервирование виртуальных машин репликацией.
                        –1
                        Нет-нет-нет. по картинке в кластере 2 сервера файловые, а остальные к ним обращаются.
                        касательно нагрузки на sql — у меня около нуля идей, я не специалист по базам данных, но «guest clustering» (в вашем случае «always on») мне кажется удобнее всегда чем 2 реальных сервера.
                        И соответственно я вел речь про свою картинку. те 2 файловых сервера и несколько хостов hyper-v. нет единой точки отказа.
              0
              А каким образом 2 файловых сервера будут иметь общее хранилище? Вы не совсем понимаете картинку? Это чисто теоретические умозаключения по картинке?
                –1
                это тн file based (smb 3.0) storage для hyper-v
                +1
                Путаете своими комментариями людей. Без JBOD он бесполезен.
                  0
                  А почему в качестве кластерного хранилища не использовали тот же Windows Server 2012? Сейчас даже не обязательно редакцию DataCenter иметь, iSCSI на всех прекрасно работает.
                    0
                    Честно говоря, рассматривали данную возможность.
                    Но, честно говоря, смутила реализация: VHD файл, даже не VHDX — лежит на жестком диске и отдается службой, это первое. Второе — скорость получалась меньше.
                      0
                      Второе — скорость получалась меньше.

                      Сильно? Сеть, я так понимаю, 1G, и диски обычные на обычном контроллере?

                      Я прямых сравнений не проводил, если честно. Когда-то давно сравнивал со StarVind-ом под той-же виндой, в конечном счете вышел паритет, но при сети в 1G, производительность дисковой подсистемы не очень-то важна. Сейчас у меня есть парочка программных SAN-ов на основе Windows Server 2012, но там 24 SAS диска по 15K оборотов в 10-х RAID-ах на контроллерах с кучей памяти и по 2 10G оптических интерфейса. Вот на них бы получилось сравнение более правдоподобное. Но они пока в продакшене.

                      P.S. Хотя я конечно сторонник «аппаратных» решений, да и FC как-то роднее iSCSI, хоть и гораздо более специфичен и капризен.
                    0
                    Да, в принципе, не сильно. Сеть — да 1G. Больше смутила реализация в WIndows.
                    И как поживают такие SAN?
                    На момент реализации Windows 2012 только появилась — не решился в продакшене эксперементировать.
                    Недавно Nexenta поставил на самосборный SAN с Enterprise HDD, SSD и большим количеством памяти — весьма не плохо, если учитывать некоторые моменты.
                    P.S. «Аппаратные» решения тоже больше нравятся, но стоимость, порой не оправдана для некоторых задач.
                      0
                      И как поживают такие SAN?

                      Да прекрасно поживают. Захожу на них ОЧЕНЬ редко. С момента внедрения, около 9 месяцев, раза три заходил LUNку создать и все. Кормят эти штуки данными два кластера по 4-ноды, один на Hyper-V второй на VMWare. Пяток SQL-ей, серверов 1С, и еще около сотни виртуалок от контроллеров домена, до фермы SP и SCCM. Производительности всем хватает, правда кое где есть затыки, но только там, где iSCSI 1G.

                    Only users with full accounts can post comments. Log in, please.