Высокая доступность — это то, что любят демонстрировать в цифрах. Все уже привыкли к маркетинговым ходам и доступность в 99% кажется просто фантастически высокой. Лишь малая часть клиентов понимают, что доступность 98- 99% это очень плохая, местами никуда не годная цифра.
Посмотрите на эти цифры и вы поймете, чем доступность в 90% отличается от доступности в 99,999%:
| Доступность | Время простоя в месяц | Время простоя в год |
| 90% | 3 дня | 37 дней |
| 98% | 14,6 часов | 7,3 дня |
| 99% | 7,3 часа | 3,7 дней |
| 99,8% | 1,5 часа | 18 часов |
| 99,9% | 44 минуты | 8.8 часов |
| 99,99% | 4.4 минуты | 53 минуты |
| 99,999% | 26 сек | 5,3 минуты |
Посмотрев на таблицу выше вы понимаете, что датацентр, гарантирующий сетевую доступность в 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%, необходимо заниматься отказоустойчивостью. И сервер должен быть не один. Но это тема отдельного разговора.
Соглашение об уровне сервиса – документ, описывающий уровень оказания услуг, ожидаемый клиентом от поставщика, основанный на показателях, применимых к данному сервису, и устанавливающий ответственность поставщика, если согласованные показатели не достигаются.
Грубо говоря, если у вас отключают интернет дома, то в конце концов вы плюнете и пойдете на прогулку, в кино или кабак, в лучшем случае надеясь на перерасчет.
Если же у вас отключается связь в офисе, то у вас останавливаются продажи (клиенты не могут дозвониться и, не дождавшись ответа по почте, уходят к другим поставщикам), бухгалтерия не может проводить платежи (здесь вы подводите уже ваших партнеров), а если вы, скажем, трейдерское бюро, то сумма убытков может достигать тысяч долларов (вы не сможете вовремя купить или сбыть акции).
Здесь может быть лирическое отступление про резервирование каналов и т.д., но у нас перед глазами есть пример – здание комплекса Москва-Сити, в котором пару лет назад неожиданным образом и основной, и резервный канал оказались от одного провайдера. А беда, как известно, не приходит одна. В итоге дважды на 7-8 часов (в рабочее время) оказывались без связи компании из рейтинга «Fortune 500».
Поэтому особо дотошные юридические службы компаний, чей бизнес особо чувствителен к качеству связи, стараются исчислять размер ущерба компании не только стоимостью не потреблённых сервисов, но и выгодой, упущенной клиентом вследствие простоя связи.
Отправные точки
Вот некоторые показатели, в том или ином составе встречающиеся в операторских документах:
ASR (Answer Seizure Ratio)
- параметр, определяющий качество телефонного соединения в заданном направлении. ASR рассчитывается как процентное отношение числа установленных в результате вызовов телефонных соединений к общему количеству совершенных вызовов в заданном направлении.
PDD (Post Dial Delay)
- параметр, определяющий период времени (в секундах), прошедший с момента вызова до момента установления телефонного соединения.
Коэффициент доступности Услуги
- отношение времени перерыва в предоставлении услуг к общему времени, когда услуга должна предоставляться.
Коэффициент потери пакетов информации
- отношение правильно принятых пакетов данных к общему количеству пакетов, которые были переданы по сети за определенный промежуток времени.
Временные задержки при передаче пакетов информации
- промежуток времени, необходимого для передачи пакета информации между двумя сетевыми устройствами.
Достоверность передачи информации
- отношение количества ошибочно переданных пакетов данных к общему числу переданных пакетов данных.
Периоды проведения работ, время оповещения абонентов и время восстановления сервисов.
Иными словами, доступность услуги 99,99% говорит о том, что оператор гарантирует не более 4,3 минут простоя связи в месяц, 99,9% - что услуга может не оказываться 43,2 минуты, а 99% - что перерыв может длиться более 7 часов. В некоторых практиках встречается разграничение доступности сети и предполагается меньшее значение параметра – в нерабочее время. На разные типы услуг (классы трафика) также предусмотрены разные значения показателей. Например, для голоса важнее всего показатель задержки – он должен быть минимальным. А скорость для него нужна невысокая, плюс часть пакетов можно терять без потери качества (примерно до 1% в зависимости от кодека). Для передачи данных на первое место выходит скорость, и потери пакетов должны стремиться к нулю.
Мировые стандарты
В западной практике принято приводить официальный отчет о параметрах сети за последний год. Вот, например, показатели для интернет-канала за май нескольких небезызвестных брендов.
Задержка передачи сигнала (Latency, ms)
| Sprintnet | Verizon | Cable&Wireless | NTT | |||||
| Факт | Стандарт | Факт | Стандарт | Факт | Стандарт | Факт | Стандарт | |
| Европа | 18.9 | 45 | 15.178 | 30 | 17.6 | 35.0 | 24.00 | 35 |
| США | 36.91 | 55 | 42.851 | 45 | 45.9 | 65.0 | 45.83 | 60 |
| Азия | 83.78 | 105 | 100.640 | 125 | 48.3 | 90.0 | 47.34 | 95 |
| Европа-Азия | 207.63 | 270 | - | - | 174.1 | 310.0 | 260.23 | 300 |
| Европа-США | 74.53 | 95 | 78.784 | 90 | 78.7 | 90.0 | 71.57 | 90 |
| Sprintnet | Verizon | Cable&Wireless | NTT | |||||
| Факт | Стандарт | Факт | Стандарт | Факт | Стандарт | Факт | Стандарт | |
| Европа | 0 | 0.3% | 0.025% | 0.5% | 0 | 0.2% | 0 | 0.3% |
| США | 0.01% | 0.3% | 0.019% | 0.5% | 0.1% | 0.2% | 0 | 0.3% |
| Азия | 0 | 0.3% | 0.004% | 1% | 0 | 0.2% | 0 | 0.3% |
| Европа-Азия | 0 | 0.3% | - | - | 0 | 0.2% | 0 | 0.3% |
| Европа-США | 0 | 0.3% | 0 | 0.5% | 0.1% | 0.2% | 0 | 0.3% |
| Sprintnet | Verizon | Cable&Wireless | NTT | |||||
| Факт | Стандарт | Факт | Стандарт | Факт | Стандарт | Факт | Стандарт | |
| Европа | 0.0017 | 2 | 0.026 | 1 | - | - | 0 | 0.5 |
| США | 0.0007 | 2 | 0.058 | 1 | - | - | 0 | 0.5 |
| Азия | 0.0201 | 2 | - | - | - | - | 0 | 0.5 |
| Европа-Азия | 0.0001 | 2 | - | - | - | - | 0 | 0.5 |
| Европа-США | 0.0001 | 2 | - | - | - | - | 0 | 0.5 |
Sprint подходит к себе более жестко, и если SLA не соблюдается (по крайней мере в отношении ), то клиенту возвращается абонентская плата за весь месяц, в котором была зафиксирована проблема.
В случае недоступности сервиса по вине NTT, оператор устанавливает для себя рамки для выявления и решения проблемы в 15 минут – по истечению которых клиенту возмещают от 1/30 до 7/30 от ежемесячного платежа. Если SLA не соответствует скорость задержки сигнала, клиент может рассчитывать на возврат суточного платежа единоразово.
Наши реалии
В Российском бизнесе трепетно к SLA относятся преимущественно международные бренды. В то же время для столичных клиентов само словосочетание тоже стало знакомым, и даже средние компании порой интересуются этим документом. Здесь хочется отметить, что соглашение об уровне сервиса не заменяет и не отменяет стандартные пункты об ответственности оператора в договоре оказания услуг, а также нормы, установленные законодательством, и подзаконные акты (например, ФЗ «О Связи», Приказ №92 «Об утверждении Норм на электрические параметры основных цифровых каналов и трактов магистральной и внутризоновых первичных сетей ВСС России» и т.д.), которым мы все свято следуем.
В практике Гарс Телеком, в случае возникновения каких-либо «факапов», споры урегулируются в рамках процедуры обработки трабл-тикетов и времени восстановления сервисов. Аварии, повлекшие неработоспособность услуги, должны ликвидироваться от 4 до 72 часов (в зависимости от причины). В случае превышения заданных параметров – абоненту компенсируется каждый дополнительный час простоя, а при достижении оператором пороговых значений – процент компенсации увеличивается.
Из интересных кейсов можно вспомнить магазин музыкальных инструментов, который обвинял нас (оператора) в падении продаж пианино (какое-то время не работал телефон). Тут опять же можно сравнивать с продвинутым клиентоориентированным западом, но лучше обратиться к российской глубинке, где не то что об SLA – вообще понятия «время восстановления сервисов» не существует. В лучшем случае – время реакции – 48 часов. За примерами даже не нужно далеко ходить – 15 км от Санкт-Петербурга – и местный оператор отнекивается от какой-либо ответственности. Говорить за всех региональных операторов было бы некрасиво, но, к сожалению, это скорее правило, чем исключение.
Какие выводы нужно сделать из этих историй
- После драки кулаками не машут – если для бизнеса есть какие-то критичные параметры, нужно подумать какие и оговорить их с оператором на этапе согласования документов
- Показатель, над которым стоит постоянно работать – это время восстановления сервисов и уровень технической поддержки. Потому что когда вообще ничего не работает – это хуже, чем когда работает, но плохо (в этом случае клиент может, по крайней мере, оперативно и безболезненно сменить оператора)
- Позаботиться о резервировании тоже стоит заранее, причем услуга должна быть от независимых операторов, хотя бы один из которых должен быть фиксированным.
Определения
Всем известно , что в Microsoft Exchange DAG означает « Database Availability Group » — «Группа Доступности Базы данных».
База данных — потому что уровень высокой доступности сервера почтовых ящиков Exchange 2010 , определяется базой данных , а не сервером , именно база данных является той единицей , которая может перемещаться между несколькими серверами в пределах группы доступности баз данных в случае сбоя. Этот принцип известен как мобильность базы данных.
Группа — потому что сфера наличия определяется серверами почтовых ящиков в группе обеспечения доступности баз, которые объединены в отказоустойчивый кластер и работают вместе как группа .
Доступность — этот термин , кажется, наименее очевидным и наиболее запутанным . Как ни странно, этот термин имеет прямое математическое определение и играет важную роль в понимании принципов проектирования Exchange в целом .
Википедия определяет
«
доступность» как обозначение одного из следующих действий
:
Степень
, в которой система, подсистема
, или
оборудование
находится в
указанном
рабочем
состоянии, случай отказа, по крайней мере неизвестен
, т.е. случайное
время
. Проще говоря
, доступность — это
доля времени, когда
система
находится в состоянии
функционирования
. Математически это
выражается в
1
минус
недоступность
.
Отношение
(а) общего времени
функционирования
в течение заданного
интервала
к
(б) величине интервала
.
В терминах теории вероятностей , данное определение означает то же : вероятность того, что данная система или компонент «в рабочем состоянии» в любой произвольный момент времени .
Математически это может быть измерено путем подсчета количества времени, когда система доступна («Время работы «) в течение некоторого большого статистически репрезентативного периода (обычно года ), и разделив его на общую длину периода . Используя широко принятые сроки среднее время между отказами (MTBF — Mean Time Between Failures) и среднее время обслуживания (MTTR — Mean Time To Repair) — представляем доступность системы / время работы между отказами, время простоя системы в течение любого данного отказа , — доступность может быть выражена как фракция:
Противоположная математическая характеристика будет вероятность отказа :
Доступность часто выражается как «количество девяток «, в соответствии со следующей таблицей :
| Уровень доступности | Значение доступности | Вероятность отказа | Допустимое время простоя в год |
| Две девятки | 99% | 1% | 5256 минут = 3.65 дня |
| Три девятки | 99.9% | 0.1% | 525.6 минут = 8.76 часов |
| Четыре девятки | 99.99% | 0.01% | 52.56 минут |
| Пять девяток | 99.999% | 0.001% | 5.26 минут |
Конечно , значение доступности будет отличаться в зависимости от того принимаем ли мы во внимание запланированные (плановые) и внеплановые (незапланированные) простои или только незапланированные простои . Соглашение об уровне обслуживания (SLA) , которое выражает бизнес-требования доступности должно содержать конкретную информацию. Но во всех случаях наличие той или иной системы или компонента зависит от многих факторов , и чрезвычайно важно определить и понять эти зависимости и как они влияют на доступность .
Влияние зависимостей на доступность
Доступность базы данных почтовых ящиков Exchange зависит от наличия многих других сервисов и компонентов — например , подсистема хранения, на которой размещена база данных , сервер, на котором работает эта базу данных , подключение к сети этого сервера , и т.д. Все эти важные компоненты , и выход из строя любого из них будет означать отказ сервиса , даже если сама база данных является совершенно работоспособной . Это означает, что для того, чтобы база данных была доступны как служба , каждая зависимость также должна быть доступна . Если мы правильно идентифицируем и изолируем компоненты зависимостей , то можем математически рассчитать , как они определяют результирующий уровень доступности базы данных почтового ящика Exchange.
Для данной
базы данных почтовых ящиков
, следующие компоненты
можно считать, как
критические зависимости
:
дисковая подсистема
базы данных
/
система хранения
—
например A1
;
сервер почтовых ящиков
(как аппаратные, так и программные компоненты
) —
A2
;
сервер клиентского доступа
(аппаратное и программное обеспечение компонентов
) —
помним, что
в
Exchange 2010
все
клиенты подключаются к
базе данных почтовых ящиков
только через
Client Access Server (Сервер с ролью клиентского доступа),
и
давайте предположим,
что CAS
установлен отдельно
от сервера почтовых ящиков
—
A3
;
сетевое подключение
между клиентами и
Client Access Server,
и
между сервером
клиентского доступа
и
сервером почтовых ящиков
—
A4
;
электроэнергия в центре обработки данных
, где расположены серверы
и системы хранения
—
A5.
Этот список можно было бы продолжить … Например , Active Directory и DNS также представляют критическую зависимость для Exchange. Кроме того , в дополнение к чисто технологическим зависимостям , на доступность оказывает влияние таких факторов, как человеческая ошибка , неправильное выполнение стандартных операций обслуживания, отсутствие координации команды техподдержки. Все это может привести к неработоспособности . Мы не будем пытаться компилировать любой исчерпывающий перечень зависимостей , а вместо этого сосредоточимся на том, как они влияют на общую доступность услуг .
Поскольку сами эти компоненты по отдельности независимы друг от друга , наличие каждого из них представляет собой самостоятельное мероприятие , а полученный уровень доступности базы данных почтовых ящиков Exchange представляет собой сочетание всех этих событий (другими словами , для того, чтобы база данных почтовых ящиков была доступна для клиентов все эти компоненты должны доступны ). Из теории вероятностей , вероятность сочетания независимых событий является продуктом отдельных вероятностей для каждого события :
Например, если подбросить три монеты , вероятность выпадения «орла» для всех трех монет (1/2) * (1/2) * (1/2) = 1/8 .
Важно понимать, что , значение доступности не может быть больше чем 1 (или 100% ), и в результате доступность сервиса является продуктом доступности индивидуальных компонентов , значение доступности которых не может быть больше , чем самый низкий из составляющих зависимость доступности.
Это можно проиллюстрировать на примере , представленном в следующей таблице (цифры примерны):
| Критическая зависимость | Вероятность отказа | Уровень доступности |
| Сервер почтовых ящиков и система хранения | 5% | 95% |
| Сервер клиентского доступа | 1% | 99% |
| Сеть | 0.5% | 99.5% |
| Питание | 0.1% | 99.9% |
| 6.51383% | 95% x 99% x 99.5% x 99.9% = 93.48617% |
Из этого примера , можно увидеть, как критически важные зависимости влияют на доступность сервиса. Даже для базы данных почтовых ящиков , которая никогда не выходит из строя (не будет повреждена , никогда не получит никаких вирусных инфекции и т.д.) , доступность до сих пор остается ниже 93,5 %!
Заключение : Большое количество сервисных зависимостей уменьшается доступность .
Все, что мы
сделаем для
уменьшения количества
или
воздействия
зависимостей
положительно скажется
на общей
доступности сервиса
. Например
, мы могли бы улучшить
ситуацию
путем упрощения и
обеспечения
управления серверами
и оптимизации
оперативных процедур
. С технической стороны
, мы можем попробовать
уменьшить количество
сервисных
зависимостей
, сделав наш дизайн
проще — например
, устраняя
сложные
системы хранения на основе SAN
, волоконных
коммутаторов
, контроллеров массива
, и даже RAID
контроллеров
и
заменив его
простым
DAS
с минимумом
движущихся частей
.
Снижение
сервисных
зависимостей
само по себе не
может быть
достаточно, чтобы
довести
доступность
до желаемого уровня
. Еще один очень
эффективный способ
увеличить
доступность и
свести к минимуму воздействие
критических
зависимостей
обслуживания
заключается в привлечении
различных методов
резервирования
, таких как использование двух источников питания
, объединение
сетевых карт
, подключение серверов
к нескольким
сетевым коммутаторам
, используя
RAID
для
операционной системы
, развертывания
аппаратных балансировщиков для серверов
клиентского доступа и
нескольких копий
баз данных почтовых ящиков
. Но как именно
увеличение
избыточности
позволяет достигнуть высокой доступности
? Давайте более подробно
рассмотрим
балансировку нагрузки и
несколько копий базы данных
в качестве важных
примеров
.
Как влияет резервирование на доступность
Концептуально все методы резервирования означают одно : есть более одного экземпляра компонента , который доступен и может быть использован либо одновременно (как с балансировщиками нагрузки ) или в качестве замены (как в случае с несколькими копиями базы данных ). Давайте предположим, у нас есть n экземпляров данного компонента (n серверов в массиве CAS , или n копий баз данных в DAG ). Даже если один из них выходит из строя, другие еще могут быть использованы для обеспечения высокого уровня доступности . Единственная ситуация, когда мы столкнемся с фактическим отказом сервиса, когда все экземпляры перестанут быть доступны.
Как определено ранее , вероятность отказа для любого данного экземпляра Р = 1 — А. Все экземпляры статистически независимы друг от друга , что означает, что работоспособность или выход из строя любого из них не влияет на доступность в других случаях . Например , выход из строя данной копии базы данных не влияет на вероятность отказа для другой копии этой базы данных (возможен логичный нюанс , когда поврежденная копия распространит изменения на другие экземпляры, но давайте игнорировать этот фактор — в конце концов, всегда можно воспользоваться отстроченной копией базы данных или вариантом восстановления средствами традиционного резервного копирования ).
Опять используя ту же теорему теории вероятностей , вероятность отказа набора n независимых компонентов является продуктом вероятностей для каждого компонента . Так как все компоненты здесь идентичные (различные экземпляры того же объекта ):
Очевидно, как P < 1, P n меньше P , что означает, что вероятность отказа уменьшается , и соответственно , доступность увеличивается :
Рассмотрим некоторый реальный пример из жизни для ясности . Скажем , что мы устанавливаем несколько копий базы данных почтовых ящиков ; каждая копия размещается на одном диске SATA . По статистике, процент неудач SATA дисков составляет ~ 5 % в течение года , что дает нам 5 % вероятность отказа : P = 0,05 (что означает наличие 95% : A = 0,95 ). Как изменится доступность по мере добавления копии базы данных ? Посмотрим на следующей таблице :
| Количество копий | Вероятность отказа | Уровень доступности |
| 1 | P 1 = P = 5% | A 1 = 1 – P 1 = 95% |
| 2 | P 2 = P 2 = 0.25% | A 2 = 1 – P 2 = 99.75% |
| 3 | P 3 = P 3 = 0.0125% | A 3 = 1 – P 3 = 99.9875% |
| 4 | P 4 = P 4 = 0.000625% | A 4 = 1 – P 4 = 99.9994% |
Впечатляет
?
В принципе,
каждый
дополнительный экземпляр
базы данных
на
SATA
диск
вводит
коэффициент умножения
5%
или
1/20
, так что вероятность
отказа
становится
в 20 раз
ниже,
с
каждой копии
(и, соответственно
, доступность увеличивается)
. Мы можем
видеть, что
даже
на самых ненадежных
дисках
SATA
, внедряя всего
4
копии баз данных
приносит
нам доступность базы данных
в пять
девяток
.
Это
уже очень хорошо
, но
можем ли сделать
еще лучше?
Можем ли мы
увеличить доступность
еще
, не делая архитектурных изменений
(например, при добавлении
еще одной
копии базы данных
)?
На самом деле
, можем.
Если
нам улучшить
индивидуальную
доступность
любого компонента
зависимости,
он будет
фактором повышения
общей доступности
сервиса
, и
приведет к гораздо
более сильному эффекту, чем
от добавления
избыточного компонента
. Например
, одним из возможных способов сделать это
, является использование
Nearline
SAS
диски
вместо
дисков
SATA
. Диски
Nearline
SAS
имеют годовой
уровень отказов
~
2,75
% вместо ~
5
% для
SATA
. Это уменьшит
вероятность отказа
для компонента
хранения
и
, следовательно, увеличит общую
доступность сервиса
. Достаточно сравнить
эффект от
добавления нескольких
копий базы данных
:
5% Коэффициент
AFR
=
1/20
=
умножение каждого нового
экземпляра
делает повреждение
базы данных
в 20 раз
реже
.
2,75
% AFR
=
1/36
коэффициент умножения
=
каждый новый
экземпляр
делает повреждение
базы данных
в 36
раз реже
.
Это значительное влияние на доступность базы данных, что также объясняет указания использовать концепцию собственной защиты данных Exchange — Exchange Native Data Protection, которая объясняет, что несколько копий базы данных может быть заменой для традиционных резервных копий , если развернуто достаточное количество (три или больше).
Та же логика применима к развертывании нескольких серверов клиентского доступа в массиве CAS , нескольких сетевых коммутаторов и т.д. Предположим, что мы развернули 4 копии базы данных и 4 сервера клиентского доступа , и давайте вернемся к компоненту таблицу доступности , которые мы анализировали ранее :
| Критическая зависимость | Вероятность отказа | Уровень доступности |
| Сервер почтовых ящиков и хранилище (4 копии) | 5% ^ 4 = 0.000625% | 99.999375% |
| Сервер клиентского доступа (4 сервера, развернутых отдельно) | 1% ^ 4 = 0.000001% | 99.999999% |
| Сеть | 0.5% | 99.5% |
| Питание | 0.1% | 99.9% |
| Общее значение (зависит от всех указанных компонентов) | 0.6% | 99.399878% |
Мы можете видеть, что как только мы развернули 4 сервера клиентского доступа и 4 копии баз данных , вероятность отказа от общего обслуживания уменьшилась более чем в 10 раз (с 6,5% до 0,6% ) и, соответственно, доступность услуг увеличилась с 93,5 % до гораздо более приличного значения 99,4 %!
Вывод: Добавление избыточности для зависимостей повышает доступность .
Соединим вместе
Возникает интересный
вопрос
от предыдущих
выводов
. Мы
проанализировали
два различных
фактора, влияющих
на общую
доступность услуг
двумя различными способами
и
нашли два
четких вывода
:
добавление
больше системных
зависимостей
уменьшается
доступность
добавление
избыточности
в
системных
зависимостях
увеличивает
доступность
Что произойдет, если
соединить в решение оба фактора? Какие
тенденции
сильнее?
Рассмотрим следующий сценарий
:
Мы используем
два сервера
почтовых ящиков
в
группе DAG
с
двумя копиями
базы данных почтовых ящиков
(один экземпляр
на каждом сервере
), и
мы используем
два сервера
клиентского доступа
в массиве
с балансировкой нагрузки
. (Для простоты мы будем
рассматривать только
наличие
базы данных почтовых ящиков
для
клиентских подключений
, не рассматривая роль транспортного сервера-концентратора
и
единой системы обмена сообщениями
)
. Если предположить, что
каждый
сервер имеет свою
индивидуальную
вероятность отказа
P
, будет
ли наличие
такой системы
лучше или хуже
, чем от
одного
развернутого автономного
сервера Exchange
с
обеими
ролями сервера
почтовых ящиков
и
клиентского доступа
?
В первом сценарии
, серверы
почтовых ящиков
являются независимыми и
станут недоступны
, только если оба сервера
выйдут из строя.
Вероятность выхода из строя
набора из двух
серверов почтовых ящиков
будет
P
× P
= P
2
. Соответственно
, его доступность
будет
A MBX
= 1 – P 2
. Следуя той же
логике
, служба
CAS
будет недоступна
только
, если оба сервера клиентского доступа
выйдут из строя,
поэтому вероятность
отказа
для
набора из двух
серверов клиентского доступа
будет
снова
P
× P
= P
2
и, соответственно,
его доступность
будет
A CAS
= 1 – P 2
.
В этом случае
, как мы уже
поняли,
два сервера
почтовых ящиков
или
два сервера
клиентского доступа
являются примерами
избыточных
компонентов системы
.
Продолжаем
этот сценарий
.
Для того, чтобы
вся система
была доступна
, оба набора
серверов
(набор серверов почтовых ящиков и
набор
серверов клиентского доступа
) должны быть доступны
одновременно
. Не
выходят из строя одновременно
, но доступны
одновременно
, потому что теперь
они представляют
системные
зависимости
, а не избыточные компоненты
. Это означает,
что в целом
доступность службы
является продуктом
доступности
каждого набора
:
Конечно,
второй вариант
значительно проще,
так как существует
только один сервер
и
рассмотреть его доступность
просто
A
= 1 – P
.
Так что теперь
мы
рассчитали значения
доступности
для обоих сценариев.
Значение которого
выше
, (1-P
2
) 2
или
1-P
?
Если построить графики обеих функций , мы увидим следующее поведение :
Мы видим, что для малого значения Р, наличие комплексной системы из 4 серверов выше, чем от наличия одного сервера. Нет ничего удивительного, это то, что мы ожидали, не так ли? Тем не менее, при Р ~ 0,618 — два участка пересекают, и при больших значениях P единая система сервера на самом деле имеет более высокую доступность. Конечно, вероятнее было бы ожидать, что значение Р должно быть очень близко к нулю в реальной жизни. Однако, если мы планируем создать собственное решение из очень ненадежных компонентов, вероятно, решение в виде одного сервера будет лучше.
Влияние точек отказа
К сожалению, сценарии развертывания, описанные выше, в реальной жизни встречаются редко. Например, как повлияет на изменение доступности при условии развертывания сервера с несколькими ролями? Мы заметили, что в приведенном выше примере, сочетание ролей сервера эффективно снижает количество служебных зависимостей, так что, вероятно, все будет хорошо? А что произойдет, если мы разместим две копии базы данных из одной базы данных на одном массиве SAN или DAS? Что делать, если все серверы почтовых ящиков подключены к одному коммутатору сети? Что делать, если у нас есть все вышеперечисленное и многое другое?
Все эти ситуации сталкивают нас с понятием точки отказа. В приведенных выше примерах серверного оборудования или массив SAN или сетевой коммутатор представляют собой точки отказа. Точка отказа ломает независимость или избыточность компонентов, что он сочетает — например, выход из строя компонентов серверного оборудования в сервере с сочетанием ролей означает, что все роли на этом сервере станут недоступны; соответственно, отказ диска или массива SAN означает, что все копии баз данных, размещенных на данном диске или массиве становятся недоступными.
Но наличие точки отказа не обязательно плохо. Важным отличием является то, что компоненты, составляющие точку отказа — отличаются от зависимостей системы или избыточных компонентов системы. Рассмотрим два из приведенных выше примеров, чтобы понять эту разницу.
Сценарий сервера с мультиролями
Давайте сравним наличие двух различных систем:
1.Роли сервера почтовых ящиков и сервера клиентского доступа, размещенные на том же сервере, который имеет вероятность аппаратных сбоев P;
2.Те же роли размещены на двух отдельных серверов, каждый из которых имеет одинаковую вероятность отказа оборудования.
В первом случае, аппаратные средства одного сервера представляют собой точку отказа. Это означает, что все размещенные роли либо доступны, либо недоступны. Это просто, в целом доступность такой системы A = 1 – P.
Во втором случае, в целом сервис будет доступен только тогда, когда оба сервера доступны независимо (потому как каждая роль представляет собой критическую зависимость). Поэтому, основываясь на теории вероятностей, его наличие будет A × A = A2.
Опять же, как А <1, это означает, что A2 < А, так во втором случае доступность будет ниже.
Судя по всему, мы можем добавить другие роли сервера Exchange (Hub Transport, и единой системы обмена сообщениями при необходимости) по тому же сценарию, не нарушая эту логику.
Вывод: Размещение ролей сервера Exchange на сервере с мультиролью повышает общую доступность услуг.
Сценарий общего хранилища
Теперь давайте рассмотрим другой сценарий точки отказа (две копии базы данных Exchange на одном массиве), и сравним доступность базы данных в следующих двух случаях:
1.Две копии баз данных, размещенных на одном и том же хранилище (массив SAN или DAS), который имеет вероятность отказа P;
2.Те же копии баз данных, размещенные на двух отдельных системах хранения данных, каждая из которых имеет одинаковую вероятность отказа.
В первом случае, общее хранилище представляет собой точку отказа. Как и в предыдущем сценарии, это означает, что обе копии базы данных доступны или недоступны одновременно, так что общий уровень доступности снова A = 1 – P.
Во втором случае, в целом служба будет доступна, если по крайней мере одна система доступна и недоступна только если обе системы выйдут из строя. Системы хранения являются независимыми. Поэтому, вероятность отказа для общего обслуживания P × P = P2 и, соответственно, общая доступность услуг является A = 1 – P2.
Опять же, если P < 1, то это означает, что Р2 <Р, и, следовательно, 1 – P2 > 1 – P. Это означает, что уровень доступности во втором случае гораздо выше.
Вывод: Размещение копий одной базы данных на одной и той же системе хранения уменьшает общую доступность услуг.
Так в чем же разница между этими двумя сценариями, почему введение точек отказа увеличивает доступность в первом случае и снижает доступность в другом?
Это потому, что точка отказа в первом случае сочетает обслуживание зависимостей, эффективно уменьшая их количество и, следовательно, повышает уровень доступности, в то время как точка отказа во втором случае сочетает избыточные компоненты, эффективно уменьшая избыточность и поэтому доступность ухудшается.
Все эти понятия и выводы могут быть, представлены в следующем виде:
Выводы
Архитектура Exchange 2010 предоставляет мощные возможности для добавления избыточности (например, развертывание нескольких копий базы данных или несколько серверов клиентского доступа в массиве CAS ) и уменьшения количества системных зависимостей (путем объединения ролей сервера Exchange или с помощью простой архитектуры хранения без чрезмерного количества критических компонентов ). Простые правила и формулы , представленные в этой статье позволяют рассчитать влияние на стоимость доступности от развертывания дополнительных копий баз данных или из сочетания ролей сервера Exchange. Также можно рассчитать влияние точек отказа. Реальная жизнь редко вписывается в простые базовые сценарии , и понадобятся гораздо более сложные расчеты , чтобы получить разумные оценки уровня доступности реальных систем ; это можно облегчить и просто измерить уровень доступности статистически и проверить , отвечает ли он требованиям SLA . Тем не менее, понимание факторов, влияющих на доступность вместе с сложностью технического решения должно помочь спроектировать решение правильно и достичь значительного увеличения общего уровня доступности служб даже для самых взыскательных бизнес-требований .
|Масштабируемость и высокая доступность становятся всё более популярными с увеличением спроса на надежные и производительные инфраструктуры, предназначенные для обслуживания критически важных систем. Уменьшение времени простоя и устранение единых точек отказа – такие же важные проблемы, как и обработка повышенной нагрузки на систему. Высокая доступность (high availability) – качество инфраструктуры, способное устранить их.
Данная статья рассказывает, что именно значит термин «высокая доступность» и как это качество может сделать инфраструктуру более надёжной.
Высокая доступность
В программировании термин «доступность» (availability) используется для описания интервала времени, в течение которого сервис доступен, а также времени, необходимого системе для ответа на запрос пользователя. Высокая доступность – это качество системы или компонента, которое обеспечивает высокий уровень эксплуатационных характеристик за определенный период времени.
Измерение доступности
Доступность часто выражается в процентах, что обозначает уровень аптайма, который ожидается от конкретной системы или компонента за конкретный период времени. В таком случае 100% доступности значит, что система никогда не выходит из строя; соответственно, система, которая обеспечивает 99% доступности в течение одного года, может иметь до 3,65 дней простоя (1%).
Эти значения вычисляются на основе нескольких факторов, включая плановое и внеплановое техническое обслуживание, а также время, необходимое для устранения возможного сбоя системы.
Как работает высокая доступность?
Высокая доступность используется в качестве механизма быстрого реагирования на сбои. Этот механизм довольно прост, но, как правило, требует специализированного программного обеспечения и конфигурации.
Когда необходима высокая доступность?
Минимизация времени простоя и перебоев в обслуживании очень важна при создании отказоустойчивых систем для производства. Независимо от того, насколько надежно системное и программное обеспечение, в системе могут возникнуть проблемы, которые приведут к сбою в работе приложения или сервера.
Внедрение высокой доступности инфраструктуры – хорошая стратегия для снижения вероятности возникновения и минимизации влияния этих событий. Высоко доступные системы могут автоматически выполнить восстановление сервера или компонента после сбоя.
Что делает систему высоко доступной?
Одной из целей высокой доступности является устранение единых точек отказа в инфраструктуре. Единая точка отказа – это компонент стека, отказ которого выводит из строя всю систему или вызывает недоступность данных; то есть любой компонент, который является необходимым условием для работы приложения, считается единственной точкой отказа.
Чтобы устранить единые точки отказа, нужно подготовить каждый слой стека к избыточности. Для примера давайте представим, что у вас есть инфраструктура, состоящая из двух одинаковых избыточных веб-серверов с балансировщиком нагрузки. Трафик, поступающий от клиентов, будет равномерно распределен между веб-серверами, но если один из серверов выйдет из строя, балансировщик нагрузки будет перенаправлять весь трафик на оставшийся веб-сервер.
В данной ситуации веб-сервер не является единой точкой отказа, потому что:
- В кластере существует «запасной» компонент, способный взять на себя все задачи.
- На другом уровне существует механизм (балансировщик нагрузки), способный обнаруживать сбои в компонентах и адаптировать свое поведение для своевременного восстановления работы приложения.
Но что если из строя выйдет балансировщик нагрузки?
В описанном сценарии (который довольно часто встречается) единой точкой отказа является именно балансировщик нагрузки.
Устранить эту точку отказа не так уж просто. Конечно, можно легко настроить дополнительный балансировщик нагрузки для обеспечения избыточности, однако в системе уровнем выше балансировщиков нагрузки не существует компонента, который мог бы взять на себя обнаружение сбоя и восстановление работы.
Одна только избыточность не может гарантировать высокой доступности.
Для обнаружения и устранения сбоев в инфраструктуре должен существовать специальный компонент.
Обнаружение и устранение сбоев можно реализовать методом top-to-bottom: верхний слой отслеживает сбои нижнего слоя. Вернёмся к нашему примеру; в таком кластере балансировщик нагрузки – это верхний слой. Если один из веб-серверов (нижний слой) станет недоступным, балансировщик нагрузки перестанет перенаправлять на него запросы.
Такой подход достаточно прост, но он имеет свои ограничения: в инфраструктуре всегда будет точка, для которой верхний слой отсутствует либо недоступен (как в случае с балансировщиком нагрузки). Создание сервиса обнаружения неисправностей для балансировщика нагрузки на внешнем сервере равно созданию новой единой точки отказа.
При таком сценарии необходим распределенный подход. Нужно соединить в кластер несколько дублирующих нод, где каждая нода будет в равной степени способна к обнаружению и устранению сбоя.
Однако в случае с балансировкой нагрузки есть дополнительная сложность, связанная с работой серверов имен. Восстановление после сбоя балансировки нагрузки, как правило, означает переход балансировки на другой (избыточный) ресурс, а для этого нужно изменить DNS (указать доменное имя или IP-адрес резервного балансировщика нагрузки). Такие изменения могут занять значительное количество времени и повлечь за собой большой период простоя.
В такой ситуации можно использовать балансировку по алгоритму round-robin. Однако этот подход не является надежным, поскольку аварийное переключение будет на клиентской стороне приложения.
Более надёжным и отказоустойчивым решением являются системы, поддерживающие гибкие ip-адреса. При необходимости IP-адрес модифицируется, что препятствует распространению неисправности и её кэшированию. При этом доменное имя может оставаться связанным с тем же IP-адресом, а сам IP-адрес перемещается между серверами.
Какие компоненты необходимы для поддержки высокой доступности?
Для настройки высокой доступности необходимо установить несколько системных компонентов. Однако гораздо сильнее высокая доступность зависит от таких факторов:
- Окружение: если все серверы кластера расположены в одной географической области, внешние условия (землетрясения, наводнения и т.п.) могут привести к полному сбою системы. Наличие серверов в разных датацентрах и географических областях повысит отказоустойчивость.
- Аппаратное обеспечение: высоко доступные серверы должны быть устойчивы к перебоям в подаче электроэнергии и сбоям оборудования, включая жесткие диски и сетевые интерфейсы.
- Программное обеспечение: весь программный стек (в том числе операционная система и само приложение) должен быть готов к обработке случайных сбоев, которые могут потребовать перезапуска системы.
- Данные: потеря и несоответствие данных может быть обусловлено несколькими факторами. Высоко доступные системы должны принимать во внимание необходимость защиты данных на случай сбоя.
- Сеть: незапланированные отключения сети представляют собой еще одну возможную точку отказа для высоконадежных систем. Важно иметь на такой случай запасную стратегию сети.
Какое программное обеспечение необходимо для высокой доступности?
Каждый слой системы с высокой доступностью будет иметь разные потребности. На уровне приложения балансировка нагрузки является неотъемлемым компонентом в системе с высокой доступностью.
(High Availability Proxy) – популярное средство для настройки балансировки нагрузки, так как позволяет обрабатывать нагрузку на нескольких уровнях, а также для различных видов серверов, включая серверы баз данных.
Также в системный стек важно внедрить надёжное средство для точки входа в приложение. Чтобы устранить единую точку отказа, как упоминалось ранее, необходимо реализовать кластер балансировки нагрузки с гибкими IP-адресами. Для создания таких систем используются Corosync и Pacemaker.
Заключение
Высокая доступность – очень важный аспект надёжности инфраструктуры, ориентированный на обеспечение высокого уровня эксплуатационных характеристик в течение определенного периода времени. На первый взгляд реализация высокой доступности может показаться довольно сложной, однако она может принести много пользы системе, требующей повышенной надежности.
Tags:Описанные выше метрики можно использовать при заключении соглашений о доступности сервиса с заказчиками. Эти договоренности входят составной частью в Соглашения об Уровне Сервиса. Приведенная ниже формула помогает определить, отвечает ли достигнутый Уровень Доступности согласованным требованиям:
Рис. 14.6. Формула доступности (источник: OGC)
Достигнутое время работоспособности системы равно разнице между согласованным временем работоспособности и случившемся временем простоя. Например: если была достигнута договоренность о 98% доступности сервиса в рабочие дни с 7.00 до 19.00 и в течение это периода был двухчасовой отказ сервиса, то достигнутое время работоспособности (процент доступности) будет равен:
(5x12- 2)/(5 х 12) х 100% = 96,7%
Анализ простоев системы (SOA)
Данный метод можно использовать для выяснения причин сбоев, изучения эффективности ИТ-организации и ее процессов, а также для представления и реализации предложений по усовершенствованию сервиса.
Характеристики метода SOA:
Широкая сфера действия: он не ограничивается инфраструктурой и охватывает также процессы, процедуры и аспекты корпоративной культуры;
Рассмотрение вопросов с точки зрения заказчика;
Совместная реализация метода представителями заказчика и ИТ-организации (команда метода SOA).
К числу преимуществ данного метода относятся эффективность подхода, прямая связь между заказчиком и поставщиком и более широкая область для предложений по улучшению сервиса.
Пост технического наблюдения (ТОР)
Данный метод заключается в наблюдении специальной командой ИТ-специалистов одного выбранного аспекта доступности. Его можно использовать в тех случаях, когда обычные средства не обеспечивают достаточной поддержки. Метод ТОР позволяет объединить знания проектировщиков и руководителей систем.
Расчеты доступности сервиса
Основным достоинством данного метода является рациональный, эффективный и неформальный подход, который быстро дает результат.
Программное обеспечение автоматизации процессов itil
- Bmc software
- Computer associates
- Hewlett-packard
- Microsoft
Bmc software
Компания BMC Software - всемирно известный разработчик и поставщик средств администрирования сетей, приложений, баз данных, ERP- и CRM-систем, повышающих доступность, производительность и восстанавливаемость критических бизнес-приложений и данных. Продукты BMC доступны для широкого спектра платформ, включая различные реализации и версии UNIX, Windows, OS/2, OS/390, OpenVMS и NetWare. Из характерных для продуктов BMC особенностей в первую очередь следует отметить ориентацию на поддержку соглашений об уровне обслуживания пользователей (Service Level Agreement, SLA) и построение модели функционирования, направленной на реализацию такого соглашения, а также их высокую производительность (рис. 1). Компания предлагает следующие семейства продуктов для управления ИТ-инфраструктурой:
- BMC Application Management - средство предназначено для управления производительностью и доступностью бизнес-приложений (включая приложения компаний Oracle и SAP) и серверных продуктов (таких, как Microsoft Exchange и J2EE-серверы BEA WebLogic, IBM WebSphere и др.);
- BMC Database Management - средство для администрирования, управления производительностью и восстановлением баз данных, управляемых СУБД ведущих производителей - Oracle, IBM, Microsoft, Sybase;
- BMC Infrastructure Management - средство для управления операционными системами серверов и мэйнфреймов, хранилищами данных, сетями, аппаратным обеспечением, ПО промежуточного звена, а также для оптимизации производительности указанных категорий программного обеспечения;
- BMC Operations Management - средство для выполнения рутинных операций по расписанию и для составления отчетов о событиях в сети;
- BMC Remedy Service Management - средство для поиска, обнаружения, моделирования сбоев в приложениях и реагирования на них;
- BMC Security Management - средство для управления правами доступа пользователей к приложениям и корпоративным ресурсам.
Данные приложений BMC могут храниться в базе данных о конфигурациях BMC Atrium CMDB (Configuration Management Database), обладающей удобными средствами визуализации данных.
Bmc software
Отметим, что продукты BMC включают документированный прикладной программный интерфейс, позволяющий создавать на их основе собственные решения и осуществлять интеграцию средств BMC с другими приложениями.
Рис. 1. Области управления ИТ-инфраструктурой, охватываемые продуктами BMC
Computer associates
Семейство продуктов Unicenter для управления ИТ-инфраструктурой компании Computer Associates (CA) можно адаптировать для применения практически в любой вычислительной среде.
В состав данного семейства входят следующие продукты:
- Unicenter Asset Management - инструмент для автоматизации управления ИТ-активами предприятия, с помощью которого осуществляется комплексный учет и контроль ИТ-ресурсов. Функциональность системы Unicenter Asset Management способствует повышению качества управленческих решений, связанных с ИТ-активами предприятия, и уменьшению сопутствующих рисков. Unicenter Asset Management обеспечивает мониторинг использования приложений на серверах, персональных компьютерах и других клиентских устройствах. Кроме того, этот продукт позволяет автоматизировать процессы управления ИТ-активами, включая учет и инвентаризацию программных и аппаратных средств, работающих в сети предприятия, обслуживание различных составляющих ИТ-инфраструктуры, администрирование лицензий и формирование отчетов в гетерогенных средах (рис. 2);
Рис. 2. Области интегрированного управления ИТ-инфраструктурой, охватываемые продуктами Computer Associates
- Unicenter Software Delivery - обеспечивает автоматизацию процессов развертывания и обновления программного обеспечения на настольных, мобильных и карманных компьютерах, а также на серверах в гетерогенных сетевых средах, включая доставку приложений, распространение исправлений и обновлений, управление системными конфигурациями и откат инсталляций на различных программных и аппаратных платформах. Данный продукт создает условия для повышения оперативности работы ИТ-служб и снижения расходов на информационную поддержку бизнеса за счет автоматизации ИТ-процессов и внедрения каталогов приложений с развитыми возможностями самообслуживания. Одним из ключевых преимуществ Unicenter Software Delivery является высокая степень автоматизации процессов установки и обслуживания ПО и гибкое и детальное управление разрешениями на доставку приложений;
- Unicenter Remote Control - это надежная и защищенная корпоративная система удаленного управления Windows-компьютерами. Перечень задач удаленного управления включает обслуживание удаленных сервисов, таких как сетевые приложения, администрирование серверов и удаленное управление компьютерами конечных пользователей (например, при оказании технической поддержки). Эта система является одним из лучших отраслевых решений в своем классе и обеспечивает централизованное обслуживание систем, управление на основе политик, разграничение прав доступа, аудит сеансов и развитые возможности администрирования. Unicenter Remote Control полностью отвечает запросам крупных предприятий в части удаленного управления и позволяет оператору одновременно выполнять сразу несколько задач: копировать файлы на удаленный компьютер, общаться с пользователем, запускать приложения, наблюдать и фиксировать пользовательские действия, а также управлять параметрами настройки и безопасности. Отметим, что при разработке Unicenter Remote Control особое внимание было уделено сокращению сроков внедрения и освоения системы.
Hewlett-packard
HP OpenView представляет собой комплекс программных продуктов, ориентированных на управление корпоративными информационными технологиями любого масштаба - от небольших систем на базе Windows-серверов до крупных распределенных систем на базе различных версий UNIX, Linux и Windows, содержащих несколько тысяч компьютеров. В данный комплекс входят средства управления сетями, операционными системами, приложениями, а также их производительностью, копированием и хранением данных, сервисами.
Портфель программных решений HP OpenView состоит из нескольких семейств продуктов (рис. 3), среди которых средства управления серверами и приложениями, хранением данных, сетями, Интернет-технологиями и телекоммуникационным оборудованием (существует спектр продуктов HP OpenView, предназначенный специально для телекоммуникационных компаний, и сегодня НР является наиболее известным поставщиком средств управления телекоммуникационным оборудованием). Отдельно отметим наличие в портфеле решений HP средств управления ИТ-услугами.
Рис. 3. Портфель программных решений HP OpenView для ИТ-подразделений
К средствам управления серверами и приложениями следует отнести в первую очередь HP OpenView Operations for Windows и HP OpenView Operations for Unix . Эти продукты предназначены для мониторинга и управления производительностью приложений, а также для осуществления контроля событий в сети и приложениях. HP OpenView Operations for Windows интегрируется со средствами управления сетевой инфраструктурой HP OpenView Network Node Manager , что позволяет производить автоматический поиск новых серверов, добавленных в сеть, а затем выполнять автоматическое развертывание требующихся компонентов и политик на основе результатов поиска сервисов.
Hewlett-packard
Для управления производительностью приложений в состав указанного семейства входят средства HP OpenView Performance Manager и Performance Agents , позволяющие с помощью единого интерфейса осуществлять централизованный мониторинг, анализ и прогнозирование использования ресурсов в распределенных и неоднородных средах, а также HP OpenView Performance Insight, помогающий осуществлять мониторинг событий в сети и приложениях, анализировать их. Решения HP OpenVew Report Packs и HP OpenView Reporter предназначены для создания отчетов о работе распределенной IT-инфраструктуры предприятия на основе данных, полученных от приложений HP OpenView.
Для управления идентификацией и доступом к ИТ-ресурсам в состав семейства HP OpenView входят продукты HP OpenView Select Identity, HP OpenView Select Access и HP OpenView Select Federation , а для управления резервным копированием и восстановлением данных серверных СУБД - HP OpenView Storage Data Protector . Последний из названных продуктов является решением корпоративного уровня для защиты данных и восстановления систем в чрезвычайных ситуациях, реализующим технологию мгновенного восстановления, а также альтернативные варианты аварийного восстановления для устранения внеплановых простоев, что позволяет восстановить работоспособность информационной системы за несколько минут.
Отметим также наличие в данном семействе продуктов, предназначенных для осуществления взаимодействия с конечными пользователями с целью улучшения качества их обслуживания, - HP OpenView Service Desk , а также средства мониторинга бизнес-процессов HP OpenView Business Process Insight и средства управления архитектурой, ориентированной на сервисы, - HP OpenView Service Oriented Architecture Manager .
Hewlett-packard
Для управления Интернет-сервисами в данном семействе продуктов предусмотрено решение HP OpenView Internet Services , позволяющее осуществлять внешнее зондирование прикладных служб, Интернет-сервисов и протоколов посредством моделирования запросов пользователей к каталогам, почтовым службам, веб-службам, сервисам удаленного доступа (в том числе коммутируемого и беспроводного доступа).
Семейство продуктов IBM Tivoli, предназначенных для управления приложениями предприятий различного масштаба, основано на наборе базовых компонентов, из которых строится решение для конкретного предприятия. Главной отличительной особенностью данного семейства продуктов является так называемое упреждающее управление IT-инфраструктурой, способное выявлять и устранять неисправности еще до их возникновения. Продукты семейства Tivoli доступны для платформ AIX, HP-UX, Sun Solaris, Windows, Novell NetWare, OS/2, AS/400, Linux, z/OS, OS/390. Отметим, что в последнее время IBM рекомендует внедрять продукты семейства Тivoli с целью следования методикам библиотеки ITIL (Information Technology Infrastructure Library), сместив акцент в позиционировании своих продуктов с управления ИТ-ресурсами и системами на управление ИТ-услугами (рис. 4).
Рис. 4. Некоторые из программных продуктов Tivoli, поддерживающих ITIL-процесс управления услугами
Семейство продуктов Tivoli включает решения для управления конфигурацией и операционной поддержки:
- IBM Tivoli Configuration Manager - позволяет управлять установкой и обновлением ПО, в том числе и на карманные компьютеры;
- IBM Tivoli License Manager - предназначено для инвентаризации программного обеспечения;
- IBM Tivoli Remote Control - позволяет устанавливать политики для управления IT-ресурсами предприятия и удаленно администрировать настольные системы;
- IBM Tivoli Workload Scheduler - дает возможность автоматизировать рабочие нагрузки.
Помимо средств управления конфигурациями, семейство продуктов Tivoli включает решения для управления производительностью и доступностью:
- IBM Tivoli Monitoring - для осуществления распределенного мониторинга различных систем, автоматического обнаружения и устранения проблем и анализа тенденций;
- IBM Tivoli Monitoring for Databases (поддерживаются СУБД производства IBM, Oracle и Microsoft) и Tivoli Manager for Sybase - для централизованного управления серверами и базами данных;
- IBM Tivoli Monitoring for Web Infrastructure - для управления web-серверами и серверами приложений;
- IBM Tivoli Monitoring for Applications - для управления бизнес-приложениями SAP;
- IBM Tivoli Analyzer для Lotus Domino 6.0 и IBM Tivoli Monitoring for Transaction Performance - для обнаружения проблем производительности систем, основанных на серверных продуктах самой IBM;
- IBM Tivoli Web Site Analyzer - для анализа трафика посетителей, статистики посещаемости страниц, целостности информационного наполнения web-сайта;
- IBM Tivoli Service Level Advisor - для обеспечения упреждающего управления и прогнозирования отказов посредством количественного анализа производительности;
- IBM Tivoli NetView - для управления сетью;
- IBM Tivoli Switch Analyzer - для обнаружения и заполнения всех коммутаторов сетевого уровня;
- IBM Tivoli Enterprise Console - для многоуровневого поиска причин неисправностей и анализа событий.
Кроме того, имеется ряд решений для автоматизированного управления распределением ИТ-ресурсов и пиковыми нагрузками.
В состав семейства Tivoli входят также продукты для обеспечения безопасности:
- IBMDirectory Server - для синхронизации данных о безопасности в масштабе всех используемых приложений;
- IBM Directory Integrator - для интеграции идентификационных параметров, содержащихся в каталогах, базах данных, системах коллективной работы и бизнес-приложениях;
- IBM Tivoli Identity Manager и IBM Tivoli Access Manager for Operating Systems - для управления доступом к приложениям и операционным системам;
- IBM Tivoli Risk Manager - для централизованного управления защитой сети.
Помимо этого семейство Tivoli включает широкий спектр продуктов для управления резервным копированием и системами хранения данных.
Microsoft
Хотя сегодня Microsoft и не является лидером рынка средств управления ИТ-инфраструктурой, средства управления приложениями производства этой компании применяются в нашей стране достаточно широко.
Основное назначение средств Microsoft Microsoft Systems Management Server (SMS) и Microsoft Operations Manager (MOM), а также средств администрирования, доступных пользователям последних версий серверных операционных систем Microsoft (таких, как Automated Deployment Services, Remote Installation Services, Microsoft Group Policy Management Console, Microsoft Windows Update Services), - управление программным обеспечением, автоматическая установка операционных систем Microsoft и предназначенных для них приложений, автоматическая доставка обновлений, управление доступом и правами пользвателей (рис. 5).
Рис. 5. Управление информационными системами с помощью Microsoft Operations Manager и Microsoft Systems Management Server
Microsoft Systems Management Server предназначен для обеспечения автоматического распространения и учета программного обеспечения в крупных распределенных системах на основе операционных систем самой Microsoft, включая планирование с определением оборудования и ПО в локальной сети, проверку, анализ, внедрение бизнес-приложений для различных целевых групп пользователей, установку приложений на вновь появившиеся рабочие места в соответствии с правами пользователя. Данный продукт позволяет осуществить целевую установку различного ПО для разных групп пользователей, а также решать проблемы, связанные с инвентаризацией ПО и с контролем над использованием ПО и аппаратных ресурсов за счет сбора информации об установленных в сети программных продуктах и оборудовании и об их использовании.
Microsoft
Microsoft Operations Manager предназначен для выявления и устранения неполадок в работе сети, оборудования и приложений за счет прямого мониторинга происходящих событий, а также состояния и производительности сетевых ресурсов и выдаче предупреждений о потенциальных проблемах (рис. 6).
Рис. 6. Мониторинг состония серверов с помощью Microsoft Operations Manager
Для управления ИТ-инфраструктурой небольших компаний или специализированными группами серверов (до 10 шт.) предназначен продукт Microsoft Operations Manager 2005 Workgroup Edition . Он позволяет выявить потенциальные опасности в функционировании программного обеспечения и благодаря встроенным средствам анализа предотвратить перерастание их в серьезные проблемы, повысить эффективность ИТ-операций, упростить поддержку гетерогенных платформ и приложений, а также создавать собственные пакеты обновления.
Кроме того, существуют отдельные решения для управления произвоительностью и для анализа событий для компонентов ИТ-инфраструктуры, основанной на серверных продуктах Microsoft, такие как Active Directory Management Pack - для отслеживания состояния службы каталогов Active Directory, Exchange Management Pack - для управления сервисами обмена сообщениями и хранилищами данных Exchange, а также ряд других продуктов. Для обеспечения взаимодействия со средствами управления ИТ-инфраструктурой производства других компаний имеется продукт MOM Connector Framework , позволяющий осуществлять двунаправленную трансляцию предупреждений и синхронизацию данных с помощью web-служб.
Управление иб
- Cobit - «цели контроля для информации и связанных с ней технологий»
- Читать раздел 1
- Читать раздел 1
- Читать раздел 1
- Читать раздел 1
Стандарт «Цели контроля для информации и связанных с ней технологий» (CobiT), сейчас уже в третьем издании, помогает реализовать многочисленные потребности в области управления, формируя взаимосвязи между бизнес-рисками, требованиями контроля и техническими вопросами. Это позволяет сформировать хорошую практику управления ИТ во всех группах процессов в рамках стандарта, также описать виды ИТ-деятельности в виде управляемой и логически выстроенной структуры. «Хорошая практика» по CobiT – это согласованные рекомендации экспертов, которые помогают оптимизировать инвестиции в информатизацию и предоставляют систему показателей, на которые можно ориентироваться в случае возникновения внештатных ситуаций.
Основная концепция CobiT состоит в том, что при осуществлении контроля ИТ информация рассматривается как продукт, необходимый для поддержания целей или требований бизнеса и как результат совместного применения ИТ и связанных ресурсов, которые должны управляться ИТ-процессами.
Стандарт CobiT включает в себя следующую серию книг:
1. Краткое изложение для руководства.
2. Основы.
3. Цели контроля (детализированных целей - 318 штук)
4. Руководство по управлению.
5. Руководство по проведению аудита.
6. Методики внедрения.
Стандарт CobiT выделяет 34 ИТ-процесса, объединенные в четыре следующие группы (рисунок 1.1):
1. Планирование и организация – процессы, охватывающие вопросы стратегии и тактики, а также определения путей развития ИТ, лучше всего способствующих достижению бизнес-целей.
2. Приобретение и внедрение – процессы, охватывающие вопросы разработки и приобретения решений ИТ, которые должны быть интегрированы в бизнес-процесс. Изменение существующих систем.
Cobit - «цели контроля для информации и связанных с ней технологий»
3. Эксплуатация и сопровождение – процессы, фактически предоставляющие требуемые услуги.
4. Контроль – процессы управленческого надзора и независимой оценки с привлечением внутреннего и внешнего аудита или других источников.
Для каждого из 34 ИТ-процессов определена одна цель контроля уровня ИТ-процессов (намерение или желаемый результат, который достигается посредством внедрения процедур контроля в ИТ-деятельность). Данные цели контроля в дальнейшем разбиваются на детализированные цели контроля. Таких детализированных целей в стандарте CobiT определено 318.
Рисунок 1.1. ИТ-процессы CobiT
Согласно CobiT, ИТ-процессы используются для обеспечения следующих 7 требований к информации (частично перекрывающих друг друга).
1. Полезность – информация является актуальной и соответствует БП, своевременно поставляется, непротиворечива и пригодна для использования.
2. Эффективность – предоставление информации на основе оптимального использования ресурсов.
3. Конфиденциальность – защита информации от НСД.
4. Целостность – точность и полнота информации в соответствии с бизнес-ценностями и ожиданиями.
5. Доступность – информация доступна по требованию БП в настоящее время и в будущем.
6. Соответствие требованиям – соответствие требованиям законодательства, регулирующих органов и договорных обязательств, которым подчиняются БП.
7. Достоверность – обеспечение руководства необходимой информацией для осуществления управления организацией и исполнения им обязанностей в отношении финансовой деятельности и представления отчетности регулирующим органам.
Cobit - «цели контроля для информации и связанных с ней технологий»
Цели контроля ИТ-процессов могут обеспечивать выше перечисленные требования к информации и быть основными либо второстепенными.
CobiT определяет также ИТ-ресурсы, которые задействованы в обеспечении выше указанных требований к информации. Выделено 5 классов ИТ-ресурсов:
1. Данные – информационные объекты в широком смысле, в том числе неструктурированные, графика, звук.
2. Приложения – совокупность ручных и программных процедур.
3. Технология – аппаратное обеспечение, ОС, СУБД, сети, мультимедиа, и т.д.
4. Инфраструктура – все ресурсы для размещения и поддержки ИС.
5. Персонал – включает в себя персонал и его навыки, осведомленность и умение планировать, организовывать, приобретать, поставлять, обслуживать и контролировать ИС и услуги.
Цели контроля ИТ-процессов, связь их с требованиями к информации и ИТ-ресурсами представлены на рисунке 1.2.
Рисунок 1.2. Цели контроля ИТ-процессов
Таким образом, для каждой цели контроля определяются определены основные и второстепенные требования к информации, которые они поддерживают. Также определено, какие ресурсы задействованы при обеспечении данных требований.
В книге CobiT «Руководство по управлению» вводится модель уровня развития процессов организации с оценкой уровня развития от 0 (не существующего) до 5 (оптимизированного). Данная модель зрелости в дальнейшем используется при проведении аудитов ИТ-процессов и ответа на вопрос – в какой степени ИТ-процессы соответствуют необходимым требованиям. С этой точки зрения CobiT имеет хорошие точки соприкосновения с банковским стандартом России.
В CobiT для каждого из 34 процессов вводятся ключевые показатели достижения цели. Они определяют контрольные показатели, которые постфактум сигнализируют руководству о достижении процессом ИТ требований бизнеса. Эти контрольные показатели обычно выражены такими требованиями к информации как:
Cobit - «цели контроля для информации и связанных с ней технологий»
Доступность информации необходимой для обеспечения потребностей бизнеса.
Отсутствие рисков для целостности или конфиденциальности.
Рентабельность процессов и эксплуатации.
Подтверждение надежности, полезности и соответствия требованиям.
Для каждого из 34 процессов вводятся ключевые показатели деятельности - которые свидетельствуют о том, насколько хорошо ИТ-процесс выполняет свои функции и служит достижению поставленных целей. Они являются главными показателями того, насколько поставленные цели могут быть вообще достигнуты, а также хорошими показателями существующих возможностей, практики и навыков.
Для каждого из 34 ИТ-процессов определена качественная шкала (0-5), которая указывает – в каком случае процесс нужно относить к определенной модели уровня развития.
В книге CobiT «Руководство по проведению аудита», для каждого из 34 процессов определено, каким образом оценивать уровень его соответствия установленным требованиям. Для каждого из них определены:
1. Лица организации, которых следует опросить при проведении аудита.
2. Информация и документы, которые нужно получить от опрашиваемых лиц.
3. Факторы, которые требуется оценить (вида опросного листа).
4. Факторы, которые требуется протестировать (проверить).
В книге CobiT «Методики внедрения» говорится о том, на кого надо повлиять для внедрения COBIT в организации, дается план мероприятий по внедрению COBIT. Даются опросные листы для персонала, используемые на этапе внедрения, для внутренней оценки корпоративного управления ИТ, внутренней диагностики руководства. Приведены формы по аудиту и оценке риска.