Service Fabric-fürt leírása a Fürterőforrás-kezelővel
Az Azure Service Fabric Fürterőforrás-kezelő funkciója számos mechanizmust biztosít a fürtök leírására:
- Tartalék tartományok
- Tartományok frissítése
- Csomópont tulajdonságai
- Csomópont-kapacitások
A futtatókörnyezet során a Fürterőforrás-kezelő ezeket az információkat felhasználva biztosítja a fürtben futó szolgáltatások magas rendelkezésre állását. A fontos szabályok kényszerítése mellett megpróbálja optimalizálni az erőforrás-felhasználást a fürtön belül.
Tartalék tartományok
A tartalék tartomány a koordinált hiba bármely területe. Egyetlen gép egy tartalék tartomány. Különböző okokból önállóan is meghiúsulhat, az áramellátási hibáktól a hibás hálózati adapterek meghibásodásán át a hibás hálózati adapter belső vezérlőprogramig.
Az ugyanahhoz az Ethernet-kapcsolóhoz csatlakoztatott gépek ugyanabban a tartalék tartományban vannak. Így vannak azok a gépek is, amelyek egyetlen áramforrással vagy egyetlen helyen osztoznak.
Mivel természetes, hogy a hardverhibák átfedésben vannak, a tartalék tartományok eredendően hierarchikusak. A Service Fabricben URI-kként vannak képviselve.
Fontos, hogy a tartalék tartományok megfelelően legyenek beállítva, mert a Service Fabric ezeket az információkat használja a szolgáltatások biztonságos elhelyezéséhez. A Service Fabric nem szeretne olyan szolgáltatásokat elhelyezni, hogy egy tartalék tartomány elvesztése (amelyet egy összetevő meghibásodása okoz) a szolgáltatás leállását okozza.
Az Azure-környezetben a Service Fabric a környezet által biztosított tartalék tartományinformációkkal konfigurálja a fürt csomópontjait az Ön nevében. A Service Fabric önálló példányai esetében a tartalék tartományok a fürt beállításakor vannak meghatározva.
Figyelmeztetés
Fontos, hogy a Service Fabricnek megadott tartalék tartomány adatai pontosak legyenek. Tegyük fel például, hogy a Service Fabric-fürt csomópontjai 10 virtuális gépen futnak, és 5 fizikai gazdagépen futnak. Ebben az esetben annak ellenére, hogy 10 virtuális gép van, csak 5 különböző (legfelső szintű) tartalék tartomány létezik. Ha ugyanazt a fizikai gazdagépet osztja meg, a virtuális gépek ugyanazt a gyökér tartalék tartományt használják, mert a virtuális gépek összehangolt hibát tapasztalnak, ha a fizikai gazdagép meghibásodik.
A Service Fabric elvárja, hogy a csomópont tartalék tartománya ne változzon. A virtuális gépek magas rendelkezésre állásának biztosítására szolgáló egyéb mechanizmusok, például a HA-VM-ek ütközéseket okozhatnak a Service Fabricdel. Ezek a mechanizmusok a virtuális gépek transzparens migrálását használják az egyik gazdagépről a másikra. Nem konfigurálják újra és nem értesítik a futó kódot a virtuális gépen belül. Ezért nem támogatottak a Service Fabric-fürtök futtatásához használt környezetek.
A Service Fabric legyen az egyetlen magas rendelkezésre állású technológia. Az olyan mechanizmusokra, mint az élő virtuális gépek migrálása és az SAN-k nem szükségesek. Ha ezeket a mechanizmusokat a Service Fabricdel együtt használják, akkor csökkentik az alkalmazások rendelkezésre állását és megbízhatóságát. Ennek az az oka, hogy további összetettséget vezetnek be, központosított hibaforrásokat adnak hozzá, és olyan megbízhatósági és rendelkezésre állási stratégiákat használnak, amelyek ütköznek a Service Fabricben lévőkkel.
Az alábbi ábrán az összes olyan entitást kiszínezzük, amely hozzájárul a tartalék tartományokhoz, és felsoroljuk az összes különböző hibatartományt, amelyek eredményeként létrejönnek. Ebben a példában adatközpontok ("DC"), állványok ("R" ) és panelek ("B") vannak. Ha minden panel egynél több virtuális gépet tartalmaz, előfordulhat, hogy a tartalék tartományhierarchia egy másik rétege is található.
Futásidőben a Service Fabric-fürt Resource Managere figyelembe veszi a fürt tartalék tartományait és a tervelrendezéseket. A szolgáltatás állapotalapú replikái vagy állapot nélküli példányai el vannak osztva, így külön tartalék tartományokban vannak. A szolgáltatás tartalék tartományok közötti elosztása biztosítja, hogy a szolgáltatás rendelkezésre állása ne sérüljon, ha egy tartalék tartomány a hierarchia bármely szintjén meghibásodik.
A fürterőforrás-kezelő nem érdekli, hogy hány réteg van a tartalék tartományhierarchiában. Megpróbálja biztosítani, hogy a hierarchia bármely részének elvesztése ne befolyásolja a benne futó szolgáltatásokat.
A legjobb, ha a hibatartomány-hierarchia minden mélységi szintjén azonos számú csomópont található. Ha a tartalék tartományok "fája" kiegyensúlyozatlan a fürtben, a Fürterőforrás-kezelő nehezebben tudja megállapítani a szolgáltatások legjobb lefoglalását. A tartalék tartományok kiegyensúlyozatlan elrendezései azt jelentik, hogy egyes tartományok elvesztése a többi tartománynál jobban befolyásolja a szolgáltatások rendelkezésre állását. Ennek eredményeként a fürterőforrás-kezelő két cél között szakad el:
- A "nehéz" tartományban lévő gépeket úgy szeretné használni, hogy szolgáltatásokat helyez el rajtuk.
- Más tartományokban szeretné elhelyezni a szolgáltatásokat, hogy a tartomány elvesztése ne okozzon problémát.
Hogyan néznek ki a kiegyensúlyozatlan tartományok? Az alábbi ábrán két különböző fürtelrendezés látható. Az első példában a csomópontok egyenletesen vannak elosztva a tartalék tartományok között. A második példában az egyik tartalék tartománynak több csomópontja van, mint a többi tartalék tartománynak.
Az Azure-ban a rendszer felügyeli a csomópontot tartalmazó tartalék tartomány kiválasztását. A kiépített csomópontok számától függően azonban továbbra is olyan tartalék tartományokhoz kerülhet, amelyekben több csomópont található, mint másokban.
Tegyük fel például, hogy öt tartalék tartománya van a fürtben, de hét csomópontot épít ki egy csomóponttípushoz (NodeType). Ebben az esetben az első két tartalék tartomány több csomóponttal végződik. Ha továbbra is több NodeType-példányt helyez üzembe csak néhány példánysal, a probléma egyre rosszabb lesz. Ezért azt javasoljuk, hogy az egyes csomóponttípusok csomópontjainak száma a tartalék tartományok számának többszöröse legyen.
Tartományok frissítése
A tartományok frissítése egy másik funkció, amely segít a Service Fabric-fürt Resource Managerének megérteni a fürt elrendezését. A frissítési tartományok olyan csomópontkészleteket határoznak meg, amelyek egyszerre frissülnek. A frissítési tartományok segítenek a fürt Resource Managerének megérteni és vezényíteni a felügyeleti műveleteket, például a frissítéseket.
A frissítési tartományok sokban hasonlítanak a tartalék tartományokra, de néhány fő különbséggel. Először is az összehangolt hardverhibák területei határozzák meg a tartalék tartományokat. A frissítési tartományokat viszont szabályzat határozza meg. Eldöntheti, hogy hányat szeretne, ahelyett, hogy a környezet diktálja a számot. Annyi frissítési tartománnyal rendelkezhet, mint a csomópontok. A tartalék tartományok és a frissítési tartományok közötti másik különbség, hogy a frissítési tartományok nem hierarchikusak. Ehelyett inkább egy egyszerű címke.
Az alábbi ábra három frissítési tartományt mutat be, három tartalék tartományra lebontva. Egy állapotalapú szolgáltatás három különböző replikájához is egy lehetséges elhelyezést jelenít meg, ahol mindegyik különböző hiba- és frissítési tartományokba kerül. Ez az elhelyezés lehetővé teszi egy tartalék tartomány elvesztését egy szolgáltatásfrissítés közben, és továbbra is rendelkezik egy másolattal a kódról és az adatokról.
A nagy számú frissítési tartománynak vannak előnyei és hátrányai. A további frissítési tartományok azt jelentik, hogy a frissítés minden lépése részletesebb, és kisebb számú csomópontot vagy szolgáltatást érint. Kevesebb szolgáltatásnak kell egyszerre mozognia, ami kevesebb változáshoz vezet a rendszerbe. Ez általában növeli a megbízhatóságot, mivel a frissítés során felmerülő problémák kevesebb szolgáltatást érintenek. A további frissítési tartományok azt is jelentik, hogy a frissítés hatásának kezeléséhez kevesebb rendelkezésre álló pufferre van szükség más csomópontokon.
Ha például öt frissítési tartománnyal rendelkezik, az egyes csomópontok a forgalom körülbelül 20 százalékát kezelik. Ha le kell vennie a frissítési tartományt a frissítéshez, a terhelésnek általában valahová kell mennie. Mivel négy további frissítési tartománnyal rendelkezik, mindegyiknek a teljes forgalom körülbelül 25%-ának elegendő helynek kell lennie. A további frissítési tartományok azt jelentik, hogy kevesebb pufferre van szükség a fürt csomópontjainál.
Fontolja meg, hogy ehelyett 10 frissítési tartományt használ-e. Ebben az esetben minden frissítési tartomány csak a teljes forgalom 10 százalékát kezeli. Amikor egy frissítés végiglép a fürtön, minden tartománynak a teljes forgalomnak csak körülbelül 11%-ának kell helyet adnia. A további frissítési tartományok általában lehetővé teszik a csomópontok magasabb kihasználtságú futtatását, mivel kevesebb fenntartott kapacitásra van szüksége. Ugyanez igaz a tartalék tartományokra is.
A számos frissítési tartomány hátránya, hogy a frissítések általában hosszabb időt vesznek igénybe. A Service Fabric rövid ideig várakozik a frissítési tartomány befejezése után, és ellenőrzéseket végez a következő frissítés megkezdése előtt. Ezek a késések lehetővé teszik a frissítés által a frissítés folytatása előtt felmerülő problémák észlelését. A kompromisszum elfogadható, mert megakadályozza, hogy a rossz változások egyszerre túl sok szolgáltatást érintenek.
A túl kevés frissítési tartomány jelenléte számos negatív mellékhatást okoz. Bár minden frissítési tartomány le van állítva és frissítve van, a teljes kapacitás nagy része nem érhető el. Ha például csak három frissítési tartománnyal rendelkezik, a teljes szolgáltatás vagy fürtkapacitás körülbelül egyharmadát veszi le egyszerre. A szolgáltatás ilyen mértékű leállása nem kívánatos, mert elegendő kapacitásra van szüksége a fürt többi részén a számítási feladat kezeléséhez. A puffer fenntartása azt jelenti, hogy a normál működés során ezek a csomópontok kevésbé töltődnek be, mint egyébként. Ez növeli a szolgáltatás futtatásának költségeit.
Nincs valós korlátja a környezetben található hibák vagy frissítési tartományok teljes számának, illetve az átfedésük korlátozásának. De vannak gyakori minták:
- Az 1:1-re leképezett tartalék tartományok és frissítési tartományok
- Csomópontonként egy frissítési tartomány (fizikai vagy virtuális operációsrendszer-példány)
- "csíkos" vagy "mátrixos" modell, ahol a tartalék tartományok és a frissítési tartományok mátrixot alkotnak, és a gépek általában az átlókon futnak
Nincs a legjobb válasz arra, hogy melyik elrendezést válassza. Mindegyiknek vannak előnyei és hátrányai. Az 1FD:1UD modell például egyszerűen beállítható. Csomópontmodellenként egy frissítési tartomány modellje a leginkább hasonlít a felhasználók által használthoz. A frissítések során az egyes csomópontok egymástól függetlenül frissülnek. Ez hasonló ahhoz, ahogyan a kis gépcsoportokat manuálisan frissítették a múltban.
A leggyakoribb modell az FD/UD mátrix, ahol a tartalék tartományok és a frissítési tartományok táblázatot alkotnak, és a csomópontok az átlós mentén kezdődnek. Ez az azure-beli Service Fabric-fürtökben alapértelmezés szerint használt modell. A sok csomóponttal rendelkező fürtök esetében minden sűrű mátrixmintának tűnik.
Megjegyzés:
Az Azure-ban üzemeltetett Service Fabric-fürtök nem támogatják az alapértelmezett stratégia módosítását. Ezt a testreszabást csak önálló fürtök biztosítják.
Hiba- és frissítési tartománykorlátozások és az ebből eredő viselkedés
Alapértelmezett megközelítés
A Fürterőforrás-kezelő alapértelmezés szerint egyensúlyban tartja a szolgáltatásokat a tartalék és a frissítési tartományok között. Ez kényszerként van modellve. A hiba- és frissítési tartományokra vonatkozó korlátozás a következő: "Egy adott szolgáltatáspartíció esetében soha nem lehet egynél nagyobb különbség a szolgáltatásobjektumok (állapot nélküli szolgáltatáspéldányok vagy állapotalapú szolgáltatásreplikák) számában az azonos hierarchiaszinten lévő két tartomány között."
Tegyük fel, hogy ez a korlátozás "maximális különbséget" biztosít. A hiba- és frissítési tartományokra vonatkozó korlátozás megakadályozza a szabályt sértő bizonyos áthelyezéseket vagy elrendezéseket.
Tegyük fel például, hogy egy hat csomóponttal rendelkező fürtünk öt tartalék tartománnyal és öt frissítési tartománnyal van konfigurálva.
| FD0 | FD1 | FD2 | FD3 | FD4 | |
|---|---|---|---|---|---|
| UD0 | N1 | ||||
| UD1 | N6 | N2 | |||
| UD2 | N3 | ||||
| UD3 | N4 | ||||
| UD4 | N5 |
Most tegyük fel, hogy létrehozunk egy ötös TargetReplicaSetSize (vagy állapot nélküli szolgáltatás esetén InstanceCount) értékkel rendelkező szolgáltatást. A replikák az N1-N5-en szállnak le. Valójában az N6 soha nem lesz használatban, függetlenül attól, hogy hány ilyen szolgáltatást hoz létre. De miért? Nézzük meg a különbséget az aktuális elrendezés és az N6 kiválasztása esetén.
Itt találja a kapott elrendezést, valamint a replikák hiba- és frissítési tartományonkénti teljes számát:
| FD0 | FD1 | FD2 | FD3 | FD4 | UDTotal | |
|---|---|---|---|---|---|---|
| UD0 | R1 | 1 | ||||
| UD1 | R2 | 1 | ||||
| UD2 | R3 | 1 | ||||
| UD3 | R4 | 1 | ||||
| UD4 | R5 | 1 | ||||
| FDTotal | 0 | 1 | 1 | 1 | 1 | - |
Ez az elrendezés a hibatartományonkénti csomópontok és a frissítési tartomány szerint kiegyensúlyozott. A hiba- és frissítési tartományonkénti replikák száma is kiegyensúlyozott. Minden tartomány ugyanannyi csomópontot és replikaszámot rendelkezik.
Most nézzük meg, mi történne, ha N2 helyett N6-ot használnánk. Hogyan oszlanak el a replikák?
| FD0 | FD1 | FD2 | FD3 | FD4 | UDTotal | |
|---|---|---|---|---|---|---|
| UD0 | R1 | 1 | ||||
| UD1 | R5 | 1 | ||||
| UD2 | R2 | 1 | ||||
| UD3 | R3 | 1 | ||||
| UD4 | R4 | 1 | ||||
| FDTotal | 2 | 0 | 0 | 1 | 1 | - |
Ez az elrendezés sérti a tartalék tartomány korlátozására vonatkozó "maximális különbség" garanciát. Az FD0 két replikával rendelkezik, míg az FD1 értéke nulla. Az FD0 és az FD1 közötti különbség összesen kettő, ami nagyobb, mint az egy maximális különbség. A korlátozás megsértése miatt a Fürterőforrás-kezelő nem engedélyezi ezt az elrendezést.
Hasonlóképpen, ha az N2-t és az N6-ot választjuk (az N1 és az N2 helyett), a következőt kapnánk:
| FD0 | FD1 | FD2 | FD3 | FD4 | UDTotal | |
|---|---|---|---|---|---|---|
| UD0 | 0 | |||||
| UD1 | R5 | R1 | 2 | |||
| UD2 | R2 | 1 | ||||
| UD3 | R3 | 1 | ||||
| UD4 | R4 | 1 | ||||
| FDTotal | 0 | 1 | 1 | 1 | 1 | - |
Ez az elrendezés a tartalék tartományok szempontjából kiegyensúlyozott. Most azonban megsérti a frissítési tartományra vonatkozó korlátozást, mivel az UD0 nem rendelkezik replikákkal, az UD1 pedig kettővel. Ez az elrendezés szintén érvénytelen, és a Fürterőforrás-kezelő nem választja ki.
Az állapotalapú replikák vagy állapot nélküli példányok elosztásának ez a megközelítése a lehető legjobb hibatűrést biztosítja. Ha egy tartomány leáll, a replikák/példányok minimális száma elveszik.
Ezzel szemben ez a megközelítés túl szigorú lehet, és nem teszi lehetővé a fürt számára az összes erőforrás használatát. Bizonyos fürtkonfigurációkhoz bizonyos csomópontok nem használhatók. Ez azt eredményezheti, hogy a Service Fabric nem helyezi el a szolgáltatásokat, ami figyelmeztető üzeneteket eredményez. Az előző példában néhány fürtcsomópont nem használható (a példában N6). Még akkor is, ha csomópontokat adott hozzá az adott fürthöz (N7-N10), a replikák/példányok csak az N1–N5 rendszeren lesznek elhelyezve a hiba- és frissítési tartományok korlátozásai miatt.
| FD0 | FD1 | FD2 | FD3 | FD4 | |
|---|---|---|---|---|---|
| UD0 | N1 | N10 | |||
| UD1 | N6 | N2 | |||
| UD2 | N7 | N3 | |||
| UD3 | N8 | N4 | |||
| UD4 | N9 | N5 |
Alternatív megközelítés
A Fürterőforrás-kezelő támogatja a hiba- és frissítési tartományokra vonatkozó korlátozás egy másik verzióját. Lehetővé teszi az elhelyezést, miközben továbbra is minimális biztonsági szintet garantál. Az alternatív korlátozás a következő módon adható meg: "Egy adott szolgáltatáspartíció esetében a replika tartományok közötti elosztásának biztosítania kell, hogy a partíció ne szenvedjen kvórumveszteséget." Tegyük fel, hogy ez a korlátozás "kvórumbiztos" garanciát biztosít.
Megjegyzés:
Állapotalapú szolgáltatás esetén kvórumveszteséget határozunk meg olyan helyzetben, amikor a partícióreplikák többsége egyszerre nem működik. Ha például a TargetReplicaSetSize értéke öt, akkor a három replika bármelyike kvórumot jelöl. Hasonlóképpen, ha a TargetReplicaSetSize hat, négy replika szükséges a kvórumhoz. Mindkét esetben legfeljebb két replika lehet egyszerre leállva, ha a partíció a normál működést szeretné folytatni.
Állapot nélküli szolgáltatás esetén nincs olyan, hogy kvórumvesztés lenne. Az állapot nélküli szolgáltatások továbbra is normálisan működnek, még akkor is, ha a példányok többsége egyszerre csökken. Ezért a cikk további részében az állapotalapú szolgáltatásokra összpontosítunk.
Térjünk vissza az előző példához. A kényszer "kvórumbiztos" verziójával mindhárom elrendezés érvényes lenne. Még ha az FD0 a második elrendezésben, vagy az UD1 nem sikerült a harmadik elrendezésben, a partíciónak továbbra is kvóruma lesz. (A replikák többsége továbbra is fel van állítva.) A korlátozás ezen verziójával az N6 szinte mindig használható.
A "kvórumbiztos" megközelítés nagyobb rugalmasságot biztosít, mint a "maximális különbség" megközelítés. Ennek az az oka, hogy egyszerűbb olyan replika-disztribúciókat találni, amelyek szinte bármilyen fürttopológiában érvényesek. Ez a megközelítés azonban nem garantálja a legjobb hibatűrési jellemzőket, mert egyes hibák rosszabbak, mint mások.
A legrosszabb esetben a replikák többsége elveszhet egy tartomány és egy további replika meghibásodásával. A kvórum öt replikával vagy példánysal való elvesztéséhez szükséges három hiba helyett most már csak két hibával elveszítheti a többséget.
Adaptív megközelítés
Mivel mindkét megközelítésnek vannak erősségei és gyengeségei, bevezettünk egy adaptív megközelítést, amely egyesíti ezt a két stratégiát.
Megjegyzés:
Ez az alapértelmezett viselkedés a Service Fabric 6.2-es verziójától kezdve.
Az adaptív megközelítés alapértelmezés szerint a "maximális különbség" logikát használja, és csak szükség esetén vált a "kvórumbiztos" logikára. A Fürterőforrás-kezelő automatikusan kitalálja, hogy melyik stratégiára van szükség a fürt és a szolgáltatások konfigurálásával.
A fürterőforrás-kezelőnek a "kvórumalapú" logikát kell használnia egy szolgáltatáshoz mindkét feltétel teljesül:
- A szolgáltatás TargetReplicaSetSize tulajdonsága egyenlően osztható a tartalék tartományok számával és a frissítési tartományok számával.
- A csomópontok száma kisebb vagy egyenlő a tartalék tartományok számával és a frissítési tartományok számával.
Ne feledje, hogy a Fürterőforrás-kezelő ezt a megközelítést használja az állapot nélküli és az állapotalapú szolgáltatásokhoz is, annak ellenére, hogy a kvórumveszteség nem releváns az állapot nélküli szolgáltatások esetében.
Térjünk vissza az előző példához, és tegyük fel, hogy egy fürtnek már nyolc csomópontja van. A fürt továbbra is öt tartalék tartománnyal és öt frissítési tartománnyal van konfigurálva, és a fürtön üzemeltetett szolgáltatás TargetReplicaSetSize értéke továbbra is öt marad.
| FD0 | FD1 | FD2 | FD3 | FD4 | |
|---|---|---|---|---|---|
| UD0 | N1 | ||||
| UD1 | N6 | N2 | |||
| UD2 | N7 | N3 | |||
| UD3 | N8 | N4 | |||
| UD4 | N5 |
Mivel minden szükséges feltétel teljesül, a Fürterőforrás-kezelő a "kvórumalapú" logikát fogja használni a szolgáltatás terjesztéséhez. Ez lehetővé teszi az N6-N8 használatát. Ebben az esetben az egyik lehetséges szolgáltatásterjesztés a következőképpen nézhet ki:
| FD0 | FD1 | FD2 | FD3 | FD4 | UDTotal | |
|---|---|---|---|---|---|---|
| UD0 | R1 | 1 | ||||
| UD1 | R2 | 1 | ||||
| UD2 | R3 | R4 | 2 | |||
| UD3 | 0 | |||||
| UD4 | R5 | 1 | ||||
| FDTotal | 2 | 0 | 1 | 0 | 1 | - |
Ha a szolgáltatás TargetReplicaSetSize értéke négyre csökken (például), a Fürterőforrás-kezelő észleli ezt a változást. A a "maximális különbség" logikával folytatódik, mert a TargetReplicaSetSize már nem osztható el a tartalék tartományok és a frissítési tartományok számával. Ennek eredményeképpen bizonyos replikamozgások történnek a fennmaradó négy replika N1-N5 csomóponton való elosztásához. Így a hibatartomány és a frissítési tartomány logikájának "maximális különbsége" nem sérül.
Az előző elrendezésben, ha a TargetReplicaSetSize érték öt, az N1 pedig el lesz távolítva a fürtből, a frissítési tartományok száma négynek lesz egyenlő. A Fürterőforrás-kezelő ismét a "maximális különbség" logikát kezdi használni, mert a frissítési tartományok száma már nem osztja el egyenletesen a szolgáltatás TargetReplicaSetSize értékét. Ennek eredményeképpen az R1 replika újraépítéskor az N4-re kell szállnia, hogy a hiba- és frissítési tartományra vonatkozó korlátozás ne sérüljön.
| FD0 | FD1 | FD2 | FD3 | FD4 | UDTotal | |
|---|---|---|---|---|---|---|
| UD0 | N.A. | N/A | N/A | N/A | N/A | N.A. |
| UD1 | R2 | 1 | ||||
| UD2 | R3 | R4 | 2 | |||
| UD3 | R1 | 1 | ||||
| UD4 | R5 | 1 | ||||
| FDTotal | 0 | 1 | 1 | 1 | 1 | - |
Hiba- és frissítési tartományok konfigurálása
Az Azure által üzemeltetett Service Fabric-környezetekben a tartalék tartományok és a frissítési tartományok automatikusan vannak definiálva. A Service Fabric felveszi és felhasználja a környezeti adatokat az Azure-ból.
Ha saját fürtöt hoz létre (vagy egy adott topológiát szeretne futtatni a fejlesztés során), saját maga is megadhatja a tartalék tartományt, és frissítheti a tartomány adatait. Ebben a példában egy kilenccsomópontos helyi fejlesztési fürtöt határozunk meg, amely három adatközpontot (egyenként három állványt) ölel fel. Ebben a fürtben három frissítési tartomány is található, amelyek ezen a három adatközponton keresztül vannak elosztva. Íme egy példa a ClusterManifest.xml konfigurációjára:
<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>
Ez a példa a ClusterConfig.json függvényt használja önálló üzemelő példányokhoz:
"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"
}
],
Megjegyzés:
Amikor fürtöket definiál az Azure Resource Manageren keresztül, az Azure tartalék tartományokat rendel hozzá és frissít tartományokat. Így az Azure Resource Manager-sablon csomóponttípusainak és virtuálisgép-méretezési csoportjainak definíciója nem tartalmaz információt a tartalék tartományról vagy a frissítési tartományról.
Csomóponttulajdonságok és elhelyezési korlátozások
Néha (valójában az esetek többségében) gondoskodnia kell arról, hogy bizonyos számítási feladatok csak a fürt bizonyos csomóponttípusaiban fussanak. Előfordulhat például, hogy egyes számítási feladatok gpu-kat vagy SSD-ket igényelnek, míg mások nem.
A hardverek adott számítási feladatokra való megcélzására kiváló példa szinte minden N szintű architektúra. Egyes gépek az alkalmazás előtér- vagy API-kiszolgálói oldalaként szolgálnak, és az ügyfelek vagy az internet számára is elérhetők. A számítási vagy tárolási rétegek munkáját különböző, gyakran különböző hardvererőforrásokkal rendelkező gépek kezelik. Ezek általában nincsenek közvetlenül kitéve az ügyfeleknek vagy az internetnek.
A Service Fabric arra számít, hogy bizonyos esetekben bizonyos számítási feladatoknak bizonyos hardverkonfigurációkon kell futniuk. Például:
- Egy meglévő n szintű alkalmazás "át lett emelve és áthelyezve" egy Service Fabric-környezetbe.
- A számítási feladatokat teljesítmény-, skálázási vagy biztonsági elkülönítési okokból meghatározott hardveren kell futtatni.
- A számítási feladatokat szabályzat- vagy erőforrás-felhasználási okokból el kell különíteni más számítási feladatoktól.
Az ilyen típusú konfigurációk támogatásához a Service Fabric olyan címkéket tartalmaz, amelyeket a csomópontokra alkalmazhat. Ezeket a címkéket csomóponttulajdonságoknak nevezzük. Az elhelyezési korlátozások az egyes szolgáltatásokhoz csatolt utasítások, amelyeket egy vagy több csomóponttulajdonsághoz választ ki. Az elhelyezési korlátozások határozzák meg a szolgáltatások futtatásának helyét. A kényszerek halmaza bővíthető. Bármely kulcs-érték pár működhet.
Beépített csomóponttulajdonságok
A Service Fabric meghatároz néhány alapértelmezett csomóponttulajdonságokat, amelyek automatikusan használhatók, így nem kell őket definiálnia. Az egyes csomópontok alapértelmezett tulajdonságai a NodeType és a NodeName.
Megírhat például egy elhelyezési kényszert a következőként "(NodeType == NodeType03)": . A NodeType egy gyakran használt tulajdonság. Ez azért hasznos, mert megfelel az 1:1-nek egy géptípusnak. Minden géptípus egy hagyományos N szintű alkalmazás számítási feladattípusának felel meg.
Elhelyezési korlátozások és csomóponttulajdonságok szintaxisa
A csomóponttulajdonságban megadott érték lehet sztring, logikai vagy aláírt hosszú. A szolgáltatásban lévő utasítást elhelyezési kényszernek nevezzük, mert korlátozza, hogy a szolgáltatás hol futhat a fürtben. A korlátozás lehet bármely logikai utasítás, amely a fürt csomóponttulajdonságaiban működik. A logikai utasítások érvényes választói a következők:
Adott utasítások létrehozásának feltételes ellenőrzése:
Utasítás Syntax "egyenlő" "==" "nem egyenlő" "!=" "nagyobb, mint" ">" "nagyobb vagy egyenlő" ">=" "kisebb, mint" "<" "kisebb vagy egyenlő" "<=" Logikai utasítások csoportosításhoz és logikai műveletekhez:
Utasítás Syntax "és" "&&" "vagy" "||" "nem" "!" "csoportosítás egyetlen utasításként" "()"
Íme néhány példa az alapvető kényszermegkötési utasításokra:
"Value >= 5""NodeColor != green""((OneProperty < 100) || ((AnotherProperty == false) && (OneProperty >= 100)))"
Csak azok a csomópontok helyezhetők el rajta, amelyeken az általános elhelyezési korlátozási utasítás "True" értéket ad vissza. A tulajdonságot nem tartalmazó csomópontok nem egyeznek meg a tulajdonságot tartalmazó elhelyezési korlátozásokkal.
Tegyük fel, hogy a clusterManifest.xml csomóponttípusához a következő csomóponttulajdonságok lettek definiálva:
<NodeType Name="NodeType01">
<PlacementProperties>
<Property Name="HasSSD" Value="true"/>
<Property Name="NodeColor" Value="green"/>
<Property Name="SomeProperty" Value="5"/>
</PlacementProperties>
</NodeType>
Az alábbi példa a ClusterConfig.jsonon keresztül definiált csomóponttulajdonságokat mutatja be önálló üzemelő példányokhoz vagy Azure-beli fürtökhöz készült Template.json használatával.
Megjegyzés:
Az Azure Resource Manager-sablonban a csomópont típusa általában paraméteres. A NodeType01 helyett a következőképpen "[parameters('vmNodeType1Name')]" nézne ki.
"nodeTypes": [
{
"name": "NodeType01",
"placementProperties": {
"HasSSD": "true",
"NodeColor": "green",
"SomeProperty": "5"
},
}
],
Szolgáltatáselhelyezési korlátozásokat az alábbiak szerint hozhat létre egy szolgáltatáshoz:
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"
Ha a NodeType01 összes csomópontja érvényes, azt a csomóponttípust is kiválaszthatja a korlátozással "(NodeType == NodeType01)".
A szolgáltatás elhelyezési korlátozásai futásidőben dinamikusan frissíthetők. Ha szükséges, áthelyezhet egy szolgáltatást a fürtben, követelményeket adhat hozzá és távolíthat el, és így tovább. A Service Fabric biztosítja, hogy a szolgáltatás akkor is elérhető maradjon, ha ilyen típusú módosításokat végez.
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"
Az elhelyezési korlátozások minden elnevezett szolgáltatáspéldányhoz meg vannak adva. Frissítések mindig a korábban megadott (felülírt) helyére kerül.
A fürtdefiníció határozza meg a csomópont tulajdonságait. A csomópont tulajdonságainak módosításához frissíteni kell a fürtkonfigurációt. A csomópont tulajdonságainak frissítéséhez minden érintett csomópontnak újra kell indulnia az új tulajdonságok jelentéséhez. A Service Fabric kezeli ezeket a működés közbeni frissítéseket.
Fürterőforrások leírása és kezelése
A vezénylők egyik legfontosabb feladata az erőforrás-felhasználás kezelése a fürtben. A fürterőforrások kezelése több különböző dolgot is jelenthet.
Először is biztosítani kell, hogy a gépek ne legyenek túlterhelve. Ez azt jelenti, hogy a gépek nem futnak több szolgáltatást, mint amennyit kezelni tudnak.
Másodszor, van kiegyensúlyozás és optimalizálás, amelyek elengedhetetlenek a szolgáltatások hatékony futtatásához. A költséghatékony vagy teljesítményfüggő szolgáltatásajánlatok nem teszik lehetővé, hogy egyes csomópontok melegek legyenek, míg mások hidegek. A gyakori csomópontok erőforrás-versengést és gyenge teljesítményt eredményeznek. A hideg csomópontok az elpazarolt erőforrásokat és a megnövekedett költségeket jelölik.
A Service Fabric az erőforrásokat metrikákként jelöli. A metrikák olyan logikai vagy fizikai erőforrások, amelyeket le szeretne írni a Service Fabricnek. A metrikák például a "WorkQueueDepth" vagy a "MemoryInMb". A Service Fabric által a csomópontokon szabályozható fizikai erőforrásokról további információt az Erőforrás-szabályozás című témakörben talál. A fürterőforrás-kezelő által használt alapértelmezett metrikákkal és az egyéni metrikák konfigurálásával kapcsolatos információkért tekintse meg ezt a cikket.
A metrikák eltérnek az elhelyezési korlátozásoktól és a csomópont tulajdonságaitól. A csomóponttulajdonságok maguk a csomópontok statikus leírói. A metrikák azokat az erőforrásokat írják le, amelyekkel a csomópontok rendelkeznek, és amelyeket a szolgáltatások használnak, amikor egy csomóponton futnak. A csomóponttulajdonság lehet HasSSD , és lehet, hogy igaz vagy hamis értékre van állítva. Az adott SSD-n rendelkezésre álló hely és a szolgáltatások által felhasznált mennyiség egy olyan metrika, mint a "DriveSpaceInMb".
Az elhelyezési korlátozásokhoz és a csomóponttulajdonságokhoz hasonlóan a Service Fabric-fürt Resource Managere sem érti a metrikák nevét. A metrikanevek csak sztringek. Célszerű az egységeket a létrehozott metrikanevek részeként deklarálni, ha nem egyértelműek.
Kapacitás
Ha kikapcsolta az összes erőforrás-kiegyensúlyozást, a Service Fabric-fürt Resource Managere továbbra is biztosítaná, hogy egyetlen csomópont sem lépi túl a kapacitását. A kapacitástúllépések kezelése csak akkor lehetséges, ha a fürt túl megtelt, vagy a számítási feladat nagyobb, mint bármely csomópont. A kapacitás egy másik korlátozás , amelyet a Fürterőforrás-kezelő használ annak megértésére, hogy egy csomópont mekkora erőforrással rendelkezik. A fennmaradó kapacitást a fürt egésze is nyomon követi.
Mind a kapacitás, mind a szolgáltatás szintjén a felhasználás metrikákban van kifejezve. Előfordulhat például, hogy a metrika "Ügyfél Csatlakozás ions", a csomópontok pedig 32 768-ból álló "Ügyfél Csatlakozás ions" kapacitással rendelkeznek. Más csomópontok más korlátozásokkal is rendelkezhetnek. Az adott csomóponton futó szolgáltatás azt mondhatja, hogy jelenleg az "Ügyfél Csatlakozás ions" metrika 32 256-át fogyasztja.
Futásidőben a Fürterőforrás-kezelő nyomon követi a fürtben és a csomópontokon fennmaradó kapacitást. A kapacitás nyomon követéséhez a Fürterőforrás-kezelő kivonja az egyes szolgáltatások használatát egy csomópont kapacitásából, ahol a szolgáltatás fut. Ezekkel az információkkal a fürterőforrás-kezelő meg tudja állapítani, hogy hol helyezze el vagy helyezze át a replikákat, hogy a csomópontok ne menjenek át a kapacitáson.
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)
A fürtjegyzékben definiált kapacitások láthatók. Íme egy példa a ClusterManifest.xml fájlra:
<NodeType Name="NodeType03">
<Capacities>
<Capacity Name="ClientConnections" Value="65536"/>
</Capacities>
</NodeType>
Íme egy példa a ClusterConfig.jsonon keresztül definiált kapacitásokra önálló üzemelő példányokhoz, vagy Az Azure által üzemeltetett fürtökhöz készült Template.json:
"nodeTypes": [
{
"name": "NodeType03",
"capacities": {
"ClientConnections": "65536",
}
}
],
A szolgáltatás terhelése gyakran dinamikusan változik. Tegyük fel, hogy a replika "Ügyfél Csatlakozás ions" terhelése 1 024-ről 2048-ra módosult. A csomópont, amelyen futott, csak 512 kapacitással rendelkezik a metrika számára. Most, hogy a replika vagy példány elhelyezése érvénytelen, mert nincs elég hely a csomóponton. A fürterőforrás-kezelőnek vissza kell szereznie a csomópontot a kapacitás alá. Csökkenti a kapacitáson túli csomópont terhelését azáltal, hogy áthelyez egy vagy több replikát vagy példányt az adott csomópontról más csomópontokra.
A Fürterőforrás-kezelő megpróbálja minimalizálni a replikák áthelyezésének költségeit. A mozgási költségekről, valamint a stratégiák és szabályok újraegyensúlyozásáról további információt is megtudhat.
Fürtkapacitás
Hogyan tartja a Service Fabric-fürt Resource Managere a teljes fürt túl megteltségétől? Dinamikus terhelés esetén nem sok mindenre képes. A szolgáltatások terhelése a Fürterőforrás-kezelő által végrehajtott műveletektől függetlenül is megnőhet. Ennek eredményeképpen előfordulhat, hogy a ma sok fejtérrel rendelkező fürtje kihasználatlan lesz, ha holnap kiugróan magas lesz.
A Fürterőforrás-kezelő vezérlői segítenek megelőzni a problémákat. Az első lépés az új számítási feladatok létrehozásának megakadályozása, amely miatt a fürt megtelik.
Tegyük fel, hogy állapot nélküli szolgáltatást hoz létre, és a szolgáltatás terhelése is hozzá van rendelve. A szolgáltatás a "DiskSpaceInMb" metrikával foglalkozik. A szolgáltatás a szolgáltatás minden példányához öt "DiskSpaceInMb" egységet használ fel. A szolgáltatás három példányát szeretné létrehozni. Ez azt jelenti, hogy a fürtben 15 egységnyi "DiskSpaceInMb" szükséges ahhoz, hogy ezeket a szolgáltatáspéldányokat is létre tudja hozni.
A Fürterőforrás-kezelő folyamatosan kiszámítja az egyes metrikák kapacitását és felhasználását, hogy megállapíthassa a fürt fennmaradó kapacitását. Ha nincs elég hely, a Fürterőforrás-kezelő elutasítja a szolgáltatás létrehozásához szükséges hívást.
Mivel a követelmény csak az, hogy 15 egység legyen elérhető, ezt a területet sokféleképpen lefoglalhatja. Előfordulhat például, hogy 15 különböző csomóponton egy kapacitásegység, öt különböző csomóponton pedig három fennmaradó kapacitásegység található. Ha a Fürterőforrás-kezelő átrendezi a dolgokat, így három csomóponton öt egység érhető el, akkor a szolgáltatás üzembe helyezhető. A fürt átrendezése általában csak akkor lehetséges, ha a fürt majdnem megtelt, vagy a meglévő szolgáltatások valamilyen okból nem konszolidálhatók.
Csomópontpuffer és túlfoglalási kapacitás
Ha egy metrika csomópontkapacitása meg van adva, a Fürterőforrás-kezelő soha nem helyezi el vagy helyezi át a replikákat egy csomópontra, ha a teljes terhelés a megadott csomópontkapacitás felett lenne. Ez néha megakadályozhatja az új replikák elhelyezését vagy a sikertelen replikák cseréjét, ha a fürt majdnem teljes kapacitású, és egy nagy terhelésű replikát kell elhelyezni, cserélni vagy áthelyezni.
A nagyobb rugalmasság érdekében megadhatja a csomópontpuffert vagy a túlfoglalási kapacitást. Ha csomópontpuffer vagy túlfoglalási kapacitás van megadva egy metrika esetében, a fürterőforrás-kezelő megkísérli a replikákat úgy elhelyezni vagy áthelyezni, hogy a puffer vagy a túlfoglalási kapacitás kihasználatlan maradjon, de lehetővé teszi a puffer vagy a túlfoglalási kapacitás használatát, ha szükséges, a szolgáltatás rendelkezésre állását növelő műveletekhez, például:
- Új replika elhelyezése vagy lecserélése meghiúsult replikákra
- Elhelyezés a frissítések során
- A helyreállítható és a szigorú korlátozások megsértéseinek kijavítása
- Töredezettségmentesítés
A csomópontpufferkapacitás a kapacitás egy fenntartott részét jelöli a megadott csomópontkapacitás alatt, a túlfoglalási kapacitás pedig a többletkapacitás egy részét jelenti a megadott csomópontkapacitás felett. A fürterőforrás-kezelő mindkét esetben megkísérli a kapacitás ingyenesen tartását.
Ha például egy csomópont 100 metrika cpu-kihasználtságához megadott kapacitással rendelkezik, és a metrika csomópontpuffer-százalékos értéke 20%, akkor a teljes és a nem felügyelt kapacitás 100, illetve 80 lesz, és a Fürterőforrás-kezelő normál körülmények között nem helyez el több mint 80 egységnyi terhelést a csomópontra.
A csomópontpuffert akkor kell használni, ha a csomópontkapacitás egy részét szeretné lefoglalni, amelyet csak a fent említett szolgáltatások rendelkezésre állását növelő műveletekhez használunk.
Ha viszont a csomópontok túlfoglalásának százalékos aránya 20%-ra van állítva, akkor a teljes és a nem felügyelt kapacitások értéke 120, illetve 100 lesz.
A túlfoglalási kapacitást akkor kell használni, ha engedélyezni szeretné, hogy a Fürterőforrás-kezelő replikákat helyezzen el egy csomóponton, még akkor is, ha a teljes erőforrás-használat meghaladja a kapacitást. Ezzel további rendelkezésre állást biztosíthat a szolgáltatások számára a teljesítmény rovására. Ha túlfoglalást használ, a felhasználói alkalmazás logikájának kevesebb fizikai erőforrással kell működnie, mint amennyi szükséges lehet.
Csomópontpuffer vagy túlfoglalási kapacitás megadása esetén a fürterőforrás-kezelő nem helyezi át vagy helyezi el a replikákat, ha a célcsomópont teljes terhelése meghaladja a teljes kapacitást (csomópontpuffer és csomópontkapacitás esetén a csomópont kapacitása + túlfoglalás esetén a kapacitás túlfoglalása).
A túlfoglalási kapacitás is megadható végtelenként. Ebben az esetben a Fürterőforrás-kezelő megkísérli a csomópont teljes terhelését a megadott csomópontkapacitás alatt tartani, de lehetséges, hogy sokkal nagyobb terhelést helyez el a csomóponton, ami súlyos teljesítménycsökkenéshez vezethet.
Egy metrika nem rendelkezhet egyszerre csomópontpufferrel és túlfoglalási kapacitással.
Íme egy példa a csomópontpufferek vagy túlfoglalási kapacitások megadására a ClusterManifest.xml fájlban:
<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>
Íme egy példa a csomópontpufferek vagy a kapacitások túlfoglalására a ClusterConfig.jsonon keresztül önálló üzembe helyezésekhez vagy Az Azure-ban üzemeltetett fürtökHöz készült Template.json használatával:
"fabricSettings": [
{
"name": "NodeBufferPercentage",
"parameters": [
{
"name": "SomeMetric",
"value": "0.15"
}
]
},
{
"name": "NodeOverbookingPercentage",
"parameters": [
{
"name": "SomeOtherMetric",
"value": "0.20"
},
{
"name": "MetricWithInfiniteOverbooking",
"value": "-1.0"
}
]
}
]
További lépések
- A Fürterőforrás-kezelő architektúrájáról és az információáramlásról további információt a Fürterőforrás-kezelő architektúrájának áttekintésében talál.
- A töredezettségmentesítési metrikák definiálása az egyik módszer a csomópontok terhelésének összevonására ahelyett, hogy kiterjeszteni. A töredezettségmentesítés konfigurálásának megismeréséhez tekintse meg a metrikák és a terhelés töredezettségmentesítését a Service Fabricben.
- Kezdje az elejétől, és ismerkedjen meg a Service Fabric-fürt Resource Managerével.
- A Fürterőforrás-kezelő a fürt terhelésének kezelésével és kiegyensúlyozásával kapcsolatos tudnivalókért tekintse meg a Service Fabric-fürt kiegyensúlyozását ismertető témakört.
Visszajelzés
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ: https://aka.ms/ContentUserFeedback.
Visszajelzés küldése és megtekintése a következőhöz: