Planera utformningen av en hanteringsgrupp

Viktigt

Den här versionen av Operations Manager har nått slutet av supporten. Vi rekommenderar att du uppgraderar till Operations Manager 2022.

Översikt

En hanteringsgrupp består av en enda operativ databas (även kallad ”använd databas”), en eller flera hanteringsservrar och en eller flera övervakade agenter och enheter. Genom att ansluta hanteringsgrupper kan du visa och redigera aviseringar och andra övervakningsdata från en enda konsol. Aktiviteter kan också initieras från en lokal hanteringsgrupp och sedan köras på hanterade objekt i en ansluten hanteringsgrupp.

Den enklaste Operations Manager-implementeringen är en enskild hanteringsgrupp. Varje ytterligare grupp kräver minst en egen operativ databas och hanteringsserver. Varje grupp måste också underhållas separat med egna konfigurationsinställningar, hanteringspaket och integrering med andra övervaknings- och ITSM-lösningar.

Implementeringen av en distribuerad hanteringsgrupp utgör grunden för 99 procent av en Operations Manager-distribution. Den gör att du kan distribuera funktioner och tjänster över flera servrar för att öka skalbarheten och redundansen för vissa av dessa funktioner. Den kan innehålla alla Operations Manager-serverroller och stöder övervakning av enheter över förtroendegränser med hjälp av gatewayservern.

I följande diagram visas en möjlig topologi för den distribuerade hanteringsgruppen.

Anteckning

Det finns ingen direkt kommunikation mellan driftkonsolen och databaserna. All kommunikation dirigeras till en viss hanteringsserver över port TCP 5724, och sedan till databasservrarna med OLE DB via TCP 1433 eller en användardefinierad port som anges av SQL-administratören under installationen av instansen av SQL Server-databasmotorn. Det finns dock direkt kommunikation mellan en programdiagnostikkonsol (samlokaliserad med webbkonsolen) och SQL Server som är värd för drift- och informationslagerdatabaserna.

En hanteringsgrupp som du har distribuerat i din miljö kan integreras med Microsoft Operations Management Suite (OMS) och genom att använda Log Analytics kan du ytterligare korrelera, visualisera och agera på prestanda, händelser och aviseringar. Detta ger dig ökad synlighet genom att kunna utföra anpassade sökningar i hela datamängden för att korrelera data mellan system och program, lokalt eller i molnet.

Integrering med Operations Manager omfattar andra produkter som BMC Remedy, IBM, Netcool eller andra företagshanteringslösningar som används av din organisation. Mer information om hur du planerar samverkan med dessa lösningar finns i Integration with other management solutions (Integration med andra hanteringslösningar).

Komponenter för hanteringsgrupp

Hanteringsserver

Rothanteringsservern (RMS) i Operations Manager 2007 hade en speciell typ av hanteringsserver i en hanteringsgrupp och var den första hanteringsservern som installerades i en hanteringsgrupp. RMS var centrum för administrationen av hanteringsgruppernas konfiguration, administrationen och kommunikationen med agenter och kommunikationen med den operativa databasen och andra databaser i hanteringsgruppen. RMS-servern var också mål för driftkonsolen, och det prioriterade målet för webbkonsolen. Rothanteringsserverrollen togs bort i System Center 2012 R2 – Operations Manager och nu är alla hanteringsservrar likställda. Den här konfigurationen finns fortfarande i System Center 2016 och senare – Operations Manager.

RMS utgör inte längre en felpunkt eftersom alla hanteringsservrar är värdar för tjänsterna som tidigare bara RMS var värd för. Roller fördelas till alla hanteringsservrar. Om en hanteringsserver blir otillgänglig fördelas dess ansvarsområden automatiskt om. En RMS-emulatorroll möjliggör bakåtkompatibilitet för hanteringspaket med RMS som mål. Om du inte har några hanteringspaket som tidigare riktades mot RMS behöver du inte använda RMS-emulatorn.

Hanteringsgruppen kan innehålla flera hanteringsservrar, så att du får ytterligare kapacitet och kontinuerlig tillgänglighet. När två eller fler hanteringsservrar läggs till i en hanteringsgrupp blir hanteringsservrarna automatiskt en del av de tre standardresurspoolerna och arbetet fördelas mellan medlemmarna i poolen. Medlemmar läggs till manuellt i anpassade resurspooler. När det blir fel på en av medlemmarna i poolen tar andra medlemmar i resurspoolen över den medlemmens arbete. När en ny hanteringsserver läggs till hämtar den nya hanteringsservern automatiskt en del av arbetet från de befintliga medlemmarna i resurspoolen. Läs designöverväganden för resurspooler för att lära dig mer om hur de fungerar och de rekommendationer som påverkar din designplan.

Om en hanteringsserver av någon anledning inte är tillgänglig redundansväxlar som standardagenter som förlitar sig på den automatiskt till en annan hanteringsserver. När du väljer antalet och placeringen av hanteringsservrar bör den här redundansväxlingsförmågan övervägas om hög tillgänglighet är ett krav.

Agenter ansluter till en hanteringsserver för att kommunicera med alla andra Operations Manager-komponenter. En del av arbetet som utförs av en hanteringsserver är att hämta användningsdata som skickas av agenter och lägga till dem i den operativa databasen och i informationslagret.

En typisk hanteringsserver hanterar cirka 3 000 agenter. Faktiska serverprestanda varierar beroende på mängden användningsdata som samlas in, men normalt stöder hanteringsservrar 3 000 agenter var, även med en relativt stor volym användningsdata.

Det finns ingen gräns för det maximala antalet hanteringsservrar per hanteringsgrupp. Det är dock bästa praxis att använda så få hanteringsservrar som möjligt när du har åtgärdat skalbarhet, hög tillgänglighet och haveriberedskapsbegränsningar.

Hanteringsservrar bör ha en bra nätverksanslutning till Operations Manager-databasen och informationslagret eftersom de ofta skickar stora mängder data till dessa datalager. I allmänhet förbrukar dessa SQL Server-anslutningar mer bandbredd och är mer känsliga för fördröjningar i nätverket. Därför bör alla hanteringsservrar finnas i samma lokala nätverk som den använda databasen och databasen för informationslagret och aldrig distribueras i ett WAN-nätverk. Det bör vara mindre än 10 millisekunders fördröjning mellan en hanteringsserver och en SQL Server-instans som är värd för Operations Manager-databaserna.

Gateway-server

Operations Manager kräver ömsesidig autentisering mellan agenter och hanteringsservrar innan de kan börja utbyta information med varandra. Processen krypteras för att skydda autentiseringsprocessen mellan dem. När agenten och hanteringsservern finns i samma Active Directory-domän eller i Active Directory-domäner som har etablerade förtroenderelationer använder de Kerberos V5-autentiseringsmekanismer som tillhandahålls av Active Directory. När agenterna och hanteringsservrarna inte ligger inom samma förtroendegräns måste andra mekanismer användas för att uppfylla kravet på säker ömsesidig autentisering.

Gatewayservrar används när en brandvägg separerar agenterna från hanteringsservrarna eller när agenterna finns i en separat obetrodd domän. Gateway-servern fungerar som en proxy mellan agenterna och hanteringsservern. Utan gatewayservern kunde agenterna fortfarande utföra certifikatautentisering med en hanteringsserver, men ett X.509-certifikat måste utfärdas och installeras på varje agent med hjälp av MOMCertImport.exe-verktyget, och var och en skulle kräva åtkomst till hanteringsservern via brandväggen. Om agenterna finns i samma domän som gateway-servern eller om de finns i en betrodd domän, kan de använda Kerberos-autentisering. I detta fall kräver endast gateway-servern och de anslutna hanteringsservrarna certifikat. Detta inkluderar övervakning av virtuella datorer som körs i Microsoft Azure-infrastruktur som en tjänst (IaaS), med Operations Manager (det vill: hybridmolnövervakning) som inte är ansluten till samma betrodda sfär som rollerna som stöder Operations Manager-hanteringsgruppen, eller du har distribuerat Operations Manager i Azure IaaS (en virtuell dator med SQL Server värd för de operativa databaserna och en eller flera virtuella datorer som är värdar för hanteringsserverrollen) och övervakar ej betrodda lokala arbetsbelastningar.

Följande är ett exempel på en Operations Manager-distribution som övervakar Azure IaaS-resurser.

Följande är ett exempel på en distribution av Operations Manager som finns i Azure IaaS.

Vanligtvis används inte gatewayservrar för att hantera bandbreddsanvändning eftersom den totala mängden data som skickas från agenter till en hanteringsserver liknar den om en gatewayserver används eller inte. Syftet med en gatewayserver är att minska det arbete som krävs för att hantera certifikat för agenter i ej betrodda domäner och minska antalet kommunikationsvägar som måste tillåtas via brandväggar.

• Att ha mer än 2 000 agenter per gateway-server kan påverka möjligheten att återställa i händelse av ett ihållande avbrott som förhindrar att gatewayservern kommunicerar med hanteringsservern. Flera gateway-servrar rekommenderas om fler än 2 000 agenter krävs. Alternativet, om återställningstiden för gatewayservern är ett problem, är att testa systemet för att säkerställa att gatewayservern snabbt kan tömma kön efter ett ihållande avbrott mellan gatewayservern och hanteringsservern. När den inkommande kön på gateway-servern är full ignoreras dessutom data i kön baserat på deras prioritet, vilket innebär att ett varaktigt avbrott på gateway-servern i det här scenariot kan resultera i dataförlust.
• Om ett stort antal agenter är anslutna via gateway-servrar kan du överväga att använda en dedikerad hanteringsserver för alla gateway-servrar. Om alla gatewayservrar ansluter till en enda hanteringsserver utan att några andra agenter är anslutna till den kan återställningstiden påskyndas vid ett ihållande avbrott. Den effektiva belastningen på hanteringsservern är det totala antalet agenter som rapporterar till den antingen direkt eller med hjälp av gateway-servrar.
• För att förhindra att gatewayservern initierar kommunikation med en hanteringsserver, inklusive när den är konfigurerad för redundansväxling mellan flera hanteringsservrar för hög tillgänglighet, innehåller gatewayens godkännandeverktyg kommandoradsargumentet /ManagementServerInitiatesConnection. Detta gör att Operations Manager kan följa kundens säkerhetspolicy när datorer distribueras i en DMZ eller en annan nätverksmiljö och kommunikationen endast kan initieras från intranätet.

Webbkonsolserver

Webbkonsolen tillhandahåller ett gränssnitt för hanteringsgruppen som kan nås via en webbläsare. Den har inte alla funktioner i driftkonsolen och ger endast åtkomst till vyerna Övervakning och Min arbetsyta. Webbkonsolen ger åtkomst till alla övervakningsdata och uppgifter som är åtgärder som kan köras mot övervakade datorer från driftkonsolen. Åtkomsten till data i webbkonsolen har samma begränsningar som åtkomsten till innehåll i driftkonsolen.

Rapportserver

Rapportering för System Center – Operations Manager är installerat på SQL Server Reporting Services (som stöds av den version av Operations Manager som du använder) och den enda giltiga konfigurationen av Reporting Services som stöds av Operations Manager Reporting är internt läge.

Anteckning

Installera System Center – Operations Manager Reporting Services integrerar säkerheten för SQL Reporting Services-instansen med rollbaserad säkerhet i Operations Manager. Installera inte andra Reporting Services-program i samma instans av SQL Server.

Operations Manager Report Server-komponenter kan installeras på samma server som kör SQL Server 2014 eller 2016 Reporting Services eller på en annan dator. För optimala prestanda, särskilt i en företagsmiljö med hög volym, parallell rapportgenerering av användare medan interaktiva eller schemalagda rapporter bearbetas samtidigt, måste du skala upp för att hantera fler samtidiga användare och större rapportkörningsbelastningar. Vi rekommenderar att Operations Manager Reporting-tjänsten inte finns på samma SQL Server som är värd för informationslagerdatabasen och installeras på ett dedikerat system.

Använd databas

Den operativa (eller ”använda”) databasen är en SQL Server-databas som innehåller alla användningsdata, konfigurationsinformation och övervakningsregler för en hanteringsgrupp. Operations Manager-databasen är en enskild felkälla för hanteringsgruppen, och kan därför konfigureras för hög tillgänglighet med hjälp av klusterkonfigurationer som stöds.

Om du vill att den här databasen ska ha en konsekvent storlek kan du använda rensningsinställningarna i Operations Manager för att ange hur länge data ska bevaras i den. Som standard är varaktigheten sju (7) dagar.

Informationslagerdatabas för rapportering

Informationslagret för rapportering är en SQL Server-databas som samlar in och lagrar användningsdata för långsiktig rapportering. Dessa data skrivs direkt från regler som samlar in data som ska rapporteras och från datasynkroniseringsprocesser i den operativa databasen. Informationslagrets underhåll, inklusive aggregering, trimning och optimering, utförs automatiskt av Operations Manager.

I följande tabell ser du standarddatatyperna och hur länge data bevaras efter den ursprungliga konfigurationen av informationslagerdatabasen.

Datamängd	Sammansättningstyp	Kvarhållningstid (i dagar)
Varning	Rådata	400
Klientövervakning	Rådata	30
Klientövervakning	Varje dag	400
Händelser	Rådata	100
Prestanda	Rådata	10
Prestanda	Varje timma	400
Prestanda	Varje dag	400
Tillstånd	Rådata	180
Tillstånd	Varje timma	400
Tillstånd	Varje dag	400

Ett datalager kan betjäna flera olika hanteringsgrupper. Detta gör att en enda rapport kan innehålla data från alla datorer i organisationen.

Precis som Operations Manager-databasen kan informationslagerdatabasen klustras för hög tillgänglighet. Om den inte är klustrad bör den övervakas noggrant så att eventuella problem snabbt kan åtgärdas.

ACS-insamlare

ACS-insamlaren tar emot och bearbetar händelser från ACS-vidarebefordrare och skickar sedan informationen till ACS-databasen. Den här bearbetningen omfattar att demontera data så att de kan spridas över flera tabeller i ACS-databasen, minimera dataredundans och tillämpa filter så att onödiga händelser inte läggs till i ACS-databasen.

ACS-databas

Händelser som genereras av en granskningsprincip inom en ACS-distribution lagras centralt i ACS-databasen. ACS-databasen kan vara på samma dator som ACS-insamlaren, men för bästa prestanda installeras varje på en dedikerad server. Som standard bevaras data i fjorton (14) dagar.

ACS-vidarebefordrare

Tjänsten som körs på ACS-vidarebefordrarna ingår i Operations Manager-agenten. Som standard är den här tjänsten installerad men inte aktiverad när Operations Manager-agenten har installerats. Du kan aktivera den här tjänsten på flera agentdatorer samtidigt med hjälp av åtgärden för gransknings- och insamlingsaktivering eller med hjälp av PowerShell. När du har aktiverat tjänsten skickas alla säkerhetshändelser till ACS-insamlaren och inte bara till den lokala säkerhetsloggen.

Designöverväganden

Ha följande faktorer i åtanke när du överväger att implementera en eller flera hanteringsgrupper:

• Ökad kapacitet. Operations Manager har inga inbyggda begränsningar för antalet agenter som en enskild hanteringsgrupp stöder. Beroende på den maskinvara du använder och hanteringsgruppens övervakningsbelastning (fler distribuerade hanteringspaket innebär högre övervakningsbelastning) kan du behöva flera hanteringsgrupper för att få acceptabla prestanda.
• Konsoliderade vyer. När flera hanteringsgrupper används för att övervaka en miljö krävs en mekanism som kan tillhandahålla en konsoliderad vy över övervaknings- och aviseringsdata från dem. Du kan åstadkomma detta genom att distribuera en ytterligare hanteringsgrupp (som har eller inte har övervakningsansvar) som har åtkomst till alla data i alla andra hanteringsgrupper. Dessa hanteringsgrupper kallas för anslutna. Den hanteringsgrupp som används för att tillhandahålla en konsoliderad vy över data kallas för den lokala hanteringsgruppen, och övriga hanteringsgrupper som förser den med data kallas för anslutna hanteringsgrupper.
• Säkerhet och administration. Partitionering av hanteringsgrupper av säkerhets- och administrativa skäl liknar begreppet delegering av administrativ auktoritet över Active Directory-organisationsenheter eller domäner till olika administrativa grupper. Ditt företag kan ha flera IT-grupper, var och en med sitt eget ansvarsområde. Området kan vara ett visst geografiskt område eller en företagsdivision. I ett holdingbolag kan det till exempel vara något av dotterbolagen. Om den här typen av fullständig delegering av administrativ behörighet från den centraliserade IT-gruppen förekommer, kan det vara praktiskt att implementera en hanteringsgruppsstruktur i varje område. De kan sedan konfigureras som anslutna hanteringsgrupper till en lokal hanteringsgrupp som finns i det centrala IT-datacentret.
• Installerade språk. Alla servrar som har en installerad Operations Manager-serverroll måste installeras på samma språk. Det vill säga att du inte kan installera hanteringsservern med hjälp av den engelska versionen av Operations Manager 2012 R2 och sedan distribuera driftkonsolen med hjälp av den japanska versionen. Om övervakningen måste omfatta flera språk krävs en ytterligare hanteringsgrupp för varje språk för operatörerna.
• Funktioner för produktion och förproduktion. I Operations Manager är det en rekommenderad metod att ha en produktionsimplementering som används för att övervaka dina produktionsprogram och en förproduktionsimplementering som har minimal interaktion med produktionsmiljön. Förproduktionshanteringsgruppen används för att testa och justera hanteringspaketfunktioner innan den migreras till produktionsmiljön. Vissa företag använder dessutom en mellanlagringsmiljö för servrar, där nybyggda servrar genomgår en felsökningsperiod (burn-in) innan de distribueras till produktionsmiljön. Förproduktionshanteringsgruppen kan användas för att övervaka mellanlagringsmiljön för att säkerställa hälsotillståndet för servrar före produktionsdistributionen.
• Dedikerade ACS-funktioner. Om dina krav inkluderar behovet av att samla in händelser i Windows Audit Security-loggen eller UNIX/Linux-säkerhetshändelser implementerar du granskningsinsamlingstjänsten (ACS). Det kan vara bra att implementera en hanteringsgrupp som exklusivt stöder ACS-funktionen om företagets säkerhetsbehov kräver att ACS-funktionen kontrolleras och administreras av en annan administrativ grupp än den som hanterar resten av produktionsmiljön.
• Funktioner för haveriberedskap. I Operations Manager registreras alla interaktioner med Operations Manager-databasen i transaktionsloggar innan de checkas in i databasen. Dessa transaktionsloggar kan skickas till en annan server som kör Microsoft SQL Server och checkas in på en kopia av Operations Manager-databasen där. Den här funktionen är ett alternativ för att tillhandahålla redundans för den operativa Operations Manager-databasen mellan två SQL-servrar i samma hanteringsgrupp. När en kontrollerad redundansväxling måste utföras kräver hanteringsservrarna i hanteringsgruppen en registerändring för att kunna referera till och kommunicera med den sekundära SQL-servern. En redundanshanteringsgrupp kan distribueras, som matchar den exakta konfigurationen av den primära hanteringsgruppen (hanteringspaket, åsidosättningar, meddelandeprenumerationer, säkerhet osv.) och agenterna har konfigurerats för att rapportera till båda hanteringsgrupperna. Om den primära hanteringsgruppen i sin helhet blir otillgänglig av någon anledning finns det ingen stilleståndstid för övervakningsmiljön. Den här lösningen säkerställer hanteringsgruppens kontinuitet, utan avbrott i användningsövervakningen.

Innan du distribuerar System Center Operations Manager i en produktionsmiljö ska du planera utformningen av hanteringsgruppen. Under planeringsfasen förstår du IT-tjänstkomponenterna (dvs. infrastruktur och programnivå) och antalet system och enheter som stöder dem, hur de integrerar och stöder dina processer för incident- och problemhantering samt hur du visualiserar data för olika supportnivåer för incidenteskalering, teknik, tjänstkonsumenter och hantering.

Anslutna hanteringsgrupper

Många företag med servrar på flera geografiska platser kräver central övervakning av dessa servrar. Konfigurationen med anslutna hanteringsgrupper, som illustreras i bilden nedan, är en uppsättning arbetsflödesprocesser som är utformade för att skapa en hanteringsinfrastruktur med hierarkiskt ordnade system.

Du kan använda den här konfigurationen om du vill implementera centraliserad övervakning. Den är utformad för att stödja visning av aviseringar och övervakningsdata och för att initiera uppgifter mot ett hanterat objekt i en ansluten hanteringsgrupp.

Genom att ansluta Operations Manager-hanteringsgrupper kan centraliserade övervakningsfunktioner underhållas samtidigt som du aktiverar:

• Övervaka ett större antal hanterade objekt än vad som är möjligt med en enskild hanteringsgrupp.
• Isolera övervakningsaktivitet baserat på logiska affärsenheter, till exempel ”Marknadsföring”, eller fysiska platser, till exempel ”Rom”.

När du ansluter hanteringsgrupper distribuerar du inga nya servrar. I stället tillåter du att den lokala hanteringsgruppen har åtkomst till aviseringar och identifieringsinformation som finns i en ansluten hanteringsgrupp. Därmed kan du visa och interagera med alla aviseringar och annan övervakningsdata från flera hanteringsgrupper i en enda driftkonsol. Dessutom kan du köra uppgifter på de datorer som övervakas i de anslutna hanteringsgrupperna. Om du vill veta hur du ansluter hanteringsgrupper kan du läsa Ansluta hanteringsgrupper i Operations Manager.

Installerade språk

Operations Manager-hanteringsgrupper stöder endast ett installerat språk. Om den övergripande IT-miljön som du behöver övervaka har fler än ett installerat språk, krävs en separat hanteringsgrupp per språk.