juan_
Well-Known Member
Hallo,
vllt hilft dir das weiter : http://www.apcc.com/tools/ups_selector/index.cfm? .
(ich meine sowohl den Rechner, als auch die Firma!)
ciao
xy BSD als Storageserver (ZFS)
- Ersteller Skaarj
- Erstellt am
Hallo,
vllt hilft dir das weiter : http://www.apcc.com/tools/ups_selector/index.cfm? .
(ich meine sowohl den Rechner, als auch die Firma!)
ciao
FFS/UFS: Das was uns als UFS2 verkauft wird, ist nicht anderes als FFS2. Die Gründe liegen in der Trennung in Layer, darauf werde ich hier jetzt nicht nicht näher eingehen. Wie der Name "Fast File System" schon sagt, ist dies Dateisystem vor allem schnell. Wenn man an den richtigen Knöpfen dreht, brauch es sich trotz seines hohen Alters nicht vor anderen, moderneren Dateisystemen wie XFS verstecken. Die großen Vorteile von FFS sind, dass es aufgrund seines Alters sehr ausgereift ist. Es ist sehr unwahrscheinlich, dass nach über 25 Jahren seit der ersten Version noch gröbere Fehler vorhanden sind. Außerdem kommt es mit wenig Ressourcen aus, meiner Erfahrung nach können auch stark belastete Dateiserver mit FFS kaum noch von mehr als einem Gigabyte RAM profitieren. Die CPU-Last kaum messbar. Auch gilt es als sehr robust, mir ist in inzwischen 11 Jahren FreeBSD nicht einmal eine Datei verloren gegangen. Auch nicht nach Teils heftigen Crashs. Das fsck mit Softupdates ist realtiv zu sehen. Softupdates halten das Dateisystem IMMER konsistent. Sie können lediglich nicht garantieren, dass freier Speicher auch als solcher markiert ist. Hierfür brauch man das fsck. Da wir hier meist von wenigen Megabytes Verlust reden, spricht absolut nichts dagegen das fsck auch noch Stunden nach dem Absturz in der tiefen Nacht durchzuführen. Da es im Hintergrund läuft, hätte man nicht mal einen Ausfall. FFS kann man mit growfs wachsen lassen.
GJournal: GJournal ist recht neu, es wird das erste mal in 7.0 auftauchen. So weit ich weiß hat Ivan allerdings auch Patches für 6.2 und 6.3 zur Verfügung gestellt. Meiner eigenen, allerdings nicht wirklich großen Erfahrung nach, läuft es stabil und zuverlässig. Die geringe Anzahl an Beschwerden auf den einschlägigen Mailinglists spricht dafür. Gjournal brauch kaum mehr Ressourcen als ein reines FFS, außer natürlich ein paar Gigabytes für das Journal selbst. Außerdem ist es leicht schneller. Ich persönlich würde es allerdings nicht einsetzen, dies liegt aber an meinen durchgehend ziemlich schlechten Erfahrungen mit Journals und nicht an GJournal. GJournal kann man meines Wissens nicht wachsen lassen, aber vielleicht irre ich mich.
ZFS: ZFS ist neu in 7.0 und explizit als "Experimental" gekennzeichnet. Pawell hat für die Zeit nach dem Release von 7.0 ein großes Update angekündigt, welches das Dateisystem auf Version 8 heben wird, hunderte Bugs beheben und vielleicht sogar Bootsupport bringen wird. Meinen Erfahrungen nach lief ZFS bis BETA2 fast unnutzbar instabil, seit BETA3 kann ich selbst keine Abstürze mehr feststellen, auch wenn ich es sehr foltere. So z.b. 5x rsync und 5x Bonnie++ parallel. Dies führte vorher ziemlich sicher zum Absturz. Allerdings sind auch so noch Probleme vorhanden, so mag ZFS es nicht besonders, wenn sich die Namen von Festplatten ändern.
ZFS hat vor allem zwei Vorteile. Einmal den eingebauten Volumenmanager, welcher durchaus in der Lage ist, einen teuren RAID-Controller zu ersetzen. Dann die Tatsache, dass ZFS als einziges Dateisystem von sich selbst aus die Konsistent halten kann. Auch bei Abstürzen und über den berüchtigten Writecache hinweg. Es brauch dazu keine "Hacks" wie Softupdates und Journaling, welche beide ein Restrisiko lassen.
Nachteilig ist der große Ressourcenhunger, ZFS füllt jeden RAM und bekommt jede CPU tot. Außerdem ist es im Schnitt langsamer als die meisten anderen Dateisysteme, dank Copy on Write kann es allerdings unter speziellen Belastungen auch deutlich schneller sein.
Alles in allem ist ZFS sehr interessant, allerdings würde ich mir aufgrund des Ressourcenhungers Gedanken machen, ob für mich der Einsatz Sinn hat. Wenn es bei den System um Leben und Tot geht, würde ich zudem bis mindestens 7.1 warten. Auf Standardserver, die auch mal 10 Minuten ausfallen dürfen, würde ich es derzeit für den produktiven Einsatz für reif genug halten. Im letzten Fall muss man allerdings auf jeden Fall an den entsprechenden Sysctl drehen und solange balancieren, bis das System stabil läuft. Und dies natürlich vor Beginn des produktiven Einsatzes.
BLUFFS: BLUFFS ist noch Zukunftsmusik, es gibt noch nicht einmal einen Prototypen. Dies echte Journal-Dateisystem auf FFS-basis wird frühestens das erste Mal in 8.0 auftauchen.
GJournal: GJournal ist recht neu, es wird das erste mal in 7.0 auftauchen. So weit ich weiß hat Ivan allerdings auch Patches für 6.2 und 6.3 zur Verfügung gestellt. Meiner eigenen, allerdings nicht wirklich großen Erfahrung nach, läuft es stabil und zuverlässig. Die geringe Anzahl an Beschwerden auf den einschlägigen Mailinglists spricht dafür. Gjournal brauch kaum mehr Ressourcen als ein reines FFS, außer natürlich ein paar Gigabytes für das Journal selbst. Außerdem ist es leicht schneller. Ich persönlich würde es allerdings nicht einsetzen, dies liegt aber an meinen durchgehend ziemlich schlechten Erfahrungen mit Journals und nicht an GJournal. GJournal kann man meines Wissens nicht wachsen lassen, aber vielleicht irre ich mich.
ZFS: ZFS ist neu in 7.0 und explizit als "Experimental" gekennzeichnet. Pawell hat für die Zeit nach dem Release von 7.0 ein großes Update angekündigt, welches das Dateisystem auf Version 8 heben wird, hunderte Bugs beheben und vielleicht sogar Bootsupport bringen wird. Meinen Erfahrungen nach lief ZFS bis BETA2 fast unnutzbar instabil, seit BETA3 kann ich selbst keine Abstürze mehr feststellen, auch wenn ich es sehr foltere. So z.b. 5x rsync und 5x Bonnie++ parallel. Dies führte vorher ziemlich sicher zum Absturz. Allerdings sind auch so noch Probleme vorhanden, so mag ZFS es nicht besonders, wenn sich die Namen von Festplatten ändern.
ZFS hat vor allem zwei Vorteile. Einmal den eingebauten Volumenmanager, welcher durchaus in der Lage ist, einen teuren RAID-Controller zu ersetzen. Dann die Tatsache, dass ZFS als einziges Dateisystem von sich selbst aus die Konsistent halten kann. Auch bei Abstürzen und über den berüchtigten Writecache hinweg. Es brauch dazu keine "Hacks" wie Softupdates und Journaling, welche beide ein Restrisiko lassen.
Nachteilig ist der große Ressourcenhunger, ZFS füllt jeden RAM und bekommt jede CPU tot. Außerdem ist es im Schnitt langsamer als die meisten anderen Dateisysteme, dank Copy on Write kann es allerdings unter speziellen Belastungen auch deutlich schneller sein.
Alles in allem ist ZFS sehr interessant, allerdings würde ich mir aufgrund des Ressourcenhungers Gedanken machen, ob für mich der Einsatz Sinn hat. Wenn es bei den System um Leben und Tot geht, würde ich zudem bis mindestens 7.1 warten. Auf Standardserver, die auch mal 10 Minuten ausfallen dürfen, würde ich es derzeit für den produktiven Einsatz für reif genug halten. Im letzten Fall muss man allerdings auf jeden Fall an den entsprechenden Sysctl drehen und solange balancieren, bis das System stabil läuft. Und dies natürlich vor Beginn des produktiven Einsatzes.
BLUFFS: BLUFFS ist noch Zukunftsmusik, es gibt noch nicht einmal einen Prototypen. Dies echte Journal-Dateisystem auf FFS-basis wird frühestens das erste Mal in 8.0 auftauchen.
Zuletzt bearbeitet:
Daemotron
Well-Known Member
Was die RAID-Controller angeht: Schau Dir mal Areca und LSI an. Bei letzteren bin ich mir sicher, dass sie unter BSD laufen, bei ersteren weiß ich nur, dass es Linux-Treiber gibt (aber nicht, ob sie OS sind oder gar Bestandteil des Kernels).
Backup auf Tapelib: Wirf mal einen Blick auf Amanda, vielleicht gefällt's Dir ja. Ist jedenfalls recht ausgereift und stabil...
Linux vs. BSD: aus technischer Sicht eigentlich eine überflüssige Diskussion. Ich sehe zur Zeit leichte Vorteile bei Linux, was Dateisysteme für große Fileserver angeht (XFS ist wirklich sehr gut) - mit der Portierung von XFS nach FreeBSD und der Implementierung von ZFS hat spätestens mit 7.1 FreeBSD wieder die Nase vorn. Beim Scheduling ist Linux seit dem letzten Kernel-Release auch etwas fixer, aber das relativiert sich auch wieder spätestens mit 7.1 (SCHED_ULE) - abgesehen davon, dass SUSE und Co. noch nicht auf dem 2.6.23er Kernel aufbauen.
Der einzige echte Nachteil von FreeBSD (gilt aber z. B. nicht für OpenBSD) für produktive Umgebungen ist, dass Applikationspakete nicht in einer bestimmten Version gepflegt und Fixes auf diese Version zurückportiert werden. Bei fälligen Bugfixes oder Security Patches muss man also die betreffende Applikation upgraden, was bei produktiven Applikationsservern ganz schön heikel werden kann.
In erster Linie hängt's aber nachher doch an den Support-Verträgen. Bei SLES und RHEL garantiert der Hersteller eben für bestimmte Leistungen mit einem bestimmten zeitlichen Horizont und hebt damit teilweise die Haftungsausschlüsse aus der GPL wieder auf (in Dt.Land eh nur bedingt wirksam). Bei BSD bekommst Du "nur" Third-Party-Support, und grade bei FreeBSD wirst Du aufgrund des, öhm, "schwer vorhersagbaren" Release-Fahrplans keine Garantien für Support-Laufzeiten bekommen (wer trotzdem welche gibt ist nicht unbedingt seriös).
Backup auf Tapelib: Wirf mal einen Blick auf Amanda, vielleicht gefällt's Dir ja. Ist jedenfalls recht ausgereift und stabil...
Linux vs. BSD: aus technischer Sicht eigentlich eine überflüssige Diskussion. Ich sehe zur Zeit leichte Vorteile bei Linux, was Dateisysteme für große Fileserver angeht (XFS ist wirklich sehr gut) - mit der Portierung von XFS nach FreeBSD und der Implementierung von ZFS hat spätestens mit 7.1 FreeBSD wieder die Nase vorn. Beim Scheduling ist Linux seit dem letzten Kernel-Release auch etwas fixer, aber das relativiert sich auch wieder spätestens mit 7.1 (SCHED_ULE) - abgesehen davon, dass SUSE und Co. noch nicht auf dem 2.6.23er Kernel aufbauen.
Der einzige echte Nachteil von FreeBSD (gilt aber z. B. nicht für OpenBSD) für produktive Umgebungen ist, dass Applikationspakete nicht in einer bestimmten Version gepflegt und Fixes auf diese Version zurückportiert werden. Bei fälligen Bugfixes oder Security Patches muss man also die betreffende Applikation upgraden, was bei produktiven Applikationsservern ganz schön heikel werden kann.
In erster Linie hängt's aber nachher doch an den Support-Verträgen. Bei SLES und RHEL garantiert der Hersteller eben für bestimmte Leistungen mit einem bestimmten zeitlichen Horizont und hebt damit teilweise die Haftungsausschlüsse aus der GPL wieder auf (in Dt.Land eh nur bedingt wirksam). Bei BSD bekommst Du "nur" Third-Party-Support, und grade bei FreeBSD wirst Du aufgrund des, öhm, "schwer vorhersagbaren" Release-Fahrplans keine Garantien für Support-Laufzeiten bekommen (wer trotzdem welche gibt ist nicht unbedingt seriös).
MrWeedster
Well-Known Member
Hoi.
Zuallererst wegen dem Controller: Wenn du unbedingt BSD verwenden willst, musst du 3ware nehmen. Was anderes wird unter BSD zwar unterstuetzt aber du hast halt keine Verwaltungstools, was ich persoenlich als no-go sehe.
Zum Thema BSD und fileserver: Man mag andere Praeferenzen haben, aber mir ist aufgefallen, dass BSD (FreeBSD Version 6.1, 6.2 oder 7.0 beta) mit Samba grundsaetzlich langsamer ist als ein Linux oder Windows auf der selben Hardware.
Zum Vergleich:
FreeBSD: 28% Netzlast beim ziehen/schieben vom Client auf Server und andersherum (Last bleibt konstant auf 28%, habe schon alles an TCP Optimierungen vorgenommen die ich kenne (TCP-Windowsize, TX und RX Buffers, etc) - IMMER max. 28%.
Auch mit FreeNAS 28% konstant.
Linux: 40% in beide Richtungen (Debian), ziemlich konstant.
Linux: zw. 30% (ziehend) und 37% (schiebend) - Suse Linux Enterprise 10, SP1.
Windows:
2003: zw. 27% (ziehend) und 51% (schiebend)
2008: zw. 38% (ziehend) und 50% (schiebend)
Zusaetzlich dazu hab ich noch Benchmarks mit dd gemacht. Dies lief so ab, dass ich den jeweiligen Samba Server (oder halt Windows) aufgesetzt und ein verzeichnis freigegeben, und dies als Netzlaufwerk verbunden habe.
Dann per cygwin ein dd (if=/dev/zero of=/cygrdrive/netzlaufwerk/bla.test bs=1024k count=1024) auf das Netzlaufwerk.
Da ich dies bisher noch nicht mit BSD getestet habe, hier die Werte von Linux und Windows:
Debian:
Suse:
2003, getunt:
2008, default:
Gut, dies sind theoretische Werte, und diese sind pro Lauf auch ein bisschen geschwankt, aber sie sagen schon etwas ueber die Performance ueber SMB/CIFS aus.
Ein paar Anmerkungen zur Hardware:
Es sind potente Netzwerkkarten verbaut (Intel), es ist immer die exakt selbe Hardware (P4 2,4 / 1GB / 750GB HD auf Server, 2,4 C2D / 4GB / 147GB HD auf Client).
Ich bekomme mit Netio ca. 110 MB/s).
Mir sagen diese Ergebnisse, dass Linux oder Windows die bessere SMB/CIFS Performance bieten. Aus diesem Grund werde ich (leider) Linux auf meinem zukuenftigen Fileserver einsetzen.
Ausser jemand kann mich vom gegenteil ueberzeugen und meinem Server Samba-performancetechnisch ein bisschen auf die Spruenge zu helfen.
Wer jedoch auf Geschwindigkeit keinen Wert legt, oder nur ein 100Mb Netz bedienen muss, ist mit BSD gut beraten.
Evtl. werde ich die noch ausstehenden Performance Messungen von BSD heute oder morgen nachliefern.
greetz
Zuallererst wegen dem Controller: Wenn du unbedingt BSD verwenden willst, musst du 3ware nehmen. Was anderes wird unter BSD zwar unterstuetzt aber du hast halt keine Verwaltungstools, was ich persoenlich als no-go sehe.
Zum Thema BSD und fileserver: Man mag andere Praeferenzen haben, aber mir ist aufgefallen, dass BSD (FreeBSD Version 6.1, 6.2 oder 7.0 beta) mit Samba grundsaetzlich langsamer ist als ein Linux oder Windows auf der selben Hardware.
Zum Vergleich:
FreeBSD: 28% Netzlast beim ziehen/schieben vom Client auf Server und andersherum (Last bleibt konstant auf 28%, habe schon alles an TCP Optimierungen vorgenommen die ich kenne (TCP-Windowsize, TX und RX Buffers, etc) - IMMER max. 28%.
Auch mit FreeNAS 28% konstant.
Linux: 40% in beide Richtungen (Debian), ziemlich konstant.
Linux: zw. 30% (ziehend) und 37% (schiebend) - Suse Linux Enterprise 10, SP1.
Windows:
2003: zw. 27% (ziehend) und 51% (schiebend)
2008: zw. 38% (ziehend) und 50% (schiebend)
Zusaetzlich dazu hab ich noch Benchmarks mit dd gemacht. Dies lief so ab, dass ich den jeweiligen Samba Server (oder halt Windows) aufgesetzt und ein verzeichnis freigegeben, und dies als Netzlaufwerk verbunden habe.
Dann per cygwin ein dd (if=/dev/zero of=/cygrdrive/netzlaufwerk/bla.test bs=1024k count=1024) auf das Netzlaufwerk.
Da ich dies bisher noch nicht mit BSD getestet habe, hier die Werte von Linux und Windows:
Debian:
Code:
$ dd if=/dev/zero bs=1024k count=1024 of=/cygdrive/z/inc/bla.test
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 11.703 s, 91.7 MB/s
$ dd if=/dev/zero bs=1024k count=10240 of=/cygdrive/z/inc/bla.test
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 172.328 s, 62.3 MB/sSuse:
Code:
$ dd if=/dev/zero bs=1024k count=1024 of=/cygdrive/z/bla.test
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 12.625 s, 85.0 MB/s
$ dd if=/dev/zero bs=1024k count=10240 of=/cygdrive/z/bla.test2
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 228.671 s, 47.0 MB/s2003, getunt:
Code:
$ dd if=/dev/zero bs=1024k count=1024 of=/cygdrive/z/bla.test3
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 10.093 s, 106 MB/s
$ dd if=/dev/zero bs=1024k count=10240 of=/cygdrive/z/bla.test2
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 125.171 s, 85.8 MB/s2008, default:
Code:
$ dd if=/dev/zero bs=1024k of=/cygdrive/y/bla.test
107331+0 records in
107331+0 records out
112544710656 bytes (113 GB) copied, 1519.44 s, 74.1 MB/s
$ dd if=/dev/zero bs=1024k count=1024 of=/cygdrive/y/bla.test
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 12.14 s, 88.4 MB/sGut, dies sind theoretische Werte, und diese sind pro Lauf auch ein bisschen geschwankt, aber sie sagen schon etwas ueber die Performance ueber SMB/CIFS aus.
Ein paar Anmerkungen zur Hardware:
Es sind potente Netzwerkkarten verbaut (Intel), es ist immer die exakt selbe Hardware (P4 2,4 / 1GB / 750GB HD auf Server, 2,4 C2D / 4GB / 147GB HD auf Client).
Ich bekomme mit Netio ca. 110 MB/s).
Mir sagen diese Ergebnisse, dass Linux oder Windows die bessere SMB/CIFS Performance bieten. Aus diesem Grund werde ich (leider) Linux auf meinem zukuenftigen Fileserver einsetzen.
Ausser jemand kann mich vom gegenteil ueberzeugen und meinem Server Samba-performancetechnisch ein bisschen auf die Spruenge zu helfen.
Wer jedoch auf Geschwindigkeit keinen Wert legt, oder nur ein 100Mb Netz bedienen muss, ist mit BSD gut beraten.
Evtl. werde ich die noch ausstehenden Performance Messungen von BSD heute oder morgen nachliefern.
greetz
ChaosKind
BSD Fan & FreeBSD Nutzer
Danke für den Link, der hilft mir die Werte gut zu ermitteln .. denk ich mal *grad da rumklick*
an APC USVs hatte ich eh schon gedacht, da ich bei meinem Ausbildungsbetrieb (DLR) nur mit APCs gute Erfahrung sammeln konnte.. die andere Marke, die wir da verwendeten (weiss leider nicht mal mehr welche*g*) hatte häufiger mal den Geist aufgegeben (Blei Akku tot) da unser Stromnetz starke Stromschwankungen ausgesetzt war, wenn im Keller mal wieder an einer Riesen Anlage Versuche gefahren wurden (da starb sogar ein Monstrum von USV bei, welches ca. 1,50m hoch war ca. 50x50cm breit und tief)
Zurzeit muss ich mir sowieso einige Gedanken machen wie ich das alles lösen will.. weil wie es aussieht habe ich nur begrenzt Mittel für das ganze Jahr 2008 zur Verfügung, und davon müssen garantiert auch noch 5-10 normale PCs beschaft werden und noch ein oder zwei neue Webserver (klingt nach braucht nicht viel.. aber da wäre der jetzige Fileserver vielleicht sogar unterdimensioniert.. )
Zurzeit rennt ein P4 3,4GHz mit 4Gig speicher bei nahezu Volllast als Webserver durch, wird demnächst in ein LoadBalancing gesetzt um den eigentlich schon vorhandenen "neuen" Webserver wieder mit zu nutzen.. und die Last zu Verteilen. Bei diesem liegt aber zurzeit ein Komisches Problem vor.. der Rechner ist sporadisch aufeinmal nciht mehr erreichbar - bis zum Neustart (leider taucht nix im Log auf, und wenn das Passierte war schon mein Cheffe am Resetknopf weil ich da meist in unserem Aussenposten grad Zugange war.. daher weiss ich auch nicht ob nur die Netzwerkkarte nich mehr ging oder ob die komplette Möhre abschmierte) ist aber leider auch kein Echter Server, sondern Plain Clienthardware (Core2Duo 1,86GHz mit 4GB die nur als 3,2 erkannt werden)
@Yamagi .. für mich klingt das so als ob FFS bzw. halt UFS2 mit Softupdate doch eigentlich sehr gut wäre... im gegensatz zum jetzigen Ext3 auf alle Fälle, und .
Mal nebenbei gibt es eine "Einfache" Möglichkeit das Filesystem vom Ext3 auf XFS unter SuSE zu wechseln ? Also ohne Datenverlust und co.. das Problem ist da.. ich kriege die Zurzeit schon belegten 1,5TB nirgendwo anders Unter...
Aber wo wir grad dabei sind das Linux so toll ist (;, heute durft ich das mal wieder beobachten.. es waren nurnoch 4 Leute da (ich, Büromitbewohner und die zwei Damen die für meine Büromitbewohner das Aktuelle Release testen müssen) keiner hat auf dem FS gearbeitet.. mit ausnahme von mir..., ich habe ein 6GB Große Datei mit Tar in 4x1,5GB gepackt ... die LoadAvg war bei >5.50 und das bei 2Prozessoren mit je 2 Kernen.. und ne 2. Shell auf dem Server öffnen (ssh) hatte auch schlappe 30 Sekunden ungefähr gebraucht. Das teil war irgendwie sehr träge.. und das passiert häufig wenn viel Last erzeugt wird.. meine ersten Schlüsse woran das liegt, zeigen immer richtung hohe Speicherbelastung bzw. hoher IO Last auf den Festplatten .. und seltsamerweise dadurch noch zusätzliche CPU Last, also ob ein Software Raid laufen würde, und mit BSD habe ich persönlich sowas noch nie erlebt.. generell ist BSD sehr begnügsam was Resourcen angeht, nach meiner persönlichen erfahrung. Daher auch meine Gedanken den neuen FS gleich als BSD System aufzusetzen.
Und da es keine Speziellen Applikationen gibt, die auf dem System laufen, ist mehr oder weniger alles Recht.. mit Ausnahme von Windows... bzw. Microsoft Produkten oder halt keine Kostenpflichte Produkte.. (wobei wir ja Campuslizenz für Windows haben)
nebenbei.. der Flyer wirkt Interessant ala Pro/Contra FreeBSD (:
@MrWeedster danke für deine Performance vergleiche - das BSD langsamer als Linux mit Samba ist, verwundert mich aber grad (ohne das ich je solche Vergleiche gemacht habe)
Hast du parallel mal ne CPU Last mit Protokolliert auf den Systemen, wo du deine Tests gemacht hast ? würd mich mal interessieren. Was ich an deinem Ergebnis interessant finde, Linux ist teilweise ja sogar Flotter als Windows. Interessant wäre es aber wie sich die Performance bei den Systemen verhält wenn 2 oder 3 Clients zugleich mit DD was draufballern ?
@Ogion Thema Supportverträge ... die einzige SLES die wir haben, läuft auf unserem Cluster.. der FS hat ne Stino openSuse 10.2 - da gehts auch mehr um den Hardwaresupport .. sprich ne Platte fällt aus.. wir hätten gern spätestens am nächsten Morgen ne neue da.
Amanda hab ich irgendwo gelesen soll "schlechter" als Bacula sein - kann das nich beurteilen, habe aber daher Bacula gewählt gehabt wobei mir grad nebenbei einfällt .. beherrscht Bacula Kompression ? (allein schon in dem Hinblick das ich zurzeit auf nur eine 750GB Platte Backup mache und diese auf kurz oder Lang voll werden wird und der neue Server und vorallem die Tapelib dazu wird sicher erst Anfang März oder so da sein.. da bei so hohen Beträgen, bei meinem Glück, warscheinlich sogar eine Ausschreibung erfolgen muss.) Beherrscht Amanda Kompression ? und gibts eigentlich auch ne Grafische Oberfläche zur "einfachen" Administration .. sprich Check ob Backup durchlief.. Restore falls mal nötig, von paar Dateien, Tapes formatieren, labeln etc?
Das Ergebnis von euren Tipps und Anmerkungen zeigt zurzeit irgendwie folgendes Ergebnis (korrigiert mich falls ich da Falsch liege):
FreeBSD: Dateisystem (UFS) sau stabil, komplett ausgereift, mit kaum CPU overhead (UFS).
XFS kommt erst
ZFS noch zu instabil (und CPU/RAM Verheizer)
Geschwindigkeit bei Samba mittelmässig.
SMP = gut - Sehr Gut (Sched_ULE)
Linux:
Dateisystem XFS wohl stabil, relativ flott, ausgereift wohl noch lange nicht (logisch)
Samba Speed: gut bis sehr gut
SMP = gut - Sehr Gut
Ergebnis des ganzen: Performancemässig ist Linux etwas flotter aber FreeBSD dafür solider/stabiler?
wenns nach diesem Ergebnis gehen würde, wäre der FS wieder n SuSE (vorallem wenigstens n Debian hätten se vorher nehm können, aber nööö n SuSE musste drauf, sogar mit Grafischer Oberfläche... weil se kein plan hatten und diese brauchten)
So aber aufjedenfall mal fettes Danke für eure Anmerkungen, vorallem das mit dem Configurator von APC, der Aufklärung von Yamagi über FFS/UFS und an MrWeedster für seine Performance Ergebnisse
Das wag ich zu bezweifeln, dass BSDler zu Solaris überlaufen würden, ohne Sparc macht das Zeug immer noch keinen Spass und die AMD und Intel Sun's fühlt sich irgend wie bääh an und ich darf mich damit rumquälen. Allerdings kann man das Attribut Slowlaris auch nicht mehr gelten lassen, die Zeiten sind für AMD/Intel vorbei.
Außerdem ist BSD doch wesentlich benutzbarer, meine persönliche Meinung.
Man kann es schon für lau bekommen.. aber es gibt eben einen ganzen Haufen
ABERS:
Solaris hustet unter 1 GB Ram nicht mal richtig, dass will niemand.
Solaris legt für Newbies eine relativ steile Lernkurve vor, vieles verhält sich anders als in Linux (das ist auch gut so)
Patches, Firmware Updates und Co, ohne Supportvertrag nur gegen Time and Delivery.
Sunsolve an sich eine super Sache um sich selbst zu helfen, aber auch nur eingeschränkt nutzbar ohne Supportvertrag kann man die lustigen Sachen nicht anschauen.
ZFS vermutlich das FS der Zukunft hat aber noch ein paar Macken.
Was die Wahl des FS angeht würde ich momentan entweder UFS mit logging benutzen, oder bei "plattformübergreifender" Umgebung Veritas FS... die Veritas Storage Foundation Basic für Linux u. Solaris kann man sich für umme runter laden und installieren. Mit Supportvertrag nehmen Sie dich allerdings aus wie eine Weihnachtsgans.
Mal ganz dumm gefragt..
wie groß ist den das Budget?
Weil wenn da schon ein Haufen Kohle investiert wird, wieso in diesem Fall nicht gleich zwei Sun's (z.B: T 2000 oder wenn es Intel/Amd basiert sein soll ne X4500 da ist die Storedge gleich mit drin) das zusammenbasteln mit Sun Cluster und hinten dran evtl.
zwei dicke Storedge Units.
Damit überstehst Du jede Rush Hour, jedenfalls zur Zeit.
Mit der T 2000 würdet Ihr jedenfalls ne Menge Strom sparen.
Sata Platten würde ich persönlich nicht einsetzen, ich seh täglich bei meinen Kunden wie Scsi Sata immer noch nass macht, was den I/O und vor allem die Konstanz dessen betrifft.
Ok der Preis pro Gigabyte ist natürlich ein Faktor bei dem Sata vorteilhaft ist, aber
in punkto Zuverlässigkeit liegt Scsi immer noch vorne und RAID6 halte ich nicht für verkehrt. Du solltest versuchen deinen Chef zu überzeugen.
Backup hin Backup her.Bezüglich Ubuntu vs SuSE .... ich würde den SLES Ubuntu immer noch vorziehen auch wenn er Geld kostet und schlechter zu administrieren oder unzuverlässiger ist er nicht, persönliche Meinung.
Allerdings sind die Folgekosten einer solchen Lösung natürlich nicht schlampig, Serviceverträge kosten Geld und sich ohne minimalen Service Vertrag Sun ins Haus holen, dass wird teuer wenn wirklich mal was den Löffel abgibt.
ChaosKind
BSD Fan & FreeBSD Nutzer
Nenn mal eine Hausnummer für dein Gebilde aus X4500 + Storedge, garantiert allein dafür irgendwas im Bereich 10k+
Das Budget für das Teil (Typisch öffentlicher Dienst) so billig wie möglich.. auf gut Deutsch mein Chef würd das ding sogar Geschenkt nehmen, und noch ein Supportvertrag mit drauf haben wollen.. allerdings fällt das doch wieder Flach, weil für Solaris bzw. Sun kann ich Cheffe noch schlechter überreden mangels Fachkenntnis
das Budget für den Server liegt bei 4-5k + ca. 5k Tapelib + unbekannte Summe für den Vorrat an Bändern für die Archivierung der Kompletten Kapazität.. wobei am Anfang wohl eher ne Begrenzte Anzahl Bänder beschaft werden würd (so was um die 20 Bänder oder so) und dann Aufgestockt wenn die nicht mehr Ausreichen
da der Plan bei den Bändern wie folgt aussieht, und Zurzeit wohl auch noch Locker Realisierbar ist (denk ich):
Täglich ein Band für Diff/Inkrement (Am Anfang wohl noch Diff.. wenns zuviel wird wohl eher Inkrement) (insg. 5 Bänder dann)
fürs Weekly Full Rechne ich mit zurzeit mit 3 Bändern
fürs Monthly Full auch 3 Bänder
und ein Satz fürs Daily im Notfall, wären dann insg. 16 Bänder
(800GB LTO4 Bänder)
Leider kostet (mein Letzter Stand von vor 2 Monaten) ein 800GB LTO4 Band grob 100 Eur, wären auch schon 2k Eur
und da das Gesamtbudget fürs Jahr nicht allein für den Server mit Backup aufgebraucht werden darf/soll, und weil davon garantiert noch 1-2 Webserver für unser Aushängeschild kommen müssen sollen bzw. ich vielleicht diese eher für ein MySQL Cluster abzwacke (aber auch fürs Aushängeschild.. bei ner DBGröße von 25GB aufm FS, dann auf dem Webserver immer was um die 20GB-40GB und auf den Entwicklungsmaschinen teilweise sogar 300GB-500GB und mehr) wird es Eng.. da auch Investitionen in normale ClientPCs auch drin sein müssen .. und die zwischendurch Aufrüstungen (Arbeitsspeicher, HDD Kapazität..->Entwicklungsmaschine)
Und dann muss das Geld auch noch für Laborrechner herhalten (obwohl die im Labor sowieso noch zusätzlcih einen großen Teil des Gesamtetars so kriegen)
Also kann man grob Rechnen das ein Budget von 15k Max für Fileserver + Backup + Bänder + USVs drin ist. Btw. was empfiehlt ihr Eher, mehrere kleine USVs (z.B. 4x 800VA) oder lieber eine Dickere (dann um die 2500VA-3000VA) der Vorteil bei mehreren USVs liegt auf der Hand.. ich kann die Server die im Archiv stehen mit Versorgen und die im Serverraum..
(das alles im Serverraum steht will der Entwickler nicht.. er will die Projektserver zumindest Räumlich getrennt haben)
btw. wo ich grad so am grübeln bin mal wieder..
Gibt es ne möglichkeit Trunking mit mehreren Netzwerkkarten (der FS jetzt hat z.B. 2xGigabit und 1x100Mbit Onboard (Tyan 5000VS Board wenn ich mich richtig erinner) allerdings kann das Trunking nur auf Serverseite erfolgen .. da das RZ mir kein Zugang zu der Switchconfig gewährt (sind Cisco Switche)
Wäre von Vorteil, da der Teil des Netzes bei uns Gigabit to Client ist (einzigst das Gebäude mit den Laboren ist mit 100mbit Ports)
Gedanklich hatte ich auch überlegt einfach einen eigenen Switch zu nehmen für die Server.. allerdings wäre da wieder das Problem das die nur einen Gigabit Uplink haben könnten weil ich auf dem Switch der vom RZ Verwaltet wird, kein Trunking machen kann
Achja SCSI fällt (leider) Flach, da diese Kapazität nur mit viel Kosten aufgebaut werden kann .. bei 3TB Speicher wären das ca. 10-20 SCA Platten (oder SAS?)
Das Budget für das Teil (Typisch öffentlicher Dienst) so billig wie möglich.. auf gut Deutsch mein Chef würd das ding sogar Geschenkt nehmen, und noch ein Supportvertrag mit drauf haben wollen.. allerdings fällt das doch wieder Flach, weil für Solaris bzw. Sun kann ich Cheffe noch schlechter überreden mangels Fachkenntnis
das Budget für den Server liegt bei 4-5k + ca. 5k Tapelib + unbekannte Summe für den Vorrat an Bändern für die Archivierung der Kompletten Kapazität.. wobei am Anfang wohl eher ne Begrenzte Anzahl Bänder beschaft werden würd (so was um die 20 Bänder oder so) und dann Aufgestockt wenn die nicht mehr Ausreichen
da der Plan bei den Bändern wie folgt aussieht, und Zurzeit wohl auch noch Locker Realisierbar ist (denk ich):
Täglich ein Band für Diff/Inkrement (Am Anfang wohl noch Diff.. wenns zuviel wird wohl eher Inkrement) (insg. 5 Bänder dann)
fürs Weekly Full Rechne ich mit zurzeit mit 3 Bändern
fürs Monthly Full auch 3 Bänder
und ein Satz fürs Daily im Notfall, wären dann insg. 16 Bänder
(800GB LTO4 Bänder)
Leider kostet (mein Letzter Stand von vor 2 Monaten) ein 800GB LTO4 Band grob 100 Eur, wären auch schon 2k Eur
und da das Gesamtbudget fürs Jahr nicht allein für den Server mit Backup aufgebraucht werden darf/soll, und weil davon garantiert noch 1-2 Webserver für unser Aushängeschild kommen müssen sollen bzw. ich vielleicht diese eher für ein MySQL Cluster abzwacke (aber auch fürs Aushängeschild.. bei ner DBGröße von 25GB aufm FS, dann auf dem Webserver immer was um die 20GB-40GB und auf den Entwicklungsmaschinen teilweise sogar 300GB-500GB und mehr) wird es Eng.. da auch Investitionen in normale ClientPCs auch drin sein müssen .. und die zwischendurch Aufrüstungen (Arbeitsspeicher, HDD Kapazität..->Entwicklungsmaschine)
Und dann muss das Geld auch noch für Laborrechner herhalten (obwohl die im Labor sowieso noch zusätzlcih einen großen Teil des Gesamtetars so kriegen)
Also kann man grob Rechnen das ein Budget von 15k Max für Fileserver + Backup + Bänder + USVs drin ist. Btw. was empfiehlt ihr Eher, mehrere kleine USVs (z.B. 4x 800VA) oder lieber eine Dickere (dann um die 2500VA-3000VA) der Vorteil bei mehreren USVs liegt auf der Hand.. ich kann die Server die im Archiv stehen mit Versorgen und die im Serverraum..
(das alles im Serverraum steht will der Entwickler nicht.. er will die Projektserver zumindest Räumlich getrennt haben)
btw. wo ich grad so am grübeln bin mal wieder..
Gibt es ne möglichkeit Trunking mit mehreren Netzwerkkarten (der FS jetzt hat z.B. 2xGigabit und 1x100Mbit Onboard (Tyan 5000VS Board wenn ich mich richtig erinner) allerdings kann das Trunking nur auf Serverseite erfolgen .. da das RZ mir kein Zugang zu der Switchconfig gewährt (sind Cisco Switche)
Wäre von Vorteil, da der Teil des Netzes bei uns Gigabit to Client ist (einzigst das Gebäude mit den Laboren ist mit 100mbit Ports)
Gedanklich hatte ich auch überlegt einfach einen eigenen Switch zu nehmen für die Server.. allerdings wäre da wieder das Problem das die nur einen Gigabit Uplink haben könnten weil ich auf dem Switch der vom RZ Verwaltet wird, kein Trunking machen kann
Achja SCSI fällt (leider) Flach, da diese Kapazität nur mit viel Kosten aufgebaut werden kann .. bei 3TB Speicher wären das ca. 10-20 SCA Platten (oder SAS?)
Naja bei einer X4500 wärst Du Listenpreis mit 19 Kilo Euro dabei, aber wer zahlt schon Listenpreise.
48x250GB Sataplatten müssten in den Hobel reinpassen, geht aber auch mehr was die Grösse angeht, allerdings wird da unverschämt Geld genommen.
Supportvertrag, ist dann oft Verhandlungssache.
Evtl, wäre es auch nicht verkehrt mal bei Dell, IBM, HP oder ICO nachzufragen was die so verlangen. Dell bietet ja auch Supportverträge an und grundsätzlich verkehrt ist das nicht.
Was das Tape/Backup angeht. Ich würde zu einem Exabyte oder IBM LTO greifen, bzw. mal ein Angebot einholen, was die so verlangen.
Wir "verscherbeln" unserer Kundschaft auch UPSEn allerdings bin ich darin nicht unbedingt der Held, das sind aber meistens Eaton Powerware.
Was Switch wegen dem Trunking angeht, Nortel Switche bieten das von Haus aus.
Hatte vor zwei Jahren einen in meinem ehemaligen Betrieb und der hat seinen Job auch zuverlässig verrichtet.
Was das Trunking über Netzwerkkarte betrifft Solaris bietet die Möglichkeit Trunking zu realisieren, über die NIC Solange der Switch auf der Gegenseite mitmacht und da sieht es bei Cisco ohne Aufpreis schlecht aus.
48x250GB Sataplatten müssten in den Hobel reinpassen, geht aber auch mehr was die Grösse angeht, allerdings wird da unverschämt Geld genommen.
Supportvertrag, ist dann oft Verhandlungssache.
Evtl, wäre es auch nicht verkehrt mal bei Dell, IBM, HP oder ICO nachzufragen was die so verlangen. Dell bietet ja auch Supportverträge an und grundsätzlich verkehrt ist das nicht.
Was das Tape/Backup angeht. Ich würde zu einem Exabyte oder IBM LTO greifen, bzw. mal ein Angebot einholen, was die so verlangen.
Wir "verscherbeln" unserer Kundschaft auch UPSEn allerdings bin ich darin nicht unbedingt der Held, das sind aber meistens Eaton Powerware.
Was Switch wegen dem Trunking angeht, Nortel Switche bieten das von Haus aus.
Hatte vor zwei Jahren einen in meinem ehemaligen Betrieb und der hat seinen Job auch zuverlässig verrichtet.
Was das Trunking über Netzwerkkarte betrifft Solaris bietet die Möglichkeit Trunking zu realisieren, über die NIC Solange der Switch auf der Gegenseite mitmacht und da sieht es bei Cisco ohne Aufpreis schlecht aus.