Introduktion till Resurshanteraren för Service Fabric-kluster

Traditionellt innebar hantering av IT-system eller onlinetjänster att specifika fysiska eller virtuella datorer skulle dedikera specifika tjänster eller system. Tjänsterna har konstruerats som nivåer. Det skulle finnas en "webbnivå" och en "data" eller "lagringsnivå". Program skulle ha en meddelandenivå där begäranden flödade in och ut, samt en uppsättning datorer som är dedikerade till cachelagring. Varje nivå eller typ av arbetsbelastning hade specifika datorer som var dedikerade till den: databasen fick ett par datorer dedikerade till den, webbservrarna några. Om en viss typ av arbetsbelastning orsakade att datorerna kördes för frekvent, lade du till fler datorer med samma konfiguration på den nivån. Alla arbetsbelastningar kan dock inte skalas ut så enkelt – särskilt med den datanivå som du vanligtvis skulle ersätta datorer med större datorer. Enkelt. Om en dator misslyckades kördes den delen av det övergripande programmet med lägre kapacitet tills datorn kunde återställas. Fortfarande ganska lätt (om inte nödvändigtvis roligt).

Nu har dock service- och programvaruarkitekturen förändrats. Det är vanligare att program har en utskalningsdesign. Det är vanligt att skapa program med containrar eller mikrotjänster (eller båda). Nu, även om du kanske fortfarande bara har ett fåtal datorer, så kör de inte bara en enda instans av en arbetsbelastning. De kan till och med köra flera olika arbetsbelastningar samtidigt. Nu har du dussintals olika typer av tjänster (som inte förbrukar resurser för hela datorn), kanske hundratals olika instanser av dessa tjänster. Varje namngiven instans har en eller flera instanser eller repliker för hög tillgänglighet (HA). Beroende på storleken på dessa arbetsbelastningar och hur upptagna de är kan du hitta dig själv med hundratals eller tusentals datorer.

Att plötsligt hantera din miljö är inte så enkelt som att hantera några datorer som är dedikerade till enskilda typer av arbetsbelastningar. Dina servrar är virtuella och har inte längre namn (du har bytt tankesätt från husdjur till boskap trots allt). Konfigurationen handlar mindre om datorerna och mer om själva tjänsterna. Maskinvara som är dedikerad till en enda instans av en arbetsbelastning tillhör till stor del det förflutna. Själva tjänsterna har blivit små distribuerade system som omfattar flera mindre delar av maskinvaran.

Eftersom din app inte längre är en serie monoliter fördelade på flera nivåer har du nu många fler kombinationer att hantera. Vem bestämmer vilka typer av arbetsbelastningar som kan köras på vilken maskinvara eller hur många? Vilka arbetsbelastningar fungerar bra på samma maskinvara och vilken konflikt? Hur vet du vad som kördes där på datorn när en dator kraschar? Vem ansvarar för att se till att arbetsbelastningen börjar köras igen? Väntar du på att datorn (virtuell?) ska komma tillbaka eller redundansväxlar dina arbetsbelastningar automatiskt till andra datorer och fortsätter att köra? Krävs mänsklig inblandning? Vad gäller för uppgraderingar i den här miljön?

Som utvecklare och operatörer som arbetar i den här miljön kommer vi att vilja ha hjälp med att hantera den här komplexiteten. Att anställa binge och försöka dölja komplexiteten med människor är förmodligen inte rätt svar, så vad gör vi?

Introduktion till orkestrerare

En "Orchestrator" är den allmänna termen för en programvara som hjälper administratörer att hantera dessa typer av miljöer. Orkestrerare är de komponenter som tar in begäranden som "Jag vill ha fem kopior av den här tjänsten som körs i min miljö". De försöker få miljön att matcha önskat tillstånd, oavsett vad som händer.

Orkestrerare (inte människor) är det som vidtar åtgärder när en dator slutar fungera eller en arbetsbelastning avslutas av någon oväntad anledning. De flesta orkestrerare gör mer än att bara hantera fel. Andra funktioner som de har är att hantera nya distributioner, hantera uppgraderingar och hantera resursförbrukning och styrning. Alla orkestrerare handlar i grunden om att upprätthålla ett visst önskat konfigurationstillstånd i miljön. Du vill kunna berätta för en orkestrerare vad du vill ha och låta den göra grovjobbet. Aurora ovanpå Mesos, Docker Datacenter/Docker Swarm, Kubernetes och Service Fabric är alla exempel på orkestrerare. Dessa dirigerare utvecklas aktivt för att uppfylla behoven hos verkliga arbetsbelastningar i produktionsmiljöer.

Orkestrering som en tjänst

Cluster Resource Manager är den systemkomponent som hanterar orkestrering i Service Fabric. Klustrets Resource Manager-jobb är uppdelat i tre delar:

1. Framtvinga regler
2. Optimera din miljö
3. Hjälp med andra processer

På den här sidan hittar du en träningsvideo som beskriver hur kluster Resource Manager fungerar:

Vad det inte är

I traditionella N-nivåprogram finns det alltid en Load Balancer. Detta var vanligtvis en NLB (Network Load Balancer) eller ett program Load Balancer (ALB) beroende på var det satt i nätverksstacken. Vissa lastbalanserare är maskinvarubaserade som F5:s BigIP-erbjudande, andra är programvarubaserade, till exempel Microsofts NLB. I andra miljöer kan du se något som HAProxy, nginx, Istio eller Envoy i den här rollen. I dessa arkitekturer är belastningsutjämningsjobbet att säkerställa att tillståndslösa arbetsbelastningar tar emot (ungefär) samma mängd arbete. Strategier för belastningsutjämning varierade. Vissa balanserare skickar varje anrop till en annan server. Andra tillhandahöll sessionspinning/fasthet. Mer avancerade balanserare använder faktisk belastningsuppskattning eller rapportering för att dirigera ett anrop baserat på den förväntade kostnaden och den aktuella maskinbelastningen.

Nätverksbalanserare eller meddelanderoutrar försökte se till att webb-/arbetsnivån förblev ungefär balanserad. Strategier för att balansera datanivån var olika och beroende av datalagringsmekanismen. För att balansera datanivån förlitade sig dataharding, cachelagring, hanterade vyer, lagrade procedurer och andra lagringsspecifika mekanismer.

Vissa av dessa strategier är intressanta, men Service Fabric-klustret Resource Manager är inte något som liknar en lastbalanserare för nätverk eller en cache. Ett nätverk Load Balancer balanserar klientdelar genom att sprida trafik över klientdelarna. Service Fabric-klustret Resource Manager har en annan strategi. I grunden flyttar Service Fabric tjänster dit de är mest meningsfulla och förväntar sig att trafik eller belastning ska följa. Det kan till exempel flytta tjänster till noder som för närvarande är kalla eftersom tjänsterna där inte utför mycket arbete. Noderna kan vara kalla eftersom de tjänster som fanns har tagits bort eller flyttats någon annanstans. Som ett annat exempel kan kluster Resource Manager också flytta en tjänst bort från en dator. Kanske är datorn på väg att uppgraderas eller överbelastas på grund av en topp i förbrukningen av de tjänster som körs på den. Alternativt kan resurskraven för tjänsten ha ökat. Därför finns det inte tillräckligt med resurser på den här datorn för att fortsätta köra den.

Eftersom kluster Resource Manager ansvarar för att flytta runt tjänster innehåller den en annan funktionsuppsättning jämfört med vad du skulle hitta i en lastbalanserare för nätverk. Detta beror på att nätverkslastbalanserare levererar nätverkstrafik till den plats där tjänsterna redan finns, även om den platsen inte är idealisk för att köra själva tjänsten. Service Fabric-klustret Resource Manager använder helt olika strategier för att säkerställa att resurserna i klustret används effektivt.

Nästa steg

• Mer information om arkitekturen och informationsflödet i Resource Manager finns i den här artikeln
• Kluster Resource Manager har många alternativ för att beskriva klustret. Mer information om mått finns i den här artikeln om hur du beskriver ett Service Fabric-kluster
• Mer information om hur du konfigurerar tjänster finns i Mer information om hur du konfigurerar tjänster
• Mått är hur Service Fabric-klusterresurshanteraren hanterar förbrukning och kapacitet i klustret. Mer information om mått och hur du konfigurerar dem finns i den här artikeln
• Kluster Resource Manager fungerar med Service Fabrics hanteringsfunktioner. Mer information om integreringen finns i den här artikeln
• Om du vill veta mer om hur kluster Resource Manager hanterar och balanserar belastningen i klustret kan du läsa artikeln om belastningsutjämning