Stavíme vlastní NAS: monitoring našeho síťového úložiště

Většina toho, co si dnes projdeme, neplatí jen pro NAS. Můžete se inspirovat a aplikovat i na jakémkoliv serveru, který provozujete. Při přemýšlení o tom, co zvolit pro oznámení problémů, jsem se snažil brát ohled hlavně na méně zkušené uživatele. Dnes máme velkou hromadu možností a není jednoduché si vybrat něco, co nebude ve výsledku složitý kanón a zároveň tak nějak samo chytne všechno bez rozsáhlé konfigurace nebo velkého množství komponent.

Zvolil jsem e-mail, protože ten mají všichni a taky většina systémových služeb automaticky informuje správce e-mailem o problémech na diskovém poli, službách, či třeba bezpečnostním incidentu.

Postfix – oznámení e-mailem

Většinou používám ZFS pooly a také mdraid (systémové disky) a budu potřebovat dostávat důležité informace o stavu disků, ale i pole a jeho poolů. Abychom dnes dokázali rozumně odesílat e-maily, ideální cestou je použít již existující standardní poštovní službu s autorizací. Zároveň uděláme pár nastavení tak, aby nám všechny systémové e-maily přirozeně končily v našem mailboxu.

apt install postfix

Během instalace se nás to bude ptát na různé věci – prostě to proklikejte jako „Satellite system“ a něco vyplňte. Není zas tak důležité co, protože konfiguraci poté uděláme stejně ručně.

Používám Gmail a tedy chci, aby se NAS vůči němu autorizoval a posílal e-maily přes něj. Proč používat existující mailserver a neodesílat rovnou z NAS do internetu? Dokázali bychom to, ale aby to fungovalo dobře, potřebovali bychom tomu věnovat samostatný seriál. Navíc u mnohých z vás by to z řady technických důvodů pravděpodobně vůbec nebylo možné.

Doporučuji si pro tento účel vytvořit oddělený e-mailový účet, abyste v případě problému neohrozili ten, který používáte pro běžnou komunikaci. V mém případě třeba  mujmailpronas@gmail.com.

Otevřeme si /etc/postfix/main.cf a upravíme ho, aby vypadal následovně:

smtpd_banner = $myhostname ESMTP $mail_name
biff = no
# appending .domain is the MUA's job.
append_dot_mydomain = no
# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h
readme_directory = no

# See http://www.Postfix.org/COMPATIBILITY_README.html -- default to 3.6 on
# fresh installs.
compatibility_level = 3.6
header_checks = regexp:/etc/Postfix/header_check
# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_security_level=may
smtp_tls_CApath=/etc/ssl/certs
smtp_tls_security_level=may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_mechanism_filter = plain, login
smtp_sasl_password_maps = hash:/etc/Postfix/sasl_password
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = nas.domena.tld
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = nas.domena.tld, $myhostname, host.domena, localhost
relayhost = [smtp.gmail.com]:587
relay_domains = nas.domena.tld
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 172.16.0.0/8
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all

Jak si můžete všimnout, všude používáme nas.domena.tld, tak, jak jsme si to nasměrovali v části pro ownCloud. Je dobrým zvykem sjednotit si hostname a doménu i v systému. Vnímavému oku určitě neuteklo ani 172.16.0.0/8 pokrývající IP rozsah pro dockerové služby, které můžou odesílat e-maily přes Postfix na hlavním systému.

Sjednotíme si hostname:

echo "nas" > /etc/hostname
echo "nas.domena.tld" > /etc/mailname
hostnamectl set-hostname nas

Kontrola správnosti – spustíme příkazy a měli bychom vidět:

> hostname
nas
> hostname -f
nas.domena.tld

Trochu jsme odbočili od Postfixu – zpátky k věci. V konfiguraci totiž odkazujeme na soubory, které jsme zatím nevytvořili.

Vytvoříme /etc/postfix/header_check:

/^From: .*$/ REPLACE From: mujmailpronas@gmail.com
/^Subject: (.+)$/i REPLACE Subject: [nas] $1
/^To:.*$/ REDIRECT muj@osobni.mail

• První řádek přepíše hlavičku From tak, aby odpovídala e-mailu, který používáme pro odesílání. Jinak by vám to Gmail odmítl, protože třeba root@localhost  pro něj není legitimní odesílatel.
• Druhý řádek přidá do předmětu e-mailu prefix „[nas]“, což se hodí, pokud provozujete víc podobných systémů a chcete je snadno rozlišit. Nemusíte použít, pokud nechcete.
• Poslední řádek přesměruje e-mail tam, kam chcete, aby dorazil.

Ještě zbývá vytvořit poslední soubor. Gmail pro autorizaci používá SSO a OAuth. To Postfix zatím neumí, takže ho to musíme „naučit“, nebo spíš to obejít. V nastavení vašeho gmailového účtu (account.google.com), který budete používat pro odesílání e-mailů, si nastavíte heslo pro konkrétní službu. Stačí jít do Security → 2 Step Verification → App passwords.

Poznámka: Pokud tam App Passwords nenajdete, zkuste kliknout na tento odkaz a vytvořte si password. Proč to poprvé není vidět, to netuším.

Vyplníte název aplikace a kliknete na „Create“.

Google vám heslo vygeneruje, zobrazí ho a tohle heslo pak umístěte do souboru /etc/postfix/sasl_password. Použijte jej normálně, bez mezer, všechno dohromady.

Vytvoříme /etc/postfix/sasl_password:

[smtp.gmail.com]:587 mujmailpronas@gmail.com:mojevygenerovaneheslo

Tento soubor je typu hash, takže ho ještě musíme převést na databázový formát:

> cd /etc/postfix
> postmap sasl_password
# tímto příkazem vznikne soubor sasl_password.db

To je všechno — můžeme restartovat Postfix:

> systemctl restart postfix

Test odesílání pošty

Pro otestování si nainstalujeme mailutils a zkusíme poslat e-mail. Měl by nám dorazit.

# Instalace mail utils
apt install -y mailutils

# Odešleme testovací emaily, měli by dorazit oba na muj@osobni.mail
echo 'Hello World' | mail -s Testovaci muj@osobni.mail
echo 'Hello World' | mail -s TestRoot root@localhost

# Pokud nedorazili, mrkneme jestli nevisí v mail queue
mailq

# Podívame se do logu co se stalo
grep -C2 muj@osobni.mail /var/log/mail.log

Poznámka: Pokud použijete jinou e-mailovou službu, postup je stejný a lišit se bude jen část nastavení hesla u konkrétní služby a obsah souboru  /etc/postfix/sasl_password.

Sběr metrik

Tohle téma není vůbec malé, ale zkusím ho rozdělit do jednotlivých částí a pokud možno co nejvíc zjednodušit. Uznávám ale, že pro mnohé uživatele toho bude moc a zřejmě to ani nepotřebují. Pokud jste jedním z nich, můžete sběr metrik a Grafanu přeskočit. Důležité informace ze serveru vám dorazí e-mailem.

V dnešní době máme k dispozici širokou škálu možností, jak monitorovat. Já jsem si vybral cestu, která je podle mě nejjednodušší, s co nejmenším množstvím komponent, a přitom plně funkční. Schéma je jasné: o sběr se stará Telegraf, data ukládáme do InfluxDB a na tu napojíme Grafanu pro vizualizaci statistik. Obojí si můžete spustit pomocídocker compose přímo na NAS (stejně jako ownCloud), nebo využít cloudové instance.

Telegraf a Grafana

Já už mám tyto dvě komponenty spuštěné jinde, takže se dál soustředíme primárně na Telegraf a Grafana dashboard.

Telegraf nainstalujeme podle oficiálního návodu. Pokud budete spouštět i InfluxDB, nezapomeňte si v dokumentaci projít části o politice uchovávání dat (retention policy) a průběžném dotazování (continuous queries). Jedna věc je totiž data do úložiště sypat, ale je potřeba i určit, jak dlouho je tam chcete držet a co se má stát se staršími daty.

Následně připravíme /etc/telegraf/telegraf.conf a zaměříme se jen na důležité části:

[global_tags]
dc = "home"
[agent]
interval = "10s"
…

Global tags je část, kde můžeme přidat nějaké globální tagy, které se připojí ke každé sbírané metrice. Já už v InfluxDB sleduji několik systémů a rozlišuji „datacentrum“, takže v tomto případě je pro mě datacentrem  home. Část agent.interval pak určuje, jak často chcete metriky sbírat.

[[outputs.influxdb]]
urls = ["https://influxdb.host:8086"]
username = "telegraf"
password = "heslo"
skip_database_creation = true

V této části definujeme výstup, kam budeme metriky ukládat. V mém případě je to tedy databáze InfluxDB. Volbu skip_database_creation  používám, protože uživatel telegraf v mém nastavení nemá administrátorská práva nad celou databází – může do ní jen zapisovat. Tímto nastavením mu říkáte, ať se nepokouší databázi vytvářet, protože by to stejně skončilo chybou. Teď ta nejdůležitější část – nadefinujeme své input pluginy, které se postarají o sběr metrik.

  [[inputs.cpu]]
  percpu = true
  totalcpu = true
  collect_cpu_time = false
  report_active = false

  [[inputs.disk]]
    ignore_fs = ["tmpfs", "devtmpfs", "devfs", "iso9660", "overlay", "aufs", "squashfs"]
  [[inputs.diskio]]
  [[inputs.kernel]]
  [[inputs.mem]]
  [[inputs.processes]]
  [[inputs.swap]]
  [[inputs.system]]
  [[inputs.docker]]
    endpoint = "unix:///var/run/docker.sock"
  [[inputs.linux_sysctl_fs]]
  [[inputs.net]]
  interfaces = ["enp1s0","enp2s0","enp3s0","enp4s0"]
  [[inputs.netstat]]
  [[inputs.nstat]]
  [[inputs.zfs]]
  [[inputs.sensors]]
  [[inputs.Postfix]]
  [[inputs.exec]]
    commands = ["/root/management/raid_monitor.sh"]
    data_format = "influx"
  [[inputs.exec]]
  commands = ["/root/management/disk-state-status.sh"]
  timeout = "30s"
  data_format = "influx"
  interval = "60s"
  name_suffix = ""

Poslední dva inputs.exec jsou moje vlastní metriky. Chtěl jsem mít zvlášť metriku, kde uvidím stav pole RAID — jak mdraid, tak ZFS. Druhý skript vytváří metriky pro stav disků, konkrétně jejich stav napájení (power state). Chci vědět, kdy se disky probouzejí a jestli je to často, abych dokázal najít příčinu. Můj záměr je, aby se disky probouzely jen tehdy, když jako uživatel opravdu přistupuji k datům.

Zastavím se ještě u inputs.sensors. Tady je potřeba zprovoznit lm-sensors. Je to jednoduchá sada nástrojů, která umožní sledovat senzory na základní desce — teploty, otáčky ventilátorů, provozní napětí a další hodnoty.

apt install lm-sensors

Po instalaci je potřeba spustit detekční utilitu sensors-detect. Během procesu detekce na vás vyskočí řada otázek — na všechny odpovězte YES a nechte doběhnout celý test.

Na konci vám utilita vypíše seznam modulů jádra, které je potřeba mít načtené, aby senzory fungovaly. Na otázku, jestli se mají tyto moduly přidat do automatického načítání, dejte taky YES. Pokud všechno proběhne správně, po spuštění příkazu sensors byste měli vidět něco jako:

coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +42.0°C (high = +84.0°C, crit = +100.0°C)
Core 0: +39.0°C (high = +84.0°C, crit = +100.0°C)
Core 1: +40.0°C (high = +84.0°C, crit = +100.0°C)
acpi-0
Adapter: ACPI interface
temp1: +45.0°C (crit = +105.0°C)

Ještě jedna drobnost: přidejte si mezi načítané moduly i drivetemp. Stačí ho přidat na nový řádek v souboru /etc/modules. Díky tomuto modulu pak přes sensors uvidíte i teploty disků — a to určitě chceme sledovat taky.

Monitorujeme poměrně hodně věcí, včetně senzorů, a na spoustu z nich je potřeba mít rootovská oprávnění. Máte dvě možnosti:

• buď si dáte tu práci a přidáte uživatele telegraf do všech potřebných skupin a upravíte práva ke stavovým souborům a socketům,
• nebo spustíte Telegraf agenta pod uživatelem root.

Já jsem zvolil jednodušší cestu. Stačí pomocí příkazusystemctl edit telegraf.service přidat následující dva řádky

[Service]
User=root

Poté je potřeba ještě agenta restartovat:

systemctl restart telegraf.service

Když už máme všechno potřebné v InfluxDB, můžeme připravit dashboard. Pro začátek můžete použít můj dashboard a rozšiřovat si ho podle potřeby.

Dashboard nám dává rychlý přehled o tom, jak na tom naše NAS je — ukáže teploty, využití CPU a paměti, ale taky přehled jako Timeline Raid Status nebo Disk Power State. Právě power state je zajímavý z pohledu toho, jak často se disky probouzejí. Je hezky vidět, že za posledních 12 hodin se disky probudily jen jednou – na 20 minut – a to během snapshotování dat. Pátý disk se probouzí jen při kopírování snapshotů na záložní disk.

Monitoring disků

Pro monitoring disků použijeme funkcionalitu S.M.A.R.T., kterou jsme už zmiňovali. Nainstalujeme balík smartmontools, který mimo jiné obsahuje démona, jenž disky průběžně sleduje.

apt install smartmontools

Upravíme soubor /etc/smartd.conf následovně. Vypadá to možná trochu krypticky, ale vysvětlíme si to:

/dev/nvme0n1 -a -o on -S on -s (S/../.././02|L/../../6/03) -W 10,40,49 -d nvme -m mujkontaktni@e-mail.tld
/dev/nvme1n1 -a -o on -S on -s (S/../.././02|L/../../6/03) -W 10,40,49 -d nvme -m mujkontaktni@e-mail.tld
/dev/disk/by-id/ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N0997268 -a -o on -S on -s (S/../.././02) -W 10,40,50 -d sat -m mujkontaktni@e-mail.tld -l scterc,70,70 -e standby,240
/dev/disk/by-id/ata-WDC_WD30EFRX-68EUZN0_WD-WMC4N0368142 -a -o on -S on -s (S/../.././02) -W 10,40,50 -d sat -m mujkontaktni@e-mail.tld -l scterc,70,70 -e standby,240
/dev/disk/by-id/ata-WDC_WD30EFRX-68EUZN0_WD-WMC4N0481373 -a -o on -S on -s (S/../.././02) -W 10,40,50 -d sat -m mujkontaktni@e-mail.tld -l scterc,70,70 -e standby,240
/dev/disk/by-id/ata-WDC_WD30EFRX-68EUZN0_WD-WMC4N0528897 -a -o on -S on -s (S/../.././02) -W 10,40,50 -d sat -m mujkontaktni@e-mail.tld -l scterc,70,70 -e standby,240
/dev/disk/by-id/ata-WDC_WD80EFPX-68C4ZN0_WD-RD2N8LPH -a -o on -S on -s (S/../.././02) -W 10,40,50 -d sat -m mujkontaktni@e-mail.tld -l scterc,70,70 -e standby,240

• /dev/disk/by-id/...  — cesta k blokovému zařízení. Používám ji schválně, protože jednoznačně identifikuje konkrétní disk. U některých řadičů se totiž může stát, že se pořadí zařízení (sda, sdb…) po restartu změní.
• -a  — aktivuje všechny standardní kontroly atributů.
• -o on  — zapne sběr automatických offline selftestů disku.
• -S on  — povolí automatické ukládání atributů.
• -s (S/...)  — plánování selftestů. V tomto případě každý den ve dvě ráno.
• -W 10,40,50  — teplotní limity: Low, Warning, Critical.
• -d sat  — volitelný parametr. U některých řadičů je potřeba, aby SMART fungoval správně. Více viz  man 5 smartd.conf.
• -m  — e-mail, kam se mají posílat notifikace (řeší náš Postfix).
• -l scterc,70,70  — nastavení error recovery. Pokud dojde k chybě, disk nebude systém blokovat déle než 70 sekund.
• -e standby,240  — uspávání disku po 240 intervalech (1 interval = 5 s, tedy 20 minut).

Restartujeme službu smartmontools a zkontrolujeme log, jestli při startu nedochází k chybám — tohle si vždycky ověřte, kdykoliv změníte konfiguraci!

  systemctl enable smartmontools.service
  systemctl restart smartmontools.service

  # Logs
  journalctl -f -n 100 -u smartmontools.service

Monitorování diskového pole

V našem případě používámemdadm a ZFS. Pokud máte nainstalovaný balíčekmdadm (a to nejspíš máte), sám se o oznámení postará a uživateliroot standardně doručí informace o problémech. Díky úpravám Postfixu, které jsme provedli, není potřeba řešit nic dalšího — všechny e-maily pro lokální uživatele dorazí správci NAS na Gmail.

U ZFS je situace podobná, jen si dejte pozor, aby byla aktivní služba  zfs-zed:

systemctl enable zfs-zed.service
systemctl start zfs-zed.service

Příště budeme zabezpečovat

V další části se můžete těšit pro změnu na trochu bezpečnosti. Dáme si nějaké základní rady do začátku.

Zdroje

• Všechny zdroje z článku jsou dostupné v repozitáři: github.com/rvojcik/nas-diy-resources
• Postfix Documentation
• Telegraf Documentation
• InfluxDB Documentation
• Grafana Dashboard

(Autorem obrázků je Robert Vojčík.)