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