Программно-технические меры являются материальной основой работ в области повышения доступности информационных сервисов. Без качественного аппаратного и программного обеспечения, без резервирования аппаратуры, тиражирования программ и данных невозможно добиться приемлемого уровня доступности. Кроме того, необходимо подчеркнуть, что проведение в жизнь большинства административных и процедурных мер осуществляется с использованием соответствующих служебных информационных сервисов (являющихся в данном случае средством автоматизации), которые, в свою очередь, должны обладать свойством высокой доступности. Таким образом, программно-технические меры играют как самостоятельную, так и вспомогательную роли, и обе эти роли представляются отнюдь не второстепенными.
Важнейшей мерой повышения доступности, затрагивающей все уровни — административный, процедурный и программно-технический, является применение структурированного подхода, нашеднего наиболее систематическое и законченное воплощение в объектно-ориентированной методологии. Структуризация необходима по отношению ко всем аспектам и составным частям информационной системы — от архитектуры до административных баз данных, на всех этапах ее жизненного цикла — от инициации до выведения из эксплуатации. Структуризация, важная сама по себе, является одновременно необходимым условием практической реализуемости прочих мер повышения доступности. Только маленькие системы можно строить и эксплуатировать как угодно. У больших систем свои законы, которые, как мы уже указывали, впервые осознали программисты около 30 лет назад.
Вообще говоря, программно-технические меры повышения доступности усложняют информационную систему, поэтому необходим взвешенный подход к их внедрению; в противном случае события будут развиваться в соответствии с известным законом Мерфи - первой выйдет из строя система повышения доступности. Каждая организация должна взвесить свои возможности, уровень квалификации своих специалистов и выбрать реалистичный набор мер.
Далее будут рассмотрены меры повышения доступности, относящиеся в первую очередь к фазе эксплуатации информационных систем, поскольку это представляется наиболее актуальным для большинства читателей.
После того, как на административном уровне приняты решения о принципах построения и архитектуре информационной системы, выполнены закупки и произведена установка аппаратного и программного обеспечения, а на процедурном уровне определен и усвоен персоналом регламент эксплуатации ИС, главным средством обеспечения безотказности на программно-техническом уровне становится проактивное управление всеми компонентами ИС и поддерживающей инфраструктуры.
Проактивное управление базируется на постоянном сборе и анализе информации о функционировании ИС. Для реализации этого процесса целесообразно применять программное обеспечение, построенное в архитектуре менеджер-агент и ориентированное на поддержку распределенных разнородных конфигураций. В качестве претендентов на эту роль можно указать семейства продуктов Solstice (Solstice Enterprise Manager и ассоциированные продукты) компании SunSoft и OpenView компании Hewlett-Packard. Одним из важных достоинств этих решений является возможность дублирования центра управления.
Информация, которая собирается в центре управления, не должна ограничиваться чисто компьютерными параметрами. Не менее важны параметры окружающей среды, такие как качество электропитания, температура и влажность в серверной комнате. Например, выход из строя кондиционера, если не предпринять немедленных мер, может повести к серьезным авариям вычислительной техники.
Системы управления допускают задание программируемых реакций на определенные события, такие как выход отслеживаемого параметра за допустимые пределы. Данная возможность автоматизации анализа регистрационной информации должна использоваться максимально широко.
По результатам анализа может быть принято решение об оптимизации ИС, об установке дополнительного оборудования или о ремонте компонентов, работающих неустойчиво.
Для проведения в жизнь политики безопасности вообще и политики повышения доступности в частности в рамках развитых ИС целесообразно использовать интегрирующие окружения, такие как CA-Unicenter компании Computer Associates или Tivoli Management Environment (TME) компании Tivoli Systems. Эти окружения позволяют управлять пользователями, программным обеспечением, потоком работ посредством интуитивно понятного графического интерфейса.
Централизованное резервное копирование, в том числе для клиентским рабочих мест, проводимое в соответствии с утвержденным расписанием, повышает доступность данных. Перечисленные интегрирующие окружения позволяют единообразно осуществлять копирование с автоматическим учетом специфики обслуживаемых сервисов (например, СУБД) без необходимости приостанавливать последние, но с сохранением целостности информации.
Балансировка загрузки, ее равномерное распределение по наличным ресурсам, является еще одним важным инструментом повышения безотказности. Избегать пиковых нагрузок — значит продлить срок службы оборудования и уменьшить вероятность проявления программных ошибок. Балансировка может осуществляться организационными мерами на основании анализа регистрационной информации, однако предпочтительнее использовать для этой цели программное обеспечение промежуточного слоя.
Консультационная служба является средством повышения безотказности работы пользователей, а также обслуживающего персонала. Для автоматизации консультационной деятельности можно рекомендовать продукты Apriori компании Platinum Technology и Top of Mind компании The Molloy Group.
Основным приемом обеспечения живучести является резервирование аппаратуры, программ и данных. Это верно и "в малом", для отдельных устройств, когда в них вводят избыточные модули, и для целых ИС, когда для обеспечения живучести создают резервный центр.
Аппаратура — относительно статичная составляющая, однако было бы ошибкой полностью отказывать ей в динамичности. В большинстве организаций информационные системы находятся в постоянном развитии, поэтому на протяжении всего жизненного цикла ИС следует соотносить все производимые изменения с необходимостью обеспечения живучести.
Программы и данные более динамичны, чем аппаратура, и резервироваться они могут постоянно, при каждом изменении, после завершения некоторой логически замкнутой группы изменений или по истечении определенного интервала времени.
Резервирование программ и данных может выполняться многими способами — за счет зеркалирования дисков, резервного копирования и восстановления, репликации баз данных и т.п. Будем использовать для всех перечисленных способов термин "тиражирование". В следующем пункте сделана попытка проанализировать общие свойства тиражирования как средства обеспечения живучести программ и данных.
Выделяются следующие классы тиражирования:
Современные сервисы, такие как СУБД (см., например, [7] , [8] ) предоставляют все перечисленные возможности. Рассмотрим, какие из них предпочтительнее.
В соответствии с рекомендуемой политикой повышения доступности, следует предпочесть стандартные средства тиражирования, встроенные в сервис.
Асимметричное тиражирование идейно проще симметричного (исключены конфликты по изменениям), поэтому целесообразно выбрать асимметрию.
Самым трудным является выбор между синхронным и асинхронным тиражированием. Синхронное идейно проще (нет периода рассогласования сервисов, когда транзакция успешно завершилась, но ее результаты еще не протиражированы; если в этот период случится отказ основного сервера, клиент будет считать, что заказанная им операция прошла нормально, однако на резервном сервере ее результаты будут отсутствовать), но его реализация может быть тяжеловесной и сложной, хотя это внутрення сложность сервиса, невидимая для приложений. Асинхронное тиражирование устойчивее к отказам в сети, оно меньше влияет на работу основного сервиса.
Чем надежнее связь между серверами, вовлеченными в процесс тиражирования, чем меньше время, отводимое на переключение с основного на резервный сервер, и чем жестче требования к актуальности информации, тем более предпочтительным оказывается синхронное тиражирование. Правда (оговоримся еще раз) необходимо также принимать во внимание особенности конкретных сервисов, апробированность реализации синхронного тиражирования, степень влияния тиражирования на работу пользователей.
С другой стороны, недостатки асинхронного тиражирования могут компенсироваться процедурными и программными мерами, направленными на контроль целостности информации в распределенной ИС. Сервисы, входящие в состав ИС, в состоянии обеспечить ведение и хранение журналов транзакций, с помощью которых можно выявлять операции, утерянные при переключении на резервный сервер. Даже в условиях неустойчивой связи с удаленными филиалами организации, подобная проверка в фоновом режиме займет не более нескольких часов, поэтому асинхронное тиражирование может рассматриваться как кандидат на использование практически в любой ИС.
Асинхронное тиражирование может производиться на сервер, работающий в режиме горячего резерва, возможно, даже обслуживающего часть пользовательских запросов, или на сервер, работающий в режиме теплого резерва, когда изменения периодически накатываются, но сам резервный сервер запросов не обслуживает.
Достоинство теплого резервирования в том, что его можно реализовать, оказывая меньшее влияние на основной сервер. Это влияние вообще может быть сведено к нулю, если асинхронное тиражирование осуществляется путем передачи инкрементальных копий с основного сервера (резервное копирование необходимо осуществлять в любом случае). Второе достоинство теплого резерва состоит в том, что его можно использовать как часть имитационного стенда и отрабатывать на нем технические и процедурные решения в условиях, максимально приближенных к реальным.
Основной недостаток теплого резерва состоит в относительном большом времени включения, что может быть неприемлемо для "тяжелых" серверов, таких как кластерная конфигурация сервера СУБД. Здесь необходимо проведение измерений в условиях, близких к реальным.
Второй недостаток теплого резерва вытекает из опасности малых изменений, связанных, например, с использованием резерва в составе имитационного стенда. Может оказаться, что в самый нужный момент срочный перевод резерва в штатный режим невозможен.
Учитывая приведенные соображения, следует в первую очередь рассматривать возможность горячего резервирования, либо тщательно контролировать использование теплого резерва и регулярно (не реже 1 раза в неделю) проводить пробные переключения резерва в горячий режим.
Обоснование целесообразности использования программного обеспечения промежуточного слоя (ПО ПС) является одним из существенных моментов настоящей работы. Причина состоит в том, что с помощью ПО ПС можно для произвольных прикладных сервисов добиться высокой живучести с полностью прозрачным для пользователей переключением на резервные мощности.
Основные черты ПО ПС подробно описаны в работе [6] на примере монитора транзакций Tuxedo System, принадлежащего ныне компании BEA Systems. В качестве других решений ПО ПС могут использоваться продукты компании Teknekron, Orbix компании Iona Technologies, семейство продуктов компании Isis Distributed Systems. Допустима и комбинация перечисленных средств, когда Orbix обеспечивает работу в распределенной объектно-ориентированной среде, а Isis — высокую готовность.
Перечислим основные достоинства ПО ПС, существенные для обеспечения доступности.
Для обеспечения обслуживаемости рекомендуется ориентироваться на решения модульной структуры с возможностью автоматического обнаружения отказов, динамического переконфигурирования аппаратных и программных средств и замены отказавших компонентов в горячем режиме.
Динамическое переконфигурирование преследует две основные цели:
Изолированные компоненты образуют зону риска реализованной угрозы. Чем меньше эта зона, тем выше обслуживаемость соответствующих сервисов. Так, при отказах блоков питания, вентиляторов и/или дисков в современных серверах зона риска ограничена ровно отказавшим компонентом; при отказах процессорных модулей весь сервер может потребовать перезагрузки (что может означать дальнейшее расширение зоны риска). Очевидно, в идеальном случае зоны поражения и риска совпадают, и современные серверы и активное сетевое оборудование, а также программное обеспечение ведущих производителей весьма близки к этому идеалу.
Возможность программирования реакции на отказ также повышает обслуживаемость систем. Каждая организация может выбрать свою стратегию реагирования на отказы тех или иных аппаратных и программных компонентов и автоматизировать эту реакцию. Так, в простейшем случае возможна отправка сообщения системному администраторы по электронной почте и/или на пейджер, чтобы ускорить начало ремонтных работ; в более сложном случае может быть реализована процедура "мягкого" выключения (переключения) сервиса, чтобы упростить обслуживание.
Возможность удаленного выполнения административных действий — важное направление повышения обслуживаемости, поскольку при этом ускоряется начало восстановительных мероприятий, а в идеале все работы (обычно связанные с обслуживанием программных компонентов) выполняются в удаленном режиме, без перемещения квалифицированного персонала, то есть с высоким качеством и в кратчайшие сроки. Для современных систем возможность удаленного администрирования — стандартное свойство, но важно позаботиться о его практической реализуемости в условиях разнородности конфигураций (в первую очередь клиентских). Централизованное распространение и конфигурирование программного обеспечения, управление и диагностирование компонентов информационной системы — надежный фундамент технических мер повышения обслуживаемости.
Целесообразно заключить договоры с компаниями, способными осуществлять сервисное обслуживание с высоким качеством и в кратчайшие сроки (порядка нескольких часов). Каждый компонент ИС должен входить в сферу действия подобного договора. Здесь имеются в виду не только компьютерные ресурсы, но и поддерживающая инфраструктура — электропитание, водоснабжение, кондиционирование, связь и т.п. В этой связи разумно использовать карту ИС, в которой с каждым компонентом связана история его "жизни" — установка, переконфигурирование, ремонт и прочие действия. Зная предысторию, проще планировать ремонтные мероприятия.
Необходимо создать целостный набор диагностического и тестового программного обеспечения, позволяющего контролировать состояние ИС после ремонта (ведущие компании-поставщики такими наборами располагают). Тестирование после обслуживающих мероприятий позволит убедиться в том, что доступность сервисов действительно восстановлена.
|
|
|
|
| Операционные регуляторы, относящиеся к обеспечению доступности | Содержание | Резервный вычислительный центр |
| Copyright ╘ 1993-2000, Jet Infosystems |