Рекомендации по аварийному восстановлению с Синхронизация файлов Azure

Для службы "Синхронизация файлов Azure" существует три ключевых аспекта, которые следует учитывать при аварийном восстановлении: высокая доступность, защита (резервное копирование) и избыточность данных. В этой статье рассматриваются все аспекты и описывается, как выбрать конфигурацию, которая будет использоваться в качестве решения для аварийного восстановления.

В развернутой службе "Синхронизация файлов Azure" в облачной конечной точке всегда содержится полная копия ваших данных, а локальный сервер можно просматривать в виде высвобождаемого кэша данных. В случае аварии на стороне сервера можно выполнить восстановление, подготовив к работе новый сервер, установив на нем агент службы "Синхронизация файлов Azure" и настроив его в качестве новой конечной точки.

Из-за своего гибридного характера некоторые традиционные стратегии резервного копирования и аварийного восстановления сервера не будут эффективны для службы "Синхронизация файлов Azure". Для любых зарегистрированных серверов служба "Синхронизация файлов Azure" не поддерживает:

• Перенос и клонирование дисков (том) с одного сервера на другой, пока конечная точка сервера по-прежнему активна
• Восстановление из резервной копии операционной системы
• Клонирование операционной системы сервера на другой сервер
• Возврат к предыдущей контрольной точке виртуальной машины
• Восстановление многоуровневых файлов из локальной (сторонней) резервной копии на конечную точку сервера

Высокая доступность

Существует две разные стратегии, которые можно использовать для обеспечения высокой доступности локального сервера. Можно настроить отказоустойчивый кластер или настроить резервный сервер. Решающий фактор между любой конфигурацией заключается в том, сколько вы готовы инвестировать в систему, и если минимизация длительности времени, когда ваша система будет снижена в случае аварии, стоит, что дополнительная стоимость.

Чтобы использовать службу "Синхронизация файлов Azure" на отказоустойчивом кластере, не нужно предпринимать никаких специальных шагов. На резервном сервере необходимо выполнить следующие настройки:

Укажите сервер-получатель с разными конечными точками сервера, которые синхронизируются с той же группой синхронизации, что и основной сервер, но не разрешайте пользователю доступ к серверу. При этом все файлы на главном сервере синхронизируются с резервным сервером. Можно рассмотреть возможность перемещения только на уровень пространства имен, чтобы изначально загружалось только это пространство. Для быстрой перенастройки доступа конечных пользователей к резервному серверу в случае сбоя на главном, можно использовать пространство имен DFS-N.

Защита / резервное копирование данных

Защита данных является ключевым компонентом решения аварийного восстановления. Это можно сделать двумя основными способами с общими папками Azure: вы можете создать резервную копию данных в облаке или локальной среде. Настоятельно рекомендуем создать резервную копию данных в облаке, так как конечная точка облака будет содержать полную копию данных, а конечные точки сервера могут содержать только подмножество данных.

Резервное копирование данных в облаке

Используйте в качестве решения для облачного резервного копирования службу Azure Backup. Среди прочего служба Azure Backup обеспечивает планирование резервного копирования, хранение и восстановление резервных копий. Если вы предпочитаете, вы можете вручную создать моментальные снимки общего ресурса и настроить собственное решение по планированию и хранению, но это не идеально. В качестве альтернативы можно напрямую создать резервную копию общих папок Azure с помощью сторонних решений.

В случае аварии можно восстановить данные с помощью моментального снимка общей папки, который представляет собой копию общей папки на определенный момент времени, доступную только для чтения. Так как эти моментальные снимки доступны только для чтения, они не будут затронуты программ-шантажистов. Для больших наборов данных, в которых операции полного восстановления общего ресурса занимают много времени, можно включить прямой доступ пользователей к моментальному снимку, чтобы пользователи могли скопировать данные, необходимые для локального диска, пока восстановление завершится.

Моментальные снимки хранятся непосредственно в общей папке Azure, независимо от того, принимаете ли их вручную или если Azure Backup принимает их для вас. Поэтому необходимо включить обратимое удаление , чтобы защитить моментальные снимки от случайного удаления общей папки.

Дополнительные сведения см. в статье О резервном копировании общей папки Azure или обратитесь к поставщику услуг по резервированию, чтобы узнать, поддерживают ли они резервное копирование общих папок Azure.

Создание резервной копии данных в локальной среде

Если вы включили распределение по уровням в облаке, не используйте решения для локального резервного копирования. С включенным распределением по уровням в облаке на сервере будут храниться только подмножество данных, а остальные данные хранятся в облачной конечной точке. В зависимости от того, какое решение резервного копирования используется для локальной резервной копии, многоуровневые файлы будут иметь следующие значения:

• пропущено и не резервное копирование (из-за их FILE_ATTRIBUTE_RECALL_ONDATA_ACCESS атрибута) или
• Резервное копирование только в виде многоуровневого файла и может быть недоступно при восстановлении из-за изменений в динамической общей папке или
• отзыв на ваш диск, что приведет к высоким затратам на исходящий трафик.

Если вы решите использовать локальное решение для резервного копирования, необходимо выполнить резервное копирование на сервере в группе синхронизации с отключенным распределением по уровням в облаке. При восстановлении используйте параметры восстановления на уровне тома или файла. Файлы, восстановленные с помощью параметра восстановления на уровне файлов, синхронизируются со всеми конечными точками в группе синхронизации, а существующие файлы будут заменены версией, восстановленной из резервной копии. При восстановлении на уровне тома более новые версии файлов в облачной конечной точке или других серверных конечных точках не будут заменены.

Моментальные снимки службы теневого копирования томов (VSS) (в том числе на вкладке Предыдущие версии) поддерживаются для тех томов, где включено распределение по уровням в облаке. Это позволяет выполнять автоматическое резервное копирование и самостоятельное восстановление, не обращаясь к администратору. Однако вы должны включить в PowerShell совместимость с предыдущими версиями, что увеличит затраты на хранение моментального снимка. Моментальные снимки с помощью службы теневого копирования томов (VSS) не защищают от сбоев в самой серверной конечной точке, поэтому их следует использовать только в сочетании с облачным резервным копированием. Подробнее см. Автоматическое резервное копирование и самостоятельное восстановление с помощью предыдущих версий и службы теневого копирования томов (VSS).

Избыточность данных

Для надежной работы решения для аварийного восстановления дополните инфраструктуру каким-либо средством для обеспечения избыточности данных. Существует четыре предложения избыточности для Файлы Azure: локально избыточное хранилище (LRS), хранилище, избыточное между зонами (ZRS), геоизбыточное хранилище (GRS) и геоизбыточное хранилище (GZRS).

• Локально избыточное хранилище (LRS). При использовании LRS в кластере хранилища Azure сохраняются три копии каждого файла. Помогает защитить данные от потери при аппаратных сбоях, например в случае повреждения диска. Однако в случае аварии в центре обработки данных, например пожара или наводнения, все реплики учетной записи хранения, использующие LRS, могут быть утрачены или оказаться непригодными для восстановления.
• Хранилище, избыточное между зонами (ZRS). При использовании ZRS, хранятся три копии каждого файла, но они физически изолируются в трех отдельных кластерах хранилища в разных зонах доступности Azure. Зоны доступности — уникальные физические расположения в пределах одного региона Azure. Каждая зона состоит из одного или нескольких центров обработки данных, обеспеченных независимыми системами электропитания, охлаждения и сетями. Запись в хранилище не принимается, пока она не будет записана в кластеры хранения во всех трех зонах доступности.
• Геоизбыточное хранилище (GRS):с GRS у вас есть два региона: основной и вторичный регион. В кластере хранилища Azure в основном регионе хранятся три копии каждого файла. Операции записи асинхронно реплицируются в определенный корпорацией Майкрософт дополнительный регион. GRS предоставляет шесть копий данных, распределенных между двумя регионами Azure.
• Геоизбыточное хранилище (GZRS): думайте о GZRS как ZRS, но с геоизбыточностью. В GZRS три копии каждого файла хранятся в трех отдельных кластерах хранилища в основном регионе. Все операции записи затем асинхронно реплицируются в определенный корпорацией Майкрософт дополнительный регион.

Надежным решением для аварийного восстановления большинству клиентов следует считать ZRS. Хранилище, избыточное между зонами (ZRS) отличается наименьшими дополнительными затратами, если сравнивать их с дополнительными преимуществами в избыточности данных, и является наиболее надежным в случае сбоя. Если согласно политике вашей организации или нормативным требованиям необходимо обеспечить геоизбыточность данных, выбирайте GRS или GZRS.

Геоизбыточность

Если учетная запись хранения настроена для использования репликации GRS или GZRS, а основной регион сочтут полностью не подлежащим восстановлению или недоступным в течение длительного времени, корпорация Майкрософт инициирует отработку отказа для службы синхронизации хранилища. Никаких действий от вас не требуется в случае аварии.

Хотя вы можете вручную запросить отработку отказа службы синхронизации хранилища в парном регионе GRS или GZRS, мы не рекомендуем выполнять это за пределами крупномасштабных региональных сбоев, так как процесс не является простым и может привести к дополнительным затратам. Чтобы начать процесс, отправьте запрос в службу поддержки и запросите отработку отказа для учетных записей службы хранилища Azure, в которых содержится ваша общая папка Azure, и для службы синхронизации хранилища.

После отработки отказа серверные конечные точки сервера автоматически переключатся на синхронизацию с облачной конечной точкой в дополнительном регионе. Однако серверные конечные точки должны согласовываться с облачными конечными точками. Это может привести к конфликтам файлов, так как данные в дополнительном регионе могут не быть пойманы до основного.

Следующий шаг

Сведения о резервном копировании общих папок Azure