Drei Architektur-Optionen für den Einsatz von SSDs

SSDs kommen im Array, im Server und in Form von SSD-Appliances zum Einsatz. Daraus ergeben sich unterschiedliche Latenz- und Performance-Fragen.

Was Sie in diesem Artikel erfahren können: Viele Nutzer sind von den unterschiedlichen verfügbaren Optionen für den Einsatz von Solid-State Drives (SSDs) verwirrt. Hauptsächlich gibt es drei Möglichkeiten dafür: im Array, im Server und in Form von SSD-Appliances. Wir beschreiben die Vorteile und Nachteile jeder dieser Methoden einschließlich Latenz- und Performance-Fragen.

Nur selten ergeben sich Gelegenheiten, gleichzeitig für mehr Performance und niedrigere Kosten zu sorgen. SSD allerdings ist eine interessante Technologie, mit der sich genau das erreichen lässt. Fast jeder größere Storage-Hersteller und viele Start-ups bieten eine breite Palette an SSD-Produkten an. Dabei lassen sich Solid-State Drives auf drei unterschiedliche Weisen einsetzen: als Array-basierte SSDs vor dem SAN, als Server-basierte SSDs dahinter oder als SSD-Appliances auf beiden Seiten. Welche Option die beste ist, hängt davon ab, welches Problem damit gelöst werden soll und um welche Anwendungsfälle es geht. Hintergrundwissen kann hier dabei helfen, technisch übertriebene und damit auch übertrieben teure Lösungen zu vermeiden.

Die einfachste Variante sind Array-basierte SSDs – aufgrund der Verwirrung oder vielleicht auch, weil sie keine anderen kennen, greifen viele IT-Manager zu ihr. Tatsächlich sind Array-basierte SSDs in vielen Fällen die beste Option. Aber wenn Sie Server-basierte SSDs und SSD-Appliances als Alternativen nicht zumindest prüfen, übersehen Sie vielleicht die Lösung, die für Ihre Umgebung optimal wäre.

Den Schlüssel-Aspekt bei der Entscheidung über die richtige SSD-Architektur bildet Latenz und in diesem Zusammenhang die Frage, wo sie das größte Hindernis für gute Anwendungsperformance darstellt. Unabhängig von der gewählten Technologie erfolgt der Zugriff auf Daten bei SSD mit der Geschwindigkeit von Arbeitsspeicher. Der I/O-Durchsatz richtet sich nach dem konkreten Gerät – dies allerdings in Abhängigkeit von dessen Design, nicht von der Platzierung im SAN. Die Latenz von SSDs wird in Nanosekunden gemessen, während sie bei Netzwerken und Festplatten (Hard Disk Drives – HDDs) eher im Millisekunden-Bereich liegt. Irgendwo müssen Sie in jeder SAN-Architektur mit der Latenz von Netzwerk und/oder HDDs zurechtkommen, also ist es für die Optimierung wichtig, wo die SSDs untergebracht sind.

Es folgt ein Überblick über die drei Möglichkeiten für den SSD-Einsatz.

Array-basierte SSDs

Array-basierte SSDs werden als eigene logische Stufe im Array implementiert und hier als Tier 0 bezeichnet. Weil sie innerhalb des Arrays liegen, werden sie direkt an das Storage-Backplane angeschlossen. Die Bewegung von Daten zwischen den Stufen wird von der HDD-Latenz, dem Durchsatz des Laufwerks und der Backplane-Latenz beeinflusst, wobei der wichtigste Faktor der I/O-Durchsatz der HDD ist. Zu diesem wiederum tragen mehrere Einzelaspekte bei, aber im vorliegenden Rahmen nehmen wir das nicht zu genau und sprechen einfach von HDD-Latenz. Das Backplane selbst dürfte bei den meisten Arrays in Unternehmen keine Begrenzung für die Gesamt-Latenz bei Daten-Zugriffen darstellen. Denn die Hersteller tun hier alles dafür, zumindest die Geschwindigkeit von HDDs zu erreichen.

Software für automatisiertes Storage-Tiering (AST) arbeitet mit ausgeklügelten Algorithmen, um festzustellen, welche Daten aktiv sind, und verschiebt sie dann von anderen Stufen auf die SSD. Dabei kommt die gesamte Latenz von HDD zum Tragen, dies aber nur einmalig – anschließend können die häufig benötigten Daten mit Nanosekunden-Latenz von SSD gelesen werden.

Allerdings: Die Latenz für das Einlesen von Medien wird in einer solchen Hinter-dem-SAN-Architektur zwar auf Nanosekunden verringert, doch die Millisekunden an Latenz über das gesamte SAN oder Wide-Area Network (WAN) lassen sich dadurch nicht umgehen. Deren genaue Höhe hängt von mehreren Faktoren ab, stellt aber fast immer das größte Hemmnis für mehr Durchsatz bei Lese-Anfragen dar. Grob gesagt lässt sich mit Array-basierten SSDs nur die Hälfte der Millisekunden-Latenz beseitigen.

Der vielleicht beste Anwendungsfall für Array-basierte SSDs ist eine allgemeine Performance-Steigerung. Weil AST-Software über Daten-Bewegungen hauptsächlich anhand von I/O-Aktivität entscheidet, ist sie in ihrer einfachen Form nicht anwendungsspezifisch. Dadurch dürfte sie in einem leicht zu implementierenden und verwaltenden Paket erhebliche Verbesserungen beim Zugriff auf Daten insgesamt bringen.

Server-basierte SSDs

Server-basierte SSDs erfreuen sich zunehmender Beliebtheit. Bei derartigen Implementationen handelt es sich meist um PCI Express (PCIe)-Karten, die im Server eingesetzt  und sowohl von Server-Hersteller als auch von einigen Storage-Herstellern angeboten werden. Im Prinzip bilden die SSDs hier einen großvolumigen Cache, auf den die CPU direkt zugreifen kann, der aber wie Storage provisioniert und verwaltet wird.

Die Verfahren für die Verlagerung von Daten auf Server-basierte SSDs unterscheiden sich nicht sehr von denen bei anderen SSD-Verwendungen: Auch hier können neben festen Zuweisungen Zugriffsmuster die Grundlage bilden. Wenn die Daten von SAN-Geräten kommen, wird die anfängliche Lese-Zeit von SAN- wie HDD-Latenz bestimmt, aber auch hier ist das nur ein Einmal-Effekt. Anschließend werden die Daten ohne SAN- oder Netzwerk-Latenz direkt vom Server bezogen. Das Millisekunden-Problem fällt also komplett weg.

Der beste Anwendungsfall für die Verwendung von SSD vor dem SAN sind hochgradig statische Daten, auf die langfristig häufig zugegriffen wird, wie etwa Datenbank-Indizes oder ganze Datenbanken. Bei dieser Art von Deployment lässt sich die Latenz beim Daten-Zugriff um bis zu 90 Prozent reduzieren. Einige AST-Produkte können zwar Daten von Arrays zu PCIe-SSDs bewegen, doch häufiger Daten-Austausch zwischen den Stufen würde wieder Latenzen im Millisekunden-Bereich bringen. In solchen Fällen kann eine Array- oder Appliance-Lösung besser sein.

SSD-Appliances

Bei SSD-Appliances handelt es sich um SSD-Arrays in eigenen Gehäusen. Ihr Hauptvorteil besteht darin, dass sie an beliebiger Stelle zwischen Host und Storage-Array platziert werden können, je nachdem, wo die Latenz das größte Problem darstellt. Appliances nah an den Servern lassen sich für Boot-Devices im Netzwerk einsetzen – eine gute Lösung für das Problem von „Boot Storms“, also von Verzögerungen bei der gleichzeitigen Anmeldung vieler Nutzer. Auch für das Bereithalten von Dateien, insbesondere mit Medien, in Cluster- oder virtualisierten Umgebungen können SSD-Appliances ideal sein. Deren Platzierung nah am Server eliminiert den größten Teil der Netzwerk-Latenz – etwas davon bleibt erhalten, doch aufgrund der physischen Nähe wahrscheinlich nur wenig. Wenn Daten dagegen von einem konventionellen Array bezogen werden, tritt wieder die Millisekunden-Latenz durch SAN und HDD auf.

Der zweite Anwendungsfall für SSD-Appliances ist auf der anderen Seite des SAN, also nah an den konventionellen Arrays. In dieser Anordnung können die Appliances als aggregierter SSD-Tier für virtualisiertes Storage eingesetzt werden. Statt in jedes Array SSD einzubauen, steht die SSD-Appliance hier als Stufe 0 für alle Arrays zur Verfügung. Dadurch kann sich die Performance von virtualisiertem Storage verbessern, bei dem Logical Unit Numbers (LUNs) sich über mehrere getrennte Arrays erstrecken und Daten dynamisch zwischen Systemen verschoben werden. Auf diese Weise werden Aktivitäten für Storage-Management am Backend den Zugriff auf Daten in der Stufe 0 nicht beeinträchtigen.

Den dritten Anwendungsfall für SSD-Appliances bildet der Einsatz auf der Rechenzentren-Seite einer hybriden Cloud-Installation. Die Latenz beim Zugriff auf Daten in einem Cloud-Rechenzentrum kann erheblich sein, abhängig von WAN-Entfernung und HDD-Charakteristik. Oft kommen in Clouds zur Minimierung der Kosten HDDs mit hoher Kapazität und hoher Latenz zum Einsatz. Durch die Verwendung einer SSD-Appliance im Rechenzentrum bleiben häufig benötigte Daten näher beim Kunden, mit deutlich weniger Latenz als über die gesamte Strecke zum Cloud-Provider. Beim Zugriff auf Daten aus dem Cloud-Array bleibt die Latenz natürlich erhalten, doch insgesamt ergibt sich eine deutliche Verbesserung.

Viertens lassen sich Appliances dafür verwenden, den aggregierten Durchsatz von älteren Arrays zu erhöhen. Diese mit neuen SSDs aufzurüsten, kann übertrieben kostspielig sein. Indem man stattdessen eine SSD-Appliance vor das Array stellt, lässt sich die Geschwindigkeit des Daten-Zugriffs deutlich erhöhen, und bestehende Technik kann länger in Gebrauch bleiben. Die Kosten dabei können deutlich geringer sein als bei einem Komplett-Upgrade.

Insgesamt gibt die breite Palette an SSD-Optionen auf dem Markt Storage-Architekten die Möglichkeit, die I/O-Performance fein auf die Anforderungen von Anwendungen abzustimmen, ohne dafür technisch übertriebenen Aufwand zu treiben. Die genaue Art des Deployments hängt auch von den eingesetzten Produkten ab, doch die meisten Anbieter helfen hier mit Richtlinien zu Best Practices. Wenn sie mit einer Analyse der Latenz-Folgen beginnen, schaffen Storage-Architekten die Grundlage dafür, SSDs genau dort einzusetzen, wo sie am stärksten gebraucht werden.

ÜBER DEN AUTOR: Phil Goodwin ist Storage-Berater und freiberuflicher Autor.

Artikel wurde zuletzt im Oktober 2011 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Solid-State-Speicher

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close