Синхронизация файлов Azure: репликация данных между файловыми серверами

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

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

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

Текущий сценарий и желаемое состояние

Мы можем начать этот сценарий с сервера TORFS01, который реплицирует некоторые данные в Azure с помощью Azure File Sync. Мы собираемся добавить новый сервер с именем TORFS02, который является частью того же локального домена, и все данные, измененные на любом файловом сервере, будут автоматически реплицированы на другие конечные точки сервера, которые являются частью той же .

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

• Установите/обновите модуль AzureRM на сервере.
• Установите на него программное обеспечение и зарегистрируйте сервер в нужной службе Azure File Sync.

Зарегистрировав сервер, нам просто нужно перечислить существующий пункт Sync Groups и нажать на нужный. В новой колонке нажмите Добавить конечную точку сервера. Выберите новый сервер, который мы только что зарегистрировали, и укажите путь. (Рекомендуется всегда использовать один и тот же физический путь для данных, потому что это значительно облегчит устранение неполадок, используя согласованные настройки на всех серверах.) Нажмите «Создать».

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

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

Через некоторое время мы видим, что структура создана (C:HomePublic) и у нас там есть данные, значит идет репликация и в конце процесса у нас будут одни и те же данные на всех трех расположения: torfs01, torfs02 и Файлы Azure.

Хорошо, я слышал, вы спрашиваете, как насчет разрешений NTFS? Он сохраняется! В примере ниже мы проверяем свойства одного из файлов и видим, что NTFS такие же, как у оригинала.

Поскольку мы находимся на мы создадим новую папку с именем Created-TORFS02 и проверим, произошла ли репликация.

Теперь, войдя в , мы видим, что папка, которую мы создали на сервере , была реплицирована и доступна и на этом сервере. Это фантастика!

Защита данных файлового сервера в файлах Azure

Есть несколько способов защитить ваши данные. Самым важным из них является правильная структура вашей учетной записи хранения, а для важных данных рекомендуется использовать GRS (геоизбыточное хранилище), которое обеспечивает 99,999999999999999 процентов долговечности объектов в заданном году (да, это много). девятки!). Он работает за счет того, что LRS (локальное избыточное хранилище) фиксирует информацию в первом регионе, а затем асинхронно отправляет информацию в другой регион.

Помимо защиты на уровне хранилища, мы можем воспользоваться . Мы можем создавать их на уровне общего доступа к файлам, и их количество ограничено 200. Они не влияют на производительность и хранятся в той же учетной записи хранения данных, что означает, что они подчиняются одним и тем же законам вашего типа репликации (GRS, ЗРС, ЛРС и так далее).

Чтобы создать , откройте учетную запись хранения, нажмите « Файлы», выберите общий файловый ресурс из списка, нажмите «Снимок» и выберите «Создать снимок», чтобы создать его, или чтобы просмотреть предыдущие снимки, нажмите «Просмотреть снимки».

Если файл был удален случайно, просто нажмите «Снимок», а затем «Просмотр снимка». Отобразится новый блейд, содержащий все снимки, выберите нужный снимок, выберите нужный файл и нажмите «Восстановить».

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

Параметр восстановления позволяет восстановить файл с новым именем или перезаписать исходный файл (если он существует).

Альтернатива Синхронизации файлов Azure?

Другая возможность — использование Azure Backup. Мы подробно расскажем об этом в отдельной статье на TechGenix.