CloudNation - Inspiratie

Een gids voor het oplossen van compatibiliteitsproblemen met Debian 10 AMI bij upgrades van AWS-instances

Geschreven door Nathan Wouda | Nov 16, 2023 8:35:48 AM

 

Onlangs heb ik een interessante situatie meegemaakt waarin een AWS Marketplace AMI, met name Debian 10, mij blokkeerde bij het upgraden van het instancetype. In dit specifieke geval stond de situatie mij niet toe om simpelweg naar een nieuwere versie van Debian te migreren, dus moest ik een oplossing vinden. In dit artikel wordt uitgelegd hoe ik het deed.

Wat was het probleem?

Het blijkt dat AMI-onderhouders van AWS Marketplace beperkingen kunnen stellen als het gaat om compatibiliteit met instancefamilies en generaties. In dit specifieke geval was de Debian 10 AMI niet compatibel met c6- of c7-instances, dus ik bleef hangen bij de c5-generatie. Dat is best jammer, want de c5-generatie is niet de nieuwste, terwijl hij evenveel kost als de c6-generatie. Normaal gesproken betekent een nieuwere generatie betere prestaties, dus ik wilde upgraden.

De methodes die ik uitprobeerde

Methode 1: Wijzig het instancetype

De eenvoudigste manier om een instance te upgraden is door het simpelweg uit te schakelen en het instancetype te wijzigen. Dit is wat ik eerst probeerde, maar het werkte niet. De foutmelding was de volgende:
"The instance configuration for this AWS Marketplace product is not supported. Please see the AWS Marketplace site for more information about supported instance types, regions, and operating systems."

Methode 2: Koppel het EBS-volume opnieuw aan een nieuwe instance

Omdat een interne upgrade niet werkte, dacht ik dat ik simpelweg een nieuwe instancetype vanuit een nieuwe AMI kon starten, het EBS-volume ervan kon loskoppelen en het oude EBS-volume aan de nieuwe instance kon koppelen. Dit resulteerde in dezelfde foutmelding als voorheen.

Dit betekent dat het EBS-volume gekoppeld is aan de AMI en zich houdt aan de beperkingen van de AMI. Nu moest ik nadenken over hoe ik dit kon omzeilen.

Methode 3: Maak een nieuw EBS-volume op basis van een momentopname

Ik dacht dat een herstelde snapshot deze link naar de originele AMI misschien niet zou hebben, omdat het een nieuw EBS-volume is. Daarom heb ik een momentopname gemaakt van het oude EBS-volume en een nieuw EBS-volume gemaakt van de momentopname. Ik heb geprobeerd het aan het nieuwere exemplaar toe te voegen, maar helaas kreeg ik nog steeds dezelfde foutmelding... Dit betekent dat de momentopname ook deze link naar de originele AMI heeft.

Methode 4: Maak een nieuw EBS-volume en kopieer de gegevens

De laatste methode die ik probeerde was een nieuw EBS-volume te maken en de gegevens van het oude EBS-volume naar het nieuwe te kopiëren. Dit is iets ingewikkelder, maar het werkte. Hier zijn de stappen die ik heb genomen:

  • Maak een migratie-instance van dezelfde generatie als de oorspronkelijke instance voor het kopiëren van de gegevens (je wil dit niet doen op de oorspronkelijke instance, omdat dit kan leiden tot beschadigde bestanden of andere inconsistenties)
  • Maak een nieuw EBS-volume met dezelfde grootte als het oude
  • Koppel het oude EBS-volume los van het oorspronkelijke exemplaar
  • Koppel zowel het nieuwe EBS-volume als het oude EBS-volume aan de migratie-instance
  • Maak bijvoorbeeld verbinding met die migratie-instance via de SSM-console
  • Voer lsblk uit om de apparaatnaam van de EBS-volumes te bekijken. Je zou ze moeten kunnen identificeren aan de hand van hun grootte, hun partities en hun mountpoints
  • Voer sudo dd if=/dev/nvme1n1 of=/dev/nvme2n1 bs=1M uit om de gegevens van het oude EBS-volume naar het nieuwe te kopiëren. Vervang  /dev/nvme1n1 en /dev/nvme2n1 door respectievelijk de apparaatnamen van het oude en nieuwe EBS-volume

After this, you can detach the old EBS volume from the migration instance, and attach the new EBS volume to the original instance. You are now able to change the instance type to a newer generation.

You can verify the instance type by checking the kernel log for the DMI information. In my case, the instance type was c6a.large:

Hierna kun je het oude EBS-volume loskoppelen van de migratie-instance en het nieuwe EBS-volume aan de oorspronkelijke instance koppelen. Je kunt nu het exemplaartype wijzigen naar een nieuwere generatie.

Je kunt het exemplaartype verifiëren door het kernellogboek te controleren op DMI-informatie. In mijn geval was het instantietype c6a.large:

admin@ip-10-0-10-11:/var/log$ grep --binary-files=text 'DMI: Amazon' kern.log
Nov 10 07:18:10 ip-10-0-10-11 kernel: [ 0.000000] DMI: Amazon EC2 c5a.large/, BIOS 1.0 10/16/2017
Nov 10 07:50:32 ip-10-0-10-11 kernel: [ 0.000000] DMI: Amazon EC2 c6a.large/, BIOS 1.0 10/16/2017


Kleine waarschuwing

De hierboven beschreven methode is niet zonder risico's. Als je niet oppast, kun je eindigen met een beschadigd EBS-volume, of erger nog, met een beschadigde instance. Hier zijn enkele dingen waarmee je rekening moet houden:

  • Zorg ervoor dat je op de juiste manier een back-up hebt gemaakt van alle belangrijke gegevens. Meer specifiek: zorg ervoor dat je een momentopname hebt van het EBS-volume
  • Zorg ervoor dat je de gegevens van het oude EBS-volume naar het nieuwe kopieert, en niet andersom. Als je niet oppast, kunt je eindigen met een leeg EBS-volume

Andere gedachten

Omdat de AMI die in dit artikel wordt gebruikt gratis is, zie ik geen problemen bij het gebruik ervan. Als je echter een Marketplace AMI gebruikt, wil je wellicht de algemene voorwaarden van de AMI controleren voordat je deze methode gebruikt. Ik ben niet verantwoordelijk voor eventuele schade veroorzaakt door het gebruik van deze methode.