Inleiding

Met Cisco UCS Director (USCD) worden infrastructuurtaken niet meer dan het starten van een workflow. Het automatisch uitrollen van ESXi op een UCS platform is een van deze taken. UCSD heeft een standaard workflow voor het uitrollen van een besturingssysteem, maar enkele aanpassingen zijn nodig om ESXi uit te rollen via deze workflow. Hier kwam ik achter toen ik zelf een workflow aan het maken was om ESXi automatisch uit te rollen. Deze blog beschrijft de werking van de automatische uitrol van ESXi via UCSD en de wijzigingen die ik heb aangebracht. Overigens is mijn oplossing zeker niet de enige mogelijkheid. Deze blog geeft vooral inzicht in de werking zodat je zelf de juiste aanpassingen kunt maken afhankelijk van je eisen en de wensen. Ik ga in deze blog uit van de volgende uitgangspunten:
  • Er is een werkend UCS platform beschikbaar met een serverpool met beschikbare servers
  • UCSD is beschikbaar, inclusief de Bare Metal Agent (ik ga uit van versie 6 van UCSD, maar eerdere versies zijn ook mogelijk, zie USCD BMA Install Guide 6)
  • De ESXi image (versie 5 of hoger) is op de standaard manier toegevoegd aan de Bare Metal Agent (zie UCSD BMA Config Guide 6)Er is een apart PXE Boot VLAN aanwezig
  • In UCS Manager is een service profile aangemaakt met daarin tenminste twee vNIC’s, het vNIC PXE (met een native VLAN voor het PXE boot netwerk) en het vNIC Management (met een VLAN voor beheer van ESXi) en een boot order policy die als eerste van LAN boot
  • Er wordt een kloon gemaakt van de standaard workflow UCSM Bare Metal Provisioning en de kloon wordt aangepast

Werking op hoofdlijnen

In essentie is de uitrol van ESXi op een UCS Platform met UCSD een automatische installatie van ESXi m.b.v. een PXE Boot installatie die bestuurd wordt door een workflow in UCSD en de Bare Metal Agent (BMA). De BMA is een virtuele appliance waarop een DHCP, PXE en TFTP service draait en waarop de ESXi image en een kickstart template staan. Deze kickstart template vormt de basis voor de ESXi installatie. Met behulp van een workflow en een service profile wordt de server tijdelijk in het PXE VLAN geplaatst. Daarna wordt er een kickstart script gegenereerd aan de hand van de kickstart template. Hierbij worden alle variabelen in de kickstart template vervangen door de juiste waarden voor het succesvol uitvoeren van de ESXi installatie door deze specifieke workflow. De UCSD ESXi installatie workflow stuurt in belangrijke mate het ESXi installatieproces. De aangepaste workflow is weergegeven in figuur 1. Hierin zijn de taken 5 en 11 toegevoegd t.o.v. de originele workflow UCSM Bare Metal Provisioning. De overige taken zijn de taken van de originele workflow. [caption id="attachment_5299" align="alignnone" width="350"] Figuur 1: de ESXi installatie workflow[/caption] Het doel van de verschillende taken is als volgt:
  1. Bare Metal Provisioning Wrapper: het ophalen van alle relevante informatie zoals gespecificeerd in de Bare Metal Server Provisioning Policy (zie ook paragraaf configuratie)
  2. Select UCS Server: het selecteren van een server uit de server pool zonder associated service profile
  3. Create UCS Service Profile from template: het maken van een service profile, uitgaande van een service profile template; de naam van het service profile wordt opgegeven bij de start van de workflow
  4. Unbind UCS Service Profile from Template: het unbinden van het service profile omdat later in het proces aanpassingen gemaakt worden aan het service profile (dat kan alleen als het service profile geen bind meer heeft met de service profile template)
  5. Associate UCS Service Profile: associate van het service profile aan de geselecteerde server
  6. Setup PXE Boot (OS Type: xxx ): het opzetten van het PXE Boot request, uitgaande van de Image Catalog Name van de ESXi image
  7. UCS Blade Power ON Action: het aanzetten van de geselecteerde server, zodat het PXE boot proces kan starten
  8. Monitor PXE Boot: op dit moment is de besturing niet meer in handen van de workflow; de workflow stopt totdat het een trigger krijgt dat het PXE boot process afgerond is
  9. Modify UCS Service Profile Boot Policy: het aanpassen van de Boot Policy, zodat er niet meer van network geboot wordt, maar van het device waarop ESXi geïnstalleerd is
  10. Delete vNIC from Service Profile: verwijderen van de PXE vNIC, omdat deze niet meer nodig is
  11. UCS Blade Power ON Action: het wederom aanzetten van de server met het aangepaste service profile; na opstarten is de server gereed als ESXi host
  12. Assign Service Profile to Group: assign user group aan het service profile

Configuratie

Om de UCSD ESXi installatie workflow te laten werken, heb ik de volgende onderdelen geconfigureerd of aangepast:
  1. Bare Metal Server Provisioning policy in UCSD
  2. Boot Policy om vanaf het device te booten waarop ESXi wordt geïnstalleerd in UCS Manager
  3. Kickstart template in de BMA

Bare Metal Server Provisioning policy

In UCSD kan een Bare Metal Server Provisioning policy aangemaakt worden via menu optie Policies -> Physical Infrastructure Policies -> Bare Metal Servers. Voeg hierna een nieuwe policy toe of pas een bestaande policy aan. Figuur 2 geeft aan welke parameters ingevuld moeten worden. [caption id="attachment_5320" align="alignnone" width="500"] Figuur 2: parameters Bare Metal Server Provisioning policy[/caption]   De betekenis van de verschillende parameters is als volgt:
  • Accountname: de accountname van de fabric waarop de servers die gebruikt worden voor de installatie aangesloten zijn
  • Server selection: selectie van de servers die geselecteerd mogen worden tijdens het PXE Boot proces
  • Server Pools: de server pools die gebruikt mogen worden
  • Service Profile Template: het service profile template waarvan een service profile gemaakt worden die geassocieerd wordt aan de geselecteerde server
  • Target BMA: De BMA (Bare Metal Agent) die gebruikt moet worden
  • OS Image Selection: de ESXi image die aan de geselecteerde BMA is toegevoegd
  • Network Management: netwerkgegevens van het ESXi management netwerk, waarbij bij Server IP Address een pool van IP adressen ingevuld wordt; elke keer als een nieuwe server via de workflow uitgerold wordt, wordt een nieuw adres uit de pool gehaald (dit adres wordt weer vrijgegeven als de service request teruggerold wordt).
  • System Parameters: gegevens voor de ESXi host, waarbij voor Server Host Name ook UCSD parameters gebruikt kunnen worden (zoals in dit voorbeeld het service request ID)
De bare metal server provisioning policy wordt vervolgens gekoppeld aan taak 2 van de UCSD workflow zoals weergegeven in figuur 3. [caption id="attachment_5321" align="alignnone" width="600"] Figuur 3: koppelen bare metal server provisioning policy aan de UCSD workflow[/caption]

Boot Policy

Maak in UCS Manager een boot policy aan waarvan het eerste boot device het device is waarop ESXi geïnstalleerd is tijdens het PXE Boot proces. Koppel deze policy vervolgens aan taak 10 van de UCS workflow, zoals weergegeven in figuur 4. [caption id="attachment_5322" align="alignnone" width="600"] Figuur 4: koppelen boot order policy aan de UCSD workflow[/caption]

Kickstart template in de BMA

In taak 9 van de UCSD workflow (zie figuur 1) ligt de besturing van de uitrol niet bij de UCSD workflow, maar bij het kickstart script dat gestart wordt door het PXE Boot proces. De workflow gaat weer verder zodra er een wget request gestuurd wordt naar http://$PXE_WEBSERVER_MGMT_VLAN_IP/$PXEID/notify.html. Hierbij is $PXE_WEBSERVER_MGMT_VLAN_IP het IP adres van de BMA op de management interface en $PXEID het PXE ID dat de workflow heeft gegenereerd. Tijdens het toevoegen van de ESXi image aan de BMA wordt een standaard kickstart template gegenereerd. Deze template is op de BMA te vinden in /opt/cnsaroot/<image name>. De kickstart template heeft de volgende structuur: <installatie commando’s> %pre --interpreter=busybox <commando’s voordat de installatie gestart is> %firstboot --interpreter=busybox <commando’s die uitgevoerd worden bij de eerste boot van ESXi; hostd is dan operationeel, zodat alle esxi shellcommando’s gebruikt kunnen worden> %post --interpreter=busybox --ignorefailure=true <commando’s die uitgevoerd worden nadat de installatie uitgevoerd is, maar voordat ESXi boot; hostd is dan niet operationeel, waardoor esxcli commando’s niet werken; gebruik in plaats daarvan localcli commando’s> De volgende regels moeten toegevoegd worden aan de %post sectie; waarbij ervan uit gegaan wordt dat de PXE vNIC gekoppeld is aan uplink vmnic4 en de Management vNIC gekoppeld is aan uplink vmnic0 . Dit is uiteraard aanpasbaar. ############################### # Change vSwitch config ############################### localcli network vswitch standard uplink add --uplink-name=vmnic0 --vswitch-name=vSwitch0 localcli network vswitch standard uplink remove --uplink-name=vmnic4 --vswitch-name=vSwitch0 Waarom zijn deze regels nodig? Bij de PXE boot wordt de vNIC van het PXE Boot VLAN gekoppeld aan de vSwitch. Echter, tijdens de installatiefase krijgt de management vmkernel port een IP adres uit het management subnet. Dit betekent dat het commando wget http://$PXE_WEBSERVER_MGMT_VLAN_IP/$PXEID/notify.html dat daarna volgt in het kickstart script niet werkt over de vNIC van het PXE VLAN (tenzij op deze vNIC ook het management VLAN is toegevoegd; dat is een alternatief). Door op de vSwitch de vNIC van het PXE VLAN te verwijderen en de vNIC van het management VLAN toe te voegen, werkt het wget request en loopt de workflow door als de installatie van ESXi voltooid is. Daarnaast dient er aan de %firstboot sectie nogmaals de regel: localcli network vswitch standard uplink add --uplink-name=vmnic0 --vswitch-name=vSwitch0 toegevoegd te worden. Uit mijn praktijktest blijkt dat anders vmnic0 niet gekoppeld wordt aan de uplink tijdens de eerste boot. Een ander aandachtspunt is de keuze van de installatiedisk. Standaard staat in het kickstart script de regel: install --firstdisk –overwritevmfs Als de installatie niet op de eerste disk geplaatst moet worden, dient dit als volgt aangepast te worden (waarbij de disk een voorbeeld is): install --disk="mpx.vmhba32:C0:T0:L0" –overwritevmfs

Conclusie

Het automatisch uitrollen van ESXi is eenvoudig realiseerbaar met UCSD. De standaard aanwezige workflow en kickstart template hebben slechts minimale aanpassingen nodig om tot een werkend geheel te komen. Deze aanpassingen zijn specifiek voor een gegeven infrastructuur en zullen in het ontwerp meegenomen moeten worden. Uiteraard is de hier beschreven oplossing niet de enige. Er zijn meer oplossingen mogelijk die steeds eenvoudig met UCSD te implementeren zijn. Daarnaast kan deze workflow verder uitgebreid worden. In de %firstboot sectie van het kickstart script kan ESXi bijvoorbeeld verder geconfigureerd worden. Of de ESXi host kan na installatie automatisch aan een cluster in vCenter toegevoegd worden. De mogelijkheden zijn eindeloos en kunnen eenvoudig toegespitst worden aan een specifieke situatie door slim toepassen van automation en orchestration met behulp van UCSD.