Самоучитель системного администратора. 5-е изд

ГЛ А В А
10 
Отказоустойчивая
информационная система 
В этой главе речь пойдет о создании отказоустойчивой и надежной информацион-
ной системы. Сразу хотим предупредить, что построение такой информационной 
системы — удовольствие недешевое. И прежде чем приступить к ее созданию, 
нужно подсчитать стоимость отказа в обслуживании — сколько потеряет предпри-
ятие за час, за день, за неделю простоя? Возможно, именно в вашем случае такая 
система и не нужна, поскольку финансовые потери из-за утраты данных окажутся 
значительно меньше стоимости создания и обслуживания отказоустойчивой 
информационной системы. 
Уточним для начала, что мы подразумеваем под надежной системой. В свете со-
временных представлений надежной считается система, не имеющая единственной 
точки отказа. Что произойдет с типичным предприятием, имеющим один сервер, 
выполняющий функции службы каталогов (Active Directory) и сервера баз данных 
для «1С:Предприятие», если этот сервер выйдет из строя? Это будет настоящий 
коллапс. Не нужно долго объяснять, чем обернется для него потеря финансовой 
информации («1С:Предприятие») или хотя бы остановка работы бухгалтерии на 
один день. Кроме того, не смогут работать даже те пользователи, которым «1С» и 
не нужна, — из-за недоступности сервера Active Directory им просто не удастся 
войти в свои системы. И даже при использовании локальных учетных записей все 
равно работа сети будет парализована: станут недоступны и сетевые диски, и сете-
вые принтеры. 
Территориальная распределенность 
Построение отказоустойчивой системы начнем с 
территориальной распределенно-
сти
. Зачем она нужна? Смерчи, торнадо, ураганы и извержения вулканов — все это 
может уничтожить ваше единственное расположение, единственный офис. Но не 
будем думать о подобного рода катастрофах, а просто представим себе, что у вас 
исчезло соединение с Интернетом. 
И даже если у вас есть резервный канал, то зачастую линии связи проходят по од-
ному и тому же участку. Следовательно, повреждение этого участка каким-нибудь 

498 
Глава 10 
стихийным бедствием или элементарным пожаром приведет к повреждению и ре-
зервного канала связи тоже. 
Это же касается и размещения технических средств. Если сетевое хранилище дан-
ных, используемое для резервного копирования, находится в одном помещении
с сервером, то тот же пожар выведет из строя и сервер, и его резервную копию. 
Так что при разработке информационной системы нужно учитывать особенности 
размещения ее элементов и заранее предусматривать меры, позволяющие восстано-
вить работоспособность системы в любых ситуациях. 
Центры обработки данных (дата-центры) 
Оптимальный вариант — размещение вычислительных мощностей информацион-
ной системы (попросту говоря, серверов) в 
центрах обработки данных
(ЦОД) или, 
как их еще называют, дата-центрах. 
ЦОД — это специально подготовленные помещения, обеспечивающие оптимальный 
режим работы оборудования. И самые серьезные из них — третьего уровня надежно-
сти — предусматривают полное дублирование всех систем. Другими словами, дата-
центр будет продолжать работать при выходе из строя или выключении для обслу-
живания любого его узла. Это очень серьезное требование, которое реализуется
путем тщательного проектирования. Поэтому построить такой ЦОД очень и очень 
дорого. В среднем стоимость хорошего ЦОД (а это не только строительные работы, 
но и оборудование систем электропитания, кондиционирования и аварийного осве-
щения) обходится в 25–30 тыс. долларов США за один квадратный метр его пло- 
щади. 
Понятно, что подобную роскошь может позволить себе не каждая компания, да и 
стоимость размещения своих серверов в таком ЦОД тоже будет доступна не всем. 
С другой стороны, практически каждая компания может позволить себе арендовать 
«облачный» ЦОД. Да, имеется в виду виртуализация. И даже если вы против пол-
ной виртуализации и еще не можете совсем отрешиться от настоящего «железа», 
можно развернуть в «облаке» хотя бы резервную площадку, работающую по прин-
ципу «теплого» резерва. И если что-то случится с основной площадкой, автомати-
чески начнет работать резервная площадка из «облака». 
Далее мы поговорим о требованиях к ЦОД — даже если ваше предприятие не пла-
нирует создавать свой собственный дата-центр, вы узнаете, как все там должно 
быть обустроено. 
Требования к помещениям 
В Интернете можно найти подробные требования к ЦОД, и нет смысла все их сюда 
переписывать. Коротко говоря, ЦОД должен размещаться на первом этаже здания, 
в помещении без окон, трубопроводов и т. п. Нужно избегать и соседства с соору-
жениями, которые потенциально могут нанести вред его помещению, — с трубо-
проводами или складами с горючими веществами. 

Отказоустойчивая информационная система 
499 
В ЦОД устанавливается весьма дорогостоящее оборудование, поэтому его помеще-
ние должно быть стойким ко взлому и оснащено системами контроля доступа. 
Материалы внутренней отделки дата-центра должны исключать выделение пыли. 
Часто для обеспечения чистоты в ЦОД реализуется наддув очищенного воздуха — 
в этом случае помещение герметизируется и оборудуется входным тамбуром. 
Размеры помещения зависят от количества устанавливаемого оборудования (по-
просту говоря, от количества стоек с серверами) с учетом резерва, который состав-
ляет 30–50% от расчетного размера. 
Поддержание в помещении постоянной температуры 
Одно из основных требований к дата-центру — поддержание температуры. Обычно 
в ЦОД весьма прохладно — температура устанавливается на уровне 18–20 °С 
(18 °С — предпочтительнее). Влажность также не должна быть повышенной, чтобы 
исключить возможность выпадения росы. В помещении ЦОД обычно не преду-
смотрена работа персонала — так что не волнуйтесь, что вы и ваши коллеги про-
студитесь. Но и именно из-за этого нет требований и по воздухообмену. Главное, 
чтобы воздух был, а его температура не превышала установленных значений. 
На поддержание температуры в дата-центре расходуется большая часть потребляе-
мой электроэнергии. Поэтому при проектировании ЦОД надо уделить внимание 
решениям, позволяющим снизить затраты на электропитание. Решения могут быть 
разными: от альтернативных источников энергии (хотя, учитывая их стоимость и 
низкий КПД, они обойдутся очень дорого) до подачи внешнего холодного воздуха 
зимой для поддержания внутри дата-центра необходимой температуры. 
Резервное электроснабжение 
Все оборудование ЦОД: серверы, коммутаторы, сетевые хранилища данных и пр. — 
следует оснащать двумя блоками питания, запитанными от разных линий: основ-
ной и резервной. Однако часто реализовать подключение ЦОД к двум независимым 
вводам от подстанций или выбрать более высокий уровень надежности внешнего 
электроснабжения невозможно. Поэтому необходимые требования по отказоустой-
чивости ЦОД нужно реализовывать только путем наращивания мощностей систе-
мы резервного электропитания. 
Основной параметр такой системы — максимальное время ее автономной работы. 
Как его рассчитать? Как предугадать, насколько быстро будет возобновлено элек-
троснабжение? Очень часто это время берется «с потолка» — вот представим, что 
электричество отключат на четыре часа... А что будет, когда это время выйдет? 
ЦОД потребляет десятки киловатт в час, поэтому система его резервного электро-
снабжения — устройство весьма дорогостоящее, и даже незначительное увели- 
чение времени автономной работы ведет к ее дополнительному серьезному удоро-
жанию. 
При этом, в плане резервного электроснабжения ЦОД, никакие ИБП не помогут, 
поскольку их мощности окажется недостаточно. Серверы — серверами, но есть еще 

500 
Глава 10 
система кондиционирования, которая потребляет электроэнергии гораздо больше, 
чем все серверы вместе взятые. 
Минимально необходимое время автономной работы рассчитывается как утроенное 
время штатного выключения всей информационной системы с сохранением дан-
ных. При этом емкость источников аварийного питания следует выбирать с запасом 
30%. Однако во многих случаях проще, дешевле и эффективнее использовать
дизель-генераторы с автоматическим запуском в случае отключения основного 
электропитания (если есть такая возможность). 
Некоторые разработчики ЦОД на время отключения электропитания предлагают 
останавливать кондиционеры. Поскольку ЦОД — это полностью закрытое поме-
щение, то сработает эффект «термоса», и некоторое время температура не подни-
мется выше 20 °С (при условии, что исходно она не превышала 18 °С). Иногда 
предлагается, отключив кондиционеры, оставить в работе только вентиляторы. Так 
можно значительно снизить потребление электроэнергии и в случае ее отключения 
продлить время автономной работы системы резервного электроснабжения. 
Системы пожаротушения 
Если площадь дата-центра превышает 20 кв. метров,
по правилам пожарной без- 
опасности должны применяться системы газового пожаротушения. При этом жела-
тельно, чтобы используемая газовая смесь допускала бы ее вдыхание человеком. 
Такая система не представляет особой сложности, и ее установку может выполнить 
любая сертифицированная организация. 
Сетевая инфраструктура 
Очень важной для дата-центра является и надежность сетевой инфраструктуры. 
Обычно эта задача решается дублированием каналов связи и активного оборудова-
ния (коммутаторов). 
Поскольку построение такой инфраструктуры существенно увеличивает стоимость 
самого дата-центра, то она создается только в том случае, если простои в работе 
информационной системы недопустимы и могут привести к финансовым потерям. 
Выбор правильной топологии сети передачи данных 
Топология сети весьма проста — все линии связи должны дублироваться, а дубли-
рующие каналы передачи данных не проходить по одним и тем же участкам. Как 
минимум, следует организовать подключение к Интернету через разных провайде-
ров, причем сами подключения должны быть разных типов, — так уменьшается 
вероятность прохождения каналов связи по одним и тем же участкам. При этом 
имеет смысл предварительно выяснить у предполагаемых провайдеров, где проло-
жены их линии связи. 
Активное сетевое оборудование также должно резервироваться. Это вдвое удоро-
жает инфраструктуру, поэтому резервирование реализуют на уровнях распределе-

Отказоустойчивая информационная система 
501 
ния, ядра и подключения серверной фермы, а оконечные устройства — пользова-
тельские станции — подключают к коммутатору нерезервированной линией связи. 
Чтобы не попасть впросак, нужно со всей ответственностью подойти к выбору обо-
рудования и к его настройке, не говоря уже о том, что построение отказозащищен-
ной инфраструктуры требует тщательного планирования. 
Существуют два варианта построения отказоустойчивой сети с дублированными 
каналами. Первый вариант использует протоколы, работающие на втором уровне 
модели OSI. Второй — основан на протоколах маршрутизации третьего уровня мо-
дели OSI. Оба эти варианта мы сейчас и рассмотрим. 
Построение отказоустойчивой сети
на основе протоколов второго уровня модели OSI 
Конфигурация на основе протоколов второго уровня модели OSI обеспечивает
в случае аварии более быстрое восстановление по сравнению с протоколами третьего 
уровня. Сеть может восстановиться за 1–2 секунды или даже еще быстрее, если ис-
пользовать проприетарные
1
протоколы. 
Протокол STP 
Протоколы STP (Spanning Tree Protocol, стандарт 802.1d) и RSTP (Rapid sTP, 
802.1w) обеспечивают автоматическое построение связей сетевой структуры. Суть 
их работы в том, что коммутаторы пытаются вычислить оптимальные маршруты 
между всеми устройствами по определенным алгоритмам. При этом для определе-
ния маршрутов и контроля соединений по специальным алгоритмам постоянно 
рассылаются служебные пакеты (Bridge Protocol Data Units, BPDU), и на их основе 
коммутаторы анализируют и определяют, где подключено активное оборудование, 
а где — конечные станции. При изменении топологии сети перенастройка ее струк-
туры осуществляется автоматически. При работе по протоколу STP этот процесс,
в зависимости от размера сети, занимает от 30 секунд до нескольких минут. Для 
протокола RSTP это время уменьшено до нескольких секунд. 
Протоколы STP/RSTP могут обеспечить связность сети без каких-либо ручных на-
строек. При построении структуры их алгоритмы учитывают скорость соединения 
и количество коммутаторов на дублированных линиях связи между точками под-
ключения — администратору нужно лишь включить эти протоколы на портах (час-
то это предусмотрено настройками по умолчанию для коммутаторов уровня досту-
па). На основании анализа рассылки пакетов BPDU коммутаторы определяют су-
ществующие связи и автоматически отключают порты, к которым подключены 
вторые, резервные каналы. 
Алгоритм изменения конфигурации сети в протоколах STP и RSTP в логический 
центр сети ставит коммутатор с самым малым весом (Bridge Priority). Для оптими-
зации процесса настройки сети администратор может вручную эти приоритеты
1
Проприетарным называется протокол, не являющийся открытым стандартом, а представляющий 
собой уникальную технологию какого-либо поставщика оборудования.

502 
Глава 10 
переназначить. Коммутатор в центре должен иметь самый малый вес. Чем дальше 
коммутатор находится от логического центра, тем выше его значение Bridge 
Priority. 
Желательно настроить и опцию быстрого старта (Fast Start) для тех портов, к кото-
рым подключены конечные устройства. Это исключит их из процедуры определе-
ния маршрутов и ускорит процесс перенастройки сети. Однако такая опция воз-
можна только для протокола RSTP. 
Протоколы STP/RSTP поддерживаются всеми современными коммутаторами. 
Однако серьезным недостатком их применения является 
отключение
резервных 
связей — при штатной работе резервные связи для передачи данных не задействуют-
ся и включаются только в случае повреждения основного канала. 
Протоколы STP/RSTP могут использоваться не только при наличии избыточных 
каналов связи. Включение этих протоколов может сохранить функционирование 
сети в случае умышленного создания петель, которые без этих протоколов приве-
дут к широковещательному шторму и прекращению функционирования сегмента 
сети. 
Протокол MSTP 
Протокол MSTP (Multi Spanning Tree Protocol, стандарт 802.1s) является расшире-
нием протокола RSTP на сеть с VLAN. 
В отличие от RSTP, протокол MSTP строит дерево связей с учетом созданных на 
коммутаторах VLAN. Поэтому предупреждение петель происходит не путем от-
ключения порта коммутатора, а через отключение передачи данных 
только
для оп-
ределенной VLAN. Но у этого протокола есть и недостаток — сложность настрой-
ки такой структуры. Администратор должен четко представлять разбиение системы 
на VLAN, оценить потоки данных в каждом сегменте и путем ручной настройки 
добиться относительно равномерного использования всех каналов связи. К тому 
же, далеко не все коммутаторы поддерживают протокол MSTP. 
Отказоустойчивая сеть
на основе протоколов третьего уровня модели OSI 
Протокол VRRP 
Для построения отказоустойчивой сети на основе протоколов третьего уровня ис-
пользуются решения, основанные на протоколах автоматической маршрутизации. 
Эти протоколы имеют несколько худшие показатели времени перестроения сети, 
чем протоколы второго уровня, однако трудоемкость настройки структуры сети
у них существенно ниже, чем при использовании, например, протокола второго 
уровня MSTP. 
Сеть с резервными каналами связи представляет собой отдельные подсети с не-
сколькими возможными путями передачи данных из одной подсети в другую. 
Обычно администратору достаточно лишь включить протоколы автоматической 
маршрутизации, чтобы сеть заработала. Причем переключение на другие пути

Отказоустойчивая информационная система 
503 
передачи данных в случае повреждения каналов связи будет происходить за счет
изменения таблиц маршрутизации. Недостаток такого решения уже был описан
ранее — данные передаются только по одному каналу, а резервный вообще никак 
не задействован. 
Обычно к коммутаторам уровней распределения и ядра подходят несколько кана-
лов связи. В случае отказа одного из них работа продолжается на исправном кана-
ле. Однако для рабочих станций существует только одна точка доступа к другим 
сетям — шлюз по умолчанию. В случае выхода из строя шлюза компьютеры поте-
ряют связь с другими сетями. 
Обойти подобную ситуацию можно с помощью протокола VRRP (Virtual Routing 
Reduntance Protocol). Конечно, лучше использовать другие технологии — напри-
мер, агрегированные каналы (см. далее), но в случае невозможности их применения 
подойдет и VRRP. 
Недостаток решения на основе протокола VRRP в том, что он поддерживается
далеко не всеми моделями маршрутизаторов, — его обычно не поддерживают 
бюджетные маршрутизаторы. 
Принцип создания отказоустойчивого шлюза следующий: в сети устанавливаются 
два коммутатора с поддержкой VRRP. На каждом из них настраиваются сетевые 
интерфейсы и включается протокол VRRP. После этого проводится настройка ин-
терфейса с одним и тем же IP-адресом на 
обоих
коммутаторах, причем один комму-
татор определяется главным, а второй — ведомым. В нормальных условиях работы 
коммутаторы постоянно обмениваются между собой служебной информацией.
Если все идет штатно, то по настроенному адресу шлюза работает только главный 
коммутатор. В случае его выхода из строя данные начинает передавать резервный 
коммутатор. 
Протокол VRRP принят в качестве стандарта, однако некоторые вендоры уже пред-
ставили свои модификации этого протокола. Например, в реализации VRRP от 
Nortel оба коммутатора могут работать в качестве шлюзов и передавать данные
в другие сети. Мы не станем подробно описывать подобные решения — при на- 
личии заинтересованности нужную информацию вы всегда сможете найти в Ин-
тернете. 
Агрегированные каналы 
Агрегированные каналы описаны в стандарте 802.3ad. Такие каналы позволяют 
объединить несколько линий связи между коммутаторами в один общий канал
передачи данных. Соответственно, агрегированный канал имеет пропускную спо-
собность, равную сумме пропускных способностей объединяемых каналов. Если 
все идет штатно, то используется общая пропускная способность всех объединен-
ных каналов. В случае отказа одного из каналов все данные будут передаваться
через оставшиеся каналы. 
Стандарт 802.3ad позволяет эффективно использовать резервные каналы связи.
Дело в том, что провайдеры часто предоставляют клиентам каналы связи с неогра-
ниченным трафиком. Следовательно, если не использовать 802.3ad, а отвести

504 
Глава 10 
одному из каналов связи роль классического резервного канала, то большую часть 
времени он будет простаивать, а вы будете за него платить. 
Агрегированный канал может настраиваться как вручную явным указанием объ- 
единяемых портов, так и автоматически на основе специального протокола LACP 
(Link Aggregation Control Protocol). Соответствующие настройки выполняются 
в программе конфигурирования коммутаторов. 
Но все имеет свои недостатки, есть они и у этого стандарта — он не поддерживает 
многоточечное подключение, т. е. соединение может осуществляться только между 
двумя устройствами. Однако многие поставщики оборудования создали решения, 
позволяющие обойти такое ограничение. Имеются решения, позволяющие создать 
агрегированный канал из двух и более линий, соединяющих объединенные в один 
стек коммутаторы. При этом настройка такого решения выполняется аналогично 
созданию агрегированного канала в пределах одного коммутатора. 
Подобные решения можно найти у различных вендоров: НР, Nortel, Cisco, вот 
только называются они у каждого из них по-разному. Например, в Cisco интере-
сующая нас технология называется EtherChannel, у Nortel — MLT. 
Проприетарные технологии
восстановления структуры сети 
Произошла авария. Как быстро будет восстановлена структура сети? На основе
открытых стандартов реально добиться восстановления работоспособности сети
за 3–5 секунд. Это очень хорошие показатели, учитывая, что даже при работе по 
протоколу STP время восстановления составляет от 30 секунд, что кажется веч- 
ностью. 
Однако 3–5 секунд — тоже не самый лучший результат. При использовании про-
приетарных технологий этот период можно сократить до менее чем одной секунды. 
Некоторые вендоры обещают крайне малые периоды восстановления: 20–30 мс. 
Конечно, они не рассказывают, в каких условиях были получены такие результаты, 
поэтому к подобным маркетинговым предложениям следует относиться с осторож-
ностью, особое внимание уделяя не только показателям, но и условиям проведения 
теста. И перед тем, как сделать выбор в пользу того или иного вендора, ознакомь-
тесь с результатами, полученными независимыми лабораториями — например, ла-
бораторией Tolly Group (
www.tolly.com
). 
Фермы серверов 
Ферма серверов — это несколько совместно работающих серверов. Основная зада-
ча ферм — балансировка нагрузки, но их можно рассматривать и с точки зрения 
повышения отказоустойчивости. 
Для распределения нагрузки между серверами используются различные решения. 
Есть аппаратные балансировщики, распределяющие нагрузку на основе учета сете-

Отказоустойчивая информационная система 
505 
вого трафика, есть программные решения, учитывающие загрузку сервера и на-
правляющие новые запросы на менее загруженную систему, и т. п. Самый простой 
способ — использовать балансировку сетевой нагрузки на основе решения, реали-
зуемого стандартными средствами Windows-серверов. 
Как уже было отмечено, существуют различные решения, адаптированные под тот 
или иной случай использования. Например, в статье по адресу: 
https://technet. 
microsoft.com/ru-ru/library/cc732370.aspx
рассказано, как создать ферму серверов 
шлюзов удаленных рабочих столов. 
Отказоустойчивые решения
для приложений 
Разработчики программного обеспечения предусмотрели собственные механизмы 
обеспечения высокой доступности. Такие механизмы реализованы для различных 
приложений; DHCP-серверов, DNS-серверов, веб-серверов и пр. На практике по-
добные решения очень эффективны. 
DNS-серверы 
DNS-серверы служат для разрешения доменных имен в IP-адреса и обратно. При 
недоступности DNS-сервера работать с информационной системой станет неудоб-
но, а то и вообще невозможно, — это зависит от ее настроек. 
Для обеспечения отказоустойчивости в технологиях DNS предусмотрено создание 
нескольких серверов: 
основного
(primary) и одного или нескольких 
вторичных
(secondary). При этом клиент получает (например, с помощью DHCP-сервера или 
при ручной настройке) IP-адреса всех серверов DNS. Если недоступен первый 
DNS-сервер, задействуется второй и т. д. Обычно поддерживается до четырех сер-
веров DNS. 
Как правило, изменения вносятся в основной DNS-сервер, а потом реплицируются 
на вторичные DNS-серверы. Если основной сервер DNS недоступен, внести изме-
нения в зону невозможно, однако информационная система остается в рабочем со-
стоянии, поскольку работают вторичные серверы, на которых имеется вся нужная 
информация о зоне. 
В домене Windows серверы DNS реализованы на распределенной базе службы ка-
талогов. Этот вариант не только обеспечивает отказоустойчивость, но и позволяет 
распределять нагрузку — каждый сервер может выступать в роли первичного и 
вносить изменения в данные зоны. Однако при использовании Windows есть одна 
большая проблема: при выходе из строя DNS-сервера, IP-адрес которого указан 
первым в настройках рабочей станции, последняя не может просто взять и исполь-
зовать второй IP-адрес (адрес вторичного DNS-сервера), — требуется ее переза-
грузка. Вообще-то, обычно это не очень большая проблема, но подобное решение 
недопустимо для систем, требующих непрерывной работы. 

506 

жүктеу/скачать 20,51 Mb.

Достарыңызбен бөлісу: