Udostępnij za pośrednictwem

Высокодоступное файловое хранилище в Azure на основе Windows Server Distributed File System (DFS)

  • Artykuł

Примечание: данная статья создана на основе статьи Carsten Lemm High-Available File Share in Windows Azure using DFS.

Зачем вообще в облаке может потребоваться высокодоступное файловое хранилище?

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

Архитектура многих существующих приложений такова, что для работы с данными используются сетевые папки или общие хранилища (настроенные RAID, SAN или что-то аналогичное), работающие по протоколу SMB. Есть несолько вариантов миграции таких приложения в Microsoft Azure :

  1. Внесение в архитектуру приложений изменения, т.е. напрямую работать с Azure BLOB Storage через REST или SDK, например. Такой подход имеет ряд преимуществ, например, нет затрат на оплату времени работы виртуальных машин, т.е. итоговая стоимость эксплуатации решения будет ниже. Кроме того, запросы на работу с файлами могут идти напрямую в Storage, используя полосу пропускания Storage’а, а не через прокси (при наличии большого количества запросов еще придется масштабировать эту прокси-машину, тогда как в Storage это осуществляется автоматически на уровне самой службы), которым выступает виртуальная машина в случае обсулживания работы с файлами.

  2. Но иногда изменения сложно осуществить, если это сторонний компонент или если задача является слишком трудозатратой (особенно на первой стадии миграции в облако). Поэтому возникается необходимость миграции приложения as-is, т.е. без внесения каких-либо изменений в код. В этом случае может быть использована отдельная виртуальной машина (IaaS), на которой настроена файловая служба (File Services) , которая обеспечит работу приложения по SBM протоколу.

Виртуальные машины в Azure и организация файлового хранилища

При выборе второго подхода следует учитывать:

  1. Во-первых, ограничение в 16ТБ. К виртуальной машине могут быть подключены от 1 до 16 дисков данных (Data Disk) в зависимости от выбранного шаблона виртуальной машины. Каждый диск данных может иметь объем до 1ТБ, и диски не могут разделяться (быть примонтированным) между виртуальными машинами.

  2. Во-вторых, доступность это виртуальной машины, на которой будут хранится файлы. На данный момент SLA на доступность (99,95%) предоставляется для 2х и более виртуальных машин, объединенных в Availability Set. Т.е. если что-то произойдет с физическим оборудованием, или хостом Hyper-V, на котором запущена виртуальная машина, или потребуется перезагрузка виртуальной машины для применения обновлений, то виртуальная машина будет какое-то время недоступна, а значит и файлы. Если запущены две вириальные машины, включенные в Availability Set, то они гарантировано разнесены по разным стойкам и обновления к ним не будут применяться одновременно, т.е. хотя бы одна из машин всегда (99,95%) должна обслуживать поступающие запросы. 

Поэтому возникает вопрос: каким образом в Azure может быть построено распределенное по нескольким машинам файловое хранилище?

Ответ простой - распределенное файловое хранилище можно создать с помощью службы Distributed File System (DFS) в Windows Server. Такой подход позволит обойти вышеописанные ограничения (доступность, максимальный объем хранилища и синхронизацию файлов между дисками данных виртуальных машин). Кроме того, DFS полностью поддерживается для разворачивания в Azure, т.к. входит в состав службы File Services (подробнее о поддерживаемых продуктах в статье Microsoft server software support for Windows Azure virtual machines).

DFS состоит из двух основных технологий:

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

  • DFS Replication, которая позволяет синхронизировать данные в общих папках между всем серверами. Для этого используется эффективный механизм репликации - Remote Differential Compression.

Объединение этих технологий позволит нам реализовать распределенное и высокодоступное файловое хранилище в Azure. Необходимо принимать во внимание, что в случае отказа одного из узлов DFS клиент может заметить небольшую задержку в доступе к данным. Это связано даже не с архитектурой DFS, а с тем, что SBM какое-то время пытается связаться с тем же сервером (что оправдано в случае временного сбоя в работе сети), а не переключается сразу на другой (работающий) сервер. Проведенные тесты в оригинальной статье показали задержку переключения максимально в 90 секунд, а среднее - 60 секунд.

Архитектура решения

image

На рисунке ниже показана общая архитектура решения:

  • DFS инфраструктура развернута в выделенной виртуальной сети в Azure (VNET).

  • Приложения или любые другие клиенты, которые будут обращаться к DFS, также должны быть включены в данную сеть.

  • На машинах настроена служба DFS и настроены DFS Replication и DFS Namespace. Эти машины включены в Avaliability Set, что соответствует требования SLA в Azure и обеспечивает доступность машин 99,95% времени.

  • Для DFS требуется Active Directory. В данном примере для простоты DFS и служба управления доменами (Domain Services) будут установлены на одних и тех же виртуальных машинах. Т.к. DC на машинах, которые уже включены в Avaliability Set, то для них также гарантируется SLA.

  • Кроме того, на двух машинах с DC запущена служба DNS, которая настроена как DNS для всей VNET.

  • Создана DFS папка, которая будет связана с общей папкой на каждом сервере. Каждая такая папка будет находится на отдельном диске данных (Data Disk) для каждого сервера.

  • Клиентские машины, получающие доступ к DSF файлам, могут быть как подключенными к созданному ранее домену, так и не подключенными, а также быть как IaaS, так и PaaS.

Пошаговая настройка DFS

Регистрация DNS сервера

Нам необходимо настроить DNS сервер для того, чтобы резолвить имена машин внутри нашей VNET. Контроллер домена, на котором запущена служба DNS, будет располагаться в отдельной подсети, это позволит нам точно знать его IP адрес. Согласно документации, первый IP-адрес в подсети будет xxx.xxx.xxx.4, второй - xxx.xxx.xxx.5 и так далее. Т.к. в подсети у нас будет только одна виртуальная машина (DC), то ее адрес можно заранее определить.

Обратите внимание, что это не гарантированное поведение и может измениться в будущем. Есть еще возможность зарезервировать внутренний IP адрес за машиной в виртуальной сети с помощью PowerShell – подробнее здесь.

  1. Зайдите на портал управления Azure, выберите Network Services – Virtual Network – Register DNS Server:

    • Name: dns01

    • DNS Server IP Address: 10.1.1.4

  2. Выберите снова Network Services –> Virtual Network –> Register DNS Server и заполните значения для второго DNS сервера:

    • Name: dns02

    • DNS Server IP Address: 10.1.1.5

    image

Создание виртуальной сети

  1. Выберите пункт New – Network Services – Virtual Network – Custom Create:

    • Name: dfsvnet

    • Affinity Group: Create a new Affinity Group (данная Affinity Group будет использована для всех ресурсов Azure данной системы)

    • Region: -выберите регион-

    • Affinity Group Name: dfsag

    image

  2. Теперь выберите DNS сервера (dns01 и dns02), которые создали ранее. При необходимости можно создать VPN тунель с локальной (Configure site-to-site VPN). Кстати, его можно создать и позже.

  3. Далее заполните значения для сети:

    • Address Space: 10.0.0.0/8

    • Subnet 1:

    • Name: dfs

    • Starting IP/CIDR: 10.1.1.0/29

    • Subnet 2:

    • Name: main

    • Starting IP/CIDR: 10.2.1.0/16

    image

  4. Виртуальная сеть начнет создаваться.

Создание аккаунта хранилища

  1. Создайте новый аккаунт хранилища (обратите внимание, что используете та же Affinity Group, что и для виртуальной сети):

  • Name: hadfsstorage

  • Affinity Group: dfsag

Создание первой виртуальной машины - dfs01

На данной виртуальной машине будет развернут домен контроллер, DNS, DFS Namespace и DFS Replication на основе Windows Server 2012 R2.

  1. Выберите Select New – Compute – Virtual Machine – From Gallery:

    • Platform Image: Windows Server 2012 R2 Datacenter

    • Virtual Machine Name: dfs01

    • Size: Medium

    • New User Name: dfs

    • New Password/Confirm: _DFS0n@zure#

    image

  2. Теперь сконфигурируем саму виртуальную машину:

    • Cloud Service: Create a new cloud service

    • Cloud Service DNS Name: dfsdemo.cloudapp.net

    • Virtual Network: dfsvnet

    • Subnet: dfs (10.1.1.0/29)

    • Storage Account: hadfsstorage

    • Availability Set: -сreate an availability set-

    • Availability Set Name: dfsavset

    image

  3. Оставьте значение порта RDP и PowerShell по умолчанию. Машина начнет создаваться, это может занять около 5 минут.

  4. Убедитесь, что машине присвоен IP адрес 10.1.1.4.

Присоединение Data Disk'ов к виртуальной машине dfs01

Далее необходимо к виртуальной машине присоединить Data Disk'и, на которых будут хранится файлы база Active Directory и общие папки DFS:

  1. На портале управления Azure откройте страницу управления виртуальной машины dfs01.

  2. Выберите пункт внизу страницы Attach – Attach empty disk.

  3. Укажите размер диска 5ГБ.

  4. Зайдите на виртуальную машину по RDP.

  5. Откройте Disk Management и инициализируйте создание нового диска.

  6. Присвойте тому букву F: и выполните быстрое форматирование.

Промотирование виртуальной машины dfs01 в домен контроллер

Процесс настройки виртуальной машины как контроллера подробно описан здесь, поэтому пройдем только по основным шагам:

  1. Присоединитесь к машине dfs01 по RDP.

  2. Установите Active Directory Domain Services через Server Manager (Add Roles and Features) .

  3. Выполните промоушен сервера до домен кнтроллера (оставьте все значения по умолчанию и проигнорируйте предупрждения):

    • Deployment operation: Add a new forest

    • Root Domain Name: dfsdemo.com

    • DSRM Password: _DFS0n@zure#

    • Location of AD DS database: F:\NTDS

    • Log files: F:\NTDS

    • SYSVOL: F:\SYSVOL

  4. После настройки машина перезаргузится и сможет теперь выполнять функции контроллера домена.

Создание второй виртуальной машины

Теперь создадим вторую виртуальную машину, котор так же будет содержать домен контролле, DNS сервер, DFS Namespace и DFS Replication и обеспечиваться отказоустойчивость этих служб (в том числе за счет настройки Availability Set).

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

Virtual Machine Name: dfs02

Cloud Service: dfsdemo (такой же как для dfs01)

Availability Set: dfsavset

Обратите внимание, что очень важно развернуть виртуальную машину в DFS подсети (subnet) и в том же Availability Set!

Присоединение Data Disk'ов к виртуальной машине dfs02

Присоедините пустой Data Disk к машине dfs02.

Промотирование виртуальной машины dfs02 в домен контроллер и присоединение к домену dfsdemo.com

Теперь приоединим машину к домену dfsdemo и назначим ее резервным домен контроллером.

  1. Присоединитесь к машине dfs02 по RDP.

  2. Установите Active Directory Domain Services через Server Manager (Add Roles and Features).

  3. Выполните промоушен сервера до домен кнтроллера (оставьте все значения по умолчанию и проигнорируйте предупрждения)

    • Deployment operation: Add a domain controller to an existing domain

    • Domain: dfsdemo.com

    • Credentials: dfsdemo\dfs

    • Site name: Default-First-Site-Name

    • DSRM Password: _DFS0n@zure#

    • Replicate from: dfs01.dfsdemo.com

    • Location of

      • AD DS database: F:\NTDS

      • Log files: F:\NTDS

      • SYSVOL: F:\SYSVOL

  4. После настройки машина перезаргузится и сможет теперь выполнять функции контроллера домена.

Проверка установки

Убедитесь, что машины созданы, запущены (Running) и имеют корректный IP адрес.

Кроме того, можете убедиться, что оба сервера указаны как домен контроллер в панели Active Directory Users and Computers.

Установка и настройка DFS на dfs01

  1. Присоединитесь к dfs01 по RDP.

  2. Откройте Add Roles and Features Wizard и выберите DFS Namespaces и DFS Replication в пункте File and Storage Services.

  3. Создайте пользователя в Active Directory:

    • User logon name: dfsuser

    • Password: _DFS0n@zure#

  4. Создайте общую директорию, которая называется Shared, на диске F:\ . Предоставьте аккаунту dfsuser  доступ на чтение\запись.

  5. Если планируете предоставлять доступ к DFS для машин, не включенных в домен, то необходимо настроить DFS на использования FQDN (fully qualified domain names). Если же клиенты будут находится в том же домене, то достаточно обращения по NetBIOS имени. Эти параметры выставляются на уровне DFS сервера и только через PowerShell:

    Set-DfsnServerConfiguration –ComputerName “dfs01″ –UseFqdn $true
    Stop-Service dfs; Start-Service dfs

Установка и настройка DFS на dfs02

Установка аналогично шагам для dfs02. Если ранее натсроили DFS на использование FQDN, то повторите тоже и для dfs02:

Set-DfsnServerConfiguration –ComputerName “dfs02″ –UseFqdn $true
Stop-Service dfs; Start-Service dfs

Настройка DFS на dfs01

  1. Откройте DFS Management панель.

  2. Из пункта Action выберите New Namespace.

    • Namespace Server: dfs01

    • Namespace Name: dfsns

    • Namespace Type: Domain-based namespace

  3. Выберите созданный namespace dfsdemo.com\dfsns.

  4. Из пункта Action выберите Add Namespace Server.

    • Namespace Server: dfs02

  5. Выберите dfsdemo.com\dfsns.

  6. Из пункта Action выберите New Folder.

    • Name: dfsshare

    • Add Folder Target: \\dfs01.dfsdemo.com\Shared

    • Add Folder Target: \\dfs02.dfsdemo.com\Shared

  7. На вопрос о создании группы репликации (replication group) ответьте Yes и примите все значения по умолчанию.

    • Replication Group Name: dfsdemo.com\dfsns\dfsshare

    • Replicated Folder Name: dfsshare

    • Replication Eligibility:

    • Primary Member: dfs01

    • Topology: Full Mesh

    • Replication Group Schedule and Bandwidth: Replicate continuously, Full Bandwidth

  8. После того как группа репликации будет создана, появится предупреждение. По умолчанию интервал репликации в Active Directory составляет 3 часа, поэтому синхронизация может занять какое-то время.

Проверка настройки DFS

  1. Зайдите по RPD на dfs01.

  2. Откройте панель DFS Management.

  3. Выберите папку dfsshare.

  4. Убедитесь, что две папки указывают на dfsshare и пути указаны верно.

  5. Выберите вкладку Replication.

  6. Убедитесь, что там указано две сущности Replicated Folders. И проверьте статус репликации (Replication Status).

  7. Выберите группу репликации dfsdemo.com\dfsns\dfsshare.

  8. Убедитесь, что указаны два папки во вкладке Membership.

  9. Выберите вкладку Connections.

  10. Убедитесь, что настроено два участника репликации.

  11. Выберите вкладку Replicated Folders.

  12. Убедитесь, что dfsshare папку указан как реплицируемая, а статус имеет значение Published to Namespace.

  13. Если все настроено верно, то можно сказать, что у нас получилось распределенное отказоустойчивое файловое хранилище!

Проверка DFS репликации

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

  1. Зайдите по RDP на dfs01.

  2. Создайте файл FromDFS01.txt в папке F:\Shared.

  3. Зайдите по RDP на dfs02.

  4. Проверьте наличие файла FromDFS01.txt в папке F:\Shared (репликация должна произойти примерно в течение минуты)

  5. На сервере dfs01 кликните правой кнопкой мыши dfsdemo.com\dfsns\dfsshare группу и выберите Create Diagnostic Report - DFS Replication Health Report.

  6. Создайте файл FromDFS02.txt в папке F:\Shared на dfs02.

  7. Проверьте рпликацию этого файла в папку F:\Shared на dfs01 сервер.

Создание клиентской машины

Итак, протестируем доступность и работоспособность созданного DFS из сторонней системы. Для этого создадим клиентскую машину, она будет вне домена dfsdemo.com, хотя поддерживаются и присоединенные к домену машины (помните про настройку FQDN?) . Если система сочетаем в себе как PaaS, так и IaaS, компоненты, то чаще всего как раз PaaS-компоненты не являются частью домена (хотя, например, Cloud Services также можно добавлять в созданную виртуальную сеть и домен). Именно поэтому протестируем на “недоменном” сценарии. Но в любом случае, создаваемая виртуальная машина должна находится в той же виртуальной сети (в нашем случае dfsvnet), что и DFS (на момент написания данной статьи, к сожалению, добавить Web Sites в виртуальную сеть было нельзя, но все может измениться в будущем, поэтому проверяйте!).

  1. Выбирете New – Compute – Virtual Machine – From Gallery

    • Platform Image: Windows Server 2012 Datacenter
    • Virtual Machine Name: dfsclient
    • Size: Small
    • New User Name: dfs
    • New Password/Confirm: _DFS0n@zure#

  2. Выполните конфигурацию виртуальной машины:

    • Cloud Service: Create a new cloud service
    • Cloud Service DNS Name: dfsclient.cloudapp.net
    • Virtual Network: dfsvnet
    • Subnet main (10.2.1.0/16)
    • Storage Account: hadfsstorage
    • Availability Set: (None)

  3. Оставьте значения портов по умолчанию для RDP и PowerShell.

  1.  

Проверка доступности общих папок в DFS

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

  1. Подключитесь по RDP к dfsclient.

  2. Откройте Windows PowerShell ISE.

  3. Создайте PowerShell скрипт, который будет в цикле опрашивать DFS каждую секунду, и сохраните его как CheckShare.ps1.

    while($true)
    {
    Get-ChildItem -path \\dfsdemo.com\dfsns\dfsshare
    (Get-Date).DateTime
    sleep -Seconds 1
    }

  4. Запустите скрипт.

  5. Вы можете создать новый файл на DFS с данной клиентской машины и проверить корректиность репликации на dfs01 and dfs02.

  6. Теперь самое интересное! Сэмулируем недостпность одной ноды DFS (dfs01). Для этого зайдите на портал управления Azure, выберите машину dfs01 и нажмите Shutdown.

    • Теперь сервер dfs02 должен начать обслуживать все входящие запросы к файлам.
    • Это должно быть хорошо видно из вывода запущенного PowerShell скрипта, который опращивает DFS.
    • Будет заметно, что на какое-то время отклика не будет, но потом ответы возобновятся.

  7. Снова запустите машину dfs01 через портал управления Azure и дождитесь пока машину будет в статусе Running.

  8. Теперь через портал управления выключите машину dfs02. Поведение DFS должно быть аналогично описанному выше при отключении первой машины.

Выводы и стоимость

Вот и все. В итоге настроена распределенное высокодоступное файловое хранилище в Azure, которое может быть использовано как только для IaaS инфраструктуры, так и для гибридной IaaS + PaaS. При необходимости в DFS могут быть добавлены новые ноды и namespace’ы, к виртуальным машинам могут быть добавлены дополнительные диски для масштабирования и распределения нагрузки.

Что касается цены такого решения, то она будет заивисеть от нагрузки (запущенных виртуальных машин, объема хранимых данных и т.п.). Например, две Extra-Small (A0) виртуальные машины обойдутся примерно в $28\месяц, а 1ТБ данных в $68\месяц.