NetApp ONTAP: SnapMirror for SVM
Начиная с версии 8.3.1 в Data ONTAP был презентован новый функционал под названием SnapMirror for SVM. SnapMirror for SVM это возможность отреплицировать все данные на СХД и все настройки или только часть данных или настроек на запасную площадку.
SVM это что-то на подобии виртуальных машин на серверах, но предназначены для СХД. Пускай эта аналогия не введет вас в заблуждение, на СХД не получится запускать ваши виртуальные машины с Windows, Linux и так далее. SVM это виртуальная машина (очень часто одна единственная, но при желании можно развернуть много) в кластере СХД. Кластер СХД с софтом (прошивкой) ONTAP может состоять из одной или более нод, на данный момент максимум 24 ноды в кластере. Каждая SVM «логически» это одна сущность, видна администратору как одно целое. SVM живёт сразу на всём кластере, но физически, на самом деле, «под капотом» СХД, это набор виртуальных машин, по одной машине на каждой ноде всего кластера, которые объединены специальным образом и представляются администратору как как единая точка управления.
Смысл SVM в кластере ONTAP, с одной стороны, в том, что для администратора СХД он видит кластер, как одну сущность, управляет её ресурсами из одной консоли, при необходимости мигрирует объекты кластера (вольюмы, луны, сетевые адреса), по нодам кластера без какой-либо специальной настройки кластера, SVM берет всю заботу по миграции на себя.
С другой стороны смысл SVM также в том, чтобы красиво, изощренным способом обманывать хосты, чтобы 2, 4,8, или даже 24 ноды кластера были видны для конечного хоста, как единое устройство, а при миграция данных из одной ноды на другую, для хостов происходила прозрачно.
Все эти возможности SVM в кластере называют «Single Namespace».
С сохранением сетевых настроек и адресов, может использоваться в двух режимах: когда имеется растянутый L2 домен между площадками и когда между сайтами есть L3 связность (маршрутизация). В режиме Identity Preserve можно также не реплицировать настройки сетевых IP адресов, тогда их нужно будет настраивать вручную после переключения на резервную площадку.
L2 домен для NAS
L2 домен между площадками требует соответствующего сетевого оборудования и каналов. Представьте себе две площадки с двумя СХД которые реплицируют данные с одной на другую, в случае аварии администратор выполняет переключение на резервный сайт и на второй СХД возникают теже самые сетевые IP адреса, что и были на основной площадке, и вообще всё, что было настроено на первой СХД тоже переезжает. В свою очередь когда переехавшие сервера (со старыми настройками подключения к СХД) использующие ранее основную СХД, поднимаются на запасной площадке, они видят те же адреса, куда они подключались ранее, но по-факту это резервная площадка, а они об этом просто не знают и подключаются ко второй СХД, как будто к основной, что очень ускоряет процесс переключения на резервную площадку. Требуемое оборудование и каналы могут себе позволить крупные компании, с другой стороны этот режим существенно ускоряет переключение на резервную площадку.L3 домен для NAS
Так как при отсутствии растянутой L2 сети между основной и резервной площадками, понадобится наличие двух разных IP подсетей и маршрутизации. Если бы данные были доступны по старым адресам, на DR площадке, то приложения не смогли бы к ним получить доступ, ведь на резервной площадке другие подсети. В этом случае также приходит на помощь функция Identity Preserve с сохранением сетевых адресов — ведь вы можете заранее указать новые сетевые IP адреса для DR площадки (которые поднимутся на DR площадке в момент переключения на вторичную СХД), по которым будут доступны данные на резервной СХД. Если просто мигрировать хосты, то их сетевые адреса тоже потребуется перенастроить: вручную или при помощи скриптов на резервной площадке, чтобы они увидели свои данные, со своих новых IP адресов подключаясь, опять таки, на новые IP адреса СХД. Этот режим работы будет больше интересен не большим компаниям, которые могут себе позволить более длительное время переключения в случае катастрофы или аварии при этом, не тратясь на дорогостоящее оборудование и каналы.
Иногда есть необходимость полностью отказаться от старых настроек, при переключении на резервную площадку, к примеру отказаться от настроек NFS экспорта, настроек CIFS сервера, DNS и т.д. Также бывает необходимо обеспечить возможность чтения данных на удаленной площадке или когда есть необходимость реплицировать луны для SAN окружения. Во всех таких ситуациях приходит на помощь функция Identity Discard (Identity Preserve = False).
Как и в случае с Identity Preserve L3 конфигурацией, на удалённом сайте, после переключения необходимо будет перенастроить сетевые IP или FC адреса (и другие настройки, которые небыли были реплицированны, согласно режима Identity Discard), по которым будут доступны старые данные на вторичной СХД. Если просто мигрировать хосты, то их сетевые адреса тоже потребуется перенастроить: вручную или при помощи скриптов на резервной площадке, чтобы они увидели свои данные. Этот режим работы будет больше интересен для заказчиков которым необходимо иметь возможность реплицировать LUN’ы для SAN инфраструктуры или для тех кто хочет выполнять чтение данных на резервной площадке (к примеру каталогизация). Также этот режим будет интересен для проверки резервной копии на возможность к ней восстановится, а также для разнообразных тестироващиков и разработчиков.
Clustered Data ONTAP SnapMirror Toolkit — это бесплатный набор Perl скриптов, которые позволят ускорить и наладить процесс автоматизации проверки, подготовки, настройки, инициализации, обновления, переключения на резервную площадку и обратно репликации SnapMirror.
Скачать SnapMirror Toolkit.
Для Windows машин доступен NetApp PowerShell Toolkit, который позволит создавать скрипты управления NetApp.
Workflow Automation — это бесплатная графическая утилита позволяющая создавать наборы или связки задач, для автоматизации процессов управления ONTAP. К примеру через неё можно настроить создание новых разрешений для файловых шар или iGroup, добавить в неё отреплицированные вольюмы и новых хостов-инициаторов с DR площадки, поднять новые LIF интерфейсы и многое другое (создать Broadcast Domain, создать Failover Groups, Firewall Policies, Routes, DNS, и т.д.). Всё это можно автоматизировать так, чтобы это было выполнено сразуже, после выполнения разрыва репликации, практически по одному клику мыши. Workflow Automation будет более полезен для режимов Identity Preserve L3 и Identity Discard, так как в этих режимах после переключения на резервную площадку необходимо будет выполнить дополнительную настройку СХД и серверов. Также Workflow Automation будет крайне полезен для тестировщиков и разработчиков, которые могут клонировать огромные наборы данных средствами СХД за секунды и автоматизировать их подготовку для своей работы.
Репликация данных может быть выполнена как на физическую FAS платформу, так и на их виртуальных братьев: Data ONTAP Edge, ONTAP Select или Cloud ONTAP в публичное облако. Последний вариант получил название Snap-to-Cloud. Если быть более точным то Snap-to-Cloud это набор (бандл) определенных моделей FAS платформ + Cloud ONTAP с установленными лицензиями репликации для бэкапа в облако.
Чтобы обеспечить 0 время переключения, понадобится ещё большие затраты на каналы, ещё больше и ещё дороже сетевое оборудование. По-этому часто более целесообразно использовать DR, а не HA. В случае DR простой при переключении на резервную площадку неизбежен, RPO и RTO может быть достаточно небольшим, но он не равняются 0, как в случае с HA.
Чтобы исключить вольюм/лун из DR реплики всего SVM, необходимо на источнике выполнить:
Использование запасной площадки как среды разработки при помощи тонкого клонирования (Data Protection вольюма) снижает нагрузку на основную СХД, при этом тестировщики и разработчики могут иметь более новую информацию (по сравнению с традиционным подходом FullBackup из-за того что снепы снимаются и реплицируются намного быстрее и как правило из-за этого чаще) для своей работы, отреплицированную из основной СХД. Для тонкого клонирования понадобится лицензия FlexClone на соответствующей площадке.
Cнепшоты NetApp вообще никак не виляют на производительность всей системы так устроено архитектурно. Благодаря чему снепшоты удобно использовать для репликации — передавать только изменения. Это более эффективно по сравнению с Full Backup/Restore так как при операциях резервного копирования читаются/пишутся только эти изменения, а не каждый раз всё по-новой. Использовать аппаратную репликацию средствами СХД более эффективно ещё и потому, что CPU хоста и его сетевые порты не задействуются во время бекапа. Это позволяет более часто выполнять резервное копирование, а возможность моментально снимать снепшоты позволит снимать их прямо посреди рабочего дня.
Хочу отметить, что репликация на основе нетаповских снепшотов, пускай и на много меньше, чем традиционая схема бекапирования или традиционных CoW снепшотов, грузит СХД, но всё-равно репликация её дополнительно грузит. Во-первых для репликации порождаются дополнительные операции чтения собственно новых изменений, генерируя дополнительную задачи чтения с дисковой подсистемы. Во-вторых операции чтения проходят через CPU СХД. Магии не происходит: мы можем существенно снизить и оптимизировать нагрузку от процесса резервного копирования, но нельзя его полностью нивилировать.
Технология SnapMirror тонко реплицирует и восстанавливает данные, используя снепшоты. Это позволяет уменьшить нагрузку на сеть и дисковую подсистему по сравнению с Full Backup/Restore и выполнять реплики даже посреди рабочего дня, благодаря чему увеличить число резервных копий и таким образом существнно уменьшить окно резервного окпирования. Функционал SnapMirror for SVM обеспечивает удобный способ создания DR схемы восстановления всей СХД. Кроме DR второй сайт может быть использован для Test/Dev, снимая эти задачи с основной СХД.
Чтобы мочь запустить все ваши сервисы на резервной системе, логично чтобы основная и запасная системы были более-менее одинаковые по производительности. Если же на резервной площадке система стоит слабее, стоит заранее задаться вопросом, какие самые критичные сервисы необходимо будет запустить, а какие будут не запущены. Можно реплицировать как весь SVM со всеми его вольюмами, так и исключить из реплики часть вольюмов и сетевых интерфейсов (начиная с ONTAP 9).
Существует два режима работы SnapMirror for SVM: Identity Preserve и Identity Discard.
Что такое NetApp SVM?
SVM это что-то на подобии виртуальных машин на серверах, но предназначены для СХД. Пускай эта аналогия не введет вас в заблуждение, на СХД не получится запускать ваши виртуальные машины с Windows, Linux и так далее. SVM это виртуальная машина (очень часто одна единственная, но при желании можно развернуть много) в кластере СХД. Кластер СХД с софтом (прошивкой) ONTAP может состоять из одной или более нод, на данный момент максимум 24 ноды в кластере. Каждая SVM «логически» это одна сущность, видна администратору как одно целое. SVM живёт сразу на всём кластере, но физически, на самом деле, «под капотом» СХД, это набор виртуальных машин, по одной машине на каждой ноде всего кластера, которые объединены специальным образом и представляются администратору как как единая точка управления.
Смысл SVM в кластере ONTAP, с одной стороны, в том, что для администратора СХД он видит кластер, как одну сущность, управляет её ресурсами из одной консоли, при необходимости мигрирует объекты кластера (вольюмы, луны, сетевые адреса), по нодам кластера без какой-либо специальной настройки кластера, SVM берет всю заботу по миграции на себя.
С другой стороны смысл SVM также в том, чтобы красиво, изощренным способом обманывать хосты, чтобы 2, 4,8, или даже 24 ноды кластера были видны для конечного хоста, как единое устройство, а при миграция данных из одной ноды на другую, для хостов происходила прозрачно.
Все эти возможности SVM в кластере называют «Single Namespace».
Identity Preserve для NAS
С сохранением сетевых настроек и адресов, может использоваться в двух режимах: когда имеется растянутый L2 домен между площадками и когда между сайтами есть L3 связность (маршрутизация). В режиме Identity Preserve можно также не реплицировать настройки сетевых IP адресов, тогда их нужно будет настраивать вручную после переключения на резервную площадку.
L2 домен для NASL2 домен между площадками требует соответствующего сетевого оборудования и каналов. Представьте себе две площадки с двумя СХД которые реплицируют данные с одной на другую, в случае аварии администратор выполняет переключение на резервный сайт и на второй СХД возникают теже самые сетевые IP адреса, что и были на основной площадке, и вообще всё, что было настроено на первой СХД тоже переезжает. В свою очередь когда переехавшие сервера (со старыми настройками подключения к СХД) использующие ранее основную СХД, поднимаются на запасной площадке, они видят те же адреса, куда они подключались ранее, но по-факту это резервная площадка, а они об этом просто не знают и подключаются ко второй СХД, как будто к основной, что очень ускоряет процесс переключения на резервную площадку. Требуемое оборудование и каналы могут себе позволить крупные компании, с другой стороны этот режим существенно ускоряет переключение на резервную площадку.L3 домен для NAS
Так как при отсутствии растянутой L2 сети между основной и резервной площадками, понадобится наличие двух разных IP подсетей и маршрутизации. Если бы данные были доступны по старым адресам, на DR площадке, то приложения не смогли бы к ним получить доступ, ведь на резервной площадке другие подсети. В этом случае также приходит на помощь функция Identity Preserve с сохранением сетевых адресов — ведь вы можете заранее указать новые сетевые IP адреса для DR площадки (которые поднимутся на DR площадке в момент переключения на вторичную СХД), по которым будут доступны данные на резервной СХД. Если просто мигрировать хосты, то их сетевые адреса тоже потребуется перенастроить: вручную или при помощи скриптов на резервной площадке, чтобы они увидели свои данные, со своих новых IP адресов подключаясь, опять таки, на новые IP адреса СХД. Этот режим работы будет больше интересен не большим компаниям, которые могут себе позволить более длительное время переключения в случае катастрофы или аварии при этом, не тратясь на дорогостоящее оборудование и каналы.
Identity Discard для SAN или NAS
Иногда есть необходимость полностью отказаться от старых настроек, при переключении на резервную площадку, к примеру отказаться от настроек NFS экспорта, настроек CIFS сервера, DNS и т.д. Также бывает необходимо обеспечить возможность чтения данных на удаленной площадке или когда есть необходимость реплицировать луны для SAN окружения. Во всех таких ситуациях приходит на помощь функция Identity Discard (Identity Preserve = False).
Как и в случае с Identity Preserve L3 конфигурацией, на удалённом сайте, после переключения необходимо будет перенастроить сетевые IP или FC адреса (и другие настройки, которые небыли были реплицированны, согласно режима Identity Discard), по которым будут доступны старые данные на вторичной СХД. Если просто мигрировать хосты, то их сетевые адреса тоже потребуется перенастроить: вручную или при помощи скриптов на резервной площадке, чтобы они увидели свои данные. Этот режим работы будет больше интересен для заказчиков которым необходимо иметь возможность реплицировать LUN’ы для SAN инфраструктуры или для тех кто хочет выполнять чтение данных на резервной площадке (к примеру каталогизация). Также этот режим будет интересен для проверки резервной копии на возможность к ней восстановится, а также для разнообразных тестироващиков и разработчиков.
SnapMirror Toolkit
Clustered Data ONTAP SnapMirror Toolkit — это бесплатный набор Perl скриптов, которые позволят ускорить и наладить процесс автоматизации проверки, подготовки, настройки, инициализации, обновления, переключения на резервную площадку и обратно репликации SnapMirror.
Скачать SnapMirror Toolkit.
NetApp-PowerShell Commandlets
Для Windows машин доступен NetApp PowerShell Toolkit, который позволит создавать скрипты управления NetApp.
Workflow Automation
Workflow Automation — это бесплатная графическая утилита позволяющая создавать наборы или связки задач, для автоматизации процессов управления ONTAP. К примеру через неё можно настроить создание новых разрешений для файловых шар или iGroup, добавить в неё отреплицированные вольюмы и новых хостов-инициаторов с DR площадки, поднять новые LIF интерфейсы и многое другое (создать Broadcast Domain, создать Failover Groups, Firewall Policies, Routes, DNS, и т.д.). Всё это можно автоматизировать так, чтобы это было выполнено сразуже, после выполнения разрыва репликации, практически по одному клику мыши. Workflow Automation будет более полезен для режимов Identity Preserve L3 и Identity Discard, так как в этих режимах после переключения на резервную площадку необходимо будет выполнить дополнительную настройку СХД и серверов. Также Workflow Automation будет крайне полезен для тестировщиков и разработчиков, которые могут клонировать огромные наборы данных средствами СХД за секунды и автоматизировать их подготовку для своей работы.
Snap-to-Cloud
Репликация данных может быть выполнена как на физическую FAS платформу, так и на их виртуальных братьев: Data ONTAP Edge, ONTAP Select или Cloud ONTAP в публичное облако. Последний вариант получил название Snap-to-Cloud. Если быть более точным то Snap-to-Cloud это набор (бандл) определенных моделей FAS платформ + Cloud ONTAP с установленными лицензиями репликации для бэкапа в облако.
Disaster Recovery не High Avalability
Чтобы обеспечить 0 время переключения, понадобится ещё большие затраты на каналы, ещё больше и ещё дороже сетевое оборудование. По-этому часто более целесообразно использовать DR, а не HA. В случае DR простой при переключении на резервную площадку неизбежен, RPO и RTO может быть достаточно небольшим, но он не равняются 0, как в случае с HA.
Исключение вольюма из DR реплики
Чтобы исключить вольюм/лун из DR реплики всего SVM, необходимо на источнике выполнить:
source_cluster::> volume modify -vserver vs1 -volume test_vol1 -vserver-dr-protection unprotected
Вторым применением SnapMirror может служить Test/Dev
Использование запасной площадки как среды разработки при помощи тонкого клонирования (Data Protection вольюма) снижает нагрузку на основную СХД, при этом тестировщики и разработчики могут иметь более новую информацию (по сравнению с традиционным подходом FullBackup из-за того что снепы снимаются и реплицируются намного быстрее и как правило из-за этого чаще) для своей работы, отреплицированную из основной СХД. Для тонкого клонирования понадобится лицензия FlexClone на соответствующей площадке.
Традиционный бекап vs Snap*
Cнепшоты NetApp вообще никак не виляют на производительность всей системы так устроено архитектурно. Благодаря чему снепшоты удобно использовать для репликации — передавать только изменения. Это более эффективно по сравнению с Full Backup/Restore так как при операциях резервного копирования читаются/пишутся только эти изменения, а не каждый раз всё по-новой. Использовать аппаратную репликацию средствами СХД более эффективно ещё и потому, что CPU хоста и его сетевые порты не задействуются во время бекапа. Это позволяет более часто выполнять резервное копирование, а возможность моментально снимать снепшоты позволит снимать их прямо посреди рабочего дня.
Хочу отметить, что репликация на основе нетаповских снепшотов, пускай и на много меньше, чем традиционая схема бекапирования или традиционных CoW снепшотов, грузит СХД, но всё-равно репликация её дополнительно грузит. Во-первых для репликации порождаются дополнительные операции чтения собственно новых изменений, генерируя дополнительную задачи чтения с дисковой подсистемы. Во-вторых операции чтения проходят через CPU СХД. Магии не происходит: мы можем существенно снизить и оптимизировать нагрузку от процесса резервного копирования, но нельзя его полностью нивилировать.
Выводы
Технология SnapMirror тонко реплицирует и восстанавливает данные, используя снепшоты. Это позволяет уменьшить нагрузку на сеть и дисковую подсистему по сравнению с Full Backup/Restore и выполнять реплики даже посреди рабочего дня, благодаря чему увеличить число резервных копий и таким образом существнно уменьшить окно резервного окпирования. Функционал SnapMirror for SVM обеспечивает удобный способ создания DR схемы восстановления всей СХД. Кроме DR второй сайт может быть использован для Test/Dev, снимая эти задачи с основной СХД.
Здесь могут содержаться ссылки на Habra-статьи, которые будут опубликованы позже.
Сообщения по ошибкам в тексте прошу направлять в ЛС.
Замечания, дополнения и вопросы по статье напротив, прошу в комментарии.
