Dela via

Introduktion till Service Fabric-klusterresurshanteraren

  • Artikel

Traditionellt hanterade IT-system eller usluge na mreži innebar att dedikera specifika fysiska eller virtuella datorer till dessa 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 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 datanivån skulle du vanligtvis ersätta datorer med större datorer. Lätt. 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 världen av tjänst- och programvaruarkitektur 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, kör de inte bara en enda instans av en arbetsbelastning. De kan till och med köra flera olika arbetsbelastningar samtidigt. Du har nu dussintals olika typer av tjänster (ingen förbrukar en fullständig dators resurser), 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). Konfiguration 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 maskinvarudelar.

Eftersom din app inte längre är en serie monoliter spridda över 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? När en dator går ner, hur vet du vad som kördes där på den datorn? Vem ansvarar för att se till att arbetsbelastningen börjar köras igen? Väntar du på att den (virtuella?) datorn ska komma tillbaka eller redundansväxlar dina arbetsbelastningar automatiskt till andra datorer och fortsätter att köras? Krävs mänsklig inblandning? Hur är det med uppgraderingar i den här miljön?

Som utvecklare och operatörer som hanterar 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 orkestratorer

En "Orchestrator" är den allmänna termen för en programvara som hjälper administratörer att hantera dessa typer av miljöer. Orchestrators ä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.

Orchestrators (inte människor) är det som vidtar åtgärder när en dator misslyckas eller en arbetsbelastning avslutas av någon oväntad anledning. De flesta orkestratorer gör mer än att bara hantera misslyckande. Andra funktioner som de har är att hantera nya distributioner, hantera uppgraderingar och hantera resursförbrukning och styrning. Alla orkestratorer 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 det tunga lyftet. Aurora ovanpå Mesos, Docker Datacenter/Docker Swarm, Kubernetes och Service Fabric är alla exempel på orkestrerare. Dessa orkestratorer utvecklas aktivt för att uppfylla behoven hos verkliga arbetsbelastningar i produktionsmiljöer.

Orkestrering som en tjänst

Klusterresurshanteraren är den systemkomponent som hanterar orkestrering i Service Fabric. Klusterresurshanterarens jobb är uppdelat i tre delar:

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

På den här sidan finns en träningsvideo som beskriver hur Klusterresurshanteraren fungerar:

Vad det inte är

I traditionella N-nivåprogram finns det alltid en lastbalanserare. Vanligtvis var detta en NLB (Network Load Balancer) eller en ALB (Application Load Balancer) beroende på var den 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. Strategierna för att balansera belastningen varierade. Vissa balancers skulle skicka varje anrop till en annan server. Andra tillhandahöll sessionspinning/klibbighet. 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. Att balansera datanivån förlitade sig på datasharding, cachelagring, hanterade vyer, lagrade procedurer och andra lagringsspecifika mekanismer.

Även om vissa av dessa strategier är intressanta är Service Fabric Cluster Resource Manager inte något som liknar en nätverkslastbalanserare eller en cache. En nätverkslastbalanserare balanserar klientdelarna genom att sprida trafik över klientdelar. Service Fabric Cluster Resource Manager har en annan strategi. I grund och botten 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 de tjänster som finns 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 Klusterresurshanteraren också flytta en tjänst bort från en dator. Kanske är datorn på väg att uppgraderas, eller är överbelastad på grund av en ökning av förbrukningen av de tjänster som körs på den. Alternativt kan tjänstens resurskrav 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 Klusterresurshanteraren 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 nätverkslastbalanserare. 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 Cluster Resource Manager använder fundamentalt olika strategier för att säkerställa att resurserna i klustret används effektivt.

Nästa steg