Innovatie & Strategie

Dit is een bijdrage van Itility
Cloud
Cloud to Cloud migratie

Van cloud naar cloud migreren, wat moet je weten voor je begint?

Het verhuizen van de ene cloud naar de andere is niet altijd makkelijk. Ontdek wat we leerde tijdens een recente migratie

29 november 2019
Door: Itility, partner

Het verhuizen van de ene cloud naar de andere is niet altijd makkelijk. Ontdek wat we leerde tijdens een recente migratie

Het verhuizen van 40 applicaties van de ene cloud naar de andere cloud is niet altijd makkelijk. Dat ondervonden we tijdens een migratie van Azure naar AWS. Onze handicap: we moesten de migratietools deels zelf bouwen. Ontdek wat we leerde van deze opdracht en wat de beste aanpak is voor een verhuizing van Azure naar AWS, met wat we nu weten.

Waarom van cloud naar cloud migreren?
Laten we beginnen met de hamvraag: Als het migreren van de ene cloud naar de andere zo moeilijk is, waarom zou je er dan aan beginnen? De meeste bedrijven migreren tenslotte nog van on-premise naar de cloud. Maar als je een van de ‘early adopters’ van cloud was, dan is er sindsdien een hoop veranderd. Alle cloud providers die toen op de short-list van onze klant stonden, hebben zichzelf opnieuw uitgevonden. Elk op hun eigen manier. Wat ‘cloud hopping’ – zoals sommigen het noemen – daarom zo interessant maakt:

  • Het optimaliseert cloudkosten voor slim gebruik van resources.
  • Het verlaagt de afhankelijkheid van één cloud provider.
  • Het kan leiden tot betere dienstverlening op het gebied van kosten en service level agreements (SLA’s).
  • Het helpt om een fusie, met andere bedrijven die de cloud gebruiken, mogelijk te maken.

Voor onze klant was het optimaliseren van kosten en het verlagen van de afhankelijkheid van één provider de belangrijkste redenen om te migreren.

Het grootste verschil tussen een on-premise-to-cloud migratie en een cloud-to-cloud migratie is de technische kant.

Uitdaging: geen impact op runtime
Het gebrek aan een volwaardige out-of-the-box migratietool was de eerste hindernis. Daarnaast hadden we nog een uitdaging: business continuity. Alle applicaties moesten altijd beschikbaar zijn. Downtime moest worden beperkt tot korte maintenance windows, liefst in het weekend, om zo de impact voor eindgebruikers minimaal te houden. Functionele verbeteringen van applicaties vielen buiten de scope, tenzij er quick wins waren op het gebied van kosten, zoals het verkleinen van volumes of databases.

Hoe zorg je er bij zo’n project voor dat je het gevraagde resultaat kunt leveren? In de eerste stap maken we daarom maken we direct de verantwoordelijkheden inzichtelijk voor alle betrokkenen. Enkele voorbeelden:

  • Onze cloud engineers zijn verantwoordelijk voor de migratie
  • De applicatie-eigenaar is verantwoordelijk voor het plannen van sign-offs, voor wijzigingen in de configuratie van applicaties en voor het testen van de applicatie na de migratie
  • Het netwerkteam is verantwoordelijk voor het aanpassen van de applicatie-endpoints en de definitieve switch naar de gemigreerde applicatie.

Nog belangrijker: wij volgden de onderstaande migratiecyclus (onze fabrieksbenadering).

Fabrieksbenadering

Deze cyclus doorlopen we voor iedere applicatie. De eerste stap is een assessment (zie onderstaand formulier). We gaan in gesprek met de applicatie-eigenaar en de Technical Application Manager, en nemen de tijd om de applicatie door te nemen: wat is de functie van de applicatie, en welke koppelingen zijn er met het netwerk of met third-party tools. Vervolgens bepalen we samen met de applicatie-eigenaar welke aanpak het beste past bij de applicatie en welke kloven we moeten overbruggen.

Assessment met een eenvoudig formulier

Migratie assessment

Strategie: bepaal je migratiemethode
Kies een van de volgende methodes:

  • ‘Lift en shift’ migratie
  • Nieuwe applicatie-uitrol, herinstallatie en datamigratie
  • Nieuwe applicatie-uitrol en herinstallatie

Als vertrekpunt adviseerde we onze klant om voor de tweede aanpak te gaan, omdat deze tot de minste downtime zou leiden. Toch besloten de applicatie-eigenaren voor de lift en shift methode te gaan. Voornamelijk omdat de documentatie van applicaties niet altijd zo scherp en duidelijk was als ze hadden gehoopt. Ook waren er applicaties door externe partijen geïnstalleerd, wat betekende dat herinstalleren een tijdrovende klus zou zijn voor de applicatie-eigenaar.

Na de keuze voor de lift en shift strategie werkten we nauw samen met iedere applicatie-eigenaar. We organiseerden meerdere sessies om te zien hoe een applicatie werkte en, gezien een lift en shift migratie downtime met zich meebrengt, stelden we vragen als: “Hebben we een maintenance window nodig voor het migreren van deze applicatie?”, “Kunnen we de migratie tijdens kantooruren uitvoeren?”, “Kunnen we bestaande maintenance windows gebruiken?” en “Wat is de beste manier om live te gaan?”

Toen alle knopen waren doorgehakt was het tijd om een draaiboek op te stellen met alle afhankelijkheden en onderdelen die geïmporteerd moesten worden. Zoals je misschien al ziet is het startpunt voor een cloud-to-cloud migratie in principe hetzelfde als voor een on-premise-to-cloud migratie. Het grootste verschil is de technische kant.

Ik moest het standaard migratiescript herschrijven

Migreren in de echte wereld
We selecteerden ongeveer 40 applicaties om naar AWS te migreren. Applicaties die voornamelijk gebouwd zijn op Virtual Machines. Daarom focusten we ons op het automatiseren van de migratie van Virtual Machines van Azure naar AWS. Omdat er op dat moment geen out-of-the-box tool beschikbaar was, werkten we nauw samen met AWS om het proces te versnellen. Zo leverde AWS ons input en voorbeelden aan over hoe om te gaan met VM-migraties. Hoewel vanwege bijzonderheden in het netwerk, toch heel wat maatwerk nodig was om de migratie te automatiseren.

Zo zag het lift en shift migratieproces eruit:

  1. Het converteren van de Azure applicatie-infrastructuur (geschreven in ARM) naar AWS infra-as-code (CloudFormation).
  2. Het doorlopen van de migratie pipeline met de parameters van de applicatie.
  3. Het uitrollen van de CloudFormation template met de nieuwe Amazon Machine Image (AMI) en data volumes via de deployment pipeline.

De Azure applicatie-infrastructuur (in ARM) converteren naar AWS CloudFormation
Deze stap kan al voor of tijdens de migratie worden voorbereid. Omdat we werken op basis van een catalogus bij het creëren van resources in de cloud, was het relatief eenvoudig om de Azure ARM-code te vertalen naar AWS CloudFormation. We hoefden in principe alleen de corresponderende resources uit de catalogus van de nieuwe provider te selecteren. In deze fase hebben we niet gelet op het rightsizen of wijzigen van de architectuur, maar hebben we ons volledig gericht op het in de lucht krijgen van de applicatie bij de nieuwe provider.

Het doorlopen van de migratie pipeline met de parameters van de applicatie
Met de hulp en input van AWS hebben we de pipeline voor de daadwerkelijke migratie opgesteld (zie onderstaande figuur). Dit waren de belangrijkste stappen:

1. Schakel de virtuele machines uit om wijzigingen tijdens de lift en shift migratie te voorkomen

2. Converteer de OS en data disks naar VHD’s en kopieer ze naar een tijdelijke migratieserver

3. Optioneel kunnen de VHD’s worden verkleind om tijd te besparen tijdens de volgende stap

4. Upload de VHD’s van de migratieserver in Azure naar een AWS S3 Bucket

5a. Converteer de Operating System VHD naar een Amazon Machine Image (AMI)

5b. Converteer de data disks naar EBS Snapshots

5c. Converteer de EBS Snapshots naar EBS volumes

6. Vul de CloudFormation Template met de nieuwe AMI en EBS parameters

Rol de CloudFormation template uit om de nieuwe applicatie-resources te maken

Cloud to Cloud Migratie Proces

1 Terabyte? Dat kunnen we migreren in twee of drie uur. Laten we vier aanhouden voor de zekerheid.

Lessons Learned
Zo, nu weet je hoe we het hebben gedaan, wil je vast weten wat we hebben ontdekt tijdens het uitvoeren van een cloud-to-cloud migratie. Onze lessen:

  • Lift en shift was de meest populaire methode bij applicatie-eigenaren
    Hoewel de tweede migratie methode (schone uitrol van de applicatie, herinstallatie en data sync) praktisch geen downtime zou opleveren, was de lift en shift methode populairder; waarschijnlijk omdat deze aanpak minder inspanning vereiste van de (technische) applicatie-eigenaren.
  • Reserveer genoeg tijd voor data-migratie
    Schommelingen in API-snelheden bij de verschillende cloud providers kan een uur extra tijd kosten bij grotere data disks.
  • Specificaties van Azure en AWS kunnen de migratie beïnvloeden
    Zo werd bijvoorbeeld een specifieke kernelversie van Azure Virtual Machines niet herkend door AWS.
  • PaaS-onderdelen zijn niet eenvoudig te migreren in een infrastructuur met proxies
    De meeste bestaande migratie-tools gebruiken een Virtual Machine om data van het ene PaaS-onderdeel naar het andere te versturen. Wanneer je werkt in een omgeving met beperkingen op internettoegang, kan deze methode fouten veroorzaken.
  • Reserveer genoeg tijd met de applicatie-eigenaren
    Het is belangrijk dat zij de urgentie van de migratie begrijpen en dat alle betrokkenen zich committeren aan de doelstelling.
  • Comprimeren is alleen nuttig als een klein deel van de disk in gebruik is
    Het comprimeren van een bijna-volle disk kost veel tijd. Het is dan beter om die direct te downloaden.
  • Applicatie intakes kunnen ingewikkeld zijn
    Met name als er specifieke kennis verloren gaat door het wisselen van applicatie-eigenaren.
  • Werk nauw samen met de cloud provider
    In dit geval AWS, om de snelheid te verhogen en complicaties die tijdens de migratie opkomen op te lossen.
  • Soms heb je pech
    Het is onvoorspelbaar dat enkele dagen voordat je je laatste migratie afrondt, AWS zijn Server Migration Service (SMS) tool officieel lanceert.

Blijf flexibel als er problemen ontstaan
Zelfs na het plannen van iedere stap van de migratie (het aanvragen van change windows tijdens of na kantooruren, en nauwe samenwerking met de technische applicatie-eigenaren), is het niet altijd mogelijk om problemen te voorkomen. Zo ontstonden er bij sommige migraties problemen tijdens het opstarten van de gemigreerde virtual machines. Door flexibel te blijven en nauw samen te werken met de project managers, applicatie-eigenaren en het support team van AWS, waren we in staat om voor vrijwel ieder probleem een oplossing te vinden.

Helaas bestonden er situaties waarin het beschikbare migratievenster te kort was en we waren we genoodzaakt de migratie terug te draaien om de impact voor gebruikers te beperken. Op dat moment lijkt dat verspilde tijd. Achteraf bleken deze momenten juist waardevol, omdat het ons en de applicatie-eigenaren meer inzicht gaf in de werking van de applicatie en het gedrag op het OS. Deze nieuwe informatie hielp bij het herplannen en succesvol uitvoeren van de migratie.

Samenvattend doorloopt een succesvolle migratie de volgende stappen: bepaal het waarom, ken je beperkingen, schat de situatie in, gebruik een standaard aanpak; start dan en adresseer de issues die je tegenkomt op een flexibele manier.

Lees meer over de Itility Cloud Community op onze website.

 

Reactie toevoegen