Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Обучение от Mail.Ru Group.
Онлайн-университет
для программистов с
гарантией трудоустройства.
Набор открыт!
2005 г.

Отказоустойчивость как мера эффективности

Николай Печерица, "Экспресс электроника", #05/2005

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

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

Тем не менее перечисленные решения обеспечивают надежность на уровне не более 99%, что соответствует времени простоя до 3,7 дней в год. И это, согласитесь, весьма неплохой показатель. Вообще же приемлемое время недоступности информационных сервисов зависит от требований бизнеса и для каждого предприятия определяется индивидуально. Оно варьируется от нескольких минут до нескольких часов, и обычно общая цифра фиксируется в соглашении об уровне сервиса (Service Level Agreement - SLA). Но для таких сфер, как банки и финансы, телекоммуникации, промышленность или научные исследования, показателя SLA на уровне 3,7 дней в год бывает недостаточно.

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

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

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

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

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

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

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

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

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

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

    Система резервного копирования относится к числу служебных и созданная ею нагрузка на вычислительные средства не является полезной с точки зрения предоставления информационных сервисов. Значит, эту нагрузку желательно снизить. Подобная задача распадается на два этапа: сокращение так называемого "окна резервного копирования" (времени, в течение которого компьютер-клиент выполняет резервное копирование) и уменьшение трафика соответствующих данных в корпоративной ЛВС. Внедрение системы резервного копирования в составе систем хранения позволяет сократить "окно" благодаря интеграции со средствами создания PIT-копий, реализованными в современных дисковых массивах: с данных практически мгновенно делается моментальный "срез", и резервное копирование выполняется уже с этого среза, а сервер продолжает работу. Снизить нагрузку на локальную сеть помогут технологии LAN-free backup и Serverless backup, предоставляемые сетями хранения данных, что является еще одним подтверждением особой эффективности этой технологии для катастрофоустойчивых систем.

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

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

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

    Однако наиболее простое, доходчивое и понятное определение кластера базируется на аппаратной особенности его реализации, некогда сформулированное компанией Digital Equipment Corporation. Итак, кластер - это разновидность параллельной или распределенной системы, которая состоит из нескольких связанных между собой компьютеров и используется как единый, унифицированный компьютерный ресурс.

    Следовательно, на каждом узле кластера находится своя копия операционной системы. Между тем такие системы, как SMMP, имеют одну общую копию ОС, и это исключение из правил. Узлом кластера может быть как однопроцессорный, так и многопроцессорный компьютер, причем в пределах одного DMMPS-кластера компьютеры могут иметь различную конфигурацию. Узлы кластера соединяются между собой (внутрикластерное, или межузловое соединение) с помощью либо обычных сетевых соединений (Ethernet, Fibre Channel), либо посредством нестандартных (фирменных) технологий. Внутрикластерные соединения позволяют узлам взаимодействовать между собой независимо от внешней сетевой среды. По внутрикластерным каналам узлы не только обмениваются информацией, но и осуществляют взаимный контроль работоспособности.

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

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

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

    Как и резервные, кластерные системы могут быть с разделяемыми дисками и без. Понятие "кластер с разделяемыми дисками" (shared disk) подразумевает, что любой узел имеет прозрачный доступ к любой файловой системе общего дискового пространства. Естественно, помимо разделяемой дисковой подсистемы на узлах кластера предусмотрены и локальные диски, но в этом случае они используются, главным образом, для загрузки ОС на узле. Такой кластер должен обладать специальной подсистемой, именуемой "распределенный менеджер блокировок" (Distributed Lock Manager) и служащей для устранения конфликтов при одновременной записи в файлы с разных узлов кластера.

    В свою очередь кластеры без разделения ресурсов (shared nothing), как и следует из названия, не имеют общих устройств ввода/вывода. Правда, есть одна тонкость: речь идет об отсутствии общих дисков на логическом, а не физическом уровне. Это означает, что дисковая подсистема может быть подключена сразу ко всем узлам. Если на дисковой подсистеме существует несколько файловых систем (или логических/физических дисков), то в любой момент времени доступ к определенной файловой системе предоставляется только одному узлу. К другой файловой системе доступ разрешен другому узлу. Такая управленческая иерархия системных ресурсов позволяет максимально обезопаситься от выхода из строя каких-либо компонентов из любого составляющего кластера надежности. Сбой одного сервера кластера мгновенно перекидывает управление на другой, а поврежденный отключается.

    Несколько примеров
    Наш материал был бы не полным без примеров внедрения катастрофоустойчивых, и в частности, кластерных систем, реализованных в СНГ. (Приведенные проекты носят имена заказчиков, для которых они были выполнены.)

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

    Так, в проекте для Центрального Банка РФ (в Главном управлении банка в Санкт-Петербурге) создана территориально распределенная информационная инфраструктура, основанная на двух идентичных вычислительных комплексах на базе мейнфреймов IBM eServer zSeries 900 и дисковых подсистем хранения информации IBM ESS 800 (кодовое название Shark), разнесенных на расстояние 22 км и соединенных между собой по технологии асинхронного удаленного копирования с использованием оборудования ONS 15540/15530 производства Cisco Systems. В этом решении вычислительный процесс выполняется на одном сервере-мейнфрейме и полностью дублируется на другом, а при каких-либо неполадках на основной машине ее функции автоматически переходят на резервный комплекс. Связь между двумя комплексами в Санкт-Петербурге осуществляется по двум волоконно-оптическим линиям, разнесенным на значительное расстояние и принадлежащим разным операторам (это, кстати, также одно из обязательных требований к катастрофоустойчивым системам). Проект разрабатывался в течение полутора лет и был выполнен в весьма сжатые сроки.

    Более продвинутое по архитектуре решение внедрено в прошлом году на Оскольском электрометаллургическом комбинате (ОЭМК). Здесь катастрофоустойчивый аппаратно-программный комплекс на UNIX-платформе IBM eServer p690 для работы с системой SAP R3, помимо технологий кластеризации, включал и систему резервного копирования на основе IBM TotalStorage FAST 700, двух дисковых систем и промышленной ленточной библиотеки, исполняющей роль системы резервирования. Катастрофоустойчивость комплекса обеспечивается за счет двух узлов кластера - основного и резервного, разнесенных на несколько сотен метров.

    Не менее интересное решение реализовано совсем недавно для одного из ведущих белорусских предприятий - ОАО "Гродно Азот". Созданная здесь катастрофоустойчивая IТ-инфраструктура представляет собой комплекс, предназначенный для обеспечения бесперебойного действия системы управления производством собственной разработки заказчика на базе СУБД Oracle, информационно-измерительной системы (хозрасчетные параметры, данные систем коммерческого учета и АСУТП), а также службы обмена электронными сообщениями на базе Lotus Domino. Данный проект, по словам его участников, отличается своей экономичностью. Внедренный комплекс состоит из двух равноценных вычислительных центров, разнесенных на расстояние около 1 км и соединенных двумя оптоволоконными каналами, проложенными по топологически разным путям. При этом один центр расположен в специально оборудованном подвальном помещении вне пределов взрывоопасной производственной зоны и не требует физического присутствия обслуживающего персонала. Комплекс построен на базе открытых систем и состоит из шести многопроцессорных RISC-серверов Sun Microsystems, систем хранения от компании EMC, Fibre Channel-коммутаторов Brocade, СУБД Oracle 9i Real Application Cluster, кластерного ПО Veritas, сервера обмена электронными сообщениями Lotus Domino Enterprise (Solaris), коммутаторов ЛВС 3-го уровня Alcatel, системы управления на базе HP OpenView и соответствующих приложений, перенесенных из старой системы. Основой обновленной IТ-инфраструктуры ОАО "Гродно Азот" стала современная сеть хранения данных, включающая две независимые матрицы коммутации (Fibre Channel Fabric). Такой подход обеспечил множественность путей доступа к данным для серверов комплекса и защиту от физического обрыва соединений. Помимо аппаратной RAID-защиты критические данные дублируются программно. Для обеспечения оптимальных режимов работы различных приложений и разумного баланса между уровнем доступности и стоимостью в комплексе используются несколько кластерных технологий: автоматическая балансировка нагрузки с параллельной обработкой транзакций, быстрое переключение на сервер "горячего" резерва и репликация по локальной сети.

    Пример решения с высоким показателем масштабируемости и высокой вычислительной загрузкой обоих узлов - проект для металлургического комбината "Азовсталь" (Украина). Здесь украинская компания-интегратор внедрила кластер на основе серверов производства Sun Microsystems и перенесла на него ERP-систему SAP R3. Это решение интересно тем, что представляет собой не просто серверный кластер, элементы которого территориально удалены друг от друга на несколько километров, а его узлы обеспечивают постоянное взаимное резервирование данных. При выходе из строя или повреждении целостности одного из узлов ERP-система автоматически переключается на работу с другим узлом, обеспечивая непрерывность вычислений. Сейчас эта кластерная система состоит из двух узлов, но возможно расширение до восьми узлов, что демонстрирует весьма высокие показатели масштабируемости предложенного решения. В качестве основных аппаратных компонентов системы, внедренной на комбинате, использованы серверы Sun Fire E2900 (сервер для вычислительных центров среднего класса на базе процессоров UltraSPARC IV), Sun Fire V440 (сервер начального уровня для вычислительных центров на базе процессоров UltraSPARC IIIi), а также системы хранения данных Sun StorEdge 3510 FC (12 дисков в "петле" FC-AL объемом 2 Гбайт с возможностью горячей замены).

Новости мира IT:

Архив новостей

Последние комментарии:

Релиз ядра Linux 4.14  (9)
Среда 22.11, 19:04
Loading

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 985 1945361
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2015 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...