что такое облачная инфраструктура
Что такое облако: простыми словами об облачных сервисах для бизнеса
Что такое облако?
Концепция «облака» была сформирована еще в 1960-х, когда появились первые высокопроизводительные мейнфреймы. Уже тогда к ним могли подключаться сразу несколько пользователей и делить вычислительные ресурсы между собой.
За несколько десятилетий эта идея эволюционировала. Сегодня облако — это комплекс технологий для решения широкого спектра задач: от разработки и запуска корпоративных и пользовательских приложений, до хранения и обработки огромных массивов данных, обучения программных моделей искусственного интеллекта.
Облачные сервисы делятся на три больших сегмента:
Помимо 3 ключевых сегментов — IaaS, PaaS, SaaS, есть и специализированные облачные сервисы, включающие в себя элементы разных сегментов. Это AIaaS (Artificial Intelligence as a Service, искусственный интеллект как услуга), DSaaS (Data Science as a Service, обработка данных как услуга) и другие облачные услуги.
Кто предоставляет облачные услуги?
Облачные провайдеры — компании, аккумулирующие у себя экспертизу в области облачных технологий. Они предлагают специализированные сервисы, а также сегментируют услуги таким образом, чтобы принести максимальную пользу своим клиентам: предпринимателям, IT-разработчикам, научным и общественным организациям.
Облачный рынок — самый перспективный сегмент в сфере IT. Даже во время кризиса он не потерял высоких темпов развития. Так, например, три крупнейших мировых облачных провайдера Amazon Web Services (AWS), Microsoft Azure и Google Cloud во втором квартале 2020 года показали значительный рост выручки по сравнению с докризисным периодом. Это свидетельствует о высоком спросе на облачные услуги в мировом масштабе. Не отстали от лидер ов рынка и российские компании. Облачный провайдер группы Сбербанка — SberCloud — даже в неблагоприятных рыночных условиях сумел вывести на рынок 40 новых, востребованных бизнесом сервисов, в составе своей облачной платформы SberCloud.Advanced.
Кто пользуется облачными сервисами?
Самые разные компании, от индивидуальных предпринимателей и стартапов до корпораций и госструктур. Это e-commerce площадки, стриминговые сервисы, малый бизнес, госорганизации. Одни делают ставку на резервное хранение и архивацию данных, тестируют новые продукты в облаке до запуска на массовую аудиторию. Другие используют весь спектр возможностей облачных платформ и переносят на их мощности все свои бизнес-процессы.
Например, американская корпорация General Electric использует облако, чтобы хранить и обрабатывать огромные объемы данных, связанных с работой промышленного оборудования — нефтяных и газовых установок. В то же время корпорация перенесла на облачную платформу более 350 бизнес-приложений, вполовину сократив затраты на их эксплуатацию.
Банки также используют облачные платформы. Они разворачивают в них бизнес- и пользовательские приложения, системы искусственного интеллекта, помогающие строить маркетинговые стратегии, анализировать предпочтения клиентов и предлагать клиентам новые услуги. Так Сбербанк на базе облачной платформы SberCloud формирует собственную экосистему и предлагает новые продукты и услуги.
Но ведь можно делать все то же самое самостоятельно. Чем облачные платформы лучше?
Облако позволяет мгновенно подключить нужные услуги и отключить те, необходимость в которых уже отсутствует. Все это может тарифицироваться по модели pay as you go («оплата по мере потребления»). Таким образом, компания-клиент тратит ресурсы только на используемые мощности и может выделить больше времени на развитие собственного бизнеса: быстро тестировать маркетинговые гипотезы, сокращать time-to-market продуктов и вовремя масштабировать свои сервисы.
Облачный провайдер берет на себя капитальные затраты на закупку оборудования и расходы на его обслуживание (при использовании IaaS). Самые зрелые и высокотехнологичные облачные платформы, такие как, например, SberCloud.Advanced, предоставляют клиентам еще и готовые программные среды с операционными системами, базами данных, инструментами разработки и тестирования (модель PaaS). Именно последний подход позволяет удешевить и ускорить процесс проектирования и вывода на рынок новых продуктов и услуг.
Хорошо, но насколько надежно и безопасно облако?
Облачные провайдеры размещают свои вычислительные мощности в дата-центрах. Это хорошо охраняемая территория, оснащенная самыми современными средствами защиты. Внутри действует пропускной режим, на дверях стоят магнитные замки и биометрические сканеры. Дата-центры в обязательном порядке оборудуют системами кондиционирования и пожаротушения, а также резервными электрогенераторами. Надежность работы всего оборудования, его отказоустойчивость сертифицируется международной организацией Uptime Institute. Дата-центры, используемые ведущими облачными провайдерами, имеют сертификат Tier 3. Устойчивость к отказам такого центра составляет 99.982%, что означает, что сервера или накопители, стоящие в таком дата-центре, могут быть недоступны не более семи с половиной минут в течение месяцев. Собственные дата-центры такого класса могут позволить только крупнейшие компании мира.
Высококвалифицированные специалисты облачного провайдера области информационной безопасности регулярно проверяют его информационные системы на наличие уязвимостей и используют для этого самые совершенные решения. Большинство компаний, которые не пользуются облаком, не располагают специалистами такого высокого уровня, и не имеют столь эффективных и дорогостоящих программно-аппаратных комплексов для защиты своей ИТ-инфраструктуры и данных клиентов.
Как понять, нужно ли это моему бизнесу?
Облачные технологии универсальны. Их используют в бизнесе, науке, образовании и в госсекторе. Они нужны практически любой компании и организации, работающей с данными и имеющей свою ИТ-инфраструктуру, так как делают бизнес более гибким, быстрым и эффективным, а значит более конкурентоспособным.
Какие именно облачные сервисы нужны, зависит от характера решаемых задач. Если это торговый бизнес, а клиенты начали больше покупать в онлайн, то возможно расширение e-commerce-составляющей с помощью ресурсов облачной платформы. Если же компания имеет широкую региональную сеть, то оснащение каждого филиала собственной ИТ-инфраструктурой долго и дорого, намного проще воспользоваться виртуальным ЦОДом облачного провайдера.
Что такое облачная IT-инфраструктура и почему можно обойтись без своего дата-центра
Что такое обычная инфраструктура для бизнеса? Это стойки с серверами, системные администраторы и куча насущных проблем типа сгоревшей памяти, безопасности и постоянных закупок каких-то штуковин, названия которых сложно запомнить. Всё это — причины для головной боли и финансовых расходов.
Чтобы не терять деньги и сберечь нервы, многие компании переходят на облачную виртуальную IT-инфраструктуру. Разбираемся, как работать с серверами, которые нельзя потрогать руками.
Что такое облачная инфраструктура предприятия
В основе облачных технологий для инфраструктуры лежит простая идея — вместо продажи клиентам физических серверных железок в дата-центрах операторы продают определенный процент вычислительных ресурсов.
Как это работает?
Когда компания использует обычные серверы, часть мощностей всегда простаивает — например, вы готовитесь к худшим сценариям и максимальным нагрузкам, значит, ставите много железа. Так как у вас обычно меньше клиентов, приходится содержать и обслуживать серверы, которые большую часть времени не используются. Если вы, наоборот, поставили меньше оборудования, его придется докупать под рост нагрузки. Это новые расходы, кроме того, подключение нового железа в работу — процесс трудоемкий: нужно физически воткнуть сервер в стойку, всё настроить и за всем следить.
Поэтому придумали внутри одного железного сервера выделять несколько программных, виртуальных серверов. Железка одна, а на самом деле в ней несколько отдельных пространств, в которых находятся разные программы, несвязанные между собой. Можно на одном железном сервере держать данные сразу нескольких клиентов — тогда за аппаратным хозяйством намного проще следить.
Такое распределение ресурсов физических серверов между виртуальными серверными пространствами пришлось по вкусу как провайдерам, так и их клиентам. Тут и использование ресурсов эффективнее, и время запуска клиентских серверов меньше, и расходы на поддержание всего этого в рабочем состоянии ниже.
IaaS: облачная инфраструктура для компании как сервис
У виртуальных серверов есть еще одна особенность, которая драматическим образом изменила то, как мы работаем с инфраструктурой сегодня.
Дело в том, что виртуальные машины, то есть те самые виртуальные серверы, создаются из готовых образов — «слепков» состояний операционной системы и всех приложений внутри нее. Эти образы копируются внутри самого облака, запускаются — и, вуаля, у вас готовый и настроенный сервер!
То есть образ для создания виртуальных машин может содержать в себе не только ОС, но и различные облачные сервисы — например, файловые хранилища. После развертывания такого слепка вы получаете сервер не только с ОС, но и с готовыми к использованию элементами инфраструктуры.
Это значит, вам не нужно тратить время и деньги на установку и конфигурирование ваших сервисов с нуля!
Заботы обо всех таких облачных сервисах ложатся на плечи администраторов облака — именно они обновляют виртуальные базы данных, делают резервные копии облачных файловых хранилищ и следят за безопасностью.
Виды облачных инфраструктур
Развитие рынка IaaS привело к появлению нескольких подвидов облачных инфраструктур:
Введение в сетевую часть облачной инфраструктуры
Облачные вычисления все глубже и глубже проникают в нашу жизнь и уже наверно нет ни одного человека, который хотя бы раз не пользовался какими либо облачными сервисами. Однако что же такое облако и как оно работает в большинстве своем мало кто знает даже на уровне идеи. 5G становится уже реальностью и телеком инфраструктура начинает переходить от столбовых решений к облачным решениями, как когда переходила от полностью железных решений к виртуализированным «столбам».
Сегодня поговорим о внутреннем мире облачной инфраструктуре, в частности разберем основы сетевой части.
Что такое облако? Та же виртуализация — вид в профиль?
Более чем логичный вопрос. Нет — это не виртуализация, хотя без нее не обошлось. Рассмотрим два определения:
Облачные вычисления (далее Облако) — это модель предоставления удобного для пользователя доступа к распределенным вычислительным ресурсам, которые должны быть развернуты и запущены по запросу с минимально возможной задержкой и минимальными затратами со стороны сервис провайдера (перевод определения от NIST).
Виртуализация — это возможность разделить одну физическую сущность (например сервер) на несколько виртуальных, тем самым повысив утилизацию ресурсов (например у вас было 3 сервера, загруженных на 25-30 процентов, после виртуализации вы получаете 1 сервер, загруженный на 80-90 процентов). Естественно виртуализация отъедает часть ресурсов — вам надо прокормить гипервизор, однако, как показала практика, игра стоит свеч. Идеальный пример виртуализации — это VMWare, которая отлично готовит виртуальные машины, или например KVM, который мне больше по душе, но это уже дело вкуса.
Мы используем виртуализацию сами этого не понимая, да даже железные маршрутизаторы уже используют виртуализацию — например в последних версия JunOS операционная система ставится как виртуальная машина поверх real-time linux дистрибутива (Wind River 9). Но виртуализация — это не облако, однако облако не может существовать без виртуализации.
Виртуализация — это один из кирпичиков, на котором облако строится.
Сделать облако, просто собрав несколько гипервизоров в один L2 домен, добавив пару yaml плейбуков для автоматического прописывания вланов через какой нибудь ansible и нахлобучить на это все что то типа системы оркестрации для автоматического создания виртуальных машин — не получится. Точнее получится, но полученный Франкенштейн — не то облако которое нам нужно, хотя кому как, может быть для кого то это предел мечтаний. К тому же если взять тот же Openstack — по сути еще тот еще Франкенштейн, но да ладно не будем пока об этом.
Но я понимаю что из представленного выше определения не совсем понятно, что же на самом деле можно назвать облаком.
Поэтому в документе от NIST (National Institute of Standards and Technology) приведены 5 основных характеристик, которыми должна обладать облачная инфраструктура:
Предоставление сервиса по запросу. Пользователю должен быть предоставлен свободный доступ к выделенным ему компьютерным ресурсам (таким как сети, виртуальные диски, память, ядра процессоров и т д) причем эти ресурсы должны предоставляться автоматически — то есть без вмешательства со стороны сервис провайдера.
Широкая доступность сервиса. Доступ к ресурсам должен обеспечиваться стандартными механизмами для возможности использования как стандартных ПК, так и тонких клиентов и мобильных устройств.
Объединение ресурсов в пулы. Пулы ресурсов должны обеспечивать одновременное предоставление ресурсов нескольким клиентам, обеспечивая изоляцию клиентов и отсутствие взаимного влияния между ними и конкуренции за ресурсы. В пулы включаются и сети, что говорит о возможности использования пересекающейся адресации. Пулы должны поддерживать масштабирование по запросу. Использование пулов позволяет обеспечить необходимый уровень отказоустойчивости ресурсов и абстрагирование физических и виртуальных ресурсов — получателю сервиса просто предоставляется запрошенный им набор ресурсов (где эти ресурсы расположены физически, на скольких серверах и коммутаторах — клиенту не важно). Однако надо учитывать тот факт, что провайдер должен обеспечить прозрачное резервирование данных ресурсов.
Быстрая адаптация к различным условиям. Сервисы должны быть гибкими — быстрое предоставление ресурсов, их перераспределение, добавление или сокращение ресурсов по запросу клиента, причем со стороны клиента должно складываться ощущение, что ресурсы облака бесконечны. Для простоты понимания, например, вы же не видите предупреждение о том, что у вас в Apple iCloud пропала часть дискового пространства из за того, что на сервере сломался жесткий диск, а диски то ломаются. К тому же с вашей стороны возможности этого сервиса практически безграничны — нужно вам 2 Тб — не проблема, заплатили и получили. Аналогично можно привести пример с Google.Drive или Yandex.Disk.
Возможность измерения предоставляемого сервиса. Облачные системы должны автоматически контролировать и оптимизировать потребляемые ресурсы, при этом эти механизмы должны быть прозрачны как для пользователя так и для провайдера услуг. То есть вы всегда можете проверить, сколько ресурсов вы и ваши клиенты потребляют.
Стоит учесть тот факт, что данные требования в большинстве своем являются требованиями к публичному облаку, поэтому для приватного облака (то есть облака, запущенного для внутренних нужд компании) эти требования могут быть несколько скорректированы. Однако они все же должны выполняться, иначе мы не получим всех плюсов облачных вычислений.
Зачем нам облако?
Однако любая новая или уже существующая технология, любой новый протокол создается для чего-то (ну кроме RIP-ng естественно). Протокол ради протокола — никому не нужен (ну кроме RIP-ng естественно). Логично, что Облако создается чтобы предоставить какой то сервис пользователю/клиенту. Мы все знакомы хотя бы с парой облачных сервисов, например Dropbox или Google.Docs и я так полагаю большинство успешно ими пользуется — например данная статья написана с использованием облачного сервиса Google.Docs. Но известные нам облачные сервисы это только часть возможностей облака — точнее это только сервис типа SaaS. Предоставить облачный сервис мы можем тремя путями: в виде SaaS, PaaS или IaaS. Какой сервис нужен именно вам зависит от ваших желаний и возможностей.
Рассмотрим каждый по порядку:
Software as a Service (SaaS) — это модель предоставления полноценного сервиса клиенту, например почтовый сервис типа Yandex.Mail или Gmail. В такой модели предоставления сервиса вы, как клиент по факту не делаете ничего, кроме как пользуетесь сервисов — то есть вам не надо думать о настройке сервиса, его отказоустойчивости или резервировании. Главное не скомпрометировать свой пароль, все остальное за вас сделает провайдер данного сервиса. С точки зрения провайдера сервиса — он отвечает полностью за весь сервис — начиная с серверного оборудования и хостовых операционных систем, заканчивая настройками баз данных и программного обеспечения.
Platform as a Service (PaaS) — при использовании данной модели поставщик услуг предоставляет клиенту заготовку под сервис, например возьмем Web сервер. Поставщик услуг предоставил клиенту виртуальный сервер (по факту набор ресурсов, таких как RAM/CPU/Storage/Nets и т д), и даже установил на данный сервер ОС и необходимое ПО, однако настройку всего этого добра производит сам клиент и за работоспособность сервиса уже отвечает клиент. Поставщик услуг, как и в прошлом случае отвечает за работоспособность физического оборудования, гипервизоров, самой виртуальной машины, ее сетевую доступность и т д, но сам сервис уже вне его зоны ответственности.
Infrastructure as a Service (IaaS) — данный подход уже интереснее, по факту поставщик услуг предоставляет клиенту полную виртуализированную инфраструктуру — то есть какой то набор (пул) ресурсов, таких как CPU Cores, RAM, Networks и т д. Все остальное — дело клиента — что клиент хочет сделать с этими ресурсами в рамках выделенного ему пула (квоты) — поставщику не особо важно. Хочет клиент создать свой собственный vEPC или вообще сделать мини оператора и предоставлять услуги связи — не вопрос — делай. В таком сценарии поставщик услуг отвечает за предоставление ресурсов, их отказоустойчивость и доступность, а также за ОС, позволяющую объединить данные ресурсы в пулы и предоставить их клиенту с возможность в любой момент провести увеличение или уменьшение ресурсов по запросу клиента. Все виртуальные машины и прочую мишуру клиент настраивает сам через портал самообслуживания и консоли, включая и прописание сетей (кроме внешних сетей).
Что такое OpenStack?
Во всех трех вариантах поставщику услуг нужна ОС, которая позволит создать облачную инфраструктуру. Фактически же при SaaS за весь стек данный стек технологий отвечает не одно подразделение — есть подразделение, которое отвечает за инфраструктуру — то есть предоставляет IaaS другому подразделению, это подразделение предоставляет клиенту SaaS. OpenStack является одной из облачных ОС, которая позволяет собрать кучу коммутаторов, серверов и систем хранения в единый ресурсный пул, разбивать этот общий пул на подпулы (тенанты) и предоставлять эти ресурсы клиентам через сеть.
OpenStack — это облачная операционная система которая позволяет контролировать большие пулы вычислительных ресурсов, хранилищ данных и сетевых ресурсов, провижининг и управление которыми производится через API с использованием стандартных механизмов аутентификации.
Другими словами, это комплекс проектов свободного программного обеспечения который предназначен для создания облачных сервисов, (как публичных, так и частных) — то есть набор инструментов, которые позволяют объединить серверное и коммутационное оборудование в единый пул ресурсов, управлять этими ресурсами, обеспечивая необходимый уровень отказоустойчивости.
На момент написания данного материала структура OpenStack выглядит так:
Картинка взята с openstack.org
Каждая из компонент, входящих в состав OpenStack которых выполняет какую либо определенную функцию. Такая распределенная архитектура позволяет включать в состав решения тот набор функциональных компонент, которые вам необходимы. Однако часть компонент являются корневыми компонентами и их удаление приведет к полной или частичной неработоспособности решения в целом. К таким компонентам принято относить:
Каждая из компонент OpenStack — это служба, отвечающая за определенную функцию и обеспечивающая API для управления этой функцией и взаимодействия этой службы с другими службами облачной операционной системы в целях создания единой инфраструктуры. Например, Nova обеспечивает управления вычислительными ресурсами и API для доступа к конфигурированию данных ресурсов, Glance – управления образами и API для управления ими, Cinder – блочное хранилище и API для управления им и тд. Все функции взаимоувязаны между собой очень тесным образом.
Однако если посудить, то все сервисы, запущенные в OpenStack представляет из себя в конечном счете какую либо виртуальную машину (или контейнер), подключенную к сети. Встает вопрос — а зачем нам столько элементов?
Давайте пробежимся по алгоритму создания виртуальной машины и подключения ее к сети и постоянному хранилищу в Openstack.
Стоит всегда держать в уме то, что облачной инфраструктуры без сети не бывает — каждый элемент так или иначе взаимодействует с другими элементами через сеть. Кроме того облако имеет абсолютно не статичную сеть. Естественно underlay сеть еще более-менее статична — не каждый день добавляются новые ноды и коммутаторы, однако overlay составляющая может и неизбежно будет постоянно менять — будут добавляться или удаляться новые сети, появляться новые виртуальные машины и умирать старые. И как вы помните из определения облака, данного в самом начале статьи — ресурсы должны выделять пользователю автоматически и с наименьшим (а лучше без) вмешательством со стороны сервис провайдера. То есть тот тип предоставления ресурсов сети, который есть сейчас в виде фронтенда в виде вашего личного кабинета доступного по http/https и дежурного сетевого инженера Василия в качестве бэкэнда — это не облако, даже при наличии у Василия восьми рук.
Neutron, являясь сетевой службой, обеспечивает API для управления сетевой частью облачной инфраструктуры. Служба обеспечивает работоспособность и управление сетевой части Openstack обеспечивая уровень абстракции, называемый Network-as-a-Service (NaaS). То есть сеть является такой же виртуальной измеримой единицей, как например виртуальные ядра CPU или объем RAM.
Но перед тем как переходить к архитектуре сетевой части OpenStack, рассмотрим как в OpenStack эта сеть работает и почему сеть является важной и неотъемлемой частью облака.
Итак, у нас есть две виртуальные машины клиента RED и две виртуальные машины клиента GREEN. Предположим, что эти машины расположенные на двух гипервизорах таким образом:
В данный момент это просто виртуализация 4-х серверов и не более того, так как пока что все что мы сделали — виртуализировали 4 сервера, раположив их на двух физических серверах. Причем пока что они даже не подключены к сети.
Чтобы получилось облако нам надо добавить несколько компонент. Во первых виртуализируем сетевую часть — нам надо эти 4 машины попарно соединить, причем клиенты хотят именно L2 соединение. Можно использовать кончено коммутатор и настроить в его сторону транк и разрулить все с помощью linux bridge ну или для более продвинутых юзеров openvswitch (к нему мы еще вернемся). Но сетей может быть очень много, да и постоянно пропихивать L2 через свич — не самая лучшая идея — так разные подразделения, сервис-деск, месяцы ожидания выполнения заявки, недели траблшутинга — в современно мире такой подход уже не работает. И чем раньше компания это понимает — тем легче ей двигаться вперед. Поэтому между гипервизорами выделим L3 сеть через которую будут общаться наши виртуальные машины, а уже поверх данной L3 сети построим виртуальные наложенные L2 (overlay) сети, где будет бегать трафик наших виртуальных машин. Как инкапсуляцию можно использовать GRE, Geneve или VxLAN. Пока остановимся на последнем, хотя это не особо важно.
Нам надо где то расположить VTEP (надеюсь все знакомы с терминологией VxLAN). Так как с серверов у нас выходит сразу L3 сеть, то нам ничего не мешает расположить VTEP на самих серверах, причем OVS (OpenvSwitch) это отлично умеет делать. В итоге мы получили вот такую конструкцию:
Так как трафик между VM должен быть разделен, то порты в сторону виртуальных машин будут иметь разные номера вланов. Номер тега играет роль только в пределах одного виртуального коммутатора, так как при инкапсулировании в VxLAN мы его можем беспроблемно снять, так как у нас будет VNI.
Теперь мы можем плодить наши машины и виртуальные сети для них без каких либо проблем.
Однако что если у клиента будет еще одна машина, но находится в другой сети? Нам нужен рутинг между сетями. Мы разберем простой вариант, когда используется централизованный рутинг — то есть трафик маршрутизируется через специальные выделенные network ноды (ну как правило они совмещены с control нодами, поэтому у нас будет тоже самое).
Вроде бы ничего сложного — делаем бридж интерфейс на контрольной ноде, гоним на нее трафик и оттуда маршрутизируем его куда нам надо. Но проблема в том, что клиент RED хочет использовать сеть 10.0.0.0/24, и клиент GREEN хочет использовать сеть 10.0.0.0/24. То есть у нас начинается пересечение адресных пространств. Кроме того клиенты не хотят, чтобы другие клиенты могли маршрутизироваться в их внутренние сети, что логично. Чтобы разделить сети и трафик данных клиентов мы для каждого из них выделим отдельный namespace. Namespace — это по факту копия сетевого стека Linux, то есть клиенты в namespace RED полностью изолированы от клиентов из namespace GREEN (ну либо маршрутизация между данными сетями клиентов разрешена через default namespace либо уже на вышестоящем транспортном оборудовании).
То есть получаем такую схему:
L2 тоннели сходятся со всех вычислительных нод на контрольную. ноду, где расположен L3 интерфейс для данных сетей, каждый в выделенном namespace для изоляции.
Однако мы забыли самое главное. Виртуальная машина должна предоставлять сервис клиенту, то есть она должна иметь хотя бы один внешний интерфейс, через который к ней можно достучаться. То есть нам нужно выйти во внешний мир. Тут есть разные варианты. Сделаем самый просто вариант. Добавим клиентам по одной сети, которые будут валидны в сети провайдера и не будут пересекаться с другими сетями. Сети могу быть тоже пересекающимися и смотреть в разные VRF на стороне провайдерской сети. Данные сети также будут жить в namespace каждого из клиентов. Однако выходить во внешний мир они все равно будут через один физический (или бонд, что логичнее) интерфейс. Чтобы разделить трафик клиентов трафик, выходящий наружу будет производиться тегирование VLAN тегом, выделенным клиенту.
В итоге мы получили вот такую схему:
Резонный вопрос — почему не сделать шлюзы на самих compute нодах? Большой проблемы в этом нет, более того, при включении распределенного маршрутизатора (DVR) это так и будет работать. В данном сценарии мы рассматриваем самый простой вариант с централизованным gateway, который в Openstack используется по умолчанию. Для высоконагруженных функций будут использовать как распределенный маршрутизатор, так и технологии ускорения типа SR-IOV и Passthrough, но как говорится, это уже совсем другая история. Для начала разберемся с базовой частью, а потом уйдем в детали.
Собственно наша схема уже работоспособна, однако есть пара нюансов:
То есть теперь наша топология уже немного усложнилась:
Пойдем далее. Нам надо добавить DHCP сервер. Самым идеальным местом для расположения DHCP серверов для каждого из клиентов будет уже упомянутая выше контрольная нода, где расположены namespaces:
Однако, есть небольшая проблема. Что если все перезагрузится и вся информация по аренде адресов на DHCP пропадет. Логично, что машинам будут выданы новые адреса, что не очень удобно. Выхода тут два — либо использовать доменные имена и добавить DNS сервер для каждого клиента, тогда нам адрес будет не особо важен (по аналогии с сетевой часть в k8s) — но тут есть проблема с внешними сетями, так как в них адреса также могу быть выданы по DHCP — нужна синхронизация с DNS серверов в облачной платформе и внешним DNS сервером, что на мой взгляд не очень гибко, однако вполне возможно. Либо второй вариант — использовать метаданные — то есть сохранять информацию о выданной машине адресе чтобы DHCP сервер знал, какой адрес машине выдать, если машина уже получала адрес. Второй вариант проще и гибче, так как позволяет сохранить доп информацию о машине. Теперь на схему добавим metadata агента:
Еще один вопрос который также стоит освятить — это возможность использовать одну внешнюю сеть всеми клиентами, так как внешние сети, если они должны быть валидны во всей сети, то будет сложность — надо постоянно выделять и контролировать выделение этих сетей. Возможность использования единой для всех клиентов внешней предконфигурированной сети будет очень кстати при создании публичного облака. Это упростит развертывание машин, так как нам не надо сверяться с базой данных адресов и выбирать уникальное адресное пространство для внешней сети каждого клиента. К тому же мы можем прописать внешнюю сеть заранее и в момент развертывания нам надо будет всего лишь ассоциировать внешние адреса с клиентскими машинами.
И тут на помощь нам приходит NAT — просто сделаем возможность клиентов выходить во внешний мир через default namespace с использованием NAT трансляции. Ну и тут небольшая проблема. Это хорошо, если клиентский сервер работает как клиент, а не как сервер — то есть инициирует а не принимает подключения. Но у нас то будет наоборот. В тамом случае нам надо сделать destination NAT, чтобы при получении трафика контрольная нода понимала, что данный трафик предназначен виртуальной машине А клиента А, а значит надо сделать NAT трансляцию из внешнего адреса, например 100.1.1.1 во внутренний адрес 10.0.0.1. В таком случае, хотя все клиенты будут использовать одну и ту же сеть, внутренняя изоляция полностью сохраняется. То есть нам надо на контрольной ноде сделать dNAT и sNAT. Использовать единую сеть с выделением плавающих адресов или внешние сети или же и то и то сразу — обуславливается тем, что вы хотите в облако затянуть. Мы не будем наносить на схему еще и плавающие адреса, а оставим уже добавленные ранее внешние сети — у каждого клиента есть своя внешняя сеть (на схеме обозначены как влан 100 и 200 на внешнем интерфейсе).
В итоге мы получили интересное и в то же время продуманное решение, обладающее определенной гибкость но пока что не обладающее механизмами отказоустойчивости.
Во первых у нас всего одна контрольная нода — выход ее из строя приведет к краху все системы. Для устранения данной проблемы необходимо сделать как минимум кворум из 3-х нод. Добавим это на схему:
Естественно все ноды синхронизируются и при выходе активной ноды ее обязанности на себя возьмет другая нода.
Следующая проблема — диски виртуальных машин. В данный момент они хранятся на самих гипервизорах и в случае проблем с гипервизором мы теряем все данные — и наличие рейда тут никак не поможет если мы потеряем не диск, а весь сервер целиком. Для этого нам нужно сделать службу, которая будет выступать фронтэндом для какого либо хранилища. Какое это будет хранилище нам особо не важно, но оно должно защитить наши данные от выхода из строя и диска и ноды, а возможно и целого шкафа. Вариантов тут несколько — есть конечно SAN сети с Fiber Channel, но скажем честно — FC это уже пережиток прошлого — аналог E1 в транспорте — да согласен, он еще используется, но только там, где без него ну никак нельзя. Поэтому добровольно разворачивать FC сеть в 2020 году я бы не стал, зная о наличии других более более интересных альтернатив. Хотя каждому свое и возможно найдутся те, кто считает, что FC со всеми его ограничениями — все что нам надо — не буду спорить, у каждого свое мнение. Однако наиболее интересным решением на мой взгляд является использование SDS, например Ceph.
Ceph позволяет построить выскодоступное решение для хранения данных с кучей возможных вариантов резервирования, начиная с кодов с проверкой четности (аналог рейд 5 или 6) заканчивая полной репликацией данных на разные диски с учетом расположения дисков в серверах, и серверов в шкафах и т д.
Для сборки Ceph нужно еще 3 ноды. Взаимодействие с хранилищем будет производиться также через сеть с использованием служб блочного, объектного и файлового хранилищ. Добавим в схему хранилище:
Примечание: можно делать и гиперконвергентные compute ноды — это концепция объединения нескольких функций на одной ноде — например storage+compute — не выделять специальные ноды под ceph storage. Мы получим такую же отказоустойчивую схему — так как SDS зарезервирует данные с указанным нами уровнем резервирования. Однако гиперконвергентные ноды — это всегда компромисс — так как storage нода не просто греет воздух как кажется на первый взгляд (так как на ней нет виртуальных машин) — она тратит ресурсы CPU на обслуживание SDS (по факту она в фоне делает все репликации, восстановления после сбоев нод, дисков и т д). То есть вы потеряете часть мощности compute ноды если совместите ее с storage.
Всем этим добром надо как то управлять — нужно что то, через что мы можем создать машину, сеть, виртуальный маршрутизатор и т д. Для этого на контрольную ноду добавим службу, которая будет выполнять роль dashboard — клиент сможет подключиться к данному порталу через http/https и сделать все, что ему надо (ну почти).
В итоге теперь мы имеем отказоустойчивую систему. Всеми элементами данной инфраструктуры надо как то управлять. Ранее было описано, что Openstack — это набор проектов, каждый их которых обеспечивает какую то определенную функцию. Как мы видим элементов, которые надо конфигурировать и контролировать более чем достаточно. Сегодня мы поговорим о сетевой части.
Архитектура Neutron
В OpenStack именно Neutron отвечает за подключение портов виртуальных машин к общей L2 сети, обеспечение маршрутизации трафика между VM, находящимися в разных L2 сетях а также маршрутизацию наружу, предоставление таких сервисов как NAT, Floating IP, DHCP и т д.
Высокоуровнево работу сетевой службы (базовая часть) можно описать так.
При запуске VM сетевая служба:
Следует сразу уточнить, что Neutron не является SDN контроллером.
Neutron состоит из нескольких взаимоувязанных между собой компонент:
Openstack-neutron-server — это демон, который через API работает с пользовательскими запросами. Данный демон не занимается прописыванием каких либо сетевых связностей, а дает необходимую для этого информацию своим плагинам, которые далее настраивают нужный элемент сети. Neutron-агенты на узлах OpenStack регистрируются на сервере Neutron.
Neutron-server это фактически приложение, написанное на python, состоящее из двух частей:
Плагины это подключаемые программные компоненты/модули которые вызываются при API запросах — то есть приписывание какого то сервиса происходит через них. Плагины делятся на два вида — сервисный и корневой. Как правило коневой плагин отвечает в основном за управление адресным пространством и L2 соединения между VM, а сервисные плагины уже обеспечивают дополнительный функционал например VPN или FW.
Список доступных на сегодня плагинов можно посмотреть например тут
Сервисных плагинов может быть несколько, однако коневой плагин может быть только один.
Openstack-neutron-ml2 — это стандартный корневой плагин Openstack. Данный плагин имеет модульную архитектуру (в отличии от своего предшественника) и через подключаемые к нему драйверы производит конфигурирование сетевого сервиса. Сам плагин рассмотрим чуть позже, так как фактически он дает ту гибкость, которой обладает OpenStack в сетевой части. Корневой плагин может быть заменен (например Contrail Networking делает такую замену).
RPC service (rabbitmq-server) — сервис, обеспечивающий управлением очередями и взаимодействие с другими службами OpenStack а также взаимодействие между агентами сетевой службы.
Network agents — агенты, которые расположены в каждой ноде, через которые и производится конфигурирование сетевых сервисов.
Агенты бывают нескольких видов.
L3 агент использует Linux namespaces для предоставления каждому тенанту набора собственных изолированных сетей и функционал виртуальных маршрутизаторов, которые маршрутизируют трафик и предоставляют услуги шлюза для Layer 2 сетей.
Database — база данных идентификаторов сетей, подсетей, портов, пулов и т д.
Фактически Neutron принимает API запросы от на создание каких либо сетевых сущностей аутентифицирует запрос, и через RPC (если обращается к какому то плагину или агенту) или REST API (если общается в SDN) передает агентам (через плагины) инструкции, необходимые для организации запрошенного сервиса.
Теперь обратимся к тестовой инсталляции (как она развернута и что в ее составе посмотрим позже в практической части) и посмотрим где какая компонента расположена:
Собственно вот и вся структура Neutron. Теперь стоит уделить некоторое время ML2 плагину.
Modular Layer 2
Как уже сказано выше плагин является стандартным корневым плагином OpenStack и имеет модульную архитектуру.
Предшественник ML2 плагина имел монолитную структуру что не позволяло например использовать микс из нескольких технологий в одной инсталляции. Например вы не могли использовать и openvswitch и linuxbridge одновременно — либо первое, либо второе. По этому причине был создан ML2 плагин с его архитектурой.
ML2 имеет две составляющие — два типа драйверов: Type drivers и Mechanism drivers.
Type drivers определяют технологии, которые будут использованы для организации сетевых связностей, например VxLAN, VLAN, GRE. При этом драйвер позволяет использовать разные технологии. Стандартной технологией является VxLAN инкапсуляция для overlay сетей и vlan внешних сетей.
К Type drivers являются следующие типы сетей:
Flat — сеть без тегирования
VLAN — тегированная сеть
Local — специальный тип сети для инсталляций типа all-in-one (такие инсталляции нужны либо для разработчиков либо для обучения)
GRE — overlay сеть, использующая GRE тоннели
VxLAN — overlay сеть, использующая VxLAN тоннели
Mechanism drivers определяют средства, которые обеспечивают организацию указанных в type driver технологий — например, openvswitch, sr-iov, opendaylight, OVN и т д.
В зависимости от реализации данного драйвера будет использованы либо агенты, которые управляются Neutron, либо использоваться соединения с внешним SDN контроллером, который берет на себя все вопросы по организации L2 сетей, маршрутизации и т д.
Пример если мы используем ML2 вместе с OVS, то на каждой вычислительной ноде устанавливается L2 агент, который управляет OVS. Однако если мы используем например OVN или OpenDayLight, то управление OVS переходит под их юрисдикцию — Neutron через корневой плагин дает команды контроллеру, а он уже делает то, что ему сказали.
Освежим в памяти Open vSwitch
На данный момент одним из ключевых компонент OpenStack является Open vSwitch.
При установке OpenStack без какого либо дополнительного вендорского SDN типа Juniper Contrail или Nokia Nuage, OVS является основной сетевой компонентой облачной сети и в совокупности с iptables, conntrack, namespaces позволяет организовывать полноценный оверлейные сети с мультитенанси. Естественно данная компонента может быть заменена, например при использовании сторонних проприетарных (вендорских) SDN решений.
OVS это программный коммутатор с открытым исходным кодом, который предназначен для использования в виртуализированных средах как виртуальный форвардер трафика.
На данный момент OVS имеет очень приличный функционал, в который входят такие технологии, как QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK и т д.
Примечание: изначально OVS не задумывался как программный коммутатор для высоконагруженных телеком функций и был больше рассчитан под менее требовательные к пропускной способности ИТ функции типа WEB сервера или почтового сервера. Однако OVS дорабатывается и текущие реализации OVS сильно улучшили его производительность и возможности что позволяет его использовать операторам связи с высоконагруженными функциями, например есть реализация OVS с поддержкой DPDK ускорения.
Существует три важных компоненты OVS, о которых необходимо знать:
В настоящий момент Openstack широко используется телеком операторами для миграции в него сетевых функций, таких как EPC, SBC, HLR и т д. Часть функций может без проблем жить с OVS в том виде в котором он есть, но например EPC обрабатывает трафик абонентов — то есть пропускает через себя огромное количество трафика (сейчас объемы трафика достигают нескольких сотен гигабит в секунду). Естественно гнать такой трафик через kernel space (так как по умолчанию форвардер расположен именно там) — не самая лучшая идея. Поэтому зачастую OVS разворачивают целиком в user space с использованием технологии ускорения DPDK для проброса трафика из NIC в user space минуя kernel.
Примечание: для облака, развернутого для телеком функций возможен вариант вывода трафика с compute ноды минуя OVS напрямую в коммутационное оборудование. Для этой цели используются механизмы SR-IOV и Passthrough.
Как это работает на реальном макете?
Ну и теперь перейдем к практической части и посмотрим как это все работает на практике.
Для начала развернем простенькую Openstack инсталляцию. Так как у меня под рукой под эксперименты нет набора серверов, то собирать макет будем на одном физическом сервере из виртуальных машин. Да, естественно под коммерческие цели такое решение не подходит, но чтобы посмотреть на примере как работает сеть в Openstack такой инсталляции хватит за глаза. Причем такая инсталляция для целей обучения даже интереснее — так как можно отловить трафик и т д.
Так как нам надо увидеть только базовую часть, то мы можем не использовать несколько сетей а все поднять с использованием всего двух сетей, причем вторая сеть в данном макете будет использоваться исключительно для доступа к undercloud и dns серверу. Внешние сети мы пока затрагивать не будем — это тема для отдельной большой статьи.
Итак, начнем по порядку. Сначала немного теории. Ставить мы будем Openstack с помощью TripleO (Openstack on Openstack). Суть TripleO заключается в том, что мы устанавливаем Openstack all-in-one (то есть на одну ноду), называемый undercloud, и далее используем возможности развернутого Openstack чтобы установить Openstack, предназначенный для эксплуатации, называемый overcloud. Undercloud будет использовать заложенную в него возможность управлять физическими серверами (bare metal) — проект Ironic — для провижининга гипервизоров, которые будут выполнять роли compute, control, storage нод. То есть мы не используем никаких сторонних средств для развертывания Openstack — мы разворачиваем Openstack силами Openstack. Далее по ходу установки станет намного понятнее, поэтому не будем останавливать на этом и пойдем вперед.
Примечание: В данной статье в целях упрощения я не стал использовать сетевую изоляцию для внутренних сетей Openstack, а все развернуто с использованием только одной сети. Однако наличие или отсутствие изоляции сетей не влияет на базовую функциональность решения — все будет работать точно также, как и при использовании изоляции, но трафик будет ходить в одной сети. Для коммерческой инсталляции естественно необходимо использовать изоляцию с использованием разных вланов и интерфейсов. Например трафик управления ceph хранилищем и трафик непосредственно данных (обращения машин к дискам и т д) при изоляции используют разные подсети (Storage management и Storage) и это позволяет сделать решение более отказоустойчивым, разделив данный трафик например по разным портам, либо использовать разные QoS профили для разного трафика, чтобы трафик данных не выдавил сигнальный трафик. В нашем же случае они будут идти в одной и той же сети и по факту это нас никак не лимитирует.
Примечание: Так как мы собираемся запускать виртуальные машины в виртуальной среде, базирующейся на виртуальных машинах, то для начала надо включить nested виртуализацию.
Проверить, включена ли nested виртуализация или нет можно так:
Нам надо собрать вот такую схему из виртуальных машин:
В моем случае для связности виртуальных машин, входящих в состав будущей инсталляции (а их у меня получилось 7 штук, но можно обойтись 4, если у вас не много ресурсов) я использовал OpenvSwitch. Я создал один ovs бридж и подключил к нему виртуальные машины черезе port-groups. Для этого создал xml файл следующего вида:
Тут объявлены три порт группы — две access и одна trunk (последняя нужна была для DNS сервера, но можно обойтись и без него, либо поднять его на хостовой машине — это как вам удобнее). Далее с помощью данного шаблона объявляем нашу есть через virsh net-define:
Теперь правим конфигурации портов гипервизора:
Примечание: в данном сценарии адрес на порту ovs-br1 не будет доступен, так как он не имеет влан тега. Чтобы это поправить надо дать команду sudo ovs-vsctl set port ovs-br1 tag=100. Однако после перезагрузки данный тег пропадет (если кто знает как заставить его остаться на месте — буду очень благодарен). Но это не столь важно, ибо данный адрес нам понадобится только на время инсталляции и будет не нужен, когда Openstack будет полностью развернут.
Далее создаем undercloud машину:
В ходе установки выставляете все нужные параметры, такие как имя машины, пароли, пользователи, ntp серверы и т д, можно сразу настроить и порты, но мне лично проще после установки зайти в машину через консоль и подправить нужные файлы. Если у вас уже есть готовый образ, то можете использовать его, либо поступить как я — скачать минимальный образ Centos 7 и использовать его для установки VM.
После успешной установки у вас должна появиться виртуальная машина на которую можно будет ставить undercloud
Сначала ставим необходимые в процессе установки инструменты:
Установка Undercloud
Создаем юзера stack, задаем пароль, добавляем в sudoer и даем ему возможность выполнять root команды через sudo без необходимости ввода пароля:
Теперь указываем в файле hosts полное имя undercloud:
Далее добавляем репозитории и ставим нужный нам софт:
Примечание: если вы не планируете ставить ceph, то команды, относящиеся к ceph вводить не надо. Я использовал релиз Queens, но вы можете использовать любой другой, который вам понравится.
Далее копируем файл конфигурации undercloud в домашнюю директорию юзера stack:
Теперь необходимо поправить данный файл, подстроив его под нашу инсталляцию.
В начало файла надо добавить данные строки:
Итак, пройдем по настройкам:
undercloud_hostname — полное имя undercloud сервера, должно совпадать с записью на DNS сервере
local_ip — локальный адрес undercloud в сторону провиженинг сети
network_gateway — этот же локальный адрес, который будет выступать в качестве gateway для доступа во внешний мир во время установки overcloud нод, тоже совпадает с local ip
undercloud_public_host — адрес внешнего API, назначается любой свободный адрес из провижининг сети
undercloud_admin_host адрес внутреннего API, назначается любой свободный адрес из провижининг сети
undercloud_nameservers — DNS сервер
generate_service_certificate — данная строка очень важна в текущем примере, так как если ее не установить в значение false вы получите ошибку при установке, проблема описана на багтрекер Red Hat
local_interface интерфейс в провижининг сети. Данный интерфейс будет переконфигурирован во время разворачивания undercloud, поэтому на undercloud необходимо иметь два интерфейса — один для доступа до него, второй для провижининга
local_mtu — MTU. Так как у нас тестовая лаборатория и MTU у меня 1500 на портах OVS свича, то необходимо выставить в значение 1450, что бы прошли инкапсулированные в VxLAN пакеты
network_cidr — провижининг сеть
masquerade — использование NAT для доступа во внешнюю сеть
masquerade_network — сеть, которая будет NAT-ся
dhcp_start — начальный адрес пула адресов, из которого будут назначаться адреса нодам во время деплоя overcloud
dhcp_end — конечный адрес пула адресов, из которого будут назначаться адреса нодам во время деплоя overcloud
inspection_iprange — пул адресов, необходимых для проведения интроспекции (не должен пересекаться с вышеобозначенным пулом)
scheduler_max_attempts — максимальное количество попыток установки overcloud (должно быть больше или равно количеству нод)
После того, как файл описан, можно дать команду на деплой undercloud:
Процедура занимает от 10 до 30 минут в зависимости от вашего железа. В конечном счете вы должны увидеть такой вывод:
Данный вывод говорит, что вы успешно установили undercloud и теперь можно проверить состояние undercloud и переходить к установке overcloud.
Если посмотреть вывод ifconfig, то вы увидите, что появился новый бридж интерфейс
Через данный интерфейс теперь будет производиться работа по развертыванию overcloud.
Из вывода ниже видно, что все сервисы у нас на одной ноде:
Ниже показана конфигурация сетевой части undercloud:
Установка overcloud
Переходим в папку с дисками наших виртуальных машин и создадим диски нужного объема:
Так как действуем мы от рута, то нам надо изменить владельца этих дисков чтобы не получить проблему с правами:
Примечание: если вы планируете ставить ceph в целях его изучения, то создавайте как минимум 3 ноды с минимум двумя дисками, а в темплейте укажите, что будут использоваться виртуальные диски vda, vdb и т д.
Отлично, теперь нам надо все эти машины определить:
Теперь нам надо все эти машины определить в virsh:
Теперь небольшой нюанс — tripleO использует IPMI для того, чтобы управлять серверами во время установки и интроспекции.
Интроспекция — это процесс инспекции аппратной части в целях получения ее параметров, необходимых для дальнешего провижининга нод. Интроспекция производится с помошью ironic — службы, предназначенной для работы с bare metal серверами.
Но вот тут проблема — если у железных серверов IPMI это отдельный порт (или shared порт, но это не принципиально), то у виртуальных машин таких портов нет. Тут нам на помощь приходит костыль под названием vbmc — утилита, которая позволяет эмулировать IPMI порт. На этот нюанс стоит обратить внимание особенно тем, кто захочет поднять такую лабораторию на ESXI гипервизоре — еслич естно, не знаю есть ли в нем аналог vbmc, поэтому стоит озадачиться этим вопросом перед тем как все разворачивать.
Если ваша ОС не может найти пакет, то добавьте репозиторий:
Теперь настраиваем утилиту. Тут все банально до безобразия. Сейчас логично, что в списке vbmc нет никаких серверов
Чтобы они появились их необходимо вручную объявить таким образом:
Думаю синтаксис команды понятен и без объяснений. Однако пока что все наши сессии в статусе DOWN. Чтобы они перешли в статус UP, необходимо их включить:
И последний штрих — необходимо поправить правила фаервола (ну либо отключить его совсем):
Теперь зайдем в undercloud и проверим что все работает. Адрес хостовой машины — 192.168.255.200, на undercloud мы добавили нужный пакет ipmitool во время подготовки к деплою:
Как видите, мы успешно запустили control ноду через vbmc. Теперь выключим ее и пойдем дальше:
Примечание: на контрольной ноде два интерфейса, но в данном случае это не важно, в данной инсталляции нам хватит и одного.
Теперь нам надо подготовить образы для ironic. Для этого скачиваем их через wget и устанавливаем:
Загружаем образы в undercloud:
Проверяем, что все образы загрузились
Еще один штрих — надо добавить dns сервер:
Теперь мы можем дать команду на интроспекцию:
Как видно из вывода все завершилось без ошибок. Проверим, что все ноды в состоянии available:
Если ноды будут в другом состоянии, как правило manageable, то что то пошло не так и надо смотреть лог, разбираться, почему так получилось. Имейте ввиду, что в данном сценарии мы используем виртуализацию и могут быть баги связанные с использованием виртуальных машин или vbmc.
Далее нам надо указать какая нода какую функцию будет выполнять — то есть указать профиль, с которым нода будет деплоиться:
Указываем профиль для каждой ноды:
Проверяем, что мы сделали все корректно:
Если все верно, даем команду на деплой overcloud:
В реальной инсталляции естественно будут использовать кастомизированные темплейты, в нашем случае это очень сильно усложнит процесс, так как надо будет объяснить каждую правку в шаблоне. Как было написано ранее — даже простой инсталляции нам будет достаточно, чтобы посмотреть, как это работает.
Теперь у вас есть около часа, а может и больше (зависит от возможностей железа) и вам остается надеяться, что по истечению этого времени вы увидите такую надпись:
Теперь у вас есть почти полноценная версия опенстак, на которой вы можете учиться, ставить опыты и т д.
Проверим что все нормально работает. В домашней директории юзера stack есть два файла — один stackrc (для управления undercloud) и второй overcloudrc (для управления overcloud). Эти файлы необходимо указать как source, так как в них содержится необходимая для аутентификации информация.
В моей инсталляции еще требуется один небольшой штрих — добавить маршрут на контроллере, так как машина, с которой я работаю находится в другой сети. Для этого зайдем на control-1 под учеткой heat-admin и пропишем маршрут
Ну и теперь вы можете зайти в горизонт. Вся информация — адреса, логин и пароль — лежат в файле /home/stack/overcloudrc. Итоговая схема выглядит следующим образом:
К слову говоря, в нашей инсталляции адреса машин выдавались через DHCP и как видите, они выдаются “как попало”. Вы можете в темплейте жестко задать, какой адрес какой машине нужно прикрепить во время деплоя, если вам это необходимо.
Как же ходит трафик между виртуальными машинами?
В данной статье мы рассмотрим три варианта прохождения трафик
Для проверки соберем такую схему:
У нас создано 4 виртуальные машины — 3 в одной L2 сети — net-1, и ещё 1 в сети net-2
Посмотрим, на каких гипервизорах расположены созданные машины:
]$
Машины vm-1 и vm-3 расположены на compute-0, машины vm-2 и vm-4 расположены на ноде compute-1.
Кроме того создан виртуальный маршрутизатор для возможности маршрутизации между указанными сетями:
У маршрутизатора два виртуальных порта, который выполняют роль шлюзов для сетей:
Но перед тем как смотреть, как ходит трафик, давайте рассмотрим, что мы имеем на данный момент на контрольной ноде (которая по совместительству и network нода) и на compute ноду. Начнем с compute ноды.
В данный момент на ноде три ovs бриджа — br-int, br-tun, br-ex. Между ними, как мы видим есть набор интерфейсов. Для простоты восприятия нанесем все данные интерфейсы на схему и посмотрим, что получится.
По адресам, на которые подняты VxLAN тоннели видно, что один тоннель поднят на compute-1 (192.168.255.26), второй тоннель смотрит на control-1 (192.168.255.15). Но наиболее интересно то, что br-ex нет физических интерфейсов, а если посмотреть, какие флоу настроены, то видно, что данный бридж в данный момент может только дропать трафик.
Как видно из вывода адрес прикручен напрямую на физический порт, а не на виртуальный бридж интерфейс.
Согласно первому правило, все что пришло из порта phy-br-ex необходимо отброс ить.
Собственно в данный бридж пока что больше неоткуда взяться трафику, кроме как из данного интерфейса (стык с br-int), и судя по дропам в бридж уже прилетал BUM трафик.
То есть с данной ноды трафик может уйти только через VxLAN тоннель и никак больше. Однако если включить DVR ситуация изменится, но с этим разберемся в другой раз. При использовании изоляции сетей например с помощью вланов, у вас будет не один L3 интерфейс в 0-вом влане, а несколько интерфейсов. Однако VxLAN трафик будет выходить с ноды точно так же, но инкапсулированный еще и в какой то выделенный влан.
С compute нодой разобрались, переходим к control ноде.
По факту можно сказать, что все тоже самое, однако ip адрес уже находится не на физическом интерфейсе а на виртуальном бридже. Это сделано из-за того, что данный порт является портом, через который будет выходить трафик во внешний мир.
Данный порт привязан к бриджу br-ex и так как на нем нет никаких влан тегов, то данный порт является транковым портом на котором разрешены все вланы, сейчас трафик выходит наружу без тега, о чем говорит vlan-id 0 в выводе выше.
Все остальное в данный момент аналогично compute ноде — те же бриджи, те же тоннели, идущие на две compute ноды.
Storage ноды мы рассматривать в данной статье не будем, но для понимания необходимо сказать, что сетевая часть данных нод банальна до безобразия. В нашем случае там всего один физический порт (eth0) с навешенным на него ip адресом и все. Там нет никаких VxLAN тоннелей, тоннельных бриджей и т д — там нет ovs вообще, так как нет от него смысла. При использовании изоляции сетей — на данной ноде будет два интерфейса (физических порта, бодны, или просто два влана — это не важно — зависит от того, что вы хотите) — один под управление, второй под трафик (запись на диск VM, чтение с диска и т д).
Разобрались что у нас есть на нодах в отсутствии каких либо сервисов. Теперь запустим 4 виртуальные машины и посмотрим, как изменится описанная выше схема — у нас должны появиться порты, виртуальные роутеры и т д.
Пока что наша сеть выглядит вот так:
У нас по две виртуальные машины на каждой компьют ноде. На примере compute-0 посмотрим, как все включено.
У машины всего один виртуальный интерфейс — tap95d96a75-a0:
Данный интерфейс смотрит в linux bridge:
Как видно из вывода в брижде всего два интерфейса — tap95d96a75-a0 и qvb95d96a75-a0.
Тут стоит немного остановиться на типах виртуальных сетевых устройства в OpenStack:
vtap — виртуальный интерфейс, присоединенный к инстансу (ВМ)
qbr — Linux bridge
qvb и qvo — vEth пара, подключенная к Linux bridge и Open vSwitch bridge
br-int, br-tun, br-vlan — Open vSwitch bridges
patch-, int-br-, phy-br- — Open vSwitch patch-интерфейсы, соединяющие bridges
qg, qr, ha, fg, sg — порты Open vSwitch, используемые виртуальными устройствами для подключения к OVS
Как вы понимаете, если у нас в брижде есть qvb95d96a75-a0 порт, который является vEth парой, то где то есть его ответная сторона, которая логично должна называться qvo95d96a75-a0. Смотрим, какие порты есть на OVS.
Как мы видим порт находится в br-int. Br-int выполняет роль коммутатора, терминирующего порты виртуальных машин. Помимо qvo95d96a75-a0 в выводе виден порт qvo5bd37136-47. Это порт во вторую виртуальную машину. В итоге наша схема теперь выглядит так:
Вопрос, который должен сразу заинтересовать внимательного читателя — на кой linux bridge между портом виртуальной машины и портом OVS? Дело в том, что для защиты машины используются security groups, которые есть не что иное как iptables. OVS не работает с iptables, поэтому был придуман такой “костыль”. Однако он отживает свое — ему на смену приходит conntrack в новых релизах.
То есть в конечном счете схема выглядит так:
Две машины на одном гипервизоре в одной L2 сети
Так как две данные VM находятся в одной и той же L2 сети и на одном и том же гипервизоре, то трафик между ними будет логично ходить локально через br-int, так как обе машины будут в одном и том же VLAN:
Две машины на разных гипервизорах в одной L2 сети
Теперь посмотрим, как пойдет трафик между двумя машинами в одной L2 сети, но расположенными на разных гипервизорах. Если быть честным, то особо сильно ничего не поменяется, просто трафик между гипервизорами пойдет через vxlan тоннель. Посмотрим на примере.
Адреса виртуальных машин, между которыми будем смотреть трафик:
Смотрим таблицу форвардинга в br-int на compute-0:
Трафик должен уйти в порт 2 — смотрим что это за порт:
Это patch-tun — то есть интерфейс в br-tun. Смотрим, что происходит с пакетом на br-tun:
Пакет упаковывается в VxLAN и отправляется в порт 2. Смотрим, куда ведет порт 2:
Это vxlan тоннель на compute-1:
Идем на compute-1 и смотрим, что дальше происходит с пакетом:
Мак есть в таблице форвардинга br-int на compute-1, и как видно из вывода выше виден он через порт 2, который является портов в сторону br-tun:
То есть полученный пакет улетит в порт 3, за которым уже находится виртуальная машина instance-00000003.
Вся прелесть развертывания Openstack для изучения на виртуальной инфраструктуре в том, что мы можем без проблем отловить трафик между гипервизорами и посмотреть, что происходит с ним. Это мы сейчас и сделаем, запустим tcpdump на vnet порту в сторону compute-0:
Первая строка показывает, что патек с адрес 10.0.1.85 идет на адрес 10.0.1.88 (ICMP трафик), причем он завернут в VxLAN пакет с vni 22 и пакет идет с хоста 192.168.255.19 (compute-0) на хост 192.168.255.26 (compute-1). Можем проверить, что VNI соответствует тому, который указан в ovs.
Вернемся к этой строке actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0х16 — это vni в 16-ричной системе счисления. Переведем это число в 10-ю систему:
То есть vni соответствует действительности.
Вторая строка показывает обратный трафик, ну его пояснять нет смысла там и так все ясно.
Две машины в разных сетях (маршрутизация между сетями)
Последний кейс на сегодня — это маршрутизация между сетями внутри одного проекта с использованием виртуального маршрутизатора. Мы рассматриваем случай без DVR (его рассмотрим в другой статье), поэтому маршрутизация происходит на network ноде. В нашем случае network нода не вынесена в отдельную сущность и расположена на control ноде.
Для начала посмотрим, что маршрутизация работает:
Теперь посмотрим, куда должен быть отправлен трафик с назначением (10.0.1.254) fa:16:3e:c4:64:70:
Смотрим куда ведет порт 2:
Все логично, трафик уходит в br-tun. Посмотрим, в какой vxlan тоннель он будет завернут:
Третий порт — это vxlan тоннель:
Который смотрит на control ноду:
Трафик долетел до control ноды, поэтому нам надо перейти на нее и посмотреть, как будет происходить маршрутизация.
Как вы помните, контрольная нода внутри выглядела точно также как и compute нода — те же три бриджа, только у br-ex был физический порт, через который нода могла слать трафик наружу. Создание инстансов изменило конфигурацию на compute нодах — добавились linux bridge, iptables и интерфейсы в ноды. Создание сетей и виртуального маршрутизатора также оставило свой отпечаток на конфигурации control ноды.
Мак виден из порта qr-0c52b15f-8f. Если вернуться обратно к списку виртуальных портов в Openstack, то этот тип порта используется для подключения к OVS различных виртуальных устройств. Если быть точнее qr — это порт в сторону виртуального маршрутизатора, который представлена в виде namespace.
Посмотрима, какие namespace есть на сервере:
Целых три экземпляра. Но судя по именам можно догадаться о назначении каждого их них. К инстансам с ID 0 и 1 мы вернемся позже, сейчас нам интересен namespace qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe:
То есть в данном случае все работает по законам стандартной маршрутизации. Так как трафик предназначен хосту 10.0.2.8, то он должен выйти через второй интерфейс qr-92fa49b5-54 и уйти через vxlan тоннель на compute ноду:
Как положено, трафик идет в br-tun, посмотрим, в какой тоннель трафик пойдет дальше:
Трафик уходит в тоннель до compute-1. Ну и на compute-1 все просто — из br-tun пакет попадает в br-int и оттуда в интерфейс виртуальной машины:
Проверим, что это действительно верный интерфейс:
Собственно мы прошли весь путь пакета. Думаю вы заметили, что трафик шел через разные vxlan тоннели и выходил с разными VNI. Давайте посмотрим, какие это VNI, после чего соберем дамп на порту control ноды и удостоверимся, что трафик ходит именно так, как описано выше.
Итак, тоннель до compute-0 имеет следующий actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Переведем 0x16 в десятичную систему счисления:
Тоннель до compute-1 имеет следующий VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Переведем 0x63 в десятичную систему счисления:
Ну и теперь посмотрим дамп:
Первый пакет — это vxlan пакет с хоста 192.168.255.19 (compute-0) на хост 192.168.255.15 (control-1) с vni 22, внутри которого упакован ICMP пакет с хоста 10.0.1.85 на хост 10.0.2.8. Как мы посчитали выше, vni соответствует тому, что мы видели в выводах.
Второй пакет — это vxlan пакет с хоста 192.168.255.15 (control-1) на хост 192.168.255.26 (compute-1) с vni 99, внутри которого упакован ICMP пакет с хоста 10.0.1.85 на хост 10.0.2.8. Как мы посчитали выше, vni соответствует тому, что мы видели в выводах.
Два следующих пакета — это обратный трафик с 10.0.2.8 не 10.0.1.85.
То есть в итоге у нас получилась такая схема control ноды:
Вроде все? Мы забыли про два namespace:
Как мы говорили про архитектура облачной платформы — было бы хорошо, чтобы машины получали адреса автоматом от DHCP сервера. Это и есть два DHCP сервера на наши две сети 10.0.1.0/24 и 10.0.2.0/24.
Проверим, что это так. В данном namespace только один адрес — 10.0.1.1 — адрес самого DHCP сервера, и он так же включен в br-int:
Посмотрим, если процессы содержащие в своем названии qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 на control ноде:
Есть такой процесс и исходя из информации, представленной в выводе выше мы можем например посмотреть, что у нас в аренде в настоящий момент:
В итоге мы получаем вот такой набор сервисов на control ноде:
Ну и имейте ввиду — это всего лишь — 4 машины, 2 внутренние сети и один виртуальный маршрутизатор… У нас тут нет сейчас внешних сетей, кучи разных проектов, каждый со своими сетями (пересекающимися), и у нас выключен распределенный маршрутизатор, да в конце концов в тестовом стенде была всего одна control нода (для отказоустойчивости должен быть кворум из трех нод). Логично, что в коммерции все “немного” сложнее, но на данном простом примере мы понимаем, как это должно работать — будет у вас 3 или 300 namespace конечно важно, но с точки зрения работы всей конструкции — особо ничего не поменяется… правда пока вы не воткнете какой нибудь вендорский SDN. Но это уже совсем другая история.
Надеюсь было интересно. Если есть замечания/дополнения ну или где то я откровенно соврал (я человек и мое мнение всегда будет субъективно) — пишите что надо поправить/добавить — все поправим/добавим.
В заключении хотелось бы сказать пару слов о сравнении Openstack (как ванильного, так и вендорских) с облачным решением от компании VMWare — слишком часть мне задавали этот вопрос последние пару лет и я уже чесно говоря от него устал, но все же. На мой взгляд эти два решения сравнить очень сложно, но можно однозначно сказать что минусы есть в обоих решениях и выбирая какое то одно решение надо взвесить все за и против.
Если OpenStack являетя community-driven решением, то VMWare вправе делать только то, что она хочет (читайте — то что ей выгодно) и это логично — ибо это коммерческая компания, которая привыкла зарабатывать деньги на своих клиентах. Но тут есть одно большое и жирное НО — вы можете слезть с OpenStack например от Nokia и малой кровью перейти на решение от например Juniper (Contrail Cloud), но слезть с VMWare у вас врядли получится. Для меня эти два решения выглядят так — Openstack (вендорский) это простая клетка, в которую вас сажают, но у вас есть ключ и вы можете выйти в любой момент. VMWare — это золотая клетка, ключ от клетки у хозяина и обойдется он вам очень дорого.
На мой взгляд самым большим недостатком VMWare является ее полная закрытость — компания вам не выдаст никакой информации о том, как у нее устроен например vSAN или что там в ядре гипервизора — ей это просто не выгодно — то есть вы никогда не станете экспертом в VMWare — без поддержки вендора вы обречены (очень часть встречаю экспертов по VMWare которых ставят в тупик банальные вопросы). Для меня VMWare — это покупка машины с закрытым на замок капотом — да, возможно у вас есть специалисты, которые могут поменять ремень ГРМ, но открыть капот сможет только тот, кто продал вам это решение. Лично я не люблю решения, в которые не могу влезть. Вы скажете, что вам возможно не придется лезть под капот. Да такое возможно, но я посмотрю на вас когда вам надо будет собрать в облаке большую функцию из 20-30 виртуальных машин, 40-50 сетей, половина из которых хочет выйти наружу, а вторая половина просит SR-IOV ускорения иначе вам надо будет еще пару десяток таких машин — иначе перфоманса не хватит.
Существуют и другие точки зрения, поэтому только вам решать что выбирать и самое главное — вам же за ваш выбор потом отвечать. Это всего лишь мое мнение — человека который видел и трогал руками как минимум 4 продукта — Nokia, Juniper, Red Hat и VMWare. То есть мне есть с чем сравнить.