Comments 14
Очень интересная статья!
Вопрос.
Как в таком случае быть с согласованностью данных? Допустим, в одной реплике проводка уже совершена, а в другой — еще нет, тут могут быть определенные проблемы даже при штатной работе, когда задержки репликации минимальны. А тут может иметь место своеобразный split brain по данным, поэтом это все надо как-то «сливать» воедино, разрешая конфликты…
Вопрос.
Отказывает Replication Link. ESXi будут работать только с локальными дисковыми устройствами
…
Происходит разрыв ISL (Inter-Switch Link). В этом случае ESXi-хосты теряют половину путей и могут обращаться только к своим локальным СХД.
Как в таком случае быть с согласованностью данных? Допустим, в одной реплике проводка уже совершена, а в другой — еще нет, тут могут быть определенные проблемы даже при штатной работе, когда задержки репликации минимальны. А тут может иметь место своеобразный split brain по данным, поэтом это все надо как-то «сливать» воедино, разрешая конфликты…
Мы исключаем ситуацию, при которой хосты с одной площадки будут обращаться к СХД на удаленной площадке (используя affinity rules) в штатном режиме. Т.е. запись ведется только на «оригинальный» том (локально), а не на «реплику», и случай, указанный вами, мы исключаем. После восстановления связи данные «выровняются» автоматически.
Если репликационный линк есть, то СХД будет поддерживать обе копии одинаковыми, рассогласования не будет, операции записи будут подтверждаться только после записи на два массива. Если связь совсем разорвана, то будет доступна для работы копия, которая была выбрана приоритетной при настройке. После восстановления связи копии отсинхронизируются.
операции записи будут подтверждаться только после записи на два массива.
Это важное уточнение, стало понятней.
А чем «не угодил» нетаповский метрокластер? ;)
У нас, как вы наверное знаете, на данный момент уже довольно давно эксплуатируется метрокластер на базе NetApp FAS. За годы он показал себя молодцом!
Мы продолжаем использовать решения NetApp, в том числе AFF.
Но в конкретном случае, с учётом ограничений и ценовых предложений, было принято решение запустить этот проект на Infinidat.
Также в нашем облаке есть СХД от IBM, Huawei, Dell, EMC. Каждой из них мы находим свою нишу и принимаем с любовью в нашу систему обслуживания и мониторинга ;)
Еще пару ссылок с описанием поподробнее
kb.vmware.com/s/article/71047
support.infinidat.com/hc/en-us/articles/360002108357-Active-Active-replication
kb.vmware.com/s/article/71047
support.infinidat.com/hc/en-us/articles/360002108357-Active-Active-replication
SAN, картинки про SAN, отказы по SAN…
Что с IP и Ethernet происходит, какие DR планы там?
Что будет, если один из PE решит сбойнуть аппаратно или программно, как остальные PE изолированы от этого сбоя?
Как вы поступаете с префиксами global unicast для интернет, которые должны быть видны и катастрофоустойчивить с двух площадок? Что будет при проблемах со связностью между двумя площадками и внешними префиксами в момент split brain?
Как вы растянули L2 между площадками? Как известно, растянутый L2 делает из двух площадок один домен отказа и облако получается неустойчивым к катастрофам.
Что с IP и Ethernet происходит, какие DR планы там?
Все клиентские сети заведены на обе площадки через общую сетевую фабрику. На каждой площадке работает Provider Edge (PE), на котором и терминируются сети клиента. PE объединены в общий кластер.
Что будет, если один из PE решит сбойнуть аппаратно или программно, как остальные PE изолированы от этого сбоя?
Как вы поступаете с префиксами global unicast для интернет, которые должны быть видны и катастрофоустойчивить с двух площадок? Что будет при проблемах со связностью между двумя площадками и внешними префиксами в момент split brain?
Как вы растянули L2 между площадками? Как известно, растянутый L2 делает из двух площадок один домен отказа и облако получается неустойчивым к катастрофам.
Что будет, если один из PE решит сбойнуть аппаратно или программно, как остальные PE изолированы от этого сбоя?
Резерв организован посредством HSRP. Программный или аппаратный сбой одного PE приведёт к переключению трафика на другое плечо. Для клиентов это будет означать потерю пары пакетов.
Как вы поступаете с префиксами global unicast для интернет, которые должны быть видны и катастрофоустойчивить с двух площадок? Что будет при проблемах со связностью между двумя площадками и внешними префиксами в момент split brain
Префиксы анонсируются с обеих площадок, но в один момент времени трафик в Интернет идёт по одному плечу. Это не проблема, так как пропускная способность линков посчитана с большим запасом. За этим ведётся постоянный мониторинг.
Проблемы со связностью и split brain маловероятны, так как каналы между площадками идут независимыми трассами, на территорию ЦОДа заведены через разные кабельные вводы и подключены к оборудованию в разных энергоцентрах. Это практически исключает их одновременный выход из строя.
Как вы растянули L2 между площадками? Как известно, растянутый L2 делает из двух площадок один домен отказа и облако получается неустойчивым к катастрофам.
Да, L2 растянут между площадками, но это не означает единый домен отказа, только если клиент сам не собрал бридж из двух интерфейсов на своей ВМ. В этом случае клиент потеряет связь со своими ВМ из-за некорректных настроек. Остальные клиенты при этом не пострадают, так как на уровне сетевого оборудования настроен storm-control.
Резерв организован посредством 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, то сломается и ваша сигнализация шлюза.
Весь вопрос цены и SLA.
Строить ЦОД фреймы Spine и SuperSpine c плюшками BGP EVPN и VXLAN, конечно, хорошо, но всегда встает вопрос цены вопроса и уровня масштабирования, на которых оно становится целесообразным.
А так, конечно, если не ограничены бюджетом и требования к отказоустойчивости решения высоки г-н @router прав, со временем имеет смысл рассмотреть вариант внедрения более надежного решения сетевой части чем L2 кластер с HSRP/VRRP/VIP даже для двух ЦОД фреймов.
Sign up to leave a comment.
Катастрофоустойчивое облако: как это работает