Storage Area Network - Aufbau und Redundanz

[sakat3000]

Hallo liebe Community,

ich habe mich im Internet über SANs und deren Aufbau informiert. Mir ist mittlerweile bewusst, dass dort mehrere redundante RAID Controller und Switches vorhanden sein können, wenn ich es richtig verstanden habe. Ich weiß auch, dass die SANs über Glasfaser mit dem Netzwerk verbunden werden und virtuelle Speichersysteme für die Server bereit stellen. Nur der genaue Aufbau ist mir nicht bekannt. Es muss ja wie jedes System ein Mainboard CPU und RAM besitzen. Leider habe ich dazu aber ein paar Fragen, die ich mir im Internet nicht beantworten konnte:

• KÖNNEN redundante controller und Switches im SAN vorhanden sein, oder sind sie automatisch bei jedem SAN dabei?
• Wenn ein Controller oder Switch im SAN ausfällt, kann man diesen ohne weiteres ersetzen?
• Was passiert, wenn in einem SAN das Mainboard oder die CPU ausfällt? Ist das SAN dann noch Verfügbar?
• Bietet ein SAN alleine völlige redundanz, so dass jedes Bauteil im SAN einmal ausfallen kann? Oder wird zur völligen Redundanz noch ein zweites SAN benötigt?

 

[lakekeman]

• KÖNNEN redundante controller und Switches im SAN vorhanden sein, oder sind sie automatisch bei jedem SAN dabei?

Können, je nach Geldbeutel.

• Wenn ein Controller oder Switch im SAN ausfällt, kann man diesen ohne weiteres ersetzen?

In der Regel hast du einen Servicevertrag zu deiner Speicherlösung, die den Hardwaretausch (Zeitrahmen wieder je nach Geldbeutel) beinhaltet.

• Was passiert, wenn in einem SAN das Mainboard oder die CPU ausfällt? Ist das SAN dann noch Verfügbar?
• Bietet ein SAN alleine völlige redundanz, so dass jedes Bauteil im SAN einmal ausfallen kann? Oder wird zur völligen Redundanz noch ein zweites SAN benötigt?

Auch hier kommt es wieder völlig auf das eingesetzte Modell an. Meist wird aber ein HA Cluster gebildet, um völlige Redundanz zu haben.

Bei richtigen Premiumgeräten kostet das dann auch richtig Geld.

 

[sakat3000]

Vielen Dank für die fixe Antwort. Also müssen alle Punkte bei dem Dienstleister konkret angefragt werden.

Die letzte Frage die mich interessieren würde, wäre wie genau ein SAN aufgebaut ist. Besteht er ganz normal aus Mainboard, CPU, RAM und Festplatten, oder ist hier noch etwas speziell anders?

 

[Masamune2]

Auch wenn sich hier die Geister streiten meine Definition ist folgende:
SAN: Storage Area Network: Netzwerk das ausschließlich für Speicherzugriffe da ist.
Im allgemeinen Sprachgebrauch wird damit meistens der Storage selbst gemeint, nicht das eigentliche Netzwerk. Finde ich nicht korrekt so.

KÖNNEN redundante controller und Switches im SAN vorhanden sein, oder sind sie automatisch bei jedem SAN dabei?

Bei fast allen Systemen am Markt sind redundante Controller immer dabei, aber nicht bei allen. Netapps kann man auch als Single Controller kaufen.

Wenn ein Controller oder Switch im SAN ausfällt, kann man diesen ohne weiteres ersetzen?

Ja das ist Sinn der Sache. Switche müssen eventuell wieder konfiguriert werden bevor sie in Betrieb gehen (alte Konfig wieder einspielen), Controller ziehen sich alles was sie brauchen in der Regel vom Partner.

Was passiert, wenn in einem SAN das Mainboard oder die CPU ausfällt? Ist das SAN dann noch Verfügbar?

Dann ist ein Controller ausgefallen und der andere übernimmt.

Bietet ein SAN alleine völlige redundanz, so dass jedes Bauteil im SAN einmal ausfallen kann? Oder wird zur völligen Redundanz noch ein zweites SAN benötigt?

Brennt der komplette Storage ab hilft nur die Daten auf einen zweiten zu spiegeln. Es kommt also immer darauf an vor welchen Szenarien man sich schützen möchte.

Ich weiß auch, dass die SANs über Glasfaser mit dem Netzwerk verbunden werden

Es muss nicht immer Glas sein, viele Storages können ihren Platz über iSCSI und "normales" Ethernet bereitstellen.

 

[sakat3000]

Vielen Dank für die Antwort, das hat mir echt schon sehr weitergeholfen.
Ich verstehe bis heute nicht, wieso es in so vielen Artikeln nicht so einfach erklärt wird wie hier

 

[lakekeman]

An sich ist da recht normale Serverhardware verbaut. Aber mit einem gesalzenen Aufpreis. Steht ja dann Netapp, EMC o.Ä. drauf.

 

[Cat Toaster]

Das Geld spielt die entscheidende Rolle, wenn man mehrere Server hat, den Storage spiegelt und man sich in der Regel auch mindestens mal zwei SAN-Switche gönnt dann kannst Du idealerweise einen ganzen Storage, Speicher oder SAN-Switch tauschen ohne die geringste Downtime.

Im simpelst möglichen Fall wo meinetwegen zwei Server mittels FC direkt an einem einzelnen Storage mit Dual-Controllern hängen (jeweils jeder Server an jedem Controller) braucht man erstmal überhaupt keine SAN-Switche.

So ein Dual-Controller-SAN nimmt vorne 24x2,5" Festplatten auf, die gehen in der Mitte auf die Backplane (den Single-Point-of-Failure) und dahinter sind die zwei Controller-Einheiten die jeweils eine eigene CPU, Speicher, Netzteil, FC- und Netzwerkanbindung haben und im Falle des Ausfalls des anderen Controllers den Job vollständig übernehmen können. Jeder Controller kann im laufenden Betrieb ohne Leistungsabfall oder Downtime gezogen werden soweit der jeweils andere noch läuft. In einer perfekten Welt. In der Regel kann man daran noch Erweiterungs-Chassis anschließen, die "Intelligenz" bleibt aber allein im "Kopf".

Durch SAN-Switche stellt man letztlich nur weitere Ports bereit worüber weitere Server auf ggf. weiteren Storage zugreifen können. Die legt man dann idealerweise eben auch entsprechend redundant aus. Wäre etwas dösig meinetwegen zwei SANs zu spiegeln und 14 Server dran zu hängen an einem einzigen Switch, wenn der dann den Geist aufgibt ist Pause für alle außer der IT.

In der Regel nehmen wir die Dinger immer mit 60 Monaten 24x7x4h Vorort-Service, beim Storage gern auch 6h Committed. In so einer Umgebung wird man vielleicht virtualisiert haben und den Wegfall mindestens eines Servers locker fest einplanen (zum Beispiel weil man einen ESX-Host mal updaten will), deswegen macht man das Theater ja. Beim Storage ist es dann schon kritischer, auch wenn man theoretisch auch hier bei einem einzelnen Dual-Controller-Gerät die Firmware der Controller abwechselnd im laufenden Betrieb updaten könnte würde ich keinen Admin verurteilen der sich das allein ohne Rückversicherung nicht antun möchte wenn er nur eine oder zwei Maschinen davon hat. Auch bei den tollsten Maschinen kann mal etwas schiefgehen und wenn ein Controller-Update nicht selten ein Firmware-Update der Platten erfordert ist das im laufenden Betrieb schon nicht mehr ganz so lustig wenn man da mutig auf "Fortsetzen" klickt.

 

[sakat3000]

Vielen Dank für deine Antwort.

Also wäre bei einem einfachen SAN mit zwei Servern erstmal nur ein redundantes Netzteil und ein redundanter Controller notwendig. Redundante Switches sind also nicht zwingend notwendig, außer man möchte weitere Ports und somit weitere Geräte an das SAN anschließen, was bei mir nicht der Fall ist.

Dieser 24x7x4h Vorort-Service. Ist das ein Garantiekriterium, den man quasi beim Erwerb eines SANs miterwirbt, oder muss man für solch einen Service monatlich eine Pauschale bezahlen?

 

[lakekeman]

Den Servicevertrag zahlst du extra auf jährlicher Basis.

Ohne zu wissen was du eigentlich für eine Umgebung aufbauen willst kann man dir auch keine wirklichen Tips geben.
Wofür soll der Storage denn überhaupt sein.

 

[sakat3000]

Ich erarbeite ein Konzept zur Virtualisierung für unsere Server. Daher war es mir wichtig zu wissen, wie viel redundanz ein SAN bietet und wie es aufgebaut ist.

Ist eine Server Virtualisierung auch ohne den Einsatz eines SAN möglich?

 

[lakekeman]

In einer so kleinen Umgebung würde ich immer ohne shared Storage arbeiten.
Du setzt 2 Virtualisierungshosts ein um dir eine (vermeintliche) Ausfallsicherheit zu schaffen, hast dahinter aber nur 1 Storage System was ein Single Point of Failure ist. Selbst mit 2 Controllern.

Das Budget ist in so einem Fall sicher recht klein. Da macht ein Storage Cluster keinen Sinn.

Natürlich kannst du auch ohne ein SAN virtualisieren.
Ich würde die 2 Hosts so dimensionieren, dass bei einem Ausfall zur Not alle VMs auf einer Maschine lauffähig sind.

Fällt ein Host aus, kannst du die VMs aus dem Backup auf dem anderen Host wieder herstellen.
Oder du nutzt zusätzlich eine asynchrone VM Replication zwischen den Servern. Dadurch hast du deine ausgefallenen VMs in kürzester Zeit wieder am laufen.

Und mal generell:
Du schreibst ja dass du selbst nicht wirklich viel Ahnung von der Materie hast. Aber willst selbst das ganze Konzept erstellen? Das sollte dringend jemand machen, der sich damit auskennt. Ist nicht böse gemeint. Aber das Thema ist dann doch etwas zu komplex, um sich das mal eben anzulesen.

 

[sakat3000]

In einer so kleinen Umgebung würde ich immer ohne shared Storage arbeiten.
Du setzt 2 Virtualisierungshosts ein um dir eine (vermeintliche) Ausfallsicherheit zu schaffen, hast dahinter aber nur 1 Storage System was ein Single Point of Failure ist. Selbst mit 2 Controllern.

Das Budget ist in so einem Fall sicher recht klein. Da macht ein Storage Cluster keinen Sinn.

Natürlich kannst du auch ohne ein SAN virtualisieren.
Ich würde die 2 Hosts so dimensionieren, dass bei einem Ausfall zur Not alle VMs auf einer Maschine lauffähig sind.

Fällt ein Host aus, kannst du die VMs aus dem Backup auf dem anderen Host wieder herstellen.
Oder du nutzt zusätzlich eine asynchrone VM Replication zwischen den Servern. Dadurch hast du deine ausgefallenen VMs in kürzester Zeit wieder am laufen.

Und mal generell:
Du schreibst ja dass du selbst nicht wirklich viel Ahnung von der Materie hast. Aber willst selbst das ganze Konzept erstellen? Das sollte dringend jemand machen, der sich damit auskennt. Ist nicht böse gemeint. Aber das Thema ist dann doch etwas zu komplex, um sich das mal eben anzulesen.

Also vornweg gebe ich dir recht. Ich habe von diesem Thema wirklich noch nicht viel Ahnung und meine AUfgabe ist es mich reinzulesen und ein Konzept zu erstellen, bevor ich mich an ein IT-Systemhaus wende. Bei dieser "Asynchronen VM Replication" die du angesprochen hast. Das wäre eigentlich eine gute alternative wenn ich das richtig verstehe.
Angenommen ich habe zwei Host-Server. Der eine rechnet, der andere läuft im Standby und springt nur dann ein, wenn der erste ausgefallen ist. Wäre diese Variante ohne SAN realisierbar?
Theoretisch brauche ich auf dem redundanten Host-Server genau so viel Festplattenspeicher wie auf dem Hauptserver

 

[Masamune2]

Ist eine Server Virtualisierung auch ohne den Einsatz eines SAN möglich?

Da geht sogar der Trend hin.

Neben der Möglichkeit einer Replikation zwischen zwei Hosts (mit Hyper-V oder ESX möglich) gibt es Ansätze lokal im Server verbaute Platten zu einem redundanten Storage zusammen zu fassen. Das macht VMware selbst mit vSAN, sowie Nutanix und Simplivity mit leicht unterschiedlichen Ansätzen.
Klar du brauchst dann natürlich die doppelte Plattenkapazität, das ist in der Regel aber in kleinen Umgebungen gar kein Problem da die Platten hier eh groß genug sind. Kleiner Nachteil: Du brauchst in allen Fällen mindestens drei Hosts für einen Cluster.

Angenommen ich habe zwei Host-Server. Der eine rechnet, der andere läuft im Standby und springt nur dann ein, wenn der erste ausgefallen ist. Wäre diese Variante ohne SAN realisierbar?

Mach aus der zwei eine drei und dann geht das.

 

[lakekeman]

Ah ok, wenn noch ein Systemhaus eingeschaltet wird ist das ja ok. Wobei man da natürlich etwas darauf achten sollte, dass sie dir sicher ganz gerne ein teures SAN ihrer Hardwarepartner verkaufen wollen. Auch wenn es nicht unbedingt sein muss


Ich würde die 2 Hosts aktiv betreiben. Jeder hält die Hälfte der VMs im eingeschalteten Zustand.

Die VMs des jeweils anderen Hosts werden je nach Zeitplan repliziert und liegen dann ausgeschaltet bereit.

So hast du recht kleinen Datenverlust, sollte ein Host ausfallen.
Natürlich muss jeder Host so ausgestattet sein, dass alle VMs darauf Platz haben.
Der Speicher ist lokal in jedem Host und es wird kein SAN benötigt.

Zur Software:
Mit Hyper-V Replica kannst du sowas ohne Aufpreis abbilden. In vSphere muss Replication lizenziert werden.
Ich empfehle allerdings Veeam Backup & Replication.
Du wirst eh ein Backup Produkt kaufen müssen, das kann in diesem Fall die Replikation gleich mit übernehmen. Und die Lizenzierungskosten für kleine Umgebungen sind sehr übersichtlich.

 

[sakat3000]

Ja das ist allerdings wahr, darauf werde ich auch besonders acht geben.

Okay, dann werde ich mir diese Variante vor Augen halten. Danke für deine Antwort

 

[Sandorkan]

Was du dir auch mal anschauen könntest ist "EVO: Rail", das VMware letztes Jahr auf der VM World vorgestellt hast (läuft unter dem Oberbegriff Hyper Converged Systems).

Das sind Systeme, die vorgefertigt und mit allen nötigen Lizenzen (vcenter, ESXi, VDP, vSAN, etc.) geliefert werden - und du kannst bis zu vier solcher Systeme zu einem Cluster zusammenfassen.
Die Hardware selbst kommt von verschiedenen Herstellern, u. a. Dell oder HP.

Gruß

Edit: Hier noch kurz die URL zu EVO: Rail mit noch ein paar Infos mehr: https://www.vmware.com/de/products/evorail/