CloudStack 4. Архитектура, особенности и недостатки

Статья опубликована в журнале «Системный Администратор»

В статье приведен обзор CloudStack — платформы для создания облачной инфраструктуры. Обзор написан после двух месяцев использования CloudStack в тестовой среде и возможно будет полезен тем кто смотрит в этом направлении.

Путь от виртуализации к облаку

К сожалению, многие не видят принципиального отличия виртуализированного дата-центра от облака и зачастую не понимают, где заканчивается одно и начинается другое.
По сути, современные платформы виртуализации – это связка физических серверов, гипервизора, дополнительных компонентов и удобных средств развертки, настройки и управления программно-аппаратной виртуальной инфраструктурой. Под средствами управления и настройки я понимаю программное обеспечение типа VMware vSphere Client и VMware vCenter Server для централизованного управления ESX/ESXi, Citrix XenCenter для XenServer и т.д.
Нужно понимать, что существующие сегодня платформы виртуализации типа VMware vSphere, Citrix XenServer, RHEV (RedHat Enterprise Virtualization) и т. д. а так же различные системы хранения данных являются базовыми блоками для облачной инфраструктуры. А инструментарий администрирования входящий в состав перечисленных выше продуктов ориентирован более на инженеров и обслуживающий персонал нежели на пользователей или возможных клиентов. Кроме того, практически все поставщики продуктов серверной виртуализации ставят ставку на один тип гипервизора (чаще всего свой собственный) и не позволяют используя одни и те же средства управления, применить несколько гипервизоров в одной среде.
Платформы для построения облака, такие как CloudStack, OpenNebula, Eucaliptus и набирающей ход OpenStack предоставляют нам дополнительный уровень иерархии позволяя абстрагироваться не только от физического оборудования, но и от различных гипервизоров совместно используемых в единой инфраструктуре. Облачные платформы не отменяют и не заменяют полностью, привычные средства управления, а вводят новые понятия и предоставляют более гибкие возможности, делая работу с огромными инфраструктурами проще и логичнее не только для администраторов, но и для простых пользователей которые являются неотъемлемой частью концепции облаков.

Основные на мой взгляд критерии облачной платформы

• Портал самообслуживания
Облако является многопользовательской, динамичной средой. Пользователи или клиенты должны иметь возможность самостоятельно, без участия обслуживающего персонала создавать, запускать/останавливать, клонировать, удалять или изменять конфигурацию ВМ. Так же доступным должна быть загрузка собственных шаблонов ВМ или ISO-образов. При этом, у администратор остается право определять количественные лимиты пользователей. Например: не более 2-х ВМ/не более 2-х публичных IP/не более 6-и снапшотов/не более 3-х собственных шаблонов ВМ и т.п.

• Шаблоны ресурсов и эластичность производительности
Администратор облака должен иметь возможность определять шаблоны ресурсов(не путать с шаблонами ВМ включающих пред-настроенную ОС) для создаваемых пользователями/клиентами ВМ. Например: Smal VM = 1 Core/ 500 MHZ/ 512 MB/20 GB; Medium VM = 1 Core/ 1GHZ/ 1GB/50 GB и т.п.
В таком случае, при создании новой ВМ определение ее производительности сводится к простому выбору сбалансированного или особого шаблона ресурсов с понятным именем.
Кроме строгих шаблонов ресурсов, неотъемлемой частью современного облака можно считать динамическое масштабирование ресурсов по требованию. К сожалению, CloudStack не предоставляет подобной эластичности. Расширение ресурсов, путем выбора более производительного шаблона осуществляется только после остановке ВМ.

• Проекты/Виртуальные дата-центры
В случае с Iaas (Infrastructure as a Service), должна быть возможность выделить пользователю или клиенту некий пул ресурсов над которым ему делегируется управление. Доступ к этим выделенным ресурсам осуществляется через упрощенный административный интерфейс. В таком пуле ресурсов(в CloudStack называется проектом) пользователь или клиент сам способен определять шаблоны ВМ, изменять конфигурацию сетевого взаимодействия между своими ВМ и прочее.

• Гибкое управление правами учетных записей
В большинстве компаний, в которых уже функционирует или только планируется построение частного или публичного облака, для централизованного управления учетными записями и ресурсами наверняка используется та или иная реализация службы каталогов. Не будет лукавством сказать, что чаще всего это Active Directory. По этому, одной из сильных сторон облачной платформы является возможность тесной интеграции с службами каталогов типа Active Directory, OpenLDAP и возможность гибко разграничивать функции администраторов, пользователей и групп в рамках облака.

• Скрытие внутренней архитектуры и иллюзия безграничности
В портале самообслуживания или в административном интерфейсе проекта/вирт. датацентра пользователю не должно быть видно внутреннее устройство облака, его архитектура, отдельные компоненты или физическое расположение. Пользователю доступны абстрактные ресурсы, использовать которые он может как угодно не подозревая на чем именно все работает и как взаимодействует. Облако это «безграничные» ресурсы которыми легко и быстро можно начать пользоваться даже простому пользователю не растрачивая время на технические тонкости.

О CloudStack

Изначально платформа CloudStack развивалась компанией Cloud.com и включала в себя ряд закрытых компонентов доступных только в коммерческой версии. После поглощения Cloud.com корпорацией Citrix в июле 2011 года продукт был переведен в разряд полностью открытых а весь код был опубликован под лицензией GPLv3. В феврале 2012 года, Citrix выпустила CloudStack 3 с поддержкой облачного хранилища Swift[1] развивающегося в рамках проекта OpenStack. Вскоре после выхода новой версии, в апреле 2012 года, Citrix передает CloudStack в Apache Software Foundation(далее ASF) и изменяет лицензию на Apache License 2 под которой проект развивается и сейчас. Версия CloudStack 4 выпущена уже под покровительством ASF в ноябре 2012 года и является на текущий момент стабильной.

Платформа CloudStack позволяет автоматизировать развертывание, настройку и управление публичным, частным или гибридным облаком. CloudStack позволяет использовать в рамках одной облачной инфраструктуры одновременно несколько гипервизоров таких как Xen (Citrix XenServer и Xen Cloud Platform), KVM, Oracle VM, VMware ESXi.

Архитектура облака на базе CloudStack

Инфраструктура CloudStack иерархическая. Наивысшим уровнем является Зона (Zone) — структура уровня дата-центра.

Зона (Zone) — является крупнейшей структурой в иерархии CloudStack. Зона обычно соответствует одному центру обработки данных, хотя допустимо иметь несколько зон в рамках одного центра обработки данных. Организация инфраструктуры в зоны необходима для обеспечения физической изоляции и избыточности. Например, каждая зона может иметь свой собственный источник питания и сетевое соединение, зоны могут быть широко разделены географически (хотя это не обязательно). В рамках одной зоны, спокойно могут работать хосты под управлением разных гипервизоров.

Стойка (Pod) — является второй по величине структурой в иерархии CloudStack и представляет из себя аналог физической стойки с серверами. Стойки, содержатся в зонах. Каждая зона может включать в себя одну или несколько стоек.
Клаcтер (Cluster) — является третьей по величине структурой в CloudStack. Кластеры содержатся в стойках а стойки в свою очередь в зонах . По сути Кластер — это группа физических серверов(хостов) с однотипной конфигурацией размещенных в одной стойке. Все хосты должны работать под управлением однотипного гипервизора, находится в одной подсети и иметь доступ как минимум к одному общему хранилищу. Живая миграция ВМ с одного хоста на другой, без прерывания обслуживания, может быть выполнена только в рамках одного кластера.

Узел (Host) — физический сервер с установленным гипервизором (KVM, Xen или ESXi). Узлы(далее хосты) обеспечивают вычислительные ресурсы, на которых работают ВМ. Хосты являются самой маленькой единицей в инфраструктуре CloudStack.
Хранилища (Storages) — бывают первичными (Primary) и вторичными(Secondary). Вторичные хранилища могут быть только на NFS-серверах, тогда как первичные дополнительно могут быть подключены по iSCSI или использовать локальные диски CloudStack-сервера.
Первичное хранилище, подключается к кластеру и является общим для всех хостов кластера. На первичном хранилище располагаются диски ВМ. Первичное хранилище должно обладать повышенной надежностью т. к. в случае его отказа функционирование облака будет полностью нарушено.
Вторичное хранилище, не подключается не к одному кластеру и хосту соответственно, оно существует на уровне зоны и служит для хранения шаблонов ВМ и ISO-образов а так же снимков ВМ(VM Snapshots).

Сервер управления облаком — собственно сам CloudStack Management Server (далее CloudStack MS) которому и просвещена данная статья. По сути, CloudStack MS это реализация централизованного управляющего сервера предоставляющего удобный интерфейс управления гетерогенной виртуальной инфраструктурой превращая ее в облако-подобный сервис.
CloudStack MS может быть установлен на одном единственном сервере или же развернут на нескольких серверах в отказоустойчивом режиме (Multi-node configuration). В самом простом случае, все, что нужно CloudStack MS для создания облака, это хосты с поддерживаемыми гипервизорами и системы хранения(NFS или iSCSI). Стоит подчеркнуть, что CloudStack MS — это управляющий сервер и не должен использоваться как узел виртуализации(хост)! Хотя, вариант с установкой гипервизора и использование его по назначению на CloudStack MS, теоретически возможен!

Рис. 1. Визуальное представление, зоны CloudStack со всей ее структурой (стойки, кластеры, хосты и хранилища).

Немного про установку

Для установки CloudStack MS в базовом варианте необходим один сервер, физический или виртуальный не принципиально, под управлением CentOS/RHEL 6.3+ или Ubuntu 12.04. Поддержка аппаратной виртуализации от сервера на котором устанавливается CloudStack MS не требуется т.к. ВМ запускаются на хостах а не на самом CloudStack MS.
Рекомендуемые требования к серверу следующие: CPU x86-64, 4 GB RAM, 50 GB на диске. В случае если CloudStack MS будет использоваться в качестве вторичного NFS-хранилища, то рекомендуется(не означает, что обязательно) 500GB дискового пространства для хранения шаблонов ВМ и ISO-образов, один сетевой контроллер, статический IP-адресс и полное FQDN имя[4]. Требования к серверу являются рекомендуемыми и не обязательны к соблюдению. Реально CloudStack MS способен работать на сервере с любыми параметрами. Пожалуй единственным требованием является наличие процессора с архитектурой x86-64. В качестве базы данных используется MySQL который может быть установлен как на отдельном сервере, так и вместе с CloudStack MS.
Установка [2] выполняется при помощи пакетов доступных из репозиториев CloudStack в несколько действий и проходит быстро и гладко.

Минимум для облака

Прежде чем запустить свою первую ВМ в облаке, необходимо сконфигурировать Зону.
Сразу же после описания Зоны будет необходимо включить в нее первую Стойку. В след за стойкой добавляется Кластер в состав которого должен входить как минимум один Хост.
После добавления Хостов, к кластеру подключается Первичное хранилище(NFS или iSCSI)которое становится доступно всем членам кластера. Вторичное хранилище(NFS) которое должно быть доступно только CloudStack MS подключается последним. Поддерживаемой конфигурацией является использование CloudStack MS в качестве Вторичного хранилища в случае если отдельного сервера для этой роли нет.
В качестве Хостов(узлов виртуализации) могут использоваться только физические сервера с поддержкой аппаратной виртуализации (Intel-VT или AMD-V) под управлением XenServer (5.6 SP2,6.0,6.0.2), KVM (Qemu/KVM: 1.0 или выше, libvirt: 0.9.4 или выше), ESXi (4.1 или 5.0 вместе с vCenter Server).
Развертывание новых ВМ производится из шаблонов ВМ (создаются на основе любой уже работающей ВМ) или из ISO-образов. Их загрузка в CloudStack MS производится только по HTTP! Поэтому, очень удобно развернуть свой локальный веб-сервер и разместить на нем нужные образы, избавив CloudStack MS от необходимости скачивать их из внешних источников.
Некоторых служебные операции, в частности загрузка новых образов или шаблонов во Вторичное хранилище, CloudStack MS возлагает на специальные, служебные ВМ (System VM). Обычно, они располагают не большими ресурсами(300Mhz/128 Mb). Создаются такие ВМ на базе специального служебного шаблона в основе которого минимальный Debian 6.0 включающий в себя последние обновления безопасности и свежие драйвера для виртуального оборудования гипервизоров KVM, Xen и ESXi. Количество одновременно существующих System VMs может быть разное, решение о создании или остановке таких ВМ принимает сам CloudStack MS. Например, если необходимо выполнить загрузку новых шаблонов или ISO-образов, создается и запускается новая служебная Secondary Storage VM которая обрабатывает эту операцию. В случае если запрашивается доступ к VNC консоли ВМ будет развернута еще и Console Proxy VM которая обеспечит зашифрованный канал от хоста к браузеру администратора или пользователя. В ситуациях когда услуги той или иной служебной ВМ не нужны, они отключаются автоматически самим CloudStack MS. Все служебные ВМ выполняются на тех же узлах виртуализации, что и остальные ВМ. Видеть и частично управлять (остановить/запустить) ими может только администратор.

Рис 2. Интерфейс веб-консоли управления облаком.

Управление ресурсами

Выделение практически любых ресурсов, будь то процессор, память, дисковое пространство или сетевые ограничения производится путем применения шаблонов (Offerings) предварительно определенных администратором. Существует несколько категорий шаблонов:

Compute Offerings — описывает основные ресурсы ВМ, такие как максимальная чистота и количество CPU, объем памяти, место хранения ВМ (локально или на общем хранилище).
System Offerings – описывает наборы ресурсов для системных ВМ (System Vms).
Disc Offerings — предустановки для дисков ВМ. Размеры и описание.
Network Offerings — Здесь можно установить ограничение на пропускную способность, VLAN, разрешить или запретить определенный тип трафика.
Всем новым шаблонам описывающим различные ресурсы присваивается произвольное, понятное имя. В дальнейшем создание ВМ сводится к выбору тех или иных шаблонов формирующих в итоге ее производительность и ограничения. Изменить какой либо шаблон ресурсов, во время работы ВМ не удасться. Единственное, что возможно при работающей ВМ, это добавить или удалить те или иные правила в одном из существующих шаблонов Network Offerings.

Авторизация и управление правами доступа

Откровенно говоря, распределение прав и ресурсов между пользователями/клиентами виртуальной инфраструктуры, выполнено на мой взгляд слабо и не логично. За близкую к эталону модель я беру реализацию разграничения прав в Proxmox VE 2.1 [3] на основе ролей, групп и простой интеграцией с Active Directory/LDAP. Что касается CloudStack, то глобально здесь существует два вида учетных записей: «User» — для пользователей и «Admin» — для администраторов. В качестве своеобразных групп, используется понятие доменов (Domains). На уровне домена можно определить такие ограничения как — макс. количество ВМ (Instance Limits), лимит публичных IP (Public IP Limits), макс. число снапшотов (Snapshot Limits) и т.д. Количественные ограничения определенные на уровне домена и являются суммарным ограничением для всех членов этого домена.
У всех пользователей облака не зависимо от их роли так же настраиваются аналогичные доменам количественные лимиты но они не могут превышать ограничения домена членами которого являются пользователи.
Все административные учетные записи делятся на корневых администраторов (Admins) и администраторов доменов (Domain-admins). В официальной документации сказано, что последние наделены привилегиями на управление учетными записями пользователей своего домена. В моем конкретном случае, практика показала, что «Domain-admins» не чем не отличаются от обычных пользователей и не способны не создавать, не удалять или редактировать учетные записи своего домена. В таком случае не совсем понятно предназначение доменов кроме как для наложения количественных ограничений на группу пользователей.
Управление конфигурацией облака, подключение кластеров, хранилищ, создание шаблонов, создание доменов и т.п. полностью возложено на корневых администраторов (Admins) и разделения прав между ними не предусмотрено вообще!
Что касается интеграции с LDAP каталогом типа Active Directory или ApacheDS то необходимо использовать CloudStack API. Каких либо намеков на включение этой возможности в веб-интерфейсе или служебных утилит с интерфейсом командной строки к сожалению нет.

Инфраструктура для клиентов

Воспользоваться виртуальной инфраструктурой предоставляемой CloudStack, могут как отдельные пользователи/клиенты, так и группы пользователей представляющие например организацию. При этом один пользователь, может существовать как самостоятельный клиент и одновременно состоять в группе. Все используемые группой ресурсы оплачиваются по одному счету. Если кто-то из клиентов будучи членом группы использовал какие то ресурсы как самостоятельный клиент то ему прийдется оплатить их отдельно.
В рамках домена, для выделения виртуальной инфраструктуры группе пользователей в CloudStack реализованы проекты (Projects). На проект налагаются количественные ограничения подобные доменам CloudStack. В отличии от доменов в рамках проекта обязательно определяется владелец (Account project owner). Будучи владельцем проекта, пользователь может добавить любого из существующих в его домене пользователей в качестве участника проекта. Владелец проекта так же вправе удалить любого члена проекта. Удаление из проекта не означает удаление учетной записи пользователя из облака. Виртуальные машины, шаблоны, ISO-образы, IP-адреса и все то что будет загружено или создано в рамках проекта, является общим для всех его членов и позволяет легко обмениваться ресурсами. Интерфейс управления проектом немного похож на полноценную консоль корневого администратора только имеет значительно меньше функций. По сути, проекты изолируют свои виртуальные ресурсы от других пользователей и проектов. По умолчанию, любой пользователь может создать свой проект и добавить в него других участников но эти возможности легко отключаются корневым администратором в разделе Global Settings.
Рис 3. Интерфейс управления проектом

Роль CloudStack Managment Server

По сути CloudStack MS является высокоуровневым сервером управления и мониторинга состояния архитектуры, своего рода посредником, между узлами виртуализации, системами хранения и администратором. Под высоким уровнем я понимаю, освобождение администратора или пользователя облака от множества технических вопросов возникающих при работе в стандартных для каждой платформы консолях управления типа Citrix XenCenter, VMware vSphere Client. Множество задач CloudStack выполняет автоматически, не спрашивая администратора/пользователя и не предоставляя возможности выбрать. Например, когда в кластере несколько хостов и доступно более одного хранилища то при создании новой ВМ, нельзя указать хранилище или конкретный хост кластера для этой ВМ. Решение о том где будет работать ВМ и куда поместить ее диски принимается CloudStack MS самостоятельно. И если переместить ВМ (мигрировать) на другой хост кластера не составит труда, то изменить хранилище дисков ВМ к сожалению не возможно! При этом использование собственных средств конфигурирования например Citrix XenCenter для управления XenServer приводит к рассинхронизации состояния хоста и CloudStack MS и влечет за собой различные проблемы. Поэтому, стоит понимать, что внедрение CloudStack предполагает использование CloudStack MS как единственного средства управления облаком.

Роль сервера баз данных

База данных используется для хранения информации обо всех объектах инфраструктуры, о пользователях, проектах, хостах и т. д. К примеру для смены пароля учетной записи от имени которой осуществляется подключение к хосту необходимо править записи прямо в БД. База данных является важной составляющей инфраструктуры. Ее отказ, может привести к потере управления над облаком в не зависимости от количество развернутых серверов управления.

Механизмы отказоустойчивости

Сервер управления CloudStack MS

CloudStack MS выполняет лишь управляющую функцию. Нормальная работа Хостов не будет нарушена при отключении или аварийной остановке единственного или всех серверов управления. Все виртуальные машины будут продолжать работать в обычном режиме.
Но, при этом создание новых или запуск существующих ВМ пользователями будет не возможен. Так же перестанут работать функции динамического распределения нагрузки и отказоустойчивость(HA) на уровне ВМ. Фактически, у администраторов останется возможность запустить или остановить ВМ стандартными средствами используемых гипервизоров. Но в таком случае, к примеру, Network Offerings определенный для ВМ не будет обработан и применен а доступа к консоли ВМ, пользователи так же получат.
Для того что бы управление облаком всегда было доступно необходимо разворачивать CloudStack MS на нескольких различных серверах. В такой конфигурации, MySQL должен находится на отдельном сервере. Отличия установки первого сервера управления от добавления дополнительного отличается лишь одним колючем в команде инициализации базы данных. При подключении еще одного CloudStack MS к существующей базе данных опускается параметр выполняющий инициализацию новой базы. Без этого параметра, свеже добавленный сервер управления работает с указанной базой данных точно так же как и первый развернутый сервер. Количество серверов может быть произвольным а их развертку можно выполнять даже путем клонирования т. к. параметры подключения к базе данных идентичны. Необходимо будет только сменить ip-адресс и имя сервера. Все сервера управления предположительно должны находится за бальзамировщиком нагрузки который автоматически будет подключать пользователей к рабочему серверу в случае если один или несколько из них откажут.

Механизмы отказоустойчивости ВМ

Каждый пользователь облака, в свойствах любой ВМ может включить опцию HA(High Availability). По умолчанию, опция HA включена только для некоторых типов служебных ВМ (Virtual router VMs, Elastic Load Balancing VMs). Если работа какой то из ВМ с включенной опцией HA, будет аварийно прервана, например по причине отказа хоста, то CloudStack MS выполнит перезапуск ВМ в рамках текущей Зоны. Аварийно завершенная ВМ с опцией HA не когда не будет перезапущена в другой Зоне. При этом CloudStack MS гарантирует, что в одно и то же время не будет двух работающих экземпляров одной и той же ВМ. Перезапуск завершенной ВМ будет выполнен на другом хосте в том же Кластере. Соответственно, если в кластере по какой то причине только один хост или же множество но на них не достаточно ресурсов для запуска остановленной ВМ, HA не чем не поможет. Планируйте инфраструктуру и нагрузку на нее изначально правильно, учитывая отказ серверов и перезапуск ВМ.
Опция HA, доступна только при использовании в качестве Первичных, NFS или iSCSI-хранилищ. Стоит отметить, что функция отказоустойчивости ВМ является особенностью самого CloudStack MS и не зависит от используемого типа лицензии на ваш гипервизор. Например, в моем случае использовался Citrix XenServer со свободной лицензией при наличии которой HA для ВМ не возможен. При этом, за счет собственных механизмов CloudStack MS, в случаях отказа одного из хостов, все ВМ с опцией HA благополучно перезапускались на оставшихся в кластере серверах.

Отказоустойчивость хранилищ

Первичное хранилище в не зависимости от типа, является на мой взгляд самым слабым звеном в инфраструктуре CloudStack-облака.
В случае если откажет Первичное хранилище, то все ВМ использующие его, будут немедленно остановлены хостами. ВМ которые работают с опцией HA будут запущенны немедленно при восстановлении работоспособности хранилища.
Возможности, например репликации Первичного хранилища в CloudStack MS нет.
Все функции отказоустойчивости хранилища полностью возложены на используемую систему хранения.

Вторичные хранилища, не содержат непосредственно данные работающих ВМ и поэтому отказ такого хранилища не повлечет за собой сбой в работе облака. Правда, не будут доступны шаблоны ВМ и ISO-образы а так же сделанные пользователями снапшоты. CloudStack MS допускает существование нескольких вторичных хранилищ в рамках одной зоны. Создание перекрестных резервных копий данных находящихся на этих хранилищах поможет обеспечить непрерывность их работы.

Выводы

На сегодняшний день, CloudStack это один из немногих продуктов которые могут быть с легкостью развернуты и настроены без каких либо сложностей. Практически весь функционал реализованный в CloudStack доступен из веб-интерфейса который стоит отметить работает шустро, не зависает и не огорчает всяческими ошибками. Огромный список настроек затрагивающий все подсистемы с понятными названиями и описанием доступен в разделе Global Settings, и не требует правки конфигурационных файлов в терминале Linux. Не плохо реализованный журнал событий позволяет просмотреть действия всех пользователей что частично компенсирует отсутствие разделения прав между корневыми администраторами. Не плохо реализован мониторинг, доступный как отдельным пользователям желающим посмотреть графики производительности своих ВМ так и для администраторов на уровне всей зоны. К сожалению CloudStack не способен полностью заменить стандартные средства управления такие как Citrix XenCenter, VMware vSphere Client и т.п. и не предоставляет подобного функционала. Например мне не удалось найти способа добавить еще один сетевой контроллер для ВМ в интерфейсе CloudStack. Похоже, что таковая возможность не предусмотрена. В текущей версии в отличии от предыдущей доступен русскоязычный интерфейс но к сожалению его я так и не увидил, т. к. при переключении на русский язык при входе, консоль не загружалась.

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

Ссылки

[1] Немного про OpenStack Swift — http://openstack.ru/about/components/openstack-swift/
[2] Про установку CloudStack — https://ivirt-it.ru/2013/01/install-cloudstack-4/
[3] Обзор Proxmo VE 2.1 — http://www.servernews.ru/articles/595907
[4] Понятие полного определенного имени — http://ru.wikipedia.org/wiki/FQDN

Помогла ли вам статья?