3
Storage area Network mit san volume controller
Hi,
Ich beschäftige mich immer noch mit "storage Area Network" und würde gerne Wissen welche Vorteile sich aus dem Einsatz von SAN Volume Controller ergeben. SAN hebt ja bekanntlich die wesentlichen Nachteile gegenüber der DAS auf , da alle im Netzwerk befindlichen Server Zugriffe auf alle im SAN intergrieten Speichereinheiten besitzen. Es besteht keine direkte Speicheranbindung der Server und sind somit je nach Speicherbedarf frei skalierbar. Das SAN fast somit alle im Netzwerk angebundenen Storageinheiten zusammnen, bindet diese aber nicht im Gegensatzt zum SAN Volume Controller. Ich verstehe nur nicht zu 100% den Sinn eines solchen controllers und würde es mir anhand eines expliziten Beispiels verdeutlichen. Bitte korrigiert mich wenn ich falsch liege....
Sorry , für mein detaliertes Kauderwelsch aber ich mich mit hier besonders schwer und hoffe das ihr mir helfen könnt.
Folgende Konstellation:
Angenommen ich habe 2 Server.
Beide Server sind nur mit 2 lokalen Festpaltten ausgestattet, die zum Raid 1 verbunden sind. Den Verbund habe ich nur in 1arrays gesplittet, auf den ESXi tut.
Unterhalb der SAN befinden sich zwei Storagebuchsen mit jeweils 12*250GB.
Eingerichtet sind beidejeweils mit einem raid 5 + 1 Hotspare, das pro Einheit einem Netto von 2,5 TB entspricht ( 2,5 TB : 5 array*500GB). Jetzt kommt meine eigentliche Frage : Ohne den Einsatz eines SVC kann ich den Speicher nur in Form von arrays zuzuordnen? Der SVC hingegen fasst alle definierten Arrays aller vorhandenen speicherbuchsen in einem Pool zusammen und teilt diese virtuell in logische Einheiten zusammen, je nach Bedarf.
MfG
Ich beschäftige mich immer noch mit "storage Area Network" und würde gerne Wissen welche Vorteile sich aus dem Einsatz von SAN Volume Controller ergeben. SAN hebt ja bekanntlich die wesentlichen Nachteile gegenüber der DAS auf , da alle im Netzwerk befindlichen Server Zugriffe auf alle im SAN intergrieten Speichereinheiten besitzen. Es besteht keine direkte Speicheranbindung der Server und sind somit je nach Speicherbedarf frei skalierbar. Das SAN fast somit alle im Netzwerk angebundenen Storageinheiten zusammnen, bindet diese aber nicht im Gegensatzt zum SAN Volume Controller. Ich verstehe nur nicht zu 100% den Sinn eines solchen controllers und würde es mir anhand eines expliziten Beispiels verdeutlichen. Bitte korrigiert mich wenn ich falsch liege....
Sorry , für mein detaliertes Kauderwelsch aber ich mich mit hier besonders schwer und hoffe das ihr mir helfen könnt.
Folgende Konstellation:
Angenommen ich habe 2 Server.
Beide Server sind nur mit 2 lokalen Festpaltten ausgestattet, die zum Raid 1 verbunden sind. Den Verbund habe ich nur in 1arrays gesplittet, auf den ESXi tut.
Unterhalb der SAN befinden sich zwei Storagebuchsen mit jeweils 12*250GB.
Eingerichtet sind beidejeweils mit einem raid 5 + 1 Hotspare, das pro Einheit einem Netto von 2,5 TB entspricht ( 2,5 TB : 5 array*500GB). Jetzt kommt meine eigentliche Frage : Ohne den Einsatz eines SVC kann ich den Speicher nur in Form von arrays zuzuordnen? Der SVC hingegen fasst alle definierten Arrays aller vorhandenen speicherbuchsen in einem Pool zusammen und teilt diese virtuell in logische Einheiten zusammen, je nach Bedarf.
MfG
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 145302
Url: https://administrator.de/contentid/145302
Printed on: April 26, 2024 at 15:04 o'clock
3 Comments
Latest comment
Hi
SAN ist eine Architektur, sprich was du davon umsetzt ist deine Sache; ich nutze als Beispiel nur die Verkabelung davon; wer weiter Geld hat kann es weiter abstrahieren um z.B. einen zentralen Storagekontroller (wie AMI's RAIDkontroller) oder einen Backupkontroller oder einen Snapshot Kontroller (wie TiNa was bei uns im Einsatz ist) oder alles in einem zentralisieren wie SUNs HSM (SAMFS) oder die EVA Struktur von Compaq oder EMC, respektive NetApps Speichersysteme. Je mehr Geld desto mehr abstrahiert sich deine App von der Hardware. Thin Provisioning oder int RAID Strukturen, Multipath Redundanzen, ...
Wir reden hier aber über viel Geld; mein 250k Server kostet für 22TB Nutzvolumen jeden Monat seinen Anschaffungspreis an Volumenkosten dafür das ich per Mausklick Snapshots je User zuweisen kann, ich jede Stunde ein Vollbackup habe und ein Baremetal Recover mehr oder minder in etwa 1h durch ist. Für meine Abteilung ist ein Ausfall von 1d einfach teurer als die Kosten. Je nach Geschmack.
Meine FC angebundenen Storages kennen nur dumme Blockzuordnung genau wie dein Fall, sprich der Kontroller gibt vor was er kann. Im Fall einer Virtualisierungsebene sieht dein VC diese beiden (x) Speicher und verwaltet sie indem er dir auch gerne 100TB anbietet und erst wenn die physischen aufgebraucht sind klagt er. Leider Fragmentiert das Zeug unglaublich (was mit ZFS bis dato mir nicht passiert ist obwohl es baugleich arbeitet), sprich regelmäßig müssen die VCs sich defragmentieren um keine zu großen Verluste zu haben (Netapp ist da ständig am rumpfriemeln).
Dein VC kann die Voluemn zu Pseudo RAID Pools fassen (sie dir dazu mal ZFS an, dort wird es gut erklärt) und gaukelt nach Außen einfach x Volumen vor. Diese können Thick (also real= oder thin (virt Volumen) sein. ESX arbeitet auch mit dieser Technik. Von den Arrays sieht dein VC auch nicht wirklich etwas da sie für ihn nur eine HD mit x LBAs sind. Die VCs sind auch normal an bestimmte Hardware gebunden, so arbeitet ein SUN System nicht bis überhaupt nicht (oder noch weniger) mit IBM oder EMC Sachen zusammen.
Zum rumspielen bietet sich Opensolaris an mit SamFS auf ZFS (beides mittlerweile integriert und OpenSource), wie etwa NexentaStor.
Gruß
Sam
SAN ist eine Architektur, sprich was du davon umsetzt ist deine Sache; ich nutze als Beispiel nur die Verkabelung davon; wer weiter Geld hat kann es weiter abstrahieren um z.B. einen zentralen Storagekontroller (wie AMI's RAIDkontroller) oder einen Backupkontroller oder einen Snapshot Kontroller (wie TiNa was bei uns im Einsatz ist) oder alles in einem zentralisieren wie SUNs HSM (SAMFS) oder die EVA Struktur von Compaq oder EMC, respektive NetApps Speichersysteme. Je mehr Geld desto mehr abstrahiert sich deine App von der Hardware. Thin Provisioning oder int RAID Strukturen, Multipath Redundanzen, ...
Wir reden hier aber über viel Geld; mein 250k Server kostet für 22TB Nutzvolumen jeden Monat seinen Anschaffungspreis an Volumenkosten dafür das ich per Mausklick Snapshots je User zuweisen kann, ich jede Stunde ein Vollbackup habe und ein Baremetal Recover mehr oder minder in etwa 1h durch ist. Für meine Abteilung ist ein Ausfall von 1d einfach teurer als die Kosten. Je nach Geschmack.
Meine FC angebundenen Storages kennen nur dumme Blockzuordnung genau wie dein Fall, sprich der Kontroller gibt vor was er kann. Im Fall einer Virtualisierungsebene sieht dein VC diese beiden (x) Speicher und verwaltet sie indem er dir auch gerne 100TB anbietet und erst wenn die physischen aufgebraucht sind klagt er. Leider Fragmentiert das Zeug unglaublich (was mit ZFS bis dato mir nicht passiert ist obwohl es baugleich arbeitet), sprich regelmäßig müssen die VCs sich defragmentieren um keine zu großen Verluste zu haben (Netapp ist da ständig am rumpfriemeln).
Dein VC kann die Voluemn zu Pseudo RAID Pools fassen (sie dir dazu mal ZFS an, dort wird es gut erklärt) und gaukelt nach Außen einfach x Volumen vor. Diese können Thick (also real= oder thin (virt Volumen) sein. ESX arbeitet auch mit dieser Technik. Von den Arrays sieht dein VC auch nicht wirklich etwas da sie für ihn nur eine HD mit x LBAs sind. Die VCs sind auch normal an bestimmte Hardware gebunden, so arbeitet ein SUN System nicht bis überhaupt nicht (oder noch weniger) mit IBM oder EMC Sachen zusammen.
Zum rumspielen bietet sich Opensolaris an mit SamFS auf ZFS (beides mittlerweile integriert und OpenSource), wie etwa NexentaStor.
Gruß
Sam
Hallo Schürsch,
ich habe das was in diesem Forum - auf Deine letzte Frage hin geschrieben
SAN Volume controller im SAN
Zum Thema VMWare
Aussage von Dir stimmt - was wir mit SVC in VMWare fast immer machen ist.
Damit sind wir ausfallsicher bzgl. der Disksysteme
Disksystem1 --> SVC Pool1
VMWare Festplatte über SVC in Pool1 und Pool2 gespiegelt
Disksystem 2 --> SVC Pool2
Noch eines drauf
SVC ist ein Cluster der immer aus 2 oder 4 (6,8) Maschinen besteht
Wir bauen jetzt auf
Disksystem1 + SVC Knoten 1 + SAN in RZ1
Disksystem2 + SVC Knoten 2 + SAN in RZ2
Damit können wir wie bei VMWAre Ping Pong mit den Disks spielen. Du ziehst einen VMWare Gast via VMotion um und kannst das gleiche mit den Disks über SVC machen
Wenn ein RZ ausfällt sind die Daten im RZ2 sofort mit den gleichen IDs zugreifbar. Der VMWare Host kann sofort wieder zugreifen
ich hoffe das hilft
ich habe das was in diesem Forum - auf Deine letzte Frage hin geschrieben
SAN Volume controller im SAN
Zum Thema VMWare
Aussage von Dir stimmt - was wir mit SVC in VMWare fast immer machen ist.
Damit sind wir ausfallsicher bzgl. der Disksysteme
Disksystem1 --> SVC Pool1
VMWare Festplatte über SVC in Pool1 und Pool2 gespiegelt
Disksystem 2 --> SVC Pool2
Noch eines drauf
SVC ist ein Cluster der immer aus 2 oder 4 (6,8) Maschinen besteht
Wir bauen jetzt auf
Disksystem1 + SVC Knoten 1 + SAN in RZ1
Disksystem2 + SVC Knoten 2 + SAN in RZ2
Damit können wir wie bei VMWAre Ping Pong mit den Disks spielen. Du ziehst einen VMWare Gast via VMotion um und kannst das gleiche mit den Disks über SVC machen
Wenn ein RZ ausfällt sind die Daten im RZ2 sofort mit den gleichen IDs zugreifbar. Der VMWare Host kann sofort wieder zugreifen
ich hoffe das hilft
Danke, deine Antwort hat mir sehr weitergeholfen...