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.
De hoofdinsteek van Microsoft System Center is traditioneel gericht op het beheren van de infrastructuur van IT omgevingen. Tools zoals de Configuration Manager, Endpoint Protection en Data Protection Manager zijn daar op gericht.
In System Center 2012 is er een duidelijke verschuiving zichtbaar richting functionaliteiten voor “de cloud”. Dit is om aansluiting te houden bij de ontwikkelingen in het veld.
Een van de belangrijkste nieuwe tools is Orchestrator (voorheen Opalis), die gebruikt kan worden als spin in het web voor het automatiseren van een datacenter.
In een eerdere blog post is al ingegaan op het onderwerp orchestratie, nu zal ik vooral in gaan op de kracht van Orchestrator en hoe het product zich verhoud tot de rest van de System Center Suite.
De interactie tussen Orchestrator en de overige onderdelen werkt twee kanten op. Zo kan Operations Manager met behulp van het specifieke Management Pack ingericht worden om de werking van de Orchestrator te monitoren.
Nog veel krachtiger zijn de Integration Packs die voor Orchestrator beschikbaar zijn. Deze Integration Packs bieden een gemakkelijke manier om met, standaard objecten binnen Orchestrator, API’s en andere functionaliteiten van de System Center Tools te communiceren.
Het eindresultaat kan een verregaand geautomatiseerde en schalende omgeving zijn. De Orchestratie voegt extra intelligentie aan de processen van het Datacenter toe.
Bij moderne toepassingen zijn vaak meerdere applicaties betrokken. Een webplatform bestaat meestal uit meerdere webservers, applicatieservers en databaseservers. Op basis van informatie uit Operations Manager kan bijvoorbeeld het signaal komen dat (op basis van een business rule) een omgeving opgeschaald moet worden.
Door een Runbook in Orchestrator in te richten kan dit signaal geautomatiseerd opgepakt worden, of kan zelfs de business logica in Orchestrator geconfigureerd worden. Met behulp van Integration Packs kunnen zo geautomatiseerd extra VM’s (met VMM) worden aangemaakt en daarnaast van de juiste configuraties worden voorzien inclusief de benodigde software. Tegelijkertijd kan ook de reguliere monitoring geregeld worden.
In bovenstaande weergave zijn de interacties gesimplificeerd weergegeven. Binnen het Datacenter wordt gebruik gemaakt van de tools van System Center. Operations Manager, Orchestrator en Service Manager zijn er voor het gemak even uitgelicht en uitvergroot om de verhouding tussen de producten goed weer te kunnen geven.
Vanuit het Datacenter wordt continue status informatie doorgegeven aan Operations Manager. De Operations Manager vertaalt deze informatie, zoals belasting van webservers naar een event (“te hoge belasting”) en geeft dit vervolgens door aan Orchestrator als signaal. Op basis van de geconfigureerde business logic bepaalt een Orchestrator Runbook hoeveel webservers er bijgeschakeld moeten worden en stuurt deze opdrachten naar Virtual Machine Manager in het Datacenter en controleert of dit daadwerkelijk uitgevoerd wordt.
Interessant is dat Orchestrator zelf ook status informatie ontvangt en daardoor intelligentie in de opdrachten kan stoppen. Zo kunnen de precondities gecontroleerd worden voor het succesvol uitvoeren van een actie: is er bijvoorbeeld wel voldoende capaciteit op storage aanwezig op een host? Zo niet, dan zal er eerst extra storage geprovisioned moeten worden. Zo kan Orchestrator het gehele proces end-to-end controleren en begeleiden.
Orchestrator is niet alleen intern op het DataCenter gericht, maar kan ook communiceren met externe bronnen. Een voorbeeld is dat een incident van Service Manager gelogd kan worden, maar ook (aangegeven met de gestippelde lijnen) kan interacteren met overige niet-infrastructurele bronnen. Hierbij kun je denken aan het toevoegen van extra informatie op basis van de business logic om de juiste prioriteit aan een incident te geven. Een ander voorbeeld is het doorgeven van de procesvoortgang of het versturen van een rapportage naar de verantwoordelijke leidinggevende.
Als laatste vind ik het belangrijk om te melden dat het toevoegen van krachtige Orchestratie en intelligentie niet betekent dat de beheerder buitenspel komt te staan. In tegendeel! Hij of zij gaat juist een centrale rol vervullen. Niet als procesuitvoerder maar als proces designer en bewaker. Op deze manier kan een beheerder veel effectiever en efficiënter zijn werk uitvoeren.
De kracht van System Center Orchestrator komt voort uit de vele beschikbare objecten die standaard aanwezig zijn. Met deze objecten hun je bijvoorbeeld gegevens uit een database halen, een webservice aanspreken, of een programma opstarten. Deze standaardobjecten zijn geschikt voor alle denkbare processen. Om het aantal stappen in een proces terug te brengen, kun je custom objecten bouwen.
Voor eenvoudige handelingen is het vaak handiger om het standaard object binnen Orchestrator te gebruiken. Hiermee kan een maatwerk .NET library aangesproken worden of een PowerShell script.
Wanneer een specifiek programma in veel verschillende processen terugkomt, is het verstandig om hiervoor een custom object aan te maken, zodat het eenvoudig hergebruikt kan worden.
Soms heeft een fabrikant van third-party software zelf een Integration Pack gemaakt. Voor Opalis, de voorganger van Orchestrator, zijn ruim meer dan 30 verschillende Integration Packs beschikbaar.
Voor System Center is er ook een groeiende verzameling beschikbaar. Microsoft geeft zelf het goede voorbeeld door Integration Packs te bouwen voor alle producten binnen de System Center Suite, Active Directory en VMware. Deze zijn op System Center Central te downloaden.
Wanneer er geen standaard Integration Pack beschikbaar is, kun je gebruik maken van de Orchestrator Integration Toolkit. De basis hiervan zijn twee wizards. De Commandline Activity Wizard, die van commandline-opdrachten een .net-dynamic link library maakt. En de Orchestrator Integration Pack wizard. Op basis van methoden uit een .net-dll (zoals gegenereerd door de Commandline Wizard) maakt deze wizard System Center Orchestrator objecten.
Het is wel belangrijk om de limieten van de Wizards te erkennen. Het is primair een mogelijkhed om een API of commandline aan te spreken. De kwaliteit van de output en mogelijkheden tot verwerking ervan hangen in grote mate af van de software zelf.
In de praktijk betekent dit dat bij inzet van custom objecten altijd een afweging gemaakt moet worden waarin het beste geïnvesteerd kan worden: Configureerwerk in de Orchestratie of maatwerk in .NET zodat met weinig configureerwerk krachtige acties kunnen plaatsvinden.
Voor het plannen van het aantal Runbook Servers binnen een System Center Orchestrator omgeving bestaan verschillende richtlijnen. Standaard heeft Microsoft dit erg conservatief ingesteld op maximaal 50 actieve Runbooks per Runbook Server.
http://technet.microsoft.com/en-us/library/hh420378.aspx
De basis van de beperking ligt in het opstarten van PolicyModule.exe. Dit proces is al eerder aan bod gekomen in een vorig blog. Voor een goede capaciteitsplanning is het dus van belang om dit proces goed te begrijpen.
Een voorbeeld runbook.
Ter illustratie: We hebben een Runbook voor batchverwerking van adressen. Het Runbook controleert iedere 5 minuten een fileshare, of er een tekstbestand met adressen is aangeleverd. Deze worden vervolgens verwerkt tot een Excel-file die per e-mail wordt doorgestuurd.
Bij het (her)starten van de Runbook Service wordt onmiddelijk een PolicyModule.exe-proces opgestart. Dit proces monitort de aangegeven fileshare op aanwezigheid van het bestand.
Zodra het bestand is aangeleverd, wordt er eerst een tweede PolicyModule.exe-proces gestart, dat de directory opnieuw gaat monitoren (te beginnen op het volgende interval), terwijl het oorspronkelijke proces de workflow zal doorlopen om uiteindelijk de e-mail met Excel-file te versturen en daarna te termineren.
Zolang de verwerking uit het voorbeeld loopt, zijn er dus 2 processen actief voor het uitvoeren van dit specifieke Runbook. Beide processen tellen mee tegen de eerder genoemde limiet van 50. Eigenlijk is de limiet dus niet het aantal Runbooks, maar het aantal draaiende PolicyModule.exe-processen!
Voor capaciteitsplanning is het dus ook van belang te weten hoe lang een Runbook doorgaans doet over zijn uitvoering. Runbooks met een hoge frequentie van monitoring en een lange doorloop in uitvoering zorgen ervoor dat je sneller tegen de maximumlimieten aanloopt.
En het is ook van belang wanneer een Runbook andere Runbooks aanroept. Immers, zolang een Runbook wacht op terugkoppeling, zal het proces blijven draaien.
Tenzij je er zeker van bent dat monitorende Runbooks niet tegelijkertijd met elkaar draaien, is het dus van belang om niet meer dan de helft van de limiet van je runbooks aan monitor-events te koppelen. Een mogelijke work-around is om niet ieder runbook een eigen monitor te geven, maar om een enkel monitor-runbook de verschillende runbooks als ad hoc proces op te laten starten. Hiermee bespaar je een flink aantal processen aan overhead.
Overigens is de limiet van 50 processen geen keiharde, maar kan je deze met de hand aanpassen. Lees hiervoor de instructies van Technet.
Naast de high level componenten is er ook een uitvoerende component binnen de System Center Orchestrator 2012. Deze rol wordt vervuld door zogenaamde Runbook Servers. Door hun functie hebben ze een wat bijzondere positie binnen de architectuur. Zij vormen namelijk de interface met bijvoorbeeld databases en fileshares. Daarnaast zorgen ze er voor dat programma’s starten of data gemuteerd wordt. Het regelen van toegang vanuit de RunBook Servers naar deze resources is van vitaal belang!
De complete architectuur. In deze post wordt ingegaan op de Runbook Servers, aangegeven met de rode pijl.
Vanwege de belangrijke rol binnen de architectuur is het dus goed om te weten hoe een Runbook Server zelf zijn taak uitvoert.
Op de server draaien twee Orchestrator-gerelateerde processen: de “OrchestratorRemotingService” en de “Runbook Service”. De Remoting Service handelt communicatie met de Management Server af. De Runbook Service zorgt er voor dat de Runbooks daadwerkelijk draaien op de desbetreffende machine.
Een belangrijk punt hier is dat de Runbook Service geen communicatie heeft met de Management Server, maar direct met de Orchestrator-database. Daarom moet een Runbook Server op de juiste poorten toegang krijgen tot de Orchestrator database (Standaard SQL Server poort is TCP 1433). Binnen een lokaal netwerk zal dit geen probleem opleveren, maar binnen een gedistribueerde omgeving kunnen firewalls roet in het eten gooien. Een best practice is om Runbook Servers en de Orchestrator database binnen één site van een Active Directory-domein te draaien. Op deze manier hoef je op externe firewalls alleen toegang voor resources buiten de ‘perimeter’ te regelen. Een bijkomend voordeel is dat de latency binnen een site beperkt blijft. De communicatie tussen Runbook Server en database is in principe als real-time te beschouwen.
De Runbook Service zelf voert overigens niet direct Runbooks uit. Hiervoor wordt namelijk iedere keer (onder hetzelfde user-account als de service zelf) een apart proces gestart: PolicyModule.exe. De naamgeving laat een erfenis van Opalis, de voorloper van System Center Orchestrator 2012, zien. In vorige versies werden Runbooks namelijk Policies genoemd. Het is goed mogelijk dat in een volgende versie van Orchestrator PolicyModule.exe door RunbookModule.exe vervangen wordt.
In een vervolgpost ga ik dieper in op PolicyModule.exe en de relatie met capaciteitsplanning.
Microsoft System Center Orchestrator 2012 (voorheen Opalis) is voor DB_Able een belangrijke tool om processen te automatiseren. Deze software verzorgt Orchestration services.
Maar wat is Orchestration nu precies?
Uit de Wikipedia:
“Orchestration describes the automated arrangement, coordination, and management of complex computer systems, middleware, and services.”
Deze definitie maakt al een hoop helder maar geeft nog geen uitleg over het doel van Orchestration. De kern van Orchestration is namelijk het optimaliseren en beheersen van processen binnen een bedrijf. Bij het implementeren van Orchestration wordt ook wel de uitspraak “process is king!” gehanteerd.
Wat betreft het soort proces of type business waar Orchestration wordt gebruikt, maakt geen verschil. Orchestration wordt ingezet voor verwerking van financiele gegevens, compliancy checking, prolongeren van assurantien maar ook on-boarding en formulierafhandeling.
Het is niet noodzakelijk dat processen vooraf in detail gedocumenteerd zijn, alhoewel het een implementatietraject wel makkelijker maakt. Sterker nog, dit is een voorbeeld waarin Orchestration juist kan helpen. Door te automatiseren wordt de impliciete kennis van een bedrijf juist expliciet in goed gedocumenteerde Runbooks gevat. Daarnaast garandeert Orchestration een standaard uitvoering van het proces, hoe complex het ook is! Dit is iets wat zonder Orchestration altijd kwetsbaar blijft.
![Ontvang ook applaus met goed georchestreerde processen!](http://azijn.files.wordpress.com/2012/01/a-different-kind-of-orchestration.jpg" "Orchestra")
Ontvang ook applaus met goed georchestreerde processen!
Belangrijk om te beseffen is dat Orchestration niet alleen de aftrap van processen verzorgt, maar juist ook procesbewaking. Dit vindt plaats door validatie en, wanneer nodig, door automatisch herstel. Een voorbeeld van de controle die zo’n systeem kan bieden is real-time auditing. Op ieder gewenst moment kan een auditproces starten en zullen alle benodigde databronnen worden aangesproken. Op deze manier kan een rapportage, wat normaal gesproken erg arbeidsintensief is, met één druk op de knop aangeleverd worden bij de juiste persoon.
Bij Orchestration is het de bedoeling om alle aanwezige kennis binnen een bedrijf beschikbaar te maken in een geautomiseerde context. Een goed ingerichte Orchestration-omgeving is robuust, kan omgaan met onverwachte omstandigheden en biedt op ieder moment volledige toegang tot de processen en bedrijfsdata.
Foto credit:Yeugene, CC-BY-SA, via Wikimedia Commons
Microsoft heeft onlangs de release candidate van System Center Orchestrator 2012 aangekondigd. Deze is, als onderdeel van de gehele System Center Suite, te downloaden op Technet. Een login account is vereist!
System Center Orchestrator 2012 is de opvolger van Opalis 6.3. Opalis was een zelfstandig bedrijf wat in 2009 is opgekocht door Microsoft. Het product is ontwikkeld met de focus op IT Process automation. Je ziet dit duidelijk terug in de objecten en de Integration Packs die ontwikkeld zijn. Door het gebruik van objecten hoef je niet te programmeren maar kun je alles configueren. Dit maakt de tool erg krachtig!
Orchestrator 2012 release candidate wordt geleverd met de volgende Integration Packs:
In de nieuwe versie van Orchestrator 2012 zijn een aantal zaken gewijzigd. De belangrijkste zijn:
Bij mijn volgende posts ga ik hier verder op in.
Wil je meer weten over de Orchestrator (Opalis) en mogelijke toepassingen? Lees dan mijn technet artikel: Introductie Microsoft System Center Opalis
Op www.dbable.nl staan nog meer toepassingen beschreven.
Geschreven door: Bernard Zweistra
