Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
In deze handleiding wordt beschreven waar u rekening mee moet houden wanneer u een bestaande traditionele WebSphere Application Server-toepassing (WAS) wilt migreren om te worden uitgevoerd op virtuele Azure-machines. Zie Wat zijn oplossingen om de IBM WebSphere-productfamilie uit te voeren in Azure? voor een overzicht van beschikbare traditionele WAS-oplossingen in Azure Marketplace.
Premigratie
Voltooi voordat u begint de evaluatie- en inventarisstappen die in de volgende secties worden beschreven om een geslaagde migratie te garanderen.
Definieer wat u bedoelt met een voltooide migratie
Deze handleiding en de bijbehorende Azure Marketplace-aanbiedingen zijn een startpunt om de migratie van uw traditionele WAS-workloads naar Azure te versnellen. Het is belangrijk om het bereik van uw migratie-inspanning te definiëren. Gaat u bijvoorbeeld een strikte lift-and-shift uitvoeren van uw bestaande infrastructuur naar Azure Virtuele Machines? Als dat het geval is, komt u misschien in de verleiding om tijdens het migreren wat 'lift and improve'-verbeteringen door te voeren.
Het is beter om zo dicht mogelijk bij een zuivere 'lift-and-shift'-aanpak te blijven, met inachtneming van de noodzakelijke wijzigingen zoals beschreven in deze handleiding. Definieer wat u bedoelt met een voltooide migratie zodat u weet wanneer u deze mijlpaal hebt bereikt. Wanneer u de status 'migratie voltooid' hebt bereikt, kunt u een momentopname van uw virtuele machines maken, zoals beschreven in Een momentopname van een virtuele harde schijf maken. Nadat u hebt geverifieerd dat u met succes kunt herstellen vanuit uw momentopname, kunt u de verbeteringen uitvoeren zonder dat u bang bent dat de migratievoortgang verloren gaat die u tot nu toe hebt bereikt.
Zorg ervoor dat het doel het juiste doel is voor uw migratie-inspanning
De eerste stap bij een geslaagde migratie van een WAS-toepassing naar Azure is het selecteren van het meest geschikte migratiedoel.
WAS is traditioneel goed uitgevoerd op virtuele Azure-machines. Het doel van de virtuele machine (VM) is de eenvoudigste keuze, omdat deze het meest lijkt op een on-premises implementatie. De beheer- en implementatie-ervaring voor virtuele machines is vergelijkbaar met wat u on-premises hebt.
Een andere optie is om naar containers te migreren door traditionele WAS-werkbelasting te converteren naar toepassingscontainers. U kunt het containerdoel uitvoeren op Azure Kubernetes Service (AKS) en Azure Red Hat OpenShift. De keerzijde van dit gemak zijn de economische kosten.
Over het algemeen zijn de kosten per minuut voor een vm-oplossing hoger in vergelijking met containers. Hoewel een oplossing op basis van containers goedkoper is in gebruik, moet u uw applicatie afstemmen op de vereisten van het containerorkestratieplatform.
Als het minimaliseren van de wijziging de belangrijkste factor is voor uw migratie-inspanning, kunt u een migratie op basis van een VM overwegen. Zie in dit geval WebSphere-toepassingen naar Azure Virtuele Machines migreren.
Als u het converteren van uw toepassing tolereert om te worden uitgevoerd binnen containers om de runtimekosten te verlagen, kunt u een migratie op basis van AKS of Azure Red Hat OpenShift overwegen.
Voor migratie op basis van AKS kunt u de gratis laag gaan gebruiken. Ontvang gratis clusterbeheer en betaal alleen voor de virtuele machines, gekoppelde opslag en netwerkresources die worden gebruikt. Zie in dit geval WebSphere-toepassingen migreren naar Azure Kubernetes Service.
Voor migratie op basis van Azure Red Hat OpenShift, naast de kosten voor reken- en infrastructuur, hebben toepassingsknooppunten nog een andere kosten voor het OpenShift-licentieonderdeel. Deze kosten worden gefactureerd op basis van het aantal toepassingsknooppunten en het exemplaartype. Gebruik prijzen op aanvraag of gereserveerde instanties, afhankelijk van de behoeften van uw workload en bedrijf. In dit geval raadpleegt u WebSphere-toepassingen migreren naar Azure Red Hat OpenShift.
De handleidingen in de Documentatie van Azure Red Hat OpenShift hebben betrekking op enkele aspecten die relevant zijn voor migratie. Zie de documentatie voor Azure Red Hat OpenShift voor de volledige lijst met handleidingen.
Bepalen of de vooraf gemaakte Azure Marketplace-aanbiedingen een goed uitgangspunt zijn
IBM en Microsoft hebben samengewerkt om een set Azure-oplossingssjablonen naar Azure Marketplace te brengen om een solide uitgangspunt te bieden voor migratie naar Azure. Zie voor de lijst met aanbiedingen De WebSphere-productfamilie en Liberty uitvoeren op Microsoft Azure en kies vervolgens de aanbieding die het meest overeenkomt met uw bestaande implementatie. U kunt de lijst met aanbiedingen bekijken in het overzichtsartikel Wat zijn oplossingen om de IBM WebSphere-productfamilie uit te voeren op Azure?
Als geen van de bestaande aanbiedingen een goed uitgangspunt is, moet u de implementatie handmatig reproduceren met behulp van Azure Virtual Machine-resources. U vindt de stap-voor-stap-handleiding in Zelfstudie: IBM WebSphere Application Server Network Deployment traditional handmatig installeren op Azure Virtuele Machines. Zie Wat is IaaS? voor meer informatie.
Bepalen of de traditionele WAS-versie compatibel is
Uw bestaande traditionele WAS-versie moet compatibel zijn met de versie in de IaaS-aanbiedingen. U vindt de versie-informatie op de overzichtspagina van IBM WebSphere Application Server Single Instance op Azure VM en IBM WebSphere Application Server Cluster op Azure-VM's. Als uw bestaande traditionele WAS-versie niet compatibel is met die versie, moet u de implementatie handmatig reproduceren met behulp van Azure IaaS-resources. Zie Wat is IaaS? voor meer informatie.
Servercapaciteit inventariseren
Documenteer de hardware (geheugen, CPU, schijf) van de huidige productieserver(s), evenals het gemiddelde aantal en piekaantal aanvragen en het resourcegebruik. Deze informatie wordt gebruikt om de VM-grootte te bepalen. Zie Grootten voor Cloud Services voor meer informatie.
Alle geheimen inventariseren
Voor de ontwikkeling van 'configuratie als een service'-technologieën zoals Azure Key Vault, was er geen goed gedefinieerd concept voor 'geheimen'. In plaats daarvan had u een set uiteenlopende configuratie-instellingen die functioneerden als wat we nu 'geheimen' noemen. Met app-servers zoals WAS bevinden deze geheimen zich in veel verschillende configuratiebestanden en configuratiearchieven. Controleer alle eigenschaps- en configuratiebestanden op de productieserver(s) op geheimen en wachtwoorden. Mogelijk bevinden zich ook in uw toepassing configuratiebestanden met wachtwoorden of referenties. WAS slaat configuratiegegevens op in verschillende documenten in een trapsgewijze hiërarchie van mappen. De meeste configuratiedocumenten hebben XML-inhoud. Zie Configuratiedocumenten en Azure Key Vault-basisconcepten voor meer informatie.
Alle certificaten inventariseren
Documenteer alle certificaten die worden gebruikt voor openbare SSL-eindpunten. U kunt alle certificaten op de productieserver(s) weergeven door de volgende opdracht uit te voeren:
keytool -list -v -keystore <path to keystore>
Zie voor meer informatie het IBM-document Certificaatbeheer in SSL
Controleren of de ondersteunde Java-versie goed werkt
Voor het gebruik van WAS op Azure Virtuele Machines is een specifieke versie van Java vereist. U moet dus controleren of uw toepassing correct wordt uitgevoerd met die ondersteunde versie.
IBM Java 8 wordt geleverd met de WAS9-distributie. U wordt aangeraden de door IBM geleverde Java JRE te gebruiken. Zie Java SE 8 in WebSphere Application Server traditional V9 voor meer informatie.
Als u wilt overschakelen naar een andere Java SDK, raadpleegt u het IBM-document Overschakelen naar de Java SDK in WebSphere Application Server.
JNDI-resources inventariseren
Inventariseer alle JNDI-resources. Gegevensbronnen zoals databases kunnen bijvoorbeeld een bijbehorende JNDI-naam hebben waarmee JPA exemplaren van correct aan een specifieke database kan binden. Voor meer informatie over JNDI-resources en databases, zie WebSphere Data Sources in de IBM-documentatie. Andere JNDI-gerelateerde resources, zoals JMS-berichtenbrokers, moeten mogelijk worden gemigreerd of opnieuw worden geconfigureerd. Zie JMS-resources gebruiken voor meer informatie over JMS-configuratie.
Uw profielconfiguratie controleren
De belangrijkste configuratie-eenheid in WAS is het profiel. Als zodanig bevat het resources.xml-bestand een schat aan configuraties die u zorgvuldig moet overwegen voor migratie. Het bestand bevat verwijzingen naar meer XML-bestanden die zijn opgeslagen in submappen. IBM adviseert dat u normaal gesproken de IBM-console moet gebruiken om de beheerbare objecten en services van WAS te configureren en WAS de map met profielen/profielnamen te laten onderhouden. Raadpleeg voor meer informatie Profielen beheren voor gedistribueerde systemen en IBM i-besturingssystemen.
Binnen uw toepassing
Inspecteer het deployment.xml-bestand en/of het WEB-INF-/web.xml-bestand .
Bepalen of sessiereplicatie wordt gebruikt
Als uw toepassing afhankelijk is van sessiereplicatie, hebt u de volgende opties:
- Voor HTTP-sessies kunt u, afhankelijk van het niveau van sessiebeheer, geheugen of een database gebruiken om sessiegegevens op te slaan.
- Voor gedistribueerde sessies kunt u sessies in een database opslaan met behulp van sessiepersistentie in de database.
- Voor Dynamic cache kunt u sessiegegevens beheren met behulp van geheugen-naar-geheugenreplicatie of in een database.
- Herstructureer uw toepassing om een database te gebruiken voor sessiebeheer.
- Herstructureer uw toepassing om de sessie te externaliseren naar Azure Redis Service. Zie Azure Cache voor Redis voor meer informatie.
Voor al deze opties is het een goed idee om te leren hoe WAS http-sessiestatusreplicatie doet. Zie Sessiebeans beheren in de IBM-documentatie voor meer informatie.
Gegevensbronnen documenteren
Als uw toepassing gebruikmaakt van databases, moet u de volgende informatie vastleggen:
- Wat is de naam van de gegevensbron?
- Wat is de configuratie van de verbindingsgroep?
- Waar vind ik het JAR-bestand van het JDBC-stuurprogramma?
Voor meer informatie over JDBC-stuurprogramma's in WAS, zie JDBC-stuurprogramma's gebruiken met WebSphere Application Server.
Bepalen of WAS is aangepast
Bepaal welke van de volgende aanpassingen zijn uitgevoerd en leg vast wat er is gebeurd.
- Zijn de opstartscripts gewijzigd? Dergelijke scripts omvatten wsadmin, AdminControl, AdminConfig, AdminApp en AdminTask.
- Zijn er specifieke parameters aan de JVM doorgegeven?
- Zijn er JAR's toegevoegd aan het classpath van de server?
- Zijn OS-voorzieningen zoals gebruikt om ervoor te zorgen dat WAS-componenten automatisch worden gestart na een serverherstart?
U moet rekening houden met migratieoverwegingen, afhankelijk van de antwoorden op deze vragen.
Bepaal of een on-premisesverbinding nodig is
Als voor uw toepassing toegang nodig is tot een van uw on-premises services, moet u een van de connectiviteitsservices van Azure inrichten. Zie Een on-premises netwerk verbinden met Azure voor meer informatie. Als alternatief moet u uw toepassing herstructureren zodat deze gebruikmaakt van openbaar beschikbare API's die door uw on-premises resources beschikbaar worden gesteld.
Bepalen of Java Message Service-wachtrijen (JMS) of -onderwerpen in gebruik zijn
Als uw toepassing JMS-wachtrijen of onderwerpen gebruikt, moet u deze migreren naar een extern gehoste JMS-server. Een strategie voor degenen die JMS gebruiken, is het gebruik van Azure Service Bus en het Advanced Message Queuing Protocol. Zie Java Message Service 1.1 gebruiken met Azure Service Bus Standard en AMQP 1.0 voor meer informatie.
Als u permanente JMS-archieven hebt geconfigureerd, moet u de configuratie vastleggen en toepassen na de migratie.
Als u IBM MQ gebruikt, kunt u deze software migreren naar Azure Virtuele Machines en deze als zodanig gebruiken.
Microsoft heeft een oplossing voor het integreren van IBM MQ met Logic Apps. Zie Verbinding maken met een IBM MQ-server vanuit een werkstroom in Azure Logic Apps voor meer informatie.
Bepalen of u uw eigen aangepaste, gedeelde Java EE-bibliotheken gebruikt
Als u de functie Gedeelde Java EE-bibliotheek gebruikt, hebt u twee opties:
- Herstructureer uw toepassingscode om alle afhankelijkheden van uw bibliotheken te verwijderen en de functionaliteit in plaats daarvan rechtstreeks in uw toepassing op te nemen.
- Voeg de bibliotheken toe aan het klassepad van de server.
Bepalen of OSGi-bundels worden gebruikt
Als u OSGi-bundels hebt gebruikt die zijn toegevoegd aan de WAS, moet u de equivalente JAR-bestanden rechtstreeks toevoegen aan uw webtoepassing.
Bepalen of uw toepassing code bevat die specifiek is voor het besturingssysteem
Als uw toepassing code bevat met afhankelijkheden van het host-besturingssysteem, moet u deze herstructureren om deze afhankelijkheden te verwijderen. U moet bijvoorbeeld elk gebruik van of in bestandssysteempaden vervangen door of als uw toepassing op Windows wordt uitgevoerd.
Bepalen of IBM Integration Bus wordt gebruikt
Als uw toepassing IBM Integration Bus gebruikt, moet u vastleggen hoe IBM Integration Bus is geconfigureerd. Zie voor meer informatie IBM Integration Bus-documentatie.
Bepalen of uw toepassing bestaat uit meerdere WAR's
Als uw toepassing bestaat uit meerdere WAR's, moet u deze allemaal behandelen als afzonderlijke toepassingen en deze handleiding voor al deze WAR's doorlopen.
Bepalen of uw toepassing is verpakt als een EAR
Als uw toepassing is verpakt als een EAR-bestand, moet u de bestanden application.xml, ibm-application-bnd.xmi en ibm-application-ext.xmi bekijken en hun configuraties vastleggen. Zie Het enterprise archivepakket (EAR) bouwen op WebSphere voor meer informatie.
Alle externe processen en daemons identificeren die worden uitgevoerd op de productieservers
U moet alle processen die buiten de toepassingsserver worden uitgevoerd, zoals controledaemons, verwijderen of naar een andere locatie migreren.
Nagaan of en hoe het bestandssysteem wordt gebruikt
VM-bestandssystemen werken op dezelfde manier als on-premises bestandssystemen met betrekking tot persistentie, opstarten en afsluiten. Het is ook belangrijk om rekening te houden met de behoeften van uw bestandssysteem en om ervoor te zorgen dat de opslagruimte en prestaties van de VM's voldoende zijn.
Statische inhoud met alleen-leestoegang
Als uw toepassing momenteel statische inhoud bedient, hebt u een alternatieve locatie nodig. Overweeg om statische inhoud te verplaatsen naar Azure Blob Storage en Azure Front Door toe te voegen voor snelle downloads wereldwijd. Zie statische websitehosting in Azure Storage en Een Azure Storage-account integreren met Azure Front Doorvoor meer informatie.
De netwerktopologie bepalen
De huidige set Azure Marketplace-aanbiedingen is een startpunt voor uw migratie. Als de aanbieding niet betrekking heeft op aspecten van uw architectuur die u moet migreren, moet u de netwerktopologie van uw bestaande implementatie vastleggen. Vervolgens moet u die netwerktopologie in Azure reproduceren, zelfs nadat u de basisaanbieding met een van de oplossingssjablonen hebt opgesteld.
Netwerktopologie is een breed onderwerp, maar de volgende verwijzingen kunnen enkele richting geven aan uw migratie-inspanningen:
- Omdat gegevensbronnen afzonderlijke servers in een WAS-systeem zijn, moet u deze beschouwen als onderdeel van de netwerktopologieanalyse. Zie WebSphere Application Server Data Sources voor meer informatie.
- Bronservers voor berichten zijn ook afzonderlijke servers. Zie Netwerktopologieën: Interoperabiliteit met behulp van de WebSphere MQ-berichtenprovider voor meer informatie.
- Taakverdeling is een fundamentele vereiste. De volgende referentie behandelt de WAS-kant van taakverdeling: WebSphere Application Server Network Deployment load-balanced clustering.
Houd rekening met het gebruik van JCA-adapters en resource-adapters
Als uw bestaande toepassing gebruikmaakt van JCA-adapters of andere resourceadapters om verbinding te maken met andere bedrijfssystemen, moet u ervoor zorgen dat u de configuratie voor deze artefacten toepast op de WAS die wordt uitgevoerd in virtuele Azure-machines. Voor meer informatie, zie Relationele resourceadapters en JCA in de IBM-documentatie.
Account voor verificatie en autorisatie
De meeste toepassingen hebben een soort verificatie en autorisatie. Als u OpenID gebruikt voor verificatie, kunt u OpenID-verbindingsverificatie configureren met Microsoft Entra-id. Zie OpenID Connect-verificatie met Microsoft Entra ID voor meer informatie.
Bepalen of WAS-clustering wordt gebruikt
Waarschijnlijk hebt u uw toepassing geïmplementeerd op meerdere WAS-servers om hoge beschikbaarheid te bereiken. U kunt deze clusters rechtstreeks vanuit uw on-premises installatie migreren naar WAS die wordt uitgevoerd in Azure Virtuele Machines. Zie WebSphere Application Server Network Deployment in de IBM-documentatie voor meer informatie.
Houd rekening met vereisten voor taakverdeling
Taakverdeling is een essentieel onderdeel van het migreren van uw WAS-cluster naar Azure. De eenvoudigste oplossing is om gebruik te maken van de ingebouwde ondersteuning voor Azure Application Gateway of IBM HTTP Server die wordt geboden in de Azure Marketplace-aanbieding voor IBM WebSphere Application Server-cluster.
Zie Load-balancing options voor een overzicht van de mogelijkheden van Azure Application Gateway in vergelijking met andere Azure-oplossingen voor taakverdeling.
Bepalen of de functie Java EE Application Client wordt gebruikt
Als uw toepassing gebruikmaakt van de functie Java EE Application Client, moet deze ongewijzigd blijven werken na de migratie naar Azure Virtuele Machines. Zie Java EE-clienttoepassingsmodules gebruiken voor meer informatie.
Migratie
Selecteer een aanbieding voor WAS traditional op Azure Virtuele Machines
De volgende aanbiedingen zijn beschikbaar voor WAS op virtuele Azure-machines.
Tijdens de implementatie van een aanbieding wordt u gevraagd om de grootte van de virtuele machine voor uw WAS-knooppunten te kiezen. Het is belangrijk om alle aspecten van de grootte (geheugen, processor, schijf) bij uw keuze voor de VM-grootte te betrekken. Zie Grootten voor Cloud Services (klassiek) voor meer informatie.
IBM WebSphere Application Server Single Instance op een Azure-VM
Met deze aanbieding worden de meeste standaardstappen geautomatiseerd voor het inrichten van één WebSphere-exemplaar op een virtuele Azure-machine. Er wordt een toepassingsserverprofiel gemaakt met de WAS-beheerconsole.
Cluster van IBM WebSphere Application Server op Azure-VM's
Met deze aanbieding worden de meeste standaardstappen geautomatiseerd voor het inrichten van een WebSphere-cluster op Azure-VM's. Er wordt een implementatiebeheerder gemaakt met de WAS-beheerconsole op een Virtuele Azure-machine en het vereiste aantal knooppuntagents op gescheiden Azure-VM's.
De aanbieding inrichten
Nadat u hebt gekozen met welke aanbieding u wilt beginnen, implementeert u die aanbieding door de instructies in WebSphere Application Server-cluster (traditioneel) implementeren op virtuele Azure-machines te volgen.
De profielen migreren
Nadat u de aanbieding hebt ingericht, kunt u de profielconfiguratie bekijken. Zie voor meer informatie Profielconcepten in de IBM-documentatie.
De databases verbinden
Nadat u de profielen hebt gemigreerd, verbindt u de databases door de instructies te volgen in het configureren van de gegevensbron WebSphere Application Server in de IBM-documentatie.
Account voor keystores
U moet rekening houden met de migratie van SSL-sleutelarchieven die door uw toepassing worden gebruikt. Zie Keystore-configuraties voor SSL in de IBM-documentatie voor meer informatie.
Verbind de JMS-bronnen
Nadat u de databases hebt verbonden, configureert u JMS door de instructies te volgen in het instellen van JMS in IBM WebSphere Application Server in de IBM-documentatie.
Account voor verificatie en autorisatie
De meeste toepassingen hebben een soort verificatie en autorisatie. Als u OpenID gebruikt voor verificatie, kunt u OpenID-verbindingsverificatie configureren met Microsoft Entra-id. Zie OpenID Connect-verificatie met Microsoft Entra ID voor meer informatie.
Account voor logregistratie
U kunt Elastic Stack configureren door de instructies te volgen in WebSphere Application Server-logboeken analyseren met Elastic Stack in de IBM-documentatie. Azure biedt ondersteuning voor Elastic. Zie Wat is Elastic-integratie met Azure? voor meer informatie. U kunt de informatie uit deze twee bronnen combineren om een voor Azure geoptimaliseerde oplossing voor logboekregistratie voor WAS op VM's te realiseren.
Uw toepassingen migreren
De technieken die worden gebruikt om toepassingen van het ontwikkelteam in de test-, faserings- en productieservers te implementeren variëren sterk per geval. In sommige gevallen is er een zeer ontwikkeld CI/CD-platform dat ertoe leidt dat de toepassingen worden geïmplementeerd op de WebSphere-toepassingsserver. In andere gevallen kan het proces meer handmatig zijn. Een voordeel van het gebruik van virtuele Azure-machines om traditionele toepassingen naar de cloud te migreren, is dat uw bestaande processen blijven werken.
U moet de netwerkbeveiligingsgroep die door de aanbieding wordt ingericht zodanig configureren dat toegang vanuit uw CI/CD-pijplijn of systeem voor handmatige implementatie wordt toegestaan. Zie Netwerkbeveiligingsgroepen voor meer informatie.
Testen
U moet in-containertests configureren voor toepassingen om toegang te krijgen tot de nieuwe servers die worden uitgevoerd in Azure. Net als bij de problemen met CI/CD moet u ervoor zorgen dat uw tests toegang hebben tot de toepassingen die zijn geïmplementeerd in Azure. Zie Netwerkbeveiligingsgroepen voor meer informatie.
Postmigratie
Zodra u de migratiedoelstellingen hebt bereikt die u in de stap pre-migratie hebt gedefinieerd, voert u end-to-endacceptatietests uit om te controleren of alles werkt zoals verwacht. Zie de volgende aanbevelingen voor hulp bij een aantal mogelijke verbeteringen na de migratie:
Gebruik Azure Storage om statische inhoud te leveren die is gekoppeld aan de virtuele machines. Zie Een gegevensschijf koppelen aan of loskoppelen van een virtuele labmachine in Azure DevTest Labs voor meer informatie.
Implementeer uw toepassingen in uw gemigreerde WAS-cluster met Azure DevOps. Zie Aan de slag met de documentatie voor Azure DevOps voor meer informatie.
Als u WAS traditioneel hebt geïmplementeerd met Azure-toepassing Gateway, wilt u mogelijk meer configuratie uitvoeren op de Application Gateway. Zie Application Gateway-configuratieoverzicht voor meer informatie.
Uw netwerktopologie verbeteren met geavanceerde taakverdelingsservices. Zie Services voor taakverdeling gebruiken in Azure voor meer informatie.
Azure Managed Identities gebruiken om beheerde geheimen te beheren en op rollen gebaseerde toegang tot Azure-resources toe te wijzen. Zie Wat zijn beheerde identiteiten voor Azure-resources? voor meer informatie.
Integreer WAS Java EE-verificatie en -autorisatie met Microsoft Entra ID. Zie de handleiding Aan de slag met het integreren van Microsoft Entra ID met toepassingen voor meer informatie.
Azure Key Vault gebruiken om informatie op te slaan die fungeert als geheim. Zie Basisconcepten van Azure Key Vault voor meer informatie.