Лекции - Корпоративные информационные системы и технологии

Подождите немного. Документ загружается.

на бизнес-технологии, в том числе на переход к процессно-ориентированной

организации бизнеса.

Стандартов на электронные технические документы (ЭТД) ни в России, ни в

Украине пока не существует. Да и сама система стандартизации электронного

документооборота строится весьма нелогично: разрабатываются частные системы

стандартов, охватывающие некоторые частные области его применения (например,

стандарты STEP, стандарты серии ГОСТ Р ИСО 10303 и др.), в то время, как нет

основополагающих общесистемных стандартов на электронный документ, системы

управления электронной документацией и системы управления электронными

данными. Таким образом, даже в таком системном деле, как стандартизация, мы

продолжаем «славное» дело лоскутных решений.

В настоящее время разработку стандартов на систему управления электронной

технической документацией в России ведет научно-исследовательский центр CALS-

технологий «Прикладная логистика» (www.cals.ru). При разработке проекта стандарта

на систему управления электронной технической документацией немало сил было

приложено к тому, чтобы решить, казалось бы, простую задачу: развести по разным

углам электронный технический документ и электронные технические данные (ЭТДА).

Уж слишком велик был соблазн сделать единую систему стандартов на систему

управления ЭТДО и ЭТДА, и весьма непросто провести различие между их

управлением и обработкой с точки зрения ИТ.

Почему это так важно? ЭТД является интегрирующим объектом, который

позволяет провести ясную и обоснованную границу между собственно электронным

документом и его контентом (ЭТДА). Лишь при таком подходе можно выработать

унифицированные интерфейсы и протоколы взаимодействия между ПО управления

ЭТДО и ПО управления ЭТДА, обеспечив не точечную, а системную интеграцию

между ними. Пока что эта граница определяется разработчиками ПО самостоятельно

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

обработки технической информации делает упор на работу с ЭТДА; вопросы

представления ЭТДА в виде подписанных ЭТД разработчиков фактически не

волновали, в частности по причине того, что применение ЭТД не является легитимным.

К тому же административное управление ролями и пользователями в

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

заменяет использование электронной цифровой подписи (ЭЦП).

Кроме того, электронные данные в общем виде — та самая «глина»,

позволяющая разработчикам программных систем «лепить» электронные объекты

самыми разнообразными способами, часто не учитывающими главного: документ

должен свободно перемещаться между разными информационными системами,

приложениями и обрабатываться в них, в то время как объекты электронных баз

данных обычно привязаны к своим прикладным средствам и СУБД. Но работа с ЭТД

связана, прежде всего, с его «организационными» свойствами. Документ — бумажный

или электронный — интересует нас как механизм, прежде всего регулирующий

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

ЭТДА формально, в виде документально оформленных объектов баз данных

(например, трехмерных моделей, каталогов деталей) возникает масса технических и

процедурных вопросов, связанных, прежде всего, с применением ЭЦП,

переносимостью этих объектов между технологическими средами разных

информационных систем и т.д.

Применение ЭТД требует управления применением ЭЦП, а последнее

основывается на специфике электронного представления ЭТД. Между тем,

например, в России Федеральный закон об электронной цифровой подписи определяет

электронный документ как «документ, в котором информация представлена в

электронно-цифровой форме» (в Украине только готовится аналогичный закон). К

сожалению, такое определение говорит об информации, но не о самом документе, и уж

тем более о специфике ЭД. Необходимость работы с ЭД и ЭТД заставляет предприятия

самим давать определения этим терминам, разрабатывать собственные системы правил

и механизмы управления ЭЦП и ЭД, что порождает множество различий в

реализациях, часто принципиальных. При интеграции с информационными системами

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

люди с их интеллектуальной системой обработки данных и принятия решений могут

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

нужны стандартные интерфейсы и протоколы обмена.

5 Технологии обеспечения надежности корпоративных

информационных систем

Первыми открытыми системами, построенными в расчете на высокую готовность,

были приложения баз данных и систем коммуникаций. Базы данных высокой

готовности гарантируют непрерывных доступ к информации, которая является

жизненно важной для функционирования многих корпораций и стержнем сегодняшней

информационной экономики.

Программное обеспечение систем коммуникаций высокой готовности усиливает

средства горячего резервирования систем и составляет основу для распределенных

систем высокой готовности и систем, устойчивых к стихийным бедствиям. Несколько

компаний, поставляющих базы данных, такие как Oracle, Sybase Informix, имеют в

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

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

кластерных решений.

Первоначально модель вычислительного кластера была разработана компанией

Digital в конце 80-х годов. Она известна под названием VMS-кластеров (или VAX-

кластеров), которые представляли собой объединенные в кластер мини-компьютеры

VAX.

Несмотря на то что кластерные решения предлагают более десятка фирм, VMS-

кластеры удерживают лидерство по числу установок (более 20 тыс.) и до сих пор

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

вычислений.

Использование ОС UNIX в качестве платформы для кластеров баз данных

началось совсем недавно (в 1993 году). До этого времени попытки реализации

подобных систем, осуществленными такими компаниями, как IBM, Sequent, Pyramid и

другими, коммерческого успеха не имели. В 1996 году во всем мире едва ли

функционировало полсотни UNIX-кластеров баз данных – признать это массовым

освоением рынка, конечно, нельзя.

Этап распределения ресурсов, Escalante (1999-2000), должен обеспечить

пользователям взаимодействие с единой системой, точнее, с единым образом системы

(Single System Image, SSI), полностью спрятав ее (возможно, гетерогенную)

внутреннюю сущность. Клиент сможет запрашивать конкретные сервисы и ресурсы и

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

искать.

По мнению Novell, этот этап должен сделать кластеры обычным явлением на всех

стандартных аппаратных платформах. Серверы, данные и приложения должны

образовывать одну «виртуальную сеть». То есть все ресурсы должны представать перед

пользователем как составляющие одного объекта, администрируемого как единый

образ системы (SSI).

Многие компании в настоящее время работают над задачей построения

гетерогенных кластерных систем, позволяющих интегрировать ПК- и UNIX-серверы. В

такой гетерогенной среде для непосредственного обслуживания клиентских систем

будут использоваться серверы на Intel-платформе с NT, объединенные в кластер с

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

быстрого тиражирования баз данных или приложений групповой работы.

Сегодня среди кластерных систем старшего класса преобладают UNIX на базе

RISC-процессоров. Но по мере того как ПО и операционные системы для

кластеризации будут совершенствоваться и предлагать все большие функциональные

возможности, кластеринг, безусловно, станет основным способом построения

надежных масштабированных систем с Windows NT и NetWarp, являющихся

промежуточным звеном между SMP-машинами и компьютерами с массовой

параллельной обработкой.

Надежность и отказоустойчивость серверов

Важнейшая характеристика любой вычислительной системы, каковой является и

сервер, - надежность. Повышение надежности основано на принципе предотвращения

неисправностей путем снижения интенсивности отказов и сбоев за счет применения

специальных технологических решений и совершенствования методов сборки

аппаратуры.

Отказоустойчивость – это такое свойство системы, которое обеспечивает ей

возможность продолжения заданных действий после возникновения неисправностей.

Введение отказоустойчивости требует избыточного программного и аппаратного

обеспечения. Направления, связанные с предотвращением неисправностей и с

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

включает не только аппаратные средства, но и программное обеспечение. Главной

целью повышения надежности систем является целостность хранимых в них данных.

Один из важных показателей отказоустойчивости – наличие у сервера памяти с

коррекцией ошибок (ECC – Error Checking and Correction). Применение ЕСС позволяет

серверу обнаруживать и исправлять ошибки в памяти, которые способны вызвать сбой

или зависание системы в целом. Если исправление ошибок не возможно, часть банка

памяти или весь банк целиком будут заблокированы, что вызовет лишь уменьшение

объема доступной памяти с простым контролем на четность.

Другой не менее важный показатель отказоустойчивости аппаратных средств – это

поддержка работы с матрицей дисков RAID.

Избыточность систем питания и охлаждение сервера в сочетании с возможностью

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

серверной системы.

Производительность и масштабируемость

Производительность сервера определяется его архитектурой, т.е. конкретной

реализацией отдельных компонентов сервера и связей между ними. К основным

элементам архитектуры сервера можно отнести следующие: процессоры, средства

реализации многопроцессорных вычислений, средства организации совместной работы

процессоров с кэш-памятью и оперативной памятью, средства организации подсистемы

ввода/вывода и ее взаимодействия с процессором и оперативной памятью.

Увеличение производительности и быстродействия достигается благодаря

распараллеливанию операций ввода/вывода между несколькими дисками,

использованию достаточно большого объема кэш-памяти RAID-контроллера и

снижению нагрузки на процессор сервера за счет обработки операций ввода/вывода

процессором RAID-контроллера.

Масштабируемость представляет собой возможность наращивания числа и мощности

процессоров, объемов оперативной и внешней памяти и других ресурсов

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

конструкцией сервера, а также соответствующими средствами ПО.

Добавление каждого нового процессора в действительно масштабируемой системе

должно давать прогнозируемое увеличение производительности и пропускной

способности при приемлемых затратах. Одной из основных задач при построении

масштабируемых систем является минимизация стоимости расширения сервера и

упрощение планирования. В идеале добавление процессоров к системе должно

приводить к линейному росту ее производительности. Однако это не всегда так. Потери

производительности могут возникать, например, при недостаточной пропускной

способности шин из-за возрастания трафика между процессорами и основной памятью,

а также между памятью и устройствами ввода/вывода. В действительности реальное

увеличение производительности трудно оценить заранее, поскольку оно в значительной

степени зависит от динамики поведения прикладных задач.

Возможность масштабирования системы определяется не только архитектурой

аппаратных средств. Она зависит также и от заложенных свойств программного

обеспечения. Масштабируемость программного обеспечения затрагивает все его

уровни: от простых механизмов передачи сообщений до работы с такими сложными

объектами, как мониторы транзакций и вся среда прикладной системы. Аппаратные

средства (процессоры, шины и устройства ввода/вывода) являются только частью

масштабируемой архитектуры, на которой ПО может дать предсказуемых рост

производительности.

Важно понимать, что простой переход, например, на более мощный процессор может

привести к перегрузке других компонентов системы. Это означает, что действительно

масштабируемая система должна быть сбалансирована по всем параметрам.

Управляемость

Управляемость подразумевает возможность конфигурирования серверов,

мониторинга их состояния и оперативного устранения возникающих проблем.

Для обеспечения управляемости серверы комплектуются как аппаратными, так и

программными средствами. К аппаратным средствам относятся встроенные датчики

температурного режима и напряжения питания таких компонентов сервера как жесткие

диски, источник питания и вентиляторы, а также датчик, отвечающий за

автоматическую перезагрузку сервера при «зависании» сетевой ОС. Автоматическая

перезагрузка позволяет существенно сократить время простоя сервера. Информация,

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

входящего в комплект поставки специального ПО.

Системы управления сервером должны самостоятельно решать незначительные

проблемы и сообщать администратору о возникновении серьезных.

Совместимость с сетевым ПО

Концепция программной совместимости заключается в создании такой

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

моделей системы, независимо от цены и производительности каждой из них. Огромные

преимущества такого подхода, позволяющего сохранять существующий задел ПО при

переходе на новые (как правило более производительные) модели, были быстро

оценены как производителями компьютеров, так и пользователями.

5.1 Аппаратные средства повышения надежности

Некоторые термины

Важнейшая характеристика любой вычислительной системы, каковой является и

сервер, - надежность. Поскольку эффективность работы сети зависит от

функционирования сервера, к его надежности предъявляются особые требования.

Имеет смысл рассматривать две составляющие надежности. Первая – устойчивость к

внешним воздействиям и сбоям аппаратуры (что, как правило, и вкладывается в

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

трафика сетевой нагрузки. Компания IBM утверждает, что ПК-серверы при повышении

нагрузки до 60% от максимальной начинают вести себя непредсказуемо.

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

надежностью поддерживается полезность остальных функциональных характеристик

сервера.

Высокая готовность (High Availability)

Настоящие конструкции с высоким коэффициентом готовности для

времени простоя используют обычную компьютерную технологию. При это

конфигурация системы обеспечивает ее быстрое восстановление после

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

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

которой программа, отдельный компонент или система простаивает, может

находится в диапазоне от нескольких секунд до нескольких часов, но более

часто в диапазоне от 2 до 20 минут. Обычно системы высокой готовности

хорошо масштабируются, предлагая пользователям большую гибкость, чем

другие типы избыточности.

Эластичность к отказам (Fault Resiliency)

Ряд поставщиков компьютерного оборудования делит весь диапазон

систем высокой готовности на две части, при этом в верхней его части

оказываются системы, эластичные к отказам. Ключевым моментом в

определении эластичности к отказам является более короткое время

восстановления, которое позволяет системе быстро «откатиться» назад при

обнаружении неисправности.

Устойчивость к отказам (Fault Tolerance)

Отказоустойчивые системы имеют в своем составе избыточную

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

питания, подсистемы ввода/вывода и подсистемы дисковой памяти. Если

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

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

избыточные аппаратные средства можно использовать для распараллеливания

обычных работ. Время восстановления после обнаружения неисправности для

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

обычно меньше одной секунды.

Непрерывная готовность (Continuos Availability)

Вершиной линии отказоустойчивых систем являются системы, обеспечивающие

непрерывную готовность. Продукт с непрерывной готовность, если он работает

корректно, устраняет любое время простоя как плановое, так и не плановое. Разработка

такой системы охватывает как аппаратные средства, так и программное обеспечение и

позволяет проводить модернизацию (upgrade) и обслуживание в режиме on-line.

Дополнительным требованиям к таким системам является отсутствие деградации в

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

Устойчивость к стихийным бедствиям (Disaster Tolerance)

Широкий ряд продуктов и услуг связан с обеспечением устойчивости к

стихийным бедствиям. Иногда устойчивость к стихийным бедствиям

рассматривается в контексте систем высокой готовности. Смысл этого термина

в действительности означает возможность рестарта или продолжения операций

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

нерабочем состоянии из-за наводнения, пожара или землетрясения. В

простейшем случае продукты, устойчивые к стихийным бедствиям, могут

просто представлять собой резервные компьютеры, расположенные вне

основного месторасположения системы, сконфигурированные по

спецификациям пользователя и доступные для использования в случае

стихийного бедствия на основной площадке. В более сложных случаях

устойчивость к стихийным бедствиям может означать полное (зеркальное)

дублирование системы вне основного месторасположения, позволяющее

принять на себя работу немедленно после отказа системы на основной

площадке.

Единицей измерения надежности является среднее время наработки на отказ (MTBF –

Mean Time Between Failure). Повышение готовности – есть способ борьбы за снижение

времени простоя системы. Единицей измерения здесь является коэффициент

готовности, который определяет вероятность пребывания системы в работоспособном

состоянии в любой произвольный момент времени. Статистически коэффициент

готовности определяется как MTBF/(MTBF+MTTR), где MTTR (Mean Time To Repair)

– среднее время восстановления (ремонта), то есть среднее время между моментом

обнаружения неисправности и моментом возврата системы к полноценному

функционированию.

«Болевые точки» серверов

Современные недорогие серверы имеют много встроенных возможностей,

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

компонентов может стать слабым звеном, способным вывести сервер из строя:

• Вентиляторы обычно отказывают первыми. Выбирайте такие

вентиляторы, которые можно легко вынуть без отключения сервера;

• Двойные источники питания способны сохранить работоспособность

сервера, если один из них даст сбой. Однако для замены неработающего

источника все-таки может понадобиться выключить сервер;

• Сетевые платы могут при совместном использовании уменьшать сетевой

трафик, или одна из них выполнять роль страховочной, если откажет

другая;

• Жесткие диски с поддержкой RAID могут содержать копии данных друг

друга, некоторые допускают свою замену при сбое.

По данным зарубежных аналитиков отказы серверов вызваны следующими причинами:

сбой (зависание) сетевой ОС – 79%, отказ дисковых накопителей – 5%, отказ ПО – 4%,

проблемы сети электропитания – 8%, отказ источника питания – 2%, отказ ЦП – 1%,

другие причины – 1%.

Поэтому важным показателем надежности работы сервера является успешное

прохождение сертификационных испытаний на совместимость той или иной ОС.

5.2 Программные средства обеспечения надежности

(на основе Контрактного программирования)

Теория Контрактного Проектирования является основой для решения многих

проблем, критических для ОО подхода: какую ОО "методологию" применять, на какие

понятия опираться на стадии анализа, как специфицировать компоненты, как

документировать ОО ПО, чем руководствоваться при выполнении тестирования. Все

это вместе обеспечивает систематический подход к построению ПО с меньшим

количеством дефектов. И надежное ПО получается как итог надлежащим образом

встроенных в процесс разработки действий.

Понятие "контрактного проектирования" (Design by Contract) – сердцевина

"Метода Эйфеля", разработанного автором систематического подхода к созданию

надежного объектно-ориентированного программного обеспечения. Это понятие столь

же важно для ОО парадигмы, как и классы, объекты, наследование, полиморфизм и

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

необходим систематический подход к специфицированию и реализации ОО

программных сущностей и их взаимосвязей в программной системе. Эта статья

содержит введение в подход "Контрактное Проектирование", предложенный

компанией Interactive Software Engineering.

При оценке новых методов и средств разработки ПО обычно ориентируются на их

производительность. Объектные технологии действительно могут существенно

повысить производительность, при этом, однако, нельзя упускать из виду качество

создаваемого ПО. Качественное ПО — это прежде всего надежное ПО. Надежность —

это способность системы функционировать в соответствии со спецификацией

("корректность") и при этом успешно справляться с возникающими ненормальными

ситуациями ("устойчивость" — robustness). Ну, а проще говоря, надежная программа не

содержит ошибок.

Конечно, надежность — это желательное качество ПО безотносительно к методу его

разработки. Однако, объектно-ориентированный метод предполагает повышенные

требования к надежности — прежде всего из-за той особой роли, которую здесь играет

повторное использование программных компонентов, в корректности которых не

должно быть никаких сомнений.

Есть несколько составляющих подхода к построению надежного ОО ПО. Например,

статическая типизация – это признанный механизм для выявления ошибок еще до того,

как они проявляются в виде "багов" в исполняемой программе. Такой метод, как сбор

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

управлением памятью (вот почему я не согласен с теми, кто считает наличие

механизмов сбора мусора лишь желательной, но не обязательной деталью реализации).

Да и принцип повторного использования при надлежащем его воплощении также

можно рассматривать как инструмент более надежной разработки. Если применяемая

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

собственного решения вы опираетесь на повторное использование компонентных

библиотек, произведенных и проверенных сторонним производителем, имеющим

хорошую репутацию, то это означает, что существенной части программного

обеспечения можно доверять в той же степени, что и компьютеру, на котором оно

исполняется. Другими словами, повторно используемые библиотеки по-существу

становятся частью единой "программно-аппаратной машины", компонентами которой

можно считать аппаратуру, операционную систему и компилятор.

Но и это еще не все. Если мы хотим быть уверенными в надлежащей работе ОО

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