Dela via

Kostnader för tjänstflytt

  • Artikel

En faktor som Service Fabric Cluster Resource Manager tar hänsyn till när du försöker avgöra vilka ändringar som ska utföras i ett kluster är kostnaden för dessa ändringar. Begreppet "kostnad" handlas bort mot hur mycket klustret kan förbättras. Kostnaden räknas in vid flytt av tjänster för balansering, defragmentering och andra krav. Målet är att uppfylla kraven på det minst störande eller dyra sättet.

Att flytta tjänster kostar cpu-tid och nätverksbandbredd minst. För tillståndskänsliga tjänster kräver det att du kopierar tillståndet för dessa tjänster och förbrukar ytterligare minne och disk. Att minimera kostnaden för lösningar som Azure Service Fabric Cluster Resource Manager kommer med hjälper till att säkerställa att klustrets resurser inte används i onödan. Men du vill inte heller ignorera lösningar som avsevärt skulle förbättra allokeringen av resurser i klustret.

Klusterresurshanteraren har två sätt att beräkna kostnader och begränsa dem när det försöker hantera klustret. Den första mekanismen är helt enkelt att räkna varje drag som den skulle göra. Om två lösningar genereras med ungefär samma saldo (poäng) föredrar Klusterresurshanteraren den med den lägsta kostnaden (totalt antal flyttningar).

Den här strategin fungerar bra. Men som med standard- eller statiska belastningar är det osannolikt i något komplext system att alla rörelser är lika. Vissa kommer sannolikt att bli mycket dyrare.

Ange flyttkostnader

Du kan ange standardkostnaden för flytt för en tjänst när den skapas:

PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton -DefaultMoveCost Medium

C#:

FabricClient fabricClient = new FabricClient();
StatefulServiceDescription serviceDescription = new StatefulServiceDescription();
//set up the rest of the ServiceDescription
serviceDescription.DefaultMoveCost = MoveCost.Medium;
await fabricClient.ServiceManager.CreateServiceAsync(serviceDescription);

Du kan också ange eller uppdatera MoveCost dynamiskt för en tjänst när tjänsten har skapats:

PowerShell:

Update-ServiceFabricService -Stateful -ServiceName "fabric:/AppName/ServiceName" -DefaultMoveCost High

C#:

StatefulServiceUpdateDescription updateDescription = new StatefulServiceUpdateDescription();
updateDescription.DefaultMoveCost = MoveCost.High;
await fabricClient.ServiceManager.UpdateServiceAsync(new Uri("fabric:/AppName/ServiceName"), updateDescription);

Dynamiskt ange flyttkostnad per replik

De föregående kodfragmenten är alla för att ange MoveCost för en hel tjänst samtidigt utanför själva tjänsten. Flyttkostnaden är dock mest användbar när flyttkostnaden för ett specifikt tjänstobjekt ändras under dess livslängd. Eftersom tjänsterna i sig förmodligen har den bästa uppfattningen om hur kostsamma de är att flytta en viss tid finns det ett API för tjänster som rapporterar sin egen individuella flyttkostnad under körningen.

C#:

this.Partition.ReportMoveCost(MoveCost.Medium);

Kommentar

Du kan bara ange flyttkostnaden för sekundära repliker via kod.

Rapporteringskostnad för flytt för en partition

I föregående avsnitt beskrivs hur tjänstrepliker eller instanser rapporterar MoveCost själva. Vi tillhandahöll Service Fabric API för rapportering av MoveCost-värden för andra partitioner. Ibland kan tjänstreplik eller instans inte avgöra det bästa MoveCost-värdet på egen hand och måste förlita sig på annan tjänstlogik. Genom att rapportera MoveCost för andra partitioner, tillsammans med rapporteringsbelastning för andra partitioner, kan du helt hantera partitioner utifrån. Dessa API:er eliminerar behovet av sidecar-mönstret ur klusterresurshanterarens perspektiv.

Du kan rapportera MoveCost-uppdateringar för en annan partition med samma API-anrop. Du måste ange PartitionMoveCostDescription-objekt för varje partition som du vill uppdatera med nya värden för MoveCost. API:et tillåter flera sätt att uppdatera MoveCost:

  • En tillståndskänslig tjänstpartition kan uppdatera sin primära replik MoveCost.
  • Både tillståndslösa och tillståndskänsliga tjänster kan uppdatera MoveCost för alla dess sekundära repliker eller instanser.
  • Både tillståndslösa och tillståndskänsliga tjänster kan uppdatera MoveCost för en specifik replik eller instans på en nod.

Varje MoveCost-uppdatering för partitionen bör innehålla minst ett giltigt värde som kommer att ändras. Du kan till exempel hoppa över den primära replikuppdateringen med att tilldela null till den primära replikposten, andra poster används under MoveCost-uppdateringen och vi hoppar över MoveCost-uppdateringen för den primära repliken. Eftersom det är möjligt att uppdatera MoveCost för flera partitioner med ett enda API-anrop, tillhandahåller API en lista med returkoder för motsvarande partition. Om vi accepterar och bearbetar en begäran om MoveCost-uppdatering kommer returkoden att lyckas. Annars tillhandahåller API:et felkod:

  • PartitionNotFound – angivet partitions-ID finns inte.
  • Omkonfiguration väntar – partitionen konfigureras för närvarande om.
  • InvalidForStatelessServices – Ett försök gjordes att ändra MoveCost för en primär replik för en partition som tillhör en tillståndslös tjänst.
  • ReplicaDoesNotExist – Sekundär replik eller instans finns inte på en angiven nod.
  • InvalidOperation – Uppdaterar MoveCost för en partition som tillhör systemprogrammet.

C#:

Guid partitionId = Guid.Parse("53df3d7f-5471-403b-b736-bde6ad584f42");
string nodeName0 = "NodeName0";

OperationResult<UpdatePartitionMoveCostResultList> updatePartitionMoveCostResults =
    await this.FabricClient.UpdatePartitionMoveCostAsync(
        new UpdatePartitionMoveCostQueryDescription
        {
            new List<PartitionMoveCostDescription>()
            {
                new PartitionMoveCostDescription(
                    partitionId,
                    MoveCost.VeryHigh,
                    MoveCost.Zero,
                    new List<ReplicaMoveCostDescription>()
                    {
                        new ReplicaMoveCostDescription(nodeName0, MoveCost.Medium)
                    })
            }
        },
        this.Timeout,
        cancellationToken);

I det här exemplet utför du en uppdatering av den senaste rapporterade flyttkostnaden för en partition 53df3d7f-5471-403b-b736-bde6ad584f42. Kostnaden för primär replikflytt blir VeryHigh. Alla sekundära replikers flyttkostnad är Noll, förutom flyttkostnad för en specifik sekundär replik som finns på noden NodeName0. Flyttkostnaden för en specifik replik blir Medel. Om du vill hoppa över uppdatering av flyttkostnaden för den primära repliken eller alla sekundära repliker kan du lämna motsvarande post som null.

Påverkan av flyttkostnader

MoveCost har fem nivåer: Zero, Low, Medium, High och VeryHigh. Följande regler gäller:

  • MoveCosts är relativa till varandra, förutom Noll och VeryHigh.
  • Nollflyttningskostnad innebär att rörelsen är fri och inte ska räknas mot lösningens poäng.
  • Att ange flyttkostnaden till Hög eller VeryHigh ger ingen garanti för att repliken aldrig flyttas.
  • Repliker med VeryHigh-flyttkostnad flyttas endast om det finns en begränsningsöverträdelse i klustret som inte kan åtgärdas på något annat sätt (även om det krävs att många andra repliker flyttas för att åtgärda överträdelsen)

Flytta kostnad som en faktor för att välja repliker för förflyttning

MoveCost hjälper dig att hitta de lösningar som orsakar minst störningar överlag och är enklast att uppnå när du fortfarande anländer till motsvarande balans. En tjänsts kostnadsbegrepp kan vara relativt många saker. De vanligaste faktorerna vid beräkning av flyttkostnaden är:

  • Mängden tillstånd eller data som tjänsten måste flytta.
  • Kostnaden för frånkoppling av klienter. Att flytta en primär replik är vanligtvis dyrare än kostnaden för att flytta en sekundär replik.
  • Kostnaden för att avbryta en flygning. Vissa åtgärder på datalagernivå eller åtgärder som utförs som svar på ett klientanrop är kostsamma. Efter en viss punkt vill du inte stoppa dem om du inte behöver. Så medan åtgärden pågår ökar du flyttkostnaden för det här tjänstobjektet för att minska sannolikheten för att det flyttas. När åtgärden är klar ställer du in kostnaden tillbaka till det normala.

Viktigt!

Användning av VeryHigh-flyttkostnaden bör övervägas noggrant eftersom det avsevärt begränsar möjligheten för Klusterresurshanteraren att hitta en globalt optimal placeringslösning i klustret. Repliker med VeryHigh-flyttkostnad flyttas endast om det finns en begränsningsöverträdelse i klustret som inte kan åtgärdas på något annat sätt (även om det krävs att många andra repliker flyttas för att åtgärda överträdelsen)

Aktivera flyttkostnad i klustret

För att du ska kunna ta hänsyn till de mer detaljerade MoveCosts måste MoveCost vara aktiverat i klustret. Utan den här inställningen används standardläget för att räkna flyttningar för att beräkna MoveCost- och MoveCost-rapporter ignoreras.

ClusterManifest.xml:

        <Section Name="PlacementAndLoadBalancing">
            <Parameter Name="UseMoveCostReports" Value="true" />
        </Section>

via ClusterConfig.json för fristående distributioner eller Template.json för Azure-värdbaserade kluster:

"fabricSettings": [
  {
    "name": "PlacementAndLoadBalancing",
    "parameters": [
      {
          "name": "UseMoveCostReports",
          "value": "true"
      }
    ]
  }
]

Nästa steg