Share via

Felsöka etablering av virtuella datorer med cloud-init

  • Artikel

Varning

Den här artikeln refererar till CentOS, en Linux-distribution som närmar sig EOL-status (End Of Life). Överväg att använda och planera i enlighet med detta. Mer information finns i CentOS End Of Life-vägledningen.

Gäller för: ✔️ Flexibla skalningsuppsättningar för virtuella Linux-datorer ✔️

Om du har skapat generaliserade anpassade avbildningar med hjälp av cloud-init för att etablera, men har upptäckt att den virtuella datorn inte har skapats korrekt, måste du felsöka dina anpassade avbildningar.

Några exempel på problem med etablering:

  • Den virtuella datorn fastnar vid att "skapa" i 40 minuter och skapandet av den virtuella datorn markeras som misslyckad.
  • CustomData bearbetas inte.
  • Det går inte att montera den tillfälliga disken.
  • Användare skapas inte, eller så finns det problem med användaråtkomst.
  • Nätverk har inte konfigurerats korrekt.
  • Växla fil- eller partitionsfel.

Den här artikeln beskriver hur du felsöker cloud-init. Mer detaljerad information finns i djupdykning i cloud-init.

Steg 1: Testa distributionen utan customData

Cloud-init kan acceptera customData, som skickas till den, när den virtuella datorn skapas. Först bör du se till att detta inte orsakar några problem med distributioner. Försök att etablera den virtuella datorn utan att skicka någon konfiguration. Om du upptäcker att den virtuella datorn inte kan etableras fortsätter du med stegen nedan, om du upptäcker att konfigurationen du skickar inte tillämpas går du till steg 4.

Steg 2: Granska bildkraven

Den främsta orsaken till vm-etableringsfel är att OS-avbildningen inte uppfyller kraven för att köras i Azure. Se till att dina avbildningar är korrekt förberedda innan du försöker etablera dem i Azure.

Följande artiklar illustrerar stegen för att förbereda olika Linux-distributioner som stöds i Azure:

För azure cloud-init-avbildningar som stöds har Linux-distributionerna redan alla nödvändiga paket och konfigurationer på plats för att korrekt etablera avbildningen i Azure. Om du upptäcker att den virtuella datorn inte kan skapa från din egen kurerade avbildning kan du prova en Azure Marketplace-avbildning som stöds och som redan har konfigurerats för cloud-init, med din valfria customData. Om fungerar customData korrekt med en Azure Marketplace-avbildning finns det förmodligen ett problem med din kurerade avbildning.

Steg 3: Samla in och granska VM-loggar

När den virtuella datorn inte kan etableras visar Azure statusen "skapar", i 20 minuter och startar sedan om den virtuella datorn och väntar ytterligare 20 minuter innan den slutligen markerar vm-distributionen som misslyckad, innan den slutligen markeras med ett OSProvisioningTimedOut fel.

När den virtuella datorn körs behöver du loggarna från den virtuella datorn för att förstå varför etableringen misslyckades. Stoppa inte den virtuella datorn för att förstå varför etableringen av virtuella datorer misslyckades. Håll den virtuella datorn igång. Du måste behålla den misslyckade virtuella datorn i ett körningstillstånd för att kunna samla in loggar. Om du vill samla in loggarna använder du någon av följande metoder:

sudo cat /rescue/var/log/cloud-init*
sudo cat /rescue/var/log/waagent*
sudo cat /rescue/var/log/syslog*
sudo cat /rescue/var/log/rsyslog*
sudo cat /rescue/var/log/messages*
sudo cat /rescue/var/log/kern*
sudo cat /rescue/var/log/dmesg*
sudo cat /rescue/var/log/boot*

Kommentar

Du kan också skapa en virtuell räddningsdator manuellt med hjälp av Azure-portalen. Mer information finns i Felsöka en virtuell Linux-dator genom att ansluta OS-disken till en virtuell återställningsdator med hjälp av Azure-portalen.

Starta den inledande felsökningen genom att börja med cloud-init-loggarna och förstå var felet inträffade, sedan använda de andra loggarna för att djupdyka och ge ytterligare insikter.

  • /var/log/cloud-init.log
  • /var/log/cloud-init-output.log
  • Serie- och startloggar

I alla loggar börjar du söka efter "Failed", "WARNING", "WARN", "err", "error", "ERROR". Vi rekommenderar att du ställer in konfigurationen för att ignorera skiftlägeskänsliga sökningar.

Dricks

Om du felsöker en anpassad avbildning bör du överväga att lägga till en användare under bilden. Om etableringen inte kan ange administratörsanvändaren kan du fortfarande logga in på operativsystemet.

Analysera loggarna

Här följer mer information om vad du ska leta efter i varje cloud-init-logg.

/var/log/cloud-init.log

Som standard skrivs alla cloud-init-händelser med prioriteten felsökning eller högre till /var/log/cloud-init.log. Detta ger utförliga loggar för varje händelse som inträffade under initieringen av cloud-init.

Till exempel:

2019-10-10 04:51:25,321 - util.py[DEBUG]: Failed mount of '/dev/sr0' as 'auto': Unexpected error while running command.
Command: ['mount', '-o', 'ro,sync', '-t', 'auto', u'/dev/sr0', '/run/cloud-init/tmp/tmpLIrklc']
Exit code: 32
Reason: -
Stdout:
Stderr: mount: unknown filesystem type 'udf'
2020-01-31 00:21:53,352 - DataSourceAzure.py[WARNING]: /dev/sr0 was not mountable

När du har hittat ett fel eller en varning läser du bakåt i cloud-init-loggen för att förstå vilket cloud-init som försökte innan felet eller varningen inträffade. I många fall har cloud-init kört OS-kommandon eller utfört etableringsåtgärder före felet, vilket kan ge insikter om varför fel uppstod i loggarna. I följande exempel visas att cloud-init försökte montera en enhet precis innan den stötte på ett fel.

2019-10-10 04:51:24,010 - util.py[DEBUG]: Running command ['mount', '-o', 'ro,sync', '-t', 'auto', u'/dev/sr0', '/run/cloud-init/tmp/tmpXXXXX'] with allowed return codes [0] (shell=False, capture=True)

Om du har åtkomst till seriekonsolen kan du försöka köra kommandot som cloud-init försökte köra igen.

Loggningen för /var/log/cloud-init.log kan också konfigureras om i /etc/cloud/cloud.cfg.d/05_logging.cfg. Mer information om cloud-init-loggning finns i dokumentationen för cloud-init.

/var/log/cloud-init-output.log

Du kan hämta information från stdout och stderr under stegen i cloud-init. Detta omfattar normalt routning av tabellinformation, nätverksinformation, verifieringsinformation stdout för ssh-värdnyckel och stderr för varje steg i cloud-init, tillsammans med tidsstämpeln för varje steg. Om du vill stderrstdout kan loggning konfigureras om från /etc/cloud/cloud.cfg.d/05_logging.cfg.

Serie- och startloggar

Cloud-init har flera beroenden, dessa dokumenteras i nödvändiga förutsättningar för avbildningar i Azure, till exempel nätverk, lagring, möjlighet att montera en ISO och montera och formatera den tillfälliga disken. Något av dessa kan utlösa fel och orsaka att cloud-init misslyckas. Om den virtuella datorn till exempel inte kan få ett DHCP-lån misslyckas cloud-init.

Om du fortfarande inte kan isolera varför cloud-init inte kunde etableras måste du förstå vilka moln-init-faser och när moduler körs. Mer information finns i Dyka djupare in i cloud-init .

Steg 4: Undersöka varför konfigurationen inte tillämpas

Alla fel i cloud-init resulterar inte i ett allvarligt etableringsfel. Om du till exempel använder modulen runcmd i en cloud-init-konfiguration kommer en slutkod som inte är noll från kommandot den kör att göra att den virtuella datorns etablering misslyckas. Det beror på att den körs efter grundläggande etableringsfunktioner som sker i de första tre stegen i cloud-init. Om du vill felsöka varför konfigurationen inte tillämpades läser du loggarna i steg 3 och cloud-init-modulerna manuellt. Till exempel:

  • runcmd – körs skripten utan fel? Kör konfigurationen manuellt från terminalen för att säkerställa att de körs som förväntat.
  • Installerar paket – har den virtuella datorn åtkomst till paketlagringsplatser?
  • Du bör också kontrollera den customData datakonfiguration som har angetts för den virtuella datorn. Detta finns i /var/lib/cloud/instances/<unique-instance-identifier>/user-data.txt.

Nästa steg

Om du fortfarande inte kan isolera varför cloud-init inte körde konfigurationen måste du titta närmare på vad som händer i varje moln-init-fas och när moduler körs. Mer information finns i Dyka djupare in i cloud-init-konfigurationen .