Ausführen eines vollständigen Paritätsknotens mit SSD-Festplatten in einem RAID 10-Setup?

TLDR; Sie möchten wahrscheinlich nur etwas Geld sparen, indem Sie eine einzelne SSD zu Ihrem Array ersetzen/hinzufügen, anstatt sie in RAID 10 auszuführen.

Mit einem ausreichend hohen Spiegelungsgrad und einem ausreichend großen Festplatten-Cache könnten Sie die Ethereum-Blockchain wahrscheinlich auf einer Festplatte synchronisieren, aber eine SSD reicht aufgrund der geringen Latenz bei zufälligen Suchvorgängen aus; Es besteht keine Notwendigkeit, SSDs in RAID zu stecken.

Sie haben nicht erwähnt, ob Sie Software- oder Hardware-RAID verwenden, aber ich vermute auf jeden Fall, dass Ihr System mehr als in der Lage ist, RAID 10 ohne negative Auswirkungen auf die Synchronisierung zu handhaben, wenn es nur auf die Verwendung von RAID hinausläuft selbst.

Wird mehr Verschleiß zu sehen sein? Ja: Sie schreiben aufgrund des gespiegelten Teils Ihres RAID 10 (des RAID 1-Teils) doppelt so viele Daten. Es ist also eine Steigerung um mindestens (und fast) den Faktor zwei. Aber der Verschleiß verteilt sich auf vier Festplatten, sodass Sie meiner Meinung nach eine ungefähr doppelt so hohe Lebenserwartung pro Festplatte wie in einem RAID 1- oder JBOD-Setup sehen würden (dh Sie müssen weniger auswechseln). Scheiben durch Verschleiß); OTOH, bei den derzeitigen Raten wird es wahrscheinlich sehr lange dauern, bis die Festplatten abgenutzt sind (in der Größenordnung von Jahren / Jahrzehnten, wenn nicht mehr, um die Anzahl der Schreibzyklen zu erreichen, für die selbst die niedrigsten SSDs ausgelegt sind).

Daher lautet die Antwort auf die Frage, ob Ihr beschriebenes Setup funktionieren würde, ja. Aber ich habe eine andere Frage: Warum denkst du an RAID10? (Ich gehe von einem 2x2-Array aus.) Liegt es daran, dass Sie RAID 10 für einen anderen Zweck benötigen/wollen? Der einzige Grund, warum ich mir vorstellen kann, RAID 10 zu benötigen, ist, dass Sie vielleicht vorhaben, einen vorhandenen Pool zu resilvern, um ohne Ausfallzeit auf SSDs umzusteigen (wenn Sie ZFS verwenden, gibt es wahrscheinlich bessere Möglichkeiten, dies zu umgehen). Deshalb denke ich, dass RAID 1 für dieses Upgrade besser geeignet ist als RAID 10: Wenn Sie einen RAID-Stripe (RAID 0) haben, dann vermute ich, dass dies Ihren Lesedurchsatz und/oder Ihre Latenz und/oder Ihre Gesamtadressierbarkeit erhöhen soll Kapazität und erfüllt bereits Ihre Anforderungen. Aber eine nicht besonders schnelle SSD kann Ihnen mehr als den doppelten Durchsatz liefernals eine HDD – und bietet daher mindestens so viel Durchsatz wie ein Stripeset-HDD-Volume. Es bietet Ihnen auch weitaus mehr IOPs als ein 2-Festplatten-Striped-HDD-Volume (zwei oder mehr Größenordnungen). Da Ethereum im Wesentlichen eine riesige Datenbank ist, in der es viele Lese-/Schreibvorgänge gibt, bietet die niedrige Festplattenzugriffslatenz von SSDs einen RIESIGEN Vorteil in Bezug auf die Blockchain-Synchronisierungsgeschwindigkeit. Sofern Sie Ihre SSDs nicht RAIDen müssen, um die benötigte Einzelvolume-Kapazität zu erreichen, können Sie Ihr Geld sparen und das Striping Ihrer SSDs überspringen.

Ich denke auch, dass Sie das Spiegeln dieser Festplatte ebenfalls überspringen sollten, es sei denn, Sie planen, andere Dinge als die Blockchain darauf zu behalten, oder Sie möchten aufgrund von Online-Redundanz (z. B. in einer Produktionsserverumgebung) eine höhere Betriebszeit erreichen. Ich würde davon ausgehen, dass Sie sowieso Redundanz auf Knotenebene in einem Hochverfügbarkeits-Setup wünschen, sodass die Festplattenspiegelung die Hochverfügbarkeit sowieso nicht vollständig ansprechen würde. Sie können die Blockchain jederzeit neu synchronisieren, wenn/wenn Ihre Festplatte kaputt geht – kein wirklicher Datenverlust (ich gehe davon aus, dass Sie Ihre Schlüssel separat sichern – Redundanz ist keine Sicherung und ungetestete Kopien sind keine Sicherungen!). Um die Synchronisierungszeit zu verkürzen, können Sie, wenn Ihre Volumes/Festplatten Snapshots unterstützen, jederzeit Snapshots erstellen und Ihre Daten auf ein kostengünstigeres Medium wie Ihre vorhandenen Festplatten ausgeben. Dann ist eine Wiederherstellung so einfach wie die Wiederherstellung aus den Snapshots und Sie müssen nur eine teilweise Neusynchronisierung durchführen. In diesem Fall ist der IOP-Vorteil von SSDs strittig – Sie brauchen nur einen Durchsatz, um Ihr Backup wiederherzustellen, von dem Ihre HDDs mehr als genug bieten. DieDie vollständige Ethereum-Blockchain (anstelle von beschnittenen Synchronisierungen) beträgt derzeit etwa 350 GB. Sie könnten diese Datenmenge von einer einzigen Festplatte in weniger als einer Stunde auf einer SSD wiederherstellen (bei einer Festplattenübertragungsrate von 120 MB/s). Also... Spiegeln ist auch nicht nötig!

Abgesehen davon läuft einer meiner Ethereum-Knoten auf einem 2x512GiB RAID1 ZFS-Volume, das aus SSDs besteht. Dies liegt daran, dass ich vorhabe, andere Daten, die eine geringe Latenz benötigen, zu einem späteren Zeitpunkt auf diese Festplatten zu legen (im Moment sind die Festplatten größtenteils leer). Anstatt eine nicht-redundante Festplatte für diese Aufgabe bereitzustellen, habe ich das gespiegelte Volume verwendet, da mir die Schächte für Hot-Swap-Festplatten ausgegangen sind und ich keinen Schacht „verschwenden“ wollte. Daher sehe ich mehrere Anwendungsfälle für RAID10 oder andere RAID-Level, die für die Blockchain verwendet werden – ich glaube nur nicht, dass es so viele gibt. Hoffentlich habe ich dir ein paar $$$ gespart :)

Weitere Leistungsdaten mit Parity/v1.7.7-stable-eb7c648-20171015/x86_64-macos/rustc1.20.0: Ich habe gerade eine brandneue Synchronisierung im Pruned-Modus (der mindestens so viel I/O wie der Archivmodus ausführen sollte) durchgeführt ein NVMe-Laufwerk; es sind nur 256 GiB, also könnte ich keinen Archivtest machen, wenn ich wollte. Meine Netzwerkverbindung ist ~200 Mbit/s hoch und runter. Parität scheint viel lese-IOPS-intensiver zu sein als Schreib-IOPS, schreibt aber in Bezug auf das Datenvolumen etwa doppelt so viel, sodass RAID1 mehr Leistungsvorteile zu bieten scheint als RAID0. Außerdem sehe ich nur 5-10.000 IOPS (<5 % Auslastung) und einen Durchsatz von 200 MB/s. und scheinen daher CPU-eingeschränkt zu sein: ~ 2 Kerne auf einem i7 6700HQ (2016 15 "MBP) ausgeschöpft. Der Vorgang dauerte 2h29m.