o2cb.service の起動が上手くいかない件に関して、以下のように調査をしたんだけど、結局上手く行かず。
原因が良くわからない。(以下の手順を実施すると、OpenvSwitch / networking の起動がダメになる。)
この件は保留にして、ocfs2 関連はステの方向で進めることにしよう。gfs2 が使えるからね。
ちなみに、設定は元に戻してある。
--------------------------------------------------------------------------------
さて、続いて o2cb.service の起動が上手くいかない問題だ。
正直言って、あまり対処する必要が無い気がするが…。
とりあえず、OS 起動後に o2cb.service をリスタートすることで正常起動することは分かっている。
であれば、起動処理を少し後ろにずらせばいいのではないだろうか？
ただしコイツ、systemd の起動スクリプトが無く、/etc/init.d の下のものを systemd-generetor によって自動的に作っている代物。
このままだと、起動処理の制御は難しい。
だったら、自動生成されたものをベースに、/lib/systemd/system の下に作ってしまったらどうだろうか？
というわけでやってみる。
ocfs2.service も同時に処理しておく。
(cancer) $ sudo systemctl stop o2cb
(cancer) $ sudo systemctl disable o2cb.service
(cancer) $ sudo systemctl stop ocfs2
(cancer) $ sudo systemctl disable ocfs2.service
(cancer) $ sudo cp -pi /run/systemd/generator.late/o2cb.service \
/lib/systemd/system/
(cancer) $ ls -l /lib/systemd/system/o2cb.service
(cancer) $ sudo vi /lib/systemd/system/o2cb.service
--ココから
先頭付近の SourcePath 宣言をコメントアウトする
SourcePath=/etc/init.d/o2cb
↓
#SourcePath=/etc/init.d/o2cb
After宣言に、openvswitch-switch.service を追加する。
After=network-online.target
↓
After=network-online.target openvswitch-switch.service
Wants宣言にも。
Wants=network-online.target
↓
Wants=network-online.target openvswitch-switch.service
末尾に[Install]セクションとインストール先を追加する。
[Install]
WantedBy=multi-user.target
--ココまで
(cancer) $ sudo systemctl daemon-reload
(cancer) $ sudo cp -pi /run/systemd/generator.late/ocfs2.service \
/lib/systemd/system/
(cancer) $ ls -l /lib/systemd/system/ocfs2.service
(cancer) $ sudo vi /lib/systemd/system/ocfs2.service
--ココから
先頭付近の SourcePath 宣言をコメントアウトする
SourcePath=/etc/init.d/o2cb
↓
#SourcePath=/etc/init.d/o2cb
末尾に[Install]セクションとインストール先を追加する。
[Install]
WantedBy=multi-user.target
--ココまで
(cancer) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl enable o2cb.service
(cancer) $ sudo systemctl enable ocfs2.service
(cancer) $ sudo systemctl status o2cb
(cancer) $ sudo systemctl status ocfs2
(cancer) $ sudo systemctl start o2cb.service
(cancer) $ sudo systemctl start ocfs2.service
(cancer) $ sudo systemctl status o2cb
(cancer) $ sudo systemctl status ocfs2
再起動して確認
(cancer) $ sudo systemctl reboot
(cancer) $ systemctl status
(cancer) $ systemctl status o2cb
(cancer) $ sudo vgchange -asy vg-ocfs2
(cancer) $ sudo systemctl start /mnt/ocfs2
2017年5月3日水曜日
2017年5月2日火曜日
シャットダウン時に刺さる現象(その2)
調べてみると、iSCSIターゲットにログインする処理は、open-iscsi.service というサービスが担っているようだ。
(cancer) $ systemctl --no-pager -l status open-iscsi.service
更に、このサービスの停止処理を追いかけていくと、どうやら iSCSI領域のファイルシステムアンマウントも実行している模様。
実際に、iSCSI領域をマウントしている状態で、このサービスの停止を仕掛けてみると、ファイルシステムのアンマウントやiSCSIターゲットからのログアウトも自動的にやってくれている。
ということは、このサービスの前提に、openvswitch-switch.service を付けてやればいいんじゃないか？
というわけで試してみる。
(cancer) $ cd /lib/systemd/system
(cancer) $ sudo cp -pi open-iscsi.service open-iscsi.service.orig
(cancer) $ sudo vi 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 openvswitch-switch.serivce
After=network-online.target iscsid.service openvswitch-switch.service
--ココまで
(cancer) $ cd
設定を読み込み
(cancer) $ sudo systemctl daemon-reload
ディスク類をマウントしてしまおう。
(まだ、o2cbの問題は解決していないので、o2cbの再起動も実施)
(cancer) $ sudo systemctl restart o2cb.service
(cancer) $ sudo vgchange -asy vg-ocfs2
(cancer) $ sudo vgchange -asy vg-gfs2
(cancer) $ sudo systemctl start /mnt/ocfs2
(cancer) $ sudo systemctl start /mnt/gfs2
ここで再起動を実施するんだけど、刺さったかどうかはコンソールを見ておく必要がある。
virt-viewerを使って、コンソールから再起動させよう。
(cancer) $ sudo systemctl reboot
あれ？刺さった。
--------------------------------------------------------------------------------
どうやら、刺さる要因は2つあったようだ。
1つは「iSCSIターゲットからログアウトする前に、OpenvSwitchが停止してしまう」という現象。
こちらは、上で対処済み。
もう1つは ocfs2 絡みのようだ。
どうも絞り込んでいくと、ocfs2 ファイルシステムがマウントされている時に刺さる現象が起きているようだ。
ocfs2 ファイルシステムのアンマウントに時間がかかっていることが原因じゃないだろうか？
どうする？gfs2 が使えるので、ocfs2 は使わないようにすればいいのだが…。一応、もう少し調べてみよう。(o2cbサービスが正常起動出来ない点も含めて)
ちなみに、今KVMホストとして使っている aquarius/sagittarius は、ocfs2 関連の環境は一切作っていないため、刺さる現象は OpenvSwitch + iSCSI によるモノだ。
色々試してみたが、以下の組み合わせの時に発生するようだ。
どうも、iSCSIターゲットからログアウトする前に、OpenvSwitch が停止しているように見える。
もしそうだとしたら、gfs2 でも同じ事象が起きそうなものだが、gfs2 では同じ事象は発生しない。
これは、gfs2 / ocfs2 のアンマウントにかかる時間が違うからのようだ。
gfs2 は一瞬でアンマウントされるが、 ocfs2 はアンマウントに時間がかかる。
どうもそれが原因のようだ。
さてどうしよう。選択肢は2つ。
というわけで、もう少し調査…。
色々調べていった結果、 lvm2-cluster-activation.service の停止処理に sleep を入れることで、再発率が大幅に下がることが分かった。
20秒の sleep で再現せず、5秒の sleep では時々再発。10秒の sleep で再現性がほぼ無くなったようだ。
ちょっと原因は分からないが、とりあえずこれで逃げることにしよう。
(cancer) $ cd /lib/systemd/system
(cancer) $ sudo vi lvm2-cluster-activation.service
--ココから
[Service]セクションに1行追加
ExecStopPost=/bin/sleep 10
--ココまで
(cancer) $ sudo systemctl daemon-reload
これでヨサゲ。
ついでに、 openvswitch-switch.service の起動時の処理に6秒の sleep を入れていたが、これも 10秒程度に延ばしておいた方が良さそうだ。
どうも、ウチの NAS の性能が良くなく、 iSCSI ログイン/ログアウトに(少し)時間がかかるのが直接の原因じゃないか？という疑い。
合わせて修正しておこう。
(cancer) $ sudo vi openvswitch-switch.service
--ココから
ExecStart=/bin/sleep 6
↓
ExecStart=/bin/sleep 10
--ココまで
(cancer) $ sudo systemctl daemon-reload
これでとりあえず大丈夫だろう。
詳細がつかめたら、合わせて本対処するが、原因不明のため、このまま行くことにする。
(cancer) $ systemctl --no-pager -l status open-iscsi.service
更に、このサービスの停止処理を追いかけていくと、どうやら iSCSI領域のファイルシステムアンマウントも実行している模様。
実際に、iSCSI領域をマウントしている状態で、このサービスの停止を仕掛けてみると、ファイルシステムのアンマウントやiSCSIターゲットからのログアウトも自動的にやってくれている。
ということは、このサービスの前提に、openvswitch-switch.service を付けてやればいいんじゃないか？
というわけで試してみる。
(cancer) $ cd /lib/systemd/system
(cancer) $ sudo cp -pi open-iscsi.service open-iscsi.service.orig
(cancer) $ sudo vi 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 openvswitch-switch.serivce
After=network-online.target iscsid.service openvswitch-switch.service
--ココまで
(cancer) $ cd
設定を読み込み
(cancer) $ sudo systemctl daemon-reload
ディスク類をマウントしてしまおう。
(まだ、o2cbの問題は解決していないので、o2cbの再起動も実施)
(cancer) $ sudo systemctl restart o2cb.service
(cancer) $ sudo vgchange -asy vg-ocfs2
(cancer) $ sudo vgchange -asy vg-gfs2
(cancer) $ sudo systemctl start /mnt/ocfs2
(cancer) $ sudo systemctl start /mnt/gfs2
ここで再起動を実施するんだけど、刺さったかどうかはコンソールを見ておく必要がある。
virt-viewerを使って、コンソールから再起動させよう。
(cancer) $ sudo systemctl reboot
あれ？刺さった。
--------------------------------------------------------------------------------
どうやら、刺さる要因は2つあったようだ。
1つは「iSCSIターゲットからログアウトする前に、OpenvSwitchが停止してしまう」という現象。
こちらは、上で対処済み。
もう1つは ocfs2 絡みのようだ。
どうも絞り込んでいくと、ocfs2 ファイルシステムがマウントされている時に刺さる現象が起きているようだ。
ocfs2 ファイルシステムのアンマウントに時間がかかっていることが原因じゃないだろうか？
どうする？gfs2 が使えるので、ocfs2 は使わないようにすればいいのだが…。一応、もう少し調べてみよう。(o2cbサービスが正常起動出来ない点も含めて)
ちなみに、今KVMホストとして使っている aquarius/sagittarius は、ocfs2 関連の環境は一切作っていないため、刺さる現象は OpenvSwitch + iSCSI によるモノだ。
色々試してみたが、以下の組み合わせの時に発生するようだ。
- OpenvSwitch を使用
- OpenvSwitch の仮想スイッチを経由した iSCSI LUN
- その LUN を multipathd でデバイスマッピング
- そのデバイスマッピングで ocfs2 ファイルシステムを使用
- そのファイルシステムをマウント
どうも、iSCSIターゲットからログアウトする前に、OpenvSwitch が停止しているように見える。
もしそうだとしたら、gfs2 でも同じ事象が起きそうなものだが、gfs2 では同じ事象は発生しない。
これは、gfs2 / ocfs2 のアンマウントにかかる時間が違うからのようだ。
gfs2 は一瞬でアンマウントされるが、 ocfs2 はアンマウントに時間がかかる。
どうもそれが原因のようだ。
さてどうしよう。選択肢は2つ。
- もっと原因と対策を追求する
- ocfs2 を捨てる
というわけで、もう少し調査…。
色々調べていった結果、 lvm2-cluster-activation.service の停止処理に sleep を入れることで、再発率が大幅に下がることが分かった。
20秒の sleep で再現せず、5秒の sleep では時々再発。10秒の sleep で再現性がほぼ無くなったようだ。
ちょっと原因は分からないが、とりあえずこれで逃げることにしよう。
(cancer) $ cd /lib/systemd/system
(cancer) $ sudo vi lvm2-cluster-activation.service
--ココから
[Service]セクションに1行追加
ExecStopPost=/bin/sleep 10
--ココまで
(cancer) $ sudo systemctl daemon-reload
これでヨサゲ。
ついでに、 openvswitch-switch.service の起動時の処理に6秒の sleep を入れていたが、これも 10秒程度に延ばしておいた方が良さそうだ。
どうも、ウチの NAS の性能が良くなく、 iSCSI ログイン/ログアウトに(少し)時間がかかるのが直接の原因じゃないか？という疑い。
合わせて修正しておこう。
(cancer) $ sudo vi openvswitch-switch.service
--ココから
ExecStart=/bin/sleep 6
↓
ExecStart=/bin/sleep 10
--ココまで
(cancer) $ sudo systemctl daemon-reload
これでとりあえず大丈夫だろう。
詳細がつかめたら、合わせて本対処するが、原因不明のため、このまま行くことにする。
2017年4月25日火曜日
シャットダウン時に刺さる現象(その1)
ココで、「シャットダウン・リブート中に刺さったような現象が」って書いた。
コレ、どうやら iSCSIターゲットにログインしている状態(iSCSIディスクのLVMアクティベートは関係なく)でシャットダウンやリブートを行うと発生するようだ。
iSCSIターゲットからログアウトした状態でリブートした場合は発生しない。
ということは、ネットワーク切断後にiSCSIログアウトを行おうとしているんだろう。
今回の構成は、OpenvSwitchで作った仮想スイッチの先に iSCSIターゲットがあるが、普通に設計する場合は、iSCSI用に専用の物理ネットワークポートを用意(大抵は冗長化のため、複数ポート)する。
この場合、iSCSI専用NICには、OpenvSwitchのような仮想スイッチを挟むことはしないはずだ。
自宅で作っているような小さな環境の場合、データ用とiSCSI用でネットワークも分離せず、全て1系統のみで賄ってしまうような形になるだろう。
つまるところ、ウチの構成が、iSCSIターゲットを使う理想の構成からは外れている、ということだ。
恐らく、OpenvSwitchによる仮想スイッチの停止処理と、iSCSIターゲットからのログアウト処理の順序性の問題だと思われる。
となると、どうすればいいのだろうか？
そのあたりを中心に、ちょっと調査を継続しよう。
コレ、どうやら iSCSIターゲットにログインしている状態(iSCSIディスクのLVMアクティベートは関係なく)でシャットダウンやリブートを行うと発生するようだ。
iSCSIターゲットからログアウトした状態でリブートした場合は発生しない。
ということは、ネットワーク切断後にiSCSIログアウトを行おうとしているんだろう。
今回の構成は、OpenvSwitchで作った仮想スイッチの先に iSCSIターゲットがあるが、普通に設計する場合は、iSCSI用に専用の物理ネットワークポートを用意(大抵は冗長化のため、複数ポート)する。
この場合、iSCSI専用NICには、OpenvSwitchのような仮想スイッチを挟むことはしないはずだ。
自宅で作っているような小さな環境の場合、データ用とiSCSI用でネットワークも分離せず、全て1系統のみで賄ってしまうような形になるだろう。
つまるところ、ウチの構成が、iSCSIターゲットを使う理想の構成からは外れている、ということだ。
恐らく、OpenvSwitchによる仮想スイッチの停止処理と、iSCSIターゲットからのログアウト処理の順序性の問題だと思われる。
となると、どうすればいいのだろうか？
そのあたりを中心に、ちょっと調査を継続しよう。
2017年4月13日木曜日
2017年4月7日金曜日
今の調査状況
--2017/04/20追記ココから--
ここで出ている問題は、前回分に追記した内容で解消したっぽい。
なので、無駄な記事になってしまった。
--2017/04/20追記ココまで--
全然解決しねぇ。
ここで出ている問題は、前回分に追記した内容で解消したっぽい。
なので、無駄な記事になってしまった。
--2017/04/20追記ココまで--
全然解決しねぇ。
今のところ…
- corosyncの自動起動にほぼ間違いなく失敗する。
- corosyncの自動起動失敗に伴い、dlmも停止する。
- o2cbの起動もほぼ間違いなく失敗する。
(ただし、systemd的には成功しているように見える。) - OSの起動後、手作業でcorosyncを起動することは可能。
- 同、手作業でdlmを起動することは可能。
(corosyncが起動していない状態でdlmを手作業で起動すれば、corosyncも連動して起動する。) - corosyncのsystemd起動ファイル(/lib/systemd/system/corosync.service)のRequiresとAfterにopenvswitch-switchを追加することで、corosync/dlmの自動起動成功率は高まる。
(必ず成功するわけではなく、自動起動失敗することもある。) - 両ノードでdlmが起動している状態で、片方のノードを停止させると、しばらくしてから生きている方のノードも自動でリブートする。
- OS起動後、o2cbを手作業で起動(停止してから起動)は成功する。
- corosync/dlmが停止している(起動失敗している)状態で、手作業でgfs2ファイルシステムをマウントしようとすると、corosync/dlmが自動起動してマウント成功する。
- o2cbが正常起動している状態でなら、ocfs2ファイルシステムのマウントが可能。
- o2cbの起動が上手く行っていない状態でocfs2ファイルシステムをマウントしようとすると、マウント失敗する。
- o2cbを正常停止させている状態からocfs2ファイルシステムをマウントしようとすると、o2cbが自動起動してマウント成功する。
- いずれも、openvswitch-switchが導入されていない環境では起きない問題。
辺りのことが分かってきた。
考え方的に、corosync/dlmとgfs2はセット、o2cbとocfs2がセット、となる。
今は両方に問題が出ているが、別モノとして整理、調査しないと混乱してしまうな。
考え方的に、corosync/dlmとgfs2はセット、o2cbとocfs2がセット、となる。
今は両方に問題が出ているが、別モノとして整理、調査しないと混乱してしまうな。
2017年4月4日火曜日
共有仮想ディスクの設定
前回、cancer側でocfs2ファイルシステムのマウントが出来なくなった、と書いた。
クラスタ云々っていう理由だと思ったけど、それ以前に共有仮想ディスク(/dev/vdb、/dev/vdc)の設定自体がおかしかった。
そもそも、複数のサーバで仮想ディスクを共有させるのなら、仮想マシンにそのディスクを割り当てる時に「共有可能」というチェックボックスにチェックを入れておく必要があった。
この時点で既に設定が間違っていたということになる。
これが付いていないと、それぞれの仮想マシン(gemini/cancer)でスナップショットを作成したりすると、この仮想ディスクも2世代スナップショットが作られてしまい、内部的に混乱してしまう。
それで、geminiでマウント出来ても、cancerでマウント出来ない状態になったようだ。
アカン…もう一度作り直すか…。
クラスタ云々っていう理由だと思ったけど、それ以前に共有仮想ディスク(/dev/vdb、/dev/vdc)の設定自体がおかしかった。
そもそも、複数のサーバで仮想ディスクを共有させるのなら、仮想マシンにそのディスクを割り当てる時に「共有可能」というチェックボックスにチェックを入れておく必要があった。
この時点で既に設定が間違っていたということになる。
これが付いていないと、それぞれの仮想マシン(gemini/cancer)でスナップショットを作成したりすると、この仮想ディスクも2世代スナップショットが作られてしまい、内部的に混乱してしまう。
それで、geminiでマウント出来ても、cancerでマウント出来ない状態になったようだ。
アカン…もう一度作り直すか…。
2017年4月2日日曜日
ocfs2とdlm
結局、gemini/cancerの作り直しをしているのだが…。
そこでちょっとおかしなことに気付いた。
共有ファイルシステム(ocfs2)では、gemini/cancerともにocfs2関連のパッケージのインストールとそのセットアップで共有ファイルシステムが実現できていたが、その後geminiにcorosync/dlm関連のパッケージを導入したら、cancer側でocfs2のファイルシステムマウントが出来なくなった。
cancer側でマウントしようとすると、「このファイルシステムはクラスタに所属している」というメッセージが出て、マウントできないのだ。
で、なんでだろうかと調べていたら、gemini側でocfs2ファイルシステムをマウントしようとすると、syslogにdlm関連のメッセージが出力される。
ocfs2とdlmは完全に独立していて、相互関連は無いと思っていたのだが、どうやら関連があるようだ。
元々調査していた問題とは別だけど、こちらはこちらで調査することにする。
--2017/04/20追記ココから--
この問題は、 gemini/cancer で仮想ディスクを共有したままスナップショットを作成したり戻したり、というのが原因だったようだ。
今後、スナップショットを取る時には、
仮想マシンの停止
↓
共有仮想ディスクの切り離し
↓
スナップショットを作成
↓
共有仮想マシンの接続
↓
仮想マシンの起動
という流れを取ることにしよう…。
--2017/04/20追記ココまで--
そこでちょっとおかしなことに気付いた。
共有ファイルシステム(ocfs2)では、gemini/cancerともにocfs2関連のパッケージのインストールとそのセットアップで共有ファイルシステムが実現できていたが、その後geminiにcorosync/dlm関連のパッケージを導入したら、cancer側でocfs2のファイルシステムマウントが出来なくなった。
cancer側でマウントしようとすると、「このファイルシステムはクラスタに所属している」というメッセージが出て、マウントできないのだ。
で、なんでだろうかと調べていたら、gemini側でocfs2ファイルシステムをマウントしようとすると、syslogにdlm関連のメッセージが出力される。
ocfs2とdlmは完全に独立していて、相互関連は無いと思っていたのだが、どうやら関連があるようだ。
元々調査していた問題とは別だけど、こちらはこちらで調査することにする。
--2017/04/20追記ココから--
この問題は、 gemini/cancer で仮想ディスクを共有したままスナップショットを作成したり戻したり、というのが原因だったようだ。
今後、スナップショットを取る時には、
仮想マシンの停止
↓
共有仮想ディスクの切り離し
↓
スナップショットを作成
↓
共有仮想マシンの接続
↓
仮想マシンの起動
という流れを取ることにしよう…。
--2017/04/20追記ココまで--
2017年2月18日土曜日
共有FSマウント変更
前回、CLVMが動くところまではナントカしたけど、よく考えてみたらcancer側でファイルシステムマウント関連の設定を施してなかった。
ココとかココとかココとかだ。
これらgeminiに適用した変更内容を、cancer側にも適用しておく必要がある。
というわけで以下の通り。
まずはファイルシステム(/mnt/ocfs2と/mnt/gfs2)がマウントされていないことを確認。
(cancer) $ df
多分、マウントされていないと思うけど、現時点でマウントされていたら、アンマウントしておく必要がある。もしアンマウントに失敗したら、強制再起動しないといけない。
fstabにマウントエントリを書く
(cancer) $ sudo vi /etc/fstab
以下の行を追記する
--ココから
/dev/mapper/vg--ocfs2-lv--ocfs /mnt/ocfs2 ocfs2 _netdev,x-systemd.requires=o2cb.service 0 0
/dev/mapper/vg--gfs2-lv--gfs /mnt/gfs2 gfs2 _netdev,x-systemd.requires=dlm.service 0 0
--ココまで
書き終わったら、設定をsystemdに反映させる。
(cancer) $ sudo systemctl daemon-reload
反映が終わったら、マウント出来るか確認。
(cancer) $ df
(cancer) $ sudo systemctl start /mnt/ocfs2
(cancer) $ sudo systemctl start /mnt/gfs2
(cancer) $ df
マウント出来たのが確認できたら、一応OSを再起動して、再起動後に自動マウントされるか確認。
(cancer) $ sudo shutdown -r now
(cancer) $ df
これでオシマイかと思ったけど、ocfs2の領域がマウントされていない。
gemini側でアクティベートされているのが原因かと思い、色々試してみたんだが、ちょっと原因が不明。
一度、gemini側でアンマウント、ディアクティベート、アクティベート、マウント、の流れを行ったら、cancer側でも問題なくマウント出来るようになった。
もしかしたら、CLVM関連を操作していく過程で、情報の同期が上手く行かなかったのかもしれない。
(gemini) $ df
(gemini) $ sudo systemctl stop /mnt/ocfs2
(gemini) $ sudo vgchange -a n vg-ocfs2
(gemini) $ sudo vgchange -a y vg-ocfs2
(gemini) $ sudo systemctl stop /mnt/ocfs2
(gemini) $ df
本来なら、LVM→CLVM→ファイルシステムという順に作成(操作)していくのを、今回はVG→ファイルシステム→CLVMという順に操作していったため、何か不具合が生じたんじゃないかと。
気になるのなら、gemini/cancerともに停止して、完全停止後に両方を起動して、マウントされるか確認しておいた方がいいかな。
今後、色々実験していく中で、同じような症状が出るかもしれないが、その時にまた考えることにしよう。
ココとかココとかココとかだ。
これらgeminiに適用した変更内容を、cancer側にも適用しておく必要がある。
というわけで以下の通り。
まずはファイルシステム(/mnt/ocfs2と/mnt/gfs2)がマウントされていないことを確認。
(cancer) $ df
多分、マウントされていないと思うけど、現時点でマウントされていたら、アンマウントしておく必要がある。もしアンマウントに失敗したら、強制再起動しないといけない。
fstabにマウントエントリを書く
(cancer) $ sudo vi /etc/fstab
以下の行を追記する
--ココから
/dev/mapper/vg--ocfs2-lv--ocfs /mnt/ocfs2 ocfs2 _netdev,x-systemd.requires=o2cb.service 0 0
/dev/mapper/vg--gfs2-lv--gfs /mnt/gfs2 gfs2 _netdev,x-systemd.requires=dlm.service 0 0
--ココまで
書き終わったら、設定をsystemdに反映させる。
(cancer) $ sudo systemctl daemon-reload
反映が終わったら、マウント出来るか確認。
(cancer) $ df
(cancer) $ sudo systemctl start /mnt/ocfs2
(cancer) $ sudo systemctl start /mnt/gfs2
(cancer) $ df
マウント出来たのが確認できたら、一応OSを再起動して、再起動後に自動マウントされるか確認。
(cancer) $ sudo shutdown -r now
(cancer) $ df
これでオシマイかと思ったけど、ocfs2の領域がマウントされていない。
gemini側でアクティベートされているのが原因かと思い、色々試してみたんだが、ちょっと原因が不明。
一度、gemini側でアンマウント、ディアクティベート、アクティベート、マウント、の流れを行ったら、cancer側でも問題なくマウント出来るようになった。
もしかしたら、CLVM関連を操作していく過程で、情報の同期が上手く行かなかったのかもしれない。
(gemini) $ df
(gemini) $ sudo systemctl stop /mnt/ocfs2
(gemini) $ sudo vgchange -a n vg-ocfs2
(gemini) $ sudo vgchange -a y vg-ocfs2
(gemini) $ sudo systemctl stop /mnt/ocfs2
(gemini) $ df
本来なら、LVM→CLVM→ファイルシステムという順に作成(操作)していくのを、今回はVG→ファイルシステム→CLVMという順に操作していったため、何か不具合が生じたんじゃないかと。
気になるのなら、gemini/cancerともに停止して、完全停止後に両方を起動して、マウントされるか確認しておいた方がいいかな。
今後、色々実験していく中で、同じような症状が出るかもしれないが、その時にまた考えることにしよう。
2017年2月10日金曜日
ファイルシステムマウント変更(/etc/fstab変更)
前回までで、gfs2をマウントする流れが理解できて設定方法も分かった。
はずなんだけど、1つ漏れていた。
/etc/fstabを書き換えた後、OS再起動させずに反映させるにはどうすれば？だ。
/etc/fstabを書き換えてOS再起動させると、/run/systemd/generatorに反映される。
これをOS再起動させずに反映させる方法だ。
で、調べてみたら、systemd.generatorのマニュアルエントリ(man systemd.generator)に書いてあった。
ちゃんと読めよ…。
/etc/fstabを書き換えたら
$ sudo systemctl daemon-reload
だ。
これで/run/systemd/generatorに反映される。
ついでに、ファイルシステムのマウントも、
$ sudo systemctl start /mnt/gfs2
という具合に、マウントポイントを指定すればマウントしてくれる。
(アンマウントは systemctl stop だ)
なんだ、すげー簡単じゃん…。
ちなみに今回のocfs2/gfs2に対応する/etc/fstabエントリは以下だ。
--ココから
/dev/mapper/vg--ocfs2-lv--ocfs /mnt/ocfs2 ocfs2 _netdev,x-systemd.requires=o2cb.service 0 0
/dev/mapper/vg--gfs2-lv--gfs /mnt/gfs2 gfs2 _netdev,x-systemd.requires=dlm.service 0 0
--ココまで
この2行を/etc/fstabに追記した後、
(gemini) $ sudo systemctl daemon-reload
を実行
(gemini) $ ls -l /run/systemd/generator
でエントリが出来ている(mnt-gfs2.mount と mnt-ocfs2.mount)のを確認して
(gemini) $ sudo systemctl start /mnt/ocfs2
(gemini) $ sudo systemctl start /mnt/gfs2
でマウント、
(gemini) $ grep -e /mnt/ocfs2 -e /mnt/gfs2 /etc/mtab
でマウントされているのを確認。
これでOKだ。
(OS再起動後は自動でマウントされるはずだぞ。)
ファイルシステム関連はこれにてオシマイ。
次こそCLVMの調査だ。
--2017/04/14追記
fstabのエントリはnoautoを付与しておくようにした。
自動マウントされると、ちょっと不便だった。(ボリュームアクティベートが失敗しているのにマウントしようとしたり…)
--2017/04/14追記終了
はずなんだけど、1つ漏れていた。
/etc/fstabを書き換えた後、OS再起動させずに反映させるにはどうすれば？だ。
/etc/fstabを書き換えてOS再起動させると、/run/systemd/generatorに反映される。
これをOS再起動させずに反映させる方法だ。
で、調べてみたら、systemd.generatorのマニュアルエントリ(man systemd.generator)に書いてあった。
ちゃんと読めよ…。
/etc/fstabを書き換えたら
$ sudo systemctl daemon-reload
だ。
これで/run/systemd/generatorに反映される。
ついでに、ファイルシステムのマウントも、
$ sudo systemctl start /mnt/gfs2
という具合に、マウントポイントを指定すればマウントしてくれる。
(アンマウントは systemctl stop だ)
なんだ、すげー簡単じゃん…。
ちなみに今回のocfs2/gfs2に対応する/etc/fstabエントリは以下だ。
--ココから
/dev/mapper/vg--ocfs2-lv--ocfs /mnt/ocfs2 ocfs2 _netdev,x-systemd.requires=o2cb.service 0 0
/dev/mapper/vg--gfs2-lv--gfs /mnt/gfs2 gfs2 _netdev,x-systemd.requires=dlm.service 0 0
--ココまで
この2行を/etc/fstabに追記した後、
(gemini) $ sudo systemctl daemon-reload
を実行
(gemini) $ ls -l /run/systemd/generator
でエントリが出来ている(mnt-gfs2.mount と mnt-ocfs2.mount)のを確認して
(gemini) $ sudo systemctl start /mnt/ocfs2
(gemini) $ sudo systemctl start /mnt/gfs2
でマウント、
(gemini) $ grep -e /mnt/ocfs2 -e /mnt/gfs2 /etc/mtab
でマウントされているのを確認。
これでOKだ。
(OS再起動後は自動でマウントされるはずだぞ。)
ファイルシステム関連はこれにてオシマイ。
次こそCLVMの調査だ。
--2017/04/14追記
fstabのエントリはnoautoを付与しておくようにした。
自動マウントされると、ちょっと不便だった。(ボリュームアクティベートが失敗しているのにマウントしようとしたり…)
--2017/04/14追記終了
2017年2月9日木曜日
ocfs2アンマウントされず
ここまで検証して、一度OS(gemini/cancer)を再起動しようとしたんだけど…。
なんかocfs2の領域がアンマウントされずにシャットダウンされへんくなった…。
これはちょっと不便なので、後で確認しよう…。
(仮想マシン上に作っているので、仮想マシンを強制的に停止させればなんとかなる)
2017/02/10追記
勘違いだった。ocfs2がマウントされているのは問題ないようで、gfs2がマウントされているとシャットダウンが上手くいかない。
もう少し調べないと…。。
なんかocfs2の領域がアンマウントされずにシャットダウンされへんくなった…。
これはちょっと不便なので、後で確認しよう…。
(仮想マシン上に作っているので、仮想マシンを強制的に停止させればなんとかなる)
2017/02/10追記
勘違いだった。ocfs2がマウントされているのは問題ないようで、gfs2がマウントされているとシャットダウンが上手くいかない。
もう少し調べないと…。。
2017年2月4日土曜日
共有ファイルシステム(ocfs2)
さて、ocfs2を試してみよう。
まずは、パッケージの導入だ。
(gemini) $ sudo apt-get update
(gemini) $ apt-cache search ocfs2
どうやら、ocfs2-toolsというパッケージが該当のようだ。(他にも、ocfs2consoleというのがあるけど、これは何だろう？別途調べてみるか…GUIインターフェースのようだ。)
(gemini) $ sudo apt-get install ocfs2-tools
さて、どういったファイルが導入されたかな？
(gemini) $ dpkg -L ocfs2-tools
あれ？実行ファイルが導入されてないぞ？これでいいのか…？あ、見間違えた。
ユーザガイドがあるので読んでみる。
(gemini) $ zcat /usr/share/doc/ocfs2-tools/users_guide.txt.gz
ユーザガイドによると、/etc/ocfs2/cluster.confという設定ファイルを作る必要があるようだな。
サンプル(/usr/share/doc/ocfs2-tools/examples/cluster.conf)があるので、それを利用してもいいだろう。
設定ファイルを作る方法は、大きく3種類あるようだ。
/etc/ocfs2ディレクトリは自動作成されたようなので、それをそのまま使う。
(gemini) $ sudo cp -p /usr/share/doc/ocfs2-tools/examples/cluster.conf \
/etc/ocfs2/cluster.conf
(gemini) $ sudo vi /etc/ocfs2/cluster.conf
以下のような内容で作成する。
--ココから
node:
ip_port = 7777
ip_address = 192.168.55.136
number = 0
name = gemini
cluster = ocfs2
node:
ip_port = 7777
ip_address = 192.168.55.137
number = 1
name = cancer
cluster = ocfs2
cluster:
node_count = 2
name = ocfs2
--ココまで
全然難しくない。ホントにこれでいいのか…？
続いて、ocfs2ファイルシステムを作成する。
(gemini) $ sudo mkfs.ocfs2 /dev/vg-ocfs2/lv-ocfs
マウントポイントを作ってマウント
(gemini) $ sudo mkdir /mnt/ocfs2
(gemini) $ sudo mount -t ocfs2 /dev/vg-ocfs2/lv-ocfs /mnt/ocfs2
あれ？コケた。
クラスタサービスへのアクセスが出来ない、とな？
ocfs2サービスを再起動してみればいいのかな？
(gemini) $ sudo systemctl status ocfs2
(gemini) $ sudo systemctl restart ocfs2
(gemini) $ sudo systemctl status ocfs2
もう一度。
(gemini) $ sudo mount -t ocfs2 /dev/vg-ocfs2/lv-ocfs /mnt/ocfs2
ダメだ。
ってよく見てみたら「while trying initialize cluster」って書いてあるな…。
初期化処理が必要なのか。
どうやるんだろう？もう一度ユーザガイドを見てみよう。
(gemini) $ zcat /usr/share/doc/ocfs2-tools/users_guide.txt.gz
なんか、o2cbというサービスが関係しているようだ。
これを再起動してみる。
(gemini) $ sudo systemctl restart o2cb
(gemini) $ sudo systemctl status o2cb
う～ん。何か変わった、という感じはしないなぁ。
(gemini) $ sudo mount -t ocfs2 /dev/vg-ocfs2/lv-ocfs /mnt/ocfs2
変わらず…。
む？o2cbって、systemd配下じゃなくて、旧来のinit.d形式なのか。
ちょっと見てみよう。
(gemini) $ view /etc/init.d/o2cb
なんか、/etc/default/o2cbというファイルを見ているようだ。
このファイルに、O2CB_ENABLEDというフラグがある。
これ、デフォルトでは「false」になっているので、これを「true」に書き換えたらいいのか？
(gemini) $ sudo vi /etc/default/o2cb
O2CB_ENABLED=false を O2CB_ENABLED=true に書き換えて保存。
これでo2cbサービスを再起動してみる。
(gemini) $ sudo systemctl restart o2cb
(gemini) $ systemctl status o2cb
なんか動いたっぽいな…。
もう一度マウント
(gemini) $ sudo mount -t ocfs2 /dev/vg-ocfs2/lv-ocfs /mnt/ocfs2
ちょっと時間がかかったな…。マウント出来たかな？
(gemini) $ df /mnt/ocfs2
出来た。
ちょっと気になるので、syslogとかチェックしておこ…。
(gemini) $ dmesg | tail
(gemini) $ tail -30 /var/log/syslog
どうやらうまく行ってるっぽいな…。
じゃぁcancer側で同じように…。
(cancer) $ sudo apt-get update
(cancer) $ sudo apt-get install ocfs2-tools
(cancer) $ sudo vi /etc/ocfs2/cluster.conf
内容はgeminiで作成したものと同じだ。
(cancer) $ sudo mkdir /mnt/ocfs2
(cancer) $ sudo vi /etc/default/o2cb
変更内容はgeminiと同じ。
(cancer) $ sudo systemctl restart o2cb
(cancer) $ sudo mount -t ocfs2 /dev/vg-ocfs2/lv-ocfs /mnt/ocfs2
(cancer) $ df /mnt/ocfs2
ここまでは何とかなった。
ホントにこれでいいのかな？
とりあえずI/Oテスト。
(gemini) $ ls -ld /mnt/ocfs2
(gemini) $ sudo chmod 777 /mnt/ocfs2
(gemini) $ ls -ld /mnt/ocfs2
(cancer) $ ls -ld /mnt/ocfs2
(gemini) $ cp /etc/hosts /mnt/ocfs2/
(gemini) $ ls -l /mnt/ocfs2
(cancer) $ ls -l /mnt/ocfs2
両方から参照出来るみたいだな。
(gemini) $ cat /mnt/ocfs2/hosts
(cancer) $ cat /mnt/ocfs2/hosts
問題ないな。
(gemini) $ vi /mnt/ocfs2/hosts
(cancer) $ vi /mnt/ocfs2/hosts
後から実行したcancerの方が、「スワップファイルが既に存在しているよ」という警告が出た。
でもこれは、viによる排他制御だよな…。ocfs2による排他制御じゃないだろう。
いや、違うかな…？
というわけで、cancer側でまず強制的に開いて、geminiの方で更新して保存終了、cancer側でも更新保存してみるか。
お？別で更新されたことが報告された。
排他制御はうまくいっているようだな。
ただ、これがocfs2によるものか、viによるものかははっきりは分からないな。
次のテストだ。
(gemini) $ rm /mnt/ocfs2/hosts
(gemini) $ ls -l /mnt/ocfs2/hosts
(cancer) $ ls -l /mnt/ocfs2/hosts
(gemini) $ dd if=/dev/urandom of=/mnt/ocfs2/randomio bs=1M count=1024
(cancer) $ dd if=/dev/urandom of=/mnt/ocfs2/randomio bs=1M count=1024
う～ん。同時に書き込めてしまったな…。
サイズも1GBだ。
これが正しい挙動なのか…な？
もしかしたら、排他制御は上位レイヤー(アプリケーションレイヤー)で組み込む、ということなのかもしれない。ocfs2はあくまで、更新されたという情報を、各ノードに通知する、という仕組みだけなのかもな。
とりあえず、なんとなく実装出来たので、ocfs2についてはこれでオシマイ。
次回はgfs2について考えてみる。
まずは、パッケージの導入だ。
(gemini) $ sudo apt-get update
(gemini) $ apt-cache search ocfs2
どうやら、ocfs2-toolsというパッケージが該当のようだ。(他にも、ocfs2consoleというのがあるけど、これは何だろう？別途調べてみるか…GUIインターフェースのようだ。)
(gemini) $ sudo apt-get install ocfs2-tools
さて、どういったファイルが導入されたかな？
(gemini) $ dpkg -L ocfs2-tools
あれ？実行ファイルが導入されてないぞ？これでいいのか…？あ、見間違えた。
ユーザガイドがあるので読んでみる。
(gemini) $ zcat /usr/share/doc/ocfs2-tools/users_guide.txt.gz
ユーザガイドによると、/etc/ocfs2/cluster.confという設定ファイルを作る必要があるようだな。
サンプル(/usr/share/doc/ocfs2-tools/examples/cluster.conf)があるので、それを利用してもいいだろう。
設定ファイルを作る方法は、大きく3種類あるようだ。
- テキストエディタで直接編集
- ocfs2consoleのGUIインターフェースを使用
- o2cb_ctlコマンドを使用
/etc/ocfs2ディレクトリは自動作成されたようなので、それをそのまま使う。
(gemini) $ sudo cp -p /usr/share/doc/ocfs2-tools/examples/cluster.conf \
/etc/ocfs2/cluster.conf
(gemini) $ sudo vi /etc/ocfs2/cluster.conf
以下のような内容で作成する。
--ココから
node:
ip_port = 7777
ip_address = 192.168.55.136
number = 0
name = gemini
cluster = ocfs2
node:
ip_port = 7777
ip_address = 192.168.55.137
number = 1
name = cancer
cluster = ocfs2
cluster:
node_count = 2
name = ocfs2
--ココまで
全然難しくない。ホントにこれでいいのか…？
続いて、ocfs2ファイルシステムを作成する。
(gemini) $ sudo mkfs.ocfs2 /dev/vg-ocfs2/lv-ocfs
マウントポイントを作ってマウント
(gemini) $ sudo mkdir /mnt/ocfs2
(gemini) $ sudo mount -t ocfs2 /dev/vg-ocfs2/lv-ocfs /mnt/ocfs2
あれ？コケた。
クラスタサービスへのアクセスが出来ない、とな？
ocfs2サービスを再起動してみればいいのかな？
(gemini) $ sudo systemctl status ocfs2
(gemini) $ sudo systemctl restart ocfs2
(gemini) $ sudo systemctl status ocfs2
もう一度。
(gemini) $ sudo mount -t ocfs2 /dev/vg-ocfs2/lv-ocfs /mnt/ocfs2
ダメだ。
ってよく見てみたら「while trying initialize cluster」って書いてあるな…。
初期化処理が必要なのか。
どうやるんだろう？もう一度ユーザガイドを見てみよう。
(gemini) $ zcat /usr/share/doc/ocfs2-tools/users_guide.txt.gz
なんか、o2cbというサービスが関係しているようだ。
これを再起動してみる。
(gemini) $ sudo systemctl restart o2cb
(gemini) $ sudo systemctl status o2cb
う～ん。何か変わった、という感じはしないなぁ。
(gemini) $ sudo mount -t ocfs2 /dev/vg-ocfs2/lv-ocfs /mnt/ocfs2
変わらず…。
む？o2cbって、systemd配下じゃなくて、旧来のinit.d形式なのか。
ちょっと見てみよう。
(gemini) $ view /etc/init.d/o2cb
なんか、/etc/default/o2cbというファイルを見ているようだ。
このファイルに、O2CB_ENABLEDというフラグがある。
これ、デフォルトでは「false」になっているので、これを「true」に書き換えたらいいのか？
(gemini) $ sudo vi /etc/default/o2cb
O2CB_ENABLED=false を O2CB_ENABLED=true に書き換えて保存。
これでo2cbサービスを再起動してみる。
(gemini) $ sudo systemctl restart o2cb
(gemini) $ systemctl status o2cb
なんか動いたっぽいな…。
もう一度マウント
(gemini) $ sudo mount -t ocfs2 /dev/vg-ocfs2/lv-ocfs /mnt/ocfs2
ちょっと時間がかかったな…。マウント出来たかな？
(gemini) $ df /mnt/ocfs2
出来た。
ちょっと気になるので、syslogとかチェックしておこ…。
(gemini) $ dmesg | tail
(gemini) $ tail -30 /var/log/syslog
どうやらうまく行ってるっぽいな…。
じゃぁcancer側で同じように…。
(cancer) $ sudo apt-get update
(cancer) $ sudo apt-get install ocfs2-tools
(cancer) $ sudo vi /etc/ocfs2/cluster.conf
内容はgeminiで作成したものと同じだ。
(cancer) $ sudo mkdir /mnt/ocfs2
(cancer) $ sudo vi /etc/default/o2cb
変更内容はgeminiと同じ。
(cancer) $ sudo systemctl restart o2cb
(cancer) $ sudo mount -t ocfs2 /dev/vg-ocfs2/lv-ocfs /mnt/ocfs2
(cancer) $ df /mnt/ocfs2
ここまでは何とかなった。
ホントにこれでいいのかな？
とりあえずI/Oテスト。
(gemini) $ ls -ld /mnt/ocfs2
(gemini) $ sudo chmod 777 /mnt/ocfs2
(gemini) $ ls -ld /mnt/ocfs2
(cancer) $ ls -ld /mnt/ocfs2
(gemini) $ cp /etc/hosts /mnt/ocfs2/
(gemini) $ ls -l /mnt/ocfs2
(cancer) $ ls -l /mnt/ocfs2
両方から参照出来るみたいだな。
(gemini) $ cat /mnt/ocfs2/hosts
(cancer) $ cat /mnt/ocfs2/hosts
問題ないな。
(gemini) $ vi /mnt/ocfs2/hosts
(cancer) $ vi /mnt/ocfs2/hosts
後から実行したcancerの方が、「スワップファイルが既に存在しているよ」という警告が出た。
でもこれは、viによる排他制御だよな…。ocfs2による排他制御じゃないだろう。
いや、違うかな…？
というわけで、cancer側でまず強制的に開いて、geminiの方で更新して保存終了、cancer側でも更新保存してみるか。
お？別で更新されたことが報告された。
排他制御はうまくいっているようだな。
ただ、これがocfs2によるものか、viによるものかははっきりは分からないな。
次のテストだ。
(gemini) $ rm /mnt/ocfs2/hosts
(gemini) $ ls -l /mnt/ocfs2/hosts
(cancer) $ ls -l /mnt/ocfs2/hosts
(gemini) $ dd if=/dev/urandom of=/mnt/ocfs2/randomio bs=1M count=1024
(cancer) $ dd if=/dev/urandom of=/mnt/ocfs2/randomio bs=1M count=1024
う～ん。同時に書き込めてしまったな…。
サイズも1GBだ。
これが正しい挙動なのか…な？
もしかしたら、排他制御は上位レイヤー(アプリケーションレイヤー)で組み込む、ということなのかもしれない。ocfs2はあくまで、更新されたという情報を、各ノードに通知する、という仕組みだけなのかもな。
とりあえず、なんとなく実装出来たので、ocfs2についてはこれでオシマイ。
次回はgfs2について考えてみる。
共有ファイルシステム(基礎)
いくつも実験したい項目はあるけど、今回はその中でも結構ポイントが高い「共有ファイルシステム」だ。
単純に共有ボリュームだけなら、別にiSCSIのLUNを複数のノード(OS)に見せておいて、どちらかでマウント、他のノードはアンマウント、としておけばいい。
HAクラスタ等を組む時の基本だ。
これだと、あくまでそのLUNを使うのは1ノードのみ。複数のノードからのI/Oは出来ない。(やってみれば分かるけど、ファイルシステムが壊れる。)
これを、複数のノードからI/O出来るような仕組みにしてみたい。
実はこれ、単純にNFSやCIFSを使えば解決しちゃうんだけど、NFSやCIFSはお世辞にも速いファイルシステムではないし、ファイルサイズ等の制約も厳しかったりする。
で、実現方法だけど、どうやらOCFS2とGFS2の2つがあるらしい。(商用製品等、他にもたくさんあるのだが…)
で、これを試してみたい。
まずは基本。以下の作業を行う。
とりあえず、ここまで実施しておいた。
次回、ocfs2の環境を作ってみたい。
単純に共有ボリュームだけなら、別にiSCSIのLUNを複数のノード(OS)に見せておいて、どちらかでマウント、他のノードはアンマウント、としておけばいい。
HAクラスタ等を組む時の基本だ。
これだと、あくまでそのLUNを使うのは1ノードのみ。複数のノードからのI/Oは出来ない。(やってみれば分かるけど、ファイルシステムが壊れる。)
これを、複数のノードからI/O出来るような仕組みにしてみたい。
実はこれ、単純にNFSやCIFSを使えば解決しちゃうんだけど、NFSやCIFSはお世辞にも速いファイルシステムではないし、ファイルサイズ等の制約も厳しかったりする。
で、実現方法だけど、どうやらOCFS2とGFS2の2つがあるらしい。(商用製品等、他にもたくさんあるのだが…)
で、これを試してみたい。
まずは基本。以下の作業を行う。
- 2つの仮想マシンを作成し、それぞれUbuntu16.04を導入する。(今回はホスト名gemini/cancerにした。)
- 仮想ディスクをocfs2.qcow2という名前、10GBのサイズで1つ作成し、gemini/cancerに接続する。(警告が出るが、無視する。)
-----2017/04/04追記-----
こちらに書いたが、仮想ディスクをgemini/cancerに接続する時「共有可能」というチェックボックスにチェックを入れておかないと、ちょっと思った挙動を示さないようだ。
チェックを入れておくこと
-----2017/04/04追記終了----- - geminiから、新しいディスクに対して、partedパーティションの作成と、pv/vg/lvを作成する。(lvは1つでいいだろう。)
(gemini) $ sudo parted /dev/vdb print
(gemini) $ sudo parted /dev/vdb mklabel gpt
(gemini) $ sudo parted /dev/vdb print
(gemini) $ sudo parted /dev/vdb mkpart primary 0% 100%
(gemini) $ sudo parted /dev/vdb print
(gemini) $ sudo parted /dev/vdb set 1 lvm on
(gemini) $ sudo parted /dev/vdb print
(gemini) $ sudo pvcreate /dev/vdb1
(gemini) $ sudo vgcreate vg-ocfs2 /dev/vdb1
(gemini) $ sudo vgdisplay vg-ocfs2
(gemini) $ sudo lvcreate -L 5G -n lv-ocfs vg-ocfs2
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs - cancerからディスクの再認識と、lvmの再認識を行う。(ちょっとめんどくさいので、再起動する。）
(cancer) $ sudo shutdown -r now
(cancer) $ ls -l /dev/vd*
(cancer) $ sudo vgdisplay vg-ocfs2 - もう1つ仮想ディスク(gfs2.qcow2/10GB)を作成し、gemini/cancerに接続する。
- 先程と同様に、geminiからpartedパーティションの作成と、pv/vg/lvの作成を行う。
(gemini) $ sudo parted /dev/vdc print
(gemini) $ sudo parted /dev/vdc mklabel gpt
(gemini) $ sudo parted /dev/vdc print
(gemini) $ sudo parted /dev/vdc mkpart primary 0% 100%
(gemini) $ sudo parted /dev/vdc print
(gemini) $ sudo parted /dev/vdc set 1 lvm on
(gemini) $ sudo parted /dev/vdc print
(gemini) $ sudo pvcreate /dev/vdc1
(gemini) $ sudo vgcreate vg-gfs2 /dev/vdc1
(gemini) $ sudo vgdisplay vg-gfs2
(gemini) $ sudo lvcreate -L 5G -n lv-gfs vg-gfs2
(gemini) $ sudo lvdisplay vg-gfs2/lv-gfs - cancerからディスクの再認識と、lvmの再認識を行う。(こちらもめんどくさいので再起動しちゃおう)
(cancer) $ sudo shutdown -r now
(cancer) $ ls -l /dev/vd*
(cancer) $ sudo vgdisplay vg-gfs2
とりあえず、ここまで実施しておいた。
次回、ocfs2の環境を作ってみたい。
登録:
投稿 (Atom)