Четвертый пост, написанные Михаилом Михеевым по его практическому опыту работы в vCloud IT-GRAD:
" Проект вступил в прикладную стадию. Согласованы условия, выделены ресурсы, дан доступ. Что теперь?"


Проект вступил в прикладную стадию. Согласованы условия, выделены ресурсы, дан доступ. Что теперь?
Нам дана ссылка и учетная запись. Воспользовавшись ими, мы попадаем в интерфейс (рис.1 "Главное окно интерфейса нашего облака").




Так как мы договорились делать работу с нуля, то тут пусто — и нам надо создать собственные виртуальные машин.
Напомню, что задача перед нами стоит следующая:
1) развернуть vSphere (свою собственную, виртуальную)
2) развернуть сервер View
3) в идеале, сделать конфигурацию тиражируемой — на случай зашедших не туда тестов, на случай развертывания тестовой площадки для изменившихся условий.
Начнем, очевидно, с создания нужных виртуальных машин, а точнее их групп — vApp (рис.2 "Создание vApp").




В мастере создания vApp (или в любой момент времени потом) можно указать:

• как долго этот vApp можно включать;  для тестовых целей самое то – чтобы не плодить сущностей сверх необходимого;
• на том же шаге – как долго vApp надо хранить;
• какие ВМ в него входят – притом можно создать новые, а можно взять из каталога шаблонов;
• указать число vCPU, объем памяти, дисков, число сетевых интерфейсов и в какие сети эти интерфейсы подключены. Так же, как для них должны быть настроены IP адреса.

Затем, в общем то, все.
Мы видим созданные ВМ, к любой открываем консоль и начинаем выполнять задачи проекта. Установка ОС, настройка, софт и так далее (рис. 3 "Несколько созданных ВМ и консоль к одной из них").




То есть действительно все так и есть – нам потребуется несколько минут от момента получения учетной записи, чтобы дойти до момента когда мы готовы начать устанавливать нужные операционные системы и приложения.К примеру, что получилось у меня (рис. 4 "Инфраструктура, решающая мою задачу"):

• моя маленькая vSphere – 2 ESXi и vCenter;
• отдельно от них – пара виртуальных машин Windows – контроллер домена AD и сервер View. Отдельно – потому что мне было удобно сделать шаблон из этой пары;
• еще отдельно – одна вспомогательная Windows.

На виртуальных ESXi запущены виртуальные десктопы. Разумеется, такая матрешка не для производственной среды и не для пилота – но для теста отлично и удобно.

К серверу View дан доступ из интернета – я спокойно тестирую подключение в разных условиях.

Если завтра будет поставлена задача протестировать какое либо альтернативное решение для VDI – я разверну AD+еще сервер из шаблона, и через 5-10 минут с момента получения задания начну его выполнять.

А если этим альтернативным проектом займется другой человек – я создам дополнительную учетную запись в облаке, и укажу сколько виртуальных машин этот пользователь может создать, и сколько времени их хранить (рис. 5 «Создание пользователя, которму затем можно дать права на часть виртуальных серверов»).




Привлеку ваше внимание к одному небольшому организационному нюансу: vDC, виртуальный ЦОД


Это тот кусок вычислительных ресурсов, что выделен под наши задачи. Попросту говоря, это пул ресурсов в vSphere облакопровайдера.
Мы всего навсего создаем себе требуемые виртуальные машины с требуемым для них количеством мегагерц и мегабайт, и затем видим выделенное нам в интерфейсе (рис.6 "Наш кусочек облака").




Интересна настройка Allocation Model.
Как видно, используется вариант настройки под названием Pay-As-You-Go.
Это означает, что настройки ресурсов указываются для каждой ВМ, а настройками пула является сумма резервов и лимитов ВМ.
таким образом, сколько ресурсов нам надо, столько мы и получаем.
Этот вариант хорош тем, что мы просто создаем виртуальные машины по факту их нужности нам – ничего ни с кем не согласовывая. И по факту потребления ресурсов платим.
Вариант хорош своей облачностью – удобно. Нет лишней бюрократии, согласований, потерь времени на все это..
Данный вариант выделения ресурсов является вариантом по умолчанию – по той простой причине, что большинству он и удобен. В самом начале общения у нас не будут выпрашивать сколько ресурсов нам надо – разве что масштаб. Дадут доступ – и все, сколько мы хотим столько используем.
Два других варианта выделения ресурсов – когда ресурсы под нас выделяются не по факту наших настроек виртуальных машин, а администратором облака. То есть создаваемые нами виртуальные машины попадают в пул ресурсов с ограниченными сверху ресурсами. Между собой эти варианты отличаются гарантией – мы можем запросить 100% резервирование ресурсов под наши задачи, или частичное. Разумеется, это различие потянет за собой различие в выставляемом счете.

Все.

А далее мы слегка углубимся в том, что скрывается за всем этим.