Neuer FC3/CentOS4-Server

[Quintus14]

Ja, könnte man testen. Aber auf der alten HW krieg' ich die dicken Ottos (80GB Seagate & 300 GB Maxtor) nicht mehr zum Laufen - daher wollte ich ja auch auf eine neue HW wechseln.

In der Zwischenzeit hab' ich probiert, ob ich Suse 9.2 von der Heft-CD PC-Professionell 2/05 zum Laufen krieg - nach dem Booten bzw. ab dem Umschalten auf Grafik bleibt der BS schwarz - Suse dürfte mit meiner Matrox ein Problem haben.

Ich glaub', es wär' für mich jetzt am sinnnvollsten, ich wart' auf die DVDs/CDs von CentOS - Ende nächster Woche sollte ich dann auch mit dem Film soweit fertig sein, dass ich mehr Zeit zum Testen hab'.

MfG, Quintus

[Philipp]

Original geschrieben von spunz
du könntest auf dem alten server einfach mal wie ich mal ein kernel update probieren. ein update auf 2.6 brachte mir damals einen spürbaren leistungszuwachs.

http://www.backports.org/debian/dist...e-2.4.27-i386/
http://www.backports.org/debian/dist...ge-2.6.7-i386/

Den Backport von Kernel 2.6.7 würde ich bei produktiven servern aber meiden, da ein sehr kritisches Sicherheitloch enthalten ist. Im entsprechenden Incoming Verzeichnis gibt es zwar schon seit Wochen ein 2.6.8 Paket, welches aber bisher noch nicht zu Backports.org hinzugefügt wurde.

[Quintus14]

@ Philipp: nein, vom Produktionsrechner lass' ich eh vorläufig die Finger.

----------

Es ist eigentlich mal die Frage zu klären, ob es überhaupt vernünftig ist, dass jener Rechner, der Firewall spielt, überhaupt Datenserver sein soll.

Wenn nein, wäre es eigentlich wenig Aufwand,

• den Debian-Server "abzuspecken", ihn nur mehr als Firewall, Printerserver & Zeitsynchronisation
• und für die Samba-Dienste (oder ggf. Windows-Netzwerk-Freigaben) einen eigenen Rechner zu nutzen.

Da das System im Debian-Server auf einer SCSI-Ultra-HDD liegt und ich noch einen Adaptec 2940U in der Lade liegen hätte....könnt' ich diese eine HDD (ohne Uminstalliererei ) im Debian-(=Firewall-)Server weiter laufen lassen und die anderen (LVD-)SCSI-HDDs im Fileserver einsetzen - nur unter welchem BS ist halt noch die Frage...

... nur laufen halt dann 2 Rechner 24/365....

Btwy - ich hab' jetzt auf einem 3GHz-Intel-Rechner (aktueller FC3-Kernel) testweise ein smb-upload gemacht - dasselbe in lila (Gott sei Dank - sonst hätt' ich an der A64-HW gezweifelt ).

MfG
Quintus

[Quintus14]

Weil ich jetzt neugierig war: so sieht übrigens ein smb-upload auf den alten Debian-Server aus.

[Quintus14]

Neben der Top-Speed und gutem Ansprechverhalten bei down- & upload wäre die Disziplin "DV Capturn aufs Netzlaufwerk" von Wichtigkeit.

Während WinXP bei up- und download hervorragende Datenraten zustande bringt, "patzt" es beim Capturen aufs Netzlaufwerk: leider kommt hin und wieder der Abbruch:



Anscheinend tut XP hin und wieder irgend etwas zwischendurch, was mal den Datenfluss stoppt . Unter FC3 scheint es diesbezüglich besser zu laufen - aber auch hier hatte ich schon einen Abbruch zu verzeichnen .

Ich fürchte, weder bei WinXP als Fileserver noch mit FC3/smb ist eine derartige Betriebssicherheit zu erreichen, dass übers Netz beispielsweise ein 3-Stunden-Film (ohne Abbruch) gecapturt werden kann.

Ich fürchte, diese Dinge muss ich weiterhin lokal auf einer Workstation machen.

Natürlich teste ich in dieser Richtung weiter - momentan läuft ein Capturn unter FC3 (aktueller Standard-Kernel) bereits 50 Minuten problemlos...

Die sogenannte "Betriebssicherheit" wär' mich noch wichtiger als die Top-Speed - Mängel in der Tops-Speed könnte ich kompensieren, indem ich beispielsweise das Timeline-Abspielen so starte, dass VORHER der Buffer gefüllt wird, bevor die Wiedergabe startet. Gegen Capture-Abbruche gibt's keinen Workaround - abgebrochenes Capturn vom TV = Film ist kaputt.

MfG, Quintus

[Quintus14]

Original geschrieben von Quintus14
...wäre die Disziplin "DV Capturn aufs Netzlaufwerk" von Wichtigkeit.

Ich hab' diesbezüglich weiter getestet:

• der WinXP-Fileservice hat sich da disqualifiziert, weil nach 10-20 Minuten durch irgendwelche Hintergrund-Aktivitäten ein Abbruch kam.
• Dem FC3-/smb-Server kann ich bescheinigen, dass er diese Disziplin anscheinend deutlich besser beherrscht - ich hab' jetzt 4½ Stunden am Stück gecapturt - kein Abbruch!

Es sieht also so aus, als wenn mein nächster Server wieder Linux wird - diese extreme Pulsiererei bei smb muss ich aber noch irgendwie weg kriegen! Ich hoffe, das erledigt sich weitgehend von selbst, wenn ich die für den A64 richtige Version installiere.(?)

Ich bin somit schon neugierig auf die Tests mit CentOS3.3 bzw. 4.0beta.

Die Frage stellt sich noch, ob ich in Zukunft 2 Rechner 7/24 - also Firewall & smb auf verschiedenen Maschinen - laufen lassen soll, oder alles wieder auf einer.

MfG, Quintus

[callas]

Original geschrieben von Quintus14


Die Frage stellt sich noch, ob ich in Zukunft 2 Rechner 7/24 - also Firewall & smb auf verschiedenen Maschinen - laufen lassen soll, oder alles wieder auf einer.

MfG, Quintus

Von der Stromkostenproblematik abgesehen eine sehr gute Idee: Wenn dein Fileserver keinen direkten Zugang ins I-Net hat, ist er wesentlich sicherer.

Auf einem Firewall Rechner sollten möglichst keine (Server-)Dienste rennen.

[Quintus14]

Ich fasse mal meine Tests bis jetzt zusammen:

• unter Linux hab' ich - wie bekannt - z.Z. noch eine langsame bzw. sehr "pulsierende" Netzwerk-Performance (Samba), aber große Stabilität - das Video-Capturn funzt.
• Unter XP hätte ich top Netzwerkperformance, um die 95% - allerdings macht XP alle paar Minuten irgend eine Hintergrundaktivität und daher Pause = Capture-Abbruch!
• W2K bringt eine kontinuierliche Netzwerkverbindung zustande (ich hab's aber nur 15 MInuten getestet) - allerdings liegt die Auslastung nur bei nur 60-70% (bei beiden NICs). Auch mager...

Nachgelesen hab' ich noch wegen dem Abschalten der IDE-HDD(s) - scheint auch nicht so einfach zu sein. Hier steht:

Bei IDE-Platten geht das mit hdparm -S, für SCSI-Platten ist ein Kernelpatch (SCSI-Idle) notwendig. In der Praxis ist ein solcher Spindown aber nur selten sinnvoll. Unter Linux, wie unter jedem Unix, erfolgt normalerweise spätestens alle paar Minuten irgendein Plattenzugriff, es sei denn, es handelt sich z.B. um eine reine Datenplatte, die nicht gemountet ist. Dadurch wird eine Platte, falls der Timeout so kurz ist, dass sie zwischen den Zugriffen den Motor abschalten kann, dauernd herunter- und und wieder heraufgefahren, was die Lebensdauer der Platte rapide verkürzen kann, insbesondere, wenn es sich um eine Desktopplatte handelt, die im Gegensatz zu einer Notebookplatte nicht für solche Stromsparmaßnahmen ausgelegt ist. Abhilfe schaffen kann hier der noflushd/ <http://sourceforge.net/projects/noflushd/>, der die Zugriffe bei Inaktivität unterbindet. Unbedingt die Warnhinweise im README beachten!

In der Readme von Spindown steht:

Be aware that noflushd might have problems with a mixed IDE/SCSI setup
or large numbers of disks. noflushd will inform you of any conflict.

Hat das schon jemand probiert? Hab' ich Chancen, die IDE-HDD still zulegen?

Thx, Quintus

[callas]

da ich nicht den ganzen thread nochmals nachlesen will: za wos soll das gut sein ?

Stromsparmassnahme wäre minimal, maximal bei einem Notebook im Akkubetrieb interessant, und an deinen Performanceproblemem ändert es sowieso nix.

[Quintus14]

IDE soll halt - im Gegensatz zu SCSI - nicht für Dauerbetrieb ausgelegt sein. Und weil ich die dicke Maxtor nur zum Videocapturn einsetzen will und das nur alle paar Tag' mal tu', war die Idee, sie zwischendurch ab zu drehen.

Natürlich könnt' ich sie durchlaufen lassen und wenn sie nach 2 Jahr' hin ist, auf den Müll schmeißen - ist ja ned viel hin. Ich muss mir dann natürlich ein bißchen mehr Gedanken wegen Kühlung derselben machen.

MfG, Quintus