Четвертый пост, написанные Михаилом Михеевым по его практическому опыту работы в vCloud IT-GRAD: Проект вступил в прикладную стадию. Согласованы условия, выделены ресурсы, дан доступ. Что теперь?"
Нам дана ссылка и учетная запись. Воспользовавшись ими, мы попадаем в интерфейс (рис.1 "Главное окно интерфейса нашего облака").
Так как мы договорились делать работу с нуля, то тут пусто – и нам надо создать собственные виртуальные машин.
Напомню, что задача перед нами стоит следующая:
1) развернуть vSphere (свою собственную, виртуальную)
2) развернуть сервер View
3) в идеале, сделать конфигурацию тиражируемой – на случай зашедших не туда тестов, на случай развертывания тестовой площадки для изменившихся условий.
Начнем, очевидно, с создания нужных виртуальных машин, а точнее их групп – vApp (рис.2 "Создание vApp").
В мастере создания vApp (или в любой момент времени потом) можно указать:
Затем, в общем то, все.
Мы видим созданные ВМ, к любой открываем консоль и начинаем выполнять задачи проекта. Установка ОС, настройка, софт и так далее (рис. 3 "Несколько созданных ВМ и консоль к одной из них").
То есть действительно все так и есть – нам потребуется несколько минут от момента получения учетной записи, чтобы дойти до момента когда мы готовы начать устанавливать нужные операционные системы и приложения.
К примеру, что получилось у меня (рис. 4 "Инфраструктура, решающая мою задачу"):
На виртуальных ESXi запущены виртуальные десктопы. Разумеется, такая матрешка не для производственной среды и не для пилота – но для теста отлично и удобно.
К серверу View дан доступ из интернета – я спокойно тестирую подключение в разных условиях.
Если завтра будет поставлена задача протестировать какое либо альтернативное решение для VDI – я разверну AD+еще сервер из шаблона, и через 5-10 минут с момента получения задания начну его выполнять.
А если этим альтернативным проектом займется другой человек – я создам дополнительную учетную запись в облаке, и укажу сколько виртуальных машин этот пользователь может создать, и сколько времени их хранить (рис. 5 "Создание пользователя, которму затем можно дать права на часть виртуальных серверов").
Привлеку ваше внимание к одному небольшому организационному нюансу: vDC, виртуальный ЦОД
Это тот кусок вычислительных ресурсов, что выделен под наши задачи. Попросту говоря, это пул ресурсов в vSphere облакопровайдера.
Мы всего навсего создаем себе требуемые виртуальные машины с требуемым для них количеством мегагерц и мегабайт, и затем видим выделенное нам в интерфейсе (рис.6 "Наш кусочек облака").
Интересна настройка Allocation Model
Как видно, используется вариант настройки под названием Pay-As-You-Go.
Это означает, что настройки ресурсов указываются для каждой ВМ, а настройками пула является сумма резервов и лимитов ВМ.
Таким образом, сколько ресурсов нам надо, столько мы и получаем.
Этот вариант хорош тем, что мы просто создаем виртуальные машины по факту их нужности нам – ничего ни с кем не согласовывая. И по факту потребления ресурсов платим.
Вариант хорош своей облачностью – удобно. Нет лишней бюрократии, согласований, потерь времени на все это..
Данный вариант выделения ресурсов является вариантом по умолчанию – по той простой причине, что большинству он и удобен. В самом начале общения у нас не будут выпрашивать сколько ресурсов нам надо – разве что масштаб. Дадут доступ – и все, сколько мы хотим столько используем.
Два других варианта выделения ресурсов – когда ресурсы под нас выделяются не по факту наших настроек виртуальных машин, а администратором облака. То есть создаваемые нами виртуальные машины попадают в пул ресурсов с ограниченными сверху ресурсами. Между собой эти варианты отличаются гарантией – мы можем запросить 100% резервирование ресурсов под наши задачи, или частичное. Разумеется, это различие потянет за собой различие в выставляемом счете.
Все. А далее мы слегка углубимся в том, что скрывается за всем этим.
Ок, все на мази – что я имею...
Нам дана ссылка и учетная запись. Воспользовавшись ими, мы попадаем в интерфейс (рис.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% резервирование ресурсов под наши задачи, или частичное. Разумеется, это различие потянет за собой различие в выставляемом счете.
Все. А далее мы слегка углубимся в том, что скрывается за всем этим.
