A feladat története
A kisebb méretű cégek egyrészt igénylik az infrastruktúrájuk minőségi monitorozását (különösen a széleskörű virtualizáció fényében), másrészt pedig pénzügyi szempontból nehezen tudnak új berendezéseket vásárolni. Gyakran előfordulnak problémák a szerverrel/hardverrel: gyakran 1-3 tower-szerver áll a felhasználói munkahelyek mellett vagy egy kisebb fülkében.
Egyszerűbb egy kész disztribúciót használni, amit egyszerűen fel lehet tölteni egy microSD-kártyára, és behelyezni egy elterjedt egylapkás számítógépbe (beaglebone, raspberry pi és orange pi családok, asus tinker board). Ezenkívül az ilyen berendezések nem drágák, és bárhol telepíthetők.
Lépjünk át a kitűzött feladatra: írjunk egy XDP mechanizmust SYN cookie-kkal.
A projekt nagymértékben fejlődött, mint egyfajta laboratóriumi munka, a kialakult eredmények alkalmazásának lehetőségével.
A monitorozó rendszerként a zabbix került kiválasztásra, mivel ez egy erőteljes, ingyenes és jól dokumentált rendszer.
Kérdésként merült fel a hardver platform kiválasztása. Egy külön gép telepítése a monitorozásra szintén nem a legjobb megoldás — vagy drága új berendezéseket kell vásárolni, vagy régi berendezéseket keresni + a kisebb cégekben gyakoriak a szerver/hardver problémák.
A buildroot rendszer használata lehetővé teszi olyan speciális megoldások létrehozását, amelyeket olyan személyzet is üzemeltethet, akinek minimális ismerete van a Linux családról. Ez a rendszer barátságos a kezdők számára, de széleskörű testreszabási lehetőségeket kínál egy tapasztalt fejlesztő kezében. Kiválóan alkalmas egy megfizethető, mégis teljes funkcionalitású IT-infrastruktúra monitorozására, minimálisan követelve az üzemeltető személyzet felkészültségét.
A megoldás lépései
Először egy x86_64 firmware-t döntöttek el létrehozni a qemu-végrehajtás érdekében, mivel ez egy kényelmes és gyors megoldás a hibakereséshez. Ezt követően kellett portolni az arm egylapkás számítógépre (én az asus tinker board-ot választottam).
A buildroot rendszer került kiválasztásra a rendszerként. Kezdetben nem tartalmazta a zabbix csomagot, ezért azt portolni kellett. Voltak problémák az orosz lokalizációval, amelyek a megfelelő javítások alkalmazásával oldódtak meg (megjegyzés: az újabb buildroot verziókban ezek a javítások már nem szükségesek).
A zabbix csomag portolása külön cikkben lesz leírva.
Mivel mindennek úgy kell működnie, mint egy firmware-nek (változatlan rendszerkép + helyreállítható konfigurációs fájlok/adatbázisok), szükség volt saját systemd célok, szolgáltatások és időzítők (target, service, timer) írására.
A döntés a tároló két partícióra osztásáról született - az egyik a rendszerfájlok, a másik pedig a módosítható konfigurációk és a Zabbix adatbázis fájlok számára.
A legnagyobb nehézséget az adatbázissal kapcsolatos feladatok megoldása okozta. Nem volt kedvem az adatbázist közvetlenül a tárolón elhelyezni. Ugyanakkor az adatbázis mérete meghaladhatja a lehetséges ramdisk méretét. Ezért kompromisszumos megoldás született: az adatbázis a második partíción helyezkedik el az SD-kártyán (a modern SLC-kártyák akár 30 000 írási ciklust is elviselnek), de van egy beállítás, amely lehetővé teszi külső tároló használatát (például USB HDD).
A hőmérsékletfigyelést a RODOS-5 eszközön keresztül valósították meg. Természetesen a Dallas 1820-at közvetlenül is használhatnánk, de gyorsabb és egyszerűbb volt USB-portba dugni.
Az x86_64 rendszerindítójaként a grub2 lett kiválasztva. Szükség volt egy minimális konfiguráció írására a rendszer indításához.
A QEMU-n végzett hibakeresés után a portálás az ASUS Tinker Board-ra történt. Az overlay struktúrámban kezdetben a platformfüggetlenség érdekében a tányérokhoz specifikus konfigurációk (designdefconfig, bootloader, rendszerpartícióval rendelkező képfájl generálása) kiemelése és a fájlrendszer maximális egységessége/állomány generálása volt a cél. Ennek köszönhetően a portálás gyorsan zajlott.
Mindenképpen javasolt az alapvető cikkek elolvasása:
Hogyan kell összerakni
A repozitórium klónozása után a következő fájlstruktúra jön létre:
[alexey@comp monitor]$ ls -1
buildroot-2019.05.tar.gz
overlay
README.md
run_me.shbuildroot-2019.05.tar.gz — a tiszta buildroot archívuma
overlay — az én könyvtáram az external-tree-hez. Itt található minden szükséges fájl a firmware buildroot segítségével történő összeállításához
README.md — a projekt leírása és kézikönyv angol nyelven.
run_me.sh — egy szkript, amely előkészíti a buildelési rendszert. Kibővíti a buildroot-ot az archívumból, hozzákapcsolja az overlay-t (external-tree mechanizmuson keresztül) és lehetőséget ad a célplat formának a kiválasztására.
[0] my_asus_tinker_defconfig
[1] my_beaglebone_defconfig
[2] x86_64_defconfig
Válassza ki a defconfigot, nyomja meg az A-t a megszakításhoz. Alapértelmezett [0]Ezután elegendő belépni a buildroot-2019.05 könyvtárba, és végrehajtani a make parancsot.
A build results will be in the output/images directory after the build process finishes.
[alexey@comp buildroot-2019.05]$ ls -1 output/images/
boot.img
boot.vfat
bzImage
data
data.img
external.img
external.qcow2
grub-eltorito.img
grub.img
intel-ucode
monitor-0.9-beta.tar.gz
qemu.qcow2
rootfs.cpio
sdcard.img
sys
updateNeeded files:
- sdcard.img — a media image for writing to an SD card (using dd or rufus under Windows).
- qemu.qcow2 — a media image for running in qemu.
- external.qcow2 — an external media image for the database.
- monitor-0.9-beta.tar.gz — archive for updating via web interface.
Generating manuals
There's no need to write the same instruction multiple times. It makes more sense to write it once in markdown, then convert it to PDF for download and HTML for the web interface. This is made possible by the pandoc package.
At the same time, all these files need to be generated before the system image is built, so post-build scripts become useless. Thus, the generation is done as a manuals package. You can check it in overlay/package/manuals.
The file manuals.mk (which does all the work)
################################################################################
#
# manuals
#
################################################################################
MANUALS_VERSION:= 1.0.0
MANUALS_SITE:= ${BR2_EXTERNAL_monitorOverlay_PATH}/package/manuals
MANUALS_SITE_METHOD:=local
define MANUALS_BUILD_CMDS
pandoc -s -o ${TARGET_DIR}/var/www/manual_en.pdf ${BR2_EXTERNAL_monitorOverlay_PATH}/../README.md
pandoc -f markdown -t html -o ${TARGET_DIR}/var/www/manual_en.html ${BR2_EXTERNAL_monitorOverlay_PATH}/../README.md
endef
$(eval $(generic-package))systemd
The Linux world is actively transitioning to systemd; I had to follow suit.
Among the pleasant innovations is the presence of timers. In fact, a separate article is written about them (and not just them), but I'll briefly explain.
There are actions that need to be performed periodically. I needed to run logrotate for cleaning up logs for lighttpd and php-fpm. It would be most familiar to write commands in cron, but I chose to use a monotonic systemd timer. Thus, logrotate runs on a strict time interval.
Of course, it's possible to create timers that trigger on certain dates, but I didn't need that.
Example of a timer:
- Timer file
[Unit] Description=RODOS temp daemon timer
[Timer]
OnBootSec=1min
OnUnitActiveSec=1min
[Install]
WantedBy=timers.target
- Service file triggered by the timer:
```bash
[Unit]
Description=RODOS temp daemon
[Service]
ExecStart=/usr/bin/rodos.shSupported boards
Asus Tinker Board — the main board on which everything should work. It was chosen for being cost-effective yet powerful.
Beaglebone Black — the first board where the operation was tested (while looking for a more powerful board).
Qemu x86_64 — used for development and debugging.
Hogyan működik
During startup, there is a two-stage recovery of settings:
- Running the settings_restore script (via service). It restores the system's main settings — timezone, locale, network settings, etc.
- Running the prepare script (via service) — here, Zabbix is prepared, a database is set up, and the IP is displayed in the console.
Az első indításkor a második partíció mérete kerül meghatározásra az sd-kártyán. Ha van még meg nem osztott hely, az adathordozó újra particionálódik, és az adatok számára fenntartott partíció az összes szabad helyet elfoglalja. Ezt az installációs image (sdcard.img) méretének csökkentése érdekében tették. Ezenkívül ebben a pillanatban létrejön a postgresql munkakönyvtár. Ezért az új adathordozóval végzett első indítás lassabb lesz a továbbiakhoz képest.
Külső merevlemez csatlakoztatásakor az indítás pillanatában szabad lemezt keres és ext4 fájlrendszerre formázza azt external címkével.
Figyelem! Külső merevlemez csatlakoztatása (valamint az eltávolítása vagy cseréje) esetén szükséges biztonsági mentést készíteni és a beállításokat helyreállítani!
A hőmérséklet figyelésére a RODOS 5 eszköz használatos. A gyártó biztosítja a segédprogram forrásait az eszközhöz. A rendszer indításakor elindul a rodos időzítő, amely ezt a segédprogramot percenként elindítja. Az aktuális hőmérséklet a /tmp/rodos_current_temp fájlba kerül rögzítésre, amelyet a zabbix monitorként figyelhet.
A konfiguráció tárolására szolgáló adathordozó a /data könyvtárba van csatolva.
A rendszer elindítása és munkára való felkészítése során a konzolban az alábbi üzenet jelenik meg:
Rendszer indul, kérjük, várjonA felkészítő munkák befejezése után ez az IP-cím megjelenítésére változik:
aktuális ip 192.168.1.32
Kész a munkáraA zabbix beállítása a hőmérséklet figyelésére
A hőmérséklet figyeléséhez elegendő két lépést végrehajtani:
- csatlakoztassa a RODOS eszközt az usb portra
- hozzon létre egy adat elemet a zabbixban
Nyisd meg a zabbix webes felületét:
- Nyisd meg a Configuration → Hosts szakaszt
- Kattints az Items gombra a zabbix szerverünk sorában
- Kattints a Create item gombra
Írd be a következő adatokat:
- name — ízlés szerint (például serverRoomTemp)
- Type — zabbix agent
- Key — rodos
- Type — numerikus
- Units — C
- History storage period — a történet tárolásának ideje. 10 napra állítottam
- Trend storage period — a trendek tárolásának ideje. 30 napra állítottam
- Új alkalmazás — server Room Temp
És kattints az ADD gombra.
A beállítások kezelése a webes felületen
A webes felület php nyelven íródott. Vannak alapvető funkciók:
- az eszköz állapotának megtekintése
- a hálózati beállítások módosítása
- a felhasználói jelszó módosítása
- időzóna kiválasztása
- biztonsági másolat készítése/helyreállítás/gyári beállítások visszaállítása
- a külső lemez csatlakozásának lehetősége
- Rendszerfrissítés
A webes felülethez jelszóval kell belépni. A kezdőlap — útmutató.
A zabbix felület címe: ${ip/dns}/zabbix
A felügyeleti felület címe: ${ip/dns}/manage
Indítás qemu-ban
qemu-system-x86_64 -smp 4 -m 4026M -enable-kvm -machine q35,accel=kvm -device intel-iommu -cpu host -net nic -net bridge,br=bridge0 -device virtio-scsi-pci,id=scsi0 -drive file=output/images/qemu.qcow2,format=qcow2,aio=threads -device virtio-scsi-pci,id=scsi0 -drive file=output/images/external.qcow2,format=qcow2,aio=threads
Ez a parancs 4 maggal, 2048 MB RAM-mal, engedélyezett KVM-mel, egy bridge0 hídra csatlakoztatott hálózati kártyával és két lemezzel indítja a rendszert: egy a rendszernek és egy az external-nak a postgresql-hez.
A képeket átkonvertálhatjuk és futtathatjuk Virtualbox-ban:
qemu-img convert -f qcow2 qemu.qcow2 -O vdi qcow2.vdi
qemu-img convert -f qcow2 external.qcow2 -O vdi external.vdiEzután importálja őket virtualbox-ba és csatlakoztassa SATA-n.
Zárás
A folyamat során érdekelt, hogy kész terméket készítsek — nem éppen szép felülettel (nem szeretem őket írni), de működő és egyszerűen beállítható.
Az utolsó kísérlet a zabbix-appliance KVM-en való telepítésére megerősítette ezt a lépést (a telepítés befejezése után a rendszer nem indul el). Lehet, hogy valamit nem jól csinálok 😉
Forrás: habr.com
