Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!

Vehältnis Datastores zu Hosts bei zentralem Storage

ESX(i)-taugliche Hardware, HCL .....

Moderatoren: irix, continuum, Dayworker

Profi
Beiträge: 535
Registriert: 04.01.2006, 12:06
Wohnort: Hamm

Vehältnis Datastores zu Hosts bei zentralem Storage

Beitragvon ostekl1 » 25.09.2015, 15:21

Hallo,

ich hab da mal eine allgemeine Frage zum Thema "Zentraler Storage". Wir haben hier gerade unterschiedliche Meinungen :)

Wenn ich z.B. 4 ESX server über FC an einem NetApp betreibe und habe 10TB nutzbaren Storage, baue ich dann einen Datastore oder mehrere?

Ich habe mal die Info bekommen, das man eigentlich mindestens so viele Datastores wie Hosts haben sollte, um die Schreibprozesse so weit wie möglich zu Parallelisieren.

Ist das richtig so?
Oder hat sich da was mit VMFS5 verändert?

Gruß
Klaus

Experte
Beiträge: 1004
Registriert: 30.10.2004, 12:41

Beitragvon mbreidenbach » 25.09.2015, 15:33

Die NetApp 'striped' ja schon über möglichst viele Platten im Aggregat.

Allerdings hat man bei mehreren FC LUNs auch mehrere IO Queues und das kann gegenüber einer LUN einen Vorteil bringen.

Vermutlich hat die NetApp 2 Controller von denen jeder seine eigenen Platten verwaltet und es also schonmal Sinn machen kann LUNs auf beide Controller aufzuteilen. Um das vollständig beurteilen zu können müßte man aber mehr über das System wissen.

Dann kann es ja auch noch mehrere Aggregate pro Controller geben. Aber bei 10 TB Storage ist das System vermutlich nicht 'gigantisch groß' bzw komplex.

Profi
Beiträge: 535
Registriert: 04.01.2006, 12:06
Wohnort: Hamm

Beitragvon ostekl1 » 25.09.2015, 15:40

Hi,

danke für die schnelle Antwort.
Das ist jetzt noch ein weiterer "storagespezifischer" Grund für mehrere Datastores

Was ich mal gehört habe ist, das über FC die Schreibprozesse immer nur von gleichzeitig einem Host auf einem Datastore ausgeführt werden können. Es kann aber auch sein, das diese Info bei VMFS 5 nichts mehr wert ist?!

Experte
Beiträge: 1004
Registriert: 30.10.2004, 12:41

Beitragvon mbreidenbach » 25.09.2015, 15:56

Wenn mehrere Hosts schreibend auf dieselbe LUN zugreifen müssen ja zumindest Operationen an gemeinsamen Datenstrukturen koordiniert werden. Also z.B. alle Operationen die etwas am Dateilayout ändern wie das Anlegen neuer VMs oder Anlegen von Snapshots und ähnliches..

Früher wurde das durch SCSI reservations geregelt und da konnte in der Tat nur einer was ändern und die anderen mußten warten. Das betraf aber nicht alle Schreibzugriffe z.B. schreiben sich die Hosts ja normalerweise nicht gegenseitig in VMDKs rum.

Seit VAAI wird das anders geregelt und diese Problematik ist damit weitestgehend entschäft.

Den Verwaltungsaufwand für mehrere LUNs muß man auch berücksichrigen.

Lesestoff:
https://blogs.vmware.com/vsphere/2012/0 ... vered.html
http://www.boche.net/blog/index.php/201 ... rban-myth/

Wenn vSphere 6 Virtual Volumes mal in die Gänge kommen wird das wieder alles anders (ich hoffe ja besser).

King of the Hill
Beiträge: 12189
Registriert: 02.08.2008, 15:06
Wohnort: Hannover/Wuerzburg
Kontaktdaten:

Beitragvon irix » 25.09.2015, 15:57

Doch das "kann" noch so sein wie vermutest/gehoert hast. Wer Blockstorage und VMFS verwendet der hat unter Umstaenden mit SCSI Reservations zutun und die kommen immer dann vor wenn eine Host in den Metainformation der LUN was aendern moechte. Dann wird ein Lock gesetzt und kein anderer hat Zugriff und es muss gewartet werden. Allerdings gibts schon seit langer Zeit VAAI und dort ATS. Aber nur weil es das schon lange gibt heist es nicht das VMware nicht gerade wieder Fehler eingebaut hat. (Siehe Treads im Forum hier)

Vorteile bei mehren LUNs
- Mehr Queues
- Bei einem VMFS Fehler ist nicht gleich 100% "weg"
- Wenn der Datastore mal volllaueft ist nicht gleich alles Betroffen
- Wer ein tradiditionelles Storage und mehrere Diskgroups/Geschwindigkeitsklassen hat muss zwanglaeufig mehere Datastore machen
- Es gibt Storagesystems dort haengt eine LUN an einem Kontroller welcher die Load traegt. Der andere Kontroller wuerde rumbummeln bei nur einer LUN
- Bei NFS wuerden mehrere Datastore ueber verschiedene IPs angesprochen werden um so ein besseres Loadbalancing hinzubekommen

Also wie du siehst gibt es viele Gruende mehr als einen Datastore zumachen sofern wir von VMFS reden. Der ein oder andere Grund ist diskussionswuerdig und faellt weg wenn NFS oder VSAN oder, oder oder vorhanden ist.

Gruss
Joerg

Profi
Beiträge: 535
Registriert: 04.01.2006, 12:06
Wohnort: Hamm

Beitragvon ostekl1 » 25.09.2015, 16:19

Hi,

ok - die Wahrheit liegt also irgendwo dazwischen.
Vielen vielen Dank für den Input!

Hintergrund meiner Frage ist, das wir eine bestehende VMware Umgebung mitsupporten sollen. Es gibt auch die Aussage der Tochtergesellschaft, das alles viel zu langsam ist.
Jetzt versuchen wir uns mühsam ein Bild der Gesamtumgebung zu machen - das ist nicht immer einfach wenn der "alte Architeckt" nicht mehr greifbar ist.

Diese riesige LUN war das erste was mir aufgefallen ist.
Das ist natürlich auf einem NetApp nicht wirklich rückgängig zu machen - befürchte ich.
D.h. man muss ein neues Shelf haben und dann umziehen - oder gibt es auch geschicktere Lösungen?

Experte
Beiträge: 1004
Registriert: 30.10.2004, 12:41

Beitragvon mbreidenbach » 25.09.2015, 16:54

Ich denke da müßte man sich erstmal das System näher ansehen. Für 'alles viel zu langsam' gibts potenzielle Ursachen (kleine Diskgruppen, Mißalignment, ungünstige Blockverteilung, multipathing falsch etc).

Profi
Beiträge: 535
Registriert: 04.01.2006, 12:06
Wohnort: Hamm

Beitragvon ostekl1 » 25.09.2015, 16:57

jep - nächste woche versuche ich mit einem Kollegen den NetApp zu "sezieren".
Ich halte euch auf dem laufenden ;-)

Member
Beiträge: 91
Registriert: 18.10.2015, 18:15

Beitragvon Whitemoon » 18.10.2015, 19:30

Guten Abend ostekl1,
falls ihr noch "sucht".. lege ich dir für die erste Suche den Befehl:

Code: Alles auswählen

sysstat -x

ans Herz. Einfach per SSH auf beide Netapp-Controller verbinden und eingeben. In der formatierten Tabelle siehst du schon mal grob, ob es auf dem Storage hakt. Falls du dir nicht sicher bist, kannst du über den Netapp Support einen Performance Case eröffnen. Durch ein Tool werden die relevanten Daten über Tage hinweg eingesammelt und danach ausgewertet.

Fehlerquellen kann es zu haufen geben:
- Die Anzahl der VMs auf dem Cluster ist für die Netapp inzwischen zu viel.
- Evtl. ist einem Volume automatische Datendeduplizierung oder Kompression aktiv.
- ONTAP ist auf einer Version, welche fehlerhaft ist.
- VMWare ESXi-Verison ist mit Netapp ONTAP-Version nicht kompatibe
etc...


Gruß,
Dani


Zurück zu „Hardware“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast