というわけで、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再起動させても自動的にクラスタが構成されるはずだ。
試しておくこと。
2019年5月4日土曜日
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クラスタの方を少し調査してみることにする。
2018年9月6日木曜日
clvmdをクラスタリソースに(gfs2用)
RedHat社の手順だと、ココで clvmd をクラスタリソースとして定義している。
んが、gemini と cancer には、まだ clvmd をインストールしていない。
なので、このタイミングでまずインストールする。
(gemini) $ sudo apt-get update
(gemini) $ sudo apt-get install clvm
(gemini) $ dpkg -l clvm
(gemiin) $ dpkg -L clvm
cancer でも。
(cancer) $ sudo apt-get update
(cancer) $ sudo apt-get install clvm
(cancer) $ dpkg -l clvm
(cancer) $ dpkg -L clvm
インストールが終わったら、clvmd をクラスタリソースとして定義する。
RedHat社のサイトでは、以下のコマンドを実行している。
pcs resource create clvmd ocf:heartbeat:clvm \
op monitor interval=30s on-fail=fence \
clone \
interleave=true \
ordered=true
dlmリソースを作成した時とよく似ている。
ということは、その時と同じように設定すればいいってことだ。
pcsdの画面を使って、RESOURCESタブからAddを選択。
以下のように入力する。
あれ？確かにclvmd-cloneとclvmdのリソースは作成されたけど、ステータスがblockedになってしまった。
clvmdが起動していないとダメなのか？
う～ん。強制的にリソースを起動してみると…。
(gemini) $ sudo pcs resource debug-start clvmd
(gemini) $ ps -ef | grep clvmd
動いたけど…起動時に「lvmetadが無効になっているのに起動してるで。有効化して再起動しな。」って言われてる気がするが…。
lvmetad は無効化するのが正しいはずなので、lvmetad を停止すればいいのかな？
とりあえず、clvmdリソースは停止する。
(gemini) $ sudo pcs resource debug-stop clvmd
(gemini) $ ps -ef | grep clvmd
lvmetadの状態を確認してみよう。
(gemini) $ systemctl status lvm2-lvmetad.service
起動していて、かつ自動起動Offだ。(disabled)
止めてしまおう。
(gemini) $ sudo systemctl stop lvm2-lvmetad.service
(gemini) $ systemctl status lvm2-lvmetad.service
なんか、lvm2-lvmetad.socketが有効だぞ、と言われたけど、一旦無視する。
これでもう一回、強制起動を。
(gemini) $ sudo pcs resource debug-start clvmd
(gemini) $ ps -ef | grep clvmd
先程のワーニングは消えた。
とりあえず止める。
(gemini) $ sudo pcs resource debug-stop clvmd
となると、systemctl から clvmd が起動してくれればイケそうだな。
以前、clvmd の起動はココで苦労したんだけど、この記事若干間違っているので、ここで再度整理して実行しよう。
lvm2-clvmd.service の定義ファイルが誤っているっぽいので、コピーして修正する。
(gemini) $ sudo cp -pi /lib/systemd/system/lvm2-clvmd.service \
/etc/systemd/system/
(gemini) $ sudo vi /etc/systemd/system/lvm2-clvmd.service
----
ExecStart=/sbin/clvmd $CLVMD_OPTS
↓
ExecStart=/usr/sbin/clvmd $CLVMD_OPTS
----
以前の記事では、うだうだと色々いじっているが、実際にいじるのは上記だけだ。
これで起動してみる。
(gemini) $ sudo systemctl daemon-reload
(gemini) $ sudo systemctl start lvm2-cluster-activation.service
pcsd の画面から、 clvmd-clone リソースを Cleanup して暫く待ったら、無事に動き出した。(ただし、リソース自体はgeminiでしか動いていない。cancer側の修正が出来てないから当たり前だが)
(gemini) $ sudo pcs resource
lvm2-cluster-activation.service は自動起動になっていないようなので、自動起動にしておく。
(gemini) $ systemctl is-enabled lvm2-cluster-activation.service
(gemini) $ sudo systemctl enable lvm2-cluster-activation.service
(gemini) $ systemctl is-enabled lvm2-cluster-activation.service
同じようにcancerをカスタマイズする。
(cancer) $ sudo cp -pi /lib/systemd/system/lvm2-clvmd.service \
/etc/systemd/system/
(cancer) $ sudo vi /etc/systemd/system/lvm2-clvmd.service
----
ExecStart=/sbin/clvmd $CLVMD_OPTS
↓
ExecStart=/usr/sbin/clvmd $CLVMD_OPTS
----
起動してみる。
(cancer) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl start lvm2-cluster-activation.service
また、pcsd の画面から、clvm-clone リソースを Cleanup して暫く待つ。
cancer側でも動いているのを確認する。
(cancer) $ sudo pcs resource
動いているのが確認できたら、cancer でも lvm2-cluster-activation.service を自動起動にする。
(cancer) $ systemctl is-enabled lvm2-cluster-activation.service
(cancer) $ sudo systemctl enable lvm2-cluster-activation.service
(cancer) $ systemctl is-enabled lvm2-cluster-activation.service
さて、あとは op monitor interval=30s on-fail=fence と interleave=true ordered=true の設定だな。
サクッと片付けよう。
(gemini) $ sudo pcs resource show clvmd-clone
(gemini) $ sudo pcs resource op remove clvmd monitor
(gemini) $ sudo pcs resource op add clvmd monitor interval=30s on-fail=fence
(gemini) $ sudo pcs resource show clvmd-clone
interleave=true と ordered=true は、pcsd の画面の Meta Attrib から足したらおしまいだ。
とりあえずココまで。
追記
cancerのlvmetadを止めておくのを忘れていたので止めておく。
(cancer) $ systemctl status lvm2-lvmetad.service
(cancer) $ sudo systemctl stop lvm2-lvmetad.service
(cancer) $ systemctl status lvm2-lvmetad.service
んが、gemini と cancer には、まだ clvmd をインストールしていない。
なので、このタイミングでまずインストールする。
(gemini) $ sudo apt-get update
(gemini) $ sudo apt-get install clvm
(gemini) $ dpkg -l clvm
(gemiin) $ dpkg -L clvm
cancer でも。
(cancer) $ sudo apt-get update
(cancer) $ sudo apt-get install clvm
(cancer) $ dpkg -l clvm
(cancer) $ dpkg -L clvm
インストールが終わったら、clvmd をクラスタリソースとして定義する。
RedHat社のサイトでは、以下のコマンドを実行している。
pcs resource create clvmd ocf:heartbeat:clvm \
op monitor interval=30s on-fail=fence \
clone \
interleave=true \
ordered=true
dlmリソースを作成した時とよく似ている。
ということは、その時と同じように設定すればいいってことだ。
pcsdの画面を使って、RESOURCESタブからAddを選択。
以下のように入力する。
- Class/Provider : ocf:heartbeat
- Type : clvm
- Resource Group : None
- Clone : チェックOn
- Master/Slave : チェックOff
- Disabled : チェックOff
- ResourceID : clvmd
- with_cmirrord : なし
- configdir : なし
- daemon_options : なし
- active_vgs : なし
あれ？確かにclvmd-cloneとclvmdのリソースは作成されたけど、ステータスがblockedになってしまった。
clvmdが起動していないとダメなのか？
う～ん。強制的にリソースを起動してみると…。
(gemini) $ sudo pcs resource debug-start clvmd
(gemini) $ ps -ef | grep clvmd
動いたけど…起動時に「lvmetadが無効になっているのに起動してるで。有効化して再起動しな。」って言われてる気がするが…。
lvmetad は無効化するのが正しいはずなので、lvmetad を停止すればいいのかな？
とりあえず、clvmdリソースは停止する。
(gemini) $ sudo pcs resource debug-stop clvmd
(gemini) $ ps -ef | grep clvmd
lvmetadの状態を確認してみよう。
(gemini) $ systemctl status lvm2-lvmetad.service
起動していて、かつ自動起動Offだ。(disabled)
止めてしまおう。
(gemini) $ sudo systemctl stop lvm2-lvmetad.service
(gemini) $ systemctl status lvm2-lvmetad.service
なんか、lvm2-lvmetad.socketが有効だぞ、と言われたけど、一旦無視する。
これでもう一回、強制起動を。
(gemini) $ sudo pcs resource debug-start clvmd
(gemini) $ ps -ef | grep clvmd
先程のワーニングは消えた。
とりあえず止める。
(gemini) $ sudo pcs resource debug-stop clvmd
となると、systemctl から clvmd が起動してくれればイケそうだな。
以前、clvmd の起動はココで苦労したんだけど、この記事若干間違っているので、ここで再度整理して実行しよう。
lvm2-clvmd.service の定義ファイルが誤っているっぽいので、コピーして修正する。
(gemini) $ sudo cp -pi /lib/systemd/system/lvm2-clvmd.service \
/etc/systemd/system/
(gemini) $ sudo vi /etc/systemd/system/lvm2-clvmd.service
----
ExecStart=/sbin/clvmd $CLVMD_OPTS
↓
ExecStart=/usr/sbin/clvmd $CLVMD_OPTS
----
以前の記事では、うだうだと色々いじっているが、実際にいじるのは上記だけだ。
これで起動してみる。
(gemini) $ sudo systemctl daemon-reload
(gemini) $ sudo systemctl start lvm2-cluster-activation.service
pcsd の画面から、 clvmd-clone リソースを Cleanup して暫く待ったら、無事に動き出した。(ただし、リソース自体はgeminiでしか動いていない。cancer側の修正が出来てないから当たり前だが)
(gemini) $ sudo pcs resource
lvm2-cluster-activation.service は自動起動になっていないようなので、自動起動にしておく。
(gemini) $ systemctl is-enabled lvm2-cluster-activation.service
(gemini) $ sudo systemctl enable lvm2-cluster-activation.service
(gemini) $ systemctl is-enabled lvm2-cluster-activation.service
同じようにcancerをカスタマイズする。
(cancer) $ sudo cp -pi /lib/systemd/system/lvm2-clvmd.service \
/etc/systemd/system/
(cancer) $ sudo vi /etc/systemd/system/lvm2-clvmd.service
----
ExecStart=/sbin/clvmd $CLVMD_OPTS
↓
ExecStart=/usr/sbin/clvmd $CLVMD_OPTS
----
起動してみる。
(cancer) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl start lvm2-cluster-activation.service
また、pcsd の画面から、clvm-clone リソースを Cleanup して暫く待つ。
cancer側でも動いているのを確認する。
(cancer) $ sudo pcs resource
動いているのが確認できたら、cancer でも lvm2-cluster-activation.service を自動起動にする。
(cancer) $ systemctl is-enabled lvm2-cluster-activation.service
(cancer) $ sudo systemctl enable lvm2-cluster-activation.service
(cancer) $ systemctl is-enabled lvm2-cluster-activation.service
さて、あとは op monitor interval=30s on-fail=fence と interleave=true ordered=true の設定だな。
サクッと片付けよう。
(gemini) $ sudo pcs resource show clvmd-clone
(gemini) $ sudo pcs resource op remove clvmd monitor
(gemini) $ sudo pcs resource op add clvmd monitor interval=30s on-fail=fence
(gemini) $ sudo pcs resource show clvmd-clone
interleave=true と ordered=true は、pcsd の画面の Meta Attrib から足したらおしまいだ。
とりあえずココまで。
追記
cancerのlvmetadを止めておくのを忘れていたので止めておく。
(cancer) $ systemctl status lvm2-lvmetad.service
(cancer) $ sudo systemctl stop lvm2-lvmetad.service
(cancer) $ systemctl status lvm2-lvmetad.service
2018年9月4日火曜日
lvmconf(gfs2用)
続いて、lvmconfコマンド。
これは以前、この辺りで書いてた内容を、新しい gemini / cancer で実行するだけのお話。
さっそくやってみよう。
(gemini) $ sudo cp -pi /etc/lvm/lvm.conf /etc/lvm/lvm.conf.orig
(gemini) $ sudo lvmconf --enable-cluster
(gemini) $ diff -c /etc/lvm/lvm.conf.orig /etc/lvm/lvm.conf
locking_type が 3に、use_lvmetad が 0 に更新された。
同じように cancer も。
(cancer) $ sudo cp -pi /etc/lvm/lvm.conf /etc/lvm/lvm.conf.orig
(cancer) $ sudo lvmconf --enable-cluster
(cancer) $ diff -c /etc/lvm/lvm.conf.orig /etc/lvm/lvm.conf
はて、lvmetadは可動しっぱなしだけど、OS再起動とか lvm2-lvmetad.service の停止は不要なのかの？
これは以前、この辺りで書いてた内容を、新しい gemini / cancer で実行するだけのお話。
さっそくやってみよう。
(gemini) $ sudo cp -pi /etc/lvm/lvm.conf /etc/lvm/lvm.conf.orig
(gemini) $ sudo lvmconf --enable-cluster
(gemini) $ diff -c /etc/lvm/lvm.conf.orig /etc/lvm/lvm.conf
locking_type が 3に、use_lvmetad が 0 に更新された。
同じように cancer も。
(cancer) $ sudo cp -pi /etc/lvm/lvm.conf /etc/lvm/lvm.conf.orig
(cancer) $ sudo lvmconf --enable-cluster
(cancer) $ diff -c /etc/lvm/lvm.conf.orig /etc/lvm/lvm.conf
はて、lvmetadは可動しっぱなしだけど、OS再起動とか lvm2-lvmetad.service の停止は不要なのかの？
2018年9月3日月曜日
dlmリソース作成(gfs2用)
続いて、dlmをリソースとして作成する。
RedHat社のサイトを参照すると、以下のコマンドがサンプルとして載っている。
pcs resource create dlm \
ocf:pacemaker:controld \
op monitor \
interval=30s \
on-fail=fence \
clone \
interleave=true \
ordered=true
今回は、pcsdを使ってセットアップしているので、このコマンド例を参考にpcsdの画面にどのように入力するのか？
まずは、pcsdの画面からgfs2-clusterを選択する。
そして、RESOURCESタブから「Add」を選んで、リソース情報入力ダイアログを表示させよう。
で、ダイアログを以下のように設定する。
cloneリソースとして作成しているので、自動的にdlm-cloneというグループ？が作られて、そこにdlmリソースが定義される。
作成したdlmリソースに関して、コマンドラインでも確認してみよう。
(gemini) $ sudo pcs resource show
(cancer) $ sudo pcs resource show
cloneリソースとして、dlmリソースが提議されているのが確認でき、Startedになっているのが確認できる。
詳細確認
(gemini) $ sudo pcs resource show dlm --full
(cancer) $ sudo pcs resource show dlm --full
詳細を見てみると、start / stop / monitor の3つの項目に、それぞれ interval やその他のパラメータが設定されていることがわかる。
redhat社のサイトでは、op monitor interval=30s on-fail=fence と指定しているので、おそらく monitor 項目の interval パラメータを 30s 、on-fail パラメータを fence に設定しているのだろう。
pcsd の画面からはどうやって設定するのだろうか？
今回のリソースはクローンリソース(複数のノードで同じリソースが稼働するタイプ)で、interval項目は、個別のノードごとに設定を変える必要は無さそうだ。
つまり、全体に影響させればいい。
ということは、dlmではなくdlm-cloneリソースの方のパラメータだろう。
pcsdの画面から、dlm-cloneリソースを選択し、Resource-Meta-Attributeを開いてみる。
Meta Attribute と Value という入力項目があるので、そこに interval と 30s を入れてみる。
…変化なし…。
どうも良くわからないのだが、Operationsパラメータは、pcsdの画面からは修正することが出来ないようだ。
コマンドラインから設定してみることにする。
(gemini) $ sudo pcs resource op add dlm monitor interval=30s on-fail=fence
おっとエラーになった。
monitor 定義が既に入っているので、重ねて定義出来ないよ、もし重ねて定義したいのなら、--force を付けてね、とのこと。
同じ interval パラメータ等を定義しても意味が無さそうなので、一旦削除してから定義する。
(gemini) $ sudo pcs resource op remove dlm monitor
(gemini) $ sudo pcs resource show dlm --full
monitor定義が消えたのを確認して
(gemini) $ sudo pcs resource op add dlm monitor interval=30s on-fail=fence
(gemini) $ sudo pcs resource show dlm --full
一応、cancerの方でも確認してみる。
(cancer) $ sudo pcs resource show dlm --full
反映されているようだ。
これで、redhat社のサイトに掲示されていたコマンドのうち、op monitor interval=30s on-fail=fence の部分は対応できた。
残りは interleave=true と orderded=true だ。
これは結論から言うと、pcsd の画面の dlm-clone リソースから Resource Meta Attribute を入力することで設定することになる。
というわけで、dlm-clone リソースの Resource Meta Attribute の Meta Attribute と Value にそれぞれ以下の値を入れよう。
確認
(gemini) $ sudo pcs resource show dlm --full
(cancer) $ sudo pcs resource show dlm --full
Meta Attrs に値が表示されていればOKだ。
とりあえず今回はここまで。
RedHat社のサイトを参照すると、以下のコマンドがサンプルとして載っている。
pcs resource create dlm \
ocf:pacemaker:controld \
op monitor \
interval=30s \
on-fail=fence \
clone \
interleave=true \
ordered=true
今回は、pcsdを使ってセットアップしているので、このコマンド例を参考にpcsdの画面にどのように入力するのか？
まずは、pcsdの画面からgfs2-clusterを選択する。
そして、RESOURCESタブから「Add」を選んで、リソース情報入力ダイアログを表示させよう。
で、ダイアログを以下のように設定する。
- Class/Provider : ocf:pacemaker
- Type : controld
- Resource Group : None
- Clone : チェックOn
- Master/Slave : チェックOff
- Disabled : チェックOff
- ResourceID : dlm
- args : なし
- configdir : なし
- daemon : なし
- allow_stonith_disabled : なし
cloneリソースとして作成しているので、自動的にdlm-cloneというグループ？が作られて、そこにdlmリソースが定義される。
作成したdlmリソースに関して、コマンドラインでも確認してみよう。
(gemini) $ sudo pcs resource show
(cancer) $ sudo pcs resource show
cloneリソースとして、dlmリソースが提議されているのが確認でき、Startedになっているのが確認できる。
詳細確認
(gemini) $ sudo pcs resource show dlm --full
(cancer) $ sudo pcs resource show dlm --full
詳細を見てみると、start / stop / monitor の3つの項目に、それぞれ interval やその他のパラメータが設定されていることがわかる。
redhat社のサイトでは、op monitor interval=30s on-fail=fence と指定しているので、おそらく monitor 項目の interval パラメータを 30s 、on-fail パラメータを fence に設定しているのだろう。
pcsd の画面からはどうやって設定するのだろうか？
今回のリソースはクローンリソース(複数のノードで同じリソースが稼働するタイプ)で、interval項目は、個別のノードごとに設定を変える必要は無さそうだ。
つまり、全体に影響させればいい。
ということは、dlmではなくdlm-cloneリソースの方のパラメータだろう。
pcsdの画面から、dlm-cloneリソースを選択し、Resource-Meta-Attributeを開いてみる。
Meta Attribute と Value という入力項目があるので、そこに interval と 30s を入れてみる。
…変化なし…。
どうも良くわからないのだが、Operationsパラメータは、pcsdの画面からは修正することが出来ないようだ。
コマンドラインから設定してみることにする。
(gemini) $ sudo pcs resource op add dlm monitor interval=30s on-fail=fence
おっとエラーになった。
monitor 定義が既に入っているので、重ねて定義出来ないよ、もし重ねて定義したいのなら、--force を付けてね、とのこと。
同じ interval パラメータ等を定義しても意味が無さそうなので、一旦削除してから定義する。
(gemini) $ sudo pcs resource op remove dlm monitor
(gemini) $ sudo pcs resource show dlm --full
monitor定義が消えたのを確認して
(gemini) $ sudo pcs resource op add dlm monitor interval=30s on-fail=fence
(gemini) $ sudo pcs resource show dlm --full
一応、cancerの方でも確認してみる。
(cancer) $ sudo pcs resource show dlm --full
反映されているようだ。
これで、redhat社のサイトに掲示されていたコマンドのうち、op monitor interval=30s on-fail=fence の部分は対応できた。
残りは interleave=true と orderded=true だ。
これは結論から言うと、pcsd の画面の dlm-clone リソースから Resource Meta Attribute を入力することで設定することになる。
というわけで、dlm-clone リソースの Resource Meta Attribute の Meta Attribute と Value にそれぞれ以下の値を入れよう。
| Meta Atribute | Value |
|---|---|
| interleave | true |
| orderded | true |
確認
(gemini) $ sudo pcs resource show dlm --full
(cancer) $ sudo pcs resource show dlm --full
Meta Attrs に値が表示されていればOKだ。
とりあえず今回はここまで。
2018年8月19日日曜日
クラスタベース作ってみる(16.04)
とりあえず、16.04のノード(gemini / cancer)でクラスタを作ってみたい。
同じ16.04のvirgoで動いているpcsdを使って実装してみる。
構成的には
ただ、pcsdを使う場合、管理サーバや各ノード間がpcsd同士で通信を行い、各種コマンドや状態のやり取りを行うようだ。
そのため、gemini/cancerでもpcsを導入しておく必要がある。
(gemini) $ sudo apt-get install pcs
(cancer) $ sudo apt-get install pcs
また、pcsdが起動してきてないと思うので、起動しておく。
(gemini) $ sudo systemctl start pcsd
(cancer) $ sudo systemctl start pcsd
gemini/cancerのhaclusterユーザも作成されているはずなので、このアカウントにパスワードを設定しておこう。
(gemini) $ sudo passwd hacluster
(cancer) $ sudo passwd hacluster
設定するパスワードは、virgoに設定したものと同じものが良いだろう。
＃クラスタノード(gemini/cancer)でのパスワードは合わせておくのが推奨のようだ。
実はこの他にも、事前準備として実施しておく必要があるものがある。
まずは、/etc/hosts。
DNSが運用できているのであれば不要だと思うけど、ウチのN/Wではローカルの名前解決にDNSは導入できていない。(したいけど…)
そのため、名前解決のために3つのサーバそれぞれの/etc/hostsにエントリを書いておく必要がある。
virgoの/etc/hostsには、geminiとcancerのホスト名/IPアドレスを追記すればいい。
(virgo) $ sudo vi /etc/hosts
gemini/cancerは、既に自分自身のホスト名とIPアドレスの対応として、127.0.1.1がエントリされているはずだ。これをコメント化(先頭に#を付与)しつつ、自分自身と相手のIPアドレスを記載しよう。
(gemini) $ sudo vi /etc/hosts
(cancer) $ sudo vi /etc/hosts
virgo(クラスタ管理サーバ)では、pacemaker/corosyncは稼動させる必要がなく、稼動していたらちょっと他に影響が出るようだ。
そのため、pacemaker/corosyncを停止させ、自動起動も止める。
(virgo) $ sudo systemctl stop pacemaker
(virgo) $ sudo systemctl stop corosync
(virgo) $ sudo systemctl disable pacemaker
(virgo) $ sudo systemctl disable corosync
合わせて、/etc/corosync/corosync.conf が存在していては上手く動作しないようなので、リネームしておく。
(virgo) $ sudo mv /etc/corosync/corosync.conf /etc/corosync/corosync.conf.orig
続いて、gemini/cancerでの準備だ。
クラスタを組む前からpacemaker/corosyncが動いていると、「このノードは既にどこかのクラスタに属している」と勘違いされる。
また、corosync.confが存在しているだけでも、同様に勘違いされる。
そのため、pacemaker/corosyncを停止させ、corosync.confを削除しておく。
(gemini) $ sudo systemctl stop pacemaker
(gemini) $ sudo systemctl stop corosync
(gemini) $ sudo rm /etc/corosync/corosync.conf
(cancer) $ sudo systemctl stop pacemaker
(cancer) $ sudo systemctl stop corosync
(cancer) $ sudo rm /etc/corosync/corosync.conf
ちなみに、上記オペレーションは、pcsコマンドで一括実施できたりする。
(gemini) $ sudo pcs cluster destroy
(cancer) $ sudo pcs cluster destroy
なお、pacemaker/corosyncの自動起動停止はしない(自動起動のままにしておく)。
ここまでやったら事前準備完了だ。
クラスタを組んでみよう。
前回と同様、virgo上のpcsdにブラウザでアクセスする。
(pcsdへのログインは、haclusterアカウントだ)
ログインできたら、「MANAGE CLUSTERS」の中にある「Create New」をクリック。
これから作成するクラスタ名と、そのノード名、その他オプションを設定するダイアログが出てきた。
クラスタ名を gfs2-cluster
ノードをgemini/cancerとする。
その他のオプションはデフォルトのまま「Create Cluster」をクリック。
gemini/cancerのhaclusterアカウントのパスワードを聞いてくると思うので、設定したパスワードを入力しよう。
これでクラスタが出来上がる。
この時点で、gemini/cancerのpacemaker/corosyncともに起動する。
また、gemini/cancerで削除したcorosync.confも自動作成されているはずだ。
次回以降は、クラスタの基本設定から続けていく予定。
同じ16.04のvirgoで動いているpcsdを使って実装してみる。
構成的には
- virgo:クラスタ管理サーバ
- gemini:クラスタノード1
- cancer:クラスタノード2
ただ、pcsdを使う場合、管理サーバや各ノード間がpcsd同士で通信を行い、各種コマンドや状態のやり取りを行うようだ。
そのため、gemini/cancerでもpcsを導入しておく必要がある。
(gemini) $ sudo apt-get install pcs
(cancer) $ sudo apt-get install pcs
また、pcsdが起動してきてないと思うので、起動しておく。
(gemini) $ sudo systemctl start pcsd
(cancer) $ sudo systemctl start pcsd
gemini/cancerのhaclusterユーザも作成されているはずなので、このアカウントにパスワードを設定しておこう。
(gemini) $ sudo passwd hacluster
(cancer) $ sudo passwd hacluster
設定するパスワードは、virgoに設定したものと同じものが良いだろう。
＃クラスタノード(gemini/cancer)でのパスワードは合わせておくのが推奨のようだ。
実はこの他にも、事前準備として実施しておく必要があるものがある。
まずは、/etc/hosts。
DNSが運用できているのであれば不要だと思うけど、ウチのN/Wではローカルの名前解決にDNSは導入できていない。(したいけど…)
そのため、名前解決のために3つのサーバそれぞれの/etc/hostsにエントリを書いておく必要がある。
- virgo(クラスタ管理サーバ)はgemini/cancerの名前解決ができること
- gemini/cancer(クラスタ構成ノード)は自分自身とお互いの名前解決ができること
virgoの/etc/hostsには、geminiとcancerのホスト名/IPアドレスを追記すればいい。
(virgo) $ sudo vi /etc/hosts
gemini/cancerは、既に自分自身のホスト名とIPアドレスの対応として、127.0.1.1がエントリされているはずだ。これをコメント化(先頭に#を付与)しつつ、自分自身と相手のIPアドレスを記載しよう。
(gemini) $ sudo vi /etc/hosts
(cancer) $ sudo vi /etc/hosts
virgo(クラスタ管理サーバ)では、pacemaker/corosyncは稼動させる必要がなく、稼動していたらちょっと他に影響が出るようだ。
そのため、pacemaker/corosyncを停止させ、自動起動も止める。
(virgo) $ sudo systemctl stop pacemaker
(virgo) $ sudo systemctl stop corosync
(virgo) $ sudo systemctl disable pacemaker
(virgo) $ sudo systemctl disable corosync
合わせて、/etc/corosync/corosync.conf が存在していては上手く動作しないようなので、リネームしておく。
(virgo) $ sudo mv /etc/corosync/corosync.conf /etc/corosync/corosync.conf.orig
続いて、gemini/cancerでの準備だ。
クラスタを組む前からpacemaker/corosyncが動いていると、「このノードは既にどこかのクラスタに属している」と勘違いされる。
また、corosync.confが存在しているだけでも、同様に勘違いされる。
そのため、pacemaker/corosyncを停止させ、corosync.confを削除しておく。
(gemini) $ sudo systemctl stop pacemaker
(gemini) $ sudo systemctl stop corosync
(gemini) $ sudo rm /etc/corosync/corosync.conf
(cancer) $ sudo systemctl stop pacemaker
(cancer) $ sudo systemctl stop corosync
(cancer) $ sudo rm /etc/corosync/corosync.conf
ちなみに、上記オペレーションは、pcsコマンドで一括実施できたりする。
(gemini) $ sudo pcs cluster destroy
(cancer) $ sudo pcs cluster destroy
なお、pacemaker/corosyncの自動起動停止はしない(自動起動のままにしておく)。
ここまでやったら事前準備完了だ。
クラスタを組んでみよう。
前回と同様、virgo上のpcsdにブラウザでアクセスする。
(pcsdへのログインは、haclusterアカウントだ)
ログインできたら、「MANAGE CLUSTERS」の中にある「Create New」をクリック。
これから作成するクラスタ名と、そのノード名、その他オプションを設定するダイアログが出てきた。
クラスタ名を gfs2-cluster
ノードをgemini/cancerとする。
その他のオプションはデフォルトのまま「Create Cluster」をクリック。
gemini/cancerのhaclusterアカウントのパスワードを聞いてくると思うので、設定したパスワードを入力しよう。
これでクラスタが出来上がる。
この時点で、gemini/cancerのpacemaker/corosyncともに起動する。
また、gemini/cancerで削除したcorosync.confも自動作成されているはずだ。
次回以降は、クラスタの基本設定から続けていく予定。
2018年8月7日火曜日
pacemaker検証(古い環境の削除)
というわけで、これまで作った検証環境のうち、今回のpacemakerで使用する環境を一旦全て削除する。
併せて、NASキット側でgemini/cancer向けに作成したiSCSIターゲット、iSCSI LUNも削除してしまう。
一旦キレイに作り直して置きたいからだ。
- pisces
- aries
- gemini
- cancer
- leo
- virgo
併せて、NASキット側でgemini/cancer向けに作成したiSCSIターゲット、iSCSI LUNも削除してしまう。
一旦キレイに作り直して置きたいからだ。
2018年8月6日月曜日
pacemaker検証(ノード名)
とりあえず、以下のノードを新規作成/再作成してpacemaker検証用にしよう。
- pisces/aries
NFSv4クラスタ(Ubuntu18.04) - gemini/cancer
gfs2クラスタ(Ubuntu16.04) - leo
pcsd(Ubuntu18.04) - virgo
pcsd(Ubuntu16.04)
pacemaker再検証(事前情報)
どうやら、gfs2を使用するには、pacemakerと組み合わせるのが基本のようだった。
今現在、KVMホストになっているaquariusとsagittariusは、pacemakerを使用せずにgfs2でファイルシステムを共有している。
これでは不安定になるようなので、本格的にpacemakerの検証をしたい。
で、少し調べてみたら、pcsdというのを使うと、ブラウザから制御できるようだ。
いくつか検証中の仮想マシンを潰して、以下の環境を検証してみたい。
NFSv4は、自宅とは別の環境で検証している環境用で、複数のLinuxノードのホームディレクトリ(/home)共有を目的としている。
できればOpenLDAPによるアカウント統合も検証したい。
pcsd検証が2環境あるのは、単に16.04と18.04でそれぞれ確認してみたいというだけの理由だ。
別途確認してみたら、一度pcsdの管理下に置いたクラスタは、pcsd管理から外してもすぐに管理下に起き直すことができるようだ。
そのため、pcsd自体をHAクラスタにしなくても、同じクラスタを複数のpcsd管理下に置けるのではないか？と考えている。
そのため、2種類のHAクラスタを、両方のpcsd管理下に置くことを想定している。
もちろん、gfs2クラスタやNFSv4クラスタの各ノードでpcsd自体を稼働させる、ということも可能なはずだが、それは余裕があったら実装したい。
まぁゆっくりと…。
今現在、KVMホストになっているaquariusとsagittariusは、pacemakerを使用せずにgfs2でファイルシステムを共有している。
これでは不安定になるようなので、本格的にpacemakerの検証をしたい。
で、少し調べてみたら、pcsdというのを使うと、ブラウザから制御できるようだ。
いくつか検証中の仮想マシンを潰して、以下の環境を検証してみたい。
- gfs2クラスタ検証(Ubuntu16.04)*2台
- NFSv4クラスタ検証(Ubuntu18.04)*2台
- pcsd検証(Ubuntu16.04)*1台
- pcsd検証(Ubuntu18.04)*1台
NFSv4は、自宅とは別の環境で検証している環境用で、複数のLinuxノードのホームディレクトリ(/home)共有を目的としている。
できればOpenLDAPによるアカウント統合も検証したい。
pcsd検証が2環境あるのは、単に16.04と18.04でそれぞれ確認してみたいというだけの理由だ。
別途確認してみたら、一度pcsdの管理下に置いたクラスタは、pcsd管理から外してもすぐに管理下に起き直すことができるようだ。
そのため、pcsd自体をHAクラスタにしなくても、同じクラスタを複数のpcsd管理下に置けるのではないか？と考えている。
そのため、2種類のHAクラスタを、両方のpcsd管理下に置くことを想定している。
もちろん、gfs2クラスタやNFSv4クラスタの各ノードでpcsd自体を稼働させる、ということも可能なはずだが、それは余裕があったら実装したい。
まぁゆっくりと…。
2017年8月23日水曜日
KVM仮想マシンをHAクラスタ化
さて、意味があるのか無いのか、KVM仮想マシンごと、クラスタ制御にしてみようと思う。
ここでネックになる課題は、分かっている限り以下の2つ。
まずは仮想マシンの用意。
既に gemini / cancer 上には、leo と virgo の2つの仮想マシンが用意してある。
過去の検証で作成したものだ。
今回は、leo を使ってみよう。
作業前に、leo を起動して、ライブマイグレーションが可能かをチェックしておこう。
対象の仮想マシンが壊れていたら、HAクラスタ検証で問題が起きても切り分けが出来ない。
(gemini) $ virsh start leo
(gemini) $ virsh list --all
(cancer) $ virsh list --all
(gemini) $ virsh \
migrate --live \
--domain leo \
--change-protection \
--desturi qemu+ssh://(cancerのIP)/system \
--migrateuri tcp://(cancerのIP)/ \
--verbose
(gemini) $ virsh list --all
(cancer) $ virsh list --all
(cancer) $ virsh \
migrate --live \
--domain leo \
--change-protection \
--desturi qemu+ssh://(geminiのIP)/system \
--migrateuri tcp://(geminiのIP)/ \
--verbose
(cancer) $ virsh list --all
(gemini) $ virsh list --all
(leo) $ sudo systemctl poweroff
(gemini) $ virsh list --all
続いて、leo を1つのリソースとして、pacemaker に登録する。
使うリソースエージェントだけど…、どうやら ocf:vm.sh ってのがある。これのようだ。
(gemini) $ crm ra list ocf
(gemini) $ crm ra info ocf:vm.sh
info で出てきたオプションを頼りに、実際に登録してみる。
(gemini) $ sudo crm configure primitive vm-leo \
ocf:vm.sh \
params \
name=leo \
domain="geminiのIP cancerのIP" \
use_virsh=1
う～む。どう考えてもオプション少ないよなぁ。もっと設定しないとアカンと思うんだけど…。
WARNING: vm-leo: default timeout 20s for start is smaller than the advised 300
WARNING: vm-leo: default timeout 20s for stop is smaller than the advised 120
おっと！？ワーニングが出た。
タイムアウト値をチューニングする必要があったか。
それは別途実施しよう。
さて、どうなったかな？
(gemini) $ sudo crm configure show
ちゃんと定義が入ってる。
(gemini) $ sudo crm resouce show vm-leo
おっと、cancer 側で起動してるみたいだ。
(gemini) $ virsh list --all
(cancer) $ virsh list --all
確かに、cancer 側の leo が起動している。
さて…リソースを落とすと、どういう動きになるのだろうか？
leo を virt-viewer で見ておこう。
(cancer) $ virt-viewer vm-leo &
この状態でリソースを落としてみる。
(gemini) $ sudo crm resource stop vm-leo
gemini からでも実行できた。
普通にシャットダウンのシグナルが飛んでるようだ。
今度は、leo の内側からシャットダウンしてみよう。
この場合、pacemaker が「リソースが落ちた」と判断してリソース起動をし始めるのか、「正常停止」と見なすのか？どっちだろうか？
明示的に leo を止めているので、本来なら後者の正常停止なのだが…。
というわけで実践。
(gemini) $ sudo crm resource show vm-leo
(gemini) $ sudo crm resource start vm-leo
(cancer) $ virsh list --all
leo が起動したのを確認。
(cancer) $ virt-viewer leo &
leo のコンソールにログインして、シャットダウンしよう。
(leo) $ sudo systemctl poweroff
結果、どうなったかな…？
(gemini) $ virsh list --all
(cancer) $ virsh list --all
仮想マシンは停止している…。
(gemini) $ sudo crm resource show vm-leo
んっ！？リソース vm-leo は相変わらず cancer 上で動いていることになってるぞ！？
これはモニター機能が働いてないってことか？違うかも。
とりあえず leo を起動させ、リソースから停止しておく。
(cancer) $ virsh start leo
(gemini) $ sudo crm resource stop vm-leo
(gemini) $ sudo crm resouce show vm-leo
OS側から正規に停止したのがダメだったのかもしれない。
というわけで、ホントに障害を想定して、仮想マシンleo のプロセスを殺してみよう。
まずは起動。
(gemini) $ sudo crm resource start vm-leo
(gemini) $ sudo crm resource show vm-leo
(cancer) $ virsh list --all
cancer で稼働している leo のプロセスを確認してみよう。
(cancer) $ ps -ef | grep leo | grep -v grep
今回はプロセスID 5639 だった。
これを殺してみる。
(cancer) $ sudo kill 5639
(cancer) $ ps -ef | grep 5639 | grep -v grep
落ちた。
リソースは…？
(gemini) $ sudo crm resource show vm-leo
(cancer) $ sudo crm resource show vm-leo
あれ？cancer で動いていることになってるぞ…？
(cancer) $ virsh list --all
仮想マシンは停止している…。何故だ？
う～ん。
cancer ごと落としてみるか…。
まずは leo を起動しておく。
(cancer) $ virsh start leo
(cancer) $ virsh list --all
leo が起動したのを確認したら、leo のホストマシンである cancer を強制停止してみる。
cancer は今、aquarius 上で稼働しているので、aquarius から落としてみよう。
(aquarius) $ virsh list --all
(aquarius) $ virsh destroy cancer
(aquarius) $ virsh list --all
停止したのを確認したら、gemini から vm-leo の状態を確認してみよう。
(gemini) $ sudo crm resource show vm-leo
む？リソース的には gemini で稼働したことになったぞ？
仮想マシンは？
(gemini) $ virsh list --all
こっちで稼働し始めたようだ。
ちなみに、リソース定義は…予想では「vm-leo は cancer では起動しないよ」という定義も追加されてない…はず…。
(gemini) $ sudo crm configure show
やっぱり追加されてない。
優先順位は付けてないから、この状態で cancer を復旧させたら…？
(aquarius) $ virsh start cancer
(aquarius) $ virsh list --all
(cancer) $ sudo crm resource show
Error signing on to the CIB service: Transport endpoint is not connected
あ、あれ？エラーになった…。
(cancer) $ systemctl status pacemaker
pacemaker が corosync と通信できずに落ちた…？
pacemaker 再起動してみよう。
(cancer) $ sudo systemctl restart pacemaker
(cancer) $ systemctl status pacemaker
これで大丈夫かな？
(cancer) $ sudo crm resource show
(cancer) $ sudo crm resource show vm-leo
ん？cancer で動き出した！？
(cancer) $ virsh list --all
(gemini) $ virsh list --all
やっぱり、cancer で動き出したぞ！？
どうやら、cancer の各種プロセスが正常起動してなかったようだ。
これは…「ノードダウン」と「リソースダウン」で挙動が違う。
整理しないと…。リソースダウンの挙動と設定がまだ掴めて無いから、もっと調査しないと…。
自動フェイルバックについても整理する必要がありそうだ。
う～ん。
ここでネックになる課題は、分かっている限り以下の2つ。
- そもそも実現出来るの？
- ライブマイグレーション機能との相性は？
まずは仮想マシンの用意。
既に gemini / cancer 上には、leo と virgo の2つの仮想マシンが用意してある。
過去の検証で作成したものだ。
今回は、leo を使ってみよう。
作業前に、leo を起動して、ライブマイグレーションが可能かをチェックしておこう。
対象の仮想マシンが壊れていたら、HAクラスタ検証で問題が起きても切り分けが出来ない。
(gemini) $ virsh start leo
(gemini) $ virsh list --all
(cancer) $ virsh list --all
(gemini) $ virsh \
migrate --live \
--domain leo \
--change-protection \
--desturi qemu+ssh://(cancerのIP)/system \
--migrateuri tcp://(cancerのIP)/ \
--verbose
(gemini) $ virsh list --all
(cancer) $ virsh list --all
(cancer) $ virsh \
migrate --live \
--domain leo \
--change-protection \
--desturi qemu+ssh://(geminiのIP)/system \
--migrateuri tcp://(geminiのIP)/ \
--verbose
(cancer) $ virsh list --all
(gemini) $ virsh list --all
(leo) $ sudo systemctl poweroff
(gemini) $ virsh list --all
続いて、leo を1つのリソースとして、pacemaker に登録する。
使うリソースエージェントだけど…、どうやら ocf:vm.sh ってのがある。これのようだ。
(gemini) $ crm ra list ocf
(gemini) $ crm ra info ocf:vm.sh
info で出てきたオプションを頼りに、実際に登録してみる。
(gemini) $ sudo crm configure primitive vm-leo \
ocf:vm.sh \
params \
name=leo \
domain="geminiのIP cancerのIP" \
use_virsh=1
う～む。どう考えてもオプション少ないよなぁ。もっと設定しないとアカンと思うんだけど…。
WARNING: vm-leo: default timeout 20s for start is smaller than the advised 300
WARNING: vm-leo: default timeout 20s for stop is smaller than the advised 120
おっと！？ワーニングが出た。
タイムアウト値をチューニングする必要があったか。
それは別途実施しよう。
さて、どうなったかな？
(gemini) $ sudo crm configure show
ちゃんと定義が入ってる。
(gemini) $ sudo crm resouce show vm-leo
おっと、cancer 側で起動してるみたいだ。
(gemini) $ virsh list --all
(cancer) $ virsh list --all
確かに、cancer 側の leo が起動している。
さて…リソースを落とすと、どういう動きになるのだろうか？
leo を virt-viewer で見ておこう。
(cancer) $ virt-viewer vm-leo &
この状態でリソースを落としてみる。
(gemini) $ sudo crm resource stop vm-leo
gemini からでも実行できた。
普通にシャットダウンのシグナルが飛んでるようだ。
今度は、leo の内側からシャットダウンしてみよう。
この場合、pacemaker が「リソースが落ちた」と判断してリソース起動をし始めるのか、「正常停止」と見なすのか？どっちだろうか？
明示的に leo を止めているので、本来なら後者の正常停止なのだが…。
というわけで実践。
(gemini) $ sudo crm resource show vm-leo
(gemini) $ sudo crm resource start vm-leo
(cancer) $ virsh list --all
leo が起動したのを確認。
(cancer) $ virt-viewer leo &
leo のコンソールにログインして、シャットダウンしよう。
(leo) $ sudo systemctl poweroff
結果、どうなったかな…？
(gemini) $ virsh list --all
(cancer) $ virsh list --all
仮想マシンは停止している…。
(gemini) $ sudo crm resource show vm-leo
んっ！？リソース vm-leo は相変わらず cancer 上で動いていることになってるぞ！？
これはモニター機能が働いてないってことか？違うかも。
とりあえず leo を起動させ、リソースから停止しておく。
(cancer) $ virsh start leo
(gemini) $ sudo crm resource stop vm-leo
(gemini) $ sudo crm resouce show vm-leo
OS側から正規に停止したのがダメだったのかもしれない。
というわけで、ホントに障害を想定して、仮想マシンleo のプロセスを殺してみよう。
まずは起動。
(gemini) $ sudo crm resource start vm-leo
(gemini) $ sudo crm resource show vm-leo
(cancer) $ virsh list --all
cancer で稼働している leo のプロセスを確認してみよう。
(cancer) $ ps -ef | grep leo | grep -v grep
今回はプロセスID 5639 だった。
これを殺してみる。
(cancer) $ sudo kill 5639
(cancer) $ ps -ef | grep 5639 | grep -v grep
落ちた。
リソースは…？
(gemini) $ sudo crm resource show vm-leo
(cancer) $ sudo crm resource show vm-leo
あれ？cancer で動いていることになってるぞ…？
(cancer) $ virsh list --all
仮想マシンは停止している…。何故だ？
う～ん。
cancer ごと落としてみるか…。
まずは leo を起動しておく。
(cancer) $ virsh start leo
(cancer) $ virsh list --all
leo が起動したのを確認したら、leo のホストマシンである cancer を強制停止してみる。
cancer は今、aquarius 上で稼働しているので、aquarius から落としてみよう。
(aquarius) $ virsh list --all
(aquarius) $ virsh destroy cancer
(aquarius) $ virsh list --all
停止したのを確認したら、gemini から vm-leo の状態を確認してみよう。
(gemini) $ sudo crm resource show vm-leo
む？リソース的には gemini で稼働したことになったぞ？
仮想マシンは？
(gemini) $ virsh list --all
こっちで稼働し始めたようだ。
ちなみに、リソース定義は…予想では「vm-leo は cancer では起動しないよ」という定義も追加されてない…はず…。
(gemini) $ sudo crm configure show
やっぱり追加されてない。
優先順位は付けてないから、この状態で cancer を復旧させたら…？
(aquarius) $ virsh start cancer
(aquarius) $ virsh list --all
(cancer) $ sudo crm resource show
Error signing on to the CIB service: Transport endpoint is not connected
あ、あれ？エラーになった…。
(cancer) $ systemctl status pacemaker
pacemaker が corosync と通信できずに落ちた…？
pacemaker 再起動してみよう。
(cancer) $ sudo systemctl restart pacemaker
(cancer) $ systemctl status pacemaker
これで大丈夫かな？
(cancer) $ sudo crm resource show
(cancer) $ sudo crm resource show vm-leo
ん？cancer で動き出した！？
(cancer) $ virsh list --all
(gemini) $ virsh list --all
やっぱり、cancer で動き出したぞ！？
どうやら、cancer の各種プロセスが正常起動してなかったようだ。
これは…「ノードダウン」と「リソースダウン」で挙動が違う。
整理しないと…。リソースダウンの挙動と設定がまだ掴めて無いから、もっと調査しないと…。
自動フェイルバックについても整理する必要がありそうだ。
う～ん。
2017年8月3日木曜日
リソースの自動フェイルバック禁止設定
というわけで前回、リソースが稼働しているノード(gemini)を強制停止、リソースが対向ノード(cancer)へ自動フェイルオーバーすることを確認した。
その後、gemini を起動させたら、リソースが自動でフェイルバックしてしまった。
これはあまりよろしくない、ということで、自動フェイルバックはしないように設定してみたい。
これは、resouce-stickiness というパラメータで制御するようだ。
ただ、resource-agent(ra)固有のパラメータではなく、汎用パラメータのようで、crm ra info ocf:IPaddr2 では表示されない。
そのために探すのに時間がかかった。
他にも汎用パラメータはあるようだけど、とりあえずはコレだけ調べがついた。
取り急ぎ、設定を反映させる手順を。
手順としては2種類。
既に稼働中のシステムに対しては前者を使用することになるが、新たにリソースを作成するときには後者の知識があったほうが便利だ。
そのため、両方を試してみよう。
まずは前者、既に作成済みのリソースに対して設定を追加するやり方。
$ sudo crm configure show testip
$ sudo crm resource meta testip show resource-stickiness
そんなパラメータ無い！と怒られる。
$ sudo crm resource meta testip set resource-stickiness INFINITY
$ sudo crm configure show testip
$ sudo crm resource meta testip show resource-stickiness
設定できた。
果たしてこれでいいのだろうか？
前回と同じように試してみよう。
まずは手作業でフェイルオーバーだ。
$ sudo crm resource migrate testip
$ sudo crm resource show testip
$ sudo crm configure show
gemini で動いていた testip が cancer に移動した。
元に戻そう。
$ sudo crm resource unmigrate testip
$ sudo crm resource show testip
…あれ？戻らなかったぞ？
ちなみに
--
location cli-ban-testip-on-gemini testip role=Started -inf: gemini
--
のエントリは消えた。
ということは、もう一回 migrate したら…？
$ sudo crm resource migrate testip
$ sudo crm resource show testip
$ sudo crm configure show
ふぅむ。リソースは gemini に戻ってきたが、その代わりに
--
location cli-ban-testip-on-cancer testip role=Started -inf: cancer
--
というエントリが追加されたか…。
もう一度 unmigrate してみよう。
$ sudo crm resource unmigrate testip
$ sudo crm resource show testip
gemini で稼働している状態で変化なし。
$ sudo crm configure show
--
location cli-ban-testip-on-cancer testip role=Started -inf: cancer
--
このエントリは無くなった。
なるほど…。migrate コマンドは、「当該ノードでは動かさないよ」マークを付けるだけの仕様なのか…。
ちょっと試してみよう。
(migrate コマンドではなく、直接 location を入れてみる)
$ sudo crm configure show
$ sudo crm resouce show testip
gemini で動いていることを確認して…
$ sudo crm configure location cli-ban-testip-on-gemini testip role=Started -inf: gemini
$ sudo crm configure show
$ sudo crm resource show testip
ふむ。やっぱり予想通り、testip リソースが cancer に移った。
なるほどねぇ。じゃぁこの状態で unmigrate したら…？
$ sudo crm resource unmigrate testip
$ sudo crm configure show
追加した location エントリは消えた。
$ sudo crm resource show testip
でも cancer で稼働し続けている。
だんだん見えてきた。
それじゃぁ今度は、実際の障害テストだ。
testip リソースを gemini に戻すが、面倒なので停止→起動の手順を踏む。
$ sudo crm resource stop testip
$ sudo crm resource start testip
$ sudo crm resource show testip
$ sudo crm configure show
ヨシ。
障害テストだ。
前回と同様、gemini を載せているホストマシン sagittarius から、gemini を強制的に停止させる。
testip が cancer 側に移ってくるはずだ。
(sagittarius) $ virsh destroy gemini
やはり 10秒ほどで、cancer に移動したようだ。
(cancer) $ sudo crm resource show testip
(cancer) $ sudo crm configure show
っと、「gemini では動かしちゃダメだよ」ルールも追加されていない。
前回と同じ挙動だ。
ここで gemini を復旧させる。
前回は、testip リソースが勝手に gemini に戻ったが、今回は勝手に戻ることは無いはずだ。
(sagittarius) $ virsh start gemini
(gemini) $ sudo crm resource show testip
予想通り、cancer 側には戻ってきていない。
これが前回との差異か。
実際の障害→復旧の流れだと、この時点で gemini の H/W 及び OS の正常性確認を行った後、サービス(リソース)を gemini 側に移動させるのだけど、クラスタ製品によっては、「戻す」というオペレーションではなく、「サービスを停止→起動」というオペレーションになる。
pacemaker だとどうなんだろう？
migrate だと location 制約が出来てしまい、unmigrate だと移動まではしてくれない。
「障害からの復旧」だから、「サービス停止→起動」でいいんだろう。
$ sudo crm resource stop testip
$ sudo crm resource start testip
$ sudo crm resource show testip
$ sudo crm configure show
復旧オペレーションはこれでオシマイかな？
さて最後に「一旦リソースを削除し、新たに作成するやり方」方法を書いておく。
まずは当該リソースを停止
$ sudo crm resource stop testip
$ sudo crm resource show testip
$ sudo crm configure show
続いて、リソースを削除
$ sudo crm configure delete testip_loc
$ sudo crm configure delete testip
$ sudo crm configure show
自動フェイルバックを Off にしてリソースを作成
$ sudo crm configure primitive testip \
ocf:heartbeat:IPaddr2 \
params \
ip="192.168.55.155" \
meta \
resource-stickiness="INFINITY"
$ sudo crm configure \
location testip_loc testip \
rule 100: \#uname eq gemini \
rule 50: \#uname eq cancer
結果の確認
$ sudo crm resource show testip
(cancer で起動してしまったので、リソースを再起動)
$ sudo crm resource restart testip
$ sudo crm resource show testip
$ sudo crm configure show
出来た。
これでリソースの自動フェイルバック禁止はOKだ。
リソース定義は他にも色々細かい設定があるようだけど、IPリソースの定義はこのあたりにしておいて、次回は KVMゲストを HA クラスタのリソースとして定義してみようと思う。
その後、gemini を起動させたら、リソースが自動でフェイルバックしてしまった。
これはあまりよろしくない、ということで、自動フェイルバックはしないように設定してみたい。
これは、resouce-stickiness というパラメータで制御するようだ。
ただ、resource-agent(ra)固有のパラメータではなく、汎用パラメータのようで、crm ra info ocf:IPaddr2 では表示されない。
そのために探すのに時間がかかった。
他にも汎用パラメータはあるようだけど、とりあえずはコレだけ調べがついた。
取り急ぎ、設定を反映させる手順を。
手順としては2種類。
- 既に作成済みのリソース、iptest に対して設定を追加するやり方
- 一旦リソースを削除し、新たに作成するやり方
既に稼働中のシステムに対しては前者を使用することになるが、新たにリソースを作成するときには後者の知識があったほうが便利だ。
そのため、両方を試してみよう。
まずは前者、既に作成済みのリソースに対して設定を追加するやり方。
$ sudo crm configure show testip
$ sudo crm resource meta testip show resource-stickiness
そんなパラメータ無い！と怒られる。
$ sudo crm resource meta testip set resource-stickiness INFINITY
$ sudo crm configure show testip
$ sudo crm resource meta testip show resource-stickiness
設定できた。
果たしてこれでいいのだろうか？
前回と同じように試してみよう。
まずは手作業でフェイルオーバーだ。
$ sudo crm resource migrate testip
$ sudo crm resource show testip
$ sudo crm configure show
gemini で動いていた testip が cancer に移動した。
元に戻そう。
$ sudo crm resource unmigrate testip
$ sudo crm resource show testip
…あれ？戻らなかったぞ？
ちなみに
--
location cli-ban-testip-on-gemini testip role=Started -inf: gemini
--
のエントリは消えた。
ということは、もう一回 migrate したら…？
$ sudo crm resource migrate testip
$ sudo crm resource show testip
$ sudo crm configure show
ふぅむ。リソースは gemini に戻ってきたが、その代わりに
--
location cli-ban-testip-on-cancer testip role=Started -inf: cancer
--
というエントリが追加されたか…。
もう一度 unmigrate してみよう。
$ sudo crm resource unmigrate testip
$ sudo crm resource show testip
gemini で稼働している状態で変化なし。
$ sudo crm configure show
--
location cli-ban-testip-on-cancer testip role=Started -inf: cancer
--
このエントリは無くなった。
なるほど…。migrate コマンドは、「当該ノードでは動かさないよ」マークを付けるだけの仕様なのか…。
ちょっと試してみよう。
(migrate コマンドではなく、直接 location を入れてみる)
$ sudo crm configure show
$ sudo crm resouce show testip
gemini で動いていることを確認して…
$ sudo crm configure location cli-ban-testip-on-gemini testip role=Started -inf: gemini
$ sudo crm configure show
$ sudo crm resource show testip
ふむ。やっぱり予想通り、testip リソースが cancer に移った。
なるほどねぇ。じゃぁこの状態で unmigrate したら…？
$ sudo crm resource unmigrate testip
$ sudo crm configure show
追加した location エントリは消えた。
$ sudo crm resource show testip
でも cancer で稼働し続けている。
だんだん見えてきた。
それじゃぁ今度は、実際の障害テストだ。
testip リソースを gemini に戻すが、面倒なので停止→起動の手順を踏む。
$ sudo crm resource stop testip
$ sudo crm resource start testip
$ sudo crm resource show testip
$ sudo crm configure show
ヨシ。
障害テストだ。
前回と同様、gemini を載せているホストマシン sagittarius から、gemini を強制的に停止させる。
testip が cancer 側に移ってくるはずだ。
(sagittarius) $ virsh destroy gemini
やはり 10秒ほどで、cancer に移動したようだ。
(cancer) $ sudo crm resource show testip
(cancer) $ sudo crm configure show
っと、「gemini では動かしちゃダメだよ」ルールも追加されていない。
前回と同じ挙動だ。
ここで gemini を復旧させる。
前回は、testip リソースが勝手に gemini に戻ったが、今回は勝手に戻ることは無いはずだ。
(sagittarius) $ virsh start gemini
(gemini) $ sudo crm resource show testip
予想通り、cancer 側には戻ってきていない。
これが前回との差異か。
実際の障害→復旧の流れだと、この時点で gemini の H/W 及び OS の正常性確認を行った後、サービス(リソース)を gemini 側に移動させるのだけど、クラスタ製品によっては、「戻す」というオペレーションではなく、「サービスを停止→起動」というオペレーションになる。
pacemaker だとどうなんだろう？
migrate だと location 制約が出来てしまい、unmigrate だと移動まではしてくれない。
「障害からの復旧」だから、「サービス停止→起動」でいいんだろう。
$ sudo crm resource stop testip
$ sudo crm resource start testip
$ sudo crm resource show testip
$ sudo crm configure show
復旧オペレーションはこれでオシマイかな？
さて最後に「一旦リソースを削除し、新たに作成するやり方」方法を書いておく。
まずは当該リソースを停止
$ sudo crm resource stop testip
$ sudo crm resource show testip
$ sudo crm configure show
続いて、リソースを削除
$ sudo crm configure delete testip_loc
$ sudo crm configure delete testip
$ sudo crm configure show
自動フェイルバックを Off にしてリソースを作成
$ sudo crm configure primitive testip \
ocf:heartbeat:IPaddr2 \
params \
ip="192.168.55.155" \
meta \
resource-stickiness="INFINITY"
$ sudo crm configure \
location testip_loc testip \
rule 100: \#uname eq gemini \
rule 50: \#uname eq cancer
結果の確認
$ sudo crm resource show testip
(cancer で起動してしまったので、リソースを再起動)
$ sudo crm resource restart testip
$ sudo crm resource show testip
$ sudo crm configure show
出来た。
これでリソースの自動フェイルバック禁止はOKだ。
リソース定義は他にも色々細かい設定があるようだけど、IPリソースの定義はこのあたりにしておいて、次回は KVMゲストを HA クラスタのリソースとして定義してみようと思う。
2017年8月2日水曜日
リソースの稼働先(優先度)を指定
前回、testip というリソースを作成した。
この testip 、起動時には gemini / cancer のいずれのノードで稼働するかは不定だ。
(どうも、cancer で起動しようとするようだ…。)
これを、
やり方はそんなに難しくない。
リソースの稼働優先度を付ければいい。
(前回、stonith リソースの稼働先を指定したコマンドとほぼ同じだ。)
まずは testip の停止
$ sudo crm resource show testip
$ sudo crm resource stop testip
$ sudo crm resource show testip
testip のリソースに対して、 gemini:100 cancer:50 の優先度をつける
$ sudo crm configure show
$ sudo crm configure \
location testip_loc testip \
rule 100: \#uname eq gemini \
rule 50: \#uname eq cancer
$ sudo crm configure show
$ sudo crm configure show testip_loc
これで、gemini の方が優先度が高くなったため、gemini が稼働中であれば、testip は gemini で起動してくるはずだ。
試してみよう。
$ sudo crm resource show testip
$ sudo crm resource start testip
$ sudo crm resource show testip
start / stop を繰り返してみたり、cancer のコマンドラインから start を仕掛けてみて、毎回必ず gemini 側で起動することを確認しよう。
gemini 側で起動することが確認できたら、手作業でフェイルオーバー(厳密にはテイクオーバー)させてみよう。
自動的に、cancer 側で動き出すはずだ。
$ sudo crm resource migrate testip
$ sudo crm resource show testip
$ sudo crm configure show
フェイルオーバーさせたら、
location cli-ban-testip-on-gemini testip role=Started -inf: gemini
というルールが追加されたと思う。
前回の解説の通り、「このリソースは gemini では動かさないよ」というものだ。
この状態で、もう一度 migrate 仕掛けてみよう。
$ sudo crm resource migrate testip
$ sudo crm resource show testip
testip は停止している。
$ sudo crm configure show
location cli-ban-testip-on-cancer testip role=Started -inf: cancer
というルールも追加された。
gemini / cancer の2つしかノードが無いので、このルールによって、稼働可能なノードが無くなり、リソース停止になったわけだ。
＃イメージとしては、gemini がシステムダウンをし、cancer 側でサービスを継続していたが、gemini を復旧させる前に cancer もダウンしてしまった、という状態だ。
さて、では元に戻すにはどうすればいい？
単純に起動させてみると…
$ sudo crm resource start testip
$ sudo crm resource show testip
動いていない。
やはり unmigrate なのだろうか？
$ sudo crm resource unmigrate testip
$ sudo crm resource show testip
おっと！gemini で動き出した。
状態は…？
$ sudo crm configure show
追加された2つのルールは削除されている。これによって gemini で稼働し始めたか。
さて今度は、本当に障害を発生させてみよう。
gemini を載せているホストマシン sagittarius から、gemini を強制的に停止させてみる。
これで testip が cancer 側に移ってくれれば、期待した動きと言える。
(sagittarius) $ virsh destroy gemini
10秒ほどで、cancer に移動したようだ。
(cancer) $ sudo crm resource show testip
(cancer) $ sudo crm configure show
っと、例の「gemini では動かしちゃダメだよ」ルールが追加されていない。
crm migrate を実施した時と若干挙動が違うな…。そういうものなのか？
もしかして、gemini が復旧したら、リソースが自動的に gemini に戻る？
確認してみよう。
(sagittarius) $ virsh start gemini
(gemini) $ sudo crm resource show testip
なんと！？gemini 側に戻ってきている！
これはちょっとよろしく無いな…。
プライマリノードがダウンした場合、スレーブノード(待機系)で自動的にサービス再開する、というのはHAクラスタとしては理想の動き。
だけど、プライマリノードが復旧したら、サービスが自動的にプライマリノードに戻る、というのは良くない。
戻る時、スレーブノードでサービスが停止し、プライマリノードでサービスが起動する、という動きになるため、一時的にサービスが止まってしまう。
サービスが止まることが予め予想出来るのなら、業務影響の少ない夜間の特定時間帯に戻す、という要求が出て当然だ。
大抵の業務クラスタはそうなっている。
＃自動フェイルバック禁止、というような表現だ。
さて、その自動フェイルバックを禁止する方法だけど…。
これについては次回にして、今回はココまでにしよう。
この testip 、起動時には gemini / cancer のいずれのノードで稼働するかは不定だ。
(どうも、cancer で起動しようとするようだ…。)
これを、
- 通常時は gemini で稼働
- gemini が停止している時は cancer で稼働
やり方はそんなに難しくない。
リソースの稼働優先度を付ければいい。
(前回、stonith リソースの稼働先を指定したコマンドとほぼ同じだ。)
まずは testip の停止
$ sudo crm resource show testip
$ sudo crm resource stop testip
$ sudo crm resource show testip
testip のリソースに対して、 gemini:100 cancer:50 の優先度をつける
$ sudo crm configure show
$ sudo crm configure \
location testip_loc testip \
rule 100: \#uname eq gemini \
rule 50: \#uname eq cancer
$ sudo crm configure show
$ sudo crm configure show testip_loc
これで、gemini の方が優先度が高くなったため、gemini が稼働中であれば、testip は gemini で起動してくるはずだ。
試してみよう。
$ sudo crm resource show testip
$ sudo crm resource start testip
$ sudo crm resource show testip
start / stop を繰り返してみたり、cancer のコマンドラインから start を仕掛けてみて、毎回必ず gemini 側で起動することを確認しよう。
gemini 側で起動することが確認できたら、手作業でフェイルオーバー(厳密にはテイクオーバー)させてみよう。
自動的に、cancer 側で動き出すはずだ。
$ sudo crm resource migrate testip
$ sudo crm resource show testip
$ sudo crm configure show
フェイルオーバーさせたら、
location cli-ban-testip-on-gemini testip role=Started -inf: gemini
というルールが追加されたと思う。
前回の解説の通り、「このリソースは gemini では動かさないよ」というものだ。
この状態で、もう一度 migrate 仕掛けてみよう。
$ sudo crm resource migrate testip
$ sudo crm resource show testip
testip は停止している。
$ sudo crm configure show
location cli-ban-testip-on-cancer testip role=Started -inf: cancer
というルールも追加された。
gemini / cancer の2つしかノードが無いので、このルールによって、稼働可能なノードが無くなり、リソース停止になったわけだ。
＃イメージとしては、gemini がシステムダウンをし、cancer 側でサービスを継続していたが、gemini を復旧させる前に cancer もダウンしてしまった、という状態だ。
さて、では元に戻すにはどうすればいい？
単純に起動させてみると…
$ sudo crm resource start testip
$ sudo crm resource show testip
動いていない。
やはり unmigrate なのだろうか？
$ sudo crm resource unmigrate testip
$ sudo crm resource show testip
おっと！gemini で動き出した。
状態は…？
$ sudo crm configure show
追加された2つのルールは削除されている。これによって gemini で稼働し始めたか。
さて今度は、本当に障害を発生させてみよう。
gemini を載せているホストマシン sagittarius から、gemini を強制的に停止させてみる。
これで testip が cancer 側に移ってくれれば、期待した動きと言える。
(sagittarius) $ virsh destroy gemini
10秒ほどで、cancer に移動したようだ。
(cancer) $ sudo crm resource show testip
(cancer) $ sudo crm configure show
っと、例の「gemini では動かしちゃダメだよ」ルールが追加されていない。
crm migrate を実施した時と若干挙動が違うな…。そういうものなのか？
もしかして、gemini が復旧したら、リソースが自動的に gemini に戻る？
確認してみよう。
(sagittarius) $ virsh start gemini
(gemini) $ sudo crm resource show testip
なんと！？gemini 側に戻ってきている！
これはちょっとよろしく無いな…。
プライマリノードがダウンした場合、スレーブノード(待機系)で自動的にサービス再開する、というのはHAクラスタとしては理想の動き。
だけど、プライマリノードが復旧したら、サービスが自動的にプライマリノードに戻る、というのは良くない。
戻る時、スレーブノードでサービスが停止し、プライマリノードでサービスが起動する、という動きになるため、一時的にサービスが止まってしまう。
サービスが止まることが予め予想出来るのなら、業務影響の少ない夜間の特定時間帯に戻す、という要求が出て当然だ。
大抵の業務クラスタはそうなっている。
＃自動フェイルバック禁止、というような表現だ。
さて、その自動フェイルバックを禁止する方法だけど…。
これについては次回にして、今回はココまでにしよう。
2017年7月26日水曜日
とりあえずリソース作ってみる
pacemaker が起動したので、今度は リソース を作ってみる。
pacemaker ってのは、その上で動かす(クラスタ制御下に置く)サービス(例えばデータベースサービス)とかを、リソースと呼ばれる単位の集まりで制御している。
意味がわからんね。
HAクラスタを実現するためには、大きく3つの物を制御する必要がある。
(これら3要素のうち、幾つかを必要としないサービスも存在する)
で、pacemaker では、これらの要素1つ1つを「リソース」として登録し、リソースの組み合わせでサービスを提供する形になっている。
あくまでとりあえず、1つリソースを登録してみる。
IPアドレスが簡単かな？
登録は crm コマンドを使用する。
また、リソースは resource agent (ra)というキットに用意されているものを使用するのがラクだ。(自分で作ることも出来るけど、それはまた後日…)
というわけで、ra の確認だが…。
ra はクラスごとに分けられている。
まずは、クラスの一覧を確認してみよう。
(gemini) $ crm ra classes
lsb
ocf / .isolation heartbeat lvm2 pacemaker redhat
service
stonith
systemd
5個出てきた。
それぞれ、
lsb : linux standard base (/etc/init.d のスクリプトだ)
ocf : Open Cluster Framework 準拠のサービス
service : service コマンドで起動停止する対象のサービス
stonith : stonith 専用の処理
systemd : systemd のルールに則ったサービス
という意味だ。うん。さっぱり分からんね。
殆どは ocf クラスに定義されていると思っていい。
ただ、今まで /etc/init.d や systemd によって起動停止していたサービスを pacemaker によってクラスタ化する、というのであれば、lsb や systemd 等のクラスに定義されているはずだ。
IPアドレスは ocf に定義されているが、一応リストを見てみよう。
(gemini) $ crm ra list lsb
(gemini) $ crm ra list ocf
(gemini) $ crm ra list service
(gemini) $ crm ra list stonith
(gemini) $ crm ra list systemd
たくさん出てきたと思うが、ocf の中に IPaddr、IPaddr2、IPsrcaddr、IPv6addr というソレっぽいのが見つかったと思う。
答えから言ってしまうと IPaddr2 が今回使用する ra だが、これらの詳細を確認するコマンドも実行しておこう。
(gemini) $ crm ra info ocf:IPaddr
(gemini) $ crm ra info ocf:IPaddr2
(gemini) $ crm ra info ocf:IPsrcaddr
(gemini) $ crm ra info ocf:IPv6addr
ざっと見ても分かる通り、IPaddr2 が Linux 専用に用意された ra だ。
専用というぐらいだから、これを使うのがいいだろう。
パラメータは…
ip
nic
cidr_netmask
broadcast
iflabel
lvs_support
lvs_ipv6_addrlabel
lvs_ipv6_addrlabel_value
mac
clusterip_hash
unique_clone_address
arp_interval
arp_count
arp_bg
arp_mac
arp_sender
flush_routes
だ。(結構あるな…)
さらに、オペレーションデフォルト値として、
start timeout=20s
stop timeout=20s
status timeout=20s intervals=10s
monitor timeout=20s intervals=10s
とある。
まぁ、必須なのは最初の ip だけなので、これだけ指定して作ってみよう。
(gemini) $ sudo crm configure primitive testip \
ocf:heartbeat:IPaddr2 \
params \
ip="192.168.55.155"
おっと！
ERROR: error: unpack_resources: Resource start-up disabled since no STONITH resources have been defined
error: unpack_resources: Either configure some or disable STONITH with the stonith-enabled option
error: unpack_resources: NOTE: Clusters with shared data need STONITH to ensure data integrity
Errors found during check: config not valid
Do you still want to commit (y/n)?
というエラーが出た。
とりあえず、最後の質問には n と答えておく。
どうやら、stonith の設定を施すか、stonith 自体を無効化しておく必要があるようだ。
stonith ってのは、どうやら対向ノードが完全クラッシュではなく、中途半端に止まってしまった時に、強制的に再起動等を実施する仕組みのようだ。
今回、gemini / cancer でクラスタにしないサービスも稼働させるツモリなので、再起動はしないようにしておきたい。
なので、stonith を無効にする。
無効にするには、stonith として null を使用するか、stonith 自体を無効化するようだ。
null を使用するのはあくまでテスト目的のようだが、今回は敢えて null を使用してみたい。
まずは stonith の一覧確認。
(gemini) $ crm ra list stonith
たくさん出てくるが、null というのがあるか確認しておく。
stonith:null の詳細確認。
(gemini) $ crm ra info stonith:null
実際に設定してみる。
(ココでは、stonith2gemini というのが gemini 障害時に gemini を強制再起動させるリソース、stonith2cancer というのを cancer 障害時に cancer を強制再起動させるリソースとして想定している。null エージェントなので、実際には何も起きないはずだが。)
(gemini) $ sudo crm configure primitive stonith2gemini \
stonith:null \
params \
hostlist="gemini"
(gemini) $ sudo crm configure primitive stonith2cancer \
stonith:null \
params \
hostlist="cancer"
を？すんなり通った。
出来たのだろうか…？
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm_mon
動いているようだ。
ただこのままでは、stonith2gemini が gemini で、stonith2cancer が cancer で稼働してしまうかもしれない。
そのため、リソースが稼働するサーバ(ノード)を固定させる必要がある。
どうやら、 location という定義で指定できるようだ。
(gemini) $ sudo crm configure help location
ヘルプを見てみると、どうやら以下のような記述でリソース稼働を固定させることが出来るようだ。
location ＜識別子＞ ＜リソース名＞ \
rule 100: #uname eq ＜リソースを動かしたいノード名＞ \
rule -INFINITY: #uname eq ＜リソースを動かしたくないノード名＞
＃-INFINITY は -inf と書くことも出来るみたいだ。
これを実際に適用するコマンドは以下の通り。
(gemini) $ sudo crm configure \
location stonith2gemini_loc stonith2gemini \
rule 100: \#uname eq cancer \
rule -inf: \#uname eq gemini
(gemini) $ sudo crm configure \
location stonith2cancer_loc stonith2cancer \
rule 100: \#uname eq gemini \
rule -inf: \#uname eq cancer
＃コマンドラインから実行する場合、 #uname でシェルのコメントになってしまう。
＃そのため、 \ でコメントを無効化しよう。
出来上がったか確認。
(gemini) $ sudo crm_mon -A
(gemini) $ sudo crm configure show
設定は出来たっぽい。
さて、とりあえずこの2つ、起動停止してみたい。(単なるリソースだから、起動停止できるはず…)
(gemini) $ sudo crm resource stop stonith2gemini
(gemini) $ sudo crm resource stop stonith2cancer
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm_mon -A
止まったっぽい。
今度は起動。
(gemini) $ sudo crm resource start stonith2gemini
(gemini) $ sudo crm resource start stonith2cancer
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm_mon -A
ちゃんと起動したっぽい。
起動停止させると、それぞれの syslog にも記録される。
これ、強制的にノードを指定して起動させるコマンドは無いのだろうか？
(対向ノードでは起動しない設定(-inf)なので、ノード指定の起動はエラーになるはず…)
う～ん。調べてみても、リソースを起動する時に、ノードを指定する方法が見当たらない。起動しているリソースを、他のノードに移動させる、というコマンドなら用意されているようだ。
それが resource migrate コマンドのようだ。(crm help resource migrate で簡単なオプションが表示される)
試してみよう。
(gemini) $ sudo crm status --verbose
stonith2gemini が cancer 上で動いており、stonith2cancer が gemni 上で動いているのが分かる。
では、stonith2gemini を gemini 上に移動させてみよう。(移動出来ないのが正解のはずだ。)
(gemini) $ sudo crm resource migrate stonith2gemini gemini
…何もエラーは起きない。
どうなっただろうか。
(gemini) $ sudo crm status --verbose
おや？何も変化していないぞ？
いや、変化しないことが正解なんだけど…。何もメッセージが出ていないのはちょっと気持ち悪いな。
ただ、クラスタ定義に1つエントリが追加されているのに気付いた。
(gemini) $ sudo crm configure show
--
前略
location cli-prefer-stonith2gemini stonith2gemini role=Started inf: gemini
後略
--
だ。
これを見ると、stonith2gemini は gemini で動く、という定義に見えるが…。
この状態でリソースを停止→起動してみるとどうなるだろうか？
(gemini) $ sudo crm resource stop stonith2gemini
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm configure show
(gemini) $ sudo crm resource start stonith2gemini
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm configure show
やっぱりリソースは cancer で動いているし、謎の location エントリは消えていない。
これが正しい動作なのだろうか…。
とりあえず、謎の location エントリは削除しておこう。
migrate で現れたステータスなので、消すのは unmigrate だ。
(gemini) $ sudo crm resource unmigrate stonith2gemini
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm configure show
元に戻った。
とりあえず、ダミーの stonith リソースは出来た。
一旦仕切り直して、IPアドレスのリソースを作ってみよう。
最初の方で警告が出たコマンドを実行してみよう。
(gemini) $ sudo crm configure primitive testip \
ocf:heartbeat:IPaddr2 \
params \
ip="192.168.55.155"
今度はすんなり通った。
状態を確認してみる。
(gemini) $ sudo crm configure show
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm_mon -A
testip リソースは cancer で動き出したな。
(何故か、cancer で優先的に動く。この辺りは何か理由があるんだろうけど、location 定義で制御するのが正しいんだろうな。)
とりあえず、cancer で IPアドレス が付与されているはずなので確認してみよう。
(cancer) $ ip address show
cancer で 192.168.55.155 が付与されたのが確認できた。
gemini から疎通確認。
(gemini) $ ping -c 5 192.168.55.155
ちゃんと応答がある。
では、cancer で動き出したリソースを、他のノード(今回は gemini しかいないので gemini )へ移動させてみよう。
(gemini) $ sudo crm resource migrate testip
(gemini) $ sudo crm status show
(gemini) $ sudo ip address show
(cancer) $ sudo ip address show
192.168.55.155 の IPアドレス は、無事に gemini に移動した。
この状態で configure を見てみると…
(gemini) $ sudo crm configure show
--
location cli-ban-testip-on-cancer testip role=Started -inf: cancer
--
このエントリが追加されている。
これ、よく見てみると -inf: cancer となっていて、このリソースはもう cancer では動かせない、という定義だ。
pacemaker で primtive リソースとして定義されたリソースは、migrate させると、元のノード(先程の例では cancer )がダウンしたものとして、そのリソースは cancer には戻らないようになるようだ。
この辺り、クラスタ定義かリソース定義で変更出来ると思うけど、別途調査しないと分からない。
そのため、もう一回この testip リソースを migrate しようとすると、移動先のノードが無いため、リソース自身が停止してしまう。
もう少しこのリソースを元に調査をしたいが、今回はここまでにしよう。
(ちょっと長すぎたかな？)
一旦、リソースは元に戻しておく。
(gemini) $ sudo crm resource unmigrate testip
というわけで一旦終了。
pacemaker ってのは、その上で動かす(クラスタ制御下に置く)サービス(例えばデータベースサービス)とかを、リソースと呼ばれる単位の集まりで制御している。
意味がわからんね。
HAクラスタを実現するためには、大きく3つの物を制御する必要がある。
- サービス用IPアドレス
- サービス用ディスク
- サービスプロセス
- クライアントからアクセスを受け付けるIPアドレス
サービスを提供する方のノード(サーバ)に、このIPアドレスを付与する。 - データやプログラムが入っているディスク
サービスを提供する方のノード(サーバ)で、このディスクをマウントする。 - データベースプロセスそのもの
上の2つが整ったら、データベースを起動する
(これら3要素のうち、幾つかを必要としないサービスも存在する)
で、pacemaker では、これらの要素1つ1つを「リソース」として登録し、リソースの組み合わせでサービスを提供する形になっている。
あくまでとりあえず、1つリソースを登録してみる。
IPアドレスが簡単かな？
登録は crm コマンドを使用する。
また、リソースは resource agent (ra)というキットに用意されているものを使用するのがラクだ。(自分で作ることも出来るけど、それはまた後日…)
というわけで、ra の確認だが…。
ra はクラスごとに分けられている。
まずは、クラスの一覧を確認してみよう。
(gemini) $ crm ra classes
lsb
ocf / .isolation heartbeat lvm2 pacemaker redhat
service
stonith
systemd
5個出てきた。
それぞれ、
lsb : linux standard base (/etc/init.d のスクリプトだ)
ocf : Open Cluster Framework 準拠のサービス
service : service コマンドで起動停止する対象のサービス
stonith : stonith 専用の処理
systemd : systemd のルールに則ったサービス
という意味だ。うん。さっぱり分からんね。
殆どは ocf クラスに定義されていると思っていい。
ただ、今まで /etc/init.d や systemd によって起動停止していたサービスを pacemaker によってクラスタ化する、というのであれば、lsb や systemd 等のクラスに定義されているはずだ。
IPアドレスは ocf に定義されているが、一応リストを見てみよう。
(gemini) $ crm ra list lsb
(gemini) $ crm ra list ocf
(gemini) $ crm ra list service
(gemini) $ crm ra list stonith
(gemini) $ crm ra list systemd
たくさん出てきたと思うが、ocf の中に IPaddr、IPaddr2、IPsrcaddr、IPv6addr というソレっぽいのが見つかったと思う。
答えから言ってしまうと IPaddr2 が今回使用する ra だが、これらの詳細を確認するコマンドも実行しておこう。
(gemini) $ crm ra info ocf:IPaddr
(gemini) $ crm ra info ocf:IPaddr2
(gemini) $ crm ra info ocf:IPsrcaddr
(gemini) $ crm ra info ocf:IPv6addr
ざっと見ても分かる通り、IPaddr2 が Linux 専用に用意された ra だ。
専用というぐらいだから、これを使うのがいいだろう。
パラメータは…
ip
nic
cidr_netmask
broadcast
iflabel
lvs_support
lvs_ipv6_addrlabel
lvs_ipv6_addrlabel_value
mac
clusterip_hash
unique_clone_address
arp_interval
arp_count
arp_bg
arp_mac
arp_sender
flush_routes
だ。(結構あるな…)
さらに、オペレーションデフォルト値として、
start timeout=20s
stop timeout=20s
status timeout=20s intervals=10s
monitor timeout=20s intervals=10s
とある。
まぁ、必須なのは最初の ip だけなので、これだけ指定して作ってみよう。
(gemini) $ sudo crm configure primitive testip \
ocf:heartbeat:IPaddr2 \
params \
ip="192.168.55.155"
おっと！
ERROR: error: unpack_resources: Resource start-up disabled since no STONITH resources have been defined
error: unpack_resources: Either configure some or disable STONITH with the stonith-enabled option
error: unpack_resources: NOTE: Clusters with shared data need STONITH to ensure data integrity
Errors found during check: config not valid
Do you still want to commit (y/n)?
というエラーが出た。
とりあえず、最後の質問には n と答えておく。
どうやら、stonith の設定を施すか、stonith 自体を無効化しておく必要があるようだ。
stonith ってのは、どうやら対向ノードが完全クラッシュではなく、中途半端に止まってしまった時に、強制的に再起動等を実施する仕組みのようだ。
今回、gemini / cancer でクラスタにしないサービスも稼働させるツモリなので、再起動はしないようにしておきたい。
なので、stonith を無効にする。
無効にするには、stonith として null を使用するか、stonith 自体を無効化するようだ。
null を使用するのはあくまでテスト目的のようだが、今回は敢えて null を使用してみたい。
まずは stonith の一覧確認。
(gemini) $ crm ra list stonith
たくさん出てくるが、null というのがあるか確認しておく。
stonith:null の詳細確認。
(gemini) $ crm ra info stonith:null
実際に設定してみる。
(ココでは、stonith2gemini というのが gemini 障害時に gemini を強制再起動させるリソース、stonith2cancer というのを cancer 障害時に cancer を強制再起動させるリソースとして想定している。null エージェントなので、実際には何も起きないはずだが。)
(gemini) $ sudo crm configure primitive stonith2gemini \
stonith:null \
params \
hostlist="gemini"
(gemini) $ sudo crm configure primitive stonith2cancer \
stonith:null \
params \
hostlist="cancer"
を？すんなり通った。
出来たのだろうか…？
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm_mon
動いているようだ。
ただこのままでは、stonith2gemini が gemini で、stonith2cancer が cancer で稼働してしまうかもしれない。
そのため、リソースが稼働するサーバ(ノード)を固定させる必要がある。
どうやら、 location という定義で指定できるようだ。
(gemini) $ sudo crm configure help location
ヘルプを見てみると、どうやら以下のような記述でリソース稼働を固定させることが出来るようだ。
location ＜識別子＞ ＜リソース名＞ \
rule 100: #uname eq ＜リソースを動かしたいノード名＞ \
rule -INFINITY: #uname eq ＜リソースを動かしたくないノード名＞
＃-INFINITY は -inf と書くことも出来るみたいだ。
これを実際に適用するコマンドは以下の通り。
(gemini) $ sudo crm configure \
location stonith2gemini_loc stonith2gemini \
rule 100: \#uname eq cancer \
rule -inf: \#uname eq gemini
(gemini) $ sudo crm configure \
location stonith2cancer_loc stonith2cancer \
rule 100: \#uname eq gemini \
rule -inf: \#uname eq cancer
＃コマンドラインから実行する場合、 #uname でシェルのコメントになってしまう。
＃そのため、 \ でコメントを無効化しよう。
出来上がったか確認。
(gemini) $ sudo crm_mon -A
(gemini) $ sudo crm configure show
設定は出来たっぽい。
さて、とりあえずこの2つ、起動停止してみたい。(単なるリソースだから、起動停止できるはず…)
(gemini) $ sudo crm resource stop stonith2gemini
(gemini) $ sudo crm resource stop stonith2cancer
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm_mon -A
止まったっぽい。
今度は起動。
(gemini) $ sudo crm resource start stonith2gemini
(gemini) $ sudo crm resource start stonith2cancer
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm_mon -A
ちゃんと起動したっぽい。
起動停止させると、それぞれの syslog にも記録される。
これ、強制的にノードを指定して起動させるコマンドは無いのだろうか？
(対向ノードでは起動しない設定(-inf)なので、ノード指定の起動はエラーになるはず…)
う～ん。調べてみても、リソースを起動する時に、ノードを指定する方法が見当たらない。起動しているリソースを、他のノードに移動させる、というコマンドなら用意されているようだ。
それが resource migrate コマンドのようだ。(crm help resource migrate で簡単なオプションが表示される)
試してみよう。
(gemini) $ sudo crm status --verbose
stonith2gemini が cancer 上で動いており、stonith2cancer が gemni 上で動いているのが分かる。
では、stonith2gemini を gemini 上に移動させてみよう。(移動出来ないのが正解のはずだ。)
(gemini) $ sudo crm resource migrate stonith2gemini gemini
…何もエラーは起きない。
どうなっただろうか。
(gemini) $ sudo crm status --verbose
おや？何も変化していないぞ？
いや、変化しないことが正解なんだけど…。何もメッセージが出ていないのはちょっと気持ち悪いな。
ただ、クラスタ定義に1つエントリが追加されているのに気付いた。
(gemini) $ sudo crm configure show
--
前略
location cli-prefer-stonith2gemini stonith2gemini role=Started inf: gemini
後略
--
だ。
これを見ると、stonith2gemini は gemini で動く、という定義に見えるが…。
この状態でリソースを停止→起動してみるとどうなるだろうか？
(gemini) $ sudo crm resource stop stonith2gemini
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm configure show
(gemini) $ sudo crm resource start stonith2gemini
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm configure show
やっぱりリソースは cancer で動いているし、謎の location エントリは消えていない。
これが正しい動作なのだろうか…。
とりあえず、謎の location エントリは削除しておこう。
migrate で現れたステータスなので、消すのは unmigrate だ。
(gemini) $ sudo crm resource unmigrate stonith2gemini
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm configure show
元に戻った。
とりあえず、ダミーの stonith リソースは出来た。
一旦仕切り直して、IPアドレスのリソースを作ってみよう。
最初の方で警告が出たコマンドを実行してみよう。
(gemini) $ sudo crm configure primitive testip \
ocf:heartbeat:IPaddr2 \
params \
ip="192.168.55.155"
今度はすんなり通った。
状態を確認してみる。
(gemini) $ sudo crm configure show
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm_mon -A
testip リソースは cancer で動き出したな。
(何故か、cancer で優先的に動く。この辺りは何か理由があるんだろうけど、location 定義で制御するのが正しいんだろうな。)
とりあえず、cancer で IPアドレス が付与されているはずなので確認してみよう。
(cancer) $ ip address show
cancer で 192.168.55.155 が付与されたのが確認できた。
gemini から疎通確認。
(gemini) $ ping -c 5 192.168.55.155
ちゃんと応答がある。
では、cancer で動き出したリソースを、他のノード(今回は gemini しかいないので gemini )へ移動させてみよう。
(gemini) $ sudo crm resource migrate testip
(gemini) $ sudo crm status show
(gemini) $ sudo ip address show
(cancer) $ sudo ip address show
192.168.55.155 の IPアドレス は、無事に gemini に移動した。
この状態で configure を見てみると…
(gemini) $ sudo crm configure show
--
location cli-ban-testip-on-cancer testip role=Started -inf: cancer
--
このエントリが追加されている。
これ、よく見てみると -inf: cancer となっていて、このリソースはもう cancer では動かせない、という定義だ。
pacemaker で primtive リソースとして定義されたリソースは、migrate させると、元のノード(先程の例では cancer )がダウンしたものとして、そのリソースは cancer には戻らないようになるようだ。
この辺り、クラスタ定義かリソース定義で変更出来ると思うけど、別途調査しないと分からない。
そのため、もう一回この testip リソースを migrate しようとすると、移動先のノードが無いため、リソース自身が停止してしまう。
もう少しこのリソースを元に調査をしたいが、今回はここまでにしよう。
(ちょっと長すぎたかな？)
一旦、リソースは元に戻しておく。
(gemini) $ sudo crm resource unmigrate testip
というわけで一旦終了。
2017年6月30日金曜日
pacemaker を入れよう
というわけで、HA クラスタソフトを入れる。
とは言え、ドレがいいのか分からないので、ここでは定番とも言える pacemaker にしよう。
対象は gemini / cancer だ。
$ sudo apt-get update
$ sudo apt-get --simulate install pacemaker
$ sudo apt-get install pacemaker
インストールが終わったら起動してみる。(基本設定してないけど…。)
(gemini) $ sudo systemctl start pacemaker
(gemini) $ systemctl --no-pager -l status pacemaker
Stonith 関係のエラーが出てる。
(gemini) $ ps -ef | grep pacemaker | grep -v grep
起動はしているようだ。
cancer も…。
(cancer) $ sudo systemctl start pacemaker
(cancer) $ systemctl --no-pager -l status pacemaker
あれ？Stonith 関連のエラーは出てこなかった…。
(cancer) $ ps -ef | grep pacemaker | grep -v grep
こちらも、起動はしているようだ。
pacemaker は、crm というコマンドを通して操作を行うようだ。
まずはステータスを見てみよう。
$ sudo crm status --verbose
どうやら、過去に構築した corosync を通して、ノード間の通信と Online 状態であることは確認できているみたいだ。
ただ、STONITHリソースが定義出来ていないので、他のリソースが起動できないよ、という警告が。っても、何のリソースも定義していないのだが…。
この後、Stonith を含む基本設定を施すことになるのだが、設定を施す前に、今どのような設定になっているかを確認しておこう。
クラスタ全体の Property 一覧は、crm の configure show_property で出力出来る。
$ sudo crm configure show_property
ただコレは、設定可能な項目の一覧なので、各項目にどのような値が設定されているか分からない。
設定されている値は、先程のコマンドの後ろに、設定項目名を入れると分かる。
例えば…
$ sudo crm configure show_property stop-orphan-resources
true
この stop-orphan-resouces というパラメータは、true が設定されている、ということだ。
一度、全部洗い出しておこう。
デフォルト値が分かったが、どの値が何を意味しているのか分からない。
おいおい調査していくことにしよう。
逆に言うと、何をどう設定すれば何が起きるのか分からない。
なので、今はデフォルトのママにして、必要に応じて修正していくことにする。
次回は、ゲストOS(leo) をクラスタサービスにしてみる。(出来るのか？)
とは言え、ドレがいいのか分からないので、ここでは定番とも言える pacemaker にしよう。
対象は gemini / cancer だ。
$ sudo apt-get update
$ sudo apt-get --simulate install pacemaker
$ sudo apt-get install pacemaker
インストールが終わったら起動してみる。(基本設定してないけど…。)
(gemini) $ sudo systemctl start pacemaker
(gemini) $ systemctl --no-pager -l status pacemaker
Stonith 関係のエラーが出てる。
(gemini) $ ps -ef | grep pacemaker | grep -v grep
起動はしているようだ。
cancer も…。
(cancer) $ sudo systemctl start pacemaker
(cancer) $ systemctl --no-pager -l status pacemaker
あれ？Stonith 関連のエラーは出てこなかった…。
(cancer) $ ps -ef | grep pacemaker | grep -v grep
こちらも、起動はしているようだ。
pacemaker は、crm というコマンドを通して操作を行うようだ。
まずはステータスを見てみよう。
$ sudo crm status --verbose
どうやら、過去に構築した corosync を通して、ノード間の通信と Online 状態であることは確認できているみたいだ。
ただ、STONITHリソースが定義出来ていないので、他のリソースが起動できないよ、という警告が。っても、何のリソースも定義していないのだが…。
この後、Stonith を含む基本設定を施すことになるのだが、設定を施す前に、今どのような設定になっているかを確認しておこう。
クラスタ全体の Property 一覧は、crm の configure show_property で出力出来る。
$ sudo crm configure show_property
ただコレは、設定可能な項目の一覧なので、各項目にどのような値が設定されているか分からない。
設定されている値は、先程のコマンドの後ろに、設定項目名を入れると分かる。
例えば…
$ sudo crm configure show_property stop-orphan-resources
true
この stop-orphan-resouces というパラメータは、true が設定されている、ということだ。
一度、全部洗い出しておこう。
| # | 項目名 | 値 | 備考 |
|---|---|---|---|
| 1 | stop-orphan-resources | true | |
| 2 | dc-deadtime | 20s | |
| 3 | placement-strategy | default | |
| 4 | symmetric-cluster | true | |
| 5 | maintenance-mode | false | |
| 6 | default-action-timeout | 20s | |
| 7 | node-health-yellow | 0 | |
| 8 | start-failure-is-fatal | true | |
| 9 | shutdown-escalation | 20min | |
| 10 | stop-all-resources | false | |
| 11 | no-quorum-policy | stop | |
| 12 | dc-version | 1.1.14-70404b0 | |
| 13 | startup-fencing | true | |
| 14 | stonith-enabled | true | |
| 15 | pe-input-series-max | 4000 | |
| 16 | stonith-action | reboot | |
| 17 | pe-error-series-max | -1 | |
| 18 | is-managed-default | true | |
| 19 | node-health-red | -INFINITY | |
| 20 | remove-after-stop | false | |
| 21 | crmd-transition-delay | 0s | |
| 22 | election-timeout | 2min | |
| 23 | node-health-green | 0 | |
| 24 | node-action-limit | 0 | |
| 25 | stonith-timeout | 60s | |
| 26 | enable-acl | false | |
| 27 | batch-limit | 0 | |
| 28 | pe-warn-series-max | 5000 | |
| 29 | enable-startup-probes | true | |
| 30 | stop-orphan-actions | true | |
| 31 | default-resource-stickiness | 0 | |
| 32 | cluster-recheck-interval | 15min | |
| 33 | cluster-infrastructure | corosync | |
| 34 | crmd-integration-timeout | 3min | |
| 35 | stonith-watchdog-timeout | (null) | |
| 36 | crmd-finalization-timeout | 30min | |
| 37 | have-watchdog | false | |
| 38 | migration-limit | -1 | |
| 39 | load-threshold | 80% | |
| 40 | node-health-strategy | none | |
| 41 | cluster-delay | 60s |
デフォルト値が分かったが、どの値が何を意味しているのか分からない。
おいおい調査していくことにしよう。
逆に言うと、何をどう設定すれば何が起きるのか分からない。
なので、今はデフォルトのママにして、必要に応じて修正していくことにする。
次回は、ゲストOS(leo) をクラスタサービスにしてみる。(出来るのか？)
2017年6月27日火曜日
HAクラスタに挑戦
今度は、Ubuntu を使った HA クラスタに挑戦してみたい。
と、その前に HA クラスタって何？ってところを整理しておきたい。
HA クラスタは、HA と クラスタ(Cluster) の2つに分割出来る。
それぞれ
そもそも、クラスタというのは「同じもの、同じようなものがたくさん集まって、1つの集合になっている」物を示すものだ。
良く引き合いに出されるのが、
ぶどうは1つずつの粒がたくさん集まって、1つの房を形成していて、それ全体で「ぶどう」と呼んでいる。
バナナも同様、1本1本もバナナだけど、それが集まった房を指して「バナナ」と呼んでいる。
こういった感じで、同じもの、同じようなものが集まって1つの大きな集合を形成している姿を「クラスタ」と呼んでいる。
最近だと、ある特定のジャンルの専門家が集まって議論しているような姿をクラスタと呼んだりしていることも…。(医療者が集まっている姿を「医療クラスタ」とか、ガンダムに詳しいオタクを集めて「ガンダムクラスタ」とか…。)
まぁこういう感じで、「コンピュータを複数集めて、1つの大きなシステムを構成していること」を「コンピュータクラスタ」と呼んでいたりする。
で、もう1つの「HA」だけど…。
「高可用性」って言われても、何がなんだか良くわからない。
「可用性」が「高い」ということなんだけど、「可用性」ってナンだ？って。
これ、漢字をバラしてみると分かる。
「用いる(使用する)」ことが「可能」な状態を維持する「性能」。
これが「高い」ということ。
具体的には「いつでも使用することが出来る状態を維持していること」。逆に言うと「使用できない状態が少ない(短い)こと」。
システム全体のうち、一箇所壊れたってシステム的には稼働させることが可能な状態、ってことになる。
(構成によっては、一箇所どころか二箇所・三箇所壊れたって稼働させることが可能、ということも)
ちなみにITの世界では、「クラスタ」と言ったら、大抵はこの「HA クラスタ」を指す。
じゃぁ HA クラスタ以外にはどんなのがあるの？ということで、触りだけ。
今回は、これらの中で HA クラスタに挑戦したいと思う。
というわけでマテ次回。
と、その前に HA クラスタって何？ってところを整理しておきたい。
HA クラスタは、HA と クラスタ(Cluster) の2つに分割出来る。
それぞれ
- HA : High Availability(高可用性)
- Cluster : 束、房
そもそも、クラスタというのは「同じもの、同じようなものがたくさん集まって、1つの集合になっている」物を示すものだ。
良く引き合いに出されるのが、
- ぶどうの房
- バナナの房
ぶどうは1つずつの粒がたくさん集まって、1つの房を形成していて、それ全体で「ぶどう」と呼んでいる。
バナナも同様、1本1本もバナナだけど、それが集まった房を指して「バナナ」と呼んでいる。
こういった感じで、同じもの、同じようなものが集まって1つの大きな集合を形成している姿を「クラスタ」と呼んでいる。
最近だと、ある特定のジャンルの専門家が集まって議論しているような姿をクラスタと呼んだりしていることも…。(医療者が集まっている姿を「医療クラスタ」とか、ガンダムに詳しいオタクを集めて「ガンダムクラスタ」とか…。)
まぁこういう感じで、「コンピュータを複数集めて、1つの大きなシステムを構成していること」を「コンピュータクラスタ」と呼んでいたりする。
で、もう1つの「HA」だけど…。
「高可用性」って言われても、何がなんだか良くわからない。
「可用性」が「高い」ということなんだけど、「可用性」ってナンだ？って。
これ、漢字をバラしてみると分かる。
「用いる(使用する)」ことが「可能」な状態を維持する「性能」。
これが「高い」ということ。
具体的には「いつでも使用することが出来る状態を維持していること」。逆に言うと「使用できない状態が少ない(短い)こと」。
システム全体のうち、一箇所壊れたってシステム的には稼働させることが可能な状態、ってことになる。
(構成によっては、一箇所どころか二箇所・三箇所壊れたって稼働させることが可能、ということも)
ちなみにITの世界では、「クラスタ」と言ったら、大抵はこの「HA クラスタ」を指す。
じゃぁ HA クラスタ以外にはどんなのがあるの？ということで、触りだけ。
- HPC(High Performance Computing)
制御用コンピュータの配下に、たくさんのコンピュータを接続。
制御用コンピュータが、複雑な処理や計算を分割、配下のコンピュータに分散処理あせることで、1台の性能では得られないパフォーマンスを得る。
スーパーコンピュータが担っていた世界を置き換えているみたい。(タンパク質構造解析とか、画像(動画)解析とか、天気予報とか…) - ロードバランシング型クラスタ
ロードバランサ配下にたくさんのコンピュータを接続。
アクセスを各コンピュータに振り分けることで、処理を分散させる。
HPCとの違いは、配下のコンピュータは全て同じ機能しか持っていない、という点、ロードバランサはあくまで振り分けをしているだけで、大きな処理を分割しているわけではない、という点。 - 垂直分散型クラスタ(機能分散型クラスタ)
システム的に、Web/Application/DB等に機能分割し、それぞれ専用のサーバを用意、各サーバ間で通信しながら、1つの大きなシステムを構成する。
90年代後半から3層構造等と言われて、よく使用されている。
今回は、これらの中で HA クラスタに挑戦したいと思う。
というわけでマテ次回。
2017年5月9日火曜日
ボリューム共有構成について整理しよう
とりあえず、ボリューム共有の構成について、整理したいと思う。
ここは、JIS規格の「決定表」に従って整理してみる。
HTML の table タグを使うのはちょっとタイヘンなのだが、敢えて使ってみる。
上手く整理出来ないが、ざっとこんな感じか。
ざっとこんな感じだ。
結局、パターン4 が一番良さそうだが、「一時的に移動」フラグを付け忘れると問題になる。
デフォルトで「一時的に移動」にチェックを入れておくことは出来ないものだろうか…？
次回は、virt-manager ではなくコマンドライン(virsh)を用いたマイグレーションにチャンレンジしてみよう。
ここは、JIS規格の「決定表」に従って整理してみる。
HTML の table タグを使うのはちょっとタイヘンなのだが、敢えて使ってみる。
| 1 | 2 | 3 | 4 | |
|---|---|---|---|---|
| 共有状態 | ||||
| 仮想マシン定義 | 独立 | 独立 | 共有 | 共有 |
| 仮想ディスク | 独立 | 共有 | 独立 | 共有 |
| 実行可否 | ||||
| 各ノードで起動 | 不可 | 不可 | 不可 | 可能 |
| マイグレーション | 不可 | 可能 | 不可 | 可能 |
| 「一時的に移動」 | - | 不要 | - | 必要 |
上手く整理出来ないが、ざっとこんな感じか。
- 各ノードで起動
ゲストを、gemini / cancer それぞれで(排他的に)起動可能か？という状態。
ゲストを gemini で稼働させていたが、gemini がダウンした時に、そのゲストを cancer で動かすことが可能か？という観点(HA観点) - マイグレーション
オンライン(ライブ)マイグレーション可能か？という状態。
ゲストを gemini で動かしているが、gemini をメンテナンスしたいので、ゲストを cancer に(稼働させたまま)移動させることが可能か？という観点 - 「一時的に移動」
マイグレーション実施時に、「一時的に移動」のフラグが必要か？という条件
ざっとこんな感じだ。
結局、パターン4 が一番良さそうだが、「一時的に移動」フラグを付け忘れると問題になる。
デフォルトで「一時的に移動」にチェックを入れておくことは出来ないものだろうか…？
次回は、virt-manager ではなくコマンドライン(virsh)を用いたマイグレーションにチャンレンジしてみよう。
2017年5月4日木曜日
kvmで使用する共有ファイルシステムの検討
とりあえず、共有ファイルシステムは gfs2 を使用することに決定。
で、これから検討したいのは、kvm の領域のドコを共有ファイルシステムにするか？という点。
具体的には…
(/var/log/libvirt は単なる稼動ログなので、共有させる必要は無いと考えている。)
仮想マシンに関する定義が /etc/libvirt/qemu に格納されていて、gemini / cancer のどちらでも同じ仮想マシンを起動できるようにするには、最低でも /etc/libvirt/qemu と仮想マシンのイメージファイルが格納されている /var/lib/libvirt/images は共有させる必要があると思う。
けど、オンラインマイグレーションを想定した場合、/etc/libvirt/qemu が共有されていていいのだろうか？
また、仮想マシンのスナップショットは、/var/lib/libvirt/qemu/snapshot に格納されるっぽい。これらも共有しなくていいのか？(外部スナップショットではなく、内部スナップショットなら、同じディスクイメージにスナップショットが作られるので、この点は確認不要だ。)
更には、共有しようとしているディレクトリに、ホスト固有の情報が記録されていないだろうか？
等など、検討しないといけないことはたくさん有り、そもそも共有出来るのかどうか…。
今回検討したいのは、主に
スナップショット等の情報もそのまま引き継げればベスト。
というわけで、次回から環境を作っていこう。
で、これから検討したいのは、kvm の領域のドコを共有ファイルシステムにするか？という点。
具体的には…
- /var/lib/libvirt を共有する
- /etc/libvirt、/var/lib/libvirt を共有する
- /var/lib/libvirt/images、/var/lib/libvirt/qemu を共有する
- /etc/libvirt、/var/lib/libvirt/images、/var/lib/libvirt/qemu を共有する
(/var/log/libvirt は単なる稼動ログなので、共有させる必要は無いと考えている。)
 |
| パターン1の例 |
 |
| パターン2の例 |
仮想マシンに関する定義が /etc/libvirt/qemu に格納されていて、gemini / cancer のどちらでも同じ仮想マシンを起動できるようにするには、最低でも /etc/libvirt/qemu と仮想マシンのイメージファイルが格納されている /var/lib/libvirt/images は共有させる必要があると思う。
けど、オンラインマイグレーションを想定した場合、/etc/libvirt/qemu が共有されていていいのだろうか？
また、仮想マシンのスナップショットは、/var/lib/libvirt/qemu/snapshot に格納されるっぽい。これらも共有しなくていいのか？(外部スナップショットではなく、内部スナップショットなら、同じディスクイメージにスナップショットが作られるので、この点は確認不要だ。)
更には、共有しようとしているディレクトリに、ホスト固有の情報が記録されていないだろうか？
等など、検討しないといけないことはたくさん有り、そもそも共有出来るのかどうか…。
今回検討したいのは、主に
- 片方のノードがダウンした時に、ダウンしていた方のノードで稼働していた仮想マシンが、生きている方のノードで起動できるか？
- 稼働している仮想マシンを、動かしたままもう片方のノードへ移動できるか？(ライブマイグレーション)
スナップショット等の情報もそのまま引き継げればベスト。
というわけで、次回から環境を作っていこう。
登録:
投稿 (Atom)