Designöverväganden för resurspooler
Viktigt
Den här versionen av Operations Manager har nått slutet av supporten. Vi rekommenderar att du uppgraderar till Operations Manager 2022.
En resurspool är en logisk gruppering av hanteringsservrar och/eller gateway-servrar som används för att fördela arbetet mellan servrarna och för att överta arbete från en medlem som får problem. Med andra ord tillhandahåller de hög tillgänglighet och skalbarhet för arbetsflöden. När du utformar en hanteringsgrupp finns det vissa saker som du måste tänka på gällande övervakningen av nätverksenheter, Linux-/UNIX-system och andra arbetsbelastningar som är utformade för att dra nytta av en resurspool.
Översikt
Resurspooler säkerställer en kontinuerlig övervakning genom att tillhandahålla flera medlemmar som är hanteringsservrar och/eller gateway-servrar som kan överta arbetsflöden för övervakning om någon av medlemmarna i poolen blir otillgänglig. Du kan skapa resurspooler för specifika ändamål. Exempelvis kan du skapa en resurspool med hanteringsservrar i ditt primära datacenter för att övervaka nätverksenheter.
Resurspooler använder en logik som liknar klustring av "majoritetsnoduppsättning", där (< antal noder som medlemmar i poolen > /2) + 1. Minst måste det finnas tre medlemmar i poolen för att upprätthålla kvorum, som måste vara mer än 50 % av kvorumröstningsmedlemmarna i en pool för att poolen ska vara tillgänglig. Om du bara har två medlemmar i poolen och en är otillgänglig har du förlorat kvorum.
För varje resurspool som skapas i driftkonsolen får Operations Manager-databasen, som kallas standardobservatör, alltid en röst, även om du har ett jämnt antal medlemmar i poolen för att kvorum ska kunna nås. Detta gäller även för de tre resurspooler som skapas som standard när du först skapar hanteringsgruppen, vilket beskrivs senare i den här artikeln. För alla resurspooler som skapats med PowerShell-cmdleten NewSCOM-ResourcePool är den inställd på inaktiverad som standard. Om du inkluderar Operations Manager-databasen som standardövervakare blir din hanteringsgrupp mindre svårhanterbar eftersom du endast behöver distribuera två hanteringsservrar som minimum för att bibehålla en hög tillgänglighet i resurspooler.
En annan roll som stöder resurspooler är Observatörer. Det här är en hanteringsserver eller en gateway-server som inte deltar i inläsning av arbetsflöden för poolen. de deltar dock i beslut om kvorum. Detta används aldrig under normala omständigheter och bör därför inte övervägas.
Det finns två typer av medlemskap:
- Automatiskt
- Manuell
När du skapar en resurspool är dess medlemskap inställt på manuellt och kan inte konfigureras om till automatiskt. När en System Center – Operations Manager-hanteringsgrupp skapas skapas tre resurspooler som standard med automatiskt medlemskap. Dessa tre resurspooler beskrivs i följande tabell.
Resurspoolens namn | Description |
---|---|
Resurspool för alla hanteringsservrar | Kör arbetsflöden för gruppberäkning, tillgänglighet, beräkning av hälsotillstånd för distribuerade övervakare samt databastrimning. |
Meddelanderesurspool | Arbetsflöden för aviseringsprenumerationstjänsten körs mot den här resurspoolen för att ge stöd för aviseringar. |
AD-tilldelning av resurspool | Arbetsflöden för AD-integrering körs mot den här resurspoolen för att ge stöd för automatisk agenttilldelning till hanteringsservrar. |
Eftersom medlemskapet i resurspoolen för alla hanteringsservrar är automatiskt blir alla hanteringsservrar som begärs automatiskt medlemmar i den här resurspoolen. I vissa arkitekturer och designstrukturer, till exempel de som omfattar geografiskt spridda oförutsedda händelser, kanske automatisk tilldelning till resurspoolen för alla hanteringsservrar inte är önskvärt. I sådana fall går det att ändra medlemskapstilldelningen från automatisk till manuell. Hanteringsservrarna måste läggas till i resurspoolen för alla hanteringsservrar genom manuell tilldelning.
Anteckning
Medlemskapet i resurspoolen för alla hanteringsservrar är skrivskyddat. Information om hur du ändrar medlemskapet från automatiskt till manuellt finns i avsnittet om hur du ändrar poolmedlemskap.
Med introduktionen av resurspooler rekommenderar vi att alla medlemmar är anslutna via ett nätverk med låg svarstid (mindre än 10 ms). Resurspooler bör inte distribueras över flera datacenter eller i en hybridmolnmiljö som Microsoft Azure.
Tillgänglighetsexempel för resurspooler
Följande exempel demonstrerar begreppet tillgänglighet för resurspooler baserat på följande konfigurationer, med endast hanteringsservrar eller Gateway-servrar.
Enskild hanteringsserver
- Standardobservatören är aktiverad som standard och ger ingen fördel eftersom det bara finns två medlemmar och kvorum inte nås.
- Det finns ingen hög tillgänglighet eftersom hanteringsservern är en felkritisk systemdel.
Två hanteringsservrar
- Standardövervakaren är aktiverad som standard.
- Poolen har hög tillgänglighet eftersom det finns tre röstningsmedlemmar – två hanteringsservrar och standardobservatören.
- Om du inaktiverar standardobservatören förlorar du hög tillgänglighet för poolen.
Tre hanteringsservrar
- Standardövervakaren är aktiverad som standard.
- Poolen har hög tillgänglighet eftersom det finns fyra röstningsmedlemmar – tre hanteringsservrar och standardobservatören.
- Som standard kan du bara ha en hanteringsserver otillgänglig för att upprätthålla kvorum. Om två hanteringsservrar inte är tillgängliga har du exakt 50 % av röstningsmedlemmarna och resurspoolen fungerar inte längre för att hantera övervakningsarbetsbelastningarna.
- Standardobservatören ökar inte antalet hanteringsservrar som kan vara nere, vilket innebär att pooltillgängligheten inte ökar.
- Överväg att ta bort standardövervakaren i det här scenariot.
Fyra hanteringsservrar
- Standardövervakaren är aktiverad som standard.
- Poolen har hög tillgänglighet eftersom det finns fem röstningsmedlemmar – fyra hanteringsservrar och standardobservatören.
- Som standard kan du bara ha två hanteringsservrar otillgängliga för att upprätthålla kvorum. Om tre hanteringsservrar är nere har du mindre än 50 % av röstningsmedlemmarna och resurspoolen fungerar inte längre för att hantera övervakningsarbetsbelastningarna.
- Standardövervakaren i det här scenariot tillhandahåller betydande värde eftersom den ökar antalet hanteringsservrar som kan vara otillgängliga. Utan standardövervakaren har du bara fyra kvorummedlemmar, vilket gör att endast en medlem tillåts vara otillgänglig.
Fem hanteringsservrar
- Standardövervakaren är aktiverad som standard.
- Poolen har hög tillgänglighet eftersom det finns sex röstningsmedlemmar – fem hanteringsservrar och standardobservatören.
- Som standard kan du bara ha två otillgängliga hanteringsservrar om du vill behålla kvorum. Om tre hanteringsservrar är otillgängliga är det exakt 50% av röstningsmedlemmarna och resurspoolen kan inte längre hantera övervakningsarbetsbelastningarna.
- Standardobservatören ökar inte antalet hanteringsservrar som kan vara nere, vilket innebär att pooltillgängligheten inte ökar.
- Överväg att ta bort standardövervakaren i det här scenariot.
När du når tre eller flera hanteringsservrar i en resurspool, där du har ett udda antal medlemmar i poolen, kan du överväga att ta bort standardobservatören som medlem. Om du når fem hanteringsservrar finns det en risk för betydande belastning för driftdatabasen, vilket kan generera tillräckligt med svarstid för att påverka beräkningar i resurspoolen.
Med sättet på vilket standardövervakaren spelar sin roll frågar varje hanteringsserver i poolen sin egen lokala SDK-tjänst, vilket gör det möjligt för dem att ställa frågor till en tabell i den använda databasen för standardövervakaren. Om SDK-tjänsten eller databasen är under belastning får du svarstider som annars inte skulle finnas.
Enskild Gateway-server
- Standardövervakaren är aktiverad som standard.
- Det finns ingen hög tillgänglighet eftersom gatewayservern är en felkritisk systemdel.
- Standardobservatören bör inte användas här eftersom Gateway-servrar inte har någon lokal SDK-tjänst och därför inte kan köra frågor mot den operativa databasen.
Två Gateway-servrar
- Standardövervakaren är aktiverad som standard.
- Det finns ingen hög tillgänglighet eftersom det bara finns två medlemmar i poolen och standardobservatören inte är deltagare eftersom Gateway-servrar inte kommunicerar direkt med den operativa databasen. Tre Gateway-servrar krävs för att behålla kvorum i poolen.
Tre Gateway-servrar
- Standardövervakaren är aktiverad som standard.
- Poolen har hög tillgänglighet eftersom det finns tre röstningsmedlemmar – tre Gateway-servrar.
- Som standard kan du bara ha en gateway-server otillgänglig för att upprätthålla kvorum. Om två Gateway-servrar är otillgängliga är det mindre än 50% av röstningsmedlemmarna och resurspoolen kan inte längre hantera övervakningsarbetsbelastningarna.
- Standardobservatören bör inte användas här eftersom Gateway-servrar inte har någon lokal SDK-tjänst och därför inte kan köra frågor mot den operativa databasen.
Övervakningsscenarier som stöder resurspooler
Följande arbetsflöden hanteras av resurspooler i Operations Manager:
- Hantering av nätverksenheter
- Hantering av UNIX-/Linux-agenter
- Övervakning av URL:er för webbprogram
Anteckning
Windows-agenter rapporterar inte till resurspooler.
Nätverksövervakning i Operations Manager kräver en egen separat, dedikerad resurspool. Det beror på att arbetsflöden för nätverksövervakning körs på hanteringsservrar (på SNMP-modulen) och inte på agenter. Detta innebär hård belastning på hanteringsservrarna när du börjar övervaka nätverksportar, särskilt om du väljer de flesta av de aktiva portarna som är tillgängliga på enheten. För bästa prestanda rekommenderar vi därför att du använder dedikerade hanteringsservrar i dedikerade resurspooler för nätverksövervakning. Hanteringsservrar som är medlemmar i den här poolen bör dessutom tas bort från poolerna för alla hanteringsservrar, meddelanden och AD-tilldelning.
Linux-/UNIX-övervakning i Operations Manager kan tilldelas till en dedikerad resurspool om det behövs för att aktivera övervakning och agenthantering med hög tillgänglighet, men krävs inte. Operations Manager använder certifikat för att autentisera åtkomst till de datorer som hanteras. När en agent distribueras med identifieringsguiden tar guiden emot ett certifikat från agenten, signerar certifikatet, distribuerar tillbaka certifikatet till agenten och startar sedan om agenten. Om du behöver stöd för hög tillgänglighet måste varje hanteringsserver i resurspoolen ha alla rotcertifikat som används för att signera certifikaten som distribueras till agenterna på UNIX- och Linux-datorer. Annars, om en hanteringsserver blir otillgänglig, skulle de andra hanteringsservrarna inte kunna lita på de certifikat som signerats av servern som misslyckades.
Nästa steg
Information om hur du skapar och hanterar resurspooler finns i Hantera resurspooler.