Linux fileserver i.c.m. usenet en virtual machines

[peak]

Hallo,

Ik heb het 1 en ander uitgewerkt, maar ik ben toch benieuwd naar jullie input.

Lees dit onderstaande als je geïnteresseerd bent.
Lees na de --------- Als je jouw configuratie wilt delen.

Ik wil al enige tijd een fileserver opzetten en krijg deze week de hardware hiervoor.
Het gaat uiteindelijk een debian server worden en dit heeft als primaire doel: fileserver.
O/S: Debian
4x 1 TB: Software raid 5
AMD athlon LE1250 = 2.2 ghz
2x 1GB geheugen
Vmware server

Nu blijft deze server dag en nacht aan staan, dus kan ik het net zo goed ook download werk laten verrichten.
Er komt o.a. sabnzbd met een web-interface en laat ik het dan ook maar torrents downloaden.

Aangezien het primaire doel: fileserver is, zit ik eraan te denken om de secundaire doelen in een virtual machine te stoppen. Zo blijft mijn fileserver intact en kan ik geen rare dingen verwachten of iets fouts doen, aangezien ik niet een gevorderde linux gebruiker ben.

Nu is mijn vraag het volgende:
sabnzbd+ gaat voor mij dingen downloaden en par/unrart ze voor mij. Deze bestanden moeten vervolgens op de fileserver komen zodat het toegankelijk is voor anderen.
Nu kan dit heel makkelijk.
Nadeel: Het download naar zijn eigen virtual machine disk, vervolgens par/unrart het. Dit resulteert weer in extra CPU en schrijf-acties. Als het hiermee klaar is, dan moet het vervolgens gekopieerd worden van zijn vm-disk naar de logische schijf zodat het beschikbaar is voor anderen. Dit veroorzaakt ook weer extra schrijf-acties.

Nu weet ik dat je een virtual machine een eigen fysieke hardeschijf kan toekennen, maar aangezien ik de file-server in een raid 5 ga draaien, lukt dit dus niet. Dat komt in conflict met de primaire doel van de server.

Nu kan ik ook een mapping maken naar de fileserver in de virtual machine en dat het rechtstreeks wat hij download gelijk op de server zet, maar als het moet parren/unrarren, dan moet het weer over het netwerk gelezen worden en dat is pas echt traag.

Nu denken jullie;
Waarom installeer je sabnzbd+ niet gewoon op de fysieke server, probleem opgelost.

Ik weet niet hoe goed sabnzbd+ is geschreven. Straks zit er een bug in die al je data corrupt maakt?
En een torrent client met web-interface op de fysieke server zie ik nou ook niet echt zitten.

Of is er een mogelijkheid dat sabnzbd+ alleen rechten krijgt tot 1 map en dat is zijn eigen download map?

---

Hoe hebben jullie je fileserver geconfigureerd i.c.m. virtual machines?

Ik wil denk ik het volgende:
Debian als host
Vmware server
vm: Windows 2003 - VPN + FTD om te zoeken
vm: Linux - sabnzbd+ + torrent met webinterface OF vm: windows xp - sabnzbd+ + utorrent.

bedankt voor het lezen van mijn lange boring verhaal en jullie input.

[CAPSLOCK2000]

Ik denk dat je je veel te veel zorgen maakt.

Allereerst, is dit een machine voor thuis of heb je een baas die het niet erg vindt dat je er op download?

Als het een thuis machine is, dan moet je wel hele gekken dingen doen om die machine te belasten. Een beetje overhead kan daar best bij. De files een keertje extra kopieren zal in de meeste gevallen zo snel gaan dat je het niet eens merkt (tenzij je naast de machine zit te wachten op je download).

Ook dat lezen over het netwerk is niet zo zwaar als jij denkt. Het hoeft namelijk niet echt over het netwerk, maar kan gewoon "binnen" de (hardware) machine blijven. Je kan de data dus zo snel versturen als je processor/schijf aan kan, ongehinderd door netwerkkaarten.

Ik zou een map aanmaken op de fileserver waar je al je downloads in wil ontvangen (al dan niet gescheiden van de rest van het systeem), en die aankoppelen vanuit de vm van waaruit je downloadt.

[peak]

CAPSLOCK2000 schreef op maandag 13 juli 2009 @ 15:51:
Ik denk dat je je veel te veel zorgen maakt.

Allereerst, is dit een machine voor thuis of heb je een baas die het niet erg vindt dat je er op download?

Als het een thuis machine is, dan moet je wel hele gekken dingen doen om die machine te belasten. Een beetje overhead kan daar best bij. De files een keertje extra kopieren zal in de meeste gevallen zo snel gaan dat je het niet eens merkt (tenzij je naast de machine zit te wachten op je download).

Ook dat lezen over het netwerk is niet zo zwaar als jij denkt. Het hoeft namelijk niet echt over het netwerk, maar kan gewoon "binnen" de (hardware) machine blijven. Je kan de data dus zo snel versturen als je processor/schijf aan kan, ongehinderd door netwerkkaarten.

Ik zou een map aanmaken op de fileserver waar je al je downloads in wil ontvangen (al dan niet gescheiden van de rest van het systeem), en die aankoppelen vanuit de vm van waaruit je downloadt.

Hoi,

Nee, voor thuis gebruik.

Het gaat met name om files van +- 10 a 20 GB.
Dat het binnen de hardware blijft met kopieeren klopt voor een deel. Het wordt wel over het ''virtueele'' netwerk verstuurd, maar in vmware is dit al standaard 1GB NIC.

Jouw laatste alinea:
Ik weet uit ervaring dat als je wat wilt uitpakken over het netwerk, dat dit erg traag gaat. Als je het bestand naar de pc toe kopieert en het lokaal uitpakt gaat dit vaak nog sneller ook.

Ik zou dus ook kunnen zeggen dat de vm virtuele schijf grootte groot genoeg maak dat die het ''lokaal'' uitpakt en vervolgens de finished downloads naar de file-server kopieert.
Echter als ik veel downloads tegelijk start, dat ik moet zorgen dat ik een virtuele schijf van minstens 100 gb moet aanmaken.
Nu kan je de ruimte al toekennen, maar dan denk ik dat een incrementele groei beter is om zo min mogelijk schijfruimte kwijt te raken. Aan de andere kant moet ik niet zeuren, want heb 4x 1 TB opslag en zit momenteel nog niet op de helft. ( 3TB effectieve opslagruimte)


Ik geef je ook gelijk. Ik maak me teveel zorgen, maar dat is omdat ik mezelf nog niet goed genoeg vind met linux. Van de belangrijke data komt hoe dan ook een back-up op een externe schijf.

Of als iemand zegt; Installeer sabnzbd+ gewoon op de host, want dat kan prima zonder gevaar.
Echter de torrents doe ik wel op een vm.

[Wolly]

Mijn ervaring is dat het kopieren vanuit een VMWare instance naar de host op Windows in ieder geval niet zo snel is als je zou verwachten. De opmerking dat het een 1GB NIC is zei bij mij dus niets over de daadwerkelijke snelheid.

De NIC in VMWare is trouwens een software component.

[peak]

Wolly schreef op maandag 13 juli 2009 @ 16:29:
Mijn ervaring is dat het kopieren vanuit een VMWare instance naar de host op Windows in ieder geval niet zo snel is als je zou verwachten. De opmerking dat het een 1GB NIC is zei bij mij dus niets over de daadwerkelijke snelheid.

De NIC in VMWare is trouwens een software component.

Via drag en drop d.m.v. vmware tools is het inderdaad trager dan dat je via het ''netwerk'' doet.
Dus naar de share op de host computer gaan in de vm is de snelste oplossing.

[UltraSub]

Installeer sabnzbd op de fysieke server. Stelt werkelijk geen drol voor.. En nee, er kan niks kapot. Echt niet.
Wijst zich vanzelf. Hier wel een handig weetje:
http://www.rutschle.net/blog/archives/2006/08/17/T22_55_16/

/edit
Overigens, wat jij wil heb ik al jaren gedaan. Ook Debian met daarin VMware Server (uiteindelijk 2.x). Daarop een W2K3 guest die alles downloadde en uitpakte op een mapped netwerk drive. Gaat best goed, maar kan sneller. De IO op de softraid 5 was vanuit VMware niet écht geweldig. Onder Debian zelf wel ok, maar ook niet om echt over naar huis te schrijven.

Mijn huidige setup:
ESX 3.5 U4 als virtualisatielaag, Dell Perc 5/i raid controller met 3x 1TB in R5. Daarop draaien alle VM's Waaronder Debian, die nog steeds sabnzbd draait. Echter die Debian heeft een softraid 5 met 5x 400GB waarop alles uitgepakt wordt. (5x 400 is middels RDM doorgegeven aan de Debian guest die er R5 van maakt). Nog steeds niet super, de performance van de R5. Eigenlijk om te huilen, maar puur voor veel opslag is het ok. Het is in ieder geval directe IO en geen netwerk meer, via een hypervisor.
De guests (dus de vmdk's) draaien natuurlijk allemaal op de Dell R5 array en die is wél retesnel. En dat komt de performance van de OS'es zeer ten goede.
Naja, kijk eens naar bovenstaande setup, kost niks (behalve de raid controller), en is SUPER te beheren en lekker flexibel.

[ Voor 72% gewijzigd door UltraSub op 13-07-2009 16:47 ]

[Wolly]

peak schreef op maandag 13 juli 2009 @ 16:37:
[...]


Via drag en drop d.m.v. vmware tools is het inderdaad trager dan dat je via het ''netwerk'' doet.
Dus naar de share op de host computer gaan in de vm is de snelste oplossing.

Ik doe altijd 'copieren' via SMB, omdat ik natuurlijk niet handmatig bestanden ga verplaatsen die ik download

Ik heb trouwens SABNZBD in een vmware host draaien (wederom op windows), omdat heel soms de unpar blijft hangen. Deze slokt dan alle cpu op en dit wilde ik niet op mijn host OS laten gebeuren. Stabiliteit is in mijn ogen belangrijker dan performance.

[peak]

UltraSub schreef op maandag 13 juli 2009 @ 16:39:
Installeer sabnzbd op de fysieke server. Stelt werkelijk geen drol voor.. En nee, er kan niks kapot. Echt niet.
Wijst zich vanzelf. Hier wel een handig weetje:
http://www.rutschle.net/blog/archives/2006/08/17/T22_55_16/

/edit
Overigens, wat jij wil heb ik al jaren gedaan. Ook Debian met daarin VMware Server (uiteindelijk 2.x). Daarop een W2K3 guest die alles downloadde en uitpakte op een mapped netwerk drive. Gaat best goed, maar kan sneller. De IO op de softraid 5 was vanuit VMware niet écht geweldig. Onder Debian zelf wel ok, maar ook niet om echt over naar huis te schrijven.

Mijn huidige setup:
ESX 3.5 U4 als virtualisatielaag, Dell Perc 5/i raid controller met 3x 1TB in R5. Daarop draaien alle VM's Waaronder Debian, die nog steeds sabnzbd draait. Echter die Debian heeft een softraid 5 met 5x 400GB waarop alles uitgepakt wordt. (5x 400 is middels RDM doorgegeven aan de Debian guest die er R5 van maakt). Nog steeds niet super, de performance van de R5. Eigenlijk om te huilen, maar puur voor veel opslag is het ok. Het is in ieder geval directe IO en geen netwerk meer, via een hypervisor.
De guests (dus de vmdk's) draaien natuurlijk allemaal op de Dell R5 array en die is wél retesnel. En dat komt de performance van de OS'es zeer ten goede.
Naja, kijk eens naar bovenstaande setup, kost niks (behalve de raid controller), en is SUPER te beheren en lekker flexibel.

Juist, ik snap em.

Wat ik niet snap is. Je hebt 3x 1 TB fysiek en deze draait in een R5 d.m.v. een controller.
Vervolgens heb jij een debian vm en daar gebruik je Software raid 5. Why ?

Dat is dus mijn volgende punt. Stel mijn hardware begeeft het op de HDD's na, dan wil ik heel makkelijk mijn HDD's in een ander pc kunnen stoppen en de software raid weer benaderen.
Stel je vmdk raakt corrupt, dat is alsnog 1 grote file wat je aan data kwijt bent. (wellicht zijn er vmdk recovery tooltjes op het net, heb me hierin nog niet verdiept)
Vandaar dat ik geen ESX ga gebruiken.

Overigens denk ik wel dat ik jouw vorige aanpak ga doen. Debian host en daaronder vmware server en daar vm's die downloaden. Mocht daar wat mee gebeuren, dan is het een snapshot of reinstall/copy. ( vmware server kan geen snapshots maken dacht ik zo)

Denk overigens dat ik sabnzbd op een windows vm ga installeren. Kan nou niet echt veel recente tutorials vinden om het op debian te installeren. Ookal is er wel een .deb op http://www.mbastiaan.nl/sabnzbd.php
Windows blijft wat dat betreft toch wel weer gemakkelijk qua installeren.

[ Voor 5% gewijzigd door peak op 13-07-2009 19:23 ]

[UltraSub]

peak schreef op maandag 13 juli 2009 @ 19:21:
[...]

Juist, ik snap em.

Wat ik niet snap is. Je hebt 3x 1 TB fysiek en deze draait in een R5 d.m.v. een controller.
Vervolgens heb jij een debian vm en daar gebruik je Software raid 5. Why ?

Ik wilde de OS'es, dus de Guests, op snelle storage hebben draaien. Maar wel protected. Dus wilde ik een battery backupped hardware raid hebben. 3 disks is het minimum voor R5, en 2TB is (was) de max vmfs size in ESX. Vandaar 3x 1TB.
Dan zou ik dus 5x 400GB niet meer gebruiken. Ook zonde. Daarnaast, heel veel data backuppen en restoren. Mdadm goed kennende, wist ik dat als ik het voor elkaar kreeg om deze 5 disks middels een raw device map aan de virtuele Debian door te geven, het appeltje eitje zou zijn om de oude raid 5 array te herstellen. Zo gezegd zo gedaan. En presto; 1.5TB netto extra, en geen backup/restore

Dat is dus mijn volgende punt. Stel mijn hardware begeeft het op de HDD's na, dan wil ik heel makkelijk mijn HDD's in een ander pc kunnen stoppen en de software raid weer benaderen.

Groot, heel groot, zo niet allergrootste voordeel van mdadm softraid inderdaad. Maar dat kan in mijn situatie dus ook nog eens. Was ook een van mijn beweegredenen.

Stel je vmdk raakt corrupt, dat is alsnog 1 grote file wat je aan data kwijt bent. (wellicht zijn er vmdk recovery tooltjes op het net, heb me hierin nog niet verdiept)
Vandaar dat ik geen ESX ga gebruiken.

Eeh, dat is ook zo met VMware server he! Die gebruikt ook gewoon vmdk's! Maarrrrr... Vmdk's zijn super makkelijk te backuppen (en zippen geweldig!), en eigenlijk heb je als je die backupped een ghost..

Overigens denk ik wel dat ik jouw vorige aanpak ga doen. Debian host en daaronder vmware server en daar vm's die downloaden. Mocht daar wat mee gebeuren, dan is het een snapshot of reinstall/copy. ( vmware server kan geen snapshots maken dacht ik zo)

Denk overigens dat ik sabnzbd op een windows vm ga installeren. Kan nou niet echt veel recente tutorials vinden om het op debian te installeren. Ookal is er wel een .deb op http://www.mbastiaan.nl/sabnzbd.php
Windows blijft wat dat betreft toch wel weer gemakkelijk qua installeren.

Ok. Besef wel dat mijn hoofdreden om weg te moven naar ESX ipv Vmware Server de performance was. ESX was op exact dezelfde hardware VEEL sneller. Echt een factor 3 of zo. Heel goed te merken met 64-bit OS'es. Je kunt een hoop tijd (en werk) besparen door meteen naar ESX te gaan, en niet achteraf alles weer om hoeven gooien. Maar goed.. de oplossing werkt goed. Die heb ik immers jaren gedraaid. Wilde alleen wat meer.

[Verwijderd]

peak schreef op maandag 13 juli 2009 @ 19:21:
Windows blijft wat dat betreft toch wel weer gemakkelijk qua installeren.

Onzin er zijn prima niet propertairy virtualisatie systemen: Xen, KVM, OpenVZ enz enz. Die zeer eenvoudig op een Linux systeem te installeren en te onderhouden zijn. Begrijp ook niet waarom mensen VMWare op een Linux systeem gaan installeren terwijl er prima open alternatieven zijn.

[peak]

Verwijderd schreef op maandag 13 juli 2009 @ 21:14:
[...]


Onzin er zijn prima niet propertairy virtualisatie systemen: Xen, KVM, OpenVZ enz enz. Die zeer eenvoudig op een Linux systeem te installeren en te onderhouden zijn. Begrijp ook niet waarom mensen VMWare op een Linux systeem gaan installeren terwijl er prima open alternatieven zijn.

Haha,
Thanks voor je input, maar ik doelde op sabnzbd i.c.m. debian.
Er is toevallig iemand die een .deb heeft gemaakt, maar anders moet je alles los met de hand doen en bij windows is het slechts 1 .exe bestand aanklikken en het wordt geinstalleerd.

Dat bedoelde ik met mijn zin maar ik snap je reactie haha

[CAPSLOCK2000]

't zit al in Debian Unstable onder de naam sabnzbdplus

[sariel]

Tsja, als je het zonder Windows kan doen, vserver zorgt voor VEEL minder overhead in je stapel VM's. Je zit maar op een paar procent vertraging (0-5%) in plaats van de aanzienlijke vertraging die VMware veroorzaakt door letterlijk alles te virtualiseren.

FTD werkt prima onder Linux (zonder X, kan gewoon x-forwarding doen naar je x-client op windows), VPN hoef je dan ook niet te doen, gewoon SSH met ssh-keys (GEEN wachtwoorden, te veel kiddies die automated wachtwoord-bruteforcers laten draaien, 1x wachtwoord fout -> block IP). Als je toch VPN wil gebruiken kan dat natuurlijk ook met openvpn oid.
Fileserver kan Linux ook prima doen: smb, nfs, etc.
NZB clientje draaien gaat dan ook een stuk sneller omdat je minder CPU overhead hebt, bijna geen geheugenoverhead en alle data wordt naar je schijven geschreven in plaats van naar virtuele schijven.

[peak]

sariel schreef op dinsdag 14 juli 2009 @ 12:00:
Tsja, als je het zonder Windows kan doen, vserver zorgt voor VEEL minder overhead in je stapel VM's. Je zit maar op een paar procent vertraging (0-5%) in plaats van de aanzienlijke vertraging die VMware veroorzaakt door letterlijk alles te virtualiseren.

FTD werkt prima onder Linux (zonder X, kan gewoon x-forwarding doen naar je x-client op windows), VPN hoef je dan ook niet te doen, gewoon SSH met ssh-keys (GEEN wachtwoorden, te veel kiddies die automated wachtwoord-bruteforcers laten draaien, 1x wachtwoord fout -> block IP). Als je toch VPN wil gebruiken kan dat natuurlijk ook met openvpn oid.
Fileserver kan Linux ook prima doen: smb, nfs, etc.
NZB clientje draaien gaat dan ook een stuk sneller omdat je minder CPU overhead hebt, bijna geen geheugenoverhead en alle data wordt naar je schijven geschreven in plaats van naar virtuele schijven.

Oke. vserver kende ik idd nog niet. Maar als ik het goed begrijp dan kan er alleen linux ''vservers'' geinstalleerd worden aangezien de kernel gedeeld wordt.

voor PPTP vpn verbinding blijf ik toch liever bij windows server. Heb er ervaring mee en weet dat het werkt.
Het enige waar ik nog aan twijfel is of ik sabnzbd of een ander gelijke web-gui programma op de fileserver ga installeren of in een virtual machine.

Het is straks de bedoeling dat alleen het lokale netwerk verbinding mag maken met de fileserver (met name de shares) en vandaar de windows vpn server wanneer ik niet lokaal zit. Tevens installeer ik hier ook gelijk FTD op voor de andere gebruikers.