SSD oder RAM Filesystem?

[BoaThor]

Hallo Leute,
ich habe extreme Probleme mit der IO einzelner Server. Der Datendurchsatz des Filesystems ist einfach zu gering, das SAN hängt am Anschlag. Das Problem sind die vielen IOs der Anwendung.

Die Frage ist ob sich die Situation durch den Einsatz von (vorzugsweise) lokalen SSD oder dem Einsatz eines RAM-Filesystems verbessern lässt.

Ist der Einsatz von SSD überhaupt sinnvoll-> Lebenszeit, wenn ja worauf muss geachtet werden. Welche Typen sind empfehlenswert.

*Das benötigte Speichervolumen liegt im Endausbau etwa 40-50 GB.

 

[Backbone]

Server SSDs sind immernoch vergleichsweise teuer, allerdings in IO-fordernden Szenarien genau DAS mittel der Wahl.

Was hast du denn im Moment für einen Aufbau, wie hängt das SAN denn dran und um welches handel es sich. Bei vielen SANs kann man die Plattentypen auch mischen und zum Beispiels auf 2 SSDs ein Raid 1 machen und diese Raidgruppe dann als dedizierte LUN dem entsprechenden Server zuweisen.

Mit RAM kann man das eigentlich nur machen, wenn man keine großen Anforderungen an Sicherheit, Redundanz und Integrität hat. In einem "richtigen" Produktivsystem hat sowas aus meiner Sicht jedenfalls nix verloren.

Backbone

 

[BoaThor]

Ok herzlichen Danke soweit.
Mit dem SAN kenne ich mich leider gar nicht aus ;-) ich weis aktuell nur das es hier der Flaschenhals liegt ;-)

 

[mr.no-name]

Wenn das SAN der Flaschenhals ist bringt lokaler SSD/RAM-Speicher ja nichts - es sei denn die IO-Last kann ohne große Umstände vom SAN auf den lokalen Speicher umgelegt werden.

 

[HisN]

Man kann für hohes IO auch ein (oder mehrere) Acard9010/Hyperdrive5 (Maximalausbau 64GB pro Laufwerk) benutzen.
Hat den hohen IO einer Flash-SSD, aber nicht deren Nachteile beim Schreiben oder in der Haltbarkeit (der RAM Deiner Server hält ja auch ewig^^).
Allerdings hat mein Vorschreiber recht, wenn das Netzwerk den IO gar nicht transportieren kann bringt eine schnellere Storage-Lösung wenig.

 

[BoaThor]

Storage wird dann, statt im SAN, lokal angebunden, das ist zum Glück kein Thema.

 

[underclocker2k4]

Erstmal würde ich auf SLC SSDs setzen.
Man kann auch das SAN auf SSDs umrüsten, entweder komplett oder eben partiell, alles ne Frage der Usage.

Die von HisN genannte Technik würde ich persönlich nicht in Produktivumgebunden einsetzen, klar die Technik ist sehr sehr performant, aber genau diese Technik sorgt prinzip bedingt dafür, dass es zu einem Datenverlußt kommen kann, wenn zB der Akku platt ist.

Beschreibe doch mal das System. Müssen denn Zugriffe aufs SAN sein, oder kann man wirklich, wie von dir vorgeschlagen, sowas auch lokal abspeisen?

 

[BoaThor]

Der aktuelle Server ist eine virtualisierte Linux-Webserver-Büchse (LAMP) als MySQL, PHP-Scripte, Apache. Da der Server aber als Monitoringstation (ahnlich Munin, Nagios, Cacti etc.) für mehrere hundert Systeme arbeitet, macht die Kiste viel IO. Das macht den Raid-Controller im SAN zu 90% dicht, weil der Slice der Maschine nur auf einer Lane fährt... ändern kann man da nix, da das SAN die Verschwaltung der Slices, Strips, Lanes vollständig automatisiert...
kotz...

Ich möchte jetzt gerne lokal ein paar SSD reinstecken, mounten, Anwendung umkopieren. Da es ein Prod-System ist soll sich das ganz möglichst an "erprobten" Konzepten orientieren.

 

[underclocker2k4]

Dann steht einem local Storage ja nix im Wege.

Empfehlung für SLC SSDs
Solidata K5-64GB - Artikeldetailansicht - WINKOM-Shop
oder besser aber >2x so teuer aber auch 2x schneller
SOLIDATA SC 64-SLC- Sandforce - Artikeldetailansicht - WINKOM-Shop

Die K5 setze ich selber in meinem Server ein. Macht gut was her. Auch vom IO her.

 

[Morpheus2200]

Sind das temporäre Daten oder werden die über einen längeren Zeitraum aufgezeichnet?

Wenn die Daten verzichtbar sind würde ich für RAM stimmen, evtl. mit einem cronjob der die Daten täglich/stündlich oder so sichert. Evtl. kann man durch einen sinvollen wert die benötigte Datenmenge reduzieren.
Eine lokale SSD wird auch helfen, aber die macht halt bei o eine bessere Figur als bei i.

 

[underclocker2k4]

aber die macht halt bei o eine bessere Figur als bei i.

?_? (steh ich aufm Schlauch?)

 

[Morpheus2200]

Naja Output (lesen) macht eine SSD schön flott bei Input (schreiben) wirds auf dauer schon was langsamer.
Bei einer Ramdisk ist das egal.

 

[underclocker2k4]

Das Problem hält sich bei SLC aber sehr in Grenzen. SLC machen echt Spaß.

 

[Morpheus2200]

Ich glaube gern, dass das bei SLCs deutlich besser ist als bei MLCs.

Aber ich hab mal gerade kurz HDtune angeworfen.
Lesen: min. 2GB/s max 4GB/s bei der RAMDISK bei der (MLC) SSD min. 163MB/s max. 235MB/s ist immerhin um einen Faktor zwischen 10 und 20 schneller.
Und das schon bei meinem kleinen Core2 Duo mit DDR2 speicher.

Von den Zugriffszeiten sprechen wir mal nicht, die sind bei der Ramdisk deutlich flotter.
Wenn man wirklich I und O braucht und vielleicht auch beides gleichzeitig ist es einfach schön, wenn man an Schnitstellen vorbei ohne Flaschenhälse oder miese controler-treiber einfach nur schreiben oder lesen kann. Kein NCQ kein caching, keine lokalen buffer aus dem übrigem RAM die notwendig wären.
Bei VMs geht das ganze auch noch durch X virtualisierungs/emulations-schichten, RAM kann man einfach reservieren und gut.
Software-Ramdisks senken auch die CPU last bei extrem IO lastigen Anwendungen teilweise erheblich. Voraussetzung ist natürlich, dass man auf die Daten seit dem letzten Sicherungslauf verzichten kann.

Was kann man so in etwa auf SLCs schreiben in der sekunde? Mal angenommen man hat millionen winziger files? Oder auch mal viele Files die genau sektorgröße der SSD haben.

 

[underclocker2k4]

Es geht mir bei der SLC darum, dass sie mit der Zeit, auch ohne TRIM und co, nicht so stark einbrechen.

Das Problem bei RAMDISKs ist einfach, dass ich sowas nicht produktiv einsetzen würde, vorallem nicht in Servern. Wenn da auch nur etwas unvorhergesehens passiert, kannst du den Datenbestand in der Pfeife rauchen.

Beim ESX zB ist nicht viel mit RAMDISKs, da mußt du also auch normalen Storage gehen.

 

[Morpheus2200]

Naja kommt immer auf die Daten an. Beim monitoring wie hier sollte man sich fragen wie schlimm das ist wenn die Daten der letzten Stunde nicht da sind. Geht es nur darum, live-statistiken zu haben ist das wohl halb so wild. Braucht man die Statistiken im Fehlerfall sind wohl auch fehlende minuten mies.

RAMDISK in der VM ist simpel, einfach mehr RAM zuteilen un din der VM halt die Ramdisk erstellen.
Man kann auch Anwendungen oder read-only Daten beim Systemstart in eine software-ramdisk kopieren.
Bei read-only exportierten Dateisystemen kann das ganz nett sein wenn auf den Platten zeitgleich viele Zugriffe statfinden. Ich hab zum Beispiel einige zentral im Netzwerk installierte Anwendungen die davon ganz gut profitieren.

Aber das ist wohl alles off topic.

 

[BoaThor]

Anzustreben wäre bei dieser Applikation eine IO von ca. 10 000 - 12 000 IOPS.

 

[hardballS4]

BoaThor
Schau dir sonst doch mal die REVODRIVES von OCZ an ggf. wäre das eine Lösung.
Sicherlich genügend IOPS schnell wie hölle und ggf. weniger anfällig für Ausfälle als
eine RAMDISK. Als Nachteil sehe ich einfach das du einen PCI-E X4 Slot freihaben
musst um die Karte Stecken zu können und den Preis.

hth
Hardball

 

[BoaThor]

Stecken ist in Pizzaschachteln (fast) immer schlecht

 

[underclocker2k4]

Hinzukommt, dass man nen Treiber braucht. ESX unterstützt die Teile nicht. (sonnst hätte ich schon so nen Revodrive )

 

[fdsonne]

Kann man doch sicher via Linux Treiber selbst einen zusammen schustern

 

[underclocker2k4]

Schustern trifft es wohl ganz gut.

 

[Morpheus2200]

Eine Intel X25-E 64GB oder vergleichbares also SLC SSD mit SATA hätte den Vorteil, dass sie für die Software ein 0815 SATA-Laufwerk ist und den Platz bietet, den du brauchst bei relativ überschaubaren Kosten.
Problem dabei: iops lassen nach etwas Laufzeit doch etwas zu wünschen übrig.
http://www.xssist.com/images/intel-x25e-cacheon-4kb-32000s.jpg

Denkbar wäre auch die SSD an einen cached Controller zu hängen, aber was das wirklich bringt ist fraglich.

Wesentlich schneller wirds nur mit RAM.
Oder du guckst nochmal, ob die Software auch mit halb so viel IOPS annehmbar läuft.
Denkbar wäre es ja auch, die Software auf mehreren Systemen zu nutzen oder die Daten auf mehrere SSDs zu legen. Lässt sich das denn überhaupt aufteilen oder sammlt man da alle Daten in einer großen Datenbank?

Wenn das alles nicht hilft ist dein Problem vielleicht so mit heutiger Hardware nicht realisierbar, dass soll es auch geben. Dann muss man halt überlegen wo man abstriche machen kann.
Aber mal eine andere Frage.
Die daten die da auf die SSD sollen, die müssen ja auch irgendwo herkommen, ist das netz dafür überhaupt tauglich? 10-12k infos in der Sekunde muss man ja auch erstmal durchs Netz schleusen, das ist ja auch nicht ganz ohne.

Oder werden die daten die meiste zeit eh nur gelesen? dann wäre noch eine andere variante denkbar.
Schreiben der gesammelten Messwerte auf SSD und auswerten in einer Ramdisk, alle 5 minuten oder so halt ein sync. Kommt halt drauf an wie die Daten aussehen, bei datenbanken könnte es kompliziert werden.
Dann gehen aber keine daten beim ausschalten verloren und die live-statistik geht halt nur 5 min. nach.