iSCSI multipathing (Freenas en ESXi)

[Perphide]

Ik wil graag weten hoe het zit met iSCSI en multipathing. Ik heb een Freenas systeem met een zvol welke ik via iSCSI aanbied aan ESXi. Nu hebben beide servers 2 fysieke NIC's.

Wat ik er van begrijp is dat Freenas verschillende subnets vereist wanneer er meer dan 1 fysieke NIC gebruikt wordt. En ESXi heeft twee verschillende vmkernels NIC's nodig om hiermee te verbinden.

Als ik op ESXi twee vmkernel NIC's configureer met bijvoorbeeld:
10.0.1.1 (vmk1)
10.0.2.1 (vmk2)

En dan op Freenas beide NIC's in dezelfde subnets zet:
10.0.1.2 (nic0)
10.0.2.2 (nic1)

Maar hoe configureer ik het nu juist?
Is het de bedoeling dat beide fysieke NIC's op Freenas één enkel IP krijgen, of moeten beide NIC's in twee subnets zitten?

De reden dat ik dit vraag is omdat ik mij afvraag hoe ESXi nog Freenas kan bereiken wanneer bij ESXi wellicht de fysieke NIC die aan 10.0.1.1 gekoppeld is uitvalt en tegelijk bij Freenas valt de NIC uit met IP 10.0.2.2.
Dan heb ik toch een situatie waarbij beide machines nog verbonden zijn met het netwerk via elk 1 fysieke NIC, maar ze kunnen geen data meer uitwisselen omdat ze elk in een ander subnet zitten?

Wie heeft hier meer ervaring mee en kan mij op weg helpen? Onderstaand is een lijst van reeds gelezen documentatie.
...
iscsi_design_deploy-whitepaper.pdf

https://community.spicewo...ow-iscsi-read-performance
https://www.codyhosterman...subnets-and-port-binding/
https://www.virtualizatio...i-configuration-for-mpio/
https://pubs.vmware.com/v...4C-84CE-1FCC14474D5B.html
https://blog.purestorage....h-the-vsphere-web-client/
https://wahlnetwork.com/2...net-iscsi-network-design/
...

[--WaaZaa--]

Geen ervaring met Freenas, maar wel iscsi setups met NetApp en Dell storage dozen.

Het idee is dat je echt meerdere paden maakt, zodat als er iets op dat pad niet werkt, je een compleet ander pad hebt waarover je verkeer alsnog kan doen. Als je het goed doet pak je ook fysiek andere switches / kabels om de koppelingen te maken.

Daarom altijd hiermee: 1 NIC, 1 IP.

Ik heb ooit ergens wel een bond interface aangemaakt met hierin 2 fysieke interfaces, waarop een tweetal sub interfaces pas een IP hadden als iscsi target. Het is een hoop gehannes met 'mitsen en maren', maar het kán wel. bv NetApp ondersteunt het wel, maar het is echt afhankelijk van je usecase

[Paul]

iSCSI connect met een IQN, niet een IP-adres. Onder water zit natuurlijk wel een IP-verbinding (en mogelijk moet je bij het initieel instellen wel een IP opgeven om de boel op gang te krijgen) maar die gegevens worden uitgewisseld tussen de initiator en de target.

Als twee NICs tegelijk uitvallen dan heb je twee errors tegelijkertijd. Dat is een situatie die wel valt op te lossen, maar dat vergt een heel grondig design, want twee NICs zijn niet de enige dingen die stuk kunnen. En als je beide nics op één switch aansluit dan is die ene switch een SPOF.

Je kunt met VLANs wel meerdere interfaces / vmKernels aanmaken en/of verkeer over meerdere paden sturen zonder dat je meer fysieke paden hebt, maar de vraag is of dat het waard is. Zo vaak gaan twee nics ook niet tegelijkertijd stuk, en dan ook nog eens in dat ene patroon (één per server, kruislings) dat dataverkeer stopt terwijl er in theorie wel iets mogelijk zou zijn geweest. Dan is de kans groter dat beide NICs in één server er mee stoppen, of de switch tussen twee NICs.

[Perphide]

@--WaaZaa-- ik begrijp helemaal wat je bedoeld, dat is ook de setup die ik in eerste instantie begreep te moeten maken.

@Paul helemaal mee eens dat het zeer onwaarschijnlijk is dat er twee nics tegelijk uitvallen en dat dat precies kruislings is waardoor beide machines nog wel 1 nic hebben, maar niet meer in elkaars subnet zitten.

Wat is jullie advies als ervaringsdeskundige?
Moet ik het laten bij 2 nics op elk een eigen ip/subnet op beide machines. Of is het advies om beide subnets te kunnen bereiken op elke nic?

[Paradox]

lees dit kb eens, https://kb.vmware.com/s/article/2045040

je maakt inderdaad 1 op 1 mappings aan.
dus als er op 2 plekken iets fout gaat doet niets het meer dat klopt.
je bouwt redundancy met mpio maar er is altijd een kans dat iets niet meer werkt.

vmk1 in vmware met 1 uplink naar de iscsi ip van je nas
vmk2 in vmware met 1 uplink naar de iscsi2 ip van je nas.
verspreid over 2 switches.

[Paul]

Mijn enige ervaring met IP-bases storage is vSAN (waarbij redundancy op vSwitch niveau geregeld wordt) en dingen die binnen de machine blijven. Bij Fiber Channel is het 100% gescheiden. Een HBA kan maar bij één fabric, de andere HBA bij het andere fabric, en die twee hebben geen koppeling.

Ik zou op FreeNAS twee interfaces aanwijzen en ieder een eigen subnet geven. Idem aan de vSphere kant, twee vmKernels, ieder in één van die subnetten.

Het stuk tussen de vmKernel en FreeNAS hangt af van hoeveel en welke switches je gebruikt

[Perphide]

@Paul , @Paradox en @--WaaZaa-- alle drie ontzettend bedankt voor deze bevestiging en verdere utileg. Ik heb er nu geen twijfel meer over. Ik ga het configureren en bekijken hoe het resultaat uitpakt. Super bedankt!

[Vorkie]

en met round-robin policy niet vergeten! IOPS naar 1.

https://kb.vmware.com/s/article/2069356

[Perphide]

@Vorkie Dat is een goeie, dat had ik ergens gelezen maar niet paraat om te gaan instellen. Bedankt daarvoor.

[Paradox]

Vorkie schreef op woensdag 22 april 2020 @ 18:37:
en met round-robin policy niet vergeten! IOPS naar 1.

https://kb.vmware.com/s/article/2069356

ook niet vergeten, je path policy in je software iscsi te regelen officieel een uplink per vmkernel

[Perphide]

Ik zie nu iets wat ik niet verwacht had, wie weet dat jullie dit wel begrijpen:

Ik heb 2 vmkernels, beide gekoppeld aan 1 nic (2e nic unused).
Beide vmkernels in een eigen subnet.
Beide vmkernels toegewezen aan 1 uplink van een dSwitch.

Ik had 2 actieve paden.
Nu pas ik als laatste stap port binding toe, beide interfaces geselecteerd op de vmbha interface van Esxi.
Nu ineens heb ik toch 4 paden.

Dit laatste had ik niet verwacht. Dit geeft mij de indruk dat ik nu toch alsnog vanaf elke nic bij elk subnet kan komen?


@Paradox Dankjewel voor je toevoeging. Ik denk dat ik begrijp wat je bedoeld, ik weet het niet helemaal zeker. Maar ik meen dat je bedoeld de multipathing policy? Ik heb deze op round robin gezet en dan zie ik vervolgens bij 4 paden Active I/O staan i.p.v. bij slechts 1 van de 4.

[ Voor 10% gewijzigd door Perphide op 22-04-2020 21:32 ]

[Paul]

Als beide NICs in een ander subnet zitten moet je geen port binding doen
https://kb.vmware.com/s/article/2038869

In this sample scenario, there are multiple VMkernel ports in on different IP subnets and broadcast domains and the target ports also reside in a different IP subnet and broadcast domain. In this case, you should not use port binding.If you configure port binding in this configuration, you may experience these issues:
[..]
- Incorrect number of paths are seen per device.

Port binding is een manier om in één subnet (op twee poorten) toch te kunnen multipathen

Daarnaast heb je maar één fysieke adapter; dan moet je eigenlijk ook maar één (iSCSI) vmkernel aanmaken.

[Perphide]

@Paul Dankjewel, heb het gelijk weer aangepast en dan zijn er weer 2 paths zoals verwacht.

Wat een super fijne en goed hulp hier op het forum, dank aan jullie allen

[_-= Erikje =-_]

Vorkie schreef op woensdag 22 april 2020 @ 18:37:
en met round-robin policy niet vergeten! IOPS naar 1.

https://kb.vmware.com/s/article/2069356

Niet perse noodzakelijk hoor, meer afhankelijk van de storage die je gebruikt; Bij onze M//20 bijvoorbeeld is de recommendation om 'm gewoon default te laten staan (dan trekt ie ook met gemak 2x 10Gbit dicht)

[Vorkie]

_-= Erikje =-_ schreef op woensdag 29 april 2020 @ 10:35:
[...]

Niet perse noodzakelijk hoor, meer afhankelijk van de storage die je gebruikt; Bij onze M//20 bijvoorbeeld is de recommendation om 'm gewoon default te laten staan (dan trekt ie ook met gemak 2x 10Gbit dicht)

Nee, maar het gaat over FreeNAS i.c.m. ESX en in de best practices die ik vindt over FreeNAS staat dat je hem naar 1 zet.

Verder staat het er ook duidelijk, bij VMWare,

Adjusting the limit can provide a positive impact to performance and is recommended by some storage vendors to change IOPS limit to 1.