
UPDATE: Habe dieses Szenario gerade auf einer Platine mit acht zusätzlichen SATA-Ports ausprobiert und es funktioniert. Langsamer als gedacht, aber immer noch akzeptabel. Gemäß der Diskussion mit David Schwartz glaube ich, dass er Recht haben könnte, dass etwas pathologisch nicht stimmt, oder dass Ali Chen Recht haben könnte, dass RHEL einfach nicht damit umgehen kann, dass so viele Host-Controller gleichzeitig ausfallen. Ich werde noch ein bisschen mehr experimentieren, da ich schon so weit gekommen bin und im Grunde dafür bezahlt werde, an diesem Punkt neugierig zu sein. :)
BEGINNEN SIE DEN ORIGINAL-POST
Die Einrichtung ist also etwas langwierig. Wir haben zwei RocketU 1144D 4-Port-USB-3.0-Karten in unserem System, eine davon in einem PCIe-2.0-Sockel und eine in einem PCIe-3.0-Sockel, um Bandbreitenprobleme zu vermeiden. An jede dieser USB-Karten sind vier Crucial MX300 1TB SSD in extern mit Strom versorgten Silver Stone Raven-Gehäusen angeschlossen. Der Kunde möchte denselben Satz von Dateien gleichzeitig auf vier der acht Festplatten schreiben können, während er Dateien von den anderen vier Festplatten liest, um MD5-Prüfsummen zu berechnen. Jede Festplatte wird so nah wie möglich an ihrer Kapazität sein, mit Dateien, die entweder zum Zeitpunkt des Lesens oder nachdem alle Dateien geschrieben wurden, ungefähr 1 GB groß sind.
Wenn wir nun nur auf die Datenträger einer der Karten zugreifen oder Dateien darauf schreiben, sind die Geschwindigkeiten nicht so schlecht. Bei voller TB-Auslastung erreichen wir durchschnittlich zwischen 3 und 4 Sekunden pro Datei (Lesen/Berechnen oder Schreiben). Das Problem ist, dass die Lese- und Schreibgeschwindigkeiten ziemlich schnell nachlassen, wenn wir versuchen, beides gleichzeitig zu tun. Sie sinken von anfänglich etwa 1,5 Sekunden pro Datei auf über 60 Sekunden pro Datei.
Die einzigen anderen Karten im System sind die Grafikkarte im PCIe 3 16x-Steckplatz und ein Intel X540-T2-Adapter (derzeit nicht verwendet) in einem anderen PCIe 3 8x-Steckplatz.
Wir haben ein Dual-CPU-X10DRL-i-Server-MOBO mit zwei 6-Core-Zenon-Prozessoren und 64 GB RAM, auf dem RHEL 7.2 von einem anderen Crucial MX300 läuft, der an einen SATA-Port angeschlossen ist.
Die Frage ist also, ob es möglich ist, das oben Beschriebene in einem angemessenen Zeitrahmen zu erledigen, der wie folgt definiert ist: Eintausend Dateien mit einem Gigabyte pro SSD werden von vier an Karte eins angeschlossenen SSDs gelesen und auf vier an Karte zwei angeschlossene SSDs geschrieben. Die Vorgänge MÜSSEN (aufgrund des Kunden) parallel ausgeführt werden, und zwar alles in weniger als einer Stunde?
Nach dem, was ich gelernt habe, tendiere ich langsam zu Nein, aber ich dachte, ich frage mal nach und schaue, ob jemand mit mehr Wissen als ich etwas Definitiveres hat. Jede Hilfe, jeder Rat und vor allem eine Antwort sind sehr willkommen.
BEARBEITEN gemäß Vorschlag von David Schwartz:
Erforderliche Bandbreite pro Karte 5 Gbit/s pro USB 3.0-Anschluss x 4 Anschlüsse = 20 Gbit/s
Verfügbare Bandbreite PCIe 2.0 x4 bei 500 MBps pro Lane = 16 Gbps
Da eine Karte die PCIe 3-Lanes und die andere die PCIe 2-Lanes verwendet, sollte es meines Wissens nach keinen Konflikt bezüglich dieser Ressourcen geben.
NOTIZ:
Ich weiß, dass die Bandbreite der Karte zu hoch angesetzt war, aber die Lese- und Schreibvorgänge sollten nicht mehrere Minuten pro GB-Datei dauern.
BEARBEITEN 2:
Nach David Schwartz' Vorschlag habe ich die Kernauslastung mithilfe des Systemmonitors und htop überwacht. Das System zeigt 100 % oder nahezu 100 % Auslastung oder vier Kerne für die ersten Dutzend Datei-E/A an. Das System friert dann für einige Sekunden ein und dann kommt es zu einer Verschlechterung der Datei-E/A. Außerdem wird die Kernauslastung danach selten auf 100 % steigen und wenn, dann nur sehr kurz.
BEARBEITEN 3: Höchstwahrscheinlich die letzte Bearbeitung.
Nach ein wenig Recherche und Experimentieren können wir wohl sagen, dass dies mit der vorliegenden Karte nicht funktionieren wird, und ich würde wetten, dass die in den Kommentaren erwähnte StarTech-Karte auch nicht funktionieren wird. Ich glaube, wir können aufgrund mehrerer Dinge zu dieser Schlussfolgerung gelangen. Kurz gesagt, eine SSD funktioniert auf der Karte hervorragend. Zwei funktionieren mit etwas Verlangsamung ok; Overhead, schätze ich. Bei 3 oder mehr jedoch fangen sie an, schlechte Dinge zu tun. Ich stelle mir vor, dass dies daran liegt, dass wir versuchen, 20 Gbps über 16 Gbps PCIe-Lanes zu übertragen, und anstatt das theoretische Maximum von 16 Gbps zu erreichen, stolpern die Controller auf beiden Seiten der Übertragung möglicherweise übereinander und verursachen im Allgemeinen Verzögerungen bis zu dem Punkt, an dem die Datenübertragung auf ein Minimum reduziert wird. Dies ist nur eine Theorie, aber sie war gut genug, um den Kunden dazu zu bringen, die USB-Anforderung fallen zu lassen und uns SATA und andere Methoden ausprobieren zu lassen. SATA funktioniert viel, VIEL besser, also denke ich, dass wir einen Gewinner haben. Danke an David Schwartz und Ali Chen für ihre Hilfe und Vorschläge.
EDIT 4: Die eigentliche Endbearbeitung
Ich bin gestern also zufällig auf die Antwort auf meine Frage gestoßen, die mehrere Teile enthielt, als ich mir SATA-Lösungen ansah. Das eigentliche Problem war zweifacher Natur und wurde erst deutlich, nachdem das erste der Probleme entdeckt wurde.
Das erste Problem war also die Speicherverwaltung. Nachdem ich die Software getestet hatte, die die großen Dateien zum Schreiben liest, sah es so aus, als würden die Dateien einmal gelesen und dann mehrere Male geschrieben. Das war nicht der Fall. Wir hatten also ständig mehrere Leseanfragen für mehrere 1-GB-Dateien. Warum das in Tests funktionierte, in der Praxis aber nicht, weiß ich nicht, aber wir hatten keine Zeit für eine Obduktion, also bleibt das der Vergangenheit überlassen.
Das zweite Problem ist, dass wir keine Hardware-Experten sind und uns daher ein sehr wichtiges Detail bei der Arbeit an einem Linux-System nicht bewusst war. Da NTFS nicht nativ für Linux ist (das wussten wir), läuft es anscheinend um fast eine Größenordnung langsamer (das wussten wir nicht). Wäre dies eine Windows-Box gewesen, hätten wir kein Problem gehabt.
Kombinieren Sie diese beiden Faktoren und Sie erhalten das unberechenbare Verhalten, das wir erlebt haben. Nachdem wir alle Festplatten komplett auf EXT4 neu formatiert hatten, traten keine unvorhersehbaren Lese-/Schreibzeiten mehr auf und alles funktionierte wie erwartet. Wir konnten die gleichzeitigen Schreibvorgänge und Lese-/MD5-Berechnungen innerhalb der zulässigen Parameter durchführen.