Toon posts:

[ESX] iSCSI SAN Multipath (Active(I/O) paths)

Pagina: 1
Acties:

Verwijderd

Topicstarter
Hoi,

Ik heb hier 3 ESX4 servers die ik met een Dell MD3000i SAN heb verbonden. De koppeling is prima. Ik heb ondertussen multipath aan de praat gekregen. Daarvoor heb ik VMkernel Ports aangemaakt per server waarmee de iSCSI verbinding tot stand wordt gebracht. Hoe dit moet kun je hier bekijken: http://www.youtube.com/watch?v=FzXYUzYTJVE

Wat ik nu zie is dat er maar 2 van de 4 paden naar de SAN op Active (I/O) staan. De andere 2 paden staan onder "Stand by". Is het mogelijk om alle 4 paden op Active in te stellen? Zo ja, hoe moet dat?

Ik heb nu een VMkernel port ingesteld per NIC. Per server heb ik 4x 1GB NIC adapters. Een VMkernel is bijvoorbeeld ingesteld op NIC1 met FAILOVER over de andere, mocht NIC1 het niet meer doen. VMkernel2 is dan ingesteld op NIC2 met Failover op de andere 3, enz enz.

De MD3000i heeft 4 porten en ik wil alle 4 poorten gaan gebruiken. Op een of de andere manier pakken alle servers standaard de eerste 2 poorten van de MD3000i.

Hieronder een aantal screenshots.

Path instellingen (Round robin configuratie)
Afbeeldingslocatie: http://lh6.ggpht.com/_1hL9OGTgMgo/TO-RqfPpXQI/AAAAAAAAA88/VpHRELAJXVI/ESX1.jpg

Storage adapter (iSCSI koppeling)
Afbeeldingslocatie: http://lh5.ggpht.com/_1hL9OGTgMgo/TO-T7MaxfWI/AAAAAAAAA-M/8P94DKbxQKU/ESX2.jpg

VMkernels (3 stuks op die moment). Elke VMKernel is aangesloten op 1 NIC met failover op de resterende NIC adapters.
Afbeeldingslocatie: http://lh6.ggpht.com/_1hL9OGTgMgo/TO-T7EXy0UI/AAAAAAAAA-E/_kv6ErO27YM/ESX3.jpg

Voorbeeld koppeling van een VMkernel (iSCSI1)
Afbeeldingslocatie: http://lh5.ggpht.com/_1hL9OGTgMgo/TO-WQnKnEbI/AAAAAAAAA-U/ATXmOcW6VOA/ESX4.jpg

Alvast bedankt!

Sead

  • CherandarGuard
  • Registratie: Oktober 2001
  • Laatst online: 14-10-2024
Dit lijkt mij een geval van 'works as designed'? Je hebt meerdere paden naar dezelfde target, dus ziet ESX die als redundant. Hij zal er dan een actief en een standby maken.

Verwijderd

Topicstarter
Ik zie dat het vooral te maken heeft met de MD3000i. Het gaat om een LUN die door 1 van de 2 RAID controllers wordt aangestuurd. De MD3000i is een active/active SAN en hij gan wel load balance over de tweede controller, maar dat doet ie standaard bij failover. Ik lees nu iets over MRU policies van de MD3000i. Misschien kan ik daar iets mee...

De instellingen van de ESX zijn waarschijnlijk goed.

To be continued... :)

Verwijderd

Topicstarter
Verwijderd schreef op vrijdag 26 november 2010 @ 12:51:
Ik zie dat het vooral te maken heeft met de MD3000i. Het gaat om een LUN die door 1 van de 2 RAID controllers wordt aangestuurd. De MD3000i is een active/active SAN en hij gan wel load balance over de tweede controller, maar dat doet ie standaard bij failover. Ik lees nu iets over MRU policies van de MD3000i. Misschien kan ik daar iets mee...

De instellingen van de ESX zijn waarschijnlijk goed.

To be continued... :)
Ja, ik kan het ondertussen bevestigen. Het ligt aan de SAN zelf dus. De MD3000i SAN kan multi-path en alle 4 verbindingen op active gooien, maar je hebt altijd 2 active verbindingen per controller. Als je dus een partitie op de SAN aanmaakt en de pad kiest voor controller 1, dan krijg je max 2 verbindingen naar die partitie. Mocht de ene controller uitvallen, dan schakkeld de SAN automatisch over op de andere 2 verbindingen. Wat je wel dus moet doen om alle 4 verbindingen vanuit ESX te gebruiken, is twee partities definieren op de SAN. Je stelt de partities in op verschillende controllers. De koppeling vanuit ESX maak je zoals hierboven weergegeven en dan krijg je 4 active IO verbindingen met je SAN, maar wel 2 per partitie. Zo verdeel je de load over de twee partities op je SAN en zijn de read en write latencies kleiner dan als je 1 grote partitie gebruikt.

Ik gebruik nog wel de Round Robin balancing over de twee verbindingen per controller. Dat gaat tot nu toe heel goed. Nu ik twee partities heb ingedeeld is de performance ook veel beter. Ook met 1 partitie was ik gemiddeld rond 20ms read latency en 3ms write latency, wat voor een iSCSI SAN erg goed is. Met de twee verbindingen ben ik per controller nu sneller uit, omdat de virtuele machines verdeeld zijn over meerdere partities op de SAN.