ここまで検証して、一度OS(gemini/cancer)を再起動しようとしたんだけど…。
なんかocfs2の領域がアンマウントされずにシャットダウンされへんくなった…。
これはちょっと不便なので、後で確認しよう…。
(仮想マシン上に作っているので、仮想マシンを強制的に停止させればなんとかなる)
2017/02/10追記
勘違いだった。ocfs2がマウントされているのは問題ないようで、gfs2がマウントされているとシャットダウンが上手くいかない。
もう少し調べないと…。。
2017年2月9日木曜日
共有ファイルシステム(corosync&dlm&gfs2その3)
さて、geminiの方は環境が整ったと思うので、それに合わせてcancerも設定しよう。
ファイルシステム作成等はgemini側で行っているので、cancerのみで実施すべき部分だけ書いておいた。
ほぼほぼ、geminiと同じ作業を行えばいい。
(cancer) $ sudo apt-get update
(cancer) $ sudo apt-get install gfs2-utils
(cancer) $ sudo tunegfs2 -l /dev/vg-gfs2/lv-gfs
(cancer) $ sudo mkdir /mnt/gfs2
(cancer) $ sudo apt-get update
(cancer) $ sudo apt-get install corosync
(cancer) $ sudo cp -pi /etc/corosync/corosync.conf \
/etc/corosync/corosync.conf.orig
(cancer) $ sudo vi /etc/corosync/corosync.conf
以下のように修正・追記していく。(geminiの時と同じだ)
totem {
cluster_name: debian
↓
cluster_name: mycluster
interface {
bindnetaddr: 127.0.0.1
↓
bindnetaddr: 192.168.55.0
}
}
(cancer) $ diff /etc/corosync/corosync.conf.orig \
/etc/corosync/corosync.conf
(cancer) $ systemctl status corosync
(cancer) $ sudo systemctl restart corosync
(cancer) $ systemctl status corosync
(cancer) $ sudo apt-get update
(cancer) $ sudo apt-get install dlm
(cancer) $ ls -l /dev/misc
あ…あれ…？geminiの時は/dev/miscができなかったのに、cancerの時は自動で作成された…。
OS再起動いらないな…。
(cancer) $ systemctl status dlm
(cancer) $ sudo mkdir /etc/dlm
(cancer) $ sudo bash -c "/usr/sbin/dlm_tool dump_config > /etc/dlm/dlm.conf"
(cancer) $ sudo vi /etc/dlm/dlm.conf
--以下の内容
enable_quorum_lockspace=1
↓この行を以下のように書き換え(geminiの時と同じ)
enable_quorum_lockspace=0
--ココまで
(cancer) $ sudo systemctl restart dlm
(cancer) $ sudo systemctl status dlm
(cancer) $ sudo mount -t gfs2 /dev/vg-gfs2/lv-gfs /mnt/gfs2
(cancer) $ df /mnt/gfs2
(cancer) $ grep gfs2 /etc/mtab
(cancer) $ dlm_tool ls -n
(cancer) $ dlm_tool status
(cancer) $ sudo touch /mnt/gfs2/test
(cancer) $ sudo bash -c "echo hogehoge >> /mnt/gfs2/test"
(cancer) $ sudo bash -c "echo fugafuga >> /mnt/gfs2/test"
(cancer) $ cat /mnt/gfs2/test
(cancer) $ sudo rm /mnt/gfs2/test
あっさり終了。
そしたら、ocfs2の時と同じテストを実施してみる。
(gemini) $ ls -ld /mnt/gfs2
(gemini) $ sudo chmod 777 /mnt/gfs2
(gemini) $ ls -ld /mnt/gfs2
(cancer) $ ls -ld /mnt/gfs2
(gemini) $ cp /etc/hosts /mnt/gfs2/
(gemini) $ ls -l /mnt/gfs2
(cancer) $ ls -l /mnt/gfs2
問題なく両方から参照出来る。
(gemini) $ cat /mnt/gfs2/hosts
(cancer) $ cat /mnt/gfs2/hosts
問題ない。
(gemini) $ vi /mnt/gfs2/hosts
(cancer) $ vi /mnt/gfs2/hosts
ocfs2の時と同じで、後から実行したcancerの方が、「スワップファイルが既に存在しているよ」という警告が出た。
というわけで、cancer側でまず強制的に開いて、geminiの方で更新して保存終了、cancer側でも更新保存してみる。
ocfs2の時とまったく同じ挙動。
次のテスト。
(gemini) $ rm /mnt/gfs2/hosts
(gemini) $ ls -l /mnt/gfs2/hosts
(cancer) $ ls -l /mnt/gfs2/hosts
(gemini) $ dd if=/dev/urandom of=/mnt/gfs2/randomio bs=1M count=1024
(cancer) $ dd if=/dev/urandom of=/mnt/gfs2/randomio bs=1M count=1024
あれ？ocfs2の時は、2ノード同時に始めて同時に終わったと思ったけど、今回のgfs2だとcancerの方が少し終わるの遅かったぞ？
何か違いがあるのかな？いや、何度かテストしてみたら、ほぼ同じタイミングで終わる。
やはり、ロックはflock等を使ってアプリケーションレイヤーで対応する、ということなのかもしれないな。
ちなみに、ocfs2とgfs2でどちらが速いのか？ってことで、簡単にI/O性能を測ってみたけど、ほとんど差が出なかった。
もっと厳密に計測すれば、それぞれの特徴が分かるんだろうけど…。
んで…。
実はocfs2にせよgfs2にせよ、ボリュームマネージャにLVMを用いるのなら、LVMもクラスタ対応のCLVMを使用するべきだった。
次回はCLVMに挑戦してみるよー。
ファイルシステム作成等はgemini側で行っているので、cancerのみで実施すべき部分だけ書いておいた。
ほぼほぼ、geminiと同じ作業を行えばいい。
(cancer) $ sudo apt-get update
(cancer) $ sudo apt-get install gfs2-utils
(cancer) $ sudo tunegfs2 -l /dev/vg-gfs2/lv-gfs
(cancer) $ sudo mkdir /mnt/gfs2
(cancer) $ sudo apt-get update
(cancer) $ sudo apt-get install corosync
(cancer) $ sudo cp -pi /etc/corosync/corosync.conf \
/etc/corosync/corosync.conf.orig
(cancer) $ sudo vi /etc/corosync/corosync.conf
以下のように修正・追記していく。(geminiの時と同じだ)
totem {
cluster_name: debian
↓
cluster_name: mycluster
interface {
bindnetaddr: 127.0.0.1
↓
bindnetaddr: 192.168.55.0
}
}
(cancer) $ diff /etc/corosync/corosync.conf.orig \
/etc/corosync/corosync.conf
(cancer) $ systemctl status corosync
(cancer) $ sudo systemctl restart corosync
(cancer) $ systemctl status corosync
(cancer) $ sudo apt-get update
(cancer) $ sudo apt-get install dlm
(cancer) $ ls -l /dev/misc
あ…あれ…？geminiの時は/dev/miscができなかったのに、cancerの時は自動で作成された…。
OS再起動いらないな…。
(cancer) $ systemctl status dlm
(cancer) $ sudo mkdir /etc/dlm
(cancer) $ sudo bash -c "/usr/sbin/dlm_tool dump_config > /etc/dlm/dlm.conf"
(cancer) $ sudo vi /etc/dlm/dlm.conf
--以下の内容
enable_quorum_lockspace=1
↓この行を以下のように書き換え(geminiの時と同じ)
enable_quorum_lockspace=0
--ココまで
(cancer) $ sudo systemctl restart dlm
(cancer) $ sudo systemctl status dlm
(cancer) $ sudo mount -t gfs2 /dev/vg-gfs2/lv-gfs /mnt/gfs2
(cancer) $ df /mnt/gfs2
(cancer) $ grep gfs2 /etc/mtab
(cancer) $ dlm_tool ls -n
(cancer) $ dlm_tool status
(cancer) $ sudo touch /mnt/gfs2/test
(cancer) $ sudo bash -c "echo hogehoge >> /mnt/gfs2/test"
(cancer) $ sudo bash -c "echo fugafuga >> /mnt/gfs2/test"
(cancer) $ cat /mnt/gfs2/test
(cancer) $ sudo rm /mnt/gfs2/test
あっさり終了。
そしたら、ocfs2の時と同じテストを実施してみる。
(gemini) $ ls -ld /mnt/gfs2
(gemini) $ sudo chmod 777 /mnt/gfs2
(gemini) $ ls -ld /mnt/gfs2
(cancer) $ ls -ld /mnt/gfs2
(gemini) $ cp /etc/hosts /mnt/gfs2/
(gemini) $ ls -l /mnt/gfs2
(cancer) $ ls -l /mnt/gfs2
問題なく両方から参照出来る。
(gemini) $ cat /mnt/gfs2/hosts
(cancer) $ cat /mnt/gfs2/hosts
問題ない。
(gemini) $ vi /mnt/gfs2/hosts
(cancer) $ vi /mnt/gfs2/hosts
ocfs2の時と同じで、後から実行したcancerの方が、「スワップファイルが既に存在しているよ」という警告が出た。
というわけで、cancer側でまず強制的に開いて、geminiの方で更新して保存終了、cancer側でも更新保存してみる。
ocfs2の時とまったく同じ挙動。
次のテスト。
(gemini) $ rm /mnt/gfs2/hosts
(gemini) $ ls -l /mnt/gfs2/hosts
(cancer) $ ls -l /mnt/gfs2/hosts
(gemini) $ dd if=/dev/urandom of=/mnt/gfs2/randomio bs=1M count=1024
(cancer) $ dd if=/dev/urandom of=/mnt/gfs2/randomio bs=1M count=1024
あれ？ocfs2の時は、2ノード同時に始めて同時に終わったと思ったけど、今回のgfs2だとcancerの方が少し終わるの遅かったぞ？
何か違いがあるのかな？いや、何度かテストしてみたら、ほぼ同じタイミングで終わる。
やはり、ロックはflock等を使ってアプリケーションレイヤーで対応する、ということなのかもしれないな。
ちなみに、ocfs2とgfs2でどちらが速いのか？ってことで、簡単にI/O性能を測ってみたけど、ほとんど差が出なかった。
もっと厳密に計測すれば、それぞれの特徴が分かるんだろうけど…。
んで…。
実はocfs2にせよgfs2にせよ、ボリュームマネージャにLVMを用いるのなら、LVMもクラスタ対応のCLVMを使用するべきだった。
次回はCLVMに挑戦してみるよー。
共有ファイルシステム(corosync&dlm&gfs2その2)
というわけで、corosyncとdlmの2つを導入してみよう。
gfs2のマニュアルを見ると、corosyncをセットアップ後にdlmをセットアップする流れになっている。
というわけで、corosyncの導入から実施する。
(gemini) $ sudo apt-get update
(gemini) $ sudo apt-get --simulate install corosync
(gemini) $ sudo apt-get install corosync
そしたら、corosyncで導入されたファイル一覧を見てみる。
(gemini) $ dpkg -L corosync
/etc/corosync/corosync.conf というファイルが作られてるな。これを参考に設定ファイルを作ればいいだろう。
と思って/etc/corosync/corosync.confを見てみたが、結構色々な設定が入っている。
各種パラメータの意味を把握するのは必要に応じて実施するとして、とりあえず最低限の設定だけ入れてみる。
(gemini) $ sudo cp -pi /etc/corosync/corosync.conf \
/etc/corosync/corosync.conf.orig
(gemini) $ sudo vi /etc/corosync/corosync.conf
以下のように修正・追記していく。
totem {
cluster_name: debian
↓
cluster_name: mycluster
interface {
bindnetaddr: 127.0.0.1
↓
bindnetaddr: 192.168.55.0
}
}
差分確認しておこう。
(gemini) $ diff /etc/corosync/corosync.conf.orig \
/etc/corosync/corosync.conf
gfs2ファイルシステムを作成する時のオプション-tに用いたラベルのうち、前半分(前回の例だと-t mycluster:mygfs2のmycluster部分)と、corosync.confのcluster_nameは合わせる必要がある。
修正したところ以外が変更されてたりしないことを確認したら、corosyncの状態を確認して起動する。
(gemini) $ systemctl status corosync
(gemini) $ sudo systemctl restart corosync
(gemini) $ systemctl status corosync
これで良いのだろうか…。
続いて、dlmをセットアップする。
corosyncと同様に、導入するところからだ。
(gemini) $ sudo apt-get update
(gemini) $ sudo apt-get --simulate install dlm
(gemini) $ sudo apt-get install dlm
む？dlmインストール時の自動セットアップでfailedになったな。
ちょっと確認してみるか。
(gemini) $ journalctl -xe
(gemini) $ systemctl -l status dlm.service
(gemini) $ systemctl -o verbose dlm.service
う～ん。/dev/misc/dlm-control とかいうデバイスファイルが無い、という理由でコケてるみたいだな…。
いやマテ…。/dev/dlm-controlというデバイスファイルは出来上がってるぞ…。
なぜ、/dev/miscという存在しないディレクトリを見に行っているんだ？
まさかと思うが…一旦再起動してみよう。
(gemini) $ sudo shutdown -r now
(gemini) $ systemctl status
え？正常になってるぞ…？
(gemini) $ systemctl status dlm
あれ？やっぱり動いている。
まさか…
(gemini) $ ls -l /dev/misc
ぐはっ、ディレクトリも出来てて、シンボリックリンクも出来てる。
OS再起動が必要だったか…。(/dev 関係だから再起動した方がいいのだろうけど、エントリ追加ぐらいオンラインで出来るはずだよな…)
気を取り直して、とりあえずdlmパッケージにてインストールされたファイルは…と。
(gemini) $ dpkg -L dlm
設定ファイルの類や、サンプルファイルは無いな…。
と言っても、dlm.confのmanは存在している。これを見る限り、やっぱり/etc/dlm/dlm.confというファイルを作らないといけないようだな。
ファイルの内容はdlm.conのmanを見てもイマイチ分からない。
どうやら、現在の設定内容を出力するコマンドがあるらしい。それを使って設定ファイルのテンプレートを作ってみる。
(gemini) $ sudo mkdir /etc/dlm
(gemini) $ sudo bash -c "/usr/sbin/dlm_tool dump_config > /etc/dlm/dlm.conf"
(gemini) $ cat /etc/dlm/dlm.conf
--以下の内容になっていた
daemon_debug=0
foreground=1
log_debug=0
timewarn=0
protocol=detect
debug_logfile=0
enable_fscontrol=0
enable_plock=1
plock_debug=0
plock_rate_limit=0
plock_ownership=0
drop_resources_time=10000
drop_resources_count=10
drop_resources_age=10000
post_join_delay=30
enable_fencing=0
enable_concurrent_fencing=0
enable_startup_fencing=1
enable_quorum_fencing=1
enable_quorum_lockspace=1
help=-1
version=-1
--ココまで
各パラメータの詳細はヨクワカラン。
ただ、lockspaceのところとかはちょっと書き換えておく。
(gemini) $ sudo vi /etc/dlm/dlm.conf
--以下の内容
enable_quorum_lockspace=1
↓この行を以下のように書き換え
enable_quorum_lockspace=0
--ココまで
書けたら、dlmを再起動してみる。
(gemini) $ sudo systemctl restart dlm
(gemini) $ sudo systemctl status dlm
なんかsyslogにたくさん出てくる…。quorumがどうとか…。
数十秒で止まったけど…。後日調査だな。
では今度こそマウント。
(gemini) $ sudo mount -t gfs2 /dev/vg-gfs2/lv-gfs /mnt/gfs2
(gemini) $ df /mnt/gfs2
(gemini) $ grep gfs2 /etc/mtab
マウント出来た。
dlm_toolコマンドで確認してみよう。
(gemini) $ dlm_tool ls
(gemini) $ dlm_tool status
動いてるっぽいな…。
I/O確認もしておこう。
(gemini) $ sudo touch /mnt/gfs2/test
(gemini) $ sudo bash -c "echo hogehoge >> /mnt/gfs2/test"
(gemini) $ sudo bash -c "echo fugafuga >> /mnt/gfs2/test"
(gemini) $ cat /mnt/gfs2/test
(gemini) $ sudo rm /mnt/gfs2/test
問題なさそうだ。
ちなみに、前回書いた dlm_jadd コマンドは、ジャーナルを1つ追加してしまい、元に戻すことが出来ないようなので、当該ファイルシステムをマウントするホストが増えたら実施するようにしよう。
(Ubuntuで、gfs2ファイルシステムのジャーナル数を確認する方法が分からない…)
とりあえず、geminiでgfs2を作成、マウントすることは出来た。
次回はcancerで同じgfs2をマウント、両ノードでの書き込みテストをしてみる。
gfs2のマニュアルを見ると、corosyncをセットアップ後にdlmをセットアップする流れになっている。
というわけで、corosyncの導入から実施する。
(gemini) $ sudo apt-get update
(gemini) $ sudo apt-get --simulate install corosync
(gemini) $ sudo apt-get install corosync
そしたら、corosyncで導入されたファイル一覧を見てみる。
(gemini) $ dpkg -L corosync
/etc/corosync/corosync.conf というファイルが作られてるな。これを参考に設定ファイルを作ればいいだろう。
と思って/etc/corosync/corosync.confを見てみたが、結構色々な設定が入っている。
各種パラメータの意味を把握するのは必要に応じて実施するとして、とりあえず最低限の設定だけ入れてみる。
(gemini) $ sudo cp -pi /etc/corosync/corosync.conf \
/etc/corosync/corosync.conf.orig
(gemini) $ sudo vi /etc/corosync/corosync.conf
以下のように修正・追記していく。
totem {
cluster_name: debian
↓
cluster_name: mycluster
interface {
bindnetaddr: 127.0.0.1
↓
bindnetaddr: 192.168.55.0
}
}
差分確認しておこう。
(gemini) $ diff /etc/corosync/corosync.conf.orig \
/etc/corosync/corosync.conf
gfs2ファイルシステムを作成する時のオプション-tに用いたラベルのうち、前半分(前回の例だと-t mycluster:mygfs2のmycluster部分)と、corosync.confのcluster_nameは合わせる必要がある。
修正したところ以外が変更されてたりしないことを確認したら、corosyncの状態を確認して起動する。
(gemini) $ systemctl status corosync
(gemini) $ sudo systemctl restart corosync
(gemini) $ systemctl status corosync
これで良いのだろうか…。
続いて、dlmをセットアップする。
corosyncと同様に、導入するところからだ。
(gemini) $ sudo apt-get update
(gemini) $ sudo apt-get --simulate install dlm
(gemini) $ sudo apt-get install dlm
む？dlmインストール時の自動セットアップでfailedになったな。
ちょっと確認してみるか。
(gemini) $ journalctl -xe
(gemini) $ systemctl -l status dlm.service
う～ん。/dev/misc/dlm-control とかいうデバイスファイルが無い、という理由でコケてるみたいだな…。
いやマテ…。/dev/dlm-controlというデバイスファイルは出来上がってるぞ…。
なぜ、/dev/miscという存在しないディレクトリを見に行っているんだ？
まさかと思うが…一旦再起動してみよう。
(gemini) $ sudo shutdown -r now
(gemini) $ systemctl status
え？正常になってるぞ…？
(gemini) $ systemctl status dlm
あれ？やっぱり動いている。
まさか…
(gemini) $ ls -l /dev/misc
ぐはっ、ディレクトリも出来てて、シンボリックリンクも出来てる。
OS再起動が必要だったか…。(/dev 関係だから再起動した方がいいのだろうけど、エントリ追加ぐらいオンラインで出来るはずだよな…)
気を取り直して、とりあえずdlmパッケージにてインストールされたファイルは…と。
(gemini) $ dpkg -L dlm
設定ファイルの類や、サンプルファイルは無いな…。
と言っても、dlm.confのmanは存在している。これを見る限り、やっぱり/etc/dlm/dlm.confというファイルを作らないといけないようだな。
ファイルの内容はdlm.conのmanを見てもイマイチ分からない。
どうやら、現在の設定内容を出力するコマンドがあるらしい。それを使って設定ファイルのテンプレートを作ってみる。
(gemini) $ sudo mkdir /etc/dlm
(gemini) $ sudo bash -c "/usr/sbin/dlm_tool dump_config > /etc/dlm/dlm.conf"
(gemini) $ cat /etc/dlm/dlm.conf
--以下の内容になっていた
daemon_debug=0
foreground=1
log_debug=0
timewarn=0
protocol=detect
debug_logfile=0
enable_fscontrol=0
enable_plock=1
plock_debug=0
plock_rate_limit=0
plock_ownership=0
drop_resources_time=10000
drop_resources_count=10
drop_resources_age=10000
post_join_delay=30
enable_fencing=0
enable_concurrent_fencing=0
enable_startup_fencing=1
enable_quorum_fencing=1
enable_quorum_lockspace=1
help=-1
version=-1
--ココまで
各パラメータの詳細はヨクワカラン。
ただ、lockspaceのところとかはちょっと書き換えておく。
(gemini) $ sudo vi /etc/dlm/dlm.conf
--以下の内容
enable_quorum_lockspace=1
↓この行を以下のように書き換え
enable_quorum_lockspace=0
--ココまで
書けたら、dlmを再起動してみる。
(gemini) $ sudo systemctl restart dlm
(gemini) $ sudo systemctl status dlm
なんかsyslogにたくさん出てくる…。quorumがどうとか…。
数十秒で止まったけど…。後日調査だな。
では今度こそマウント。
(gemini) $ sudo mount -t gfs2 /dev/vg-gfs2/lv-gfs /mnt/gfs2
(gemini) $ df /mnt/gfs2
(gemini) $ grep gfs2 /etc/mtab
マウント出来た。
dlm_toolコマンドで確認してみよう。
(gemini) $ dlm_tool ls
(gemini) $ dlm_tool status
動いてるっぽいな…。
I/O確認もしておこう。
(gemini) $ sudo touch /mnt/gfs2/test
(gemini) $ sudo bash -c "echo hogehoge >> /mnt/gfs2/test"
(gemini) $ sudo bash -c "echo fugafuga >> /mnt/gfs2/test"
(gemini) $ cat /mnt/gfs2/test
(gemini) $ sudo rm /mnt/gfs2/test
問題なさそうだ。
ちなみに、前回書いた dlm_jadd コマンドは、ジャーナルを1つ追加してしまい、元に戻すことが出来ないようなので、当該ファイルシステムをマウントするホストが増えたら実施するようにしよう。
(Ubuntuで、gfs2ファイルシステムのジャーナル数を確認する方法が分からない…)
とりあえず、geminiでgfs2を作成、マウントすることは出来た。
次回はcancerで同じgfs2をマウント、両ノードでの書き込みテストをしてみる。
2017年2月8日水曜日
共有ファイルシステム(corosync&dlm&gfs2その1)
今度はgfs2だ。
こちらも初めて手を出すので、うまく動かせるか分からない。
とは言え、やってみなきゃ分からないので、ガシガシやってみる。
まずはパッケージの確認だ。
(gemini) $ sudo apt-get update
(gemini) $ apt-cache search gfs2
gfs2-utilsってのが該当っぽいな。
ではインストールしてみる。
(gemini) $ sudo apt-get install gfs2-utils
どんなファイルが入ったかな？
(gemini) $ dpkg -L gfs2-utils
あまりドキュメントは無い、というより、manに詳しく書いてあるみたいだ。
(gemini) $ man gfs2
色々複雑そうだ…。
とりあえずファイルシステムを作ってみる。
(gemini) $ sudo mkfs.gfs2 /dev/vg-gfs2/lv-gfs
おっと、オプションが足りないって怒られたわ。
manを見てみたらサンプルが載ってた。ちょっとサンプルに従ってみるか。
(gemini) $ sudo mkfs.gfs2 -t mycluster:mygfs2 \
-p lock_dlm \
-j 2 \
/dev/vg-gfs2/lv-gfs
おや？「シンボリックリンクだけどええか？」って聞かれた。今までファイルシステム作る時、そんなこと聞かれたことなかったが…。まぁ素直にyと答えておこう。どうせ実験環境だし。
ちょっと時間がかかった(10秒程度？)が、無事に出来たようだ。
デバイス名やUUID、Lock table等のパラメータが表示されたな。
これ、後から確認すること出来るんだろうか？
なんか、tunegfs2というコマンドがあるぞ…。これ、もしかしてext2系ファイルシステムで用いるtune2fsのgfs2版か？
(gemini) $ sudo tunegfs2 -l /dev/vg-gfs2/lv-gfs
う～ん。ファイルシステム構築時に表示されたパラメータのうち、Device / Device size / Filesystem size / Journals / Resource groups は表示されず、Block size / Lock protocol / Lock table は表示された…。
それ以外にも、Block shift や Root inodeが表示されたけど、あまり意識しなくて良さそうだ。
とは言え、後から Journals が確認できないのはちょっと面倒かもしれない。
他にオプションやコマンドは無いかな…？
なんか、gfs2_jaddというコマンドが使えそうだけど、これはマウントしているファイルシステムでないと見られないっぽいな…。
マウントしてみるか。
(gemini) $ sudo mkdir /mnt/gfs2
(gemini) $ sudo mount -t gfs2 /dev/vg-gfs2/lv-gfs /mnt/gfs2
ダメだ。
man gfs2をよく読んだら、gfs2によるクラスタリング(共有ファイルシステム)はdlmの機構が必要だとのこと。んで、corosyncによってメッセージング(多分、更新情報等のやり取り)されるので、corosyncのセットアップが必要らしい。
だったらなんで、gfs2を導入する時に、前提パッケージとしてdlmやらcorosyncが指定されてないんだろう？と思ったけど、gfs2はクラスタ環境ではなく、スタンドアロン環境でも利用可能だから、か。
ということで、今回はちょっと止めて、dlmやらcorosyncやらを調べていくことにする。
こちらも初めて手を出すので、うまく動かせるか分からない。
とは言え、やってみなきゃ分からないので、ガシガシやってみる。
まずはパッケージの確認だ。
(gemini) $ sudo apt-get update
(gemini) $ apt-cache search gfs2
gfs2-utilsってのが該当っぽいな。
ではインストールしてみる。
(gemini) $ sudo apt-get install gfs2-utils
どんなファイルが入ったかな？
(gemini) $ dpkg -L gfs2-utils
あまりドキュメントは無い、というより、manに詳しく書いてあるみたいだ。
(gemini) $ man gfs2
色々複雑そうだ…。
とりあえずファイルシステムを作ってみる。
(gemini) $ sudo mkfs.gfs2 /dev/vg-gfs2/lv-gfs
おっと、オプションが足りないって怒られたわ。
manを見てみたらサンプルが載ってた。ちょっとサンプルに従ってみるか。
(gemini) $ sudo mkfs.gfs2 -t mycluster:mygfs2 \
-p lock_dlm \
-j 2 \
/dev/vg-gfs2/lv-gfs
おや？「シンボリックリンクだけどええか？」って聞かれた。今までファイルシステム作る時、そんなこと聞かれたことなかったが…。まぁ素直にyと答えておこう。どうせ実験環境だし。
ちょっと時間がかかった(10秒程度？)が、無事に出来たようだ。
デバイス名やUUID、Lock table等のパラメータが表示されたな。
これ、後から確認すること出来るんだろうか？
なんか、tunegfs2というコマンドがあるぞ…。これ、もしかしてext2系ファイルシステムで用いるtune2fsのgfs2版か？
(gemini) $ sudo tunegfs2 -l /dev/vg-gfs2/lv-gfs
う～ん。ファイルシステム構築時に表示されたパラメータのうち、Device / Device size / Filesystem size / Journals / Resource groups は表示されず、Block size / Lock protocol / Lock table は表示された…。
それ以外にも、Block shift や Root inodeが表示されたけど、あまり意識しなくて良さそうだ。
とは言え、後から Journals が確認できないのはちょっと面倒かもしれない。
他にオプションやコマンドは無いかな…？
なんか、gfs2_jaddというコマンドが使えそうだけど、これはマウントしているファイルシステムでないと見られないっぽいな…。
マウントしてみるか。
(gemini) $ sudo mkdir /mnt/gfs2
(gemini) $ sudo mount -t gfs2 /dev/vg-gfs2/lv-gfs /mnt/gfs2
ダメだ。
man gfs2をよく読んだら、gfs2によるクラスタリング(共有ファイルシステム)はdlmの機構が必要だとのこと。んで、corosyncによってメッセージング(多分、更新情報等のやり取り)されるので、corosyncのセットアップが必要らしい。
だったらなんで、gfs2を導入する時に、前提パッケージとしてdlmやらcorosyncが指定されてないんだろう？と思ったけど、gfs2はクラスタ環境ではなく、スタンドアロン環境でも利用可能だから、か。
ということで、今回はちょっと止めて、dlmやらcorosyncやらを調べていくことにする。
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の環境を作ってみたい。
スナップショットを使おう その5(内部スナップショットの破棄-停止状態)
というわけで、スナップショットの破棄のパターンをテストしてみる。
これまで色々いじってきた内容と基本的には被るわけだが、整理だと思ってくれい。
とりあえず、内部スナップショット-停止状態のパターンを書く。
piscesが稼動していたら停止させよう
(aquarius) $ virsh list --all
内部スナップショットの作成だ。(piscesにスナップショットが無いことが前提だ。)
(aquarius) $ virsh snapshot-list pisces
(aquarius) $ virsh snapshot-create-as \
--domain pisces \
--name pisces-1.....
(aquarius) $ virsh snapshot-list pisces
piscesを起動させよう。
(aquarius) $ virsh start pisces
(aquarius) $ virsh list --all
仮想ディスクの状態の確認
(aquarius) $ sudo qemu-img info /var/lib/libvirt/images/pisces.qcow2
piscesにダミーファイルを作成してみる。
(pisces) $ touch 1
(pisces) $ ls -l 1
piscesのスナップショットを削除する。
(aquarius) $ virsh snapshot-delete --domain pisces pisces-1
(aquarius) $ virsh list --all
停止した状態でスナップショットを作成したので、停止した状態に戻るかと思ったんだが、起動したままになっている。
スナップショットの状態を確認
(aquarius) $ virsh snapshot-list pisces
スナップショットは削除されている。
piscesのファイルの状態は？
(pisces) $ ls -l 1
スナップショット作成後に作成したファイル、残っている。
ということは、この手順は、スナップショットは消えるが、スナップショットに対して行った作業は、ベースのディスクに反映されるってことか。
手順間違えた。もう一度実施だ。
まずは、pisces上のごみファイル(1)を削除する。
(pisces) $ rm 1
(pisces) $ ls -l
piscesはシャットダウンしておく。
(pisces) $ sudo shutdown -h now
(aquarius) $ virsh list --all
もう一度、内部スナップショットを作成する。(piscesにスナップショットが無いことが前提だ。)
(aquarius) $ virsh snapshot-list pisces
(aquarius) $ virsh snapshot-create-as \
--domain pisces \
--name pisces-1
(aquarius) $ virsh snapshot-list pisces
piscesを起動させよう。
(aquarius) $ virsh start pisces
(aquarius) $ virsh list --all
仮想ディスクの状態の確認
(aquarius) $ sudo qemu-img info /var/lib/libvirt/images/pisces.qcow2
piscesにダミーファイルを作成してみる。
(pisces) $ touch 1
(pisces) $ ls -l 1
piscesをスナップショットまで戻してみる。
(aquarius) $ virsh snapshot-revert --domain pisces pisces-1
(aquarius) $ virsh list --all
この時点で、piscesは停止する。(もともと停止状態で取得したスナップショットに戻ったわけだから、正常な挙動だ。)
スナップショットの確認
(aquarius) $ virsh snapshot-list pisces
(aquarius) $ sudo qemu-img info /var/lib/libvirt/images/pisces.qcow2
スナップショットは残っている。
この状態でスナップショットを削除する。
(aquarius) $ virsh snapshot-delete --domain pisces pisces-1
(aquarius) $ virsh snapshot-list pisces
(aquarius) $ sudo qemu-img info /var/lib/libvirt/images/pisces.qcow2
スナップショットは削除された。
本当に元に戻ったか、piscesを起動して確認だ。
(aquarius) $ virsh start pisces
(pisces) $ ls -l 1
ファイルが存在していない。スナップショット取得前に戻った状態だ。
これで、
次は、同様のパターンで「起動状態でスナップショットを取得する」の手順の確立を実施してみたい。
と、途中まで書いていたが、ちょっとスナップショット関連は停止。
まだまだ色々やりたいことがあるので、色んなことやってく過程で、またスナップショットは記載する。
これまで色々いじってきた内容と基本的には被るわけだが、整理だと思ってくれい。
とりあえず、内部スナップショット-停止状態のパターンを書く。
piscesが稼動していたら停止させよう
(aquarius) $ virsh list --all
内部スナップショットの作成だ。(piscesにスナップショットが無いことが前提だ。)
(aquarius) $ virsh snapshot-list pisces
(aquarius) $ virsh snapshot-create-as \
--domain pisces \
--name pisces-1.....
(aquarius) $ virsh snapshot-list pisces
piscesを起動させよう。
(aquarius) $ virsh start pisces
(aquarius) $ virsh list --all
仮想ディスクの状態の確認
(aquarius) $ sudo qemu-img info /var/lib/libvirt/images/pisces.qcow2
piscesにダミーファイルを作成してみる。
(pisces) $ touch 1
(pisces) $ ls -l 1
piscesのスナップショットを削除する。
(aquarius) $ virsh snapshot-delete --domain pisces pisces-1
(aquarius) $ virsh list --all
停止した状態でスナップショットを作成したので、停止した状態に戻るかと思ったんだが、起動したままになっている。
スナップショットの状態を確認
(aquarius) $ virsh snapshot-list pisces
スナップショットは削除されている。
piscesのファイルの状態は？
(pisces) $ ls -l 1
スナップショット作成後に作成したファイル、残っている。
ということは、この手順は、スナップショットは消えるが、スナップショットに対して行った作業は、ベースのディスクに反映されるってことか。
手順間違えた。もう一度実施だ。
まずは、pisces上のごみファイル(1)を削除する。
(pisces) $ rm 1
(pisces) $ ls -l
piscesはシャットダウンしておく。
(pisces) $ sudo shutdown -h now
(aquarius) $ virsh list --all
もう一度、内部スナップショットを作成する。(piscesにスナップショットが無いことが前提だ。)
(aquarius) $ virsh snapshot-list pisces
(aquarius) $ virsh snapshot-create-as \
--domain pisces \
--name pisces-1
(aquarius) $ virsh snapshot-list pisces
piscesを起動させよう。
(aquarius) $ virsh start pisces
(aquarius) $ virsh list --all
仮想ディスクの状態の確認
(aquarius) $ sudo qemu-img info /var/lib/libvirt/images/pisces.qcow2
piscesにダミーファイルを作成してみる。
(pisces) $ touch 1
(pisces) $ ls -l 1
piscesをスナップショットまで戻してみる。
(aquarius) $ virsh snapshot-revert --domain pisces pisces-1
(aquarius) $ virsh list --all
この時点で、piscesは停止する。(もともと停止状態で取得したスナップショットに戻ったわけだから、正常な挙動だ。)
スナップショットの確認
(aquarius) $ virsh snapshot-list pisces
(aquarius) $ sudo qemu-img info /var/lib/libvirt/images/pisces.qcow2
スナップショットは残っている。
この状態でスナップショットを削除する。
(aquarius) $ virsh snapshot-delete --domain pisces pisces-1
(aquarius) $ virsh snapshot-list pisces
(aquarius) $ sudo qemu-img info /var/lib/libvirt/images/pisces.qcow2
スナップショットは削除された。
本当に元に戻ったか、piscesを起動して確認だ。
(aquarius) $ virsh start pisces
(pisces) $ ls -l 1
ファイルが存在していない。スナップショット取得前に戻った状態だ。
これで、
- スナップショットを破棄する。(スナップショット取得前に戻す。)
- スナップショットは停止状態で取得する。
- スナップショット形式は「内部スナップショット」。
次は、同様のパターンで「起動状態でスナップショットを取得する」の手順の確立を実施してみたい。
と、途中まで書いていたが、ちょっとスナップショット関連は停止。
まだまだ色々やりたいことがあるので、色んなことやってく過程で、またスナップショットは記載する。
登録:
投稿 (Atom)