Самоучитель
системного администратора

10.1. Отказоустойчивые решения приложений

Для многих приложений разработчики предусмотрели собственные механизмы обеспечения высокой доступности. Обычно такие варианты решений наиболее эффективны на практике.

DHCP-сервер

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

Реализация DHCP на основе сервера Microsoft имеет серьезный недостаток, связанный с невозможностью создания горячего резерва данной службы для одного диапазона IP-адресов. Документы Microsoft предлагают для повышения отказоустойчивости два способа. Первый заключается в размещении службы DHCP на серверном кластере. В этом случае база адресов будет храниться на общем диске, а при выходе из строя одного сервера его работу "подхватит" второй сервер кластера. К сожалению, такое решение часто не доступно малым и средним организациям из-за высокой стоимости реализации отказоустойчивого кластера.

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

Иначе решается вопрос в Linux. Существует простой способ объединения двух или более серверов DHCP в отказоустойчивый пул. Для этого достаточно внести в конфигурацию DHCP-демона следующий блок настроек:

(Параметры пула следует уточнить по онлайновой документации).

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

DNS-серверы

DNS-серверы сегодня являются основой систем разрешения имен. В случае недоступности DNS работа систем в сети практически будет парализована.

Для обеспечения отказоустойчивости в технологиях DNS предусмотрено создание нескольких серверов: основного (primary) и одного или нескольких вторичных (secondary). Клиенту сообщаются адреса всех серверов DNS. При этом изменения могут вноситься только на основном сервере, остальные серверы синхронизируют данные с первичного.

В домене Windows серверы DNS реализованы на распределенной базе службы каталогов. Данный вариант позволяет распределять нагрузку: каждый сервер может выступать в роли первичного и вносить изменения в данные зоны. При этом основная проблема заключается в клиентах Windows. На практике в случае выхода из строя сервера DNS, который указан в качестве первой записи в настройке параметров IP-протокола рабочей станции Windows, последняя не может переключиться на использование второго сервера. Ситуацию спасает перезагрузка рабочей станции, но такое решение недопустимо для систем, требующих непрерывной работы.

Oracle Real Application Cluster (RAC)

Кластер Oracle RAC предназначен для обеспечения высокой доступности и распределения нагрузки приложений, работающих с сервером баз данных Oracle.

Oracle RAC — это кластерное решение для сервера баз данных с архитектурой общего кэша. В состав кластера может входить большое число серверов, при этом средства управления Oracle обеспечивают равномерное распределение нагрузки и перемещение вычислений в случае отказа одного из узлов.

Обратите внимание, что в отличие от описываемых в этой книге других кластерных решений, Oracle RAC загружает все серверы. Чем больше серверов, тем большая вычислительная мощность будет у распределенной базы данных.

Распределенная база 1С

Данное решение позволяет использовать программу 1С одновременно как в центральном офисе, так и в филиалах (складах, участках и т. п.). Решение основано на периодической синхронизации данных: изменения данных, внесенные на сервере, записываются в файл и передаются (например, по электронной почте) на другое рабочее место. Принятый файл автоматически обрабатывается, и данные вносятся в локальную копию.

Исходя из описанного принципа работы, понятны и ограничения: работа будет проходить без конфликтов, если организационными мерами разделить зоны ответственности операторов.

Дублирование данных

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

Зеркалирование серверов баз данных

Большинство приложений, работающих с систематизированными данными, хранит их на серверах баз данных или SQL-серверах. В связи с распространенностью для SQL-серверов разработаны решения, обеспечивающие дублирование данных одного сервера на другом.

Репликация данных SQL-серверов

Репликацию данных часто называют зеркалированием баз данных.

    Примечание

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

Можно назвать следующие преимущества собственных (для SQL-серверов) методов зеркалирования от, например, построения кластерной системы:

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

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

Как уже упоминалось, репликация может настраиваться в двух вариантах: активный-активный и активный-пассивный. Простейший случай, когда данные могут меняться только на одном сервере. Обычно проблем при таком варианте настроек не возникает.

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

Собственно настройка зеркалирования, например в MS SQL, не представляет сложностей. Предварительно рекомендуется сделать резервную копию данных и включить режим восстановления Full. После чего вызвать мастер создания подписки (в терминологии MS SQL основной сервер называют издателем, а сервер, на который копируются данные, — подписчиком) и следовать его указаниям (выбрать базу, указать подписчика, выбрать алгоритм и т. д.). Обязательно следует проверить состояние репликации и отсутствие очереди невнесенных изменений в журнале.

Снимки баз данных

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

Настройка клиентских подключений

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

Для автоматического переключения на резервный сервер прикладные программы должны быть запрограммированы специальным образом. В случае если для подключения к данным используются клиенты Native client или ADO.NET, то достаточно дописать второй сервер в строку подключения:

"Server=srv1; Failover_Partner=srv2; Database=db1"

Если разработчик использует клиентов, не поддерживающих переключение на резервный сервер, то решение должно быть предусмотрено в теле программы.

Распределенная файловая система

Подключение к общим сетевым ресурсам традиционно осуществляется с использованием следующего пути: \\сетевое_имя_сервера\имя_ресурса. Понятно, что при выходе из строя сервера-источника, сетевой ресурс становится недоступным.

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

Если говорить о Windows-системах, то это распределенная файловая структура (Distributed File System, DFS), реализованная на серверах Windows 2000 и старше. Для Linux-систем на сегодня автору не известно бесплатное решение, которое являлось бы лидером в данном классе. Можно упомянуть такие системы, как Ceph (клиентская часть включена в ядро Linux версии старше 2.6.34), XtreemFS, GlusterFS, GFS (Google File System), GPFS (General Parallel File System), Lustre и др. Все это вполне работоспособные решения, которые можно реализовывать в проектах. Соответствующая документация по настройке упомянутых файловых систем легко доступна в Интернете. При этом на Linux-системах легко можно настроить поддержку корней DFS (описание приведено далее в этой главе).

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

Создание DFS

Структура DFS напоминает дерево каталогов: на самом "верху" расположена одна точка входа, называемая корнем DFS, к которой подключены вложенные папки. Корень DFS представляет собой коллекцию ссылок на совместно используемые ресурсы, находящиеся на различных компьютерах сети. Следует заметить, что структура DFS-домена хранится в службе каталогов (AD).

Корень DFS может быть создан на любом сервере Windows 200х, причем на рядовых серверах возможно создание только одного корня DFS, тогда как в домене может поддерживаться несколько корней DFS (разными контроллерами).

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

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

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

    Примечание

    Конечно, можно воспользоваться и средствами автоматической репликации для такого переноса данных (создать пустую папку и добавить ее в репликацию). Но при большом объеме файлов ресурсов системы может не хватить для нормального завершения операции. Например, на практике автора система потребовала изменения настроек в реестре при попытке создания автоматической копии структуры папок документов объемом порядка 5 Гбайт.

Репликация DFS

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

Реплицируемые ресурсы должны быть расположены в папках с NTFS 5.0, поскольку система использует систему протоколирования этой файловой структуры для отслеживания изменений.

    Примечание

    Если необходимо использовать ограничения прав доступа к документам в папках DFS, то эти настройки следует применить только к папкам сервера (\\<имя_сервера>\ <имя_папки>). Иначе при создании ссылки DFS по новому месту репликации папка унаследует права родительской структуры.

По умолчанию репликация не включена. Чтобы организовать синхронизацию данных нескольких серверов, необходимо выделить соответствующие ссылки на ресурсы и выбрать команду Синхронизовать. При создании репликации требуется указать, какой ресурс будет являться основным (мастером). Когда первоначальная репликация завершится, все ссылки станут равнозначными: изменение в одном месте повлечет изменение по другой ссылке.

    Примечание

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

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

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

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

Настраивается график репликации в задаче AD Пользователи и компьютеры. Открыв оснастку, следует включить отображение дополнительных функций (Вид | Дополнительные функции) и найти необходимый корень DFS. Открыв его свойства на вкладке Набор репликации, нужно нажать кнопку Изменить расписание и отредактировать график (рис. 10.2).

Рис. 10.2.
Настройка графика репликаций DFS

Поддержка DFS в Linux-системах

На Linux-системах могут быть размещены корни DFS. Обеспечивает эту функциональность пакет Samba. Для того чтобы разместить корень DFS, достаточно в глобальной секции конфигурации Samba указать host msdfs = yes, а в определение совместно используемого ресурса добавить msdfs root = yes.

Поскольку корни DSF включают линки на другие совместно используемые ресурсы, то для их создания используется команда ln с указанием типа ресурса (msdfs):

Указание двух линков на один ресурс соответствует включению балансировки ресурсов.

В результате настройка корня DFS в конфигурации демона Samba будет выглядеть примерно так:

Корни DFS на Samba-сервере функционируют со всеми DFS-клиентами Windows (начиная от Windows 95).

Администратор должен назначить необходимые права доступа на папки с ресурсами и проконтролировать, чтобы на момент создания состав предполагаемых к балансировке папок был идентичным.

    Примечание

    Имена DFS-корням в Samba должны назначаться только в нижнем регистре. Если администратор преобразует в корень DFS существующий совместно используемый ресурс, то клиенты Windows в таком случае нуждаются в перезагрузке.


Рейтинг@Mail.ru