Datenschaufleritis

Meine Arbeit im Bereich Digital Content Services bringt es mit sich, dass wir immense Datenmengen bewegen muessen. Anlieferung der Rohdaten von den Ton-/Filmstudios, Aufbereitung fuers Mastering, Weiterverarbeitung zum Cutting der Pressvorlagen, Formatkonvertierungen fuer die Internet-Musikshops usw. usf. – derzeit summiert sich unser Datenvorrat auf rund 600TB online in diversen SAN-Schraenken, und rund 4PB standby als Bandkapazitaeten. Diese Daten wollen natuerlich irgendwie von einem Rechner zum anderen kommen – und genau da manifestiert sich das Problem, dessen Beseitigung ich mir heute in die Todo-Liste setzen lassen habe.

Bisher laeuft das meiste davon intern ueber gescriptete FTP-Transfers, mit entsprechendem Verwaltungs-Overhead. Die Konverter-Maschinen holen die Daten per FTP auf ihre lokale Platte, verarbeiten den Kram, und liefern ihn wieder per FTP beim naechsten Server ab. Bei 50 Konvertern muss so ein Server also mindestens 50 gleichzeitige Verbindungen abkoennen, plus die Datenlieferungen die parallel dazu von aussen ankommen. Diese ungewoehnlich hohen Anforderungen sind dementsprechend schwer zu planen. (Fuer alle die jetzt denken „langweilig, mein PC mit $FTPserver-Freeware packt das auch – ich rede hier nicht von DSL-Geschwindigkeiten sondern weit im GBit-Bereich).

Irgendwann damals beim SCNA-Kurs habe ich mal gelernt, dass man pro MBit zu saettigende Netzwerkleistung rund 3 MHz CPU-Geschwindigkeit braucht. Dies wuerde bedeuten, dass ich eine der GBit-Karten mit 3GHz CPU-Power ausgereizt bekomme. Nur: diese Faustregel skaliert leider offenbar nicht unbegrenzt. Zumindest bekomme ich mit vier einigermassen belasteten 1GBit-Leitungen eine voll ausgebaute SunFire V880 (8x 1,25 GHz) leicht zum Schreien.

Momentan sieht’s so aus wie wenn das Problem am Protokoll haengt. Leider scheint nur FTP immer noch das performanteste der bisher getesteten zu sein.. damit bekomme ich durch eine 1GBit-Leitung immerhin rund 45 MB/sek durch. Irgendwie ein bescheidener Wirkungsgrad, und ich kann mir nicht vorstellen dass wirklich 2/3 der Leitung an Overhead verloren gehen. Mit NFS bin ich knapp darunter auf 40 MB/sek gekommen, SMB hat weit unten bei 25MB/sek rumgeduempelt. Bei einem Einzeltransfer auf unbelastetem Rechner, wohlgemerkt. Bei zwei parallelen Transfers hats schon anders ausgesehen.. FTP ist auf 40MB/sek Gesamtdurchsatz runter, NFS auf 50MB/sek rauf, SMB weit abgeschlagen bei nur noch 4MB/sek – jeweils getestet mit 1GB grossen Random-Dateien. Bei dem extremen Leistungseinbruch bei SMB bin ich noch nicht ganz sicher ob das an Samba liegt, oder ob der verwendete Windows-Client so beschissenes Paketscheduling betreibt. Ich wills aber glaubich garnicht wissen. Bei drei parallelen Transfers haben sich NFS und FTP wieder bei 45MB/sek getroffen.. SMB erwaehne ich aus Scham nicht mehr.

Bleibt im Endergebnis die Frage, woran kann ich noch rumtunen um mehr Daten durchzukriegen. Die CPUs langweilen sich, da liegt der Engpass also nicht. Bei 50MB/sek, also 400 MBit, duerfte die Netzwerkkarte auch noch Kapazitaeten frei haben. Beim Switch (Cisco Catalysts) gehe ich mal davon aus, dass er den Durchsatz schafft. Mit Paketgroessen werde ich am Montag mal bissl experimentieren.. im Gigabit-Ethernet sind ja Frames bis 8k moeglich.. mal schaun ob das was bringt. Dann ein bisschen am Kernel rumschrauben, Paket-ACK-Fenster vergroessern etc.. nur darf die Leistung halt nicht auf Kosten der Zuverlaessigkeit gehen. Wie schlimm ist eigentlich der Overhead bei HTTP?
Wenn jemand spontan eine Idee hat, bewerft mich damit😉

Veröffentlicht in Job. 2 Comments »

2 Antworten to “Datenschaufleritis”

  1. Zarquod Says:

    In Bezug auf den Protokolloverhead darf zwischen HTTP und FTP bei solchen Datenmengen eigentlich kein großer Unterschied bestehen. Das ist ja in beiden Fällen einfach nur eine TCP-Strecke, auf die die Daten draufgepumpt werden. Der Application-Level-Overhead wäre da nur interessant, wenn du diese Datenmengen in Form von vielen kleinen Dateien überträgst; das scheint mir hier eher nicht der Fall zu sein.🙂

    Unter Umständen könnte hier tatsächlich etwas UDP-basiertes interessant sein. Im LAN ist ja per se der Paketverlust kein so großes Problem. Den eher pessimistischen TCP-Ansatz braucht man von daher nicht. Aber unter Hochlast könnten ACK-Traffic und andere Features von TCP durchaus auf den Durchsatz drücken. Mir fällt jetzt allerdings spontan kein UDP-basiertes Protokoll ein, dass man da benutzen könnte. Du bräuchtest eine Art modernisiertes TFTP.

  2. Woo Says:

    UDP waere als Option bei NFS machbar.. nur habe ich keine Ahnung, wie gut das den potentiellen Paketverlust wegsteckt. Vollstaendig verlorengehen darf da kein Paket, und wenn im Falle eines erkannten Fehlpakets die ganze Datei neu angefordert wird, habe ich mit meinen 10-20GB Kolossen wieder die A*Karte.
    Ich werds wohl mal testen. Auch auf der Experimentierliste stehen Veraenderungen an der ACK-Fenster-Groesse.. mal schaun wie weit ich das ausreizen kann bevors unzuverlaessig wird.


Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ã„ndern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ã„ndern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ã„ndern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ã„ndern )

Verbinde mit %s

%d Bloggern gefällt das: