Рекомендации по созданию отказоустойчивой сети

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

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

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

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

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

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

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

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

НЕНУЖНЫЕ ПОТЕРИ?

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

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

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

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

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

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

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

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

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

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

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

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

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

АНАТОМИЯ ПРИЛОЖЕНИЙ

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

Из таблицы мы можем видеть, какое влияние тот или иной системный сбой оказывает на работоспособность приложения. При выходе из строя сервера базы данных (в данном случае Sun Microsystems 2000) неработоспособными окажутся все бухгалтерские приложения. Скорее всего, заказы можно будет принимать и без него, но, например, служба по работе с клиентами не сможет получить ответы на свои запросы.

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

Что касается коммутатора Fast Ethernet, при отсутствии резервного коммутатора или альтернативного маршрута сервер базы данных окажется недоступен.

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

Если сбой произойдет в проводке между коммутатором Fast Ethernet и маршрутизатором, то филиал лишится доступа к приложению и другим сервисам центрального офиса. Тот же результат может спровоцировать неисправность на маршрутизаторе или на DSU/CSU.

Что касается провайдера услуг глобальной сети, простои и сбои должны предусматриваться соглашением об уровне сервиса (Service Level Agreement, SLA). Однако распространение SLA дало неоднозначные результаты. SLA далеко не всегда отвечает требованиям заказчиков, но даже если и отвечает, то оператор часто оказывается не в состоянии выполнить условия соглашения на практике, особенно в критических ситуациях.

Другая проблема, следствием которой также является потеря доступа к приложению и другим сервисам, это неисправность DSU/CSU в офисе филиала. То же может случиться при отказе маршрутизатора или концентратора в филиале.

Каждый компонент в Таблице 1 имеет собственный набор характеристик (помимо общей доступности), любая из которых способна повлиять на работоспособность приложения. Во врезке "Потенциальные проблемы с сервером базы данных" мы перечислили некоторые из проблем, которые могут возникнуть с сервером Sun Microsystems 2000 из Таблицы 1.

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

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

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

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

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

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

ИНФОРМАЦИОННЫЕ И ТЕЛЕКОММУНИКАЦИОННЫЕ ПРИЛОЖЕНИЯ

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

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

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

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

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

InterNIC является хранителем информации о регистрации доменов Internet. Неуплата ежегодного взноса в InterNIC может привести к временной или безвозвратной потере имени домена; в результате организация остается без имени домена, на который ей можно было бы посылать почту.

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

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

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

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

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

Например, пакеты голосовой почты часто выполняются на компьютерах с ОС DOS, OS/2 Warp и различными разновидностями UNIX. Вследствие того, что срок службы телефонного оборудования намного дольше, чем у компьютерного, телефонные устройства (вместе со старой периферией и операционными системами) могут потребовать дополнительного обслуживания и обеспечения доступности/запаса/избыточности. Многие организации ежедневно осуществляют резервное копирование информации с серверов, но немногие задумываются о необходимости резервного копирования голосовой почты.

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

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

Несмотря на предупреждение пользователей о нежелательности использования сервера голосовой почты для хранения сообщений, они тем не менее часто хранят сообщения именно там. Как правило, многие системы предусматривают введение ограничений, чтобы пользователи не заполнили жесткий диск весь целиком, но некоторые системы оказываются при этом неработоспособными, если какое-то сообщение выходит за установленные пределы. Аналогично, сложные настройки системы автоматического распределения вызовов о маршрутизации входящих вызовов могут быть утеряны в результате отказа жесткого диска. Мне случалось не один раз видеть светящиеся, как Нью-Йорк в ночь на Рождество, консоли при отказе системы интерактивного голосового ответа, потому что пользователи системы все как один считали своим долгом сообщить супервизору, что они не могут получить доступ к системе.

В телефонии подробная документация может немало помочь в случае отказа системы или подсистемы. Точное описание необходимых действий позволит сэкономить время. Документация должна содержать список тех, кому следует звонить в зависимости от того, что именно произошло. Она должна также содержать список оборудования в сети вкупе с описаниями способов идентификации сбойных аппаратных компонентов и процедур восстановления системы. Эти инструкции должны быть написаны на понятном простому человеку языке без использования профессионального жаргона; иллюстрации из руководств по эксплуатации также могут немало способствовать получению представления о части сети или всей сети — данная информация может оказаться бесценной, когда диагностирование необходимо произвести немедленно. Советы по составлению документации и другим мерам, способным помочь при реализации общего плана обеспечения отказоустойчивости, приводятся во врезке "Приведение плана в действие".

ЗАЩИТА ОБОРУДОВАНИЯ

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

? предоставление постоянного чистого питания (насколько это возможно);

? организация защиты на административном уровне;

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

Источники бесперебойного питания (ИБП) имеются в изобилии фактически для любого типа оборудования — от настольных/рабочих станций до целых центров обработки данных. Некоторые из этих ИБП обладают достаточной интеллектуальностью для останова аппаратных систем в периоды длительного отсутствия электропитания. Другие могут останавливать работу аппаратных компонентов с помощью разнообразных программных систем. Защита питания наиболее эффективна, когда она вписывается в систему, а не просто добавляется к различным компонентам оборудования.

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

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

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

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

Многие программные пакеты управления сетью выполняют важную работу по сбору информации, необходимой для обеспечения защиты на административном уровне. Однако каждую неделю обнаруживаются новые ошибки и дыры, способные подвергнуть риску не только сетевую операционную систему, но также и защиту клиентских систем. Практически все крупные разработчики операционных систем отводят отдельный раздел на своем сервере Web под вопросы защиты. Другие узлы, например BugWatch.com, содержат перечни потенциальных дыр, как официальные, так и неофициальные.

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

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

СЛУЧАЙ СЛУЧАЮ РОЗНЬ

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

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

Приведение плана в действие

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

Ниже мы приводим список вопросов, которые вам следует задать самим себе при разработке проекта отказоустойчивой сети.

Персонал.

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

? Кто еще может помочь при восстановлении после аварий?

? К кому следует обращаться при отказе конкретного компонента или системы?

? Каковы обязанности основного персонала при восстановлении вычислительных/телекоммуникационных систем?

Отказы оборудования.

? Можно ли оборудование отремонтировать или заменить? Если да, то может ли сделать это кто-то из сотрудников компании или надо будет вызывать специалиста фирмы-поставщика?

? Сколько времени займет замена компонента и кто будет платить за нее?

? Имеются ли в наличии необходимые для ремонта инструменты? Можно ли их арендовать или купить? Если да, то у кого и сколько они стоят?

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

? Как долго будет длиться простой при отказе конкретного компонента?

Документация

? Где хранится документация и кто за нее отвечает?

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

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

? Где материалы хранятся за пределами офиса? Как к ним получить доступ?

Ресурсы Internet

Советы о том, как избежать отказов оборудования в сети, можно найти на сервере Ассоциации вычислительной техники:

http://www.acm.org .

Информацию о том, как избежать отказов сети из-за нарушения защиты, можно получить на сервере CERT:

http://www.cert.org .

Сведения о приложениях для компьютерной телефонии и предотвращении их отказов имеются на сервере журнала Computer Telephony Magazine:

http://www.computertelephony.com .

Потенциальные проблемы с сервером базы данных

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

? Неадекватное администрирование защиты. Как следствие, ваша база данных подвергается риску несанкционированного доступа к файлам.

? Устаревшие и/или легко доступные таблицы прав доступа к базе данных. Это открывает дверь для хакеров, чьи методы атаки включают поиск по словарю на предмет обнаружения возможных паролей.

? Повреждение кабелей. Повреждение кабелей внешней подсистемы может привести к полной неработоспособности сервера базы данных.

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