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

    Ð¡Ð¾Ð·Ð´Ð°Ð½Ð¸Ðµ виртуальной машины 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, etc);
  •  
  • Дозволяє задавати додаткові політики для дисків — вибір типу диска: 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.  
  3. Зверніть увагу на групу, яку ми задаємо для користувача. Це та сама група, яку ми вказали при створенні vDC та каталогу. Власне за рахунок прив'язки нашого користувача до потрібної групи ми даємо йому можливість користуватися створеним нами каталогом (іншими словами отримувати послугу).
  4.  
 
 

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 в області «провіжінінга» віртуальних машин і порталі самообслуговування. Дякуємо тим, хто дочитав до кінця, сподіваюся, пост буде корисний для тих, хто починає знайомитися з продуктом.
    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.