Fürterőforrás-kezelő integrációja a Service Fabric-fürtkezeléssel

A Service Fabric-fürt Resource Managere nem hajtja végre a frissítéseket a Service Fabricben, de benne van. A fürterőforrás-kezelő elsőként a fürt kívánt állapotának és a benne lévő szolgáltatásoknak a nyomon követésével segít a felügyeletben. A Fürterőforrás-kezelő állapotjelentéseket küld, ha nem tudja a fürtöt a kívánt konfigurációba helyezni. Ha például nincs elegendő kapacitás, a fürterőforrás-kezelő állapotjelzéseket és hibákat küld a problémára vonatkozóan. Egy másik integrációnak a frissítések működéséhez kell köze. A fürterőforrás-kezelő kissé módosítja a működését a frissítések során.

Állapotintegráció

A fürterőforrás-kezelő folyamatosan nyomon követi a szolgáltatások elhelyezéséhez meghatározott szabályokat. Emellett nyomon követi a csomópontokon, a fürtön és a fürt egészében lévő összes metrika fennmaradó kapacitását. Ha nem felel meg ezeknek a szabályoknak, vagy ha nincs elegendő kapacitás, állapotjelzések és hibák jelennek meg. Ha például egy csomópont túl van a kapacitáson, és a fürterőforrás-kezelő megpróbálja kijavítani a helyzetet a szolgáltatások áthelyezésével. Ha nem tudja kijavítani a helyzetet, állapotjelzést ad ki, amely jelzi, hogy melyik csomópont van a kapacitáson túl, és mely metrikákhoz.

A Resource Manager állapotjelzéseinek egy másik példája az elhelyezési korlátozások megsértése. Ha például egy elhelyezési kényszert (például “NodeColor == Blue”) definiált, és a Resource Manager észleli a korlátozás megsértését, állapotjelzést ad ki. Ez igaz az egyéni korlátozásokra és az alapértelmezett korlátozásokra (például a tartalék tartományra és a frissítési tartományra vonatkozó korlátozásokra).

Íme egy példa egy ilyen állapotjelentésre. Ebben az esetben az állapotjelentés a rendszerszolgáltatás egyik partíciójára vonatkozik. Az állapotüzenet azt jelzi, hogy a partíció replikái átmenetileg túl kevés frissítési tartományba vannak csomagolva.

PS C:\Users\User > Get-ServiceFabricPartitionHealth -PartitionId '00000000-0000-0000-0000-000000000001'


PartitionId           : 00000000-0000-0000-0000-000000000001
AggregatedHealthState : Warning
UnhealthyEvaluations  :
                        Unhealthy event: SourceId='System.PLB', Property='ReplicaConstraintViolation_UpgradeDomain', HealthState='Warning', ConsiderWarningAsError=false.

ReplicaHealthStates   :
                        ReplicaId             : 130766528804733380
                        AggregatedHealthState : Ok

                        ReplicaId             : 130766528804577821
                        AggregatedHealthState : Ok

                        ReplicaId             : 130766528854889931
                        AggregatedHealthState : Ok

                        ReplicaId             : 130766528804577822
                        AggregatedHealthState : Ok

                        ReplicaId             : 130837073190680024
                        AggregatedHealthState : Ok

HealthEvents          :
                        SourceId              : System.PLB
                        Property              : ReplicaConstraintViolation_UpgradeDomain
                        HealthState           : Warning
                        SequenceNumber        : 130837100116930204
                        SentAt                : 8/10/2015 7:53:31 PM
                        ReceivedAt            : 8/10/2015 7:53:33 PM
                        TTL                   : 00:01:05
                        Description           : The Load Balancer has detected a Constraint Violation for this Replica: fabric:/System/FailoverManagerService Secondary Partition 00000000-0000-0000-0000-000000000001 is
                        violating the Constraint: UpgradeDomain Details: UpgradeDomain ID -- 4, Replica on NodeName -- Node.8 Currently Upgrading -- false Distribution Policy -- Packing
                        RemoveWhenExpired     : True
                        IsExpired             : False
                        Transitions           : Ok->Warning = 8/10/2015 7:13:02 PM, LastError = 1/1/0001 12:00:00 AM

Ez az állapotüzenet a következőt mondja nekünk:

1. Maguk a replikák kifogástalan állapotban vannak: mindegyik rendelkezik AggregatedHealthState : Ok
2. A frissítési tartomány terjesztési korlátozását jelenleg megsértik. Ez azt jelenti, hogy egy adott frissítési tartománynak több replikája van ebből a partícióból, mint kellene.
3. Melyik csomópont tartalmazza a szabálysértést okozó replikát. Ebben az esetben ez az a csomópont, amelynek a neve Node.8
4. Folyamatban van-e frissítés erre a partícióra ("Aktuális frissítés –- false")
5. A szolgáltatás terjesztési szabályzata: "Terjesztési szabályzat – Csomagolás". Ezt az elhelyezési RequireDomainDistribution szabályzat szabályozza. A csomagolás azt jelzi, hogy ebben az esetben a DomainDistribution nem volt kötelező, ezért tudjuk, hogy az elhelyezési szabályzat nincs megadva ehhez a szolgáltatáshoz.
6. Amikor a jelentés megtörtént - 2015.08.10. 19:13:02

Az ilyen információk riasztást adnak. Az éles környezetben lévő riasztásokkal tudathatja, hogy valami hiba történt. A riasztás a hibás frissítések észlelésére és leállítására is használható. Ebben az esetben szeretnénk megtudni, hogy ki tudjuk-e deríteni, miért kellett a Resource Managernek a replikákat a frissítési tartományba csomagolnia. A csomagolás általában átmeneti, mert a többi frissítési tartomány csomópontjai például leálltak.

Tegyük fel, hogy a fürterőforrás-kezelő bizonyos szolgáltatásokat próbál elhelyezni, de nincsenek működő megoldások. Ha a szolgáltatások nem helyezhetők el, az általában az alábbi okok valamelyike miatt történik:

1. Néhány átmeneti feltétel lehetetlenné tette a szolgáltatáspéldány vagy a replika helyes elhelyezését
2. A szolgáltatás elhelyezési követelményei nem kielégítőek.

Ezekben az esetekben a Fürterőforrás-kezelő állapotjelentései segítenek meghatározni, hogy miért nem helyezhető el a szolgáltatás. Ezt a folyamatot kényszerelhárítási sorozatnak nevezzük. Ennek során a rendszer végigvezeti a szolgáltatásra vonatkozó konfigurált korlátozásokon, és rögzíti, hogy mit szüntetnek meg. Így, amikor a szolgáltatások nem helyezhetők el, láthatja, hogy mely csomópontokat szüntették meg, és miért.

Kényszertípusok

Beszéljünk az állapotjelentések különböző korlátairól. Ha a replikák nem helyezhetők el, ezekhez a korlátozásokhoz kapcsolódó állapotüzenetek jelennek meg.

• ReplicaExclusionStatic és ReplicaExclusionDynamic: Ezek a korlátozások azt jelzik, hogy a megoldás elutasításra került, mert ugyanazon a partíción két szolgáltatásobjektumot kell elhelyezni ugyanazon a csomóponton. Ez nem engedélyezett, mert a csomópont meghibásodása túlzottan hatással lenne erre a partícióra. ReplicaExclusionStatic és ReplicaExclusionDynamic szinte ugyanaz a szabály, és a különbségek nem igazán számítanak. Ha a ReplicaExclusionStatic vagy a ReplicaExclusionDynamic kényszert tartalmazó kényszerelhárítási sorozatot lát, a fürterőforrás-kezelő úgy véli, hogy nincs elég csomópont. Ehhez további megoldásokra van szükség az érvénytelen elhelyezések használatához, amelyek nem engedélyezettek. A sorozat többi kényszere általában azt jelzi, hogy miért szüntetik meg a csomópontokat.
• PlacementConstraint: Ha ezt az üzenetet látja, az azt jelenti, hogy megszüntettünk néhány csomópontot, mert azok nem felelnek meg a szolgáltatás elhelyezési korlátainak. Az üzenet részeként nyomon követjük a jelenleg konfigurált elhelyezési korlátozásokat. Ez normális, ha egy elhelyezési korlátozás van meghatározva. Ha azonban az elhelyezési kényszer helytelenül okoz túl sok csomópont eltávolítását, ezt fogja észrevenni.
• NodeCapacity: Ez a korlátozás azt jelenti, hogy a fürterőforrás-kezelő nem tudta elhelyezni a replikákat a megjelölt csomópontokon, mert az átterjedt a kapacitásra.
• Affinitás: Ez a korlátozás azt jelzi, hogy nem sikerült a replikát elhelyezni az érintett csomópontokon, mert az az affinitási kényszer megsértését okozná. Az affinitással kapcsolatos további információk ebben a cikkben találhatók
• FaultDomain és UpgradeDomain: Ez a korlátozás kiküszöböli a csomópontokat, ha a replika a megjelölt csomópontokon való elhelyezése egy adott hiba- vagy frissítési tartományban történő csomagolást okozna. A hiba- és frissítési tartománykorlátozásokról és az ebből eredő viselkedésről szóló témakör több példát is bemutat a korlátozásról
• PreferredLocation: Ez a korlátozás általában nem távolítja el a csomópontokat a megoldásból, mivel alapértelmezés szerint optimalizálásként fut. Az előnyben részesített helymegkötés a frissítések során is jelen van. A frissítés során a szolgáltatások visszahelyezhetők oda, ahol a frissítés elkezdődött.

Csomópontok blokkolása

A Fürterőforrás-kezelő jelentései egy másik állapotüzenet, amikor a csomópontok tiltva vannak. A tiltólistát ideiglenes kényszernek tekintheti, amelyet a rendszer automatikusan alkalmaz Önre. A csomópontok akkor lesznek letiltva, ha ismétlődő hibákat tapasztalnak az adott szolgáltatástípus példányainak indításakor. A csomópontok szolgáltatástípusonként vannak tiltva. Előfordulhat, hogy egy csomópontot egy szolgáltatástípus tilt, egy másikat azonban nem.

A fejlesztés során gyakran jelenik meg a tiltólista: Néhány hiba miatt a szolgáltatásgazda összeomlik az indításkor, a Service Fabric néhányszor megpróbálja létrehozni a szolgáltatás gazdagépét, és a hiba továbbra is fennáll. Néhány kísérlet után a csomópont blokkolva lesz, és a fürterőforrás-kezelő megpróbálja máshol létrehozni a szolgáltatást. Ha a hiba több csomóponton is előfordul, lehetséges, hogy a fürt összes érvényes csomópontja le van tiltva. A tiltás olyan sok csomópontot is eltávolíthat, hogy nem elég, hogy sikeresen elindítsa a szolgáltatást a kívánt méretarány eléréséhez. Általában további hibák vagy figyelmeztetések jelennek meg a Fürterőforrás-kezelőtől, amely azt jelzi, hogy a szolgáltatás a kívánt replika vagy példányszám alatt van, valamint állapotüzenetek jelzik, hogy mi a hiba, ami a tiltólistához vezet.

A tiltás nem állandó feltétel. Néhány perc elteltével a csomópont el lesz távolítva a tiltólistáról, és a Service Fabric újra aktiválhatja a szolgáltatásokat ezen a csomóponton. Ha a szolgáltatások továbbra is sikertelenek, a csomópont ismét letiltja az adott szolgáltatástípust.

Kényszerprioritások

Figyelmeztetés

A kényszerprioritások módosítása nem ajánlott, és jelentős káros hatással lehet a fürtre. Az alábbi információk az alapértelmezett kényszerprioritásokra és azok viselkedésére hivatkoznak.

Az összes ilyen megkötések, lehet, hogy arra gondolt: "Hey – Azt hiszem, hogy a tartalék tartomány megkötései a legfontosabb dolog a rendszeremben. Annak érdekében, hogy a tartalék tartományra vonatkozó korlátozás ne sérüljön, hajlandó vagyok más korlátozásokat is megsérteni."

A korlátozások különböző prioritási szintekkel konfigurálhatók. Ezek a következők:

• "kemény" (0)
• "soft" (1)
• "optimalizálás" (2)
• "off" (-1).

A legtöbb korlátozás alapértelmezés szerint kemény kényszerként van konfigurálva.

A kényszerek prioritásának módosítása nem gyakori. Voltak olyan időszakok, amikor a kényszerprioritások módosítására volt szükség, általában valamilyen más, a környezetet érintő hiba vagy viselkedés megkerüléséhez. A kényszerprioritású infrastruktúra rugalmassága általában nagyon jól működik, de gyakran nincs rá szükség. Legtöbbször minden az alapértelmezett prioritásokat irányítja.

A prioritási szintek nem jelentik azt, hogy egy adott korlátozás sérül, és nem is mindig teljesül. A kényszerprioritások egy sorrendet határoznak meg, amelyben a kényszerek érvénybe lépnek. A prioritások akkor határozzák meg a kompromisszumokat, ha lehetetlen minden korlátozást kielégíteni. Általában az összes korlátozás teljesülhet, kivéve, ha valami más történik a környezetben. A kényszerek megsértéséhez vezető forgatókönyvek némelyike ütköző kényszer, vagy nagy számú egyidejű hiba.

Speciális helyzetekben módosíthatja a kényszer prioritásait. Tegyük fel például, hogy biztosítani szeretné, hogy az affinitás mindig sérüljön, ha a csomópont kapacitásproblémáinak megoldásához szükség van rá. Ennek eléréséhez az affinitási kényszer prioritását "puha" (1) értékre állíthatja, és a kapacitáskényszert "kemény" (0) értékre állíthatja.

A különböző korlátozások alapértelmezett prioritási értékei a következő konfigurációban vannak megadva:

ClusterManifest.xml

        <Section Name="PlacementAndLoadBalancing">
            <Parameter Name="PlacementConstraintPriority" Value="0" />
            <Parameter Name="CapacityConstraintPriority" Value="0" />
            <Parameter Name="AffinityConstraintPriority" Value="0" />
            <Parameter Name="FaultDomainConstraintPriority" Value="0" />
            <Parameter Name="UpgradeDomainConstraintPriority" Value="1" />
            <Parameter Name="PreferredLocationConstraintPriority" Value="2" />
        </Section>

ClusterConfig.json önálló üzemelő példányokhoz vagy azure-beli üzemeltetett fürtökhöz készült Template.json:

"fabricSettings": [
  {
    "name": "PlacementAndLoadBalancing",
    "parameters": [
      {
          "name": "PlacementConstraintPriority",
          "value": "0"
      },
      {
          "name": "CapacityConstraintPriority",
          "value": "0"
      },
      {
          "name": "AffinityConstraintPriority",
          "value": "0"
      },
      {
          "name": "FaultDomainConstraintPriority",
          "value": "0"
      },
      {
          "name": "UpgradeDomainConstraintPriority",
          "value": "1"
      },
      {
          "name": "PreferredLocationConstraintPriority",
          "value": "2"
      }
    ]
  }
]

Tartalék tartomány és frissítési tartomány korlátozásai

A fürterőforrás-kezelő a tartalék és a frissítési tartományok között szeretné elosztani a szolgáltatásokat. Ezt kényszerként modellozza a Fürterőforrás-kezelő motorján belül. A használatukról és a működésükről további információt a fürtkonfigurációról szóló cikkben talál.

Előfordulhat, hogy a fürterőforrás-kezelőnek be kell csomagolnia néhány replikát egy frissítési tartományba a frissítések, hibák vagy egyéb korlátozások megsértéseinek kezeléséhez. A hiba- vagy frissítési tartományokba való csomagolás általában csak akkor történik meg, ha a rendszerben több hiba vagy egyéb változás akadályozza a helyes elhelyezést. Ha még ezekben a helyzetekben is meg szeretné akadályozni a csomagolást, használhatja az elhelyezési RequireDomainDistribution szabályzatot. Vegye figyelembe, hogy ez mellékhatásként befolyásolhatja a szolgáltatás rendelkezésre állását és megbízhatóságát, ezért körültekintően vegye figyelembe.

Ha a környezet megfelelően van konfigurálva, a rendszer minden korlátozást teljes mértékben betart, még a frissítések során is. A legfontosabb az, hogy a fürterőforrás-kezelő figyeli a korlátozásokat. Ha szabálysértést észlel, azonnal jelenti, és megpróbálja kijavítani a problémát.

Az előnyben részesített helymegkötés

A PreferredLocation kényszer kissé eltérő, mivel két különböző felhasználási módja van. Ennek a korlátozásnak az egyik használata az alkalmazásfrissítések során történik. A fürterőforrás-kezelő automatikusan kezeli ezt a korlátozást a frissítések során. Annak biztosítására szolgál, hogy a frissítések befejezésekor a replikák visszatérjenek a kezdeti helyükre. A PreferredLocation kényszer másik használata az elhelyezési PreferredPrimaryDomain szabályzatra érvényes. Mindkettő optimalizálás, ezért alapértelmezés szerint a PreferredLocation kényszer az egyetlen "Optimalizálás" korlát.

Frissítések

A Fürterőforrás-kezelő az alkalmazás- és fürtfrissítések során is segít, amelynek során két feladat áll a számára:

• győződjön meg arról, hogy a fürt szabályai nem sérülnek
• próbálja meg segíteni a frissítést zökkenőmentesen

A szabályok betartatása

A legfontosabb tudnivaló az, hogy a szabályok – például az elhelyezési korlátozások és a kapacitások – továbbra is érvényben vannak a frissítések során. Az elhelyezési korlátozások biztosítják, hogy a számítási feladatok csak ott fussanak, ahol engedélyezve vannak, még a frissítések során is. Ha a szolgáltatások erősen korlátozottak, a frissítések hosszabb időt is igénybe vehetnek. Ha a szolgáltatás vagy annak csomópontja le van hozva egy frissítésre, előfordulhat, hogy kevés lehetőség van arra, hogy hová menjen.

Intelligens csere

A frissítés indításakor a Resource Manager pillanatképet készít a fürt aktuális elrendezéséről. Amikor minden frissítési tartomány befejeződik, megpróbálja visszaadni a frissítési tartományban lévő szolgáltatásokat az eredeti elrendezésüknek. Így a frissítés során legfeljebb két áttűnés áll rendelkezésre egy szolgáltatáshoz. Van egy áthelyezés az érintett csomópontról, egy pedig vissza. Ha visszaadja a fürtöt vagy szolgáltatást a frissítés előtti folyamatnak, az azt is biztosítja, hogy a frissítés ne befolyásolja a fürt elrendezését.

Csökkentett forgalom

A frissítések során a fürterőforrás-kezelő is kikapcsolja a kiegyensúlyozást. A kiegyensúlyozás megakadályozása megakadályozza a frissítés szükségtelen reakcióit, például a szolgáltatásokat a frissítéshez kiürített csomópontokba helyezi át. Ha a szóban forgó frissítés fürtfrissítés, akkor a teljes fürt nem lesz egyensúlyban a frissítés során. A kényszerellenőrzések aktívak maradnak, csak a metrikák proaktív kiegyensúlyozásán alapuló mozgás le van tiltva.

Pufferelt kapacitás és frissítés

Általában azt szeretné, hogy a frissítés akkor is befejeződjön, ha a fürt korlátozott vagy közel van a teljeshez. A fürt kapacitásának kezelése a szokásosnál is fontosabb a frissítések során. A frissítési tartományok számától függően a kapacitás 5–20 százalékát át kell migrálni, amikor a frissítés a fürtön halad át. A munkának valahol el kell mennie. Itt hasznos a pufferelt kapacitások fogalma. A pufferelt kapacitást a rendszer a normál működés során tiszteletben tartja. A fürterőforrás-kezelő szükség esetén feltöltheti a csomópontokat a teljes kapacitásukig (a puffert használva).

Következő lépések

• Kezdje az elejétől, és ismerkedjen meg a Service Fabric-fürt Resource Managerével