Мобильность виртуальных машин. Действительно ли нужна L2 связность?

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

• Адрес IP и MAC виртуальной машины
• Адрес IP и MAC шлюза по умолчанию
• Состояние ARP кэша (как самой виртуальной машины так и других хостов из её сети)
• Маршрутную информацию о достижимости виртуальной машины

Некоторые скажут, что это все автоматически сохраняется, если протянуть сеть (VLAN) между площадками ЦОД, как изображено на следующем рисунке:

Недостатком такого решения является увеличение т.н. failure domain (подробнее об этом уже писалось в одной из статей раздела “Блоги” нашего веб-сайта)

Можно отказаться от L2 между площадками и сохранять видимость единого VLAN другими способами (VXLAN, OTV, EVPN и т.п). Однако при этом в сеть вводится дополнительная Control Plane, что уменьшает надежность такой схемы и одновременно усложняет администрирование.
Существует и другой подход к решению задачи мобильности приложений, для которого достаточно L3 связности между площадками, и который не вводит дополнительной Control Plane.

1. Детектировать расположение виртуальной машины;
2. Распространить информацию о месте расположения виртуальной машины в сеть ЦОД;
3. Распространить информацию об IP и MAC адресе шлюза по умолчанию в новое место запуска виртуальной машины;
4. Заполнить ARP кэш всех виртуальных машин таким образом, чтобы они могли передавать трафик друг другу даже будучи разделенными сетью L3.

Для решения первой задачи – детектирования расположения виртуальной машины – используется таблица ARP шлюза по умолчанию. Эта таблица всегда содержит актуальную информацию вследствие того факта, что после перемещения “на горячую” машина продолжает генерировать IP трафик, создавая тем самым запись в таблице ARP в новом месте запуска.

Следующая задача – распространить эту информацию, чтобы клиенты могли подключаться к приложению, расположенному на этой виртуальной машине. Для обмена информацией используется протокол маршрутизации – OSPF или BGP. Он запускается на коммутаторе, выполняющем роль шлюза по умолчанию для виртуальных машин. Вы спросите: “Как информация из таблицы ARP попадет в таблицу маршрутизации?” На каждом коммутаторе работает процесс (демон), в задачу которого входит редистрибьюция IP адресов из таблицы ARP в таблицу протокола маршрутизации. Фактически, мы заполняем таблицу маршрутизации маршрутами по маске /32, ведущими к каждой виртуальной машине.

Для решения третьей задачи используется комбинация метода маршрутизации anycast и протокола VRRP. Каждый коммутатор ЦОД становится обладателем одного и того же виртуального IP и MAC адреса (он же адрес шлюза по умолчанию) за счет использования VRRP.

Для решения четвертой задачи на каждом из шлюзов запускается механизм Proxy ARP. Благодаря этому у каждой виртуальной машины в результате отправки ARP запросов в кэше будет несколько записей о других машинах в пределах IP сети, однако MAC адреса у этих записей будут одинаковые, указывающие на ближайший шлюз по умолчанию. А уже задача шлюза – отмаршрутизировать пакет в соответствии со своей таблицей маршрутизации, где, напомню, присутствует полный набор маршрутов /32, к каждой виртуальной машине в ЦОД. Справедливости ради, стоит заметить что на шлюзе по умолчанию необходимо запускать Proxy ARP в режиме, который некоторые производители называют Local Proxy ARP. Дело в том, что в соответствии с RFC 1027, шлюз по умолчанию не будет отвечать на ARP, если запрашиваемый адрес доступен через интерфейс, с которого пришел запрос.

В итоге решение выглядит так, как показано на следующем рисунке:

После миграции виртуальной машины VM2 на коммутаторе площадки 2 появляется соответствующая запись в таблице ARP, откуда она вбрасывается в BGP. В итоге, в сети ЦОД становится известно о новом месте расположения VM.

Как и описывалось, на каждом коммутаторе создается IP и MAC адрес шлюза по умолчанию. А для того, чтобы виртуальные машины на разных площадках могли общаться между собой, запущен Proxy ARP. Благодаря ему в таблице ARP каждой из машин появляется запись, говорящая о том, что чтобы отправить трафик на виртуальную машину VMx, в качестве Destination MAC нужно использовать 00:00:00:00:00:01, являющийся адресом шлюза по умолчанию.

Нужно отметить, что в сценарии горячей миграции у описанного метода есть и некоторые ограничения.

Вспомним, что после миграции виртуальной машины остается запись в кэше ARP шлюза по умолчанию и соответствующая ей запись в таблице маршрутизации. Механизм явной очистки ARP таблиц не предусмотрен. Поэтому после перемещения машины некоторое время в пределах ЦОД будут актуальны две маршрутных записи, несогласованные между собой. Одна – о новом месте запуска, другая – старая, т.к. на исходном месте запуска машина все еще считается непосредственно подключенной и, эта запись является более предпочтительной по сравнению с приходящими по BGP обновлениями. Она исчезнет из таблицы только когда истечет ее время жизни в кэша ARP. В итоге, после перемещения машины существующие TCP сессии к приложению можно будет возобновить только после истечения времени жизни для соответствующей ARP записи. При условии, что TCP сессия не завершится к этому моменту по таймауту. Поэтому, при настройке коммутаторов необходимо задавать время жизни записи в кэше ARP меньше, чем таймаут TCP сессий для приложений. Точных значений, определяющих время жизни TCP сессий, нет, т.к. для каждой сессии этот параметр устанавливается индивидуально, с учетом RTT (Round-Trip Time). Однако, можно сделать приблизительную оценку. Для серверов на базе Windows, нижняя оценка времени жизни сессии составляет ~ 4-5 секунд, для серверов на базе Linux — ~ 25 секунд.

Еще одно ограничение связано с тем, что виртуальные машины подключены к программному коммутатору (vswitch) в гипервизоре. Это приводит к тому, что записи ARP могут содержать реальные MAC адреса интерфейсов, а не виртуальный адрес шлюза по умолчанию. Как следствие, при перемещении машины на другую площадку с такими хостами потеряется связность. Для парирования этого ограничения можно, к примеру, в пределах vswitch использовать технологию Private VLAN. Тогда виртуальные машины смогут получить ARP ответ только от шлюза по умолчанию, но не от соседей по vswitch.

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