Bewerkingen voor bedrijfskritieke workloads in Azure

Net als bij elke toepassing vindt er een wijziging plaats in uw bedrijfskritieke workloads. De toepassing zal zich na verloop van tijd ontwikkelen, sleutels verlopen, patches worden vrijgegeven en meer. Alle wijzigingen en onderhoud moeten worden toegepast met behulp van implementatiepijplijnen. Dit artikel bevat operationele richtlijnen voor het aanbrengen van algemene wijzigingen en updates.

Organisatorische uitlijning is even belangrijk voor bewerkingsprocedures. Het is van cruciaal belang voor het operationele succes van een bedrijfskritieke workload dat de end-to-end verantwoordelijkheden binnen één team vallen, het DevOps-team.

De technische uitvoering moet profiteren van de systeemeigen platformmogelijkheden van Azure en het gebruik van geautomatiseerde Azure Pipelines om wijzigingen in de toepassing, infrastructuur en configuratie te implementeren. Nogmaals, onderhoudstaken moeten worden geautomatiseerd en handmatige taken moeten worden vermeden.

In de volgende secties worden benaderingen beschreven voor het verwerken van verschillende typen wijzigingen.

Toepassingsautomatisering

Continue integratie en continue implementatie (CI/CD) maakt de juiste implementatie en verificatie van bedrijfskritieke workloads mogelijk. CI/CD is de voorkeursbenadering voor het implementeren van wijzigingen in elke omgeving, Dev/Test, productie en andere. Voor bedrijfskritieke workloads moeten de wijzigingen in de volgende sectie resulteren in de implementatie van een volledig nieuwe stempel. De nieuwe stempel moet grondig worden getest als onderdeel van het releaseproces voordat verkeer wordt doorgestuurd naar de stempel via een blauw/groen implementatiestrategie.

In de volgende secties worden wijzigingen beschreven die, indien mogelijk, moeten worden geïmplementeerd via CI/CD.

Toepassingswijzigingen

Alle wijzigingen in de toepassingscode moeten worden geïmplementeerd via CI/CD. De code moet worden gebouwd, linted en getest op regressies. Toepassingsafhankelijkheden, zoals runtime-omgeving of pakketten, moeten worden bewaakt, met updates die zijn geïmplementeerd via CI/CD.

Infrastructuurwijzigingen

Infrastructuur moet als code worden gevormd en ingericht. Deze praktijk wordt meestal 'Infrastructure as Code' (IaC) genoemd. Alle wijzigingen in de IaC moeten worden geïmplementeerd via de CI/CD-pijplijnen. Updates voor de infrastructuur, zoals het patchen van het besturingssysteem, moeten ook worden beheerd via CI/CD-pijplijnen.

Configuratiewijzigingen

Configuratiewijzigingen zijn een veelvoorkomende oorzaak van storingen in toepassingen. Om deze storingen te bestrijden, moet de configuratie voor de toepassing of infrastructuur worden vastgelegd als code. Deze procedure staat bekend als Configuratie als Code (CaC). Wijzigingen in CaC moeten worden uitgerold met behulp van CI/CD-pijplijnen.

Bibliotheek- en SDK-updates

Voor bedrijfskritieke toepassingen is het essentieel dat broncode en afhankelijkheden worden bijgewerkt wanneer er nieuwe versies beschikbaar komen. De aanbevolen aanpak is om te profiteren van het wijzigingsproces voor configuratiebeheer in de opslagplaats voor broncode. Deze moet worden geconfigureerd om automatisch pull-aanvragen te maken voor verschillende afhankelijkheidsupdates, zoals:

• .NET NuGet-pakketten
• JavaScript Node Package Manager-pakketten
• Terraformprovider

Het volgende scenario is een voorbeeld van het automatiseren van bibliotheekupdates met behulp van dependabot- in een GitHub-opslagplaats.

1. Dependabot detecteert updates van bibliotheken en SDK die worden gebruikt in toepassingscode

2. Dependabot werkt de toepassingscode bij in een branch en maakt een pull request (PR) met deze wijzigingen ten opzichte van de hoofdbranch. De PR bevat alle relevante informatie en is klaar voor definitieve beoordeling.

3. Wanneer codebeoordeling en testen zijn voltooid, kan de PR worden samengevoegd met de hoofdbranch.

Voor afhankelijkheden die dependabot niet kan monitoren, zorg ervoor dat u processen hebt om nieuwe releases te detecteren.

Rotaties van sleutels, geheimen en certificaten

Roterende (vernieuwende) sleutels en geheimen moeten een standaardprocedure zijn in elke werkbelasting. Geheimen moeten mogelijk op korte termijn worden gewijzigd nadat ze zijn blootgesteld of regelmatig als een goede beveiligingspraktijk.

Omdat verlopen of ongeldige geheimen storingen kunnen veroorzaken in de toepassing (zie Foutanalyse), is het belangrijk dat u een duidelijk gedefinieerd en bewezen proces hebt. Voor Azure Mission-Critical worden stempels naar verwachting slechts een paar weken bewaard. Daarom vormt het roteren van wachtwoorden van stempelbronnen geen probleem. Als geheimen in één stempel verlopen, blijft de toepassing als geheel functioneren.

Het beheer van geheimen voor toegang tot langlevende wereldwijde resources is echter essentieel. Een opmerkelijk voorbeeld is de Azure Cosmos DB API-sleutels. Als Azure Cosmos DB API-sleutels verlopen, worden alle processen gelijktijdig beïnvloed, wat leidt tot een volledige onderbreking van de toepassing.

De volgende benadering is een essentiële, geteste en gedocumenteerde benadering voor het roteren van Azure Cosmos DB-sleutels zonder dat er downtime is voor services die worden uitgevoerd in Azure Kubernetes Service.

1. Werk stempels bij met secundaire sleutel. Standaard wordt de primaire API-sleutel voor Azure Cosmos DB in elke stempel opgeslagen als geheim in Azure Key Vault. Maak een pull request waarmee de IaC-sjablooncode wordt bijgewerkt die de secundaire Azure Cosmos DB API-sleutel gebruikt. Laat deze wijziging door de normale review- en updateprocedure voor pull-aanvragen gaan om te worden geïmplementeerd als een nieuwe release of als een hotfix.

2. (optioneel) Als de update is geïmplementeerd als hotfix voor een bestaande release, halen de pods na enkele minuten automatisch het nieuwe geheim van Azure Key Vault op. De Azure Cosmos DB-clientcode wordt momenteel echter niet opnieuw geïnitialiseerd met een gewijzigde sleutel. U kunt dit probleem oplossen door alle pods handmatig opnieuw op te starten met behulp van de volgende opdrachten op de clusters:

   kubectl rollout restart deployment/CatalogService-deploy -n workload
   kubectl rollout restart deployment/BackgroundProcessor-deploy -n workload
   kubectl rollout restart deployment/healthservice-deploy -n workload
   

3. Nieuw geïmplementeerde of opnieuw gestarte pods gebruiken nu de secundaire API-sleutel voor de verbinding met Azure Cosmos DB.

4. Zodra alle pods op alle stempels opnieuw zijn opgestart of een nieuwe zegel is geïmplementeerd, genereert u de primaire API-sleutel voor Azure Cosmos DB opnieuw. Hier volgt een voorbeeld voor de opdracht:

   az cosmosdb keys regenerate --key-kind primary --name MyCosmosDBDatabaseAccount --resource-group MyResourceGroup
   

5. Wijzig de IaC-sjabloon om de primaire API-sleutel te gebruiken voor toekomstige implementaties. U kunt ook de secundaire sleutel blijven gebruiken en terugkeren naar de primaire API-sleutel wanneer het tijd is om de secundaire sleutel te vernieuwen.

Waarschuwingen

Waarschuwingen zijn essentieel om te begrijpen of en wanneer er problemen zijn met uw omgeving. Wijzigingen in waarschuwingen en/of actiegroepen moeten worden geïmplementeerd via CI/CD-pijplijnen. Zie Health modeling en waarneembaarheid van bedrijfskritieke workloads in Azurevoor meer informatie over waarschuwingen.

Automatisering

Veel platforms en services die worden uitgevoerd in Azure bieden automatisering voor algemene operationele activiteiten. Deze automatisering omvat automatisch schalen en automatische verwerking van sleutels en certificaten.

Opschalen

Als onderdeel van het toepassingsontwerp moeten de schaalvereisten voor het definiëren van een schaaleenheid voor de stempel als geheel worden bepaald. De afzonderlijke services binnen de stempel moeten kunnen opschalen om aan de vraag tijdens piekuren te voldoen of afschalen om geld of middelen te besparen.

Services die onvoldoende resources hebben, kunnen verschillende bijwerkingen vertonen, waaronder de volgende lijst:

• Een onvoldoende aantal pods dat berichten van een wachtrij/artikel/partitie verwerkt, resulteert in een toenemend aantal niet-verwerkte berichten. Dit resultaat wordt soms ook wel een groeiende wachtrijdiepte genoemd.
• Onvoldoende resources op een Azure Kubernetes Service-knooppunt kunnen ertoe leiden dat pods niet kunnen worden uitgevoerd.
• Het volgende resultaat resulteert in beperkte aanvragen:
  • Onvoldoende aanvraageenheden (RU's) voor Azure Cosmos DB
  • Onvoldoende verwerkingseenheden (VE's) voor Event Hubs Premium of doorvoereenheden (DU's) voor standaard
  • Onvoldoende berichteneenheden (RU's) voor de Service Bus Premium-laag

Profiteer waar mogelijk van functies voor automatisch schalen van de services om ervoor te zorgen dat u voldoende resources hebt om aan de vraag te voldoen. Hieronder vindt u functies voor automatisch schalen die u kunt gebruiken:

• horizontale schaalaanpassing van pods kunt u het aantal pods waarop workloads worden uitgevoerd, verhogen of verlagen, afhankelijk van de vraag.
• Met de automatische schaalaanpassing van AKS-clusters kunt u het aantal knooppunten in het cluster verhogen of verlagen, afhankelijk van de vraag.
• U kunt Azure Event Hubs-doorvoereenheden (standaardniveau) automatisch omhoog schalen
• U kunt berichteneenheden van een Azure Service Bus-naamruimte automatisch bijwerken

Sleutels, geheimen en certificaten beheren

Gebruik waar mogelijk beheerde identiteiten om te voorkomen dat u API-sleutels of geheimen zoals wachtwoorden hoeft te beheren.

Wanneer u sleutels, geheimen of certificaten gebruikt, gebruikt u waar mogelijk systeemeigen platformmogelijkheden van Azure. Hier volgen enkele voorbeelden van deze mogelijkheden op platformniveau:

• Azure Front Door heeft ingebouwde mogelijkheden voor TLS-certificaatbeheer en -verlenging.
• Azure Key Vault biedt ondersteuning voor automatische sleutelrotatie.

Handmatige bewerkingen

Er zijn operationele activiteiten waarvoor handmatige interventie is vereist. Deze processen moeten worden getest.

Onbestelbare berichten

Berichten die niet kunnen worden verwerkt, moeten worden doorgestuurd naar een dead-letter queue, waarvoor een waarschuwing is geconfigureerd. Deze berichten vereisen meestal handmatige tussenkomst om het probleem te begrijpen en te verhelpen. U moet de mogelijkheid ontwikkelen om berichten met dode letters weer te geven, bij te werken en opnieuw af te spelen.

Herstellen van Azure Cosmos DB

Wanneer Azure Cosmos DB-gegevens onbedoeld worden verwijderd, bijgewerkt of beschadigd, moet u een herstelbewerking uitvoeren vanuit een periodieke back-up. Herstellen vanuit een periodieke back-up kan alleen worden uitgevoerd via een ondersteuningsaanvraag. Dit proces moet regelmatig worden gedocumenteerd en getest.

Quotumverhogingen

Azure-abonnementen hebben quotumlimieten. Implementaties kunnen mislukken wanneer deze limieten zijn bereikt. Sommige quota zijn aanpasbaar. Voor aanpasbare quota kunt u een verhoging aanvragen via de pagina Mijn quota's in Azure Portal. Voor niet-aanpasbare quota moet u een ondersteuningsaanvraag indienen. Het ondersteuningsteam van Azure werkt met u mee om een oplossing te vinden.

Belangrijk

Zie Operationele procedures voor bedrijfskritieke workloads in Azure voor overwegingen en aanbevelingen voor operationeel ontwerp.

Bijdragers

Microsoft onderhoudt dit artikel. De volgende inzenders hebben dit artikel geschreven.

Hoofdauteurs:

• Rob Bagby- | Hoofdontwikkelaar Inhoud
• Allen Sudbring- | Senior Content Developer

Meld u aan bij LinkedIn als u niet-openbare LinkedIn-profielen wilt zien.

Volgende stappen

Implementeer de referentie-implementatie om volledig inzicht te krijgen in de resources en de configuratie die in deze architectuur wordt gebruikt.

Implementatie: Mission-Critical Online