Domoticz cz. 8 – Stabilna praca Domoticza w trybie 24/7/365 – wysoka dostępność aplikacji w domu

Domoticz cz. 8 – Stabilna praca Domoticza w trybie 24/7/365 – wysoka dostępność aplikacji w domu

Domoticz od początku swojego istnienia próbował pogodzić wiele różnych celów:

  • dostępność różnych wtyczek i sprzętu
  • pomysły na automatyzację użytkowników
  • skrypty (LUA i niedawno Python) i mechanizmy if, then, else
  • integrację gotowych rozwiązań firm trzecich
  • integrację bibliotek open-source
  • obsługę różnych platform sprzętowych, w tym SBC, które często mają własne ograniczenia sprzętowe oraz wydajnościowe

W efekcie często początkujący jak i zaawansowany użytkownik system trafia na sytuację, gdy działający do dziś system – przestaje działać w ogóle, wymaga częstych restartów lub wznawiania usługi, albo też powoduje szybsze zużycie nośników danych – które są narażone na szybsze zużycie.

Czy istnieje proste i skuteczne rozwiązanie podnoszące dostępność Domoticza na Raspberry Pi/Orange Pi?

Oczywiście. Najpierw KONIECZNIE zrób kopię karty (micro)SD z Raspberry Pi/Orange Pi.
UWAGA: Będziemy wykonywać operacje które mogą doprowadzić do utraty wszystkich danych – upewnij się więc że masz kopię!

Czego będziemy potrzebować?

Software:

  • monit
  • rsync

Hardware:

  • dysk twardy HDD lub SSD, mały dysk SSD jest preferowany – od 32GB do 128GB
  • trzy sztuki radiatorów dla Raspberry Pi/Orange Pi
  • adapter USB 2.0 lub 3.0 do SATA do podłączenia dysku przez wolny port USB

    Do dzieła!

    Plan jest bardzo prosty – należy podłączyć dysk twardy, przenieść (skopiować dane) na koniec sprawdzić czy mamy radiatory. Dysk typu SSD jest zalecany ze względu na długą żywotność i bezawaryjność oraz niewielki pobór mocy. Nawet dość stare konstrukcyjnie dyski, lub dyski z pamięciami NAND typu MLC/TLC – będą nam służyć bardzo długo. Na dysk przeniesiemy następujące zasoby:

/home – dom dla domoticza przy typie starszej instalacji
/root – tutaj także możemy spotkać domoticz’a
/var – często zmieniające się pliki

Wraz z przejściem na dysk twardy – nie należy zaniedbywać karty microSD; unikajmy kart no-name, o marnej reputacji, ale też weryfikujmy poprzez rejestrację na stronie producenta. Możemy również rozważyć karty „endurance”, ale zwykle ich cena zbliża się do ceny dysku twardego.

Po przeniesieniu szybko zmieniających się danych – ryzyko uszkodzenia karty ze względu na nieplanowany reset, czy też zużycie samej karty – będzie zdecydowanie zredukowane.
Pamiętaj także o umieszczeniu radiatorów – głównie na CPU, pamięci i kontrolerze. Stabilnie działające RPi – szczególnie wersja 3 – wymaga radiatorów.

Hardware – dysk SSD

Stojąc przed wyborem dysku musimy pamiętać o:

  • interfejs SATA
  • zasilanie 5V
  • pobór mocy – możliwe minimalny, najlepiej max 50% budżetu 800mA portu USB w Raspberry Pi 3, lub przy max_current=1 dla Raspberry Pi 2

Aby podłączyć dysk z interfejsem SATA, należy nabyć adapter USB-SATA dla dysków 2,5″ – przenoszący zintegrowane zasilanie. Godnymi polecenia są adaptery z jednym złączem USB 3.0 (niebieskie), zgodne z USB 2.0 oraz oparte na chipsecie JMicron. W przykładzie używam starego „mostka”, bez obsługi trim/ATA.

Należy przetestować podłączenie dysku do działającego Raspberry Pi, oraz podczas restartu – zwracamy uwagę czy nie zgaśnie czerwony LED, lub pojawi się ikona błyskawicy w przypadku podłączonego monitora przez HDMI/CVSB.

Po podłączeniu – identyfikujemy nowy dysk, dzięki komendzie „dmesg”:

[    5.649443] usb 1-1.3: new high-speed USB device number 6 using dwc_otg
[    5.782360] usb 1-1.3: New USB device found, idVendor=05e3, idProduct=0718
[    5.786326] usb 1-1.3: New USB device strings: Mfr=0, Product=1, SerialNumber=2
[    5.790444] usb 1-1.3: Product: USB Storage
[    5.794449] usb 1-1.3: SerialNumber: 000000000033
[    5.806179] usb-storage 1-1.3:1.0: USB Mass Storage device detected
[    5.814256] scsi host0: usb-storage 1-1.3:1.0
[    5.922077] gpiomem-bcm2835 3f200000.gpiomem: Initialised: Registers at 0x3f200000
[    6.362614] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[    6.902236] scsi 0:0:0:0: Direct-Access     INTEL SS DSA2CT040G3      0016 PQ: 0 ANSI: 4
[    6.917156] sd 0:0:0:0: [sda] 78165356 512-byte logical blocks: (40.0 GB/37.3 GiB)
[    6.933290] sd 0:0:0:0: [sda] Write Protect is off
[    6.933314] sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00
[    6.934475] sd 0:0:0:0: [sda] No Caching mode page found
[    6.934491] sd 0:0:0:0: [sda] Assuming drive cache: write through
[    6.941523]  sda: sda1
[    6.944631] sd 0:0:0:0: Attached scsi generic sg0 type 0
[    6.949765] sd 0:0:0:0: [sda] Attached SCSI disk

Interpretując dane zauważamy, że jeśli jest to jedyny zewnętrzny dysk, to będzie w systemie widziany jako /dev/sda, a dodatkowo pierwsza partycja to /dev/sda1. Należy następnie sforatować nasz nowy dysk (utracimy na nim wszystkie dane!) – wybieramy bezpieczny format – ext4. (można też rozważyć B-tree File System zwany też Butter FS – ale jednak mówimy tu o stabilności).

Zainstalujmy nowe oprogramowanie:

apt update
apt upgrade
apt install rsync monit

Formatujemy komendą na Raspberry Pi/Orange Pi, upewniając się, że jest to podłączony przez nas dysk! Formatowanie usunie wszystkie dane jakie znajdują się aktualnie na dysku.

mkfs.ext4 /dev/sda1

Następnie aby przetestować – montujemy – a więć mówimy systemowi operacyjnemu aby zaczął używać dysku:

mkdir -p /mnt/ssd
mount /dev/sda1 /mnt/ssd

W dmesg powinniśmy zobaczyć log:

[    7.744129] EXT4-fs (sda1): mounting with "discard" option, but the device does not support discard
[    7.754021] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: discard,commit=600,errors=remount-ro

Uzupełniamy plik /etc/fstab o następujące wpisy na początku:

/dev/sda1       /mnt/ssd        ext4    discard,noatime,commit=600,errors=remount-ro    0       1
/mnt/ssd/var    /var/           none    bind    0       1
/mnt/ssd/home   /home           none    bind    0       1
/mnt/ssd/opt    /opt            none    bind    0       1

Teraz należy wyłączyć wszystkie usługi oprócz sshd – po to aby przenieść ważne pliki systemowe na dysk SSD. Praktycznie taką operacją zgodnie ze sztuką należałoby wykonać na osobnym komputerze, bez uruchomionego systemu – ale ryzyko jest minimalne.

sudo su -
systemctl stop domoticz.sh
systemctl stop influx.service
systemctl stop grafana.service
systemctl stop cron.service
systemctl stop rsyslog.service
...

Kopiujemy zawartość /home /root i /var na SSD.

sudo rsync -avz /home /root /var /mnt/ssd/

Weryfikujemy:

ls -alR /mnt/ssd

Powinno nam dać długą listę plików i katalogów.
Reboot i po restarcie powinnyśmy zobaczyć:

sudo mount | grep sda1

Wynik:

/dev/sda1 on /mnt/ssd type ext4 (rw,noatime,discard,errors=remount-ro,commit=600,data=ordered)
/dev/sda1 on /root type ext4 (rw,noatime,discard,errors=remount-ro,commit=600,data=ordered)
/dev/sda1 on /home type ext4 (rw,noatime,discard,errors=remount-ro,commit=600,data=ordered)
/dev/sda1 on /var/ type ext4 (rw,noatime,discard,errors=remount-ro,commit=600,data=ordered)

Stabilne oprogramowanie – monit

Domoticz to program rozbudowany, często złożny z kodu o różnej jakości i dynamice rozwoju. W rezultacie, dodanie nawet niewinnego czujnika czy funkcji może spowodować destabilizację – nawet wersji stabilnej. Niezłym lekarstwem na syndrom „Domoticz offline” jest monit – program monitorujący działanie domoticza (oczywiście nie tylko) uruchamiający go ponownie, oraz posiadający schludny interfejs WWW.

Edytujemy plik /etc/monit/monitrc i odnajdujemy sekcję – która modyfikujemy (port 'httpd’ oraz TAJNE_HASLO):

## Monit has an embedded HTTP interface which can be used to view status of 
## services monitored and manage services from a web interface. The HTTP 
## interface is also required if you want to issue Monit commands from the
## command line, such as 'monit status' or 'monit restart service' The reason
## for this is that the Monit client uses the HTTP interface to send these
## commands to a running Monit daemon. See the Monit Wiki if you want to 
## enable SSL for the web server. 
#
 set httpd port 8888 and
    use address localhost  # only accept connection from localhost
    allow localhost        # allow localhost to connect to the server and
    allow admin:TAJNEHASLO # require user 'admin' with password 'monit'
    use address 0.0.0.0    # only accept connection from localhost (comment to connect from other hosts)
    allow 0.0.0.0/0.0.0.0     
    allow @monit           # allow users of group 'monit' to connect (rw)
    allow @users readonly  # allow users of group 'users' to connect readonly

Następnie na końcu tworzymy sekcję dla domoticza (zakładamy że pracuje na porcie 8080 i nie wymaga username/password dla połączeń z localhost):

check process domoticz with pidfile /var/run/domoticz.pid
  start program = "/etc/init.d/domoticz.sh start"
  stop  program = "/etc/init.d/domoticz.sh stop"
  if failed
     url http://127.0.0.1:8080/json.htm?type=command¶m=getversion
         and content = '"status" : "OK"'
     for 2 cycles
     then restart
  if 5 restarts within 5 cycles then exec "/sbin/reboot"

Uruchamiamy monit:

sudo systemctl enable monit.service
sudo systemctl restart monit.service

Uruchamiamy przeglądarkę i logujemy się na stronę adres IP domoticza, na wybrany port – tutaj 8888, logujemy się zgodnie z konfiguracją i powinniśmy otrzymać:
monit
Kilka uwag na koniec pierwszej części: Dyski SSD najlepiej używać wraz z obsługą trim, której większość mostków nie przenosi. Oznacza to, że najlepiej raz na pół roku – warto podłączyć przy okazji backupu karty micro SD nasz dysk SSD do większego PC z interfejsem SATA, a następnie wykonać komendę fstrim.

Jednocześnie pamiętaj – że takie rozwiązanie nie daje 100% gwaracji, ale jest krokiem do podniesienia stabilności i żywności systemu. W następnej części opiszę kopię i montowanie zasobów sieciowych (NFS) na zewnętrzny NAS, oraz użycie zasilania zapasowego (UPS).

Previous Post Next Post