На прошлой неделе объявлено о GA версии 8.3 Clustered Data ONTAP - внутри довольно много нововведений. Больше “совместимой” 7-mode версии нет - только clustered вариант. Но одним из ключевых изменений я вижу вот это:
"Starting with Data ONTAP 8.3, MetroCluster configurations are supported in clustered Data ONTAP."
Начиная с Data ONTAP 8.3 в clustered Data ONTAP поддерживаются конфигурации MetroCluster.
Важно отметить, что это не совсем тот, знакомый по 7й версии MetroCluster - это сильно переработанный механизм обеспечения отказоустойчивости в двухсайтовых конфигурациях.
Как только мы начинаем говорить про отказоустойчивость, сразу появляются два важных параметра:
- RPO, Recovery Point Objective - максимально допустимая потеря данных при сбое
- RTO, Recovery Time Objective - максимально допустимое время восстановления сервис СХД (обеспечение доступности данных для приложений)
Отказоустойчивость в системах с MetroCluster в Data ONTAP 8.3 базируется на двух столпах:
- NDO (NonDisruptive Operation) при большинстве локальных сбоев внутри датацентра (отдельные компоненты, узел кластера, сбои сети и т.п.). Кроме того, обеспечивается непрерывность обслуживания и во время проведения планового обслуживания системы.
- Непосредственно MetroCluster повышает доступность за счет наличия второго датацентра и зеркалирования данных на удаленную систему
Между узлами кластера обеспечивается автоматическое переключение в рамках одного датацентра и ручное переключение нагрузки при полном сбое в основном ЦОДе. При этом, заказчик получает нулевой RPO (данные не теряются) и RTO порядка 120 секунд для запланированных переключений между площадками и порядка несколько минут для “аварийных” переключений (администратору достаточно выполнить только одну команду).
Функционирование MetroCluster “прозрачно” для ОС и прикладных приложений, поэтому нет необходимости во внесении существенных изменений в имеющуюся инфраструктуру. Переход на резервную площадку не требует переподключения хостов к SAN или NFS ресурсам, так как все пути до СХД остаются неизменными. Только для SMB клиентам понадобится подключиться заново (в силу ограничений протокола).
MetroCluster интегрирован непосредственно в Data ONTAP и не требует никаких дополнительных лицензий - нужно только правильно спланировать архитектуру системы.
Больше нет разделения на Fabric MetroCluster (FMC) и strech MetroCluster (SMC) - есть только один MetroCluster, который может быть использован на расстояниях до 200км.
Как уже наверное стало понятно из вышесказанного, в новой версии мы больше не “растягиваем” одну пару контроллеров между площадками, а размещаем на каждой площадке по HA-паре. Несомненный плюс такого подхода - снимается одно из главных возражений против использования метрокластера, которое регулярно приходилось слышать. А что будет, если у нас выйдет из строя один контроллер? Раньше нас ждал переезд на вторую площадку (как правило, в ручном режиме) и, безусловно, такие мероприятия доставляют мало удовольствия. В то же время, исследования показывают, что незапланированные проблемы, приводящие к выходу из строя целой площадки составляют всего около 1% от всех возможных нештатных ситуаций. Чаще всего вообще причина остановки - плановое обслуживание. Прозрачное переключение между узлами в HA-паре позволяет практически полностью избавиться от такого рода проблем - теперь плановые работы можно проводить именно “по плану”.
Что же нужно, чтобы “построить” MetroCluser?
- Для связи между площадками используются FC линки, которых желательно иметь не менее четырех.
- Также потребуется установить на каждой площадке по 2 FC коммутатора
- Все контроллеры должны иметь доступ к дискам на всех площадках, поэтому дисковые полки нельзя подключить через SAS напрямую, а нужно использовать FC-SAS гейты (ATTO 6500N).
- Желательно на каждой площадке установить не менее 4 дисковых полок (минимум 2). Когда каждая полка содержит диски только одного пула, администрировать систему заметно проще - не нужно вручную назначать диски контроллерам, а значит и запутаться вероятность ниже.
- По FC-VI карте в каждый контроллер
- Все правильно подключить и настроить :)
После этого, каждый контроллер в двух HA-парах начнет синхронно зеркалировать все изменяющиеся данные (включая информацию о конфигурации) на вторую площадку. На самом деле, на каждой площадке может быть и больше двух контроллеров - у нас же clustered Data ONTAP!
Как видим, получается не такую уж и маленькую система. При этом, совсем младшие модели будут иметь много ограничений по доступным портам - часть слотов расширения займут FC-VI карты.
После того как все настроено, данные будут зеркалироваться между площадками. Операции чтения по-умолчанию происходят с “локальных” для контроллера дисков. Контроллер A1 будет всегда читать данные с дисков в "A1 Plex0". Однако, для некоторых типов нагрузки, с точки зрения производительности, может быть выгоднее включить чередование операций чтения с разных площадок (это можно настроить). А вот операции записи будут подтверждаться только после того, как второй контроллер в паре и парный контроллер на второй площадке отрапортуют о получении данных (в NVRAM).
Помимо данных, зеркалируется и содержимое NVRAM контроллеров. Поэтому каждый контроллер использует для “своих” нужд только четверть от общего объема NVRAM и реплицирует данные на два других контроллера (локального и удаленного партнера). В нормальном режиме функционирования в NVRAM каждого контроллера, помимо "своих" данных, есть еще и данные двух других контроллеров (в NVRAM контроллера A1 - данные из NVRAM контроллеров A2 и B1). Еще четверть резервируется на случай выхода из строя одного из контроллеров после сбоя на площадке, т.е. на случай, когда у нас останется в живых только один контроллер из четырех. И даже в этом случае система будет продолжать работать!
Конечно, думая о внедрении MetroCluster, мы должны помнить и об ограничениях:
- Нельзя защитить только часть данных - в MetroCluster должны дублироваться абсолютно все данные. На двух площадках всегда должно быть одинаковое количество дисковых ресурсов и нельзя создать агрегат без зеркалирования. Конечно можно на одной площадке использовать 60% доступных локальных дисковых ресурсов, а на второй 40%. Такая схема будет поддерживаться, но зеркалировать нужно все.
- Не поддерживаются Infinite Volumes.
- Не поддерживается Advanced Disk Partitioning.
- Не поддерживается NSE (NetApp Storage Encryption). Если требуется шифрование, можно использовать виртуализацию СХД и подключить сторонние системы, которые такой режим поддерживают.
- Действуют ограничения на количество SSD дисков в стеке полок (не более 48). Кроме того, рекомендуется не смешивать в одной полке SSD и обычные диски.
- Ограничение конкретной модели FAS на число дисков распространяется не на HA-пару, а на 4 контроллера (т.е. на две площадки), так что на каждой площадке может быть не более 50% от возможного числа дисков.
- Рекомендуется “ручное” переключение между площадками в случае сбоя
- Восстановление всегда "ручная” операция, требующая вмешательства администратора СХД
Еще несколько слов про переключение между площадками. Рекомендация делать переключения вручную неслучайна - вероятность выхода целой площадки из строя весьма мала, но последствия могут быть самыми разными, поэтому важно понимать что мы делаем и зачем. Кроме того, может быть ситуация, когда обе площадки живы, а вот канал связи между ними потерян - в таком случае, никакие переключения делать не стоит. Обычно в таких случаях используется третья площадка, которая “следит” за происходящим. В случае с MetroCluster есть т.н. tiebreaker software, который и выполняет эту роль. Да, с его помощью можно полностью автоматизировать переключение на резервную площадку при сбое, но, поверьте, это не самая лучшая идея. Поэтому лучше использовать этот софт только как средство дополнительного мониторинга.
Не могу сказать, что MetroCluster это универсальное и наилучшее решение для создания катастрофоустойчивых решений - такие решения строго индивидуальны и нет "серебряной пули", которая бы решала все проблемы. С одной стороны, весомым аргументом за метрокластер всегда была цена "входа" в решение - да, нужно было дублировать дисковые полки, но фактически было достаточно одной системы (всего пары контроллеров). Но, с другой стороны, именно эта особенность системы всегда вызывала больше всего нареканий. Сейчас мы, безусловно, получили "взрослое" решение, но не отпугнет ли заказчика итоговая цена? Думаю, что если и отпугнет, то далеко не всех - катастрофоустойчивые системы не бывают бесплатными и это, к счастью все понимают.
Почитать по теме:
Комментариев нет:
Отправить комментарий