Aanvullend op het verslag van de Private Cloud Launch Event: Microsoft heeft de presentaties en de foto’s van die dag online beschikbaar gemaakt.
Kevin McCuistion en Matt McSpirit geven een presentatie over de meerwaarde van SystemCenter 2012
Afgelopen woensdag was in Fort Voordorp te Groenekan de Microsoft Private Cloud Launch Event. Een bijeenkomst, georganiseerd door Microsoft, om zowel System Center 2012 als Windows Server 2012 voor te stellen aan IT professionals.
Op deze prachtige dag was er naast de promotie- en netwerkmogelijkheden natuurlijk ook veel aandacht voor de techniek zelf.
De nadruk van de meeste presentaties ging over integratie. Voor Microsoft zelf betekent dat natuurlijk dat alle verschillende producten van System Center 2012 elkaar kunnen aanvullen. Dit is ook te zien in de nieuwe, versimpelde, licensing-voorwaarden, waar je geen licenties voor de losse producten betaalt, maar alle producten van de suite onder 1 licentie kunt inzetten.
Natuurlijk was er ook veel aandacht voor de “BYOD”-trend. Kon men bij de IT-afdeling vroeger vanuit gaan dat alle elektronische apparaten op het netwerk door hun beheerd werden, brengen werknemers tegenwoordig steeds vaker hun smartphones, tablets of zelfs laptops mee naar het werk.
Geen wolkje aan de lucht op de lokatie in Fort Voordorp. Maar wel volop aandacht voor de Cloud.
Opvallend was dan ook dat, mede door deze trend, de integratie en ondersteuning van concurrerende technologie niet gemeden wordt. Hoewel Microsoft bijvoorbeeld duidelijk erg sterk inzet op de eigen virtualisatie-technologie, Hyper-V, is er meer dan voldoende ondersteuning voor ESX, van concurrent VMWare.
Een spil bij deze integratie van producten is natuurlijk System Center Orchestrator 2012.
Waar de andere producten heel duidelijk hun eigen rol hebben en in principe nog steeds stand-alone kunnen worden gebruikt is Orchestrator de motor, of misschien beter gezegd, het brein van System Center.
Het belang van Orchestrator, zo benadrukte Kevin McCuistion van Microsoft, is dat het zonder problemen ook processen op Linux, XenApp, VMWare of zelfs webbased platformen kan begeleiden.
Hierdoor werd duidelijk dat voor Microsoft de aanschaf en ontwikkeling van Orchestrator een strategische keuze is. Ook op de langere termijn zien zij dat het steeds belangrijker wordt om meer controle op infrastructuur en processen te krijgen, waarvoor zij in Orchestrator de belangrijkste tool zien.
Voor de meeste Runbooks geldt dat ze volautomatisch draaien. Ze worden opgestart volgens een vast schema of reageren op een specifieke monitoringswaarde of ander startevenement. Een andere mogelijkheid is dat Runbooks worden aangeroepen als onderdeel van andere Runbooks.
In een goed ingerichte omgeving haal je juist door deze automatisering het meeste voordeel uit Orchestrator. Toch zal zelfs in de meest robuuste omgeving het soms nodig zijn om ‘met de hand’ Runbooks te bekijken en te stoppen of juist weer te starten. Ook in ontwikkelomgevingen en tijdens acceptatietesten zal met enige regelmaat handmatig beheer noodzakelijk zijn.
Binnen praktisch iedere organsiatie is er een strikt beleid op toegang tot de servers zelf. Daarom is er voor beheerders en ontwikkelaars beheertoegang mogelijk gemaakt via de Orchestration Console. Dit is een webgebaseerde interface, te benaderen met de browser. Omdat de Orchestration doorgaans bedrijfskritische processen aanstuurt, is het van belang om over de veiligheid hiervan na te denken.
De Orchestration Console zoals bezien door de browser
Omdat de Orchestration Console via de browser te benaderen, is het dus primair zaak om deze website te beveiligen in overeenstemming met het bedrijfsbeleid voor informatiebeveiliging. Zo moet toegang van buiten het bedrijfsnetwerk voorkomen worden en bijvoorbeeld alleen via VPN of andere beveiligingsoplossingen mogelijk zijn.
Om de Runbooks zelf te beschermen kan gebruik gemaakt worden van permissies. Naast het Orchestrator Service-account is er ook de Orchestator Users Group. Deze groep heeft standaard volledige permissies op alle Runbooks. Bij grotere organisaties is een enkele groep onvoldoende granulair. Ontwikkelaars mogen bijvoorbeeld wel toegang hebben tot de ene set van Runbooks, maar niet tot de andere. De ene beheerder hoeft alleen maar een Runbook te kunnen stoppen en starten, een ander zal er ook wijzigingen aan mogen maken.
Binnen de Runbook Designer is het daarom mogelijk om gebruik te maken van permissies.
De rode pijl wijst aan waar je de instelling voor permissies kunt wijzigen
Deze permissies hebben de volgende uitwerking.
Deze permissies integreren natuurlijk met lokale of Active Directory-groepen. Zo kun je bijvoorbeeld een Read-only groep voor beheerders maken en een of meerdere Read-Write groepen voor ontwikkelaars.
Daarnaast speelt natuurlijk de vraag, onder welke accounts de Runbooks zelf worden uitgevoerd en welke rechten ze nodig hebben voor het uitvoeren van hun taken. Dit zal behandeld worden in een toekomstige blogpost!
Wanneer we advies uitbrengen voor klanten maken we praktisch altijd gebruik van procesvisualisaties. Dat zijn plaatjes die helpen om de processen van een bedrijf inzichtelijk te maken. De tekentechniek die we hiervoor gebruiken is BPMN, Business Process Model and Notation.
Deze methode helpt om op basis van een aantal basiselementen een goed overzicht te krijgen van alle stappen van een proces en op welke plek beslissingen worden genomen. De methode is flexibel genoeg om zowel op operationeel niveau alle details te kunnen modelleren, als ook om op strategisch niveau een helikopterview te kunnen geven.
Een BPMN-schema van het deployen (installeren) van een in een WAR-bestand verpakte Java/Tomcat applicatie. (Klik voor volledig formaat)
Het voorbeeld toont het proces dat hoort bij het uitbrengen van een nieuwe release van een webapplicatie door een hostingbedrijf. Tussen de verschillende stappen is er telkens communicatie met de klant die goedkeuring moet geven over de resultaten.
Bij het opstellen van dit proces waren alle stappen uit dit proces handmatig. Controle van de nieuw opgeleverde versie, het installeren en het communiceren met de klant was allemaal (duur) werk van specialisten.
Het voordeel van het in kaart brengen van zo’n proces is dat je hiermee al de eerste stap naar het automatiseren van het proces hebt gedaan.
Dit kan bijvoorbeeld met Orchestrator.
Een Orchestratro 2012 Runbook voor het deployment-proces. (Klik voor groter formaat)
Het BPMN-schema is nog duidelijk herkenbaar. De communicatie met de klant is vervangen door een object dat zich herhaalt en op feedback wacht. Bij ontvangst van een bevestiging wordt pas naar de volgende stap doorgegaan.
Hoewel in dit voorbeeld het hele proces geautomatiseerd is, zal dat niet altijd mogelijk zijn. Voor meer complexe releases zijn er bijvoorbeeld telkens gewijzigde aanvullende instructies. Een specialist zal die dan moeten uitvoeren.
Daarnaast is het aan te bevelen om het Runbook op te delen in kleinere onderdelen. Deze kunnen dan afhankelijk van de omstandigheden los worden aangeroepen door een overkoepelend Runbook. In de praktijk zullen met name de stappen tussen de twee goedkeuringsmomenten als los Runbook worden ingericht.
In een blog post gaat het wat te ver om alle implementatiedetails te bespreken. De essentie is dat het in kaart brengen van het proces en dit vervolgens te automatiseren, duidelijk een tijdsbesparing oplevert en daarmee de kosten drukt. Een specialist zal hierdoor zich niet meer met de standaard activiteiten bezig houden maar kan zich richten op verstoringen, aanvullende instructies en uitzonderingssituaties.