CentOS Cluster

[DennusB]

Hoi Tweakers,

Ik heb hier een proefopstelling met 2x Centos 6.4 die in een cluster zitten. De cluster.conf (/etc/cluster/cluster.conf) ziet er op beide machines zo uit :

code:

<?xml version="1.0"?>
<cluster name="dbcluster" config_version="10">

  <cman two_node="1" expected_votes="1"/>
  <clusternodes>
    <clusternode name="test1" votes="1" nodeid="1">
      <fence>
        <method name="single">
        </method>
      </fence>
    </clusternode>
    <clusternode name="test2" votes="1" nodeid="2">
      <fence>
        <method name="single">
        </method>
      </fence>
    </clusternode>
  </clusternodes>

  <fencedevices>
  </fencedevices>


        <rm>
        <failoverdomains>
        <failoverdomain name="DB" nofailback="0" ordered="1" restricted="0">
               <failoverdomainnode name="test1" priority="1"/>
               <failoverdomainnode name="test2" priority="2"/>
           </failoverdomain>
        </failoverdomains>
        <resources/>
        <service autostart="1" domain="db" exclusive="0" name="IP" recovery="relocate">
                <ip address="IPADDR" monitor_link="on" sleeptime="3"/>
        </service>
        </rm>

</cluster>

Dit werkt want ze zitten samen in een cluster :

Cluster Status for dbcluster @ Mon Jun 24 12:02:27 2013
Member Status: Quorate

Member Name ID Status
------ ---- ---- ------
test1 1 Online, rgmanager
test2 2 Online, Local, rgmanager

Service Name Owner (Last) State
------- ---- ----- ------ -----
service:IP test1 started

Dit werkt prima. Zodra het shared IP aan test 1 hangt en ik geef deze netjes een shutdown (shutdown -h) dan moved hij het gedeelde IP gelijk naar test2. Maaaaar, zodra ik de test1 machine gewoon abrupt uitzet (dat is tenslotte waarschijnlijk ook hoe het het in het echt gaat bij problemen) gebeurt er niks. Hij ziet dat hij offline is gegaan en zet dit in de log :

Jun 24 11:59:13 test2 corosync[1421]: [TOTEM ] A processor failed, forming new configuration.
Jun 24 11:59:15 test2 kernel: dlm: closing connection to node 1
Jun 24 11:59:15 test2 corosync[1421]: [QUORUM] Members[1]: 2
Jun 24 11:59:15 test2 corosync[1421]: [TOTEM ] A processor joined or left the membership and a new membership was formed.
Jun 24 11:59:15 test2 corosync[1421]: [CPG ] chosen downlist: sender r(0) ip(IPADDR) ; members(old:2 left:1)
Jun 24 11:59:15 test2 corosync[1421]: [MAIN ] Completed service synchronization, ready to provide service.
Jun 24 11:59:15 test2 rgmanager[2688]: State change: test1 DOWN
Jun 24 11:59:15 test2 fenced[1477]: fencing node test1

Maar het gedeelde IP word niet naar test2 gezet. Ik heb Google al ondersteboven gekeerd en m'n config 10x nagekeken maar ik zie het probleem niet. Iemand hier die tips heeft of weet wat er fout gaat?

[Cidolfas]

Gaat het fencen wel goed dan?

De nog actieve node ziet inderdaad wel dat de andere node er niet meer is, maar hij kan er niet zeker van zijn dat de andere node ook echt dood is.

[ Voor 72% gewijzigd door Cidolfas op 24-06-2013 16:17 ]

[blaataaps]

2 nodes is geen cluster, en daardoor is in een 2-node "cluster" een quorum van 2 nodes nodig. Als je een server uitzet, is er geen quorum meer, en gaan je services terecht offline.
Je kunt dit fixen door een compleet cluster te bouwen, of no-quorum-policy=ignore activeren.

[silentsnake]

blaataaps schreef op maandag 24 juni 2013 @ 20:30:
2 nodes is geen cluster, en daardoor is in een 2-node "cluster" een quorum van 2 nodes nodig. Als je een server uitzet, is er geen quorum meer, en gaan je services terecht offline.
Je kunt dit fixen door een compleet cluster te bouwen, of no-quorum-policy=ignore activeren.

Dit is niet waar, je kan prima een twee node cluster maken, wat ook aangegeven wordt door de "two_nodes" parameter. Dan kan één node nogsteeds een quorum hebben. Immers staat expected_votes op 1, dus er moet minimaal 1 vote zijn om quorum te hebben (dus maar 1 node).

Jun 24 11:59:15 test2 fenced[1477]: fencing node test1

Als dit de laatste log regel is heeft Cidolfas het denk ik bij het juist eind. Aangezien je geen fence agents heb gespecificeerd weet het cluster niet wat ie moet doen. Als je geen fencing wil moet je fence_manual als fence agent opgeven, of een scriptje dat een status code 0 terug geeft.

Let wel op dat fencing niet voor niets bestaat - als allebei de nodes het virtuele IP address aan gaan nemen omdat node 1 denkt dat node 2 dood is terwijl node2 nog leeft heb je natuurlijk een IP conflict te pakken, om maar eens een voorbeeld te noemen. Het is dus zeer zeker aan te raden om fatsoenlijke fencing te configureren.

Mocht je geen LOM hebben (bijvoorbeeld DRAC / ILO) of een remote power switch kan je altijd IPMI gebruiken - de meeste Dell / HP servertjes hebben een IPMI agent die je kan gebruiken om een remote reset / poweroff te doen buiten het OS om.

Waar je wel op moet letten bij een twee node cluster is de mogelijkheid van een split-brain. Als de cluster heartbeat om wat voor reden dan ook niet meer kan plaats vinden bestaat de kans dat de nodes elkaar op exact hetzelfde moment gaan fencen. Je hele cluster gaat dan dus down. Dit kan je voorkomen door een quorum disk te hebben die wel redundant is (denk aan een HA iSCSI of Fibre Channel verbinding). De quorum disk is dan de tie breaker in geval van een split brain en kan dus bepalen welke node er gefenced gaat worden.

Een andere manier zonder quorum disk is je cluster heartbeat over twee NICs per server te laten lopen en daar een bond van te maken. Eventueel met cross kabels zodat je geen dependency heb op je netwerk switch.

Als je nog meer vragen hebt laat het weten!

[blaataaps]

silentsnake schreef op maandag 24 juni 2013 @ 22:09:
[...]


Dit is niet waar, je kan prima een twee node cluster maken, wat ook aangegeven wordt door de "two_nodes" parameter. Dan kan één node nogsteeds een quorum hebben. Immers staat expected_votes op 1, dus er moet minimaal 1 vote zijn om quorum te hebben (dus maar 1 node).

2 nodes kan inderdaad wel, als je daarvoor corrigeert in je quorumberekening. Ik had de two_node over het hoofd gezien en tevergeefs gezocht naar de no-quorum-policy-optie en nam aan dat dat niet gebeurd was

[Hero of Time]

silentsnake schreef op maandag 24 juni 2013 @ 22:09:
Een andere manier zonder quorum disk is je cluster heartbeat over twee NICs per server te laten lopen en daar een bond van te maken. Eventueel met cross kabels zodat je geen dependency heb op je netwerk switch.

Als de machines 't hebben, kan je ook een seriële kabel gebruiken voor heartbeat. Desnoods als extra. Op school werd dit door een studentengroepje ook gedaan tussen de fileservers. Twee machines, een deed iSCSI, de ander NFS, gekoppeld met een GB link voor data sync met heartbeat en een seriële kabel als extra zekerheid. Een tweede NIC in de systemen ging naar de switches.

[DennusB]

silentsnake schreef op maandag 24 juni 2013 @ 22:09:
[...]


Dit is niet waar, je kan prima een twee node cluster maken, wat ook aangegeven wordt door de "two_nodes" parameter. Dan kan één node nogsteeds een quorum hebben. Immers staat expected_votes op 1, dus er moet minimaal 1 vote zijn om quorum te hebben (dus maar 1 node).


[...]


Als dit de laatste log regel is heeft Cidolfas het denk ik bij het juist eind. Aangezien je geen fence agents heb gespecificeerd weet het cluster niet wat ie moet doen. Als je geen fencing wil moet je fence_manual als fence agent opgeven, of een scriptje dat een status code 0 terug geeft.

Let wel op dat fencing niet voor niets bestaat - als allebei de nodes het virtuele IP address aan gaan nemen omdat node 1 denkt dat node 2 dood is terwijl node2 nog leeft heb je natuurlijk een IP conflict te pakken, om maar eens een voorbeeld te noemen. Het is dus zeer zeker aan te raden om fatsoenlijke fencing te configureren.

Mocht je geen LOM hebben (bijvoorbeeld DRAC / ILO) of een remote power switch kan je altijd IPMI gebruiken - de meeste Dell / HP servertjes hebben een IPMI agent die je kan gebruiken om een remote reset / poweroff te doen buiten het OS om.

Waar je wel op moet letten bij een twee node cluster is de mogelijkheid van een split-brain. Als de cluster heartbeat om wat voor reden dan ook niet meer kan plaats vinden bestaat de kans dat de nodes elkaar op exact hetzelfde moment gaan fencen. Je hele cluster gaat dan dus down. Dit kan je voorkomen door een quorum disk te hebben die wel redundant is (denk aan een HA iSCSI of Fibre Channel verbinding). De quorum disk is dan de tie breaker in geval van een split brain en kan dus bepalen welke node er gefenced gaat worden.

Een andere manier zonder quorum disk is je cluster heartbeat over twee NICs per server te laten lopen en daar een bond van te maken. Eventueel met cross kabels zodat je geen dependency heb op je netwerk switch.

Als je nog meer vragen hebt laat het weten!

Nee dat is niet de laatste regel, in de laatste regels laat hij 3x weten dat hij kan niet kan gaan fencen. Misschien begrijp ik het gewoon nog niet helemaal goed, dat fencen zorgt toch voor gedeelde services?

[Cidolfas]

DennusB schreef op dinsdag 25 juni 2013 @ 07:44:
[...]


Nee dat is niet de laatste regel, in de laatste regels laat hij 3x weten dat hij kan niet kan gaan fencen. Misschien begrijp ik het gewoon nog niet helemaal goed, dat fencen zorgt toch voor gedeelde services?

Nee, fencing zorgt er voor dat een bepaalde node 100% zeker kan zijn dat hij de enige is die de gedeelde resource actief heeft.

Stel je hebt twee nodes, node A en node B. Deze nodes controleren van elkaar of ze nog actief zijn middels heartbeat over een netwerk.

In jou voorbeeld is de gedeelde resource een virtueel ip nummer (VIP). Deze mag maar op 1 node tegelijk actief zijn, anders heb je een dubbel IP nummer conflict op je netwerk.

Het VIP is in eerste instantie actief op node A. Als je deze node A uit zet zal node B dat zien, omdat node A niet meer op heartbeat reageert.

Echter, hoe weet je zeker dat node A uit is? Als het heartbeat netwerk uitvalt heb je immers dezelfde situatie. Ook dan zullen de nodes elkaar niet meer zien, maar is node A en dus het VIP nog gewoon online.

Voordat node B dus kan besluiten om het VIP adres actief te maken op node B, moet hij 100% zeker zijn dat node A het VIP niet meer in gebruik heeft. Alleen heartbeat is daar dus niet genoeg voor.

Daarom is fencing bedacht. Node B kan node A fencen, wat normaal een manier is om er voor te zorgen dat de node niet meer bij de gedeelde resource kan. In de meeste gevallen gebruikt men dan een power management interface (zoals te vinden in iLO etc..) om de hele server uit te zetten.

Dus node B sluit node A uit (fencing), en weer daarom zeker dat hij het VIP veilig kan claimen en activeren.

Als je hier mee verder gaat moet je dus ook rekening houden met een fence delay op een van de nodes. Als beide nodes elkaar tegelijk niet meer zien (heartbeat netwerk valt uit) wil je niet dat ze allebei tegelijk gaan fencen, want dan staan daarna beide servers uit

[DennusB]

Cidolfas schreef op dinsdag 25 juni 2013 @ 15:41:
[...]


Nee, fencing zorgt er voor dat een bepaalde node 100% zeker kan zijn dat hij de enige is die de gedeelde resource actief heeft.

Stel je hebt twee nodes, node A en node B. Deze nodes controleren van elkaar of ze nog actief zijn middels heartbeat over een netwerk.

In jou voorbeeld is de gedeelde resource een virtueel ip nummer (VIP). Deze mag maar op 1 node tegelijk actief zijn, anders heb je een dubbel IP nummer conflict op je netwerk.

Het VIP is in eerste instantie actief op node A. Als je deze node A uit zet zal node B dat zien, omdat node A niet meer op heartbeat reageert.

Echter, hoe weet je zeker dat node A uit is? Als het heartbeat netwerk uitvalt heb je immers dezelfde situatie. Ook dan zullen de nodes elkaar niet meer zien, maar is node A en dus het VIP nog gewoon online.

Voordat node B dus kan besluiten om het VIP adres actief te maken op node B, moet hij 100% zeker zijn dat node A het VIP niet meer in gebruik heeft. Alleen heartbeat is daar dus niet genoeg voor.

Daarom is fencing bedacht. Node B kan node A fencen, wat normaal een manier is om er voor te zorgen dat de node niet meer bij de gedeelde resource kan. In de meeste gevallen gebruikt men dan een power management interface (zoals te vinden in iLO etc..) om de hele server uit te zetten.

Dus node B sluit node A uit (fencing), en weer daarom zeker dat hij het VIP veilig kan claimen en activeren.

Als je hier mee verder gaat moet je dus ook rekening houden met een fence delay op een van de nodes. Als beide nodes elkaar tegelijk niet meer zien (heartbeat netwerk valt uit) wil je niet dat ze allebei tegelijk gaan fencen, want dan staan daarna beide servers uit

Dat klinkt logisch Bedankt voor de uitgebreide uitleg. Heb jij voor mij een voorbeeld van een VIP in zo'n Fence constructie? Op internet kan ik heel veel voorbeelden vinden, maar niet met een VIP!

[Cidolfas]

DennusB schreef op woensdag 26 juni 2013 @ 07:58:
[...]


Dat klinkt logisch Bedankt voor de uitgebreide uitleg. Heb jij voor mij een voorbeeld van een VIP in zo'n Fence constructie? Op internet kan ik heel veel voorbeelden vinden, maar niet met een VIP!

Het fence mechanisme is op node basis, je fenced een node geen resource.

Als je geen mogelijkheid hebt om een fence device te gebruiken kan je manual fencing gebruiken. De documentatie van Red Hat in deze is best aardig:

Manual fencing (paragraaf 10.2.7. Manual) is hier uitgelegd: https://access.redhat.com...ide/s1-fence-methods.html

Nog meer leesvoer over fencing hier: https://access.redhat.com..._Example_-_Fence_Devices/