Данные можно реплицировать как в пределах локальной сети, так и через глобальную WAN сеть. Технология DFSR была спроектирована с расчетом на медленные WAN сети и работает столь же надежно через Интернет, как и в пределах одного здания.
Возникает вопрос- чем же эта функция по сути отличается от пространства имен DFS? Основное ее отличие- это наличие функции Алгоритма дифференциальной компрессии -- Remote differential compression algorithm (RDC), который применяется для репликации изменений. Основная идея этого алгоритма состоит в том, что реплицируются только измененные части файла. Например, если есть большой текстовый документ, и мы добавили несколько страниц в середину документа, то только эти несколько страниц и будут переданы по сети во время следующего сеанса синхронизации. Тем самым наиболее предпочтительней использовать репликацию DFS в медленных сетях, например для репликации одной (нескольких) папок между удаленно расположенными офисами с медленными каналами.
Репликация данных устойчива к проблемам с сетью. Если связь с удаленной машиной прервется, то репликация, разумеется, остановится. Но как только сеть будет снова работать, то репликация начнется с того места, где она прервалась.
Рассмотрим пошаговую инструкцию настройки репликации DFS. Первое что необходимо сделать - .
После этого создаем группу репликации (группа репликации - это набор серверов, именуемых членами, которые участвуют в репликации одной или нескольких реплицируемых папок. Реплицируемая папка - это папка, для которой поддерживается синхронизация на каждом из членов), для этого нажимаем правой кнопкой мыши на «Репликации»
, выбираем «Новая группа репликации…»
В типе реплицируемой группе репликации, рекомендую указать «Универсальная группа репликации»
, поскольку этот тип является более гибким в использовании в дальнейшем.
В следующем окне указываем имя группы репликации, пишем комментарий (по желанию) и смотрим тот ли домен используется (если в вашей организации используется несколько доменов).
Затем указываем сервера, которые будут входить в группу репликации (их может быть два и более).
В окне выбора топологии указываем тип топологии подключения, читая комментарии под каждым типом выберите, подходящий для вас и нажмите «Далее» . В данном примере используется «Полная сетка» .
В следующем окне выбираем время в которое будет выполняться репликация, в данном примере, я хочу чтобы репликация выполнялась круглосуточно, для этого я оставляю все по умолчанию.
В окне «Основной член репликации» указываем сервер на котором хранятся данные.
В следующем окне указываем папку, которую необходимо реплицировать.
Затем указываем папку на которую необходим реплицировать (на другом сервере).
После этого просматриваем все указанные настройки и если все указанно верно, нажимаем «Создать» .
Теперь в категории «Репликации» видим созданную репликацию Common .
Для того что бы запустить репликацию вручную, необходимо нажать на репликацию, в данном примере "Сommon" , затем зайти во вкладку "Подключения" и нажав правой кнопкой на любом подключении выбрать "Реплицировать сейчас" .
Чем хорошо использование пространства имен DFS? Тем, что все ресурсы для пользователей лежат в одном едином каталоге, который не привязан к именам серверов и все вопросы касающиеся физического расположения файловых ресурсов не касаются пользователей. Для них путь до рабочей папки всегда остается неизменным. Еще DFS позволяет использовать репликацию данных между несколькими сетевыми папками и равномерное распределение пользователей между файловыми серверами.
Есть некая программа, которая использует базу данных и файловую папку. В базе – пути до файлов, файлы соответственно, в сетевой папке.
Папка суммарно размером более терабайта, файлов много. Файлы являют собой сжатый звук и иногда имеют не маленькие размеры.
Работа программы критична для функционирования бизнеса, а значит есть необходимость в организации определенного запаса прочности на случай отказа оборудования или программного обеспечения.
Отказоустойчивость базы данных достигнута посредством использования функционала Always On Availability Groups на MS SQL 2012.
Отказоустойчивость сетевой папки проще всего достигнуть посредством репликации папки средствами DFS.
Отдельно хочу заметить, что коренную папку пространства имен DFS (DFS root) тоже необходимо защитить от отказа. В Windows Server 2008 и выше это достигается без использования технологий кластеризации. Просто после создания корня, добавляем еще один сервер пространства имен. Например – два контроллера домена, они же серверы пространства имен DFS. В случае перезагрузки или поломки одного из них, пользователи продолжат пользоваться пространством имен DFS и ни чего не заметят.
И так, создаем коренную папку DFS. Создаем виртуальную структуру папок для отделов компании. В папках отделов создаем папки указывающие на конечные файловые ресурсы на файловых серверах.
Теперь переходим к настройке репликации DFS для нужной нам папки.
Для включения репликации нам нужно заранее установить на сервера где будет находиться папка, роль “Репликация DFS” (DFS replication) и Компонент “Удаленное разностное сжатие” (Remote Differential Compression).
Затем, заходим в MMC консоль “Управление DFS” (DFS Management), выбираем папку и запускаем мастер репликации:
Указываем сервер:
Папку назначения:
Создаем группу репликации:
Выбираем сервер с основной копией данных (это актуально на время первичной репликации):
Выбираем топологию (если сервера два, то вариантов нет):
Можем выбрать скорость репликации и расписание: 
Заканчиваем:
Теперь ждем завершения первичной синхронизации.
И так, репликация настроена, потираем руки и в течение суток получаем жалобу, что папки на серверах отличаются, а значит репликация не работает.
Тратим кучу времени на сравнение папок и копируем вручную отличающиеся куски информации.
Собственно поэтому не любят использовать репликацию DFS.
Всё произошло потому, что ни кто не читал руководство настройке DFS. Как я сказал, папка занимает около терабайта. Там множество файлов, с которыми работают пользователи посредством программы.
Репликация папки происходит путем использования скрытого каталога DfsrPrivate\Staging, а там задействован механизм квот. Квота кэша репликации (Staging Folder) или “Промежуточной квоты” по умолчанию равна 4 гигабайта, что катастрофически мало при объемах данных указанных выше. Потому не работает репликация.
Как повышать? Гадать не наш метод. Смотрим что пишут на Technet .
2003 сервер – Staging quota должна быть размером в девять самых больших файлов в папке репликации.
2008 и 2008 R2 – Staging quota должна быть размером в 32 самых больших файлов в папке репликации.
Тут нам поможет PowerShell.
Пишем команду (заменяем <путь> на путь до нужной папки):
“{0:N0}” -f((get-childitem <ПУТЬ> -recurse | sort-object length -descending | select-object -first 32 | measure-object -property length -sum).sum /1gb)
Получаем суммарный объем 32-х самых больших файлов в гигабайтах, округленный до целого. Идем в настройки репликации:
Применяем. Как вариант, увеличиваем еще и квоту для конфликтов и удаленных файлов.
Не забываем повторить настройку для второго сервера.
P.S: В моём случае, DFSR оказалась не применима, так как приложение выбирает мастера из рабочих машин, где запущено, путём изменения определенного файла, который лежит в файловом хранилище, вместе с данными приложения. Файл обновляется чаще чем раз в секунду незначительной информацией. В файл пишется время и имя машины-мастера. В итоге файл обновляется одновременно на всех серверах и репликация его не проходит, так как DFSR не может определить какая версия файла правильная. В добавок несколько машин одновременно считают себя мастером операций, что приводит к проблемам в приложении.
Если бы разработчики придерживались идеи “сервер-свидетель” и вынесли файл на отдельный ресурс, не совмещая его с данными приложения, то смогли бы сэкономить десятикратно на упрощении аппаратной инфраструктуры.
В итоге придется держать папку с помощью MSFT-кластера или Fault Tolerance в VSphere.
Данные можно реплицировать как в пределах локальной сети, так и через глобальную WAN сеть. Технология DFSR была спроектирована с расчетом на медленные WAN сети и работает столь же надежно через Интернет, как и в пределах одного здания.
Возникает вопрос- чем же эта функция по сути отличается от пространства имен DFS? Основное ее отличие- это наличие функции Алгоритма дифференциальной компрессии -- Remote differential compression algorithm (RDC), который применяется для репликации изменений. Основная идея этого алгоритма состоит в том, что реплицируются только измененные части файла. Например, если есть большой текстовый документ, и мы добавили несколько страниц в середину документа, то только эти несколько страниц и будут переданы по сети во время следующего сеанса синхронизации. Тем самым наиболее предпочтительней использовать репликацию DFS в медленных сетях, например для репликации одной (нескольких) папок между удаленно расположенными офисами с медленными каналами.
Репликация данных устойчива к проблемам с сетью. Если связь с удаленной машиной прервется, то репликация, разумеется, остановится. Но как только сеть будет снова работать, то репликация начнется с того места, где она прервалась.
Рассмотрим пошаговую инструкцию настройки репликации DFS. Первое что необходимо сделать - .
После этого создаем группу репликации (группа репликации - это набор серверов, именуемых членами, которые участвуют в репликации одной или нескольких реплицируемых папок. Реплицируемая папка - это папка, для которой поддерживается синхронизация на каждом из членов), для этого нажимаем правой кнопкой мыши на «Репликации»
, выбираем «Новая группа репликации…»
В типе реплицируемой группе репликации, рекомендую указать «Универсальная группа репликации»
, поскольку этот тип является более гибким в использовании в дальнейшем.
В следующем окне указываем имя группы репликации, пишем комментарий (по желанию) и смотрим тот ли домен используется (если в вашей организации используется несколько доменов).
Затем указываем сервера, которые будут входить в группу репликации (их может быть два и более).
В окне выбора топологии указываем тип топологии подключения, читая комментарии под каждым типом выберите, подходящий для вас и нажмите «Далее» . В данном примере используется «Полная сетка» .
В следующем окне выбираем время в которое будет выполняться репликация, в данном примере, я хочу чтобы репликация выполнялась круглосуточно, для этого я оставляю все по умолчанию.
В окне «Основной член репликации» указываем сервер на котором хранятся данные.
В следующем окне указываем папку, которую необходимо реплицировать.
Затем указываем папку на которую необходим реплицировать (на другом сервере).
После этого просматриваем все указанные настройки и если все указанно верно, нажимаем «Создать» .
Теперь в категории «Репликации» видим созданную репликацию Common .
Для того что бы запустить репликацию вручную, необходимо нажать на репликацию, в данном примере "Сommon" , затем зайти во вкладку "Подключения" и нажав правой кнопкой на любом подключении выбрать "Реплицировать сейчас" .
Данные из удаленных офисов часто накапливаются и объединяются в центральном офисе. Аналогичным образом, можно реплицировать данные в удаленные офисы. Технология для этого называется „Репликация данных” и поддерживается продуктами Microinvest .
Основные положения
Репликация данных – современная технология управления данными в нескольких точках, при которой выстраивается общая система обработки и консолидации данных. В общих чертах, репликация это процесс, при котором данные записываются и сохраняются вверху отдельных серверов, но, с помощью управления информационным потоком, постигается систематизирование результатов в центральном сервере.
Виды репликации
Существует разделение репликаций по времени:
- Синхронная репликация
- Асинхронная репликация
Разделение репликаций по задачам:
- Репликация Master-Slave
- Репликация с равноправными серверами (Multi Master)
Синхронная репликация
Синхронная репликация проходит в реальном времени, информация мультиплицируется на всех серверах. Особенность синхронной репликации в том, что при потере связи между серверами никто не отражает изменения, цикл останавливается и процесс практически не может быть продолжен. Необходимо, чтобы все данные были на 100% одинаковык у всех серверов и клиентов. Этот режим не применяется в реальных торговых системах, т.к. зависим от связи.
Асинхронная репликация
Асинхронная репликация – это технология, при которой данные сохраняются в локальном сервере, который, со своей стороны, заботится об их передаче к следующему и передает только разницу. Это правильная технология для построения торговой системы, т.к. нет требований к бесперебойной связи, и данные передаются при первой возможности, но не обязательно в реальном времени.
Репликация Master-Slave
Репликация Master-Slave зависит от одного центрального Master сервера, который аккумулирует все данные и передает разницу к подчиненным Slave серверам. Таким образом, Master сервер всегда имеет актуальную копию данных, пока Slave серверы ждут изменений и подчиняются информации, отправленной от Master. Они актуализируют свои данные с опозданием. Преимущество этой технологии в простом выполнении, недостаток – записи всегда делаются в Master сервере, что требует постоянно связи с этим сервером. Если пропадет связь с центральным сервером, в системе не смогут выводиться новые операции, но можно будет делать справки. Эта технология реализована в MySQL сервере и часто используется в торговых системах. Обыкновенно, Master сервер стоит в центральном офисе фирмы.
Репликация с равноправными серверами
Репликация с равноправными серверами – прогрессивная технология, где каждый сервер является самостоятельным и, одновременно с этим, частью общей сети. При этой технологии так же существует центральный сервер, который управляет связью между остальными серверами. Преимущество технологии в полной независимости от связи в работе. Когда есть связь, данные передаются к центральному серверу. Подчиненные серверы передают только свою разницу и не загружают канал обмена данными. Когда не существует связи между серверами, данные аккумулируются локально для последующего объединения при восстановлении связи. Эта технология называется Transactional Merge и реализуется в MS SQL Server.
Репликация в Microinvest Склад Pro
Некоторые полезные ресурсы
- Документация по всем продуктам;
- Форум технической поддержки Microinvest , где Вы сможете быстро получить ответ на интересующий вопрос;
- Примеры автоматизации ресторанов и торговли на базе Microinvest в России и странах СНГ;
Репликация — одна из техник масштабирования баз данных. Состоит эта техника в том, что данные с одного сервера базы данных постоянно копируются (реплицируются) на один или несколько других (называемые репликами). Для приложения появляется возможность использовать не один сервер для обработки всех запросов, а несколько. Таким образом появляется возможность распределить нагрузку с одного сервера на несколько.
Существует два основных подхода при работе с репликацией данных:
- Репликация Master-Slave;
- Репликация Master-Master.
Master-Slave репликация
В этом подходе выделяется один основной сервер базы данных, который называется Мастером. На нем происходят все изменения в данных (любые запросы MySQL INSERT/UPDATE/DELETE). Слейв сервер постоянно копирует все изменения с Мастера. С приложения на Слейв сервер отправляются запросы чтения данных (запросы SELECT). Таким образом Мастер сервер отвечает за изменения данных, а Слейв за чтение.
В приложении нужно использовать два соединения — одно для Мастера, второе — для Слейва:
$master = mysql_connect("10.10.0.1", "root", "pwd"); $slave = mysql_connect("10.10.0.2", "root", "pwd"); # ... mysql_query("INSERT INTO users ...", $master ); # ... $q = mysql_query("SELECT * FROM photos ...", $slave );
# Используем два соединения — для Мастера и Слейва — для записи и чтения соответственно
Несколько Слейвов
Преимущество этого типа репликации в том, что Вы можете использовать более одного Слейва. Обычно следует использовать не более 20 Слейв серверов при работе с одним Мастером.
Тогда из приложения Вы выбираете случайным образом один из Слейвов для обработки запросов:
$slaves = [ "10.10.0.2", "10.10.0.3", "10.10.0.4", ]; $slave = mysql_connect($slaves , "root", "pwd"); # ... mysql_query("INSERT INTO users ...", $master); # ... $q = mysql_query("SELECT * FROM photos ...", $slave);
Задержка репликации
Асинхронность репликации означает, что данные на Слейве могут появится с небольшой задержкой. Поэтому, в последовательных операциях необходимо использовать чтение с Мастера, чтобы получить актуальные данные:
id = 7 ", $master ); $q = mysql_query("SELECT * FROM users WHERE id = 7 ", $master ); # ... $q = mysql_query("SELECT * FROM photos ...", $slave);
# При обращении к изменяемым данным, необходимо использовать Мастер-соединение
Выход из строя
При выходе из строя Слейва, достаточно просто переключить все приложение на работу с Мастером. После этого восстановить репликацию на Слейве и снова его запустить.
Если выходит из строя Мастер, нужно переключить все операции (и чтения и записи) на Слейв. Таким образом он станет новым Мастером. После восстановления старого Мастера, настроить на нем реплику, и он станет новым Слейвом.
Резервирование
Намного чаще репликацию Master-Slave используют не для масштабирования, а для резервирования. В этом случае, Мастер сервер обрабатывает все запросы от приложения. Слейв сервер работает в пассивном режиме. Но в случае выхода из строя Мастера, все операции переключаются на Слейв.
Master-Master репликация
В этой схеме, любой из серверов может использоваться как для чтения так и для записи:
При использовании такого типа репликации достаточно выбирать случайное соединение из доступных Мастеров:
$masters = [ "10.10.0.1", "10.10.0.2", "10.10.0.3", ]; $master = mysql_connect($masters , "root", "pwd"); # ... mysql_query("INSERT INTO users ...", $master);
# Выбор случайного Мастера для обработки соединений
Выход из строя
Вероятные поломки делают Master-Master репликацию непривлекательной. Выход из строя одного из серверов практически всегда приводит к потере каких-то данных. Последующее восстановление также сильно затрудняется необходимостью ручного анализа данных, которые успели либо не успели скопироваться.
Используйте Master-Master репликацию только в крайнем случае. Вместо нее лучше пользоваться техникой "ручной" репликации, описанной ниже.
Асинхронность репликации
В MySQL репликация работает в асинхронном режиме. Это значит, что приложение не знает, как быстро данные появятся на Слейве.
Задержка в репликации (replication lag) может быть как очень маленькой, так и очень большой. Обычно рост задержки говорит о том, что сервера не справляются с текущей нагрузкой и их необходимо масштабировать дальше, например техниками
