Hyper-V Quorum lost

[Verwijderd]

Sinds enige tijd heb ik een Hyper-V cluster draaien (Windows 2008R2) en om een of andere reden raakt het cluster zijn quorum kwijt wanneer dat niet verwacht wordt.

De situatie:
Netwerk
Office netwerk - 2x Cisco 3750 gekoppeld middels stack kabel
iSCSI netwerk 1 - Dell switch, jumbo packets enabled
iSCSI netwerk 2 - Dell switch, jumbo packets enabled

Servers
Server1: HP DL380G7 gekoppeld met 2 netwerkkabels aan het Office netwerk (HP Network Team) en 1 kabel naar beide iSCSI netwerken
Server2: HP DL380G7 gekoppeld met 2 netwerkkabels aan het Office netwerk (HP Network Team) en 1 kabel naar beide iSCSI netwerken
Server3: HP DL360G5 gekoppeld met 2 netwerkkabels aan het Office netwerk (HP Network Team) en 1 kabel naar beide iSCSI netwerken
Storage: P2000g3 gekoppeld met 2 netwerkkabels naar Office netwerk (geen team, slechts beheerinterface) en 1 kabel naar beide iSCSI netwerken

Omschrijving
Op de iSCSI netwerken is geen cluster communicatie toegestaan. Dit is wel toegestaan op het Office netwerk. Cluster Validation is gerund en geeft geen noemenswaardige fouten (enkel wat Windows Updates). Cluster draait in Node Majority Quorum.

Wat gaat er mis:
Als ik Server1 of Server2 uit het cluster haal door hem op pause te zetten en vervolgens te rebooten (uiteraard is die server leeg qua resources) dan verliest het cluster het quorum op het moment dat de server de cluster service stopt. Cluster stort in en pas als Server1 of Server2 terug is gaan we weer draaien. Wel opvallend is dat als Server2 bijvoorbeeld reboot dat dan op Server1 de Cluster Service stopt maar op Server3 gewoon blijft draaien.

Als ik Server3 reboot dan blijft het cluster wel draaien, maar op het moment dat Server3 dan terugkomt in het cluster dan gaat of op Server1 of op Server2 (geen regelmaat in kunnen ontdekken) even op rood (cluster service stopt dus), maar hij komt snel weer terug en alles draait door. Resources worden wel gemoved naar de server die niet op rood ging (maar niet naar de gereboote Server3).

Hopelijk is het een beetje duidelijk zo. Mijn gevoel zegt dat ik ergens iets vergeten ben goed te zetten, maar ik kan niet vinden waar dat zou moeten zijn. Het enige manco (en fout) die ik me kan voorstellen is het feit dat ik niet een apart live migration en cluster communication netwerk heb. Ik heb echter geen bandbreedte problemen zover ik kan beoordelen en ook hoeft er geen live migration plaats te vinden op het moment dat er 1 van de 3 nodes weg valt, dat zou dus geen hoge belasting mogen opleveren.

Tl;DR: HEEELP

[ Voor 5% gewijzigd door Verwijderd op 20-01-2013 12:39 ]

[Semt-x]

Oei, iSCSI icm NIC teaming. Als iemand daar bewust voor heeft gekozen zal er nog wel meer mis zijn.
Dan verbaast het me niks dat het niet stabiel is. Mijn Advies: Zoek een partij met ervaring en vraag ze om de boel te fixen.

[Verwijderd]

Semt-x schreef op zondag 20 januari 2013 @ 14:10:
Oei, iSCSI icm NIC teaming. Als iemand daar bewust voor heeft gekozen zal er nog wel meer mis zijn.
Dan verbaast het me niks dat het niet stabiel is. Mijn Advies: Zoek een partij met ervaring en vraag ze om de boel te fixen.

Ik heb het zelf opgebouwd

Maar waar jij vandaan haalt dat de iSCSI interfaces in een NIC team zitten? Dat is namelijk niet zo.

[Semt-x]

ahja ik zie het! te snel gelezen :<

[Brahiewahiewa]

Hoe ziet je storage configuratie er uit?
Als je disks op dezelfde LUN aanbiedt en een cluster node reboot, dan zal de hele LUN een (i)scsi-bus reset krijgen. Dan is het niet zo gek dat andere nodes hun disks en daarmee hun quorum kwijtraken.
Gebeurt 't ook als je alleen local-quorum gebruikt?

[wagenveld]

CSV of gewone volumes?
Multipath correct opgezet?
Als ik het goed begrijp heb je geen NIC meer over om apart een heartbeat/cluster netwerk op te zetten? Ik zou in jouw geval de teams verbreken en 1 van de NICs daarvoor gebruiken. Daarmee hou je je iSCSI failover.

[Verwijderd]

Brahiewahiewa schreef op dinsdag 22 januari 2013 @ 03:15:
Hoe ziet je storage configuratie er uit?
Als je disks op dezelfde LUN aanbiedt en een cluster node reboot, dan zal de hele LUN een (i)scsi-bus reset krijgen. Dan is het niet zo gek dat andere nodes hun disks en daarmee hun quorum kwijtraken.
Gebeurt 't ook als je alleen local-quorum gebruikt?

Storage is uiteraard 1 LUN, anders heb je geen failover mogelijkheden
Maar daarvoor heeft Microsoft de Cluster Storage Volume bedacht, daarmee voorkom je die bus resets en dat de disk op meerdere plekken gemount wordt. Dat is dus conform design zover ik kan zien.

Local quorum zegt me niets? Wat bedoel je daar precies mee?

---

wagenveld schreef op dinsdag 22 januari 2013 @ 11:51:
CSV of gewone volumes?
Multipath correct opgezet?
Als ik het goed begrijp heb je geen NIC meer over om apart een heartbeat/cluster netwerk op te zetten? Ik zou in jouw geval de teams verbreken en 1 van de NICs daarvoor gebruiken. Daarmee hou je je iSCSI failover.

CSV zoals ik boven zei, dat zou ervoor bedoeld zijn dus dat lijkt me goed. Het CSV mount ook netjes op een andere server als ik dat handmatig doe of een failover gebeurd.
Multipath is volgens mij goed, ik kan gerust 1 van de 2 kabels eruit trekken en dan blijft het netjes draaien. Zelfs in de initiator gezorgd dat de source en destination netjes zijn gekozen.

Ik zit er ook hard aan te denken om het team te verbreken als dat niet anders kan, een losse gbit switch voor heartbeat/cluster lijkt me wel handig. Sowieso gaat het cluster dan toch 2 wegen gebruiken zodat er minder kans op een false fail is.

Ben al een paar dagen weg van de zaak dus nog geen tijd gehad om offertes op te vragen voor wat extra nic's. Zou eigenlijk per server een 2 ports NIC moeten hebben erbij. Al wordt dat lastig in de 360G5, daar zitten onboard maar 2 poorten en gebruik ik dus al een extra kaart met 2 poorten. Het team is toch alleen goed voor failover (bundelt de poorten niet) dus echt een gemis zal het niet worden.

[Brahiewahiewa]

Verwijderd schreef op dinsdag 22 januari 2013 @ 18:49:
[...]
Storage is uiteraard 1 LUN, anders heb je geen failover mogelijkheden
Maar daarvoor heeft Microsoft de Cluster Storage Volume bedacht, daarmee voorkom je die bus resets en dat de disk op meerdere plekken gemount wordt. Dat is dus conform design zover ik kan zien.

't Gaat niet zozeer om de shared resources maar om de vraag of je ook de system disks via iSCSI aanbiedt

[Verwijderd]

Brahiewahiewa schreef op woensdag 23 januari 2013 @ 03:22:
[...]

't Gaat niet zozeer om de shared resources maar om de vraag of je ook de system disks via iSCSI aanbiedt

Je bedoeld de system disks van de Hyper-V hosts neem ik aan? Die draaien gewoon op een DAS RAID1 (ik heb geen gebrek aan disken dus lekker makkelijk ).

[bigfoot1942]

Je combineert wel erg veel over je LAN team, _ALLE_ cluster communicatie, LAN connectivity zowel vanuit host als guest, CSV data en Livemigration.
verder, is dat toevallig een broadcom onboard nic?

[Verwijderd]

bigfoot1942 schreef op woensdag 23 januari 2013 @ 17:52:
Je combineert wel erg veel over je LAN team, _ALLE_ cluster communicatie, LAN connectivity zowel vanuit host als guest, CSV data en Livemigration.

Helemaal mee eens, zeker als je bedenkt dat het NIC team zodanig staat ingesteld dat hij wel over 2 verbindingen zend maar op slechts 1 ontvangt. Er is, behalve de redundancy wat betreft kabels en de dubbele 3750 switch, eigenlijk meer noodzaak aan 2x 1Gbit zend/ontvang. Daar haal ik meer uit.

Beste in mijn situatie zou denk ik zijn om het team te breken en dan CSV en cluster communicatie via 1 nic te laten lopen. Ik vind de live migration prima over het LAN, er is amper noodzaak om dat snel te doen. Door de nic's te scheiden krijg je ook 2 paden voor het failover stuk als ik het goed heb toch? En dan prefer je taken op bepaalde nic's.

verder, is dat toevallig een broadcom onboard nic?

Volgens de HP quickspecs is de chip op de G7 een BCM5709C. Van de G5 kan ik het zo snel niet vinden, kan zowel Broadcom als Intel zijn.

[wagenveld]

Dan ook even de laatste Broadcom drivers installeren en alle offloading features uitzetten:
Information about the TCP Chimney Offload, Receive Side Scaling, and Network Direct Memory Access features in Windows Server 2008

Ook even doen bij de NIC eigenschappen.

[bigfoot1942]

Ik zou zelf minimaal een dual port intel nic bijplaatsen, of anders de huidige dual port upgraden naar een Quad port (intel, that is). Gewoon teamen en sharen tussen VM en host zou niet voor problemen mogen zorgen.
Verder onboard broadcom gebruiken om redundant heartbeat netwerken (internal cluster use) van te maken, voor CSV en Livemigration. Hou er ook rekening mee dat je bij eventuele problemen aan je stacked LAN switches (zoals Master Re-elect) toch een werkende heartbeat wilt behouden...

edit: uiteraard broadcom bewerken zoals aangegeven in de post hierboven.

[ Voor 7% gewijzigd door bigfoot1942 op 25-01-2013 22:51 ]

[Verwijderd]

Meer netwerk segregatie is nodig hier. Best practices schrijven voor om op zijn minst vier seperate netwerken te gebruiken (physiek seperaat, dus geen vlan geneuzel, het gaat hier om de capaciteit van de backbone).

Ik gebruik vier netwerken voor mijn hyper-v clusters:

Guest Lan / Management twee nics per server, teamed.
iscsi Lan twee nics per server, teamed (in tegenstelling tot eerder beweerd kan dat gewoon en werkt rete stabiel)
Cluster lan een nic per server, enkel cluster verkeer.
Csv / Live migratie een nic per server.

[Question Mark]

Verwijderd schreef op zaterdag 26 januari 2013 @ 11:15:
Meer netwerk segregatie is nodig hier. Best practices schrijven voor om op zijn minst vier seperate netwerken te gebruiken (physiek seperaat, dus geen vlan geneuzel, het gaat hier om de capaciteit van de backbone).

Heb je een bron naar die best practice (waarin staat dat het geen voorkeur geniet om vlans te gebruiken)?

Ik heb net even gezocht, maar ik kom geen enkel artikel tegen waarin dit vermeld wordt. Wel kom ik een blog tegen waarin het juist aangeraden wordt. Zeker bij situaties waarin het aantal fysieke nic's beperkt is, zoals bv. bij blade oplossingen...

[Verwijderd]

Question Mark schreef op zaterdag 26 januari 2013 @ 11:50:
[...]
Heb je een bron naar die best practice (waarin staat dat het geen voorkeur geniet om vlans te gebruiken)?

Ik heb net even gezocht, maar ik kom geen enkel artikel tegen waarin dit vermeld wordt. Wel kom ik een blog tegen waarin het juist aangeraden wordt. Zeker bij situaties waarin het aantal fysieke nic's beperkt is, zoals bv. bij blade oplossingen...

Geen link, wel common sense. Het gaat vooral om bandbreedte, vlans helpen daar niet, immers het verkeer gaat nog steeds over dezelfde backbone. Vlans zijn leuk als security een overweging is, niet als (zoals in dit geval) bandbreedte het probleem is.

De setup die ik beschrijf wordt toegepast op blade servers, ik heb hetzelfde probleem meegemaakt, teveel verkeer over twee switches, zodanig dat bij een cluster join (na een reboot van een van de servers) er zoveel verkeer over die backbone ging, dat servers elkaar niet meer konden bereiken en dus VM's die gemigreerd werden en dus een reboot ondergingen. Het toevoegen van twee switches en een dual port in de blades was de oplossing, samen met het toewijden van een switch enkel voor cluster verkeer, nu draait het al 1.5 jaar probleemloos.

[ Voor 24% gewijzigd door Verwijderd op 26-01-2013 12:47 ]

[bigfoot1942]

Verwijderd schreef op zaterdag 26 januari 2013 @ 11:15:
Meer netwerk segregatie is nodig hier. Best practices schrijven voor om op zijn minst vier seperate netwerken te gebruiken (physiek seperaat, dus geen vlan geneuzel, het gaat hier om de capaciteit van de backbone).

Ik gebruik vier netwerken voor mijn hyper-v clusters:

Guest Lan / Management twee nics per server, teamed.
iscsi Lan twee nics per server, teamed (in tegenstelling tot eerder beweerd kan dat gewoon en werkt rete stabiel)
Cluster lan een nic per server, enkel cluster verkeer.
Csv / Live migratie een nic per server.

Volgens mij gebruikt de TS al geen verschillende VLANs?

Overigens, iSCSI LAN, wat bedoel je daar mee?
voor gewoon iSCSI verkeer is de manier om dit redundant en loadbalanced te krijgen MPIO. Nic teaming kan wel werken maar is zeker geen best practice, om dit te staven:

The seemingly easy answer might be to use NIC “teaming” like you do with your production network connections. However, classic NIC teaming for iSCSI connections is neither supported nor is it considered a best practice. Don’t do it.

bron: Technet (http://technet.microsoft.com/en-us/magazine/ff679916.aspx)

[Verwijderd]

bigfoot1942 schreef op zaterdag 26 januari 2013 @ 13:07:
[...]

Volgens mij gebruikt de TS al geen verschillende VLANs?

Overigens, iSCSI LAN, wat bedoel je daar mee?
voor gewoon iSCSI verkeer is de manier om dit redundant en loadbalanced te krijgen MPIO. Nic teaming kan wel werken maar is zeker geen best practice, om dit te staven:

[...]
bron: Technet (http://technet.microsoft.com/en-us/magazine/ff679916.aspx)

Ik gebruik MPIO i.s.m. met teaming. Ik beweer nergens dat TS vlans zou gebruiken, ik beweer enkel dat vlans niet helpen bij bandbreedte problemen.

[bigfoot1942]

Verwijderd schreef op zaterdag 26 januari 2013 @ 13:17:
[...]


Ik gebruik MPIO i.s.m. met teaming. Ik beweer nergens dat TS vlans zou gebruiken, ik beweer enkel dat vlans niet helpen bij bandbreedte problemen.

Wat is de meerwaarde van teaming als je toch MPIO gebruikt?

Overigens heb je helemaal gelijk mbt je VLANs verhaal, aan de andere kant kan je soms meerdere kabels gebruiker voor meerdere VLANs ipv 1 kabel per VLAN. Dan geeft een 4Gb voor 4 VLANs gemiddeld een aanmerkelijk betere performance dan 1Gb/vlan ivm overboeking

Maar voor de TS zal de grootste verbetering komen door een netwerk tbv cluster internal communicatie...

[Question Mark]

Verwijderd schreef op zaterdag 26 januari 2013 @ 12:41:
[...]

Geen link, wel common sense. Het gaat vooral om bandbreedte, vlans helpen daar niet, immers het verkeer gaat nog steeds over dezelfde backbone. Vlans zijn leuk als security een overweging is, niet als (zoals in dit geval) bandbreedte het probleem is.

Okay, maar dat is het een kwestie goed sizen en ontwerpen... Da's iets anders als roepen dat het gebruik van vlan's geen best practise is. Hoeveel netwerktouwtjes en wat voor backend/storage switches zijn is situatie afhankelijk.

Verwijderd schreef op zaterdag 26 januari 2013 @ 11:15:
Ik gebruik vier netwerken voor mijn hyper-v clusters:

iscsi Lan twee nics per server, teamed (in tegenstelling tot eerder beweerd kan dat gewoon en werkt rete stabiel).

Kan en werkt misschien wel, maar is niet supported door Microsoft. Wees je daar wel van bewust bij het "wegzetten" van produktie omvingen. Microsoft adviseert om hiervoor netjes MPIO te gaan gebruiken.

[ Voor 4% gewijzigd door Question Mark op 26-01-2013 16:58 ]

[Verwijderd]

Zo ineens druk in het topic

Heb ondertussen wat Intel NIC's gevonden waarmee ik alle servers met 2 extra poorten kan uitbreiden. Deze gaan dienen voor CSV/Live Migration en 1 voor Cluster Communicatie.

Ik gebruik nu inderdaad geen VLAN's hierin, alle switches zijn apart. Ik weet echter nog niet of ik nog 2 switches wil gaan plaatsen, het wordt dan wel erg overdone voor het gevoel. Maar ik ben toch bang dat ik er niet aan ga ontkomen

Broadcom's ga ik nog aanpassen. Ik moet echter eerst weer een zondag gaan prikken en de komende weke is het dermate druk dat dat lastig wordt. En om dit nou op een avond te gaan zitten doen, dan zal je altijd zien dat het tegenzit en het 4 uur wordt...

[ Voor 22% gewijzigd door Verwijderd op 26-01-2013 21:57 ]

[Verwijderd]

Question Mark schreef op zaterdag 26 januari 2013 @ 16:57:
[...]

Okay, maar dat is het een kwestie goed sizen en ontwerpen... Da's iets anders als roepen dat het gebruik van vlan's geen best practise is. Hoeveel netwerktouwtjes en wat voor backend/storage switches zijn is situatie afhankelijk.


[...]

Kan en werkt misschien wel, maar is niet supported door Microsoft. Wees je daar wel van bewust bij het "wegzetten" van produktie omvingen. Microsoft adviseert om hiervoor netjes MPIO te gaan gebruiken.

Miin best practices opmerking had dan ook geen directe betrekking op vlans maar op fysiek seperate netwerken. Wellicht heb ik mij niet gelukkig uitgedrukt, maar vlan seperatie helpt niet bij bandbreedte problemen, en dat was precies hetgene wat ik wilde benadrukken.

Ik gebruik mpio en gebruik teaming enkel en alleen om zo een enkel ip address voor iscsi beheer te hebben, immers teaming zorgt aan de server kant ervoor dat ik altijd een connectie heb, terwijl mpio ervoor zorgt dat ik vanuit die geteamde nic meerdere connecties maak met de op zijn minst twee nics van de vier nics op de ps6500 controller, werkt als een zonnetje.

[Turdie]

Je zou ook is in je cluster logs kunnen kijken op moment als je het quorom verliest.

How to create the cluster.log in Windows Server 2008 Failover Clustering

Understanding the Cluster Debug Log in 2008

Handling Windows Server 2008 R2 Cluster Log

[ Voor 59% gewijzigd door Turdie op 27-01-2013 02:29 ]

[bigfoot1942]

Verwijderd schreef op zaterdag 26 januari 2013 @ 21:56:
Zo ineens druk in het topic

Heb ondertussen wat Intel NIC's gevonden waarmee ik alle servers met 2 extra poorten kan uitbreiden. Deze gaan dienen voor CSV/Live Migration en 1 voor Cluster Communicatie.

Ik gebruik nu inderdaad geen VLAN's hierin, alle switches zijn apart. Ik weet echter nog niet of ik nog 2 switches wil gaan plaatsen, het wordt dan wel erg overdone voor het gevoel. Maar ik ben toch bang dat ik er niet aan ga ontkomen

CSV / Live Migation en heartbeating zou ik als volgt verdelen:
NicA: cluster use: internal, CSV prio (dmv metric) :1, LM prio 2.
NicB: cluster use: internal, CSV prio (dmv metric) :2, LM prio 1.
In principe kan je als je nog vrije poortjes op 2 non-stacked switches hebt (op verschillende UPS), deze poortjes in een apart VLAN zetten, alle NicA in switch A en nicB in switch B.
Daar zitten volgens mij geen nadelen aan...

Verwijderd schreef op zaterdag 26 januari 2013 @ 23:19:
[...]
Ik gebruik mpio en gebruik teaming enkel en alleen om zo een enkel ip address voor iscsi beheer te hebben, immers teaming zorgt aan de server kant ervoor dat ik altijd een connectie heb, terwijl mpio ervoor zorgt dat ik vanuit die geteamde nic meerdere connecties maak met de op zijn minst twee nics van de vier nics op de ps6500 controller, werkt als een zonnetje.

Leuk, Equallogic
Dan kan ik je verklappen dat dit ook niet volgens de EQL whitepapers / best-practises is.
Is het hebben van 1 ipv 2 iSCSI ip-adressen werkelijk je enige reden?
/off-topic

[ Voor 25% gewijzigd door bigfoot1942 op 27-01-2013 14:02 ]

[Verwijderd]

Een update, voor als er mensen dit topic in de search vinden.

Het aantal netwerken is uitgebreid, qua netwerk ziet het er als volgt uit nu:
Netwerk
Office LAN - 2x Cisco 3750 gekoppeld middels stack kabel
iSCSI netwerk 1 - Dell switch, jumbo packets enabled
iSCSI netwerk 2 - Dell switch, jumbo packets enabled
Cluster LAN - HP Procurve switch, VLAN 1
CSV LM LAN - HP Produrve switch, VLAN 2

Ik heb gekozen voor VLAN's omdat dat 1 switch bespaart. De switch is dusdanig laag belast dat dit geen probleem mag zijn. Live Migration kan nooit meer de Cluster communicatie in de weg zitten. Mocht de switch onverhoopt uitvallen dan mag er Cluster communicatie via het Office LAN. Dit heeft bewezen gewerkt, zolang je maar geen rare fratsen uithaalt. De omgeving is dusdanig kleinschalig dat mij dit nu afdoende lijkt.

Wat wel opvalt is dat de verbinding met het SAN niet optimaal is. Er zijn 2 kabels op 2 switches naar 2 controllers in de SAN, en de volgende instellingen kan ik terugvinden:
1. Via de Disk Management en dan de Properties van de Disk staat in het tabblad MPIO de Policy op "Round Robin with Subset"
2. Via de iSCSI Initiator bij Target -> Properties -> Identifier -> MCS de MCS policy op "Round Robin"

De 2de instelling lijkt me niet van belang, dat is instelbaar per Identifier en elke Identifier heeft slechts 1 Connection. Ik zal het dus in de eerste moeten zoeken verwacht ik.

De policy "Round Robin with Subset" heeft de volgende eigenschappen volgens MS:

Round Robin with Subset - Load balancing policy that allows the application to specify a set of paths to be used in a round robin fashion, and with a set of standby paths. The DSM uses paths from a primary pool of paths for processing requests as long as at least one of the paths is available. The DSM uses a standby path only when all the primary paths fail. For example, given 4 paths: A, B, C, and D, paths A, B, and C are listed as primary paths and D is the standby path. The DSM chooses a path from A, B, and C in round robin fashion as long as at least one of them is available. If all three paths fail, the DSM uses D, the standby path. If paths A, B, or C become available, the DSM stops using path D and switches to the available paths among A, B, and C.

Bijzonder is dat als er een hoge traffic naar het SAN is dat er slechts 1 kabel wordt gebruikt volgens de Task Manager. Je zou verwachten dat er 2 gebruikt worden.

Mijn idee is om dit nog om te zetten naar "Least Queue Depth":

Least Queue Depth - Load balancing policy that sends I/O down the path with the fewest currently outstanding I/O requests. For example, consider that there is one I/O that is sent to LUN 1 on Path 1, and the other I/O is sent to LUN 2 on Path 1. The cumulative outstanding I/O on Path 1 is 2, and on Path 2, it is 0. Therefore, the next I/O for either LUN will process on Path 2.

[bigfoot1942]

least queue depth is inderdaad te prefereren boven Round-robin, helemaal wanneer deze niet correct werkt.
Welk merk iSCSI storage gebruik je?

[Verwijderd]

bigfoot1942 schreef op woensdag 03 april 2013 @ 12:14:
least queue depth is inderdaad te prefereren boven Round-robin, helemaal wanneer deze niet correct werkt.
Welk merk iSCSI storage gebruik je?

Stond al in de OP: HP

De MPIO vereist nog wat uitzoekwerk voor mijn gevoel. Voor de rest draait het prima

[Question Mark]

Ik zou sowieso even de HP MPIO DSM installeren. Deze default naar Round Robin voor een P2000. De andere opties (volgens de HP manual):

FailOver
No load balancing is performed. There is a single active path and the rest of the paths
are standby paths. The active path is used for sending all I/O. If the active path fails then one of the
standby paths is used.

RoundRobin
All paths are active paths. They are used for sending I/O in a round-robin fashion.

RoundRobinWithSubset
In configurations where some I/O paths are faster than others, this variant of the RoundRobin policy does not distribute I/O to the slower paths, as long as at least one of the faster paths is available.

Dynlqd
Uses the path with the least number of active requests.

Weighted
Each path is assigned a weight and I/O is sent on the path with the lowest weight. If the path with the lowest weight fails, then the path with the next lowest weight is used.

LeastBlocks
Uses the path with the fewest pending I/O blocks.

Ik zou persoonlijk gaan testen met de default instelling van HP -> Round Robin. Als ik het goed begrijp uit de topicstart heb je maar 1 controller in je P2000 zitten?

[Verwijderd]

Question Mark schreef op woensdag 03 april 2013 @ 13:05:
Ik zou sowieso even de HP MPIO DSM installeren. Deze default naar Round Robin voor een P2000. De andere opties (volgens de HP manual):

[...]
Ik zou persoonlijk gaan testen met de default instelling van HP -> Round Robin. Als ik het goed begrijp uit de topicstart heb je maar 1 controller in je P2000 zitten?

Volgens mij staat de HP MPIO er al op, maar ben nu thuis en kan niet loeren (lees, geen zin in ).

Er zitten 2 controllers in de P2000, beiden via een eigen switch aangesloten naar de servers. Dus dat zou helemaal MPIO ready moeten zijn.

Ik kom alleen nog even niet uit uitvinden van de MPIO, het is me onduidelijk waar ik nou precies kan checken hoe de verbindingen lopen, welke er actief zijn en welke policy er draait. Ik weet wel zeker dat de MPIO werkte, ik heb bij het bouwen bewust kabels eruit getrokken om te kijken of e.e.a. bleef draaien.

[Question Mark]

Verwijderd schreef op woensdag 03 april 2013 @ 13:08:
[...]
Er zitten 2 controllers in de P2000, beiden via een eigen switch aangesloten naar de servers. Dus dat zou helemaal MPIO ready moeten zijn.

Nou.... It all depends...

De P2000 is geen active/active system, dat wil zeggen dat slechts 1 controller "owner" van een vdisk/lun is. Alle I/O voor een lun moet dan via die ene controller lopen...

Het is al een tijdje geleden dat ik met een P2000 gewerkt heb, maar dat is wel de reden dat ik destijds meerdere vdisks aangemaakt hebt. Op die wijze kon ik de load over de beide controllers verdelen.

[Verwijderd]

Question Mark schreef op woensdag 03 april 2013 @ 13:27:
[...]

Nou.... It all depends...

De P2000 is geen active/active system, dat wil zeggen dat slechts 1 controller "owner" van een vdisk/lun is. Alle I/O voor een lun moet dan via die ene controller lopen...

Het is al een tijdje geleden dat ik met een P2000 gewerkt heb, maar dat is wel de reden dat ik destijds meerdere vdisks aangemaakt hebt. Op die wijze kon ik de load over de beide controllers verdelen.

Niet rottig bedoeld, maar daarin zit je fout:

Reduce risk of IT failure with dual active/active controllers, dual-ported drives, and redundant hardware components.

Bron: http://www8.hp.com/us/en/...t-detail.html?oid=4118559

Die is dus zeker wel active/active. Ik denk dat een ouder type P2000 dat niet was en dat je daarmee gewerkt hebt.

[Question Mark]

Ah thx, zou kunnen dat ik inderdaad met een G2 gewerkt heb. Dat was destijds een grote beperking van het systeem...

[Verwijderd]

Question Mark schreef op woensdag 03 april 2013 @ 15:09:
Ah thx, zou kunnen dat ik inderdaad met een G2 gewerkt heb. Dat was destijds een grote beperking van het systeem...

Klopt, is ook een van de problemen die ik heb met een oude MSA1000. Had er dus bewust naar gekeken en extra geld uitgegeven aan een tweede controller. Beter nu paar honderd meer dan over 4 jaar staan te kijken en je de blubber moeten zoeken.