Комментарии 37
аналогичные решения есть у большинства крупных производителей СХД
Как же NetApp то забыли?
Спасибо за статью.
В статье же перечислены технологии которые позволяют выполнять операции чтения/записи через любой массив в кластере, в любой момент времени.
C NetApp MetroCluster данные читаются локально, они доступны на обеих площадках. Это можно менять опцией. Запись же идёт по оптимальному пути, используется ALUA, и синхронно попадает на вторую площадку. Да в один момент времени LUN доступен для записи только на одной площадке. Зато с точки зрения надежности позволяет избавиться от решения проблемы когерентности записи данных. Для приложений всё прозрачно. В случае c Pure ActiveCluster надо не забывать о том, что эту проблему необходимо решать на уровне приложений. При одновременной записи в одни блоки в LUNе на разных площадках "побеждает" тот, кто записал последни.
В этой статье я перечислил именно те конкурентные продукты, которые позволяют выполнять запись на обе площадки в один момент времени и выполнять Transperent Failover (то есть хост не замечает потерю LUNa в случается выхода из строя одной СХД, теряется только часть путей до LUNа). NetApp MetroCluster ни хуже, ни лучше, у него другая идеология работы, поэтому я его не включал в этот перечень конкурентных продуктов.
выполнять Transperent Failover (то есть хост не замечает потерю LUNa в случается выхода из строя одной СХД, теряется только часть путей до LUNа)
Что без проблем позволяет сделать MetroCluster. И Dell EMC VPLEX.
Включать продукты в список по критерию деталей реализации — странный подход. Клиент решает проблему, а не покупает конкретную реализацию технического решения.
DellEMC VPLEX не является СХД, это виртуализатор в первую очередь.
Всё это происходит быстрее, чем сработает таймаут на стороне хоста.
То есть если мы говорим о решении, которе должно обеспечивать RTO, RPO = 0, то MetroCluster подходит под это определение.
Клиент не покупает СХД в вакууме, он покупает решение.
Всё это происходит быстрее, чем сработает таймаут на стороне хоста
Предложите это клиенту при покупке NetApp и зафиксируйте в договоре :)
Сам NetApp заявляет, что MetroCluster обеспечивает RPO Zero и RTO under 120 seconds.
Пруф — www.netapp.com/us/products/backup-recovery/metrocluster-bcdr.aspx
Solaris и Linux по дефолту имеют 60 секунд scsi timeout.
VMware вроде 140 секунд, виртуальные машины вероятно переживут такое пропадание дисков, приложения которые работают в ВМ — вряд ли.
То есть в большинстве случаев, мы получим простой бизнеса.
Вот и главное отличие этих решений, в случае active/active кластеров, такой как Pure Storage ActiveCluster — резервная площадка всегда готова, что бы принять нагрузку на себя. И здесь действительно RTO&RPO = Zero.
Есть еще аргументы в пользу NetApp MetroCluster? Или теперь понятно почему его нет в списке конкурентных решений?
Solaris и Linux по дефолту имеют 60 секунд scsi timeout.
Который невозможно поменять? Так себе аргумент
То есть в большинстве случаев, мы получим простой бизнеса.
Предлагаю рассказывать эти байки клиентам, которые успешно используют MetroCluster последние 10+ лет и не имеют простоя бизнеса из-за проблем с хранилищем.
Сам NetApp заявляет, что MetroCluster обеспечивает RPO Zero и RTO under 120 seconds.
NetApp аккуратен в своих заявлениях, даже маркетинговых.
Клиенты более 10 лет используют решение, простоев не имеют. В том числе клиенты в России. Всё проверяется тестированием на реальных задачах.
Solaris и Linux по дефолту имеют 60 секунд scsi timeout.
Который невозможно поменять? Так себе аргумент
С вашим подходом, можно выкрутить таймаут в 120+ секунд и заявить, что СХД обеспечивает Transperent Failover! Ведь ОС не заметит пропадание дисков… Но вот любое приложение может заметить и отвалиться… И тут вы скажите подкрутить таймаут в приложении, верно? Пусть тоже подождет 120 секунд :) Но ведь, это означет, что все пользователи приложения теперь тоже должны подождать 120 секунд… А если это крупный банк или ритейл компания, где каждая транзакция или каждый клиент на счету. Как ни говори, а это простой бизнеса. Ваш подход — подкрутить таймауты, не серьезен.
Еще раз повторюсь, в статье описаны решения, которые обеспечивают RTO&RPO = 0. MetroCluster таким не является (ссылка выше).
Я очень рад за клиентов которые успешно внедрили и используют MetroCluster. Означает, что это решение полностью покрывает их потребности и SLA.
За какое время происходит переключение путей в растянутой FC фабрике? По вашей логике, если это значение >0, то никто не обеспечивает RTO=0.
Oracle RAC по умолчанию имеет значение disktimeout = 200 секундам. Как с этим жить фанатам RTO= абсолютному 0?
Например, есть крупный банк в России, который имеет 5 метрокластеров. Банк частный. Сколько бы метрокластеров они купили, если бы первый не обеспечил им RTO=0?
За какое время происходит переключение путей в растянутой FC фабрике? По вашей логике, если это значение >0, то никто не обеспечивает RTO=0.
Вы вообще представляете как работает FC SAN и Multipathing на хостах? :)
За переключение путей отвечает хост (точнее multipating software). В случае пропадания СХД из SAN, multipathing мгновенно отрабатывает это событие (современные multipath решения умеют смотреть в SAN). Исключение составляют события, когда СХД остается в SAN фабрике, но по каким то причинам «не отвечает» на scsi команды, обычно такое может происходить из за высокой нагрузки на СХД или на SAN. В таком случае на хостах срабатывают таймауты. Никакой разницы при переключении путей между растянутой SAN и локальной — нет.
В статье описан тест, когда мы по питанию отключали одну из СХД. Никакого прерывания в вводе/выводе не происходило, ни на секунду. Multipathing мгновенно отрабатывал это событие и переключал активные пути на резервную СХД.
Oracle RAC по умолчанию имеет значение disktimeout = 200 секундам. Как с этим жить фанатам RTO= абсолютному 0?
Опять вас не понимаю. В случае выхода из строя одной из СХД, multipathing мгновенно отрабатывает (см. тесты в статье) и резервная СХД уже готова принять на себя ввод/вывод, никакие таймауты на хостах не срабатывают и не важно какие значения они имеют.
Да в один момент времени LUN доступен для записи только на одной площадке. Зато с точки зрения надежности позволяет избавиться от решения проблемы когерентности записи данных. Для приложений всё прозрачно
Если в NetApp MetroCluster нет необходимости смотреть за когерентностью кеша, то как же данные будут идеинтичны на обоих площадках? Или гарантирована потеря части данных, в случае если кто-нибудь в активный массив гвоздь забъёт?
Есть ли другие способы репликации?
Меня одного смущает, что хост подключается к схд по протоколу FC со скоростью 16 Гбит, а репликацию между контроллерами осуществляет через ethernet со скоростью 10 Гбит?
Чисто в теории, на удаленную площадку передаются только операции write. В нормальной режиме работы я сомневаюсь, что у вас процент записи по потоку превысит значение в 50% от общего потока ввода\вывода. Ну и All Flash СХД обычно используются как первичный сторадж под большую транзакционную нагрузку, т.е. в принципе сомнительно, что вы сможете при этом забить по потоку даже 10G интерфейс.
И предложенный способ репликации на самом деле самое лучшее, что может быть на рынке с текущим уровнем развития технологий (по крайней мере из того как описаны принципы работы у Pure), да еще и предлагается вендором "бесплатно". Какой еще более надежный способ репликации вы бы хотели увидеть? :)
Ну и не надо забывать что метро-кластер не равно резервное копирование.
Вы не ответили про другие более надежные способы репликации, которые вы хотели бы видеть или видели на СХД.
Про 40G и 100G согласен только отчасти. Тут еще вопрос в распространенности сетевого оборудования и готовности существующих каналов связи к таким подключениям.
Вы зря упираете на максимальную пропускную способность :). Для СХД важнее показатели по транзакционной нагрузке (IOPS) и времени отклика (ms). Но если уж вы хотите приравнять все к пропускной способности каналов, то попробуйте поделить например 2GB/s (гигабайта) на 8KB (килобайт). Получите вполне приличную цифру в IOPS, и это только для операций записи, которые нужно передавать на удаленный массив. Много вы видели даже средних инсталляций, где суммарная транзационная нагрузка c хостов превышает хотя бы 100к IOPS?
Так что на мой взгляд решение от Pure вполне претендует на свое место в сегменте компаний, которые доросли уже до двух площадок, но не доросли еще до дорогих энтерпрайзных решений.
Есть ли другие способы репликации?
Других способов репликации не заявлено.
Репликационный порт не один, их 4 штуки на массив, то есть 40Gb/s.
Интересно как реализовано подключение контроллеров массивов между площадками. Сама схема и логика работы (контроллер1 площадка1 в контроллер1 площадка2 или как?). Что произойдет например, если отваляться линки репликации только от одного контроллера одного массива? Оба массива будут лететь на одном крыле котроллере или это как-то по другому отрабатывается.
Т.е. в случае выхода из строя контроллера на первой площадке, данные записанные на второй площадке буду с обоих контроллеров "пихаться" в живой контроллер на первой. Все верно? Или все таки все POD переедут на один контроллер на второй площадке?
Куда будет писать данные живой контроллер на первой площадке? В один контроллер на второй? Вообще в нормально режиме как выбирается контроллер, которому передать данные на удаленной площадке?
Сборка метро кластера возможна, если заказчик не хочет давать массивам выход в интернет и нет возможности подключить облачный Cloud Mediator?
Как отработает кластер split-brain, если обе площадки работают, но пропала связь с Cloud Mediator и оборвались каналы репликации?
Т.е. в случае выхода из строя контроллера на первой площадке, данные записанные на второй площадке буду с обоих контроллеров «пихаться» в живой контроллер на первой. Все верно? Или все таки все POD переедут на один контроллер на второй площадке?
Куда будет писать данные живой контроллер на первой площадке? В один контроллер на второй? Вообще в нормально режиме как выбирается контроллер, которому передать данные на удаленной площадке?
К сожалению у меня нет ответа на данный вопрос. Это внутренние алгоритмы работы и они нигде не описаны.
Сборка метро кластера возможна, если заказчик не хочет давать массивам выход в интернет и нет возможности подключить облачный Cloud Mediator?
Возможна. Он может работать и без медиатора, только в таком случае возможна ситуация split-brain. Pure предоставляют возможность скачать медиатор в виде OVA образа и развернуть локально на площадке.
Как отработает кластер split-brain, если обе площадки работают, но пропала связь с Cloud Mediator и оборвались каналы репликации?
Если связь с медиатором и каналы репликации оборвались одновременно, то ввод/вывод будет заблокирован на обеих СХД. Только администратор сможет вручную выбрать, какая из СХД продолжит работать.
В случае если сначала оборвался канал репликации, то медиатор выберет, какая из СХД продолжит работать, а какая перейдет в состояние readonly. Затем, если оборвется связь до медиатора, уже ничего не произойдет и доступ к данным будет продолжен через одну из СХД.
Как я понимаю, у IBM это умеет только SVC и продукты на её (или его) основе. Их новомодные флеши A9000 и A9000R умеют какой-то hyper-swap, но то ли это?
Новые линейки IBM Storwize и Flashsystem по сути несут в себе весь функционал SVC. HyperSwap это feature этих СХД, которая по сути является аналогом ActiveCluster. Я немного почитал про HyperSwap и судя по документации там тоже поддерживается режим работы active/active, когда чтение/запись возможна на любую из СХД.
И я правильно понимаю, что репликация всегда синхронная, т.е. разнести датацентры далеко не получиться?
В крайнем случае вы конечно можете разместить медиатор на одной из площадок, где стоит СХД. Но тогда в случае обрыва репликационных каналов — выигрывать будет именна та СХД, которая стоит вместе с медиатором. А в случае падения всей площадки где стоит СХД+Медиатор, вторая СХД просто перейдет в режим ReadOnly.
В данной статье описана именно синхронная active/active репликация, Pure так же поддерживает и асинхронную репликацию.
А active/active при асинхронной будут работать? Как-то пугающе выглядит…
Active/active (не путать с двунаправленной асинхронной) и асинхронная репликация изначально вещи взаимоисключающие. При асинхронной репликации вторая площадка всегда passive и недоступна хостам при нормальном режиме работы (только если снапшот с нее делать и отдавать его хостам для бэкапа например). Да и просто банально вторая площадка всегда отстает от первичной площадки на некую дельту данных при асинхронной репликации.
Pure Storage ActiveCluster в связке с VMware: обзор и тестирование