Schalen in Service Fabric

Artikel
06/01/2023

Met Azure Service Fabric kunt u eenvoudig schaalbare toepassingen bouwen door de services, partities en replica's op de knooppunten van een cluster te beheren. Het uitvoeren van veel workloads op dezelfde hardware zorgt voor een maximaal resourcegebruik, maar biedt ook flexibiliteit wat betreft de manier waarop u ervoor kiest om uw workloads te schalen. In deze Channel 9-video wordt beschreven hoe u schaalbare microservicetoepassingen kunt bouwen:

Schalen in Service Fabric kan op verschillende manieren:

Schalen door stateless service-exemplaren te maken of te verwijderen
Schalen door nieuwe benoemde services te maken of te verwijderen
Schalen door nieuwe benoemde toepassingsexemplaren te maken of te verwijderen
Schalen met behulp van gepartitioneerde services
Schalen door knooppunten toe te voegen aan en te verwijderen uit het cluster
Schalen met behulp van metrische gegevens van cluster Resource Manager

Schalen door stateless service-exemplaren te maken of te verwijderen

Een van de eenvoudigste manieren om binnen Service Fabric te schalen, werkt met stateless services. Wanneer u een staatloze service maakt, krijgt u de kans om een InstanceCountte definiëren. InstanceCount definieert hoeveel actieve kopieën van de code van die service worden gemaakt wanneer de service wordt gestart. Stel dat er 100 knooppunten in het cluster zijn. Stel dat er een service wordt gemaakt met een InstanceCount van 10. Tijdens runtime kunnen die tien actieve exemplaren van de code allemaal te druk worden (of niet bezet genoeg zijn). Een manier om die workload te schalen, is door het aantal exemplaren te wijzigen. Een deel van de bewakings- of beheercode kan bijvoorbeeld het bestaande aantal exemplaren wijzigen in 50 of in 5, afhankelijk van of de workload moet worden in- of uitgeschaald op basis van de belasting.

C#:

StatelessServiceUpdateDescription updateDescription = new StatelessServiceUpdateDescription(); 
updateDescription.InstanceCount = 50;
await fabricClient.ServiceManager.UpdateServiceAsync(new Uri("fabric:/app/service"), updateDescription);

PowerShell:

Update-ServiceFabricService -Stateless -ServiceName $serviceName -InstanceCount 50

Dynamisch aantal exemplaren gebruiken

Met name voor stateless services biedt Service Fabric een automatische manier om het aantal exemplaren te wijzigen. Hierdoor kan de service dynamisch worden geschaald met het aantal beschikbare knooppunten. U kunt zich hiervoor aanmelden door het aantal exemplaren = -1 in te stellen. InstanceCount = -1 is een instructie voor Service Fabric met de tekst 'Voer deze stateless service uit op elk knooppunt'. Als het aantal knooppunten verandert, wijzigt Service Fabric automatisch het aantal exemplaren zodat deze overeenkomt, zodat de service wordt uitgevoerd op alle geldige knooppunten.

C#:

StatelessServiceDescription serviceDescription = new StatelessServiceDescription();
//Set other service properties necessary for creation....
serviceDescription.InstanceCount = -1;
await fc.ServiceManager.CreateServiceAsync(serviceDescription);

PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName -Stateless -PartitionSchemeSingleton -InstanceCount "-1"

Schalen door nieuwe benoemde services te maken of te verwijderen

Een benoemd service-exemplaar is een specifiek exemplaar van een servicetype (zie Levenscyclus van Service Fabric-toepassing) binnen een benoemd toepassingsexemplaar in het cluster.

Nieuwe benoemde service-exemplaren kunnen worden gemaakt (of verwijderd) naarmate services meer of minder bezet worden. Hierdoor kunnen aanvragen worden verdeeld over meer service-exemplaren, waardoor de belasting van bestaande services meestal kan afnemen. Bij het maken van services plaatst het Service Fabric-cluster Resource Manager de services op gedistribueerde wijze in het cluster. De exacte beslissingen worden bepaald door de metrische gegevens in het cluster en andere plaatsingsregels. Services kunnen op verschillende manieren worden gemaakt, maar de meest voorkomende zijn via beheeracties zoals iemand die aanroept New-ServiceFabricServiceof door code aan te roepen CreateServiceAsync. CreateServiceAsync kan zelfs worden aangeroepen vanuit andere services die in het cluster worden uitgevoerd.

Het dynamisch maken van services kan in allerlei scenario's worden gebruikt en is een veelvoorkomend patroon. Denk bijvoorbeeld aan een stateful service die een bepaalde werkstroom vertegenwoordigt. Aanroepen die werk vertegenwoordigen, worden weergegeven voor deze service en deze service voert de stappen voor die werkstroom uit en registreert de voortgang.

Hoe kunt u deze specifieke service schalen? De service kan in een bepaalde vorm meerdere tenants hebben en aanroepen accepteren en stappen starten voor veel verschillende exemplaren van dezelfde werkstroom, allemaal tegelijk. Dat kan de code echter complexer maken, omdat deze zich nu zorgen moet maken over veel verschillende exemplaren van dezelfde werkstroom, allemaal in verschillende fasen en van verschillende klanten. Bovendien wordt het schaalprobleem niet opgelost door meerdere werkstromen tegelijk te verwerken. Dit komt omdat deze service op een bepaald moment te veel resources verbruikt om op een bepaalde computer te passen. Veel services die in de eerste plaats niet voor dit patroon zijn gebouwd, ondervinden ook problemen vanwege een inherent knelpunt of vertraging in hun code. Dit soort problemen zorgen ervoor dat de service niet zo goed werkt wanneer het aantal gelijktijdige werkstromen dat wordt bijgehouden, groter wordt.

Een oplossing is om een exemplaar van deze service te maken voor elk ander exemplaar van de werkstroom die u wilt bijhouden. Dit is een geweldig patroon en werkt, ongeacht of de service staatloos of stateful is. Dit patroon werkt alleen als er een andere service is die fungeert als een Workload Manager-service. De taak van deze service bestaat uit het ontvangen van aanvragen en het routeren van deze aanvragen naar andere services. De manager kan dynamisch een exemplaar van de workloadservice maken wanneer deze het bericht ontvangt en vervolgens aanvragen doorsturen naar die services. De managerservice kan ook callbacks ontvangen wanneer een bepaalde werkstroomservice de taak voltooit. Wanneer de manager deze callbacks ontvangt, kan het exemplaar van de werkstroomservice worden verwijderd of worden verwijderd als er meer aanroepen worden verwacht.

Geavanceerde versies van dit type manager kunnen zelfs pools maken van de services die worden beheerd. De pool zorgt ervoor dat wanneer een nieuwe aanvraag binnenkomt, deze niet hoeft te wachten totdat de service wordt uitgevoerd. In plaats daarvan kan de manager een werkstroomservice kiezen die momenteel niet bezet is in de pool of willekeurig routeren. Door een pool van services beschikbaar te houden, worden nieuwe aanvragen sneller verwerkt, omdat het minder waarschijnlijk is dat de aanvraag moet wachten totdat een nieuwe service is geïmplementeerd. Het maken van nieuwe services is snel, maar niet gratis of onmiddellijk. De pool helpt de hoeveelheid tijd te minimaliseren die de aanvraag moet wachten voordat deze wordt verwerkt. U ziet dit manager- en poolpatroon vaak wanneer reactietijden het belangrijkst zijn. Het in de wachtrij plaatsen van de aanvraag en het maken van de service op de achtergrond en deze vervolgens doorgeven is ook een populair managerpatroon, net als het maken en verwijderen van services op basis van het bijhouden van de hoeveelheid werk waarvoor de service momenteel in behandeling is.

Schalen door nieuwe benoemde toepassingsexemplaren te maken of te verwijderen

Het maken en verwijderen van hele toepassingsexemplaren is vergelijkbaar met het patroon van het maken en verwijderen van services. Voor dit patroon is er een managerservice die de beslissing neemt op basis van de aanvragen die het ziet en de informatie die wordt ontvangen van de andere services in het cluster.

Wanneer moet u een nieuw benoemd toepassingsexemplaar maken in plaats van een nieuwe benoemde service-exemplaren te maken in een bestaande toepassing? Er zijn een paar gevallen:

Het nieuwe toepassingsexemplaar is bedoeld voor een klant waarvan de code moet worden uitgevoerd onder bepaalde identiteits- of beveiligingsinstellingen.
- Met Service Fabric kunnen verschillende codepakketten worden gedefinieerd die onder bepaalde identiteiten kunnen worden uitgevoerd. Als u hetzelfde codepakket wilt starten onder verschillende identiteiten, moeten de activeringen plaatsvinden in verschillende toepassingsexemplaren. Overweeg een geval waarin u de workloads van een bestaande klant hebt geïmplementeerd. Deze kunnen worden uitgevoerd onder een bepaalde identiteit, zodat u de toegang tot andere resources, zoals externe databases of andere systemen, kunt bewaken en beheren. In dit geval wilt u, wanneer een nieuwe klant zich aanmeldt, de code waarschijnlijk niet activeren in dezelfde context (procesruimte). Dit maakt het voor uw servicecode moeilijker om binnen de context van een bepaalde identiteit te handelen. Doorgaans moet u over meer beveiligings-, isolatie- en identiteitsbeheercode beschikken. In plaats van verschillende benoemde service-exemplaren binnen hetzelfde toepassingsexemplaar en dus dezelfde procesruimte te gebruiken, kunt u verschillende benoemde Service Fabric-toepassingsexemplaren gebruiken. Dit maakt het eenvoudiger om verschillende identiteitscontexten te definiëren.
Het nieuwe toepassingsexemplaar fungeert ook als een configuratiemiddel
- Standaard worden alle benoemde service-exemplaren van een bepaald servicetype in een toepassingsexemplaar in hetzelfde proces uitgevoerd op een bepaald knooppunt. Dit betekent dat hoewel u elk service-exemplaar anders kunt configureren, dit ingewikkeld is. Services moeten een token hebben dat ze gebruiken om hun configuratie op te zoeken in een configuratiepakket. Meestal is dit alleen de naam van de service. Dit werkt prima, maar koppelt de configuratie aan de namen van de afzonderlijke benoemde service-exemplaren binnen dat toepassingsexemplaar. Dit kan verwarrend en moeilijk te beheren zijn, omdat de configuratie normaal gesproken een ontwerptijdartefact is met specifieke waarden voor het toepassingsexemplaar. Het maken van meer services betekent altijd meer toepassingsupgrades om de informatie in de configuratiepakketten te wijzigen of om nieuwe pakketten te implementeren, zodat de nieuwe services hun specifieke informatie kunnen opzoeken. Het is vaak eenvoudiger om een geheel nieuw benoemd toepassingsexemplaar te maken. Vervolgens kunt u de toepassingsparameters gebruiken om de configuratie in te stellen die nodig is voor de services. Op deze manier kunnen alle services die in dat benoemde toepassingsexemplaar zijn gemaakt, bepaalde configuratie-instellingen overnemen. In plaats van bijvoorbeeld één configuratiebestand te hebben met de instellingen en aanpassingen voor elke klant, zoals geheimen of resourcelimieten per klant, hebt u in plaats daarvan een ander toepassingsexemplaar voor elke klant met deze instellingen overschreven.
De nieuwe toepassing fungeert als een upgradegrens
- Binnen Service Fabric dienen verschillende benoemde toepassingsexemplaren als grenzen voor een upgrade. Een upgrade van één benoemd toepassingsexemplaar heeft geen invloed op de code die een ander benoemd toepassingsexemplaar uitvoert. Op de verschillende toepassingen worden uiteindelijk verschillende versies van dezelfde code op dezelfde knooppunten uitgevoerd. Dit kan een factor zijn wanneer u een schaalbeslissing moet nemen, omdat u kunt kiezen of de nieuwe code dezelfde upgrades moet volgen als een andere service. Stel dat een aanroep binnenkomt bij de managerservice die verantwoordelijk is voor het schalen van de workloads van een bepaalde klant door services dynamisch te maken en te verwijderen. In dit geval is de aanroep echter voor een workload die is gekoppeld aan een nieuwe klant. De meeste klanten vinden het leuk om van elkaar te worden geïsoleerd, niet alleen vanwege de eerder genoemde beveiligings- en configuratieredenen, maar omdat het meer flexibiliteit biedt bij het uitvoeren van specifieke versies van de software en het kiezen wanneer ze worden bijgewerkt. U kunt ook een nieuw toepassingsexemplaar maken en daar de service maken om de hoeveelheid services die een upgrade raakt, verder te partitioneren. Afzonderlijke toepassingsexemplaren bieden meer granulariteit bij het uitvoeren van toepassingsupgrades en maken ook A/B-tests en Blauw/Groen-implementaties mogelijk.
Het bestaande toepassingsexemplaren is vol
- In Service Fabric is toepassingscapaciteit een concept dat u kunt gebruiken om de hoeveelheid beschikbare resources voor bepaalde toepassingsexemplaren te beheren. U kunt bijvoorbeeld besluiten dat voor een bepaalde service een ander exemplaar moet worden gemaakt om te kunnen schalen. Dit toepassingsexemplaren hebben echter geen capaciteit meer voor een bepaalde metrische waarde. Als aan deze specifieke klant of workload nog steeds meer resources moeten worden toegewezen, kunt u de bestaande capaciteit voor die toepassing vergroten of een nieuwe toepassing maken.

Schalen op partitieniveau

Service Fabric ondersteunt partitionering. Partitionering splitst een service in verschillende logische en fysieke secties, die elk onafhankelijk van elkaar werken. Dit is handig met stateful services, omdat geen enkele set replica's alle aanroepen tegelijk moet verwerken en alle statussen hoeft te manipuleren. Het overzicht van partitionering biedt informatie over de typen partitieschema's die worden ondersteund. De replica's van elke partitie zijn verspreid over de knooppunten in een cluster, waardoor de belasting van die service wordt gedistribueerd en ervoor wordt gezorgd dat noch de service als geheel, noch een partitie een Single Point of Failure heeft.

Overweeg een service die gebruikmaakt van een bereikpartitioneringsschema met een lage sleutel van 0, een hoge sleutel van 99 en een aantal partities van 4. In een cluster met drie knooppunten kan de service zijn ingedeeld met vier replica's die de resources op elk knooppunt delen, zoals hier wordt weergegeven:

Partitie-indeling met drie knooppunten

Als u het aantal knooppunten verhoogt, verplaatst Service Fabric een aantal van de bestaande replica's daarheen. Stel dat het aantal knooppunten toeneemt tot vier en dat de replica's opnieuw worden gedistribueerd. De service heeft nu drie replica's die op elk knooppunt worden uitgevoerd, die elk behoren tot verschillende partities. Dit zorgt voor een beter resourcegebruik omdat het nieuwe knooppunt niet koud is. Normaal gesproken worden de prestaties ook verbeterd omdat voor elke service meer resources beschikbaar zijn.

Partitie-indeling met vier knooppunten

Schalen met behulp van de Service Fabric-cluster Resource Manager en metrische gegevens

Metrische gegevens geven aan hoe services hun resourceverbruik naar Service Fabric uitdrukken. Het gebruik van metrische gegevens biedt de cluster-Resource Manager de mogelijkheid om de indeling van het cluster te herorganiseren en te optimaliseren. Het cluster kan bijvoorbeeld voldoende resources hebben, maar deze zijn mogelijk niet toegewezen aan de services die momenteel werken. Met behulp van metrische gegevens kan het cluster Resource Manager het cluster opnieuw ordenen om ervoor te zorgen dat services toegang hebben tot de beschikbare resources.

Schalen door knooppunten toe te voegen aan en te verwijderen uit het cluster

Een andere optie voor schalen met Service Fabric is het wijzigen van de grootte van het cluster. Als u de grootte van het cluster wijzigt, betekent dit dat u knooppunten voor een of meer van de knooppunttypen in het cluster toevoegt of verwijdert. Denk bijvoorbeeld aan een geval waarin alle knooppunten in het cluster dynamisch zijn. Dit betekent dat de resources van het cluster bijna allemaal worden verbruikt. In dit geval is het toevoegen van meer knooppunten aan het cluster de beste manier om te schalen. Zodra de nieuwe knooppunten deel uitmaken van het cluster, verplaatst het Service Fabric-cluster Resource Manager services naar de knooppunten, wat resulteert in minder totale belasting op de bestaande knooppunten. Voor stateless services met het aantal exemplaren = -1 worden automatisch meer service-exemplaren gemaakt. Hierdoor kunnen sommige aanroepen van de bestaande knooppunten naar de nieuwe knooppunten worden verplaatst.

Zie Clusterschalen voor meer informatie.

Een platform kiezen

Vanwege verschillen in implementatie tussen besturingssystemen kan het gebruik van Service Fabric met Windows of Linux een essentieel onderdeel zijn van het schalen van uw toepassing. Een mogelijke belemmering is de wijze waarop gefaseerde logboekregistratie wordt uitgevoerd. Service Fabric in Windows maakt gebruik van een kernelstuurprogramma voor een één-per-machine-logboek, gedeeld tussen stateful servicereplica's. Dit logboek weegt ongeveer 8 GB. Linux maakt daarentegen gebruik van een faseringslogboek van 256 MB voor elke replica, waardoor het minder ideaal is voor toepassingen die het aantal lichtgewicht servicereplica's willen maximaliseren dat op een bepaald knooppunt wordt uitgevoerd. Deze verschillen in tijdelijke opslagvereisten kunnen mogelijk het gewenste platform voor de implementatie van het Service Fabric-cluster informeren.

Alles samenvoegen

We nemen alle ideeën die we hier hebben besproken en bespreken een voorbeeld. Overweeg de volgende service: u probeert een service te bouwen die fungeert als een adresboek, waarbij u namen en contactgegevens vasthoudt.

Meteen hebt u een aantal vragen met betrekking tot schalen: Hoeveel gebruikers gaat u hebben? Hoeveel contactpersonen slaat elke gebruiker op? Het is moeilijk om dit allemaal te achterhalen wanneer u uw service voor de eerste keer opgeeft. Stel dat u voor één statische service met een specifiek aantal partities zou gaan. De gevolgen van het kiezen van het verkeerde aantal partities kunnen ertoe leiden dat u later schaalproblemen krijgt. En zelfs als u het juiste aantal kiest, beschikt u mogelijk niet over alle informatie die u nodig hebt. U moet bijvoorbeeld ook vooraf de grootte van het cluster bepalen, zowel wat betreft het aantal knooppunten als de grootte ervan. Het is meestal moeilijk om te voorspellen hoeveel resources een service in de loop van de levensduur gaat verbruiken. Het kan ook moeilijk zijn om van tevoren te weten welk verkeerspatroon de service daadwerkelijk ziet. Misschien kunnen mensen hun contactpersonen alleen 's ochtends toevoegen en verwijderen, of misschien wordt het gelijkmatig verdeeld over de dag. Op basis hiervan moet u mogelijk dynamisch uitschalen en inschalen. Misschien kunt u leren voorspellen wanneer u moet uitschalen en inschalen, maar in beide gevallen moet u waarschijnlijk reageren op veranderend resourceverbruik door uw service. Dit kan betekenen dat de grootte van het cluster wordt gewijzigd om meer resources te bieden wanneer het opnieuw organiseren van het gebruik van bestaande resources niet voldoende is.

Maar waarom zou u zelfs proberen om één partitieschema te kiezen voor alle gebruikers? Waarom zou u zich beperken tot één service en één statisch cluster? De werkelijke situatie is meestal dynamischer.

Houd bij het bouwen voor schaal rekening met het volgende dynamische patroon. Mogelijk moet u deze aanpassen aan uw situatie:

In plaats van vooraf een partitioneringsschema voor iedereen te kiezen, bouwt u een 'managerservice'.
De taak van de managerservice is om klantgegevens te bekijken wanneer ze zich registreren voor uw service. Afhankelijk van die informatie maakt de managerservice vervolgens een exemplaar van uw werkelijke service voor contactopslag voor die klant. Als ze een bepaalde configuratie, isolatie of upgrades vereisen, kunt u ook besluiten om een toepassingsexemplaren voor deze klant te maken.

Dit patroon voor dynamisch maken biedt veel voordelen:

U probeert niet vooraf het juiste aantal partities voor alle gebruikers te raden of één service te bouwen die volledig zelf oneindig schaalbaar is.
Verschillende gebruikers hoeven niet hetzelfde aantal partities, replica's, plaatsingsbeperkingen, metrische gegevens, standaardbelastingen, servicenamen, DNS-instellingen of een van de andere eigenschappen te hebben die zijn opgegeven op service- of toepassingsniveau.
U krijgt extra gegevenssegmentatie. Elke klant heeft een eigen kopie van de service
- Elke klantenservice kan anders worden geconfigureerd en meer of minder resources worden verleend, met meer of minder partities of replica's, indien nodig op basis van de verwachte schaal.
  - Stel dat de klant heeft betaald voor de 'Gold'-laag. Deze kan meer replica's of een groter aantal partities krijgen, en mogelijk resources die zijn toegewezen aan hun services via metrische gegevens en toepassingscapaciteiten.
  - Of stel dat ze informatie hebben opgegeven die aangeeft dat het aantal contactpersonen dat ze nodig hadden klein was. Ze zouden slechts een paar partities krijgen of zelfs in een gedeelde servicegroep met andere klanten kunnen worden geplaatst.
U voert geen aantal service-exemplaren of replica's uit terwijl u wacht totdat klanten worden weergegeven
Als een klant ooit vertrekt, is het verwijderen van de gegevens uit uw service net zo eenvoudig als het verwijderen van de manager die service of toepassing die deze heeft gemaakt.

Volgende stappen

Zie de volgende artikelen voor meer informatie over Service Fabric-concepten: