Share via

Inleiding tot De Resource Manager van het Service Fabric-cluster

  • Artikel

Traditioneel beheren van IT-systemen of onlineservices bedoeld om specifieke fysieke of virtuele machines toe te wijzen aan die specifieke services of systemen. Services zijn ontworpen als lagen. Er zou een 'web'-laag en een 'gegevens' of 'opslaglaag' zijn. Toepassingen zouden een berichtenlaag hebben waarin aanvragen in en uit zijn gestroomd, evenals een set machines die zijn toegewezen aan caching. Voor elke laag of type workload zijn specifieke machines toegewezen: de database heeft een aantal machines toegewezen aan de database, de webservers een paar. Als een bepaald type werkbelasting de computers heeft veroorzaakt waarop deze te heet was, hebt u meer machines met dezelfde configuratie aan die laag toegevoegd. Niet alle workloads kunnen echter zo eenvoudig worden uitgeschaald, met name door de gegevenslaag die u doorgaans vervangt door grotere machines. Gemakkelijk. Als een machine is mislukt, werd dat deel van de algehele toepassing uitgevoerd met een lagere capaciteit totdat de machine kon worden hersteld. Nog steeds redelijk eenvoudig (indien niet noodzakelijkerwijs leuk).

De wereld van service- en softwarearchitectuur is nu echter veranderd. Het is gebruikelijker dat toepassingen een uitschalend ontwerp hebben aangenomen. Het bouwen van toepassingen met containers of microservices (of beide) is gebruikelijk. Hoewel u mogelijk nog maar een paar computers hebt, worden ze niet slechts één exemplaar van een workload uitgevoerd. Ze kunnen zelfs meerdere verschillende workloads tegelijk uitvoeren. U hebt nu tientallen verschillende soorten services (geen gebruik van de resources van een volledige machine), 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 het is, kunt u zich met honderden of duizenden computers bevinden.

Plotseling is het beheren van uw omgeving niet zo eenvoudig als het beheren van enkele machines die zijn toegewezen aan één type workloads. Uw servers zijn virtueel en hebben geen namen meer (u bent overgeschakeld van huisdieren tot 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 iets van het verleden. Services zelf zijn kleine gedistribueerde systemen geworden die meerdere kleinere onderdelen van basishardware omvatten.

Omdat uw app geen reeks monolithen meer is verspreid over verschillende lagen, hebt u nu nog veel meer combinaties waarmee u te maken hebt. Wie bepaalt welke typen workloads kunnen worden uitgevoerd op welke hardware of hoeveel? Welke workloads werken goed op dezelfde hardware en welk conflict? Wanneer een machine uitvalt hoe weet u wat daar op die computer werd uitgevoerd? Wie zorgt ervoor dat de werkbelasting opnieuw wordt uitgevoerd? Wacht u tot de (virtuele?) machine terugkomt of voert u automatisch een failover van uw workloads uit naar andere machines en blijft u actief? Is menselijke tussenkomst vereist? Hoe zit het met upgrades in deze omgeving?

Als ontwikkelaars en operators in deze omgeving werken, willen we u helpen 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?

Introductie van orchestrators

Een Orchestrator is de algemene term voor een stuk software waarmee beheerders deze soorten omgevingen kunnen beheren. Orchestrators zijn de onderdelen die aanvragen verwerken, zoals 'Ik wil vijf exemplaren van deze service die in mijn omgeving worden uitgevoerd'. Ze proberen de omgeving te laten overeenkomen met de gewenste status, ongeacht wat er gebeurt.

Orchestrators (niet mensen) ondernemen actie wanneer een machine uitvalt of een werkbelasting om een onverwachte reden wordt beëindigd. De meeste orchestrators doen meer dan alleen om te gaan met fouten. Andere functies die ze hebben, zijn het beheren van nieuwe implementaties, het verwerken van upgrades en het omgaan met resourceverbruik en governance. Alle orchestrators hebben fundamenteel betrekking op het onderhouden van een bepaalde gewenste configuratiestatus in de omgeving. U wilt een orchestrator kunnen vertellen wat u 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

Cluster Resource Manager is het systeemonderdeel dat indeling verwerkt in Service Fabric. De taak van 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 Cluster Resource Manager werkt:

Wat het niet is

In traditionele N-laagtoepassingen is er altijd een Load Balancer. Meestal was dit een Network Load Balancer (NLB) of een Application Load Balancer (ALB), afhankelijk van waar deze zich in de netwerkstack bevond. Sommige load balancers zijn hardware-gebaseerde, zoals het BigIP-aanbod van F5, andere zijn softwaregebaserend, zoals NLB van Microsoft. In andere omgevingen ziet u mogelijk iets als HAProxy, nginx, Istio of Envoy in deze rol. In deze architecturen is de taak van taakverdeling om ervoor te zorgen dat staatloze workloads dezelfde hoeveelheid werk ontvangen (ruwweg). Strategieën voor taakverdeling gevarieerd. Sommige balancers verzenden elke verschillende aanroep naar een andere server. Anderen kregen sessie vastmaken/plakkerigheid. Meer geavanceerde balancers maken gebruik van de werkelijke belastingschatting of rapportage om een aanroep te routeren op basis van de verwachte kosten en de huidige machinebelasting.

Netwerkverdelers of berichtrouters probeerden ervoor te zorgen dat de web-/werklaag ruwweg evenwichtig bleef. Strategieën voor het verdelen van de gegevenslaag waren verschillend en waren afhankelijk van het mechanisme voor gegevensopslag. Het verdelen van de gegevenslaag is afhankelijk van gegevenssharding, caching, beheerde weergaven, opgeslagen procedures en andere opslagspecifieke mechanismen.

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

Omdat Cluster Resource Manager verantwoordelijk is voor het verplaatsen van services, bevat deze een andere functieset vergeleken met wat u zou vinden in een netwerk load balancer. Dit komt doordat netwerktaakverdelers netwerkverkeer leveren aan waar services zich al bevinden, zelfs als die locatie niet ideaal is voor het uitvoeren van de service zelf. 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