Рекомендации по аварийному восстановлению с помощью службы "Синхронизация файлов Azure"
Для службы "Синхронизация файлов Azure" существует три ключевых аспекта, которые следует учитывать при аварийном восстановлении: высокая доступность, защита (резервное копирование) и избыточность данных. В этой статье рассматриваются все аспекты и описывается, как выбрать конфигурацию, которая будет использоваться в качестве решения для аварийного восстановления.
В развернутой службе "Синхронизация файлов Azure" в облачной конечной точке всегда содержится полная копия ваших данных, а локальный сервер можно просматривать в виде высвобождаемого кэша данных. В случае аварии на стороне сервера можно выполнить восстановление, подготовив к работе новый сервер, установив на нем агент службы "Синхронизация файлов Azure" и настроив его в качестве новой конечной точки.
Из-за своего гибридного характера некоторые традиционные стратегии резервного копирования и аварийного восстановления сервера не будут эффективны для службы "Синхронизация файлов Azure". Для любых зарегистрированных серверов служба "Синхронизация файлов Azure" не поддерживает:
Предупреждение
Выполнение любого из этих действий может привести к проблемам с синхронизацией или повреждению многоуровневых файлов и в конечном счете к потере данных. Если вы выполнили одно из этих действий, обратитесь к поддержка Azure, чтобы убедиться, что развертывание работоспособно.
- Передача и клонирование дисков (томов) с одного сервера на другой, пока конечная точка сервера по-прежнему активна
- Восстановление из резервной копии операционной системы
- Клонирование операционной системы сервера на другой сервер
- Возврат к предыдущей контрольной точке виртуальной машины
- Восстановление многоуровневых файлов из локальной (сторонней) резервной копии в конечную точку сервера
Высокий уровень доступности
Существует две различные стратегии, которые можно использовать для обеспечения высокого уровня доступности локального сервера. Можно настроить отказоустойчивый кластер или резервный сервер. Решающим фактором между любой конфигурацией является то, сколько вы готовы инвестировать в систему, и стоит ли свести к минимуму продолжительность времени работы системы в случае аварии.
Чтобы использовать службу "Синхронизация файлов Azure" на отказоустойчивом кластере, не нужно предпринимать никаких специальных шагов. На резервном сервере необходимо выполнить следующие настройки:
Укажите сервер-получатель с другими конечными точками сервера, которые синхронизируются с той же группой синхронизации, что и главный сервер, но не включайте доступ к серверу для конечных пользователей. При этом все файлы на главном сервере синхронизируются с резервным сервером. Можно рассмотреть возможность перемещения только на уровень пространства имен, чтобы изначально загружалось только это пространство. Для быстрой перенастройки доступа конечных пользователей к резервному серверу в случае сбоя на главном, можно использовать пространство имен DFS-N.
Защита / резервное копирование данных
Защита фактических данных — это один из ключевых компонентов решений для аварийного восстановления. Существует два main способов сделать это с общими папками Azure: вы можете создать резервную копию данных в облаке или локальной среде. Настоятельно рекомендуется создать резервную копию данных в облаке, так как облачная конечная точка будет содержать полную копию данных, а конечные точки сервера могут содержать только подмножество данных.
Резервное копирование данных в облаке
Используйте в качестве решения для облачного резервного копирования службу Azure Backup. Среди прочего служба Azure Backup обеспечивает планирование резервного копирования, хранение и восстановление резервных копий. При желании можно вручную создавать моментальные снимки общего ресурса и настраивать собственное решение для планирования и хранения, но это не идеально. В качестве альтернативы можно напрямую создать резервную копию общих папок Azure с помощью сторонних решений.
В случае аварии можно восстановить данные с помощью моментального снимка общей папки, который представляет собой копию общей папки на определенный момент времени, доступную только для чтения. Так как эти моментальные снимки доступны только для чтения, программа-шантажист не повлияет на них. Для больших наборов данных, в которых операции полного восстановления общего ресурса занимают много времени, можно включить прямой доступ пользователей к snapshot, чтобы пользователи могли копировать необходимые данные на локальный диск во время восстановления.
Моментальные снимки хранятся непосредственно в общей папке 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 не будет очищена.
После отработки отказа серверные конечные точки сервера автоматически переключатся на синхронизацию с облачной конечной точкой в дополнительном регионе. Однако серверные конечные точки должны согласовываться с облачными конечными точками. Это может привести к конфликтам файлов, так как данные в дополнительном регионе могут быть не перехвачены в основной.