Резервный VPN доступ к виртуальным машинам

OpenStack является одной из самых популярных платформ для создания частных и публичных облачных сервисов с открытым исходным кодом. Сегодня мы подробнее остановимся на OpenStack Elastic Compute, который также известен как Nova.

Есть то, что выделяет OpenStack Nova среди своих конкурентов – это его архитектура, которая была разработана для поддержки массивных объемов развертывания. Изначально Nova была разработана NASA для замены Eucalyptus из-за его ограниченных возможностей поддерживать масштабные развертывания.

Масштабируемость Nova, в конечном счете, делает его популярным для работы не только с частными, но и с публичными веб-облаками. OpenStack набирает обороты в частном бизнесе, а также среди хостинг-провайдеров. Такие компании, как Internap, DreamHost, Rackspace, а с недавнего времени и HP, располагают свои публичные облака на OpenStack.
Хотя архитектура Nova идеально подходит для публичных облаков, сам проект еще довольно новый и требует доработок, чтобы он обладал высокой отказоустойчивостью для поддержки сотен узлов. В данной дискуссии мы хотели бы сосредоточиться на одной довольно большой и чрезвычайно важной доработке, которая должна стать решением практически для всех, кто хочет задействовать Nova.

Для поставщиков услуг (для частных облаков в некоторых случаях) облака должны поддерживать различные сетевые топологии. В дополнение к возможности предоставления виртуальных машин с публичными IP адресами, нужно обеспечить возможность раскрутить частные сети, размещенные в облаке (также известные как виртуальные частные облака). Такие частные сети могут быть доступны через VPN. Хотя OpenStack поддерживает такую возможность, некоторые ручные доработки необходимы для поддержки частных сетей и VPN доступа в конфигурации высокой отказоустойчивости.

Вне зависимости от топологии сети, используемой в развертывании (Nova в настоящее время поддерживает три различных топологии), чтобы получить доступ к виртуальным машинам в размещенной на сервере частной сети, сервер VPN должен быть предоставлен в том же VLAN с остальными машинами в частной сети. Nova использует реализацию OpenVPN VPN сервера. VPN-серверы, развертываемые Nova, называются Cloudpipe. Cloudpipe в целом является сервером VPN, который позволяет клиенту получать доступ к виртуальным машинам внутри частной сети клиента. Например, если Cloudpipe выходит из строя, клиент полностью теряет доступ к виртуальному частному облаку и всем приложениям, которые на нем работают. Текущие версии OpenStack не поддерживают отказоустойчивых конфигураций для Cloudpipe, следовательно, делают его более уязвимым.

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

Для мониторинга VPN-подключения был использован метод ”periodic tasks” находящийся внутри сервиса “nova network”. Мы настроили этот метод для работы с периодическим интервалом, который мы установили в файле конфигурации. Для проверки VPN-подключения был использован метод vpn_ping из utils.py. Vpn_ping посылает пакеты VPN на сервер и возвращает «истинное» или «ложное» значение в зависимости от статуса попытки подключения. Было установлено, что проверки должны проводиться не чаще, чем каждые 10 секунд. Чтобы не закрыть версии, которые зависали на секунду во время проверки, проводились три попытки с 10-секундной задержкой между ними. Если VPN не был доступен во всех трех попытках, Cloudpipe закрывался и загружался новый. Время загрузки Cloudpipe и получения рабочего VPN занимает в среднем от 2 ? до 3 минут.

Чтобы минимизировать время задержки в доступе, связанное с неполадкой Cloudpipe, мы также внедрили резервные Cloudpipe, которые работают на отдельном физическом сервере. При настройке OpenVPN на стороне клиента можно определить несколько конечных точек соединения (такие, как подключения портов). В то же время, с некоторыми доработками сетей Nova можно развернуть несколько Cloudpipe. В этом случае, когда один из Cloudpipe выходит из строя, клиент автоматически переключается на оставшийся запущенный Cloudpipe. При установке, клиент испытывает минимальное время ожидания (около 10 секунд).

Если у вас есть вопросы по поводу данного подхода, пожалуйста, делитесь ими с Михаилом на Twitter @mihgen.

Об авторе: Михаил Щербаков, Главный разработчик по вопросам облачных сервисов, Mirantis.

Подписка на RSS канал
« »

Комментарии

Оставить комментарий
или