Сегодня в блоге наш ИТ-эксперт, Хенрик Моцкус, представит ряд детальных обзоров основных функций Microsoft StorSimple. Мы остановимся на нескольких отдельных аспектах. Одним из наиболее важных является аварийное восстановление. После базовой установки Microsoft StorSimple необходимо выбрать настройки, соответствующие требованиям надежности. На примере файлового сервера Хенрик расскажет о технических тонкостях данного сценария.
StorSimple является гибридным решением компании Microsoft для хранения данных, разработанное для обеспечения простого, быстрого, экономически выгодного хранения данных из центра данных Microsoft Azure для локальных пользователей. Для ознакомления с основами и для приобретения базовых знаний о работе этого ПО, советуем прочитать статью «Microsoft Azure StorSimple: Простой вход в гибридное облако».
Как выглядит архитектура данного сценария? Файловый сервер работает на виртуальной машине (ВМ) с Windows Server 2012 R2. У него может быть конфигурация отказоустойчивого кластера. Для хранения данных сервер использует StorSimple в качестве общих томов кластера (ОТК), которые идут как тома iSCSI. StorSimple отражает тома в Azure (CloudSnapshots), после чего пользователи доменов получают к ним доступ. Эта архитектура обеспечивает отличную доступность. Все компоненты дублируются. Объем работы и эксплуатационные расходы ограничены до минимума.
Источник: Microsoft
Что мне нужно знать для создания соответствующей среды для аварийного восстановления Enterprise? В данном разделе описываются следующие отдельные компоненты, необходимые для настройки АВ:
В предыдущих статьях блога я описывал функции Microsoft StorSimple. В данном контексте следует также отметить Cloud Snapshots. Они используются для безопасного копирования целого набора данных, а также для зашифрованного копирования из томов iSCSI в хранилище больших двоичных объектов. Здесь и пригодится облачное устройство для Microsoft StorSimple. Облачное устройство Microsoft StorSimple – это виртуальное устройство, работающее на ВМ Microsoft Azure. Это облачное устройство обеспечивает те же функции в устройстве аппаратного обеспечения, и делает тома iSCSI доступными для серверов. Однако следующее условие является существенным: облачное устройство может обрабатывать не более 64 Тб данных. Поэтому если память устройства аппаратного обеспечения более 64 Тб, тома iSCI необходимо разделить между несколькими облачными устройствами. Такое ограничение установлено по причине того, что облачное устройство является стандартной ВМ в Azure. И, как мы знаем, ВМ поддерживает не более 64 жестких дисков с объемом памяти 1023 Гб каждый.
Теперь необходимо найти способ аутентифицировать пользователей. Ниже представлены следующие варианты, в зависимости от сложности среды:
Затем необходимо удостовериться, что файловые серверы, через которые пользователи получают доступ к общим ресурсам (через DFS, FailoverCluster и т. д.), также доступны во время аварии. В данном случае Microsoft Azure Site Recovery используется для дублирования соответствующих ВМ в центре обработки данных Azure в качестве точных копий вплоть до последнего бита. В следующей диаграмме отображены базовые принципы работы Microsoft Azure Site Recovery по определенному сценарию.
Как работает Microsoft Azure Site Recovery (источник: Microsoft)
Для этого необходим поставщик Azure Site Recovery, который будет отвечать за координирование операций на узле Hyper-V. Для связи с центром обработки данных Microsoft Azure он использует порт 443. Также нужен агент служб восстановления по каждой ВМ. При необходимости он запускает сценарии на текущих ВМ для осуществления соответствующих операций во время аварии.
Последнее, но не менее важное, предусматривается возможность автоматического выполнения процесса перехода на другой ресурс. Служба автоматизации Microsoft Azure как раз предназначена для этой цели. Пользователи могут настроить учетную запись службы автоматизации Azure или выбрать готовый перечень задач (runbook) из пула. После добавления runbook в личную учетную запись для запуска нескольких операций потребуется всего один клик.
Тестовый переход на другой ресурс никоим образом не влияет на серверы. ВМ просто загружаются в Azure, и тома сопоставляются с ВМ. Но перед этим тома StorSimple копируются и прикрепляются к виртуальному устройству, таким образом образуя идеальное игровое поле.
Планируемый переход на другой ресурс использует «дружественный подход» для прекращения работы ВМ в локальных центрах обработки данных для последующей ее загрузки в Azure. Для этого существующие Cloud Snapshot сопоставляются с виртуальным устройством. Вуаля!
Затем при незапланированном переходе на другой ресурс ВМ просто загружаются в Azure и осуществляют переход контейнера томов StorSimple на другой ресурс. После чего тома находятся в ВМ, и доступ файлового сервера к данным восстанавливается.
источник: Microsoft
В частности, готовый runbook делает весь процесс очень простым. Шаблонные сценарии уже написаны, в них могут вноситься изменения для соответствия отдельным сценариям.
Описанное здесь гибридное решение обещает обеспечивать превосходную доступность для предоставленных файловых сервисов, упрощенное администрирование и хороший потенциал для сокращения расходов. В конце концов, центр обработки данных Microsoft Azure используется в качестве места нахождения аварии. Кроме того, выделенное месторасположение осуществляемого перехода аппаратного и программного обеспечения, таким образом, уже устарело.
В будущем компания Microsoft сфокусируется на разработке решения для гибридного центра обработки данных. В Azure Site Recovery, Azure StorSimple или Azure Active Directory уже представлены готовые решения для идеальной связи между локальной инфраструктурой и Azure.
StorSimple является гибридным решением компании Microsoft для хранения данных, разработанное для обеспечения простого, быстрого, экономически выгодного хранения данных из центра данных Microsoft Azure для локальных пользователей. Для ознакомления с основами и для приобретения базовых знаний о работе этого ПО, советуем прочитать статью «Microsoft Azure StorSimple: Простой вход в гибридное облако».
1. Архитектура автоматического аварийного восстановления
Как выглядит архитектура данного сценария? Файловый сервер работает на виртуальной машине (ВМ) с Windows Server 2012 R2. У него может быть конфигурация отказоустойчивого кластера. Для хранения данных сервер использует StorSimple в качестве общих томов кластера (ОТК), которые идут как тома iSCSI. StorSimple отражает тома в Azure (CloudSnapshots), после чего пользователи доменов получают к ним доступ. Эта архитектура обеспечивает отличную доступность. Все компоненты дублируются. Объем работы и эксплуатационные расходы ограничены до минимума.
Источник: Microsoft
2. Что нужно для автоматического аварийного восстановления?
Что мне нужно знать для создания соответствующей среды для аварийного восстановления Enterprise? В данном разделе описываются следующие отдельные компоненты, необходимые для настройки АВ:
- облачное устройство для томов iSCSI в Microsoft Azure;
- ActiveDirectory в Azure или в локальной сети;
- хранилище Azure SiteRecovery;
- служба автоматизации Azure.
В предыдущих статьях блога я описывал функции Microsoft StorSimple. В данном контексте следует также отметить Cloud Snapshots. Они используются для безопасного копирования целого набора данных, а также для зашифрованного копирования из томов iSCSI в хранилище больших двоичных объектов. Здесь и пригодится облачное устройство для Microsoft StorSimple. Облачное устройство Microsoft StorSimple – это виртуальное устройство, работающее на ВМ Microsoft Azure. Это облачное устройство обеспечивает те же функции в устройстве аппаратного обеспечения, и делает тома iSCSI доступными для серверов. Однако следующее условие является существенным: облачное устройство может обрабатывать не более 64 Тб данных. Поэтому если память устройства аппаратного обеспечения более 64 Тб, тома iSCI необходимо разделить между несколькими облачными устройствами. Такое ограничение установлено по причине того, что облачное устройство является стандартной ВМ в Azure. И, как мы знаем, ВМ поддерживает не более 64 жестких дисков с объемом памяти 1023 Гб каждый.
3. Пошаговое руководство автоматического аварийного восстановления
Теперь необходимо найти способ аутентифицировать пользователей. Ниже представлены следующие варианты, в зависимости от сложности среды:
- Контроллер домена может использовать Azure Site Recovery для отображения целой ВМ для менее сложных сред, в которых работает только один контроллер домена и присутствует небольшое количество пользователей. В случае аварии отражение просто перезагружается. После чего все изменения в структуре Azure необходимо повторить в центре обработки данных компании. Я не являюсь сторонником данного метода, и в некоторых случаях он даже не будет работать.
- Рекомендуется настроить другой ЦОД в Azure для настройки крупных сред с большим количеством ЦОД, пользователей и большим коэффициентом изменений в АД. После чего данный ЦОД становится частью общей структуры, автоматически отображающий все изменения в структуре до Microsoft Azure, как части топологии репликации.
4. Microsoft Azure Site Recovery
Затем необходимо удостовериться, что файловые серверы, через которые пользователи получают доступ к общим ресурсам (через DFS, FailoverCluster и т. д.), также доступны во время аварии. В данном случае Microsoft Azure Site Recovery используется для дублирования соответствующих ВМ в центре обработки данных Azure в качестве точных копий вплоть до последнего бита. В следующей диаграмме отображены базовые принципы работы Microsoft Azure Site Recovery по определенному сценарию.
Как работает Microsoft Azure Site Recovery (источник: Microsoft)
Для этого необходим поставщик Azure Site Recovery, который будет отвечать за координирование операций на узле Hyper-V. Для связи с центром обработки данных Microsoft Azure он использует порт 443. Также нужен агент служб восстановления по каждой ВМ. При необходимости он запускает сценарии на текущих ВМ для осуществления соответствующих операций во время аварии.
5. Служба автоматизации Microsoft Azure
Последнее, но не менее важное, предусматривается возможность автоматического выполнения процесса перехода на другой ресурс. Служба автоматизации Microsoft Azure как раз предназначена для этой цели. Пользователи могут настроить учетную запись службы автоматизации Azure или выбрать готовый перечень задач (runbook) из пула. После добавления runbook в личную учетную запись для запуска нескольких операций потребуется всего один клик.
Тестовый переход на другой ресурс никоим образом не влияет на серверы. ВМ просто загружаются в Azure, и тома сопоставляются с ВМ. Но перед этим тома StorSimple копируются и прикрепляются к виртуальному устройству, таким образом образуя идеальное игровое поле.
Планируемый переход на другой ресурс использует «дружественный подход» для прекращения работы ВМ в локальных центрах обработки данных для последующей ее загрузки в Azure. Для этого существующие Cloud Snapshot сопоставляются с виртуальным устройством. Вуаля!
Затем при незапланированном переходе на другой ресурс ВМ просто загружаются в Azure и осуществляют переход контейнера томов StorSimple на другой ресурс. После чего тома находятся в ВМ, и доступ файлового сервера к данным восстанавливается.
источник: Microsoft
В частности, готовый runbook делает весь процесс очень простым. Шаблонные сценарии уже написаны, в них могут вноситься изменения для соответствия отдельным сценариям.
6. Выводы и перспективы
Описанное здесь гибридное решение обещает обеспечивать превосходную доступность для предоставленных файловых сервисов, упрощенное администрирование и хороший потенциал для сокращения расходов. В конце концов, центр обработки данных Microsoft Azure используется в качестве места нахождения аварии. Кроме того, выделенное месторасположение осуществляемого перехода аппаратного и программного обеспечения, таким образом, уже устарело.
В будущем компания Microsoft сфокусируется на разработке решения для гибридного центра обработки данных. В Azure Site Recovery, Azure StorSimple или Azure Active Directory уже представлены готовые решения для идеальной связи между локальной инфраструктурой и Azure.
