Azure Service Fabric-clusters upgraden en bijwerken

  • Artikel

Een Azure Service Fabric-cluster is een resource die u bezit, maar deze wordt gedeeltelijk beheerd door Microsoft. In dit artikel worden de opties beschreven voor wanneer en hoe u uw Azure Service Fabric-cluster bijwerkt.

Automatische versus handmatige upgrades

Het is essentieel om ervoor te zorgen dat uw Service Fabric-cluster altijd een ondersteunde runtimeversie uitvoert. Telkens wanneer Microsoft de release van een nieuwe versie van Service Fabric aankondigt, wordt de vorige versie gemarkeerd voor beëindiging van de ondersteuning na minimaal 60 dagen vanaf die datum. Nieuwe releases worden aangekondigd op de Blog van het Service Fabric-team.

Veertien dagen voordat de release van uw cluster verloopt, wordt er een statusgebeurtenis gegenereerd die uw cluster in de status Waarschuwing plaatst. Het cluster blijft in een waarschuwingsstatus totdat u een upgrade uitvoert naar een ondersteunde runtimeversie.

U kunt instellen dat uw cluster automatische Service Fabric-upgrades ontvangt wanneer deze door Microsoft worden uitgebracht, of u kunt handmatig kiezen uit een lijst met momenteel ondersteunde versies. Deze opties zijn beschikbaar in de sectie Infrastructuurupgrades van uw Service Fabric-clusterresource.

Selecteer Automatische of handmatige upgrades in de sectie Infrastructuurupgrades van uw clusterresource in Azure Portal.

U kunt ook de clusterupgrademodus instellen en een runtime-versie selecteren met behulp van een Resource Manager-sjabloon.

Automatische upgrades zijn de aanbevolen upgrademodus, omdat deze optie ervoor zorgt dat uw cluster in een ondersteunde status blijft en profiteert van de nieuwste oplossingen en functies, terwijl u ook updates kunt plannen op een manier die het minst verstorend is voor uw workloads met behulp van een wave-implementatiestrategie .

Notitie

Als u een bestaand cluster wijzigt in de automatische modus, wordt het cluster ingeschreven voor de volgende upgradeperiode, te beginnen met een nieuwe release. Nieuwe releases worden aangekondigd op de Blog van het Service Fabric-team. Per upgradeperiode wordt het hoogst mogelijke upgradepad gekozen. Zie ondersteunde versies. De handmatige upgrademodus activeert een onmiddellijke upgrade.

Wave-implementatie voor automatische upgrades

Met wave-implementatie kunt u de onderbreking van een upgrade naar uw cluster minimaliseren door het volwassenheidsniveau van een upgrade te selecteren, afhankelijk van uw workload. U kunt bijvoorbeeld een implementatiepijplijn Test ->Fase ->Productiegolf instellen voor uw verschillende Service Fabric-clusters om de compatibiliteit van een runtime-upgrade te testen voordat u deze toepast op uw productieworkloads.

Als u zich wilt aanmelden voor wave-implementatie, geeft u een van de volgende wave-waarden op voor uw cluster (in de implementatiesjabloon):

  • Wave 0: Clusters worden bijgewerkt zodra een nieuwe Service Fabric-build wordt uitgebracht. Bedoeld voor test-/ontwikkelclusters.
  • Wave 1: Clusters worden één week (zeven dagen) bijgewerkt nadat een nieuwe build is uitgebracht. Bedoeld voor pre-prod-/faseringsclusters.
  • Wave 2: Clusters worden twee weken (14 dagen) bijgewerkt nadat een nieuwe build is uitgebracht. Bedoeld voor productieclusters.

U kunt zich registreren voor e-mailmeldingen met koppelingen naar verdere hulp als een clusterupgrade mislukt. Zie Wave-implementatie voor automatische upgrades om aan de slag te gaan.

Fasen van automatische upgrade

Microsoft onderhoudt de Service Fabric-runtimecode en -configuratie die wordt uitgevoerd in een Azure-cluster. We voeren automatisch bewaakte upgrades voor de software uit op een basis die nodig is. Deze upgrades kunnen code, configuratie of beide zijn. Om de impact van deze upgrades op uw toepassingen te minimaliseren, worden ze in de volgende fasen uitgevoerd:

Fase 1: een upgrade wordt uitgevoerd met behulp van alle clusterstatusbeleidsregels

Tijdens deze fase worden de upgrades één upgradedomein tegelijk uitgevoerd en blijven de toepassingen die in het cluster werden uitgevoerd, zonder uitvaltijd worden uitgevoerd. Het clusterstatusbeleid (voor knooppuntstatus en toepassingsstatus) wordt tijdens de upgrade nageleefd.

Als niet aan het clusterstatusbeleid wordt voldaan, wordt de upgrade teruggedraaid en wordt er een e-mailbericht verzonden naar de eigenaar van het abonnement. Het e-mailbericht bevat de volgende informatie:

  • Melding dat we een clusterupgrade moesten terugdraaien.
  • Voorgestelde herstelacties, indien van toepassing.
  • Het aantal dagen (n) totdat fase 2 wordt uitgevoerd.

We proberen dezelfde upgrade nog een paar keer uit te voeren voor het geval upgrades om infrastructuurredenen zijn mislukt. Na de n dagen vanaf de datum waarop de e-mail is verzonden, gaan we verder naar fase 2.

Als aan het statusbeleid van het cluster wordt voldaan, wordt de upgrade als geslaagd beschouwd en gemarkeerd als voltooid. Deze situatie kan zich voordoen tijdens de eerste upgrade of een van de upgrades die in deze fase opnieuw wordt uitgevoerd. Er is geen e-mailbevestiging van een geslaagde uitvoering, om te voorkomen dat overmatige e-mailberichten worden verzonden. Het ontvangen van een e-mailbericht geeft een uitzondering op normale bewerkingen aan. We verwachten dat de meeste clusterupgrades slagen zonder dat dit van invloed is op de beschikbaarheid van uw toepassing.

Fase 2: een upgrade wordt alleen uitgevoerd met behulp van standaardstatusbeleid

Het statusbeleid in deze fase is zodanig ingesteld dat het aantal toepassingen dat aan het begin van de upgrade in orde was, gelijk blijft tijdens het upgradeproces. Net als in fase 1 gaan de fase 2-upgrades één domein tegelijk upgraden en blijven de toepassingen die in het cluster werden uitgevoerd, zonder enige downtime worden uitgevoerd. Het clusterstatusbeleid (een combinatie van knooppuntstatus en de status van alle toepassingen die in het cluster worden uitgevoerd) wordt tijdens de upgrade nageleefd.

Als niet wordt voldaan aan het statusbeleid van het cluster, wordt de upgrade teruggedraaid. Vervolgens wordt er een e-mail verzonden naar de eigenaar van het abonnement. Het e-mailbericht bevat de volgende informatie:

  • Melding dat we een clusterupgrade moesten terugdraaien.
  • Voorgestelde herstelacties, indien van toepassing.
  • Het aantal dagen (n) totdat fase 3 wordt uitgevoerd.

We proberen dezelfde upgrade nog een paar keer uit te voeren voor het geval upgrades om infrastructuurredenen zijn mislukt. Een herinneringsmail wordt een paar dagen voordat n dagen zijn afgelopen verzonden. Na de n dagen vanaf de datum waarop de e-mail is verzonden, gaan we verder met fase 3. De e-mails die we u in fase 2 sturen, moeten serieus worden genomen en er moeten herstelacties worden ondernomen.

Als aan het statusbeleid van het cluster wordt voldaan, wordt de upgrade als geslaagd beschouwd en gemarkeerd als voltooid. Dit kan gebeuren tijdens de eerste upgrade of een van de upgrades wordt opnieuw uitgevoerd in deze fase. Er is geen e-mailbevestiging van een geslaagde uitvoering.

Fase 3: een upgrade wordt uitgevoerd met behulp van agressief statusbeleid

Deze statusbeleidsregels in deze fase zijn gericht op het voltooien van de upgrade en niet op de status van de toepassingen. Er komen weinig clusterupgrades in deze fase terecht. Als uw cluster in deze fase komt, is er een goede kans dat uw toepassing beschadigd raakt en/of de beschikbaarheid verliest.

Net als bij de andere twee fasen vinden fase 3-upgrades één upgradedomein tegelijk plaats.

Als niet aan het statusbeleid van het cluster wordt voldaan, wordt de upgrade teruggedraaid. We proberen dezelfde upgrade nog een paar keer uit te voeren voor het geval upgrades om infrastructuurredenen zijn mislukt. Daarna wordt het cluster vastgemaakt, zodat het geen ondersteuning en/of upgrades meer ontvangt.

Er wordt een e-mailbericht met deze informatie verzonden naar de eigenaar van het abonnement, samen met de herstelacties. Er wordt niet verwacht dat clusters een status krijgen waarin fase 3 is mislukt.

Als aan het statusbeleid van het cluster wordt voldaan, wordt de upgrade als geslaagd beschouwd en gemarkeerd als voltooid. Dit kan gebeuren tijdens de eerste upgrade of een van de upgrades wordt opnieuw uitgevoerd in deze fase. Er is geen e-mailbevestiging van een geslaagde uitvoering.

Aangepast beleid voor handmatige upgrades

U kunt aangepaste beleidsregels opgeven voor handmatige clusterupgrades. Deze beleidsregels worden toegepast telkens wanneer u een nieuwe runtime-versie selecteert, waardoor het systeem wordt geactiveerd om de upgrade van uw cluster te starten. Als u het beleid niet overschrijft, worden de standaardinstellingen gebruikt. Zie Aangepast beleid instellen voor handmatige upgrades voor meer informatie.

Andere clusterupdates

Naast het upgraden van de runtime moet u mogelijk een aantal andere acties uitvoeren om uw cluster up-to-date te houden, waaronder de volgende:

Certificaten beheren

Service Fabric maakt gebruik van X.509-servercertificaten die u opgeeft wanneer u een cluster maakt om de communicatie tussen clusterknooppunten te beveiligen en clients te verifiëren. U kunt certificaten voor het cluster en de client toevoegen, bijwerken of verwijderen in de Azure Portal of met behulp van PowerShell/Azure CLI. Lees certificaten toevoegen of verwijderen voor meer informatie

Toepassingspoorten openen

U kunt toepassingspoorten wijzigen door de Load Balancer resource-eigenschappen te wijzigen die zijn gekoppeld aan het knooppunttype. U kunt de Azure Portal of PowerShell/Azure CLI gebruiken. Lees Toepassingspoorten openen voor een cluster voor meer informatie.

Knooppunteigenschappen definiëren

Soms wilt u ervoor zorgen dat bepaalde workloads alleen worden uitgevoerd op bepaalde typen knooppunten in het cluster. Voor sommige werkbelastingen zijn bijvoorbeeld GPU's of SSD's vereist, terwijl andere mogelijk niet. Voor elk van de knooppunttypen in een cluster kunt u aangepaste knooppunteigenschappen toevoegen aan clusterknooppunten. Plaatsingsbeperkingen zijn de instructies die zijn gekoppeld aan afzonderlijke services die selecteren voor een of meer knooppunteigenschappen. Plaatsingsbeperkingen bepalen waar services moeten worden uitgevoerd.

Lees knooppunteigenschappen en plaatsingsbeperkingen voor meer informatie over het gebruik van plaatsingsbeperkingen, knooppunteigenschappen en knooppunteigenschappen.

Metrische gegevens over capaciteit toevoegen

Voor elk van de knooppunttypen kunt u aangepaste metrische capaciteitsgegevens toevoegen die u in uw toepassingen wilt gebruiken om de belasting te rapporteren. Voor meer informatie over het gebruik van metrische gegevens over capaciteit om belasting te rapporteren, raadpleegt u de Service Fabric-cluster Resource Manager Documenten over het beschrijven van uw cluster en metrische gegevens en belasting.

Instellingen voor uw cluster aanpassen

Veel verschillende configuratie-instellingen kunnen worden aangepast op een cluster, zoals het betrouwbaarheidsniveau van de cluster- en knooppunteigenschappen. Lees Service Fabric-clusterinfrastructuurinstellingen voor meer informatie.

Installatiekopieën van het besturingssysteem voor clusterknooppunten upgraden

Het inschakelen van automatische upgrades van installatiekopieën van het besturingssysteem voor uw Service Fabric-clusterknooppunten is een best practice. Hiervoor moeten verschillende clustervereisten en stappen worden uitgevoerd. Een andere optie is het gebruik van Patch Orchestration Application (POA), een Service Fabric-toepassing waarmee het patchen van het besturingssysteem op een Service Fabric-cluster zonder downtime wordt geautomatiseerd. Zie Patch voor het Windows-besturingssysteem in uw Service Fabric-cluster voor meer informatie over deze opties.

Volgende stappen