Een Service Fabric cluster beschrijven met behulp van Cluster Resource Manager

De Cluster Resource Manager functie van Azure Service Fabric biedt verschillende mechanismen voor het beschrijven van een cluster:

• Foutdomeinen
• Domeinen upgraden
• Knooppunteigenschappen
• Knooppuntcapaciteiten

Tijdens runtime gebruikt Cluster Resource Manager informatie om hoge beschikbaarheid te garanderen van de services die in het cluster worden uitgevoerd. Tijdens het afdwingen van deze belangrijke regels wordt ook geprobeerd het resourceverbruik binnen het cluster te optimaliseren.

Foutdomeinen

Een foutdomein is een gebied van gecoördineerde fouten. Eén computer is een foutdomein. Het kan om verschillende redenen zelf mislukken, van stroomstoringen tot storingen in slechte NIC-firmware.

Machines die zijn verbonden met dezelfde Ethernet-switch, zijn in hetzelfde foutdomein. Machines die één stroombron of op één locatie delen, zijn dat ook.

Omdat hardwarefouten elkaar natuurlijk overlappen, zijn foutdomeinen inherent hiërarchisch. Ze worden weergegeven als URI's in Service Fabric.

Het is belangrijk dat foutdomeinen correct zijn ingesteld omdat Service Fabric deze informatie gebruikt om veilig services te plaatsen. Service Fabric wilt geen services zo plaatsen dat het verlies van een foutdomein (veroorzaakt door het uitvallen van een onderdeel) ervoor zorgt dat een service uitvallen.

In de Azure-omgeving gebruikt Service Fabric foutdomeingegevens van de omgeving om namens u de knooppunten in het cluster correct te configureren. Voor zelfstandige exemplaren van Service Fabric worden foutdomeinen gedefinieerd op het moment dat het cluster wordt ingesteld.

In de volgende afbeelding kleuren we alle entiteiten die bijdragen aan foutdomeinen en geven we een lijst weer van alle verschillende foutdomeinen die het resultaat zijn. In dit voorbeeld hebben we datacenters (DC), rekken (R) en blades ('B'). Als elke blade meer dan één virtuele machine bevat, is er mogelijk een andere laag in de foutdomeinhiërarchie.

Tijdens runtime worden Service Fabric Cluster Resource Manager foutdomeinen in de cluster- en planindelingen in overweging. De stateful replica's of staatloze exemplaren voor een service worden gedistribueerd, zodat ze zich in afzonderlijke foutdomeinen. Het distribueren van de service over foutdomeinen zorgt ervoor dat de beschikbaarheid van de service niet wordt aangetast wanneer een foutdomein op elk niveau van de hiërarchie uitvalt.

Cluster Resource Manager maakt het niet uit hoeveel lagen er in de foutdomeinhiërarchie zijn. Er wordt geprobeerd ervoor te zorgen dat het verlies van een deel van de hiërarchie geen invloed heeft op de services die in de hiërarchie worden uitgevoerd.

Het is het beste als hetzelfde aantal knooppunten zich op elk niveau in de foutdomeinhiërarchie in de hiërarchie van het foutdomein voordeed. Als de 'structuur' van foutdomeinen niet in balans is in uw cluster, is het moeilijker voor Cluster Resource Manager om de beste toewijzing van services te achterhalen. Ongelijke indelingen van foutdomeinen betekenen dat het verlies van sommige domeinen meer invloed heeft op de beschikbaarheid van services dan andere domeinen. Als gevolg hiervan Cluster Resource Manager twee doelen verdeeld:

• Het wil de machines in dat 'zware' domein gebruiken door er services op te plaatsen.
• Het wil services in andere domeinen plaatsen, zodat het verlies van een domein geen problemen veroorzaakt.

Hoe zien onevenwichtige domeinen eruit? In het volgende diagram ziet u twee verschillende clusterindelingen. In het eerste voorbeeld worden de knooppunten gelijkmatig verdeeld over de foutdomeinen. In het tweede voorbeeld heeft het ene foutdomein veel meer knooppunten dan de andere foutdomeinen.

In Azure wordt de keuze welk foutdomein een knooppunt bevat voor u beheerd. Maar afhankelijk van het aantal knooppunten dat u inrichten, kunt u nog steeds foutdomeinen krijgen met meer knooppunten dan in andere.

Stel dat u vijf foutdomeinen in het cluster hebt, maar zeven knooppunten inrichten voor een knooppunttype (NodeType). In dit geval bevatten de eerste twee foutdomeinen meer knooppunten. Als u meer NodeType-exemplaren met slechts een paar exemplaren blijft implementeren, wordt het probleem alleen maar groter. Daarom raden we aan dat het aantal knooppunten in elk knooppunttype een veelvoud van het aantal foutdomeinen is.

Domeinen upgraden

Upgradedomeinen zijn een andere functie die u helpt Service Fabric Cluster Resource Manager de indeling van het cluster te begrijpen. Upgradedomeinen definiëren sets knooppunten die tegelijkertijd worden bijgewerkt. Upgradedomeinen helpen Cluster Resource Manager beheerbewerkingen zoals upgrades te begrijpen en te beheren.

Upgradedomeinen zijn veel lijkt op foutdomeinen, maar met een paar belangrijke verschillen. Ten eerste definiëren gebieden van gecoördineerde hardwarefouten foutdomeinen. Upgradedomeinen worden daarentegen gedefinieerd door beleid. U kunt zelf bepalen hoeveel u wilt, in plaats van dat de omgeving het aantal dicteert. U kunt net zoveel upgradedomeinen hebben als knooppunten. Een ander verschil tussen foutdomeinen en upgradedomeinen is dat upgradedomeinen niet hiërarchisch zijn. In plaats daarvan zijn ze meer een eenvoudige tag.

In het volgende diagram ziet u drie upgradedomeinen die zijn gestriped over drie foutdomeinen. Er wordt ook één mogelijke plaatsing weergegeven voor drie verschillende replica's van een stateful service, waarbij elk in verschillende fout- en upgradedomeinen belandt. Door deze plaatsing kan een foutdomein verloren gaan tijdens een service-upgrade en is er nog steeds één kopie van de code en gegevens.

Er zijn voor- en nadelen als er grote aantallen upgradedomeinen zijn. Meer upgradedomeinen betekenen dat elke stap van de upgrade gedetailleerder is en van invloed is op een kleiner aantal knooppunten of services. Er moeten minder services tegelijk worden verplaatst, wat minder verloop in het systeem introduceert. Dit verbetert doorgaans de betrouwbaarheid, omdat minder van de service wordt beïnvloed door een probleem dat tijdens de upgrade is geïntroduceerd. Meer upgradedomeinen betekenen ook dat u minder beschikbare buffer op andere knooppunten nodig hebt om de impact van de upgrade te verwerken.

Als u bijvoorbeeld vijf upgradedomeinen hebt, verwerken de knooppunten in elk domein ongeveer 20 procent van uw verkeer. Als u dat upgradedomein voor een upgrade wilt uitvoeren, moet die belasting meestal ergens naartoe gaan. Omdat u vier resterende upgradedomeinen hebt, moet elk domein ruimte hebben voor ongeveer 25 procent van het totale verkeer. Meer upgradedomeinen betekenen dat u minder buffer nodig hebt op de knooppunten in het cluster.

Overweeg of u in plaats daarvan tien upgradedomeinen hebt. In dat geval zou elk upgradedomein slechts ongeveer 10 procent van het totale verkeer verwerken. Wanneer een upgrade via het cluster wordt uitgevoerd, moet elk domein ruimte hebben voor slechts ongeveer 11 procent van het totale verkeer. Met meer upgradedomeinen kunt u over het algemeen uw knooppunten uitvoeren bij een hoger gebruik, omdat u minder gereserveerde capaciteit nodig hebt. Hetzelfde geldt voor foutdomeinen.

Het nadeel van een groot aantal upgradedomeinen is dat upgrades vaak langer duren. Service Fabric wacht een korte periode nadat een upgradedomein is voltooid en voert controles uit voordat de volgende upgrade wordt uitgevoerd. Deze vertragingen maken het mogelijk om problemen te detecteren die tijdens de upgrade zijn geïntroduceerd voordat de upgrade wordt uitgevoerd. De afweging is acceptabel omdat hierdoor wordt voorkomen dat slechte wijzigingen te veel van de service tegelijk beïnvloeden.

De aanwezigheid van te weinig upgradedomeinen heeft veel negatieve neveneffecten. Terwijl elk upgradedomein niet beschikbaar is en wordt bijgewerkt, is een groot deel van uw totale capaciteit niet beschikbaar. Als u bijvoorbeeld slechts drie upgradedomeinen hebt, neemt u ongeveer een derde van de totale service- of clustercapaciteit tegelijk in gebruik. Het is niet wenselijk om een groot deel van uw service in één keer uit te zetten, omdat u in de rest van uw cluster voldoende capaciteit nodig hebt om de workload te verwerken. Als u deze buffer onderhoudt, worden deze knooppunten tijdens de normale werking minder belast dan anders. Dit verhoogt de kosten voor het uitvoeren van uw service.

Er is geen echte limiet voor het totale aantal fout- of upgradedomeinen in een omgeving, of beperkingen voor hoe ze overlappen. Maar er zijn algemene patronen:

• Foutdomeinen en upgradedomeinen 1:1
• Eén upgradedomein per knooppunt (fysiek of virtueel besturingssysteem))
• Een 'striped' of 'matrix'-model waarbij de foutdomeinen en upgradedomeinen een matrix vormen met machines die doorgaans over de diagonalen lopen

Er is geen beste antwoord voor welke indeling u moet kiezen. Elk heeft voor- en nadelen. Het 1FD:1UD-model is bijvoorbeeld eenvoudig in te stellen. Het model van één upgradedomein per knooppuntmodel lijkt het meest op wat mensen gewend zijn. Tijdens upgrades wordt elk knooppunt onafhankelijk bijgewerkt. Dit is vergelijkbaar met hoe kleine sets machines in het verleden handmatig zijn bijgewerkt.

Het meest voorkomende model is de FD/UD-matrix, waarbij de foutdomeinen en upgradedomeinen een tabel vormen en knooppunten vanaf de diagonaal worden geplaatst. Dit is het model dat standaard wordt gebruikt in Service Fabric clusters in Azure. Voor clusters met veel knooppunten lijkt alles op een compact matrixpatroon.

Domeinbeperkingen voor fouten en upgrades en het resulterende gedrag

Standaardbenadering

Standaard houdt Cluster Resource Manager services in balans over fout- en upgradedomeinen. Dit wordt gemodelleerd als een beperking. De beperking voor fout- en upgradedomeinen geeft aan: "Voor een bepaalde servicepartitie mag er nooit een verschil zijn dat groter is dan één in het aantal serviceobjecten (stateless service-exemplaren of stateful service-replica's) tussen twee domeinen op hetzelfde hiërarchieniveau."

Stel dat deze beperking een garantie voor een 'maximaal verschil' biedt. De beperking voor fout- en upgradedomeinen voorkomt bepaalde stappen of overeenkomsten die de regel schenden.

Stel bijvoorbeeld dat we een cluster hebben met zes knooppunten, geconfigureerd met vijf foutdomeinen en vijf upgradedomeinen.

Stel nu dat we een service maken met de waarde TargetReplicaSetSize (of, voor een stateless service, InstanceCount) van vijf. De replica's komen terecht op N1-N5. In feite wordt N6 nooit gebruikt, ongeacht het aantal services zoals dit dat u maakt. Maar waarom? Laten we eens kijken naar het verschil tussen de huidige indeling en wat er zou gebeuren als N6 wordt gekozen.

Dit is de indeling die we hebben en het totale aantal replica's per fout- en upgradedomein:

Deze indeling wordt verdeeld in termen van knooppunten per foutdomein en upgradedomein. Het is ook evenwichtig wat betreft het aantal replica's per fout- en upgradedomein. Elk domein heeft hetzelfde aantal knooppunten en hetzelfde aantal replica's.

Laten we nu eens kijken wat er zou gebeuren als we N6 zouden gebruiken in plaats van N2. Hoe worden de replica's vervolgens gedistribueerd?

Deze indeling schendt onze definitie van de garantie voor het maximale verschil voor de beperking van het foutdomein. FD0 heeft twee replica's, terwijl FD1 nul heeft. Het verschil tussen FD0 en FD1 is een totaal van twee, wat groter is dan het maximale verschil van één. Omdat de beperking wordt geschonden, Cluster Resource Manager deze rangschikking niet toestaan.

En als we N2 en N6 zouden kiezen (in plaats van N1 en N2), zouden we het volgende krijgen:

Deze indeling is in termen van foutdomeinen evenwichtig. Maar nu schendt het de upgradedomeinbeperking, omdat UD0 geen replica's heeft en UD1 er twee heeft. Deze indeling is ook ongeldig en wordt niet door de Cluster Resource Manager.

Deze benadering van de distributie van stateful replica's of staatloze exemplaren biedt de best mogelijke fouttolerantie. Als één domein uitgaat, gaat het minimale aantal replica's/exemplaren verloren.

Aan de andere kant kan deze aanpak te strikt zijn en het cluster niet toestaan om alle resources te gebruiken. Voor bepaalde clusterconfiguraties kunnen bepaalde knooppunten niet worden gebruikt. Dit kan ertoe Service Fabric uw services niet te plaatsen, wat resulteert in waarschuwingsberichten. In het vorige voorbeeld kunnen sommige clusterknooppunten niet worden gebruikt (N6 in het voorbeeld). Zelfs als u knooppunten aan dat cluster hebt toegevoegd (N7-N10), worden replica's/exemplaren alleen op N1–N5 geplaatst vanwege beperkingen voor fout- en upgradedomeinen.

Alternatieve benadering

Cluster Resource Manager ondersteunt een andere versie van de beperking voor fout- en upgradedomeinen. Het maakt plaatsing mogelijk en garandeert nog steeds een minimumniveau van veiligheid. De alternatieve beperking kan als volgt worden aangegeven: 'Voor een bepaalde servicepartitie moet de replicadistributie over domeinen ervoor zorgen dat de partitie geen quorumverlies heeft'. Stel dat deze beperking een 'quorumveilige' garantie biedt.

Laten we teruggaan naar het vorige voorbeeld. Met de 'quorumveilige' versie van de beperking zijn alle drie de indelingen geldig. Zelfs als FD0 mislukt in de tweede indeling of UD1 mislukt in de derde indeling, zou de partitie nog steeds quorum hebben. (Het merendeel van de replica's is dan nog steeds in gebruik.) Met deze versie van de beperking kan N6 bijna altijd worden gebruikt.

De benadering 'quorumveilig' biedt meer flexibiliteit dan de benadering 'maximaal verschil'. De reden hiervoor is dat het gemakkelijker is om replicadistributies te vinden die geldig zijn in vrijwel elke clustertopologie. Deze aanpak biedt echter geen garantie voor de beste kenmerken van fouttolerantie, omdat sommige fouten slechter zijn dan andere.

In het ergste geval kan een meerderheid van de replica's verloren gaan door het uitvallen van één domein en één extra replica. In plaats van dat er drie fouten nodig zijn om het quorum met vijf replica's of exemplaren te verliezen, kunt u nu een meerderheid verliezen met slechts twee fouten.

Adaptieve benadering

Omdat beide benaderingen sterke en zwakke punten hebben, hebben we een adaptieve benadering geïntroduceerd waarin deze twee strategieën worden gecombineerd.

Laten we teruggaan naar het vorige voorbeeld en ervan uitgaan dat een cluster nu acht knooppunten heeft. Het cluster is nog steeds geconfigureerd met vijf foutdomeinen en vijf upgradedomeinen, en de waarde TargetReplicaSetSize van een service die op dat cluster wordt gehost, blijft vijf.

Omdat aan alle noodzakelijke voorwaarden wordt voldaan, Cluster Resource Manager de op quorum gebaseerde logica gebruiken bij het distribueren van de service. Hiermee schakelt u het gebruik van N6-N8 in. Een mogelijke servicedistributie kan er in dit geval als volgende uitzien:

Als de waarde van TargetReplicaSetSize van uw service is gereduceerd tot vier (bijvoorbeeld), ziet Cluster Resource Manager deze wijziging. Het wordt hervat met behulp van de logica 'maximaal verschil', omdat TargetReplicaSetSize niet meer kan worden verdeeld door het aantal foutdomeinen en upgradedomeinen. Als gevolg hiervan worden bepaalde replicaveringen uitgevoerd om de resterende vier replica's op knooppunten N1-N5 te distribueren. Op die manier wordt de 'maximale verschil'-versie van het foutdomein en de upgradedomeinlogica niet geschonden.

Als in de vorige indeling de waarde TargetReplicaSetSize vijf is en N1 uit het cluster wordt verwijderd, wordt het aantal upgradedomeinen gelijk aan vier. Ook hier Cluster Resource Manager 'maximum verschil'-logica gebruikt, omdat het aantal upgradedomeinen de targetReplicaSetSize-waarde van de service niet meer gelijkmatig verdeelt. Als gevolg hiervan moet replica R1, wanneer deze opnieuw wordt gebouwd, op N4 landen, zodat de beperking voor het fout- en upgradedomein niet wordt geschonden.

Fout- en upgradedomeinen configureren

In door Azure gehoste Service Fabric worden foutdomeinen en upgradedomeinen automatisch gedefinieerd. Service Fabric haalt de omgevingsgegevens van Azure op en gebruikt deze.

Als u uw eigen cluster maakt (of een bepaalde topologie in ontwikkeling wilt uitvoeren), kunt u het foutdomein zelf leveren en domeingegevens upgraden. In dit voorbeeld definiëren we een lokaal ontwikkelcluster met negen knooppunt dat drie datacenters omvat (elk met drie rekken). Dit cluster heeft ook drie upgradedomeinen die zijn gestriped over deze drie datacenters. Hier is een voorbeeld van de configuratie in ClusterManifest.xml:

  <Infrastructure>
    <!-- IsScaleMin indicates that this cluster runs on one box/one single server -->
    <WindowsServer IsScaleMin="true">
      <NodeList>
        <Node NodeName="Node01" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType01" FaultDomain="fd:/DC01/Rack01" UpgradeDomain="UpgradeDomain1" IsSeedNode="true" />
        <Node NodeName="Node02" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType02" FaultDomain="fd:/DC01/Rack02" UpgradeDomain="UpgradeDomain2" IsSeedNode="true" />
        <Node NodeName="Node03" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType03" FaultDomain="fd:/DC01/Rack03" UpgradeDomain="UpgradeDomain3" IsSeedNode="true" />
        <Node NodeName="Node04" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType04" FaultDomain="fd:/DC02/Rack01" UpgradeDomain="UpgradeDomain1" IsSeedNode="true" />
        <Node NodeName="Node05" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType05" FaultDomain="fd:/DC02/Rack02" UpgradeDomain="UpgradeDomain2" IsSeedNode="true" />
        <Node NodeName="Node06" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType06" FaultDomain="fd:/DC02/Rack03" UpgradeDomain="UpgradeDomain3" IsSeedNode="true" />
        <Node NodeName="Node07" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType07" FaultDomain="fd:/DC03/Rack01" UpgradeDomain="UpgradeDomain1" IsSeedNode="true" />
        <Node NodeName="Node08" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType08" FaultDomain="fd:/DC03/Rack02" UpgradeDomain="UpgradeDomain2" IsSeedNode="true" />
        <Node NodeName="Node09" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType09" FaultDomain="fd:/DC03/Rack03" UpgradeDomain="UpgradeDomain3" IsSeedNode="true" />
      </NodeList>
    </WindowsServer>
  </Infrastructure>

In dit voorbeeld wordt ClusterConfig.jsgebruikt voor zelfstandige implementaties:

"nodes": [
  {
    "nodeName": "vm1",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc1/r0",
    "upgradeDomain": "UD1"
  },
  {
    "nodeName": "vm2",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc1/r0",
    "upgradeDomain": "UD2"
  },
  {
    "nodeName": "vm3",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc1/r0",
    "upgradeDomain": "UD3"
  },
  {
    "nodeName": "vm4",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc2/r0",
    "upgradeDomain": "UD1"
  },
  {
    "nodeName": "vm5",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc2/r0",
    "upgradeDomain": "UD2"
  },
  {
    "nodeName": "vm6",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc2/r0",
    "upgradeDomain": "UD3"
  },
  {
    "nodeName": "vm7",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc3/r0",
    "upgradeDomain": "UD1"
  },
  {
    "nodeName": "vm8",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc3/r0",
    "upgradeDomain": "UD2"
  },
  {
    "nodeName": "vm9",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc3/r0",
    "upgradeDomain": "UD3"
  }
],

Beperkingen voor knooppunteigenschappen en plaatsing

Soms (meestal) wilt u ervoor zorgen dat bepaalde workloads alleen worden uitgevoerd op bepaalde typen knooppunten in het cluster. Voor sommige workloads zijn bijvoorbeeld GPU's of SSD's vereist en andere niet.

Een goed voorbeeld van het richten van hardware op bepaalde workloads is bijna elke n-tier-architectuur. Bepaalde machines fungeren als de front-end- of API-dienende kant van de toepassing en zijn beschikbaar voor clients of internet. Verschillende machines, vaak met verschillende hardwarebronnen, verwerken het werk van de reken- of opslaglagen. Deze zijn meestal niet rechtstreeks zichtbaar voor clients of internet.

Service Fabric verwacht dat in sommige gevallen bepaalde workloads op bepaalde hardwareconfiguraties moeten worden uitgevoerd. Bijvoorbeeld:

• Een bestaande n-tier-toepassing is 'opgetild en verplaatst' naar een Service Fabric omgeving.
• Een workload moet worden uitgevoerd op specifieke hardware voor prestatie-, schaal- of beveiligingsisolatie.
• Een workload moet worden geïsoleerd van andere workloads om redenen van beleid of resourceverbruik.

Ter ondersteuning van dit soort configuraties bevat Service Fabric tags die u op knooppunten kunt toepassen. Deze tags worden knooppunteigenschappen genoemd. Plaatsingsbeperkingen zijn de instructies die zijn gekoppeld aan afzonderlijke services die u selecteert voor een of meer knooppunteigenschappen. Plaatsingsbeperkingen bepalen waar services moeten worden uitgevoerd. De set beperkingen kan worden verdedelijkt. Elk sleutel-waardepaar kan werken. Vanaf Service Fabric 8.1 kunnen knooppunteigenschappen dynamisch worden bijgewerkt, zonder onderbreking van het uitvoeren van workloads.

Ingebouwde knooppunteigenschappen

Service Fabric definieert een aantal standaard knooppunteigenschappen die automatisch kunnen worden gebruikt, zodat u ze niet hoeft te definiëren. De standaardeigenschappen die op elk knooppunt zijn gedefinieerd, zijn NodeType en NodeName.

U kunt bijvoorbeeld een plaatsingsbeperking schrijven als "(NodeType == NodeType03)" . NodeType is een veelgebruikte eigenschap. Dit is handig omdat deze overeenkomt met 1:1 met een type machine. Elk type machine komt overeen met een type workload in een traditionele n-tier-toepassing.

Plaatsingsbeperkingen en syntaxis van knooppunt-eigenschappen

De waarde die is opgegeven in de knooppunt-eigenschap kan een tekenreeks, Booleaanse waarde of lang ondertekend zijn. De instructie bij de service wordt een plaatsingsbeperking genoemd, omdat deze beperkt waar de service in het cluster kan worden uitgevoerd. De beperking kan elke Booleaanse instructie zijn die wordt gebruikt op de knooppunteigenschappen in het cluster. De geldige selectors in deze Booleaanse instructies zijn:

• Voorwaardelijke controles voor het maken van bepaalde instructies:

  Instructie	Syntax
  'gelijk aan'	"=="
  'niet gelijk aan'	"!="
  'groter dan'	">"
  'groter dan of gelijk aan'	">="
  'kleiner dan'	'<'
  'kleiner dan of gelijk aan'	"<="

• Booleaanse instructies voor groeperen en logische bewerkingen:

  Instructie	Syntax
  'and'	'&&'
  'of'	"||"
  'niet'	"!"
  'groep als één instructie'	"()"

Hier zijn enkele voorbeelden van basisbeperkingsverklaringen:

• "Value >= 5"
• "NodeColor != green"
• "((OneProperty < 100) || ((AnotherProperty == false) && (OneProperty >= 100)))"

Alleen knooppunten waar de algehele plaatsingsbeperkingsverklaring wordt geëvalueerd als 'Waar', kunnen de service er op plaatsen. Knooppunten die geen eigenschap hebben gedefinieerd, komen niet overeen met een plaatsingsbeperking die de eigenschap bevat.

Stel dat de volgende knooppunteigenschappen zijn gedefinieerd voor een knooppunttype in ClusterManifest.xml:

    <NodeType Name="NodeType01">
      <PlacementProperties>
        <Property Name="HasSSD" Value="true"/>
        <Property Name="NodeColor" Value="green"/>
        <Property Name="SomeProperty" Value="5"/>
      </PlacementProperties>
    </NodeType>

In het volgende voorbeeld ziet u knooppunteigenschappen die via ClusterConfig.jszijn gedefinieerd voor zelfstandige implementaties of Template.jsvoor in Azure gehoste clusters.

"nodeTypes": [
    {
        "name": "NodeType01",
        "placementProperties": {
            "HasSSD": "true",
            "NodeColor": "green",
            "SomeProperty": "5"
        },
    }
],

U kunt als volgt beperkingen voor serviceplaatsing voor een service maken:

FabricClient fabricClient = new FabricClient();
StatefulServiceDescription serviceDescription = new StatefulServiceDescription();
serviceDescription.PlacementConstraints = "(HasSSD == true && SomeProperty >= 4)";
// Add other required ServiceDescription fields
//...
await fabricClient.ServiceManager.CreateServiceAsync(serviceDescription);

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceType -Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton -PlacementConstraint "HasSSD == true && SomeProperty >= 4"

Als alle knooppunten van NodeType01 geldig zijn, kunt u ook dat knooppunttype met de beperking "(NodeType == NodeType01)" selecteren.

De plaatsingsbeperkingen van een service kunnen dynamisch worden bijgewerkt tijdens runtime. Als dat nodig is, kunt u een service verplaatsen in het cluster, vereisten toevoegen en verwijderen, en meer. Service Fabric zorgt ervoor dat de service up-and-available blijft, zelfs wanneer deze typen wijzigingen worden aangebracht.

StatefulServiceUpdateDescription updateDescription = new StatefulServiceUpdateDescription();
updateDescription.PlacementConstraints = "NodeType == NodeType01";
await fabricClient.ServiceManager.UpdateServiceAsync(new Uri("fabric:/app/service"), updateDescription);

Update-ServiceFabricService -Stateful -ServiceName $serviceName -PlacementConstraints "NodeType == NodeType01"

Plaatsingsbeperkingen worden opgegeven voor elk benoemd service-exemplaar. Updates nemen altijd de plaats in van (overschrijven) wat eerder is opgegeven.

De clusterdefinitie definieert de eigenschappen op een knooppunt. Voor het wijzigen van de eigenschappen van een knooppunt is een upgrade naar de clusterconfiguratie vereist. Voor het upgraden van de eigenschappen van een knooppunt moet elk betrokken knooppunt opnieuw worden opgestart om de nieuwe eigenschappen te rapporteren. Service Fabric beheert deze rolling upgrades.

Clusterbronnen beschrijven en beheren

Een van de belangrijkste taken van een orchestrator is het beheren van resourceverbruik in het cluster. Het beheren van clusterbronnen kan een aantal verschillende dingen betekenen.

Ten eerste moet u ervoor zorgen dat machines niet overbelast raken. Dit betekent dat u ervoor moet zorgen dat machines niet meer services uitvoeren dan ze kunnen verwerken.

Ten tweede is er taakverdeling en optimalisatie, wat essentieel is voor het efficiënt uitvoeren van services. Kosteneffectieve of prestatiegevoelige serviceaanbiedingen kunnen niet toestaan dat sommige knooppunten hot zijn terwijl andere niet werken. Hot-knooppunten leiden tot resource-matige en slechte prestaties. Koude knooppunten vertegenwoordigen verspilde resources en hogere kosten.

Service Fabric vertegenwoordigt resources als metrische gegevens. Metrische gegevens zijn logische of fysieke resources die u wilt beschrijven voor Service Fabric. Voorbeelden van metrische gegevens zijn WorkQueueDepth of MemoryInMb. Zie Resourcebeheer voor informatie over de fysieke resources Service Fabric op knooppunten kunnen worden beheerd. Zie dit artikel voor informatie over de standaard metrische gegevens die door de Cluster Resource Manager worden gebruikt en over het configureren van aangepaste metrische gegevens.

Metrische gegevens verschillen van plaatsingsbeperkingen en knooppunteigenschappen. Knooppunteigenschappen zijn statische descriptors van de knooppunten zelf. Metrische gegevens beschrijven de resources die knooppunten hebben en die services gebruiken wanneer ze worden uitgevoerd op een knooppunt. Een knooppunt-eigenschap kan HasSSD zijn en kan worden ingesteld op waar of onwaar. De hoeveelheid ruimte die beschikbaar is op die SSD en hoeveel er door services wordt verbruikt, is een metriek zoals 'DriveSpaceInMb'.

Net als bij plaatsingsbeperkingen en knooppunteigenschappen, Service Fabric Cluster Resource Manager niet wat de namen van de metrische gegevens betekenen. Metrische namen zijn alleen tekenreeksen. Het is een goed idee om eenheden te declareer als onderdeel van de metrische namen die u maakt wanneer ze ambigu zijn.

Capaciteit

Als u alle resourceverdeling hebt uitgeschakeld, zorgt Service Fabric Cluster Resource Manager ervoor dat het knooppunt de capaciteit overschreed. Het beheren van overschrijdingen van capaciteit is mogelijk, tenzij het cluster te vol is of de werkbelasting groter is dan een knooppunt. Capaciteit is een andere beperking die Cluster Resource Manager gebruikt om te begrijpen hoeveel van een resource een knooppunt heeft. De resterende capaciteit wordt ook bij het hele cluster bijgespoord. Vanaf Service Fabric 8.1 kunnen knooppuntcapaciteiten dynamisch worden bijgewerkt, zonder onderbreking van het uitvoeren van workloads.

Zowel de capaciteit als het verbruik op serviceniveau worden uitgedrukt in termen van metrische gegevens. De metrische gegevens kunnen bijvoorbeeld ClientConnections zijn en een knooppunt heeft mogelijk een capaciteit voor 'ClientConnections' van 32.768. Andere knooppunten kunnen andere limieten hebben. Een service die op dat knooppunt wordt uitgevoerd, kan zeggen dat deze momenteel 32.256 van de metrische gegevens ClientConnections verbruikt.

Tijdens runtime houdt Cluster Resource Manager resterende capaciteit in het cluster en op knooppunten bij. Als u capaciteit wilt bijhouden, Cluster Resource Manager het gebruik van elke service af van de capaciteit van een knooppunt waarop de service wordt uitgevoerd. Met deze informatie kunnen Cluster Resource Manager replica's plaatsen of verplaatsen, zodat knooppunten de capaciteit niet over hebben.

StatefulServiceDescription serviceDescription = new StatefulServiceDescription();
ServiceLoadMetricDescription metric = new ServiceLoadMetricDescription();
metric.Name = "ClientConnections";
metric.PrimaryDefaultLoad = 1024;
metric.SecondaryDefaultLoad = 0;
metric.Weight = ServiceLoadMetricWeight.High;
serviceDescription.Metrics.Add(metric);
await fabricClient.ServiceManager.CreateServiceAsync(serviceDescription);

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton –Metric @("ClientConnections,High,1024,0)

U kunt capaciteiten zien die zijn gedefinieerd in het clustermanifest. Hier is een voorbeeld van ClusterManifest.xml:

    <NodeType Name="NodeType03">
      <Capacities>
        <Capacity Name="ClientConnections" Value="65536"/>
      </Capacities>
    </NodeType>

Hier is een voorbeeld van capaciteiten die zijn gedefinieerd via ClusterConfig.jsop voor zelfstandige implementaties of Template.jsvoor door Azure gehoste clusters:

"nodeTypes": [
    {
        "name": "NodeType03",
        "capacities": {
            "ClientConnections": "65536",
        }
    }
],

De belasting van een service verandert vaak dynamisch. Stel dat de belasting van ClientConnections voor een replica is gewijzigd van 1024 in 2048. Het knooppunt waar het op werd uitgevoerd, had toen nog een capaciteit van slechts 512 voor die metrische gegevens. Nu de plaatsing van de replica of het exemplaar ongeldig is, omdat er onvoldoende ruimte is op dat knooppunt. Cluster Resource Manager moet het knooppunt weer onder de capaciteit krijgen. Het vermindert de belasting van het knooppunt dat overcapaciteit is door een of meer replica's of exemplaren van dat knooppunt naar andere knooppunten te verplaatsen.

Cluster Resource Manager probeert de kosten van het verplaatsen van replica's te minimaliseren. Meer informatie over verplaatsingskosten en over herbalanceringsstrategieën en regels.

Clustercapaciteit

Hoe kan de Service Fabric Cluster Resource Manager ervoor zorgen dat het algehele cluster niet te vol is? Met dynamische belasting is er niet veel mogelijk. Services kunnen hun belastingspieken hebben, onafhankelijk van de acties die Cluster Resource Manager uitvoeren. Als gevolg hiervan is uw cluster met veel ruimte vandaag mogelijk onderbekracht als er morgen een piek is.

Besturingselementen in Cluster Resource Manager helpen problemen te voorkomen. Het eerste wat u kunt doen, is voorkomen dat er nieuwe workloads worden gemaakt die ervoor zorgen dat het cluster vol is.

Stel dat u een stateless service maakt en er een bepaalde belasting aan is gekoppeld. De service geeft om de metrische gegevens DiskSpaceInMb. De service verbruikt vijf eenheden van DiskSpaceInMb voor elk exemplaar van de service. U wilt drie exemplaren van de service maken. Dit betekent dat u 15 eenheden 'DiskSpaceInMb' in het cluster nodig hebt om zelfs deze service-exemplaren te kunnen maken.

Cluster Resource Manager berekent voortdurend de capaciteit en het verbruik van elke metrische waarde, zodat deze de resterende capaciteit in het cluster kan bepalen. Als er onvoldoende ruimte is, Cluster Resource Manager de aanroep om een service te maken.

Omdat de vereiste is dat er slechts 15 eenheden beschikbaar zijn, kunt u deze ruimte op veel verschillende manieren toewijzen. Er kan bijvoorbeeld één resterende capaciteitseenheid op 15 verschillende knooppunten zijn, of drie resterende capaciteitseenheden op vijf verschillende knooppunten. Als Cluster Resource Manager kunnen rangschikken, zodat er vijf eenheden beschikbaar zijn op drie knooppunten, wordt de service op de plaats gemaakt. Het opnieuw rangschikken van het cluster is meestal mogelijk, tenzij het cluster bijna vol is of de bestaande services om een of andere reden niet kunnen worden geconsolideerd.

Capaciteit voor knooppuntbuffer en overboeking

Als er een knooppuntcapaciteit voor een metrische waarde wordt opgegeven, Cluster Resource Manager nooit replica's naar een knooppunt plaatsen of verplaatsen als de totale belasting hoger zou zijn dan de opgegeven knooppuntcapaciteit. Dit kan de plaatsing van nieuwe replica's voorkomen of mislukte replica's vervangen als het cluster bijna volledige capaciteit heeft en een replica met een grote belasting moet worden geplaatst, vervangen of verplaatst.

Als u meer flexibiliteit wilt bieden, kunt u de capaciteit voor knooppuntbuffer of overboeking opgeven. Wanneer de capaciteit voor knooppuntbuffer of overboeking is opgegeven voor een metrische gegevens, probeert de Cluster Resource Manager replica's zodanig te plaatsen of te verplaatsen dat de buffer- of overboekingscapaciteit ongebruikt blijft, maar de buffer- of overboekingscapaciteit zo nodig kan worden gebruikt voor acties die de beschikbaarheid van de service vergroten, zoals:

• Plaatsing van nieuwe replica's of het vervangen van mislukte replica's
• Plaatsing tijdens upgrades
• Schendingen van zachte en harde beperkingen oplossen
• Defragmentatie

De capaciteit van de knooppuntbuffer vertegenwoordigt een gereserveerd deel van de capaciteit onder de opgegeven knooppuntcapaciteit en overboekingscapaciteit vertegenwoordigt een deel van de extra capaciteit boven de opgegeven knooppuntcapaciteit. In beide gevallen probeert de Cluster Resource Manager deze capaciteit vrij te houden.

Als een knooppunt bijvoorbeeld een opgegeven capaciteit heeft voor metrische cpu-utilisatie van 100 en het bufferpercentage voor dat metrische knooppunt is ingesteld op 20%, zullen de totale en niet-gebufferd capaciteit respectievelijk 100 en 80 zijn en zal de Cluster Resource Manager onder normale omstandigheden niet meer dan 80 eenheden aan belasting op het knooppunt plaatsen.

Knooppuntbuffer moet worden gebruikt wanneer u een deel van de knooppuntcapaciteit wilt reserveren dat alleen wordt gebruikt voor acties die de hierboven genoemde beschikbaarheid van de service verhogen.

Als daarentegen een overboekingspercentage voor knooppunt wordt gebruikt en is ingesteld op 20%, zijn de totale en niet-beschikbare capaciteit respectievelijk 120 en 100.

Overboekingscapaciteit moet worden gebruikt wanneer u wilt toestaan dat Cluster Resource Manager replica's op een knooppunt plaatsen, zelfs als het totale resourcegebruik de capaciteit overschrijdt. Dit kan worden gebruikt om extra beschikbaarheid voor services te bieden, ten koste van de prestaties. Als overboeking wordt gebruikt, moet gebruikerstoepassingslogica kunnen werken met minder fysieke resources dan nodig is.

Als er capaciteit voor knooppuntbuffers of overboekingen is opgegeven, verplaatsen of plaatsen Cluster Resource Manager geen replica's als de totale belasting van het doel-knooppunt de totale capaciteit overschreed (knooppuntcapaciteit in het geval van knooppuntbuffer en knooppuntcapaciteit + overboekingscapaciteit in het geval van overboeking).

Overboekingscapaciteit kan ook worden opgegeven als oneindig. In dit geval probeert Cluster Resource Manager de totale belasting van het knooppunt onder de opgegeven knooppuntcapaciteit te houden, maar kan het mogelijk een veel grotere belasting op het knooppunt plaatsen, wat kan leiden tot ernstige prestatievermindering.

Voor een metrische gegevens mogen niet tegelijkertijd zowel een knooppuntbuffer- als overboekingscapaciteit zijn opgegeven.

Hier is een voorbeeld van hoe u capaciteit voor knooppuntbuffers of overboekingen opgeeft in ClusterManifest.xml:

<Section Name="NodeBufferPercentage">
    <Parameter Name="SomeMetric" Value="0.15" />
</Section>
<Section Name="NodeOverbookingPercentage">
    <Parameter Name="SomeOtherMetric" Value="0.2" />
    <Parameter Name=”MetricWithInfiniteOverbooking” Value=”-1.0” />
</Section>

Hier is een voorbeeld van hoe u capaciteit voor knooppuntbuffers of overboekingen opgeeft via ClusterConfig.jsaan voor zelfstandige implementaties ofTemplate.jsvoor door Azure gehoste clusters:

"fabricSettings": [
  {
    "name": "NodeBufferPercentage",
    "parameters": [
      {
          "name": "SomeMetric",
          "value": "0.15"
      }
    ]
  },
  {
    "name": "NodeOverbookingPercentage",
    "parameters": [
      {
          "name": "SomeOtherMetric",
          "value": "0.20"
      },
      {
          "name": "MetricWithInfiniteOverbooking",
          "value": "-1.0"
      }
    ]
  }
]

Volgende stappen

• Zie overzicht van Cluster Resource Manager architectuur voor Cluster Resource Manager informatie over de architectuur Cluster Resource Manager informatiestroom.
• Het definiëren van metrische defragmentatiegegevens is één manier om de belasting van knooppunten te consolideren in plaats van deze uit te spreiden. Zie Defragmentatie van metrische gegevens en belasting in Service Fabric voor meer informatie over het configureren Service Fabric.
• Begin vanaf het begin en krijg een inleiding tot Service Fabric Cluster Resource Manager.
• Zie Balancing your Cluster Resource Manager Service Fabric cluster (Taakverdeling van uw Service Fabric cluster) voor meer informatie over hoe u de belasting in het cluster Service Fabric beheert.