Architectuur voor werklast bepalen vóór migratie

In dit artikel worden het proces en de overwegingen beschreven voor het ontwerpen van de beoogde gemigreerde status van een workload in de cloud. In het artikel worden activiteiten besproken die deel uitmaken van het definiëren van de architectuur van een workload binnen een iteratie.

Het artikel over incrementele rationalisering geeft aan dat sommige architectuurveronderstellingen deel uitmaken van een bedrijfstransformatie die een migratie omvat. In dit artikel worden typische veronderstellingen verduidelijkt. Het wijst ook op een aantal obstakels die u kunt vermijden en identificeert kansen om bedrijfswaarde te versnellen door uitdagende architectuurveronderstellingen. Dit incrementele model voor het ontwerpen van architectuur helpt teams sneller te bewegen en sneller bedrijfsresultaten te verkrijgen.

Basisarchitectuurontwerp op basis van algemene veronderstellingen

De volgende veronderstellingen zijn typisch voor elke migratie-inspanning:

• Ga uit van een Infrastructure as a Service (IaaS)-workload. Het migreren van workloads omvat voornamelijk het verplaatsen van servers van een fysiek datacenter naar een clouddatacenter via een IaaS-migratie. Het proces vereist doorgaans minimale herontwikkeling of herconfiguratie. Deze benadering wordt een lift-en-shift- migratie genoemd.
• Houd de architectuur consistent. Het aanbrengen van wijzigingen in de kernarchitectuur tijdens een migratie neemt de complexiteit aanzienlijk toe. Het opsporen van fouten in een gewijzigd systeem op een nieuw platform introduceert veel variabelen die moeilijk te isoleren zijn. Workloads moeten alleen kleine wijzigingen ondergaan tijdens de migratie en eventuele wijzigingen moeten grondig worden getest.
• Plan om het formaat van assetste wijzigen. Stel dat slechts enkele on-premises assets alle resources volledig gebruiken. Vóór of tijdens de migratie worden assets aangepast aan de werkelijke gebruiksvereisten. Hulpprogramma's zoals Azure Migrate en Modernize bieden groottebepaling op basis van daadwerkelijk gebruik.
• Vereisten voor bedrijfscontinuïteit en herstel na noodgevallen (BCDR) vastleggen. Als u een overeengekomen SLA (Service Level Agreement) hebt voor de workload die al met het bedrijf is onderhandeld, kunt u de SLA blijven gebruiken na de migratie naar Azure. Als er nog geen SLA is ingesteld, definieert u er een voordat u de workload in de cloud ontwerpt om ervoor te zorgen dat u op de juiste manier ontwerpt.
• Migratie-downtime plannen. Net als het niet voldoen aan de SLA-vereisten, kan downtime die optreedt wanneer u een workload naar productie promovt, een nadelig effect hebben op het bedrijf. Soms hebben oplossingen die met minimale downtime moeten overgaan architectuurwijzigingen nodig. Voordat u met de releaseplanning begint, wordt ervan uitgegaan dat er een algemeen begrip is van de downtimevereisten.
• Gebruikers- en toepassingsverkeerspatronen definiëren. Bestaande oplossingen kunnen afhankelijk zijn van bestaande netwerkrouteringspatronen en -oplossingen. Identificeer de resources die u nodig hebt om het huidige netwerkgebruik te ondersteunen.
• Plan om netwerkconflictente voorkomen. Wanneer u datacenters samenvoegt in één cloudprovider, maakt u waarschijnlijk conflicten in Domain Name System (DNS) of andere netwerkstructuren. Tijdens de migratie is het belangrijk om deze conflicten te vermijden om onderbrekingen in productiesystemen te voorkomen die worden gehost in de cloud.
• Plan voor routeringstabellen. Zorg ervoor dat uw project een plan bevat voor het wijzigen van routeringstabellen als u netwerken of datacenters samenbrengt. Overweeg routeringsvereisten voor meerdere datacenters.

Ontwerparchitectuur voor een landingszone

In de fase Gereed van het Cloud Adoption Framework heeft uw organisatie gedeelde platformservices geïmplementeerd als onderdeel van het aannemen van Azure-landingszones. In Uw landingszone voorbereiden voor migratie, hebt u de landingszone voorbereid om gemigreerde workloads te ontvangen.

Op basis van deze planning kunt u ervan uitgaan dat de volgende migratieonderdelen aanwezig zijn:

• Hybride connectiviteit verbindt uw Azure-netwerken met uw on-premises netwerken.
• Netwerkbeveiligingsapparaten zoals Azure Firewall verwerken de inspectie van verkeer buiten uw workload.
• Azure-beleid om governanceprocessen af te dwingen, zoals logboekvereisten, toegestane regio's, uitgesloten services en andere besturingselementen, zijn actief.
• Een Werkruimte voor Azure Monitor-logboeken voor gedeelde logboeken is ingesteld in Azure Monitor.
• Gedeelde identiteitsbronnen ter ondersteuning van servers die lid zijn van een domein of andere identiteitsbehoeften zijn tot stand gebracht.

Als deze essentiële elementen voor migratie niet zijn vastgesteld, moet uw organisatie onmiddellijk terugkeren naar de gereed-fase om aan deze eisen te voldoen. Zonder deze onderdelen heeft uw migratie waarschijnlijk vertragingen en terugval en is deze minder succesvol.

De workload die u ontwerpt, heeft een abonnement toegewezen, in het ideale instantie via een verkoopproces voor abonnementen. Het abonnement kan meerdere werkbelastingen of slechts één werkbelasting bevatten, afhankelijk van de manier waarop uw organisatie de resourceorganisatie voor werkbelastingenheeft voltooid. Als u een workload migreert met veel toepassingsomgevingen, hebt u mogelijk zelfs meerdere abonnementen op basis van de richtlijnen voor toepassingsomgevingen.

Ontwerp netwerkarchitectuur voor werklasten

Plannen om toepassingsspecifieke resources in een specifiek abonnement te specificeren en te implementeren en plannen om een speciaal virtueel netwerk voor de werklast te ontwerpen. Zie de richtlijnen voor het ontwerpen van uw netwerkarchitectuurvoor meer informatie. U moet zich vooral richten op het segmenteren van virtuele netwerken.

Uw netwerk heeft waarschijnlijk resources nodig, zoals load balancers en andere resources voor het leveren van toepassingen. U kunt de architectuurhandleiding voor N-laag gebruiken om deze resources in Azure te plannen.

Werkbelastingafhankelijkheden ontwerpen

Uw hulpprogramma's voor migratieevaluatie moeten u een manier bieden om afhankelijkheidsanalyse uit te voeren, zoals afhankelijkheidsanalyse in Azure Migrate en moderniseren. Het hulpprogramma helpt u bij het identificeren van onderlinge afhankelijkheden tussen servers.

Naast het plannen van architectuur voor de workload zelf, moet u mogelijk rekening houden met afhankelijkheden tussen workloads. Sommige workloads hebben bijvoorbeeld vaak communicatie nodig. Zo ja, dan helpt het plannen van uw migratiegolven en afhankelijkheden om rekening te houden met deze vereiste uw migratie succesvol te maken.

U kunt richtlijnen gebruiken in Azure Architecture Center, zoals voor spoke-to-spoke-netwerken netwerken, om te ontwerpen hoe onderling verbonden workloads werken na de migratie.

Voorbereiden op het aannemen van confidential computing

Een subset van uw workloads met vereisten voor soevereiniteit kan leiden tot het gebruik van vertrouwelijke computing. Als onderdeel van een implementatie van een onafhankelijke landingszone worden beheergroepen voor vertrouwelijke computing gemaakt.

Binnen een soevereiniteitscontext vereist het gebruik van confidential computing Azure Key Vault en door de klant beheerde sleutels als ondersteunende service. Zie versleuteling met door de klant beheerde sleutels in Microsoft Cloud for Sovereigntyvoor meer informatie.

Uw eerste cloudraming bijwerken

Wanneer u klaar bent met het ontwerp van uw architectuur, gaat u opnieuw naar uw cloudschatting om ervoor te zorgen dat u zich nog steeds binnen het geplande budget bevindt. Wanneer u ondersteunende services zoals load balancers of back-ups toevoegt, kunnen de kosten veranderen. Hoewel u hulpprogramma's zoals business cases in Azure Migrate en Modernize kunt gebruiken om gedetailleerde kostenbeheeroefeningen uit te voeren, moet u uw schattingen regelmatig opnieuw bekijken wanneer u uw architectuurontwerp aanpast.

Als u bekend bent met traditionele IT-inkoopprocessen, lijkt het schatten van resources in de cloud misschien vreemd. Wanneer u cloudtechnologieën gebruikt, verschuift de overname van een star, gestructureerd kapitaalkostenmodel naar een vloeiend operationeel onkostenmodel. Het plannen van een migratie naar de cloud is vaak de eerste keer dat een organisatie of IT-team deze wijziging tegenkomt.

In het traditionele kapitaalkostenmodel probeert een IT-team de aanschafkracht voor meerdere workloads in verschillende programma's te combineren. Deze aanpak centraliseert een groep gedeelde IT-assets die elk van deze oplossingen kunnen ondersteunen. In het cloudmodel voor operationele onkosten kunnen kosten rechtstreeks worden toegeschreven aan de ondersteuningsbehoeften van afzonderlijke workloads, teams of bedrijfseenheden. Het geeft een organisatie een directere toewijzing van kosten aan interne klanten en de bedrijfsdoelstellingen die ze ondersteunen. Deze dynamischere benadering van financieel beheer wordt vaak FinOps genoemd. Hoewel FinOps geen specifieke Azure-overweging is, kan het handig zijn om een uitgebreid begrip van FinOps te hebben. Voor meer informatie, zie Wat is FinOps?.

Wanneer u uw workloadarchitectuur voor migratie ontwerpt, kunt u de prijscalculator gebruiken met uw evaluatiegegevens om inzicht te hebben in de prijs van de hele workload.

Nadat uw workload is gemigreerd, moet u ook blijven werken om de workloadkosten te optimaliseren. Zie De kostenbeheer-discipline verbeterenvoor meer informatie over hoe organisaties hun vaardigheden voor kostenbeheer kunnen ontwikkelen.

Weten wanneer u uw architectuur moet wijzigen

Migraties richten zich meestal op het onderhouden van een bestaande architectuur en het overstappen naar uw cloudplatform. Er zijn echter momenten waarop u uw workload mogelijk opnieuw moet ontwerpen, zelfs voor migratie. Deze lijst bevat voorbeelden van wanneer u mogelijk architectuurwijzigingen moet aanbrengen voordat u migreert:

• Betalen voor technische schuld. Sommige verouderde workloads hebben een grote hoeveelheid technische schuld. Technische schulden kunnen leiden tot langdurige uitdagingen door hostingkosten bij elke cloudprovider te verhogen. Wanneer de technische schuld onnatuurlijk de hostingkosten verhoogt, moet u alternatieve architecturen evalueren.
• Verbeteren van de betrouwbaarheid. Standaardbewerkingsbasislijnen bieden een mate van betrouwbaarheid en herstel in de cloud. Voor sommige workloadteams zijn mogelijk hogere SLA's vereist, wat kan leiden tot wijzigingen in de architectuur.
• workloads met hoge kosten. Tijdens de migratie moet u alle assets optimaliseren om de grootte af te stemmen op het werkelijke gebruik. Voor sommige workloads zijn mogelijk architectuurwijzigingen vereist om specifieke kostenproblemen op te lossen.
• Prestatievereisten. Wanneer de prestaties van workloads rechtstreeks van invloed zijn op het bedrijf, is mogelijk extra architectuuroverwegingen vereist.
• Toepassingen beveiligen. Beveiligingsvereisten worden meestal centraal geïmplementeerd en worden doorgaans toegepast op alle workloads in een portfolio. Sommige workloads hebben mogelijk specifieke beveiligingsvereisten die kunnen leiden tot wijzigingen in de architectuur.

Elk van deze criteria fungeert als een indicator van een mogelijke migratieblokkering. In de meeste gevallen kunt u het criterium aanpakken nadat u de workload hebt gemigreerd door servers met de juiste grootte te wijzigen, nieuwe servers toe te voegen of andere wijzigingen aan te brengen. Als een van deze criteria echter vereist is voordat u een workload migreert, verwijdert u de workload uit de migratiegolf en evalueert u deze afzonderlijk.

De Azure Well-Architected Framework en Azure Well-Architected Review kunnen helpen bij het begeleiden van gesprekken met de technische eigenaar van een specifieke workload, zodat ze alternatieve opties kunnen overwegen voor het implementeren van de workload.

De workload wordt vervolgens geclassificeerd als een herarchitecture of moderniseringsinspanning in uw cloudimplementatieplan. Vanwege de extra tijd die nodig is om een workload opnieuw te ontwerpen, kunt u deze alternatieve migratiepaden voor workloadimplementatie beschouwen als gescheiden van het migratieproces.

Controlelijst voor architectuur

U kunt de volgende controlelijst gebruiken om ervoor te zorgen dat u belangrijke overwegingen met betrekking tot de architectuur behandelt:

• Controleer of uw architectuur voldoet aan SLA's voor beschikbaarheid, herstel na noodgevallen en gegevensherstel.
• Controleer of u netwerksegmentatieprocedures hebt toegepast op uw netwerkontwerp.
• Bevestig dat u hebt gepland voor het bewaken en vastleggen van logboeken.
• Controleer of uw virtuele machines de juiste grootte hebben voor de werkelijke rekentijd die u nodig hebt.
• Controleer of uw schijven de juiste grootte hebben voor de werkelijke grootte en prestaties die u nodig hebt.
• Controleer of u hebt gepland voor taakverdelingsservices als deze nodig zijn. De services kunnen exemplaren van Azure Load Balancer, Azure Application Gateway, Azure Front Door of Azure Traffic Manager bevatten.
• Bevestig dat u de vereisten voor soevereiniteit en confidential computing hebt gepland als deze nodig zijn.

Volgende stap

Migratieworkloads implementeren