I denne artikkelen skal vi se på Service Management Automation (SMA) som er en ny komponent i System Center for automatisering av prosesser.
Før vi ser på de tekniske detaljene, la oss se på hvilke bruksområder et automatiseringsprodukt som SMA har:
- Automatisere vedlikeholdsoppgaver som patching av clustre, stopp og start av tjenester i riktig rekkefølge samt nedkjøring og oppstart av virtuelle maskiner i riktig rekkefølge i forbindelse med planlagt vedlikehold.
- Automatisere forretningsprosesser som opprettelse, endring og avvikling av brukere, resetting av passord og automatisering av filoverføringer.
- Automatisering av oppgaver i tjenestekatalog og endringshåndtering som opprettelse av virtuelle servere og automatisk konfigurasjon av backup.
- Dynamisk ressurs-allokering basert på for eksempel last eller kalender. Et praktisk eksempel på dette kan være å utvide en webfarm med flere servere før en høysesong som julehandel.
- Respondere på overvåkingsalarmer fra for eksempel System Center Operations Manager.
- Integrasjoner på tvers av systemer, eksempelvis at det basert på en hendelse i overvåkingssystemet automatisk genereres en sak i et saksbehandlingssystem.
SMA er ikke en egen komponent i System Center porteføljen på lik linje med de andre produktene, installasjonsfilene er inkludert i installasjonsmediet for System Center Orchestrator:
Som man ser på skjermbildet består SMA av 3 komponenter:
Runbook Worker– Utfører runbook jobber. Disse kan enten være schedulert eller startes manuelt.
PowerShell Module– Cmdlets for å administrere SMA.
Web Service– Web API (REST OData) som blant annet brukes for å kommunisere med Windows Azure Pack, distribuere runbook-jobber til runbook workers og for å delegere tilganger.
I tillegg vil man behøve en SQL-database hvor data lagres (angis under installasjon).
Arktitektur-messig er det likheter mellom System Center Orchstrator (SCO) og Service Management Automation (SMA). Hovedforskjellen i brukeropplevelsen er at definering av runbooks i SCO er grafisk med støtte for drag and drop, mens det i SMA er 100% basert på Windows PowerShell Workflow.
PowerShell Workflow ble introdusert i PowerShell 3.0 og er basert på Windows Workflow Foundation. Med PowerShell Workflow får man mulighet for å orkestrere aktiviteter som kjører over lengre tid som til sammen kan utføre komplekse oppgaver, eksempelvis utrulling av en tjeneste bestående av flere servere. PowerShell Workflow har egenskaper som det å kunne kjøre aktiviteter parallelt, det å kunne fortsette etter en feil (for eksempel brudd på nettverksforbindelse) og fortsette kjøring etter restart av en maskin. Detaljert info og linker til mer informasjon til PowerShell Workflow finner du i artikkelen «When Windows PowerShell Met Workflow» på Windows PowerShell Teamet`s blog.
Portal
SMA i seg selv har ingen innebygd portal, den eneste muligheten for å definere runbooks er via PowerShell modulen eller web servicen. Windows Azure Pack for Windows Server er en gratis komponent for Microsoft-kunder som gjør det mulig å tilby selvbetjening for store miljøer og hostingselskaper i en portal som er konsistent med opplevelsen man får i Windows Azure:
En av komponentene i Windows Azure Pack er Automation, som bygger på en kobling til webservicen i SMA. Man kan dermed bruke Automation-komponenten i Windows Azure Pack som en webportal for SMA:
Dashboard gir en samlet oversikt over status på alle runbooks.
Runbooks gir en oversikt over alle definerte runbooks hvor man kan sortere på status, tags eller søke opp en runbook basert på navn:
Går man inn på en valgt runbook får man opp et eget dashboard med status på jobber for den aktuelle runbooken:
Under Author har man mulighet til å se den publiserte utgaven av runbooken:
Under Draft kan man editere og teste koden:
Øverst ser man at keyword for PowerShell Workflow er definert etterfulgt av navnet på runbooken. Deretter kan man valgfritt angi parametre etterfulgt av selve PowerShell koden.
Velger man å angi parametre vil man kunne angi verdier for disse parametrene når man starter runbooken:
Verdier for parametrene kan også angis om man velger å schedulere en runbook. Schedulering legges inn under Schedule:
Under Configure kan man legge inn beskrivelse, tags og aktivere logging:
Logging medfører mye ekstra data i databasen, og bør kun aktiveres i forbindelse med feilsøking.
Det siste valget på en runbook er Jobs hvor man kan se historikk og gå inn og se output fra hver enkelt jobb:
Det siste vi skal se på i Automation portalen i Windows Azure Pack er Assets:
En Asset kan være PowerShell moduler eller en av følgende:
Connections er forbindelser til andre systemer, for eksempel til andre System Center produkter som Virtual Machine Manager og DPM. Credentials kan legges inn globalt for å unngå å hardkode de i runbooks, det samme gjelder variabler. Den siste typen asset er schedules som vi har sett på tidligere.
Arktitektur
Når PowerShell Workflow brukes standalone vil status på aktiviteter («persistence») lagres til disk på maskinen workflowen eksekveres fra. Ved hjelp av SMA får man en høytilgjengelig PowerShell Workflow, siden persistence lagres i SQL-databasen.
Det er dermed mulig å konfigurere en høytilgjengelig automatiseringsplattform ved å sette opp en høytilgjengelig SQL-tjeneste (clustering eller AlwaysOn) samt 2 eller flere servere hvor SMA-rollene Runbook Worker og Webservice installeres:
Illustrasjon hentet fra System Center Orchestrator Engineering Team Blog
Oppsummering
Siden SMA er basert på PowerShell Workflow er det mulig å automatisere alt som kan utføres med PowerShell. I motsetning til Orchestrator som kan utvides ved å installere såkalte Integration Packs kan SMA utvides ved å legge til PowerShell moduler. Dagens utgave av SMA er første versjon av produktet og mangler en del funksjonalitet man finner i Orchestrator, slik som muligheten til å sette rettigheter på runbooks. Dette er noe som er ønskelig når man vil tilby for eksempel systemeiere muligheten til å kjøre kun de runbooks de er delegert rettigheter til. Det er ikke uttalt noe offisielt i forhold til hva strategien rundt Orchestraor og SMA er for fremtiden, men det er ikke utenkelig at SMA på sikt vil ta over for Orchestrator når flere funksjoner kommer på plass.
Ressurser
Overview of Service Management Automation
Windows Azure Pack for Windows Server
Getting Started with Windows PowerShell Workflow