Popis Service Fabric clusteru pomocí Správce prostředků clusteru

Funkce Správce prostředků clusteru azure Service Fabric nabízí několik mechanismů pro popis clusteru:

• Domény selhání
• Upgradování domén
• Vlastnosti uzlu
• Kapacity uzlů

Během běhu Správce prostředků clusteru tyto informace k zajištění vysoké dostupnosti služeb spuštěných v clusteru. Při vynucování těchto důležitých pravidel se také snaží optimalizovat spotřebu prostředků v rámci clusteru.

Domény selhání

Doména selhání je jakákoli oblast koordinovaného selhání. Jeden počítač je doména selhání. Může sama o sobě selhat z různých důvodů, od selhání napájení až po selhání napájení až po chybný firmware síťové karty.

Počítače připojené ke stejnému ethernetovému přepínači jsou ve stejné doméně selhání. Stejně tak počítače, které sdílejí jeden zdroj napájení nebo na jednom místě.

Vzhledem k tomu, že je přirozené, že se hardwarové chyby překrývají, domény selhání jsou ze své podstaty hierarchické. V tomto souboru jsou reprezentované jako identifikátory URI Service Fabric.

Je důležité, aby se domény selhání správně nastavily, protože Service Fabric tyto informace používají k bezpečnému umístění služeb. Service Fabric služby tak, aby při ztrátě domény selhání (způsobené selháním některé komponenty) došlo k výpadku služby.

V prostředí Azure Service Fabric domény selhání poskytnuté prostředím ke správné konfiguraci uzlů v clusteru vaším jménem. U samostatných instancí Service Fabric domény selhání definovány v době, kdy je cluster nastavený.

Na následujícím obrázku vybarvime všechny entity, které přispívají do domén selhání, a vypište všechny různé domény selhání, které jsou výsledkem. V tomto příkladu máme datová centra (DC), racky (R) a okna (B). Pokud každé okno obsahuje více než jeden virtuální počítač, může být v hierarchii domény selhání další vrstva.

Během běhu Service Fabric Správce prostředků clusteru domény selhání v rozložení clusteru a plánů. Stavové repliky nebo bezvýcové instance služby se distribuují, takže jsou v samostatných doménách selhání. Distribuce služby napříč doménami selhání zajišťuje, že dostupnost služby nebude ohrožena v případě, že doména selhání selže na jakékoli úrovni hierarchie.

Správce prostředků clusteru nezáleží na tom, kolik vrstev se nachází v hierarchii domén selhání. Pokusí se zajistit, aby ztráta některé části hierarchie neovlivnila spuštěné služby.

To je nejlepší, pokud je stejný počet uzlů v každé úrovni hloubky v hierarchii domén selhání. Pokud je strom domén selhání ve vašem clusteru nevyvážený, je Správce prostředků clusteru obtížnější zjistit, co nejlépe přidělující služby. Rozložení nevyvážených domén selhání znamenají, že ztráta některých domén má vliv na dostupnost služeb více než jiných domén. V důsledku toho se Správce prostředků clusteru roztrhané mezi dva cíle:

• Chce používat počítače v dané "těžké" doméně umístěním služeb.
• Chce umístit služby do jiných domén tak, aby ztráta domény nezpůsobila problémy.

Co vypadají domény jako nevyrovnané? Následující diagram znázorňuje dvě různá rozložení clusterů. V prvním příkladu jsou uzly rovnoměrně rozloženy napříč doménami selhání. V druhém příkladu má jedna doména selhání mnoho dalších uzlů než jiné domény selhání.

V Azure můžete zvolit, která doména selhání obsahuje uzel, se spravuje za vás. V závislosti na počtu uzlů, které jste zřídili, můžete i nadále končit doménami selhání, které mají více uzlů v nich než jiné.

Řekněme například, že máte pět domén selhání v clusteru, ale zřizujete sedm uzlů pro typ uzlu (NodeType). V takovém případě se první dvě domény selhání ukončí s více uzly. Pokud budete pokračovat v nasazování více instancí NodeType s pouze několika instancemi, bude problém horší. Z tohoto důvodu doporučujeme, aby počet uzlů v každém typu uzlu byl násobek počtu domén selhání.

Upgradování domén

Domény upgradu jsou další funkcí, Service Fabric Správce prostředků clusteru pochopit rozložení clusteru. Upgradované domény definují sady uzlů, které se upgraduly současně. Upgradování domén pomáhá Správce prostředků clusteru a orchestraci operací správy, jako jsou upgrady.

Upgradování domén se hodně liší od domén selhání, ale s několika klíčovými rozdíly. Zaprvé oblasti koordinovaných selhání hardwaru definují domény selhání. Upgradované domény jsou na druhé straně definované zásadou. Můžete se rozhodnout, kolik chcete, místo abyste prostředí nechali diktovat číslo. Můžete mít tolik upgradovaných domén jako uzly. Další rozdíl mezi doménami selhání a upgrady je v tom, že upgradování domén není hierarchické. Jsou spíše jako jednoduchá značka.

Následující diagram znázorňuje tři upgradovací domény prokládané napříč třemi doménami selhání. Ukazuje také jedno možné umístění pro tři různé repliky stavové služby, kde každá z nich skončí v různých doménách selhání a upgradu. Toto umístění umožňuje ztrátu domény selhání uprostřed upgradu služby a stále má jednu kopii kódu a dat.

Velké množství upgradovaných domén má své výhody a nevýhody. Další upgradovací domény znamenají, že každý krok upgradu je podrobnější a ovlivňuje menší počet uzlů nebo služeb. Méně služeb se musí přesouvat najednou, takže se do systému méně často pracuje. To obvykle zvyšuje spolehlivost, protože méně služby je ovlivněno libovolnými problémy zavedenými během upgradu. Více upgradovaných domén také znamená, že potřebujete méně dostupné vyrovnávací paměti na jiných uzlech, abyste zvládli dopad upgradu.

Pokud máte například pět domén upgradu, budou mít uzly v každé z nich zpracování přibližně 20 procent provozu. Pokud potřebujete vzít v úvahu upgrade upgradovací domény, musí se tato zátěže obvykle nacházet někde. Vzhledem k tomu, že máte čtyři zbývající domény pro upgrade, musí mít každý z nich místo 25 procent celkového provozu. Víc domén upgradu znamená, že pro uzly v clusteru potřebujete méně vyrovnávací paměti.

Vezměte v úvahu, jestli jste místo toho měli 10 upgradovacích domén. V takovém případě by každá upgradovací doména mohla zpracovávat pouze přibližně 10 procent celkového provozu. Když provedete kroky upgradu v rámci clusteru, musí mít každá doména prostor jenom pro přibližně 11 procent celkového provozu. Další domény upgradu obvykle umožňují spouštět uzly s vyšším využitím, protože potřebujete méně rezervovanou kapacitu. Totéž platí pro domény selhání.

Nevýhodou s mnoha doménami upgradu je, že inovace mají za následek delší dobu. Service Fabric čeká krátkou dobu po dokončení upgradovací domény a provede kontrolu před zahájením upgradu dalšího. Tato zpoždění umožňují zjistit problémy zavedené upgradem před pokračováním upgradu. Kompromisy jsou přijatelné, protože zabraňují chybovým změnám v tom, aby ovlivnily příliš velkou část služby najednou.

Existence příliš málo domén upgradu má mnoho negativních vedlejších účinků. Zatímco každá upgradovací doména je mimo provoz a je upgradována, není k dispozici velká část celkové kapacity. Pokud máte například jenom tři domény upgradu, provedete si přibližně jednu třetinu celkové kapacity služby nebo clusteru. Nestačí, když máte dost služby v provozu, protože ve zbývající části clusteru potřebujete dostatek kapacity pro zpracování úloh. Zachování této vyrovnávací paměti znamená, že při normálním provozu jsou tyto uzly méně načtené, než by byly jinak. Tím se zvýší náklady na provoz vaší služby.

Neexistují žádné reálné omezení celkového počtu domén selhání nebo upgradu v prostředí nebo omezení jejich překrytí. Existují ale běžné vzory:

• Domény selhání a upgradované domény 1:1
• Jedna upgradovní doména na uzel (fyzická nebo virtuální instance operačního systému)
• "Prokládaný" nebo "maticový" model, ve kterém domény selhání a upgradovací domény tvoří matici s počítači, které obvykle běží diagonálně.

Neexistuje žádná nejlepší odpověď na to, jaké rozložení zvolit. Každá z nich má výhody a nevýhody. Například nastavení modelu 1FD:1UD je jednoduché. Model jedné upgradovní domény na jeden model uzlu se nejvíce podobná tomu, na co jsou lidé zvykní. Během upgradů se každý uzel aktualizuje nezávisle. To se podobá tomu, jak se v minulosti ručně upgradovali malé sady počítačů.

Nejběžnějším modelem je matice FD/UD, kde domény selhání a upgradovací domény tvoří tabulku a uzly se umisťuje podél diagonální struktury. Toto je model, který se ve výchozím nastavení používá Service Fabric clusterech v Azure. U clusterů s mnoha uzly vypadá všechno jako spousta maticových vzorů.

Omezení domény selhání a upgradu a výsledné chování

Výchozí přístup

Ve výchozím nastavení Správce prostředků clusteru zajišťuje vyvážení služeb napříč doménami selhání a upgradů. Modeluje se jako omezení. Omezení pro stavy domén selhání a upgradu: "U daného oddílu služby by nikdy neměl být mezi dvěma doménami na stejné úrovni hierarchie rozdíl větší než jeden v počtu objektů služby (bez stavových instancí služby nebo replik stavových služeb).

Řekněme, že toto omezení poskytuje záruku maximálního rozdílu. Omezení pro domény selhání a upgradování brání určitým přesunům nebo uspořádáním, která porušují pravidlo.

Řekněme například, že máme cluster se šesti uzly nakonfigurovaných s pěti doménami selhání a pěti doménami upgradu.

Teď řekněme, že vytvoříme službu s hodnotou TargetReplicaSetSize (nebo pro bez stavovou službu InstanceCount) pěti. Repliky přistane na N1–N5. Ve skutečnosti se N6 nikdy nevyužít bez ohledu na to, kolik služeb vytvoříte. Ale proč? Podívejme se na rozdíl mezi aktuálním rozložením a tím, co by se stalo, kdyby byla zvolena možnost N6.

Tady je rozložení, které jsme získali, a celkový počet replik na doménu selhání a upgradu:

Toto rozložení je vyvážené z hlediska uzlů na doménu selhání a upgradování domény. Je také vyvážená z hlediska počtu replik na chybu a upgradované domény. Každá doména má stejný počet uzlů a stejný počet replik.

Teď se podívejme, co by se stalo, kdybychom použili N6 místo N2. Jak by se pak repliky distribuují?

Toto rozložení porušuje naši definici záruky "maximálního rozdílu" pro omezení domény selhání. FD0 má dvě repliky, zatímco FD1 má nulovou hodnotu. Rozdíl mezi FD0 a FD1 je celkem 2, což je více než maximální rozdíl jedna. Vzhledem k tomu, že je porušení omezení, Správce prostředků clusteru toto uspořádání nepovoluje.

Podobně, pokud jsme vybrali N2 a N6 (místo N1 a N2), získáme:

Toto rozložení je vyvážené z hlediska domén selhání. Ale teď porušuje omezení domény upgradu, protože UD0 nemá žádné repliky a UD1 má dvě. Toto rozložení je také neplatné a nebude vybráno Správce prostředků clusteru.

Tento přístup k distribuci stavových replik nebo bezvýcových instancí poskytuje nejlepší možnou odolnost proti chybám. Pokud dojde k vypnutí jedné domény, dojde ke ztrátě minimálního počtu replik nebo instancí.

Na druhé straně může být tento přístup příliš striktní a neumožňuje clusteru využívat všechny prostředky. U určitých konfigurací clusteru se některé uzly nesmět používat. To může způsobit, Service Fabric vaše služby neumisovat, což může vést k upozorněním. V předchozím příkladu není možné použít některé uzly clusteru (v tomto příkladu N6). I v případě, že jste do tohoto clusteru přidali uzly (N7–N10), repliky a instance se umístí pouze do N1–N5 z důvodu omezení domén selhání a upgradu.

Alternativní přístup

Cluster Správce prostředků podporuje další verzi omezení pro domény selhání a inovace. Umožňuje umístění a zároveň zaručuje minimální úroveň bezpečnosti. Alternativní omezení lze určit následujícím způsobem: "pro daný oddíl služby by distribuce replik mezi doménami měla zajistit, aby nedošlo ke zhoršení kvora." Řekněme, že toto omezení poskytuje jistotu "bezpečné pro kvorum".

Vraťme se k předchozímu příkladu. U "bezpečné" verze omezení by všechna tři rozložení byla platná. I v případě selhání funkce FD0 ve druhém rozložení nebo selhání UD1 ve třetím rozložení bude mít oddíl stále kvorum. (Většina replik by stále byla v systému.) S touto verzí tohoto omezení je téměř vždy možné využít N6.

Přístup "bezpečný pro kvorum" poskytuje větší flexibilitu než přístup "maximální rozdíl". Je to proto, že je jednodušší najít distribuce replik, které jsou platné téměř v jakékoli topologii clusteru. Tento přístup ale nemůže zaručit nejlepší charakteristiky odolnosti proti chybám, protože některá selhání jsou horší než jiná.

V nejhorším případě může být většina replik ztracena kvůli selhání jedné domény a jedné další repliky. Například místo toho, aby se kvůli ztrátě kvora vyžadovala tři selhání s pěti replikami nebo instancemi, můžete teď přijít o většinu jenom se dvěma selháními.

Adaptivní přístup

Vzhledem k tomu, že oba přístupy mají silné a slabé stránky, zavedli jsme adaptivní přístup, který tyto dvě strategie kombinuje.

Pojďme přejít zpátky na předchozí příklad a předpokládat, že má cluster teď osm uzlů. Cluster je stále nakonfigurovaný s pěti doménami selhání a pěti upgradovacími doménami a hodnota TargetReplicaSetSize služby hostované v tomto clusteru zůstane pět.

Protože jsou splněny všechny nezbytné podmínky, Správce prostředků clusteru při distribuci služby použije logiku založenou na kvoru. To umožňuje použití N6–N8. Jedna z možných distribucí služeb v tomto případě může vypadat třeba takhle:

Pokud je hodnota TargetReplicaSetSize vaší služby zmenšená na čtyři (například), clusterová správce prostředků si všimněte, že se změní. Bude pokračovat pomocí logiky "maximálního rozdílu", protože TargetReplicaSetSize není rozdělit podle počtu domén selhání a již upgradovacích domén. V důsledku toho dojde k distribuci zbývajících čtyř replik na uzlech N1-N5 k některým přesunům replik. Tímto způsobem není porušená verze "maximální rozdíl" v doméně selhání a logika domény upgradu.

Pokud je v předchozím rozložení hodnota TargetReplicaSetSize 5 a N1 z clusteru, je počet domén upgradu stejný jako čtyři. Cluster Správce prostředků se znovu spouští pomocí logiky "maximálního rozdílu", protože počet domén upgradu už ještě nerozděluje hodnotu TargetReplicaSetSize služby. V důsledku toho se replika R1, když se znovu vytvoří, musí vystavit na N4, aby nedošlo k porušení omezení pro doménu selhání a upgrade.

Konfigurace domén selhání a upgradu

V nasazeních hostovaných Service Fabric Azure se domény selhání a upgradované domény definují automaticky. Service Fabric vyzvedne a použije informace o prostředí z Azure.

Pokud vytváříte vlastní cluster (nebo chcete spustit konkrétní topologii ve vývoji), můžete doménu selhání a informace o doméně upgradovat sami. V tomto příkladu definujeme místní vývojový cluster s devíti uzly, který zahrnuje tři datová centra (každé se třemi racky). Tento cluster má také tři upgradovací domény prokládané mezi těmito třemi datacentra. Tady je příklad konfigurace v 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>

Tento příklad používá ClusterConfig.json pro samostatná nasazení:

"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"
  }
],

Vlastnosti uzlu a omezení umístění

Někdy (ve většině času) budete chtít zajistit, aby se určité úlohy spouštěly jenom na určitých typech uzlů v clusteru. Některé úlohy například můžou vyžadovat GPU nebo SSD a jiné ne.

Skvělým příkladem cílení hardwaru na konkrétní úlohy je téměř každá n-úrovňová architektura. Některé počítače slouží jako front-end nebo rozhraní API obsluhující stranu aplikace a jsou vystaveny klientům nebo internetu. Různé počítače, často s různými hardwarovými prostředky, pracují s výpočetními vrstvami nebo vrstvami úložiště. Ty obvykle nejsou přímo vystaveny klientům ani internetu.

Service Fabric, že v některých případech může být nutné spouštět konkrétní úlohy v konkrétních hardwarových konfiguracích. Například:

• Existující n-vrstvá aplikace byla "vyzdvižena a přesunuta" do Service Fabricho prostředí.
• Zatížení musí být spuštěno na konkrétním hardwaru pro účely výkonu, škálování nebo důvodů izolace zabezpečení.
• Úlohy by měly být izolované od jiných úloh pro účely zásad nebo spotřeby prostředků.

Pro podporu těchto řazení konfigurací Service Fabric obsahuje značky, které můžete použít na uzly. Tyto značky se nazývají Vlastnosti uzlu. Omezení umístění jsou příkazy připojené k jednotlivým službám, které vyberete pro jednu nebo více vlastností uzlu. Omezení umístění definují, kde by měly služby běžet. Sada omezení je rozšiřitelná. Může fungovat jakýkoli pár klíč/hodnota. Počínaje Service Fabric 8,1 je možné dynamicky aktualizovat vlastnosti uzlů, aniž by došlo k přerušení provozu úloh.

Předdefinované vlastnosti uzlu

Service Fabric definuje některé výchozí vlastnosti uzlů, které se dají použít automaticky, takže je nemusíte definovat. Výchozí vlastnosti definované na jednotlivých uzlech jsou NodeType a Node.

Můžete například zapsat omezení umístění jako "(NodeType == NodeType03)" . NodeType je běžně používaná vlastnost. To je užitečné, protože odpovídá 1:1 s typem počítače. Každý typ počítače odpovídá typu úlohy v tradiční n-vrstvé aplikaci.

Omezení umístění a syntaxe vlastností uzlu

Hodnota zadaná ve vlastnosti node může být řetězec, logická hodnota nebo dlouhý podpis. Příkaz ve službě se nazývá omezení umístění, protože omezuje, kde může služba běžet v clusteru. Omezením může být libovolný logický příkaz, který pracuje s vlastnostmi uzlu v clusteru. Platné selektory v těchto logických příkazech jsou:

• Podmíněné kontroly pro vytváření konkrétních příkazů:

  Příkaz	Syntax
  "je rovno"	"=="
  "není rovno"	"!="
  "větší než"	">"
  "větší než nebo rovno"	">="
  "menší než"	"<"
  "menší než nebo rovno"	"<="

• Logické příkazy pro seskupení a logické operace:

  Příkaz	Syntax
  "and"	"&&"
  "or"	"||"
  mění	"!"
  "seskupit jako jeden příkaz"	"()"

Tady je několik příkladů základních příkazů omezení:

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

V případě, že je vyhodnocena jako "true", může být služba umístěna pouze v uzlech, kde je uvedena celková hodnota omezení umístění. Uzly, které nemají definovanou vlastnost, neodpovídají žádnému omezení umístění, které obsahuje vlastnost.

Řekněme, že následující vlastnosti uzlu byly definovány pro typ uzlu v ClusterManifest.xml:

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

Následující příklad ukazuje vlastnosti uzlu definované pomocí ClusterConfig.jsv pro samostatná nasazení nebo Template.jsv případě clusterů hostovaných v Azure.

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

Omezení umístění služby můžete pro službu vytvořit následujícím způsobem:

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"

Pokud jsou všechny uzly NodeType01 platné, můžete také vybrat tento typ uzlu s omezením "(NodeType == NodeType01)" .

Omezení umístění služby je možné během běhu aktualizovat dynamicky. Pokud potřebujete, můžete přesunout službu v rámci clusteru, přidat a odebrat požadavky a tak dále. Service Fabric zajistí, že služba zůstane v provozu a dostupná i v případě, že jsou provedeny tyto typy změn.

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"

Omezení umístění jsou určena pro každou pojmenovanou instanci služby. Aktualizace vždy přebírají místo (přepsat), co bylo dříve zadáno.

Definice clusteru definuje vlastnosti uzlu. Změna vlastností uzlu vyžaduje upgrade na konfiguraci clusteru. Upgrade vlastností uzlu vyžaduje, aby byl každý ovlivněný uzel restartován, aby nahlásil nové vlastnosti. Service Fabric tyto postupné inovace spravuje.

Popis a správa prostředků clusteru

Jednou z nejdůležitějších úloh jakéhokoli orchestrátoru je pomoc se spravování spotřeby prostředků v clusteru. Správa prostředků clusteru může znamenat několik různých věcí.

Nejprve se zajistí, že počítače nebudou přetížené. To znamená zajistit, aby na počítačích neběhlo více služeb, než dokáže zvládnout.

Za druhé existuje vyvážení a optimalizace, které jsou důležité pro efektivní provoz služeb. Nákladově efektivní nabídky služeb nebo nabídky služeb citlivé na výkon neumožňují, aby některé uzly měly horkou horkou paměť, zatímco jiné jsou studené. Horké uzly vedou ke poraci prostředků a špatnému výkonu. Studené uzly představují plýtvání prostředky a zvýšené náklady.

Service Fabric představuje prostředky jako metriky. Metriky jsou všechny logické nebo fyzické prostředky, které chcete popsat pro Service Fabric. Příklady metrik jsou WorkQueueDepth nebo MemoryInMb. Informace o fyzických prostředcích, které Service Fabric správného řízení na uzlech, najdete v tématu Zásady správného řízení prostředků. Informace o výchozích metrikách používaných webovou Správce prostředků clusteru a o tom, jak nakonfigurovat vlastní metriky, najdete v tomto článku.

Metriky se liší od omezení umístění a vlastností uzlu. Vlastnosti uzlu jsou statické popisovače samotných uzlů. Metriky popisují prostředky, které uzly mají a které služby spotřebovávají, když běží na uzlu. Vlastnost uzlu může být HasSSD a může být nastavená na true nebo false. Množství dostupného místa na tomto disku SSD a kolik spotřebovávají služby, by byla metrika jako "DriveSpaceInMb".

Stejně jako u omezení umístění a vlastností uzlu ani Service Fabric Správce prostředků clusteru, co názvy metrik znamenají. Názvy metrik jsou pouze řetězce. Je dobrým zvykem deklarovat jednotky jako součást názvů metrik, které vytvoříte, když budou pravděpodobně dvojznačné.

Kapacita

Pokud jste vypnuli veškeré Vyrovnávání prostředků, Service Fabric správce prostředků clusteru by pořád zajistil, že žádný uzel nepřekračuje kapacitu. Je možné spravovat přetečení kapacity, pokud není cluster příliš úplný nebo je zatížení větší než u libovolného uzlu. Kapacita je jiné omezení , které clusterová správce prostředků používá k pochopení, kolik prostředků má uzel. Zbývající kapacita je také sledována pro cluster jako celek. Počínaje Service Fabric 8,1 lze kapacitu uzlů dynamicky aktualizovat bez přerušení provozu úloh.

Kapacita i spotřeba na úrovni služby se vyjadřují v souvislosti s metrikami. Metrika může být například "ClientConnections" a uzel může mít kapacitu "ClientConnections" z 32 768. Ostatní uzly mohou mít další omezení. Služba spuštěná v tomto uzlu může říci, že aktuálně spotřebovává 32 256 metriky "ClientConnections".

Cluster Správce prostředků během doby běhu sledovat zbývající kapacitu v clusteru a na uzlech. Ke sledování kapacity cluster Správce prostředků odečte využití jednotlivých služeb od kapacity uzlu, kde je služba spuštěná. S těmito informacemi může cluster Správce prostředků zjistit, kde umístit nebo přesunout repliky, aby uzly nepřešly do kapacity.

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)

Můžete zobrazit kapacity definované v manifestu clusteru. Tady je příklad pro ClusterManifest.xml:

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

Tady je příklad kapacit definovaných prostřednictvím ClusterConfig.jspro samostatné nasazení nebo Template.jsv případě clusterů hostovaných v Azure:

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

Načítání služby se často mění dynamicky. Řekněme, že zatížení repliky "ClientConnections" se změnilo z 1 024 na 2 048. Uzel, na který běžel, pak měl pro metriku kapacitu pouze 512 zbývajících. Umístění repliky nebo instance je teď neplatné, protože na tomto uzlu není dostatek místa. Správce prostředků clusteru musí uzel dostat zpět pod kapacitu. Snižuje zatížení uzlu, který přetěžuje kapacitu, přesunutím jedné nebo více replik nebo instancí z tohoto uzlu do jiných uzlů.

Správce prostředků clusteru se snaží minimalizovat náklady na přesun replik. Další informace o nákladech na pohyb a o vyvažovánístrategií a pravidel najdete tady: .

Kapacita clusteru

Jak aplikace Service Fabric Správce prostředků clusteru, aby byl celkový cluster příliš plný? Při dynamickém zatížení není k dispozici mnoho. Služby mohou mít špičku zatížení nezávisle na akcích, které Správce prostředků clusteru provádět. V důsledku toho může být váš cluster s mnoha prostory v dnešní době pod kontrolou, pokud zítra dojde ke špičkě.

Ovládací prvky v Správce prostředků clusteru pomáhají předcházet problémům. První věc, kterou můžete udělat, je zabránit vytvoření nových úloh, které by způsobily, že se cluster zaplní.

Řekněme, že vytvoříte bezvýkonnou službu, ke které je přidruženo určité zatížení. Služba se stará o metriku DiskSpaceInMb. Služba bude pro každou instanci služby spotřebovávat pět jednotek "DiskSpaceInMb". Chcete vytvořit tři instance služby. To znamená, že potřebujete 15 jednotek DiskSpaceInMb, abyste v clusteru dokonce vytvořili tyto instance služby.

Správce prostředků clusteru průběžně počítá kapacitu a spotřebu jednotlivých metrik, aby mohl určit zbývající kapacitu v clusteru. Pokud není dostatek místa, Správce prostředků clusteru odmítne volání pro vytvoření služby.

Vzhledem k tomu, že požadavek je pouze k dispozici pro 15 jednotek, můžete toto místo přidělit mnoha různými způsoby. Například může existovat jedna zbývající kapacita jednotky na 15 různých uzlech nebo tři zbývající jednotky kapacity na pěti různých uzlech. Pokud cluster Správce prostředků může změnit uspořádání položek tak, aby bylo na třech uzlech dostupné pět jednotek, služba umístí. Změna uspořádání clusteru je obvykle možná, pokud není cluster téměř úplný, nebo z nějakého důvodu nelze konsolidovat stávající služby.

Kapacita vyrovnávací paměti uzlu a přetečení

Pokud je zadána kapacita uzlu pro metriku, cluster Správce prostředků nikdy nebude umísťovat ani přesouvat repliky do uzlu, pokud by celková zátěž přešla nad určenou kapacitu uzlu. To může někdy zabránit umístění nových replik nebo nahrazení neúspěšných replik, pokud má cluster blízko celou kapacitu a replika s velkým zatížením musí být vložena, nahrazena nebo přesunuta.

Aby bylo možné zajistit větší flexibilitu, můžete zadat buď vyrovnávací paměť uzlu, nebo kapacitu pro přetečení. Když je v rámci metriky zadaná vyrovnávací paměť uzlu nebo kapacita přetečení, cluster Správce prostředků se pokusí umístit nebo přesunout repliky takovým způsobem, že vyrovnávací paměť nebo kapacita při přetečení zůstanou nevyužité, ale umožňuje použití vyrovnávací paměti nebo vymezené kapacity, pokud je to nutné pro akce, které zvyšují dostupnost služby, jako je například:

• Nové umístění repliky nebo nahrazení neúspěšných replik
• Umístění během upgradů
• Oprava porušení provizorního a pevného omezení
• Defragmentace

Kapacita vyrovnávací paměti uzlu představuje rezervovanou část kapacity níže zadané kapacity uzlu a kapacita při zastavování představuje část nadbytečné kapacity nad zadanou kapacitou uzlu. V obou případech se cluster Správce prostředků pokusí zachovat tuto kapacitu zdarma.

Pokud má například uzel zadanou kapacitu pro metriku CpuUtilization 100 a procento vyrovnávací paměti uzlu pro příslušnou metriku je nastaveno na 20 %, pak celková kapacita a kapacita bez vyrovnávací paměti bude 100 a 80 v uvedeném pořadí a Správce prostředků clusteru nebude během normálních okolností do uzlu zatěžovat více než 80 jednotek zatížení.

Vyrovnávací paměť uzlu by se měla použít, když chcete rezervovat část kapacity uzlu, která se bude používat pouze pro akce, které zvyšují dostupnost služby uvedenou výše.

Na druhé straně platí, že pokud se použije procento přetížení uzlu a nastaví se na 20 %, celkový počet kapacit a kapacit bez vyrovnávací paměti bude 120 a 100.

Kapacita pro přehánění by se měla použít, když chcete povolit, Správce prostředků clusteru repliky umístit do uzlu i v případě, že jejich celkové využití prostředků překročí kapacitu. Můžete ho použít k zajištění další dostupnosti služeb na úkor výkonu. Pokud se používá přebookování, logika aplikace uživatele musí být schopná fungovat s menším počtem fyzických prostředků, než by to mohlo vyžadovat.

Pokud je zadaná vyrovnávací paměť uzlu nebo kapacity pro přehánění, Správce prostředků clusteru se přesune nebo neumisní repliky, pokud by celkové zatížení cílového uzlu přetěžuje celkovou kapacitu (kapacita uzlu v případě vyrovnávací paměti uzlu a kapacity uzlu + kapacita přehánění v případě přehánění).

Kapacitu přetížování je také možné zadat jako neomezenou. V takovém případě se Správce prostředků clusteru pokusí udržet celkové zatížení uzlu pod zadanou kapacitou uzlu, ale může potenciálně způsobit mnohem větší zatížení uzlu, což by mohlo vést k závažnému snížení výkonu.

Metrika nemůže mít zadanou vyrovnávací paměť uzlu a kapacitu pro přetížování současně.

Tady je příklad, jak zadat vyrovnávací paměť uzlu nebo kapacity pro 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>

Tady je příklad, jak určit kapacitu pro vytvoření vyrovnávací paměti uzlu nebo při přetečení pomocí ClusterConfig.jsv pro samostatná nasazení nebo Template.jsv případě clusterů hostovaných v Azure:

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

Další kroky

• Informace o architektuře a toku informací v rámci clusteru Správce prostředků najdete v tématu Přehled architektury clusterových správce prostředků.
• Definování metrik defragmentace je jedním ze způsobů, jak konsolidovat zatížení uzlů místo jejich rozprostření. Informace o tom, jak nakonfigurovat defragmentaci, najdete v tématu Defragmentace metrik a načítání v Service Fabric.
• Začněte od začátku a Získejte Úvod do Service Fabric správce prostředků clusteru.
• Informace o tom, jak cluster Správce prostředků spravuje a vyrovnává zatížení v clusteru, najdete v tématu Balancing the Service Fabric cluster.