Overzicht van de architectuur van clusterresourcebeheer

Het Service Fabric-cluster Resource Manager is een centrale service die in het cluster wordt uitgevoerd. Het beheert de gewenste status van de services in het cluster, met name met betrekking tot het resourceverbruik en eventuele plaatsingsregels.

Als u de resources in uw cluster wilt beheren, moet het Service Fabric-cluster Resource Manager verschillende gegevens bevatten:

• Welke services er momenteel bestaan
• Het huidige (of standaard) resourceverbruik van elke service
• De resterende clustercapaciteit
• De capaciteit van de knooppunten in het cluster
• De hoeveelheid resources die op elk knooppunt wordt verbruikt

Het resourceverbruik van een bepaalde service kan in de loop van de tijd veranderen en services hebben meestal betrekking op meer dan één type resource. In verschillende services kunnen er zowel echte fysieke als fysieke resources worden gemeten. Services kunnen fysieke metrische gegevens bijhouden, zoals geheugen- en schijfverbruik. Meestal geven services om logische metrische gegevens, zoals 'WorkQueueDepth' of 'TotalRequests'. Zowel logische als fysieke metrische gegevens kunnen in hetzelfde cluster worden gebruikt. Metrische gegevens kunnen worden gedeeld tussen veel services of specifiek zijn voor een bepaalde service.

Andere overwegingen

De eigenaren en operators van het cluster kunnen verschillen van de service- en toepassingsauteurs, of zijn minimaal dezelfde personen die verschillende hoeden dragen. Wanneer u uw toepassing ontwikkelt, weet u een paar dingen over wat er nodig is. U hebt een schatting van de resources die worden gebruikt en hoe verschillende services moeten worden geïmplementeerd. De weblaag moet bijvoorbeeld worden uitgevoerd op knooppunten die zijn blootgesteld aan internet, terwijl de databaseservices dat niet doen. Een ander voorbeeld is dat de webservices waarschijnlijk worden beperkt door CPU en netwerk, terwijl de services van de gegevenslaag meer om geheugen- en schijfverbruik geven. De persoon die een live-site-incident voor die service in productie afhandelt of die een upgrade naar de service beheert, heeft echter een andere taak te doen en heeft verschillende hulpprogramma's nodig.

Zowel het cluster als de services zijn dynamisch:

• Het aantal knooppunten in het cluster kan toenemen en verkleinen
• Knooppunten van verschillende grootten en typen kunnen komen en gaan
• Services kunnen worden gemaakt, verwijderd en de gewenste resourcetoewijzingen en plaatsingsregels wijzigen
• Upgrades of andere beheerbewerkingen kunnen op infrastructuurniveau door het cluster in de toepassing worden gerold
• Fouten kunnen op elk gewenst moment optreden.

Onderdelen en gegevensstroom van clusterresourcebeheer

De Cluster-Resource Manager moet de vereisten van elke service en het verbruik van resources door elk serviceobject in die services bijhouden. De cluster-Resource Manager bestaat uit twee conceptonderdelen: agents die op elk knooppunt worden uitgevoerd en een fouttolerante service. De agents op elk knooppunt houden belastingsrapporten van services bij, aggregeren ze en rapporteren ze periodiek. De Cluster Resource Manager-service voegt alle informatie van de lokale agents samen en reageert op basis van de huidige configuratie.

Laten we eens kijken naar het volgende diagram:

Tijdens runtime zijn er veel wijzigingen die kunnen optreden. Stel bijvoorbeeld dat de hoeveelheid resources die sommige services verbruiken wijzigingen, sommige services mislukken en sommige knooppunten het cluster koppelen en verlaten. Alle wijzigingen op een knooppunt worden geaggregeerd en periodiek verzonden naar de Cluster Resource Manager-service (1,2), waar ze opnieuw worden geaggregeerd, geanalyseerd en opgeslagen. Om de paar seconden bekijkt de service de wijzigingen en bepaalt deze of er acties nodig zijn (3). Er kunnen bijvoorbeeld enkele lege knooppunten aan het cluster zijn toegevoegd. Als gevolg hiervan wordt besloten om sommige services naar die knooppunten te verplaatsen. De cluster-Resource Manager kan ook merken dat een bepaald knooppunt overbelast is of dat bepaalde services zijn mislukt of zijn verwijderd, waardoor resources elders worden vrijgemaakt.

Laten we het volgende diagram eens bekijken en zien wat er vervolgens gebeurt. Stel dat de Cluster-Resource Manager bepaalt dat er wijzigingen nodig zijn. Het coördineert met andere systeemservices (met name failoverbeheer) om de benodigde wijzigingen aan te brengen. Vervolgens worden de benodigde opdrachten verzonden naar de juiste knooppunten (4). Stel dat de Resource Manager gemerkt dat Node5 overbelast was en dus besloot om service B te verplaatsen van Node5 naar Node4. Aan het einde van de herconfiguratie (5) ziet het cluster er als volgt uit:

Volgende stappen

• De 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 hierover
• De primaire taken van de cluster Resource Manager zijn het opnieuw verdelen van het cluster en het afdwingen van plaatsingsregels. Zie Uw Service Fabric-cluster in balans brengen voor meer informatie over het configureren van dit gedrag.