SCOM & SCCM PAYBACK TIME!
Det er hørt før Vores SCOM løsning støjer helt vildt med masser af irrelevante alarmer vi kan ikke se skoven for bare træer. Vi har slukket for notifikationer i SCOM, da vi bliver vækket midt om natten af alarmer. Konen er p. sur. Vores database log drev løb fuld og så stoppede ERP systemet, hvorfor opdagede vi ikke det i overvågningen? Overvågningen viser ikke tilstanden af vores forretningskritiske systemer, men en masse komponenter. Vi har ikke noget overblik.
Det er hørt før Når vi ruller arbejdspladser ud, skal vi lige rette dem lidt til efterfølgende, så de er klar til brugerne. Vi ringer til brugerne for at få deres kodeord, så vi kan logge ind og rette de sidste ting på arbejdspladsen. Nogle programmer installeres manuelt, da vi ikke har nået at lave installationspakker endnu. Vi lader nogle applikationer opdatere sig selv, da vi ikke gider at lave opdateringspakker herpå så tit. MSI formatet er rigtigt fedt, man kan jo alt. Jeg håber, at jeg får tid til at komme i dybden med det.
Hvem er vi? Microsoft Guld Partner Fokus på System Center Dyb teknisk kompetence som afsæt Erfaringer fra den rigtige verden Søren Egtved Lassen Konsulent Automation og integration 10+ års erfaring med System Center Vores edge: Tænke ud af boksen Skabe værdi Forankring
Agenda System Center Operations Manager Design og implementering Baselining / Støj Forretningsdrevet overvågning Automatisering System Center Configuration Manager Værdien af Desktop Management Klassiske tidsrøvere Repackaging Patch Management og automation Opsummering
Mål og form side 6 Dele ud af erfaringer opsamlet i SCOM og SCCM projekter Illustrere forløb og løsningsmuligheder Give praktiske eksempler Spørg gerne undervejs eller efterfølgende i pausen Advarsel: mange slides få demoer beklager
SCOM og SCCM De klassiske System Center discipliner. Har defineret System Center begrebet Største udbredelse
Overblik fra 10 Km s højde Operations Manager Server og systemovervågning Integration Konsoller Alarmering Rapportering Visualisering Configuration Manager Device Management Deployment (OS + Apps) Patch Management Asset Management Metering & Compliance Endpoint Protection
Typiske udfordringer Operations Manager Alarm støj Skalering topologi Ukomplet overvågning Tilpasning til organisation og forankring heri Configuration Manager Manuelle procedurer ~ manglende automation Inkonsistente patch management rutiner Degradering af værdi Lang leveringstid på nye softwareprodukter og versioner
System Center Operations Manager Design og implementering Topologi er afgørende for kapacitet og skalering Operations Manager 2012 løser (tidligere) udfordringer (RMS i HA) Anbefaling: Tænk multi tiering fra starten Basér overvågning på forretningskrav
System Center Operations Manager Støjkilder Manglende baselining Management Pack konfiguration Sikkerhed (RunAs Accounts/Profiles) Rigtige mænd læser ikke (MP )vejledninger Usual Suspects MPs: Windows Base OS Exchange SharePoint SQL Server
Management packs Modul indeholdende viden om overvåget teknologi Leveres af software/hardwareproducent eller 3. partsleverandør SCOM indeholder værktøjer til at udarbejde egne MPs MP Definerer: Discovery Health model Monitors og alarmer Præsentation Automation Rapporter Overrides
Mere støj Overvågning kan blive påvirket af: Patch management System vedligehold Hardware service Maintenance Mode Manuelt Automatisk f.eks. via Orchestrator
Baselining En proces hvor Operations Manager lærer it miljøet at kende Definition af normal tilstand Initiel baselining foretages typisk som en del af implementeringsprocessen Løbende baselining bør være en del af driftsvedligeholdelsen
Hvorfor baselining? VS. Non baselined Baselined
System Center Operations Manager Anbefales: Trinvis implementeringsforløb Design Installation Management Packs step 1 Baselining step 1 Management Packs step 2 Baselining step 2 Osv.
Initiel baselining Anbefalet proces Bottom up i teknologistakken Gruppér Management Packs Fejljusteringer i underliggende lag har afsmittende effekt i højere liggende lag Tålmodighed hastværk er lastværk Forretningsapplikationer Middleware Infrastruktur services Net services OS Hardware
Inden for hvert trin Opsaml alarmer over en periode Evaluer alarmer, f.eks. Relevans Grænseværdier severity Definér jeres normal tilstand Mål: 1:1 alarm:ticket ratio Tilpas alarmer: Ændring af grænseværdier Ændring af severity Deaktivering af irrelevante målinger Korrigér fejlkonfigurationer
Drift løbende baselining Ingen it installation er statisk F.eks. ændringer til: Produkter/versioner Belastningsprofiler Ændrede forretningsprocesser Forbered evt. ændringer og reagér hvis overvågningen rapporterer afvigelser
Forretningsdrevet overvågning Forretningen definerer hvad der er vigtigt Nedbrydning i systemer og komponenter er vigtig for at identificere det, der bør overvåges Top down Forretning Processer Systemer Komponenter
Hvad kan overvåges? I boksen : Windows Server OS Windows Server Apps Unix/Linux Netværk/SNMP Syslog.NET applikationsovervågning Andre (eksempler): Citrix VMware Hardware 3. parts platforme Integration imod andre overvågningsplatforme
Hvad med det andet? Templates Wizards Windows Services Windows processer Web applikationer TCP port Linux logs/processer OLE DB databaseopslag System Center Orchestrator Egne MPs: Authoring space Authoring console
System Center Orchestrator Automatiseringskomponent i System Center Tidligere kendt som Opalis Nem integration imod System Center og andre platforme Integration igennem Integration Packs DEMO
Find problemet End to end systemovervågning Distribution af prober Watcher Nodes SCOM01 SCOM02 OrgC.company.com Syntetiske transaktioner Slutbrugerperspektiv F.eks. Web, DB eller integration med test tools OrgA.company.com OrgB.company.com dmz.company.com
Vis det Dashboards, Diagrams og Distributed Applications Mulighed for at kombinere overvågningsdata i en sammenhæng Relationer og vægtning imellem løsningskomponenter Kan integreres med SharePoint og Visio
Desktop Management ~ SCCM Automatisering og rationalisering Reducere manuelle arbejdsgange Udrulning OS + software Vedligehold software Vedligehold patch management Fjerne kompleksitet fra vedligehold
Desktop Management Typisk implementeringsforløb Design Installation af løsning Forankring Application Repackaging Ressourcekrævende
Rationalisering Applikationskonsolidering Faser: 1. Indsamling af det, der er installeret, og det der bruges SCCM er din ven 2. Kill! Fjern applikationer som (næsten) ikke bruges 3. Konsolidér applikationer med overlappende funktioner
Software distribution mål Høj færdiggørelsesgrad Ingen manuelle arbejdsgange Hensigt: Arbejdspladser kan geninstalleres på et givent tidspunkt uden tab af opsætninger og funktionalitet
Desktop Management udfordringer Forretningskrav ændrer sig Behov for nye/andre softwarepakker Høj opdateringsfrekvens på eksisterende pakker It afdelingen kan ikke følge med, så manueller procedurer bliver nødvendige for at imødekomme forretningskrav Visse softwareprodukter kan være svære at automatisere / tilpasse MSI repackaging er ofte en tung/dyr proces Resultat: Løsning sander til Værdi over tid År 1 År 2 År 3 År 4
SOFT2go Koncept og teknologi: Pakkeværktøj DEMO Web service Automation i SCCM Baseret på abonnementsvilkår
System Center Configuration Manager Optimering via SOFT2go Drift Design Installation af løsning Forankring Application Repackaging Vedligehold/nye pakker Vedligehold/nye pakker Vedligehold/nye pakker Vedligehold/nye pakker Etc.
Patch Management PM i SCCM 2012 er enklere og mere overskueligt Færre begreber og trin end i tidligere versioner af SCCM (yay!) Nyt: Automatic Deployment Rules
Patch Management basis Det anbefales altid at teste patches før udrulning Med ADR er det nemt at definere test/prod udrulning: Pilotklienter udrulles efter Patch Tuesday Produktion udrulles f.eks. 14 dage forskudt Samme gælder servere Brug Maintenance Windows i SCCM til at styre udrulning og genstartstidspunkter
Patch Management avanceret Udfordring: Udrulning af patches i multi tiered applikation Flere datacentre Applikationslag er indbyrdes afhængige Begrænsede tidsrum for gennemførsel af patches Front end servere skal draines for brugersessioner inden patching Middle tier servere skal have services stoppet i en specifik rækkefølge for at sikre at batchkørsler afvikles korrekt Front-end Middle-tier Back-end Problemer: Udrulning på passende tidspunkter Genstart i rette rækkefølge Afvikling af jobs før og efter patching Lokation Vest Lokation Øst
Patch Management avanceret Løsning: SCCM + Orchestrator + Små scripts + Lidt smarte Runbooks
Patch Management avanceret Kør jobs før/efter: Stoppe/starte services Flytte ressourcer Afvikle køer Drain Kontrol: Flow Rækkefølge Advisering
Opsummering Kom godt fra start Tålmodighed og vedholdenhed lønner sig Automatiser, integrer og visualiser Visionær og moden teknologi edgemo fokus på værktøj og proces
Spørgsmål