2018年8月23日木曜日

クラスタ設定変更(gfs2用)

クラスタのベース部分が出来上がったところで、早速gfs2関連に手を出したいところだけど、その前に1つ、クラスタの設定を変更しておく必要がある。

redhatのサイトだけど、
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/global_file_system_2/ch-clustsetup-gfs2
が分かりやすいかな?
あと、ちょっと古いslideshare情報だけど、
https://www.slideshare.net/takmatsuo/osc2010-tokyo-fall-pacemaker
ここも見ておく必要がある。

今回の構成は
  • 2ノードクラスタ
  • 使用リソースはgfs2で、これを両ノードでマウントして使用
なので、クラスタのno-quorum-policyをfreezeに設定しておく必要がある。
この先、Ubuntu18.04(aries/pisces)のクラスタでは、nfs4のサービスを作る予定だが、そちらの場合はno-quorum-policyはignoreに設定しておく必要がありそうだ。

先程のredhatのサイトでは、コマンドで設定するように記載されているけど、今回作成中の環境では、手抜きでvirgoのpcsdから設定する。

ブラウザからvirgoのpcsdにログイン後、Managed Clustersからgfs2-clusterを選択して、gfs2-clusterの設定画面に移動しよう。
移動後、画面上部にあるタブからCLUSTER PROPERTIESを選択すると、クラスタ全体に関わる設定値を確認・変更できる。
クラスタ設定項目に、No Quorum Policyという設定項目があるはずだ。
プルダウンからfreezeを選択し、画面下部のApply Changesボタンを押して反映させよう。

これで、no-quorum-policyの変更ができた。

一応確認してみよう。
#コマンドでの確認は、virgoから実行する方法が分からない。
#gemini/cancerで実行してみよう。
(gemini) $ sudo pcs property show no-quorum-policy
freezeになっているのが確認できると思う。

とりあえず設定変更はココまで。

2018年8月20日月曜日

GFS2/DLM導入(16.04)

gemini/cancerクラスタは、gfs2ファイルシステムの運用を想定している。
そのため、gemini/cancer両ノードにgfs2ファイルシステムを導入しておく必要があった。
また、gfs2ファイルシステムを複数のノードで共有するためには、dlmも必要になる。
一緒に導入しておこう。
(gemini) $ sudo apt-get install gfs2-utils dlm
(cancer) $ sudo apt-get install gfs2-utils dlm

さくっと導入できた。

2018年8月19日日曜日

クラスタベース作ってみる(16.04)

とりあえず、16.04のノード(gemini / cancer)でクラスタを作ってみたい。
同じ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月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自体を稼働させる、ということも可能なはずだが、それは余裕があったら実装したい。

まぁゆっくりと…。