Главная Пресс-центр Статьи и публикации Резервирование сервера технологических данных - путь к созданию отказоустойчивых технологических серверов, Мир Компьютерной Автоматизации: ВКС, 2002/1

Резервирование сервера технологических данных - путь к созданию отказоустойчивых технологических серверов, Мир Компьютерной Автоматизации: ВКС, 2002/1

Е.Н. Новиков, Р.Р. Валеев, ЗАО «РТСофт»

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

 
  Поводом для создания этой статьи послужил реальный проект по созданию резервированного сервера сбора и хранения технологических данных. Основной целью разработки комплекса явилось снижение риска потери информации из-за возможных аппаратных и программных сбоев в работе сервера АСУ ТП.

 
  Необходимо особо отметить, что система создавалась не на пустом месте. Заказчиком уже была реализована достаточно сложная и многоуровневая система АСУ ТП (рис 1). На первом, нижнем, уровне данные собирались по разнообразным протоколам на коммуникационных серверах, в основу которых положена SCADA-система InTouch компании Wonderware. Затем данные передавались на следующий уровень для архивации в промышленной базе данных реального времени IndustrialSQL Server той же компании Wonderware. После этого архивная и оперативная информация становится доступной различным клиентским приложениям. Для доступа к данным используется язык SQL. При этом возможно как применение готовых пакетов клиентских приложений, поставляемых компанией Wonderware и третьими фирмами, так и пакетов, разработанных сторонними фирмами. Подробную информацию о пакете промышленной автоматизации FactorySuite2000 фирмы Wonderware, компонентами которого являются IndustrialSQL Server и InTouch, можно получить в [1].

 
  Таким образом, не было необходимости организовывать сбор технологических данных с нижнего уровня, и можно было сосредоточить все усилия на создании надежной и отказоустойчивой системы сбора и хранения собранной информации. Старая система была построена на платформе однопроцессорного сервера HP NetServer LH3, в котором использовался встроенный дисковый RAID-массив (RAID Redundant Arrays of Inexpensive Disks) 5-го уровня (далее в статье RAID) Подробнее работа RAID-массивов рассмотрена во врезке. Сервер управлялся операционной системой Windows NT 4.0.

 
 
 
  Несмотря на все достоинства сервера HP NetServer LH3, он не обеспечивал требуемой надежности работы, коэффициента готовности и производительности системы. Дело в том, что в этом сервере резервирование осуществлялось только на уровне дисков встроенного RAID-массива. Однако по мере создания и наращивания системы цена потери информации возрастала. Эта цена складывается из ряда факторов: стоимость потерянной информации, потеря прибыли, неудовлетворенность клиентов, стоимость технической поддержки и восстановления, и т. д. Открытость и удобство доступа к архивным данным IndustrialSQL-сервера позволила подключиться самым разнообразным отделам и службам, соответственно возросла потребность в постоянном доступе к ресурсам сервера. В результате проведенных исследований было решено строить систему сбора и хранения данных с резервированием на трех уровнях:

 
 
  • аппаратном;
 
 
  • системного ПО;
 
 
  • прикладного ПО.
 
  В основу была положена кластерная технология с применением в качестве аппаратной платформы серверов фирмы Hewlett Packard HP NetServer lp2000r. Каждый сервер имеет в своем составе два процессора PIII с тактовой частотой 1 ГГц.

 

Что такое кластер?

  Для начала давайте посмотрим на кластерную технологию построения вычислительных систем. Для тех, кто хорошо знаком с миром UNIX-подобных систем, термин «кластер» не нов. Эти системы обеспечивали кластеризацию вычислительных ресурсов ещё во времена юности Microsoft Windows. Впрочем, стоит отметить, что с появлением Windows NT кластеризация тоже использовалась, но для этого требовалось дополнительное программное обеспечение, такое как Microsoft Cluster Service. Ситуация изменилась с выходом в свет операционной системы Microsoft Windows 2000, точнее, серверной линейки этой операционной системы, где кластерная служба является компонентом системы.

 
  Так что же такое кластер? Одним из удачных определений, на наш взгляд, является следующее:

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

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

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

 
  А теперь поподробнее о том, что и как было реализовано в нашем проекте по созданию комплекса «резервированный сервер сбора и хранения технологических данных».

 

Уровень аппаратных средств

  Комплекс построен на 2 серверах HP NetServer LP2000r, объединенных в кластер и имеющих доступ к одному дисковому массиву (Используется RAID-массив 5-го уровня). Этот массив является внешним по отношению к обоим серверам и имеет дублирование питание. Доступ серверов к массиву осуществляется по интерфейсу Ultra SCSI-3, производительность которого достигает 160 Мбит/с.

 
  В данном комплексе используется контроллер RAID-массива HP NetRAID-4M, который управляет шестью SCSI-дисками. Один из шести дисков предназначен для организации кворума кластера. Этот диск необходим для организации «голосования» компонентов кластера по системе 2 из 3 (для работы кластера необходимо два работающих устройства из трех). Если один из серверов кластера исправен и диск кворума доступен, то кластер находится в рабочем состоянии. Если же исправны серверы, но возникают проблемы с диском кворума, то кластер, по-прежнему, исправен, однако корректного переключения с основного сервера на резервный в этом случае не произойдет (два устройства, сервер и кворумный диск, из трех неисправны). В этом случае, необходимо провести замену кворумного диска на исправный. Перед извлечением диска его необходимо корректно отключить из конфигурации общих дисковых ресурсов кластера и затем подключить новый диск.

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

 
 
  • по выделенной сети кластера;
 
 
  • через корпоративную сеть.
 
 
 
  Конструктивно комплекс выполнен в одном 19-дюймовом шкафу промышленного исполнения, что обеспечивает удобный доступ ко всем компонентам для замены, контроля и диагностики, а также оптимальный температурный режим.

 

Уровень системного программного обеспечения

  В качестве операционной системы используется Windows 2000 Advanced Server. Данная операционная система обеспечивает поддержку кластерной технологии на системном уровне.

 
  ПО Cluster Service Windows 2000 Advanced Server базируется на модели архитектуры кластера «с индивидуальным доступом». Эта модель характеризует способ, с помощью которого серверы в кластере управляют локальными и общими устройствами и ресурсами кластера и используют их. Ресурсы, разделяемые кластером, такие как общий дисковый массив и сетевой адрес, в каждый конкретный момент находятся в собственности и под управлением только одного сервера. Второй сервер может находиться в горячем резерве или же выполнять свои собственные приложения. В нашем проекте резервный сервер не несет полезной нагрузки в момент нахождения в горячем резерве, так как основная его задача обеспечить перевод ресурсов кластера с основного сервера в случае сбоя последнего.

 
  Модель с индивидуальным доступом облегчает управление дисковыми устройствами и стандартными приложениями. Эта модель не требует специальных кабельных соединений или специальных приложений и дает Cluster Service возможность поддерживать стандартные приложения и дисковые ресурсы на базе Windows 2000.

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

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

 
  ПО Cluster Service управляет виртуальным сервером как группой ресурсов, и группа ресурсов для каждого виртуального сервера содержит в том числе IP- адрес и сетевое имя, сопоставленное этому адресу.

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

 
 
 
  В случае сбоя приложения или отказа сервера Cluster Service перемещает всю группу ресурсов виртуального сервера на другой узел кластера (Рис. 3). При возникновении подобного сбоя клиент обнаружит отказ в сеансе работы с приложением и попытается подключиться вновь тем же самым образом, каким был подключен. И у него будет возможность успешно это выполнить, поскольку Cluster Service просто перенесет опубликованный адрес IP виртуального сервера на один из работающих узлов в кластере в рамках действий по восстановлению. Сеанс клиента сможет заново установить подключение к приложению, при этом ему не нужно знать, что физически оно теперь помещается на другом узле кластера. Ниже дан перечень служб и приложений, подлежащих переносу с одного сервера кластера на другой, в случае сбоя или отказа основного сервера (не указаны системные сервисы).

 
  Службы обеспечивающие работу MSSQL Server:

 
 
  • MSSQLServer.
 
  Службы приложений Wonderware:

 
 
  • Wonderware Logger;
 
 
  • InSQL Control (эта служба обеспечивает старт и останов всех служб InSQL-сервера).
 
  Таким образом, перерыв в архивации может возникнуть по двум причинам:

 
 
  • Поскольку данные, собираемые соответствующей подсистемой IndustrialSQL сервера, сначала поступают в специальный буфер в оперативной памяти, а затем, через 60 секунд, сохраняются на диске, то, в случае аварийного останова сервера, будет потеряна информация не более чем за последние 60 секунд.
 
 
  • В момент запуска вышеуказанных сервисов на резервном сервере сбор данных и архивация проводиться не будут. Длительность запуска сервисов не более трех минут.
 
  Суммарное время потери данных составляет не более 4 минут, что соответствует требованиям, указанным в техническом задании. Временные характеристики получены экспериментальным путем.

 
  Для хранения данных IndustrialSQL-сервера и таблиц MSSQL-сервера в нашем проекте используется дисковый RAID-массив, являющийся общим ресурсом для обоих серверов, входящих в кластер. Благодаря использованию общего дискового массива обеспечивается:

 
 
  • целостность данных, независимо от того, какой из серверов кластера является активным в данный момент, так как в каждый момент времени только службы активного сервера имеют доступ к данным на RAID-массиве;
 
 
  • единая конфигурация MSSQL и IndustrialSQL обоих серверов кластера.
 
  Обнаружение и предотвращение отказов главные преимущества, предоставляемые ПО Cluster Service. Когда в кластере отказывает узел или приложение, Cluster Service может ответить на это перезапуском отказавшего приложения или перераспределением нагрузки отказавшей системы между работающими узлами кластера. Обнаружение и предотвращение отказов Cluster Service включает двустороннее восстановление после отказов и восстановление приложения после отказа. ПО Cluster Service динамически обнаруживает отказы отдельных ресурсов или всего узла и перезапускает ресурсы приложений, ресурсы данных и файловые ресурсы на доступном работающем сервере кластера. Это позволяет сохранять высокую доступность для пользователей и клиентских приложений таких ресурсов, как базы данных, общие файлы и приложения.

 
  В Cluster Service предусмотрены два различных механизма обнаружения отказов:

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

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

 
  Обнаружение отказов ресурсов  
  Для обнаружения отказов ресурса и восстановления после этих отказов совместно работают диспетчер восстановления и мониторы ресурсов. Мониторы ресурсов следят за состоянием ресурсов, периодически опрашивая ресурсы с использованием библиотек ресурсов. Опрос проводится в два этапа: коротким запросом LooksAlive ( «с виду живой») и более долгим и детальным запросом IsAlive ( «действительно живой»). Когда монитор ресурсов обнаруживает отказ ресурса, он извещает об этом диспетчер восстановления и продолжает следить за ресурсом.

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

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

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

 

Заключение

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

 
 
  • на аппаратном (использование высокопроизводительных и надежных серверов и дисковых RAID-массивов фирмы Hewlett Packard),
 
 
  • на уровне операционной системы (Cluster Service Windows 2000 Server),
 
 
  • на уровне приложений (IndustrialSQL сервер).
 
  Все оборудование и системное программное обеспечение имеет сертификаты производителей (Hewlett-Packard и Microsoft), подтверждающие возможность использования в системах с поддержкой резервирования, что, несомненно, повышает надежность созданного комплекса.

 
  В результате, нами был создан программно технический комплекс системы сбора и хранения данных, удовлетворяющий требования заказчика по надежности, гарантированному доступу к архивным данным и возможности дальнейшего расширения. Задачи, поставленные при создании этого комплекса, все чаще встают при проектировании систем АСУТП, поэтому опыт, накопленный при выполнении проекта, будет полезен в дальнейшем.

 

Литература

  Куцевич Н. А. «IndustrialSQL база данных реального времени», Мир компьютерной автоматизации, 3, 1999.

 
  Куцевич Н. А. «FactorySuite 2000 комплексный инструментарий следующего поколения», PCWeek, 42, 1998.

 
  IndustrialSQL7.1 Server Administrator Guide.

 
 

 
  Тел. (095) 742-68-28

21.04.2014