Oddaljeno omrežno diskovje NAS v gnezdeni napravi
Vzgibi, ki nas vodijo v amaterske projekte, so najrazličnejši. Mene je v tega vodil vlom, ki me je doletel med lansko odsotnostjo med prvomajskimi prazniki. Pokradli so marsikaj, a meni najvrednejšo stvar so pustili v hiši: moje podvojene strežniške diske v razdrtem neuglednem ohišju, na katerih so skriti vsi moji posnetki s kamero, fotografije, zvočni posnetki in vsa moja pisna zgodovina od začetkov osebnega računalništva. Takrat sem vedel dvoje: potrebujem še tretjo kopijo diskov in biti mora na oddaljeni lokaciji.
Na strežniku BeringNAS sem OpenVPN nastavil v datoteki /etc/openvpn/server.conf takole:
# Nastavitev vrat
port 1194
# protokol TCP ali UDP?
proto udp
# nastavitev usmerjevalniškega tunela, ne premoščanja
dev tun
# SSL/TLS certifikati in kljuci
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
# parametri Diffie-Hellman.
dh /etc/openvpn/keys/dh1024.pem
# nastavitev strežnikovega VPN omrezja
server 192.168.200.0 255.255.255.0
# povezava odjemalec <==> navidezni IP naslov
ifconfig-pool-persist /var/lib/openvpn-ipp.txt
# vzdrževanje povezave na 10 sekund
keepalive 10 120
# zadnje stanje VPN omrezja
status /var/log/openvpn-status.log
# intenzivnost zapisov v sistemski zapisnik
verb 3
Na delovni postaji Windows XP SP2 je postavitev odjemalca dokaj enostavna. Vse je dosegljivo z desno mišjo tipko na ikoni. Certifikate je treba postaviti v imenik OpenVPN. Odjemalca sem si nastavil v datoteki client.ovpn takole:
# odjemalec del nastavitev potegne s streznika
client
# ta povezava bo usmerjevalniški tunel
dev tun
# protokol TCP ali UDP?
proto udp
# tunel naj se vzpostavi do streznika, na vrata
remote 10.8.0.32 1194
# Ce ne uspe, ponavljaj naprej
resolv-retry infinite
# SSL/TLS certifikati in kljuci.
ca ca.crt
cert client1.crt
key client1.key
# intenzivnost zapisov v sistemski zapisnik
verb 3
Rešitev sem si hotel izdelati sam, saj bi ji samo tako z lahkim srcem zaupal svoje dragocene datoteke. Le kdo bi vedel, kako poševnooki "kung fu" NASi (Network Access Storage) pišejo po diskih in v kakšnem datotečnem sistemu. In le kako ga obnoviš, če se ti sesuje zadnja uporabna kopija? Poigral sem se s FreeNAS različice 0.684b [1], o katerem je malo pred tem pisal Monitor. In bil nad njim globoko razočaran, saj se mi je petkrat zaporedoma na dveh različnih strojnih podlagah RAID podrl takoj po inicializaciji v sicer estetskem PHP vmesniku. Ali je kaj ušpičil tisti rdeči rogati možic z vilami v rokah (čeprav na podlago pod FreeNASom, M0n0wall, res nimam pripomb) ali pa sem imel smolo z napačno delujočo PHP lupino. Zato sem se raje odločil začeti tam, kjer se mi v takih primerih zdi smiselno: iz ničle, po svoje.
Strojna oprema in OS
Potepanje po omrežju me je pripeljalo do mini-ITX ploščice EK8000, ki jo izdeluje VIA. Niti po procesni zmogljivosti niti po ceni ni med zmagovalci, ima pa posebno lastnost, da ne potrebuje aktivnega hlajenja. Njen procesor Luke se vrti z 800 MHz. Mini-ITX ploščico sem izbral zato, ker manjše in cenejše rešitve takrat še niso podpirale SATA vmesnikov za diskovje. Danes bi se verjetno odločil za ploščico s procesorjem Atom, ki so cenejše in bistveno zmogljivejše - pravzaprav daleč premočne za ta namen.
EK8000 je neslišna podlaga s hladilnimi rebri brez ventilatorja. Idealno gnezdišče za primerne ptiče.
Uporabil sem pomnilnik RAM s 128 MB. Ker mini-ITX ploščice ponavadi nimajo vmesnikov za CF kartice, sem izbral DoM modul z 256 MB. DoM (Disk On Module) je flash pomnilnik, nadgrajen nad vtičem PATA, ki posnema delovanje diska IDE. Vstavi se ga neposredno v vtičnico namesto kabla IDE. Mini-ITX ploščice imajo pogosto dva vmesnika IDE s PATA vtičnico in dva vmesnika SATA. DoM je tako zasedel eno vtičnico PATA, dva vmesnika SATA pa sem namenil diskom za podatke. S tem sem popolnoma ločil programsko kodo od podatkov. Koda v flash, podatki na diske.
Za podatkovna diska sem izbral velikost 320 GB vmesnik SATA, 8 MB predpomnilnika. Ob času nakupa je bilo razmerje zmogljivost/cena najugodnejše ravno pri tej velikosti, obenem pa mi je 640 GB povsem zadoščalo. Še kar nekaj časa bomo z vsemi družinskimi video-kamermanskimi potrebami še vedno sub-tera družina.
Saj je lepo, če je ohišje majhno, a diski potrebujejo prostor. Še posebej, če je človek tako čuden kot jaz in odklaplja hladilne ventilatorje, kjer je le mogoče, da ne ropotajo. Diski pa ne marajo visokih temperatur. Zato sem izbral ohišje Morex Venus, ki je nekoliko večje od ohišij komercialnih NASov, zato pa je moj izdelek skoraj neslišen, edina mehanska sklopa, oba diska, pa imata dovolj prostora, da se ne pregrevata.
Kdor je v preteklosti prebral kakšen moj prispevek o gnezdenih rešitvah, je že uganil, da sem tudi NAS zgradil na Linuxu LEAF uClibc Bering [2]. Vzgib ali nujnost? Vzgib.
Morex Venus je dovolj veliko ohišje, da sem si ob tako nizki porabi moči, kot jo ima EK8000, privoščil odklopiti ventilatorje na ohišju in na napajalniku. Diska, ki sta si postavljena pravokotno, med njima pa je prazna diskovna reža, se nista pregrevala.
Polnjenje DoM
DoM je za gradnjo gnezdenih sistemov idealen. Težava je le, da ga ni mogoče napolniti s ciljnim operacijskim sistemom prek čitalnika flash kartic. V ta namen sem uporabil odslužen računalnik z Linuxom na disku in v njegovo prosto vtičnico PATA na drugem kanalu IDE vstavil DoM. Nato sem šel skozi običajni postopek priprave novega diska za zaganjanje operacijskega sistema: s fdisk tabelo razdelkov, z uporabo paketa syslinux pa zagonsko kodo v prvi sektor. Nato sem ustvaril datotečni sistem in prenesel vse potrebne datoteke sistema uClibc Bering na DoM in s programom syslinux zagotovil zagon sistema. Po osnovnem konfiguriranju zagonskih datotek je bil DoM pripravljen za premestitev v ciljno okolje.
Disk On Module je odlična rešitev za gnezdene sisteme. Že tale je bil zame 32-krat prevelik, a ob oddaji prispevka so v spletnih trgovinah ponujali predvsem DoMe od 1 GB naprej. Ob tem sem nehote pomislil, koliko programskih neumnosti in skritih napak bi bilo treba, da bi zapolnil tako velikanski prostor s kodo.
Dodajanje programskih paketov
EK-8000 se je zbudila v Linux v prvo, manjkali pa so ji pravi gonilniki za omrežje. VIA uporablja za ethernet čipovje Rhine, zato sem moral med module dodati:
crc32
mii
via_rhine
in ethernetni vmesnik je oživel. Še osnovno konfiguriranje omrežja in ssh strežnika dropbear in prek omrežja je bila odprta pot za nalaganje programskih paketov na DoM. Za svoj NAS sem si izbral naslednje pakete za obravnavanje diskov:
mdadm (za naprave RAID)
hdsupp (za upravljanje diskov)
hdspind (za "dajanje diska spat", t. i. spindown)
smartd (za nadzor diskov SMART)
S kabelčki SATA sem priključil oba diska na vmesnika na ploščici, vendar je bilo to jalovo dejanje, saj operacijski sistem diskov SATA ni videl brez gonilnikov zanju. V ta namen sem pobrskal po omrežju, katere gonilnike potrebujem. Z novim znanjem in pomočjo metode poskusov in napak sem prišel do naslednjega seznama potrebnih modulov, ki sem jih shranil v /var/lib/modules in jih aktiviral v datoteki /etc/modules :
scsi_mod
libata
sata_via
Na tem koraku je Bering videl vmesnik SATA, ne pa še diskov. Zadnji modul:
sd_mod
je omogočil, da je operacijski sistem zagledal dve novi napravi, /dev/sda in /dev/sdb.
Priprava diskov
Ker sem pripravljal okolje za tretjo kopijo mojih podatkov, a na oddaljeni lokaciji, sem se po razmisleku odločil, da tako visoke stopnje redundance, da bi se odločil še za RAID, ne potrebujem, čeprav je vsa potrebna podpora zanj vsebovana v paketu mdadm. Paket hdsupp pa vsebuje osnovna orodja za obravnavanje diskov v uClibc Beringu. Zdaj, ko so gonilniki videli oba diska SATA kot naprave SCSI, sem naredil
# fdisk /dev/sda
in ustvaril novo tabelo razdelkov, dodal primarni razdelek tipa 83 (linux) in shranil spremembe na ciljni disk. Razdelka nisem označil za aktivnega, ker z njega ne bom nalagal operacijskega sistema. Ta ostane samo v flashu DoM. Diska bosta v celoti namenjena hranjenju podatkov. Isto sem ponovil še za drugi disk, /dev/sdb.
Odločil sem se, da bom svoje podatke zaupal preizkušenemu datotečnemu sistemu ext3. Oba diska sem na sveže "preoral" z:
mkfs.ext3 /dev/sda1
mkfs.ext3 /dev/sdb1
a pričakovanega rezultata ni bilo. Operacijski sistem ju ni videl. uClibc Bering zna po privzeti konfiguraciji brati le datotečna sistema FAT in minix, ker varčuje pri obsegu programske kode. Ne pozna niti ext2. Slednjega sem preskočil, ker ga nisem potreboval, sem pa dodal oba modula, ki ju potrebuje ext3:
insmod jbd.o
insmod ext3.o
mount /dev/sda1 /mnt mi je zdaj povezal prazen datotečni sistem. Oba modula sem še pospravil v /var/lib/modules in ju trajno aktiviral v konfiguracijski datoteki /etc/modules.
Zdaj ju je bilo treba še povezati na smiselno mesto v Beringov datotečni sistem. Zato sem moral narediti povezovalni točki v datotečnem sistemu, kamor bom lahko preslikal oba diska. Uporabil sem postopek, ki sem ga opisal v prispevku o izdelavi gnezdenega spletnega strežnika v majski številki Monitorja. Razkopal sem modul initrd.lrp in v datoteko linuxrc dodal tik pred koncem vrstici:
qt mkdir /mnt/sata-1
qt mkdir /mnt/sata-2
Ob naslednjem zagonu se bo Linux zbudil s tema dvema imenikoma. Treba je bilo le še trajno povezati nova diska s tema dvema imenikoma. V ta namen sem v datoteko /etc/fstab dodal spodnji vrstici in shranil konfiguracijo:
/dev/sda1 /mnt/sata-1 auto defaults 0 1
/dev/sdb1 /mnt/sata-2 auto defaults 0 2
S tem sta bila diska pripravljena za rabo.
Podpora protokolu SMB
Čeprav bi mu lahko očitali marsikaj, je najbrž danes najbolj razširjen protokol za preslikovanje omrežnih diskov SMB, ki ga uporablja Windows. Manj primeren je, ker preveč po nepotrebnem "čveka" po omrežju in ker njegov imenski protokol dvojček, NMB, ne zna delati čez mejo krajevnega omrežja. Kljub vsemu se mu skoraj ni mogoče izogniti.
Paket samba22.lrp za uClibc Bering vsebuje oba strežnika, SMB in NMB. Dodal sem ga na DoM in popravil konfiguracijo leaf.cfg, tako da se je sam naložil ob zagonu.
Čeprav je banalno, imam sam pri nastavljanju sambe največje težave z lastniškimi pravicami nad datotekami, ker ponavadi kaj spregledam in potem strežnik ne more do datotek. Tokrat sem se lotil stvari sistematično in najprej ustvaril navideznega uporabnika za sambo:
# adduser samba
ter mu določil geslo. To je uporabniško geslo za Linux, a ne za sambo. Zato sem moral določiti še geslo za sambo:
# smbpasswd samba mojegeslozasambo
Nato sem poskrbel za lastništvo nad diski, ki jih bom stregel v omrežje. Ker sem diske pripravljal kot root, sem jih sedaj dodelil uporabniku samba in skupini samba:
chown -R samba /mnt/sata-1
chgrp -R samba /mnt/sata-1
Nato sem še vsem datotekam popravil dovoljenja za dostop, tako da sta uporabnik in skupina samba lahko brala in pisala po njih, drugi pa samo brali. Izvajanja programov s teh diskov nisem dovolil nikomur.
chmod 664 -R samba /mnt/sata-1
Isti postopek sem ponovil še za drugi disk, sata-2.
Parametre za delovanje sambe je treba določiti v datoteki /etc/samba/smb.conf, lahko pa se v Beringu isto naredi z menuja lrcfg. Nastavitve so iz dveh delov. Prvi se nanaša na globalne postavke, ki veljajo za sambo, drugi del se nanaša na konkretne dele diskov, ki jih preslikujemo v omrežje. Prvi del sem nastavil takole:
[global]
workgroup = MOJASKUPINA
netbios name = Bering-NAS
server string = Middle-Earth
encrypt passwords = yes
security = user
local master = yes
Nastavitve pomenijo, da bo strežnik viden skupini uporabnikov MOJASKUPINA, imenoval pa se bo Bering-NAS z dodatnim opisnim imenom Middle-Earth. Za prijavo v strežnik bo treba podati uporabniško ime in geslo, oziroma če bosta enaka kot za prijavo na delovno postajo Windows, bo strežnik pripustil uporabnika te delovne postaje brez overjanja. Zadnja nastavitev pomeni, da bo strežnik glavni pregledovalec imen strežnikov v tej skupini. A žal, kot omenjeno, je ta lastnost omejena na krajevno omrežje.
Za vsak navidezni omrežni disk, ki ga bo strežnik stregel, pa sem moral nastaviti parametre, ki veljajo le zanj. Prvi disk sem preslikal z naslednjimi parametri:
[Lothlorien-1]
browseable = yes
writeable = yes
path = /mnt/sata-1
force user = samba
force group = samba
force create mode = 0664
force directory mode = 0664
Zgornje nastavitve pomenijo, da se bo ta navidezni disk omrežju izkazal z imenom Lothlorien-1. Po njem bo dovoljeno brskati z raziskovalcem in, poleg branja, zapisovati datoteke. Omrežje bo pod imenom Lothlorien-1 videlo vse, kar je pod imenikom /mnt/sata-1, to pa je imenik, kamor sem višje zgoraj preslikal disk /dev/sda1. Kdorkoli bo uporabljal streženi disk, bo po njem pisal datoteke kot uporabnik "samba" v skupini "samba". Vse datoteke in imeniki, ki jih bo ustvaril, bodo imeli dovoljenja za dostopanje nastavljena kot 664, to je enako, kot sem malo prej nastavil pristopne pravice že obstoječih datotek na tem disku.
Podobno sem v omrežni disk Lothlorien-2 preslikal fizični disk /dev/sdb1. S tem so bile vse osnovne nastavitve za streženje s protokolom SMB/NMB pripravljene. Po vnovičnem zagonu sambe na Beringu z ukazom /etc/init.d/samba restart sta se na testni delovni postaji Windows na sosednjem računalniku pojavila dva nova omrežna diska na strežniku BeringNAS.
Še čisto na začetku poti - Windows Explorer zagleda nov strežnik v omrežju LAN s preslikanimi diski.
Podpora protokolu rsync
Za namene varnostnega shranjevanja, predvsem na daljavo prek prostranega omrežja, je protokol rsync [3] daleč primernejši od sambe. Čeprav sta si samba in rsync zelo različna, imata istega avtorja: Avstralca Andrewa Tridgella. Sambo je naredil z vzvratnim inženirstvom nad paketi, ki jih je lovil iz omrežja. Rsync pa je bil predmet njegovega doktorata.
Poenostavljeno algoritem rsync razpolavlja datoteko na vedno manjše delce, za katere izračunava kontrolno vsoto. Nato pošiljatelj pošlje samo tiste dele datoteke, katerih kontrolne vsote se ne ujemajo s kopijo pri prejemniku (torej so spremenjeni), prejemnik pa z njimi nadomesti samo vsebino, ki se je spremenila. Vseh drugih delov datoteke sploh ne prenašata prek omrežja. Prenos datotek je tako minimiziran. Zato je rsync odlično orodje za osveževanje varnostnih kopij podatkov na daljavo.
Bering ima protokol rsync vgrajen v paket rsync.lrp. Po namestitvi paketa sem moral napisati nastavitve v datoteki /etc/rsyncd.conf. Bile so dokaj enostavne:
[Lothlorien-1]
comment = rsync backup on BeringNAS
path = /mnt/sata-1
read only = no
uid = samba
gid = samba
Rsync lahko poženemo na dva načina, kot navaden program ali pa kot strežnik, tako da v ozadju čaka na povezavo z drugega sistema. Slednje sem naredil z ukazom:
# rsync --daemon
Da bi strežnik rsync lahko uporabil, sem moral na neki drug računalnik postaviti odjemalca za rsync. Za delovne postaje Windows je najprimernejši odprtokodni DeltaCopy [4], grafična lupina nad rsyncom, ki za razliko od drugih izvedb ne potrebuje simuliranega Unixovega okolja cygwin.
Kriptirani tunel OpenVPN do oddaljenega strežnika
V naslovu prispevka je beseda "oddaljeno". Za ta del projekta sem uporabil paket OpenVPN [5], ki omogoča tuneliranje kriptiranih podatkov skozi javna IP omrežja. VPN pomeni Virtual Private Network oziroma navidezno zasebno omrežje. Za podatkovni tunel skozi javno omrežje bi zlahka našli analogijo na morski plaži: iz hladilnika na obali (strežnik v zasebnem omrežju) je črna, neprosojna cev (kriptiran tunel) speljana skozi toplo morsko vodo (javno omrežje) do čolna (oddaljena zasebna lokacija), kjer odjemalec iz nje srka hladno pivo (podatkovni tok v tunelu). Za uClibc Bering je vsa potrebna VPN funkcionalnost vsebovana v paketih:
easyrsa (pokriva upravljanje certifikatov)
libcrpto (podporna knjižnica za easyrsa)
libssl (podporna knjižnica za enkripcijo SSL)
openssl (vsebuje raven SSL)
openvpn (vsebuje VPN tuneliranje)
Poleg tega je potreben še modul tun.o, ki sem ga shranil v /lib/modules in aktiviral v /etc/modules. Tun upravlja navidezni omrežni vmesnik z lastnim IP naslovom, "vrata" tunela.
Paketa easyrsa in libcrpto sta v smislu certifikatske agencije potrebna samo za generiranje ključev. Za varno delo s ključi (generiranje, preklicevanje, hranjenje ključa agencije) je priporočljivo, da ga ne izvajamo na sistemu, ki je strežnik VPN. Preostali trije paketi so potrebni na strežniku VPN. Vse module sem dodal na DoM in jih aktiviral v /leaf.cfg.
Ključe sem generiral na drugem sistemu. Pripravil sem si naslednje datoteke:
ca.crt (certifikat moje "agencije")
server.crt (certifikat strežnika BeringNAS)
server.key (ključ strežnika BeringNAS)
client1.crt (certifikat za delovno postajo)
client1.key (ključ za delovno postajo)
Nastavitve za Shorewall
Po konfiguriranju OpenVPN (glej okvirček) sem moral nastaviti požarno pregrado Shorewall na strežniku BeringNAS, da je prepuščala tunelirane IP pakete. Poleg običajne nastavitve sem naredil še naslednje:
V datoteki /etc/shorewall/zones sem odprl novo cono:
#ZONE TYPE OPTIONS IN OUT
vpn
V datoteki /etc/shorewall/policy sem dodal VPN politiko:
#SOURCE DEST POLICY LOG
fw vpn ACCEPT
vpn fw ACCEPT
V datoteki /etc/shorewall/rules sem dovolil sambo, rsync in http (za namene upravljanja na daljavo) skozi tunel do strežnika BeringNAS:
#ACTION SOURCE DEST
SMB/ACCEPT vpn fw
Rsync/ACCEPT vpn fw
Web/ACCEPT vpn fw
Poleg storitev prek tunela sem dovolil samo še NTP in DNS v omrežje. Na vse drugo se BeringNAS ni smel odzvati.
V datoteki /etc/shorewall/tunnels sem na koncu še omogočil tuneliranje iz cone net:
#TYPE ZONE GATEWAY
openvpn:udp:1194 net 0.0.0.0/0
Ničle za prehod pomenijo, da je oddaljena stran "cestni bojevnik" oz. road-warrior, kakor izrazoslovje VPN imenuje posamični sistem, ki se vključuje v VPN.
Po svežem zagonu obeh strani sem z Windows dvignil tunel in naredil ping na tunelski naslov strežnika.
Promet je stekel in tunel je bil s tem odprt. Za razliko od Šentviškega tunela protipožarna zaščita ob tem ni odpadla.
Meritve odzivnosti tunela, SMB in rsync v krajevnem omrežju
Precej me je skrbelo, kako bo breme kriptiranja vplivalo na zmogljivosti prenosa skozi tunel. Pred skoraj 10 leti, ko sem na procesorjih z 200 MHz preizkušal izvedbo tuneliranja IPsec, nekdanji FreeSWAN oz. današnji OpenSWAN [6], je kriptiranje v tunelu zmanjšalo prepustnost za desetkrat. Takrat sem uporabljal način 3-DES. OpenVPN privzeto uporablja AES-256-CBC.
Preizkusni poligon. Med delovno postajo in strežnikom sta dve poti - neposredna po ethernetu in posredna skozi tunel na ethernetu. Modra, ethernetna pot, gre prek fizičnih vmesnikov eth. Rdeča, tunelirana, gre prek navideznih vmesnikov tun. Vsaka pot ima svojo IP naslovno shemo.
Preizkusni poligon sem si postavil na 100 Mb/s ethernetu. Odjemalec je bila delovna postaja Windows XP SP2 na strojni opremi: Shuttle SB61, P4-2,4GHz, 256 MB RAM, Maxtor 128 GB ATA. Strežnik Bering-NAS z Linuxom uClibc Bering 3.02 pa je stal na gnezdeni strojni podlagi: VIA EK8000, Luke 800 MHz CoreFusion, 128 MB RAM, 2x Seagate 320 GB/8 MB SATA.
Postavitev s Slike 5 omogoča dostop do strežnika po dveh različnih poteh. Da to ni teorija, temveč praksa, se vidi v Windows Explorerju na delovni postaji Windows, ki isti diskovni strežnik vidi na dveh IP naslovih prek dveh preslikav - prvo skozi tunel in drugo skozi ethernet.
Za merjenje vpliva kriptiranja na hitrost shranjevanja podatkov prek omrežja bi moral meritve opravljati v sorazmerno hitrem komunikacijskem okolju, tako da bi pot paketov predstavljala majhen delež zakasnitve. Idealno bi bilo meriti na stikalu s prepustnostjo 1 Gb/s, jaz pa sem imel na voljo samo okolje 100 Mb/s. Ne glede na to so meritve zgovorne.
Merni podatki so bili vzeti iz realnega okolja. Uporabil sem približno 2000 fotografij v skupni velikosti 4 GB.
Za meritev s protokolom SMB sem na delovni postaji Windows napisal preprost DOSov skript:
time <enter >PlainStart.txt
xcopy 2008 "\\Bering-nas\Lothlorien-1\_PlainTest" /e
time <enter >PlainEnd.txt
ki je najprej izpisal čas začetka prenosa, nato je z ukazom xcopy prenesel merne podatke z diska na postaji Windows prek omrežja ethernet na disk v strežniku BeringNAS. Na koncu je izpisal čas konca prenosa.
Drugi skript je naredil enako, le da je podatke poslal skozi tunel na naslov "\\192.168.200.1\Lothlorien-1\_VPNtest" namesto na ethernetni vmesnik. Pri tem velja poudariti, da so šli podatki v obeh primerih fizično prek ethernetnega omrežja, le da so bili v drugem primeru tunelirani in kriptirani, to pa je predvsem obremenilo procesorja obeh računalnikov, povečalo pa je tudi količino prenesenih podatkov prek etherneta. Nato sem namesto xcopy uporabil neprimerno pametnejši paket za varnostno shranjevanje podatkov, SyncBack. Za prenos enakih podatkov je porabil natanko toliko časa kot xcopy (odmik le 5 promilov časa). Odlika SyncBacka bi se pokazala šele pri osveževanju že obstoječe oddaljene kopije podatkov z nekoliko spremenjenim izvirnikom, kjer bi bil SyncBack neprimerno hitrejši od xcopy. A to ni bil namen testiranja.
Tabela povzema rezultate meritev. V vrsticah so meritve s protokolom SMB (xcopy ali SyncBack) prek etherneta in prek tunela OpenVPN ter nato s protokolom rsync, spet najprej prek etherneta in nato prek tunela. Stolpci pa podajajo izmerjene vrednosti.
Transparentni način s SMB, lokalno
V transparentnem prenosu po 100 % izkoriščenem 100 Mb/s ethernetu bi se merni podatki morali teoretično prenesti v nekaj več kot 320 sekundah. Moj prenos prek etherneta je trajal 498 sekund. Razlika časa se je porabila za procesiranje na obeh straneh in za prenos protokolnega presežka. Procesor v strežniku je bil obremenjen 50 %.
Promet na vmesniku eth med testom T1.
Obremenjenost procesorja v odjemalcu med testom T1.
Obremenjenost procesorja v strežniku med testom T1.
Kriptirani način s SMB, lokalno
V primeru pošiljanja skozi kriptirani tunel se je obremenitev procesorja odjemalca dvignila na 35 %, prenos pa je trajal 1077 sekund ob izkoriščenosti nosilnega etherneta 36 %. Kriptiranje je zelo obremenjujoče za procesor, saj se njegova obremenitev ob 2,4 GHz taktu poveča s 17 na 35 %, torej za več kot 100 %. Na strežniški strani se obremenitev procesorja zveča na 90 %, zaradi upočasnitve delovanja pa se znatno spremeni obremenitev procesa SMB: če je brez kriptiranja SMB trošil 50 % procesorja, ga ob kriptiranju samo še 13 %. Kriptiranje samo pa celih 77 %.
Promet na vmesniku eth med tuneliranjem v testu T2. Zanimivo je, da Windows samovoljno trdi, da navidezni vmesnik (to, kar Linux imenuje tun, Windows imenuje tap) deluje s hitrostjo 10 Mb/s, čeprav je očitno, da skozenj teče več kot 30 Mb/s.
Obremenjenost procesorja na odjemalcu med testom T2. Kriptiranje očitno doda svojo težo.
Še bolj je bila zanimiva situacija na drugi strani tunela, kjer se je pod bremenom kriptoalgoritmov šibil 800 MHz procesor. Obremenitev procesorja se dvigne na 90 %, zaradi upočasnitve pretoka pa se znatno spremeni obremenitev procesa SMB: če je brez kriptiranja SMB prej trošil 50 % procesorja, ga ob kriptiranju samo še 13 %. Kriptiranje samo pa porabi celih 77 %.
Obremenjenost procesorja v strežniku med testom T2. Večina bremena je na kriptiranju. SMB ostane samo še za priokus.
Transparentni način z rsync, lokalno
Za meritev s protokolom rsync sem na delovni postaji Windows uporabil DeltaCopy. Podobno kot za meritev SMB sem pripravil dva profila: enega za shranjevanje neposredno čez ethernet in enega za shranjevanje skozi tunel OpenVPN.
Pred analizo rezultatov meritev pa kratek komentar. SMB zgolj preslikuje omrežne diske in arhiviranje z neumnim ukazom xcopy je pristop z grobo silo. Nasprotno rsync, kot je opisano zgoraj, na kopiji podatkov obnavlja samo tiste datoteke, ki se razlikujejo glede na izvirno kopijo. Pri shranjevanju prek prostranega omrežja, ki je mnogo počasnejše od okolij LAN, to pomeni velikanski prihranek časa. Moj test pa je prenašal začetno stanje, torej ni šlo za diferencialno shranjevanje, temveč je prenos obsegal vse, kar je bilo predmet testiranja med prejšnjima dvema testoma: 4 GB podatkov v 2000 datotekah. Normalen način delovanja rsync je samo prenašanje razlike.
Skozi ethernet je rsync prenesel 4 GB s povprečno hitrostjo 4,3 Mb/s v 978 sekundah. Izkoriščenost etherneta je bila približno 41 %, procesor na odjemalčevi strani je bil obremenjen približno 48 %, na strežniški pa 58 %.
Promet na vmesniku eth med testom T3
Obremenjenost procesorja na odjemalcu med testom T3
Obremenjenost procesorja na strežniku med testom T3
Kriptirani način z rsync, lokalno
Skozi tunel OpenVPN je enak prenos potekal s povprečno hitrostjo 2,3 Mb/s in je trajal 1821 sekund. Izkoriščenost etherneta je bila približno 22 %, procesor na odjemalčevi strani je bil obremenjen približno 52 %, na strežniški pa 70 %, pri čemer je OpenVPN porabil 50 %, rsync pa 20 % procesorja. Primerjava s kriptiranim načinom s SMB nam pove, da je rsync procesno bolj naporen od SMB, kar je razumljivo.
Promet na vmesniku eth med tuneliranjem v testu T4. Windows še vedno klati neumnosti o virtualnem vmesniku.
Obremenjenost procesorja na odjemalcu med testom T4
Obremenjenost procesorja v strežniku med testom T4. Dozdevno znižana obremenitev procesorja s kriptiranjem gre na račun tega, da je protokol rsync bolj zapleten in počasneje polni prenosno linijo kot enostavno kopiranje.
Testi v prostranem omrežju
Nato sem opravil testiranje še prek omrežja v realnih razmerah. Skica testa je na sliki 19. Strežnik je bil v internetnem omrežju operaterja, katerega priključek je izkazoval hitrost proti uporabniku 1,97 Mb/s [8]. Odjemalec je bil med testom v omrežju drugega operaterja s simetričnim priključkom 10 Mb/s. Hitrost odjemalca je bila torej precej višja od hitrosti strežnika in zato ni vplivala na meritev. Enako velja za hitrost etherneta, saj je bil odjemalec na priključku 1Gb/s, strežnik pa na 100 Mb/s, čeprav je ob nižji hitrosti prostranega omrežja to tako ali tako zanemarljiv podatek. Rezultati so prikazani v tabeli 2.
Preizkušanje prek prostranega omrežja je potekalo po zgornji skici.
Rezultati meritev prek prostranega omrežja
Promet SMB v kriptiranem tunelu pri testu T5. Obremenitev etherneta je še 2 % večja (glej tabelo 2).
Pri testu T5 dekriptiranje na strežniku pri hitrosti okrog 2 Mb/s pobira približno 4 % procesne moči. Pri hitrosti 22 Mb/s, ki jo je enak proces dosegel neposredno na stikalu ethernet, je dekriptiranje požiralo 77 %. SMB troši samo 1,1 %.
Promet rsync v tunelu pri testu T6. Obremenitev etherneta je še 2 % večja (glej tabelo 2).
Na strežniku je pri testu T6 dekriptiranje pri hitrosti približno 2 Mb/s pobralo enako količino procesorja kot pri testu SMB: 4,4 %. Rsync je bil skoraj dvakrat bolj požrešen od SMB: 2,1 %. Neposredno na ethernetu je bilo v testu T4 razmerje 50 : 20.
Za konec
Gradnja oddaljenega NAS je bila prijeten izziv. Naredil sem si iz omrežja hermetično zaprto škatlo, ki je sprejemala zgolj tunelske povezave na podlagi digitalnega certifikata. Razen nekaj malega običajnih zapletov s Sambo na račun lastništva datotek in pravic dostopa do diska nisem naletel na kakšne hude pasti. S hitrostjo delovanja sem bil kar zadovoljen. Na 100 Mb/s ethernetu je shranjevanje testnih podatkov trajalo 2,5 krat dlje kot neposredno kopiranje z diska na disk. Že res, da se v običajnem ljubljanskem internetnem okolju tak proces podaljša za faktor 100, a v prostranem omrežju groba sila ne igra vloge. Tu pride na vrsto prefinjenost algoritmov. Rsync ali Syncback bistveno skrajšata proces sinhronizacije diskov: čeprav arhiv meri pol terabajta, novih 500 fotografij obsega 1 GB sinhronizirata v oddaljeni kopiji arhiva prek 2 Mb/s internetne povezave v dobri uri in pol. Zvečer pred spanjem pognani proces arhiviranja zagotavlja neverjetno prijetne sanje, ko veš, da se podatki kotalijo skozi kriptiran tunel, ki ga praktično ni mogoče zlorabiti, prestavitev fizično oprijemljivega diskovnega strežnika v sfere virtualnega pa še tako konkretnim tatovom preprečuje krajo tvojih največjih zakladov.
Reference
[1] www.freenas.org/
[2] leaf.sourceforge.net/bering-uclibc/
[3] www.samba.org/rsync/
[4] www.aboutmyip.com/AboutMyXApp/DeltaCopy.jsp
[5] openvpn.net/
[6] www.openswan.org/
[7] www.tuxfiles.org/linuxhelp/fstab.html
[8] www.speedtest.net/