Skip to main content

6.2 Diagnostika problémov a prevencia

V ideálnom svete by server IoT stačilo len nainštalovať podľa návodu a už nič viac neriešiť. Realita je však iná a je treba pripraviť sa na rôzne komplikácie.

Diagnostické nástroje

Niekedy sa stane, že niečo nám nefunguje. V takejto situácii je dobré poznať aspoň niektoré základné nástroje pre získanie informácií a diagnostiku:

# informácie o systéme a OS
hostnamectl # komplexné informácie o OS, kerneli, základnej doske, BIOS verzii
uname -a # základné informácie o OS

# pamäte a voľné miesto
df -h # voľné miesto na diskoch
free # využitie operačnej pamäte
btop # prehľadný monitoring CPU, pamäte, disku, siete a procesov

# hardvér
lscpu # detailné informácie o CPU
lsusb # zoznam USB zariadení
lsblk # zoznam diskov

Použité nástroje by mali byť súčasťou každej inštalácie Linuxu, s výnimkou btop, ktorý sme si nainštalovali v predošlej kapitole.

Testovanie stability

Pokiaľ to so serverom myslíme vážne, základnou požiadavkou je jeho spoľahlivosť a stabilita. Tá môže byť ohrozená aj chybami hardvéru, najčastejšie chybnými pamäťovými modulmi, či nedostatočným chladením pri plnej záťaži. Preto je vhodné pred nasadením servera a pri každej zmene pamätí vykonať diagnostiku. Záťažové testy simulujú extrémne podmienky, ktoré môžu odhaliť skryté chyby napájania alebo chladenia ešte predtým, než serveru zveríte dôležité údaje.

Môžeme na to využiť testy stress-ng a memtester, dostupné cez APT:

apt install stress-ng memtester

Ukážka konkrétnych testov:

# test CPU a cache (cca 10 minút):
stress-ng --class cpu-cache --cache-enable-all --seq 0 --verify --tz --verbose --timeout 10

# maximálne zahriatie CPU, sekvenčne a paralelne (cca 10 minút):
stress-ng --cpu 0 --cpu-method fft --vecwide 0 --vnni 0 --str 0 --wcs 0 --cpu 0 --verify --tz --seq 0 --timeout 100
stress-ng --cpu 0 --cpu-method fft --vecwide 0 --vnni 0 --str 0 --wcs 0 --verify --tz --timeout 600

# testy pamäte (cca 10 minút):
stress-ng --class memory --seq 1 --verify --verbose --timeout 10
stress-ng --vm 1 --vm-bytes 75% --verify --timeout 600

# cyklický dôkladný test pamäte:
memtester {veľkosť}G # treba zadať maximálne 90 % *voľnej* operačnej pamäte

Stav disku

Samostatným problémom je stav disku. Niekedy disk slúži len ako miesto pre uloženie súborov operačného systému, aby mohol naštartovať, no často je to aj miesto ukladania údajov, o ktoré by sme len neradi prišli bez varovania.

S.M.A.R.T.

Väčšina diskov podporuje monitoring stavu S.M.A.R.T. (Self-Monitoring, Analysis, and Reporting Technology), z ktorého vieme zistiť zaujímavé údaje, ako napríklad počet hodín prevádzky, počet štartov, počet chybných blokov, teplotu a podobne. Pre zistenie týchto zaujímavých údajov slúži program smartctl, ktorý je treba najskôr nainštalovať:

apt install smartmontools

A následne už môžeme získavať informácie - v uvedených príkazoch je treba {disk} uviesť konkrétne, napríklad /dev/sda alebo /dev/nvme0n1 - zoznam diskov získame príkazom lsblk:

smartctl -i {disk} # detailné informácie o modeli disku
smartctl -H {disk} # celkový stav (PASSED / FAILED)
smartctl -A {disk} # detailné informácie o stave disku

Stavové parametre S.M.A.R.T.

Posledný uvedený príkaz vypíše mnoho informácií, z hľadiska bezpečnosti uložených údajov nás na SATA diskoch (HDD i SSD) zaujímajú predovšetkým tieto parametre, ktoré by v ideálnom prípade mali byť na hodnote 0:

  • 5 - Reallocated_Sector_Ct (počet premapovaných sektorov): Týka sa mechanického HDD (fyzické poškodenie platne), ale aj SSD (opotrebované bunky flash pamäte). Keď disk nájde fyzicky poškodené miesto, označí ho za zlé a nahradí ho „náhradným“ sektorom zo špeciálnej rezervnej oblasti. Ak toto číslo rastie, disk sa rozpadá. Ak je číslo stabilné, disk sa dá ešte používať, ale už mu netreba veriť.

  • 197 - Current_Pending_Sector (čakajúce sektory): Sektory, ktoré disk nevedel prečítať a „čakajú na verdikt“. Akonáhle na ne disk úspešne zapíše dáta, zistí, či sú v poriadku  alebo ich musí premapovať (presunúť do ID 5). Týka sa to mechanického HDD - pri SSD sa nečaká, rieši sa okamžite.

  • 198 - Offline_Uncorrectable (neopraviteľné sektory): Sektory, ktoré disk nedokázal opraviť ani pomocou vlastných mechanizmov pri vnútornom teste. Sú nenávratne stratené.

  • 199 - UDMA_CRC_Error_Count (chyby prenosu): Toto nehovorí o zdraví platní, ale o probléme s káblom alebo konektorom. Ak toto číslo nie je 0, pravdepodobne je zlý SATA kábel alebo zlý kontakt.

Ďalšie informácie sú skôr štatistické, ale môžu nás zaujímať:

  • 9 - Power_On_Hours (počet hodín prevádzky): Pre mechanický HDD je to „tachometer“ - staré disky sú náchylnejšie na mechanickú únavu ložísk a motora. Pre SSD má nižšiu výpovednú hodnotu, no i elektronické súčiastky „starnú“.
  • 12 - Power_Cycle_Count (počet zapnutí): Koľkokrát bol disk zapnutý/vypnutý. Pre mechanický disk je najväčší stres práve štart (roztočenie platní). Disk, ktorý beží 5 rokov v kuse, je na tom často lepšie ako ten, ktorý bol 5 rokov zapínaný 10-krát denne. V prípade SSD nie je tento údaj až tak podstatný, no príliš vysoké číslo môže poukazovať na problémy s napájaním.

  • 194 - Temperature (teplota): Teplota mechanického HDD by nemala dlhodobo presahovať 45 - 50 °C. Každých 10 stupňov navyše drasticky skracuje životnosť ložísk a magnetickej vrstvy. V prípade SSD je kritická hranica cca 70 °C, pri prehrievaní disk začne spomaľovať.

Testovanie S.M.A.R.T.

Na SATA diskoch (nie NVMe) môžeme spustiť aj S.M.A.R.T. testovanie - počas neho je možné disk používať, no bude spomalený a neodporúča sa to. Lepšie je testovať mimo prevádzky (napríklad v noci):

smartctl -t short {disk} # spustenie rýchleho testu (cca 2 až 5 minút)
smartctl -t long {disk} # spustenie dlhého testu (cca 1 noc)
smartctl -l selftest {disk} # protokol posledných testov

NVMe disky

V prípade NVMe diskov je situácia mierne odlišná - autodiagnostiku si robia priebežne počas prevádzky a neumožňujú spúšťať test manuálne. Zistené údaje nemajú číselné ID a sú trochu inak pomenované:

  • Critical Warning: U NVMe diskov je toto najdôležitejšie pole. Na rozdiel od SATA diskov, kde musíme sledovať desiatky atribútov, NVMe zjednodušuje diagnostiku do tohto kritického indikátora. Ak je tam 0x00, všetko je OK. Akékoľvek iné číslo znamená prehrievanie alebo vážnu hardvérovú chybu.
  • Available Spare: Je to ekvivalent k 5 - Reallocated_Sector_Ct, ale obrátene - určuje, koľko je ešte k dispozícii záložnej kapacity, teda 100 % je ideálny stav nového disku. SSD má vždy niečo „navyše“, čo nie je viditeľné pre používateľa. Keď nejaká pamäťová bunka umrie, disk ju nahradí bunkou z tejto zálohy.
  • Media and Data Integrity Errors: Ak je tu niečo iné ako nula, disk má problém s pamäťovými čipmi a začína prichádzať o dáta.
  • Percentage Used: SSD majú obmedzený počet zápisov. Toto číslo ide od 0 % (nový) do 100 % (opotrebovaný). Keď dosiahne 100 %, neznamená to, že hneď umrie, ale už prekročil záruku výrobcu na počet zápisov.
  • Data Units Written: Udáva, koľko dát (logických jednotiek, zväčša 1000 sektorov po 512 B) disk už zapísal. Výrobcovia garantujú napríklad 600 TB pre 1 TB disk.
  • Údaje Power On Hours, Power Cycles a Temperature majú rovnaký význam, ako pri SATA SSD (uvedené vyššie).

Aktualizácia firmvéru

Kým softvér aktualizujeme cez APT, na aktualizáciu hardvéru (jeho firmvéru) slúži nástroj fwupd. Ten je v praxi použiteľný najmä pre mini PC s architektúrou x86 od výrobcov ako Dell (modely Optiplex), Lenovo (ThinkCentre), HP (EliteDesk, ProDesk, Z-Workstation), či Intel (NUC). Ostatní výrobcovia túto formu, žiaľ, veľmi nepodporujú.

Poznámka: Na Raspberry Pi sa pre tento účel používa špecifický nástroj rpi-eeprom-update.

Tento nástroj dokáže priamo z terminálu aktualizovať firmvér, no vyžaduje, aby bol systém nainštalovaný v režime UEFI. Výrobcovia týmto spôsobom môžu posielať dôležité bezpečnostné záplaty nielen pre hlavný BIOS / UEFI základnej dosky, ale aj opravy pre SSD disky, sieťové karty, či TPM moduly. Pri IoT serveri, ktorý beží non-stop, chceme mať záplaty proti kritickým chybám, akými boli napríklad Spectre a Meltdown.

Použitie nástroja fwupd:

fwupdmgr refresh     # stiahnutie informácií o nových verziách
fwupdmgr get-devices # zobrazenie informácií o zariadeniach
fwupdmgr get-updates # kontrola dostupných aktualizácií
fwupdmgr update      # vykonanie aktualizácie

Pre vykonanie aktualizácie je po skončení procesu takmer vždy potrebný reštart systému. Či je to skutočne tak, zistíme prítomnosťou súboru /var/run/reboot-required.

Aktualizácia mikrokódu CPU

Okrem firmvéru existuje ešte jedna špecifická vrstva „opráv“ hardvéru -  mikrokód procesora. Sú to drobné opravy chýb v logike procesora od výrobcov Intel alebo AMD. Hoci sa tieto opravy môžu dostať do počítača cez aktualizáciu BIOSu, výrobcovia základných dosiek ich často vydávajú so značným oneskorením.

Operačný systém Linux však dokáže tieto opravy aplikovať sám pri každom štarte (bootovaní). Je to najrýchlejšia cesta, ako zabezpečiť procesor proti známym zraniteľnostiam, aj keď výrobca PC už nevydáva nové verzie BIOSu. Slúžia na to nástroje intel-microcode a amd64-microcode, ktoré sú v Linuxe bežne predinštalované a každá aktualizácia systému nainštaluje aj prípadné opravy mikrokódu.

Či je systém a procesor aktuálne v bezpečí a či má aplikované všetky dôležité záplaty, je možné kedykoľvek overiť nahliadnutím do systémových súborov:

tail /sys/devices/system/cpu/vulnerabilities/*

Tento príkaz vypíše zoznam známych hrozieb a pri každej z nich uvedie stav (napríklad Not affected alebo Mitigation). Ak je pri niektorej položke uvedené Vulnerable, znamená to, že počítaču chýba aktualizácia BIOSu alebo mikrokódu.

Prípadne si môžeme zobraziť len zraniteľnosti, možné varianty príkazu:

grep -r "Vulnerable" /sys/devices/system/cpu/vulnerabilities/
lscpu | grep "Vulnerable"

Žiaľ, nie vždy je dostupná oprava (hlavne pre staršie CPU), no v domácom prostredí IoT servera v LAN to zvyčajne nepredstavuje kritické bezpečnostné riziko.

Back to top