Самообслуживание с помощью Cisco UCS Director: как дать пользователям возможность самостоятельно создавать виртуальные сервера

в 7:46, , рубрики: Cloupia, автоматизация бизнес-процессов, Блог компании ИТ-ГРАД, виртуализация, виртуальные сервера, Софт, метки: , , ,

Создание виртуальной машины yourself online

Вы уже слышали про Cisco UCS Director?
Готовы начать знакомство с этим продуктом?
Тогда я покажу, как сделать, чтобы конечные пользователи могли самостоятельно сформировать запрос на портале самообслуживания Cisco UCS Director и автоматически получить готовую виртуальную машину.

Для этого мы с вами научимся создавать наборы политик и объединять несколько политик в группу в рамках vDC, а также создадим каталог (шаблон) на базе этих политик, чтобы предоставить пользователям доступ к этому каталогу через портал самообслуживания.

Начнем с инфраструктуры. Инфраструктура, на базе которой мы будем выполнять все настройки, состоит из:

  • NetApp Clustered DataONTAP 8.2 Simulator в качестве дискового массива;
  • виртуальной инфраструктуры развернутой на базе:
  • ESXi appliance 5.5.0;
  • vCenter appliance 5.5.0a.

Выглядит это примерно так:
Инфраструктура для развертывания виртуальной машины

Сразу отмечу, что все настройки политик и параметров для шаблона(ов) виртуальных машин в нашем посте будут относиться к VMWare vSphere инфраструктуре.

Создание шаблона (каталога) на базе политик

В этом разделе я опишу процесс подготовки шаблона для виртуальной машины на базе дистрибутива CentOS 6.4, публикацию данного шаблона на Self-service портале и организацию доступа для конечного пользователя к данному шаблону (каталогу).

Политики (Policies)

В первую очередь мы создадим набор политик, которые позволят нам управлять шаблоном виртуальной машины, ограничивать набор ресурсов (CPU, Memory, Disk usage) и предоставлять пользователю возможность выбора определенного количества ресурсов при создании машины (в рамках разрешенных, разумеется).
Для начала давайте поймем что такое «Policy» в терминологии UCSD. Почти дословный перевод документации звучит так:
Политики – это набор правил, определяющих, где и как будет развернута виртуальная машина, с учетом имеющейся инфраструктуры и наличия системных ресурсов.
В целом это исчерпывающее объяснение. Остается добавить, что политики можно (и нужно) определять не только для виртуальных машин, но и для hardware серверов, дисковых массивов и даже сетевых устройств. Описание таких политик выходит за рамки моего поста.
Политики для виртуальных машин в UCSD делятся на четыре группы:

  • Computing;
  • Storage;
  • Network;
  • System.

Computing policy

Данный вид политик:

  • Позволяет явно выбрать нужный ESX сервер(а), кластер и пул ресурсов для размещения виртуальной машины;
  • Автоматизировать выбор ESX сервера с помощью заданий условий (Minimum conditions) размещения виртуальной машины (иными словами позволяет задать критерии выбора ESX сервера);
  • Изменить опции деплоймента машины;
  • Предоставить пользователю возможность самостоятельно выбрать нужное количество ресурсов (количество vCPU и памяти) из заданного администратором диапазона.

Для создания политики в интерфейсе UCSD переходим на закладку Policies -> Computing -> VMWare Computing Policy

СозданиеComputing policy в интерфейсе UCSD

И добавляем новую политику, нажав на Add button:

Задание параметров Computing policy

В нашем случае мы зададим следующие параметры:

Policy name CentOS_vm_computing
Cloud name IT-GRAD-TEST
Resizing options Allow resizing of VM (checkbox enable)
Permitting value for vCPUs 1,2,4
Permitting value for Memory in Mb 1024,2048,4192

Сохраняем политику в каталоге.

Storage policy

Данный вид политик:

  • Определяет набор датасторов на которых можно разместить виртуальную машину, а также предоставляет выбор требуемого датастора для пользователя;
  • Позволяет задать тип датастора, разрешенного для использования;
  • Позволяет указать набор условий (Minimum condition) для выбора датастора (Capacity, latency, e.t.c);
  • Позволяет задавать дополнительные политики для дисков – выбор типа диска: data, database, log, swap (не спрашивайте меня как эти политики влияют на распределение дискового пространства и производительность, ответа на этот вопрос у меня пока нет-;)).

Для создания политики в интерфейсе UCSD переходим на закладку Policies -> Storage -> VMWare Storage Policy.

Создание Storage policy в интерфейсе UCSD

Задаем параметры:

Задание параметров для Storage policy

Задание параметров для Storage policy

Задание параметров для Storage policy

Жмем Next, переходим на ту самую загадочную страницу с настройками Additional Disk Policy, оставляем на ней все без изменения.

Задание параметров для Storage policy

Итого мы получили новую сущность – VMWare Storage Policy со следующими настройками:

Policy name CentOS_vm_computing
Cloud name IT-GRAD-TEST
Datastore scope Include selected
Selected datastore vs1_nfs1 (в нашем случае)
Use shared datastore checkbox uncheck
Use local storage checkbox uncheck
Use NFS checkbox enable
Use SAN checkbox enable
Allow resizing of disk checkbox enable
Permitted values of disk in Gb 16,40

Network policy

Сразу уточню, что описываемая политика не имеет никакого отношения к сетевому оборудованию и отвечает только за конфигурацию сетевой подсистемы у создаваемой виртуальной машины.
Данный вид политик:

  • Позволяет конфигурировать параметры выбора ip адреса (DHCP, IP Pool or Static IP);
  • Разрешить добавление дополнительных сетевых адаптеров при создании виртуальной машины;
  • Позволяет задавать требуемую PortGroup для размещения виртуальной машины;
  • Позволяет определять тип сетевого адаптера.

Для создания политики в интерфейсе UCSD переходим на закладку Policies -> Network -> VMWare Network Policy

Создание Network policy в интерфейсе UCSD

Задаем параметры:

Задание параметров для Network policy

Задание параметров для Network policy

Задание параметров для Network policy

Задание параметров для Network policy

Задание параметров для Network policy

Далее жмем Submit до победного. В итоге получили политику, в которой определено количество адаптеров, тип адаптера, PortGroup на виртуальном свиче, пул статических адресов из которого можно будет взять адрес для виртуальной машины.

Policy name CentOS_vm_computing
Cloud name IT-GRAD-TEST
VM Network
NIC alias vNIC1
Adapter type VMXNET3
Port group VM Network
IPv4 configuration
Select IP address type Static
Select IP address source Inline IP Pool
Static IP Pool 192.168.1.2-192.168.1.10
Netmask 255.255.255.0
Gateway IP address 192.168.1.1

System policy

Заключительный тип политик, который мы рассмотрим в данном посте – это system policy.
Данный вид политик:

  • Определяет системные параметры виртуальной машины, такие как шаблон имени VM и шаблон имени хоста (hostname на уровне OS);
  • Настройки DNS, такие как name servers и доменный суффикс;
  • Настройки timezone для Linux OS;
  • Выбор устанавливаемой операционной системы и многие другие (см. документ Cisco UCS Director Administration Guide, Release 4.1).

Для создания политики в интерфейсе UCSD переходим на закладку Policies -> Service Delivery -> VMWare System Policy

Создание System policy в интерфейсе USCD

Настроек в этом разделе немного:

Настройка System policy

Policy name CentOS_vm_computing
VM name template vm-${USER_NAME}
Power on after deploy Checkbox enable
Host name template testvm1
DNS domain Test.local
Linux time zone Europe/Moscow
VM Image Type Linux only

На этом настройки политик закончены, все необходимые политики созданы. Далее мы должны объединить все наши политики в группу и опубликовать наш шаблон (приложение) на портале самообслуживания.

Создание vDC

В терминологии UCSD vDC – это объект в рамках которого сгруппирован некий набор виртуальных ресурсов, образов виртуальных машин (templates) и политик. vDC дает возможность предоставлять управление строго определенным набором ресурсов на уровне групп пользователей или организаций, созданных в UCSD.

Используя vDC, мы можем:

  • Предоставлять возможность управления наборами ресурсов организациям или группам;
  • Задавать квоты на ресурсы для организаций или групп;
  • Определять набор действий, разрешенных конечному пользователю в отношении виртуальных машин, ассоциированных с vDC;
  • Определять политику, которая будет выполнять набор действий описанных с помощью WorkFlow, после создания конечным пользователем виртуальной машин;
  • Определять набор предопределенных действий (на базе штатных workflow), которые пользователь может производить с виртуальной машиной в заданном vDC;
  • Задавать требования для апрува запросов на выделение ресурсов и определять пользователей, ответственных за апрув запросов на уровне vDC.

Для создания политики в интерфейсе UCSD переходим на закладку Policies -> Virtual Data Centers -> vDC:

Создание Virtual DataCenters (vDC)

Настройка Virtual DataCenter (vDC)

Настройка Virtual DataCenter (vDC)

В нашем случае мы определили следующие настройки:

vDC Name vDC_cust1
Group Cust1
Cloud name IT-GRAD-TEST
Policies
System policy CentOS_vm_system
Computing policy CentOS_vm_computing
Network policy CentOS_vm_network
Storage policy CentOS_vm_storage
End User self-service options
Vm power management checkbox enable
VM snapshot management checkbox enable
VM Network management checkbox enable

Итак, мы выполнили настройки vDC. Задание группы в настройках нашего vDC означает, что пользователи указанной группы получают доступ к ресурсам, сгруппированным для нашего vDC.

Также мы дали возможность нашим пользователям управлять состоянием (вкл/выкл), управлять снапшотами и сетевыми настройками для виртуальных машин, ассоциированных с vDC.

Создание каталога (Catalog)

Мы постепенно приближаемся к финалу наших работ и на заключительном этапе нам необходимо создать каталог. Что же это такое?

Catalog – это объект, на базе которого пользователь на портале самообслуживания сможет сформировать запрос на создание виртуальной машины (и не только это конечно же, но мы разбираем частный случай). Другими словами – это интерфейс предоставления определенной услуги или набора услуг для конечного потребителя.

Каталоги в UCSD могут быть четырех типов (детали вы можете узнать в документе Cisco UCS Director Administration Guide, Release 4.1). В нашем случае мы будем использовать каталог типа Standard, который предназначен как раз для хранения шаблонов виртуальных машин, предназначенных для создания готовых VM по запросу пользователя.

Для создания политики в интерфейсе UCSD переходим на закладку Policies -> Catalog:

Создание каталога (Catalog)

Создание каталога (Catalog)

Настройки каталога (Catalog)

Catalog name CentOS_vm_Cust1
Catalog type Standard
Catalog Icon VM: CentOS Linux
Selected groups Cust1
Cloud Name IT-GRAD-TEST
VM Images CentOS
Category Generic VM
Specify OS Linux – CentOS

Собственно все необходимые нам настройки мы задаем на первых двух страницах формы создания каталога: Basic Information и Application Details. Остальные настройки я оставлю без изменения, если кто-то хочет узнать об этих настройках больше – велкам в неоднократно указанное мной руководство администратора UCSD.

После создания каталога он автоматически публикуется на портале самообслуживания и доступен членам той группы, которую мы выбрали.

Итак, мы закончили базовую часть наших настроек, получив в итоге vDC с набором политик и каталог с заданным шаблоном операционной системы. Что дальше?

Работа с Self-Service Portal

Пользователи и группы в UCSD

В первую очередь я опишу процедуру создания группы (надеюсь, всем понятно, что наша группа Cust1 была создана до момента создания vDC и каталога). Для этого переходим на вкладку Administration -> Users and Groups -> User Groups:

Создание группы в UCSD

И запускаем форму создания новой группы:

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

Собственно создание группы не должно вызывать никаких сложностей. Самое интересное мы выполним после создания группы — мы зададим набор ограничений на ресурсы, которые могут быть использованы пользователями, входящими в нашу группу. Мы можем задать ограничения для:

  • Virtual resources;
  • Operating system resources;
  • Physical resources.

Для того, чтобы задать лимиты необходимо выбрать нужную нам группу из списка уже созданных и запустить форму «Edit resource limits»

Создание ограничений ресурсов для определенной группы

Создание ограничений ресурсов для определенной группы

Не забываем включить чекбокс «Enable resource limits». Подробное описание всех настроек формы есть в документе «Cisco UCS Director Administration Guide, Release 4.1».

Теперь давайте создадим нашего пользователя, которому дадим доступ на портал самообслуживания. Для этого переходим на вкладку Administration -> Users and Groups -> Login Users

Создание пользователя с правами доступа на портал самообслуживания

И добавим нового пользователя

Добавление нового пользователя

Несколько комментариев:

  1. Тип пользователя Service End-User определяет для пользователя возможность заходить и использовать портал самообслуживания. Другими словами это встроенная роль, определяющая права доступа пользователя к набору ресурсов сервис-портала.
  2. Обратите внимание на группу, которую мы задаем для пользователя. Это та самая группа, которую мы указывали при создании vDC и каталога. Собственно за счет привязки нашего пользователя к нужной группе мы даем ему возможность пользоваться созданным нами каталогом (другими словами получать услугу).

Self-Service portal

И наконец то, ради чего мы делали все предыдущие настройки – портал самообслуживания. Доступ к порталу получить очень просто, для этого нужно всего лишь зайти по стандартной ссылке под пользователем enduser, которого мы создали.

Интерфейс портала самообслуживания

На интерфейсе портала нам автоматически будет доступен созданный ранее каталог CentOS-vm_Cust1. Попробуем создать запрос на развертывание виртуальной машины. Для этого можно либо выбрать доступный каталог и нажать на «Create Request»

Создание запроса на создание виртуальной машины

Либо просто щелкнуть дважды мышкой на нужном каталоге. В обоих случаях появится форма создания запроса:

Форма запроса на создание виртуальной машины

Жмем Next

Выбор доступного vDC и время развертывания виртуальной машины

Здесь мы можем выбрать доступный нам vDC и время развертывания виртуальной машины (можно запланировать нужное нам время). Говорим, что хотим развернуть машину right now и жмем Next.

Задание требуемых ресурсов виртуальной машины

Я хочу получить виртуалку с 2-мя vCPU, 4-мя гигами оперативки и 16 Гб vHDD. Задаю нужные параметры, как показано на рисунке выше. И жму Next.

Кастомный workflow

Кастомных workflow мы к нашему шаблону пока не привязали, поэтому просто жмем Next.

Сводка о создании виртуальной машины

На этом создание запроса завершено, можно просмотреть сводку и нажать Submit

Статус Service Request’а

Безусловно нам будет интересно следить за ходом выполнения нашей заявки. На портале самообслуживания UCSD есть удобный интерфейс для просмотра статуса и логов выполнения запроса.

Нам нужно перейти на страницу портала, которая называется «Services» и выбрать нужный нам запрос из списка:

Просмотр статуса и логов выполнения запроса

Для просмотра деталей либо кликаем два раза мышкой на нужный запрос, либо жмем «View Details»

Просмотр деталей запроса

Мы видим этапы выполнения запроса и их текущий статус. Что выполнено, что выполняется, какие результаты.

Этапы выполнения запроса и текущий статус

Все этапы нашего запроса выполнились успешно. Итог – новая виртуальная машина.

На этом я закончу рассказ о функционале UCSD в области «провижининга» виртуальных машин и портале самообслуживания. Спасибо тем, кто дочитал до конца, надеюсь, пост будет полезен для тех, кто начинает знакомиться с продуктом.

Автор: it_man

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js