Mijn FreeBSD Server: Deel 3 - ZFS & Mail

Door Lima op woensdag 15 december 2010 19:30 - Reacties (13)
Categorie: FreeBSD, Views: 6.025

ZFS was voor mij één van de redenen waarom ik FreeBSD koos. Dankzij de BSD licentie is het mogelijk om dit fantastische filesystem te gebruiken op FreeBSD, waar ik dan ook dankbaar gebruik van maak.
Waarom is ZFS zo interessant? Wel hier zou je bijna een volledig boek over kunnen schrijven, maar ik haal even de belangrijkste punten aan.

Theoretisch
Meestal zal ik een groot stuk theoretisch bespreken, om de achterliggende concepten te begrijpen zodat problemen soms snel kunnen begrepen worden. Verder volgt ook een praktisch gedeelte, het "hands-on" gedeelte zeg maar.
Zettabyte File System?!
Jawel je hoort het goed, Zettabyte! Hoeveel Terrabyte is dit? Wel:
1073741824 Terrabyte :) Erg veel dus! Laten we stellen dat je in praktijk dus nooit tegen deze limiet zal aanlopen. Hoe komt het dat ZFS zo een grote limiet heeft? Dit komt omdat ZFS gebruikt maakt van 128bit adressering. Hierdoor kan het dus 2^128 blocks aanspreken.
Copy-on-write
ZFS maakt gebruik van een copy-on-write model. Hierbij komt het erop neer dat er meerdere metadata blokken kunnen verwijzen naar hetzelfde data blok. Dit zorgt er dus voor dat er geen nutteloze kopijen worden bijgehouden van dezelfde datablokken. Het grote voordeel van dit systeem komt pas tot zijn recht als er een van de verwijzende metadata blokken het datablok wil wijzigen. Dan wordt het metadata blok zodanig gewijzigd dat dezelfde datablok gebruikt word + de wijzigingen worden opgeslagen in een andere datablok. Een toepassing hiervan zijn bv de snapshots die ik later bespreek.
Data integriteit
Dit is dé reden waarom ik voor ZFS koos. Ik wil dat mijn data zo veilig mogelijk staat, en niet corrupt word bij het minste probleem. ZFS is van de grond af aan ontworpen om deze taak zo goed mogelijk te vervullen, en laat de concurrentie ver achter zich op dit gebied.

Silent Corruption

Dit is het corrupt worden van data zonder dat je het doorhebt. Dit kan komen door allerlei factoren. Fouten in geheugen waardoor CRC checksums mislopen, overclockte CPU's waardoor bv een floating point berekening niet juist word uitgevoerd en er 1 bit verkeerd word opgeslaan. Op deze manier sluipen er langzaam maar zeker fouten in je data. Meer hierover kan je lezen in het CERN data-rapport
Hoe pakt ZFS dit dan aan? Wel hier kan je een erg mooie demo vinden waaruit blijkt dat ZFS de integriteit van data blijft verifiëren en zo deze fouten kan oplossen. Ofwel kan je ook naar onderstaande video kijken.



Bit rotting

Opnieuw spreekt deze term voor zichzelf. Sommige bits durven wel eens te veranderen van waarde op je harde schijf na verloop van tijd. Hoe komt dit? Wel stel er is 10 keer een 0 geschreven naar dezelfde plaats op je harde schijf. Na 5 maanden schrijf je op exact deze plaats een 1. De waarde van die bit zal dan dus een 1 bedragen, maar de magnetische waarde van die bit zal dan bijvoorbeeld 0,55 zijn (fictief gesproken), dus net genoeg om een 1 voor te stellen. Na verloop van tijd kan deze dan dus wel eens verminderen van waarde naar bv 0,45 waardoor deze bit nu aan logische 0 voorstelt! Dit fenomeen is dus bit rotting, het vervagen van informatie over tijd. Hoe snel deze informatie vervaagt hangt af van je medium.
Wat doen de meeste filesystems hiervoor? Wel ze nemen een checksum van een blok data, zodat ze later de data kunnen verifiëren aan de hand van de checksum en voegen deze bij in dezelfde blok data. Echter kunnen hierdoor nog steeds verschillende zaken fout gaan:

- DMA pariteitsfouten (fouten tijdens transfer van geheugen naar hdd en vice versa)
- Driver fouten waardoor de checksum ergens verkeerd word opgeslagen
- Accidentele fouten waarbij de blok overschreven word.

ZFS heeft hier een oplossing voor. De checksum word opgeslagen naast de pointer die naar dit data blok verwijst. De meeste andere filesysteem slaan de checksum op in dezelfde datablok! Ook word er altijd een checksum on the fly berekend als dit data blok word geraadpleegd. Vroeger zou dit een te zware belasting geweest zijn maar tegenwoordig kan dit helemaal geen kwaad meer. Hierdoor worden ook eerder genoemde problemen voorkomen, want de checksum zit meteen in het geheugen en kan meteen vergeleken worden met de opgeslagen checksum :)
Een mooi voorbeeld dat de kracht hiervan aantoont is als men bij een mirror configuratie rommel zou schrijven op slechts 1 schijf. ZFS ziet dat er data blokken worden geraadpleegd en haalt de desbetreffende checksums erbij die zijn opgeslagen. Tevens maakt ZFS een checksum van de data die op de schijf staat die niet word beschreven, en van de rommel die op de andere schijf word geschreven. Hierdoor kan ZFS meteen beslissen dat de mirror niet meer gesynchroniseerd is en begint met rebuilden. Want de checksum die is opgeslagen klopt met 1 van de schijven, en niet met de andere schijf. Een ander filesystem zou hier niks van merken, laat staan meteen corrigeren. Ook zou je het achteraf manueel moeten uitzoeken welk stuk data nu het gewenste is.
Storage pools
Normaal word er steeds een volume manager gebruikt die het beheer van schijven voor zich neemt. Bij ZFS bestaan filesystemen uit virtuele storage pools. Deze storage pools bestaan uit virtuele devices (afgekort vdev's). Deze vdev's bestaan uit block devices; verschillende volledige harde schijven, partities van harde schijven, of zelfs één of meerdere files!

Configuratie mogelijkheden

Je kan vdev's configureren op verschillende manieren. RAID 0, RAID 1 van 2 of meerdere veda's, RAID5 (RAID-Z genaamd in ZFS) van 3 of meer vdev's, en tenslotte zijn er ook de meer redundante RAID5 levels. RAID-Z2 vanaf 4 of meer vdev's, en vanaf 2009 is er ook RAID-Z3 waarbij dus 3 schijven kunnen uitvallen.
Ook zijn er "hot spares" mogelijk, waarbij een schijf klaar staat om een falende schijf over te nemen.
Verder is er ook ondersteuning ingebouwd voor caching. Hier kan je bijvoorbeeld een SSD inschakelen die dan actieve data zal cachen waardoor lezen en schrijven veel sneller wordt en de belasting deels van de harde schijven word gehaald.
Features
Property's

Er zijn nog een erg groot aantal opties die je kan instellen, hiervoor moet je eens zoeken bij de properties van een ZFS dataset. Zo is het mogelijk de ingebouwde samba sharing te activeren, of de ingebouwde NFS server. Hierdoor word het delen van bestanden erg eenvoudig en vooral ook snel. Samba sharing word momenteel nog niet ondersteund in FreeBSD, maar met de nieuwe versie die eraan komt zal dit er misschien wel bij zitten. Misschien zeg ik, omdat de huidige samba implementatie van FreeBSD met de AIO module voor een erg goede performance zorgt :)
Ook is het natuurlijk mogelijk om quota's en reservations te gebruiken, welke ik nog zal bespreken verderop.

Snapshots en clones

Deze twee komen voort uit het gebruikte copy-on-write systeem. Als een datablok gewijzigd wordt dan kan erg eenvoudig de vorige versie behouden worden door in de metadata de oude verwijzing te behouden. Een snapshot of een clone is dus een kopie van alle metadata blokken. Bij een snapshot wordt dus eigenlijk een versie van je huidige filesystem opgeslagen. Let wel, dit is dus geen kopie! Er word geen extra opslagruimte verbruikt, want vanaf de snapshot genomen is worden alleen de wijzigingen in het filesystem opgeslagen. Als je dus na een snapshot 1 bestand extra opslaat komt alleen dat bestand erbij in datablokken. Als je een bestaand bestand wijzigt, worden dus alleen de datablokken die gewijzigd zijn opgeslagen.
Bij een clone word een kopie op analoge wijze als een snapshot bijgehouden. Eén of meerdere clones kunnen dus erg veel datablokken gemeenschappelijk hebben, en opnieuw worden alleen wijzigingen opgeslagen.

Deduplication

Dit is momenteel nog niet mogelijk in de huidige FreeBSD versie, maar met versie 8.2 in het verschiet zal dit waarschijnlijk wel mogelijk zijn. Wat is deduplication nu? Wel hierbij wordt bij het aanmaken van een bestand gekeken of er niet al een bestand bestaat dat gemeenschappelijke datablokken heeft. Dit heeft zowel een enorm groot voordeel als nadeel. De bijkomende belasting voor te kijken of er gemeenschappelijke datablokken zijn is erg groot. Daarentegen kan op deze manier veel efficiënter omgegaan worden met de beschikbare storage. Bijvoorbeeld: Een server moet virtuele machines hosten. Neem nu dat elke virtuele machine draait op Windows XP, dan zullen er x aantal Windows XP machines moeten worden opgeslagen. Maar als deduplication word gebruikt, dan ziet ZFS dat er enorm veel gemeenschappelijke data blokken zijn (alles basisbestanden van Windows XP bijvoorbeeld) waardoor al deze gemeenschappelijke datablokken slechts 1 keer worden opgeslagen! Dit kan dus een enorm groot voordeel zijn! Voor huis-, tuin- en keukenservers is dit een veel te grote belasting, aangezien er minstens 8GB geheugen word aangeraden, en per TB aan storage nog eens 2GB. Maar het is wel mogelijk om 's nachts met een cronjob ZFS te laten zoeken, zodat de workload verdeeld word. Dan kan je 's ochtends ineens x aantal GB hebben vrijgemaakt :) Let wel, vergelijkbare resultaten zijn mogelijk door clones te nemen, maar dan moet je dit bewust doen. Deduplication detecteert dit voor jou, zodat je hier geen last van hebt.
Hands-on
Ik heb 4 x 2TB Samsung F4's die ik in een RAIDZ configuratie wil steken. Mijn schijven zijn ad4, ad6, ad8 & ad10. Op deze manier verlies ik 1/4de aan opslag, maar heb ik een redelijk veilige configuratie. Waar je bij andere filesystemen eerst partities moet toekennen, het filesysteem kiezen, mountpoint enz, is dit bij ZFS slecht 1 commando, wel moeten we eerst ZFS activeren opnieuw in /etc/rc.conf:
$ echo 'zfs_enable="YES"' >> /etc/rc.conf
$ zpool create storage raidz /dev/ad4 /dev/ad6 /dev/ad8 /dev/ad10
Voila dat was het! Nu heb je een RAIDZ systeem gemaakt bestaande uit 4 schijven, met als dataset naam "storage". Hierbij word automagisch een mountpoint gemaakt op de root, namelijk /storage. Het mountpoint en andere properties kunnen gewijzigd worden bij bovenstaand commando door de desbetreffende optie mee te geven. Je kan je net aangemaakt storage pool verifieren door het volgende commando:
$ zpool status
pool: storage
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
storage ONLINE 0 0 0
raidz1 ONLINE 0 0 0
ad4 ONLINE 0 0 0
ad6 ONLINE 0 0 0
ad8 ONLINE 0 0 0
ad10 ONLINE 0 0 0

errors: No known data errors
Niet-zo-Pro-tip:
Moest er er nu 1 van mijn schijven falen, weet ik niet welke schijf wat is. Daarom is het verstandig om je schijven te "labelen" zodat je in plaats van ad4 een logischere naam hebt staan. Ik heb dit dus niet gedaan, maar in een update zal ik nog bespreken hoe dit moet.

Quota's en reservations

Bij mijn server wil ik een aparte backup "schijf" die 1TB groot is. Hierop laat ik alle Windows 7 PC's thuis op backuppen. Ik moet er dus voor zorgen dat ik sowieso 1TB ter beschikking heb, en dat er niet meer als 1TB kan worden opgeslagen. Hiervoor gebruik ik een quota, om een limiet van 1TB op te leggen aan de dataset. Dit wel echter nog niet zeggen dat er steeds 1TB beschikbaar zal zijn op mijn server, daarvoor gebruiken we dan een reservation. Zoals het woord zelf zegt reserveert ZFS dan 1TB voor je dataset.
$ zfs create -o quota=1TB -o reservation=1TB storage/backups
Dit zal dus een map maken in /storage genaamd backups. Hier kan je dus ook zien hoe je property's kan meegeven in een create commando. Op deze manier kan je dus ook een mountpoint kiezen.

Voldoet mijn configuratie?

Mijn server word gebruikt als NAS. Dit wil dus zeggen dat alles door de netwerkkaart moet. Dan mag je rekenen op een maximum troughput van ongeveer 70MB/sec met een gigabit netwerkkaart. Ik zou dus graag willen dat mijn systeem tegen 70MB/sec kan lezen en schrijven. Mijn schijven zijn zeker niet de bottleneck, want deze halen die snelheden al op zichzelf. Echter zorgt ZFS wel voor een zekere CPU load, welke hier de bottleneck is. Hiervoor schrijf ik een file naar mijn storage dataset, en kijk ik met het top commando hoe erg mijn CPU belast word:
$ dd if=/dev/zero of=somefile bs=1m count=4k
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 41.668926 secs (103073626 bytes/sec)
En de gedeeltelijke output van het top commando:
CPU: 0.0% user, 0.0% nice, 100% system, 0.0% interrupt, 0.0% idle
Als besluit kunnen we zeggen dat we schrijfsnelheden halen van 103MB/sec met een CPU die 100% belast is. Dit wil dus zeggen dat als we hierbij een sharing protocol zoals samba mogen rekenen de CPU load nog zwaarder zal zijn en de transfer snelheden dus zullen dalen. Aangezien ik nu 103MB/sec haal zal dit nog steeds ruim voldoende zijn om mijn netwerkverbinding vol te trekken.
Mail
Als standaard mail server word er sendmail gebruikt in FreeBSD. Dit is een erg ingewikkelde mailserver (met erg veel mogelijkheden natuurlijk) die erg moeilijk is om in te stellen. In een ver verleden heb ik deze eens ingesteld, maar het is gewoonweg te veel werk, zeker als je bekijkt waarvoor ik de mailserver maar gebruik. Daarom kies ik er voor om een veel eenvoudigere mailclient in te stellen. Deze zal geen mails kunnen ontvangen, enkel verzenden. Dit is het enige wat voor mij een vereiste is. Zo kunnen websites via php scripts mails verzenden enz...

Om te beginnen installeren we deze mailclient:
$ whereis ssmtp
ssmtp: /usr/ports/mail/ssmtp
$ cd /usr/ports/mail/ssmtp
$ make config-recursive install clean
Pro-tip
Om rechtstreeks naar een directory te gaan met whereis kan je dit commando gebruiken:
$ cd `whereis -sq ssmtp`
#let op de speciale ticks `
Hierna moeten we sendmail uitschakelenen ssmtp inschakelen, dit doen we in /etc/rc.conf:

sendmail_enable="NO"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"
ssmtp_enable="YES"

Dan rest ons nog ssmtp te configureren, ik gebruik mijn gmail account, maar er zijn nog andere opties te vinden ook. Gebruik ee om de configuratie in te geven:
$ ee /usr/local/etc/ssmtp/ssmtp.conf
En geef je dit in:
root=email@gmail.com
mailhub=smtp.gmail.com:587
AuthUser=email@gmail.com
AuthPass=***************
UseSTARTTLS=YES
Let wel op, als je gebruikt maakt van een package of er gaat iets mis tijdens je installatie, dan kan het zijn dat je de inhoud van /etc/mail/mailer.conf moet veranderen alst volgt:
#sendmail /usr/libexec/sendmail/sendmail
#send-mail /usr/libexec/sendmail/sendmail
#mailq /usr/libexec/sendmail/sendmail
#newaliases /usr/libexec/sendmail/sendmail
#hoststat /usr/libexec/sendmail/sendmail
#purgestat /usr/libexec/sendmail/sendmail
sendmail /usr/local/sbin/ssmtp
send-mail /usr/local/sbin/ssmtp
mailq /usr/local/sbin/ssmtp
newaliases /usr/local/sbin/ssmtp
hoststat /usr/bin/true
purgestat /usr/bin/true
Hierna moet je wel rebooten! Als je deze stap vergeet zal het systeem dus niet werken! Als alles goed is ingesteld krijg je normaal elke nacht 2 mails van je server, een mail waarin een algemeen overzicht staat en een aparte security mail. Deze mail word verzonden als root, en gebruikt als afzender de naam van de root. Aangezien we deze nog niet hebben ingesteld zal dit dus de default waarde hebben (nl: Charlie &). Dit veranderen we als volgt:
$ pw usermod -n root -c "rootnaam"
Zo dit was het dan voor deze blog, volgende keer ga ik verder met het instellen van Samba, wat ook een hele klus kan zijn!

Volgende: Mijn FreeBSD Server: Deel 4 - Samba 05-'11 Mijn FreeBSD Server: Deel 4 - Samba
Volgende: Mijn FreeBSD Server: Deel 2 - Post installatie 11-'10 Mijn FreeBSD Server: Deel 2 - Post installatie

Reacties


Door Tweakers user Dadona, woensdag 15 december 2010 19:35

Is iSCSI niet interessant?
Voor de rest op het oog interessant, over een paar dagen ga ik eindelijk mijn (te) lang uitgestelde plannen uitvoeren, waaronder FreeBSD. :)

Door Tweakers user TRRoads, woensdag 15 december 2010 20:26

ZFS is echt een geweldig FS voor nerds, allemaal fixes voor problemen die nooit voorkomen :D

Door Tweakers user Mar2zz, woensdag 15 december 2010 21:25

Thx, heel leerzaam stuk over ZFS. Ik wist er geen klap van, maar nu alles mag ik aannemen. Ik moet toch maar eens met een BSD gaan stoeien, in ver verleden al eens gedaan. freenas, is daar afgeleide van toch?

Wat is nou het grootste argument in het voordeel van *BSD vs. Linux?

Door Tweakers user base_, woensdag 15 december 2010 21:26

Ik denk dat het voor velen nog niet duidelijk is dat je met ZFS een betrouwbare raid storage kan opbouwen zonder dure hardware controller, iets wat ik voor mijn thuisserver zeker nog ga doen! Je weet hier mooi de belangrijkste aandachtspunten voor ZFS neer te zetten, FreeBSD ftw :)

Door Tweakers user Lima, woensdag 15 december 2010 21:35

@Dadona
iSCSI is zeker interessant, maar ik doel op gebruiksgemak en out-of-the-box functionaliteit. Als ik moet uitleggen aan mijn ouders of zussen hoe je een iSCSI schijf aankoppelt.... Daarom opteer ik voor samba, zodat mijn server gewoon in netwerklocaties verschijnt.

@TRRoads
Het is maar van zeker te zijn, mijn files met onder andere kostbare digitale foto's moeten nog een hele tijd meegaan! Daarom heb ik ze dan liever extra veilig staan! Het is niet dat ik een erg dure raid 10 heb staan met allerlei dure hardware. Ik maak weloverwogen beslissingen om een medium te vinden tussen kostprijs en redudancy.

@Mar2zzz
BSD is interessant door zijn licentie, anders zou ZFS bijvoorbeeld niet mogelijk zijn. Freenas is idd een afgeleide, met een gigantisch veel lagere leercurve dan FreeBSD. En ik moet je teleurstellen, je weet nog lang niet alles van ZFS nu, maar het belangrijkste wel :)

@base_
Ik denk dat de meeste wel redelijk snel inzien dat het hier om een software raid gaat zonder bijkomende dure hardware controllers?

Door Tweakers user HyperBart, woensdag 15 december 2010 22:50

Hulde! _/-\o_
wou al zo lang iets meer leren over ZFS, maar dit maakt het wel heel makkelijk...

Volgende NAS eens zelf bouwen en misschien toch eens met ZFS proberen? Klinkt wel ongelooflijk robuust...
(of als NAS-vendors ZFS gaan gebruiken _/-\o_ )

[Reactie gewijzigd op woensdag 15 december 2010 22:52]


Door Tweakers user Dadona, woensdag 15 december 2010 23:10

ZFS vraag nogal wat resources om zo veilig te zijn en tegelijk nette prestaties neer te kunnen zetten. Zo heb je voor ZFS wel de nodige hoeveelheid geheugen nodig om het lekker te laten draaien, daar zit het eerste probleem met menig NAS. Maar daarnaast is het met beperkte hardware niet het snelste, terwijl de meeste gebruikers daar snel over gaan klagen.

Zou de gemiddelde consument nu de extreme hoge datazekerheid op prijs stellen dan zie ik een mogelijkheid. Maar de gemiddelde consument gaat toch nog doorgaans voor een simpele opslag, lage prijs en goede prestatie. De extra zekerheid is niet goed kwantificeerbaar, dus gaat de consument daar niet voor.

Door Tweakers user HyperBart, donderdag 16 december 2010 15:21

Dadona schreef op woensdag 15 december 2010 @ 23:10:
ZFS vraag nogal wat resources om zo veilig te zijn en tegelijk nette prestaties neer te kunnen zetten. Zo heb je voor ZFS wel de nodige hoeveelheid geheugen nodig om het lekker te laten draaien, daar zit het eerste probleem met menig NAS. Maar daarnaast is het met beperkte hardware niet het snelste, terwijl de meeste gebruikers daar snel over gaan klagen.
Niets wat een zuinig AMD'tje of mss zelfs een i3'tje niet aankan toch?

Door Tweakers user P5ycho, woensdag 22 december 2010 07:52

TRRoads schreef op woensdag 15 december 2010 @ 20:26:
ZFS is echt een geweldig FS voor nerds, allemaal fixes voor problemen die nooit voorkomen :D
Totdat je dit in je logs terugvindt:
Checking status of zfs pools:
pool: zroot
state: ONLINE
status: One or more devices has experienced an unrecoverable error. An
attempt was made to correct the error. Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
using 'zpool clear' or replace the device with 'zpool replace'.
see: http://www.sun.com/msg/ZFS-8000-9P
scrub: resilver completed after 0h0m with 0 errors on Thu Sep 9 10:54:19 2010
config:

NAME STATE READ WRITE CKSUM
zroot ONLINE 0 0 0
mirror ONLINE 0 0 0
gpt/zfsdisk1 ONLINE 0 3 0 6.77M resilvered
gpt/zfsdisk0 ONLINE 0 0 0 2.09M resilvered

errors: No known data errors
Een ATA error uit het niets, na 2 jaar probleemloos draaien. Zonder problemen opgelost(door een resilvering, niets aan hardware gedaan), en niet meer voorgekomen sindsdien. Dan haal je opgelucht adem als je ZFS gebruikt, en ben je met een beetje pech een halve dag aan het rebuilden als je enige andere standaardvorm vorm van RAID gebruikt.

Overigens is rebuilden zeer schijf-intensief en tijdens een rebuild is je array nu net niet beschermd tegen corruptie/uitval/andere errors!

[Reactie gewijzigd op woensdag 22 december 2010 08:00]


Door Tweakers user sloth, dinsdag 4 januari 2011 16:02

Heel interessante blog. Vooral je uitleg over ZFS wist ik erg te smaken.
Super hoe je complexe dingen helder weet uit te leggen in een 'Whats in it for me' vorm!

Kan alvast niet wachten op je volgende deel, doe zo door! _/-\o_

Door Tweakers user Lima, dinsdag 4 januari 2011 16:05

Thx sloth! Na de examens komt het volgende deel, of als ik ergens een gaatje vind...

Door Tweakers user vex4vex, donderdag 12 mei 2011 13:38

Hele mooie stukjes leesmateriaal!
Enig idee wanneer de handleiding voor Samba komt?
En zou die handleiding dan ook een tutorial bevatten voor hoe je vanuit je windows pc over het netwerk je filmpjes kunt overpompen / afspelen?

Erg bedankt voor de moeite zover al!

Door Tweakers user Lima, donderdag 12 mei 2011 15:57

Bedankt :) Het stuk over samba is bijna af. Van zodra ik tijd heb zet ik dit stuk erop, dit zal toch zeker binnen de week zijn.

Reageren is niet meer mogelijk