Данная статья является переводом блог поста NedPyle [MSFT], опубликована с разрешения автора. Я сделаю попытку перевести его стиль, но вероятно у меня ничего не выйдет :) рекомендую прочитать первоисточник. (This article is a translation of NedPyle [MSFT] blog post, published with authors permission. I've did my best trying to save authors style, but I don't think that it is as good as a source, so you should read the source, if possible :) )

Всем привет, Ned снова с вами. С той огромной популярностью виртуализации как сейчас, вы можете захотеть надежно и безопасно использовать DFSR на Hyper-v, Xen, KVM, или VMware - Более того, вполне возможно, вы уже там его запустили!

Знайте, это статья поможет сохранить вам свою работу! Ок, наверное я перегнул палку; Это статья поможет спасти ваши файловые сервера (и доменный контролер, прим. переводчика).

О ролях, с множеством владельцев.

В большинстве случаев сервера виртуализируются прозрачно и нет необходимости задумываться о каких то деталях; Гипервизор становится чем то вроде стандартной "физической среды" внутри компании. Но когда вы планируете развернуть на нем роль с множеством владельцев, к примеру репликацию, такую как - Active Directory Domain Services (AD DS), File Replication System (FRS) или Distributed File System Replication (DFSR) - вам следует отнестись к этому внимательно.

DFSR содержит свою базу данных на каждом томе, участвующем в файловой репликации. Такой движок (extensible storage engine, aka Jet) базы данных записывает к каждому изменение реплики дополнительные метаданные, которые мы называем "свод знаний" или "вектор версий". Это значит, что каждый сервер отслеживает:

UID и GVSN:

• GUID соответствует DFSR database ID определенного сервера
• Водяной знак версии тома базы данных, который фиксируется в момент когда мы замечаем создание файла, его обновление или удаление.

Эти записи можно просмотреть у файла командой DFSRDIAG IDRECORD и, если вы захотите узнать, какие GUID пришли от какого сервера, используйте команду DFSRDIAG GUID2NAME.

Сразу видно, что очень важный файл (файл крыска.bmp, прим. переводчика)

Число или вектор версий ("Логическое время") всегда может только расти и каждый DFSR сервер отслеживает его последнее известное значение на других серверах репликации. При этом UID файла никогда не изменяется, тогда как GVSN меняется при любом изменении файла или директории.

Таблица ниже отображает состояние базы данных сервера “ServerA”: она содержит в себе реплицируемую директорию “rf1” с двумя файлами “canary”(канарейка, п.п.) и “cat” (кошка, п.п.) созданных на этом сервере:

Примечание: Когда DFSR создает первую реплицируемую директорию, UID этой папки помечен с помощью GUID содержимого из Active Directory и "v1”, и GVSN первого сервера в Реплицируемой Директории и “v10”.

На данный момент, база данных сервера ServerB знает только о директории RF:

Затем происходит обмен векторами версий между серверами. ServerB сверив свою базу данных с ServerA, понимает, что у ServerA максимальный водяной знак равен 12 и то, что у него нет водяных знаков с 11 по 12 (речь о GVSN, п.п.). Соответственно, он запрашивает эти обновления, реплицирует их и обновляет св��ю базу данных, чтобы она соответствовала базе данных ServerA.

Когда ServerA реплицирует данные "от себя" к своему партнеру ServerB – такой процесс называется "объединением", вместе с вектором версий он шлет последовательность(chain) типа “ServerA –> 11..12”, а затем реплицирует данные файлы в такой последовательности:

По завершению этого процесса, базы данных обоих серверов выглядят одинаково и ServerB знает все последние изменения на ServerA:

Если происходят изменения на ServerB в файлах cat.docx (кошка, п.п.) и появляется новый файл dog.txt (собака, п.п.), он использует свои водяные знаки, помеченные как ServerB и процесс запускается в обратную сторону, в тот момент когда ServerA узнает о векторе версий ServerB. Более того, если я добавлю поддиректорию “Fried”(жаренный, п.п.) с файлом “chicken.rtf” (цыпленок, п.п.) на ServerA, эта информация реплицируется на ServerB с куда более глубокой взаимосвязью с родителем.

Теперь база данных на обоих серверах выглядит вот так:

А файловая система выглядит вот так:

 
Мммм.... Жаренный цыпленок....

Самая Важная Плюшка - Не восстанавливайте snapshots или полный бэкап сервера

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

Словом, если вы ничего не прочитали в этой статье, прочитайте хотя бы это:

• Сохранение/Snapshot Виртуальных машин. Если вам нужно остановить виртуальную машину с DFSR, полностью выключите ее через "выключение работы". Не надо ее сохранять, приостанавилвать или делать Snapshot. 
• Бэкап Виртуализированного DFSR. Когда вы делаете бэкап виртуализированного DFSR, делайте это на стороне гостевой машины используя программу, которая знает как работать с VSS (теневые копи��, п.п.). Не надо делать это со стороны хоста виртуализации и не надо пытаться восстановить бэкапы DFSR серверов (которые сделаны со стороны хоста, п.п.).

Частный DFSR

Если вы не будете руководствоваться этой статьей и попытает��сь использовать snapshot или сохранение виртуальной машины, или используете бэкап на стороне хоста виртуализации не поддерживающий теневые копии, то после восстановления такой виртуальной машины, она больше никогда не будет реплицироватся. В логах сервера будут появляться DFSR события 2212, 2104, 2004 и 2106. Между восстановленным серверов и другими серверами репликации появятся конфликты в сохраненных данных об изменениях, и они не смогут их решить, так как не ожидают, что у кого то из них время может пойти вспять. Только обычное восстановление базы данных на виртуальной машине, которое учитывает использования VSS способно избежать таких проблем - но это не оптимальное решение; проще просто сохранить сами файлы и восстановить их, не задумываясь, что там происходит с самой базой данных. Если вы обнаружили, что у вас ситуация KB2517913, то это значит, что вас ждет куча проблем (вас ждет мир боли и страдания - примерно так в оригинале, п.п.) и вам следует начинать звонить команде поддержки MS, чтобы они помогли удалить текущую структуру базы данных DFSR на всех восстановленных серверах, и возможно сделать несколько настроек репликации, чтобы убедится что у вас все стало работать так, как следует. 

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

AD DC и SYSVOL 

(очень рекомендую ознакомится с этим курсом, там много на эту тему, п.п.)

Почему слово "безопасно" в кавычках? Потому что по прежнему есть риск при восстановлении DC snapshots или бэкапов этих машин:

1. Если вы восстановите все доменные контроллеры в домене, SYSVOL перестанет реплицироваться. В инфраструктуре не будет ни одного авторитативного доменного контроллера и все будут пытаться одновременно получить авторитативные данные, которых уже нет.

2. Любая другая частная реплика DFSR на другом томе (которая не имеет отношения к SYSVOL) перестанет реплицироваться и потребует восстановления. Более того, частные RFs на том же томе, что и SYSVOL "вдруг" попытаются восстановится не авторитативно (а они разделяют одну и туже базу данных), они вполне могут потерять часть данных от изменений, которые не успели реплицироватся до момента создания snapshot - такие изменения будут удалены.

3. Не смотря на то, что не авторитативное восстановления SYSVOL обычно нормальное действие (так как обычно там не так много изменений и они в большинстве своем приходит от одного сервера), групповые политики PDC эмулятора на этом узле будут нарушены до тех пор пока они не пройдут новую синхронизацию. А также, если это был PDC эмулятор, то недавние GP(групповая политика, п.п.) изменения, которые не успели реплицироваться будут потеряны навсегда (как в случае под пунктом №2) 

4. Эта техника требует виртуализацию Windows Server 2012 или позднее. Windows Server 2008 R2 и более рание домейн контроллеры не поддерживают VM Generation ID, так что у них все закончится на этапе USN rollback для AD с полностью уничтоженной SYSVOL базой данных.

Я похож на заевшую запись? Это все старая информация для администраторов AD - они годами читают это в KB статьях, на TechNet'е и в блогах, начиная еще с Virtual Server 2005 – но нам бы хотелось, чтобы все осознали насколько это важно!

Прочее

Ниже будут приведены прочие рекомендации по безопасной виртуализации серверов DFSR.

Примечание: В этой статье речь идет только о Microsoft Hyper-V; в случаях решений от других компаний, пожалуйста, свяжитесь с вашими поставщиками гипервизера по поводу возможностей и ограничений на их использование..

1. Microsoft рекомендует Hyper-V как предпочитаемый гипервизер для виртуализации DFSR. Как было замечено ранее, Windows Server 2012 Hyper-V/Microsoft Hyper-V Server 2012, оба включают в себя критически важную новую фичу,   VM Generation ID, которая была разработана, чтобы решить проблемы в рабочих процессах, таких как Active Directory, File Replication Services и DFSR, которые чувствительны к "путешествиям во времени". Также, Microsoft разрабатывает, тестирует, оптимизируют и проверяет все программные решения с Hyper-V, это входит в цикл тестирования продукта (Common Engineering Criteria).

К тому же, Microsoft не рекомендует использовать гипервизеры, которые не заявлены как поддерживаемые в Microsoft Server Virtualization Validation Program (SVVP).

2. Избегайте создание Snapshot и бэкапов со стороны хоста виртуализации – выше об этом написано достаточно. Восстановление виртуальной машины из сохраненого состояния или snapshot разрушает частный DFSR. Используйте бэкап со стороны виртуальной машины, поддерживающий VSS (теневые копии).

3. Надежная и высокопроизводительная подсистема дисковой записи, с настройкой гипервизера как прямой записи на диск – Хост виртуализации должен иметь дисковую систему, которая соответствует хотя бы одному из следующих критериев, чтобы обеспечить целостность не смотря на кратковременные ошибки системы питания:

• Система построена на базе дисков серверного класса (SCSI, Fiber Channel, и т.д.)
• Система использует диски, с обеспечением независимого питания (батарейки) для кэша (HBA)
• Система использует дисковый массив (такой как RAID) в качестве устройства для хранения
• Система подключена через ИБП
• Отключена система кэгирования дисков

Если данные критерии не выполняются, то разрушения данных (возникновение ошибок), при аварийной потери питания, становятся намного вероятней. Когда DFSR обнаруживает ошибки в базе данных в Windows Server 2012 и более поздних выпусках, она удаляет базу данных и инициирует не авторитативную синхронизацию.

При виртуализации DFSR с помощью Hyper-V, используйте виртуальные диски подключенные к виртуальным SCSI контроллерам для DFSR данных (через настройки виртуальной машины). Это позволит значительно повысить скорость системы ввода вывода, т.к. виртуальный SCSI значительно превосходит по производительности виртуальный IDE (даже без кэширования)(в интернете много обратной информации, но NED, утверждает, что это так, п.п.). Помните, что Windows Server 2012 Hyper-V и ранее могут загружатся только с виртуальных дисков, подключенных к вирутальному IDE. Таким образом, ваша виртуальная машина должна быть настроена следующим образом:

       A. Загрузка ОС с виртуального диска подключенного к виртуальному IDE контроллеру.

       Б. Подключен один или более диск (для данных) к виртуальному SCSI контроллеру (именно на нем должны находится реплицируемые данные).

 
Ну да, такое имя у хоста виртуализации. У меня очень ограниченный бюджет на железо, я просто PM (в вольном переводе, имя - вторсырье, п.п.)

При использовании Hyper-V, размещайте DFSR данные на виртуальных дисках, подключенных к виртуальному SCSI!

4. Не клонируйте, не экспортируйте и не копируйте виртуальные машины  – Я писал в первой части, что DFSR базируется на определенных уникальных параметрах компьютера, таких как дисковый том или сигнатура базы данных. Если вы создаете множественные копии DFSR серверов, то все они будут полагать, что они один и тот же сервер, с точки зрения DFSR – даже если вы потом их переименуете и заново введете в домен. Клоны создают черные дыры в топологии репликации если вы вновь использовалии эти машины с прежними метаданными DFSR (особенно если вы случайно оставили им прежнее имя и IP– что возможно даже с VDC). Всегда создавайте новые сервера из sysprepped образов или с чистой установки и никогда не делайте копии действующих серверов.

5. P2V с заботой - Несмотря на то, что конвертирование физического DFSR сервера в виртуальный является поддерживаемой при помощи SCVMM или Disk2Vhd, вы не должны допустить, чтобы оба образа компьютера были запущены одновременно. В случае SCVMM, вы должны выбрать “offline mode conversion”, а, в случае Disk2VHD, просто будьте осторожны. В обоих случаях, как только у вас появилась рабочая виртуальная машина, вы никогда не должны запускать ее физический аналог внутри сети (с.м. №3).

6. Не приостанавливайте и не сохраняйте виртуальную машину – не смотря на то, что использовать эти технологии не является плохим методом, тем не менее такая виртуальная машина похожа на отключенную: чем дольше она в таком состоянии, тем более значительные изменении в репликации происходят без нее. Если пройдет слишком много времени, то она больше никогда не сможет реплицироваться, особенно если учесть, что в Windows Server 2012 опция "content freshness" включена по умолчанию. Привычка ставить на паузу или сохранять виртуальную машину, это как привычка выключать физические сервера - рано или поздно, вы забудете, что сделали это.

7. Используйте несколько хостов виртуализации – Типичный сценарий когда все яйца в одной корзине. Если у вас всего один хост виртуализации, то однажды он навернётся. Используйте Failover Clustering, Hyper-V Live Migration, или Hyper-V Replica чтобы быть увереными, что даже если хост виртуализации упадет, все процессы смогут продолжится. Если вы не можете реализовать настоящую высокую доступность, хотя бы убедитесь что ваши машины запущены на разных хостах виртуализации (речь явно идет о членах репликации, п.п.). Это (очень) базовая подстраховка, что выход из строя железа не остановит вашу файловую репликацию.

8. Обеспечьте безопасность ваших гостевых машин и хостов виртуализации – В отличии от других best practices(лучших решений), здесь речь не про надежность, а реально о безопасности данных:

• Убедитесь, что только наиболее доверенные администраторы имеют права локальных администраторов на хосте виртуализации (например, свободный доступ к виртуальным дискам). Невозможно запретить администратору просто скопировать виртуальный диск на внешний носитель для дальнейшей атаки, поэтому тех. поддержка MS рекомендует предпринимать меры по безопасности от должностных преступлений, обеспечивать хороший аудит и применять рекомендуемую практику безопасности.
• Ваши Hyper-V админы должны использовать группу Hyper-V Администраторов и иметь файловый доступ только к своим собственным виртуальным машинам.
• Физические диски, на которых размещены ваши виртуальные диски должны использовать шифрование, такое как  BitLocker (с TPM и множеством защит). А еще лучше, убедитесь, что хосты также используют BitLocker Network Unlock, чтобы эта информация не могла свободно "уйти" за пределы организации. (BitLocker не поддерживается внутри виртуальной машины, так как вам пришлось бы использовать Защиту Паролем (Password Protectors), и массовый перезапуск серверов во вторник(microsoft выпускает обновления каждый вторник, п.п.) испортил бы вам день)

Послесловие