Расчет доступности системы. Что такое высокая доступность? Преимущества использования процесса

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

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

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

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

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

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

Владимир Курилов, компания «Онланта».

Так разговор дошёл до показателей надёжности. И вёлся он вокруг сравнения уровней доступности ЦОДов, в которых располагались облака. Достаточно быстро выяснилось, что только двое кандидатов располагают ЦОДами с уровнем доступности 99,98%. Выбор был сделан в пользу зарубежного провайдера облачных услуг - победила цена. Коллега объяснил всё просто, - «Какой смысл платить больше за те же самые показатели надёжности?»

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

Последовавший за этим решением год эксплуатации, показал, что у провайдера имеют место небольшие сбои в работе инженерных систем ЦОДа, при плановых переключениях. При этом доступность ЦОД оставалась в пределах SLA, так как переключение занимало секунды. Однако, если информационная система заказчика не останавливалась заранее перед такими переключениям, то база данных при сбоях требовала восстановления из резервной копии, что останавливало работу сотрудников на несколько часов. Выключение/включение систем, перед переключениями, немного поправляло ситуацию, но и при этом имел место простой сотрудников 25-30 минут, что тоже вызывало нарекания пользователей.

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

Ответы на эти вопросы я и попробую сформулировать далее.

Надёжность приложения - из чего она складывается в облаке

Надёжность сервиса приложения

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

От чего зависит работоспособность приложения и, как надёжность приложения связана с доступностью ЦОДа?

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

Рис. Упрощённый пример расчёта доступности Сервиса Приложения

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

Доступность такой системы (As) определяется как произведение показателей доступности всех элементов:

A i – доступность каждого последовательно соединённого компонента.
A s = 0,99995 0,99995 0,993 0998 ≈ 0,99091 или 99,091

Как видим, доступность Сервиса Приложения имеет значение, далёкое от доступности инженерной платформы ЦОДа. Можно пересчитать цифры доступности в значения простоя системы. Получается, несмотря на допустимый годовой простой инженерной платформы, в 1 час. 45 мин., для сервиса приложения годовой простой составит 86 ч. 22 мин.

Соответственно, высокий показатель доступности ЦОДа, не говорит о столь же высокой надёжности сервисов приложений, работающих в этом ЦОДе.

Надёжность сетевого приложения

Следовательно, при выборе сервис-провайдеров правильно было бы ориентироваться на совокупную доступность сервисов приложений? К сожалению, тут не всё так просто.

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

Один из вариантов реализации применения специализированных библиотек компанией Microsoft - Transient Fault Handling Application Block (см. http://msdn.microsoft.com/en-us/library/hh680934(v=pandp.50).aspx).

Надёжность программной платформы

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

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

Надёжность инфраструктурной платформы

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

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

Тем не менее:

• Попросите схему функциональной структуры инфраструктурной платформы для размещения именно Вашего Сервиса приложения. Она должна включать:
  • Сетевую инфраструктуры;
  • Сеть хранения данных;
  • Вычислительную инфраструктуру.
• Попросите указать в этой схеме места резервирования оборудования. Указывать тип используемого оборудования нет необходимости.
• Попросите указать доступность (или готовность) для каждого уровня.
• Посчитайте доступность как произведение доступностей элементов инфраструктурной платформы.

Теперь у Вас есть возможность максимально достоверно определить доступность Вашего сервиса приложения. 90% СП в России, исходя из нашего опыта, имеют суммарную доступность не выше 99%. А это риск простоев до 87 часов в год. Это нормальные показатели доступности, если у Вас нет критических для бизнеса приложений, часовой простой которых приносит Вам миллионные убытки. А если часовая остановка сродни катастрофе для Вашего бизнеса, то для Вас есть оставшиеся 10%, СП, предоставляющие сервис корпоративного уровня с доступностью Сервиса приложения на уровне 99,99%. О том, какими способами это достигается в следующем разделе.

Решения, обеспечивающие высокую доступность сервиса приложения

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

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

Есть ли возможность повысить доступность приложения, если параметры доступности конкретного ЦОДа заданы и изменить их нельзя?

Ответ - можно.

Вот, например, два подхода, которые позволяют это сделать:

• Географически распределённый кластер высокой доступности;
• Восстановление обработки в географически удалённом резервном центре обработки данных (Disaster recovery).

Рис. Структурная схема географически распределённого кластера высокой доступности

Рис. Структурная схема для восстановления обработки в географически удалённом резервном центре обработки данных

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

В обоих случаях необходимо говорить о географической удалённости ЦОДов, чтобы максимально избежать возможности взаимосвязанных ресурсов. Например, использования одних и тех же подстанций, обеспечивающих электропитание ЦОДов. Можно вспомнить отключение электричества на юго-востоке г. Москва в мае 2008 года из-за пожара на Чагинской подстанции, New York 2003 год. Поэтому резервный ЦОД должен располагаться подальше от основного.

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

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

Где: A s – Суммарная доступность, доступность всей системы,
A i – доступность каждого параллельно соединённого компонента.

Для примера, рассчитаем систему географически распределённого кластера высокой доступности из двух ЦОДов с доступностью = 99%, каждый.

A s = 1-(1-0,99)*(1-0,99)= 0,9999 или 99,99

Т.е., два не самых надёжных ЦОДа могут обеспечить доступность на уровне mission-critical систем.

Определить доступность сервиса приложения в варианте восстановления обработки в географически удалённом резервном центре обработки данных с 15 минутным интервалом синхронизации для случая единичного сбоя рассчитывается так: надо запросить время восстановления сервиса приложения, гарантируемое СП; далее считаем процент от годового интервала - и результат вычитаем из единицы. Получаем доступность после первого сбоя. Например, для системы с 15 минутным интервалом синхронизации:

Общее количество часов в году 365*24=8760
Гарантированное время простоя = Время максимального простоя
15 минут или 0,25 часа, что составляет ≈ 0,003 от годового времени

Т.е. каждый сбой будет иметь вес в 0,003%. Таким образом, система до сбоя система имеет доступность, равную 100%, после первого сбоя, 99,997%, после второго сбоя 99,994%. Посчитаем тоже самое для системы с часовым интервалом синхронизации:

Гарантированное время восстановления = Время максимального простоя = 1 час, что составляет ≈ 0,01 от годового времени

Каждый сбой будет иметь вес в 0,01%. Таким образом, система до сбоя система имеет доступность, равную 100%, после первого сбоя, 99,99%, после второго сбоя 99,98%. Дальше, приверженцы теории вероятности могут поупражняться в оценке вероятности наступления первого, второго, третьего сбоев. Результат убедит, что влияние этого фактора ничтожно мало на получаемые результаты. Это позволяет мне рекомендовать предложенную методику для оценки доступности сервисов для Ваших приложений в облаке .

Резюмируя вышесказанное...

• Начните с оценки бизнес-критичности приложения, планируемого к размещению в облаке. Оцените стоимость простоя приложения. Сколько Вам будет обходиться отсутствие сервиса приложения?
• Отсюда оцените допустимое значение простоя в день, в год. Посчитайте критическую доступность сервиса приложения.
• Сопоставьте возможные потери от простоя с ценами СП, которые предлагают приемлемую для ваших приложений доступность.
• При выборе СП, отдавайте предпочтение тому, кто может обеспечить не только текущий уровень доступности, но и как дополнительный сервис/услугу предоставить улучшение доступности. Особенно если Ваш бизнес растёт и развивается.
• И оставайтесь практиками. Берите то, что дают пощупать = потестировать. Теория без практики, не очень полезна для бизнеса.

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

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

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

На рис. 14.1 схематично представлены базовые понятия процесса Управления Доступностью.

Рис. 14.1. Концептуальные понятия процесса Управления Доступностью (источник: OGC)

Доступность

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

Сложности ИТ-инфраструктуры;

Надежности компонентов;

Способности быстро и эффективно реагировать на сбои;

Качества обслуживания и качества работы поддерживающих организаций и поставщиков;

Качества и границ компетенции процессов операционного управления.

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

Надежность компонентов, используемых для предоставления сервиса;

Способность сервиса или его компонентов эффективно функционировать, несмотря на сбой одной или нескольких подсистем (устойчивость);

Профилактическое обслуживание для предотвращения простоев.

Понятия «обслуживание» и «способность к восстановлению» предполагают выполнение работ по обеспечению функционирования сервиса и его восстановлению после сбоев, а также проведение профилактического обслуживания и регламентных (плановых) проверок, а именно:

Принятие мер по предотвращению сбоев;

Своевременное обнаружение сбоев;

Проведение диагностики, включая автоматическую самодиагностику компонентов;

Ликвидация сбоев;

Восстановление функционирования после сбоя;

Восстановление сервиса.

Предоставление сервиса внешними поставщиками

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

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

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

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

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

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

14.2.1. Преимущества использования процесса

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

Создание единой точки контактов по вопросам доступности продуктов и услуг и наличие одного человека, отвечающего за эти вопросы;

Гарантируется соответствие новых продуктов и услуг предъявляемым к ним требованиям и согласованному с заказчиком стандарту доступности;

Уровень Затрат поддерживается на приемлемом уровне;

Постоянный мониторинг стандартов доступности и их совершенствование по мере необходимости;

В случае недоступности сервиса выполнение восстановительных мероприятий, соответствующих ситуации;

Уменьшение количества отказов в доступе к системам и сокращение периода недоступности сервиса;

Смещение акцентов с исправления дефектов на улучшение сервиса;

Простота обоснования добавочной стоимости для ИТ-организации.

Процесс Управления Доступностью связан со следующими процессами ITIL.

Управление Уровнем Сервиса

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

Управление Конфигурациями

Процесс Управления Конфигурациями располагает информацией об инфраструктуре и может предоставлять ценную информацию Процессу Управления Доступностью.

Управление Мощностями

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

Управление Непрерывностью Сервиса

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

Управление Проблемами

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

Управление Инцидентами

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

Управление Безопасностью

Процесс Управления Доступностью тесно связан с Процессом Управления Безопасностью, в котором основными вопросами являются:

Конфиденциальность;

Целостность;

Доступность.

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

Управление Изменениями

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

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

Рис. 14.2. Входы и выходы Процесса Управления Доступностью (источник: OGC)

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

Входами для Процесса Управления Доступностью являются (рис. 14.2):

Требования бизнеса к доступности;

Оценка влияния на все бизнес-процессы, поддерживаемые ИТ;

Требования к доступности, надежности и обслуживанию ИТ-компонентов инфраструктуры;

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

Данные о конфигурациях услуг и их компонентах и данные мониторинга;

Достигнутые Уровни Сервиса в сравнении с согласованными уровнями для всех услуг, оговоренных в соглашении о предоставлении сервиса.

Выходы :

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

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

Гарантии доступности, надежности и обслуживания компонентов инфраструктуры, необходимые для предоставления ИТ-сервиса;

Отчеты о достигнутых Уровнях Доступности, надежности и обслуживания;

Требования к мониторингу доступности, надежности и обслуживания;

План обеспечения доступности для проведения проактивного улучшения ИТ-инфраструктуры.

В рамках Процесса Управления Доступностью выполняется ряд ключевых видов деятельности, связанных с планированием и мониторингом, а именно:

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

Определение требований к доступности сервиса;

Проектирование систем для достижения требуемого Уровня Доступности;

Проектирование систем для достижения требуемой способности восстановления ;

Вопросы безопасности;

Управление обслуживанием;

Разработка Плана Доступности.

Мониторинг

Проведение измерений и составление отчетов.

Ниже дается описание основных видов деятельности.

14.4.1. Определение требований к доступности сервиса

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

Ключевые бизнес-функции;

Согласованный период простоя ИТ-сервиса;

Количественная оценка требований к доступности сервиса;

Количественная оценка воздействия незапланированного простоя на бизнес-функции;

Рабочие часы заказчика;

Соглашения об «окнах» для планового обслуживания.

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

14.4.2. Проектирование систем для достижения требуемого Уровня Доступности

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

Хорошее проектирование, выполненное с учетом стандартов доступности, позволит заключить с поставщиками эффективные договоры на обслуживание. При проектировании используется ряд методов, таких как Анализ степени влияния сбоя компонента (CFIA – см. раздел 14.4.9) для выявления отказов, вызванных наличием SPOF, методика CCTA по анализу и Управлению Рисками (CRAMM – см. главу «Управление Непрерывностью ИТ-сервиса») и методы моделирования. Если требования стандартов доступности не могут быть удовлетворены, лучший путь – попытаться внести соответствующие усовершенствования в проект. В обеспечении соответствия стандартам может помочь использование дополнительных технологий, других методов, инструментальных средств разработки, другой стратегии Управления Релизами, улучшение или изменение процесса проектирования.

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

14.4.3. Проектирование систем для достижения требуемого Уровня Обслуживания

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

14.4.4. Ключевые вопросы безопасности

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

Среди вопросов могут быть следующие :

Определение лиц, имеющих право доступа в защищенные области;

14.4.5. Управление Обслуживанием

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

Обслуживание следует проводить в такие периоды, когда степень его воздействия на предоставление услуг является минимальной. Это значит, что необходимо заранее определить цели обслуживания, период его проведения, и какие работы при этом будут выполняться (для этого можно использовать метод Анализа влияния отказа компонентов – CFIA). Такая информация об обслуживании очень важна для Процесса Управления Изменениями и для других процессов.

14.4.6. Проведение измерений и составление отчетов

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

Если вы не измеряете, вы не можете управлять.

Если вы не измеряете, вы не можете улучшать.

Если вы не измеряете, вам, вероятно, все равно.

Если вы не можете влиять, то не стоит и измерять.

Цикл жизни инцидента включает в себя следующие этапы:

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

Обнаружение : поставщик сервиса проинформирован о сбое. Инцидент получает статус «Сообщено». Затраченное на это время известно как время обнаружения.

Реагирование : поставщику сервиса необходимо время, чтобы прореагировать на инцидент. Это время реагирования, оно используется для проведения диагностики, за которой следует выполнение ремонтных работ. В Процесс Управления Инцидентами входят такие виды работ, как Прием и Регистрация инцидентов, Классификация, Сопоставление, Анализ и Диагностика.

Ремонт : поставщик сервиса восстанавливает компоненты, которые вызвали сбой.

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

На рис. 14.3 показаны периоды времени, которые поддаются измерению.

Рис. 14.3. Измерение доступности (источник: OGC)

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

В Процессе Управления Доступностью, как правило, используются следующие метрики:

Среднее время ремонта (Mean Time to Repair – MTTR) : среднее время между возникновением сбоя и восстановлением сервиса, также известное как «простой». Оно складывается из времени обнаружения сбоя и времени разрешения сбоя. Данная метрика относится к таким аспектам сервиса, как способность восстановления и обслуживаемость .

Среднее время между сбоями (Mean Time Between Failures – MTBF) : среднее время между восстановлением после одного сбоя и возникновением другого, также известное как «период работоспособного состояния» (uptime). Данная метрика относится к надежности сервиса.

Среднее время между системными инцидентами (Mean Time Between System Incidents – MTBSI) : среднее время между двумя последовательными инцидентами. Данная метрика представляет собой сумму двух метрик MTTR и MTBF.

Соотношение метрик MTBF и MTBSI помогает понять, имело ли место много незначительных сбоев или было несколько серьезных нарушений в работе.

В отчеты о доступности сервиса могут быть включены следующие метрики:

Коэффициент доступности (или недоступности) сервиса, выраженный в метриках MTTR, MTBSI и MTBF;

Общее время работоспособного состояния и время простоя;

Количество сбоев;

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

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

14.4.7. Разработка Плана Обеспечения Доступности

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

План – это живой документ. В начале он должен дать описание текущей ситуации, а затем в него можно включать рекомендации и конкретные виды работ по улучшению существующих услуг, а также предложения по вводу новых услуг и их обслуживанию. Для составления полного и точного плана необходимо взаимодействие с такими Процессами, как Управление Уровнем Сервиса, Управление Непрерывностью ИТ-сервиса, Управление Финансами ИТ-сервиса, а также с Управлением Разработкой Приложений (напрямую или через Процесс Управления Изменениями).

14.4.8. Инструментальные средства

Для достижения эффективности Процесс Управления Доступностью должен использовать ряд инструментальных средств следующего назначения:

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

Фиксация исторической информации;

Создание отчетов;

Статистический анализ;

Анализ воздействия.

Процесс Управления Доступностью берет информацию из записей Процесса Управления инцидентами, Базы Данных CMDB и из Базы Данных Процесса Управления Мощностями (CL). Эта информация может храниться в специальной Базе Данных Процесса Управления Доступностью.

14.4.9. Методы и методики

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

Анализ влияния отказа компонентов (CFIA)

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

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

X – сбой/дефект означает, что услуга недоступна

А – безотказная конфигурация

В – безотказная конфигурация, с переключением

« » – нет воздействия

Рис. 14.4. Матрица CFIA (

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

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

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

Здесь может быть лирическое отступление про резервирование каналов и т.д., но у нас перед глазами есть пример – здание комплекса Москва-Сити, в котором пару лет назад неожиданным образом и основной, и резервный канал оказались от одного провайдера. А беда, как известно, не приходит одна. В итоге дважды на 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)

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

В случае недоступности сервиса по вине NTT, оператор устанавливает для себя рамки для выявления и решения проблемы в 15 минут – по истечению которых клиенту возмещают от 1/30 до 7/30 от ежемесячного платежа. Если SLA не соответствует скорость задержки сигнала, клиент может рассчитывать на возврат суточного платежа единоразово.

Наши реалии

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

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

Из интересных кейсов можно вспомнить магазин музыкальных инструментов, который обвинял нас (оператора) в падении продаж пианино (какое-то время не работал телефон). Тут опять же можно сравнивать с продвинутым клиентоориентированным западом, но лучше обратиться к российской глубинке, где не то что об SLA – вообще понятия «время восстановления сервисов» не существует. В лучшем случае – время реакции – 48 часов. За примерами даже не нужно далеко ходить – 15 км от Санкт-Петербурга – и местный оператор отнекивается от какой-либо ответственности. Говорить за всех региональных операторов было бы некрасиво, но, к сожалению, это скорее правило, чем исключение.

Какие выводы нужно сделать из этих историй

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

«Эталонные архитектуры максимальной доступности Oracle (Oracle Maximum Availability Architecture) Основа подхода DBaaS (база данных как сервис) ОФИЦИАЛЬНЫЙ ДОКУМЕНТ ORACLE | СЕНТЯБРЬ...»

Availability Architecture (MAA)

Эталонные архитектуры максимальной доступности

Oracle (Oracle Maximum Availability Architecture)

Основа подхода DBaaS (база данных как сервис)

ОФИЦИАЛЬНЫЙ ДОКУМЕНТ ORACLE | СЕНТЯБРЬ 2015

Введение 1

Эталонные архитектуры высокой доступности - обзор 2

Bronze: одиночный экземпляр 4 Высокая доступность и защита данных в Oracle Database 4 Консолидация баз данных на уровне Bronze 5 Управление жизненным циклом и предоставление базы данных как сервис (DBaaS) 5 Комплексы Oracle Engineered Systems 5 Заключение по уровню Bronze: защита данных, RTO и RPO 6 Silver: высокая доступность с автоматическим переключением на резерв 7 Oracle Real Application Clusters (Oracle RAC) 8 Oracle RAC One Node 8 Заключение по уровню Silver: защита данных, RTO и RPO 9 Gold: комплексные возможности высокой доступности и аварийного восстановления 9 Oracle Active Data Guard - защита данных в реальном времени и высокая доступность 10 Oracle GoldenGate 11 Oracle Site Guard 12 Заключение по уровню Gold: защита данных, RTO и RPO 13 Platinum: отсутствие простоев для приложений, готовых к уровню сервиса Platinum 14 Технология Application Continuity 14 Oracle Active Data Guard Far Sync 15

ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)

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

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

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

В этой статье подробно рассмотрена каждая эталонная архитектура и соответствующие уровни обслуживания, которых можно достичь. Статья предназначена в основном для технических специалистов: архитекторов, директоров по ИТ и администраторов баз данных, ответственных за проектирование и внедрение подхода DBaaS. Рекомендованные лучшие практики одинаково подходят для любой платформы, которую поддерживает СУБД Oracle Database, если специально не указано, что данная оптимизация предназначена только для Oracle Engineered Systems.

1 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)

Они обеспечивают уровни обслуживания, описанные на рис. 1.

–  –  –

Рис. 1. Уровни обслуживания для высокой доступности и защиты данных На каждом уровне используется собственная эталонная архитектура MAA для развертывания оптимального набора средств высокой доступности Oracle, которые надежно обеспечат заданный уровень обслуживания с минимальными расходами и сложностью. Они решают проблемы любых внеплановых отключений, включая повреждение данных, отказ одного из компонентов, выход из строя системы или отключение центра обработки данных, а также плановых отключений для техобслуживания, миграции или других целей. Общее описание каждой архитектуры представлено на рис. 2.

Рис. 2. Эталонные архитектуры высокой доступности и защиты данных

Уровню Bronze соответствуют базы данных, где простой перезапуск или восстановление из резервной копии считается «достаточно высокой доступностью». Уровень Bronze основан на одиночном экземпляре СУБД Oracle Database и использует лучшие практики архитектуры MAA, которые включают множество средств защиты данных и высокой доступности, включенных в лицензию Oracle Enterprise Edition.

Резервные копии, оптимизированные Oracle с помощью Oracle Recovery Manager (RMAN), обеспечивают

2 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)

Уровень Silver обеспечивает дополнительную степень высокой доступности для баз данных, требующих минимального или нулевого простоя при выходе из строя экземпляра БД или сервера, а также для большинства видов планового простоя на обслуживание. Уровень Silver дополнен технологией кластеризации - Oracle RAC или RAC One Node. RMAN предоставляет резервные копии баз данных для защиты данных и восстановления доступности, если отключение делает перезапуск кластера невозможным.

Уровень Gold значительно повышает уровень обслуживания для критически важных бизнес-приложений, где отказ ни одного из компонентов не приводит к выходу из строя всей системы. Уровень Gold дополнен технологиями репликации баз данных: Active Data Guard и Oracle GoldenGate. Эти технологии синхронизируют одну или более реплик производственной базы данных для обеспечения защиты данных в реальном времени и высокой доступности. Репликация баз данных обеспечивает значительно более высокий уровень доступности и защиты данных, чем технологии репликации на уровне системы хранения. Она также снижает расходы и повышает выгоду от инвестиций благодаря постоянному активному использованию всех реплик.

Уровень Platinum предоставляет несколько новых возможностей Oracle Database 12c, а также ранее доступные продукты, расширенные в новой версии. В него включены технология Application Continuity для надежного повтора выполняемых транзакций, Active Data Guard Far Sync для полной защиты от потери данных при любом удалении реплики от основной БД, новые расширения GoldenGate для обновления и миграций без простоев и Global Data Services для автоматического управления и балансировкой нагрузки для репликаций БД. Хотя внедрение каждой из технологий требует значительных усилий, это обеспечивает значительные преимущества для критически важных приложений, где простои и потеря данных недопустимы.

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

ВЫСОКАЯ ДОСТУПНОСТЬ И ЗАЩИТА ДАННЫХ

–  –  –

Эталонные архитектуры MAA по своей сути предназначены для решения противоречивых задач.

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

Эталонная архитектура MAA учитывает обе реальности и предоставляет инфраструктуру, которая оптимизирована для Oracle Database и позволяет задать нужный уровень HA для разных требований к уровню сервиса. Благодаря этому можно легко перенести базу данных на следующий уровень в случае изменения бизнес-требований или при

3 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)

В следующих разделах каждая эталонная архитектура описывается более подробно.

Bronze: одиночный экземпляр Уровень Bronze предоставляет базовый сервис БД с самыми низкими расходами. Расходы и сложность внедрения снижаются за счет более низкого уровня доступности и защиты данных. На рис. 3 представлен общий вид уровня Bronze.

Уровень Bronze использует один экземпляр БД Oracle Database; никакая технология кластеризации не используется в случае отказа сервера для автоматического переключения на резерв, на котором есть работающий экземпляр Oracle Database. Если выходит из строя сервер или база данных, целевое время восстановления (RTO) зависит от того, насколько быстро можно предоставить другое оборудование на замену или выполнить восстановление из резервной копии. В худшем сценарии полного отключения вычислительной площадки потребуется дополнительное время для выполнения этих задач на резервном узле, и в некоторых случаях на это могут потребоваться дни.

Уровень Bronze: одиночный экземпляр RTO от минут до дней, RPO со времени последнего резервного копирования Рис. 3. Эталонная архитектура высокой доступности Bronze Oracle Recovery Manager (RMAN) используется для регулярного резервного копирования СУБД Oracle Database.

Возможная потеря данных, называемая целевой точкой восстановления (RPO), - это все данные, сформированные после создания последней резервной копии. Копии резервных копий баз данных также хранятся в удаленном ЦОД или облаке в целях архивации и для аварийного восстановления в случае аварии в основном ЦОД.

Уровень Bronze состоит из основных компонентов, описанных в следующих разделах.

Высокая доступность и защита данных в Oracle Database На уровне Bronze используются следующие средства высокой доступности и защиты данных, включенные в Oracle Database Enterprise Edition без дополнительной платы.

Oracle Restart автоматически перезапускает базу данных, Listener и другие компоненты »

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

Средства Oracle для защиты от повреждений проверяют наличие физических »

повреждений и логических внутриблоковых повреждений. Повреждения данных в оперативной памяти обнаруживаются и не попадают на диск. Во многих случаях они могут быть устранены автоматически. Дополнительные сведения см. в разделе Preventing, Detecting, and Repairing Block Corruption for the Oracle Database (Предотвращение, обнаружение и устранение поврежденных блоков для Oracle Database).

Automatic Storage Management (ASM) - интегрированная с Oracle файловая система »

4 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)

Oracle Flashback Technologies - группа функций, обеспечивающих быстрое исправление »

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

Oracle Recovery Manager (RMAN) обеспечивает экономичное и надежное резервное »

копирование и восстановление, оптимизированное для Oracle Database.

Online Maintenance - функция, которая включает переопределение и реорганизацию »

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

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

Oracle Multitenant - методология MAA для консолидации и виртуализации баз данных, начиная с версии Oracle Database 12c. Другие опции консолидации включают следующее.

Виртуализация операционной системы - несколько виртуальных машин на одной физической хост-машине »

Консолидация схем - разные схемы приложений в одной базе данных »

Консолидация платформ - несколько отдельных баз данных на одной физической машине или в одном »

кластере Oracle RAC Компромиссы между Oracle Multitenant и другими методами консолидации обсуждаются в технической статье по Архитектуре Максимальной Доступности Oracle (Oracle Maximum Availability Architecture) «High Availability Best Practices for Database Consolidation» (Лучшие практики высокой доступности для консолидации баз данных).

Управление жизненным циклом и предоставление базы данных как сервис (DBaaS) Oracle Enterprise Manager Cloud Control - обеспечивает развертывание ИТ-ресурсов пользователями самостоятельно согласно модели пулов ресурсов для разных мультиарендных архитектур. Эти возможности необходимы для внедрения подхода DBaaS (база данных как сервис) - парадигмы, в которой конечные пользователи (АБД, разработчики приложений, инженеры по качеству обслуживания, руководители проектов и т. д.) могут запрашивать сервис баз данных, использовать их в течение жизненного цикла проекта, а затем освободить их и вернуть в пул ресурсов. С помощью Cloud Control Database as a Service (DBaaS) обеспечивается следующее.

Общая консолидированная платформа для предоставления сервиса базы данных »

Модель самообслуживания для развертывания этих ресурсов »

Гибкое увеличение и уменьшение ресурсов базы данных »

Взимание платы только за использованные ресурсы БД »

Комплексы Oracle Engineered Systems Комплексы Oracle Engineered Systems снижают расходы в течение всего жизненного цикла за счет стандартизации на предынтегрированной и оптимизированной платформе для СУБД Oracle Database и приложений. Комплексы Oracle Engineered Systems включают следующее.

Oracle Virtual Compute Appliance - кардинально упрощает для заказчиков установку и развертывание »

виртуальных инфраструктур для любого приложения Linux, Oracle Solaris или Microsoft Windows, а также управление ими.

Oracle Database Appliance - недорогой комплексный пакет программного обеспечения, систем хранения »

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

5 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)

Программно-аппаратный комплекс Oracle Exadata Database Machine - самая высокопроизводительная, »

масштабируемая и доступная платформа для работы Oracle Database. Oracle Exadata Database Machine работает с приложениями любых типов, включая оперативную обработку транзакций (OLTP), хранилища данных (DW) и консолидацию приложений смешанного типа нагрузки, что создает идеальную основу для консолидации баз данных.

Oracle SuperCluster - специализированные системы, идеальные для консолидации баз данных и »

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

Oracle ZFS Storage Appliance обеспечивает немедленные преимущества экономии дискового »

пространства, управления и экономии средств для заказчиков, используюя сетевую систему хранения (NAS). Oracle ZFS включает многофункциональный пакет ПО для управления, мониторинга, устранения неисправностей, моментальных копий, клонирования, тиражирования и дополнительные сервисы хранения данных, естественно дополняя все системы Oracle Engineered Systems.

Заключение по уровню Bronze: защита данных, RTO и RPO В таблице ниже суммируются все возможности защиты данных уровня Bronze. В первом столбце таблицы 2 указано, когда выполняются проверки на наличие физического и логического повреждения данных.

Ручные проверки инициируются администратором или через регулярные интервалы времени »

плановым заданием, выполняющим периодические проверки.

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

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

периоды, когда ресурсы не используются.

Каждая проверка уникальна для Oracle Database и использует специальные знания структуры блоков данных Oracle и журналов базы данных.

ЗАЩИТА ДАННЫХ BRONZE

–  –  –

Обратите внимание, что проверка HARD и функция Automatic Hard Disk Scrub and Repair уникальны для системы хранения Exadata. Благодаря проверке HARD СУБД Oracle Database не записывает физически поврежденные блоки на диск. Automatic Hard Disk Scrub and Repair периодически определяет и восстанавливает жесткие диски с поврежденными или изношенными секторами (кластер системы хранения), а также обнаруживает и устраняет другие физические и логические дефекты, когда есть свободные ресурсы.

Exadata посылает запрос в ASM на восстановление поврежденных секторов путем считывания данных из другой зеркальной копии. По умолчанию очистка диска (scrub) выполняется каждые две недели.

6 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)

ВРЕМЯ ВОССТАНОВЛЕНИЯ (RTO) И ВОЗМОЖНАЯ ПОТЕРЯ ДАННЫХ (RPO) НА УРОВНЕ BRONZE

–  –  –

Silver: высокая доступность с автоматическим переключением на резерв Уровень Silver основан на уровне Bronze, но включает технологию кластеризации для повышенной доступности во время внеплановых простоев и планового обслуживания (рис. 4). Уровень Silver использует технологию кластеризации Oracle RAC или Oracle RAC One Node для обеспечения высокой доступности в ЦОД. Это достигается путем автоматического переключения на резерв в случае отключения одного из экземпляров базы данных или в случае полного выхода из строя сервера, на котором работает экземпляр базы данных. Oracle RAC дает еще одно существенное преимущество - устраняет различные типы плановых простоев благодаря возможности техническому обслуживания узлов кластера Oracle RAC поочередно Уровень Silver: высокая доступность с быстрым переключением на резерв RTO за секунды в случае выхода сервера из строя, RPO со времени последнего резервного копирования Рис. 4. Эталонная архитектура высокой доступности Silver

7 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)

Oracle Real Application Clusters (Oracle RAC) Oracle RAC повышает доступность приложения внутри ЦОД в случае отказа экземпляра базы данных или сервера, на котором работает экземпляр. Переключение на резервный сервер с Oracle RAC происходит мгновенно. Время восстановления сервиса на оставшихся экземплярах и повторного подключения пользователей отказавшего узла практически незаметно.

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

Краткий обзор того, как работает кластер Oracle RAC, помогает понять его преимущества. Существует два компонента: экземпляры Oracle Database и сама СУБД Oracle Database.

Экземпляр базы данных определяется как набор серверных процессов и структур памяти, которые работают »

на одном узле (или сервере) и делают конкретную базу данных доступной для клиентов.

База данных - определенный набор файлов с общим доступом (файлы данных, индексные файлы, »

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

Oracle RAC использует архитектуру «активный-активный», в которой может быть несколько экземпляров баз »

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

Архитектура «активный-активный» кластера Oracle RAC обеспечивает следующие преимущества.

Повышение уровня высокой доступности. Отказ сервера или экземпляра базы данных не затрагивает »

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

Масштабируемость. Кластер Oracle RAC идеален для приложений и консолидированных сред, где »

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

Надежная производительность. Oracle Quality of Service (QoS) может использоваться для назначения »

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

Высокая доступность во время планового обслуживания. Высокая доступность обеспечивается благодаря »

внесению изменений на узлах Oracle RAC поочередно. Это включает обслуживание оборудования, ОС или сети, когда сервер должен быть переведен в автономный режим, внесение патчей в программный стек Oracle Grid Infrastructure или базу данных, а также обслуживание, когда необходимо перенести экземпляр базы данных на другой сервер для повышения вычислительной мощности или распределения нагрузки.

Oracle RAC - лучшая практика MAA для обеспечения высокой доступности серверов.

Oracle RAC One Node Oracle RAC One Node обеспечивает альтернативу кластеру Oracle RAC на уровне Silver, когда высокая доступность сервера необходима, а масштабируемость и мгновенное переключение на резерв не требуются. Лицензия Oracle RAC One Node стоит вдвое дешевле, чем Oracle RAC, и является менее дорогой альтернативой, если в случае отказов серверов достаточно RTO в минутах.

8 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)

В случае отказа сервера, на котором размещена открытая база данных, Oracle RAC One Node автоматически запускает новый экземпляр базы данных на втором узле для быстрого возобновления сервиса.

Oracle RAC One Node имеет ряд преимуществ над другими технологиями кластеризации «активный-пассивный».

В конфигурации Oracle RAC One Node сервисы Oracle Database HA Services, инфраструктура Grid Infrastructure и прослушивающие процессы базы данных всегда работают на втором узле. Во время аварийного переключения на резерв требуется запуск только экземпляра базы данных и сервисов базы данных, что ускоряет возобновление обслуживания и дает возможность перезапустить службы за минуты.

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

Заключение по уровню Silver: защита данных, RTO и RPO Уровень защиты данных такой же, как на уровне Bronze. Улучшения на уровне Silver по сравнению с уровнем Bronze связаны с RTO в случае отказа сервера и с некоторыми, часто выполняемыми видами планового ТО. Области улучшения по сравнению с уровнем Bronze показаны жирным шрифтом в следующей таблице.

ВРЕМЯ ВОССТАНОВЛЕНИЕ (RTO) И ВОЗМОЖНЫЕ ПОТЕРИ ДАННЫХ (RPO) НА УРОВНЕ SILVER

–  –  –

Gold: комплексные возможности высокой доступности и защиты от сбоев Уровень Gold основан на уровне Silver, но использует технологию репликации баз данных для устранения единой точки отказа, который может вызвать выход из строя всей системы, а также для значительного повышения уровня защиты и доступности данных для всех типов внеплановых сбоев, включая повреждения данных, отказы баз данных и отказы ЦОД. Наличие тиражированной копии также значительно сокращает простои в периоды планового обслуживания. Общий вид уровня Gold показан на рис. 5.

9 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)

Уровень Gold: комплексные возможности высокой доступности и защиты от сбоев RTO от секунд до минут, RPO до нуля или почти до нуля Рис. 5. Эталонная архитектура высокой доступности Gold Обратите внимание, что уровень Gold использует Oracle RAC как стандарт для высокой доступности серверов вместо менее функционального Oracle RAC One Node, доступного на уровне Silver.

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

Oracle Active Data Guard - защита данных в реальном времени и высокая доступность Oracle Active Data Guard поддерживает одну или несколько синхронизированных физических реплик (резервных баз данных) на удаленном узле для устранения единой точки отказа, которой мог бы привести к выходу из строя основной базы данных. Основываясь на лучших практиках MAA, предлагается использовать одну и ту же конфигурацию для основной и резервной баз данных (ЦП, память, ввод-вывод и т. д.), чтобы резервная база данных после аварийного переключения на нее могла обеспечить ту же производительность, что и исходная основная.

Active Data Guard добавляет следующие возможности на уровне Gold.

Выбор защиты для нулевой или практически нулевой потери данных. Active Data Guard выполняет »

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

Администраторы могут выбрать синхронную передачу в режиме защиты Maximum Availability (Максимальная »

доступность) для гарантии нулевой потери данных. Или они могут выбрать асинхронную передачу в режиме Maximum Performance (Максимальная производительность) с почти нулевой потерей данных. Режим Maximum Performance может ограничить возможность потери данных интервалом менее одной секунды, если пропускная способность сети достаточна для размера реплицируемых данных.

Data Guard и Active Data Guard - это единственные технологии репликации Oracle, обеспечивающие защиту »

с нулевой потерей данных.

Резервная база данных Oracle Active Data Guard может быстро принять на себя производственную нагрузку »

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

10 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)

базы данных на резерв. Это ускоряет восстановление, устраняя задержку на уведомление администратора, чтобы он мог среагировать на сбой. Fast Start Failover использует ролевые сервисы базы данных и технологию уведомления клиентов Oracle, чтобы приложения могли быстро отключиться от отказавшей основной БД и автоматически подключиться к новой основной. Передача роли БД может производиться вручную через интерфейс командной строки или Oracle Enterprise Manager.

Прозрачная репликация. Data Guard и Active Data Guard выполняют полную, одностороннюю физическую »

репликацию СУБД Oracle Database со следующими характеристиками: высокая производительность, простота управления, поддержка всех типов данных, приложений и видов нагрузок, таких как DML, DDL, OLTP, пакетная обработка и хранилище данных, а также консолидированные базы данных. Data Guard и Active Data Guard тесно интегрируются с технологиями Oracle RAC, ASM, RMAN и Oracle Flashback.

Перенос нагрузки с промышленной БД для большей окупаемости инвестиций. Резервные базы данных Oracle »

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

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

Освобождение основной БД от задач резервного копирования. Основная и резервная системы являются »

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

Снижение простоев для планового обслуживания. Резервные БД могут использоваться для обновления на »

новый патчсет (например, патч для перехода с версии 11.2.0.2 на 11.2.0.4) или для перехода на новую версию Oracle (например, с 11.2 на 12.1) поочередно: сначала обновляется резервная база данных, после чего она становится производственной уже с новой версией. Общее время простоя снижается до времени передачи роли основной базы данных резервной базе данных и времени переключения пользователей на новую основную базу данных после окончания обновления.

Резервная база данных Oracle Active Data Guard выполняет постоянную проверку данных, чтобы никакие »

повреждения не могли быть скопированы из исходной базы данных. Oracle Active Data Guard обнаруживает физические и логические повреждения блоков, которые могут возникнуть в основной или резервной базе данных. Это также уникальное средство обнаружения повреждений блоков при записи (потерянных или потерявшихся операций записи, признанных успешными подсистемой ввода-вывода). Дополнительные сведения доступны в документе My Oracle Support Note 1302539.1 - Best Practices for Corruption Detection, Prevention, and Automatic Repair (Лучшие практики обнаружения, предотвращения и автоматического устранения повреждений блоков БД).

Автоматическое восстановление блоков. Oracle Active Data Guard автоматически устраняет повреждения на »

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

Вышеуказанное также объясняет, почему уровень Gold использует технологию репликации для поддержания синхронизированной копии, а не продукты удаленного зеркалирования системы хранения (SRDF, Hitachi TrueCopy и т. д.). Дополнительные сведения об этих различиях см. в разделе Oracle Active Data Guard vs. Storage Remote Mirroring (Сравнение Oracle Active Data Guard и удаленного зеркалирования системы хранения).

Oracle GoldenGate Программное обеспечение Oracle GoldenGate обеспечивает логическую репликацию для поддержания синхронизированной копии (целевая база данных) основной базы данных (исходная база данных). Oracle GoldenGate считывает изменения с диска исходной базы данных, переводит данные в файловый формат, независимый от платформы, передает файл в целевую базу данных и затем превращает данные в операторы SQL (обновления, вставки и удаления), нативные для целевой базы данных. Целевая БД содержит те же данные, но это уже не исходная, а другая БД (например, резервные копии не взаимозаменяемы). Логическая репликация - это более

11 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)

С точки зрения распределения данных логическая репликация предназначена для экономичной »

репликации подмножеств исходной БД с целью распространения данных на другие целевые БД. Она также может использоваться для консолидации данных из нескольких исходных БД в одну целевую БД (например, Operational Data Store).

С точки зрения высокой доступности логическая репликация может использоваться для поддержания »

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

Логическая репликация Oracle GoldenGate позволяет гибко проводить техническое обслуживание и »

миграцию поочередно, когда с репликацией Data Guard это невозможно. Например, Oracle GoldenGate обеспечивает репликацию из исходной БД на платформе, использующей порядок байтов big-endian в целевую БД на платформе с little-endian (cross-endian репликация). Это позволяет получить дополнительное преимущество от миграции с платформы на платформу: можно изменить направление репликации на обратное для быстрого возврата к предыдущей версии после перехода.

Логическая репликация Oracle GoldenGate - более сложный процесс с большим числом предварительных требований, чем у Data Guard. Но это компенсируется уникальными способностями Oracle GoldenGate обеспечить современные виды репликации. Документ MAA Best Practices: Oracle Active Data Guard and Oracle GoldenGate (Лучшие практики MAA: Oracle Active Data Guard и Oracle GoldenGate) содержит дополнительные сведения для выбора оптимальной технологии репликации или использования обеих технологий как дополняющих друг друга.

Oracle Site Guard Oracle Site Guard дает возможность администраторам координировать как плановые, так и внеплановые переключения (в случае непредвиденного отключения основного ресурса) целиком окружения Oracle (несколько баз данных и приложений) между производственным сайтом и удаленным. Oracle Site Guard входит в пакет Oracle Enterprise Manager Life-Cycle Management Pack.

Oracle Site Guard дает следующие преимущества.

Снижения числа ошибок благодаря готовой реакции на выход из строя узла. Oracle Site Guard »

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

Координация множества приложений, баз данных и различных технологий репликации. Oracle Site »

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

Site Guard интегрируется с Oracle Active Data Guard для координации одновременных аварийных переключений нескольких баз данных на резерв. Site Guard также обеспечивает простой механизм интеграции любого продукта для удаленного зеркалирования системы хранения. Это ПО интегрируется с устройствами хранения для планового или аварийного переключения ресурсов на резерв. Для этого вызываются определенные сценарии передачи ролей для систем хранения.

Ускорение восстановления. Автоматизация Oracle Site Guard сводит к минимуму ручную »

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

12 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)

Области улучшений выделены жирным шрифтом.

ЗАЩИТА ДАННЫХ УРОВНЯ GOLD

–  –  –

13 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)

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

Уровень Platinum Отсутствие простоев для приложений, готовых к уровню сервиса Platinum

–  –  –

Рис. 6. Эталонная архитектура высокой доступности Platinum Для полного исключения простоев на уровне Platinum многим приложениям потребуются незначительные изменения. Вот почему мы говорим, что уровень Platinum обеспечивает нулевое время простоя только приложениям, готовым к уровню Platinum. Обратите внимание, что для нулевой потери данных никакие изменения в приложениях не требуются.

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

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

В случае отказа всего кластера Oracle RAC, когда база данных становится недоступной, технология Application Continuity воспроизводит сеанс, в том числе нужную транзакцию, после аварийного переключения на резервной БД с помощью Oracle Active Data Guard. Для использования технологии Application Continuity с резервной базой данных требуется режим Data Guard Maximum Availability и Data Guard Fast Start Failover.

14 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)

Active Data Guard Far Sync устраняет вышеуказанные ограничения, обеспечивая нулевую потерю данных без ухудшения производительности основной базы данных даже в случае, если основная и резервная базы данных находятся в сотнях и даже тысячах километров друг от друга. Это достигается с помощью «легкого» механизма передачи, простого в развертывании и прозрачного для операций аварийного переключения Oracle Active Data Guard или планового переключения. Если Far Sync используется с опцией Oracle Advanced Compression Option, обеспечивается также сжатие данных для передачи за пределы основного сайта для экономии пропускной способности сети.

Если технология Application Continuity используется вместе с Far Sync в режиме Data Guard Fast-Start-Failover (автоматическим аварийным переключением на резерв), она может сделать отключения незаметными для транзакций, выполнявшихся в этот момент, независимо от расстояния между основным и резервным узлами.

Таким образом, Far Sync обеспечивает два основных дополнительных преимущества уровня Platinum: аварийное переключение на резерв без потери данных для любой базы данных и возможность использовать технологию Application Continuity независимо от расстояния между узлами. Active Data Guard Far Sync - новый режим в Oracle Database 12c. Для использования преимуществ Far Sync никакие изменения в приложениях не требуются.

Техническое обслуживание без простоев с помощью GoldenGate и репликация «активный-активный»

Уровень Platinum использует передовые свойства репликации Oracle GoldenGate для технического обслуживания без простоев и для миграций с помощью двусторонней репликации. Рассмотрим следующий сценарий.

Техническое обслуживание сначала выполняется на целевой БД.

Исходная и целевая БД синхронизируются для разных версий БД, использующих логическую репликацию »

Oracle GoldenGate. Это обеспечивает миграции между платформами с прямым и обратным порядком байтов (cross-endian). Это также обеспечивает сложные обновления приложений, которые изменяют серверные объекты, где механизм репликации должен преобразовать данные из старой версии в новую или наоборот.

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

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

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

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

15 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)

Для удовлетворения требования нулевой потери данных уровень Platinum использует двустороннюю репликацию GoldenGate в сочетании с Oracle Active Data Guard.

Локальная реплика GoldenGate используется для планового технического обслуживания без потери данных, а резерв Oracle Active Data Guard стабильно исключает потери данных при аварийном переключении в случае внепланового отключения во время обслуживания.

Функция Edition Based Redefinition Edition-Based Redefinition (EBR) обеспечивает обновления приложения, которые изменяют серверные объекты БД, в сети без нарушения доступности приложения. Когда установка обновлений завершена, старый и обновленный варианты приложения могут использоваться одновременно. Существующие сессии могут продолжать использовать приложение, каким оно было до обновления, пока пользователи не решат прекратить работу, а новые сессии могут использовать уже новую редакцию. Когда сессий, использующих необновленное приложение, не останется, его можно вывести из эксплуатации.

EBR позволяет обновлять приложения в интерактивном режиме следующим образом.

Изменения программного кода вводятся в новой редакции.

Изменения в данных вводятся безопасным способом путем записи только в новые столбцы или новые »

таблицы, невидимые для старой редакции. В специальном представлении редакций (editioning view) таблица отображается особым образом для каждой редакции, чтобы каждая редакция видела только свои столбцы.

Сross-edition распространяет изменения данных, произведенные в старом приложении, на столбцы »

обновленного приложения, и наоборот.

Так же как и с беспростойным обновлением приложения с Oracle GoldenGate, для внедрения и использования EBR требуется глубокое знание приложения и значительные усилия разработчика. В отличие от Oracle GoldenGate для использования EBR достаточно разовой инвестиции. После этого можно использовать EBR для последующих версий приложения с минимальными усилиями. Уже доказана на практике возможность использования EBR для самых сложных приложений. Например, Oracle E-Business Suite 12.2 использует EBR для патчирования без остановки. Возможность EBR добавлена в СУБД Oracle Database без дополнительной платы.

Решение Oracle Global Data Services Oracle Global Data Services (GDS) - комплексное решение по автоматическому управлению нагрузкой для реплицированных БД, использующих Oracle Active Data Guard или Oracle GoldenGate. GDS обеспечивает более высокий коэффициент использования системы, а также более высокий уровень производительности, масштабируемости и доступности для реплицируемых БД.

GDS обеспечивает следующие возможности для набора реплицируемых БД:

–  –  –

16 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)

RTO и RPO для уровня Platinum показаны в следующей таблице.

ВРЕМЯ ВОССТАНОВЛЕНИЯ (RTO) И ВОЗМОЖНАЯ ПОТЕРЯ ДАННЫХ (RPO) НА УРОВНЕ PLATINUM

–  –  –

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

Лучшие практики Oracle MAA определяют четыре эталонные архитектуры высокой доступности:

BRONZE, SILVER, GOLD и PLATINUM. Каждая эталонная архитектура MAA использует оптимальный набор средств высокой доступности Oracle для надежного обеспечения нужного уровня обслуживания с наименьшими расходами и сложностью. Развертывание программных средств высокой доступности и защиты данных, интегрированных в Oracle, с помощью стандартного набора архитектур высокой доступности, использующих общую инфраструктуру, обеспечивает уникальное решение для поддержки подхода база данных как сервис (DBaaS) в публичных или частных облаках.

«ПРОГРАММА БЛАГОТВОРИТЕЛЬНОГО ФОНДА "САФМАР" 2014 год Содержание О Фонде 3 Обращение учредителя Фонда 4 Органы управления 5 Бюджет Фонда на 2014 г. 6 Целевые программы 6 Программы Фонда 7 Программа...»

2017 www.сайт - «Бесплатная электронная библиотека - различные документы»

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