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 が設定されている、ということだ。
一度、全部洗い出しておこう。
#項目名備考
1stop-orphan-resourcestrue
2dc-deadtime20s
3placement-strategydefault
4symmetric-clustertrue
5maintenance-modefalse
6default-action-timeout20s
7node-health-yellow0
8start-failure-is-fataltrue
9shutdown-escalation20min
10stop-all-resourcesfalse
11no-quorum-policystop
12dc-version1.1.14-70404b0
13startup-fencingtrue
14stonith-enabledtrue
15pe-input-series-max4000
16stonith-actionreboot
17pe-error-series-max-1
18is-managed-defaulttrue
19node-health-red-INFINITY
20remove-after-stopfalse
21crmd-transition-delay0s
22election-timeout2min
23node-health-green0
24node-action-limit0
25stonith-timeout60s
26enable-aclfalse
27batch-limit0
28pe-warn-series-max5000
29enable-startup-probestrue
30stop-orphan-actionstrue
31default-resource-stickiness0
32cluster-recheck-interval15min
33cluster-infrastructurecorosync
34crmd-integration-timeout3min
35stonith-watchdog-timeout(null)
36crmd-finalization-timeout30min
37have-watchdogfalse
38migration-limit-1
39load-threshold80%
40node-health-strategynone
41cluster-delay60s

デフォルト値が分かったが、どの値が何を意味しているのか分からない。
おいおい調査していくことにしよう。

逆に言うと、何をどう設定すれば何が起きるのか分からない。
なので、今はデフォルトのママにして、必要に応じて修正していくことにする。

次回は、ゲストOS(leo) をクラスタサービスにしてみる。(出来るのか?)

2017年6月27日火曜日

HAクラスタに挑戦

今度は、Ubuntu を使った 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層構造等と言われて、よく使用されている。
だ。(最後のは私が勝手に命名している。クラスタの1つに数えない人も多い。)

今回は、これらの中で HA クラスタに挑戦したいと思う。

というわけでマテ次回。

2017年6月26日月曜日

fcitx の profile か?

というわけで調べてみた。
全部を調べたわけではないが、まず引っ掛かったのは ~/.config/fcitx/profile というファイルだ。
こちらに、 IMName という設定がある。
これが、 gemini は mozc が指定されていて、cancer は fcitx-keyboard-jp が指定されている。
この違いだろうか?
これは恐らく、fcitx-configtool によって書き換えられたものと思われるけど、直接書き換えてみよう。
(cancer) $ vi ~/.config/fcitx/profile
--
IMName=fcitx-keyboard-jp

IMName=mozc
--
この状態でも日本語入力出来ない。

一度ログアウト・ログインし直してから試してみる。
(再ログイン後、環境変数 XMODIFIERS を設定するのを忘れないように。)
それでもダメな(日本語入力出来ない)ようだ。

う~ん…。
一旦、gemini / cancer に teraterm でログインし、fcitx を起動、fcitx-configtool を比較してみるか。
$ export XMODIFIERS=@im=fcitx
$ fcitx
$ fcitx-configtool

う~む。どうやら設定が違うな。
  • Default keyboard layout
    • gemini : 日本語 - 日本語 (OADG 109A)
    • cancer : Default
  • Mozc Keyboard layout
    • gemini : 日本語 - 日本語 (OADG 109A)
    • cancer : Default
この違いだろうか…。
一度、cancer の設定を gemini の設定と同じにして、確認してみよう。
やっぱりダメだった…。

と、ここで gemini / cancer と taurus の /etc/default/im-config に差異があることが分かった。
gemini / cancer の /etc/default/im-config は同じだった。
どういうことだ?
って当たり前だ。gemini / canccer は Ubuntu 16.04、taurus は 17.04 だ。バージョンが違えばパッケージも違うわ。ボケてた。

ただ、virt-manager を起動しようとするたびに
Gtk-message: Failed to load module "canberra-gtk-module"
というメッセージが出てくる。
今の現象には関係無いけど、gemini / cancer にインストールだけしておこう。
$ sudo apt-get update
$ sudo apt-get --simulate install libcanberra-gtk-module
$ sudo apt-get install libcanberra-gtk-module
あれ?コレじゃないのかな?virt-manager 起動しても同じメッセージが出る。

…気を取り直して…
virt-manager 側の問題の可能性もあるので、一度、別のアプリケーションで試してみたい。
とは言え、gemini / cancer には X アプリケーションは全然入っていないので、何かインストールしよう。
テキストエディタの gedit がいいかな?
$ sudo apt-get --simulate install gedit
$ sudo apt-get install gedit

gedit で試してみたところ、やっぱり gemini の方は日本語入力出来て、 cancer の方は入力出来ない。
ということは、virt-manager の設定ではないということだ。

ラチが開かないので、taurus から sagittarius にログインして、同じように試してみた…。
なんと、日本語入力出来る!
特に fcitx を導入したわけでも無く、環境変数 XMODIFIERS を設定しただけだ。

う~ん。 cancer の設定がおかしいとしか思えないな…。なんだろう…???

一度、cancer の個人環境をクリアしてみよう。
(cancer) $ cd
(cancer) $ rm -rf .config
(cancer) $ rm -rf .dbus
(cancer) $ rm -rf .mozc
(cancer) $ rm -rf .cache
(cancer) $ rm .xinputrc
ここで一旦ログインし直し。
これで、もう一度確認してみよう。
…やっぱりダメだ…。

色々調べてみたんだけど、結局ダメだった。

出来れば解決しておきたかったんだけど、解決出来ないので今回は諦め。
もし何かヒントが見つかれば、また挑戦しよう…。


2017年6月22日木曜日

ちょっと不思議な事象が…

というわけで、taurus から gemini / cancer への日本語入力のテストを実施してみる。

taurus のコンソール(Remote Viewer や virt-manager を使用してくれぃ)からログインし、デスクトップ上でマウス右クリックからの「端末を開く」で2枚の端末を開く。
それぞれの端末で日本語入力出来ることを確認したら、ssh の -X オプションつきで gemini / cancer にログインしよう。
(taurus) $ ssh -X (ユーザ名)@(geminiのIP)
(taurus) $ ssh -X (ユーザ名)@(cancerのIP)

そしたら、gemini / cancer ともに fcitx と mozc が動いていないことを確認。
(gemini) $ ps -ef | grep -e fcitx -e mozc | grep -v grep
(cancer) $ ps -ef | grep -e fcitx -e mozc | grep -v grep

環境変数 XMODIFIERS を設定しよう。
(gemini) $ export XMODIFIERS=@im=fcitx
(gemini) $ env | grep XMODIFIERS
(cancer) $ export XMODIFIERS=@im=fcitx
(cancer) $ env | grep XMODIFIERS

設定されていることが確認できたら、 virt-manager を起動して日本語入力出来るか確認しよう。

というところでタイトルの「ちょっと不思議な現象が…」になる。
何故か、gemini から起動した virt-manager では日本語入力が可能で、cancer から起動した virt-manager では日本語入力が不可能なのだ。
両方共、fcitx / mozc は起動していないので、taurus のローカルで動いている fcitx / mozc を使っているはず。
gemini と cancer 、同じように作ったはずなんだが、何か違いがあるようだ。
この違いを追求しないと、ちょっと面倒なことになるかもしれない…。

というわけで、次回以降で調査を行おう。

Ubuntu Desktop 作ってみる

前回に引き続いて、日本語入力関連だ。
今までは Windows をメインマシンに据えて、そこから ssh で Ubuntu マシンにログイン、操作するというやり方だった。
この Windows の部分を、Ubuntu Desktop に置き換えてみようというのが今回の主旨。

まずは、Ubuntu Linux のサイトから、Ubuntu Desktop のメディアをダウンロードしよう。今回は 17.04 を入手した。

そしたら、仮想マシンの作成だ。
スペックは以下の通り。
  • 仮想マシン名 : taurus
  • ホスト名 : taurus
  • IP Address : 192.168.55.135 / 24
  • CPU : 4コア*1スレッド(4スレッド)
  • メモリ : 4GB
  • HDD : 72GB
  • ソフトウェア等構成 : デフォルト
  • ディスクレイアウト : お任せ&LVM
実は、この blog には記載していないけど、過去に taurus は作っている。
あくまでテスト的な存在だったので、今はもう不要だ。
これをバッサリ削除して、完全に新規に作成する。

ざっくりインストールして、taurus 上で日本語入力が出来ることを確認しておこう。
あとは、個人的に FireFox は利用していないので、chromium-browser を導入しようと思ったが、google から Debian / Ubuntu 用の chrome がリリースされているようなので、それだけ入れておいた。

導入が終わったら、taurus にログインして、ssh で gemini / cancer にログインできることを確認しておこう。

次回から、日本語入力周りを再確認する。

2017年6月20日火曜日

X から日本語入力(fcitx の起動)

今現在、日本語入力の環境を整えたのは gemini / cancer の2つだ。
これらを、Windows(pegasus)上の teraterm / VcXsrv から利用している。
イメージ的には以下のような状態だ。
pegasusからgemini/cancerを利用


そのため、gemini 上で動く virt-manager と、cancer 上で動く virt-manager、いずれも同じように pegasus には表示されるが、別アプリケーション(別マシンで動いているアプリケーション)だ。
それぞれのアプリケーションに日本語入力を行うためには、それぞれに fcitx と mozc が必要だと思…う…。

というわけで確認をしてみる。

まず、gemini / cancer で fcitx が動いていたら止める。
$ ps -ef | grep fcitx | grep -v grep
動いているプロセスを kill すること。

両方(gemini / cancer)のsshセッションで、環境変数 XMODIFERS が設定されているか確認。
$ env | grep XMODIFIERS

両方で virt-manager を起動し、それぞれ仮想マシンの設定を適当に開いておく。
$ virt-manager
まだ現時点では、日本語入力は出来ないはずだ。

この状態で、gemini で fcitx を起動する。
(gemini) $ fcitx

起動が出来たら、gemini / cancer 両方で起動した virt-manager に日本語入力を試してみる。
gemini のウィンドウには入力可能だけど、cancer のウィンドウには入力出来ない。

では、cancer 上で fcitx を起動してみる。
(cancer) $ fcitx
エラーが発生する。エラーメッセージは
--
(ERROR-NNNNN /build/fcitx-PSoVA1/fcitx-4.2.9.1/src/frontend/xim/xim.c:240) XIM  開始エラー: fcitx という他の XIM が動いていませんか?
(ERROR-NNNNN /build/fcitx-PSoVA1/fcitx-4.2.9.1/src/lib/fcitx/instance.c:440) Exiting.
--
というものだ。(NNNNN は fcitx のプロセスNo.のようだ)
cancer 上では fcitx は動かしていないにも関わらず、fcitx が動いていないか?というエラーが出るのだ。
しかし、エラーが出たにも関わらず、この状態で cancer 上で稼働させている virt-manager には日本語入力が出来る。
これは一体どういうことなんだろうか…?

今現在は、gemini / cancer いずれも fcitx は稼働している。
$ ps -ef | grep fcitx | grep -v grep

mozc は?
$ ps -ef | grep mozc | grep -v grep
両方のマシンで mozc_server が動いているようだ。

もう一度、cancer 上で fcitx を停止(kill)しておこう。
fcitx を kill したら、mozc_server も停止したはずだ。念のために確認し、もし mozc_server が稼働していたら kill しておこう。

これで今は、
  • gemini : fcitx 稼働 / mozc_server 稼働
  • cancer : fcitx 停止 / mozc_server 停止
の状態になった。
今の状態で、それぞれの virt-manager に日本語入力が可能か再確認を。
予想通り、gemini 側には入力可能、cancer 側には入力不可、だ。

では、cancer で mozc_server だけを起動してみたら…?
(cancer) $ /usr/lib/mozc/mozc_server &
(cancer) $ ps -ef | grep mozc | grep -v grep
これでも入力は出来ないな…。

cancer で fcitx を起動すれば、日本語入力は可能になる。
(相変わらずエラーは表示されるが…)

となると、先程出た
--
(ERROR-NNNNN /build/fcitx-PSoVA1/fcitx-4.2.9.1/src/frontend/xim/xim.c:240) XIM  開始エラー: fcitx という他の XIM が動いていませんか?
(ERROR-NNNNN /build/fcitx-PSoVA1/fcitx-4.2.9.1/src/lib/fcitx/instance.c:440) Exiting.
--
というエラーはどういう意味なんだろうか?

恐らくは、「gemini の fcitx」→「pegasus の VcXsrv」というセッションがあるのに、「cancer の fcitx」→「pegasus の VcXsrv」というセッションを作ろうとして、cancer が「あれ?pegasus の VcXsrv、既にセッションあるよ?」と言っているんだと思うんだが…。
であれば、cancer 上の virt-manager に対して、gemini の fcitx を使って日本語入力出来てもいいような気がするんだが…。

良くわからない。
まぁとりあえず、必要に応じて fcitx を起動すれば、とりあえず日本語入力出来るので、一旦はコレでヨシとしておくか…。

日本語入力に関しては、Xサーバ側をWindowsのVcXsrvで実装しているので、Linux Xサーバ(+GNOME)とかだったらどうなるんだろうか?
ちょっと気になる。
次回は、Ubuntu Desktop を作って、そちらから gemini / cancer にログインしてみることにしよう。

X から日本語入力(最小限パッケージ)

さて前回、日本語入力が出来ることは確認できた。
ただ、必要以上のパッケージが導入された気がするので、今回はパッケージの絞込をしてみたいと思う。

まず最低限、使うコマンドだけは絶対に必要なはずだ。
前回使ったのは、im-config / fcitx / fcitx-configtool の3つか。
それぞれ、dpkg -S で調べてみると…
  • im-config コマンド : im-config パッケージ
  • fcitx コマンド : fcitx-bin パッケージ
  • fcitx-configtool コマンド : fcitx-bin パッケージ
のようだ。

あと、mozc 関連も必要なはずだが…。
どうやら、fcitx-mozc、mozc-data、mozc-server、mozc-utils-gui というパッケージがあるようだ。
このうち、mozc-data と mozc-server は必要だろう。
fcitx-mozc も必要な気がするが、mozc-utils-gui は必要無い気がする。

さて、これを踏まえて、cancer 上で構築してみるか…。
im-config は fcitx-bin を入れると自動的にインストールされるな。

う~ん。fcitx-mozc を入れる(137個のパッケージ)のと、fcitx-bin と mozc-server を入れる(132個のパッケージ)のとで、導入されるパッケージに若干の差異があるみたいだな。
とりあえず、後者の方がパッケージ数が少ないので、後者を試してみよう。
(cancer) $ sudo apt-get update
(cancer) $ sudo apt-get --simulate install fcitx-bin mozc-server
(cancer) $ sudo apt-get install fcitx-bin mozc-server

導入終わったら、日本語入力の切り替えだ。
(cancer) $ im-config -n fcitx

後は fcitx 動かせば良いのかな?
(cancer) $ export XMODIFIERS=@im=fcitx
(cancer) $ fcitx

このまま、virt-manager で確認してみる。
(cancer) $ virt-manager
どうやら、中途半端のようだ。(mozc に接続出来ていない様子)

だったら、mozc に接続するようにいじってみる。
(cancer) $ fcitx-configtool
あれ?mozc がリストに表示されない。
ってことは、mozc との接続が出来る状態に無いってことか…。

ん?ちょっとマテよ…?まだ mozc-data がインストールされてないぞ?
これ、変換に必要なデータじゃないのか?
入れてみよう。
(cancer) $ sudo apt-get install mozc-data

そしたら、既に起動中の fcitx を kill して、再度実行だ。
(cancer) $ ps -ef | grep fcitx | grep -v grep
(出てきたプロセスのプロセスID に対して、kill プロセスID だ。)
(cancer) $ fcitx
(cancer) $ fcitx-configtool
やっぱりダメっぽいな。

fcitx-mozc を導入する必要がありそうだ。
(cancer) $ sudo apt-get --simulate install fcitx-mozc
(cancer) $ sudo apt-get install fcitx-mozc

もう一度 fcitx を停止・起動させ、設定の確認
(cancer) $ ps -ef | grep fcitx | grep -v grep
(出てきたプロセスのプロセスID に対して、kill プロセスID だ。)
(cancer) $ fcitx
(cancer) $ fcitx-configtool
お!Mozc が出てきた。

ということは…
(cancer) $ virt-manager
あれ?まだ入力出来ないや。

fcitx-configtool で出てくるエントリのうち、Mozc を一番上に移動させれば、日本語入力出来るようになった!

ってことで、gemini に導入されたパッケージと cancer に導入されたパッケージ、比較してみたら5つだけ差異が。
fonts-takao-gothic, fonts-takao-mincho, fonts-takao-pgothic, wamerican, wbritish だ。
これらは今のところ gemini にも不要なので削除してしまおう。
(gemini) $ sudo apt-get purge fonts-takao-gothic \
fonts-takao-mincho \
fonts-takao-pgothic \
wamerican \
wbritish

これまでを整理すると…
  1. fcitx-mozc を導入
  2. 環境変数 XMODIFIERS を設定
  3. fcitx を起動
  4. fcitx-configtool を使って、Mozc を一番上に(最優先に)する
  5. 以後は、環境変数設定(2番)と fcitx の起動(3番)だけ
で、日本語入力が出来るようになるようだ。

実はココまで実行してみて、1つ気になる点が見つかった。
次回はそこを調査してみたい。
(gemini / cancer の両方で同時に fcitx を起動できないっぽい、ということ、どちらかで fcitx を起動していれば、もう片方マシンで動いているアプリケーションでも日本語入力出来るっぽい、ということ)

2017年6月19日月曜日

X から日本語入力

そういえば、virt-manager 等でコメントを入力する時、今はまだ日本語入力が出来ない。
その設定を施していないからだ。

入力できないことが今のところ不自由ではないが、出来れば日本語入力できるようにしておきたい。
というわけで、まずは gemini でテストしてみよう。

どうやら、必要なパッケージは check-language-support というコマンドで表示されるようだ。
(gemini) $ check-language-support

たくさん出て来るので、とりあえずそのまま apt-get に渡してみよう。
(gemini) $ sudo apt-get --simulate install `check-language-support`
かなりたくさんインストールされるな…。ホントにこんなに必要なのだろうか…。

まぁインストールしてみよう。
(gemini) $ sudo apt-get install `check-language-support`

そしたら、日本語入力を fcitx に切り替えるらしい。
(gemini) $ im-config -n fcitx

何もメッセージは出なかったけど、~/.xinputrc というファイルが出来上がってる。
中身はどうなってるんだろうか?
(gemini) $ cat ~/.xinputrc
大したこと書いてなかった…。

ログインセッションに関係あるはずなので、一旦ログアウト・再ログインしておこう。
その後、virt-manager を起動してみる。
(gemini) $ virt-manager
…ここまで書いて、やっぱりまだダメなことが分かった。

関係あるか分からないけど、一度 gemini を再起動してみよう。
仮想マシン leo が動いていると思うので、先に leo を止めておくこと。
(gemini) $ virsh shutdown leo
(gemini) $ virsh list --all
(gemini) $ sudo systemctl reboot

再起動が終わったら、日本語入力のテストだ。
環境変数を設定
(gemini) $ export XMODIFIERS=@im=fcitx

fcitx を起動
(gemini) $ fcitx

続いて、fcitx を設定する。(VcXsrv 等の X Window System が必要だぞ)
(gemini) $ fcitx-configtool

Input Method Configuration の画面が出て来る。
Input Method タブに、Mozc が出ていると思うので、それをダブルクリックだ。
Keyboard layout を選ぶダイアログが出て来るので、「日本語 - 日本語 (OADG 109A)」等、自分のキーボードに合わせたキーボードを選ぼう。
その他にも色々設定が出来るようだが、ヨクワカラン。日本語入力モードに入るためのキーバインディングの変更も可能。

ここまで出来たら、virt-manager から日本語入力が出来るか確認だ。
(gemini) $ virt-manager

適当に仮想マシンを開き、設定画面から「説明」欄等にカーソルを合わせてみよう。
その状態で、キーボードの「半角/全角」キーを押してみると、日本語入力が出来るようになったと思う。

以後は、環境変数 XMODFIERS の設定と、fcitx の起動で日本語入力出来るはずだ。

毎回、fcitx が起動しているか確認するのと、環境変数設定するのは、ちょっと面倒くさいな…。

とりあえず次回は、gemini に導入されたパッケージが本当に全て必要なのかの確認を含めて、cancer でパッケージ導入をしてみる。

2017年6月16日金曜日

Windows ゲストの CPU 使用率

ずっと気になっていたことがある。
Windows ゲストを使用していると、ゲストのタスクマネージャで見る限りぜんぜん CPU を使っていないのに、ホスト側で top を実行すると CPU 消費率が高い、という状態が続いてた。
色々な原因はあるけど、どうやらゲストの定義に
<input type='tablet' bus='usb'/>
というのがあると、USB ポーリングが激しく動いて、ホスト側から見た kvm プロセスの CPU 消費が高くなる、らしい。

virt-manager 等でゲストを作る時、ゲストOSにWindowsを指定するとデフォルトで入る定義のようだ。
但し、この定義を消してゲストを起動すれば、CPU使用率は落ち着くが、virt-viewer/Remote viewer でマウスカーソルの動きがおかしくなるようだ。

で、いつも使っているゲスト:pegasus(Windows 7)もこの設定が入っている。
このゲストで試してみようと思う。

まずは、設定が入っているかを確認。
(sagittarius) $ virsh dumpxml pegasus | grep tablet

設定が入っているのを確認したら、そのままゲストを起動する。
(sagittarius) $ virsh start pegasus

合わせて、top コマンドで CPU 使用率を見てみよう。
(sagittarius) $ top -d 1
(終了させるには、キーボードから q を入力すればいい)

起動したら、端末側の Remote viewer で接続してみよう。

Windows ゲストにログオンしていないウチは、ホストから見たゲストの CPU 使用率は 20%弱のようだ。(sagittarius は 8論理CPU なので、全体では2%~3%程度)
ところが、Windows ゲストにログオンすると、途端にCPU使用率が100%を超える。
Windows としては何のアプリ起動せず、全然負荷をかけていないにも関わらず、だ。

では、先程の <input type='tablet' bus='usb'/> を消したらどうなるだろう?

Windows ゲストをシャットダウンさせ、実際に消してみよう。
(sagittarius) $ virsh shutdown pegasus
(sagittarius) $ virsh edit pegasus
--
<input type='tablet' bus='usb'/>
の行を消す
--

削除が終わったら、先程と同様に起動とCPU使用率の確認だ。
(sagittarius) $ virsh start pegasus
(sagittarius) $ top -d 1

先程は、ログオン前で大体20%程消費していたCPUが、今度は10%前後まで落ちたようだ。(時々跳ね上がるが…)
ログオンしてみるとどうだろうか…。
CPU 使用率は少し下がった。100%をちょっと下回る状態だ。(時々、100%を超えるが…)
但し、Remote Viewer にフォーカスを当てたマウスカーソルが、マウス操作だけではフォーカスを外すことが出来なくなり、更に ゲストWindows 内のマウスカーソルと、端末側のマウスカーソルの2重表示になってしまった。
(フォーカスを外すには、左Ctrl+左Alt の同時押し)

Remote Viewer をフルスクリーン表示してみたらどうだろうか…。
やはり、マウスカーソルの2重表示が消えない。
ちょっと使いにくいが、コンソールを使うことってあまり無さそうだから大丈夫かな?

試しに、リモートデスクトップ接続で CPU 使用率等を確認してみよう。
…う~ん。CPU 使用率は 100% を少し上回るなぁ。
あまり改善された感じはしないけど、少しはマシか…。

頻繁に使う pegasus はこのままにして、他の Windows ゲスト定義は <input type='tablet' bus='usb'/> の定義は残しておくことにしよう…。

--2020/11/17追記
どうやら、別の宣言で解決できそうだ。
とりあえずコチラに記載しておいた。

2017年6月13日火曜日

OpenvSwitch による VLAN 検証(その4)

さて続けて…。
今度はこちらの記事の6枚目~9枚目(最後)の画像部分に挑戦。

現在、leo / virgo ともに起動していると思う。
leo 側の設定を変更したいので、leo を停止するが、virgo から leo に向けて ping を打ち続けよう。
(virgo) $ ping 192.168.57.138

virgo → leo の ping を打ち続けたまま、leo を停止させる。
(leo) $ sudo systemctl poweroff
leo が停止されたら、virgo → leo の ping も通信出来なくなるはず。ping はそのまま置いておく。

vlan10 に接続していた leo を、vlan20 に接続し直す。
(gemini) $ virsh edit leo
--ココから
<interface type='network'>~</interface> の間の1行を修正。
<source network='vlan10'/>

<source network='vlan20'/>
--ココまで

更新が出来たら、leo を起動させよう。
(gemini) $ virsh start leo

leo が起動するまでの間、ping を打ち続けている virgo の方をチェック。
通信が回復しないはずだ。
異なる vlanスイッチなので、通信が回復しなくて当然、のはず。

今度は virgo を vlan20 のスイッチに繋ぎ替える。
leo から virgo へ ping を打ち続けよう。
(leo) $ ping 192.168.57.139
当然、通信は出来ていないはず。

このまま ping を放置して、virgo の接続先スイッチを切り替える。
virgo の停止
(virgo) $ sudo systemctl poweroff

virgo の接続先の切り替え
(cancer) $ virsh edit virgo
--ココから
<interface type='network'>~</interface> の間の1行を修正。
<source network='vlan10'/>

<source network='vlan20'/>
--ココまで

そしたら virgo を起動。
(cancer) $ virsh start virgo

起動中、virgo に ping を打ち続けている leo の画面をチェックしよう。
期待した通りなら、通信が復旧するはずだ。

う~む。今回は全て、期待した通りの動きになった。
おかげで検証もスムーズに進んだ。
VLAN は恐らく、OpenStack 等を使う時に意識しておく必要があると思うから、検証がスムーズに出来てよかった。

さて、OpenvSwitch を使った VLAN の構築検証はココまでにして、次は何に着手しようかな?

OpenvSwitch による VLAN 検証(その3)

やっと前回、vlan10 と vlan20 のスイッチが作られた。

今度は仮想マシン leo / virgo を vlan10 のスイッチに繋いでテストだ。
こちらの4枚目と5枚目の画像の作業になる。

まずは leo / virgo に追加した2枚目の NIC を、vlan10 のスイッチに繋ぎ替える。
virt-manager でもいいが、今回は virsh edit を使うことにする。
(gemini) $ virsh edit leo
(gemini) $ virsh edit virgo
--ココから
<interface type='network'>~</interface> が2セットある。この内の2つ目の方のセットを修正する。
<source network='ovsbridge'/>

<source network='vlan10'/>
--ココまで

gemini 側で修正したら、 cancer 側にも反映させる。
(cancer) $ virsh dumpxml leo
(cancer) $ virsh dumpxml virgo
(cancer) $ sudo systemctl reload libvirt-bin.service
(cancer) $ virsh dumpxml leo
(cancer) $ virsh dumpxml virgo

反映されたことが確認できたら、それぞれ仮想マシンを起動しよう。
(gemini) $ virsh start leo
(cancer) $ virsh start virgo

起動したらそれぞれにログイン。
さて、ping による疎通が出来るのだろうか…?
(leo) $ ip address show ens10
(virgo) $ ip address show ens10

(leo) $ ping 192.168.57.139
(virgo) $ ping 192.168.57.138

どうやら通信できるようだ。
でも、通信出来るから OK というわけではなく、コチラの残りの部分(画像6枚目以降)も出来ることが確認できて、始めて VLAN が作動していることになるわけで。
まだ楽観視出来ないな…。

OpenvSwitch による VLAN 検証(その2)

続いて、VLAN-ID を持った仮想スイッチってやつを作ってみたい。
このページの4枚目の図だ。

作成するのは gemini / cancer 上。
まずは、それぞれのネットワーク設定からだ。
(gemini) $ sudo vi /etc/network/interfaces.d/0020.vlan10
--ココから
auto vlan10
allow-extsw
iface vlan10 inet manual
ovs_bridge extsw
ovs_type OVSIntPort
ovs_options tag=10
--ココまで

(gemini) $ sudo vi /etc/network/interfaces.d/0030.vlan20
--ココから
auto vlan20
allow-extsw
iface vlan20 inet manual
ovs_bridge extsw
ovs_type OVSIntPort
ovs_options tag=20
--ココまで

(gemini) $ sudo vi /etc/network/interfaces.d/0010.extsw
--ovs_ports ens3 の下に2行追加
ovs_ports vlan10
ovs_ports vlan20
--ココまで

(gemini) $ sudo vi /etc/default/networking
--1行修正
EXCLUDE_INTERFACES=extsw

EXCLUDE_INTERFACES="extsw vlan10 vlan20"
--

cancer でも同じ設定を。
(cancer) $ sudo vi /etc/network/interfaces.d/0020.vlan10
--ココから
auto vlan10
allow-extsw
iface vlan10 inet manual
ovs_bridge extsw
ovs_type OVSIntPort
ovs_options tag=10
--ココまで

(cancer) $ sudo vi /etc/network/interfaces.d/0030.vlan20
--ココから
auto vlan20
allow-extsw
iface vlan20 inet manual
ovs_bridge extsw
ovs_type OVSIntPort
ovs_options tag=20
--ココまで

(cancer) $ sudo vi /etc/network/interfaces.d/0010.extsw
--ovs_ports ens3 の下に2行追加
ovs_ports vlan10
ovs_ports vlan20
--ココまで

(cancer) $ sudo vi /etc/default/networking
--1行修正
EXCLUDE_INTERFACES=extsw

EXCLUDE_INTERFACES="extsw vlan10 vlan20"
--

続いて、bridge の作成
(gemini) $ sudo ovs-vsctl show
(gemini) $ sudo ovs-vsctl add-br vlan10 extsw 10
(gemini) $ sudo ovs-vsctl add-br vlan20 extsw 20
(gemini) $ sudo ovs-vsctl show

(cancer) $ sudo ovs-vsctl show
(cancer) $ sudo ovs-vsctl add-br vlan10 extsw 10
(cancer) $ sudo ovs-vsctl add-br vlan20 extsw 20
(cancer) $ sudo ovs-vsctl show

これでいいのかな…?
leo / virgo を停止させ、gemini / cancer を再起動、反映されているか確認。
(leo) $ sudo systemctl poweroff
(virgo) $ sudo systemctl poweroff
(gemini) $ sudo systemctl reboot
(cancer) $ sudo systemctl reboot
(gemini) $ sudo ovs-vsctl show
(cancer) $ sudo ovs-vsctl show

これで、VLANタグ付きのスイッチが出来た…はず…。

作った VLANタグスイッチを、 libvirt に登録しよう。
(gemini) $ vi vlan10.xml
--ココから
<network>
<name>vlan10</name>
<forward mode='bridge'/>
<bridge name='vlan10'/>
<virtualport type='openvswitch'/>
</network>
--ココまで

(gemini) $ vi vlan20.xml
--ココから
<network>
<name>vlan20</name>
<forward mode='bridge'/>
<bridge name='vlan20'/>
<virtualport type='openvswitch'/>
</network>
--ココまで

(gemini) $ virsh net-list --all
(gemini) $ virsh net-define vlan10.xml
(gemini) $ virsh net-define vlan20.xml
(gemini) $ virsh net-list --all

(gemini) $ virsh net-autostart vlan10
(gemini) $ virsh net-autostart vlan20
(gemini) $ virsh net-start vlan10
(gemini) $ virsh net-start vlan20
(gemini) $ virsh net-list --all

cancer 側で取り込む。(libvirt 関連の情報は共有ディスク上にあるはずなので、cancer 側は再読込でOKのはず。)
(cancer) $ virsh net-list --all
(cancer) $ sudo systemctl reload libvirt-bin.service
(cancer) $ virsh net-list --all

これで VLAN付きスイッチの libvirt への登録も完了だ。
次は leo / virgo のネットワーク設定を変更して起動する流れだが、これは次回に。

OpenvSwitch による VLAN 検証(その1)

とりあえず、前述の図の3枚目までを実施してみる。

まずは leo / virgo を停止させよう。
(leo) $ sudo systemctl poweroff
(virgo) $ sudo systemctl poweroff

停止の確認が出来たら、gemini で virt-manager を起動し、leo / virgo に NIC を追加させる。
(gemini) $ virt-manager
NICを追加し、今まで使用していたものと
同じスイッチに繋ぐ

NIC追加したら、一度構成を見直してみよう。
(gemini) $ virsh edit leo
(gemini) $ virsh edit virgo
<interface type='network'>タグが2つあると思う。
2つ目の<interface ...>タグの<address ...>タグ、slot='0xNN'を見てみて欲しい。
0x0a になっていると思うけど、異なる値になっているかもしれない。
ココは leo / virgo で値を合わせておこう。(ここの値を 0x0a にした場合、ゲストOS leo / virgo の追加NICのデバイス名は ens10 になる)

仮想マシンの設定変更が完了したら、cancer 側にも反映させよう。
(cancer) $ sudo systemctl reload libvirt-bin.service
(cancer) $ virsh dumpxml leo
(cancer) $ virsh dumpxml virgo
(もし反映されてなかったら、 sudo systemctl restart libvirt-bin.service で再起動だ。)

設定反映が確認できたら、gemini 上で leo を、cancer 上で virgo をそれぞれ起動しよう。
(gemini) $ virsh start leo
(cancer) $ virsh start virgo

起動が完了したら、ネットワークインターフェースを確認。
(leo) $ ip link show
(virgo) $ ip link show
ens10 というネットワークインターフェース(NIC)が出来ているのが確認できるはずだ。

この NIC に IP アドレスを付与しよう。
今回は
leo : 192.168.57.138/24
virgo : 192.168.57.139/24
を充てる。
(普段使っている ens3 には、192.168.55.x/24 のIPアドレスが付与されている。ens10 には ens3 とは異なるネットワークアドレスを充てるように。)
(leo) $ sudo vi /etc/network/interfaces.d/ens10
--ココから
auto ens10
iface ens10 inet static
address 192.168.57.138
network 192.168.57.0
netmask 255.255.255.0
broadcast 192.168.57.255
--ココまで

(virgo) $ sudo vi /etc/network/interfaces.d/ens10
--ココから
auto ens10
iface ens10 inet static
address 192.168.57.139
network 192.168.57.0
netmask 255.255.255.0
broadcast 192.168.57.255
--ココまで

IPアドレスが付与されるか確認。(leo / virgo ともに同じ操作だ)
(leo) $ ip address show ens10
(leo) $ sudo ifup ens10
(leo) $ ip address show ens10

(virgo) $ ip address show ens10
(virgo) $ sudo ifup ens10
(virgo) $ ip address show ens10

OS 再起動して確認しよう。
(leo) $ sudo systemctl reboot
(virgo) $ sudo systemctl reboot
(leo) $ ip address show ens10
(virgo) $ ip address show ens10

IP アドレスの付与が出来たら、相互に ping を打って、疎通が取れることも確認しておく。
(leo) $ ping 192.168.57.139
(virgo) $ ping 192.168.57.138

今回はココまで。
次回は gemini / cancer に VLAN-ID 付きの仮想スイッチを作ってみる。

2017年6月12日月曜日

OpenvSwitch による VLAN 検証(概要)

さて、leo / virgo という仮想マシンが出来上がったところで、OpenvSwitch を用いた VLAN の検証をしてみたい。
と言っても、OpenvSwitch の癖がまだ掴めていないし、そもそも出来るのかどうかも不明。
イメージとしては、以下の図のように実装出来ると考えている。
スタート時の状態
(NIC は1つずつ)

仮想マシンに NIC を追加し、IPを付与。
これまで使っていた仮想スイッチにそのまま繋ぐ。

新しいIPアドレスで、仮想マシン同士の通信が可能

VLAN10 / VLAN20 のスイッチを作成し、既存スイッチへ接続
仮想マシンを VLAN10 経由に繋ぎ替える

同じ VLAN 同士なので通信できるはず

leo を VLAN10 から VLAN20 へ繋ぎ替える

異なる VLAN なので通信できないはず

virgo を VLAN20 へ繋ぎ替える

同じVLANになったので、また通信可能になる
はず

実は既に、最初の3枚分は実施している。
そんなに難しいことはやっていないので、次回から順番に書いていくことにする。

新仮想マシン virgo 誕生!

更に実験をすすめるため、新たな仮想マシン virgo を作成した。
構成は leo と同じ。
配置は、sagittarius / aquarius クラスタではなく、その上で稼働している gemini / cancer の上だ。
これも leo と同じ。
OS も leo と同じ、Ubuntu 16.04 だ。
物理マシン sagittarius / aquarius をセットで操作、仮想マシン gemini / cancer をセットで操作するのと同じように、仮想マシン上の仮想マシン leo / virgo をセットで動かす想定だ。
サクッと作って、まずは普通に動くようにしてくれ。

2017年6月8日木曜日

cancer の残りセットアップ

cancer かなり復活してきた。
残りは多分、ホスト停止時にゲストを停止カーネルの自動アップデート停止 の2つじゃないかな?

サクッと実装してしまおう。
まずは、ホスト停止時にゲストを停止する設定。
(cancer) $ sudo vi /etc/default/libvirt-guests
--ココから
25行目付近
#ON_SHUTDOWN=shutdown

ON_SHUTDOWN=shutdown
--ココまで
反映
(cancer) $ sudo systemctl daemon-reload
これで反映されてるんやろか…?
念のために、libvirt-guests.service を再起動しておくか。
(cancer) $ sudo systemctl restart libvirt-guests.service
多分コレで大丈夫。

続いて、カーネルの自動アップデートの停止。
$ sudo vi /etc/apt/apt.conf.d/50unattended-upgrades
--ココから
16行目付近
Unattended-Upgrade::Package-Blacklist {
//      "vim";
↓3行追記
Unattended-Upgrade::Package-Blacklist {
        "linux-headers-generic";
        "linux-signed-generic";
        "linux-signed-image-generic";
//      "vim";
--ココまで

これで cancer は元通りになったはず。
gemini 上で leo が動いていると思うので、オンラインマイグレーションや leo を動かしたまま cancer を停止、等試してみよう。

cancer で共有ボリュームをマウント

続いて共有ボリュームのマウントだ。

単純に /etc/fstab を書き換えて、OS再起動等でイケるんだけど…。
今回 cancer を再作成している過程で、ちょっと気になる点があった。

今まで、sagittarius / aquarius / gemini でgfs2共有ボリュームをマウントする時、「x-systemd.requires=dlm.service」という条件を付けていた。
gfs2 をマウントするだけならこれでいいんだけど、clvmd(lvm2-clvmd.service) によって管理され、lvm2-cluster-activation.service によってアクティベートされる領域は、前提条件が変わってくるのではないだろうか?

実際に、/lib/systemd/system/lvm2-clvmd.service には「After=dlm.service corosync.service」という条件が付いており、 /lib/systemd/system/lvm2-cluster-activation.service には「After=lvm2-clvmd.service」という条件が付いている。

つまり、dlm.service、lvm2-clvmd.service、lvm2-cluster-activation.serivce の3つのサービスの起動順は、
  1. dlm.service
  2. lvm2-clvmd.service
  3. lvm2-cluster-activation.service
になっているはず。
そして、CLVM管理のボリュームは、最後の lvm2-cluster-activation.service によってアクティベーションされるということを考えると、このボリュームはこのサービスの起動後出ないとマウント出来ないはずだ。

つまり、/etc/fstab につける条件は、「x-systemd.requires=dlm.service」ではなく「x-systemd.requires=lvm2-cluster-activation.service」だと考えられる。

という前提を踏まえて、作業開始。
/etc/fstab 書き換え
(cancer) $ sudo vi /etc/fstab
--ココから
以下の行を追加
/dev/mapper/vg--gfs2-etc--libvirt /etc/libvirt gfs2 _netdev,x-systemd.requires=lvm2-cluster-activation.service 0 0
/dev/mapper/vg--gfs2-var--lib--libvirt /var/lib/libvirt gfs2 _netdev,x-systemd.requires=lvm2-cluster-activation.service 0 0
--ココまで

追記が終わったら反映させてみる。
(cancer) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl start /etc/libvirt
(cancer) $ sudo systemctl start /var/lib/libvirt
(cancer) $ df
(cancer) $ ls -ld /etc/libvirt
(cancer) $ ls -ld /var/lib/libvirt
マウント出来たようだ。

この状態なら、libvirt に OpenvSwitch が使えるようになっているはずだけど…
(cancer) $ virsh net-list --all
(cancer) $ virsh list --all
まだ libvirt に反映されていない。

というわけで、libvirt-bin を再読込み。
(cancer) $ sudo systemctl reload libvirt-bin.service
(cancer) $ virsh net-list --all
(cancer) $ virsh list --all
無事に認識された。

後は OS再起動できちんとマウントされるかどうか…。
(cancer) $ sudo systemctl reboot
(cancer) $ df
問題なくマウント出来ている。
(cancer) $ virsh list --all
(cancer) $ virsh net-list --all
libvirt の方も共有ディスク側の情報を得ているようだ。

…が…
何度か再起動確認をしていったら、停止時は問題出てないが、起動時に corosync/dlm が上手く起動しない現象がまた発生。(一回だけ)
イマイチ原因がつかめない。
う~ん…。その後何度か再起動しているが、発生したのは一回だけ…。う~ん…。

気を取り直して…。
sagittarius / aquarius / gemini の /etc/fstab も合わせて書き換えておこう。
$ sudo vi /etc/fstab
--
x-systemd.requires=dlm.service を x-systemd.requires=lvm2-cluster-activation.service に書き換え(2箇所?)
--
$ cat /run/systemd/generator/etc-libvirt.mount
$ cat /run/systemd/generator/var-lib-libvirt.mount
$ sudo systemctl daemon-reload
$ cat /run/systemd/generator/etc-libvirt.mount
$ cat /run/systemd/generator/var-lib-libvirt.mount

これでオシマイ。

2017年6月7日水曜日

cancer で iscsi initiator

さて、iSCSI イニシエータだ。
まずは、open-iscsi.service の起動停止順を制御しておこう。

(cancer) $ sudo cp -pi /lib/systemd/system/open-iscsi.service \
    /lib/systemd/system/open-iscsi.service.orig
(cancer) $ sudo vi /lib/systemd/system/open-iscsi.service
--ココから
Wants=network-online.target remote-fs-pre.target iscsid.service
After=network-online.target iscsid.service
↓(前提条件に openvswitch-switch.service を追加)
Wants=network-online.target remote-fs-pre.target iscsid.service
Wants=openvswitch-switch.serivce
After=network-online.target iscsid.service
After=openvswitch-switch.service
--ココまで

設定を読み込み
(cancer) $ sudo systemctl daemon-reload

この時点で OS 再起動して、問題ないか確認しておきたい。
(cancer) $ systemctl status
(cancer) $ sudo systemctl reboot
(cancer) $ systemctl status
(cancer) $ systemctl --no-pager -l status open-iscsi.service

そうしたら、新 cancer の iqn名を確認。
(cancer) $ sudo cat /etc/iscsi/initiatorname.iscsi

NAS(iSCSIターゲット)側のアクセス許可を修正し、旧 cancer の iqn名を削除、今確認した新 cancer の iqn名からのアクセスを許可しよう。

そこまで実施できたら cancer から iSCSIターゲットへログインだ。
(cancer) $ sudo iscsiadm --mode node \
--targetname (iSCSI ターゲット名) \
--portal (NASのIPアドレス):3260 \
--op new
(3260 は NAS の iSCSIポートだ。デフォルトなら3260 のはず。)

(cancer) $ sudo iscsiadm --mode session
(cancer) $ sudo iscsiadm --mode node \
--targetname (iSCSI ターゲット名) \
--login
(cancer) $ sudo iscsiadm --mode session
ログインしただろうか?

ログインできたら、iSCSI の LUN が見えてきたはずだ。
(cancer) $ dmesg
(cancer) $ lsblk
(cancer) $ sudo multipath -ll

とりあえず、iSCSIターゲットへのログインを自動ログインにする。
(cancer) $ sudo iscsiadm --mode node \
--targetname (iSCSIターゲット名) \
--op show
node.startup が manual になっていることを確認。

(cancer) $ sudo iscsiadm --mode node \
--targetname (iSCSIターゲット名) \
--op update \
--name node.startup \
--value automatic

(cancer) $ sudo iscsiadm --mode node \
--targetname (iSCSIターゲット名) \
--op show
node.startup が automatic に変化しただろうか。

ココまで来たら、共有VG をアクティベートしてみよう。
(cancer) $ lsblk
(cancer) $ sudo vgchange -asy vg-gfs2
おや、どうやら出来ない。

何となく、dlm がこのボリュームを認識してないことが原因な気がする。
一度、dlm を再起動してみる。
(cancer) $ sudo systemctl restart dlm.service
(cancer) $ lsblk
お、LVを認識したぞ。

マウント云々は次回に回して、まずはキチンと再起動が出来るか確認だ。
(cancer) $ systemctl status
(cancer) $ sudo systemctl reboot
(cancer) $ dmesg
(cancer) $ systemctl status
(cancer) $ systemctl --no-pager -l status open-iscsi.service
(cancer) $ systemctl --no-pager -l status lvm2-cluster-activation.service
(cancer) $ systemctl --no-pager -l status corosync
(cancer) $ systemctl --no-pager -l status dlm
(cancer) $ dlm_tool status
(cancer) $ dlm_tool ls
(cancer) $ sudo vgdisplay -v vg-gfs2

どうやら問題無さそうだ。
次回はファイルシステムマウントかな?

cancer で multipath

次は multipath だ。
まだ cancer には iSCSI のボリュームは見えていないが、gemini と同じボリュームを同じように見えるようにするので、先に multipath を設定しておく。

(cancer) $ ls -ld /etc/multipath
(cancer) $ sudo mkdir /etc/multipath
(cancer) $ sudo chown root:root /etc/multipath
(cancer) $ sudo chmod 600 /etc/multipath
(cancer) $ ls -ld /etc/multipath

(cancer) $ ls /etc/multipath.conf
(cancer) $ sudo bash -c \
"zcat /usr/share/doc/multipath-tools/examples/multipath.conf.annotated.gz \
> /etc/multipath.conf"
(cancer) $ ls /etc/multipath.conf

(cancer) $ sudo vi /etc/multipath.conf
--ココから
10行目付近
#defaults {
↓先頭の#を削除
defaults {

215行目付近
# user_friendly_names no
↓先頭の#を削除し、no→yesへ書き換え
user_friendly_names yes

341行目付近
#}
↓先頭の#を削除
}
--ココまで
(cancer) $ sudo systemctl reload multipathd.service
(cancer) $ systemctl --no-pager -l status multipathd.service

先行して wwids ファイルと bindings ファイルは作ってしまおう。
中身は gemini のものと同じでいいので、gemini の中身を参考に。
(gemini) $ sudo cat /etc/multipath/wwids
(cancer) $ sudo vi /etc/multipath/wwids
--gemini で確認した内容をそのまま書き込む

(cancer) $ sudo chmod 600 /etc/multipath/wwids

(gemini) $ sudo cat /etc/multipath/bindings
(cancer) $ sudo vi /etc/multipath/bindings
--gemini で確認した内容をそのまま書き込む

(cancer) $ sudo chmod 600 /etc/multipath/bindings

これで終わりかな?
後は iSCSIターゲットから LUN が見られるようになれば、自動的に multipath デバイスとして認識してくれるはずだ。

というわけで次回は iSCSIイニシエータかな?

cancer で CLVM

続いて、CLVM の設定だ。
こちらも、過去実績通り。

パッケージ類は導入済みなので、ガツガツ設定を施していく。
/etc/init.d/clvm の無効化
(cancer) $ systemctl --no-pager -l status clvm.service
(cancer) $ systemctl is-enabled clvm.service
(cancer) $ sudo systemctl disable clvm.service
(cancer) $ systemctl is-enabled clvm.service
(cancer) $ systemctl is-active clvm.service
(cancer) $ systemctl --no-pager -l status clvm.service

起動停止処理の変更
(cancer) $ sudo cp -pi /lib/systemd/system/lvm2-cluster-activation.service \
/lib/systemd/system/lvm2-cluster-activation.service.orig
(cancer) $ sudo cp -pi /lib/systemd/system/lvm2-clvmd.service \
/lib/systemd/system/lvm2-clvmd.service.orig

(cancer) $ sudo vi /lib/systemd/system/lvm2-cluster-activation.service
--ココから
After=lvm2-clvmd.service lvm2-cmirrord.service
↓(lvm2-cmirrord.service を削除)
After=lvm2-clvmd.service

EnvironmentFile=-${prefix}/etc/sysconfig/clvmd
↓(コメント化)
#EnvironmentFile=-${prefix}/etc/sysconfig/clvmd
--ココまで

(cancer) $ sudo vi /lib/systemd/system/lvm2-clvmd.service
--ココから
EnvironmentFile=-${prefix}/etc/sysconfig/clvmd
↓(コメント化)
#EnvironmentFile=-${prefix}/etc/sysconfig/clvmd

ExecStart=/sbin/clvmd $CLVMD_OPTS
↓(パスを /usr/sbin/clvmd に変更)
ExecStart=/usr/sbin/clvmd $CLVMD_OPTS
--ココまで
(ちなみに、lvm2-cmirrord.service は Ubuntu 17.10 の開発中のパッケージには含まれているようだ。LTS版は 18.04 で導入が間に合うかな?)

設定の反映と起動
(cancer) $ sudo systemctl daemon-reload
(cancer) $ systemctl --no-pager -l status lvm2-cluster-activation.service
(cancer) $ systemctl --no-pager -l status lvm2-clvmd.service
(cancer) $ sudo systemctl start lvm2-cluster-activation.service
(cancer) $ systemctl --no-pager -l status lvm2-cluster-activation.service
(cancer) $ systemctl --no-pager -l status lvm2-clvmd.service
(cancer) $ dlm_tool status

lvmconf の変更
(cancer) $ sudo lvmconf --enable-cluster --services --startstopservices
(cancer) $ systemctl --no-pager -l status lvm2-clvmd.service
(cancer) $ systemctl --no-pager -l status lvm2-cluster-activation.service

OS 再起動して結果確認
(cancer) $ systemctl status
(cancer) $ sudo systemctl reboot
(cancer) $ systemctl status
(cancer) $ systemctl --no-pager -l status lvm2-clvmd.service
(cancer) $ systemctl --no-pager -l status lvm2-cluster-activation.service
(cancer) $ dlm_tool status
(cancer) $ dlm_tool ls

良さそうだな。
次は multipathd 関連を。(共有ボリュームを使うのはその先で。)

cancer で dlm と corosync を

続いて、dlm と corosync だ。
これは色々苦労したんだけど、本当にこれまでのやり方が正しいのか分からない。

とりあえず、手を出せるところに手を出してみる。

まずは、dlm.conf だ。
(cancer) $ sudo mkdir /etc/dlm
(cancer) $ sudo bash -c "dlm_tool dump_config > /etc/dlm/dlm.conf"
(cancer) $ sudo vi /etc/dlm/dlm.conf
--ココから
enable_fencing を 0 に
enable_fencing=1

enable_fencing=0
--ココまで

(cancer) $ sudo systemctl restart dlm.service

再起動して確認してみる。
(cancer) $ sudo systemctl reboot
(cancer) $ systemctl --no-pager -l status dlm.service
(cancer) $ systemctl status
(cancer) $ tail -f /var/log/syslog
(cancer) $ dlm_tool status

ここまでは問題無さそうだ。
続いて corosync。
(cancer) $ sudo vi /etc/corosync/corosync.conf
gemini を参照しながら修正しよう。
修正内容は gemini と同じだ。
--ココから
cluster_name: debian

cluster_name: mycluster

bindnetaddr: 127.0.0.1

bindnetaddr: 192.168.55.0

quorum {} 内に2行追加
two_node: 1
wait_for_all: 0
--ココまで

(cancer) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl restart corosync.service
(cancer) $ systemctl --no-pager -l status corosync.service
(cancer) $ systemctl --no-pager -l status dlm.service
(cancer) $ dlm_tool status

再起動して確認。
(cancer) $ sudo systemctl reboot
(cancer) $ systemctl status
(cancer) $ systemctl --no-pager -l status corosync.service
(cancer) $ systemctl --no-pager -l status dlm.service
やっぱり、dlm_controld が落ちる現象が出てるな。

というわけで、corosync の起動を openvswitch の後に変更する。
今までは、Requires エントリと After エントリに追記する形にしてたけど、どうやら両エントリとも複数行書くことが可能のようだ。
今回は、Requires と After の行を増やす方向で実施してみる。
(cancer) $ sudo cp -pi /lib/systemd/system/corosync.service \
/lib/systemd/system/corosync.service.orig
(cancer) $ sudo vi /lib/systemd/system/corosync.service
--ココから
ConditionKernelCommandLine=!nocluster
Requires=network-online.target
After=network-online.target

↓(Requires と After の行を増やす)
ConditionKernelCommandLine=!nocluster
Requires=network-online.target
Requires=openvswitch-switch.service
After=network-online.target
After=openvswitch-switch.service
--ココまで

設定を反映させ、再起動して確認。
(cancer) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl reboot
(cancer) $ systemctl status
(cancer) $ systemctl --failed
(cancer) $ systemctl --no-pager -l status corosync.service
(cancer) $ systemctl --no-pager -l status dlm.service
(cancer) $ ps -ef | grep -e corosync -e dlm | grep -v grep
(cancer) $ dlm_tool status
やはり、corosync がダウンして期待した動作にならない。

今度は、openvswitch の起動処理後に sleep を入れてみる。
(cancer) $ sudo cp -pi /lib/systemd/system/openvswitch-switch.service \
/lib/systemd/system/openvswitch-switch.service.orig
(cancer) $ sudo vi /lib/systemd/system/openvswitch-switch.service
--ココから
以下の行を[Service]エントリに追記する。
ExecStart=/bin/sleep 10
--ココまで

再び設定を反映させ、再起動して確認。
(cancer) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl reboot
(cancer) $ systemctl status
(cancer) $ systemctl --failed
(cancer) $ systemctl --no-pager -l status corosync.service
(cancer) $ systemctl --no-pager -l status dlm.service
(cancer) $ ps -ef | grep -e corosync -e dlm | grep -v grep
(cancer) $ dlm_tool status
今度は大丈夫なようだ。
何度か再起動して、挙動を確認してみよう。

これで gemini との間の通信は確立できた。
次は CLVM の設定か。

2017年6月6日火曜日

cancer に autofs を

続いて、autofs 化を実施。
こちらも、gemini と同じ作業を行えばいい。

パッケージ類は導入済みなので、さっくり実施。
(cancer) $ sudo mkdir /etc/auto.master.d
(cancer) $ sudo vi /etc/auto.master.d/mnt.autofs
--ココから
/mnt /etc/auto.master.d/auto.mnt --timeout=60 --ghost
--ココまで

(cancer) $ sudo vi /etc/auto.master.d/auto.mnt
--ココから
iso-os -fstype=cifs,guest ://(NASのIP)/(共有フォルダ)
--ココまで

(cancer) $ sudo systemctl restart autofs
(cancer) $ df /mnt/iso-os
(cancer) $ ls /mnt/iso-os
(cancer) $ sleep 60
(cancer) $ df /mnt/iso-os

あっさり終了。

cancer の IP固定化&OpenvSwtich

続いて、cancer の IP を固定化する。
これ、ついでに OpenvSwitch も設定してしまう予定だ。
過去に何度か実施しているので、その辺りを探してみればいいけど、一応コマンド入れておく。

(cancer) $ ip link show
(cancer) $ sudo ovs-vsctl show
(cancer) $ sudo ovs-vsctl add-br extsw
(cancer) $ sudo ovs-vsctl show

(cancer) $ sudo vi /etc/default/networking
--ココから
1行編集
#EXCLUDE_INTERFACES=

EXCLUDE_INTERFACES=extsw
--ココまで

(cancer) $ sudo vi /etc/network/interfaces.d/0110.ens3
--ココから
auto ens3
allow-extsw
iface ens3 inet manual
ovs_bridge extsw
ovs_type OVSPort
--ココまで

(cancer) $ sudo vi /etc/network/interfaces.d/0010.extsw
--ココから
auto extsw
allow-ovs extsw
iface extsw inet static
address 192.168.55.137
network 192.168.55.0
netmask 255.255.255.0
broadcast 192.168.55.255
gateway 192.168.55.1
ovs_type OVSBridge
ovs_ports ens3

dns-nameservers 192.168.55.1
--ココまで

(cancer) $ sudo ifdown ens3
(cancer) $ sudo vi /etc/network/interfaces
--ココから
2行コメント化
auto ens3
iface ens3 inet dhcp

#auto ens3
#iface ens3 inet dhcp
--ココまで

(cancer) $ sudo ovs-vsctl add-port extsw ens3
(cancer) $ sudo ovs-vsctl show
(cancer) $ sudo ifup ens3
(cancer) $ sudo ifup extsw
(cancer) $ ip address show
(cancer) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl reboot
(cancer) $ ip address show

これで IP アドレスは元通りになったけど、ssh ホスト鍵が異なるので、ssh クライアントから接続する時にエラーになると思う。
クライアント側の known_hosts をいじることになるので、各クライアント毎に対処しよう。

あ、忘れてた。
合わせて、ssh鍵認証出来るように設定しておこう。
gemini の ~/.ssh/authorized_keys と同じ内容のファイルを、cancer 側の同じパスに作っておくだけでいいぞ。