Pull to refresh
98.6
CloudMTS
Виртуальная инфраструктура IaaS

Как приручить облака: примеры практического использования. Что мы получили?

Reading time 3 min
Views 8.4K
Четвертый пост, написанные Михаилом Михеевым по его практическому опыту работы в 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% резервирование ресурсов под наши задачи, или частичное. Разумеется, это различие потянет за собой различие в выставляемом счете.

Все. А далее мы слегка углубимся в том, что скрывается за всем этим.
Tags:
Hubs:
+14
Comments 2
Comments Comments 2

Articles

Information

Website
cloud.mts.ru
Registered
Founded
Employees
201–500 employees
Location
Россия