Nejčastější dotazy ke službě Service Fabric

Existuje mnoho nejčastějších dotazů k tomu, co Může Service Fabric dělat a jak se má používat. Tento dokument popisuje řadu běžných otázek a jejich odpovědí.

Poznámka:

Při práci s Azure doporučujeme používat modul Azure Az PowerShellu. Pokud chcete začít, přečtěte si téma Instalace Azure PowerShellu. Informace o tom, jak migrovat na modul Az PowerShell, najdete v tématu Migrace Azure PowerShellu z AzureRM na Az.

Nastavení a správa clusteru

Návody vrátit zpět certifikát clusteru Service Fabric?

Vrácení veškerého upgradu do aplikace vyžaduje detekci selhání stavu před potvrzením změny v kvoru clusteru Service Fabric. potvrzené změny je možné vrátit dál. Eskalační technik prostřednictvím služeb zákaznické podpory může být nutný k obnovení clusteru, pokud něco představuje nesledovanou změnu certifikátu způsobující chybu. Upgrade aplikace Service Fabric používá parametry upgradu aplikace a poskytuje příslib upgradu nulového výpadku. Podle našeho doporučeného režimu monitorování upgradu aplikací je automatický postup prostřednictvím aktualizačních domén založený na předávání kontrol stavu. Pokud se aktualizace výchozí služby nezdaří, vrátí se zpět automaticky.

Pokud váš cluster stále používá vlastnost klasického kryptografického otisku certifikátu v šabloně Resource Manageru, doporučujeme změnit cluster z kryptografického otisku certifikátu na běžný název a použít moderní funkce správy tajných kódů.

Můžu vytvořit cluster, který zahrnuje více oblastí Azure nebo vlastní datacentra?

Ano.

Základní technologie clusteringu Service Fabric se dá použít ke kombinování počítačů běžících kdekoli na světě, pokud mají síťové připojení k sobě navzájem. Sestavení a spuštění takového clusteru ale může být složité.

Pokud vás tento scénář zajímá, doporučujeme vám kontaktovat se prostřednictvím seznamu problémů Service Fabric Na GitHubu nebo prostřednictvím zástupce podpory, abyste získali další pokyny. Tým Service Fabric pracuje na další přehlednosti, pokynech a doporučeních pro tento scénář.

Pár věcí k uvážení:

1. Prostředek clusteru Service Fabric v Azure je dnes regionální, stejně jako škálovací sady virtuálních počítačů, na které je cluster založený. To znamená, že v případě regionálního selhání může dojít ke ztrátě možnosti správy clusteru prostřednictvím Azure Resource Manageru nebo webu Azure Portal. K tomu může dojít, i když cluster zůstane spuštěný a budete s ním moct pracovat přímo. Kromě toho Azure v současné chvíli nenabízí možnost mít jednu virtuální síť, která je použitelná napříč oblastmi. To znamená, že cluster s více oblastmi v Azure vyžaduje pro každý virtuální počítač ve škálovacích sadách virtuálních počítačů nebo ve službě Azure VPN Gateway veřejné IP adresy. Tyto volby sítí mají různé dopady na náklady, výkon a návrh aplikací až do určitého stupně, takže před umístěním takového prostředí je nutná pečlivá analýza a plánování.
2. Údržba, správa a monitorování těchto počítačů se může komplikovat, zejména když jsou rozložené mezi typy prostředí, jako jsou různí poskytovatelé cloudu nebo místní prostředky a Azure. Před spuštěním produkčních úloh v takovém prostředí je potřeba věnovat pozornost upgradu, monitorování, správě a diagnostice clusteru i aplikacím. Pokud už máte zkušenosti s řešením těchto problémů v Azure nebo ve vlastních datacentrech, je pravděpodobné, že tato stejná řešení se dají použít při sestavování nebo spouštění clusteru Service Fabric.

Přijímají uzly Service Fabric aktualizace operačního systému automaticky?

Funkci Automatické aktualizace imagí operačního systému můžete dnes používat ve škálovací sadě virtuálních počítačů.

Pro clustery, které nejsou spuštěné v Azure, jsme poskytli aplikaci pro opravu operačních systémů pod uzly Service Fabric.

Můžu v clusteru SF používat velké škálovací sady virtuálních počítačů?

Krátká odpověď - Ne.

Dlouhá odpověď – I když velké škálovací sady virtuálních počítačů umožňují škálovat škálovací sadu virtuálních počítačů až na 1 000 instancí virtuálních počítačů, dělá to pomocí skupin umístění (PG). Domény selhání (FD) a upgradující domény (UD) jsou konzistentní pouze v rámci skupiny umístění Service Fabric, která k rozhodování o umístění replik služeb nebo instancí služby používá disky FD a UDS. Vzhledem k tomu, že disky FD a UD jsou srovnatelné pouze v rámci skupiny umístění, SF ho nemůže použít. Pokud má například virtuální počítač 1 v PG1 topologii FD=0 a VM9 v PG2 má topologii FD=4, neznamená to, že virtuální počítač 1 a VM2 jsou na dvou různých hardwarových rackech, proto SF nemůže k rozhodování o umístění použít hodnoty FD.

V současné době dochází k dalším problémům s velkými škálovacími sadami virtuálních počítačů, jako je nedostatek podpory vyrovnávání zatížení úrovně 4. Podrobnosti o rozsáhlých škálovacích sadách

Jaká je minimální velikost clusteru Service Fabric? Proč to nemůže být menší?

Minimální podporovaná velikost clusteru Service Fabric s produkčními úlohami je pět uzlů. Pro vývojové scénáře podporujeme jeden uzel (optimalizovaný pro rychlé vývojové prostředí v sadě Visual Studio) a pět clusterů uzlů.

Kvůli následujícím třem důvodům vyžadujeme, aby produkční cluster měl alespoň pět uzlů:

1. I když nejsou spuštěné žádné uživatelské služby, cluster Service Fabric spustí sadu stavových systémových služeb, včetně služby pojmenování a služby správce převzetí služeb při selhání. Tyto systémové služby jsou nezbytné pro zachování provozu clusteru.
2. Vždy umístíme jednu repliku služby na uzel, takže velikost clusteru je horní limit počtu replik, které může mít služba (ve skutečnosti oddíl).
3. Vzhledem k tomu, že upgrade clusteru způsobí aspoň jeden uzel, chceme mít vyrovnávací paměť alespoň jednoho uzlu, proto chceme, aby produkční cluster měl kromě minimálního běhu alespoň dva uzly. Úplné minimum je velikost kvora systémové služby, jak je vysvětleno níže.

Chceme, aby byl cluster k dispozici v případě současného selhání dvou uzlů. Aby byl cluster Service Fabric dostupný, musí být systémové služby dostupné. Stavové systémové služby, jako je pojmenování služby a služba správce převzetí služeb při selhání, sledují, které služby byly nasazeny do clusteru a kde jsou aktuálně hostované, závisí na silné konzistenci. Tato silná konzistence zase závisí na možnosti získat kvorum pro každou danou aktualizaci stavu těchto služeb, kde kvorum představuje striktní většinu replik (N/2 +1) pro danou službu. Proto pokud chceme být odolní proti souběžné ztrátě dvou uzlů (souběžná ztráta dvou replik systémové služby), musíme mít ClusterSize - KvorumSize >= 2, což vynutí minimální velikost na pět.

Všimněte si, že ve výše uvedeném argumentu jsme předpokládali, že každý uzel má repliku systémové služby; proto se velikost kvora vypočítá na základě počtu uzlů v clusteru. Změnou targetReplicaSetSize bychom ale mohli zmenšit velikost kvora menší než (N/2+1), což by mohlo mít dojem, že bychom mohli mít cluster menší než 5 uzlů a stále mít nad velikost kvora 2 další uzly. Pokud například v clusteru se 4 uzly nastavíme TargetReplicaSetSize na 3, velikost kvora založená na TargetReplicaSetSize je (3/2 + 1) nebo 2, takže máme ClusterSize - KvorumSize = 4-2 >= 2. Nemůžeme však zaručit, že systémová služba bude v kvoru nebo nad ním, pokud současně ztratíme dvojici uzlů, může to být tím, že dva uzly, které jsme ztratili, hostovaly dvě repliky, takže systémová služba přejde ke ztrátě kvora (zbývá jenom jedna replika) a stane se nedostupnou.

S tímto pozadím se podíváme na některé možné konfigurace clusteru:

Jeden uzel: Tato možnost neposkytuje vysokou dostupnost, protože ztráta jednoho uzlu z jakéhokoli důvodu znamená ztrátu celého clusteru.

Dva uzly: kvorum pro službu nasazenou napříč dvěma uzly (N = 2) je 2 (2/2 + 1 = 2). Když dojde ke ztrátě jedné repliky, není možné vytvořit kvorum. Vzhledem k tomu, že provedení upgradu služby vyžaduje dočasné odstranění repliky, není to užitečná konfigurace.

Tři uzly: se třemi uzly (N=3) je požadavek na vytvoření kvora stále dva uzly (3/2 + 1 = 2). To znamená, že můžete ztratit jednotlivé uzly a stále udržovat kvorum, ale současné selhání dvou uzlů bude řídit systémové služby do ztráty kvora a způsobí nedostupnost clusteru.

Čtyři uzly: se čtyřmi uzly (N=4) je požadavek na vytvoření kvora tři uzly (4/2 + 1 = 3). To znamená, že můžete ztratit jednotlivé uzly a stále udržovat kvorum, ale současné selhání dvou uzlů bude řídit systémové služby do ztráty kvora a způsobí nedostupnost clusteru.

Pět uzlů: s pěti uzly (N=5), požadavek na vytvoření kvora je stále tři uzly (5/2 + 1 = 3). To znamená, že můžete současně ztratit dva uzly a stále udržovat kvorum pro systémové služby.

U produkčních úloh musíte být odolní vůči souběžné chybě nejméně dvou uzlů (například kvůli upgradu clusteru, jedné z jiných důvodů), takže je potřeba pět uzlů.

Můžu vypnout cluster v noci/o víkendech, aby se ušetřily náklady?

Obecně platí, že ne. Service Fabric ukládá stav na místních dočasných discích, což znamená, že pokud se virtuální počítač přesune na jiného hostitele, data se s ním nepřesouvají. V normálním provozu to není problém, protože nový uzel je aktuální jinými uzly. Pokud ale zastavíte všechny uzly a restartujete je později, existuje významná možnost, že se většina uzlů spustí na nových hostitelích a systém nebude moct obnovit.

Pokud chcete vytvořit clustery pro testování aplikace před nasazením, doporučujeme tyto clustery dynamicky vytvářet jako součást kanálu průběžné integrace nebo průběžného nasazování.

Návody upgradovat operační systém (například z Windows Serveru 2012 na Windows Server 2016)?

Zatímco pracujeme na vylepšeném prostředí, v současné době zodpovídáte za upgrade. Image operačního systému musíte upgradovat na virtuálních počítačích clusteru po jednom virtuálním počítači.

Můžu připojené datové disky zašifrovat v typu uzlu clusteru (škálovací sada virtuálních počítačů)?

Ano. Další informace najdete v tématu Vytvoření clusteru s připojenými datovými disky a službou Azure Disk Encryption pro škálovací sady virtuálních počítačů.

Můžu použít virtuální počítače s nízkou prioritou v typu uzlu clusteru (škálovací sada virtuálních počítačů)?

Ne. Virtuální počítače s nízkou prioritou se nepodporují.

Jaké adresáře a procesy musím vyloučit při spuštění antivirového programu v clusteru?

Vyloučené adresáře antivirové ochrany
Program Files\Microsoft Service Fabric
FabricDataRoot (z konfigurace clusteru)
FabricLogRoot (z konfigurace clusteru)

Vyloučené procesy antivirové ochrany
Fabric.exe
FabricHost.exe
FabricInstallerService.exe
FabricSetup.exe
FabricDeployer.exe
ImageBuilder.exe
FabricGateway.exe
FabricDCA.exe
FabricFAS.exe
FabricUOS.exe
FabricRM.exe
FileStoreService.exe

Jak se moje aplikace ověří ve službě Key Vault, aby získala tajné kódy?

To znamená, že vaše aplikace získá přihlašovací údaje pro ověřování ve službě Key Vault:

A. Během sestavování a balení aplikací můžete do datového balíčku aplikace SF načíst certifikát a použít ho k ověření ve službě Key Vault. B. U hostitelů s podporou MSI škálovací sady virtuálních počítačů můžete pro aplikaci SF vyvíjet jednoduchý PowerShell SetupEntryPoint, abyste získali přístupový token z koncového bodu MSI a pak získali tajné kódy ze služby Key Vault.

Můžu své předplatné převést do jiného tenanta Microsoft Entra?

Ne. V tuto chvíli byste po převodu předplatného do jiného tenanta Microsoft Entra museli vytvořit nový prostředek clusteru Service Fabric.

Můžu přesunout nebo migrovat cluster mezi tenanty Microsoft Entra?

Ne. V tuto chvíli byste v rámci nového tenanta museli vytvořit nový prostředek clusteru Service Fabric.

Můžu přesunout nebo migrovat cluster mezi předplatnými?

Ne. V tuto chvíli budete muset v rámci nového předplatného vytvořit nový prostředek clusteru Service Fabric.

Můžu přesunout nebo migrovat prostředky clusteru nebo clusteru do jiných skupin prostředků nebo je přejmenovat?

Ne. V tuto chvíli byste museli vytvořit nový prostředek clusteru Service Fabric pod novou skupinou prostředků nebo názvem.

Návrh aplikace

Jaký je nejlepší způsob, jak dotazovat data napříč oddíly spolehlivé kolekce?

Spolehlivé kolekce jsou obvykle rozdělené na oddíly, které umožňují horizontální navýšení kapacity pro zajištění vyššího výkonu a propustnosti. To znamená, že stav dané služby může být rozložen do desítek nebo stovek počítačů. Pokud chcete provádět operace s celou sadou dat, máte několik možností:

• Vytvořte službu, která se dotazuje na všechny oddíly jiné služby a načítá požadovaná data.
• Vytvořte službu, která může přijímat data ze všech oddílů jiné služby.
• Pravidelně odsílají data z každé služby do externího úložiště. Tento přístup je vhodný pouze v případě, že dotazy, které provádíte, nejsou součástí základní obchodní logiky, protože data externího úložiště budou zastaralá.
• Případně uložte data, která musí podporovat dotazování napříč všemi záznamy přímo v úložišti dat, a ne ve spolehlivé kolekci. Tím se eliminuje problém se zastaralými daty, ale neumožňuje využívat výhody spolehlivých kolekcí.

Jaký je nejlepší způsob, jak dotazovat data napříč mými aktéry?

Aktéři jsou navrženi tak, aby byly nezávislé jednotky stavu a výpočetních prostředků, takže se nedoporučuje provádět rozsáhlé dotazy na stav objektu actor za běhu. Pokud potřebujete dotazovat v celé sadě stavů objektu actor, měli byste zvážit jednu z těchto možností:

• Nahraďte služby actor stavovými spolehlivými službami, aby počet síťových požadavků na shromáždění všech dat z počtu herců do počtu oddílů ve vaší službě.
• Navrhování objektů actor tak, aby pravidelně odsílaly svůj stav do externího úložiště, aby se usnadnilo dotazování. Jak je uvedeno výše, tento přístup je realizovatelný pouze v případě, že dotazy, které provádíte, nejsou vyžadovány pro chování modulu runtime.

Kolik dat můžu uložit ve spolehlivé kolekci?

Spolehlivé služby jsou obvykle rozdělené na oddíly, takže množství, které můžete uložit, je omezené pouze počtem počítačů, které máte v clusteru, a množstvím paměti dostupné na těchto počítačích.

Předpokládejme například, že máte ve službě spolehlivou kolekci s 100 oddíly a 3 replikami a ukládáte objekty, které průměrně mají velikost 1 kB. Teď předpokládejme, že máte cluster 10 počítačů s 16 gb paměti na počítač. Kvůli jednoduchosti a konzervativnosti předpokládejme, že operační systém a systémové služby, modul runtime Service Fabric a vaše služby spotřebovávají 6 gb z toho, přičemž na počítač je k dispozici 10 GB nebo 100 gb pro cluster.

Mějte na paměti, že každý objekt musí být uložen třikrát (jeden primární a dva repliky), měli byste dostatek paměti pro přibližně 35 milionů objektů v kolekci při provozu v plné kapacitě. Doporučujeme však, aby byla odolná vůči souběžné ztrátě domény selhání a upgradované domény, která představuje přibližně 1/3 kapacity, a snížila by počet na přibližně 23 milionů.

Tento výpočet také předpokládá:

• Distribuce dat mezi oddíly je zhruba jednotná nebo že hlásíte metriky načítání do Správce prostředků clusteru. Ve výchozím nastavení je vyrovnávání zatížení Service Fabric založené na počtu replik. V předchozím příkladu by se na každý uzel v clusteru umístilo 10 primárních replik a 20 sekundárních replik. To funguje dobře pro zatížení, které je rovnoměrně rozdělené mezi oddíly. Pokud zatížení není ani, musíte načíst sestavu, aby Resource Manager mohl zabalit menší repliky dohromady a umožnit větším replikám spotřebovávat více paměti na jednotlivých uzlech.

• Spolehlivá služba je jediným úložištěm stavu v clusteru. Vzhledem k tomu, že do clusteru můžete nasadit více služeb, musíte mít na paměti prostředky, které musí každý spustit a spravovat jeho stav.

• Že samotný cluster se nerozrůstá ani nezmenšuje. Pokud přidáte další počítače, Service Fabric znovu vyrovnává vaše repliky, aby využily další kapacitu, dokud počet počítačů překročí počet oddílů ve vaší službě, protože jednotlivá replika nemůže zahrnovat počítače. Pokud naopak zmenšujete velikost clusteru odebráním počítačů, repliky se zabalí těsněji a mají menší celkovou kapacitu.

Kolik dat můžu uložit v objektu actor?

Stejně jako u spolehlivých služeb je množství dat, která můžete uložit ve službě actor, omezeno pouze celkovým místem na disku a pamětí dostupnou v uzlech ve vašem clusteru. Jednotlivé aktéry jsou ale nejúčinnější, když se používají k zapouzdření malého množství stavu a přidružené obchodní logiky. Obecně platí, že jednotlivý aktér by měl mít stav měřený v kilobajtech.

Kde poskytovatel prostředků Azure Service Fabric ukládá zákaznická data?

Poskytovatel prostředků Azure Service Fabric nepřesunuje ani neukládá zákaznická data z oblasti, ve které jsou nasazená.

Další otázky

Jak Service Fabric souvisí s kontejnery?

Kontejnery nabízejí jednoduchý způsob, jak zabalit služby a jejich závislosti tak, aby běžely konzistentně ve všech prostředích a mohly fungovat izolovaně na jednom počítači. Service Fabric nabízí způsob nasazení a správy služeb, včetně služeb zabalených v kontejneru.

Plánujete open source Service Fabric?

Na GitHubu máme opensourcové části Service Fabric (architektura spolehlivých služeb, architektura reliable actors, ASP.NET základní integrační knihovny, Service Fabric Explorer a Service Fabric CLI) a přijímáme příspěvky komunity k těmto projektům.

Nedávno jsme oznámili , že plánujeme open source modul runtime Service Fabric. V tuto chvíli máme úložiště Service Fabric spuštěné na GitHubu s linuxovými buildy a testovacími nástroji, což znamená, že úložiště můžete klonovat, sestavovat Service Fabric pro Linux, spouštět základní testy, otevírat problémy a odesílat žádosti o přijetí změn. Snažíme se také migrovat prostředí sestavení Windows spolu s kompletním prostředím CI.

Další podrobnosti o oznámení najdete na blogu Service Fabric.

Další kroky

Další informace o konceptech a osvědčených postupech modulu runtime Service Fabric