nl

NL

  • EN
  • DE
  • NL
£
nl

Startpagina / Blog / Acht punten ter overweging bij de planning van je cloud migratiestrategie

Het migreren van je infrastructuur naar de cloud is meestal geen probleem voor organisaties die op de lange termijn willen besparen, prestaties willen verbeteren en de schaalbaarheid willen vergroten. Verhuizen naar de cloud kan echter een ontmoedigend vooruitzicht zijn. Organisaties kunnen grote problemen tegenkomen wanneer ze slecht voorbereid aan een migratieproject beginnen. In dit artikel bespreek ik acht dingen waaraan je moet denken bij het plannen van je strategie om naar de cloud te migreren.

Discovery fase

Discovery is het proces van het komen tot een uitgebreide inventaris van al je servers, applicaties en hun bijbehorende afhankelijkheden die samen je IT vormen. Dit kan soms over het hoofd worden gezien bij het plannen van een migratie, maar het is van cruciaal belang om deze stap methodisch en grondig uit te voeren, waarbij je zoveel mogelijk informatie over je bestaande IT-omgeving vastlegt.

In de discovery fase krijg je belangrijke inzichten zoals de schaal van je IT-omgeving, besturingssystemen die mogelijk niet worden ondersteund na migratie, software die mogelijk niet compatibel is, licentievereisten die kunnen veranderen, systemen die buiten gebruik kunnen worden gesteld en mogelijk problematische systemen die speciale aandacht vereisen. Problematische systemen? Ja, want hoe zit het met de twintig jaar oude pc onder iemands bureau die niemand opnieuw durft op te starten omdat je die voor het uitbetalen van de salarissen gebruikt? Je moet een manier bedenken om dit te migreren.

Ook kun je ontmoedigd raken door de discovery omdat je zorgen hebt over de tijd en middelen die het vergt, dus kan de verleiding om te haasten groot zijn. Als je dat doet loop je het risico dat je project juist langer duurt en de kosten hoger uitvallen. De uitdrukking "wisten we dit maar aan het begin van het project" kan je behoorlijk ontmoedigen midden in een multi-fase datacentermigratie.

Gelukkig kan discovery veel eenvoudiger worden gemaakt. Met behulp van tools zoals CloudPhysics of Cloudamize is het mogelijk een duidelijker inzicht te krijgen in hoe je IT-omgeving eruit ziet, zodat je op basis van heldere informatie beslissingen kunt nemen over je infrastructuurmigratie. Een gedetailleerde inventaris van je systemen en applicaties helpt je in de volgende fase van je migratieplan.

Een migratieaanpak kiezen

Doorgaans zijn er twee hoofdbenaderingen bij het migreren van systemen naar de cloud. Deze worden meestal 'Big Bang' en 'Gefaseerd' genoemd. Beide hebben voor- en nadelen, dus het is belangrijk om te beoordelen welke aanpak het beste werkt voor jou.

Big Bang

Zoals de naam al doet vermoeden, migreer je al je systemen en services tegelijkertijd in een 'Big Bang'. Je schakelt effectief onmiddellijk over naar de nieuwe omgeving. Deze benadering, hoe spannend het ook klinkt, kan behoorlijk effectief zijn. Als je omgeving redelijk klein is - zeg maar een handvol VM's en een eenvoudig netwerk - dan is de 'Big Bang' de beste aanpak. Als je bijvoorbeeld je webservers naar de cloud migreert terwijl je databaseserver afzonderlijk lokaal wordt gemigreerd, resulteert dit waarschijnlijk in het onderhouden van een VPN en enkele andere complexe maar tijdelijke netwerkoplossingen. Voor een systeem met simpelweg een handvol webservers en een database, is 'Big Bang' waarschijnlijk de beste aanpak.

De belangrijkste uitdagingen bij deze aanpak doen zich voor wanneer de te migreren systemen en diensten talrijk zijn; het netwerken complex is; er meerdere databases zijn waarmee je rekening moet houden, enzovoorts. In deze scenario's is een big bang-aanpak waarschijnlijk niet haalbaar, vereist het een enorme hoeveelheid technische middelen en kan het veel problemen veroorzaken.

Gefaseerde aanpak

Voor grootschalige of complexe omgevingen is een gefaseerde aanpak zonder twijfel de aanbevolen strategie voor migratie.

Hier wordt gedetailleerde discovery essentieel; je zult eerst je systemen in logische eenheden of fasen moeten verdelen. Er zijn veel verschillende manieren om je systemen te verdelen, waarbij je rekening moet houden met de meest logische manier om dit te doen.

Stel bijvoorbeeld dat je een applicatie hebt met de naam 'App1' met vier webservers achter een load balancer, een API-server en een database. Je hebt ook een andere applicatie genaamd "App2" met een API-server en een andere database, maar je hebt ook een verbinding nodig met de database voor "App1".

In dit scenario is het logisch om “App1” als de eerste fase en “App2” als de tweede fase te behandelen. Door alternatieve tijdelijke DNS-vermeldingen voor de toepassingen te maken, kun je de infrastructuur voor "App1" migreren en grondig testen met enkele oude gegevens voordat je deze overschakelt naar productie. In de tweede fase kun je vervolgens de infrastructuur voor "App2" migreren onder een andere alternatieve DNS-vermelding en de verbinding tot stand brengen met de "App1" -database. Na migratie van alle infrastructuur, blijven de bestaande applicaties nog steeds op locatie actief terwijl je wacht op de overschakeling naar hun cloudgebaseerde tegenhangers en tests uitvoert op de gemigreerde infrastructuur. Na het voltooien van je tests, is 'live gaan' gewoon een DNS-wijziging en databaseherstel, et voila, je applicaties zijn naar de cloud gemigreerd en in productie genomen.

Vangnet

Hoewel een goede planning het meest aan te raden is en de voordelen vrij duidelijk zijn, is er nog steeds een kans dat je tijdens een migratie roept "Help, alles gaat vreselijk mis!" Technologie is complex, mensen zijn niet perfect en soms gaat er gewoon iets mis. Een gefaseerde aanpak betekent dat je de straal van de explosie verkleint tijdens een mislukte migratie. Alleen omgaan met een handvol systemen betekent minder dingen om ongedaan te maken.

Wanneer je een migratie plant, is het belangrijk om de vraag te stellen: "Hoe krijg ik dit weer online als de migratie mislukt?" Het antwoord op die vraag hangt meestal af van de toestand waarin je systemen zich vóór de migratie bevinden. Enkele eenvoudige dingen die kunnen helpen bij een snel herstel tijdens een migratiefout zijn dingen als:

  • Maak een back-up - dit is cruciaal voor elke vorm van migratie
  • Controleer of je gegevens uit de back-up kunt herstellen - soms zijn back-ups corrupt, zorg ervoor dat de jouwe dat niet is
  • Plan waar mogelijk wat downtime van je gebruikers
  • Voer de migratie uit tijdens een rustige periode
  • Bij geclusterde servers, failover naar de ene server en migreer de andere
  • Snapshot van de bronserver (als je hypervisor deze functionaliteit heeft)
  • Probeer zoveel mogelijk van de migratiestappen te scripten met zoiets als Bash, Python of PowerShell in plaats van een GUI te gebruiken - scripts zullen precies doen wat je hen opdraagt, zodat je ze vooraf kunt testen en collega's ze kunnen beoordelen . Omgekeerd kan het moeilijk zijn om te onthouden waar je om 03:00 op hebt geklikt, vooral als het fout is gegaan!
  • Controleer of de TTL op je DNS goed en laag is ingesteld (ik raad 5 minuten aan) ongeveer 48 uur voorafgaand aan de migratie - dit zou de DNS-omschakeling moeten versnellen
  • Zorg dat de betrokken stakeholders op de hoogte zijn gebracht
  • Zorg ervoor dat monitoringsystemen zijn bijgewerkt
  • Zorg ervoor dat ook flexibel personeel weet dat je vanavond je servers migreert!
  • Controleer je back-up nog eens, en maak er voor de zekerheid nog een
  • Definieer enkele succescriteria - een set tests die je na migratie kan uitvoeren waarmee je bepaalt of de migratie is geslaagd

Risicobeoordeling

Een ander element waarmee je je migratiestrategie vaststelt, is een risicobeoordeling. Er zijn veel manieren om een risicobeoordeling uit te voeren, maar uiteindelijk moet je beslissen wat je als een risico beschouwt en hoe zwaar dit risico weegt.

Enkele nuttige factoren voor het definiëren van risico's kunnen zaken zijn als kosten, hersteltijd, impact op je reputatie, juridische en nalevingsimplicaties, enzovoorts. Aangenomen dat je een gefaseerde aanpak volgt, zou een nuttige oefening tijdens de planning zijn om een rekenmodel te maken die een score toekent aan elk van je belangrijkste risicofactoren. Dit kan in een eenvoudige spreadsheet, je hoeft hiervoor geen speciale applicatie te schrijven.

Werk aan een scenario van een denkbeeldige uitval van twee uur en bereken de risicoscore voor elk van je applicaties. Hier is een voorbeeld van een rudimentaire risicoscore, omdat je de 'App3'-scores het hoogst kunt zien, dus moet het hoogste risico worden bepaald:




Om het beste inzicht in het risicolandschap te krijgen, moet je ervoor zorgen dat de risicobeoordeling wordt voltooid door verschillende mensen die bekend zijn met de toepassingen en een gemiddelde van de scores nemen. Dit zou je moeten helpen om de menselijke neiging van slechts één persoon de risicobeoordelingsscores toe te laten wijzen, tegen te gaan.

Nadat je elk van je applicaties en services hebt beoordeeld, kun je de resultaten gebruiken om op gegevens gebaseerde beslissingen te nemen over de prioriteitsvolgorde van je migratie. Bijvoorbeeld: wat doe je eerst? Welke van je applicaties heeft de hoogste risicoscore? Welke van hebben een laag risico en wat zijn potentiële quick wins?

Wat je niet migreert

Iedereen kent de uitspraak 'cloud is de toekomst' en dit stimuleert vaak de keuze voor een migratie voor veel organisaties. Er zijn echter momenten waarop migratie van een bepaald systeem niet praktisch is. Het Google Cloud whitepaper 'CIO's Guide to Application Migration' stelt 3 vragen om te bepalen of je applicatie geschikt is voor migratie:

  • Zijn de componenten van mijn applicatiestack gevirtualiseerd of virtualiseerbaar?
  • Kan mijn applicatiestack naar de cloud en tegelijkertijd alle vereisten voor licenties, beveiliging, privacy en compliance ondersteunen?
  • Kunnen alle applicatie-afhankelijkheden (bijv. Derde deel talen, frameworks, bibliotheken etc.) worden ondersteund in de cloud?

Over het algemeen geldt dat als het antwoord op een van deze vragen 'nee' is, een 'lift en shift migratie' niet geschikt zal zijn. Je zou moeten overwegen je gegevens tot in de latere fasen van je migratie on-premise te laten, zodat je meer tijd hebt om een oplossing te vinden voor voor 'Verplaatsen en Verbeteren'.

Lift en Shift vs Verplaatsen en Verbeteren

Je kent de term 'Lift en Shift' waarschijnlijk wel als het gaat om migraties. Het idee om vrijwel alles opnieuw te implementeren in een nieuwe omgeving. Deze mentaliteit vormt vaak de basis van een grootschalige migratie; "Server-A" blijf je "Server-A" noemen, deze zal nog steeds Windows Server 2016 draaien en het zal nog steeds met "Master-DB" praten op dezelfde poorten als toen het zich nog in je datacenter bevond. De netwerken ziet er misschien een beetje anders uit, maar voor het grootste deel zijn de virtuele machines hetzelfde en doen ze hetzelfde als altijd. Dezelfde werklast, met ander gereedschap.

Misschien ken je de term 'Verplaatsen en Verbeteren' nog. Dit vormt meestal de basis van 'infrastructuurmodernisering', het proces waarbij een bestaande of 'legacy' werklast wordt gebruikt en opnieuw wordt bewerkt om gebruik te maken van moderne tools en technieken of 'cloud native' -aanbiedingen. Dit kan zorgen voor een gestroomlijnde en efficiënte toepassing die vaak veel schaalbaarder en kosteneffectiever is.

Het principe van 'Verplaatsen en Verbeteren' begint met de beoordeling van welke van je applicaties of workloads je kunt vervangen door een betere technologie, zelfs een 'cloud native' -technologie.

Stel dat je bijvoorbeeld een gegevensset van 100 TB hebt waarmee je analyses uitvoert. Je bestaande systeem maakt gebruik van traditionele SQL-servers en het kan enkele dagen duren voordat het analysemodel is verwerkt. Dit systeem zou gemakkelijk profiteren van de transformatie naar een Big Query-werkbelasting in GCP. Na enige query-optimalisatie zou het analysemodel minuten of seconden nodig hebben om te verwerken in plaats van dagen en werkt het hele systeem veel kosteneffectiever.

Na de migratie

Na migratie van je VM naar de cloud, is de kans groot dat dingen niet meteen perfect werken. Er zullen monitoring- en logging-agenten zijn om te installeren, firewallconfiguratie om in te stellen, connectiviteitscontroles met andere services, enzovoorts. Neem daarom de tijd om te beoordelen wat je server mogelijk nodig heeft om correct te werken in de nieuwe omgeving.

Bijvoorbeeld, bij het migreren van een server naar GCP zijn er de Google SDK, Stackdriver logging en monitoring agents, VSS snapshot-functionaliteit, Google Metadata Server-ingangen voor het hostbestand, enzovoorts. Als je een tool zoals CloudEndure hebt gebruikt om de machine naar GCP te migreren, moet je een manier vinden om alle onderdelen te installeren die niet automatische worden geïnstalleerd maar die correct moeten worden uitgevoerd in GCP.

Na het instellen van al deze componenten, moet je ze in een installatie- en configuratiescript na de migratie schrijven. Afhankelijk van je gekozen migratieprogramma kun je dit script misschien zelfs doorgeven aan de instantie die wordt gemigreerd naar GCP om tijdens het opstarten als een postmigratietaak uit te voeren.

Continu onderhoud

Een laatste (maar zeker niet onbeduidende) zaak die je moet overwegen voorafgaand aan een infrastructuurmigratie, is het toepassen van moderne IT-methoden om je bronnen na migratie te behouden. Een van de belangrijkste mijlpalen voor moderne IT-praktijken is het gebruik van tools voor de gewenste configuratie van de staat. Deze tools dienen als een eenvoudige en consistente manier om te definiëren hoe je infrastructuur eruit moet zien en zorgen ervoor dat deze jouw "gewenste staat" behoudt. Hieronder tref je een meer gedetailleerde weergave van deze tools.

Infrastructure as a Code

Infrastructure as a Code is een term die doet wat het zegt. Het zijn je servers, netwerken, firewalls, beveiliging, opslag, enzovoorts. Gedefinieerd als een tekstbestand. De meest bekende en meest gebruikte tool voor 'Infrastructuur als code' is Terraform van HashiCorp.

Terraform geeft de gebruiker een eenvoudige en door mensen leesbare taal om 'bronnen' te definiëren. Deze bronnen kunnen vervolgens worden geïmplementeerd op je cloudplatform en een record, van wat er bestaat, wordt bewaard in een extern "statusbestand". Dit systeem zorgt ervoor dat de volledige infrastructuur zelf wordt gedocumenteerd, omdat deze allemaal in platte tekst is gedefinieerd en garandeert de werking door te vereisen dat de infrastructuur in code wordt gewijzigd en toegepast via Terraform, waardoor het "statusbestand" wordt bijgewerkt.

Wist je dit nog niet? Overweeg dan zeker om als codemodel naar een infrastructuur te gaan als onderdeel van je migratie of als een taak na de migratie. Als je geïnteresseerd bent in Terraform, bekijk dan hier de leerpagina van HashiCorp voor Terraform.

Configuratie Management

Nadat implementatie van je servers, heb je een manier nodig om ze te configureren. Hoe vertel je een webserver dat zijn functie een webserver is? Dat doe je met configuratiebeheer. Net zoals Infrastructuur als Code is de infrastructuur gedefinieerd in tekstbestanden, dat geldt ook voor configuratiebeheer.

Tools zoals Puppet, Ansible, Chef, PowerShell DSC zijn gewenste tools voor configuratie op de server. Vanuit dezelfde bestands gebaseerde benadering kun je met configuratiebeheer bepalen hoe je een virtuele machine moet configureren. Op basis van deze definities zullen de tools je machines configureren zoals je ze definieert.

Wil je meer informatie over configuratiebeheer, bezoek dan: opensource.com

Broncontrole

"Maar waar plaats ik al deze code ?!" vraag je. Het antwoord: "In een Git-repository".

Git is een versiebeheersysteem voor code. Het wordt ook gedistribueerd, dus er is niet langer slechts één exemplaar van "daves_super_belangrijk_script.sh". In plaats daarvan wordt het veilig bewaard in een repository en kan het worden opgeroepen wanneer dat nodig is, zoals een gouden speer uit de hemel ...

Of meer praktisch kun je hiermee bijhouden welke versie van het script momenteel wordt gebruikt. Wanneer mensen je vragen "Waar is het script voor X?" Of zeggen: "Ik denk dat er een probleem is met de code voor Y", kun je ze in de richting wijzen van een handige plek waar al die code wordt opgeslagen en veilig wordt bewaard. Je kunt zelf bepalen wie toegang heeft tot die code en wanneer mensen er wijzigingen in willen aanbrengen, zorg je ervoor dat ze deze moeten indienen voor controle en goedkeuring.

Er zijn veel Git-providers en welke je moet kiezen, hangt af van je vereisten. Dit blogonderwerp duikt niet diep in Git omdat het een enorm onderwerp is. Als je Git nog niet kent, is in principe is elke provider dat GitHub, GitLab, BitBucket enz. Ik raad je aan om de zeer nuttige documentatie van GitHub hier te bekijken.

Conclusie

Natuurlijk behelst de planning van een infrastructuurmigratie veel meer dan wat ik in dit artikel behandel, maar dit geeft je in elk geval richting te sturen of zet je misschien zelfs aan om na te denken over iets waaraan je nog niet had gedacht.

Als je meer wilt weten over het migreren van je services naar Google Cloud Platform en de hulp van een getrainde GCP Professional Architect kunt gebruiken bij het plannen van jouw reis naar de cloud, neem dan contact met ons op! Via coffee@cloudsolutions.co.uk of telefonische +31 (0) 20 333 7500.

Vergelijkbare verhalen