Лекция: Обеспечение высокой доступности. SLA для IaaS: реальные гарантии для виртуальной ИТ-инфраструктуры Определение требований к доступности сервиса
Соглашение об уровне сервиса – документ, описывающий уровень оказания услуг, ожидаемый клиентом от поставщика, основанный на показателях, применимых к данному сервису, и устанавливающий ответственность поставщика, если согласованные показатели не достигаются.
Грубо говоря, если у вас отключают интернет дома, то в конце концов вы плюнете и пойдете на прогулку, в кино или кабак, в лучшем случае надеясь на перерасчет.
Если же у вас отключается связь в офисе, то у вас останавливаются продажи (клиенты не могут дозвониться и, не дождавшись ответа по почте, уходят к другим поставщикам), бухгалтерия не может проводить платежи (здесь вы подводите уже ваших партнеров), а если вы, скажем, трейдерское бюро, то сумма убытков может достигать тысяч долларов (вы не сможете вовремя купить или сбыть акции).
Здесь может быть лирическое отступление про резервирование каналов и т.д., но у нас перед глазами есть пример – здание комплекса Москва-Сити, в котором пару лет назад неожиданным образом и основной, и резервный канал оказались от одного провайдера. А беда, как известно, не приходит одна. В итоге дважды на 7-8 часов (в рабочее время) оказывались без связи компании из рейтинга «Fortune 500».
Поэтому особо дотошные юридические службы компаний, чей бизнес особо чувствителен к качеству связи, стараются исчислять размер ущерба компании не только стоимостью не потреблённых сервисов, но и выгодой, упущенной клиентом вследствие простоя связи.
Отправные точки
Вот некоторые показатели, в том или ином составе встречающиеся в операторских документах:
ASR (Answer Seizure Ratio)
- параметр, определяющий качество телефонного соединения в заданном направлении. ASR рассчитывается как процентное отношение числа установленных в результате вызовов телефонных соединений к общему количеству совершенных вызовов в заданном направлении.
PDD (Post Dial Delay)
- параметр, определяющий период времени (в секундах), прошедший с момента вызова до момента установления телефонного соединения.
Коэффициент доступности Услуги
- отношение времени перерыва в предоставлении услуг к общему времени, когда услуга должна предоставляться.
Коэффициент потери пакетов информации
- отношение правильно принятых пакетов данных к общему количеству пакетов, которые были переданы по сети за определенный промежуток времени.
Временные задержки при передаче пакетов информации
- промежуток времени, необходимого для передачи пакета информации между двумя сетевыми устройствами.
Достоверность передачи информации
- отношение количества ошибочно переданных пакетов данных к общему числу переданных пакетов данных.
Периоды проведения работ, время оповещения абонентов и время восстановления сервисов.
Иными словами, доступность услуги 99,99% говорит о том, что оператор гарантирует не более 4,3 минут простоя связи в месяц, 99,9% - что услуга может не оказываться 43,2 минуты, а 99% - что перерыв может длиться более 7 часов. В некоторых практиках встречается разграничение доступности сети и предполагается меньшее значение параметра – в нерабочее время. На разные типы услуг (классы трафика) также предусмотрены разные значения показателей. Например, для голоса важнее всего показатель задержки – он должен быть минимальным. А скорость для него нужна невысокая, плюс часть пакетов можно терять без потери качества (примерно до 1% в зависимости от кодека). Для передачи данных на первое место выходит скорость, и потери пакетов должны стремиться к нулю.
Мировые стандарты
В западной практике принято приводить официальный отчет о параметрах сети за последний год. Вот, например, показатели для интернет-канала за май нескольких небезызвестных брендов.
Задержка передачи сигнала (Latency, ms)
| Sprintnet | Verizon | Cable&Wireless | NTT | |||||
| Факт | Стандарт | Факт | Стандарт | Факт | Стандарт | Факт | Стандарт | |
| Европа | 18.9 | 45 | 15.178 | 30 | 17.6 | 35.0 | 24.00 | 35 |
| США | 36.91 | 55 | 42.851 | 45 | 45.9 | 65.0 | 45.83 | 60 |
| Азия | 83.78 | 105 | 100.640 | 125 | 48.3 | 90.0 | 47.34 | 95 |
| Европа-Азия | 207.63 | 270 | - | - | 174.1 | 310.0 | 260.23 | 300 |
| Европа-США | 74.53 | 95 | 78.784 | 90 | 78.7 | 90.0 | 71.57 | 90 |
| Sprintnet | Verizon | Cable&Wireless | NTT | |||||
| Факт | Стандарт | Факт | Стандарт | Факт | Стандарт | Факт | Стандарт | |
| Европа | 0 | 0.3% | 0.025% | 0.5% | 0 | 0.2% | 0 | 0.3% |
| США | 0.01% | 0.3% | 0.019% | 0.5% | 0.1% | 0.2% | 0 | 0.3% |
| Азия | 0 | 0.3% | 0.004% | 1% | 0 | 0.2% | 0 | 0.3% |
| Европа-Азия | 0 | 0.3% | - | - | 0 | 0.2% | 0 | 0.3% |
| Европа-США | 0 | 0.3% | 0 | 0.5% | 0.1% | 0.2% | 0 | 0.3% |
| Sprintnet | Verizon | Cable&Wireless | NTT | |||||
| Факт | Стандарт | Факт | Стандарт | Факт | Стандарт | Факт | Стандарт | |
| Европа | 0.0017 | 2 | 0.026 | 1 | - | - | 0 | 0.5 |
| США | 0.0007 | 2 | 0.058 | 1 | - | - | 0 | 0.5 |
| Азия | 0.0201 | 2 | - | - | - | - | 0 | 0.5 |
| Европа-Азия | 0.0001 | 2 | - | - | - | - | 0 | 0.5 |
| Европа-США | 0.0001 | 2 | - | - | - | - | 0 | 0.5 |
Sprint подходит к себе более жестко, и если SLA не соблюдается (по крайней мере в отношении ), то клиенту возвращается абонентская плата за весь месяц, в котором была зафиксирована проблема.
В случае недоступности сервиса по вине NTT, оператор устанавливает для себя рамки для выявления и решения проблемы в 15 минут – по истечению которых клиенту возмещают от 1/30 до 7/30 от ежемесячного платежа. Если SLA не соответствует скорость задержки сигнала, клиент может рассчитывать на возврат суточного платежа единоразово.
Наши реалии
В Российском бизнесе трепетно к SLA относятся преимущественно международные бренды. В то же время для столичных клиентов само словосочетание тоже стало знакомым, и даже средние компании порой интересуются этим документом. Здесь хочется отметить, что соглашение об уровне сервиса не заменяет и не отменяет стандартные пункты об ответственности оператора в договоре оказания услуг, а также нормы, установленные законодательством, и подзаконные акты (например, ФЗ «О Связи», Приказ №92 «Об утверждении Норм на электрические параметры основных цифровых каналов и трактов магистральной и внутризоновых первичных сетей ВСС России» и т.д.), которым мы все свято следуем.
В практике Гарс Телеком, в случае возникновения каких-либо «факапов», споры урегулируются в рамках процедуры обработки трабл-тикетов и времени восстановления сервисов. Аварии, повлекшие неработоспособность услуги, должны ликвидироваться от 4 до 72 часов (в зависимости от причины). В случае превышения заданных параметров – абоненту компенсируется каждый дополнительный час простоя, а при достижении оператором пороговых значений – процент компенсации увеличивается.
Из интересных кейсов можно вспомнить магазин музыкальных инструментов, который обвинял нас (оператора) в падении продаж пианино (какое-то время не работал телефон). Тут опять же можно сравнивать с продвинутым клиентоориентированным западом, но лучше обратиться к российской глубинке, где не то что об SLA – вообще понятия «время восстановления сервисов» не существует. В лучшем случае – время реакции – 48 часов. За примерами даже не нужно далеко ходить – 15 км от Санкт-Петербурга – и местный оператор отнекивается от какой-либо ответственности. Говорить за всех региональных операторов было бы некрасиво, но, к сожалению, это скорее правило, чем исключение.
Какие выводы нужно сделать из этих историй
- После драки кулаками не машут – если для бизнеса есть какие-то критичные параметры, нужно подумать какие и оговорить их с оператором на этапе согласования документов
- Показатель, над которым стоит постоянно работать – это время восстановления сервисов и уровень технической поддержки. Потому что когда вообще ничего не работает – это хуже, чем когда работает, но плохо (в этом случае клиент может, по крайней мере, оперативно и безболезненно сменить оператора)
- Позаботиться о резервировании тоже стоит заранее, причем услуга должна быть от независимых операторов, хотя бы один из которых должен быть фиксированным.
Масштабируемость и высокая доступность становятся всё более популярными с увеличением спроса на надежные и производительные инфраструктуры, предназначенные для обслуживания критически важных систем. Уменьшение времени простоя и устранение единых точек отказа – такие же важные проблемы, как и обработка повышенной нагрузки на систему. Высокая доступность (high availability) – качество инфраструктуры, способное устранить их.
Данная статья рассказывает, что именно значит термин «высокая доступность» и как это качество может сделать инфраструктуру более надёжной.
Высокая доступность
В программировании термин «доступность» (availability) используется для описания интервала времени, в течение которого сервис доступен, а также времени, необходимого системе для ответа на запрос пользователя. Высокая доступность – это качество системы или компонента, которое обеспечивает высокий уровень эксплуатационных характеристик за определенный период времени.
Измерение доступности
Доступность часто выражается в процентах, что обозначает уровень аптайма, который ожидается от конкретной системы или компонента за конкретный период времени. В таком случае 100% доступности значит, что система никогда не выходит из строя; соответственно, система, которая обеспечивает 99% доступности в течение одного года, может иметь до 3,65 дней простоя (1%).
Эти значения вычисляются на основе нескольких факторов, включая плановое и внеплановое техническое обслуживание, а также время, необходимое для устранения возможного сбоя системы.
Как работает высокая доступность?
Высокая доступность используется в качестве механизма быстрого реагирования на сбои. Этот механизм довольно прост, но, как правило, требует специализированного программного обеспечения и конфигурации.
Когда необходима высокая доступность?
Минимизация времени простоя и перебоев в обслуживании очень важна при создании отказоустойчивых систем для производства. Независимо от того, насколько надежно системное и программное обеспечение, в системе могут возникнуть проблемы, которые приведут к сбою в работе приложения или сервера.
Внедрение высокой доступности инфраструктуры – хорошая стратегия для снижения вероятности возникновения и минимизации влияния этих событий. Высоко доступные системы могут автоматически выполнить восстановление сервера или компонента после сбоя.
Что делает систему высоко доступной?
Одной из целей высокой доступности является устранение единых точек отказа в инфраструктуре. Единая точка отказа – это компонент стека, отказ которого выводит из строя всю систему или вызывает недоступность данных; то есть любой компонент, который является необходимым условием для работы приложения, считается единственной точкой отказа.
Чтобы устранить единые точки отказа, нужно подготовить каждый слой стека к избыточности. Для примера давайте представим, что у вас есть инфраструктура, состоящая из двух одинаковых избыточных веб-серверов с балансировщиком нагрузки. Трафик, поступающий от клиентов, будет равномерно распределен между веб-серверами, но если один из серверов выйдет из строя, балансировщик нагрузки будет перенаправлять весь трафик на оставшийся веб-сервер.
В данной ситуации веб-сервер не является единой точкой отказа, потому что:
- В кластере существует «запасной» компонент, способный взять на себя все задачи.
- На другом уровне существует механизм (балансировщик нагрузки), способный обнаруживать сбои в компонентах и адаптировать свое поведение для своевременного восстановления работы приложения.
Но что если из строя выйдет балансировщик нагрузки?
В описанном сценарии (который довольно часто встречается) единой точкой отказа является именно балансировщик нагрузки.
Устранить эту точку отказа не так уж просто. Конечно, можно легко настроить дополнительный балансировщик нагрузки для обеспечения избыточности, однако в системе уровнем выше балансировщиков нагрузки не существует компонента, который мог бы взять на себя обнаружение сбоя и восстановление работы.
Одна только избыточность не может гарантировать высокой доступности.
Для обнаружения и устранения сбоев в инфраструктуре должен существовать специальный компонент.
Обнаружение и устранение сбоев можно реализовать методом top-to-bottom: верхний слой отслеживает сбои нижнего слоя. Вернёмся к нашему примеру; в таком кластере балансировщик нагрузки – это верхний слой. Если один из веб-серверов (нижний слой) станет недоступным, балансировщик нагрузки перестанет перенаправлять на него запросы.
Такой подход достаточно прост, но он имеет свои ограничения: в инфраструктуре всегда будет точка, для которой верхний слой отсутствует либо недоступен (как в случае с балансировщиком нагрузки). Создание сервиса обнаружения неисправностей для балансировщика нагрузки на внешнем сервере равно созданию новой единой точки отказа.
При таком сценарии необходим распределенный подход. Нужно соединить в кластер несколько дублирующих нод, где каждая нода будет в равной степени способна к обнаружению и устранению сбоя.
Однако в случае с балансировкой нагрузки есть дополнительная сложность, связанная с работой серверов имен. Восстановление после сбоя балансировки нагрузки, как правило, означает переход балансировки на другой (избыточный) ресурс, а для этого нужно изменить DNS (указать доменное имя или IP-адрес резервного балансировщика нагрузки). Такие изменения могут занять значительное количество времени и повлечь за собой большой период простоя.
В такой ситуации можно использовать балансировку по алгоритму round-robin. Однако этот подход не является надежным, поскольку аварийное переключение будет на клиентской стороне приложения.
Более надёжным и отказоустойчивым решением являются системы, поддерживающие гибкие ip-адреса. При необходимости IP-адрес модифицируется, что препятствует распространению неисправности и её кэшированию. При этом доменное имя может оставаться связанным с тем же IP-адресом, а сам IP-адрес перемещается между серверами.
Какие компоненты необходимы для поддержки высокой доступности?
Для настройки высокой доступности необходимо установить несколько системных компонентов. Однако гораздо сильнее высокая доступность зависит от таких факторов:
- Окружение: если все серверы кластера расположены в одной географической области, внешние условия (землетрясения, наводнения и т.п.) могут привести к полному сбою системы. Наличие серверов в разных датацентрах и географических областях повысит отказоустойчивость.
- Аппаратное обеспечение: высоко доступные серверы должны быть устойчивы к перебоям в подаче электроэнергии и сбоям оборудования, включая жесткие диски и сетевые интерфейсы.
- Программное обеспечение: весь программный стек (в том числе операционная система и само приложение) должен быть готов к обработке случайных сбоев, которые могут потребовать перезапуска системы.
- Данные: потеря и несоответствие данных может быть обусловлено несколькими факторами. Высоко доступные системы должны принимать во внимание необходимость защиты данных на случай сбоя.
- Сеть: незапланированные отключения сети представляют собой еще одну возможную точку отказа для высоконадежных систем. Важно иметь на такой случай запасную стратегию сети.
Какое программное обеспечение необходимо для высокой доступности?
Каждый слой системы с высокой доступностью будет иметь разные потребности. На уровне приложения балансировка нагрузки является неотъемлемым компонентом в системе с высокой доступностью.
(High Availability Proxy) – популярное средство для настройки балансировки нагрузки, так как позволяет обрабатывать нагрузку на нескольких уровнях, а также для различных видов серверов, включая серверы баз данных.
Также в системный стек важно внедрить надёжное средство для точки входа в приложение. Чтобы устранить единую точку отказа, как упоминалось ранее, необходимо реализовать кластер балансировки нагрузки с гибкими IP-адресами. Для создания таких систем используются Corosync и Pacemaker.
Заключение
Высокая доступность – очень важный аспект надёжности инфраструктуры, ориентированный на обеспечение высокого уровня эксплуатационных характеристик в течение определенного периода времени. На первый взгляд реализация высокой доступности может показаться довольно сложной, однако она может принести много пользы системе, требующей повышенной надежности.
Tags:Доступность
Основные понятия
Информационная система предоставляет своим пользователям определенный набор услуг (сервисов). Говорят, что обеспечен нужный уровень доступности этих сервисов, если следующие показатели находятся в заданных пределах:
- Эффективность услуг . Эффективность услуги определяется в терминах максимального времени обслуживания запроса, количества поддерживаемых пользователей и т.п. Требуется, чтобы эффективность не опускалась ниже заранее установленного порога.
- Время недоступности. Если эффективность информационной услуги не удовлетворяет наложенным ограничениям, услуга считается недоступной. Требуется, чтобы максимальная продолжительность периода недоступности и суммарное время недоступности за некоторой период (месяц, год) не превышали заранее заданных пределов.
В сущности, требуется, чтобы информационная система почти всегда работала с нужной эффективностью. Для некоторых критически важных систем (например, систем управления) время недоступности должно быть нулевым, без всяких "почти". В таком случае говорят о вероятности возникновения ситуации недоступности и требуют, чтобы эта вероятность не превышала заданной величины. Для решения данной задачи создавались и создаются специальные отказоустойчивые системы, стоимость которых, как правило, весьма высока.
К подавляющему большинству коммерческих систем предъявляются менее жесткие требования, однако современная деловая жизнь и здесь накладывает достаточно суровые ограничения, когда число обслуживаемых пользователей может измеряться тысячами, время ответа не должно превышать нескольких секунд, а время недоступности – нескольких часов в год.
Задачу обеспечения высокой доступности необходимо решать для современных конфигураций, построенных в технологии клиент/сервер. Это означает, что в защите нуждается вся цепочка – от пользователей (возможно, удаленных) до критически важных серверов (в том числе серверов безопасности).
Основные угрозы доступности были рассмотрены нами ранее.
В соответствии с ГОСТ 27.002, под отказом понимается событие, которое заключается в нарушении работоспособности изделия. В контексте данной работы изделие – это информационная система или ее компонент.
В простейшем случае можно считать, что отказы любого компонента составного изделия ведут к общему отказу, а распределение отказов во времени представляет собой простой пуассоновский поток событий. В таком случае вводят понятие интенсивности отказов и среднего времени наработки на отказ, которые связаны между собой соотношением
Рис. 13.1.
где i – номер компонента,
λ i – интенсивность отказов,
T i – среднее время наработки на отказ.
Интенсивности отказов независимых компонентов складываются:
Рис. 13.2.
а среднее время наработки на отказ для составного изделия задается соотношением
Рис. 13.3.
Уже эти простейшие выкладки показывают, что если существует компонент, интенсивность отказов которого много больше, чем у остальных, то именно он определяет среднее время наработки на отказ всей информационной системы. Это является теоретическим обоснованием принципа первоочередного укрепления самого слабого звена.
Пуассоновская модель позволяет обосновать еще одно очень важное положение, состоящее в том, что эмпирический подход к построению систем высокой доступности не может быть реализован за приемлемое время. При традиционном цикле тестирования/отладки программной системы по оптимистическим оценкам каждое исправление ошибки приводит к экспоненциальному убыванию (примерно на половину десятичного порядка) интенсивности отказов. Отсюда следует, что для того, чтобы на опыте убедиться в достижении необходимого уровня доступности, независимо от применяемой технологии тестирования и отладки, придется потратить время, практически равное среднему времени наработки на отказ. Например, для достижения среднего времени наработки на отказ 10 5 часов потребуется более 10 4,5 часов, что составляет более трех лет. Значит, нужны иные методы построения систем высокой доступности, методы, эффективность которых доказана аналитически или практически за более чем пятьдесят лет развития вычислительной техники и программирования.
Пуассоновская модель применима в тех случаях, когда информационная система содержит одиночные точки отказа, то есть компоненты, выход которых из строя ведет к отказу всей системы. Для исследования систем с резервированием применяется иной формализм.
В соответствии с постановкой задачи будем считать, что существует количественная мера эффективности предоставляемых изделием информационных услуг. В таком случае вводятся понятия показателей эффективности отдельных элементов и эффективности функционирования всей сложной системы.
В качестве меры доступности можно принять вероятность приемлемости эффективности услуг, предоставляемых информационной системой, на всем протяжении рассматриваемого отрезка времени. Чем большим запасом эффективности располагает система, тем выше ее доступность.
При наличии избыточности в конфигурации системы вероятность того, что в рассматриваемый промежуток времени эффективность информационных сервисов не опустится ниже допустимого предела, зависит не только от вероятности отказа компонентов, но и от времени, в течение которого они остаются неработоспособными, поскольку при этом суммарная эффективность падает, и каждый следующий отказ может стать фатальным. Чтобы максимально увеличить доступность системы, необходимо минимизировать время неработоспособности каждого компонента. Кроме того, следует учитывать, что, вообще говоря, ремонтные работы могут потребовать понижения эффективности или даже временного отключения работоспособных компонентов; такого рода влияние также необходимо минимизировать.
Высокая доступность — это то, что любят демонстрировать в цифрах. Все уже привыкли к маркетинговым ходам и доступность в 99% кажется просто фантастически высокой. Лишь малая часть клиентов понимают, что доступность 98- 99% это очень плохая, местами никуда не годная цифра.
Посмотрите на эти цифры и вы поймете, чем доступность в 90% отличается от доступности в 99,999%:
| Доступность | Время простоя в месяц | Время простоя в год |
| 90% | 3 дня | 37 дней |
| 98% | 14,6 часов | 7,3 дня |
| 99% | 7,3 часа | 3,7 дней |
| 99,8% | 1,5 часа | 18 часов |
| 99,9% | 44 минуты | 8.8 часов |
| 99,99% | 4.4 минуты | 53 минуты |
| 99,999% | 26 сек | 5,3 минуты |
Посмотрев на таблицу выше вы понимаете, что датацентр, гарантирующий сетевую доступность в 99% может позволить себе 7 часов простоя в месяц. Представьте себе такую ситуацию: весь день в датацентре что-то чинят, ваш сайт недоступен, вы несете убытки, а предъявить претензии датацентру не можете — даже при этой ситуации он обеспечит обещанную доступность.
Я считаю сетевую доступность 99% плохой. Предпочитаю датацентры, обеспечивающие не менее 99,9% сетевой доступности.
Наверное, существуют интернет-проекты, которые могут пережить и 37 дней простоя в год (больше месяца!). Но всё-таки большинство интернет-магазинов, порталов и сайтов (в особенности тех, чьи транзакции проходят через сайт) не могут себе позволить такой роскоши, как даже 18 часов в год. Репутацию восстановить сложно всегда, а если она теряется по причинам “у системного администратора выходной” это и вовсе обидно.
“Пять девяток” — вот, что такое высокая доступность
Термин “пять девяток” означает доступность 99,999% и встречается в маркетинговой литературе не реже, чем в технической. Считается, что сайт или система с уровнем доступности «пять девяток» — это и есть высокая доступность.
Высокая доступность нужна всем
Из таблицы видно, что 99,999% доступности — это всего 5,3 минуты простоя в год. Но даже те датацентры, которые гарантируют 100% доступность нередко пускаются на маркетинговые ухищрения.
Например, вычитают время регламентного обслуживания из времени доступности. К примеру, дата-центр обещает доступность 99.99%, но в момент, когда проводит плановые работы по замене чего-нибудь пишет “проводятся регламентные работы в течение 2 часов” и не считает это за недоступность. Отсюда вывод — читайте соглашение об уровне обслуживания (SLA) внимательно.
Если вы хотите обеспечить максимально высокую доступность вашему сайту на одном единственном сервере, выбирайте датацентр с хорошей ГАРАНТИРОВАННОЙ SLA (соглашением об уровне обслуживания) доступностью.
Обратите внимание! В SLA должно быть гарантировано время замены неисправного железа. И, в идеале, время реакции на проблему.
Кроме того, ваш админ должен отслеживать работу сервиса и быстро реагировать на недоступность.
Немного о том, из чего складывается высокая доступность
Доступность может быть сетевая и сервиса.
Сетевая доступность
— это когда ваш сервер доступен по сети.
Доступность сервиса
— это когда ваш сервер может обслуживать клиентов.
Доступность сервиса не может быть лучше сетевой доступности, если вы не используете альтернативных подключений (со своей сетевой доступностью).
Доступность сервиса зависит от:
- сетевой доступности вашего сервера
- скорости реакции вашего админа на проблему
- скорости реакции поддержки дата-центра на проблему
- скорости замены неисправного железа в дата-центре
Недоступность складывается из:
- проблем сетевой доступности
- проблем с “железом”
- проблем с нагрузкой на сервере (“тормозит”, не справляется)
- программных ошибок (“косяки” программистов)
И месячную (кроме случаев поломки железа) и уж тем более годовую доступность 99,8% можно обеспечить в хорошем ДЦ на одном сервере без дополнительных мер обеспечения отказоустойчивости. Доступность 99,9% уже требует некоторого везения.
Если вам нужна гарантированная доступность выше 99,8%, необходимо заниматься отказоустойчивостью. И сервер должен быть не один. Но это тема отдельного разговора.
Есть разновидности бизнеса, где перерывы в предоставлении сервиса недопустимы. Например, если у сотового оператора из-за поломки сервера остановится биллинговая система, абоненты останутся без связи. От осознания возможных последствий этого события возникает резонное желание подстраховаться.
Мы расскажем какие есть способы защиты от сбоев серверов и какие архитектуры используют при внедрении VMmanager Cloud: продукта, который предназначен для создания кластера высокой доступности .
Предисловие
В области защиты от сбоев на кластерах терминология в Интернете различается от сайта к сайту. Для того чтобы избежать путаницы, мы обозначим термины и определения, которые будут использоваться в этой статье.- Отказоустойчивость (Fault Tolerance, FT) - способность системы к дальнейшей работе после выхода из строя какого-либо её элемента.
- Кластер - группа серверов (вычислительных единиц), объединенных каналами связи.
- Отказоустойчивый кластер (Fault Tolerant Cluster, FTC) - кластер, отказ сервера в котором не приводит к полной неработоспособности всего кластера. Задачи вышедшей из строя машины распределяются между одной или несколькими оставшимися нодами в автоматическом режиме.
- Непрерывная доступность (Continuous Availability, CA) - пользователь может в любой момент воспользоваться сервисом, перерывов в предоставлении не происходит. Сколько времени прошло с момента отказа узла не имеет значения.
- Высокая доступность (High Availability, HA) - в случае выхода из строя узла пользователь какое-то время не будет получать услугу, однако восстановление системы произойдёт автоматически; время простоя минимизируется.
- КНД - кластер непрерывной доступности, CA-кластер.
- КВД - кластер высокой доступности, HA-кластер.
На первый взгляд самый привлекательный вариант для бизнеса тот, когда в случае сбоя обслуживание пользователей не прерывается, то есть кластер непрерывной доступности. Без КНД никак не обойтись как минимум в задачах уже упомянутого биллинга абонентов и при автоматизации непрерывных производственных процессов. Однако наряду с положительными чертами такого подхода есть и “подводные камни”. О них следующий раздел статьи.
Continuous availability / непрерывная доступность
Бесперебойное обслуживание клиента возможно только в случае наличия в любой момент времени точной копии сервера (физического или виртуального), на котором запущен сервис. Если создавать копию уже после отказа оборудования, то на это потребуется время, а значит, будет перебой в предоставлении услуги. Кроме этого, после поломки невозможно будет получить содержимое оперативной памяти с проблемной машины, а значит находившаяся там информация будет потеряна.Для реализации CA существует два способа: аппаратный и программный. Расскажем о каждом из них чуть подробнее.
Аппаратный способ
представляет собой “раздвоенный” сервер: все компоненты дублированы, а вычисления выполняются одновременно и независимо. За синхронность отвечает узел, который в числе прочего сверяет результаты с половинок. В случае несоответствия выполняется поиск причины и попытка коррекции ошибки. Если ошибка не корректируется, то неисправный модуль отключается.
На Хабре недавно была на тему аппаратных CA-серверов. Описываемый в материале производитель гарантирует, что годовое время простоя не более 32 секунд. Так вот, для того чтобы добиться таких результатов, надо приобрести оборудование. Российский партнёр компании Stratus сообщил, что стоимость CA-сервера с двумя процессорами на каждый синхронизированный модуль составляет порядка $160 000 в зависимости от комплектации. Итого на кластер потребуется $1 600 000.
Программный способ.
На момент написания статьи самый популярный инструмент для развёртывания кластера непрерывной доступности - от VMware. Технология обеспечения Continuous Availability в этом продукте имеет название “Fault Tolerance”.
В отличие от аппаратного способа данный вариант имеет ограничения в использовании. Перечислим основные:
- На физическом хосте должен быть процессор:
- Intel архитектуры Sandy Bridge (или новее). Avoton не поддерживается.
- AMD Bulldozer (или новее).
- Машины, на которых используется Fault Tolerance, должны быть объединены в 10-гигабитную сеть с низкими задержками. Компания VMware настоятельно рекомендует выделенную сеть.
- Не более 4 виртуальных процессоров на ВМ.
- Не более 8 виртуальных процессоров на физический хост.
- Не более 4 виртуальных машин на физический хост.
- Невозможно использовать снэпшоты виртуальных машин.
- Невозможно использовать Storage vMotion.
Экспериментально установлено, что технология Fault Tolerance от VMware значительно “тормозит” виртуальную машину. В ходе исследования vmgu.ru после включения FT производительность ВМ при работе с базой данных упала на 47%.
Лицензирование vSphere привязано к физическим процессорам. Цена начинается с $1750 за лицензию + $550 за годовую подписку и техподдержку. Также для автоматизации управления кластером требуется приобрести VMware vCenter Server, который стоит от $8000. Поскольку для обеспечения непрерывной доступности используется схема 2N, для того чтобы работали 10 нод с виртуальными машинами, нужно дополнительно приобрести 10 дублирующих серверов и лицензии к ним. Итого стоимость программной части кластера составит 2 *(10 + 10)*(1750 + 550)+ 8000 =$100 000.
Мы не стали расписывать конкретные конфигурации нод: состав комплектующих в серверах всегда зависит от задач кластера. Сетевое оборудование описывать также смысла не имеет: во всех случаях набор будет одинаковым. Поэтому в данной статье мы решили считать только то, что точно будет различаться: стоимость лицензий.
Стоит упомянуть и о тех продуктах, разработка которых остановилась.
Есть Remus на базе Xen, бесплатное решение с открытым исходным кодом. Проект использует технологию микроснэпшотов. К сожалению, документация давно не обновлялась; например, установка описана для Ubuntu 12.10, поддержка которой прекращена в 2014 году. И как ни странно, даже Гугл не нашёл ни одной компании, применившей Remus в своей деятельности.
Предпринимались попытки доработки QEMU с целью добавить возможность создания continuous availability кластера. На момент написания статьи существует два таких проекта.
Первый - Kemari , продукт с открытым исходным кодом, которым руководит Yoshiaki Tamura. Предполагается использовать механизмы живой миграции QEMU. Однако тот факт, что последний коммит был сделан в феврале 2011 года говорит о том, что скорее всего разработка зашла в тупик и не возобновится.
Второй - Micro Checkpointing , основанный Michael Hines, тоже open source. К сожалению, уже год в репозитории нет никакой активности. Похоже, что ситуация сложилась аналогично проекту Kemari.
Таким образом, реализации continuous availability на базе виртуализации KVM в данный момент нет.
Итак, практика показывает, что несмотря на преимущества систем непрерывной доступности, есть немало трудностей при внедрении и эксплуатации таких решений. Однако существуют ситуации, когда отказоустойчивость требуется, но нет жёстких требований к непрерывности сервиса. В таких случаях можно применить кластеры высокой доступности, КВД.
High availability / высокая доступность
В контексте КВД отказоустойчивость обеспечивается за счёт автоматического определения отказа оборудования и последующего запуска сервиса на исправном узле кластера.В КВД не выполняется синхронизация запущенных на нодах процессов и не всегда выполняется синхронизация локальных дисков машин. Стало быть, использующиеся узлами носители должны быть на отдельном независимом хранилище, например, на сетевом хранилище данных. Причина очевидна: в случае отказа ноды пропадёт связь с ней, а значит, не будет возможности получить доступ к информации на её накопителе. Естественно, что СХД тоже должно быть отказоустойчивым, иначе КВД не получится по определению.
Таким образом, кластер высокой доступности делится на два подкластера:
- Вычислительный. К нему относятся ноды, на которых непосредственно запущены виртуальные машины
- Кластер хранилища. Тут находятся диски, которые используются нодами вычислительного подкластера.
- Heartbeat версии 1.х в связке с DRBD;
- Pacemaker;
- VMware vSphere;
- Proxmox VE;
- XenServer;
- Openstack;
- oVirt;
- Red Hat Enterprise Virtualization;
- Windows Server Failover Clustering в связке с серверной ролью “Hyper-V”;
- VMmanager Cloud.
VMmanager Cloud
Наше решение VMmanager Cloud использует виртуализацию QEMU-KVM. Мы сделали выбор в пользу этой технологии, поскольку она активно разрабатывается и поддерживается, а также позволяет установить любую операционную систему на виртуальную машину. В качестве инструмента для выявления отказов в кластере используется Corosync. Если выходит из строя один из серверов, VMmanager поочерёдно распределяет работавшие на нём виртуальные машины по оставшимся нодам.В упрощённой форме алгоритм такой:
- Происходит поиск узла кластера с наименьшим количеством виртуальных машин.
- Выполняется запрос хватает ли свободной оперативной памяти для размещения текущей ВМ в списке.
- Если памяти для распределяемой машины достаточно, то VMmanager отдаёт команду на создание виртуальной машины на этом узле.
- Если памяти не хватает, то выполняется поиск на серверах, которые несут на себе большее количество виртуальных машин.
Практика показывает, что лучше выделить одну или несколько нод под аварийные ситуации и не развёртывать на них ВМ в период штатной работы. Такой подход исключает ситуацию, когда на “живых” нодах в кластере не хватает ресурсов, чтобы разместить все виртуальные машины с “умершей”. В случае с одним запасным сервером схема резервирования носит название “N+1”.
VMmanager Cloud поддерживает следующие типы хранилищ: файловая система, LVM, Network LVM, iSCSI и Ceph . В контексте КВД используются последние три.
При использовании вечной лицензии стоимость программной части кластера из десяти “боевых” узлов и одного резервного составит €3520 или $3865 на сегодняшний день (лицензия стоит €320 за ноду независимо от количества процессоров на ней). В лицензию входит год бесплатных обновлений, а со второго года они будут предоставляться в рамках пакета обновлений стоимостью €880 в год за весь кластер.
Рассмотрим по каким схемам пользователи VMmanager Cloud реализовывали кластеры высокой доступности.
FirstByte
Компания FirstByte начала предоставлять облачный хостинг в феврале 2016 года. Изначально кластер работал под управлением OpenStack. Однако отсутствие доступных специалистов по этой системе (как по наличию так и по цене) побудило к поиску другого решения. К новому инструменту для управления КВД предъявлялись следующие требования:- Возможность предоставления виртуальных машин на KVM;
- Наличие интеграции с Ceph;
- Наличие интеграции с биллингом подходящим для предоставления имеющихся услуг;
- Доступная стоимость лицензий;
- Наличие поддержки производителя.
Отличительные черты кластера:
- Передача данных основана на технологии Ethernet и построена на оборудовании Cisco.
- За маршрутизацию отвечает Cisco ASR9001; в кластере используется порядка 50000 IPv6 адресов.
- Скорость линка между вычислительными нодами и коммутаторами 10 Гбит/с.
- Между коммутаторами и нодами хранилища скорость обмена данными 20 Гбит/с, используется агрегирование двух каналов по 10 Гбит/с.
- Между стойками с нодами хранилища есть отдельный 20-гигабитный линк, используемый для репликации.
- В узлах хранилища установлены SAS-диски в связке с SSD-накопителями.
- Тип хранилища - Ceph.
Данная конфигурация подходит для хостинга сайтов с высокой посещаемостью, для размещения игровых серверов и баз данных с нагрузкой от средней до высокой.
FirstVDS
Компания FirstVDS предоставляет услуги отказоустойчивого хостинга, запуск продукта состоялся в сентябре 2015 года.К использованию VMmanager Cloud компания пришла из следующих соображений:
- Большой опыт работы с продуктами ISPsystem.
- Наличие интеграции с BILLmanager по умолчанию.
- Отличное качество техподдержки продуктов.
- Поддержка Ceph.
- Передача данных основана на сети Infiniband со скоростью соединения 56 Гбит/с;
- Infiniband-сеть построена на оборудовании Mellanox;
- В узлах хранилища установлены SSD-носители;
- Используемый тип хранилища - Ceph.
В случае общего отказа Infiniband-сети связь между хранилищем дисков ВМ и вычислительными серверами выполняется через Ethernet-сеть, которая развёрнута на оборудовании Juniper. “Подхват” происходит автоматически.
Благодаря высокой скорости взаимодействия с хранилищем такой кластер подходит для размещения сайтов со сверхвысокой посещаемостью, видеохостинга с потоковым воспроизведением контента, а также для выполнения операций с большими объёмами данных.
Эпилог
Подведём итог статьи. Если каждая секунда простоя сервиса приносит значительные убытки - не обойтись без кластера непрерывной доступности.Однако если обстоятельства позволяют подождать 5 минут пока виртуальные машины разворачиваются на резервной ноде, можно взглянуть в сторону КВД. Это даст экономию в стоимости лицензий и оборудования.
Кроме этого не можем не напомнить, что единственное средство повышения отказоустойчивости - избыточность. Обеспечив резервирование серверов, не забудьте зарезервировать линии и оборудование передачи данных, каналы доступа в Интернет, электропитание. Всё что только можно зарезервировать - резервируйте. Такие меры исключают единую точку отказа, тонкое место, из-за неисправности в котором прекращает работать вся система. Приняв все вышеописанные меры, вы получите отказоустойчивый кластер, который действительно трудно вывести из строя. Добавить метки