Assets herstellen vóór de migratie

Tijdens het migratiebeoordelingsproces identificeert het team alle configuraties die een asset mogelijk niet compatibel maken met de gekozen cloudprovider. Herstel is een controlepunt in het migratieproces dat u kunt gebruiken om eventuele incompatibiliteit op te lossen.

In dit artikel worden enkele veelvoorkomende hersteltaken beschreven en kunt u bepalen of herstel een verstandige investering is.

Hersteltypen

Er zijn twee hoofdtypen herstelactiviteiten die u tijdens uw implementatie moet plannen.

• Op basis van de resultaten van de evaluatieactiviteiten
  • Herstelactiviteiten die moeten worden voltooid om replicatie en implementatie toe te staan.
  • U hebt deze herstelactiviteiten in uw workloadevaluatie tijdens de evaluatiefase vastgesteld. U moet deze taken uitvoeren om ervoor te zorgen dat u uw workload correct kunt repliceren en faseren in de cloud.
  • Dit is voornamelijk gericht op de bronservers die worden gemigreerd.
• Op basis van de resultaten van de testactiviteiten
  • Dit komt van het testen van migratieactiviteiten en het uitvoeren van bedrijfstests.
  • Deze herstelactiviteiten zijn gericht op de configuratie van de gerepliceerde doelservers en eventuele ondersteunende services, zoals load balancers, virtuele netwerken en opslagaccounts.
  • Deze taken zijn waarschijnlijk iteratiefer. Testen en herstellen van verschillende cycli totdat alle testcases zijn geslaagd, wordt verwacht.

Herstelactiviteiten bijhouden

Tijdens de iteratie kunt u hersteltaken voor uw workloads identificeren via evaluatie of testen. U moet deze taken bijhouden als projectactiviteiten om ervoor te zorgen dat ze zijn voltooid.

Hoewel kleine migratiegolven spreadsheets kunnen gebruiken om items bij te houden, genereren grotere golven met veel hersteltaken meerdere items. U kunt hulpprogramma's zoals Azure DevOps gebruiken om werkitems te maken en prioriteit te geven en door specifieke fasen te lopen om u te helpen uit te schalen. Zelfs als u Azure DevOps niet gebruikt voor andere inspanningen, kunt u dit gebruiken om herstelproblemen op te lossen en taken voor het migratieproces te organiseren.

Wanneer u deze taken maakt, moet u ervoor zorgen dat u ze weer verbindt met de werkbelasting die ze beïnvloeden. Hiermee kunt u bepalen welke workloads mogelijk worden vertraagd door hersteltaken. Vervolgens kunt u prioriteit geven aan het werk op workloadprioriteit.

Sommige problemen kunnen van invloed zijn op meerdere workloads. Dit zijn over het algemeen items met de host, een brede configuratie of problemen met de landingszone als geheel. Deze problemen moeten de eerste zijn die prioriteit hebben voor herstel.

Algemene hersteltaken

Technische schulden zijn een gezond en verwacht onderdeel van de bedrijfsomgeving. Architectuurbeslissingen die geschikt zijn voor een on-premises omgeving zijn mogelijk niet geschikt in een cloudplatform. In beide gevallen zijn algemene hersteltaken mogelijk vereist om assets voor te bereiden op migratie. Hier volgen enkele voorbeelden:

• Secundaire hostupgrades: af en toe moet een verouderde host worden bijgewerkt voordat de replicatie wordt uitgevoerd.
• Secundaire upgrades van het gastbesturingssysteem: u moet uw besturingssysteem waarschijnlijk patchen of upgraden voordat de replicatie wordt uitgevoerd.
• Sla-wijzigingen (Service Level Agreement): Back-up- en herstelprocessen veranderen aanzienlijk in een cloudplatform. De back-upprocessen voor gemigreerde assets moeten mogelijk worden gewijzigd om ervoor te zorgen dat ze hun benodigde SLA's in de cloud blijven bereiken.
• Wijzigingen in de toepassingsconfiguratie: gemigreerde toepassingen vereisen mogelijk aanpassingen aan variabelen, zoals netwerkpaden naar afhankelijke activa, wijzigingen in serviceaccounts of updates van afhankelijke IP-adressen.
• Kleine wijzigingen in netwerkpaden: routeringspatronen moeten worden gewijzigd om gebruikersverkeer naar de nieuwe assets correct te routeren. Dit is geen productieroutering naar de nieuwe assets, maar configuratie om de juiste routering naar de assets in het algemeen mogelijk te maken.

Grootschalige hersteltaken

Er is weinig behoefte aan herstel wanneer een datacentrum correct wordt onderhouden, gepatcht en bijgewerkt. Herstelrijke omgevingen komen vaak voor in grote ondernemingen. Dit kunnen organisaties zijn onder grote IT-downsizing, verouderde beheerde service en omgevingen met veel overnamemogelijkheden. In elk van deze omgevingen bestaat herstel uit een groot deel van de migratie-inspanning. De volgende hersteltaken kunnen vaak optreden of een negatieve invloed hebben op de migratiesnelheid of consistentie. Als dit gebeurt, moet u een afzonderlijk herstel uitvoeren in een parallelle inspanning en een team dat vergelijkbaar is met cloudimplementatie en cloudgovernance.

• Frequente hostupgrades: het upgraden van meerdere hosts om de migratie van een workload te voltooien, kan het migratieteam vertragen. Isoleer betrokken toepassingen en los de herstelstappen op voordat u betrokken toepassingen in geplande releases opneemt.
• Frequente upgrade van gastbesturingssystemen: grote ondernemingen hebben vaak servers die worden uitgevoerd op verouderde versies van Linux of Windows. Afgezien van de beveiligingsrisico's van het gebruik van een verouderd besturingssysteem, zijn er ook incompatibiliteitsproblemen die de migratie van betrokken workloads voorkomen. Wanneer voor meerdere virtuele machines (VM's) herstel van het besturingssysteem is vereist, probeert u deze inspanningen te scheiden in een parallelle iteratie. Sommige upgrades kunnen worden voltooid door de migratiehulpprogramma's als onderdeel van het migratieproces, zoals de windows Server-upgradefunctie in Azure Migrate en moderniseren.

Grootschalige herstelbewerkingen oplossen

Omdat herstel voor kleinere workloads eenvoudig kan zijn, kiest u kleinere workloads voor de eerste migratiegolven. Naarmate uw migratie-inspanningen volwassen worden en u grotere workloads gaat aanpakken, kan herstel tijdrovend en kostbaar zijn. Herstelinspanningen voor een Migratie van Windows Server 2003 met een groep assets met meer dan 5000 VM's kunnen bijvoorbeeld een migratie met maanden vertragen. Wanneer dergelijke grootschalige herstelbewerkingen vereist zijn, moet u mogelijk uw plannen voor het migreren van de betrokken workloads wijzigen. In dergelijke gevallen kunnen moderniseringsactiviteiten om de waarde van herstelinspanningen te maximaliseren efficiënter en productiever zijn.

U kunt de volgende vragen gebruiken om beslissingen te helpen nemen:

• Zijn alle workloads die worden beïnvloed door de herstelbewerkingen geïdentificeerd en vermeld in de achterstallige migratie?
• Voor workloads die niet worden beïnvloed, produceert een migratie een vergelijkbaar rendement op investeringen (ROI)?
• Kunnen de betrokken assets worden hersteld in samenhang met de oorspronkelijke migratietijdlijn? Welk effect hebben tijdlijnwijzigingen op de ROI?
• Is het economisch haalbaar om de assets parallel met de migratie te herstellen?

Als de vorige vragen niet worden beantwoord, kunt u deze moderniseringsmethoden overwegen:

• Containerisatie: Sommige assets kunnen zonder herstel worden gehost in een containeromgeving. Dit kan minder dan gunstige prestaties opleveren en lost geen beveiligings- of nalevingsproblemen op.
• Automatisering: afhankelijk van de workload en herstelvereisten kan het uitvoeren van scripts voor de implementatie naar nieuwe assets met behulp van een DevOps-benadering rendabeler zijn.
• Herbouwen: wanneer herstelkosten en bedrijfswaarde even hoog zijn, is een workload geschikt voor herbouwen of opnieuw ontwerpen.

Volgende stap

Assets repliceren