Использование Route Health Injection и IP Mobility при миграции виртуальных машин между ЦОД

При перемещении в другой ЦОД виртуальная машина сохраняет свой IP адрес, а информация о том, где сейчас этот IP адрес находится, распространяется в сеть с помощью сообщений OSPF LSA. В теории этот метод очень хорош и прост. Однако на практике (как всегда) есть ряд нюансов.

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

Второй вариант — внутри гипервизора. Достаточно интересный вариант, который не обладает недостатками предыдущего. Однако на сегодняшний день на практике в своих продуктах этот функционал не реализовал ни один из игроков рынка виртуализации. И, думается мне, это не входит в их планы на будущее. Скорее, интерес для них будет представлять движение в сторону SDN (Software Defined Network). Но, это в любом случае тема для отдельного разговора.

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

Однако у этого варианта есть значительное ограничение. Давайте вспомним о том, что целью наших изысканий было найти решение, при котором после миграции виртуальной машины пользовательские сессии сохранились бы (иначе было бы проще не делать live migration, а переместить машину в другой ЦОД просто выключив ее и сменив IP адрес при включении). В случае использования stateful устройства, трафик существующих сессий должен проходить через один и тот же балансировщик. Однако это противоречит сценарию отработки механизма health-check в RHI (когда необходимо, чтобы балансировщик потерял связь с виртуальной машиной и прекратил анонсирование маршрута). Таким образом, третий вариант не позволяет обеспечить непрерывность пользовательских сессий. Хотя, возможно, кто-то из вендоров уже озаботился описанной проблемой и смог придумать что-то вроде синхронизации состояния своих балансировщиков. Однако мне на глаза, к сожалению, такие решения пока не попадались. Буду благодарен, если кто-то предоставит ссылки или просто поделится информацией в этом направлении.

Должен признать, что еще одним направлением для исследования может быть использование stateless устройства с возможностью выполнять функции health-check и запуска протокола динамической маршрутизации. В среде open-source есть несколько продуктов, которые позволяют запустить OSPF — например, проекты Quagga или BIRD. Однако задачу “прикручивания” health-check к этим продуктам придется решать самостоятельно. Кроме этого, такой сервер на пути между клиентами и приложениями становится единой точкой отказа и требуется озаботиться его отказоустойчивостью. В силу большого объема информации, который нужно осилить, чтобы составить какое-либо решение, я отложу обсуждение этой темы. Возможно, в дальнейшем (если у читателей будет интерес) этому будет посвящена отдельная статья в блоге.

Запуск OSPF не является единственной проблемой в случае применения схемы с RHI. Как вы могли убедиться из иллюстрации, каждый маршрут, создаваемый виртуальной машиной, имеет маску /32. Наличие большого количества маршрутов в таблицах маршрутизации отнюдь не добавляет производительности коммутаторам ЦОД и затрудняет процесс траблшутинга, в случае если что-то где-то не работает. К тому же, если речь идет не о приватных адресах, а о публичных, которые впоследствии анонсируются в сторону интернет-провайдера, то здесь все становится еще сложнее, т.к. провайдер, скорее всего не захочет принимать от вас ничего длиннее маски /24. В итоге, вся информация о перемещении IP адреса между ЦОД потеряется в процессе суммаризации.

В итоге, технология RHI, на мой взгляд, пока слабо подходит для обеспечения миграции без перерыва сессий. Единственным рабочим вариантом остается запуск демона OSPF внутри гостевой OS — что не является удобным с точки зрения администрирования.

Поговорив о RHI, можно плавно перейти ко второй части обсуждения — а именно, к использованию встроенных механизмов Mobility в протокол IPv6. Думаю, многие из вас как минимум слышали об этом протоколе и, возможно, даже пытались с ним работать. Одна из прелестей этого протокола — отсутствие необходимости иметь приватные и публичные адреса, т.к. больше нет необходимости в их экономии. А еще одним приятным нововведением стала встроенная поддержка мобильности IP адресов. Это означает, что задачу выбора ЦОД при перемещении виртуальной машины можно было бы попытаться решить простым и доступным средством без изысканных технологий и дополнительного железа (благо, почти все оборудование сейчас поддерживает IPv6). На практике все как всегда не настолько радужно, однако и не безнадежно. Давайте поразбираемся, как бы это могло выглядеть.

Технологии IP Mobility, как, собственно, и RHI — далеко не новы, и существуют со времен протокола IPv4 (описаны в RFC 3344, позднее замененном на RFC 5944). Возникает закономерный вопрос — почему бы не воспользоваться ими? Дело в том, что архитектура решения предусматривает наличие компонентов Home Agent и Foreign Agent (как правило, его функции выполняет ближайшее к клиенту устройство L3), и специального ПО —  Mobile Agent — на клиентском терминале. Принцип функционирования классического IPv4 Mobility представлен далее:

Терминал, получив IP адрес в т.н. “домашней” сети, регистрируется на Home Agent, который с этого момента играет роль своеобразного якоря для трафика клиента. В случае если терминал перемещается в другую сеть (не “домашнюю”), он получает другой адрес (т.н. Care of Address) и регистрируется на Foreign Agent, который передает данные о регистрации на Home Agent. Весь трафик, приходящий на терминал из внешнего мира, адресуется на основной (домашний) адрес терминала и попадает на HA. После этого HA туннелирует трафик к FA и он попадает на терминал.

Все это не выглядит простым и требует введения в сеть ряда дополнительных компонентов (FA и HA). А таких продуктов как Mobile Agent для серверных версий Windows и Linux — мне попросту найти не удалось.

Кроме этого, как видно из предыдущей иллюстрации, путь трафика не является оптимальным и задача выбора ЦОД в соответствии с расположением виртуальной машины не решается.

Вот здесь нам и пригодятся нововведения, которые появились в шестой версии протокола IP. Одно из новых сообщений позволяет терминалу сообщить клиенту соответствие Home Address <-> Care of Address. Получив это сообщение, клиент может направить трафик сразу на новый адрес терминала, тем самым избежав ситуации с неоптимальностью путей прохождения трафика. Эта ситуация проиллюстрирована на следующем видео:

Но остался еще вопрос — как быть с Mobile Agent на хосте? Для этого случая тоже есть решение, и называется оно Proxy Mobile IP (RFC 5213). В случае применения этой технологии стек TCP/IP на хосте работает в обычном режиме. Все функции по детектированию перемещений хоста возлагаются на ближайшее L3 устройство, называемое MAG — Mobile Access Gateway. Кстати, собственно механизмы детектирования в RFC не описаны. Но, к примеру, для коммутаторов L3 это может быть детектирование отказа на канальном уровне. В случае, когда на уровне доступа находится устройство L2, может быть использован механизм Neighbor Unreachability Detection (RFC 4861) для IPv6. Отмечу, что в случае Proxy Mobile IPv6 адрес на терминале не изменяется после миграции (т.е, не появляется т.н. CoA — Care of Address). В итоге, применяя Proxy Mobile IPv6 можно добиться поведения, когда сессии приложения не разрываются при перемещении виртуальной машины между ЦОД.

Однако в этом подходе есть и минусы. Первый и, пожалуй, наиболее серьезный, состоит в тои, что на сегодняшний момент большинство ЦОД продолжают работать, используя для адресации серверов протокол IPv4. То же самое, кстати, касается и клиентов — ведь согласитесь, большинство из нас прямо сейчас используют на своем компьютере именно четвертую версию протокола? Если речь идет о доступе к приложениям из корпоративной сети, то, теоретически, эту проблему можно решить административно, введя т.н. dual-stacking на рабочих местах клиентов и на серверах. Однако, думаю, на практике мало кто будет этим заниматься — потому что иметь в сети два протокола означает в два (а то и более) раза больше головной боли для администратора. Тем более, если в обозримом будущем компания не планирует использование IPv6 в своей корпоративной сети.

Если же речь идет о доступе к приложениям из Интернета, то здесь все сложнее, потому что заставить клиентов пользоваться IPv6 не представляется возможным. Теоретически, опять же, можно делать NAT 46 (превращать IPv4 в IPv6) на границе сети. Однако такой подход будет работать для ограниченного круга приложений, которые хорошо относятся к наличию NAT на пути. Либо придется озаботиться наличием т.н. Application Layer Gateway (ALG), который возьмет на себя работу по корректировке содержимого пакетов (на уровне приложения) при прохождении через NAT. А продолжая тему дополнительных устройств, стоит отметить, что при использовании Proxy Mobile IP появляется функция MAG (Mobile Access Gateway), поддержку которой также следует уточнять у производителя оборудования.

Думаю, что на этом можно завершить обсуждение двух обозначенных тем. Хотелось бы еще раз подчеркнуть, что я не ставил целью рассказать, как работает OSPF, RHI и Proxy Mobile IP. Скорее, интересно было представить, как можно использовать эти технологии для решения конкретной задачи — обеспечения непрерывности пользовательских сессий при миграции VM с приложением между ЦОД. Резюмируя описанные решения:  для наиболее простых приложений (например, веб) достаточно хорошо будет работать вариант с балансировщиком и RHI. В более сложных случаях — можно подумать о внедрении технологии Proxy Mobile IP с учетом описанных выше нюансов и ограничений.