CC BY
4
УДК 004.01
Фадеев И.В. студент магистратуры 2 курса отдел аспирантуры и магистратуры Поволжский Государственный Университет Телекоммуникаций и Информатики
Россия, г. Самара АРХИТЕКТУРА МЕНЕДЖЕРА ВИРТУАЛЬНОЙ ИНФРАСТРУКТУРЫ
Аннотация: Статья посвящена архитектуре менеджера виртуальной архитектуры, на примере решения с открытым исходным кодом OpenStack.
Ключевые слова:
Виртуализация, OpenStack, VIM, NFV, Cloud, VNF.
Fadeev I. V. magistracy student
2nd year magistracy and postgraduate studies department Povolzhskiy State University of Telecommunications & Informatics
Russia, Samara
ARCHITECTURE OF VIRTUAL INFRASTRUCTURE MANAGER
Annotation: The article focuses on the architecture of the virtual architecture manager, using the example of the open source OpenStack solution.
Keywords:
Virtualization, OpenStack, VIM, NFV, Cloud, VNF.
Базовая архитектура OpenStack
Openstack - это облачная операционная система, которая контролирует большие объёмы вычислительных мощностей, сетевых хранилищ и сетевых ресурсов в целом. Для любых действий в облаке предоставляется API с поддержкой аутентификации пользователей. Данная система представляет из себя стандарт - IaaS и позволяет использовать встроенные возможности по мониторингу ресурсов и управлению сервисами, что обеспечивает высокую доступность пользовательских сервисов.
Архитектура вычислительных узлов
При проектировании пулов вычислительных ресурсов необходимо учитывать количество процессоров, объём памяти и тд.
При разработке облака на базе ОС нужно определить какое физическое оборудование будет использоваться, будут ли вычислительные ресурсы предоставляться в одном пуле или в нескольких, или же они будут предоставляться в зонах доступности (Target AZ).
Для облаков, которые основаны на базе NFV могут существовать специфичные сетевые конфигурации, которые в обязательном порядке должны быть зарезервированы в системе.
Наращивание количества поддерживаемых окружений увеличивает и сетевой трафик, количество сообщений, добавляет нагрузку на контроллеры
и сервисы администрирования, использующиеся для поддержки всей системы. При рассмотрении контроллеров для аппаратного обеспечения, независимо от того, используется ли монолитная архитектура или архитектура без совместного использования ресурсов, необходимые ресурсы должны быть выделены для адекватного соответствия требованиям системы. Правильное планирование ресурсов поможет избежать узких мест и перегрузки сети при масштабировании облака.
Вычислительные узлы автоматически добавляются к ОС, что приводит к процессу горизонтального масштабирования при добавлении дополнительной вычислительной мощности к ОС. Для дальнейшей группировки вычислительных узлов и размещения узлов в соответствующих зонах доступности и хост-агрегатах требуется дополнительная работа. Необходимо спланировать емкость стойки и сетевые коммутаторы, поскольку масштабирование вычислительных хостов напрямую влияет на ресурсы инфраструктуры центра обработки данных, как и любое другое расширение инфраструктуры.
Хотя это не так часто встречается на крупных предприятиях, компоненты вычислительного хоста также можно обновить, чтобы учесть увеличение спроса, известное как вертикальное
масштабирование. Обновление процессоров с большим количеством ядер или увеличение общей памяти сервера может добавить дополнительную необходимую емкость в зависимости от того, являются ли запущенные приложения более ресурсоемкими или занимающими больший объём памяти. Рекомендуется непрерывное обновление вычислительных узлов для обеспечения избыточности и доступности. После обновления, когда вычислительные узлы возвращаются в кластер OpenStack, они будут повторно проверены, и новые ресурсы будут добавлены в OpenStack.
Некоторые процессоры включают функции, характерные для виртуализированных вычислительных хостов(УМ), такие как аппаратная виртуализация и технология, связанная с разбиением на страницы памяти (также известная как теневое копирование EPT). Эти функции могут оказать существенное влияние на производительность виртуальной машины.
Количество ядер и потоков процессора влияет на количество рабочих потоков, которые можно запустить на сервере. Проектные решения должны иметь непосредственное отношение к сервису, выполняемому на нем, а также обеспечивать сбалансированную инфраструктуру для всех сервисов.
Другим вариантом является оценка средних рабочих нагрузок и увеличение количества экземпляров, которые могут работать в вычислительной среде, путем корректировки коэффициента чрезмерной загрузки. Это соотношение настраивается для процессора и памяти. Коэффициент перегрузки центрального процессора по умолчанию составляет 16: 1, а коэффициент перегрузки памяти по умолчанию - 1,5: 1. Определение настройки коэффициентов перегрузки на этапе проектирования важно, так как это напрямую влияет на компоновку аппаратных средств вычислительных узлов.
Недостаточная емкость диска также может негативно повлиять на общую производительность, включая использование процессора и памяти. В
зависимости от серверной архитектуры включает в себя добавление дисковых полок в корпоративные системы хранения или установку дополнительных узлов хранилища. Может потребоваться обновление напрямую подключенного хранилища, установленного на хостах, и увеличение емкости общего хранилищ.
Следует учитывать возможность создания пулов или зон доступности для непредсказуемых рабочих нагрузок. В некоторых случаях спрос на определенные экземпляры или разновидности может не оправдывать индивидуальный дизайн оборудования.
Выбранное серверное оборудование должно иметь соответствующее количество сетевых подключений, а также правильный тип сетевых подключений, чтобы поддерживать предложенную архитектуру. Убедитесь, что в каждой стойке есть как минимум два разных сетевых подключения. Выбор форм-факторов или архитектур влияет на выбор серверного оборудования. Убедитесь, что выбранное серверное оборудование настроено для поддержки достаточного объема хранилища (или расширяемости хранилища) для соответствия требованиям выбранного решения для горизонтального хранения. Аналогично, сетевая архитектура влияет на выбор аппаратного обеспечения сервера и наоборот.
Хотя каждая корпоративная установка отличается, следующие сети с их предполагаемой пропускной способностью настоятельно рекомендуется для базовой производственной установки OpenStack.
Сеть установки или автономной работы. Обычно используется большинством средств распространения и предоставления ресурсов в качестве сети для развертывания базового программного обеспечения на вычислительных узлах OpenStack. Эта сеть должна быть подключена как минимум на 1 Гб, и маршрутизация обычно не требуется. Внутренняя сеть или сеть управления - используется в качестве внутренней сети связи между вычислительными и управляющими узлами OpenStack. Может также использоваться в качестве сети для связи iSCSI между вычислительными узлами и узлами хранения iSCSI. Опять же, это должен быть минимум сетевой адаптер 1 Гбит и сеть без маршрутизации. Этот интерфейс должен быть избыточным для высокой доступности (HA).
Сеть арендатора - частная сеть, которая обеспечивает связь между экземплярами каждого арендатора. При использовании плоских сетей и сетей провайдеров эта сеть не является обязательной. Эта сеть также должна быть изолирована от всех других сетей для обеспечения безопасности. Интерфейс 1 Гбит должен быть достаточным и избыточным для HA. Сеть хранения - частная сеть, которая может быть подключена к интерфейсу Ceph или другому общему хранилищу. Для целей HA это должна быть избыточная конфигурация с предлагаемыми сетевыми адаптерами 10 Гбит. Эта сеть изолирует хранилище для экземпляров от других сетей. Под нагрузкой этот трафик хранения может перегружать другие сети и вызывать
перебои в работе других служб OpenStack.
Внешняя или общедоступная сеть - эта сеть используется для внешней связи виртуальных машин с общедоступным сетевым пространством. Эти адреса обычно обрабатываются нейтронным агентом на узлах контроллера и могут также обрабатываться SDN, отличным от нейтрона.
Использованные источники: 1. https://docs.openstack.org/arch-design [Электронный ресурс]
