Как «быть готовым» или DR на Nutanix: асинхронная репликация



    Тема построения отказоустойчивых ЦОД с использованием гиперконвергентных систем Nutanix довольно обширна, поэтому, чтобы, с одной стороны, «не скакать по верхушкам», а с другой — не углубляться в занудность, разобьем ее на две части. В первой рассмотрим теорию и «классические» методы репликации, во второй — нашу новую фишку, так называемую Metro Availability, возможность построения синхронно-реплицируемого метрокластера (metropolitan-area, масштаба большого города и даже более) на расстоянии разноса датацентров до 400 километров.

    Сегодня уже очень редко приходится «начинать с самого начала» и объяснять, зачем вообще нужен резервный датацентр. Сегодня, когда, с одной стороны, выросли объемы и ценность хранимой в ЦОДах информации, с другой — подешевели и получили широкое распространение многие решения для организации распределенного хранения и обработки данных, обычно уже не надо объяснять «зачем» компании нужен резервный ЦОД. Но все еще приходится смотреть на то, «как именно» и какой он нужен.


    Nutanix, как компания молодая и возникшая «на острие потребностей» сразу ориентировалась на необходимость в современном датацентре иметь и резервный ЦОД, и правильную, многофункциональную репликацию. Именно поэтому, даже в самой младшей лицензии, которая идет с каждой системой Nutanix, и включена в цену (у нас она называется Starter), уже есть полнофункциональные средства репликации. Этим Nutanix отличается от многих традиционных систем, в которых репликация, зачастую, идет как опция и стоит дополнительных, часто весьма существенных денег.
    Не так у нас. Любой Nutanix уже умеет двунаправленную асинхронную репликацию. Двунаправленность, к слову, которая позволяет использовать оба датацентра в режиме «активный-активный» (а не «активный-резера», как обычно) также встречается далеко не у всех вендоров.

    В мире методов репликаций принято различать два основных принципа их работы, так называемые «синхронную» и «асинхронную» репликации.
    Синхронная репликация — это просто. Каждая операция записи на диски не считается законченной, пока та же операция записи не будет передана и завершена на дисках удаленной системы. Блок данных пришел, блок записался на диски локального устройства хранения, но приложение пока ответа «готово, записано!» не получило. Тем временем блок данных передался на удаленную систему, и на ней начат процесс записи этого блока. И только после того, как блок записан на удаленной системе, она рапортует об успехе, и вот тогда о завершении записи система сообщает приложению, блок которого записывался, локальная, первая система.



    Достоинства синхронной репликации очевидны. Данные записываются на локальную и удаленную системы максимально безопасным образом, копия в резервном ЦОДе всегда полностью идентична копии в вашем локальном ЦОДе. Однако есть и минус, он хоть и один, но — огромный.
    В случае, если у вас две системы связаны синхронной репликацией, то скорость активной, локальной для вашего приложения, системы будет равна скорости канала передачи данных между локальной и удаленной системой. Потому что пока удаленная система не получит блок данных для записи и не запишет его, ваша локальная система будет стоять и ждать. И если от приложения к дискам локальной системы у вас 16G FC, а от локальной системы до удаленной — 1GB Ethernet по каналу провайдера через несколько роутеров, то запись на локальные диски у вас не превысит скорость этого вот канала Gigabit Ethernet.

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

    Тем не менее, на практике, асинхронная репликация широко применяется. Что же делать с «неточностью копии»? Ну, во-первых, вы можете подумать, и оценить, что производительность записи системы и низкие значения latency при записи для вас важнее, чем возможная потеря 15 минут изменений в данных (а часто так и бывает). Либо же использовать в дополнение к общей асинхронной репликации для всех приложений, какие-то средства защиты данных на уровне конкретных приложений, а не хранилища данных вообще (пример — различные средства, которые есть у продуктов Microsoft, Availability Groups в MS Exchange, или аналогичные средства у MS SQL Server).

    В принципе тут Nutanix не изобрел ничего нового. На системах Nutanix есть как синхронная, с помощью которой реализована так называемая Metro Availability, так и асинхронная репликация с одного кластера Nutanix, в одном ДЦ, на другой, обычно в другом ДЦ. Асинхронная репликация выполнена с помощью передачи «снэпшотов» дискового хранилища, а синхронная — немного посложнее и полюбопытнее.

    Несколько слов о некоторой терминологической закавыке.
    Используемое сегодня всеми подряд слово «кластер» может ввести в некоторое затруднение, если не заблуждение. Дело в том, что в IT-индустрии сегодня слово «кластер» используется для обозначения не просто очень разных по природе вещей, но еще и, в основном, применяется к структуре, обеспечивающей высокую доступность (high availability). И настолько часто слово «кластер» применяется для обозначения именно и только «HA-cluster», что у многих создается впечатление, что «кластер»=«отказоустойчивый кластер», и только.
    Не всегда это так.

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

    Мне часто приходится отвечать на вопрос: «А можно ли нам разбросать ноды кластера Nutanix по разным сайтам, вот у нас и будет надежность?»
    Ответ тут такой: в теории — да, можно (конечно не стоит забывать, что вам нужно по сайтам протянуть также и по паре 10G каналов для внутрикластерной коммуникации, но даже это уже сегодня можно сделать), но на практике это не рекомендуется, и вообще «вы этого сами не захотите». Почему?

    Давайте представим, для аналогии, что кластер Nutanix это группа дисков в дисковом массиве, подключенном по FC. Вот у нас есть сайт A, и на нем JBOD-полка и в ней десяток дисков на FC, и сайт Б, с такой же полкой и десятком дисков, все включенные в общую FC-сеть. И мы решаем сделать из всех этих двадцати дисков RAID-группу в RAID-5 или 6. В принципе, в теории — можем, отчего нет. Каждый диск JBOD мы видим как отдельное FC-устройство, объединяй. Но дальше вопрос, что случится с RAID-ом, если у нас проедет экскаватор что-то случится с сетью между сайтами?
    Ничего хорошего. Потери половины, или даже хотя бы трети участников разом, скорее всего не выдержит ни RAID, ни, в сходной ситуации, кластер Nutanix.

    Именно поэтому, говоря с пользователями про кластеры и про Nutanix, приходится минимизировать путаницу, уточняя, что тут мы говорим: «кластер Nutanix», а тут под «кластер» понимается «HA-кластер VMware», а тут — Real Application Cluster (RAC) базы данных Oracle. И это будут все разные кластеры, часто расположенные иерархически друг над другом, и это совершенно нормально.

    Таким образом, раскидать ноды одного кластера Nutanix по сайтам для обеспечения отказоустойчивости мы не можем. Но можем на одном сайте расположить ноды одного «кластера Nutanix», на другом сайте — другого («кластера Nutanix»), а дальше объединить их в реплицируемые отношения в нужном нам направлении, например, из основного ДЦ в резервный, из головного офиса в филиалы (и наоборот), а то и вовсе в обоих направлениях.

    Причем, если это будет «синхронный» метрокластер, то поверх такой синхронно реплицируемой пары кластеров, которые, напомню, могут располагаться на расстоянии, в идеальном случае, до 400 километров (или, говоря техническим языком, нам надо, чтобы между сайтами roundtrip IP-пакета не превышал 5ms), а потом поверх этой метро-пары мы можем создать один кластер VMware, внутри которого виртуальные машины будут перезапускаться и мигрировать как на общем, едином дисковом хранилище, согласно политикам DRS, которые мы напишем. Но об этом я детальнее расскажу в следующей серии.

    Для асинхронной репликации данных с одного сайта на другой Nutanix использует внутренний механизм «снэпшотов Vmcaliber». При их использовании по каналу передачи данных между двумя сайтами передается только разностная часть, своеобразный diff содержимого дискового тома-контейнера. С исходной системы берется diff от предыдущей передачи, затем отправляется на удаленный сайт-получатель репликации, и там «накатывается». На сегодня интервал передачи асинхронной репликации у Nutanix — 15 минут. То есть, в наихудшем случае, вы можете потерять лишь 15 минут данных, при этом, в отличие от синхронной репликации, процесс не снижает производительность и не увеличивает latency при работе с данными.



    Таким образом, каждые 15 минут на DR-сайт уезжает diff дисков основной системы, и там автоматически разворачивается и накатывается, поддерживая ее актуальность. При потере системы в «главном» ДЦ, в наихудшем случае, вы потеряете изменения данных за 15 минут.
    Но что делать, если пятнадцатиминутный лаг — слишком много, и нужна синхронная репликация?
    Для этого можно воспользоваться нашей технологией Metro Availability, о которой следующий пост.
    Nutanix
    41,00
    Компания
    Поделиться публикацией

    Похожие публикации

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

      0
      Вроде и тема мне интересная, и подход Ваш нравится, но статьи читаются с трудом. Особенно режут глаз «маркетинговые вставки» вроде:

      Сегодня уже очень редко приходится «начинать с самого начала» и объяснять, зачем вообще нужен резервный датацентр. Сегодня, когда, с одной стороны, выросли объемы и ценность хранимой в ЦОДах информации, с другой — подешевели и получили широкое распространение многие решения для организации распределенного хранения и обработки данных, обычно уже не надо объяснять «зачем» компании нужен резервный ЦОД. Но все еще приходится смотреть на то, «как именно» и какой он нужен.

      Nutanix, как компания молодая и возникшая «на острие потребностей» сразу ориентировалась на необходимость в современном датацентре иметь и резервный ЦОД, и правильную, многофункциональную репликацию.


      Еще название можно было бы сделать например: «Nutanix: обзор асинхронной репликации.» или еще что нибудь говорящее.
      А может быть вообще первые три абзаца с картинкой убрать? Вставить сразу первой картинкой, ту, что «номер 2»?
      Удачи.
        0
        К сожалению, уровень читающих на Хабре очень разный, иногда лучше быть подробнее, чем оставить непонятное.
        Пропустить при чтении, если оно для вас чересчур подробно — секунда. Я сам так читаю :)

        ЗЫ. Такие комментарии, как и указания на опечатки, гораздо лучше смотрятся в личной почте.
        0
        Что происходит с основной системой, если лаг становится больше 15 минут? Например, идёт активная-активная запись, тут рраз, и экскаватор. Как рассказывает мой коллега: «связь уже восстановилась, но экскаватор продолжает копать». Так вот, даун. И размер снапшота растёт. А экскаватор продолжает копать. А запись продолжается.

        И? (Я понимаю, что в финале нас что-то ждёт — вопрос, что?) Удаление снапшота, отказ в записи, «ну не шмогла», ещё какие-то варианты?
          0
          Я думаю тут ничего уникального нет. Если с точки зрения VMware, то думают все будет зависеть от того насколько «правильно» настроен VMware SRM. В соответствии с этим либо будет, либо не будет выполнен перезапуск VM на удаленной площадке. Кстати в плане временного лага «подозрение» вызывает таймаут в 15 минут :). Помниться у VMware он точно такой же, если SRM организован на базе собственных аплайнсов VMware, а не на стороннем решении для репликации данных. Хотя при «умелом» подходе или некотором «везении» можно наверно и «split brain» поймать.

          А как обстоят дела с репликацией для Hyper-V?

          Ждем продолжение про синхронную репликацию. 400км — это хорошая заявка, но интересны детали реализации. На свитчах каких вендоров может быть построено такое решение (обеспечивающее RTT 5 мс на таком расстоянии)? Какие требования к каналу помимо RTT?
            0
            15 минут — безусловно надо быть очень аккуратными, например для тяжелых серверных нагрузок с большим количеством изменяемыех данных куда более безопасно ставить один час. Ну а самое лучше — кластеризация на уровне приложения.

            Для VDI — 15 минут не проблема.

            Для HyperV функционал Async DR идентичен, для KVM уже тоже практически реализован.

            Мы стараемся держать 100% функционала идентичным для всех гипервизоров, но чуть раньше выпускаем для ESXi, затем HyperV, затем KVM (но возможно в свете выхода нашей KVM Management Tool приоритеты будут меняться).

            Требования к каналу — собственно успевать пропускать трафик, никаких особенностей нет, хватает обычного L3.

            Очевидно что для 400км надо или прямое включение или роутеры / коммутаторы с ультра-низкими задержками. Мы рекомендуем Arista Networks и Cumulus.
              0
              Нам не нужен SRM для Async DR, в сущности многие клиенты как раз отказываются от него и переходят на наш DR.

              Полная автоматизация процессов, включая запуск VM на standby ДЦ. Работает все намного лучше и быстрее чем SRM, но отсутствуют некоторые «фишки» (смена IP адресов например).

              В любом случае идея менять IP адреса — кривая, намного лучше или VXLAN или просто DHCP.
                0
                Не, мне просто интересно, что происходит, когда репликация отстаёт. По мне логичным решением было бы делать удаление снапшота (когда места больше нет) и полный ресинк при восстановлении связи.
                  0
                  Все просто

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

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

                    0
                    Ок, вы не поняли вопрос.

                    Разорвалась связь. Копится дельта. Копится. День, два, месяц, пятый год. Место начинает заканчиваться. Действия системы? Удалить дельту, отказаться писать новые изменения в неё, поделить на ноль, нарисовать овечку на консоли?
                      0
                      Вы не поняли как работают у нас снапшоты ;)

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

                      Вот тут посмотрите:

                      stevenpoitras.com/the-nutanix-bible#snap_clone
                        0
                        С вашей же статьи:



                        Вот у вас становится A2, B2, C2, а для D2 уже нет места. А синхронизация не происходит. И не надо расказывать, что вы умеете делать снапшоты, в которые пишут, и которые не растут.

                        У всех с этим проблема, потому что она теоретическая. Все её решают. Я не с целью сказать «как у вас всё плохо» спрашиваю, а просто из любопытства: что вы делаете, когда в снапшот для асинхронной репликации больше нельзя писать (aka ремапить блоки для старых/новых данных)?
                          0
                          Снапшоты у нас делаются с ретеншн политиками, указывается сколько и за какой срок хранить.

                          Нет места где? Если вообще не осталось места для снапшотов VM — то это уже совершенно другая история, которая к DR в общем-то отношения имеет мало.

                          Если же просто долго был разрыв связи — мы передадим полный снапшот заново, это очевидный и логичный выход.
                            0
                            Аа…

                            Ещё раз: у вас асинхронная репликация. С помощью снапшотов. Если снапшоты копятся, место заканчивается.

                            Впрочем, вы уже ответили: полная ресинхронизация тех, кто переел по записи и срокам (если я правильно понял «retention policy»).
                              0
                              Retention policy — это стандартный термин применяющийся в бэкапах.

                              en.wikipedia.org/wiki/Glossary_of_backup_terms

                              Сколько копий и за какой срок хранить.
                    0
                    Кстати сегодня будет еще одна статья, точно будет интересно почитать — особенно для сервис-провайдеров :D

                    У нас лицензирование вводится специальное для ISP — в пересчете на процессор. Весьма выгодное надо заметить.
                      0
                      Как один из (бывших) сотрудников сервис-провайдеров могу сказать, что сервис-провайдеры обычно охотно соглашаются на «готовенькое o(1)», но совершенно не хотят платить за o(n).
                        0
                        Мог бы согласиться, если бы уже не продали пачки лицензий (только в РФ на миллионы долларов)

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

                        Но мы выкатили на рынок действительно уникальный продукт, о котором и будет речь :)
                          0
                          Если не секрет, кто из self-service хостеров (то есть не «всё под ваши нужды менеджер по продажам согласует», а «вот вам сла, панелька, тарифы и тыкайтесь сами») в РФ уже использует ваши решения, и под какими виртуализаторами?

                          Я понимаю, что вы сильно двигаете с рынка загнивающий netapp и (не знаю в каком состоянии) emc, но это всё махровый энтерпрайз, нет?

                          Или вы что-то разумное по цене сделали для self-service провайдеров?
                            0
                            Цены лучше приватно обсуждать, но для SP экономика очень интересная. Но там минимальный коммитмент (и довольно большой, AFAIR 100 серверов аппаратных минимальный порог).

                            Однозначно мы не конкурируем с «клаудмаузами» и прочими ультра-дешевыми хостингами.

                            Насчет «панелек» — у нас все с этим прекрасно, ибо 100% функционала (включая управление облаком / VM) — доступно через RESTful API.

                            Список клиентов выдавать не могу, в РФ не любят быть референсами :(

                            Через месяц один из ДЦ собирался правда рассказать как они сделаны.
                              0
                              Смотрите, простая математика на пальцах: дороже амазона продают только pets (за ваши деньги любой каприз). Self serving это cattle чистой воды.

                              Соотетственно, от неё мы и пляшем. При ценах амазоновского ebs, какая доля isp будет?

                              Насчёт клаудмауса — их эпикфейл, скорее, в сторону shared storage, а не cepha. Кривые руки на вашей системе тоже все порушить могут. В отличие от этого share nothing ломать куда сложнее.

                              Т.е. ebs интересно, но за деньги ниже амазона, причём настолько ниже, чтобы и тенант разницу заметил, и компании на фраппе с сувлой осталось.
                                0
                                У нас несколько другой сектор, нежели чем амазон и прочие.

                                Дорогие, но очень качественные частные облака на любом гипервизоре (ESXi, HyperV, KVM). Для энтерпрайз рынков, правительства, военные, медицина и тд.

                                Массовый рынок нам не интересен совершенно.

                                В РФ есть ДЦ / SP которые работают на этих рынках, особенно последние месяцы кардинально вырос спрос.
                                  0
                                  Это и называется pets. Любой каприз за ваши деньги. Очень любим капризным энтерпрайзом, но не любим amazon/openstack style облаками, т.к. требует слишком много человеческого времени и мешает автоматическому скейлу бэк-части (лицензии, нюансы конфигов под тенанта и т.д.).

                                  Совсем разные рынки.
                                    0
                                    Абсолютно согласен, мы и не претендуем :)

                                    Проблема в том что у нас реально поддержка работает по высшему классу (96% вопросов закрываем (если надо — чиним) менее чем за час, 99% менее чем за два часа).
                                    Гартнер клиентов наших опрашивал — более 90% рейтинг удовлетворенности.

                                    У нас нет множества слоев техподдержки, фактически сразу все вопросы попадают к очень квалифицированным инженерам.

                                    Поэтому мы не можем себе позволить идти на рынок дешевых облачных решений.

                                    p.s. мы скорее бесплатно отдадим, чтобы не грузить поддержку ;) ждите новостей. Лето будет жарким.
                                  0
                                  А инвесторам / владельцам компании скорее всего глубоко фиолетово, кривые ручки или ceph был причиной. Корень причины в «наколенных» технологиях — все пытаются построить очередной Амазон, но удается это единицам.
                                    0
                                    Там другой профиль использования. Правильное приложение глюк cloudmouse переживает как небольшой degradation в производительности.

                                    Старый энтерпрайз от такого бежит как от чумы, конечно, но новые ит-компании просто отлично себя чувствуют.

                                    Насчёт «получается» — я не видел iaas cattle хостеров, которые бы закрывались. Кроме скалакси, но там явно дело было не в оттоке клиентов.

                                    Зы 50 процентов, что cloudmouse не растеряет большинство клиентов.
                                      0
                                      Насчет приложений — это актуально только для самописного ПО. Даже Hadoop несчастный до сих пор крив до жути (проблемы с namenode так и не решены нормально).

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

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

                                      p.s. Скалакси кстати я активно консалтил, технически очень хорошее и красивое решение было. И команда отличная. Причины закрытия не технические точно, это факт.

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