Adding new node to DFS/DFSR (part 1)

В общем, простая на первый взгял задача. Имеются удаленные офисы, один домен, но в каждой локации как минимум один домен-контроллер. Плюс для обмена файлами поднят DFS/DFSR, в каждой локации имеется свой DFS/DFSR сервер. Всё на виртуалках. В одной из локаций возникла задача перемещения одного из узлов DFS/DFSR на другой Hyper-V сервер (чтобы освободить старый для длительного обслуживания). Можно, конечно, было просто переместить виртуалку, но попутно решили перейти со старой уже WS2012 R2 на более новую WS2016. Причем желательно, ничего не поломав %) Поехали…

Тут не затрагиваем вопросы, как создавать DFS namespaces и как создавать новые группы репликации – в Интернете достаточно много материала, как это делается.

А вот как добавить-перенести – оказалось, что и не так уж и много и большинство из времен 2000-2008 версий.

Поэтому пишу себе шпаргалку %)

0. Основная идея и базовые понятия

Основная идея – если нужно что-то перенести, причем попутно еще и сменить-проапгрейдить – в мире Микрософт для этого проще всего создать новый узел, реплицировать всё на него, а старый… на пенсию или на апгрейд. Причем это работает как для домен-контроллеров, так и для миграции баз Exchange, перемещения узлов DFS/DFSR.

Базовые понятия – детально тут – How DFS Works. И хотя тут про 2003-ю версию, но базовые понятия те же. Ну или вездесущая WikiPedia.

И так – DFS (Distributed File System). Состоит из двух базовых понятий – Namespaces и Replication.

Namespaces – это возможность доступа к общим ресурсам по универсальным сслыкам типа \\имя_домена\имя_ресурса, при этом у одного ресурса может быть несколько копий (например, в каждом удаленном офисе имеется своя копия) и сервер сам решает, куда отправлять пользователя за данными.

Естественно, копии должны быть синхронизированы – для этого существует вторая функция/роль – Replication. Она решает, что и как реплицировать между копиями. При этом, попутно, периодически возникают конфликты (например, один и тот же файл одновременно редактировался в двух локациях, а так как реплицирование далеко не мгновенное – серверу придется решать, какую копию оставить, а какую… нет, не удалить – конфликтные копии перемещаются в скрытую папку DfsrPrivate/ConflictAndDeleted, где она и хранится некоторое время. Аналогично для удаленных файлов – они сперва перемещаются в DfsrPrivate/Deleted).

Причем не обязательно, чтобы роли Namespaces и Replication были на одном сервере – но у меня именно на одном.

Еще такой момент – где хранить свою копию реплицируемых данных? На старом сервере для этого был создан виртуальный vhd диск на рейде Hyper-V. Но за время пользования хранилище немного разрослось (до 1Тб) и активно используется. Плюс бекапы виртуалки – бекапится вся виртуалка включая копию реплицируемых данных. И хотя бекап итеративный – но каждый раз приходится сканировать весь 1Тб, что увеличивает время бекапа. Можно бекапить не все диски, а только избранные – но это уже другая тема, почему у нас так. Учитывая, что данные и так на рейде, да еще и во многих географически разнесенных ипостасях (как минимум в 4-х) – то бекапить всю виртуалку, да еще в 4-х локациях, смысла не имеет. Если накрылся один узел – пользователь будет незаметно перенаправлен на другую копию. Как поднимется новый узел, на него просто реплицируем актуальные данные с остальных локаций. Что и сделано в данной статье.

Поэтому учитывая, что имеется достаточно мощный QNAP TVS-863+ с 10G линком к Hyper-V серверу, было  решено “отрезать” 1Тб от хранилища QNAP в виде iSCSI LUN и приаттачить его напрямую к виртуалке, то есть без всяких промежуточных vhd.

1. Установка “голого” WS2016 Standard

Итак, на новом Hyper-V будет развернут новый WS2016 Standard (почему именно 2016 и почему Standard – потому что согласно Microsoft Action Pack subscription у меня имеются именно такие лицензии).

Итак, качаем ISO образ, создаем новую виртуалку с параметрами  2x vCPU, 4G RAM, SSD 60G. Меньше CPU или памяти не советую. Сразу линкуем скачанный ISO и запускаем установку. Там всё тривиально, единственное что при выборе, что ставить – Windows Server 2016 или Windows Server 2016 (desktop experience) – выбираю последний. Первый, который просто Windows server 2016 – это чисто консольный вариант (то есть тогда настройка через PowerShell и только PowerShell ). Дальше ничего особенного, установил, активировал, накатил последние обновления… А нет, не так просто – оказалось, что сперва у меня был образ полугодовой давности и он ну никак не захотел обновляться – не понравился ему кумулятивный апдейт за март 2018. И в логах ничего интересного. Просто failed без объяснения причин… Поэтому скачал самый последний образ и о чудо – всё накатилось с полпинка….

2. iSCSI LUN с QNAP TVS-863+ в качестве хранилища

2.1. QNAP: iSCSI LUN

Сперва смотрим мануал от самого QNAP – How to create and use the iSCSI target service on a QNAP Turbo NAS

В моем случае выглядело так – на QNAP заходим в Storage&Snapshots и запускаем визард iSCSI Storage -> Create (в картинках), на примере тестового target’а в 100G :

Из особенностей:

  • логин-пароль CHAP и очень желательно прописать еще и доступ в iSCSI ACL (см. последний скриншот);
  • я выбрал Thick provisioning так как QNAP используется еще и как хранилище всяких больших тестовых файлов и, как это всегда оказывается, много места мало не бывает. Поэтому лучше сразу зарезервировать всё место;
  • поставил Report volitile write cache, если будет сильно мешать (так как повышая надежность понижаем производительность), снимем. Но учитывая, что по умолчанию у DFSR выставлен bandwidth в … 8М – не думаю, что критично;
  • насчет FUA bit capability – нигде не нашел, поддерживается ли. Поэтому пока оставил как есть, потом проверим;
  • образ в виде файла (image file on a volume) по двум причинам: другой вариант у меня задизейблен в виду того, что нет свободного неразмеченного места + хоть и выделил 1ТБ, но, подозреваю, это не надолго и нужно иметь возможность легко и просто расширить.

Линкуем к виртуалке.

3. Hyper-V + iSCSI LUN

Запускаем на Hyper-V сервере Server Manager -> Tools -> iSCSI Initiator.

У меня он сразу увидел созданный только что QNAP iSCSI LUN target (сейчас он inactive):

Если этого не произошло, идем на вкладку Discovery

и там в Discover Portal прописываем наш QNAP.

Возвращаемся на вкладку Targets, выбираем наш target (который сейчас Inactive) и жмем Connect:

Обязательно щелкаем Advanced и прописываем созданные ранее логин-пароль CHAP. Если вдруг создавали еще и Mutual CHAP логин-пароль – прописываем тут же:

Жмем Ок и – ура, connected:

Если на сервере зайти в Disk management – увидите новый диск, статус offline. Так и оставьте, не надо его делать online.

Дальше просто полностью отдаем этот диск нужной виртуальной машине:

Теперь, если зайти на виртуалку – увидим там новый диск, вот тут ему уже нужно сделать “online”, и дальше как с обычным диском – создать раздел, форматнуть.

Всё, к установке DFS/DFSR всё готово.

Продолжение следует…

One Comment