О подключении серверов к фабрике
Задачам, встречающимся на границе двух различных систем, зачастую не уделяют должного внимания. Взять, к примеру, центр обработки данных, с серверами и фабрикой.
Как правило, объект “сервер” работает под управлением среды виртуализации. И, как правило, упор при этом делается на виртуализацию аппаратных ресурсов (процессор, память, диск). С другой стороны, есть объект “фабрика”, функция которого – предоставление транспорта для трафика серверов. Естественным образом появляется задача – наладить взаимодействие между объектами.
Прежде всего, необходимо понять, каких целей мы хотим добиться, решая задачу включения серверов в фабрику. Думаю, наиболее вероятной целью является обеспечение доступности приложений, запускаемых на сервере. А именно, при потере любого из элементов ЦОД – отдельного интерфейса, сервера или коммутатора перерыв в сервисе не должен превысить некоторого количества секунд (какого – каждый решает для себя сам).
В такой трактовке важным является тот факт, что для парирования отказа сервера необходимо иметь возможность запустить приложение на другом, рабочем оборудовании. И чтобы в новом месте приложение чувствовало себя “как дома”, для него необходимо сохранить сетевое окружение, а именно:
— IP-адрес;
— маску сети;
— адрес шлюза по умолчанию.
Можно рассмотреть следующие подходы:
— отнести границу L2/L3 от приложения, чтобы при перезапуске ее не пересекать, и, как следствие, не менять сетевое окружение (рис. 1):
— в случае перезапуска переносить границу L2/L3 вместе с приложением, для чего приблизить ее к приложению – сделать ее индивидуальной, персональной для каждого приложения (рис. 2):
При первом подходе придется выбирать компромисс между размером широковещательного домена (он же – failure domain) и областью миграции приложений. То есть, чем больше широковещательный домен, чем больше риск широковещательного шторма, тем в больших пределах может работать виртуальная машина. И наоборот, стараясь уменьшить failure domain, мы тем самым сокращаем список серверов, на которых может быть запущено приложение.
Особенно явно это противоречие проявляется при наличии нескольких площадок ЦОД, когда при выходе из строя одной площадки необходимо перезапустить приложения на другой. С учетом того, что на другой площадке адресация на сетевых устройствах не такая, как на исходной, процедура Disaster Recovery может проводиться по-разному. К примеру, можно изменять IP-адрес для каждой виртуальной машины. Или, можно перенести сетевые настройки между устройствами. В любом случае, процесс получается достаточно сложным и, как правило, требует вмешательства администратора. Если же вместо него применить стандартный механизм High Availability – то перезапуск произойдет в автоматическом режиме. Остался лишь маленький нюанс – получается, что для применения High Availability при перезапуске на другой площадке нужно расширить область миграции машин на две площадке. А, как показано в предыдущем абзаце, при этом расширяется и failure domain, чего не хотелось бы – ведь вторая площадка как раз и строилась, чтобы “прикрыть” первую на случай проблем, а не для того, чтобы вместе погибнуть в широковещательном шторме.
Получается, что необходимо искать некий компромисс между областью миграции машин и размерами failure domain. Но можно посмотреть и в другом направлении.
Чем потенциально интересен подход, предложенный на рисунке 2?
- Широковещательный домен минимально возможного размера – он даже не выходит за пределы сервера;
- Перенос процесса маршрутизации ближе к приложению позволяет использовать динамические протоколы для парирования отказа порта или коммутатора – т.е, в этих сценариях задача отказоустойчивости решается “из коробки”;
- Во всем ЦОД формируется единая Control Plane в виде того самого динамического протокола маршрутизации;
- Использование протокола маршрутизации позволит приложению работать на любом сервере, на любой из площадок ЦОД.
В общем, вариант привлекательный, осталось только его реализовать.
В одной из предыдущих статей нашего блога я уже описывал механизм, позволяющий детектировать расположение виртуальной машины на коммутаторах ToR и анонсировать маршрут по маске /32 в фабрику ЦОД. Идея, предлагаемая в этой статье, как раз и состоит в том, чтобы взять тот самый механизм, и перенести его еще ближе к приложениям, с коммутаторов ToR на сервер гипервизора – к примеру, как это показано на рис. 3.
Первый, универсальный для любого гипервизора способ – создать на каждом сервере сервисную виртуальную машину, на которой реализовать описанный механизм.
Второй способ подойдет для гипервизоров KVM, где можно установить дополнительный пакет и запустить процесс маршрутизации в виде отдельного демона операционной системы. То есть, в этом случае сам гипервизор будет играть роль маршрутизатора для запущенных на нем виртуальных машин.
Во-первых, как уже отмечалось ранее, виртуальная машина с приложением может быть запущена на любом сервере, на любой площадке ЦОД.
Во-вторых, при таком подходе нет необходимости в подборе определенных коммутаторов ToR с поддержкой механизма детектирования IP-адреса виртуальных машин. Теперь этот механизм перемещается внутрь гипервизора. К примеру, в лаборатории нашей компании работает стенд с гипервизорами KVM и коммутаторами, от которых требуется лишь поддержка BGP.
В-третьих, использование маршрутизатора на сервере позволяет задействовать ECMP, что приводит к следующим приятным последствиям:
— парирование отказа порта “из коробки”;
— парирование отказа коммутатора “из коробки”;
— балансировка трафика по интерфейсам сервера (вероятно, пропускная способность интерфейсов и не является узким местом, но если это “бесплатно” – почему бы и не воспользоваться?).
Подводя итоги, хочется сказать следующее. В индустрии ЦОД существует множество подходов к решению задачи миграции виртуальных машин (например, OTV, VXLAN, EVPN). Зачастую они характеризуются наличием дополнительных Control Plane и Data Plane. В подходе “Server Router” Data Plane не изменяется, а в качестве Control Plane используется протокол маршрутизации, и без того уже работающий в фабрике ЦОД. В итоге, предлагаемый в статье подход, на мой взгляд, выгодно отличается своей простотой.
Комментариев пока нет
Добавить комментарий