Обеспечение стабильной работы облака

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

1. стабильность организации интернет-канала;
2. корректная сетевая и “железная” архитектура без узких мест;
3. стабильность программного обеспечения и гипервизора;
4. надежный дата-центр, в котором нет проблем с энергопитанием и охлаждением.

А теперь разберем эти факторы подробнее:

Интернет

Одной из наиболее часто встречающихся проблем у облачного хостинга – это нестабильность интернет-канала. Он может не обеспечивать должной пропускной способности или не иметь шейпера. Что приведет в какой-то момент к его перегрузке одним или парой активных клиентов. Или не иметь защиты от DDOS. Очень важно, чтобы интернет канал был представлен не одним, а двумя или более провайдерами, с настроенным протоколом BGP между ними. Дополнительным фактором обеспечение стабильности интеренета в облаке будет отказоустойчивое каналообразующее оборудование. Можно иметь много входящих линков от провайдеров, но если они все будут подключаться в единственный маршрутизатор, то это будет точка сбоя. Поэтому важно выбирать хостинг-провайдера, у которого маршрутизаторы зарезервированы, в идеале находятся в Active-Active кластере.

Железо

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

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

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

• доступность дисков в массивах;
• нагрузку IOPS на массивах и лунах;
• загрузку CPU;
• загрузка SAN сети.

Система хранения данных

Следующий фактор надежности – это система хранения данных. Как не парадоксально звучит, но софт – это более стабильная компонента, нежели “железо”. Все-таки основным генератором неожиданных проблем является аппаратная составляющая, которая уже порождает сбои и ошибки программной части. В данном разделе хочу обратить внимание на выбранную архитектуру системы хранения данных облака. Очень грубо её можно разбить на два варианта:

• структура с децентрализованным хранением данных, использующая локальные диски;
• структура с централизованным хранением данных, использующая стореджы (аппаратные или программные) и соотвествующую SAN сеть.

У каждой из этих структур есть свои преимущества и недостатки, опишу их в таблице ниже:

Гипервизор

Дополнительный важный программный компонент – это гипервизор, который является сердцем облака. Систем виртуализации существует большое количество, как платных, так и условно бесплатных. Самые известные из платных решений – VMWare и Hyper-V. Несмотря на то, что их сейчас нельзя приобрести и поддержка производителя затруднена, большое количество хостинг-провайдеров продолжают их использовать. Крупные провайдеры осуществляют поддержку вендора через личные связи или зарубежных партнеров, более мелкие – по огромной базе знаний проблем из Интернета. Такая архитектура вполне имеет право на существование даже сейчас. Данные решения очень зрелые и без экстренных обновлений вполне способны долго и стабильно работать. Вторая группа – это условно бесплатные гипервизоры. Здесь наиболее известное решение – OpenStack и Proxmox. Что про них можно сказать? OpenStack – это мощный, навороченный, сложный, страшный зверь, который из коробки работать фактически не будет. Вместе с ним должна идти мощная и дорогая команда специализированных разработчиков и инженеров. Однако крупные хостинг-провайдеры идут этим путем, продукт дает большие возможности для доработок под себя. Proxmox гораздо более простое решение, зато способное качественно и быстро работать из коробки. Функционал у него не такой богатый как у OpenStack, но для небольшого хостинг-провайдера достаточный. И он не потребует для эксплуатации большого и дорого штата инженеров и разработчиков. В основе обоих вышеперечисленных продуктов лежит открытый гипервизор KVM, но в Proxmax он изначально оптимизирован и работает из коробки заметно шустрее. Существует еще третий класс гипервизоров – это различные отечественные платные решения сделанные на базе OpenStack или oVirt. В этой категории сейчас идет реальное импортозамещение у крупного бизнеса и государственных структур. Поэтому российские разработки сейчас на подъеме и развиваются семимильными шагами. Такими темпами они вскоре могут составить конкуренцию именитым зарубежным брендам. Так что считаю – их сейчас тоже можно установливать для управления коммерческим облаком.

Резервное копирование

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

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

Система резервного копирования в облаке должна иметь глубину хранения бэкапов не менее недели, а лучше две. Обычно для резервного копирования в облаках применяют комплексные продукты, резервирующие виртуальную машину целиком. Наиболее известный такой продукт в России – Veeam. Я считаю, что для критических данных (например, баз данных) стоит создать параллельную систему резервного копирования, независимую от основной. Даже в лучших решениях случаются сбои, поэтому лучше подстраховаться. Резервных копий много не бывает! В облаке EFSOL мы имеем базовую глубину хранения 2 недели + месячный + квартальный и полугодовой бэкап. Наш опыт показал, что это иногда полезно бухгалтерам и в случае поиска потерянного документа. Так же мы делаем параллельные бэкапы баз встроенными средствами копирования самой СУБД, что является подстраховкой на случай ошибок бэкапов в Veeam.

Дата-центр

Важно обратить внимание на выбор дата-центра (ЦОД). Если площадка размещения серверов окажется не слишком надежной, то при условии, что все вышеперечисленное сделано и настроено идеально – это не защитит от сбоев. Все дата центры поделены на классы надежности. В детали вдаваться не буду – важно выбирать хостинг-провайдера, который располагается в дата-центре класса Tier-3 или выше. (Правда, в России нет Tier-4, т.к. это очень дорого).

• Но есть нюанс! Выбирайте сертифицированный Tier-3 ЦОД, ведь на рынке очень много дата-центров уровня Tier-3 Design.

Что значит “Tier-3 Design”? Это дата-центр, спроектированный по всем требованиям Tier-3 за исключением одного момента: он не находится в отдельно стоящем здании! А это важно, потому что в таком случае может случиться ЧП не по вине сотрудников ДЦ, а соседей. Например, случаи из практики: при реконструкции части здания, в котором находился Дата-центр Tier-3 Design, с крана отвалилась балка и упала на чиллеры охлаждения. Естественно летом… в результате получили перегрев Дата-центра. Или был еще случай: загорелась общая крыша у соседей, в результате при тушении пожара залили все здание водой. Благо оборудование не пострадало – находилось в гермозонах, но электричество пожарники отключили на двое суток. Да и воду потом откачивали из под фальш-пола еще неделю.