Delen via

Defragmentatie van metrische gegevens en belasting in Service Fabric

  • Artikel

De standaardstrategie van Service Fabric Cluster Resource Manager voor het beheren van metrische gegevens over belasting in het cluster is het distribueren van de belasting. Ervoor zorgen dat knooppunten gelijkmatig worden gebruikt, voorkomt dynamische en koude plekken die leiden tot conflicten en verspilde resources. Het distribueren van workloads in het cluster is ook het veiligste in termen van overlevende fouten, omdat een storing geen groot percentage van een bepaalde workload uitneemt.

Service Fabric Cluster Resource Manager biedt wel ondersteuning voor een andere strategie voor het beheren van belasting, wat defragmentatie is. Defragmentatie betekent dat in plaats van het gebruik van een metrische waarde over het cluster te verdelen, deze wordt geconsolideerd. Consolidatie is slechts een inversie van de standaardverdelingsstrategie, in plaats van de gemiddelde standaarddeviatie van de metrische belasting te minimaliseren, probeert Cluster Resource Manager deze te verhogen.

Wanneer moet u defragmentatie gebruiken

Het distribueren van de belasting in het cluster verbruikt enkele van de resources op elk knooppunt. Sommige workloads maken services die uitzonderlijk groot zijn en de meeste of alle knooppunten verbruiken. In dergelijke gevallen is het mogelijk dat wanneer er grote workloads worden gemaakt, er onvoldoende ruimte is op een knooppunt om ze uit te voeren. Grote workloads zijn geen probleem in Service Fabric; In deze gevallen bepaalt de Cluster Resource Manager dat het cluster opnieuw moet worden georganiseert om ruimte te maken voor deze grote werkbelasting. In de tussentijd moet de werkbelasting echter wachten om te worden gepland in het cluster.

Als er veel services en status zijn om te navigeren, kan het lang duren voordat de grote werkbelasting in het cluster wordt geplaatst. Dit is waarschijnlijker als andere workloads in het cluster ook groot zijn en het dus langer duurt om opnieuw te organiseren. Het Service Fabric-team heeft de aanmaaktijden gemeten in simulaties van dit scenario. We hebben vastgesteld dat het maken van grote services veel langer duurde zodra het clustergebruik hoger was dan 30% en 50%. Om dit scenario af te handelen, hebben we defragmentatie geïntroduceerd als een evenwichtsstrategie. We hebben vastgesteld dat voor grote workloads, met name werkbelastingen waar de aanmaaktijd belangrijk was, defragmentatie echt heeft geholpen bij het plannen van deze nieuwe workloads in het cluster.

U kunt metrische gegevens over de fragmentatie zo configureren dat Cluster Resource Manager proactief probeert de belasting van de services te verkorten in minder knooppunten. Dit zorgt ervoor dat er bijna altijd ruimte is voor grote services zonder het cluster opnieuw te organiseren. Als u het cluster niet opnieuw hoeft te organiseren, kunt u snel grote workloads maken.

De meeste mensen hebben geen defragmentatie nodig. Services zijn meestal klein, dus het is niet moeilijk om ruimte te vinden in het cluster. Wanneer reorganisatie mogelijk is, gaat het snel, opnieuw omdat de meeste services klein zijn en snel en parallel kunnen worden verplaatst. Als u echter grote services hebt en ze snel wilt maken, is de defragmentatiestrategie voor u. Hierna bespreken we de compromissen van het gebruik van defragmentatie.

Compromissen tussen de fragmentatie

Defragmentatie kan de impact van fouten vergroten, omdat er meer services worden uitgevoerd op knooppunten die mislukken. Defragmentatie kan ook de kosten verhogen, omdat resources in het cluster in reserve moeten worden bewaard, wachtend op het maken van grote workloads.

Het volgende diagram geeft een visuele weergave van twee clusters, een die is gedefragmenteerd en een cluster dat niet is.

Evenwichtige en gedefragmenteerde clusters vergelijken

Houd in het evenwichtige geval rekening met het aantal verplaatsingen dat nodig is om een van de grootste serviceobjecten te plaatsen. In het gedefragmenteerde cluster kan de grote werkbelasting worden geplaatst op knooppunten vier of vijf zonder te hoeven wachten tot andere services zijn verplaatst.

Defragmentatie voor- en nadelen

Wat zijn die andere conceptuele compromissen? Hier volgt een korte tabel met dingen die u moet bedenken:

Defragmentatie pro's Defragmentatie cons
Maakt het sneller maken van grote services mogelijk Focust de belasting op minder knooppunten, waardoor conflicten toenemen
Maakt lagere gegevensverplaatsing mogelijk tijdens het maken Fouten kunnen van invloed zijn op meer services en leiden tot meer verloop
Biedt een uitgebreide beschrijving van vereisten en het terugroepen van ruimte Complexere algemene resourcebeheerconfiguratie

U kunt gedefragmenteerde en normale metrische gegevens in hetzelfde cluster combineren. De Cluster Resource Manager probeert de metrische gegevens over de fragmentatie zoveel mogelijk samen te voegen terwijl de andere worden uitgespreid. De resultaten van het mengen van defragmentatie- en evenwichtsstrategieën zijn afhankelijk van verschillende factoren, waaronder:

  • het aantal metrische gegevens voor taakverdeling versus het aantal metrische gegevens over de fragmentatie
  • Of een service beide typen metrische gegevens gebruikt
  • de metrische gewichten
  • huidige metrische belasting

Experimenten zijn vereist om de exacte configuratie te bepalen die nodig is. We raden u aan om uw workloads grondig te meten voordat u metrische gegevens over de fragmentatie in productie inschakelt. Dit geldt met name bij het combineren van defragmentatie en evenwichtige metrische gegevens binnen dezelfde service.

Metrische gegevens over defragmentatie configureren

Het configureren van metrische gegevens over de fragmentatie is een globale beslissing in het cluster en afzonderlijke metrische gegevens kunnen worden geselecteerd voor defragmentatie. In de volgende configuratiefragmenten ziet u hoe u metrische gegevens configureert voor defragmentatie. In dit geval is 'Metric1' geconfigureerd als een defragmentatiemetriek, terwijl 'Metric2' normaal wordt verdeeld.

ClusterManifest.xml:

<Section Name="DefragmentationMetrics">
    <Parameter Name="Metric1" Value="true" />
    <Parameter Name="Metric2" Value="false" />
</Section>

via ClusterConfig.json voor zelfstandige implementaties of Template.json voor gehoste Azure-clusters:

"fabricSettings": [
  {
    "name": "DefragmentationMetrics",
    "parameters": [
      {
          "name": "Metric1",
          "value": "true"
      },
      {
          "name": "Metric2",
          "value": "false"
      }
    ]
  }
]

Volgende stappen