[Multipath] Dell MD3000i iscsi

[Verwijderd]

Ik heb een vraagje, Ik heb twee servers welke allebei via multiapath verbinding maken met een dell MD3000i (twee controllers) . Echter gebeurd er iets raars. Bijde servers maken wel verbinding, maar via multipath -ll zie ik dat wat bij de een de ghost is de ander de ready is en andersom. Weet iemand hoe dit kan, of weet iemand hoe je dit kan omdraaien op een server?

Ik gebruik debian Lenny en het filesysteem is Ext4.


Server A
-------------
[size=1.1T][features=0][hwhandler=1 rdac]
\_ round-robin 0 [prio=6][active]
\_ 1:0:0:0 sde 8:64 [active][ready]
\_ 4:0:0:0 sdd 8:48 [active][ready]
\_ round-robin 0 [prio=0][enabled]
\_ 2:0:0:0 sdc 8:32 [active][ghost]
\_ 3:0:0:0 sdb 8:16 [active][ghost]

Server B
--------------
[size=1.1T][features=0][hwhandler=1 rdac]
\_ round-robin 0 [prio=6][active]
\_ 1:0:0:0 sdc 8:32 [active][ready]
\_ 4:0:0:0 sdd 8:48 [active][ready]
\_ round-robin 0 [prio=0][enabled]
\_ 3:0:0:0 sde 8:64 [active][ghost]
\_ 2:0:0:0 sdb 8:16 [active][ghost]


Alvast bedankt

[Verwijderd]

Het probleem wat ik hierdoor ervaar is, gek genoeg alle bestanden ziet, die de ander ook zie, maar bewerk ik een bestand of voeg ik een nieuw bestand toe, dan wordt dit wel opgeslagen, alleen is het niet op de andere server terug te vinden.

[mookie]

Ik weet niet wat je precies doet, maar het lijkt erop alsof je een volume via iSCSI op 2 servers tegelijkertijd benadert.
Met iSCSI kun je dan wel 1 logische schijf vanaf 2 servers tegelijkertijd benaderen, maar dat is niet de bedoeling.
Dat is net alsof je een gewone schijf in 2 servers tegelijkertijd aanspreekt.

Je kunt dat alleen maar doen icm cluster services, en zelfs dan is er maar 1 server die echt actief op de schijf bezig is.
Als die ene uitvalt zal de 2de server in de cluster het overnemen.

Daarnaast is het zo dan aangezien je 2 controllers hebt je in principe alles over 1 controller kan laten lopen, maar het is efficienter om iedere client zijn eigen controller te geven.
Dus met 2 servers zit server 1 op controller 1 en server 2 op controller 2.
Als dan controller 1 uitvalt gaat server 1 en server 2 beide op controller 2.

[ Voor 25% gewijzigd door mookie op 06-03-2011 03:15 ]

[SpamLame]

With him ^

Verwijderd schreef op zaterdag 05 maart 2011 @ 16:06:
Het probleem wat ik hierdoor ervaar is, gek genoeg alle bestanden ziet, die de ander ook zie, maar bewerk ik een bestand of voeg ik een nieuw bestand toe, dan wordt dit wel opgeslagen, alleen is het niet op de andere server terug te vinden.

filesysteem corruptie alarm!

[erwinb]

Als het ook de bedoeling is dat beide servers gelijktijdig toegang hebben tot het zelfde LUN, dan moet je voor iSCSI eens kijken naar de tools van Tiger Technology(www.tiger-technology.com/). Zij maken de meta-Lan en Meta SAN software. hiermee kan je een LUN aanmaken op een storage systeem en dit gelijktijdig benaderen vanuit zowel server A als server B. Dit wordt vaan ik de media wereld gebruikt voor het editen van video.
Als het niet de bedoeling is dat server A en server B bij het zelfde LUN kunnen zou ik maar snel een lun-map maken waarin dit wordt geregeld.

[Verwijderd]

Bedankt voor de reacties. Ik lees nu ook op het internet inderdaad dat dit alleen met cluster filesystems mogelijk is, en ik fancing (waar ik niet op zit te wachten).

Echter ben ik zoals op het internet wel meer blijkt, door dell niet voldoende geholpen met aankoop van dit apparaat. Dell heeft een ex collega van mij dit verkocht, om met twee webservers een directory te lezen waarin de websites staan, vanaf de MD3000i. Volgens dell is dit met ext4 geen enkel probleem.

Helaas is de realiteit natuurlijk dat dit niet kan met een san. De reden waarom ik de bestanden op server b niet zie die server a schrijft, is vanwege server a gewoonweg niet doorheeft dat er iets geschreven is op de san lijkt mij. Hoorde wel dat ik caching kan uitzetten en het dan wel zou werken, echter vertrouw ik dit niet bepaald.

Ik denk persoonlijk dat ik het beste deze met een server kan verbinden en van daaruit het sharen via NFS naar de webservers toe, of weet iemand een betere mogelijkheid?

[Bigs]

Je zult inderdaad naar een cluster FS als GFS of OCFS moeten kijken om te doen wat jij wil. Dat kan prima met een MD3000i overigens.

Ik snap alleen niet waarom je de helft van je paden als ghost ziet staan. Heb je well de Dell MD Configuration Utility gebruikt om je iSCSI initiators te configureren?

[ Voor 4% gewijzigd door Bigs op 07-03-2011 14:46 . Reden: juiste tooltje noemen ]

[Verwijderd]

Daar ben ik zelf ook nog niet helemaal zeker van, maar ik vermoed zelf dat het komt omdat ik 2 controllers heb in de md3000i...

Ik heb zelf gekeken naar OCFS2, Dit lijkt mij het meest makkelijk om optezetten, en volgens mij vrijwel onderhouds vrij, omdat je deze gewoon op een "normale" manier kan mounten.

Heeft iemand meer ervaring met OSCF2 icm een dergelijk iscsi apparaat?

Ik zit een beetje met een naar mijn idee overkill apparaat, voor 2 webservers, dus wil graag het gebruiken op de minst overkille manier.

bedankt alvast

[Bigs]

Ik heb nog even gekeken, maar waar bij jou ready/ghost staat staat bij mij 'undef' op alle paden (verder staat de groep van de actieve controller active en die andere enabled, dus dat is hetzelfde). Het zal dus wel kloppen aangezien de controllers in de MD3000i afaik altijd active/passive werken en niet active/active.

[Verwijderd]

bedankt voor je reactie,

Ik heb momenteel twee opties voor ogen:

* Verbind een nieuwe server met de SAN en maak een share naar de twee webservers

* Ik gebruik OCFS2 op de twee webservers die rechtstreeks verbonden zijn aan de SAN

Wat is de meest veiligge en betrouwbare optie in dit geval? Bij optie een heb ik een single point of failure, maar bij optie twee gebruik ik een filesysteem waar ik me het senario afvraag wat er gebeurd als een node een restart doet, of uitvalt en weer aangezet wordt?

Kan iemand daar iets oververtellen of zijn ervaring vertellen?

Alvast bedankt

[Bigs]

Met optie een ben je het snelst aan de gang en zul je prima prestaties hebben. Alleen heb je inderdaad wel een single point of failure, plus je maakt niet echt gebruik van de mogelijkheden van je SAN.

Optie twee kost wat meer tijd om op zetten, maar je hebt dan wel gelijk een (2-node) cluster met centrale opslag. Je kunt dan bijvoorbeeld server 1 de services van server 2 over laten nemen bij uitval van die laatste. Mochten je uptime eisen nog hoger worden in de toekomst dan kun je er zo een 3e node bijplaatsen die passief standby staat. Wij hebben zelf een cluster op basis van de Red Hat Cluster Suite en daar kun je vrij eenvoudig je eigen services opzetten met wat scriptwerk.

Volgens mij ontkom je bij OCFS2 niet aan het opzetten van een klein cluster. Bij uitval handelt een Red Hat cluster met GFS gebeurt het volgende (ik verwacht dat OCFS2 ongeveer hetzelfde werkt op basis van wat ik heb gelezen):

* Node 1 valt uit (hetzij door stroomuitval, verbroken netwerkverbinding, kernel panic etc.)
* Node 2 ziet dit en zal node 1 proberen te fencen (rebooten) zodat hij er zeker van is dat node 1 geen gebruik van de opslag meer maakt (de nodes zijn namelijk van het cluster afhankelijk voor het afstemmen van hun locking). Fencen kan via een switched rack PDU, maar b.v. ook met de ingebouwde IPMI controller van je server. Tijdens het fencen zal node 2 niet naar het cluster schrijven.
* Zodra node 2 er zeker van is dat node 1 weg is zal hij het journal van node 1 ophalen uit het SAN en verwerken om de consistensie van het FS te waarborgen. Daarna gaat node 2 weer verder waar hij mee bezig was.
* Als node 1 gereboot is is hij in een 'clean state' en mag hij het cluster weer joinen. Bij RHCS mag een node niet terugkeren zonder reboot. Dit is een mechanisme waarmee het cluster een veilige status afdwingt.

Het klinkt allemaal heel ingewikkeld, maar in de praktijk is het allemaal eigenlijk best simpel als je het eenmaal afgericht hebt. Je hebt een SAN met dubbele voedingen, dubbele controllers en RAID schijven dus daarmee kan niet veel misgaan. Het enige wat je dan nog moet doen om een compleet redundante opstelling te hebben is het dubbel uitvoeren van het netwerk. Je begrijpt dat je dan wel een veel robuustere opstelling hebt dan bij optie 1.

Er is slechts 1 kanttekening die ik uit eigen ervaring mee kan delen: cluster bestandssystemen zijn niet efficient in het werken met grote getallen kleine bestanden (zeg duizenden Maildir directories met elk tienduizenden berichten) doordat ze hun locks over het netwerk moeten communiceren met de andere cluster nodes. Met webserving zul je echter niet zo snel tegen dit probleem aan lopen.