Глава 12 — здесь

Введение

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

В этой модели, оператору необходимо обеспечить полную совместимость всех компонентов и требуемые параметры работы системы.

Разделение оборудования и ПО значительно усложняет эту задачу для оператора. Может создаться впечатление, что виртуализация имеет негативное влияние на надёжность. Однако, на самом деле, это не так. Автоматизация всего рабочего цикла, быстрое восстановление сервисов в случае отказа может значительно повысить надёжность.

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

Сценарий отказа

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

Каждый компонент VNFC обычно имеет резервирование (Redundancy) 1+1. Это означает, что во время установки VNF, создаются две копии компонента VNFC, активная и резервная. Эти два экземпляра VNFC либо могут иметь доступ к общей базе данных, где хранится информация о состоянии; либо активный экземпляр VNFC может изменять состояние резервного VNFC, в случае изменения состояния. В любом случае, резервный экземпляр VNFC в любой момент времени готов продолжать работу, в случае отказа активного экземпляра.

Для проверки на отказ, обычно используется одна из форм проверки работоспособности между двумя VNFC. Например, если требуется очень быстрое обнаружение отказа, два VNFC могут посылать друг другу сообщения о работоспособности каждые 10 мс. Когда резервный VNFC не получает подтверждение работоспособности своего активного товарища, он решает, что тот отказал, и после этого сам становится активным. В этом случае сервис восстанавливается в течение не более 50 мс после отказа.

Однако, после этого ставший активным VNFC оказывается незащищённым. Поэтому необходимо как можно скорее создать новый экземпляр VNFC, который теперь будет резервным. Его созданием ведает VNFM, который получает сигнал об отказе VNFC, либо от нового активного VNFC; либо от VIM, который может обнаружить отказ сервера, на котором работал отказавший VNFC; либо от других элементов, которые могут обнаруживать отказ.

В результате, VNFM взаимодействует с VIM, чтобы создать новый экземпляр VNFC.

Факторы, влияющие на надёжность

• Отказы сервера и гипервизора

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

• Отказы сети

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

• Надёжность кода VNF

Надёжность кода VNF – третий важный фактор надёжности NFV. ПО VNF может содержать баги, которые могут вызвать недоступность VNF.

• Системы управления

Восстановлением отказавшего VNFC занимаются VNFM и VIM. VNFM инициирует создание или восстановление отказавшего VNFC. VIM затем выполняет эти действия. Если VNFM или VIM недоступны, то восстановление произвести не удаётся, и как следствие VNF временно не будет иметь требуемого уровня защиты.

Например, если какой-то VNFC имеет защиту 1+1, то отказ одного из VNFC оставит VNF в незащищённом состоянии. Последующий отказ второго VNFC может привести к недоступности VNF. Поэтому доступность VNFM и VIM очень важны для общей надёжности NFV.

• Скорость восстановления VNFC

Из изложенного ясно, что чем скорее отказавший VNFC будет восстановлен, тем меньше времени VNF проведёт в незащищённом состоянии. Если даже VNFM и VIM доступны, то вся процедура обнаружения отказа, выделения нового сервера, создания там виртуальной машины, загрузка и запуск образа VNFC, и прочие операции, может занять довольно значительное время.

В невиртуализированных сетях, однако, могут пройти часы, прежде чем удаётся найти и заменить отказавший модуль в каком-либо оборудовании. В NFV полное восстановление VNFC – дело нескольких минут, или меньше. На надёжность NFV это оказывает небольшое влияние.

• Задержки между VNFC

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

• Отказ домена

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

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

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

Структурированный процесс обеспечения надёжности

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

1. Оценка работоспособности инфраструктуры.

• Ожидаемый процент отказов серверов и гипервизоров?
• Ожидаемый процент отказов сети?
• Ожидаемая задержка в полностью нагруженной инфраструктуре?
• Есть ли отказы, которые могут затронуть более чем один север в данным момент времени?

2. Оценка и тестирование надёжности критичных систем управления

• Ожидаемая доступность VNFM, VIM и контроллеров SDN

На основе этих данных можно выбрать требуемую степень резервирования VNFC, VNF серверов и сетевых соединений.

Продолжение — здесь.

***