Linux HA Storage

[Steven-b]

Hoi!

Ik weet dat ik niet zo vaak post op het forum maar hier ben ik dan weer
Alsook zal ik er al maar meteen bij vermelden dat mijn kennis over Linux ondermaats is voor hetgene ik eigenlijk wil hebben maar ik hou wel van een uitdaging

Ik heb een test omgeving beschikbaar met volgende hardware:

Intel Server Board S2600CP4
2x Intel E5-2620V2 (6C/12T)
64GB DDR3 REG ECC RAM (4x 16GB)
Intel HW RAID RMS25PB080
Maintenance Free Backup Unit
4x 900GB 10K SAS2 (RAID 10)
3x Intel X540-T2 10GBIT adapters.

Hiervan heb ik uiteraard zoals het topic al aangeeft 2 nodes.
Ik heb hierop Hyper-V staan als Hypervisor, met aan beide zijde 2x CentOS 7 hierop staat geinstalleerd:

DRBD, Targetcli, Corosync, Pacemaker, PCS

Met deze installatie wil ik een "High Available ISCSI Storage" omgeving maken, om te beginnen met Active-Passive en later als ik het wat beter onder de knie heb Active-Active.

Nu het opzetten van de gehele omgeving is me gelukt (Thanks Google) op een paar issues na.

Ik heb de Active-Passive draaien, zonder mulitpath op dit moment ofzo, met 1 virtueel IP verbonden aan een 10GBIT switch in Hyper-V en deze op zijn manier verbonden naar de fysieke netwerkadapter.

Als ik nu de netwerkverbinding verbreek dan heb ik 1x maal een mooie failover gehad zonder manueele tussenkomst van mezelf.

Eenmaal de netwerkverbinding terug actief op de node in kwestie probeerde ik dit aan de andere kant maar helaas hij moved zijn resources niet...

Als ik dan de cluster manueel failover gaat dit wel en als ik dezelfde handeling toepaste was het ook nougabolle er gebeurde dus niets meer. (Ik heb al het 1 en ander gaan opzoeken over Heartbeat, hier zal ik mogelijks later dieper op in moeten gaan veronderstel ik.)

Maar ook heb ik het probleem dat ik op het DRBD niveau de disk /dev/sbd1 heb gekoppeld aan /dev/drbd0...

Nu als ik 1 van de 2 nodes reboot komt dit volume niet automatisch online, ik heb de betreffende filters toegepast in LVM, deze werken wel want hij scant zijn sdb1 partitie niet meer maar het drbd0 volume komt er nog steeds niet automatisch op te staan.

Alsook start drbd etc etc etc allemaal automatisch op tijdens het opstarten, want uiteraard komt het drbd0 volume alleen maar online als DRBD zelf actief is en de resources up zijn.

Toch eenmaal alles online is moet ik manueel een pvscan --cache commando uitvoeren vooraleer dit volume beschikbaar is en daarna kan ik gewoon weer verder...

Ik heb al vaak gelezen over timing issues etc etc etc, iets over dracuta -f (Ik weet niet goed wat dit doet, ik heb het al wel geprobeerd maar dit bracht geen oplossing)

Als kers op de taart verbind ik het ISCSI volume met een client welke ook 10GBIT nics heeft en Jumbo frames aangepast naar 9000 voor Linux en 9014 voor Windows merk ik op dat de performance van de betreffende iSCSI disk (Met HDTune, Ik weet dat dit mogelijks niet representatief is maargoed) echt slecht is, ik haal een read van +/- 60MB/s terwijl als ik op de host zelf een performance test ga doen op de de fysieke RAID set hier een goeie 250 a 300MB/s haal zonder problemen.


Hopelijk hebben jullie raad wat ik met deze issues kan aanvangen, uiteraard ben ik mezelf er vol op in aan't verdiepen maar aangezien mijn kennis niet sky-high is haal ik er nu toch wel wat hulp bij...

Verder zit ik er niet echt mee in om veel Try & Error te doen of de omgeving een aantal keer opnieuw op te zetten, ik ben al ver gekomen met de handleidingen op Linbit & Clusterlabs maar ikzelf ken helaas geen Linux engineers die ik onder vuur kan leggen met al mijn vragen.

Ik maak ook deze post om vooral ook naar andere ervaringen te luisteren in verband met High Available Storage over iSCSI liefst omdat ik me geen FiberChannel kan permitteren en ik heb het ook niet zomaar liggen op het werk

Er zullen ongetwijfeld ook mensen zijn die me doorverwijzen naar Open-E Ik zal er alvast bij vermelden dat ikzelf dit product ken en ook een OECE (Open-E Certified Engineer) voor DSSV7 ben.
Dit is een goed product, maar ik zou graag meer kennis hebben over wat er onder de motorkap draait en wat er eigenlijk allemaal wel en niet kan, dit kan dus niet bij Open-E , je krijgt een mooie web interface en je kan wat instellingen tweaken maar je krijgt geen echte toegang tot de command line (wat ik ook wel begrijp uiteraard.)

Ik hoop alvast te leren van de verschillende ervaringen die andere mensen hebben met dit onderwerp.

Mvg,
Steven

[CAPSLOCK2000]

Concrete tips voor je problemen heb ik niet, daarvoor is je informatie niet gedetailleerd genoeg, maar dat was volgens mij ook niet je bedoeling.

Mijn algemene tip is om het een keer helemaal opnieuw te doen. Mijn ervaring is dat je tijdens het experimenteren onbewust kleine veranderingen doet waar je later last van krijgt. Een keertje vers inrichten voorkomt dat soort ellende.

iSCSI zal nooit zo snel zijn als een lokale disk maar beter dan dit moet wel kunnen.
Ik zou beginnen met eerst het netwerk te testen. 10gbit wordt nog niet heel veel gebruikt. Controleer dus eerst of je hardware het wel aan kan. Je zou niet de eerste zijn met een slechte driver of ondermaatse netwerkkabel.

DRBD heb ik goede ervaringen mee maar heel snel is het niet.

Waarom is het niet goed dat "/dev/sbd1 heb gekoppeld aan /dev/drbd0"? Moet het een andere disk zijn, een andere drbd-device of nog iets anders?

Waarom heb je Windows een andere instelling voor Jumbo Frames gegeven dan Linux? jumbo's moeten overal hetzelfde zijn. Je hebt geluk, het maximum is 9000, waarschijnlijk rond Windows het nu al af naar 9000.

Ik heb geen idee hoe goed de performance van Linux onder Hyper-V tegenwoordig is. Ooit was dat best duur.

Overigens, is het je doel om hier productie op te gaan draaien?
Gebrek aan evaring en High-Availability zijn geen handige combinatie
Ik ga er maar van uit dat je dit doet om er van te leren.

[Steven-b]

CAPSLOCK2000 schreef op vrijdag 16 oktober 2015 @ 15:48:
Concrete tips voor je problemen heb ik niet, daarvoor is je informatie niet gedetailleerd genoeg, maar dat was volgens mij ook niet je bedoeling.

Mijn algemene tip is om het een keer helemaal opnieuw te doen. Mijn ervaring is dat je tijdens het experimenteren onbewust kleine veranderingen doet waar je later last van krijgt. Een keertje vers inrichten voorkomt dat soort ellende.

--> Daar dacht ik ook aan, ik heb inderdaad wel het één en ander aan het veranderen geweest


iSCSI zal nooit zo snel zijn als een lokale disk maar beter dan dit moet wel kunnen.
Ik zou beginnen met eerst het netwerk te testen. 10gbit wordt nog niet heel veel gebruikt. Controleer dus eerst of je hardware het wel aan kan. Je zou niet de eerste zijn met een slechte driver of ondermaatse netwerkkabel.

--> De 10GBIT connectie fysiek is volledig in orde HW wordt volledig ondersteunt


DRBD heb ik goede ervaringen mee maar heel snel is het niet.

--> Hoe bedoel je precies niet snel? Hey syncen gaat bij mij vrij vlotjes heb ik de indruk.


Waarom is het niet goed dat "/dev/sbd1 heb gekoppeld aan /dev/drbd0"? Moet het een andere disk zijn, een andere drbd-device of nog iets anders?

--> Nee het is wel goed dat het drbd0 volume is gekoppeld aan sdb1, maar het probleem is wanneer alles online komt bij mij na een reboot dit drbd0 volume niet automatisch opkomt, dit gebeurt pas na een pvscan --cache commando, als ik bv failover moet ik dit commando de eerste keer ook uitvoeren op de andere server of mijn betreffende volume komt gewoon niet online met als gevolg dat ik dus niet aan mijn data kan.

Waarom heb je Windows een andere instelling voor Jumbo Frames gegeven dan Linux? jumbo's moeten overal hetzelfde zijn. Je hebt geluk, het maximum is 9000, waarschijnlijk rond Windows het nu al af naar 9000.

--> Ik heb al ondervonden dat als ik de Jumbo Frames overal gelijk zet deze gefragmenteerd zijn, wanneer ik ze op Linux op 9000 zet en in windows op 9014 dan gebeurt dit niet en is alles ok, ik heb bv ook nog een 10GBIT switch waar ze op 9216 moeten staan om overeen te komen met 9014 in windows en 9000 in Linux... waarom dit precies zo is weet ik niet maar het doet 't em wel

Ik heb geen idee hoe goed de performance van Linux onder Hyper-V tegenwoordig is. Ooit was dat best duur.

--> wel de performance op zich lijkt mij nog wel Ok

Overigens, is het je doel om hier productie op te gaan draaien?

--> Met CentOS, DRBD etc apart? Neen geen productie daarvoor heb ik iets te weinig kennis op dit moment om echt alles apart te managen, we hebben wel zelf Open-E A/A Clusters draaien bij klanten in productie met Hyper-V omgevingen dit gaat goed.

Gebrek aan evaring en High-Availability zijn geen handige combinatie
Ik ga er maar van uit dat je dit doet om er van te leren.

--> absoluut

[Blokker_1999]

euhm, snelle vraag want ik kan niet goed aan de uitleg aan uit: heb je je drbd gebouwd op een LVM volume, of heb je je drbd gebruikt als physiek apparaat om een LVM op te bouwen?

[CAPSLOCK2000]

Splits voortaan je quotes aub in losse blokjes met je antwoorden er tussen in plaats van je eigen antwoorden binnen de quote te zetten. Zo is het moeilijk te lezen.

Ik heb geen idee wat je uitspookt met je jumbo frames maar een framesize 9216 is uitzonderlijk. Doe je stiekem nog iets met FCoE (al dan niet virtueel)?

Bij DRBD maakt de configuratie erg veel uit voor de performance. Als DRBD asynchroon draait zal het wel lekker snel zijn maar synchroon kost het aardig wat performance, alles moet immers door 2 disks worden gedaan dan is er altijd eentje net iets langzamer dan de andere en er komt ook nog de netwerkvertraging bij.
Dat kost al snel tientallen procenten aan performance.

[Steven-b]

Blokker_1999 schreef op zaterdag 17 oktober 2015 @ 13:27:
euhm, snelle vraag want ik kan niet goed aan de uitleg aan uit: heb je je drbd gebouwd op een LVM volume, of heb je je drbd gebruikt als physiek apparaat om een LVM op te bouwen?

Ik heb drbd gebruikt als fysiek apparaat om een LVM op te bouwen.
Ik heb dus eerst sdb1 die verberg ik in de LVM filter en nadat mijn drbd resource up zijn gebruik ik pvcreate waarin drbd0 verwijst naar sdb1

[Steven-b]

CAPSLOCK2000 schreef op zaterdag 17 oktober 2015 @ 14:40:
[mbr]Splits voortaan je quotes aub in losse blokjes met je antwoorden er tussen in plaats van je eigen antwoorden binnen de quote te zetten. Zo is het moeilijk te lezen.[/mbr]

Ik heb geen idee wat je uitspookt met je jumbo frames maar een framesize 9216 is uitzonderlijk. Doe je stiekem nog iets met FCoE (al dan niet virtueel)?

Bij DRBD maakt de configuratie erg veel uit voor de performance. Als DRBD asynchroon draait zal het wel lekker snel zijn maar synchroon kost het aardig wat performance, alles moet immers door 2 disks worden gedaan dan is er altijd eentje net iets langzamer dan de andere en er komt ook nog de netwerkvertraging bij.
Dat kost al snel tientallen procenten aan performance.
[/quote]

De jumbo frames met een framesize 9216 is inderdaad met FCoE (Als er switches tussen zitten op 10GBIT tenminste)

Asynchroon heb ik nog niet echt getest, ik gebruik altijd het Protocol C (synchroon) en ik merk toch dat dit vrij vlotjes gaat, doe dit uiteraard over een dedicated verbinding dus sowieso heb je er al niet veel last van...

[DSK]

Als ik het goed begrijp heb je eigenlijk twee problemen:
- Na een restore na failover gaan de actieve resources niet terug naar de eerste nodig (die terug op is).
-> Het lijkt me ergens mis te gaan met de colocation constraints (storage volgt de andere resources misschien niet).
- Bij het starten gaat iets mis waardoor de resources niet automatisch beschikbaar komen.
Geen idee waar dit aan kan liggen (wel best jouw /dev/drbd0 niet rechtstreeks aan een fysiek device of LV koppelen, altijd een subfolder). Tot een tijd terug was er icm. systemd wel een bug die het goed starten van Corosync verhinderde (bugzilla 1030583). Workaround was het starten 10s uit te stellen: (ExecStartPre=/usr/bin/sleep 10 in de Systemd-service file bij [Service])

Kijk anders hier eens voor wat meer info. In het verleden ben ik er best wel intensief mee bezig geweest:
http://jensd.be/156/linux...th-pacemaker-corosync-pcs
http://jensd.be/186/linux...and-pacemaker-on-centos-7

Zelf heb ik goede ervaring met Corosync icm. een Gluster-volume. DRBD levert, naar mijn mening, te vaak configuratieproblemen op en zeker bij het switchen tussen nodes gaat het wel al eens mis.

De applicatielaag (jouw iSCSI-server) vertrouw je toe aan Corosync en Pacemaker en de storage daarvoor regel je met Gluster. Een Gluster volume opzetten is belachelijk eenvoudig en best wel robuust. Voor mij voelt dit, na veel nare ervaringen met DRBD, een stuk beter aan.

Hou er ook rekening mee dat Active-active met Corosync niet altijd eenvoudig is omdat er gebruik gemaakt wordt van Multicast Mac adressen.