München, Starnberg, 5. Sept. 2016 - Scale-Out anstelle Scale-Up; ein Beitrag zur Architektur von NetApp SolidFire im Zusammenhang mit OpenStack Cinder und Swift...
Zum Hintergrund: SolidFire verfügt mit seiner Webscale scale-out Flash-Architektur Softwareseitig (Hochleistungs-Filesystem O/S) über wichtige zentrale Technologieoptionen in Bezug auf skalierbare Leistung, Volume-level Quality of Service Control (QoS), Performance und Verfügbarkeit. Mit Version v8 des Betriebssystem wurde bereits im letzten Jahr eine sog. „selbstheilende“ Hochverfügbarkeits-Architektur eingeführt; sie erlaubt die Durchführung von Upgrades ohne Unterbrechungen des Betriebs und ist deshalb für Hosting Unternehmen und große Rechenzentren mit sehr anspruchsvollen SLAs interessant (hier der Link auf unseren Beitrag zur V.8). Im Detail liefern die Software-Erweiterungen folgende Vorteile:
- Synchrone Replikation zum Datenschutz im Desaster-Fall
- Snapshot-Replikation repliziert Snapshots zur Sicherstellung der Rollback-Flexibilität auf einen zweiten Ort
- Scheduler/Retention Manager vereinfacht die Terminierung und Automatisierung von Snapshots und Rollback Points sowie die Festlegung der Speicherdauer
- Erweitertes VLAN Tagging mit Unterstützung von bis zu 256 sicheren, logischen Storage-Teilnetzen auf einer Storage-Plattform
- LDAP-Authentifizierung mittels zentralisierter User-Account-Verwaltung
Im folgenden Beitrag von NetApp Solidfire's Mara McMahon (1) sollen einige wesentlichen Vorteile von Scale-Out Flash Architekturen gegenüber klassischen Scale-Up-Systemumgebungen dargestellt werden, wie die Lösung von Noisy-Neighbor"-Problemen sowie eine höhere System- und damit Anwendungsverfügbarkeit.
Zum Beitrag: „Die Planung der Storage-Kapazität im Rechenzentrum ist eine komplizierte Sache, zumal wenn Service-Provider auf die falsche Architektur setzen. In einem Scale-Out-Modell lassen sich dagegen Kapazitätserweiterungen bei garantierter Performance flexibel und ohne Betriebsunterbrechungen vornehmen.
Die richtige Planung der Storage-Kapazität ist für alle Cloud- und Hosting-Service-Provider ein kritisches Thema, denn Planungsfehler können erhebliche Auswirkungen auf die Profitabilität eines Anbieters haben. Um einerseits den Anforderungen performancekritischer Workloads gerecht zu werden und andererseits eine breite Palette von Business-Anwendungen in Multi-Tenant- (mandantenfähigen) Umgebungen unterstützen zu können, setzen Service-Provider heute verstärkt auf All-Flash-Arrays. Aber bei den meisten Lösungen, die auf dem entsprechenden Markt verfügbar sind, stellt die Skalierung der Kapazität ein Risiko dar. Da die meisten All-Flash-Speicherlösungen auf einem Scale-up-Modell basieren, müssen die Anwender mit hohen Kosten und Ausfallzeiten aufgrund von Datenmigration und den damit verbunden Wartungsarbeiten rechnen.
Generell ist es so, dass wegen der hohen Performance von All-Flash-Arrays die meisten Systeme viel früher an Kapazitäts- als an Leistungsgrenzen stoßen. In einem Scale-Up-Modell erhält man mehr Kapazität durch das Hinzufügen neuer Speichersysteme, das heißt durch neue Controller plus Laufwerke. Damit sind nicht nur erhebliche Kosten verbunden; in der Regel heißt das auch, dass Daten migriert werden müssen, verbunden mit dem Risiko von Datenverlusten. Und es entstehen regelmäßig "Storage-Inseln" – separate, siloartige Systeme mit einer bestimmten, nicht austauschbaren Technologie –, die einen hohen Verwaltungsaufwand mit sich bringen.
- Da in einem Scale-Up-Modell Performance und Kapazität voneinander abhängig sind, wird bei zusätzlichen Kapazitäten die Controller-Leistung des Systems auf mehr Daten und Anwendungen verteilt. Dadurch werden Scale-Up-Designs anfällig für das "Noisy-Neighbor"-Problem: eine kleine Zahl Performance-hungriger Anwendungen monopolisiert die Controller-Ressourcen und beeinträchtigt damit die Leistung aller anderen Anwendungen innerhalb des Arrays.
Dagegen erlaubt es eine Scale-Out-Architektur, die Kapazität nach oben oder unten zu skalieren, indem einfach Knoten hinzugefügt oder entfernt werden. Ein gut organisiertes System benötigt dabei keine Datenmigration und auch keinen zusätzlichen Verwaltungsaufwand. Um das Noisy-Neighbor-Problem aus der Welt zu schaffen, stellt ein Scale-Out-Design seine Kapazitäten unabhängig von der Performance zur Verfügung; Quality of Service (QoS) verschafft jeder Anwendung eine garantierte Performance. Diese verschlechtert sich daher nicht, wenn die Kapazitäten erweitert werden; der Service-Provider muss also nicht – ungenutzte – Kapazitäten hinzufügen, um damit mögliche Performance-Probleme schon im Vorfeld abzufangen.
- Scale-out-Designs, die den Anforderungen von Service-Providern genügen, müssen deshalb in der Lage sein, für die Leistung ein Minimum-, Maximum- und Burst-Level zu definieren, wobei das Minimum-Level am wichtigsten ist, da es für jede Anwendung eine feste Basis bestimmt, also eine bestimmte garantierte Leistung. Für Service-Provider, die bei Performance-Problemen viel Zeit mit der Fehlersuche verbringen, ist ein Scale-Out-Design mit QoS unerlässlich, denn nur so können sie ihren Aufwand reduzieren und die Zufriedenheit ihrer Kunden verbessern.
Upgrades am Ende der Tage
Ein anderes Risiko für Service-Provider stellen End-of-Life-Upgrades der Storage-Lösung dar. In einer Scale-up-Architektur sind die üblichen, drei bis fünf Jahre dauernden Service-Zyklen der Fluch der Administratoren. Planung, Prüfung und Realisierung erstrecken sich oft über Monate, darüber hinaus sind teure professionelle Services nötig und schließlich werden die Kunden mit Downtime konfrontiert.
Mit einer Scale-Out-Architektur, die es erlaubt, verschiedene Hardware-Generationen zu mischen, werden Hardware-Upgrades zu einem eher trivialen Prozess. Service-Provider können einfach Knoten zum Cluster hinzufügen oder entfernen – ohne Ausfallzeiten, ohne Rebalancing, ohne Restriping, ohne Re-Allokation von Volumes. Außerdem sind Service Provider damit in der Lage, die Kapazität und Knoten zwischen ihren Rechenzentren auszutauschen. Wenn ein Datenzentrum über ungenutzte Kapazitäten verfügt, während ein anderes Rechenzentrum mehr benötigt, kann ein Knoten ohne Betriebsunterbrechung von einem zum anderen bewegt werden.
Fazit
Ohne die richtige Technologie stellt das Upgrading von Kapazität oder Performance ein echtes Problem dar: Wenn ein Provider sich bei der Kapazitätsplanung nicht absolut sicher ist, ist er schon zum Upgrade gezwungen. Das bedeutet aber immer auch Betriebsunterbrechungen: Services müssen offline gehen, wofür entsprechende Wartungsintervalle einzuplanen sind. Nur mit einem Scale-Out-Ansatz in einer robusten und einfach zu verwaltenden Architektur können Service-Provider zuverlässig planen und ihre Kapazität ohne Risiko skalieren.“
(1) Mara McMahon ist Segment Director bei NetApp SolidFire
Abb. 1: Block Storage mit Cinder, Object Storage mit Swift