Окончание статьи.

Перейти к части 1
Перейти к части 2

4. Системные сервисы и операционные среды

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



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

Может показаться естественным шагом установить внутри виртуальной машины ту же самую версию Linux, что и на поддерживающей её хост-системе (то есть, например, SLES или RHEL). Это имеет те преимущества, что требует учёта особенностей и поддержания политики обновления только одного продукта, а также позволяет использовать общую лицензию для физического сервера и его виртуальных машин. Однако, данный подход имеет и существенный недостаток, связанный с тем, что SLES и RHEL – это дистрибутивы, гораздо более ориентированные на администратора, управляющего стандартными приложениями, нежели на разработчика, и поддержка на них окружения для выполнения программ, полученных в последних версиях средств разработки, может потребовать существенной дополнительной работы по управлению конфигурацией системных и внешних пакетов.

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


Разумеется, ОС ВМ не менее, чем ОС физической машины, потенциально способна к сбоям и отказам. Задача избыточности вычислительной платформы, на физическом уровне решаемая кластеризацией, на виртуальном уровне решается реализацией фунций системы на нескольких взаимосвязанных виртуальных машинах, контролирующих работу друг друга. Задачу контроля работоспособности, на физическом уровне решаемую строжевыми таймерами, можно было бы на виртуальном уровне решать так же – виртуальным устройством сторожевого таймера — но гораздо проще и функциональнее осуществлять из контролирующей виртуальной машины выдачу команд кластеру на перезапуск контролируемой виртуальной машины (разумеется, контроль должен быть перекрёстным). Образы виртуальных машин легко сохранять для создания точек отката и аварийного восстановления.

5. Вычислительные процессы

Наконец, мы дошли до того, ради чего всё затевалось – до тех самых персистентных процессов в управляющих ситемах реального времени.

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

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

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

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

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

while [1]
do
my_executable_module
done


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

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