remote differential compression что это

Обзор репликации DFS

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, Windows Server 2008

Репликация DFS представляет собой службу роли в Windows Server, которая позволяет эффективно реплицировать папки (включая те, ссылка на которые указывается по пути пространства имен DFS) между разными серверами и сайтами. Репликация DFS предоставляет эффективный механизм репликации между несколькими источниками, который поддерживает синхронизацию папок между серверами, соединенными сетевыми подключениями с ограниченной пропускной способностью. Она заменяет собой службу репликации файлов (FRS) в роли подсистемы репликации для пространств имен DFS, а также для репликации папки SYSVOL доменных служб Active Directory (AD DS) в доменах с Windows Server 2008 или более поздним функциональным уровнем.

Репликация DFS использует алгоритм сжатия, называемый удаленным разностным сжатием (remote differential compression — RDC). Алгоритм удаленного разностного сжатия определяет изменение данных в файле, что позволяет репликации DFS реплицировать только измененные блоки файла, а не весь файл.

Дополнительные сведения о переходе с репликации SYSVOL на репликацию DFS см. в этой статье.

Чтобы использовать репликацию DFS, следует создать группы репликации и добавить в них реплицируемые папки. На следующем рисунке представлены группы репликации, реплицируемые папки и элементы.

На этом рисунке видно, что группа репликации представляет собой набор серверов (элементов), между которыми выполняется репликация одной или нескольких папок. Реплицируемая папка — это папка, содержимое которой постоянно синхронизируется между всеми элементами. На рисунке есть две реплицируемые папки: Projects и Proposals. При любом изменении данных в каждой реплицируемой папке все такие изменения реплицируются между элементами группы репликации по установленным подключениям. Подключения между всеми элементами формируют топологию репликации. Создание нескольких реплицируемых папок в одной группе репликации упрощает процесс развертывания реплицируемых папок, так как топология, расписание и регулирование пропускной способности для группы репликации автоматически применяются к каждой реплицируемой папке. Чтобы развернуть дополнительные реплицируемые папки, нужно с помощью программы Dfsradmin.exe или по инструкциям мастера определить локальный путь и разрешения для новой реплицируемой папки.

Каждая реплицируемая папка имеет уникальные параметры, в том числе фильтры файлов и вложенных папок, что позволяет исключать разные файлы и вложенные папки для каждой реплицируемой папки.

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

Для управления репликацией DFS можно использовать оснастку управления DFS, команды DfsrAdmin и Dfsrdiag, а также скрипты с вызовом WMI.

Требования

До начала развертывания репликации распределенной файловой системы (DFS) необходимо настроить серверы следующим образом.

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

Использование репликации DFS на виртуальной машине в Azure протестировано для Windows Server. Однако существуют некоторые ограничения и требования, которые необходимо соблюдать.

Дополнительные сведения о начале работы с виртуальными машинами Azure см. на веб-сайте Microsoft Azure.

Установка репликации DFS

Репликация DFS входит в роль «Файловые службы и службы хранилища». Средства управления для DFS («Управление DFS», модуль репликации DFS для Windows PowerShell, а также средства командной строки) устанавливаются отдельно в составе средств администрирования удаленного сервера.

Репликацию DFS можно установить с помощью Windows Admin Center, диспетчера сервера или PowerShell, как описано в следующих разделах.

Чтобы установить DFS с помощью диспетчера серверов

Откройте диспетчер серверов, щелкните Управление, а затем нажмите кнопку Добавить роли и компоненты. Откроется мастер добавления ролей и компонентов.

На странице Выбор сервера выберите сервер или виртуальный жесткий диск автономной виртуальной машины, на который требуется установить DFS.

Выберите службы ролей и компоненты, которые следует установить.

Чтобы установить службу репликации DFS», на странице Роли сервера выберите Репликация DFS.

Чтобы установить только средства управления DFS, на странице Компоненты разверните узлы Средства администрирования удаленного сервера, Средства администрирования ролей, Средства файловых служб, а затем выберите Средства управления DFS.

Компонент Средства управления DFS устанавливает оснастку «Управление DFS», модули «Пространства имен DFS» и «Репликация DFS» для Windows PowerShell, а также средства командной строки, но не устанавливает на сервер никаких служб DFS.

Установка репликации DFS с помощью Windows PowerShell

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

Например, для установки средств распределенной файловой системы, включенных в компонент средств удаленного администрирования сервера, введите:

Для установки таких частей компонента средств удаленного администрирования сервера, как «Репликация DFS» и «Средства распределенной файловой системы», введите:

Источник

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

Используемый алгоритм основан на блокировке отпечатков пальцев в каждом файле локально на обоих концах партнеров репликации. Поскольку многие типы изменений файлов могут привести к перемещению содержимого файла без других значительных изменений (например, небольшая вставка или удаление в начале файла может привести к смещению остальной части файла с исходным содержимым) используемые блоки для сравнения, основаны не на статических произвольных точках разреза, а на точках разреза, определенных содержимым каждого сегмента файла. Это означает, что если часть файла изменяется по длине или блоки содержимого перемещаются в другие части файла, границы блоков для частей, которые не изменились, остаются фиксированными по отношению к содержимому, и, следовательно, серия отпечатков пальцев эти блоки не меняются, они просто меняют положение. Сравнивая все хэши в файле с хешами того же файла на другом конце пары репликации, RDC может определить, какие блоки файла были изменены, а какие нет, даже если содержимое файла было значительно изменено. перетасовали. Поскольку для сравнения больших файлов может потребоваться большое количество сравнений сигнатур, алгоритм рекурсивно применяется к хеш-наборам, чтобы определить, какие блоки хэшей были изменены или перемещены, что значительно сокращает объем данных, которые необходимо передать для сравнения файлов.

Более поздние версии Windows поддерживают межфайловый RDC, который находит файлы, похожие на реплицируемый, и использует блоки подобных файлов, которые идентичны реплицируемому файлу, для минимизации данных, передаваемых по глобальной сети. Межфайловый RDC может использовать блоки до пяти одинаковых файлов.

Содержание

Прекращение

Источник

Страж файлового дерева: развертываем распределенную файловую систему DFS

Содержание статьи

Назначение и возможности DFS

Эти разные корни

При доменном DFS вся информация о пространстве имен находится на контроллере
домена, к которому периодически обращается сервер DFS. Учитывая синхронизацию
между DFS в домене, которая становится все более сложной при каждом изменении
структуры, эти запросы могут быть узким местом в системе, поэтому в этом случае
также есть некоторые ограничения. Так в Win2k существовало ограничение на 16
корней для одного пространства имен. В Win2k3 это ограничение снято, так как
сервер DFS теперь может обращаться к любому DC, а не только к эмулятору PDC.
Второе ограничение доменных корней связано с тем, что вся структура хранится в
специальном объекте, который также необходимо дублировать на всех DC при любом
малейшем изменении в структуре DFS. В документации рекомендуется ограничивать
максимальный размер объекта 5-тью Мб, что приблизительно соответствует 5000
ссылкам (каталогам). Эта величина зависит от многих параметров, длины имени
ссылок, наличия и размера комментариев, которые также хранятся в этом объекте.
Но в среднем DFS редко когда превышает 50-100 ссылок, и после первоначальной
настройки она остается в основном статичной, а значит, часто дублироваться не
будет, и этих ограничений достигнуть просто не удастся. Кстати, в будущей
Windows 2008 ограничение в 5000 ссылок уже снято, но для этого все серверы
должны работать под управлением Longhorn. Для Standalone DFS рекомендованный
лимит ссылок на порядок выше и составляет 50000 ссылок.

Настройка DFS

Для примера настроим DFS на компьютере под управлением Win2k3 с SP2, все
настройки в SP1 аналогичны. В настройках DFS в R2 и Win2k есть некоторые
отличия, но не настолько глобальные, чтобы не разобраться самостоятельно. Все
управление распределенной файловой системой выполняется централизованно с
помощью оснастки MMC «Распределенная файловая система DFS«, которую можно
вызвать во вкладке «Администрирование» Панели управления Windows. С ее помощью
можно создавать и удалять корни, подключаться к любым корням DFS. Удобно, что в
одной вкладке может отображаться несколько корней DFS. В случае работы корня в «Mixed
mode domain DFS«, то есть когда реплики и корни DFS располагаются на компьютерах
под управлением разных версий Windows, управление DFS необходимо производить с
компьютера, работающего под Win2k3. Как вариант, можно установить пакет Win2k3 Administration Tools Pack (adminpak.msi), который лежит в свободном доступе на
сайте корпорации. В этом случае для управления можно использовать и компьютеры с
WinXP. Информацию по этому пакету найдешь по адресу

support.microsoft.com/kb/304718. Кроме этого, для работы с DFS также можно
использовать утилиты командной строки dfscmd.exe и dfsutil.exe. Последняя имеет
больше возможностей, но по умолчанию не включена в состав операционной системы,
чтобы ее использовать, необходимо установить пакет Win2k3 Support Tools. Обрати
внимание, что для успешной установки Support Tools требуется скачать два файла:
suptools.msi и support.cab.

Для создания нового корня вызываем оснастку, щелкаем мышкой по заголовку и в
контекстном меню выбираем «Создать корень» (New Root), как вариант, можно
выбрать аналогичный пункт в меню «Действие». Появляется Мастер создания нового
корня (New Root Wizard), следуем его подсказкам. На втором шаге выбираем тип
создаваемого корня (доменный или изолированный), указываем несущий домен и
сервер. После проверки соединения с выбранным сервером вводим имя корня. Обрати
внимание, как будет выглядеть UNC путь к новому корню, по умолчанию \\server\nameshare.
Так как на данный момент общего каталога не существует, на следующем шаге нужно
выбрать локальный каталог, который будет использоваться в качестве общего. Этот
каталог не содержит реальных данных, в нем будут находиться ссылки, указывающие
на физическое расположение данных. Мастер создает ресурсы, разрешающие чтение и
выполнение членам группы Пользователи. При необходимости следует скорректировать
разрешения. Теперь нажимаем кнопку Готово, новый корень появится в окне консоли.
Если сервер работает под управлением Win2k3, аналогичным образом создаем и
другие корни. С помощью команды Проверить статус (Check Status), вызываемую из
меню консоли или контекстного меню, можно проверить состояние реплики. Состояние
будет указано в одноименном столбце и рядом с именем появится кружок с отметкой.
Если она зеленого цвета, значит, все нормально. Для проверки можно зайти по
указанному UNC или использовать на локальном компьютере команду «net share» или
«net view computer_name» с удаленного. Команда «dfsutil /Root:\\server\share /View»
покажет информацию о DFS.

>dfsutil /Root:\\server.com\first /View
DFS Utility Version 5.2 (built on 5.2.3790.3959)
Domain Root with 0 Links [Blob Size: 284 bytes]
Root Name=»\\SERVER\first» Comment=»first Root» State=»1″ Timeout=»300″
Target Server=»GRINDERS» Folder=»first» State=»2″ [Site: Default-First-Site-Name]

После создания корня его можно опубликовать в Active Directory. Для этого в
контекстном меню выбираем Свойства, переходим на вкладку Публикация и
устанавливаем флажок «Опубликовать этот корень в Active Directory». Доменные
корни публикуются автоматически и в обязательном порядке.

Создание ссылок

После создания корня можно начинать подключать общие ресурсы. Для чего в том
же контекстном меню выбираем пункт Создать ссылку (New Link). В появившемся окне
«Новая ссылка», в поле «Имя ссылки», вводим имя ссылки, под которым она будет
доступна в DFS, затем чуть ниже UNC-путь к целевому каталогу (должен уже
существовать). Для поиска общих ресурсов можно использовать кнопку Обзор, чуть
ниже можно изменить время кэширования этой ссылки для клиентов DFS (по умолчанию
1800 сек). По окончании нажимаем кнопку ОК. Команда «dfsutil /view» должна
показать состояние всех подключенных ссылок и их свойства. Если в сети работает
несколько серверов, есть возможность добавить реплику, указывающую на
альтернативную ссылку. Реплика на корень или отдельный объект создается
аналогично, только в первом случае в контекстном меню выбираем пункт «Создать
корневую целевую папку», а во втором – «Создать папку».

Общие ресурсы, с которыми будет производиться репликация, должны
располагаться в разделах с файловой системой NTFS на компьютерах, работающих под
управлением серверных версий Windows от 2000 (лучше 2003). В поле «Путь к
целевой общей папке» появившегося окна вводим или при помощи кнопки Обзор
указываем общий ресурс, располагающийся на другом компьютере. В том случае если
для синхронизации информации между этими ресурсами планируется использовать
альтернативные программы (или синхронизация будет производиться вручную),
следует снять флажок «Добавить эту целевую папку к набору репликации» (Add this
target to the replication set). Нажимаем ОК, и появляется Мастер настройки
репликации (Configure Replication Wizard), который поможет выбрать
мастер-реплику и топологию репликации. На первом шаге указываем каталог, который
будет использоваться в качестве основного целевого, вся информация из этого
каталога затем будет скопирована в другую папку. Последняя должна быть пустой,
если в ней есть файлы, они будут скопированы во временный каталог, а затем
удалены. Если общий ресурс по каким-либо причинам не подходит для репликации
(например, расположен не в разделе с NTFS), он будет отмечен красным крестиком,
при попытке перейти к следующему шагу мастер предложит указать другую ссылку или
закончить работу.

Нажатием кнопки «Промежуточное хранение» (Staging Folder) можно изменить
расположение каталога, который будет использоваться для временного хранения
реплицируемых данных. По умолчанию этот каталог размещается в разделе, отличном
от того, на котором находится общий ресурс, связанный с DFS. Далее мастер
предложит выбрать топологию репликации. Необходимо будет указать один из
следующих вариантов:

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

После создания реплики для ссылки соответствующий ей значок в окне оснастки
изменится. В контекстном меню также появятся два новых пункта: Отобразить/Скрыть
статус репликации и Остановить репликацию. В поле статуса репликации может быть
один из трех результатов. Если процесс репликации завершен нормально, на значках
будут зеленые флажки. Красный крестик на значке реплики укажет, что она в данный
момент недоступна, в поле Состояние подпись изменится на Автономный. Если в
проверяемой ссылке недоступны лишь некоторые реплики, в значке появится желтый
восклицательный знак.

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

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

Для принудительной репликации информации, хранящейся на определенном сервере,
можно воспользоваться утилитой NtfrsUtl.exe, которая входит в состав пакета
Support Tools. Команда проста: «ntfrsutl poll /now server.com». Чтобы увидеть
установленные временные интервалы, через которые производится репликация,
следует ввести «ntfrsutl poll». Все установки доступны по команде «ntfrsutl sets
server.com».

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

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

Полную версию статьи
читай в декабрьском номере
Хакера!

Источник

About Remote Differential Compression

Remote Differential Compression (RDC) allows data to be synchronized with a remote source using compression techniques to minimize the amount of data sent across the network.

RDC is different from patching-oriented differencing mechanisms, such as Binary Delta Compression (BDC), that are designed to operate only on known versions of a single file. BDC requires the server to have copies of all versions of the file, and differences between each pair of versions are precomputed so that they can be distributed efficiently from a server to multiple clients.

RDC makes no assumptions about file similarity or versioning. Because differences between files are computed on the fly, RDC is ideally suited for synchronizing files that are different or have been updated independently.

RDC does not assume that the file data to be synchronized resides in physical files. Therefore, the RDC application is responsible for performing file I/O on behalf of the RDC library.

Because it is transport independent, RDC can be used with RPC, HTTP, or other desired transport mechanisms. The RDC application bears the responsibility for choosing the appropriate transport and performing any client or server authentication that is required to support the transport’s security model.

RDC is suitable for applications that move data across a wide area network (WAN) where the data transmission costs outweigh the CPU cost of signature computation. RDC can also be used on faster networks if the amount of data to be transferred is relatively large and the changes to the data are typically small.

Remote Differential Compression Algorithm Overview

RDC divides a file’s data into chunks by computing the local maxima of a fingerprinting function that is computed at every byte position in the file. A fingerprinting function is a hash function that can be computed incrementally. For example, if you compute the function F over a range of bytes from the file, B_i. B_j, it should then be possible to compute F(B_i+1. B_j+1) incrementally by adding the byte B_j+1 and subtracting the byte B_i. The range of bytes from the file, B_i. B_j, is called the hash window. The length of this window, in bytes, is called the hash window size.

The RDC library’s FilterMax signature generator «slides» the hash window across the entire file by adding the byte at the leading edge and subtracting the byte at the trailing edge of the window. Meanwhile, the generator continually examines the sequence of fingerprint function values over a given range of bytes, called the horizon size. If a fingerprint function value is a local maximum within the range, its byte position is chosen as a «cut point,» or chunk boundary.

After the file has been divided into chunks, the signature generator computes a strong hash value (an MD4 hash), called a signature, for each chunk. The signatures can be used to compare the contents of two arbitrarily different versions of a file.

Because the size of the signature file grows linearly with the size of the original file, comparing very large files can be expensive. This cost is reduced dramatically by applying the RDC algorithm recursively to the signature files. For example, if the original file size is 9 GB, the signature file size would typically be about 81 MB. If the RDC algorithm is applied to the signature file, the resulting second-level signature file size would be about 5.7 MB.

Remote Differential Compression Application Concepts

When developing an application that uses RDC, it is important to understand the following concepts and terminology.

In a typical RDC scenario, a server and a client have different versions of a file. (The terms client and server refer only to the computers’ roles in this scenario, not their operating systems.) The client’s copy of the file is called the seed file. The server’s copy is called the source file. The objective of the RDC application is to download the file updates to the client, which uses them to construct a target file that combines the updates from the source file with the unchanged contents from the seed file.

The RDC client and server each use the RDC library’s FilterMax signature generator to divide their copy of the file into chunks and compute a strong hash, called a signature, for each chunk of file data. Thus, the client has a list of signatures for the seed file, and the server has a list of signatures for the source file. These signature lists can be computed on the fly, or they can be precomputed.

The client initiates the RDC protocol by requesting the source signature list from the server. Then the client compares each source signature against the signatures in its own seed signature list. If a source signature matches a seed signature, the client already has the file data for that signature. If a source signature does not appear in the client’s list of seed signatures, the client must request the specified chunk (of file data) from the server.

The result of comparing the two signature lists is a needs list, which describes which chunks of file data, from where (seed or source file), are needed to construct the target file on the client computer. Each entry in the needs list is called a needs block.

The client iterates through each needs block and copies the specified chunk of the source or seed file data to the target file. Seed file data is copied locally. Source file data is downloaded from the server. The more similar the seed and source files are, the less network bandwidth is required to create the target file.

Источник