Опытные мелочи-10, или «DFS и отказоустойчивость»

    image Продолжение «опытных мелочей». Предыдущие части можно почитать тут.
    Сегодняшний выпуск будет выпуск-обещание. Выполняя то, что обещал, я расскажу как с помощью DFS можно сделать интересную вещь. Это будет, конечно, не полноценная отказоустойчивость файловых данных, но что-то похожее на онлайн-бэкап, как минимум.


    Для начала повторю свои эмпирические убеждения о том, что не стоит устраивать файловый кластер, средствами DFS. Не для этих целей DFS создавалась. И чтобы расставить все точки над I вот мои аргументы:
    • В механизме работы DFS нет способа определить какая реплика файла является правильной.
    • При наличие нескольких реплик в одном сайте, DFS сама выбирает куда отправить пользовательский запрос, на реплику А или на реплику Б, ориентируясь при этом, судя по всему по загруженности сервера-хранилища. (Есть некоторые настройки порядка выбора реплики, но сути они не меняют: если в пределах сайта несколько реплик, то выбор конкретной из них может быть непредсказуем.
    • Эти нюансы позволяют смоделировать ситуацию, когда пользователь А обратится на реплику А и будет работать там с данными, а пользователь Б обратится на реплику Б и будет там работать с данными. В результате будут образованы ДВЕ ветки измененных данных, и DFS не будет знать какие данные правильные, а просто выберет те, которые последние по времени изменения. Можете себе представить что будет твориться в этой ситуации с файловым хранилищем, или того хуже, с базами данных
    • Ну и стоит отметить то, что репликация открытых файлов может задерживаться на неопределенное время. Самый простой пример — это пользователи, которые не закрывают офисные документы уходя домой.

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

    Можно построить на базе DFS своего рода онлайн-реплику, которая не будет работать основное время (а значит бОльшая часть проблем с синхронизацией данных не проявится), и которую можно будет включить, в случае отказа основной реплики.
    Выглядеть это может например вот так:image
    Здесь (на примере папки Department) создано две реплики одной папки, настроена группа репликации и задания репликации (все это делается мастером настройки и не вызовет у вас никаких проблем). Самый смак идеи в том, что одна из ссылок на сервера хранилища — отключена, т.е. реплика есть, репликация между серверами проходит как задано, но пользователи, обращающиеся через DFS в эту папку будут перенаправляться исключительно на первый, активный сервер.

    Второй сервер будет реплицировать данные по мере возможности, и будет как бы «на подхвате». В случае какой-то нештатной ситуации, можно будет произвести рокировку и включить линк уже на второй сервер, а линк на первый — выключить и пользователи снова попадут к своим родным данным, которые будут настолько актуальны, насколько DFS-репликация была способна сделать (на практике это от полной актуальности, т.е. состояния 0,5-2 сек давности, до 2-3 дней в случае с открытыми файлами, которые не реплицируются пока не будут закрыты, т.е. разблокированы приложением).

    Казалось бы здорово! Срочно побежали делать эту супер-систему! Но кроме всех хороших моментов, есть и не очень хорошие:
    • Потребуется минимум двукратный запас по месту на каждом томе для скрытой папки DfsrPrivate (служебная папка для репликации данных). Учитывая двойные расходы на хранение данных (на обоих серверах хранится одно и то же, причем в один момент времени работают только с одним) это уже не выглядит столь заманчивым, т.к. места под такую отказоустойчивость нужно отвести минимум в 4 раза больше чем самих данных
    • У пользователей иногда могут наблюдаться тормоза в момент работы с DFS. Точных причин мне понять так и не удалось, но всегда это было следствием наличия нескольких реплик, и ненулевой нагрузки на сеть. Как только реплика оставалась одна — тормоза становились исчезающе малы. Это совершенно точно не было связано с работающей репликацией, очень было похоже на какие-то проблемы с резолвингом DFS-имен.
    • Чтобы пользователи увидели новую реплику, на которую вы их переключили в «час Х», им скорее всего придется перегрузить компьютеры, в противном случае они будут пытаться идти по старому пути.
    • Автоматическое переключение на работающую реплику — я не сделал, т.к. стандартных методов для этого нет, а писать чудо-скрипт в ситуации когда сама технология имеет столько минусов, показалось мне безрассудством.

    Как видите в описанном примере кроме довольно весомых плюсов. есть также и немаленькие минусы, поэтому расставляйте приоритеты, взвешивайте ЗА и ПРОТИВ, и решайте сами как поступать в вашей конкретной ситуации.

    Кстати, по словам знающих, в среде Windows Server 2008 (R2) DFS (и особенно ее служба репликации) была кардинально улучшена, и, возможно, часть проблем была успешно решена. Попробуйте — может быть там предложенная схема будет работать куда лучше.

    Продолжение следует.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 8

      +1
      1) У dfs есть выбор приоритетного сервера
      2) Опытным путем установлен лучший вариант:

      Включаются оба конечных объекта. репликация настраивается одностороняя. второй(резервный) сервер ставится в режим только-чтение.

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

      Ну и как бонус, со второго резервного сервера можно настроить бекап, не затрагивая производительность первого.
        0
        Эти нюансы позволяют смоделировать ситуацию, когда пользователь А обратится на реплику А и будет работать там с данными, а пользователь Б обратится на реплику Б и будет там работать с данными. В результате будут образованы ДВЕ ветки измененных данных, и DFS не будет знать какие данные правильные, а просто выберет те, которые последние по времени изменения. Можете себе представить что будет твориться в этой ситуации с файловым хранилищем, или того хуже, с базами данных

        Вообще у баз данных есть свои механизмы репликации, потому вряд ли кто-то надумает использовать DFS для этого, да и микрософт сама позиционирует DFS для хранения данных пользователей http://technet.microsoft.com/en-us/library/cc779627%28WS.10%29.aspx, а не файлов БД.

        В подобной ситуации файл будет скопирован в папку ConflictandDeleted и на моей памяти я ни разу конфликтов не видел (хотя это и не означает что их может не быть). Так что информация не совсем теряется, но чтобы достать её без помощи системного администратора, надо постараться (хотя я этот вопрос глубоко не разбирал).

        Сам я DFS использовал для поддержания консистентности данных (профили и личные файлы пользователей) в разных отделениях (т.е. физически в разных местах), почти никаких проблем не встретил (пришлось добавить ключ в реестр чтобы система начала видеть правильно обновление файлов в шаре). Всё устроило.
          0
          Я несколько раз встречал людей, которые клали 1С базы(DBF) в DFS и реплицировали их. А потом удивлялись чудесам которые начинали там происходить.
          У вас не было конфликтов и проблем, т.к. вы использовали репликацию для разных отделений (могу ручаться что и для разных сайтов в домене), и это правильно. DFS для этого и создавалась.
          Здесь же конфликты более вероятны, т.к. две реплики находятся в пределах одного сайта, а значит они практически равноправны для DFS.
            0
            Да у меня серверы в разных сайтах были.

            Но для отказоустойчивости в пределах одного сайта есть ведь кластеризация, почему бы её не использовать, это ведь более логично?
              0
              да. это единственный правильный выход.
              Но не забываем про редакции серверов которые кластеризацию поддерживают и цены на них.
              Да я и не предлагаю кластеризацию — это так… отчасти онлайн-бэкап, отчасти игрища с DFS.
              Все равно автоматически не переключается, будет простой, ну и куча других минусов — см пост.
              Я лично такое не использую, но решил описать как вариант, который дешев и прост в настройке, тем более, что ранее я обещал это сделать (написать) — вот и написал :)
          0
          Если я ничего не путаю, то размеры подпапок DfsrPrivate можно настраивать… Staging и ConflictAndDeleted уж точно. Это хоть как-то уменьшит потребности в дисковой емкости.
            0
            Как известно, помимо синхронизации, DFS дает большой огромный плюс в получении сетевого ресурса непривязанного к конкретному серверу/имени.

            Даже только из-за этого стоит поднять DFS. Т.к. контроллера обычно 2, то поднимая на них корень DFS мы практически ничего не теряя в надежности (правда, чуть теряя в скорости первого доступа к ресурсу) получаем единое дерево сетевых ресурсов. На хабре уже была статья на этот счет. Мы этим подходом пользуемся еще с 2000 винды (правда, со своими ньюансами).

            + На серверах нужны сервисные утилитки (стандартные для всех, вроде sysinternals) — для этого dfs подходит идеально. изменил на одном — изменилось на всех (+распределенное хранилище логов серверов получается).
              0
              вы не поверите, но с этого все и началось. И именно там поднялся вопрос о плюсах и минусах синхронизации, который плавно переродился в этот пост.

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

            Самое читаемое