SSD im Server-Betrieb

Der Einsatz von Solid State Drives (SSD) ist inzwischen auch im Server-Umfeld Alltag. In diesem Beitrag verdeutlichen wir mit Co-Autor Michael Elbel, IT-Leiter bei ConSol, die StĂ€rken der SSD gegenĂŒber klassischen Festplatten

1 Star2 Stars3 Stars4 Stars5 Stars (29 votes, average: 3,86 out of 5)
Loading...
| CompuRAM Redaktion | 10 Antworten
Schlagwörter: , , ,

Der Einsatz von Solid State Drives (SSD), wie z.b. die Samsung SM863 oder auch die PM863, ist inzwischen auch im Server-Umfeld Alltag. In diesem Beitrag verdeutlichen wir gemeinsam mit Co-Autor Michael Elbel, IT-Leiter beim MĂŒnchner IT-Service Provider ConSol, die tatsĂ€chlichen StĂ€rken der Flashspeicher im Rechenzentrum gegenĂŒber klassischen Festplatten. Anhand von Best Practices zeigen wir klassische Anwendungsbeispiele und geben Strategien an die Hand, wie Sie das Potential von SSDs optimal in Ihrer individuellen Unternehmens-IT-Infrastruktur nutzen können.

Der Beitrag im Überblick:  

SSDs: Keine Sicherheitseinbußen im Server

Zweifel hinsichtlich der Eignung der Flashspeicher im Server-Umfeld aufgrund ihrer Lebensdauer und Ausfallsicherheit sind heute nicht mehr berechtigt. Die Hersteller von Server-SSDs haben in den vergangenen Jahren mit Hochdruck daran gearbeitet, die Zahl der garantierten Schreib- und Lesezugriffe deutlich zu erhöhen, so dass sich die Lebensdauer von SSD und HDD im professionellen Bereich weitestgehend angenĂ€hert hat. So beinhaltet eine 256GB SSD fĂŒr den Server-Einsatz je nach Hersteller tatsĂ€chlich zwischen 300 und 350GB – auch wenn die Logik der Platte den Puffer außen vor lĂ€sst und konsequent 256GB anzeigt. Geht tatsĂ€chlich einmal ein Block kaputt, was man meistens beim Schreiben bemerkt, so wird ersatzweise der nĂ€chste Block beschrieben.

Zudem sorgt „Wear leveling“ dafĂŒr, dass die zur VerfĂŒgung stehenden Speicherzellen ausgewogen beschrieben werden. Dabei packt eine SSD beispielsweise die Windows-Auslagerungsdatei (pagefile.sys) nicht bei jedem Speichervorgang in dieselbe Speicherzelle, sondern verteilt sie ĂŒber alle beschreibbaren Bereiche. Auf diese Weise wird der ĂŒberlastungsbedingte Ausfall einzelner Zellen (durchschnittlich nach etwa 10.000 vollstĂ€ndigen Schreibzugriffen) deutlich verzögert.

Überdies stehen im Falle eines Ausfalls durchaus Hilfsmittel zur VerfĂŒgung, verlorene Daten aus einer defekten SSD herauszuholen, auch wenn das Thema Datenrettung von SSDs natĂŒrlich noch genauso jung ist, wie die Technologie selbst.

Um gegen den möglichen Ausfall einer einzelnen Platte gewappnet zu sein, sollten Festplatten in Servern – ganz gleich ob es sich um SSD oder HDD handelt – in RAIDs („Redundant Array of Independent Disks“) organisiert sein. Dank der gezielt redundant erzeugten Informationen im RAID-System ist auch beim Ausfall einer einzelnen RAID-Komponente DatenverfĂŒgbarkeit gewĂ€hrleistet.

Dabei darf die Redundanz im RAID allerdings keinesfalls mit Datensicherheit verwechselt werden: Sie schĂŒtzt allein vor dem Ausfall einer Platte im RAID-Verbund, nicht aber vor dem – im VerhĂ€ltnis deutlich wahrscheinlicheren – Datenverlust etwa durch Software- oder Anwender-Fehler. Vor der Entscheidung fĂŒr eine SSD oder HDD als Speichermedium innerhalb des Servers und dem Aufbau eines RAID-Verbundes muss zwingend – sofern nicht vorhanden – die sorgfĂ€ltige Ausarbeitung eines Backup-Konzepts stehen, das nicht nur die Datensicherung selbst klar definiert, sondern auch organisatorische Aspekte umfasst wie z.B. die vom Server rĂ€umlich getrennte Aufbewahrung der Backups zum Datenerhalt bei Feuer- und WasserschĂ€den.

Kurzum: Wer sich auf Basis eines vernĂŒnftigen Backup-Konzeptes fĂŒr den Einsatz von SSDs in seinem Server entscheidet und diese in einem RAID organisiert, muss im Vergleich zu klassischen Festplatten keinerlei Sicherheitseinbußen hinnehmen.

StÀrken von SSDs im Serverbetrieb

WĂ€hrend SSDs in mobilen GerĂ€ten durch ihren geringen Energieverbrauch und ihre besondere Unempfindlichkeit gegenĂŒber StĂ¶ĂŸen punkten, spielen diese Aspekte im Rechenzentrum keine Rolle. So haben sich im Serverbetrieb auch bei den klassischen Festplatten die Formfaktoren in den letzten Jahrzehnten drastisch verĂ€ndert: Abgesehen von der technischen Entwicklung, dass immer grĂ¶ĂŸere SpeicherkapazitĂ€ten auf immer kleineren Platten unterkommen, geht die Tendenz auch aus PlatzgrĂŒnden in den vergangenen Jahren zunehmend zum Einsatz kleinerer Platten. Neuere Server sind also nicht zwangslĂ€ufig mit 3,5 Zoll-, sondern hĂ€ufig mit 2,5 Zoll-Festplatten ausgestattet. Je kleiner die physischen Abmessungen einer Festplatte sind, desto geringer ist auch ihr Stromverbrauch. Gemessen an ihren KapazitĂ€ten unterscheiden sich die Energiebilanzen von HDD und SSD nicht mehr allzu deutlich – hĂ€ufig braucht bei einem leistungsstarken Server die CPU mehr Strom als die installierten Speicherplatten.

Rasanter Zugriff – die wahre StĂ€rke der Flashspeicher

Die tatsĂ€chliche StĂ€rke von SSDs liegt in ihrer Performance. Im Server-Umfeld kommt dabei weniger die Datentransferrate (auch DatenĂŒbertragungsrate) zum Tragen, da diese bei aktuellen Festplatten – egal ob HDD oder SSD – mit ĂŒber 200 MB/sec. jenseits dessen liegt, was im Serverbetrieb ĂŒblicherweise nötig ist. Oft sind der Datentransfergeschwindigkeit anderweitig Grenzen gesetzt, z.B. wenn die Daten in einem SAN (Storage Area Network ) gelagert sind.

Ganz anders verhĂ€lt es sich mit der Zugriffszeit. Diese ist bei SSDs deutlich kĂŒrzer als bei HDDs, bei denen sich erst die Platte drehen und der Kopf mechanisch zur richtigen Stelle bewegen muss. Da Server, auf denen mehrere Applikationen laufen, in aller Regel mit einem großen Hauptspeicher (RAM) ausgestattet sind, mĂŒssen sie nicht fĂŒr jede einzelne Aktion auf die Festplatte zurĂŒckgreifen. Das heißt, der Einsatz einer SSD muss im Vergleich zu einer HDD nicht zwangslĂ€ufig stark zu Buche schlagen.

Drastische Unterschiede sind dagegen bei I/O-intensiven Anwendungen messbar, bei denen beispielsweise mehrere Nutzer gleichzeitig auf dem Server arbeiten und auf Daten zugreifen. WĂ€hrend eine klassische Festplatte mit 50-100 IOPS (I/O operations per second) aufwartet, sorgt eine SSD mit 10.000 IOPS fĂŒr einen Faktor 1.000 an Performance-Plus. Typische Einsatzgebiete fĂŒr SSDs in Servern finden sich somit immer im Umfeld von Anwendungen, die innerhalb kĂŒrzester Zeit auf große Datenmengen zugreifen, diese verarbeiten und zur VerfĂŒgung stellen – etwa Datenbanken (MySQL, MS-SQL, Oracle
) oder Exchange-Server.

Klassische AnwendungsfĂ€lle und Best Practices fĂŒr SSDs in Servern

Beispiel: 100 Anwender erhalten stĂŒndlich 100 E-Mails und greifen laufend auf ihre PostfĂ€cher zu. Bis der gewĂŒnschte Datenpunkt auf der HDD erreicht ist, werden bei jedem Zugriff 10 Millisekunden benötigt. Bei 100 Zugriffen pro Sekunde wird es in diesem Fall ohne den Einsatz von SSDs auf dem Mail-Server schnell eng.

Wer eine zugriffsintensive Applikation hat, die Performance-BeschrÀnkungen unterliegt, sollte zunÀchst untersuchen, warum sie so viele Zugriffe/Sekunde benötigt. Sofern softwareseitig alles in Ordnung ist, löst der gezielte Austausch der betroffenen HDDs im Server gegen SSDs in einem solchen Fall den Engpass und bringt enormen Gewinn. So auch bei folgendem Kunden-Projekt von ConSol:
Ein großer Automobilhersteller nutzt die BPM-Software ConSol*CM im Lead Management. In einem Data Warehouse werden laufend alle prozessrelevanten Informationen gespeichert und fĂŒr Analysen zur VerfĂŒgung gestellt. Einmal pro Stunde sollte ein Report ĂŒber die gesamte Datenbank gezogen werden – allerdings dauerte es zunĂ€chst ausgesprochen lange, bis das Ergebnis verfĂŒgbar war. Hintergrund: Das integrierte Analyse-Tool musste fĂŒr jeden Report auf eine schier unendliche Anzahl von DatensĂ€tzen zugreifen, um ein aussagekrĂ€ftiges Ergebnis zusammenzustellen. Heute lĂ€uft die gesamte Anwendung inkl. Data Warehouse und Reporting auf Server-SSDs. Der Austausch bewirkte, dass die Datenanalyse auf einen Schlag fĂŒnf Mal schneller erfolgte als zuvor auf den klassischen Festplatten. Entsprechend schneller stehen die Reports jetzt zur weiteren Nutzung zur VerfĂŒgung.

Einen Anhaltspunkt fĂŒr die tatsĂ€chliche Wirkung des – in der Regel partiellen – UmrĂŒstens eines Servers auf SSD gibt die Betrachtung des Working Sets. Das Working Set ist die Menge von Daten innerhalb einer Anwendung, die in einem vorgegebenen Zeitraum hĂ€ufig genutzt werden: Ein Warenwirtschaftssystem umfasst beispielsweise sĂ€mtliche Rechnungen und Kontenbewegungen der vergangenen zehn Jahre. TatsĂ€chlich gearbeitet wird aber normalerweise nur mit den Daten der letzten drei Monate. WĂ€hrend alle Daten zusammengenommen einen Speicherbedarf von geschĂ€tzten 20-200GB haben, wird in diesem Fall nur auf rund 2GB regelmĂ€ĂŸig zugegriffen; eine GrĂ¶ĂŸenordnung, die der Hauptspeicher spielend abdeckt: Er liest die benötigten Daten einmal aus und nur in AusnahmefĂ€llen muss er anschließend erneut auf die Platte zugreifen. Die besondere StĂ€rke einer SSD kĂ€me hier nicht wesentlich zum Tragen, sofern der Server mit ausreichend RAM-KapazitĂ€t ausgestattet ist.

Tiering: Datenspeicher sinnvoll aufteilen

Um SpeicherkapazitĂ€t und IOPS gleichzeitig zu optimieren, bieten die Hardware-RAID-Controller der gĂ€ngigen Server-Hersteller die Möglichkeit, bestehende HDDs im Speichersubsystem durch SSDs zu ergĂ€nzen, die dann intern als Zwischenspeicher dienen und sicherstellen, dass hĂ€ufig genutzte Daten schnellstmöglich verfĂŒgbar sind. Auf diese Weise lĂ€sst sich die Zugriffsgeschwindigkeit oftmals auf einen Schlag um den Faktor 2 beschleunigen, obwohl weiterhin hauptsĂ€chlich HDDs im Einsatz sind.

GrundsĂ€tzlich bieten Server im Vergleich zu einfachen Rechnern oder gar Notebooks aufgrund ihrer grĂ¶ĂŸeren Anzahl von Slots zur BestĂŒckung mit SSD oder HDD ein deutliches Plus an FlexibilitĂ€t. Da unterschiedliche Festplatten und KapazitĂ€ten sehr große Preisunterschiede aufweisen, arbeitet man bei der Konfektionierung von Servern in der Regel mit „Tiering“ (dt. Abstufung, Staffelung). Dabei wird der gesamte Datenspeicher in verschiedene Gruppen unterteilt und geeigneten Speichermedien zugeordnet. Hier ein Beispiel fĂŒr ein 3-stufiges Tiering:

    • SSDs fĂŒr ĂŒberschaubaren Datenbereich, auf den extrem schnell zugegriffen werden muss
    • SAS-Festplatten fĂŒr grĂ¶ĂŸeren Bereich mit wichtigen und hochperformanten Daten, auf den ein schneller Zugriff erforderlich ist
    • Große und gĂŒnstigere SATA-Festplatten fĂŒr den Datenbereich, auf den nur selten zugegriffen wird (z.B. Archivierung)

ssd-vs-festplatte

Step by Step: SSDs gezielt in der Server-Infrastruktur nutzen

Wer also vor sinkenden Reaktionszeiten seines Servers steht und aus seiner bestehenden Hardware das Maximum an Leistung, Datensicherheit und VerfĂŒgbarkeit herausholen möchte, sollte Schritt fĂŒr Schritt seine individuelle Speicher-Zielausstattung erarbeiten. Allem voran stehen sollte dabei ein tragfĂ€higes Datensicherheitskonzept mit einem sauber aufgesetzten Backup.

1.       Ursachen kennen

ZunĂ€chst ist im Detail zu untersuchen, was die Reaktionszeit des Servers verlangsamt hat: Ist die Nutzerzahl oder die Datenmenge gestiegen? Sind neue Anwendungen im Einsatz? Eine solche Ursachenanalyse hilft zum einen, technische Probleme unabhĂ€ngig von SpeicherengpĂ€ssen aufzuspĂŒren und ggf. zu beheben, zum anderen dienen die Ergebnisse als fundierte Ausgangsbasis fĂŒr die nachfolgenden Schritte.

2.       Optionen prĂŒfen (1): RAM aufrĂŒsten

Soll das System schneller auf ein ĂŒberschaubares Working Set zugreifen, so kann ein Upgrade des Hauptspeichers auf Maximalwerte schnell und unkompliziert fĂŒr ein spĂŒrbares Performance-Plus beim Datenzugriff sorgen.

3.       Optionen prĂŒfen (2): Festplattenslots und AnschlĂŒsse abchecken

Sofern es mit dem RAM-Upgrade nicht getan ist bzw. bereits im Hinblick auf zukĂŒnftige Anforderungen die Ausstattung des Servers mit SSDs sinnvoll ist, fĂŒhren Sie eine detaillierte Bestandsaufnahme an Ihrem Server durch: Wie viele Festplatten-Slots gibt es? Wie viele davon sind frei? Welche Festplatten sind aktuell verbaut (KapazitĂ€ten, AnschlĂŒsse)?

Bei Servern mit 3,5-Zoll-EinschĂŒben ist in der Regel der Einsatz eines Montagerahmens notwendig. GĂ€ngige Adapter-Rahmen passen allerdings meistens nicht in Hot-Swap-EinschĂŒbe, da hier der SATA-Konnektor nicht an der gleichen Stelle sitzt wie der einer 3,5-Zoll Platte. Soll also eine bestehende 3,5-Zoll-HDD durch eine Hot-Swap-fĂ€hige SSD ersetzt werden, so ist deren Einbau unter UmstĂ€nden mit etwas Bastelarbeit verbunden, was wiederum die Hot-Swap-Möglichkeit erschwert. Bei 2,5-Zoll-EinschĂŒben besteht dieses Problem nicht.

4.       SSDs auswÀhlen

FĂŒr die Auswahl der richtigen SSD-KapazitĂ€t ist die Datenmenge ausschlaggebend, die langfristig darauf gelagert werden soll. GrundsĂ€tzlich lĂ€sst sich jede Festplatte durch ein schnelleres Speichermedium mit gleicher KapazitĂ€t ersetzen. Zumeist werden jedoch grĂ¶ĂŸere Festplatten aus KostengrĂŒnden durch SSDs mit kleinerer KapazitĂ€t ersetzt, so dass vor der Migration Daten umgeshiftet werden mĂŒssen (vgl. Punkt 6). In diesem Fall gibt ein sorgfĂ€ltig erarbeitetes Tiering-Konzept Aufschluss ĂŒber die geeignete SSD-GrĂ¶ĂŸe.

5.       RAID-Verbund konzipieren

Um gegen den Ausfall einer SSD gefeit zu sein, sollte bei der UmrĂŒstung von Anfang an ein RAID-Verbund eingeplant werden. Insbesondere wenn die SSDs Teil eines mehrstufigen Tiering-Konzepts sind, genĂŒgt in der Regel eine Datenspiegelung im Rahmen eines schlichten RAID 1 mit einem SSD-PĂ€rchen. Wie man das RAID aufbaut, hĂ€ngt dabei stark von der Art des Servers sowie vom eingesetzten RAID-Controller ab. In der Regel lĂ€sst sich der Verbund im laufenden Betrieb einrichten.

Falls im Server nicht mehr ausreichend Platz fĂŒr 2 – oder ggf. 4 – SSDs ist, lassen sich durch kombinierte AnsĂ€tze freie Slots schaffen. So kann in Betracht gezogen werden, zunĂ€chst die bestehenden Festplatten durch grĂ¶ĂŸere zu ersetzen. Beispiel: Ein Server ist mit vier 500GB Festplatten ausgestattet – alle Festplatten-Slots sind damit besetzt. Um mit zwei SSDs gezielt fĂŒr eine höhere Zugriffsgeschwindigkeit sorgen zu können, werden daher zwei Terabyte-Festplatten eingesetzt und mit den Inhalten der 500GB HDDs bestĂŒckt, so dass die SpeicherkapazitĂ€t der Festplatten grundsĂ€tzlich erhalten bleibt und zugleich zwei Slots frei werden.

6.       Datenmigration

Bei gegebener Slot-Knappheit ist fĂŒr die Datenmigration im laufenden System möglicherweise etwas KreativitĂ€t gefragt. Um etwas Raum zum Umshiften der Daten zu schaffen, empfiehlt sich in solchen FĂ€llen z.B. der RĂŒckgriff auf externe Speichermedien. Schon bei der KapazitĂ€tsplanung sollte in jedem Fall ein klares Konzept vorliegen, welche Daten ihren Platz final auf welcher Platte finden sollen. Auf diese Weise lassen sich nicht nur gezielt die benötigten KapazitĂ€ten bestimmen, sondern auch ungewollte Datenverluste und Redundanzen im Rahmen der Migration von vornherein ausschließen. GrundsĂ€tzlich hĂ€ngen die tatsĂ€chlichen Migrationsschritte stark von den Raid-Controllern und dem Betriebssystem ab, welche zum Einsatz kommen.

(Update 3.2.2016) Wie es sich um die konkrete Lebensdauer einer SSD verhĂ€lt und wie und ob man dies beeinflussen kann, lesen Sie in unserem Beitrag „Die Lebensdauer einer SSD – wie lange hĂ€lt sie und was kann ich ihr Gutes tun?“

consol_michael_elbel_6886-klMichael Elbel ist IT-Leiter beim MĂŒnchner IT Service Provider ConSol und verantwortet hier die Architektur, Konzeption, Implementierung und den Betrieb sĂ€mtlicher IT-Infrastruktur – im Server-Bereich von dedizierten Einzel-Rechnern mit speziellen Aufgaben (z.B. Reporting-Server) bis hin zum firmenweiten VMware-Cluster mit etlichen TB RAM und Datenhaltung in einem mehrfach redundanten, getierten SAN. In seiner beruflichen Laufbahn hat Elbel in den vergangenen 25 Jahren die Entwicklung von Server-Infrastrukturen und den zugehörigen Speichersystemen – von waschmaschinengroßen Acht-Zoll-HDDs mit wenigen hundert MB KapazitĂ€t bis hin zu aktuell direkt ĂŒber PCI-Express angebundenen Hochleistungs-SSDs – erlebt und aktiv als System-Administrator und -Architekt  auf den unterschiedlichsten Betriebssystemen begleitet.

Leistungsstarke Samsung-SSDs fĂŒr unterschiedliche Einsatzgebiete finden Sie bei CompuRAM.
FĂŒr den Einsatz in Servern empfiehlen sich diese Samsung SSD.



10 Kommentare zu “SSD im Server-Betrieb

  1. A. Mueller

    Guten Tag,
    auch eine PS863 und PM863 haben die TRIM Funktion. FĂŒhrt das auf Dauer nicht zu Problemen wenn der Controller (Bspw. LSI 9361) die Funktion nicht unterstĂŒtzt? Macht es da einen Unterschied ob es eine PS863 oder 850 pro ist?

    danke
    A.Mueller

  2. Sebastian Engler

    Hallo in die kompetente SSD-Runde 🙂

    Ich hĂ€tte diesbezĂŒglich einmal eine Nachfrage. Wir haben den Bedarf unserem Server etwas mehr „Geschwindigkeit“ zu verleihen.
    Folgender Aufbau: HP ProLiant ML350e Gen8, 64 GB RAM, vmWare vSphere (ESX) 5 mit a) SBS 2011 (Exchange+SQL Server) und b) Server 2008R2 (Terminal Server). Über Sinn und Unsinn der Dienste des SBS soll an dieser Stelle einmal nicht eingegangen werden.

    Derzeit laufen beide WIN-Server auf einem RAID 10. Der Plan ist den SBS aufgrund der Datenbankzugriffe auf ein SSD-RAID auszulagern, der 2008R2 verbleibt auf dem klassischen RAID 10. Diese hĂ€ngen dann an einem dafĂŒr eingebauten HP P420 RAID Controller. Und hier nun die Fragen:

    – macht hier ein RAID 10 ĂŒberhaupt Sinn (Controller-Durchsatz seitig)?
    – ist mit den SSDs ein RAID5+ Spare im klassischen Sinne möglich?
    – wie sieht es mit der sonst so wichtigen TRIM-FunktionalitĂ€t aus? Nach unserem Kenntnisstand unterstĂŒttz das weder der Controller noch vMWare.

    FĂŒr Antworten bin ich sehr dankbar.

  3. Dieter Hoffmann

    Wir wollen einen Raid 10 Verbund mit 4 SAS Platten im laufenden Betrieb durch SSD ersetzen.
    Normalerweise wĂŒrden wir hergehen und die Platten einfach eine nach der anderen tauschen, das Raid regenerieren lassen, die nĂ€chste tauschen… usw.
    Hat das schon mal jemand versucht?

    1. Robert

      …Wir wollen einen Raid 10 Verbund mit 4 SAS Platten im laufenden Betrieb durch SSD ersetzen.
      Normalerweise wĂŒrden wir hergehen und die Platten einfach eine nach der anderen tauschen, das Raid regenerieren lassen, die nĂ€chste tauschen
 usw.
      Hat das schon mal jemand versucht?…

      Hallo Herr Hoffmann, lassen Sie das lieber!
      Ich habe das Gleiche auf unserem produktiven Dell PE2900III Server versucht und klĂ€glich gescheitert. Soll ein W2K8R2 Server mit MSSQL + MySQL + Terminal Server von 3 x SAS 15K 149GB auf 3 x SSD 240 GB umgezogen werden. Ich habe zuerst die Spare-HD deaktiviert und dann die HDÂŽs eine nach der anderen ersetzt. 2 Mal ist das gut gegangen, bei der letzten SSD ist leider der ganze Raidverbund geplatzt. 🙁
      Habe dann (es war die Nacht von So auf Mo und ich war völlig mit den Nerven fertig) den Raidverbund auf den alten Zustand konfiguriert und von der Image-Datei den ganzen Server wiederhergestellt. Habe spĂ€ter 5 x SSD 480GB gekauft. 2 x RAID 1 (1 x fĂŒr Windows und 1 x fĂŒr Datenpartition) + Spare-SSD erstellt und mit Hilfe des Acronis Echo Server Backup den ganzen Server wiederhergestellt. SQL lĂ€uft merklich schneller, mit MySQL bin ich ein wenig enttĂ€uscht. Hier wir aber noch geschraubt. Summa summarum bin zufrieden. Der alte Server fĂŒhlt sich wie 3 Generationen frischer.
      Ich hoffe, ich konnte helfen.
      MfG
      Robert U.

      1. Dieter Hoffmann

        Hallo Robert,
        vielen Dank fĂŒr den ausfĂŒhrlichen Hinweis. Werde ich dementsprechend berĂŒcksichtigen.

      2. Dieter Hoffmann

        Hier jetzt ein real durchgefĂŒhrtes Scenario.
        Der ca. 6 Jahre alte Primergy TX 200 S5 „sonderte“ nun seine SAS HDDs jetzt so nach und nach aus. Die ursprĂŒnglichen Platten sind nur noch mit langer Lieferzeit zu bekommen.
        Wir haben uns dann dazu entschieden die Maschine komplett auf Samsung SM843T umzustellen.
        Das alles hat Dank der Guten UnterstĂŒtzung im Vorfeld durch Herrn Bauer und einen Fujitsu Techniker alles recht problemlos funktioniert.
        Im Prinzip ist das alles recht simpel, wenn man erst einmal die Angst vor dem Neuland verloren hat.
        1. Komplettes Imgage der Maschine mit Acronis B&R Server erstellt
        2. Alte SAS Platten raus, neue Samsung SM843T Platten in die Hotplug-Rahmen geschraubt
        3. Die alte RAID Konfig im Controller BIOS gelöscht und eine neue angelegt (bißchen Gefrickel, aber geht)
        4. Image zurĂŒckgespielt und Server wieder gestartet
        Maschine lĂ€uft einwandfrei mit einem RAID1 (2 Platten) fĂŒrs OS und einem RAID10 (4 Platten) fĂŒr die Datenbank jetzt wieder seit rund 10 Tagen. Die 7te SSD ist als GlobalHotspare ganz zum Schluß noch hinzugefĂŒgt worden.

        Vielleicht hilft das anderen bei der Entscheidung zur Server Umstellung auf SSD.

  4. Michael Elbel

    Kleiner Nachtrag:
    In jedem Fall ist es wichtig, explizit fĂŒr den Server-Betrieb ausgelegte SSDs zu verwenden, auch wenn die teurer sind als die Consumer-Versionen. Bei denen passiert es nĂ€mlich schon mal, dass die SSD ein oder zwei Sekunden braucht, um auf eine Anfrage zu reagieren, weil sie gerade mit internen Organisations-Aufgaben beschĂ€ftigt sind. Ein Raid-Controller wird sie dann postwendend wegen Timeout aus dem Raid-Verbund werfen. Außerdem kann in diesen FĂ€llen TRIM nicht verwendet werden. Server-SSDs sind so konzipiert, dass sie problemlos im RAID-Verbund arbeiten.

  5. Friedemann Sachse

    Sie schreiben, dass es keine SAS-SSD gÀbe, das ist definitiv falsch.

    Schauen SIe z.B. mal unter

    Sicher etwas teuerer als die SATA-Varianten, aber es gibt sie!

    1. Nadine

      Hallo Herr Sachse,
      vielen Dank fĂŒr Ihre aufmerksame LektĂŒre und Ihren Hinweis. Sie haben vollkommen Recht. Wir haben den entsprechenden Passus aus unserem Beitrag entfernt.
      Freundliche GrĂŒĂŸe, Nadine Hoffmann

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert