Программное обеспечение высокой доступности

Программное обеспечение высокой доступности — это программное обеспечение, используемое для обеспечения работы и доступности систем большую часть времени. Высокая доступность — это высокий процент времени, в течение которого система функционирует. Формально его можно определить как (1 – (время простоя/общее время))*100%. Хотя минимально необходимая доступность зависит от задачи, системы обычно пытаются достичь доступности 99,999 % (5 девяток). Эта характеристика слабее, чем отказоустойчивость , которая обычно стремится обеспечить 100% доступность, хотя и со значительными потерями в цене и производительности.

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

Функции

Типичное программное обеспечение высокой доступности предоставляет функции, которые:

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

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

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

Включить активную/резервную связь (в частности, контрольную точку) :Активные подсистемы должны взаимодействовать с резервными подсистемами, чтобы гарантировать, что резервная готова взять на себя управление с того места, где остановилась активная. Программное обеспечение высокой доступности может предоставлять абстракции связи, такие как резервные очереди сообщений и событий, чтобы помочь активным подсистемам выполнить эту задачу. Кроме того, важная концепция, называемая «контрольными точками», характерна исключительно для высокодоступного программного обеспечения. В системе с контрольными точками активная подсистема определяет все свое критическое состояние и периодически обновляет резервную систему при любых изменениях этого состояния. Эту идею обычно абстрагируют как распределенную хеш-таблицу : активная система записывает записи ключ/значение в таблицу, а активная и резервная подсистемы считывают из нее. В отличие от «облачной» распределенной хеш-таблицы ( Chord (peer-to-peer) , Kademlia и др.) контрольная точка реплицируется полностью. То есть все записи в хеш-таблице «контрольной точки» доступны для чтения, пока работает одна копия. ^[1] Другой метод, называемый [контрольная точка приложения], периодически сохраняет все состояние программы. ^[2]

Включите обновления во время работы :В Service Software Upgrade — это возможность обновлять программное обеспечение без ухудшения качества обслуживания. Обычно это реализуется в резервных системах путем выполнения так называемого «последовательного» обновления — обновления резервной системы, в то время как активная система предоставляет услуги, переключения при сбое и последующего обновления старой активной системы. Еще одной важной особенностью является возможность быстрого возврата к более старой версии программного обеспечения и конфигурации в случае сбоя новой версии. ^[3]^[4]

Минимизируйте задержку в режиме ожидания и обеспечьте корректность режима ожидания :Задержка в режиме ожидания определяется как время между моментом, когда резервному устройству сообщают о необходимости стать активным, и моментом, когда он фактически предоставляет услугу. Системы «горячего» резерва — это системы, которые активно обновляют внутреннее состояние в ответ на активные контрольные точки системы, что приводит к простою в миллисекундах. «Холодные» резервные системы находятся в автономном режиме до тех пор, пока активная система не выйдет из строя, и обычно перезапускаются из «базового» состояния. Например, многие облачные решения перезапускают виртуальную машину на другой физической машине в случае сбоя базовой физической машины. Задержка «холодного» переключения в режиме ожидания может варьироваться от 30+ секунд до нескольких минут. Наконец, «теплый» резерв — это неофициальный термин, охватывающий все системы, которые работают, но должны выполнить некоторую внутреннюю обработку, прежде чем стать активными. Например, система «теплого» резерва может обрабатывать задания с низким приоритетом — в случае сбоя активной системы она прерывает эти задания и считывает состояние активной контрольной точки перед возобновлением обслуживания. Задержки теплого резерва зависят от объема данных, находящихся в контрольной точке, но обычно имеют задержку в несколько секунд.

Архитектура системы

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

Самая простая конфигурация (или «модель резервирования») — 1 активный, 1 резервный или 1+1. Другая распространенная конфигурация — N+1 (N активная, 1 резервная), которая снижает общую стоимость системы за счет меньшего количества резервных подсистем. Некоторые системы используют полностью активную модель, преимуществом которой является то, что «резервные» подсистемы постоянно проверяются.

Конфигурации также могут быть определены с использованием подсистем активного, горячего резерва и холодного резерва (или простоя), расширяя традиционную номенклатуру «активный+резервный» до «активный+резервный+ожидающий» (например, 5+1+1). Обычно подсистемы «холодного резерва» или «холостого» активны для работы с более низким приоритетом. Иногда эти системы расположены далеко от своей резервной пары в соответствии со стратегией, называемой географической избыточностью. ^[5] Эта архитектура стремится избежать потери обслуживания из-за физически локальных событий (пожар, наводнение, землетрясение) путем разделения резервных машин.

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

Использование в промышленности

За последние 20 лет телекоммуникационные сети и другие сложные программные системы стали неотъемлемой частью деловой и развлекательной деятельности.

«В то же время [поскольку экономика находится в состоянии спада], почти 60% — это шесть из 10 предприятий — требуют 99,999. Это четыре девятки или пять девяток доступности и времени безотказной работы критически важных бизнес-приложений.А 9% респондентов, то есть почти одна из 10 компаний, говорят, что им требуется более пяти девяток времени безотказной работы. Это означает отсутствие простоев. Другими словами, у вас должны быть действительно пуленепробиваемые приложения и аппаратные системы. Итак, вы знаете, что вы используете? Ну, во-первых, у вас есть кластеры с высокой доступностью или более дорогие и сложные отказоустойчивые серверы». ^[6]

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

Оборона/Военные : в последнее время программное обеспечение высокой доступности нашло применение в оборонных проектах как недорогой способ обеспечить доступность пилотируемых и беспилотных транспортных средств. ^[7]

Космос : Программное обеспечение высокой доступности предлагается для использования нерадиационно защищенного оборудования в космических условиях. Радиационно-стойкая электроника значительно дороже и имеет более низкую производительность, чем стандартное оборудование. Но программное обеспечение высокой доступности, работающее на одном или паре радиационно-защищенных контроллеров, может управлять многими резервными высокопроизводительными, нерадиационными компьютерами, потенциально обеспечивая аварийное переключение и сброс их в случае сбоя. ^[8]

Использование в облаке

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

Стандарты

Форум доступности служб определяет стандарты высокой доступности с учетом приложений. ^[9]

См. также

Ссылки

^ Форум доступности услуг. «Сервис КПП» .
^ Куперман, Джин. «Распределенная многопоточная контрольная точка». dmtcp.sourceforge.net . {{cite web}}: Отсутствует или пусто |url= ( помощь )
^ Cisco Systems, Inc. «Обновление программного обеспечения Cisco IOS High Availability In Service» (PDF) . www.cisco.com .
^ Джунипер Нетворкс. «Понимание процесса обновления программного обеспечения» .
^ Бауэр, Эрик; Адамс, Рэнди; Юстас, Дэниел (ноябрь 2011 г.). За пределами избыточности: как географическая избыточность может улучшить доступность услуг и надежность компьютерных систем . Wiley-IEEE Press. ISBN 978-1-118-03829-1 .
^ ДиДио, Лора. «Тенденции высокой доступности и отказоустойчивости» .
^ ОткрытьClovis. «SAIC выбирает OpenClovis SAFPlus для проекта ACTUV» .
^ Самсон, Джон. «Надежная многопроцессорная (DM) архитектура для космических приложений» (PDF) . Архивировано из оригинала (PDF) 4 февраля 2015 г. Проверено 4 февраля 2015 г.
^ «Форум доступности услуг — Главная» . www.saforum.org . Архивировано из оригинала 6 октября 2008 г. Проверено 14 января 2020 г.

Внешние ссылки

[1] Форум доступности услуг. «Сервис КПП» .

[2] Куперман, Джин. «Распределенная многопоточная контрольная точка». dmtcp.sourceforge.net . {{cite web}}: Отсутствует или пусто |url= ( помощь )

[3] Cisco Systems, Inc. «Обновление программного обеспечения Cisco IOS High Availability In Service» (PDF) . www.cisco.com .

[4] Джунипер Нетворкс. «Понимание процесса обновления программного обеспечения» .

[5] Бауэр, Эрик; Адамс, Рэнди; Юстас, Дэниел (ноябрь 2011 г.). За пределами избыточности: как географическая избыточность может улучшить доступность услуг и надежность компьютерных систем . Wiley-IEEE Press. ISBN 978-1-118-03829-1 .

[6] ДиДио, Лора. «Тенденции высокой доступности и отказоустойчивости» .

[7] ОткрытьClovis. «SAIC выбирает OpenClovis SAFPlus для проекта ACTUV» .

[8] Самсон, Джон. «Надежная многопроцессорная (DM) архитектура для космических приложений» (PDF) . Архивировано из оригинала (PDF) 4 февраля 2015 г. Проверено 4 февраля 2015 г.

[9] «Форум доступности услуг — Главная» . www.saforum.org . Архивировано из оригинала 6 октября 2008 г. Проверено 14 января 2020 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]