Fotolia

So verbessern Sie die Leistung Ihrer Analyse in der Storage-Infrastruktur

Analytische Workloads benötigen zugeschnittene Storage-Lösungen. Wir zeigen Ihnen, wie Sie die Analyseanforderungen am besten verwirklichen.

Analyse wird als Hilfsmittel für das Kerngeschäft immer wichtiger. Deshalb ist es wichtig, den Einfluss von Analyseanwendungen auf die Storage-Systeme zu verstehen.

Es gibt verschiedene Varianten analytischer Anwendungen, beispielsweise vorausschauende Analyse, In-Database-Analyse, Big Data Analyse, Webanalyse, semantische Analyse und so weiter. Allerdings haben die Workloads zur Analyse einige Gemeinsamkeiten, die sich darauf auswirken, wie Storage, auf die diese Anwendungen zugreift, gestaltet und bereitgestellt wird.

Statt kurzer Phasen hoher Aktivität mit Antwortzeiten im Millisekundenbereich wie bei traditionellen Aufgaben entstehen durch analytische Anwendungen weniger, aber dafür komplexere Storage-Anfragen, die große Datenmengen betreffen.

Der In- und Output (I/O) für analytische Anwendungen kann unvorhersehbar verlaufen und ebenfalls große Datenmengen betreffen, die kurzfristig zwischengespeichert werden müssen. Es ist nicht unüblich, dass Tabellen Tausende Spalten haben.

Im Allgemeinen erzeugen analytische Anwendungen eine große Ein-/Ausgabebelastung und weniger Schreibzugriffe, was gut zu Flash-Storage passt. Denn es kann schneller gelesen als beschrieben werden und verschleißt langsamer, wenn Lesevorgänge überwiegen.

Geht es bei den Analysen allerdings um viele kleine oder unterschiedlich große Datenstücke, bringen Solid-State-Arrays mit fester Blockgröße weniger Leistung als solche mit variabler Blockgröße.

Analytische Anwendungen erzeugen je nach ihrer Aufgabe und Technologie unterschiedliche Workload-Typen. Beispiele sind Big-Data-Umgebungen wie Hadoop und Spark, Data Warehouses mit Query-intensiven Workloads, die meistens auf strukturierte Daten zugreifen, Ingestions-Technologien, die Rohdaten speichern und sie für Stapelverarbeitung oder als Datenstrom bereitstellen, NoSQL für die Speicherung von Daten anders als in der traditionellen Tabellenform und Suchtechnologien, wie sie von Firmen für die Analyse von Logfiles wie Splunk entwickelt und angeboten werden.

Organisationen setzen heute meist mehrere unterschiedliche Analysetechnologien ein. Einige kleine, datenfokussierte Systeme können durchaus mit einer SQL-Datenbank auf einer Standardplattform arbeiten. Informationszentrierte Analysen benötigen Hadoop-ähnliche Systeme mit Ein-/Ausgabeleistungen in anderen Dimensionen.

NoSQL dagegen stellt vollkommen andere I/O-Anforderungen. Sie lassen sich durch zwei Stichworte beschreiben: synchron und asynchron. Asynchrone Analysen umfassen hauptsächlich drei Schritte: Das Sammeln, Aufzeichnen und Analysieren der Daten.

Beispielsweise werden Daten, die an den Kassen des Einzelhandels während des Tages gesammelt wurden, über Nacht analysiert. Ein anderes asynchrones Szenario ist die Off-Site-Webanalyse. Sie wird verwendet, um die Effizienz und den Traffic von Websites zu messen.

Solche Lösungen verwenden traditionelle relationale Datenbank-Management-Systeme (RDBMS), um die Daten in eine strukturierte Form zu bringen. Das dafür verwendete Storage muss genügend leistungsfähig und skalierbar sein und ausreichend Kapazität bieten.

Die Ein-/Ausgabecharakteristiken können erheblich variieren. Es kann sich um einige wenige sehr große Dateien handeln (wie bei der Genomanalyse) oder um eine sehr große Mengen kleiner Dateien oder Datenblocks (wie beim Data Warehousing- oder Kundendaten-Applikationen).

Synchrone Analyse geschieht in Echtzeit. Ein typisches Szenario: Eine Social-Media-Site verfolgt die Anwenderaktivitäten und liefert Werbung und andere nach den Präferenzen des Anwenders selektierte Inhalte, während er oder sie sich durch das Angebot bewegt. Das bezeichnet man auch als On-Site-Webanalyse. Solche Analysen laufen meist auf NoSQL-Datenbanken, die aus Geschwindigkeitsgründen von Flash-Storage unterstützt werden und vielleicht mit langsameren, großen Speicherkapazitäten im Hintergrund verbunden ist.

Storage-Architekturen für Analyse

Analysewerkzeuge lesen dieselben Daten oft wieder und wieder, um Profile aufzubauen. Daher laufen analytische Anfragen per se parallel ab und reagieren empfindlich auf Verzögerungen, sobald Datenströme zusammengeführt werden. Deshalb verteilen viele Storage-Architekturen Daten über mehrere physische Knoten und Platten. Hadoop ist ein klassisches Beispiel für diese Herangehensweise.

Üblicherweise schafft man es, große Datenmengen mit geringstmöglicher Verzögerung zu lesen, indem Flash als Cache vor Festplatten implementiert wird. Ist allerdings die Architektur nicht individuell austariert, kann dieses Design die Verzögerung eher erhöhen als verringern. Denn befinden sich Daten nicht im Cache, wird die Anfrage noch einmal ausgeführt, was unter Umständen mehr Zeit verbraucht, als direkt auf langsamere Speichermedien zuzugreifen.

Aus diesem Grund müssen Cache und Storage unbedingt aneinander angepasst sein. Es gilt also, das Ein-/Ausgabeprofil der entsprechenden analytischen Anwendung genau zu verstehen.

Dafür braucht man Zugriffe auf deren detaillierte Metrik bezüglich Leistung und Ressourceneinsatz. Auf dieses Weise können die Auswirkungen von Veränderungen besser gemessen,  eingeschätzt und in Relation zu den Kosten zusätzlicher Ressourcen gesetzt werden.

Daher ist angesichts der Ein-/Ausgabeintensität analytischer Workloads eine sehr geringe Verzögerung entscheidend für die Leistung analytischer Anwendungen.

Ein Blick in die Zukunft

Mit der weitergehenden Virtualisierung analytischer Workloads und Storage-Systeme wird es immer schwerer, analytische Workloads von anderen Aktivitäten virtueller Maschinen im Hintergrund zu unterscheiden.

Eine mögliche Gegenmaßnahme besteht darin, wenigstens die bekannten zeitweisen Aktivitätsspitzen zu verstehen – etwa einen Report, der meist am letzten Tag des Monats abläuft – und die Systeme automatisch so zu rekonfigurieren, dass solche Aufgaben priorisiert abgewickelt werden.

In dem Maß allerdings, in dem Speicher billiger wird, werden häufiger In-Memory-Analysen genutzt. Damit hört die Storage-Architektur auf, als Engpass zu wirken, außer es handelt sich um sehr große Datensets.

Cisco IT Hadoop Platform und HyperFlex

Der Compute-Block der Cisco IT Hadoop-Plattform besteht aus Ciscos UCS C240 M3 Rackserver, ein Gerät mit 2 Höheneinheiten und 256 GByte RAM sowie 24 TByte lokaler Storage, von denen 22 TByte für das Hadoop Distributed File System (HDFS) zur Verfügung stehen. Das System umfasst vier Racks, in jedem Rack stecken 16 Serverknoten, die 384 TByte Rohkapazität pro Rack unterstützten. Wie meist bei geclusterten Systemen werden Daten und Metadaten, um Hochverfügbarkeit zu garantieren, über die Knoten hinweg repliziert.

Cisco beschreibt seine HyperFlex-Systeme, die ebenfalls auf der UCS-Plattform basieren, als Scale-Out-Lösung mit geringer Verzögerung. Der HX Data Platform Controller verteilt die Daten über die mittels Ethernet angebundenen Flash- und/oder mechanischen Laufwerksknoten des Clusters, der so zu einem verteilten, mehrschichtigen, objektbasierenden Data Store wird. Das System wird nicht als Lösung für große analytische Projekte vermarktet, kleinere Projekte können es aber durchaus nutzen.

Dell EMC Isilon Scale-Out Storage-Lösungen für Hadoop

Dell EMC Isilon ist eine Scale-Out NAS-Plattform, die mehrere Instanzen von Apache Hadoop-Distributionen unterschiedlicher Hersteller unterstützt. Sie integriert HDFS, was Analysen im System ermöglicht und die getrennte Hadoop-Infrastruktur einspart.

Mitgeliefert wird eine Deduplizierungsfunktion. Das System skaliert von 18 TByte bis auf mehr als 20 PByte in einem Cluster. Zum Lieferumfang gehört auch das hochverfügbare Betriebssystem OneFS, das den NameNode als nicht redundanten Schwachpunkt in der Hadoop/HDFS-Speicherschicht beseitigt.

IBM DS888F

IBM bietet mit der Power8-basierenden IBM DS888F ein Gerät an, das laut Hersteller „permanent Antwortzeiten im Mikrosekundenbereich und Verfügbarkeit ohne Kompromisse“ bei Integration mit z-Mainframes bietet.

Laut IBM schafft die 888F bis zu 2,5 Millionen I/O-Operationen pro Sekunde (IOPS) bei Workloads mit zufälligen I/O-Zugriffen. In das Chassis mit Fibre-Channel-Anbindung passen Flash-Karten von 400 GByte bis 1,23 PByte Rohkapazität in einem Rack mit vier Höheneinheiten. Es unterstützt die RAID-Level 5,6 und 10.

Hitachi Content Platform (HCP)

HCP ist eine Object-Storage-Plattform mit mehreren Knoten, die Funktionen wie Metadaten-Management und Datenverteilung über alle Knoten des Systems hinweg bereitstellt. Das setzt sich aus diversen Zugangsknoten (HCP G) und HCP-S-Knoten zusammen. Dabei befinden sich die HCP-G-Knoten über Ethernet Angebunden vor dem HCP-S-Cluster.

Die G-Knoten übernehmen Service- und Management-Funktionen. Sie virtualisieren die Kapazität der S-Knoten im Hintergrund und stellen sie zur Verfügung. Sie können auf Block-, File-, Objekt- oder Cloud-Storage zugreifen. Das System skaliert durch das Hinzufügen von Knoten. Hitachi Data Systems behauptet, dass seine Kapazität unbegrenzt ist.

TeraData Appliance for Hadoop und Integrated Big Data Platform

TeraData bietet eine Appliance for Hadoop an. Sie ist entweder mit zwei 12-Core-2,5-GHz-Xeon-Prozessoren oder mit zwei 2,6-GHz-Xeon-Prozessoren mit acht Kernen und mit konfigurierbaren Speicheroptionen zwischen 128 GByte und 512 GByte verfügbar. Jeder der mit Infiniband angebundenen Knoten enthält 12 Laufwerke mit 4 oder 8 TByte Kapazität sowie zwischen 256 und 768 GByte RAM. Darauf läuft eine optimierte Hadoop-Version von Hortonworks und Cloudera.

Außerdem bietet Teradata die Integrated Big Data Platform als Teil seiner auf spezifische Workloads zugeschnittenen Systemserie an. Das System umfasst maximal 2048 aktive Knoten. Dadurch lässt es sich mit 3 oder 4-TByte-Spindeln, 168 pro Schrank, bis auf 341 PByte skalieren. Dazu kommen bis zu 512 GByte RAM pro Knoten. Auf allen läuft die Teradata-Datenbank, zu der eine Analyse-Engine gehört. Sie kann auf Daten anderer Systeme einschließlich der Hadoop-Appliance zugreifen.

Folgen Sie SearchStorage.de auch auf Twitter, Google+, Xing und Facebook!

Nächste Schritte

Fünf Wege zur Vermeidung üblicher Fallstricke in Big-Data-Analytics-Projekte

Analytische Datenbanken: Merkmale, Funktionen und Einsatzszenarien

Big Data Analyse und Internet der Dinge (IoT) machen Storage klüger

Big Data und das Internet der Dinge verändern Storage-Anforderungen und -Analyse

Artikel wurde zuletzt im Juni 2017 aktualisiert

Pro+

Premium-Inhalte

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

Erfahren Sie mehr über Enterprise-Storage: Planung und Management

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