Учебные пособия / Усков М.В., Гольдштейн А.Б., Кисляков С.В. Программирование систем управления ИКС (черновик)
.pdfСреди типовых проблем при интеграции выделяется задача одинакового восприятия некоторых константных значений – типов, групп, категорий и прочих классификаторов. Если ключи одинаковых значений при взаимодействии не совпадают, это полностью нарушает смысловую нагрузку сообщений и приводит к неверному поведению систем.
Наиболее удобен случай, когда взаимодействующие информационные системы опираются на единую (общую) систему нормативно-справочной информации, хранящую справочники всех ключевых значений. Если подобного централизующего элемента нет, или применение одинаковых ключей невозможно по технологическим причинам, используется методика синхронизации ключей (идентификаторов), иногда называемая «маппинг». Это определение соответствия данных между двумя потенциально различными объектами (моделями данных). Каждая из взаимодействующих систем имеет на своей стороне таблицу соответствия «своих» и «чужих» идентификаторов (как для бизнес-объектов, так и для справочных значений). Процесс включает в себя преобразование данных между источником и получателем в соответствии с таблицей соответствия, в зависимости от происхождения данных.
4.4. Интеграционная шина как элемент построения инфраструктуры взаимодействия
Использование очередей сообщений в основе платформы интеграции приложений существенно усложняется при увеличении числа интегрируемых систем, каждая из которых может реализовывать очереди по-своему. Желание унификации взаимодействия привело к поискам обобщённой архитектуры интеграции. Когда появился метод межплатформного взаимодействия на основе Web-сервисов, родился и новый подход к организации основы для интеграции — сервисная шина уровня предприятия (Enterprise Service Bus, ESB).
Основной принцип сервисной шины [51] — концентрация обмена сообщениями между различными системами через единую точку, в которой, при необходимости, обеспечивается транзакционный контроль, преобразование данных, сохранность сообщений. Все настройки обработки и передачи сообщений предполагаются также сконцентрированными в единой точке, и формируются в терминах служб, таким образом, при замене какойлибо информационной системы, подключённой к шине, нет необходимости в перенастройке остальных систем.
«Сервисная шина предприятия» является объединяющим термином для набора возможностей, которые в разных реализациях трактуются несколько различными способами. Как правило, выделяются следующие ключевые возможности:
поддержка синхронного и асинхронного способа вызова служб;
51
использование защищённого транспорта, с гарантированной доставкой сообщений, поддерживающего транзакционную модель;
статическая и алгоритмическая маршрутизация сообщений;
доступ к данным из сторонних информационных систем с помощью готовых или специально разработанных адаптеров;
обработка и преобразование сообщений;
разнообразные механизмы контроля и управления (аудиты, протоколирование).
Определенные программные продукты обычно также содержат готовые адаптеры для соединения с конкретным прикладным программным обеспечением, а также могут включать API для создания таких адаптеров.
Для интеграции корпоративных приложений в современные BPMS активно применяются технологии сервисно-ориентированной архитектуры
(Service-Oriented Architecture, SOA). SOA – это подход к организации си-
стем, в которых сервис – некоторый абстрактный ресурс, имеющий имя, способный выполнять некоторые функции на основе получаемой им информации, причем выполнять их на заданном уровне безопасности и по определенным правилам. Сервисный подход отличается тем, что между модулями взаимодействующих информационных систем нет навсегда установленной жесткой связи, она заменяется легко модифицируемой слабой связанностью компонентов. Слабая связь между компонентами предполагает возможность ее трансформации в процесс функционирования системы, то есть внутренняя архитектура системы может видоизменяться и настраиваться. Можно «на ходу» из набора готовых ресурсов собирать ту конфигурацию, которая необходима на данный момент.
Основная задача SOA - обеспечение стандарта на интерфейсы и среду, в которой эти интерфейсы могут публиковаться и вызываться, а BPMS – обеспечение смысловой нагрузки и правила, согласно которым системы должны передавать друг другу информацию и управление. Наиболее распространенная реализация SOA – это спецификация веб-сервисов, которые базируются на наборе открытых стандартов HTTP (транспорт), SOAP (обмен сообщениями), WSDL (описание интерфейсов) и UDDI (публикация и поиск сервисов). Назначение технологии веб-сервисов состоит в обеспечении доступа к функциям прикладных систем через сеть вне зависимрсти от используемой платформы. В ашем контексте веб-сервис можно определить как автономный стандартизированный программный компонент с описанными на языке XML внешними интерфейсами. Признанным отраслевым стандартом описания веб-сервисов является основанный на XML язык
WSDL (Web Services Description Language). Стандарт WSDL позволяет описывать ключевые элементы интерфейса веб-сервиса: его имя, поддерживаемые операции, исключения, входные и выходные данные; а также информацию, касающуюся вызова сервиса (связывания): протокол, способ
52
передачи входных и выходных данных. Упрощенно принцип использования веб-сервисов показан на рисунке 30.
Рисунок 30. Принцип использования веб-сервисов.
Важным отличием ESB от шины сообщений предприятия стала поддержка дополнительных методов взаимодействия между приложениями и хабом, прежде всего, протокола SOAP.
Появились новые продукты, поддерживающие SOAP, в старые продукты такая поддержка была добавлена, однако они не стали дешевле, а значит, доступнее своих предшественников. Поддержка «хабом» интеграционной системы широкого спектра методов взаимодействия и протоколов облегчает и удешевляет интеграцию. Но не в разы, а на проценты — что уже неплохо с учетом стоимости интеграционных проектов.
SOA — это концепция построения информационных систем путем представления их в виде сервисов, доступных для «наружного» использования, в том числе путем их интеграции с другими приложениями. SOA дает теоретическую возможность выбирать компоненты от разных поставщиков по принципу «лучший в классе» и объединять их в информационную систему предприятия [51].
5. РЕАЛИЗАЦИЯ НЕФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ К ПО ЭКСПЛУАТАЦИИ СЕТЕЙ СВЯЗИ
5.1. Многопользовательский доступ к данным
Абсолютно любая база данных годна к использованию только тогда, когда ее состояние соответствует состоянию предметной области. Такие состояния называют целостными. Очевидно, что при изменении данных БД
53
должна переходить от одного целостного состояния к другому. Однако, в процессе обновления данных возможны ситуации, когда состояние целостности нарушается.
Для того чтобы предотварить такие ситуации, в СУБД появляется понятие транзакции - атомарного действия над БД, переводящего ее из одного целостного состояния в другое целостное состояние. Другими словами, транзакция - это последовательность операций, которые должны быть или все выполнены или все не выполнены (все или ничего).
Методом контроля за транзакциями является ведение журнала, в котором фиксируются все изменения, совершаемые транзакцией в БД. Если во время обработки транзакции происходит сбой, транзакция откатывается - из журнала восстанавливаеться состояние БД на момент начала транзакции.
Стандарт SQL определяет, что транзакция начинается с первого SQLоператора, инициируемого пользователем или содержащегося в прикладной программе. Все последующие SQL-операторы составляют тело транзакции. Транзакция завершается одним из возможных способов [52]:
1.оператор COMMIT означает успешное завершение транзакции, все изменения, внесненные в базу данных делаются постоянными
2.оператор ROLLBACK прерывает транзакцию и отменяет все внесенные ею изменения
3.успешное заверешение программы, инициировавшей транзакцию, означает успешное завершение транзакции (как использо-
вание COMMIT)
4.ошибочное завершение программы (или сетевого соединения) прерывает транзакцию (как ROLLBACK)
Ксожалению, описанный механизм транзакций гарантирует обеспечение целостного состояния базы данных только в том случае, когда все транзакции выполняются последовательно, т.е. в каждую единицу времени активна только одна транзакция. Если работу с данными ведут одновременно несколько пользователей, вряд ли их устроит такой способ организации обработки запросов, т.к. это приведет к увеличению времени реакции системы. В то же время, если одновременно выполняются две транзакции, могут возникнуть следующие ошибочные ситуации:
Грязное чтение (Dirty Read) - транзакция Т1 модифицировала некий
элемент данных. После этого другая транзакция Т2 прочитала содержимое этого элемента данных до завершения транзакции Т1. Если Т1 заврешается операцией ROLLBACK, то получается, что транзакция Т2 прочитала не существующие данные.
Неповторяемое (размытое) чтение (Non-repeatable or Fuzzy Read) -
транзакция Т1 прочитала содержимое элемента данных. После этого другая транзакция Т2 модифицировала или удалила этот элемент. Если Т1 прочи-
54
тает содержимое этого элемента занова, то она получит другое значение или обнаружит, что элемент данных больше не существует.
Фантом (фиктивные элементы) (Phantom) - транзакция Т1 прочи-
тала содержимое нескольких элементов данных, удовлетворяющих некому условию. После этого Т2 создала элемент данных, удовлетворяющий этому условию и зафиксировалась. Если Т1 повторит чтение с тем же условием, она получит другой набор данных.
Как уже было сказано, ни одна из этих ситуаций не может возникнуть при последовательном выполнении транзакций. Отсюда возникло понятие сериализуемости (способности к упорядочению) параллельной обработки транзакций. Т.е. чередующееся (параллельное) выполнение заданного множества транзакций будет верным, если при его выполнении будет получен такой же результат, как и при последовательном выполнении тех же транзакций.
Принудительное упорядочение транзакций обеспечивается с помощью механизма блокировок. Суть этого механизма в следующем: если для выполнения некоторой транзакции необходимо, чтобы некоторый объект базы данных не изменялся непредсказуемо и без ведома этой транзакции, такой объект блокируется. Основными видами блокировок являются:
блокировка со взаимным доступом, называемая также S-
блокировкой (от Shared locks) и блокировкой по чтению.
монопольная блокировка (без взаимного доступа), называемая также X-блокировкой от (eXclusive locks) или блокировкой по записи. Этот режим используется при операциях изменения, добавления и удаления объектов.
При этом:
если транзакция налагает на объект X-блокировку, то любой запрос другой транзакции с блокировкой этого объекта будет отвергнут.
если транзакция налагает на объект S-блокировку, то
1.запрос со стороны другой транзакции с X-блокировокй на этот объект будет отвергнут.
2.запрос со стороны другой транзакции с S-блокировокй этого
объекта будет принят.
Транзакция, запросившая доступ к объекту, уже захваченному другой транзакцией в несовместимом режиме, останавливается до тех пор, пока захват этого объекта не будет снят.
К сожалению, применение механизма блокировки приводит к замедлению обработки транзакций, поскольку система вынуждена ожидать пока освободятся данные, захваченные конкурирующей транзакцией. Решить эту проблему можно за счет уменьшения фрагментов данных, захватываемых транзакцией. В зависимости от захватываемых объектов различают несколько уровней блокировки:
55
блокируется вся база данных - очевидно, этот вариант неприемлим, поскольку сводит многопользовательский режим работы к однопользовательскому
блокируются отдельные таблицы
блокируются страницы (страница - фрагмент таблицы размером обычно 2-4 Кб, единица выделения памяти для обработки данных системой)
блокируются записи
блокируются отдельные поля
Способ реализации блокировок зависит от конкретной реализации СУБД. Применение СУБД под существенной пользовательской нагрузкой требует тщательного изучения данного механизма программистом, чтобы сохранить высокие эксплуатационные характеристики информационной системы.
В ходе существенного развития технологий распределенных вычислений и параллельной обработки возникли распределенные системы управления базами данных и параллельные системы управления базами данных. Именно эти системы становятся доминирующими инструментами для создания приложений интенсивной обработки данных.
Распределенная база данных (DDB – distributed database) [53] – это со-
вокупность логически взаимосвязанных баз данных, распределенных в компьютерной сети. Распределенная система управления базой данных определяется как программная система, которая позволяет управлять распределенной базой данных таким образом, чтобы ее распределенность была прозрачна для пользователей. Первая особенность такой БД - система состоит из (возможно, пустого) множества узлов приема запросов (query site) и непустого множества узлов данных (data site). Узлы данных обладают средствами для хранения данных, а узлы приема запросов – нет. В узлах приема запросов лишь выполняются программы, реализующие пользовательский интерфейс для доступа к данным, хранящимся в узлах данных. Вторая особенность состоит в том, что узлы логически представляют собой независимые компьютеры. Следовательно, у такого узла имеется собственная основная и внешняя память, установлена собственная операционная система (может быть, одна и та же на всех узлах, а возможно, и нет) и имеется возможность выполнять приложения. Узлы связаны компьютерной сетью, а не входят в мультипроцессорную конфигурацию. Важно подчеркнуть слабую связанность процессоров, которые обладают собственными операционными системами и функционирует независимо.
Распределенная транзакция — это транзакция, затрагивающая несколько ресурсов. Для фиксации распределенной транзакции все участники должны гарантировать, что любое изменение данных будет постоянным. Изменения должны сохраняться даже в случае фатального сбоя си-
56
стемы или других непредвиденных событий. Если хоть один из участников не сможет предоставить такую гарантию, вся транзакция завершится с ошибкой и будет выполнен откат любых изменений данных внутри области транзакции.
5.2. Масштабируемость, отказоустойчивость, балансировка нагрузки
Масштабируемость — способность устройства увеличивать свои возможности путем наращивания числа функциональных блоков,выполняющих одни и те же задачи.
Служба балансировки нагрузки сети повышает надежность и масштабируемость серверных приложений Интернета, используемых на веб-, прокси- и FTP-серверах, серверах брандмауэра и виртуальной частной сети (VPN) и на других ответственных серверах [54].
На данный момент существует две технологии кластеризации: отказоустойчивые кластеры и балансировка сетевой нагрузки. Отказоустойчивые кластеры служат, в первую очередь, для обеспечения высокой доступности; балансировка сетевой нагрузки обеспечивает масштабируемость и, в то же время, увеличивает доступность служб Интернета.
Выбор технологии кластеризации (отказоустойчивый кластер или балансировка сетевой нагрузки) зависит в основном от того, должны ли приложения работать долгое время в оперативной памяти.
Отказоустойчивые кластеры предназначены для приложений, которые должны длительное время работать в оперативной памяти, или которые содержат часто обновляемые данные большого объема. Эти приложения называются переменными приложениями со сведениями о состоянии и включают в себя приложения для работы с базами данных и для обмена сообщениями. Как правило, отказоустойчивые кластеры используются для файловых серверов, серверов печати, баз данных и обмена сообщениями.
Балансировка сетевой нагрузки предназначена для приложений, которые не должны длительное время работать в оперативной памяти. Они называются неизменными приложениями. Неизменное приложение обрабатывает каждый запрос клиента как независимую операцию, поэтому может балансировать нагрузку для каждого запроса по отдельности. Как правило, данные в неизменных приложениях предназначены только для чтения и редко изменяются. Обычно балансировку сетевой нагрузки используют веб-серверы переднего плана, виртуальные частные сети, FTPсерверы, брандмауэры и прокси-серверы. Кластеры балансировки сетевой нагрузки также могут поддерживать другие службы и приложения на основе протоколов TCP и UDP.
Преимущества отказоустойчивых кластерных систем с балансировкой нагрузки [55]:
57
Надежность и отказоустойчивость,
Масштабируемость,
Легкая интеграция в существующую IT-инфраструктуру,
Работающий кластер выглядит для клиента как один сервер,
Использование недорогих серверов стандартной архитектуры,
Не требуют специальных приложений,
Поддерживается широкий набор дисковых и сетевых подсистем,
Хорошее соотношение цена/надежность.
Особенности кластеров с балансировкой нагрузки:
Вертикальная и горизонтальная масштабируемость,
Равномерное распределение нагрузки,
Добавление серверов (масштабируемость) без остановки работы.
Сохранение работоспособности при отказе более одного сервера за счет большего количества узлов в системе.
Для реализации балансировщика нагрузки обычно используется схема с организацией так наз. обратного прокси-сервера. Обратный проксисервер (англ. reverse proxy) — тип прокси-сервера, который ретранслирует запросы клиентов из внешней сети на один или несколько серверов, логически расположенных во внутренней сети. При этом для клиента это выглядит так, будто запрашиваемые ресурсы находятся непосредственно на прокси-сервере. В отличие от «прозрачного прокси», который перенаправляет запросы клиентов к любым серверам в Интернете и возвращает им результат, обратный прокси непосредственно взаимодействует лишь с ассоциированными с ним серверами и возвращает ответ только от них.
Рисунок 31. Общая схема использования reverse proxy при обеспечении отказоустойчивости
58
5.3.Мониторинг
Влюбой сети, имеющей больше чем один сервер, очень полезно иметь перед глазами полную картину происходящего. Уже в сетях среднего размера, где количество хостов превышает несколько десятков, следить за каждым в отдельности — непосильная задача для администраторов. Для облегчения задачи наблюдения применяются системы мониторинга.
Втехнической диагностике под мониторингом понимают непрерывный процесс сбора и анализа информации о значении диагностических параметров состояния объекта.
Мониторинг был и остается важнейшей частью системного и сетевого администрирования. К специализированным средствам централизированного управления и мониторинга можно отнести: Cacti, Zabbix, RHQ, Puppet и Cfengine. Чаще всего средства контроля администраторы применяют для мониторинга состояния аппаратного обеспечения, но с ростом числа программных сервисов на первый план выходит необходимость слежения за показателями программных комплексов.
Универсальные средства контроля (мониторинга) позволяют следить за процессами, происходящими в компьютерной системе. При этом возможны два подхода: наблюдение в реальном режиме времени или контроль
сзаписью результатов в специальном протокольном файле. Первый подход обычно используют при изыскании путей для оптимизации работы вычислительной системы и повышения её эффективности. Второй подход используют, когда мониторинг выполняется автоматически и (или) дистанционно, о последнем случае результаты мониторинга можно передать удаленной службе технической поддержки для установления причин конфликтов в работе программного и аппаратного обеспечения.
Наиболее популярным средством мониторинга является система Zabbix. Она состоит из нескольких частей, и при большой нагрузке и наблюдении за очень большим количеством хостов позволяет разнести эти части на несколько раздельных машин [56].
Zabbix состоит из:
собственно сервера мониторинга, который выполняет периодическое получение данных, обработку, анализ и запуск скриптов оповещения
базы данных (MySQL, PostgreSQL, SQLite или Oracle)
веб-интерфейса на PHP
агента — «демона», который запускается на отслеживаемых объектах и предоставляет данные серверу. Агент опционален, мониторинг можно производить не только с помощью него, но и по SNMP (версий 1, 2, 3), запуском внешних скриптов, выдающих данные, и несколько видов предопределенных встроенных проверок, таких как
59
ping, запрос по http, ssh, ftp и другим протоколам, а так же замер времени ответа этих сервисов.
Основная логическая единица — Узлы сети (host), сервера, находящиеся под наблюдением. Каждому серверу присваивается описание и адрес (dns или ip, можно оба, причем с возможностью выбирать, что использовать для соединения).
Узлы объеднияются в группы, например веб-сервера или сервера баз данных. Группы служат для вывода только определенных серверов при наблюдении.
Каждый узел имеет несколько Элементов данных (items) — параметров, за которыми ведется мониторинг. Для каждого элемента данных можно указать свой период обновления, способ хранения(сам параметр или скорость его изменения), множитель, временной интервал сбора (например только в рабочее время).
Создавать элементы данных для каждого из множества серверов — сложно, поэтому можно создать узлы-шаблоны. Эти узлы тоже содержат элементы данных, но они не мониторятся напрямую. Вместо этого реальный хост связывается с одним или несколькими шаблонами, и все параметры шаблона автоматически наследуются хостом.
Следить за тысячами параметров и думать, не выходит ли это значение за допустимые границы, администратору сети невозможно. Zabbix предоставляет гибкие возможности по настройке условий-триггеров, которые включаются при авариях и неполадках, и система включает индикаторы, показывая администратору наличие нештатной ситуации.
Если администратора нет на месте, то Zabbix достаточно самостоятелен и сможет отправить уведомление на почту, в jabber, sms или другой сервис немедленных сообщений, или даже попытаться самостоятельно поднять неисправный сервис, выполнив заранее определенные действия (останов, перезагрузку, переключение режимов), которые запускаются при срабатывании определенных триггеров.
По данным любого параметра система может построить график изменения за любой промежуток времени с максимальной детализацией. Можно создавать сложные графики, отображающие на одном поле несколько параметров.
Для отображения логической структуры сети можно создавать карты сети, отображающие именно расположение узлов сети и связей между ними. Состояние узлов (доступен или нет) отображается и на карте.
Другая программная система, служащая аналогичной цели мониторинга состояния сервисов - RHQ.
Открытая система RHQ предназначена для централизованного управления, инвентаризации, мониторинга и конфигурирования программного обеспечения [57]. Распространяется в рамках лицензии GNU GPL.
60