Interner Entwicklungs- und Fileserver: Debian oder Windows Server


Heute ist der neue Server gekommen. ESXi läuft bereits und nun wird testweise die erste Debian-Maschine installiert.

Was mich gerade etwas in der untransparenten Lizenzpolitik von VMWare stutzig macht: ESXi ist kostenlos, aber der Client zur Verwaltung kostet was, richtig? Und wenn ich es richtig gesehen habe, nicht gerade wenig.

Kann den ESXi auch ohne den Client verwaltet werden? Über die Konsole oder dergleichen?
 
Der Client kostet nichts, er kann auch direkt vom eigenen Server geladen werden, wenn man mit nem Webbrowser auf die ESXi Ip geht.

Nein, der ESXi kann nur mit dem Client konfiguriert werden. Und das ist völlig ok so.

Was kostet, sind die anderen VSphere Bestandteile, die man aber mit einem Einzelserver nicht braucht.
 
OK, dann werde ich mal sehen, was in 60 Tagen passiert, da ich beim Starten des Clients immer darauf hingewiesen werde, dass die Testphase in 60 Tagen abläuft.

Noch eine andere Frage bezüglich der Festplattenaufteilung:

Ich habe ab Werk eine 500er-Platte, die ich ja eigentlich verwenden kann. Zusätzlich sind mehrere 2TB-Platten drin (nicht im Raid). Da ich bis jetzt nur wenig Erfahung mit VMWare habe, wie macht man denn hier die Aufteilung? Ich nehme an, man muss im Vorfeld beim Definieren der VM sagen, wie groß die Festplatte sein soll. Dann werden alle Files innerhalb der VM gespeichert, richtig? Oder gibt es auch eine Möglichkeit, das OS von den Files zu splitten? Wie würdet ihr hier diese Aufteilung machen?
 
Was die Virtualisierung des Fileservers angeht, bin ich gerade auch etwas skeptisch geworden.

Ich sehe hier folgende Nachteile:
  • Flaschenhals, da virtualisiert
  • Ich muss die 4 Kerne in jeweils 2 splitten
  • Ich muss den Speicher splitten
  • Ich muss die FreeNAS-Platte mit ZFS formatieren. Leider kann ich es nicht beurteilen, aber über ZFS scheiden sich die Geister

Ich sehe ein paar wenige Vorteile:

  • FreeNAS bringt alle Daemons mit, die ich brauche (Apple-Shares und Samba)
  • Es spart mir etwas an Arbeitszeit, da ich diese Features einfach nutzen kann
  • Verwaltungsoberfläche (z.B. Userverwaltung und Berechtigungen)
  • Backup-Routinen

Bin mir nicht sicher, ob die Virtualisierung nicht einen gewissen Overhead für unsere Zwecke darstellt und evtl. sogar Gefahren darstellt.

Wie seht ihr das mit der Virtualisierung des Fileservers als FreeNAS? Kann man bereits im Vorfeld sagen, dass ein reines, nicht virtualisiertes Debian mit LAMP-Umgebung und Netatalk (+Samba) mehr Performance und Sicherheit bringt?
 
OK, dann werde ich mal sehen, was in 60 Tagen passiert, da ich beim Starten des Clients immer darauf hingewiesen werde, dass die Testphase in 60 Tagen abläuft.

Die Seriennummer dazu findest Du im VMWare Account, dort wo Du auch ESXi heruntergeladen hast. Log Dich in https://my.vmware.com/de/web/vmware/login ein und hol Dir die Nummer. Dann ist der ESXi und natürlich auch der Client unbefristet verwendbar.

Ich habe ab Werk eine 500er-Platte, die ich ja eigentlich verwenden kann. Zusätzlich sind mehrere 2TB-Platten drin (nicht im Raid). Da ich bis jetzt nur wenig Erfahung mit VMWare habe, wie macht man denn hier die Aufteilung?

Wie ich bereits mehrfach geschrieben habe: ein Hardware Raid Controller ist eigentlich PFLICHT für einen ESXi (wie auch für jeden anderen Fileserver). Du wolltest einen separat besorgen. Also, wo ist der? Ohne diesen macht eigentlich die ganze Konfiguriererei wenig Sinn!

ESXi selbst kannst Du auch auf einen 2 GB USB oder SATA Stick installieren. Eine Trennung von ESXi und den Datastores ist sinnvoll. Außerdem lässt sich ein Stick leicht backuppen und austauschen.

Die Festplatten werden dann mit dem ESXi Client für Datastores konfiguriert, von denen Du mehrere haben kannst. In diesen Datastores legst Du dann Deine VMs an. Du kannst jederzeit auch mehrere virtuelle HDs pro VM konfigurieren, z.B. eine 10GB HD fürs OS und zusätzlich eine 1,9TB HD für Daten. Du kannst auch kleiner anfangen und später noch HDs hinzufügen. Theoretisch könnte man auch "eine Art Raid" machen, indem man eine vHD auf einer Platte und eine andere vHD auf einer anderen physischen Platte verwendet und diese beiden vHDs dann im OS als Raid1 konfiguriert. SAUBER ist das aber nicht!! Ein HW Raid5 ist immer noch DEUTLICH besser.

Ich nehme an, man muss im Vorfeld beim Definieren der VM sagen, wie groß die Festplatte sein soll. Dann werden alle Files innerhalb der VM gespeichert, richtig? Oder gibt es auch eine Möglichkeit, das OS von den Files zu splitten? Wie würdet ihr hier diese Aufteilung machen?

Wie gesagt, kleine OS vHD, große Daten vHD. Splitting done.
 
[*] Flaschenhals, da virtualisiert
Kommt auf einen Versuch an und hängt von der Netzwerkanbindung ab.
[*] Ich muss die 4 Kerne in jeweils 2 splitten
Mann kann in VMWare mehr Kerne vergeben als physisch vorhanden sind, insofern muss also nicht unbedingt gesplittet werden. Aber mal abgesehen: ein Fileserver braucht nicht wirklich viel CPU! Da reicht m.E. eine vCPU dafür.
[*] Ich muss den Speicher splitten
Yepp, aber auch hier: ein Fileserver braucht vielleicht max 1GB. Dafür hast Du aber halt auch völlig unabhängigen Betrieb. Außerdem habe ich Dir gesagt, dass RAM in adäquater Menge vorgehalten werden muss.

[*] Backup-Routinen

Als Backuproutine kannst Du nun auch Snapshots verwenden.

Bin mir nicht sicher, ob die Virtualisierung nicht einen gewissen Overhead für unsere Zwecke darstellt und evtl. sogar Gefahren darstellt.

Ein wenig Overhead ist da, ja. Dafür ist aber eine VM hardwareunabhängig, kann leicht auf einen anderen Rechner transferiert werden, ermöglicht Snapshots und ist prinzipiell auf (dann aber kostenpflichtig) High Availability vorbereitet.

Wie seht ihr das mit der Virtualisierung des Fileservers als FreeNAS? Kann man bereits im Vorfeld sagen, dass ein reines, nicht virtualisiertes Debian mit LAMP-Umgebung und Netatalk (+Samba) mehr Performance und Sicherheit bringt?

Man opfert bei Virtualisierung immer etwas Performance für die Vorteile, die selbige mit sich bringt. Wenn Euch plötzlich einfällt, dass Ihr doch noch einen Windows Server oder einen getrennten Linux Server benötigt, dann ist das mit dem ESXi im Handumdrehen erledigt.
 
Kein Raid :-)

Nach langem hin und her überlegen dagegen entschieden. Auch wenn die Ausfallsicherung eine feine Sache ist, nehmen wir den Worst Case in Kauf. Die Platten werden immer besser. Außerdem schützt uns ein Raid nur vor Ausfall, nicht vor einem nicht vorhandenen Backup. Deswegen wird alles automatisiert und versioniert gesichert...

Ich habe das entschieden, weil:

  • Kostenfaktor: Lieber kein Raid als ein schlechter Raid-Controller
  • Performance
 
Kostenfaktor von RAID: Ein guter RAID-Controller ist schon für wenige hundert Euro zu haben. Ohne RAID sorgt eine defekte Platte u.U. dafür, daß der komplette Server nicht mehr ansprechbar ist, bis die Platte getauscht und das Backup zurückgespielt ist - da kommen schnell mal ein paar Stunden zusammen, in denen dann kein Geld verdient werden kann, weil man u.U. an wichtige Daten nicht dran kommt. Außerdem sind die Daten seit der letzten Sicherung ohnehin weg.
Ein Server im Business-Umfeld ohne RAID ist IMHO bis auf ganz wenige Ausnahmen ein absolutes NoGo.
Bezüglich Performance von RAID: In der Regel wird deutlich mehr von den Platten gelesen als geschrieben. Bei einem RAID 1 und einen guten RAID-Controller gewinnt man sogar an Performance, denn der RAID-Controller kann zeitgleich unterschiedliche Daten von beiden Platten lesen. Wenn man dann noch bedenkt, daß viele RAID-Controller auch noch Cache-Speicher haben...
 
Kein Raid :-)
Kostenfaktor: Lieber kein Raid als ein schlechter Raid-Controller

Lieber ein guter Raid Controller als kein Raid. Das ist die korrekte Formulierung. Der Raid Controller, nicht die CPU ist das "Herz" eines Fileservers. Der Rest um ihn rum ist eigentlich nur dafür da, dass er seine Arbeit verrichten kann. :D

Du musst die Rechnung so auf machen: wie viel kostet es (an nutzlosen Personalarbeitsstunden, stillstehenden Produktionsmitteln, Miete, etc.) pro Stunde / pro Tag wenn der Betrieb wegen Plattenausfall steht? Wie viel kostet ein vernünftiger Raid Controller? Bei wem da nicht Ausfall in € >> Raid Controller rauskommt, der sollte schleunigst mit dem Business aufhören.

Performance

Quatsch. Ein guter (im Gegensatz zu einem schlechten) Raid Controller zeichnet sich ja gerade dadurch aus, dass er die Berechnung von Raid Quersummen übernimmt. Raid1 ist sowieso vergleichsweise easy, und Raid5 (vom Platzverlust für Redundanz das günstigste) stemmen solche Controller meist auch easy.
 
Ein Server im Business-Umfeld ohne RAID ist IMHO bis auf ganz wenige Ausnahmen ein absolutes NoGo.

Es sei denn, man nutzt FreeBSD und ZFS. ;)

Wenn du aus Kostengründen auf einen RAID-Controller verzichten willst, dann spricht noch mehr für die FreeNAS-Lösung. Mit drei Platten als RAID-Z1 unter ZFS bekommst du ein vollwertiges RAID-5. Eine der drei Platten kann also ausfallen, ohne dass die Verfügbarkeit beeinträchtigt wird oder Daten verloren gehen. Dabei kommt ein weiterer Vorteil von ZFS zum tragen. Bei ZFS gibt es kein "write hole", d.h. die Daten und das Parity-Bit werden synchron geschrieben, was die BBU eines RAID-Controllers überflüssig macht. Bei einem Stromausfall bleibt die Konsistenz des Filesystems also erhalten. Das Thema SSD als Caching-Device habe ich ja auch bereits angesprochen.

Wie bereits angemerkt, könntest du dir für die Entwicklungsumgebung ein Debian-Jail einrichten, was vergleichbar mit einer VM ist. Unter FreeBSD läuft das wie gesagt halt etwas anders (Jails statt VMs). Die Performanceeinbußen eines virtualisierten Fileservers wurde ich pauschal mit 20-30% beziffern. Je mehr parallele Zugriffe es gibt, desto höher.
 
Last edited by a moderator:
Derzeit installiert gerade wieder ein Debian :-)

Was hat es mit FreeBSD auf sich? Ich nehme an, dass unter FreeBSD alles über die Konsole verwaltet wird, richtig? Unter Debian habe ich damit kein Problem. Mit einem komplett neuen OS sehe ich hier allerdings eine enorme Einarbeitungszeit, bis das mit der Jail so hinhaut wie es soll...

Eine Alternative schwebt mir noch im Kopf: Der alte Proliant steht ja noch mit 2x2 TB hier rum. Ich werde ihn einfach mal mißbrauchen. Vielleicht gibt es sogar eine physikalische Trennung der Systeme...
 
Große Unterschiede die mir aus dem Stegreif einfallen:

-zwischen *BSD und Linux bestehen beispielsweise große Unterschied im Kernel: *BSD nutzt einen Mikrokernel wohingegen Linux einen monolithischen Kernel nutzt.
-*BSD setzt in aller Regel auf die BSD-Lizenz, wohingegen Linux selbst unter der GPL steht, was aber nur für Entwickler und Unternehmen wirklich relevant ist. Für dich als Anwender ist das eher peripher von Interesse.
- Bis auf Gentoo nutzen alle Linuxdistributionen eine Paketverwaltung mit Binaries, wohingegen FreeBSD auf Ports setzt (Gentoo lehnt sich an diesen Stil an), allerdings gibt es auch dort fertige Pakete.

Ansonsten gibt es sehr viele Gemeinsamkeiten bei den Paketen (auch den Desktops), der Userverwaltung und den verfügbaren Shells.

Auch wenn ich jetzt Schläge aus irgend einer der Fraktionen beziehen werde: probier's aus und nutze was Dir besser gefällt. Der heftigste Unterschied (Kernelarchitektur) ist bei typischen Einsatzszenarien als gewöhnlicher Server absolut irrelevant.
Zeloten gibt es übrigens auf beiden Seiten (und nicht nur bei diesen Betriebssystemen) - leider - mehr als genug.
 
Last edited by a moderator:
Was hat es mit FreeBSD auf sich?

FreeBSD ist einfach toll. :)

Wenn du Debian (bzw. Linux) kennst, dann kennst du bereits 70% von FreeBSD. Die restlichen 30% sind halt neu, darunter fällt z.B. das Device-Handling. FreeBSD wird nachgesagt, den robustesten und performantesten TCP/IP-Stack zu haben. Yahoo setzte jahrelang auf FreeBSD, mittlerweile nutzt man aber auch Redhat. Netflix setzt beim Storage komplett auf FreeBSD. Auch Cisco und Juniper setzten in einigen ihrer Netzwerkprodukte FreeBSD(-Derivate) ein.
 
Guten Tag zusammen,

so, ich habe das ganze nun etwas erweitert und als Grundlage für die virtualisierten Betriebssysteme eine Flash-Platte eingebaut. Zusätzlich sind mehrere Festplatten als Datenspeicherung im Einsatz.

Allerdings fällt auf:
Wenn ich per SCP Daten übertrage, dann wird die Verbindung immer langsamer. Startet bei ca. 60MB/s. und geht dann runter auf ca. 20MB/s.
Derzeit ist der Arbeitsspeicher noch nicht eingebaut. Kann dies daran liegen? Bei der Übertragung auf das kleine NAS (ebenfalls unter Debian) bleibt es konstant bei 70MB/s.

Oder kann dies andere Ursachen in der Virtualisierung haben?
 
OK, die Lizenz ist eingebunden. Danke für den Hinweis. Allerdings hatte die gedrosselte Geschwindigkeit nur bedingt damit zu tun.

Die Anzahl der virtuellen Sockets und Kerne pro Socket waren falsch eingestellt. Wahrscheinlich hatte ich hier zu viel zugewiesen. Wenn ich nur 1 Socket und diesem 1 Kern zuweise, dann liegt die Geschwindigkeit bei 70MB/s. Zwar nicht ganz konstant, aber geht nicht unter 50MB/s. Damit können wir erst einmal arbeiten.

Sicher optimierungsbedürftig, aber ich werde die richtige Einstellung sicher noch finden und muss ohnehin mal warten, bis der neue RAM da ist und eingebaut werden kann.
 

Back
Top