今回のgemini/cancerの構成は、2ノードで両方でgfs2をマウントする、という構成。
なので、そもそもstonithを稼働させる必要は無いのでは？
ということを調べてみたら、stonith自体を無効化させることが出来ることが分かった。
stonithが有効だと、stonithで定義したfence-deviceが有効にならないと、リソースが起動しない。
無理やり、シングルノードでfence-deviceを有効にする必要も無いので、無効にしてしまう。
無効の仕方は以下の通り。
クラスタのプロパティ確認。
sudo pcs property show --all
そもそも、--allをつけないと全パラメータが確認できないなんて…。
stonith-enabledがtrueになっていると思う。
ちなみに、最初にクラスタを作った時に指定したno-quorum-policyもfreezeに設定されているのが分かる。
stonithを無効化する。
sudo pcs property set stonith-enabled=false
確認。
sudo pcs property show --all
これでクラスタの状態を見てみると…fence-deviceは動いているな…。
クラスタを再起動させてみよう。
sudo pcs cluster stop --all
sudo pcs cluster start --all
あれ？今度は dlm が起動しなくなった…。これは一体…？？？
う～ん。dlmを動かすためには、stonithの設定は必須みたいだ…。
元に戻そう。
sudo pcs property set stonith-enabled=true
sudo pcs cluster stop --all
sudo pcs cluster start --all
dlmリソースのパラメータに「allow_stonith_disabled」というのがあった。
これをtrueに設定してみたが…、やっぱりダメっぽいな。
う～ん…。dlmの制御がネックだなぁ…。
問題になっているのは、dlm不意にが対向ノードと通信できなくなった時、dlmがダウンしてしまうってことなんだよなぁ。
これを解決できれば、全て通ると思うんだけど…。
2019年5月11日土曜日
2019年5月5日日曜日
あかん。まだや。
https://uramocha02.blogspot.com/2019/05/2.html
ココで、片方のノードがダウンした時の、もう片方のノードの運用について記載したけど、まだ問題があった。
上記は、片方のノードを正常停止(systemctl poweroff)してから、もう片方のノードを運用する、というスタンスで書いていた。
ところが、正常停止ではなく異常終了(電源停止などによるクラッシュ)の時は、生き残っている方のノードもマトモに稼働しない、ということが判明。
この時、生き残っている方のクラスタリソース、dlmが落ちるという事象が発生している。
これ、dlmのパラメータ(/etc/dlm/dlm.conf)を適切に設定すれば良いんだと思っていたんだが、どうも良くワカラン。そもそも、dlmに関するドキュメント類が薄すぎるんだよなー。
もっと調べないとアカンかなぁ。まぁdlmは、GFS2等の共有ファイルシステムを使っている時にのみ利用するデーモンだから、情報量少ないのはしょうがないか…。
イマイチ本運用まで到達出来ないなぁ。
ココで、片方のノードがダウンした時の、もう片方のノードの運用について記載したけど、まだ問題があった。
上記は、片方のノードを正常停止(systemctl poweroff)してから、もう片方のノードを運用する、というスタンスで書いていた。
ところが、正常停止ではなく異常終了(電源停止などによるクラッシュ)の時は、生き残っている方のノードもマトモに稼働しない、ということが判明。
この時、生き残っている方のクラスタリソース、dlmが落ちるという事象が発生している。
これ、dlmのパラメータ(/etc/dlm/dlm.conf)を適切に設定すれば良いんだと思っていたんだが、どうも良くワカラン。そもそも、dlmに関するドキュメント類が薄すぎるんだよなー。
もっと調べないとアカンかなぁ。まぁdlmは、GFS2等の共有ファイルシステムを使っている時にのみ利用するデーモンだから、情報量少ないのはしょうがないか…。
イマイチ本運用まで到達出来ないなぁ。
2ノードクラスタでの特殊運用やっと分かった！
https://uramocha02.blogspot.com/2019/05/1604gfs2pacemaker.html
ココで書いたけど、2ノードクラスタは半分諦めていた。
もう一度書くと
2ノードクラスタ
片方のノードが死亡
生きている方のノードをメンテナンスで再起動
させると、生きている方のノードでもクラスタが正常起動しない、という問題だ。
これ、過半数のquorumに到達しない(2ノードなので、1ノードしか生きていなければ50%、つまり過半数に到達していない)というのが直接の原因。
で、クラスタによってはquorum diskという特殊な共有ディスクを用意して、そのquorum diskのロックに成功したノードは、quorumを1つ余分に得る、という仕組みを用意している。
これによって、生き残っているノードは、自身のquorum＋quorum diskをロックすることによって得られるquorumの合計2つのquorumを得て、過半数に到達する、という作りだ。
で、RHEL6時代のpacemakerには、そのものズバリのquorum disk(qdiskd)というソフトがあり、これを利用することで1ノードでも暫定運用が可能、という動きになる。
Ubuntu16.04にはこのquorum diskが無く、またUbuntu18.04やRHEL7は、quorum diskではなく、quorum deviceというのが使えるのだが、こちらはクラスタとは別に1つマシンが必要。
ということで、2ノードクラスタなのに3台のマシンが必要ということで、正直諦めていた。
諦めつつ、18.04のクラスタの構築を始めていたのだが、corosyncのコマンドにcorosync-quorumtoolというのがあるのに気づいた。
もしかしてコレ…と調べてみたら、ノードが持つquorum数を、意図的に変更することができるようだ。
だったら、生き残っている方のノードのquorum数を、1ではなく2にしてみたら、quorum数が過半数に到達し、1ノードでもクラスタ動くんじゃないか？ということで急遽実験。
結論は成功。
生き残っている方のノードで
sudo corosync-quorumtool -s
を実行し、自身のノードIDを確認する。
続いて
sudo corosync-quorumtool -v 2 -n (先程確認したノードID)
と実行し、指定したノードが持つquorum数を2つにすることで、クラスタが稼働し始めた。
なるほど…こういうことか…。
注意事項としては、OS再起動させるとquorum数も元に戻ってしまうので、再起動のたびにquorum数を再設定する必要がある、という点だ。
quorum数を固定することもできるかもしれないが、死んだノードを復旧させた後、またquorum数を1に戻す必要があるので、固定する機能は多分無いだろう。
やー、ここまで辿り着くの、永かった…。
ココで書いたけど、2ノードクラスタは半分諦めていた。
もう一度書くと
2ノードクラスタ
片方のノードが死亡
生きている方のノードをメンテナンスで再起動
させると、生きている方のノードでもクラスタが正常起動しない、という問題だ。
これ、過半数のquorumに到達しない(2ノードなので、1ノードしか生きていなければ50%、つまり過半数に到達していない)というのが直接の原因。
で、クラスタによってはquorum diskという特殊な共有ディスクを用意して、そのquorum diskのロックに成功したノードは、quorumを1つ余分に得る、という仕組みを用意している。
これによって、生き残っているノードは、自身のquorum＋quorum diskをロックすることによって得られるquorumの合計2つのquorumを得て、過半数に到達する、という作りだ。
で、RHEL6時代のpacemakerには、そのものズバリのquorum disk(qdiskd)というソフトがあり、これを利用することで1ノードでも暫定運用が可能、という動きになる。
Ubuntu16.04にはこのquorum diskが無く、またUbuntu18.04やRHEL7は、quorum diskではなく、quorum deviceというのが使えるのだが、こちらはクラスタとは別に1つマシンが必要。
ということで、2ノードクラスタなのに3台のマシンが必要ということで、正直諦めていた。
諦めつつ、18.04のクラスタの構築を始めていたのだが、corosyncのコマンドにcorosync-quorumtoolというのがあるのに気づいた。
もしかしてコレ…と調べてみたら、ノードが持つquorum数を、意図的に変更することができるようだ。
だったら、生き残っている方のノードのquorum数を、1ではなく2にしてみたら、quorum数が過半数に到達し、1ノードでもクラスタ動くんじゃないか？ということで急遽実験。
結論は成功。
生き残っている方のノードで
sudo corosync-quorumtool -s
を実行し、自身のノードIDを確認する。
続いて
sudo corosync-quorumtool -v 2 -n (先程確認したノードID)
と実行し、指定したノードが持つquorum数を2つにすることで、クラスタが稼働し始めた。
なるほど…こういうことか…。
注意事項としては、OS再起動させるとquorum数も元に戻ってしまうので、再起動のたびにquorum数を再設定する必要がある、という点だ。
quorum数を固定することもできるかもしれないが、死んだノードを復旧させた後、またquorum数を1に戻す必要があるので、固定する機能は多分無いだろう。
やー、ここまで辿り着くの、永かった…。
2019年5月4日土曜日
まずはpcsdの導入と初期セットアップ(18.04)
というわけで、18.04の構成(pisces/aries)を使って、NFSクラスタを構築する。
最初はpcsdの導入だ。
sudo apt-get update
sudo apt-get dist-upgrade
(必要に応じて再起動)
sudo apt-get install pcs
合わせて、pacemakerもインストールされる。
pcsdは自動起動にセットされた。
16.04の時と同様、haclusterアカウントが出来ているはずなので、パスワードを設定しておく。
sudo passwd hacluster
ついで、pisces/ariesと管理ノードのleoに、pisces/ariesのホスト名とIPアドレスを/etc/hostsに記載しておく。
sudo vi /etc/hosts
(127.0.1.1に自身のホスト名が定義されていると思うので、それは外しておくこと)
相互にpingを打って、名前解決出来ていることを確認しておこう。
gemini/cancerの時は、ブラウザからクラスタを組んだが、今回はコマンドで組んでみることにする。
sudo pcs cluster auth pisces aries -u hacluster
sudo pcs cluster setup --name nfs-cluster pisces aries --force
sudo pcs status
sudo pcs cluster start pisces aries
sudo pcs status
これでクラスタの構成は出来たが、corosync.serviceとpacemaker.serviceが自動起動になっていない。(pcs cluster setup に --start --enable のオプションを付与しておけば、自動起動に設定されると思うが、今回は敢えて設定しなかった。)
両方共自動起動にしておく。(pisces / ariesの両方で実施しておくこと)
sudo systemctl enable corosync.service
sudo systemctl enable pacemaker.service
これで、OS再起動させても自動的にクラスタが構成されるはずだ。
試しておくこと。
最初はpcsdの導入だ。
sudo apt-get update
sudo apt-get dist-upgrade
(必要に応じて再起動)
sudo apt-get install pcs
合わせて、pacemakerもインストールされる。
pcsdは自動起動にセットされた。
16.04の時と同様、haclusterアカウントが出来ているはずなので、パスワードを設定しておく。
sudo passwd hacluster
ついで、pisces/ariesと管理ノードのleoに、pisces/ariesのホスト名とIPアドレスを/etc/hostsに記載しておく。
sudo vi /etc/hosts
(127.0.1.1に自身のホスト名が定義されていると思うので、それは外しておくこと)
相互にpingを打って、名前解決出来ていることを確認しておこう。
gemini/cancerの時は、ブラウザからクラスタを組んだが、今回はコマンドで組んでみることにする。
sudo pcs cluster auth pisces aries -u hacluster
sudo pcs cluster setup --name nfs-cluster pisces aries --force
sudo pcs status
sudo pcs cluster start pisces aries
sudo pcs status
これでクラスタの構成は出来たが、corosync.serviceとpacemaker.serviceが自動起動になっていない。(pcs cluster setup に --start --enable のオプションを付与しておけば、自動起動に設定されると思うが、今回は敢えて設定しなかった。)
両方共自動起動にしておく。(pisces / ariesの両方で実施しておくこと)
sudo systemctl enable corosync.service
sudo systemctl enable pacemaker.service
これで、OS再起動させても自動的にクラスタが構成されるはずだ。
試しておくこと。
2019年5月2日木曜日
16.04でのgfs2のpacemaker化(一部諦め)
あーでもないこーでもない、と色々検証していった結果、Ubuntu16.04でgfs2をpacemaker管理下に置くのは、いくつか問題があって厳しいことが分かった。
今現在分かっているのは、
クラスタ製品の仕様として、「クラスタを構成するノード数のうち、過半数のノードが起動しない限り、クラスタは稼働させない(3ノードの場合は2台以上、4ノード・5ノードの場合は3台以上)」というのがある。
これはクラスタとしては当然の仕様だ。
2ノードの場合、この条件を満たすためには、2台が正常稼働する必要がある。
クラスタを組んでいるのに、1台も障害を受け付けない、というのはクラスタとしては片手落ちだ。
そこで、クラスタ製品は幾つかの対策を施している。
2ノードのみ特定の設定をし、片方がダウンしてもサービスを継続させる、という仕組みもその一つ。今回使用しているpacemakerの場合、corosync.confに記載する「two_node」というパラメータが該当する。
確かにこのパラメータを1に設定しておけば、片方のノードがダウンしてもサービスは継続実行可能だ。
ただし、これはクラスタ稼働中の話だ。
片系ダウンしている時に、生きている方のノードを再起動させた場合、「クラスタ稼働中」ではなく「クラスタを起動させる時」に該当する。
この時、もう片方のノード(死んでいる方のノード)がクラスタに参加するのを待ってしまうため、いつまで経ってもクラスタが上がってこない。
pcsコマンドにある cluster quorum unblock というのが「ノード数が過半数に達しなくても、サービスを稼働させる」というコマンドのようなのだが、16.04で試してみても期待した動きにならない。
他のクラスタ製品では、「quorum disk」という設定を施すことで、上記の状態を回避することが可能になっている。これは、2ノードの片系ダウンだけでなく、4ノードなどの「偶数台クラスタ」による「スプリットブレイン」にも対応している。
quorum diskは、クラスタを構成しているすべてのノードに接続している共有ディスクで、ほんの僅かなサイズ(数百MB程度？)のディスクであればいい。
偶数クラスタがちょうど半分に分離してしまった場合(ちょうど半数のノードから応答が無かった場合)、予め定義していたquorum diskにロックを仕掛け、ロックを取得することが出来たノード、及びそのノードと通信可能な方のノードの組でクラスタサービスを継続し、ロックを取得できずに切り離されてしまった組はクラスタから離れる、という仕様だ。
これによって、スプリットブレインに対応している。
ちょうど、quorum diskをロックすることによって、ノード数(投票数)が一つ増えたイメージになる。
pacemaker にも同様の仕組みがあると思っていたのだが、なかなかその情報が見つけられず、スプリットブレイン対策がイマイチ分からなかった、というのが先日までの状態。
で、もう一度調査したところ、RHEL6.xまでは、そのものズバリのquorum diskという設定があったようだ。
ところが、RHEL7.xになって、quorum diskが無くなり、quorum deviceという仕組みに置き換わっていた。
Ubuntu16.04のpacemakerで同様の仕組みを探してみたが、corosyncのバージョン違いからか、quorum diskもquorum deviceも設定が無い。
Ubuntu18.04の方を見てみたら、quorum deviceという設定はあるようだ。
この時点で、quorum diskを使用したスプリットブレイン対策は施せないことが分かったのだが、quorum deviceの方を調べてみたら、クラスタ構成ノードとは別に、サーバが1環境必要であることが分かった。
2ノードクラスタを組むのに、3台必要、ということだ。
ちなみに、quorum deviceというのは、スプリットブレインが発生した時に、どちらの組でサービスを継続させるかを決定する、調停役として存在させるみたいだ。
HPE社のクラスタソフトであるServiceGuard for Linuxでは、確か「quorum server」と呼ばれるものに相当するようだ。
とまぁ色々書いてきたが、今のホストOS(sagittarius/aquarius)の2台では、16.04のpacemakerどころか、18.04のpacemakerでも不都合が起きる。
とりあえず、動かすことはできるので、2台のいずれかが故障しないことを祈るか、もう1台手配して、quorum deviceとしてセットアップするか…。
gfs2を使用するためのクラスタだけでなく、nfsサーバもクラスタ化することを考えているので、現状ではかなり厳しい状態なのが判明。果たしてどうするか？
18.04でquorum diskが使えるといいんだが…。
とりあえず今後は、16.04でのgfs2クラスタは一旦放置し、18.04のnfsクラスタの方を少し調査してみることにする。
今現在分かっているのは、
- 2ノードで稼働
- 片方のノードが死亡
- 生きている方のノードをメンテナンスのために再起動
クラスタ製品の仕様として、「クラスタを構成するノード数のうち、過半数のノードが起動しない限り、クラスタは稼働させない(3ノードの場合は2台以上、4ノード・5ノードの場合は3台以上)」というのがある。
これはクラスタとしては当然の仕様だ。
2ノードの場合、この条件を満たすためには、2台が正常稼働する必要がある。
クラスタを組んでいるのに、1台も障害を受け付けない、というのはクラスタとしては片手落ちだ。
そこで、クラスタ製品は幾つかの対策を施している。
2ノードのみ特定の設定をし、片方がダウンしてもサービスを継続させる、という仕組みもその一つ。今回使用しているpacemakerの場合、corosync.confに記載する「two_node」というパラメータが該当する。
確かにこのパラメータを1に設定しておけば、片方のノードがダウンしてもサービスは継続実行可能だ。
ただし、これはクラスタ稼働中の話だ。
片系ダウンしている時に、生きている方のノードを再起動させた場合、「クラスタ稼働中」ではなく「クラスタを起動させる時」に該当する。
この時、もう片方のノード(死んでいる方のノード)がクラスタに参加するのを待ってしまうため、いつまで経ってもクラスタが上がってこない。
pcsコマンドにある cluster quorum unblock というのが「ノード数が過半数に達しなくても、サービスを稼働させる」というコマンドのようなのだが、16.04で試してみても期待した動きにならない。
他のクラスタ製品では、「quorum disk」という設定を施すことで、上記の状態を回避することが可能になっている。これは、2ノードの片系ダウンだけでなく、4ノードなどの「偶数台クラスタ」による「スプリットブレイン」にも対応している。
quorum diskは、クラスタを構成しているすべてのノードに接続している共有ディスクで、ほんの僅かなサイズ(数百MB程度？)のディスクであればいい。
偶数クラスタがちょうど半分に分離してしまった場合(ちょうど半数のノードから応答が無かった場合)、予め定義していたquorum diskにロックを仕掛け、ロックを取得することが出来たノード、及びそのノードと通信可能な方のノードの組でクラスタサービスを継続し、ロックを取得できずに切り離されてしまった組はクラスタから離れる、という仕様だ。
これによって、スプリットブレインに対応している。
ちょうど、quorum diskをロックすることによって、ノード数(投票数)が一つ増えたイメージになる。
pacemaker にも同様の仕組みがあると思っていたのだが、なかなかその情報が見つけられず、スプリットブレイン対策がイマイチ分からなかった、というのが先日までの状態。
で、もう一度調査したところ、RHEL6.xまでは、そのものズバリのquorum diskという設定があったようだ。
ところが、RHEL7.xになって、quorum diskが無くなり、quorum deviceという仕組みに置き換わっていた。
Ubuntu16.04のpacemakerで同様の仕組みを探してみたが、corosyncのバージョン違いからか、quorum diskもquorum deviceも設定が無い。
Ubuntu18.04の方を見てみたら、quorum deviceという設定はあるようだ。
この時点で、quorum diskを使用したスプリットブレイン対策は施せないことが分かったのだが、quorum deviceの方を調べてみたら、クラスタ構成ノードとは別に、サーバが1環境必要であることが分かった。
2ノードクラスタを組むのに、3台必要、ということだ。
ちなみに、quorum deviceというのは、スプリットブレインが発生した時に、どちらの組でサービスを継続させるかを決定する、調停役として存在させるみたいだ。
HPE社のクラスタソフトであるServiceGuard for Linuxでは、確か「quorum server」と呼ばれるものに相当するようだ。
とまぁ色々書いてきたが、今のホストOS(sagittarius/aquarius)の2台では、16.04のpacemakerどころか、18.04のpacemakerでも不都合が起きる。
とりあえず、動かすことはできるので、2台のいずれかが故障しないことを祈るか、もう1台手配して、quorum deviceとしてセットアップするか…。
gfs2を使用するためのクラスタだけでなく、nfsサーバもクラスタ化することを考えているので、現状ではかなり厳しい状態なのが判明。果たしてどうするか？
18.04でquorum diskが使えるといいんだが…。
とりあえず今後は、16.04でのgfs2クラスタは一旦放置し、18.04のnfsクラスタの方を少し調査してみることにする。
登録:
投稿 (Atom)