Лекция: Обеспечение высокой доступности. Что такое высокая доступность? Методы и методики

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

Посмотрите на эти цифры и вы поймете, чем доступность в 90% отличается от доступности в 99,999%:

Посмотрев на таблицу выше вы понимаете, что датацентр, гарантирующий сетевую доступность в 99% может позволить себе 7 часов простоя в месяц. Представьте себе такую ситуацию: весь день в датацентре что-то чинят, ваш сайт недоступен, вы несете убытки, а предъявить претензии датацентру не можете — даже при этой ситуации он обеспечит обещанную доступность.

Я считаю сетевую доступность 99% плохой. Предпочитаю датацентры, обеспечивающие не менее 99,9% сетевой доступности.

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

“Пять девяток” — вот, что такое высокая доступность

Термин “пять девяток” означает доступность 99,999% и встречается в маркетинговой литературе не реже, чем в технической. Считается, что сайт или система с уровнем доступности «пять девяток» — это и есть высокая доступность.

Высокая доступность нужна всем

Из таблицы видно, что 99,999% доступности — это всего 5,3 минуты простоя в год. Но даже те датацентры, которые гарантируют 100% доступность нередко пускаются на маркетинговые ухищрения.
Например, вычитают время регламентного обслуживания из времени доступности. К примеру, дата-центр обещает доступность 99.99%, но в момент, когда проводит плановые работы по замене чего-нибудь пишет “проводятся регламентные работы в течение 2 часов” и не считает это за недоступность. Отсюда вывод — читайте соглашение об уровне обслуживания (SLA) внимательно.

Если вы хотите обеспечить максимально высокую доступность вашему сайту на одном единственном сервере, выбирайте датацентр с хорошей ГАРАНТИРОВАННОЙ SLA (соглашением об уровне обслуживания) доступностью.

Обратите внимание! В SLA должно быть гарантировано время замены неисправного железа. И, в идеале, время реакции на проблему.

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

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

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

Сетевая доступность — это когда ваш сервер доступен по сети.
Доступность сервиса — это когда ваш сервер может обслуживать клиентов.

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

Доступность сервиса зависит от:

• сетевой доступности вашего сервера
• скорости реакции вашего админа на проблему
• скорости реакции поддержки дата-центра на проблему
• скорости замены неисправного железа в дата-центре

Недоступность складывается из:

• проблем сетевой доступности
• проблем с “железом”
• проблем с нагрузкой на сервере (“тормозит”, не справляется)
• программных ошибок (“косяки” программистов)

И месячную (кроме случаев поломки железа) и уж тем более годовую доступность 99,8% можно обеспечить в хорошем ДЦ на одном сервере без дополнительных мер обеспечения отказоустойчивости. Доступность 99,9% уже требует некоторого везения.

Если вам нужна гарантированная доступность выше 99,8%, необходимо заниматься отказоустойчивостью. И сервер должен быть не один. Но это тема отдельного разговора.

Доступность

Основные понятия

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

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

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

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

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

Основные угрозы доступности были рассмотрены нами ранее.

В соответствии с ГОСТ 27.002, под отказом понимается событие, которое заключается в нарушении работоспособности изделия. В контексте данной работы изделие – это информационная система или ее компонент.

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

Рис. 13.1.

где i – номер компонента,

λ i – интенсивность отказов,

T i – среднее время наработки на отказ.

Интенсивности отказов независимых компонентов складываются:

Рис. 13.2.

а среднее время наработки на отказ для составного изделия задается соотношением

Рис. 13.3.

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

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

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

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

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

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

«Доступность», «три девятки после запятой» — эти термины часто употребляют при обсуждении новых ИТ-решений. ИТ‑архитекторы предлагают заказчику проект новой системы, особенно обращая внимание на то, что она обладает очень высокой доступностью. Контракт заключен, система построена, акты о сдаче комплекса подписаны, начинается эксплуатация… Именно на стадии эксплуатации можно проверить «качество» созданной системы, и именно тогда может наступить разочарование. Что же скрывается за магическими «девятками»? Что в действительности обещают на этапе проектирования? И кто отвечает за доступность?

Доступность: введение в предмет

Самый правильный способ понять, что такое доступ­ность, - разобраться, зачем она нужна. До­ступность - это характеристика того, что хочет получить бизнес от ИТ‑службы. К сожалению, некоторые представители бизнеса на вопрос о желаемой доступности ИТ-услуги отвечают примерно следующее: «Хочу, чтобы всё всегда работало». В этом случае писать техническое задание на услугу приходится ИТ-менеджеру, в том числе определяя параметры доступности. Итак, доступность - это параметр ИТ-услуги, которую потребляет бизнес и которую предоставляет ИТ‑служба. Формула расчета доступности такова:

Availability = (AST - DT)/AST×100 = Servise or Component Availability (%)

где
AST (agreed service time) - согласованное время предоставления услуги;
DT (actual downtime during agreed service time) - фактическое время, когда услуга была недоступна в течение согласованного времени её предоставления.

Особенности расчета доступности проще понять на конкретном примере. Попробуем определить доступность ИТ-услуги «интернет-магазин» для компании ААА, расположенной в Москве, которая продает книги. При этом книги и их доставку в любой город можно оплатить, например, с помощью кредитной карты. Очевидно, что заказы на доставку будут обрабатываться только в рабочие дни с 9 до 18.

Но каким будет AST - согласованное время предоставления услуги? Для ответа на этот вопрос необходимо учесть, что люди могут размещать заказы в нерабочее время, и обязательно взять в расчет то, что в России 11 часовых поясов. Следовательно, предоставлять услугу надо 24 часа в сутки 7 дней в неделю.

Теперь нужно разобраться с DT - временем, когда услуга может быть недоступна. Здесь без переговоров с бизнесом не обойтись. Вполне возможно, что четыре часа недоступности услуги один раз в месяц может быть вполне адекватным выбором для данного примера. Однако надо учесть один нюанс - период времени, в течение которого проводится оценка параметра DT, то есть собственно согласованное время предоставления услуги (AST). Выбор периода AST - личное дело договаривающихся сторон: бизнеса и ИТ‑службы. В качестве такого периода лучше взять неделю или несколько недель, так как месяц или год - величины непостоянные (включают разное количество дней). Однако нужно обращать внимание и на психологию: более короткие периоды времени могут быть негативно восприняты бизнесом. В нашем примере то же самое значение доступности соответствует простою примерно час в неделю. Однако бизнесу может не понравиться, что интернет-магазин будет недоступен в течение часа каждую неделю, хотя на четыре часа простоя в месяц он может согласиться. С другой стороны, иногда невозможно эксплуатировать ИТ‑систему без того, чтобы не остановить её на несколько часов для плановых работ по обслуживанию. Такие плановые простои тоже должны быть учтены при выборе DT, что, в свою очередь, может привести к пересмотру параметра AST.

Исходя из вышеизложенного мы выбираем 4 часа недоступности услуги один раз в течение четырех недель. То есть AST = 4 недели, DT = 4 часа. Тогда доступность такова:

Availability = (24×7×4–4)/(24×7×4)×100% = 99,40%

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

Обратите внимание, что мы определили необходимую доступность до того, как стали работать над решением, которое ее обеспечивает, а не наоборот - сначала выбрали решение и стали считать его доступность. Техническое задание первично, а требуемая доступность - это один из параметров, зафиксированный в нём. Когда система будет сдана в эксплуатацию, доступность должна соответствовать требуемому значению. Поэтому мы советуем в соглашении с бизнесом (SLA - Service Level Agreement) подробно расшифровать, что подразумевается под цифрой доступности (в нашем примере так: «4 часа недоступности услуги один (1) раз в течение четырех (4) недель»), чтобы все стороны однозначно понимали, чтó действительно скрывается за цифрами.

Три составляющие доступности

Самое первое, что нужно осознать при выборе решения, - это из чего состоит доступность ИТ-услуги. Множество разочарований во время эксплуатации объясня­ется тем, что доступность услуги, которую хочет получить бизнес, напрямую связывают с доступностью оборудования. Однако доступность ИТ-услуги представляет собой совокупность трех составляющих:
1) Reliability - обычно переводится как надежность;
2) Maintainability - переводится как «обслуживаемость»;
3) Serviceability - ремонтопригодность.
Разберем каждый из этих пунктов.

Reliability

Reliability - это доступность инфраструктуры или аппаратно-программного комплекса в целом, включая коммуникации. Например, для интернет-магазина нам нужен веб‑сервер, сервер приложений, СУБД, дисковое хранилище и доступ в Интернет. Для простоты будем считать, что программное обеспечение «сервер приложений» включает в себя веб‑сервер и будет установлено на одном аппаратном сервере, СУБД - на втором, а дисковое хранилище представляет собой внешний дисковый массив.

Начинаем творить - строим проект инфраструктуры. Под каждым компонентом напишем параметры его доступности. Доступность каждого компонента - далее будем пользоваться термином «надежность» - должна быть получена от поставщика компонента (оборудования, программного обеспечения или услуги). Если это по каким‑либо причинам невозможно (например, для программных компонентов значение надежности, как правило, неизвестно) - искомую величину придётся самостоятельно оценить и назначить. Каждый компонент является единой точкой отказа, поэтому на рабочей схеме для расчета надежности они соединены последовательно (рис. 1). Заметим, что это не схема соединения компонентов инфраструктуры, а лишь схема расчета надежности.

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

Reliability = (0,985×0,97×0,975×0,98×0,99×0,9999×0,99)×100%= 89,47%

Это явно недостаточно по сравнению с требуемым значением 99,40%. Тогда изменим решение - включим в систему альтернативного поставщика услуг доступа в Интернет (рис. 2) и рассчитаем его надежность. Поскольку относительно интернет-доступа мы имеем параллельное соединение, общая надежность определяется следующим образом:

Общая надежность =

Reliability = ×100% = 91,72%

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

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

Maintainability и Serviceability

Переходим к другим составляющим до­ступ­нос­ти - maintainability и serviceability. Замечу, что переводы «обслуживаемость» и «ремонтопригодность» неудачны, поскольку из них малопонятно, что это значит. Лучше использовать более понятные переводы: maintainability - деятельность внутренней ИТ‑службы организации; serviceability - услуги, предоставляемые внешними поставщиками.

Чтобы прояснить ситуацию, рассмотрим крайние варианты. В каком случае полностью отсутствует maintainability (деятельность внутренней ИТ‑службы организации)? Это бывает, когда компания собственную ИТ‑службу отдает на аутсорсинг. Здесь доступность складывается только из надежности и услуг, предоставляемых внешними поставщиками.

В каком случае полностью отсутствует serviceability (услуги, предоставляемые внешними поставщиками)? Это происходит, например, в ФСБ, которая из соображений секретности всю деятельность по поддержанию системы в рабочем состоянии вынуждена вести исключительно силами своего ИТ-подразделения, даже запчасти покупаются самостоятельно, а не поставляются в рамках контракта технической поддержки. Тогда доступность складывается только из надежности системы и деятельности внутренней ИТ‑службы организации.

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

Способы манипулирования составляющими доступности

Чтобы понять, каким образом можно манипулировать всеми составляющими доступности, рассмотрим другой практический пример. Компания, имеющая центры обработки данных в двух городах России, Зеленограде (город - спутник Москвы) и Иркутске, приобрела две одинаковые системы «под ключ». Следовательно, надежность - reliability - у них одинаковая. Обе ИТ‑системы были обеспечены одинаковыми контрактами технической поддержки на аппаратную и программную части, значит, услуги, предоставляемые внешними поставщиками, - serviceability - также были одинаковы. Однако доступность систем оказалась разная. И компания стала жаловаться поставщику на плохую доступность системы в Иркутске, утверждая, что одно из решений «бракованное», и требуя провести его аудит.

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

Вариант 1: к потере доступности привели аппаратные сбои. Из-за географического положения центров обработки данных одинаковые контракты технической поддержки аппаратной части на самом деле могут оказаться разными. Например, сервисный центр внешнего поставщика расположен в Москве, а в контракте технической поддерж­ки написано, что он действует только в рабочие дни и инженер прибывает на место установки оборудования «первым доступным железнодорожным или авиарейсом». Очевидно, что для инженера, отбывающего из Москвы, эта величина будет разной для Зеленограда и Иркутска.

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

• изменить надежность ИТ‑системы в Иркутске, например поставить дополнительный узел в кластер;
• изменить параметр serviceability - создать склад в Иркутске, получить возможность для ИТ‑специалистов компании самостоятельно менять неисправные компоненты, если это не противоречит правилам производителя.

Кроме того, имеет смысл проверить условия эксплуатации. Примеры типичных нарушений этих условий:

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

Вариант 2: к снижению требуемого уровня доступности привели программные сбои. В этом случае скорее всего проблема в ИТ‑службе в Иркутске. Услуги технической поддержки программного обеспечения предоставляются в дистанционном режиме. Следовательно, разницы в услугах нет за исключением того, что для разных часовых поясов существуют различные периоды предоставления услуг по отношению к местному времени, но это, как правило, существенного влияния не оказывает. Вероятной при­чиной «провала» доступности здесь является разный уровень профессионализма ИТ‑департаментов - в Иркутске он наверняка ниже, чем в Зеленограде. Возможные ре­шения:

• подтянуть maintainability до нужного уровня - провести обучение ИТ-персонала в Иркутске по программным и аппаратным продуктам, входящим в состав ИТ‑системы, организовать семинары по передаче опыта ИТ-команды из Зеленограда, скопировать процессы эксплуатации и т. п.;
• компенсировать maintainability за счет serviceabi­lity - приобрести расширенные услуги технической поддерж­ки, услуги ауттаскинга и т. п.

Если вернуться к нашему примеру с интернет-магазином, то какое сочетание reliability, maintainability и serviceability будет оптимальным? Ответ на этот вопрос зависит от каждого конкретного случая. Например, можно порекомендовать хостинг вместо того, чтобы полностью реализовывать всю инфраструктуру (ИТ и техническую) самостоятельно. В общем случае имеем следующие типовые способы управления доступностью. 1. Изменение reliability (надежности):

• изменение ИТ-решения в сторону высокой доступности (High Availability) - использование кластеров, применение оборудования с поддержкой «горячей» замены, неоднократного дублирования потенциальных точек отказа и т. п.;
• аренда всей инфраструктуры или её части у внешних поставщиков (хостинг, collocation).

2. Изменение maintainability (изменения в деятельности ИТ‑службы компании):

• распространение внутри организации собственного передового опыта управления ИТ;
• приглашение внешних консультантов для организации процессов в ИТ-подразделении;
• обучение ИТ-персонала.

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

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

В третьей версии ITIL-процессы управления доступностью и непрерывностью ИТ-услуг рассматриваются вместе (далее процесс). Важнейшими ключевым понятиями этого совместного процесса являются:

доступность - способность ИТ-услуги или ее компонентов выполнять свои функции в определенный период времени;

надежность - способность ИТ-услуги или ее компонентов выполнять заданные функции при определенных условиях эксплуатации;

восстанавливаемость - способность ИТ-услуги или ее компонентов к восстановлению своих эксплуатационных характеристик, утраченных частично или полностью в результате сбоя;

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

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

Планирование и разработка ИТ-услуг с учетом требований бизнеса к уровню доступности;

Оптимизация доступности ИТ-услуг путем проведения эффективных с точки зрения затрат усовершенствований;

Сокращение количества и продолжительности инцидентов, влияющих на доступность ИТ-услуг.

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

Планирование

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

При проектировании доступности ИТ-услуг проводится анализ ИТ-инфраструктуры с целью определения наиболее уязвимых компонентов, не имеющих резерва и способных в случае сбоя оказать негативное влияние на предоставление ИТ-услуг. В терминологии ITIL подобные компоненты называются Single Point of Failure (SPOF), и для их определения используется метод «Анализ влияния сбоев компонентов инфраструктуры» (Component Failure Impact Analysis, CFIA). Данный метод применяется для оценки и прогнозирования воздействия отказов ИТ-компонентов на ИТ-услугу. Основные цели CFIA таковы:

Определение точек сбоев, влияющих на доступность;

Анализ влияния сбоя компонентов на бизнес и пользователей;

Определение взаимосвязи компонентов и персонала;

Определение времени восстановления компонентов;

Определение и документирование вариантов восстановления.

Для анализа рисков используется метод анализа и управления рисками (CCTA Risk Analysis and Management Method, CRAMM), в котором анализируются возможные угрозы и зависимости ИТ-компонентов, проводится оценка вероятности возникновения нестандартных ситуаций или чрезвычайных событий.

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

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

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

Улучшение доступности ИТ-услуг

Зачем нужно улучшать доступность? Причин может быть множество: несоответствие качества ИТ-услуг требованиям SLA; нестабильность предоставления ИТ-услуг; тенденции к снижению уровня доступности ИТ-услуг; недопустимо большие сроки восстановления; запросы со стороны бизнеса на увеличение уровня доступности.

Улучшение доступности требует обоснованных дополнительных финансовых затрат, и для установления возможности улучшения ИТ-услуг используются определенные методы и технологии, среди них анализ дерева отказов (Fault Tree Analysis, FTA) и анализ системных простоев (Systems Outage Analysis, SOA).

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

Анализ системных простоев представляет собой структурированный подход к идентификации основных причин прерывания в предоставлении ИТ-услуг и использует несколько источников данных для определения места и причины возникновения прерываний. Цели такого анализа:

Определение основных причин сбоев предоставления ИТ-услуг;

Определение эффективности поддержки ИТ-услуг;

Подготовка отчетов;

Инициирование программы по исполнению принятых рекомендаций;

Анализ улучшений уровня доступности, полученного с помощью анализа системных простоев.

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

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

Измерение доступности ИТ-услуг

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

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

Роли и ответственности

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

Внедрение процесса

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

Как и любой проект, внедрение процесса начинается с создания проектных команд, разработки документов по управлению проектом, составления плана проекта и т.д. На этапе «предпроектных» работ проводятся маркетинговые мероприятия по ознакомлению представителей бизнеса с технологиями и рекомендациями ITIL и обоснованию необходимости для бизнеса внедрения процесса управления доступностью ИТ-услуг.

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

Эффект и проблемы

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

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

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

Отказ от внедрения процесса по причине того, что текущая доступность ИТ-услуг считается приемлемой;

Предположения, что при наличии других внедренных процессов ITSM процесс управления доступностью будет выполнен автоматически;

Сопротивление централизации в управлении ИТ-инфраструктурой со стороны ИТ-менеджеров;

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

Евгений Булычев ([email protected]) - консультант отделения «Ай-Теко Бизнес Консалтинг» (Москва).

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

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

Предисловие

• Отказоустойчивость (Fault Tolerance, FT) - способность системы к дальнейшей работе после выхода из строя какого-либо её элемента.
• Кластер - группа серверов (вычислительных единиц), объединенных каналами связи.
• Отказоустойчивый кластер (Fault Tolerant Cluster, FTC) - кластер, отказ сервера в котором не приводит к полной неработоспособности всего кластера. Задачи вышедшей из строя машины распределяются между одной или несколькими оставшимися нодами в автоматическом режиме.
• Непрерывная доступность (Continuous Availability, CA) - пользователь может в любой момент воспользоваться сервисом, перерывов в предоставлении не происходит. Сколько времени прошло с момента отказа узла не имеет значения.
• Высокая доступность (High Availability, HA) - в случае выхода из строя узла пользователь какое-то время не будет получать услугу, однако восстановление системы произойдёт автоматически; время простоя минимизируется.
• КНД - кластер непрерывной доступности, CA-кластер.
• КВД - кластер высокой доступности, HA-кластер.

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

Continuous availability / непрерывная доступность

Аппаратный способ представляет собой “раздвоенный” сервер: все компоненты дублированы, а вычисления выполняются одновременно и независимо. За синхронность отвечает узел, который в числе прочего сверяет результаты с половинок. В случае несоответствия выполняется поиск причины и попытка коррекции ошибки. Если ошибка не корректируется, то неисправный модуль отключается.
На Хабре недавно была на тему аппаратных CA-серверов. Описываемый в материале производитель гарантирует, что годовое время простоя не более 32 секунд. Так вот, для того чтобы добиться таких результатов, надо приобрести оборудование. Российский партнёр компании Stratus сообщил, что стоимость CA-сервера с двумя процессорами на каждый синхронизированный модуль составляет порядка $160 000 в зависимости от комплектации. Итого на кластер потребуется $1 600 000.

Программный способ.
На момент написания статьи самый популярный инструмент для развёртывания кластера непрерывной доступности - от VMware. Технология обеспечения Continuous Availability в этом продукте имеет название “Fault Tolerance”.

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

• На физическом хосте должен быть процессор:
  • Intel архитектуры Sandy Bridge (или новее). Avoton не поддерживается.
  • AMD Bulldozer (или новее).
• Машины, на которых используется Fault Tolerance, должны быть объединены в 10-гигабитную сеть с низкими задержками. Компания VMware настоятельно рекомендует выделенную сеть.
• Не более 4 виртуальных процессоров на ВМ.
• Не более 8 виртуальных процессоров на физический хост.
• Не более 4 виртуальных машин на физический хост.
• Невозможно использовать снэпшоты виртуальных машин.
• Невозможно использовать Storage vMotion.

Лицензирование vSphere привязано к физическим процессорам. Цена начинается с $1750 за лицензию + $550 за годовую подписку и техподдержку. Также для автоматизации управления кластером требуется приобрести VMware vCenter Server, который стоит от $8000. Поскольку для обеспечения непрерывной доступности используется схема 2N, для того чтобы работали 10 нод с виртуальными машинами, нужно дополнительно приобрести 10 дублирующих серверов и лицензии к ним. Итого стоимость программной части кластера составит 2 *(10 + 10)*(1750 + 550)+ 8000 =$100 000.

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

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

Есть Remus на базе Xen, бесплатное решение с открытым исходным кодом. Проект использует технологию микроснэпшотов. К сожалению, документация давно не обновлялась; например, установка описана для Ubuntu 12.10, поддержка которой прекращена в 2014 году. И как ни странно, даже Гугл не нашёл ни одной компании, применившей Remus в своей деятельности.

Предпринимались попытки доработки QEMU с целью добавить возможность создания continuous availability кластера. На момент написания статьи существует два таких проекта.

Первый - Kemari , продукт с открытым исходным кодом, которым руководит Yoshiaki Tamura. Предполагается использовать механизмы живой миграции QEMU. Однако тот факт, что последний коммит был сделан в феврале 2011 года говорит о том, что скорее всего разработка зашла в тупик и не возобновится.

Второй - Micro Checkpointing , основанный Michael Hines, тоже open source. К сожалению, уже год в репозитории нет никакой активности. Похоже, что ситуация сложилась аналогично проекту Kemari.

Таким образом, реализации continuous availability на базе виртуализации KVM в данный момент нет.

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

High availability / высокая доступность

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

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

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

• Heartbeat версии 1.х в связке с DRBD;
• Pacemaker;
• VMware vSphere;
• Proxmox VE;
• XenServer;
• Openstack;
• oVirt;
• Red Hat Enterprise Virtualization;
• Windows Server Failover Clustering в связке с серверной ролью “Hyper-V”;
• VMmanager Cloud.

VMmanager Cloud

В упрощённой форме алгоритм такой:

1. Происходит поиск узла кластера с наименьшим количеством виртуальных машин.
2. Выполняется запрос хватает ли свободной оперативной памяти для размещения текущей ВМ в списке.
3. Если памяти для распределяемой машины достаточно, то VMmanager отдаёт команду на создание виртуальной машины на этом узле.
4. Если памяти не хватает, то выполняется поиск на серверах, которые несут на себе большее количество виртуальных машин.

Практика показывает, что лучше выделить одну или несколько нод под аварийные ситуации и не развёртывать на них ВМ в период штатной работы. Такой подход исключает ситуацию, когда на “живых” нодах в кластере не хватает ресурсов, чтобы разместить все виртуальные машины с “умершей”. В случае с одним запасным сервером схема резервирования носит название “N+1”.

VMmanager Cloud поддерживает следующие типы хранилищ: файловая система, LVM, Network LVM, iSCSI и Ceph . В контексте КВД используются последние три.

При использовании вечной лицензии стоимость программной части кластера из десяти “боевых” узлов и одного резервного составит €3520 или $3865 на сегодняшний день (лицензия стоит €320 за ноду независимо от количества процессоров на ней). В лицензию входит год бесплатных обновлений, а со второго года они будут предоставляться в рамках пакета обновлений стоимостью €880 в год за весь кластер.

Рассмотрим по каким схемам пользователи VMmanager Cloud реализовывали кластеры высокой доступности.

FirstByte

1. Возможность предоставления виртуальных машин на KVM;
2. Наличие интеграции с Ceph;
3. Наличие интеграции с биллингом подходящим для предоставления имеющихся услуг;
4. Доступная стоимость лицензий;
5. Наличие поддержки производителя.

Отличительные черты кластера:

• Передача данных основана на технологии Ethernet и построена на оборудовании Cisco.
• За маршрутизацию отвечает Cisco ASR9001; в кластере используется порядка 50000 IPv6 адресов.
• Скорость линка между вычислительными нодами и коммутаторами 10 Гбит/с.
• Между коммутаторами и нодами хранилища скорость обмена данными 20 Гбит/с, используется агрегирование двух каналов по 10 Гбит/с.
• Между стойками с нодами хранилища есть отдельный 20-гигабитный линк, используемый для репликации.
• В узлах хранилища установлены SAS-диски в связке с SSD-накопителями.
• Тип хранилища - Ceph.

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

FirstVDS

К использованию VMmanager Cloud компания пришла из следующих соображений:

1. Большой опыт работы с продуктами ISPsystem.
2. Наличие интеграции с BILLmanager по умолчанию.
3. Отличное качество техподдержки продуктов.
4. Поддержка Ceph.

• Передача данных основана на сети Infiniband со скоростью соединения 56 Гбит/с;
• Infiniband-сеть построена на оборудовании Mellanox;
• В узлах хранилища установлены SSD-носители;
• Используемый тип хранилища - Ceph.

В случае общего отказа Infiniband-сети связь между хранилищем дисков ВМ и вычислительными серверами выполняется через Ethernet-сеть, которая развёрнута на оборудовании Juniper. “Подхват” происходит автоматически.

Благодаря высокой скорости взаимодействия с хранилищем такой кластер подходит для размещения сайтов со сверхвысокой посещаемостью, видеохостинга с потоковым воспроизведением контента, а также для выполнения операций с большими объёмами данных.

Эпилог

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

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