Inleiding tot de Resource Manager van het Service Fabric-cluster

Traditioneel betekende het beheren van IT-systemen of onlineservices het toewijzen van specifieke fysieke of virtuele machines aan die specifieke services of systemen. Services zijn ontworpen als lagen. Er zou een 'web'-laag en een 'data'- of 'storage'-laag zijn. Toepassingen zouden een berichtenlaag hebben waar aanvragen in- en uitstroomden, evenals een set computers die zijn toegewezen aan caching. Aan elke laag of elk type workload zijn specifieke machines toegewezen: de database heeft een aantal computers die eraan zijn toegewezen, de webservers een paar. Als een bepaald type workload ertoe leidde dat de computers waarop deze was geïnstalleerd, te heet worden uitgevoerd, hebt u meer machines met dezelfde configuratie aan die laag toegevoegd. Niet alle werkbelastingen kunnen echter zo eenvoudig worden uitgeschaald, met name met de gegevenslaag die u normaal gesproken zou vervangen door grotere machines. Simpel. Als een machine uitviel, werd dat deel van de algemene toepassing uitgevoerd op een lagere capaciteit totdat de machine kon worden hersteld. Nog steeds redelijk eenvoudig (zo niet noodzakelijkerwijs leuk).

Nu is de wereld van service- en softwarearchitectuur echter veranderd. Het komt vaker voor dat toepassingen een uitschaalontwerp hebben. Het bouwen van toepassingen met containers of microservices (of beide) is gebruikelijk. Hoewel u misschien nog maar een paar computers hebt, wordt er niet slechts één exemplaar van een workload uitgevoerd. Ze kunnen zelfs meerdere verschillende workloads tegelijkertijd uitvoeren. U hebt nu tientallen verschillende typen services (geen die de resources van een volledige machine verbruiken), mogelijk honderden verschillende exemplaren van deze services. Elk benoemd exemplaar heeft een of meer exemplaren of replica's voor hoge beschikbaarheid (HA). Afhankelijk van de grootte van deze workloads en hoe druk ze zijn, kunt u honderden of duizenden machines hebben.

Plotseling is het beheren van uw omgeving niet zo eenvoudig als het beheren van een paar machines die zijn toegewezen aan één type werkbelasting. Uw servers zijn virtueel en hebben geen namen meer (u bent van gedachten veranderd van huisdieren naar vee ). Configuratie gaat minder over de machines en meer over de services zelf. Hardware die is toegewezen aan één exemplaar van een workload, is grotendeels verleden tijd. Services zelf zijn kleine gedistribueerde systemen geworden die meerdere kleinere onderdelen van basishardware omvatten.

Omdat uw app niet langer een reeks monoliets is verspreid over verschillende lagen, hebt u nu veel meer combinaties om mee om te gaan. Wie bepaalt welke typen workloads op welke hardware kunnen worden uitgevoerd, of hoeveel? Welke workloads werken goed op dezelfde hardware en welke conflicterende workloads? Wanneer een machine uitvalt, hoe weet u dan wat er op die machine werd uitgevoerd? Wie moet ervoor zorgen dat de workload weer wordt uitgevoerd? Wacht u tot de (virtuele?) machine terugkeert of voert u automatisch een failover uit naar andere machines en blijft u actief? Is menselijke tussenkomst vereist? Hoe zit het met upgrades in deze omgeving?

Als ontwikkelaars en operators die in deze omgeving werken, willen we hulp bij het beheren van deze complexiteit. Een binge inhuren en proberen de complexiteit met mensen te verbergen is waarschijnlijk niet het juiste antwoord, dus wat doen we?

Inleiding tot orchestrators

Een orchestrator is de algemene term voor software waarmee beheerders dit type omgevingen kunnen beheren. Orchestrators zijn de onderdelen die aanvragen als 'Ik wil dat vijf exemplaren van deze service worden uitgevoerd in mijn omgeving'. Ze proberen ervoor te zorgen dat de omgeving overeenkomt met de gewenste status, ongeacht wat er gebeurt.

Orchestrators (geen mensen) ondernemen actie wanneer een machine uitvalt of een workload om een onverwachte reden wordt beëindigd. De meeste orchestrators doen meer dan alleen omgaan met fouten. Andere functies die ze hebben, zijn het beheren van nieuwe implementaties, het afhandelen van upgrades en het omgaan met resourceverbruik en governance. Alle orchestrators hebben in principe betrekking op het onderhouden van een gewenste configuratiestatus in de omgeving. Je wilt een orchestrator kunnen vertellen wat je wilt en het zware werk laten doen. Aurora bovenop Mesos, Docker Datacenter/Docker Swarm, Kubernetes en Service Fabric zijn allemaal voorbeelden van orchestrators. Deze orchestrators worden actief ontwikkeld om te voldoen aan de behoeften van echte workloads in productieomgevingen.

Indeling als een service

Het cluster Resource Manager is het systeemonderdeel dat de indeling in Service Fabric afhandelt. De taak van de cluster Resource Manager is onderverdeeld in drie delen:

1. Regels afdwingen
2. Uw omgeving optimaliseren
3. Hulp bij andere processen

Bekijk deze pagina voor een trainingsvideo om te begrijpen hoe de cluster-Resource Manager werkt:

Wat het niet is

In traditionele N-laagtoepassingen is er altijd een Load Balancer. Meestal was dit een netwerk Load Balancer (NLB) of een toepassing Load Balancer (ALB), afhankelijk van waar het zich in de netwerkstack bevond. Sommige load balancers zijn op hardware gebaseerd, zoals het BigIP-aanbod van F5, andere zijn gebaseerd op software, zoals NLB van Microsoft. In andere omgevingen ziet u mogelijk iets als HAProxy, nginx, Istio of Envoy in deze rol. In deze architecturen is taak van taakverdeling ervoor te zorgen dat stateless workloads (ongeveer) dezelfde hoeveelheid werk ontvangen. Strategieën voor taakverdeling varieerden. Sommige balancers zouden elke aanroep naar een andere server verzenden. Anderen hebben sessiepinning/-stickiness opgegeven. Geavanceerdere balancers gebruiken schatting van werkelijke belasting of rapportage om een oproep te routeren op basis van de verwachte kosten en de huidige machinebelasting.

Netwerk balancers of berichtrouters hebben geprobeerd ervoor te zorgen dat de web-/werklaag ongeveer in balans bleef. Strategieën voor het balanceren van de gegevenslaag waren verschillend en waren afhankelijk van het mechanisme voor gegevensopslag. Het verdelen van de gegevenslaag was afhankelijk van gegevenssharding, caching, beheerde weergaven, opgeslagen procedures en andere opslagspecifieke mechanismen.

Hoewel sommige van deze strategieën interessant zijn, is het Service Fabric-cluster Resource Manager niet zoiets als een netwerk load balancer of een cache. Een netwerk-Load Balancer balanceert front-ends door verkeer over front-ends te spreiden. Het Service Fabric-cluster Resource Manager heeft een andere strategie. In principe verplaatst Service Fabric services naar de locatie waar ze het meest zinvol zijn, waarbij verkeer of belasting moet volgen. Het kan bijvoorbeeld services verplaatsen naar knooppunten die momenteel koud zijn omdat de services daar niet veel werk doen. De knooppunten kunnen koud zijn omdat de services die aanwezig waren, zijn verwijderd of ergens anders zijn verplaatst. Een ander voorbeeld is dat de cluster-Resource Manager ook een service van een computer kan verwijderen. Misschien staat de machine op het punt om te worden geüpgraded of overbelast vanwege een piek in het verbruik door de services die erop worden uitgevoerd. De resourcevereisten van de service kunnen ook zijn toegenomen. Als gevolg hiervan zijn er onvoldoende resources op deze computer om door te gaan met het uitvoeren ervan.

Omdat de Cluster-Resource Manager verantwoordelijk is voor het verplaatsen van services, bevat het een andere functieset dan wat u in een netwerk load balancer zou vinden. Dit komt doordat netwerktaakverdelers netwerkverkeer leveren naar waar services zich al bevinden, zelfs als die locatie niet ideaal is voor het uitvoeren van de service zelf. Het Service Fabric-cluster Resource Manager maakt gebruik van fundamenteel verschillende strategieën om ervoor te zorgen dat de resources in het cluster efficiënt worden gebruikt.

Volgende stappen

• Raadpleeg dit artikel voor informatie over de architectuur en informatiestroom binnen de cluster-Resource Manager
• Het cluster Resource Manager heeft veel opties voor het beschrijven van het cluster. Raadpleeg dit artikel over het beschrijven van een Service Fabric-cluster voor meer informatie over metrische gegevens
• Meer informatie over services configureren voor meer informatie over het configureren van services
• Metrische gegevens zijn de wijze waarop het Service Fabric-clusterresourcebeheer het verbruik en de capaciteit in het cluster beheert. Raadpleeg dit artikel voor meer informatie over metrische gegevens en hoe u deze configureert
• De Cluster Resource Manager werkt met de beheermogelijkheden van Service Fabric. Lees dit artikel voor meer informatie over die integratie
• Raadpleeg het artikel over taakverdeling voor meer informatie over hoe de cluster-Resource Manager de taak in het cluster beheert en balanceert