Upgrade a aktualizace clusterů Azure Service Fabric
Cluster Azure Service Fabric je prostředek, který vlastníte, ale částečně ho spravuje Microsoft. Tento článek popisuje možnosti, kdy a jak aktualizovat cluster Azure Service Fabric.
Automatické versus ruční upgrady
Je důležité zajistit, aby váš cluster Service Fabric vždy běžel podporovanou verzi modulu runtime. Pokaždé, když Microsoft oznámí vydání nové verze Service Fabric, je předchozí verze označena pro ukončení podpory po uplynutí minimálně 60 dnů od tohoto data. Nové verze jsou oznámeny na blogu týmu Service Fabric.
Čtrnáct dní před vypršením platnosti vydané verze clusteru se vygeneruje událost stavu, která cluster umístí do stavu upozornění . Cluster zůstane ve stavu upozornění, dokud neupgradujete na podporovanou verzi modulu runtime.
Cluster můžete nastavit tak, aby přijímal automatické upgrady Service Fabric při jejich vydání microsoftem, nebo si můžete ručně vybrat ze seznamu aktuálně podporovaných verzí. Tyto možnosti jsou k dispozici v části Upgrady prostředků clusteru Service Fabric.
Můžete také nastavit režim upgradu clusteru a vybrat verzi modulu runtime pomocí šablony Resource Manageru.
Automatický upgrade je doporučený režim upgradu, protože tato možnost zajišťuje, že váš cluster zůstane v podporovaném stavu a bude využívat nejnovější opravy a funkce a zároveň vám umožní naplánovat aktualizace způsobem, který bude nejméně rušivý pro vaše úlohy pomocí strategie nasazení vln.
Poznámka:
Pokud změníte existující cluster na automatický režim, cluster se zaregistruje na další období upgradu počínaje novou verzí. Nové verze jsou oznámeny na blogu týmu Service Fabric. Pro každé období upgradu je zvolena nejvyšší možná cesta upgradu, viz podporované verze. Režim ručního upgradu aktivuje okamžitý upgrade.
Nasazení wave pro automatické upgrady
Při nasazení vln můžete minimalizovat přerušení upgradu na cluster výběrem úrovně vyspělosti upgradu v závislosti na vaší úloze. Můžete například nastavit kanál nasazení Test -Stage ->>Production wave pro různé clustery Service Fabric, abyste před použitím upgradu modulu runtime otestovali kompatibilitu upgradu modulu runtime.
Pokud chcete vyjádřit výslovný souhlas s nasazením vln, zadejte jednu z následujících hodnot vlny pro váš cluster (v šabloně nasazení):
- Vlna 0: Clustery se aktualizují hned po vydání nového buildu Service Fabric. Určeno pro testovací a vývojové clustery.
- Vlna 1: Clustery se aktualizují o týden (sedm dní) po vydání nového buildu. Určeno pro předpřipravené nebo přípravné clustery.
- Vlna 2: Clustery se aktualizují dva týdny (14 dní) po vydání nového buildu. Určeno pro produkční clustery.
Pokud se upgrade clusteru nezdaří, můžete si zaregistrovat e-mailová oznámení s odkazy na další pomoc. Pokud chcete začít, podívejte se na nasazení wave pro automatické upgrady .
Fáze automatického upgradu
Microsoft udržuje kód a konfiguraci modulu runtime Service Fabric, který běží v clusteru Azure. Automaticky monitorované upgrady softwaru provádíme podle potřeby. Tyto upgrady můžou být kód, konfigurace nebo obojí. Pokud chcete minimalizovat dopad těchto upgradů na vaše aplikace, provádějí se v následujících fázích:
Fáze 1: Upgrade se provádí pomocí všech zásad stavu clusteru.
Během této fáze upgrady probíhají postupně po jedné doméně upgradu a aplikace spuštěné v clusteru budou dál běžet bez jakýchkoli výpadků. Zásady stavu clusteru (pro stav uzlu a stav aplikace) se během upgradu dodržují.
Pokud zásady stavu clusteru nejsou splněné, upgrade se vrátí zpět a pošle se e-mail vlastníkovi předplatného. E-mail obsahuje následující informace:
- Oznámení, že jsme museli vrátit zpět upgrade clusteru.
- Navrhované nápravné akce, pokud existuje.
- Počet dnů (n), dokud nespustíme fázi 2.
Pokusíme se provést stejný upgrade několikrát několikrát v případě selhání upgradů z důvodů infrastruktury. Po n dnech od data odeslání e-mailu pokračujeme do fáze 2.
Pokud jsou splněné zásady stavu clusteru, upgrade se považuje za úspěšný a označený jako dokončený. K této situaci může dojít během počátečního upgradu nebo jakéhokoli opětovného spuštění upgradu v této fázi. Neexistuje žádné potvrzení úspěšného spuštění e-mailu, abyste se vyhnuli odesílání nadměrných e-mailů. Příjem e-mailu označuje výjimku normálního provozu. Očekáváme, že většina upgradů clusteru bude úspěšná, aniž by to mělo vliv na dostupnost vaší aplikace.
Fáze 2: Upgrade se provádí pouze pomocí výchozích zásad stavu.
Zásady stavu v této fázi jsou nastavené tak, aby počet aplikací, které byly na začátku upgradu v pořádku, zůstaly během procesu upgradu stejné. Stejně jako ve fázi 1 upgraduje fáze 2 postupně jednu doménu upgradu a aplikace spuštěné v clusteru budou dál běžet bez jakýchkoli výpadků. Zásady stavu clusteru (kombinace stavu uzlu a stavu všech aplikací spuštěných v clusteru) se během upgradu dodržují.
Pokud zásady stavu clusteru nejsou splněné, upgrade se vrátí zpět. Pak se pošle e-mail vlastníkovi předplatného. E-mail obsahuje následující informace:
- Oznámení, že jsme museli vrátit zpět upgrade clusteru.
- Navrhované nápravné akce, pokud existuje.
- Počet dnů (n) do provedení fáze 3.
Pokusíme se provést stejný upgrade několikrát několikrát v případě selhání upgradů z důvodů infrastruktury. E-mail s připomenutím se pošle několik dní před n dny. Po n dnech od data odeslání e-mailu přejdeme do fáze 3. E-maily, které vám pošleme ve fázi 2, se musí brát vážně a musí být přijata nápravná opatření.
Pokud jsou splněné zásady stavu clusteru, upgrade se považuje za úspěšný a označený jako dokončený. K tomu může dojít během počátečního upgradu nebo jakéhokoli opětovného spuštění upgradu v této fázi. Úspěšné spuštění není potvrzeno e-mailem.
Fáze 3: Upgrade se provádí pomocí agresivních zásad stavu
Tyto zásady stavu v této fázi jsou zaměřené na dokončení upgradu, nikoli na stav aplikací. V této fázi skončí několik upgradů clusteru. Pokud se váš cluster dostane do této fáze, existuje dobrá šance, že vaše aplikace není v pořádku nebo ztratí dostupnost.
Podobně jako u ostatních dvou fází probíhá upgrade fáze 3 postupně po jedné doméně upgradu.
Pokud nejsou splněné zásady stavu clusteru, upgrade se vrátí zpět. Pokusíme se provést stejný upgrade několikrát několikrát v případě selhání upgradů z důvodů infrastruktury. Potom se cluster připne, takže už nebude dostávat podporu ani upgrady.
E-mail s touto informací se pošle vlastníkovi předplatného spolu s nápravnými akcemi. Neočekáváme, že by se žádné clustery dostaly do stavu, kdy fáze 3 selhala.
Pokud jsou splněné zásady stavu clusteru, upgrade se považuje za úspěšný a označený jako dokončený. K tomu může dojít během počátečního upgradu nebo jakéhokoli opětovného spuštění upgradu v této fázi. Úspěšné spuštění není potvrzeno e-mailem.
Vlastní zásady pro ruční upgrady
Můžete zadat vlastní zásady pro ruční upgrady clusteru. Tyto zásady se použijí pokaždé, když vyberete novou verzi modulu runtime, která aktivuje systém, aby se spustil upgrade clusteru. Pokud zásady nepřepíšete, použijí se výchozí hodnoty. Další informace najdete v tématu Nastavení vlastních zásad pro ruční upgrady.
Další aktualizace clusteru
Mimo upgrade modulu runtime existuje řada dalších akcí, které možná budete muset provést, aby byl cluster aktuální, včetně následujících:
Správa certifikátů
Service Fabric používá certifikáty serveru X.509, které zadáte při vytváření clusteru pro zabezpečení komunikace mezi uzly clusteru a ověření klientů. Certifikáty pro cluster a klienta můžete přidat, aktualizovat nebo odstranit na webu Azure Portal nebo pomocí PowerShellu nebo Azure CLI. Další informace najdete v článku o přidávání nebo odebírání certifikátů.
Otevření portů aplikace
Porty aplikace můžete změnit změnou vlastností prostředku Load Balanceru, které jsou přidružené k typu uzlu. Můžete použít Azure Portal nebo PowerShell nebo Azure CLI. Další informace najdete v tématu Otevření portů aplikace pro cluster.
Definování vlastností uzlu
Někdy můžete chtít zajistit, aby určité úlohy běžely jenom na určitých typech uzlů v clusteru. Některé úlohy můžou například vyžadovat gpu nebo disky SSD, zatímco jiné nemusí. Pro každý z typů uzlů v clusteru můžete do uzlů clusteru přidat vlastní vlastnosti uzlu. Omezení umístění jsou příkazy připojené k jednotlivým službám, které vyberou jednu nebo více vlastností uzlu. Omezení umístění definují, kde se mají služby spouštět.
Podrobnosti o použití omezení umístění, vlastností uzlu a jejich definování, čtení vlastností uzlu a omezení umístění.
Přidání metrik kapacity
Pro každý z typů uzlů můžete přidat vlastní metriky kapacity, které chcete použít v aplikacích k hlášení zatížení. Podrobnosti o využití metrik kapacity k hlášení zatížení najdete v dokumentech Resource Manageru clusteru Service Fabric popisující cluster a metriky a načtení.
Přizpůsobení nastavení clusteru
Mnoho různých nastavení konfigurace je možné přizpůsobit v clusteru, například úroveň spolehlivosti clusteru a vlastností uzlu. Další informace najdete v nastavení clusteru Service Fabric.
Poznámka:
U clusterů, které používají verze modulu runtime před verzí 10.0CU6, 10.1CU5 a 9.1CU12, pokud jste upravili nebo plánujete upravit jakékoli nastavení NTLM pro FileStoreService, počítejte s určitým výpadkem, zatímco se uzly clusteru restartují. Toto restartování je svázané s vyčištěním, ke kterému dochází během cyklu upgradu.
Toto chování se změní od verze 10.0CU6, 10.1CU5 a 9.1CU12 a v clusterech s těmito verzemi nebo novějšími by se nemělo restartovat žádný uzel.
Další informace o správě verzí Service Fabric najdete na stránce s verzemi.
Upgrade imagí operačního systému pro uzly clusteru
Povolení automatických upgradů imagí operačního systému pro uzly clusteru Service Fabric je osvědčeným postupem. Aby to bylo možné provést, existuje několik požadavků na cluster a kroky, které je potřeba provést. Další možností je použití aplikace Service Fabric (Patch Orchestraation Application), která automatizuje opravy operačního systému v clusteru Service Fabric bez výpadků. Další informace o těchto možnostech najdete v tématu Oprava operačního systému Windows v clusteru Service Fabric.