Architectuur voor workload ontwerpen 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 veronderstellingen over architectuur deel uitmaken van elke 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 aannames zijn kenmerkend voor alle migratiepogingen:

• Stel dat u een IaaS-workload (Infrastructure as a Service) gebruikt. 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-and-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 brengt veel variabelen met zich mee die moeilijk te isoleren kunnen zijn. Workloads moeten alleen kleine wijzigingen ondergaan tijdens de migratie en eventuele wijzigingen moeten grondig worden getest.
• Plannen om het formaat van assets te 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 de grootte 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.
• Plan uitvaltijd voor migratie. 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 moeten oplossingen die moeten worden overgestapt met minimale downtime architectuurwijzigingen nodig hebben. 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 netwerkconflicten te 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.
• Plannen 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 de overstap naar Azure-landingszones. In Gereed voor de landingszone 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 voor het afdwingen van governanceprocedures zoals logboekregistratievereisten, toegestane regio's, niet-toegestane 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 migratie essentials niet tot stand zijn gebracht, moet uw organisatie onmiddellijk terugkeren naar de fase Gereed om aan deze behoeften 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 abonnementsautomaat proces. Het abonnement kan meerdere workloads of slechts één workload bevatten, afhankelijk van hoe uw organisatie de resourceorganisatie voor workloads heeft voltooid. Als u een workload migreert met veel toepassingsomgevingen, hebt u mogelijk zelfs meerdere abonnementen op basis van de richtlijnen voor toepassingsomgevingen.

Netwerkarchitectuur voor werkbelasting ontwerpen

Plan toepassingsspecifieke resources te implementeren in een specifiek abonnement en plan om een toegewezen virtueel netwerk voor de workload te ontwerpen. Zie de richtlijnen voor het ontwerpen van uw netwerkarchitectuur voor 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-lagen gebruiken om deze resources in Azure te plannen.

Afhankelijkheden van workload 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 van workload-naar-workload. 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 , 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 Sovereignty voor 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 zakelijke cases in Azure Migrate en Moderniseren kunt gebruiken om gedetailleerde oefeningen voor kostenbeheer uit te voeren, moet u regelmatig uw schattingen opnieuw bekijken tijdens het aanpassen van uw architectuurontwerp.

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 financiële activiteiten (FinOps) genoemd. Hoewel FinOps geen specifieke Azure-overweging is, kan het handig zijn om een uitgebreid begrip van FinOps te hebben. Zie Wat is FinOps? voor meer informatie.

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 kostenbeheerdiscipline verbeteren voor 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:

• Technische schulden betalen. Sommige verouderde workloads hebben een grote hoeveelheid technische schulden. 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.
• Betrouwbaarheid verbeteren. 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.
• Hoge kosten voor workloads. 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.
• Beveiligde toepassingen. 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.

Het Azure Well-Architected Framework en Azure Well-Architected Review kunnen helpen bij het begeleiden van gesprekken met de technische eigenaar van een specifieke workload om hen te helpen bij het overwegen van alternatieve opties 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-toepassing 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