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.
+ Antworten
Ergebnis 1 bis 23 von 23
Thema: SSD oder RAM Filesystem?
- 08.12.10, 10:58 #1Matrose
- Registriert seit
- 21.08.2008
- Beiträge
- 30
SSD oder RAM Filesystem?
- 08.12.10, 11:02 #2Stabsgefreiter
- Registriert seit
- 01.02.2010
- Beiträge
- 315
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.
BackboneGeändert von Backbone (08.12.10 um 11:05 Uhr)
- 08.12.10, 11:54 #3Matrose
- Registriert seit
- 21.08.2008
- Beiträge
- 30
Themenstarter
Ok herzlichen Danke soweit.
Mit dem SAN kenne ich mich leider gar nicht aus ;-) ich weis aktuell nur das es hier der Flaschenhals liegt ;-)
- 08.12.10, 12:30 #4Bootsmann
- Registriert seit
- 29.06.2006
- Beiträge
- 646
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.
- 08.12.10, 12:32 #5
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.Geändert von HisN (08.12.10 um 12:34 Uhr)
ACARD-Workstation VRAM/RAM-Usage aktueller Games
Suche (funktionierende) SLI-Profile: Rage, Age of Conan, X-Plane
- 08.12.10, 12:35 #6Matrose
- Registriert seit
- 21.08.2008
- Beiträge
- 30
Themenstarter
Storage wird dann, statt im SAN, lokal angebunden, das ist zum Glück kein Thema.
- 08.12.10, 13:33 #7SuperModerator
Mr. Alzheimer
- Registriert seit
- 01.11.2004
- Ort
- Bärlin
- Beiträge
- 13.930
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?
- 08.12.10, 15:12 #8Matrose
- Registriert seit
- 21.08.2008
- Beiträge
- 30
Themenstarter
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.
- 08.12.10, 15:23 #9SuperModerator
Mr. Alzheimer
- Registriert seit
- 01.11.2004
- Ort
- Bärlin
- Beiträge
- 13.930
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.
- 08.12.10, 18:59 #10Stabsgefreiter
- Registriert seit
- 28.03.2008
- Beiträge
- 363
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.
- 08.12.10, 19:01 #11SuperModerator
Mr. Alzheimer
- Registriert seit
- 01.11.2004
- Ort
- Bärlin
- Beiträge
- 13.930
- 08.12.10, 20:05 #12Stabsgefreiter
- Registriert seit
- 28.03.2008
- Beiträge
- 363
Naja Output (lesen) macht eine SSD schön flott bei Input (schreiben) wirds auf dauer schon was langsamer.
Bei einer Ramdisk ist das egal.
- 08.12.10, 20:10 #13SuperModerator
Mr. Alzheimer
- Registriert seit
- 01.11.2004
- Ort
- Bärlin
- Beiträge
- 13.930
Das Problem hält sich bei SLC aber sehr in Grenzen. SLC machen echt Spaß.
- 08.12.10, 20:47 #14Stabsgefreiter
- Registriert seit
- 28.03.2008
- Beiträge
- 363
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.Geändert von Fr@ddy (08.12.10 um 20:49 Uhr)
- 08.12.10, 21:45 #15SuperModerator
Mr. Alzheimer
- Registriert seit
- 01.11.2004
- Ort
- Bärlin
- Beiträge
- 13.930
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.
- 09.12.10, 04:27 #16Stabsgefreiter
- Registriert seit
- 28.03.2008
- Beiträge
- 363
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.
- 09.12.10, 07:41 #17Matrose
- Registriert seit
- 21.08.2008
- Beiträge
- 30
Themenstarter
Anzustreben wäre bei dieser Applikation eine IO von ca. 10 000 - 12 000 IOPS.
- 09.12.10, 07:49 #18Gefreiter
- Registriert seit
- 24.12.2009
- Beiträge
- 34
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
- 09.12.10, 10:31 #19Matrose
- Registriert seit
- 21.08.2008
- Beiträge
- 30
Themenstarter
Stecken ist in Pizzaschachteln (fast) immer schlecht :-)
- 09.12.10, 12:40 #20SuperModerator
Mr. Alzheimer
- Registriert seit
- 01.11.2004
- Ort
- Bärlin
- Beiträge
- 13.930
Hinzukommt, dass man nen Treiber braucht. ESX unterstützt die Teile nicht. (sonnst hätte ich schon so nen Revodrive
)
- 09.12.10, 16:18 #21
Kann man doch sicher via Linux Treiber selbst einen zusammen schustern
Workstation: 2x Intel Woodcrest Xeon 5160@3560,03MHz (WR) | Tyan Tempest i5000XL | 2x1+2x4GB Kingston Value FB-Dimm DDR2-667 CL5 | PoV GF465@470GTX 1280MB@750/1550MHz@1,1V | Audigy 2 ZS | HPT RocketRaid 2300 | 1x160GB Samsung SATA; 2x320GB WD SATA non Raid; 4x500GB WD RE SATA@Raid5 | Windows 7 Prof. 64Bit
ESX Server: 2x Intel Woodcrest Xeon 5150@2660MHz | Intel S5000PSL SATA | 6x1+2x1GB Samsung/Kingston FB-Dimm DDR2-667 CL5 | Nvidia Quadro NVS 280 | 1x120GB Samsung SATA; 1x1TB Hitatchi SATA | ESXi 4.0.0
Fileserver: 1xPentium 4 3,0GHz | Asus P4C800 Deluxe | 1x512MB Corsair DDR333 CL2 | Asus Geforce 4 TI 4200 64MB | 1x160GB Samsung SATA; 2x160GB Maxtor IDE non Raid; 1x250GB Seagate IDE; 2x320GB WD SATA non Raid; 1x500GB Seagate SATA | Windows Server 2003 R2 32Bit Standard
- 09.12.10, 18:05 #22SuperModerator
Mr. Alzheimer
- Registriert seit
- 01.11.2004
- Ort
- Bärlin
- Beiträge
- 13.930
Schustern trifft es wohl ganz gut.
- 10.12.10, 08:09 #23Stabsgefreiter
- Registriert seit
- 28.03.2008
- Beiträge
- 363
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-x...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.

LinkBack URL
About LinkBacks
Zitieren

