うらもちゃのブログ

2018年8月14日火曜日

まずはpcsの導入

まずは、クラスタ管理用のサーバ(leo/virgo)にpcsを導入して、簡単な初期セットアップだけしてしまおう。

まずはleo(18.04)から。
(leo) $ dpkg -l pcs
(leo) $ sudo apt-get update
(leo) $ sudo apt-get --simulate install pcs
(leo) $ sudo apt-get install pcs
(leo) $ dpkg -l pcs
(leo) $ dpkg -L pcs
(leo) $ systemctl status pcsd
(leo) $ ss -natl | grep 2224
2224番ポートでlistenしているサービスができた。

ブラウザで、
https://(leoのIPアドレス):2224/
へアクセスすると、pacemaker/corosyncへのログイン画面が表示されるはずだ。
ただ、この状態ではどのID/PWDを入力してもログインできない。

この時点で、OS(leo)に hacluster というアカウントができている。これは pcsd を導入した時に(厳密には多分、依存関係にあるパッケージが導入されたタイミングに)作成されたものだ。
で、pcsd はこのアカウントを使用するため、このアカウントにパスワードを設定しておく必要がある。
ちなみに、pcsd が hacluster というアカウントを使用するというのは /usr/share/pcsd/settings.rb というファイルで定義されているからのようだ。
(leo) $ sudo passwd hacluster

hacluster のパスワードが設定できたら、先程のブラウザ画面に戻って、hacluster アカウントでログインしてみよう。
ログインできるのが確認できたら、右上の方のメニューからログアウトしておこう。
現時点ではまだ、ログインできるのを確認するだけだ。

leo での確認が終わったら、virgo でも同じように導入と確認しておこう。
コマンド類はまったく同じだ。
…と思ったけど、pcsd導入時に自動起動しなかった。なぜだろう？
とりあえず、起動しておこう。
(virgo) $ sudo systemctl start pcsd

導入後、leo と同じように hacluster アカウントにパスワードを設定し、ブラウザからアクセスしてみよう。
アクセスできることが確認できたら、pcsの導入は完了だ。

Ubuntu18.04.1へのアップグレードパス

リリース後にいくつか問題があったUbuntu18.04.1だけど、どうやら致命的なバグは解決したらしい。

本来なら、Ubuntu18.04.1がリリースされた2018/07/末で、16.04→18.04へのアップグレードが可能になるはずだったんだけど、何か致命的なバグがあって、アップグレードできない状態だった。

それが解決したようで、アップグレードパスが整った模様。

実施するのなら、root権限で

% do-release-upgrade

とする。

ただ、自分が運用しているaquarius/sagittariusは、gfs2ファイルシステムをpacemaker配下で運用していないので、正しい状態じゃない。

正しい状態じゃない環境をアップグレードしたら、トラブルのは目に見えている。

まずは、pacemakerの構築・運用を確立させてから、アップグレードすることにする。

2018年8月9日木曜日

pacemaker検証(各OS作成)

というわけで、各仮想マシンを作成し、OSをローディング。
構成は考えるのがめんどくさいので、基本的に全部統一。

EFIブート
メモリ4GB
CPU1コア2スレッド
HDD20GB
NIC1ポート

だ。
OSはデフォルトインストール＋OpenSSHサーバ。
クラスタを組むサーバ(pisces/aries、gemini/cancer)には、各クラスタごとに100GBの仮想ディスクを割り当てた。(とりあえず、iSCSIではなく、qcow2形式の仮想ディスクだ。)

あとは、各ゲストごとにIPアドレスを割り当てる。

pisces : 192.168.55.133
aries : 192.168.55.134
gemini : 192.168.55.136
cancer : 192.168.55.137
leo : 192.168.55.138
virgo : 192.168.55.139

とりあえずここまで。

pacemaker検証(OSメディアの入手)

Ubuntuの16.04と18.04の両方を使って検証するので、OSメディアを入手しておく。
通常通り、ubuntuのサイト(https://www.ubuntu.com/)から入手してもいいんだけど、18.04は新しいタイプのインストーラー(ライブインストーラ？)になっている。
16.04時代と同じタイプのインストーラーを使いたかったら、UbuntuのサイトにあるAlternative Donwloadのリンクから、ファイル名に「live」が付いていない方を入手しよう。
ただし、こちらも日本語インストーラーが壊れているらしく、英語モードでインストールする必要がある。
結局、使うメディアは以下の2つにした。

ubuntu-16.04.5-server-amd64.iso
ubuntu-18.04.1-server-amd64.iso

2018年8月7日火曜日

pacemaker検証(古い環境の削除)

というわけで、これまで作った検証環境のうち、今回のpacemakerで使用する環境を一旦全て削除する。

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というのを使うと、ブラウザから制御できるようだ。
いくつか検証中の仮想マシンを潰して、以下の環境を検証してみたい。

gfs2クラスタ検証(Ubuntu16.04)*2台
NFSv4クラスタ検証(Ubuntu18.04)*2台
pcsd検証(Ubuntu16.04)*1台
pcsd検証(Ubuntu18.04)*1台

gfs2クラスタ検証は、検証内容をaquarius/sagittariusにフィードバックするため。
NFSv4は、自宅とは別の環境で検証している環境用で、複数のLinuxノードのホームディレクトリ(/home)共有を目的としている。
できればOpenLDAPによるアカウント統合も検証したい。
pcsd検証が2環境あるのは、単に16.04と18.04でそれぞれ確認してみたいというだけの理由だ。
別途確認してみたら、一度pcsdの管理下に置いたクラスタは、pcsd管理から外してもすぐに管理下に起き直すことができるようだ。
そのため、pcsd自体をHAクラスタにしなくても、同じクラスタを複数のpcsd管理下に置けるのではないか？と考えている。
そのため、2種類のHAクラスタを、両方のpcsd管理下に置くことを想定している。

もちろん、gfs2クラスタやNFSv4クラスタの各ノードでpcsd自体を稼働させる、ということも可能なはずだが、それは余裕があったら実装したい。

まぁゆっくりと…。