Сводка
У нас есть устаревшая система DFS, которую мы переносим в облако, с организационным требованием перестраивать серверы каждый месяц, используя высокоавтоматизированную среду для запуска и настройки серверов. Проблема в том, что автоматизация восстановления обычно завершает работу старых серверов перед созданием новых, но этот подход не может работать с серверами пространства имен DFS: если вы удалите все серверы, поддерживающие пространство имен, вы потеряете весь доступ к пространству имен и не сможете присоединиться к новым. серверы для управления этим пространством имен.
(Справочная информация)
Система DFS используется многими пользователями и некоторыми приложениями, многие из которых являются старыми приложениями, ожидающими, что определенные пути к каталогам будут доступны . Приложения создают выходные каталоги на нижних уровнях дерева каталогов для хранения вновь созданных данных. В настоящее время у нас есть несколько петабайт данных, по крайней мере, на 100 целевых серверах DFS, используя Windows Server 2016.
Проблема
В то время как мы можем легко создавать новые серверы и поддерживать данные при перестроениях легко, нам нужно будет сломать модель автоматизации из-за необходимости поддерживать пространства имен DFS - вы не можете завершить работу всех серверов пространства имен, а затем создать новые, потому что без существующего сервера, поддерживающего это пространство имен, вы не можете добавлять новые серверы в пространство имен.
У нас гораздо более строгие ограничения на реализацию DFS в облаке (существует гораздо больше ограничений, чем те, которые я упомянул в этом вопросе); как правило, мы будем перестраивать все серверы пространства имен DFS и целевые серверы DFS каждый месяц, и автоматизация работает таким образом, чтобы завершить работу старого набора серверов (но не подключенных томов данных) перед запуском нового набора серверов (и присоединяя старые тома данных к новым серверам - мы по сути заменяем только диск ОС). Но вам потребуется 1 сервер пространства имен для активной поддержки пространства имен, а это означает, что нам придется изменить способ работы автоматизации перестроения, чтобы отделить сервер имен от завершений, завершить / перестроить все, позволить новым серверам пространства имен подключаться к существующее пространство имен посредством того, что старый сервер поддерживает его, затем удаляет старый сервер пространства имен из пространства имен, а затем завершает работу старого сервера пространства имен. Это, по-видимому, несет в себе большой риск, поскольку мы рискуем потерять доступ к пространству имен каждый месяц, если что-то пойдет не так с автоматизацией восстановления, и если потребуется ручное вмешательство, чтобы отсоединить его от существующей инфраструктуры, это также несет риск, присущий всем ручным
Решение?
Альтернативный вариант, который я хочу попробовать, - использовать символьные c ссылки вместо пространства имен DFS. Все наши «цели DFS» представляют собой просто Windows общих ресурсов, поэтому, если бы мы могли создать «пространство имен», имея сервер с общим ресурсом, представляющим «root пространство имен» DFS, иметь в нем несколько каталогов, а затем создавать символические ссылки к фактическим серверам данных на соответствующих нижних уровнях, это позволит всем нашим пользователям просматривать «Пространство имен» как обычно, прозрачно перенаправляться на множество различных файловых серверов, когда они переходят на более низкие уровни дерева каталогов, и это также будет работать для приложений, которые ожидают, что будут доступны определенные c пути. Наша система управления конфигурацией автоматически обеспечит доступность всех правильных каталогов / общих ресурсов / разрешений и их применение как на файловых серверах, так и на сервере «Пространства имен» (она уже делает это для других систем, имеющих Windows общих ресурсов, так что это уже доказано) .
«Пространство имен» не нужно поддерживать при перестроениях, потому что это будет просто другой сервер, который можно перестроить и настроить вместе с файловыми серверами, где автоматизация проверяет / создает каталоги «Пространства имен» и символические ссылки при первом запуске сервера. Мы выполняем перестройку во время запланированного периода обслуживания, она перестраивает все файловые серверы и сервер «пространства имен» (фактически «серверы», потому что у нас будет их несколько за балансировщиком нагрузки), управление конфигурацией обеспечивает все правильные каталоги / ресурсы / разрешения присутствуют (и создает их, если нет), и вскоре у нас есть полностью новый набор всех серверов с правильными ссылками, указывающими на правильные файловые серверы.
Я не использовал символические ссылки раньше. Я знаю, что вы можете создать символическую ссылку на общий сетевой ресурс, поэтому мои основные вопросы:
- по вашему мнению, как вы думаете, мы можем заменить пространства имен DFS символическими ссылками, где цели DFS - Windows share?
- есть ли что-то, присущее моему подходу, которое я пропустил?
- как Windows определяет поток c сетевого трафика при прохождении символической ссылки? Если каталог, в который я пытаюсь записать, - это "\\ root \ business_unit \ data_type \ year", где "datatype" - это символическая ссылка на общий ресурс файлового сервера "\\ servername \ sharename", будет ли операция записи файла проходить через " Namespace "или он будет писать прямо в общий ресурс? Если приложение записывает файл размером 20 ГБ, я не хочу, чтобы весь этот трафик c проходил через сервер «Пространства имен».
Я понимаю, что пытаюсь создать свою собственную упрощенную версию DFS здесь, когда система явно уже существует для выполнения этой работы, но проблема автоматизации, связанная с перестройкой пространства имен, требует от меня, по крайней мере, исследования альтернатив.
Совет приветствуется.