Řešení problémů se zřizováním virtuálních počítačů pomocí cloud-init

Platí pro: ✔️ Flexibilní škálovací sady virtuálních počítačů s Linuxem ✔️

Pokud vytváříte generalizované vlastní image a ke zřizování používáte cloud-init, virtuální počítač se nemusí správně sestavit. V takovém případě analyzujte obrázek, abyste našli problém.

Příklady problémů se zřizováním:

  • Rozhraní API poskytovatele výpočetních prostředků vrátí chybu a cloud-init hlásí výsledný neúspěch.
  • Virtuální počítač se po dobu 40 minut zasekne a vytvoření virtuálního počítače se označí jako neúspěšné.
  • Vlastní data nebo uživatelská data se nezpracují.
  • Dočasný disk se nedaří připojit (pro varianty virtuálních počítačů, které přicházejí s SCSI disky zdrojů).
  • Uživatelé se nevytvořili nebo dochází k problémům s uživatelským přístupem.
  • Sítě nejsou správně nastavené.
  • Selhání prohození souboru nebo oddílu

Tento článek vás provede postupem řešení potíží s cloud-init. Podrobnější podrobnosti najdete v podrobných informacích o cloud-init.

Upozornění

Tento článek odkazuje na CentOS, což je linuxová distribuce, která je ve stavu Ukončení podpory (EOS). Zvažte své použití a naplánujte podle toho. Další informace najdete v doprovodných materiálech CentOS End Of Life.

Řešení potíží se selháními hlášenými cloud-init a zaprotokolovanými jako chyba

Cloud-init generuje strukturované chyby při hlášení selhání do Azure během zřizování. Mezi tyto chybové zprávy patří důvod a podpůrná data (například časové razítko, identifikátor virtuálního počítače, adresa URL dokumentace atd.), které vám pomůžou prošetřit selhání.

Důvod Popis Činnost
nepodařilo se najít rozhraní DHCP Nebylo nalezeno žádné síťové rozhraní. Odstraňte a znovu vytvořte virtuální počítač. Pokud problém přetrvává, ujistěte se, že jsou nainstalovány síťové ovladače a jádro specifické pro Azure, a zkontrolujte diagnostiku spuštění, abyste ověřili, že je eth0 správně uvedeno.
selhání získání pronájmu DHCP Služba DHCP nereaguje kvůli přechodnému problému s platformou. Opětovné nasazení virtuálního počítače (odstranění a opětovné vytvoření) kvůli přechodnému problému s platformou DHCP Azure
nepodařilo se najít primární rozhraní DHCP Primární rozhraní DHCP nebylo nalezeno. Zkontrolujte diagnostiku spouštění a ujistěte se, že je pojmenované eth0 primární síťové rozhraní a není přejmenováno.
Časový limit připojení vypršel při dotazování IMDS Kvůli přechodnému problému s platformou, skupině zabezpečení sítě nebo konfiguraci brány firewall operačního systému může dojít k vypršení časového limitu připojení k IMDS. Odstraňte a znovu vytvořte virtuální počítač. Pokud problém přetrvává, ověřte, zda NSG nebo brána firewall operačního systému nebrání přístupu k IMDS.
Časový limit při čtení dotazování IMDS K vypršení časového limitu připojení k IMDS může dojít kvůli přechodnému problému platformy nebo konfiguraci brány firewall operačního systému. Odstraňte a znovu vytvořte virtuální počítač. Pokud problém přetrvává, ověřte, že brána firewall operačního systému nebrání přístupu k IMDS.
neočekávaná analýza metadat ovf-env.xml Poškozená metadata virtuálního počítače v souboru ovf-env.xml. Odešlete problém do cloud-init sledovače.
chyba při čekání na vypnutí hostitele Selhání během zpracování vypnutí hostitele Odešlete problém do cloud-init sledovače.
Agent Azure-proxy se nenašel Binární azure-proxy-agent soubor chybí. Ujistěte se, že je v obrazu nainstalovaný agent proxy Azure. Další informace o řešení potíží najdete v průvodci odstraňováním potíží s MSP.
Selhání stavu agenta Azure-proxy Agent proxy serveru oznámil chybu stavu. Zkontrolujte protokoly agenta proxy serveru a v případě potřeby aktualizujte. Další informace o řešení potíží najdete v průvodci odstraňováním potíží s MSP.
neošetřená výjimka Uvnitř cloud-init došlo k neočekávané chybě. Odešlete problém do cloud-init sledovače.

Nápovědu k povolení a kontrole diagnostiky spouštění najdete v tématu Diagnostika spouštění.

Pokud některé z těchto problémů potrvají při následujících pokusech o zřízení, příčinou je chybná konfigurace obrazu. Pokud je důvod se domnívat, že je problém s cloud-init, nahlaste jej na GitHub Issue Tracker pro cloud-init.

Řešení potíží s jinými selháními, které nehlásí cloud-init

V závislosti na selhání zvažte tyto kroky.

Krok 1: Testování nasazení bez customData

Cloud-init může akceptovat customData, když je virtuální počítač vytvořen. Nejprve byste měli zajistit, aby tato konfigurace nezpůsobovala žádné problémy s nasazeními. Mezi běžné problémy patří:

  • YaML je poškozený.
  • Skripty uvnitř customData selžou nebo zablokují
  • Přepsání něčeho, co cloud-init využívá (například nastavení disku nebo sítě)
  • Data obsahují nepodporované znaky nebo problémy s kódováním. Pokuste se zřídit virtuální počítač bez předání jakékoli konfigurace. Pokud se virtuální počítač nepodaří zřídit, postupujte podle doporučených kroků pro řešení potíží. Pokud se konfigurace nepoužije, projděte si krok 4.

Krok 2: Kontrola požadavků na image

Hlavní příčinou selhání zřizování virtuálních počítačů je, že image operačního systému nesplňuje požadavky na provoz v Azure. Před pokusem o jejich zřízení v Azure se ujistěte, že jsou vaše image správně připravené.

Následující články ukazují postup přípravy různých distribucí Linuxu podporovaných v Azure:

U podporovaných imagí Cloud-init Azure už distribuce Linuxu mají všechny požadované balíčky a konfigurace pro správné zřízení image v Azure. Pokud zjistíte, že se vám nedaří vytvořit virtuální počítač z vlastní kurátorované image, vyzkoušejte podporovanou image Azure Marketplace, která je už nakonfigurovaná pro cloud-init, a to s volitelnou možností customData. Pokud customData funguje správně s obrázkem Azure Marketplace, pravděpodobně je problém s vaším přizpůsobeným obrázkem.

Krok 3: Shromažďování a kontrola protokolů virtuálních počítačů

Když se nepodaří zřídit virtuální počítač, Azure zobrazí stav "vytváří se" na 20 minut, poté virtuální počítač restartuje a čeká dalších 20 minut, než nakonec označí nasazení virtuálního počítače jako neúspěšné, a poté ho označí chybou OSProvisioningTimedOut.

Zatímco je virtuální počítač spuštěný, potřebujete protokoly z virtuálního počítače, abyste pochopili, proč zřizování selhalo. Pokud chcete zjistit, proč se zřizování virtuálního počítače nezdařilo, nezastavte virtuální počítač. Nechte virtuální počítač spuštěný. Abyste mohli shromažďovat protokoly, musíte ponechat virtuální počítač, který selhal, ve spuštěném stavu. Pokud chcete shromáždit protokoly, použijte jednu z následujících metod:

Poznámka:

Případně můžete ručně vytvořit záchranný virtuální počítač pomocí webu Azure Portal. Další informace najdete v tématu Řešení potíží s virtuálním počítačem s Linuxem připojením disku s operačním systémem k virtuálnímu počítači pro obnovení pomocí webu Azure Portal. Pokud chcete začít s počátečním řešením potíží, začněte sériovými protokoly a protokoly cloud-init, abyste pochopili, kde k chybě došlo. Pak použijte další protokoly pro hlubší analýzu a pomozte tak získat další poznatky.

Ve všech protokolech začněte hledat výrazy „Failed,“ „WARNING,“ „WARN,“ „err,“ „error,“ a „ERROR.“ Doporučujeme nastavit konfiguraci pro ignorování hledání s rozlišováním velkých a malých písmen.

Případně pomocí příkazu cloud‑init collect‑logs shromážděte všechny potřebné protokoly. Nejnovější verze cloud-init Azure (≥ 18.2) zahrnují příkaz collect-logs, který:

Shromažďuje základní protokoly: /var/log/cloud-init*.log, metadata instancí, systémové informace.

Zabalí všechno do archivu .tar.gz s časovým razítkem.

Uloží archiv místně (například /tmp/cloud-init-logs-timestamp.tar.gz).

Návod

Pokud řešíte potíže s vlastním obrazem, měli byste zvážit přidání uživatele během vytváření obrazu. Pokud se proces zřizování nepodaří nastavit uživatele správce, můžete se stále přihlásit k operačnímu systému.

Analýza protokolů

Tady jsou další podrobnosti o tom, co hledat v jednotlivých logech cloud-init.

/var/log/cloud-init.log

Ve výchozím nastavení jsou všechny události cloud-init s prioritou ladění nebo vyšší, zapsány do /var/log/cloud-init.log. Tento protokol poskytuje podrobné protokoly všech událostí, ke kterým došlo během inicializace cloud-init.

Například:

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

Když zjistíte chybu nebo upozornění, přečtěte si zpětně v protokolu cloud-init, abyste pochopili, co se cloud-init pokusil předtím, než došlo k chybě nebo upozornění. V mnoha případech cloud-init spouští příkazy operačního systému nebo provádí kroky zřizování dříve, než dojde k chybě. Tyto akce můžou pomoct vysvětlit, proč se chyba zobrazuje v protokolech. Následující příklad ukazuje, že se cloud-init pokusil připojit zařízení přímo před tím, než došlo k problému.

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)

Pokud máte přístup k sériové konzole, můžete zkusit znovu spustit příkaz, který se cloud-init pokusil spustit.

Protokolování /var/log/cloud-init.log lze také překonfigurovat v rámci /etc/cloud/cloud.cfg.d/05_logging.cfg. Další informace o protokolování cloud-init najdete v dokumentaci ke cloud-init.

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

Informace můžete získat z stdout fází cloud-init a stderr během těchto fází. Tato data obvykle zahrnují informace o směrovací tabulce, síťové informace, ověřovací informace stdout, o klíči hostitele ssh a stderr pro každou fázi cloud-init spolu s časovými razítky. V případě potřeby stderr je stdout možné protokolování překonfigurovat z /etc/cloud/cloud.cfg.d/05_logging.cfg.

Protokoly sériového/spouštěcího prostředí

Cloud-init má více závislostí. Tyto závislosti jsou popsané v požadovaných požadavcích pro image v Azure, jako jsou sítě, úložiště, možnost připojení ISO a připojení a formátování dočasného disku. Každá z těchto závislostí může vyvolat chyby a způsobit selhání cloud-init. Pokud virtuální počítač například nemůže získat pronájem DHCP, cloud-init selže.

Pokud stále nemůžete izolovat, proč se cloud-init nepodařilo zřídit, musíte pochopit, jaké jsou fáze cloud-init a kdy se moduly spouští. Další informace najdete v tématu Podrobnější informace o cloud-init.

Krok 4: Prozkoumejte, proč se konfigurace nepoužívá

Ne každé selhání v cloud-init vede k závažnému selhání zřizování. Například, pokud použijete modul runcmd v konfiguraci cloud-init, a příkaz vrátí nenulový ukončovací kód, zřizování virtuálního počítače selže. K tomuto chování dochází, protože modul běží po základních krocích zřizování v prvních třech fázích cloud-init. Chcete-li zjistit, proč se konfigurace neaplikovala, projděte si ručně protokoly ve třetím kroku a moduly cloud-init. Například:

  • runcmd - Spouští se skripty bez chyb? Pokud chcete zajistit, aby se spouštěly podle očekávání, spusťte konfiguraci ručně z terminálu.
  • Instalace balíčků – má virtuální počítač přístup k úložištím balíčků?
  • customData Zkontrolujte konfiguraci, která byla k virtuálnímu počítači k dispozici. Tento soubor je umístěn v /var/lib/cloud/instances/<unique-instance-identifier>/user-data.txt.

Další kroky

Pokud cloud-init přeskočí konfiguraci, prozkoumejte jednotlivé fáze cloud-init a načasování spuštění modulu a zjistěte příčinu. Další informace najdete v tématu Podrobnější informace o konfiguraci cloud-init.

  • Last updated on