Service Fabric – GYIK

  • Cikk

Számos gyakori kérdés merül fel azzal kapcsolatban, hogy a Service Fabric mire képes, és hogyan kell használni. Ez a dokumentum számos gyakori kérdést és azok válaszait ismerteti.

Feljegyzés

Javasoljuk, hogy az Azure Az PowerShell modult használja az Azure-ral való interakcióhoz. Az első lépésekhez tekintse meg az Azure PowerShell telepítését ismertető szakaszt. Az Az PowerShell-modulra történő migrálás részleteiről lásd: Az Azure PowerShell migrálása az AzureRM modulból az Az modulba.

Fürt beállítása és kezelése

Hogyan a Service Fabric-fürttanúsítvány visszaállítását?

Az alkalmazás frissítésének visszaállítása állapothibák észlelését igényli, mielőtt a Service Fabric-fürt kvóruma véglegesíti a módosítást; a véglegesített módosítások csak előretekerhetők. Előfordulhat, hogy az ügyfélszolgálaton keresztüli eszkalációs mérnöknek szüksége van a fürt helyreállítására, ha a tanúsítvány nem figyelt módosítása történt. A Service Fabric alkalmazásfrissítése alkalmazásfrissítési paramétereket alkalmaz, és nulla állásidő-frissítési ígéretet biztosít. Az ajánlott alkalmazásfrissítési figyelt módot követve a frissítési tartományok automatikus előrehaladása az állapot-ellenőrzéseken alapul, és automatikusan visszagördül, ha egy alapértelmezett szolgáltatás frissítése sikertelen.

Ha a fürt továbbra is a Resource Manager-sablon klasszikus Tanúsítvány ujjlenyomat tulajdonságát használja, javasoljuk, hogy módosítsa a fürtöt a tanúsítvány ujjlenyomatáról a köznapi névre, hogy kihasználhassa a modern titkos kódok kezelési funkcióit.

Létrehozhatok olyan fürtöt, amely több Azure-régióra vagy saját adatközpontra terjed ki?

Igen.

Az alapvető Service Fabric-fürtözési technológia a világ bármely pontján futó gépek kombinálására használható, mindaddig, amíg hálózati kapcsolattal rendelkeznek egymással. Egy ilyen fürt létrehozása és futtatása azonban bonyolult lehet.

Ha érdekli ez a forgatókönyv, javasoljuk, hogy lépjen kapcsolatba a Service Fabric GitHub problémáinak listájával vagy a támogatási képviselőjén keresztül, hogy további útmutatást kapjon. A Service Fabric csapata azon dolgozik, hogy további egyértelműséget, útmutatást és javaslatokat nyújtson ehhez a forgatókönyvhöz.

Néhány mérlegelendő szempont ezzel kapcsolatban:

  1. Az Azure Service Fabric-fürterőforrása ma regionális, ahogy a fürt által létrehozott virtuálisgép-méretezési csoportok is. Ez azt jelenti, hogy regionális hiba esetén elveszítheti a fürt Azure Resource Manageren vagy az Azure Portalon keresztüli kezelését. Ez akkor is előfordulhat, ha a fürt továbbra is fut, és ön közvetlenül is használhatja. Emellett az Azure ma nem kínál egyetlen, régiók közötti használható virtuális hálózatot. Ez azt jelenti, hogy egy Többrégiós fürt az Azure-ban nyilvános IP-címeket igényel a virtuálisgép-méretezési csoportokban lévő egyes virtuális gépekhez vagy az Azure VPN Gatewayekhez. Ezek a hálózatkezelési lehetőségek különböző hatással vannak a költségekre, a teljesítményre és bizonyos mértékben az alkalmazások tervezésére, ezért gondos elemzésre és tervezésre van szükség egy ilyen környezet felállása előtt.
  2. Ezeknek a gépeknek a karbantartása, felügyelete és monitorozása bonyolulttá válhat, különösen akkor, ha különböző környezettípusokra terjed ki, például különböző felhőszolgáltatók vagy helyszíni erőforrások és az Azure között. Ügyelni kell arra, hogy a frissítések, a monitorozás, a felügyelet és a diagnosztikák mind a fürt, mind az alkalmazások számára érthetők legyenek, mielőtt éles számítási feladatokat futtatnak egy ilyen környezetben. Ha már van tapasztalata a problémák megoldásában az Azure-ban vagy a saját adatközpontjaiban, akkor valószínű, hogy ugyanezek a megoldások alkalmazhatók a Service Fabric-fürt létrehozásakor vagy futtatásakor.

A Service Fabric-csomópontok automatikusan kapnak operációsrendszer-frissítéseket?

A virtuálisgép-méretezési csoport automatikus operációsrendszer-rendszerkép-frissítésének általánosan elérhető funkcióját ma használhatja.

Olyan fürtök esetében, amelyek NEM az Azure-ban futnak, a Service Fabric-csomópontok alatti operációs rendszerek javításához biztosítottunk egy alkalmazást .

Használhatok nagy méretű virtuálisgép-méretezési csoportokat az SF-fürtben?

Rövid válasz – Nem.

Hosszú válasz – Bár a nagy virtuálisgép-méretezési csoportok lehetővé teszik egy virtuálisgép-méretezési csoport 1000 virtuálisgép-példányra történő skálázását, ezt az elhelyezési csoportok (PG-k) használatával teszi meg. A tartalék tartományok (FD-k) és a frissítési tartományok (UD-k) csak egy elhelyezési csoporton belül konzisztensek, a Service Fabric FD-ket és UD-ket használ a szolgáltatásreplikák/szolgáltatáspéldányok elhelyezési döntéseinek meghozatalához. Mivel az FD-k és az UD-k csak egy elhelyezési csoportban összehasonlíthatók, az SF nem használhatja. Ha például a PG1 VM1 topológiája FD=0, a PG2 VM9 pedig FD=4 topológiával rendelkezik, az nem jelenti azt, hogy a VM1 és a VM2 két különböző hardverállványon található, ezért az SF ebben az esetben nem használhatja az FD-értékeket elhelyezési döntések meghozatalához.

A nagy méretű virtuálisgép-méretezési csoportok jelenleg más problémákat is tapasztalnak, például a 4. szintű terheléselosztási támogatás hiányát. Részletes információk a nagyméretű méretezési csoportokról

Mi a Service Fabric-fürt minimális mérete? Miért nem lehet kisebb?

Az éles számítási feladatokat futtató Service Fabric-fürt minimális támogatott mérete öt csomópont. Fejlesztői forgatókönyvek esetén egy csomópontot (a Visual Studio gyors fejlesztési élményére optimalizálva) és öt csomópontfürtöt támogatunk.

Az alábbi három ok miatt egy éles fürtnek legalább öt csomópontot kell tartalmaznia:

  1. Még akkor is, ha nincsenek felhasználói szolgáltatások, a Service Fabric-fürtök állapotalapú rendszerszolgáltatásokat futtatnak, beleértve az elnevezési szolgáltatást és a feladatátvétel-kezelő szolgáltatást. Ezek a rendszerszolgáltatások elengedhetetlenek ahhoz, hogy a fürt működőképes maradjon.
  2. Csomópontonként mindig egy szolgáltatás replikát helyezünk el, így a fürt mérete a szolgáltatás (valójában egy partíció) replikáinak maximális száma.
  3. Mivel egy fürtfrissítés legalább egy csomópontot le fog állítani, legalább egy csomópont pufferét szeretnénk használni, ezért azt szeretnénk, hogy az éles fürtök legalább két csomópontot rendelkezzenek a minimális kihasználatlanság mellett . A minimális érték a rendszerszolgáltatás kvórummérete az alábbiakban leírtak szerint.

Azt szeretnénk, hogy a fürt két csomópont egyidejű meghibásodása esetén legyen elérhető. Ahhoz, hogy egy Service Fabric-fürt elérhető legyen, a rendszerszolgáltatásoknak elérhetőnek kell lenniük. Az olyan állapotalapú rendszerszolgáltatások, mint az elnevezési szolgáltatás és a feladatátvétel-kezelő szolgáltatás, amelyek nyomon követik, hogy mely szolgáltatások lettek üzembe helyezve a fürtben, és hol vannak jelenleg üzemeltetve, az erős konzisztenciától függ. Ez az erős konzisztencia viszont attól függ, hogy képes-e kvórumot szerezni a szolgáltatások állapotának adott frissítéséhez, ahol a kvórum az adott szolgáltatás replikáinak szigorú többségét (N/2 +1) képviseli. Így ha két csomópont egyidejű elvesztésével szemben szeretnénk ellenállóvá tenni magunkat (tehát egy rendszerszolgáltatás két replikájának egyidejű elvesztésével), akkor a ClusterSize - QuorumSize >= 2 értéket kell használnunk, ami a minimális méretet ötre kényszeríti. Ennek megtekintéséhez vegye figyelembe, hogy a fürt N csomópontokkal rendelkezik, és egy rendszerszolgáltatás N replikái vannak – mindegyik csomóponton. A rendszerszolgáltatás kvórummérete (N/2 + 1). A fenti egyenlőtlenség úgy néz ki, mint N – (N/2 + 1) >= 2. Két esetet kell figyelembe venni: ha az N páros, és az N páratlan. Ha N egyenlő, mondjuk N = 2*m, ahol m >= 1, az egyenlőtlenség 2*m - (2*m/2 + 1) >= 2 vagy m >= 3. Az N minimális értéke 6, és ez akkor érhető el, ha m = 3. Ha viszont az N páratlan, mondjuk N = 2*m+1, ahol m >= 1, az egyenlőtlenség 2*m+1 - ( (2*m+1)/2 + 1 ) >= 2 vagy 2*m+1 - (m+1) >= 2 vagy m >= 2. Az N minimális értéke 5, és ez akkor érhető el, ha m = 2. Ezért a ClusterSize - QuorumSize >= 2 egyenlőtlenségnek megfelelő N összes értéke között a minimum 5.

Vegye figyelembe, hogy a fenti argumentumban feltételeztük, hogy minden csomópont rendelkezik egy rendszerszolgáltatás replikával, így a kvórum mérete a fürt csomópontjainak száma alapján lesz kiszámítva. A TargetReplicaSetSize módosításával azonban a kvórumméret kisebb lehet, mint (N/2+1), ami azt a benyomást keltheti, hogy 5 csomópontnál kisebb fürtünk lehet, és még mindig 2 további csomóponttal rendelkezünk a kvórumméret felett. Ha például egy 4 csomópontos fürtben a TargetReplicaSetSize értéket 3-ra állítjuk, akkor a TargetReplicaSetSize alapján a kvórumméret (3/2 + 1) vagy 2, tehát a ClusterSize - QuorumSize = 4-2 >= 2. Azonban nem garantálhatjuk, hogy a rendszerszolgáltatás kvórumon vagy fölött lesz, ha egyszerre elveszítünk egy csomópontpárt, akkor előfordulhat, hogy az elveszett két csomópont két replikát üzemeltet, így a rendszerszolgáltatás kvórumvesztésbe kerül (csak egyetlen replika maradt), és elérhetetlenné válik.

Ezzel a háttérrel vizsgáljunk meg néhány lehetséges fürtkonfigurációt:

Egy csomópont: ez a beállítás nem biztosít magas rendelkezésre állást, mivel az egyetlen csomópont bármilyen okból történő elvesztése a teljes fürt elvesztését jelenti.

Két csomópont: két csomóponton üzembe helyezett szolgáltatás kvóruma (N = 2) 2 (2/2 + 1 = 2). Ha egyetlen replika elveszik, nem lehet kvórumot létrehozni. Mivel a szolgáltatásfrissítés végrehajtásához ideiglenesen le kell vennie egy replikát, ez nem hasznos konfiguráció.

Három csomópont: három csomóponttal (N=3) a kvórum létrehozásának követelménye továbbra is két csomópont (3/2 + 1 = 2). Ez azt jelenti, hogy elveszíthet egy adott csomópontot, és továbbra is fenntarthatja a kvórumot, de két csomópont egyidejű meghibásodása a rendszerszolgáltatás kvórumvesztését eredményezi, és a fürt elérhetetlenné válik.

Négy csomópont: négy csomóponttal (N=4) a kvórum létrehozásának követelménye három csomópont (4/2 + 1 = 3). Ez azt jelenti, hogy elveszíthet egy adott csomópontot, és továbbra is fenntarthatja a kvórumot, de két csomópont egyidejű meghibásodása a rendszerszolgáltatás kvórumvesztését eredményezi, és a fürt elérhetetlenné válik.

Öt csomópont: öt csomóponttal (N=5) a kvórum létrehozásának követelménye továbbra is három csomópont (5/2 + 1 = 3). Ez azt jelenti, hogy egyszerre két csomópontot is elveszíthet, és továbbra is fenntarthatja a rendszerszolgáltatások kvórumát.

Éles számítási feladatok esetén ellenállónak kell lennie legalább két csomópont egyidejű meghibásodásával szemben (például egy fürtfrissítés miatt, egy más ok miatt), ezért öt csomópontra van szükség.

Kikapcsolhatom a fürtöt éjszaka/hétvégén a költségek csökkentése érdekében?

Általában nem. A Service Fabric helyi, rövid élettartamú lemezeken tárolja az állapotot, ami azt jelenti, hogy ha a virtuális gépet egy másik gazdagépre helyezi át, az adatok nem lesznek vele együtt áthelyezve. Normál működés esetén ez nem jelent problémát, mivel az új csomópontot más csomópontok is naprakészen hozzák. Ha azonban leállítja az összes csomópontot, és később újraindítja őket, jelentős eséllyel a csomópontok többsége új gazdagépeken indul el, és a rendszer nem tud helyreállni.

Ha az üzembe helyezés előtt szeretne fürtöket létrehozni az alkalmazás teszteléséhez, javasoljuk, hogy dinamikusan hozza létre ezeket a fürtöket a folyamatos integrációs/folyamatos üzembehelyezési folyamat részeként.

Hogyan frissítse az operációs rendszeremet (például Windows Server 2012-ről Windows Server 2016-ra)?

A továbbfejlesztett felhasználói élményen dolgozunk, de jelenleg Ön a felelős a frissítésért. Az operációsrendszer-rendszerképet egyszerre csak egy virtuális géppel frissítheti a fürt virtuális gépein.

Titkosíthatom a csatolt adatlemezeket fürtcsomópont-típusban (virtuálisgép-méretezési csoport)?

Igen. További információ: Fürt létrehozása csatolt adatlemezekkel és Azure Disk Encryption virtuálisgép-méretezési csoportokhoz.

Használhatok alacsony prioritású virtuális gépeket fürtcsomópont-típusban (virtuálisgép-méretezési csoport)?

Szám Az alacsony prioritású virtuális gépek nem támogatottak.

Melyek azok a könyvtárak és folyamatok, amelyeket ki kell zárnom, amikor vírusirtó programot futtatok a fürtön?

Víruskereső kizárt könyvtárai
Program Files\Microsoft Service Fabric
FabricDataRoot (fürtkonfigurációból)
FabricLogRoot (fürtkonfigurációból)
Víruskereső kizárt folyamatai
Fabric.exe
FabricHost.exe
FabricInstallerService.exe
FabricSetup.exe
FabricDeployer.exe
ImageBuilder.exe
FabricGateway.exe
FabricDCA.exe
FabricFAS.exe
FabricUOS.exe
FabricRM.exe
FileStoreService.exe

Hogyan hitelesíthető az alkalmazás a Key Vaultban a titkos kódok lekéréséhez?

Az alábbiak azt jelentik, hogy az alkalmazás hitelesítő adatokat szerez be a Key Vaultba való hitelesítéshez:

V. Az alkalmazások buildelési/csomagolási feladata során lekérhet egy tanúsítványt az SF-alkalmazás adatcsomagjába, és ezzel hitelesítheti magát a Key Vaultban. B. A virtuálisgép-méretezési csoport MSI-kompatibilis gazdagépeihez létrehozhat egy egyszerű PowerShell SetupEntryPointot az SF-alkalmazáshoz, amely lekéri a hozzáférési jogkivonatot az MSI-végpontról, majd lekérheti a titkos kulcsokat a Key Vaultból.

Átvihetem az előfizetésemet egy másik Microsoft Entra-bérlőre?

Szám Ekkor létre kell hoznia egy új Service Fabric-fürterőforrást, miután az előfizetést átvitték egy másik Microsoft Entra-bérlőre.

Áthelyezhetem/migrálhatom a fürtöt a Microsoft Entra-bérlők között?

Szám Ekkor létre kell hoznia egy új Service Fabric-fürterőforrást az új bérlő alatt.

Áthelyezhetem/migrálhatom a fürtöt az előfizetések között?

Szám Ekkor létre kell hoznia egy új Service Fabric-fürterőforrást az új előfizetés alatt.

Áthelyezhetem/migrálhatom a fürt- vagy fürterőforrásokat más erőforráscsoportokba, vagy átnevezhetem őket?

Szám Ekkor létre kell hoznia egy új Service Fabric-fürterőforrást az új erőforráscsoport/név alatt.

Alkalmazástervezés

Mi a legjobb módja az adatok megbízható gyűjtemény partíciói közötti lekérdezésének?

A megbízható gyűjtemények általában particionálva vannak, hogy nagyobb teljesítményt és átviteli sebességet tegyenek lehetővé. Ez azt jelenti, hogy egy adott szolgáltatás állapota több tíz vagy több száz gépre terjedhet ki. Ha műveleteket szeretne végrehajtani a teljes adatkészleten, az alábbi lehetőségek közül választhat:

  • Hozzon létre egy szolgáltatást, amely lekérdezi egy másik szolgáltatás összes partícióját a szükséges adatok lekéréséhez.
  • Hozzon létre egy szolgáltatást, amely képes adatokat fogadni egy másik szolgáltatás összes partíciójáról.
  • Rendszeresen leküldi az adatokat az egyes szolgáltatásokból egy külső tárolóba. Ez a megközelítés csak akkor megfelelő, ha a végrehajtott lekérdezések nem részei az alapvető üzleti logikának, mivel a külső tároló adatai elavultak lesznek.
  • Másik lehetőségként olyan adatokat is tárol, amelyeknek támogatniuk kell az összes rekord lekérdezését közvetlenül egy adattárban, nem pedig megbízható gyűjteményben. Ez kiküszöböli az elavult adatokkal kapcsolatos problémát, de nem teszi lehetővé a megbízható gyűjtemények előnyeit.

Mi a legjobb módja az adatok lekérdezésének a színészek között?

A szereplőket úgy tervezték, hogy független állapot- és számítási egységek legyenek, ezért futásidőben nem ajánlott széles körű aktorállapot-lekérdezéseket végezni. Ha az aktor állapotának teljes halmazát le kell kérdeznie, fontolja meg a következők valamelyikét:

  • Az aktor-szolgáltatások lecserélése állapotalapú megbízható szolgáltatásokra, így a hálózati kérések száma, amelyek az összes adat összegyűjtésére irányulnak a szereplők számától a szolgáltatás partícióinak számához.
  • A könnyebb lekérdezés érdekében úgy tervezheti meg a szereplőket, hogy rendszeresen leküldjék az állapotukat egy külső tárolóba. A fentiekhez hasonlóan ez a megközelítés csak akkor használható, ha az éppen végrehajtott lekérdezések nem szükségesek a futásidejű működéshez.

Mennyi adatot tárolhatok egy megbízható gyűjteményben?

A megbízható szolgáltatások általában particionáltak, így a tárolható mennyiség csak a fürtön lévő gépek száma és az ezeken a gépeken rendelkezésre álló memória mennyisége alapján korlátozott.

Tegyük fel például, hogy egy megbízható gyűjtemény egy szolgáltatásban 100 partícióval és 3 replikával rendelkezik, amelyek átlagosan 1 kb méretű objektumokat tárolnak. Tegyük fel, hogy van egy 10 gépfürtje, amely gépenként 16 GB memóriával rendelkezik. Az egyszerűség és a konzervatívság kedvéért tegyük fel, hogy az operációs rendszer és a rendszerszolgáltatások, a Service Fabric-futtatókörnyezet és a szolgáltatások 6 GB-ot használnak fel, így gépenként 10 gb vagy 100 GB lesz a fürt számára.

Ne feledje, hogy minden objektumot háromszor (egy elsődleges és két replika) kell tárolni, elegendő memóriával rendelkezik a gyűjtemény körülbelül 35 millió objektumához, amikor teljes kapacitással működik. Javasoljuk azonban, hogy rugalmas legyen egy hibatartomány és egy frissítési tartomány egyidejű elvesztésével szemben, amely körülbelül a kapacitás 1/3-át jelenti, és körülbelül 23 millióra csökkentené a számot.

Ez a számítás a következőket is feltételezi:

  • Az adatok partíciók közötti eloszlása nagyjából egységes, vagy hogy terhelési metrikákat jelent a fürterőforrás-kezelőnek. Alapértelmezés szerint a Service Fabric betölti az egyensúlyt a replikák száma alapján. Az előző példában 10 elsődleges replikát és 20 másodlagos replikát helyezne el a fürt minden csomópontján. Ez jól működik a partíciók között egyenletesen elosztott terheléshez. Ha a terhelés nem egyenletes, be kell jelentenie a terhelést, hogy a Resource Manager összecsomagolhassa a kisebb replikákat, és lehetővé tegye a nagyobb replikák számára, hogy több memóriát használhassanak fel egy adott csomóponton.

  • Az, hogy a szóban forgó megbízható szolgáltatás az egyetlen, amely a fürtön tárolja az állapotot. Mivel több szolgáltatást is üzembe helyezhet egy fürtben, figyelembe kell vennie azokat az erőforrásokat, amelyeket mindegyiknek futtatnia és kezelnie kell az állapotát.

  • Hogy maga a fürt nem növekszik vagy zsugorodik. Ha további gépeket ad hozzá, a Service Fabric újra kiegyensúlyozza a replikákat a további kapacitás kihasználása érdekében, amíg a gépek száma meg nem haladja a szolgáltatás partícióinak számát, mivel az egyes replikák nem haladják meg a gépeket. Ezzel szemben, ha a gépek eltávolításával csökkenti a fürt méretét, a replikák szorosabban vannak csomagolva, és kevesebb a teljes kapacitásuk.

Mennyi adatot tárolhatok egy színészben?

A megbízható szolgáltatásokhoz hasonlóan az aktorszolgáltatásban tárolható adatok mennyiségét csak a fürt csomópontjaiban elérhető teljes lemezterület és memória korlátozza. Az egyes szereplők azonban akkor a leghatékonyabbak, ha kis mennyiségű állam és kapcsolódó üzleti logika beágyazására használják őket. Általános szabály, hogy az egyes szereplőknek kilobájtban mért állapotmal kell rendelkezniük.

Hol tárolja az Azure Service Fabric erőforrás-szolgáltató az ügyféladatokat?

Az Azure Service Fabric-erőforrás-szolgáltató nem helyezi át vagy tárolja az ügyféladatokat az üzembe helyezett régióból.

Egyéb kérdések

Hogyan kapcsolódik a Service Fabric a tárolókhoz?

A tárolók egyszerű módot kínálnak a szolgáltatások és függőségeik csomagolására, hogy minden környezetben konzisztensen fussanak, és elszigetelt módon működjenek egyetlen gépen. A Service Fabric lehetővé teszi a szolgáltatások üzembe helyezését és kezelését, beleértve a tárolóba csomagolt szolgáltatásokat is.

Nyílt forráskódú Service Fabricet tervez?

A Service Fabric nyílt forráskódú részeivel (reliable services framework, reliable actors framework, ASP.NET Core integrációs kódtárak, Service Fabric Explorer és Service Fabric CLI) rendelkezünk a GitHubon, és közösségi hozzájárulásokat fogadunk el ezekhez a projektekhez.

Nemrég bejelentettük, hogy a Service Fabric-futtatókörnyezet nyílt forráskódú lesz. Jelenleg a Service Fabric-adattár a GitHubon érhető el Linux buildelési és tesztelési eszközökkel, ami azt jelenti, hogy klónozhatja az adattárat, felépítheti a Service Fabricet Linuxhoz, futtathat alapszintű teszteket, megnyithatja a problémákat, és lekéréses kérelmeket küldhet. Keményen dolgozunk azon, hogy a Windows buildkörnyezetét is áttelepítsük, valamint egy teljes CI-környezetet.

A bejelentések részleteiért kövesse a Service Fabric blogot .

Következő lépések

Tudnivalók a Service Fabric futtatókörnyezetre vonatkozó fogalmairól és ajánlott eljárásairól