В этом посте специалисты компани ИТ-ГРАД расскажут о решении 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
И добавляем новую политику, нажав на Add button:
В нашем случае мы зададим следующие параметры:
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.
Задаем параметры:
Жмем Next, переходим на ту самую загадочную страницу с настройками Additional Disk 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
Задаем параметры:
Далее жмем 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
Настроек в этом разделе немного:
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:
В нашем случае мы определили следующие настройки:
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 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:
Собственно создание группы не должно вызывать никаких сложностей. Самое интересное мы выполним после создания группы — мы зададим набор ограничений на ресурсы, которые могут быть использованы пользователями, входящими в нашу группу. Мы можем задать ограничения для:
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
И добавим нового пользователя:
Несколько комментариев:
Тип пользователя Service End-User определяет для пользователя возможность заходить и использовать портал самообслуживания. Другими словами это встроенная роль, определяющая права доступа пользователя к набору ресурсов сервис-портала.
Обратите внимание на группу, которую мы задаем для пользователя. Это та самая группа, которую мы указывали при создании vDC и каталога. Собственно за счет привязки нашего пользователя к нужной группе мы даем ему возможность пользоваться созданным нами каталогом (другими словами получать услугу).
Self-Service portal
И наконец то, ради чего мы делали все предыдущие настройки – портал самообслуживания. Доступ к порталу получить очень просто, для этого нужно всего лишь зайти по стандартной ссылке под пользователем enduser, которого мы создали.
На интерфейсе портала нам автоматически будет доступен созданный ранее каталог CentOS-vm_Cust1. Попробуем создать запрос на развертывание виртуальной машины. Для этого можно либо выбрать доступный каталог и нажать на «Create Request».
Либо просто щелкнуть дважды мышкой на нужном каталоге. В обоих случаях появится форма создания запроса:
Жмем Next:
Здесь мы можем выбрать доступный нам vDC и время развертывания виртуальной машины (можно запланировать нужное нам время). Говорим, что хотим развернуть машину right now и жмем Next.
Я хочу получить виртуалку с 2-мя vCPU, 4-мя гигами оперативки и 16 Гб vHDD. Задаю нужные параметры, как показано на рисунке выше. И жму Next.
Кастомных workflow мы к нашему шаблону пока не привязали, поэтому просто жмем Next.
На этом создание запроса завершено, можно просмотреть сводку и нажать Submit
Статус Service Request’а
Безусловно нам будет интересно следить за ходом выполнения нашей заявки. На портале самообслуживания UCSD есть удобный интерфейс для просмотра статуса и логов выполнения запроса.
Нам нужно перейти на страницу портала, которая называется «Services» и выбрать нужный нам запрос из списка:
Для просмотра деталей либо кликаем два раза мышкой на нужный запрос, либо жмем «View Details»:
Мы видим этапы выполнения запроса и их текущий статус. Что выполнено, что выполняется, какие результаты.
Все этапы нашего запроса выполнились успешно. Итог – новая виртуальная машина.
На этом я закончу рассказ о функционале UCSD в области «провижининга» виртуальных машин и портале самообслуживания. Спасибо тем, кто дочитал до конца, надеюсь, пост будет полезен для тех, кто начинает знакомиться с продуктом.
RSS
