УДК 004.052.3

Обеспечение непрерывности сервиса

Феоктистов Артём Алексеевич – магистрант МИРЭА – Российского технологического университета.

Новичков Дмитрий Евгеньевич – ассистент кафедры Математического обеспечения и стандартизации информационных технологий МИРЭА – Российского технологического университета.

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

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

Введение

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

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

Как резерв может быть реализован

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

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

Рисунок 1. Архитектура холодного StandBy резервирования.

Рисунок 2. Архитектура горячего StandBy резервирования.

N-ый резерв и параллельное исполнение реализовываются путём создания на нескольких площадках одинакового набора технических средств и постоянного обслуживания промышленной нагрузки. Для обеспечения равномерности нагрузки на контурах точкой входа в систему служит балансировщик нагрузки. Отличие параллельного исполнения от N-ого резервирования отличается тем, что все контуры исполняют одинаковые запросы, чем обеспечивают гарантированную доставку в случае неисправности одного из контуров в то время, как контуры N-ого резервирования исполняют разные запросы, обслуживая 1/N от всего трафика (в случае равномерной балансировки).

Рисунок 3. Архитектура резервирования с высокой степенью доступности.

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

Таблица 1. Зависимость допустимого времени простоя от процента доступности.

Процент доступности	Допустимое время простоя минут в год
99,0%	5256
99,9%	525,6
99,99%	52,56
99,999%	5,256
99,9999%	0,5256

Как проводить работы без прерывания сервиса

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

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

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

Поведение системы в случае аварии

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

Принятие решения о переходе на резерв может производиться как в автоматическом режиме, так и в ручном. Автоматизированным методом определения «сбойности» одного из модулей в высоконагруженных системах называется «healthcheck», который формирует мониторинг состояния системы – heartbeat. В зависимости от реализации, «healthcheck» может сигнализировать как о сетевой недоступности узла, так и о замедлении его работы, говорящей о высоком шансе не уложиться в установленное время исполнения запроса. В «контейнеризированных» средах исполнения эти проверки вынесены в разные понятия: liveness probe – проверяющая сетевую доступность узла и readiness probe – проверяющая стабильность узла.

Заключение

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

Список литературы

1. Резервирование – Основы теории надежности информационных систем : сайт. – URL: https://studref.com/388361/informatika/rezervirovanie (дата обращения: 05.11.2022).
2. Катастрофоустойчивые IT-системы: как внедрить в своей компании : сайт. – URL: https://habr.com/ru/company/croc/blog/143877/ (дата обращения: 05.11.2022).
3. Отказоустойчивая кластеризация - общие сведения : сайт. – URL: https://interface31.ru/tech_it/2014/06/otkazoustoychivaya-klasterizaciya-obschie-svedeniya.html (дата обращения: 06.11.2022).
4. High Availability Cluster: Concepts and Architecture : сайт. – URL: https://bluexp.netapp.com/blog/cvo-blg-high-availability-cluster-concepts-and-architecture (дата обращения: 12.11.2022).
5. High-Availability Cluster (What Is It & Why Does It Matter) : сайт. – URL: https://www.weka.io/learn/hpc/high-availability-clusters (дата обращения: 12.11.2022).