Руководство по аварийному восстановлению для Avere vFXT для Azure

В этой статье описаны стратегии защиты рабочего процесса Avere vFXT для Azure и рекомендации по резервному копированию данных для восстановления после аварий или сбоев.

Avere vFXT для Azure временно сохраняет данные в своем кэше. Данные долговременно сохраняются в системах хранения серверной части — на локальных вычислительных системах, в контейнерах хранения Azure Blob или обоих.

Чтобы защититься от сбоев и возможных потерь данных, рассмотрите следующие четыре области:

  • Защита от простоя, если система Avere vFXT для Azure становится недоступной
  • Защита данных в кэше кластера
  • Защита данных в бэкенд-хранилище аппаратуры NAS
  • Защита данных в серверном облачном хранилище Azure Blob

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

Защита от простоя

Избыточность встроена в Avere vFXT для продукта Azure:

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

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

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

Защита данных в кэше кластера

Кэшированные данные всегда записываются в основные файловые серверы перед плановым завершением работы, но при аварийном завершении работы данные, измененные в кэше, могут быть потеряны.

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

Как правило, план восстановления должен сосредоточиться на резервном копировании внутренних систем хранения, которые содержат больше данных и, как правило, более важны для повторного создания рабочего процесса после сбоя.

Защита данных в основных файловиках NAS

Используйте принятые методы для защиты данных, хранящихся в локальном аппаратном хранилище NAS, включая моментальные снимки и полные резервные копии, как это рекомендуется поставщиком NAS. Аварийное восстановление для этих основных файлов выходит за рамки этой статьи.

Защита данных в хранилище BLOB-объектов Azure

Avere vFXT для Azure использует локально избыточное хранилище (LRS) для основных хранилищ Blob в Azure. Это означает, что данные в контейнерах BLOB-объектов автоматически копируются для защиты от временных сбоев оборудования в центре обработки данных.

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

Ниже приведены рекомендации по защите данных в хранилище BLOB-объектов Azure.

  • Копировать критически важные данные в другую учетную запись хранения в другом регионе часто (как часто определяется планом аварийного восстановления).
  • Управляйте доступом к данным во всех целевых системах, чтобы предотвратить случайное удаление или повреждение. Рассмотрите возможность использования блокировок ресурсов в хранилище данных.
  • Включите функцию Avere vFXT для Azure для облачных моментальных снимков ваших файлов Blob.

Копирование данных основного файлового файла Avere vFXT в учетную запись резервного копирования

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

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

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

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

    Дополнительные сведения см. в параметрах .

    Если контейнер использует только встроенное шифрование Azure, этот шаг можно пропустить.

  2. Удалите основной файловый модуль из системы. Это заставляет кластер записывать все измененные данные в внутреннее хранилище.

    Хотя после резервного копирования необходимо повторно добавить основной файловый сервер, его удаление - лучший способ гарантировать, что все данные полностью записываются в бэк-энд. (Иногда параметр "приостановка" может оставлять измененные данные в кэше.)

    Запишите имя основного файла и сведения о соединении (перечисленные на странице пространства имен на панели управления), чтобы вы могли реплицировать его при повторном добавлении контейнера после резервного копирования.

    Используйте панель управления кластером для удаления основного файлера. Откройте панель управления кластером и выберите Core filer>Управление основными файловыми системами. Найдите систему хранения, которую вы хотите создать резервную копию и используйте кнопку "Удалить ", чтобы удалить ее из кластера.

  3. Создайте новый пустой контейнер для объектов Blob в другой учетной записи для хранения в другом регионе.

  4. Используйте любое удобное средство копирования для переноса данных с основного файлобменника в новый контейнер. Копия должна реплицировать данные без изменений и не нарушать собственный формат облачной файловой системы, используемый Avere vFXT для Azure. Средства на основе Azure включают AzCopy, Azure PowerShell и Фабрику данных Azure.

  5. После копирования данных в контейнер резервной копии добавьте исходный контейнер обратно в кластер, как описано в разделе "Настройка хранилища".

    • Используйте одно и то же имя основного файлового средства и сведения о соединении, чтобы рабочие процессы клиента не должны изменяться.
    • Установите значение параметра Содержимое контейнера на существующий вариант данных.
    • Если контейнер был зашифрован кластером, необходимо ввести текущий ключ шифрования для его содержимого. (Это ключ, который вы обновили на шаге один.)

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

Доступ к источнику данных резервного копирования во время сбоя

Чтобы получить доступ к контейнеру резервного копирования из кластера Avere vFXT для Azure, выполните следующий процесс:

  1. При необходимости создайте новый кластер Avere vFXT для Azure в не затронутом регионе.

    Подсказка

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

  2. Добавьте новое облачное основное хранилище, указывающее на дублирующий контейнер BLOB.

    Обязательно укажите, что целевой контейнер уже содержит данные в параметре содержимого контейнера мастера создания основного файла. (Система должна оповещать вас, если вы случайно оставьте этот набор пустым.)

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

Дальнейшие шаги

  • Last updated on