{"id":35801,"date":"2019-10-31T22:06:24","date_gmt":"2019-10-31T19:06:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-vybrat-shd-ne-vystreliv-sebe-v-nogu\/"},"modified":"2019-10-31T22:06:24","modified_gmt":"2019-10-31T19:06:24","slug":"kak-vybrat-shd-ne-vystreliv-sebe-v-nogu","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kak-vybrat-shd-ne-vystreliv-sebe-v-nogu","title":{"rendered":"Wie w\u00e4hlt man ein Speicher-Subsystem, ohne sich ins eigene Fleisch zu schneiden?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Einf\u00fchrung<\/h2>\n

\nEs ist Zeit, ein Speicher-Subsystem zu kaufen. Welches soll man nehmen und wem soll man zuh\u00f6ren? Anbieter A erz\u00e4hlt von Anbieter B, und es gibt Integrator C, der das Gegenteil behauptet und Anbieter D empfiehlt. In so einer Situation kann selbst ein erfahrener Architekt f\u00fcr Speichersysteme den \u00dcberblick verlieren, besonders mit all den neuen Anbietern und den angesagten SDS und hyperkonvergenten L\u00f6sungen.<\/p>\n

Und wie kann man das alles verstehen und nicht auf die Nase fallen? Wir (AntonVirtual<\/a><\/noindex> Anton Zhbankov und korp<\/a><\/noindex> Evgeny Elizarov) werden versuchen, dies in verst\u00e4ndlichem Russisch zu erkl\u00e4ren.
\nDer Artikel steht in vielerlei Hinsicht im Zusammenhang und ist praktisch eine Erweiterung des \u201cDesigns eines virtualisierten Rechenzentrums<\/a><\/noindex>\u201d im Hinblick auf die Auswahl von Datenspeichersystemen und einen \u00dcberblick \u00fcber Speichersystemtechnologien. Wir werden einen kurzen \u00dcberblick \u00fcber die allgemeine Theorie geben, empfehlen jedoch auch, sich den genannten Artikel anzusehen.<\/p>\n

Warum<\/h2>\n

\nBeobachtet man h\u00e4ufig die Situation, dass eine neue Person in ein Forum oder einen spezialisierten Chat, wie beispielsweise Storage Discussions, kommt und die Frage stellt: \u201cMir werden zwei Optionen f\u00fcr ein Speicher-Subsystem angeboten \u2014 ABC SuperStorage S600 und XYZ HyperOcean 666v4, was k\u00f6nnen Sie empfehlen?\u201d<\/p>\n

Und schon beginnt das Messen der Besonderheiten unterschiedlichster, furchterregender und unklarer Funktionen, die f\u00fcr einen unvorbereiteten Menschen wie Chinesisch erscheinen.
\n<\/a><\/noindex>
\nDer entscheidende und erste Fragen, die man sich lange vor dem Vergleichen der Spezifikationen in Angeboten stellen sollte, lautet: Warum? Warum braucht man dieses Speichersystem?<\/p>\n

\"Wie
\n
\nDie Antwort wird unerwartet sein und erinnert stark an einen Stil von Tony Robbins \u2013 um Daten zu speichern. Danke, Captain! Dennoch verlieren wir manchmal so sehr in den Details, dass wir vergessen, warum wir das Ganze eigentlich tun.<\/p>\n

Das Ziel eines Speichersystems ist das Speichern und Bereitstellen von Daten mit einer festgelegten Leistung. Mit den Daten beginnen wir.<\/p>\n

Daten<\/h2>\n

<\/p>\n

Datentyp<\/h3>\n

\nWelche Daten planen wir zu speichern? Eine sehr wichtige Frage, die viele Speicherl\u00f6sungen aus der Auswahl ausschlie\u00dfen kann. Zum Beispiel, wenn die Speicherung von Videoaufnahmen und Fotos geplant ist. Systeme, die f\u00fcr den zuf\u00e4lligen Zugriff auf kleine Bl\u00f6cke ausgelegt sind, oder Systeme mit propriet\u00e4ren Funktionen in der Komprimierung\/Deduplizierung k\u00f6nnen sofort ausgeschlossen werden. Diese Systeme k\u00f6nnen hervorragend sein, wir m\u00f6chten nichts Negatives \u00fcber sie sagen. Aber in diesem Fall k\u00f6nnten ihre St\u00e4rken sich als Schw\u00e4chen herausstellen (Video und Fotos lassen sich nicht komprimieren) oder einfach die Kosten des Systems erheblich erh\u00f6hen.<\/p>\n

Umgekehrt werden hervorragende Streaming-Systeme f\u00fcr Multimedia, die Gigabyte pro Sekunde liefern k\u00f6nnen, eine schlechte Wahl sein, wenn die Zielanwendung eine stark belastete transaktionale Datenbank ist.<\/p>\n

Datenvolumen<\/h3>\n

\nWie viele Daten planen wir zu speichern? Die Menge entwickelt sich immer zu Qualit\u00e4t, das sollten wir niemals vergessen, besonders in unserer Zeit des exponentiellen Datenwachstums. Systeme mit Petabyte-Kapazit\u00e4t sind mittlerweile keine Seltenheit mehr, doch je gr\u00f6\u00dfer das Petabyte-Volumen, desto spezialisierter wird das System und desto weniger gewohnte Funktionalit\u00e4ten stehen in Systemen mit kleinerem und mittlerem Volumen zur Verf\u00fcgung. Das liegt einfach daran, dass selbst die Statistiktabellen f\u00fcr den Blockzugriff gr\u00f6\u00dfer werden als der verf\u00fcgbare Arbeitsspeicher auf den Controllern. Ganz zu schweigen von der Kompression \/ Tiering. Angenommen, wir m\u00f6chten den Kompressionsalgorithmus auf einen leistungsst\u00e4rkeren umschalten und 20 Petabyte Daten komprimieren. Wie lange wird das dauern: ein halbes Jahr, ein Jahr?<\/p>\n

Auf der anderen Seite, warum den Aufwand treiben, wenn wir nur 500 GB Daten speichern und verarbeiten m\u00fcssen? Nur 500. Herk\u00f6mmliche SSDs (mit niedrigem DWPD) in diesem Volumen kosten so gut wie nichts. Warum daf\u00fcr eine Fiber Channel-Fabrik bauen und ein externes High-End-Speichersystem kaufen, das so viel kostet wie eine Eisenbr\u00fccke?<\/p>\n

Welcher Anteil der gesamten Datenmenge bilden die Hot-Daten? Wie ungleich verteilt ist die Last bez\u00fcglich der Datenmenge? Hier kann die Technologie des mehrstufigen Speichers oder Flash Cache sehr hilfreich sein, wenn das Volumen der Hot-Daten im Vergleich zur Gesamtheit gering ist. Andernfalls, bei einer gleichm\u00e4\u00dfigen Lastverteilung, die h\u00e4ufig in Streaming-Systemen (z.B. Video\u00fcberwachung, bestimmte Analysesysteme) vorkommt, werden solche Technologien nichts bewirken und lediglich die Kosten \/ Komplexit\u00e4t des Systems erh\u00f6hen.<\/p>\n

IS<\/h3>\n

\nDie Kehrseite der Daten ist das Informationssystem, das diese Daten nutzt. Die IS hat eine Reihe von Anforderungen, die von den Daten abgeleitet werden. Mehr \u00fcber IS erfahren Sie im \"Design eines virtualisierten Rechenzentrums\".<\/p>\n

Anforderungen an Ausfallsicherheit \/ Verf\u00fcgbarkeit<\/h4>\n

Die Anforderungen an die Ausfallsicherheit \/ Verf\u00fcgbarkeit der Daten leiten sich von dem sie verwendenden IS ab und werden in drei Zahlen ausgedr\u00fcckt \u2014 RPO<\/b>, RTO<\/b>, Verf\u00fcgbarkeit<\/b>.<\/p>\n

Verf\u00fcgbarkeit <\/b> \u2014 der Zeitraum, in dem die Daten f\u00fcr die Nutzung verf\u00fcgbar sind. Dies wird gew\u00f6hnlich in der Anzahl der Neunen ausgedr\u00fcckt. Zum Beispiel bedeutet zwei Neunen pro Jahr, dass die Verf\u00fcgbarkeit 99 % betr\u00e4gt, was 95 Stunden Ausfallzeit im Jahr entspricht. Drei Neunen bedeuten 9,5 Stunden Ausfallzeit im Jahr.<\/p>\n

RPO \/ RTO \u2014 diese Kennzahlen beziehen sich nicht auf die Summe, sondern pro Vorfall (St\u00f6rung), im Gegensatz zur Verf\u00fcgbarkeit.<\/p>\n

RPO <\/b> \u2014 das Volumen der Daten, die bei einer St\u00f6rung verloren gehen (in Stunden). Wenn ein Backup einmal t\u00e4glich durchgef\u00fchrt wird, betr\u00e4gt RPO = 24 Stunden. Das hei\u00dft, im Falle einer St\u00f6rung und dem vollst\u00e4ndigen Verlust des Speicher-Backends k\u00f6nnen Daten bis zu 24 Stunden (seit dem letzten Backup) verloren gehen. Aus dem f\u00fcr das Informationssystem festgelegten RPO wird beispielsweise eine Backup-Richtlinie formuliert. Dar\u00fcber hinaus kann man mithilfe des RPO einsch\u00e4tzen, wie wichtig die synchrone \/ asynchrone Datenreplikation ist.<\/p>\n

RTO<\/b> \u2014 die Zeit, die ben\u00f6tigt wird, um den Dienst (Zugriff auf die Daten) nach einer St\u00f6rung wiederherzustellen. Anhand des festgelegten RTO-Werts k\u00f6nnen wir bestimmen, ob ein Metrocluster erforderlich ist oder ob eine einseitige Replikation ausreicht. Auch die Notwendigkeit eines hochmodernen, multi-controller Speicher-Backends kann abgeleitet werden.<\/p>\n

\"Wie
\n<\/p>\n

Leistungsanforderungen<\/h4>\n

\nObwohl es eine offensichtlich simple Frage ist, treten gerade hier oft die gr\u00f6\u00dften Schwierigkeiten auf. Abh\u00e4ngig davon, ob Sie bereits \u00fcber eine Infrastruktur verf\u00fcgen oder nicht, werden sich die Wege zur Erhebung der ben\u00f6tigten Statistiken entwickeln.<\/p>\n

Sie haben bereits ein SAN und suchen nach einem Ersatz oder m\u00f6chten eine weitere f\u00fcr die Erweiterung erwerben. Hier ist alles klar. Sie wissen, welche Dienste Sie bereits haben und welche Sie in der nahen Zukunft implementieren m\u00f6chten. Basierend auf den aktuellen Diensten haben Sie die M\u00f6glichkeit, Leistungsstatistiken zu sammeln. Bestimmen Sie die derzeitige Anzahl der IOPS und die aktuellen Latenzzeiten \u2013 wie sehen diese Werte aus, und reichen sie f\u00fcr Ihre Anforderungen aus? Dies kann sowohl auf dem Speichersystem selbst als auch von den Hosts, die damit verbunden sind, erfolgen.<\/p>\n

Es ist wichtig, nicht nur die aktuelle Auslastung zu betrachten, sondern \u00fcber einen bestimmten Zeitraum (idealerweise einen Monat) zu analysieren. Achten Sie darauf, welche maximalen Spitzen w\u00e4hrend des Tages auftreten, welche Last durch das Backup erzeugt wird usw. Wenn Ihr SAN oder Ihre Software Ihnen nicht alle erforderlichen Daten liefert, k\u00f6nnen Sie das kostenlose RRDtool verwenden, das mit den meisten g\u00e4ngigen SANs und Switches arbeitet und detaillierte Leistungsstatistiken bereitstellen kann. Zudem sollten Sie die Auslastung auf den Hosts \u00fcberpr\u00fcfen, die mit diesem SAN verbunden sind, insbesondere auf konkreten virtuellen Maschinen oder Diensten, die auf diesem Host laufen.<\/p>\n

\"Wie
\n
\nEs ist au\u00dferdem anzumerken, dass, wenn die Latenzen auf dem Volume und dem Datastore, der sich auf diesem Volume befindet, stark variieren, Sie einen Blick auf Ihr SAN-Netzwerk werfen sollten. Die Wahrscheinlichkeit ist hoch, dass es Probleme gibt, und bevor Sie ein neues System erwerben, sollten Sie dieses Problem kl\u00e4ren, da es eine hohe Wahrscheinlichkeit gibt, dass die Leistung Ihres aktuellen Systems dadurch verbessert werden kann.<\/p>\n

Sie bauen eine Infrastruktur von Grund auf auf oder erwerben ein System f\u00fcr einen neuen Service, dessen Lasten Ihnen nicht bekannt sind. Hier gibt es mehrere M\u00f6glichkeiten: Sie k\u00f6nnen sich mit Kollegen auf spezialisierten Plattformen austauschen, um die Lasten zu ermitteln und vorherzusagen, oder Sie wenden sich an einen Integrator, der Erfahrung mit der Implementierung solcher Services hat und die Lasten f\u00fcr Sie berechnen kann. Die dritte Option (in der Regel die schwierigste, besonders wenn es um ma\u00dfgeschneiderte oder seltene Anwendungen geht) besteht darin, die Leistungsanforderungen bei den Entwicklern des Systems zu kl\u00e4ren.<\/p>\n

Und, achten Sie darauf, die praktischste L\u00f6sung \u2014 ist ein Pilotversuch mit der aktuellen Hardware oder mit der vom Anbieter\/Integrator bereitgestellten Testhardware.<\/p>\n

Spezialanforderungen<\/h4>\n

\nSpezialanforderungen sind alle Aspekte, die nicht unter die Vorgaben zur Leistung, Ausfallsicherheit und Funktionalit\u00e4t bei der unmittelbaren Verarbeitung und Bereitstellung von Daten fallen.<\/p>\n

Eine der einfachsten speziellen Anforderungen an ein Speichersystem sind \"entbehrliche Informationsspeichermedien\". Sofort wird klar, dass dieses Speichersystem eine Bandbibliothek oder einfach ein Tape-Drive umfassen muss, auf das ein Backup gespeichert wird. Anschlie\u00dfend signiert ein speziell geschulter Mitarbeiter das Band und tr\u00e4gt es stolz in einen speziellen Safe.
\nEin weiteres Beispiel f\u00fcr eine spezielle Anforderung ist eine sto\u00dfgesch\u00fctzte Ausf\u00fchrung.<\/p>\n

Dabei ist<\/h2>\n

\nDer zweite Hauptfaktor bei der Auswahl eines bestimmten Speichersystems ist die Information dar\u00fcber, WO dieses System platziert wird. Angefangen bei der Geographie und den klimatischen Bedingungen bis hin zum Personal.<\/p>\n

Auftraggeber<\/h3>\n

\nF\u00fcr wen ist dieses Speichersystem geplant? Diese Frage hat folgende Hintergr\u00fcnde:<\/p>\n

\u00d6ffentlicher Auftraggeber \/ kommerzieller.<\/b>
\nDer kommerzielle Auftraggeber hat keine Einschr\u00e4nkungen und ist nicht einmal verpflichtet, Ausschreibungen durchzuf\u00fchren, au\u00dfer nach eigenen internen Richtlinien. <\/p>\n

Der \u00f6ffentliche Auftraggeber ist ein anderes Kapitel: 44 FZ und andere Feinheiten mit Ausschreibungen und Pflichtenheften, die angefochten werden k\u00f6nnen.<\/p>\n

Auftraggeber unter Sanktionen<\/b>
\nHier ist die Frage sehr einfach \u2013 die Auswahl beschr\u00e4nkt sich nur auf die f\u00fcr diesen Kunden verf\u00fcgbaren Angebote.<\/p>\n

Interne Vorschriften \/ zugelassene Einkaufsanbieter \/ Modelle<\/b>
\nDie Frage ist ebenfalls \u00e4u\u00dferst einfach, aber man sollte sie im Hinterkopf behalten.<\/p>\n

Wo physisch<\/h3>\n

\nIn diesem Abschnitt betrachten wir alle Aspekte der Geographie, der Kommunikationskan\u00e4le und des Mikroklimas im Unterbringungsraum.<\/p>\n

Personal<\/h4>\n

\nWer wird mit diesem Speicherverwaltungssystem arbeiten? Das ist nicht weniger wichtig als das, was das Speicherverwaltungssystem tats\u00e4chlich kann.
\nSo beeindruckend und vielversprechend das Speicherverwaltungssystem von Anbieter A auch sein mag, es macht wenig Sinn, es zu implementieren, wenn das Personal nur mit Anbieter B umgehen kann und keine weiteren Eink\u00e4ufe oder eine kontinuierliche Zusammenarbeit mit A geplant sind.<\/p>\n

Und nat\u00fcrlich ist die Kehrseite der Medaille, wie gut geschultes Personal in diesem geografischen Gebiet direkt im Unternehmen und potenziell auf dem Arbeitsmarkt verf\u00fcgbar ist. In manchen Regionen kann die Wahl eines Speichersystems mit einfachen Schnittstellen oder der M\u00f6glichkeit zur zentralen, remote Steuerung von gro\u00dfer Bedeutung sein. Ansonsten kann es irgendwann schmerzhaft werden. Das Internet ist voll von Geschichten \u00fcber neue Mitarbeiter, die gerade erst vom Studium kommen und so viele Fehler machen, dass das gesamte Unternehmen betroffen ist.<\/p>\n

\"Wie
\n<\/p>\n

Umgebung<\/h4>\n

\nEin weiteres wichtiges Thema ist, in welcher Umgebung dieses Speichersystem betrieben wird. <\/p>\n