Катастрофоустойчивое облако: как это работает

    Привет, Хабр!

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


    СХД катастрофоустойчивого облака на площадке OST.

    Что внутри


    Под капотом у кластера серверы Cisco UCS с гипервизором VMware ESXi, две СХД INFINIDAT InfiniBox F2240, сетевое оборудование Cisco Nexus, а также SAN-свитчи Brocade. Кластер разнесен на две площадки – OST и NORD, т. е. в каждом дата-центре идентичный набор оборудования. Собственно, это и делает его катастрофоустойчивым.

    В рамках одной площадки основные элементы тоже продублированы (хосты, SAN-свитчи, сетевка).
    Две площадки соединены выделенными оптоволоконными трассами, тоже зарезервированными.

    Пару слов про СХД. Первый вариант катастрофоустойчивого облака мы строили на NetApp. Здесь выбрали INFINIDAT, и вот почему:

    • Опция Active-Active репликации. Она позволяет виртуальной машине оставаться в работоспособном состоянии даже при полном отказе одной из СХД. Про репликацию расскажу подробнее дальше.
    • Три дисковых контроллера для повышения отказоустойчивости системы. Обычно их два.
    • Готовое решение. К нам приехала уже собранная стойка, которую только нужно подключить к сети и настроить.
    • Внимательная техподдержка. Инженеры INFINIDAT постоянно анализируют логи и события СХД, устанавливают новые версии в прошивке, помогают с настройкой.

    Вот немного фоточек с unpacking’а:





    Как работает


    Облако уже отказоустойчиво внутри себя. Оно защищает клиента от единичных аппаратных и программных отказов. Катастрофоустойчивое же поможет защититься от массовых сбоев в пределах одной площадки: например, отказ СХД (или кластера SDS, что случается нередко :) ), массовые ошибки в сети хранения и прочее. Ну и самое главное: такое облако спасает, когда становится недоступной целая площадка из-за пожара, блэкаута, рейдерского захвата, высадки инопланетян.

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

    Схема кластера устроена так, что любой ESXi-хост с клиентскими виртуальными машинами может обращаться к любой из двух СХД. Если СХД на площадке OST выйдет из строя, то виртуальные машины продолжат работать: хосты, на которых они работают, будут обращаться за данными к СХД на NORD.


    Вот так выглядит схема подключения в кластере.

    Это возможно благодаря тому, что между SAN-фабриками двух площадок настроен Inter-Switch Link: SAN-свитч Fabric A OST соединен с SAN-свитчем Fabric A NORD, аналогично и для SAN-свитчей Fabric B.

    Ну и чтобы все эти хитросплетения SAN-фабрик имели смысл, между двумя СХД настроена Active-Active репликация: информация практически одновременно записывается на локальную и удаленную СХД, RPO=0. Получается, что на одной СХД хранится оригинал данных, на другой – их реплика. Данные реплицируются на уровне томов СХД, а уже на них хранятся данные ВМ (ее диски, конфигурационный файл, swap-файл и пр.).

    ESXi-хост видит основной том и его реплику как одно дисковое устройство (Storage Device). От ESXi-хоста к каждому дисковому устройству идут 24 пути:

    12 путей связывают его с локальной СХД (оптимальные пути), а остальные 12 – с удаленной (не оптимальные пути). В штатной ситуации ESXi обращается к данным на локальной СХД, используя “оптимальные” пути. При выходе из строя этой СХД ESXi теряет оптимальные пути и переключается на “неоптимальные”. Вот как это выглядит на схеме.


    Схема катастрофоустойчивого кластера.

    Все клиентские сети заведены на обе площадки через общую сетевую фабрику. На каждой площадке работает Provider Edge (PE), на котором и терминируются сети клиента. PE объединены в общий кластер. При отказе PE на одной площадке весь трафик перенаправляется на вторую площадку. Благодаря этому виртуальные машины с площадки, оставшейся без PE, остаются доступными по сети для клиента.

    Давайте теперь посмотрим, что будет происходить с виртуальными машинами клиента при различных отказах. Начнем с самых лайтовых вариантов и закончим самым серьезным – отказом всей площадки. В примерах основной площадкой будет OST, а резервной, с репликами данных, – NORD.

    Что происходит с виртуальной машиной клиента, если…


    Отказывает Replication Link. Репликация между СХД двух площадок прекращается.
    ESXi будут работать только с локальными дисковыми устройствами (по оптимальным путям).
    Виртуальные машины продолжают работать.



    Происходит разрыв ISL (Inter-Switch Link). Случай маловероятный. Разве что какой-нибудь бешеный экскаватор перекопает сразу несколько оптических трасс, которые проходят независимыми маршрутами и заведены на площадки через разные вводы. Но все-таки. В этом случае ESXi-хосты теряют половину путей и могут обращаться только к своим локальным СХД. Реплики собираются, но хосты не смогут к ним обращаться.

    Виртуальные машины работают штатно.



    Отказывает SAN-свитч на одной из площадок. ESXi-хосты теряют часть путей к СХД. В этом случае хосты на площадке, где отказал свитч, будут работать только через один свой HBA.

    Виртуальные машины при этом продолжают работать штатно.



    Отказывают все SAN-свитчи на одной из площадок. Допустим, такая беда случилась на площадке OST. В этом случае ESXi-хосты на этой площадке потеряют все пути к своим дисковым устройствам. В дело вступает стандартный механизм VMware vSphere HA: он перезапустит все виртуальные машины площадки OST в NORD`е максимум через 140 секунд.

    Виртуальные машины, работающие на хостах площадки NORD, работают штатно.



    Отказывает ESXi-хост на одной площадке. Тут снова отрабатывает механизм vSphere HA: виртуальные машины со сбойного хоста перезапускаются на других хостах – на той же или же удаленной площадке. Время перезапуска виртуальной машины – до 1 минуты.

    Если отказывают все ESXi-хосты площадки OST, тут уже без вариантов: ВМ перезапускаются на другой. Время перезапуска то же.



    Отказывает СХД на одной площадке. Допустим, отказала СХД на площадке OST. Тогда ESXi-хосты площадки OST переключаются на работу с репликами СХД в NORD’e. После возвращения сбойной СХД в строй произойдет принудительная репликация, ESXi-хосты OST снова начнут обращаться к локальной СХД.

    Виртуальные машины все это время работают штатно.



    Отказывает одна из площадок. В этом случае все виртуальные машины будут перезапускаться на резервной площадке через механизм vSphere HA. Время перезапуска ВМ – 140 секунд. При этом все сетевые настройки виртуальной машины сохранятся, и она остается доступной для клиента по сети.

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



    Вот от таких отказов защищает катастрофоустойчивое облако на базе двух дата-центров.

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

    Источники:

    1. www.infinidat.com/sites/default/files/resource-pdfs/DS-INFBOX-190331-US_0.pdf
    2. support.infinidat.com/hc/en-us/articles/207057109-InfiniBox-best-practices-guides
    DataLine
    Экосистема на базе дата-центров TIER III

    Комментарии 13

      0
      Очень интересная статья!

      Вопрос.
      Отказывает Replication Link. ESXi будут работать только с локальными дисковыми устройствами

      Происходит разрыв ISL (Inter-Switch Link). В этом случае ESXi-хосты теряют половину путей и могут обращаться только к своим локальным СХД.


      Как в таком случае быть с согласованностью данных? Допустим, в одной реплике проводка уже совершена, а в другой — еще нет, тут могут быть определенные проблемы даже при штатной работе, когда задержки репликации минимальны. А тут может иметь место своеобразный split brain по данным, поэтом это все надо как-то «сливать» воедино, разрешая конфликты…
        0
        Мы исключаем ситуацию, при которой хосты с одной площадки будут обращаться к СХД на удаленной площадке (используя affinity rules) в штатном режиме. Т.е. запись ведется только на «оригинальный» том (локально), а не на «реплику», и случай, указанный вами, мы исключаем. После восстановления связи данные «выровняются» автоматически.
          +1
          Если репликационный линк есть, то СХД будет поддерживать обе копии одинаковыми, рассогласования не будет, операции записи будут подтверждаться только после записи на два массива. Если связь совсем разорвана, то будет доступна для работы копия, которая была выбрана приоритетной при настройке. После восстановления связи копии отсинхронизируются.
            +1
            операции записи будут подтверждаться только после записи на два массива.


            Это важное уточнение, стало понятней.
              0

              Я правильно понял, что в таком случае файловая система на виртуальной машине переходит в read-only? И остаётся в таком режиме до восстановления работоспособности вышедших из строя компонентов?

                0
                В каком именно случае? При разрыве фабрик FC все работает и VMFS read/write, при разрыве IP (репликация) тоже все работает. Если есть разрыв по IP (репликация), то не основная сторона просто не доступна, а на основной все продолжает работать. Это сделано чтобы не было split brain.
          0
          А чем «не угодил» нетаповский метрокластер? ;)
            0

            У нас, как вы наверное знаете, на данный момент уже довольно давно эксплуатируется метрокластер на базе NetApp FAS. За годы он показал себя молодцом!
            Мы продолжаем использовать решения NetApp, в том числе AFF.
            Но в конкретном случае, с учётом ограничений и ценовых предложений, было принято решение запустить этот проект на Infinidat.
            Также в нашем облаке есть СХД от IBM, Huawei, Dell, EMC. Каждой из них мы находим свою нишу и принимаем с любовью в нашу систему обслуживания и мониторинга ;)

              0
              Ясно. Спасибо.
            0
            Еще пару ссылок с описанием поподробнее
            kb.vmware.com/s/article/71047
            support.infinidat.com/hc/en-us/articles/360002108357-Active-Active-replication
              0
              SAN, картинки про SAN, отказы по SAN…
              Что с IP и Ethernet происходит, какие DR планы там?
              Все клиентские сети заведены на обе площадки через общую сетевую фабрику. На каждой площадке работает Provider Edge (PE), на котором и терминируются сети клиента. PE объединены в общий кластер.

              Что будет, если один из PE решит сбойнуть аппаратно или программно, как остальные PE изолированы от этого сбоя?
              Как вы поступаете с префиксами global unicast для интернет, которые должны быть видны и катастрофоустойчивить с двух площадок? Что будет при проблемах со связностью между двумя площадками и внешними префиксами в момент split brain?
              Как вы растянули L2 между площадками? Как известно, растянутый L2 делает из двух площадок один домен отказа и облако получается неустойчивым к катастрофам.
                0
                Что будет, если один из PE решит сбойнуть аппаратно или программно, как остальные PE изолированы от этого сбоя?

                Резерв организован посредством HSRP. Программный или аппаратный сбой одного PE приведёт к переключению трафика на другое плечо. Для клиентов это будет означать потерю пары пакетов.

                Как вы поступаете с префиксами global unicast для интернет, которые должны быть видны и катастрофоустойчивить с двух площадок? Что будет при проблемах со связностью между двумя площадками и внешними префиксами в момент split brain

                Префиксы анонсируются с обеих площадок, но в один момент времени трафик в Интернет идёт по одному плечу. Это не проблема, так как пропускная способность линков посчитана с большим запасом. За этим ведётся постоянный мониторинг.
                Проблемы со связностью и split brain маловероятны, так как каналы между площадками идут независимыми трассами, на территорию ЦОДа заведены через разные кабельные вводы и подключены к оборудованию в разных энергоцентрах. Это практически исключает их одновременный выход из строя.
                Как вы растянули L2 между площадками? Как известно, растянутый L2 делает из двух площадок один домен отказа и облако получается неустойчивым к катастрофам.

                Да, L2 растянут между площадками, но это не означает единый домен отказа, только если клиент сам не собрал бридж из двух интерфейсов на своей ВМ. В этом случае клиент потеряет связь со своими ВМ из-за некорректных настроек. Остальные клиенты при этом не пострадают, так как на уровне сетевого оборудования настроен storm-control.

                  0
                  Резерв организован посредством HSRP

                  Вы не только растянули L2 между площадками, вы еще используете протокол без свидетелей или каких-то защитных механизмов через резервирование сигнализации (например, BGP), который может легко привести к split brain. Программный или аппаратный сбой между «PE» приведет к появлению по 1 активному и независимому шлюзу на каждой площадке «катастрофоустойчивого» облака.

                  Проблемы со связностью и split brain маловероятны, так как каналы между площадками идут независимыми трассами, на территорию ЦОДа заведены через разные кабельные вводы и подключены к оборудованию в разных энергоцентрах

                  У вас ограниченный SPOF анализ для «катастрофоустойчивого» облака: рассмотрите выше каналов — сбои в аппаратной (например, ASIC) или программной частях (например, *IOS*), а так же подумайте про человеческую ошибку (например, конфигурацию оборудования). Для HSRP я привел его выше: как видите, энергоцентры и кабельные вводы не спасают, когда все сводится в 1 логическую точку резервирования шлюза.

                  L2 растянут между площадками, но это не означает единый домен отказа

                  У вас HSRP в едином домене отказа живет, от сбоя в нем пострадает большинство клиентов. Домен отказа характеризуется не только штормами, но и консистентостью сигнализации, чего L2 гарантировать не может.

                  Остальные клиенты при этом не пострадают, так как на уровне сетевого оборудования настроен storm-control.

                  У большинства производителей оборудования strom-control работает на портах стыков, но не на L2 домен индивидуально. У вас где-то trunk с набором VLAN нескольких клиентов. 1 из этих клиентов сделал плохое и в его VLAN шторм. Как storm-control вырежет шторм только для этого клиента? Если вы не можете ограничить шторм в 1 L2 сегменте, то storm-control без разбора подропает бродкасты всех L2 сегменты в trunk и L2 сломается у всех клиентов. Если в этом trunk еще идет и L2 для HSRP, то сломается и ваша сигнализация шлюза.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое