Azure Service Fabric-clusters upgraden en bijwerken
Een Azure Service Fabric-cluster is een resource die u bezit, maar wordt deels 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 het einde van de ondersteuning na minimaal 60 dagen vanaf die datum. Nieuwe releases worden aangekondigd in de Service Fabric-teamblog.
Veertien dagen voordat de release van het cluster is verlopen, wordt er een statusgebeurtenis gegenereerd waarmee uw cluster de status Waarschuwing krijgt. 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 Fabric-upgrades van uw Service Fabric-clusterresource.
U kunt ook de upgrademodus voor uw cluster instellen en een runtimeversie 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 golfimplementatiestrategie .
Notitie
Als u een bestaand cluster wijzigt in de automatische modus, wordt het cluster ingeschreven voor de volgende upgradeperiode vanaf een nieuwe release. Nieuwe releases worden aangekondigd in de Service Fabric-teamblog. Per upgradeperiode wordt het hoogst mogelijke upgradepad gekozen, zie ondersteunde versies. De handmatige upgrademodus activeert een onmiddellijke upgrade.
Golfimplementatie voor automatische upgrades
Met een golfimplementatie kunt u de onderbreking van een upgrade naar uw cluster minimaliseren door het vervaldatumniveau van een upgrade te selecteren, afhankelijk van uw workload. U kunt bijvoorbeeld een implementatiepijplijn testfase ->>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 golfimplementatie, geeft u een van de volgende golfwaarden op voor uw cluster (in de implementatiesjabloon):
- Wave 0: Clusters worden bijgewerkt zodra een nieuwe Service Fabric-build wordt uitgebracht. Bedoeld voor test-/ontwikkelclusters.
- Golf 1: Clusters worden één week (zeven dagen) bijgewerkt nadat een nieuwe build is uitgebracht. Bedoeld voor pre-prod-/faseringsclusters.
- Golf 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 voor 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 naar de software uit op basis van behoefte. 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: Er wordt een upgrade uitgevoerd met behulp van alle clusterstatusbeleidsregels
Tijdens deze fase worden de upgrades één upgradedomein tegelijk uitgevoerd en blijven de toepassingen die in het cluster worden uitgevoerd, zonder uitvaltijd actief. 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 met fase 2.
Als aan het clusterstatusbeleid wordt voldaan, wordt de upgrade beschouwd als geslaagd en gemarkeerd als voltooid. Deze situatie kan optreden tijdens de eerste upgrade of een van de upgrades die in deze fase opnieuw worden uitgevoerd. Er is geen e-mailbevestiging van een geslaagde uitvoering, om te voorkomen dat overmatige e-mailberichten worden verzonden. Als u een e-mailbericht ontvangt, wordt een uitzondering op normale bewerkingen aangegeven. We verwachten dat de meeste clusterupgrades slagen zonder dat dit van invloed is op de beschikbaarheid van uw toepassing.
Fase 2: Er wordt alleen een upgrade uitgevoerd met standaardstatusbeleid
Het statusbeleid in deze fase wordt zodanig ingesteld dat het aantal toepassingen dat aan het begin van de upgrade in orde was, hetzelfde blijft tijdens het upgradeproces. Net als in fase 1 gaan de fase 2-upgrades één upgradedomein tegelijk verder en blijven de toepassingen die in het cluster worden uitgevoerd, zonder uitvaltijd actief. Het clusterstatusbeleid (een combinatie van knooppuntstatus en de status van alle toepassingen die in het cluster worden uitgevoerd) worden tijdens de upgrade nageleefd.
Als niet aan het beleid voor clusterstatus wordt voldaan, wordt de upgrade teruggedraaid. Vervolgens 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 3 wordt uitgevoerd.
We proberen dezelfde upgrade nog een paar keer uit te voeren voor het geval upgrades om infrastructuurredenen zijn mislukt. Een herinnerings-e-mail wordt een paar dagen voor n dagen verzonden. Na de n dagen vanaf de datum waarop de e-mail is verzonden, gaan we verder met fase 3. De e-mailberichten die we u in fase 2 sturen, moeten serieus worden genomen en er moeten herstelacties worden ondernomen.
Als aan het clusterstatusbeleid wordt voldaan, wordt de upgrade beschouwd als geslaagd en gemarkeerd als voltooid. Dit kan gebeuren tijdens de eerste upgrade of een van de upgrades die in deze fase opnieuw worden uitgevoerd. Er is geen e-mailbevestiging van een geslaagde uitvoering.
Fase 3: Er wordt een upgrade uitgevoerd met behulp van agressief statusbeleid
Deze statusbeleidsregels in deze fase zijn gericht op het voltooien van de upgrade in plaats van de status van de toepassingen. Enkele clusterupgrades eindigen in deze fase. Als uw cluster deze fase krijgt, is er een goede kans dat uw toepassing beschadigd raakt en/of de beschikbaarheid verliest.
Net als in de andere twee fasen gaan fase 3-upgrades één upgradedomein tegelijk verder.
Als niet aan het clusterstatusbeleid 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. We verwachten niet dat clusters een status krijgen waarin fase 3 is mislukt.
Als aan het clusterstatusbeleid wordt voldaan, wordt de upgrade beschouwd als geslaagd en gemarkeerd als voltooid. Dit kan gebeuren tijdens de eerste upgrade of een van de upgrades die in deze fase opnieuw worden uitgevoerd. Er is geen e-mailbevestiging van een geslaagde uitvoering.
Aangepast beleid voor handmatige upgrades
U kunt aangepast beleid opgeven voor handmatige clusterupgrades. Deze beleidsregels worden toegepast telkens wanneer u een nieuwe runtimeversie 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
Buiten het upgraden van de runtime zijn er een aantal andere acties die u mogelijk moet uitvoeren om uw cluster up-to-date te houden, waaronder het 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 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 resource-eigenschappen van de Load Balancer te wijzigen die zijn gekoppeld aan het knooppunttype. U kunt Azure Portal gebruiken of u kunt PowerShell/Azure CLI gebruiken. Lees open toepassingspoorten 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 ofHD'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 plaatsingsbeperkingen.
Metrische capaciteitsgegevens toevoegen
Voor elk van de knooppunttypen kunt u metrische gegevens voor aangepaste capaciteit toevoegen die u in uw toepassingen wilt gebruiken om de belasting te rapporteren. Raadpleeg de Documenten van Service Fabric-clusterbronbeheer over het beschrijven van uw cluster en metrische gegevens en belasting voor meer informatie over het gebruik van metrische capaciteitsgegevens voor het rapporteren van belasting.
Instellingen voor uw cluster aanpassen
Veel verschillende configuratie-instellingen kunnen worden aangepast op een cluster, zoals het betrouwbaarheidsniveau van het cluster- en knooppunteigenschappen. Lees de infrastructuurinstellingen voor Service Fabric-clusters voor meer informatie.
Installatiekopieën van het besturingssysteem voor clusterknooppunten bijwerken
Het inschakelen van automatische upgrades van installatiekopieën van het besturingssysteem voor uw Service Fabric-clusterknooppunten is een best practice. Hiervoor zijn er verschillende clustervereisten en stappen die moeten worden uitgevoerd. Een andere optie is het gebruik van Patch Orchestration Application (POA), een Service Fabric-toepassing waarmee patches van besturingssystemen op een Service Fabric-cluster zonder uitvaltijd worden geautomatiseerd. Zie Patch het Windows-besturingssysteem in uw Service Fabric-cluster voor meer informatie over deze opties.