STONITH 2 düğümlü aktif / pasif linux HA pacemaker kümesinde nasıl kurulur?

Bir PostgreSQL-Veritabanı kurmak ve çalıştırmak için corosync ve kalp pili ile aktif / pasif (2 düğüm) bir Linux-HA kümesi kurmaya çalışıyorum. DRBD ve bir service-ip üzerinden çalışır. Düğüm1 başarısız olursa, düğüm2 devralınmalıdır. PG düğüm2'de çalışıyorsa ve başarısız olursa da aynı şey. STONITH dışında her şey yolunda gidiyor.

Düğümler arasında özel bir HA bağlantısı (10.10.10.X) var, bu yüzden aşağıdaki arayüz yapılandırmasına sahibim:

eth0            eth1            host
10.10.10.251    172.10.10.1     node1
10.10.10.252    172.10.10.2     node2

Stonith etkinleştirildi ve düğümleri öldürmek için ssh aracısıyla test yapıyorum.

crm configure property stonith-enabled=true
crm configure property stonith-action=poweroff
crm configure rsc_defaults resource-stickiness=100
crm configure property no-quorum-policy=ignore

crm configure primitive stonith_postgres stonith:external/ssh \
                params hostlist="node1 node2"
crm configure clone fencing_postgres stonith_postgres

crm_mon -1 gösterileri:

============
Last updated: Mon Mar 19 15:21:11 2012
Stack: openais
Current DC: node2 - partition with quorum
Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b
2 Nodes configured, 2 expected votes
4 Resources configured.
============

Online: [ node2 node1 ]

Full list of resources:

 Master/Slave Set: ms_drbd_postgres
     Masters: [ node1 ]
     Slaves: [ node2 ]
 Resource Group: postgres
     fs_postgres        (ocf::heartbeat:Filesystem):    Started node1
     virtual_ip_postgres        (ocf::heartbeat:IPaddr2):       Started node1
     postgresql (ocf::heartbeat:pgsql): Started node1
 Clone Set: fencing_postgres
     Started: [ node2 node1 ]

Sorun: eth0 arabirimleri arasındaki bağlantıyı kestiğimde, her iki düğümü de öldürüyor . Çekirdek ile ilgili bir sorun olduğunu düşünüyorum, çünkü sadece 2 düğüm var. Ama sadece doğru nisabı hesaplamak için 3. bir düğüm eklemek istemiyorum.

Bu sorunu çözmek için herhangi bir fikir var mı?

Bu biraz daha eski bir soru ama burada sunulan sorun, kümelerde, özellikle de iki düğümlü kümelerde yük devretmenin nasıl ve ne zaman işe yaradığına dair yanlış bir anlayışa dayanıyor.

Amaç: İki düğüm arasındaki iletişimi devre dışı bırakarak yük devretme testi yapamazsınız. Bunu yapmak, tam olarak gördüğünüz şeyle sonuçlanır, ek, karşılıklı STONITH ile bölünmüş beyin senaryosu. Eskrim yeteneklerini test etmek istiyorsanız killall -9 corosync, aktif düğüm üzerinde bir basit olacaktır. Diğer yollar crm node fenceveya stonith_admin -F.

Kümenizin tam olmayan açıklamasından (çıktı crm configure showve nerede cat /etc/corosync/corosync.conf?), 10.10.10.xx adreslerini mesajlaşma, yani Corosync / küme iletişimi için kullandığınız anlaşılıyor. 172.10.10.xx adresleri normal / hizmet ağ adreslerinizdir ve belirli bir düğüme, örneğin SSH kullanarak, 172.10.10.xx adresiyle erişirsiniz. DNS ayrıca node1172.10.10.1 gibi bir düğüm ana bilgisayar adını çözüyor gibi görünüyor.

Kendi başına iyi bir fikir olmayan SSH'yi kullanmak için STONITH yapılandırdınız, ancak muhtemelen sadece test ediyorsunuz. Kendim kullanmadım ama SSH STONITH ajanının diğer düğüme giriş yaptığını ve ssh root@node2 "shutdown -h now"eşdeğer bir şey gibi bir kapatma komutu verdiğini varsayıyorum .

Şimdi, düğümler arasındaki küme iletişimini kestiğinizde ne olur? Düğümler artık her düğümü canlı ve iyi görmüyor, çünkü aralarında daha fazla iletişim yok. Böylece her düğüm, bunun talihsiz bir olaydan kurtulan tek kişi olduğunu varsayar ve aktif veya birincil düğüm olmaya (veya kalmaya) çalışır. Bu klasik ve korkunç bölünmüş beyin senaryosu .

Bunun bir kısmı, STONITH'in devreye girdiği açık, muhtemelen ve muhtemelen başarısız olan düğümün iyi durumda olduğundan emin olmaktır. Her iki düğümün de aynı oyunu oynadığını unutmayın : aktif olmaya (veya kalmaya) ve almaya çalışın başındaki diğer düğümü vurmanın yanı sıra

Muhtemelen şimdi ne olacağını tahmin edebilirsiniz. node1yapar ssh root@node2 "shutdown -h now"ve node2yapar ssh root@node1 "shutdown -h now". Küme iletişim ağı 10.10.10.xx değil, hizmet ağı 172.10.10.xx kullanılır. Her iki düğüm de aslında canlı ve iyi olduğundan, komut verme veya SSH bağlantıları alma konusunda hiçbir problemleri yoktur, bu nedenle her iki düğüm de aynı anda birbirini vurur. Bu her iki düğümü de öldürür.

STONITH'i kullanmazsanız, bölünmüş bir beynin, özellikle de her iki düğümün Birincil hale gelebileceği DRBD durumunda daha da kötü sonuçları olabilir. Veri bozulması muhtemeldir ve bölünmüş beyin manuel olarak çözülmelidir.

Ben malzemeyi okumanızı tavsiye http://www.hastexo.com/resources/hints-and-kinks "Linux HA ne bugün aramanın büyük bir kısmını katkıda (ve hala katkıda) adamlar tarafından yazılan ve korunur "yığın.

TL; DR : Eskrim kurulumunuzu test etmek için düğümleriniz arasında küme iletişimini kesiyorsanız, yanlış yapıyorsunuz . Kullanım killall -9 corosync, crm node fenceya stonith_admin -Fonun yerine. Küme iletişiminin kesilmesi, yalnızca veri bozulmasına yol açabilecek ve yol açabilecek bölünmüş beyin senaryosuyla sonuçlanır.

auto_tie_breaker: 1/Etc/corosync/corosync.conf'un çekirdek bölümüne eklemeyi deneyebilirsiniz

ATB etkinleştirildiğinde, küme aynı anda başarısız olan düğümlerin% 50'sine kadar belirleyici bir şekilde zarar görebilir. Küme bölümü veya en düşük düğüm değerine sahip düğümle hala temas halinde olan düğümler kümesi tırnak içinde kalacaktır. Diğer düğümler sorgulanacaktır.

Kalp Pili belgelerinin Çekirdek ve iki düğümlü kümeler bölümünü okumayı deneyin .

Pacemaker kullanarak HA kümesi için bunu kontrol edin: http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Clusters_from_Scratch/index.html