Sběr binárních dat na slabém HW

[tuxmartin]

Zdravim,
budu mit X (X=hodne) linuxovych krabicek, ktere budou sbirat binarni data. Bude to priblizne 4MB za minutu (240MB za hodinu). Kazdych 15 minut mi vypadnou soubory (pro ucely dotazu se jedna o binarni blob, ktery uz nelze komprimovat) o velikosti cca 15MB, jejich pocet bude 1 az 5. Celkove se tedy bude pohybovat velikost mezi 15 a 60MB za 15 minut, jak ktera krabicka.
Tyto data potrebuju ukladat na centralni server.

Problem krabicek je jejich slaby hardware, rad bych pouzil TP-Link wifi routery. Narozdil treba od Raspberry Pi se daji koupit kolem 500Kc se vsim - neni potreba zadna dalsi, SD karta, krabicka, zdroj. Pripojim zdroj, flashnu OpenWrt a je hotovo.
TL-WR741ND za 490Kc ma 4MB flash a 32MB RAM.
TL-WR842ND za 870Kc ma 8MB flash a 32MB RAM, ale ma USB. Teoreticky se da pripojit root oddil na usb flash disk, ale to nechci. Vzdy se najde blbec, ktery ze zapnuteho routeru flashku vytahne...
Velkou vyhodou je take 5x Ethernet a WiFi, do kterych muzu napichat merena zarizeni.

Puvodne jsem chtel 15 minut ukladat soubory do RAM a kazdych 15 minut je poslat na server - pri 32MB RAM je to nerealne. Navic nebudu mit zalozni zdroje a nerad bych prisel o 15 minut dat.

Otazka zni: Jak sifrovane dostavat data z krabicek na centralni linuxovy server? Moje napady:

• Samba disk pres OpenVPN. Neni to overkill?
• SFTP (pripojeny disk pres SSH)
• WebDAV (https)
• FTPS / FTPES (sifrovane ftp)
• Rozsekat soubory napr. na 1MB dily (kvuli male RAM) a pres curl je periodicky nahravat pomoci HTTP POST na server, ktery si je spoji. imho velka prasarna...

Rad bych idealne malou rezii, nechci zbytecne velky prenos dat. Uz takhle s tim budu mit na dost mistech problem.

Rad bych to mel bezpecne, tedy aby se nikdo po hacknuti krabicky nemohl dostat k datum poslanych ostatnimi krabickami (kazda krabicka bude mit svuj samotny ucet, oddeleny od ostatnich). Tady se mi libi WebDAV, nastavim konkretni adresar a je hotovo. Samba take neni spatna, ale jak je to s bezpecnosti? U sftp uz se musi nastavovat chroot, to by snad taky nebyl problem.
Uzivatele vytvoreni pro krabicky nesmi mit pristup k shellu.

U OpenVPN a WebDAV me laka pouzizi certifikacni autority, pokud bude problem, okamzize muzu revokovat certifikat dane krabicky.
Na OpenVPN se mi take libi moznost syslogu a vzdalene ssh administrace krabicek z centralniho serveru (krabicky budou mit neverejne IP).

[Reklama]

[Pavouk106]

SSH potřebuje výkon, aby dokázalo tlačit data solidní rychlostí. Otázka je, zda zařízení má dostatečnej výkon a/nebo zda ten výkon můžeš obětovat.

Možná by stálo za úvahu taky NFS přes OpenVPN - je to víc systémový (myšleno nativní), než Samba.

Co plánuješ sbírat? Resp. jakej to bude mít účel? (ptám se jen tak ze zajímavosti)

[M.]

Provozuji něco podobného. Jenom číslo X se blíží stovce a každá ta krabička sbírá cca 140 MB/sec. :-) takže místo TPlinku tam máme vlastní HW s hromadou hardwarovýh polí od Xilinxu, aby se to stíhalo v reálnéím čase přehrabovat. Nicméně ten počítač za tím (linux na bázi slackware10 běžící v RAMdisku) to plive tak, že jednotlivé události, které se z toho trvalého toku vyzobávají (pár až pár desítek MB), tlačí pomocí FTPS na server přímo ze své RAM. Používá se libcurl. Jednoduché a relativně blbovzorné a funguje to tak roky.
Co to sbírá je nepodstatné. :-)

[Jenda]

SSH potřebuje výkon, aby dokázalo tlačit data solidní rychlostí. Otázka je, zda zařízení má dostatečnej výkon a/nebo zda ten výkon můžeš obětovat.

OpenVPN (a SSL a další…) šifrují stejným způsobem, tak to výkonově asi bude nastejno. A docela to jde, řádově 1 MB/s to dá.

Tazatel: Rozsekal bych to na fragmenty a scpčkoval. Pokud by byl overhead na handshake SSH, můžeš použít takovou tu démonizační/socketovou SSH feature, která naváže spojení jen jedno a zbytek jde přes soket. Taky (pokud máš stabilní síť) to můžeš tlačit rovnou pajpou "logger | ssh stroj".

Pan M. sbírá odposlechy u ISP a telefonních operátorů.

[tuxmartin]

SSH potřebuje výkon, aby dokázalo tlačit data solidní rychlostí. Otázka je, zda zařízení má dostatečnej výkon a/nebo zda ten výkon můžeš obětovat.

OpenVPN (a SSL a další…) šifrují stejným způsobem, tak to výkonově asi bude nastejno. A docela to jde, řádově 1 MB/s to dá.

Tazatel: Rozsekal bych to na fragmenty a scpčkoval. Pokud by byl overhead na handshake SSH, můžeš použít takovou tu démonizační/socketovou SSH feature, která naváže spojení jen jedno a zbytek jde přes soket. Taky (pokud máš stabilní síť) to můžeš tlačit rovnou pajpou "logger | ssh stroj".

Pan M. sbírá odposlechy u ISP a telefonních operátorů.

1MB/s je absolutne dostatecne. Takovou rychlost z 90% nebude mit ani internetove pripojeni u jednotlivych krabicek.

Nad sifrovanym FTP jsem taky uvazoval, ale moc se mi to nelibi. Nemam ten protokol rad. Spousty spojeni a ruznych portu, sifrovani se obcas chova podivne. Prece jen to je 43 let stary protokol...

NFS v OpenVPN tunelu zni zajimave, ale v 99% jsem vzdy vsude pouzival sambu, takze s NFS nemam skoro zadne zkusenosti.

Zkousel jsem nainstalovat NFS. Na serveru jsem do /etc/exports dal "/home 192.168.0.0/255.255.0.0(rw,sync,no_root_squash,no_subtree_check)" a pokud na klientovi udelam "mount 192.168.1.1:/home/martin /mnt/test/" pripoji mi to muj domovsky adresar. Jenze na klientovi musim pripojiovat pod rootem a pak se me to nepta na zadne heslo.
Da se nejak u NFS na serveru nastavit jmeno/heslo? Jako u samby \\server\home a po zadani jmena a hesla uzivatele jsem pouze v jeho home adresari. U NFS jsem nic takoveho nenasel, ve vsech navodech je "zabezpeceni" resene IP adresou v /etc/exports...

Stale uvazuju o monitoringu krabicek (asi nagios). Proto by se hodilo mit VPN pristup do krabicek. Kdyz se neco po.... tak take budu mit moznosti dostat se k ssh v krabicce.
Proto je pak nesmysl jeste uvnitr sifrovane vpn mit sifrovane kopirovani souboru.


Zmena - kvuli vypadkum a rychlosti pripojeni bude wifi router ukladat na usb flash disk a jednou za X minut nakopiruje data na server. Stale tedy zkustava problem, pres jaky protokol kopirovat.

[Reklama]

[Pavouk106]

NFS funguje na základě UID a GID. Klient musí mít stejně UID a GID, jako má an serveru, jinak na "své" soubory nemůže. Proto žádné jméno a heslo. Dá se to tuším nějak "ochcat" pomocí nastavení NFS (jako třeba překlad z UID 1001 na UID 1010, pokud by uživateli nesouhlasilo UID). Jinak zabezpečení jako takové řešeno vůbec není (žádný login, prostě jen otevřený port).

Pokud budeš mít stejně VPN (kvůli nagiosu/správě), tak to udělej přes čisté FTP a nazdar bazar ;-)

[Jenda]

Stale uvazuju o monitoringu krabicek (asi nagios). Proto by se hodilo mit VPN pristup do krabicek. Kdyz se neco po.... tak take budu mit moznosti dostat se k ssh v krabicce.

Když použiješ tu metodu, že se to SCPčkuje/SSHčkuje, tak stačí přidat reverzní SSH tunel a můžeš se tam přihlásit.

[Ondřej Surý]

Vsuvka k USB disku - ten pidiflashdisk se do krabice dá zalepit, aby jej nikdo nemohl vytáhnout.

RIPE Atlas takhle nějaké zalepené věci do TP-Linku má.

[Mirek Prýmek]

Hezkej dotaz! S chutí jsem si přečetl různé návrhy řešení

Pokud to dobře chápu, chceš řešení pokud možno pomocí nějakých základních utilit, do kterých jenom data naláduješ? Protože pokud by byla možnost napsání vlastní malé aplikace, tak jsou zase možnosti jinde...

Např. v energomonitor.cz používáme tftp, http POST, mqtt. Pokud nechceš nějaké extra featury, tak bych se s protokolem nezalamoval a volil bych co nejrobustnější (=> nejjednodušší) řešení. Takže NFS a sambě bych se určitě vyhnul, s tím budeš mít při takovém množství zařízení kdesi v trapu na kdovíjaké síti jenom problémy. Pokud budeš mít šifrování na jiné vrstvě (VPN), tak bych klidně šel do toho tftp. Anebo do http post, to už záleží spíš na tobě, s čím se víc kamarádíš a líp to ukočíruješ a taky co s datama budeš dělat dál. Režie je u obojího rozumná, pokud nechceš posílat nějak butálně realtime, tam by to pak chtělo něco speciálnějšího jako právě to mqtt, něco custom po udp apod.

Dost důrazně bych ale NEdporučoval ukládat jakákoli průběžná data na flashku. Flashky při konstantním zápisu odchází rychlostí, která by tě dost nemile překvapila. Fakt to určitě nedělej, je to asi ten nejhorší nápad, co jde v takové situaci vymyslet. Pokud to nutně chceš, pak jedině mini pci-e ssd, nebo ještě líp rovnou notebookový disk. Lepší ale je se tomu vyhnout, pokud to jenom trochu jde, protože tím nic nezískáš - množství posílaných dat bude pořád stejný, akorát se trochu sníží režie za cenu imho výraznýho snížení spolehlivosti.

[tuxmartin]

Presne tak, rad bych poslepoval jiz exitujici programy.
Nechci se podcenovat, ale ftp, samba nfs, ... jsou mnohem lepsi a lety overenejsi protokoly, nez ja ted u kafe vymyslim. :-)

Ja potrebuju v realnem case sbirat data, ale na server mohou dorazit klidne i s 12 hodinovym zpozdenim (dele ne). Problem je, ze na danych lokalitach neni extra rychle pripojeni k internetu. Navic behem dne byva dost casto zpomalene praci uzivatelu. Proto s nejvetsi pravdepodobnosti nepujde, jak jsem puvodne zamyslel data primo ukladat na sitovy disk. Takhle se data muzou ukladat na kartu a v noci se pres FTP odesilat (co se behem dne nestihne). 
Dalsi problem, kdyz na par minut chcipne internet, byl bych bez dat.

Uvazoval jsem o male USB ctecce microSDHC karet a do toho za 120Kc 8GB kartu.
Pokud by ji bylo nutne jednou za rok vymenit, snad by se to dalo prezit. Cenove urcite, horsi ta prace s tim :-(

Jak to delaji treba dnes tolik oblibene kamery v autech? Ty imho taky neustale od zacatku do konce ve smycce prepisuji sd kartu. Jak dlouha tam karta vydrzi?

Nemate zkusenosti s zivotnosti sd karet? Kdyz budu cca 12 hodin denne zapisovat 4 soubory kazdy cca 1MB/minutu, za jak dlouho bude karta na vyhozeni?

[M.]

Hehe, jak člověk dospěje v podobném případě k pdobnému řešení. Také máme i nějaký systém pro monitorování elektro, akorát místo pulzů z elektroměru monitoruje trošku ryhlejší děje, občas doprovázené létáním zbytků vedení a transformátorů do okolí, takže těch dat je o pár řádů více. Po letech to došlo k přenosu FTP, HTTP PUT a ZeroMQ. Na to MQTT se podívám, to vypadá zajimavě. Třeba bych se konečně zbavil vlastního bastlu na gateway 0MQ na WS (respektive SSE). :-)

Jinak souhlas, komplikované protokoly jako Samba a NFS nebrat. S tím jsem si nabil držku už před hodně lety (NFSv3 tehdy, ať TCP nebo UDP spojení), a to i na celkem vyhrazených linkách, jak je to dál, je z toho bolehlav.

Trvalé cachování na flashku je problém také, doložený bednou plnou mrtvých DOC, SD a dalších modulů. Leda to dělat tak, že data mám v RAM, odesílám a jen když se nepodaří odeslat, tak po nějaké době zhajuji cachování na disk pro případ ztráty napájení a po obnovení spojení odešlu (v mém případě prvně posílám obsah RAM a pak doposílám co ja na flashce). Ale výrazně to komplikuje logiku aplikace, takže je vhodné zvážit, zda mi to za tu námahu stojí. Jinak dle popisu toho MQTT, tak některé klientstké knihovny podporují cachovábí na disk při nedostupnosti spojení.

[tuxmartin]

Cachovani do RAM je zajimavy napad, urcite by se hodne usetril zapis na kartu. Skoda jen, ze mam jen 32MB RAM. Ale ve vetsine pripadu by to mohlo stihat odesilat po internetu.

MQTT jsem neznal, urcite se na nej podivam. Klientska cast v Pythonu pro OpenWrt by mohla byt relativne jednoducha.

[Mirek Prýmek]

Nechci se podcenovat, ale ftp, samba nfs, ... jsou mnohem lepsi a lety overenejsi protokoly, nez ja ted u kafe vymyslim. :-)

To záleží na typu těch dat. Pokud bys potřeboval každou půl minutu odeslat tři byty, s jistotou a navěky to budou 3B, tak je zbytečný kvůli tomu cokoli řešit a stačí jednoduchý C prográmek na deset řádků

U samby i nfs je ten problém, že to jsou protokoly primárně určený na LAN. Všelijaký výpadky, ztráty packetů apod. je můžou docela rozhodit. Prostě tímhle si jenom přiděláš problémy, který budou obtížně řešitelný a neustálý, proto je to špatný řešení. Potřebuješ něco naprosto jednoduchýho, robustního, bezúdržbovýho, jinak se z toho zblázníš.

Nemate zkusenosti s zivotnosti sd karet? Kdyz budu cca 12 hodin denne zapisovat 4 soubory kazdy cca 1MB/minutu, za jak dlouho bude karta na vyhozeni?

S SD kartama ne, ale můžu ti říct, že normální USB flashka, na kterou logoval málo vytížený servřík, odešla asi za dva měsíce. Jestli mají SD karty jinou technologii, to nevím, ale jestli jich hodláš do světa rozeslat tisíc, tak bych si to prvně hodně dobře ověřil, jinak ztrávíš příští rok objížděním republiky a vyměňováním karet

Jak to dělají kamery dneska, to netuším, dřív se AFAIK používaly CF karty, které by měly vydržet víc.

Třeba bych se konečně zbavil vlastního bastlu na gateway 0MQ na WS (respektive SSE). :-)

Náhodou ZMQ je super

[M.]

To cachování umí i ZeroMQ, ať už 0MQ SWAP nebo PZQ modul. Takže aplikace nastaví watermark, kolik RAM může mít fronta v RAM a když se naplní (pro nedostupnost spojení nebo malý průtok), tak se začne odkládat do souboru. S tímto se dá obejít náročnosti řídit si to ve vlastní logice aplikace, zkrátka zapisuji zprávy do fronty a nechám na knihovně, ať je nějak dopraví dál.
Jenom bude problém, co z toho dokážete narvat do toho routeru/OpenWRT.

[tuxmartin]

Zni to zajimave, dokonce jsem nasel nejaky port ZeroMQ na OpenWrt.

Vidim v mem pripade zasadni problem. Musel bych mit velky soubor a ten chtit posilat. Ja ale soubor nemam. Mam souvisly stream dat (cca 1MB/min), ktery mi generuje jiny program a zapisuje ho na disk do souboru. Ja maximalne muze nastavit vytvareni novych soubou kazdych par minut, abych se vesel do RAM.

Takze asi nakonec budu mit 1 soubor na jednu minutu, ktery se bude ukladat do RAM disku. Po skonceni souboru, se zacne novy a stary se posle pres FTP/ HTTP POST/ ... na server. Pokud se to nepovede, odlozi se na SD kartu a zkusi se to pozdeji.
Chudak server, kdyz mu kazdou minutu dorazi stovky souboru (cca 4 soubory na jednu krabicku). Souborovy system bude mit z tisicu souboru velkou radost. Ale ukladat binarni data do MySQL se mi porad zda jako nesmysl, radeji ulozim do db nazev souboru a nejaka metadata.