2017年4月19日水曜日

ちょっとマテよ…(clvmd)

なんてこったい。
clvmパッケージはいくつかのファイルが含まれているけど、起動に関するファイルは主に以下の3つ。
  • /etc/init.d/clvm
  • /lib/systemd/system/lvm2-clvmd.service
  • /lib/systemd/system/lvm2-cluster-activation.service
1つ目が旧来のsysVinitで使用するファイル。残りの2つがsystemdにて使用されるファイルだ。
ただ、1つ目もsystemdによって自動的に読み込まれる。
ただし、毎回起動に失敗している様子だった。

で、中身を読んでみたら…
/etc/init.d/clvm は /usr/sbin/clvmd を起動し、その後にクラスタLVMのアクティベートを行う。
対して /lib/systemd/system/lvm2-clvmd.service が clvmd の起動、
/lib/systemd/system/lvm2-cluster-activation.service が /lib/systemd/lvm2-cluster-activationを起動し、クラスタVGをアクティベートする、という機能だ。
つまり、 /etc/init.d/clvm の持つ2つの機能を、 lvm2-clvmd.service と lvm2-cluster-activation.service の2つで担っているというわけ。
だから、 /etc/init.d/clvm のサービスは起動する必要なし。起動しなくて正解だった。

また余計な時間をかけてしまった…。
--2017/04/20追記ココから--
だったら、 /etc/init.d/clvm は自動起動しないように設定しておけばいいんじゃないかな?
というわけで自動起動から外す。
(gemini) $ systemctl is-enabled clvm
(gemini) $ sudo systemctl disable clvm
(gemini) $ systemctl is-enabled clvm
再起動して確認
(gemini) $ sudo systemctl reboot
(gemini) $ dmesg
(gemini) $ systemctl status clvm
これで大丈夫だろう…。
--2017/04/20追記ココまで--

2017年4月14日金曜日

Ubuntu 17.04リリース

Ubuntuの17.04がリリースされた模様。
このリリースはLTSではないので、一応16.04をメインに使っていくよ。
#デスクトップ用途なら17.04でもいいかも。

2017年4月13日木曜日

幾つか記事の修正を

結局、corosyncの起動失敗に関しては、結論が出なかった。
そのため、corosync/dlmとlibvirt関連、KVM関連、及びKVM/libvirtが使用するファイルシステムのマウントは、OS起動時ではなくOS起動後、手作業で実施することにしよう。

また、過去の記事もかなり誤りが見つかったので、この辺りの記事から見直して加筆修正する。
直接記事を加筆修正するので、一度確認してみて欲しい。
--2017/04/20追記ココから--
とりあえず記事を修正してみた。
まだ抜け漏れあるかもしれないけど、気付いたら追記していく。
--2017/04/20追記ココまで--

dlm.confのマニュアル@超意訳&ぐぐる翻訳

dlm.confのマニュアルエントリを超意訳。ぐぐる翻訳も利用。
一部意味不明なのだけどご容赦。
---------------------------------------------------------------------------
DLM.CONF(5)                           dlm                          DLM.CONF(5)

NAME
dlm.conf - dlm_controld configuration file

SYNOPSIS
/etc/dlm/dlm.conf

DESCRIPTION
The configuration options in dlm.conf mirror the dlm_controld command line options.
The config file additionally allows advanced fencing and lockspace configuration that are not supported on the command line.
dlm.confへの記述は、dlm_controld コマンド行のオプションに反映されます。
また、dlm.confでは、コマンドラインでサポートされていない高度なフェンシングとロックスペースの設定も可能です。

Command line equivalents
コマンドラインオプションと同等の設定項目

If an option is specified on the command line and in the config file, the command line setting overrides the config file setting.
See dlm_controld(8) for descriptions and dlm_controld -h for defaults.
コマンドラインと設定ファイルの両方でオプションが指定されている場合、コマンドラインの設定が優先されます。
各オプションの説明についてはdlm_controld(8)、デフォルトについてはdlm_controld -hを参照してください。

Format:

key=val

Example:

log_debug=1
post_join_delay=10
protocol=tcp

Options:

daemon_debug
log_debug
protocol
debug_logfile
enable_plock
plock_debug
plock_rate_limit
plock_ownership
drop_resources_time
drop_resources_count
drop_resources_age
post_join_delay
enable_fencing
enable_concurrent_fencing
enable_startup_fencing
enable_quorum_fencing
enable_quorum_lockspace

Fencing
A fence device definition begins with a device line, followed by a number of connect lines, one for each node connected to the device.
フェンスデバイスの定義はdevice行で始まり、接続数分の各ノードごとのconnect行が続きます。

A blank line separates device definitions.
空白行はデバイス定義を区切ります。

Devices are used in the order they are listed.
デバイスは、記載されている順序で使用されます。

The device key word is followed by a unique dev_name, the agent program to be used, and args, which are agent arguments specific to the device.
デバイスキーワードの後には、固有のdev_name、使用するエージェントプログラム、およびデバイス固有のエージェント引数が続きます。

The connect key word is followed by the dev_name of the device section, the node ID of the connected node in the format node=nodeid and args, which are agent arguments specific to the node for the given device.
connect行の後には、デバイスセクションのdev_name、接続ノードのノードID(node = nodeidおよびargsの形式)、指定されたデバイスのノードに固有のエージェント引数が続きます。

The format of args is key=val on both device and connect lines, each pair separated by a space, e.g. key1=val1 key2=val2 key3=val3.
argsの形式は、deviceとconnectの両方の行でkey = valの形式であり、各ペアはスペースで区切られています。例 key1 = val1 key2 = val2 key3 = val3。

Format:

device  dev_name agent [args]
connect dev_name node=nodeid [args]
connect dev_name node=nodeid [args]
connect dev_name node=nodeid [args]

Example:

device  foo fence_foo ipaddr=1.1.1.1 login=x password=y
connect foo node=1 port=1
connect foo node=2 port=2
connect foo node=3 port=3

device  bar fence_bar ipaddr=2.2.2.2 login=x password=y
connect bar node=1 port=1
connect bar node=2 port=2
connect bar node=3 port=3

Parallel devices
Some devices, like dual power or dual path, must all be turned off in parallel for fencing to succeed.
To define multiple devices as being parallel to each other, use the same base dev_name with different suffixes and a colon separator between base name and suffix.
デュアルパワーまたはデュアルパスのようなデバイスの中には、フェンシングを成功させるためにすべて並列にオフにする必要があるものがあります。
複数のデバイスを互いに並列に定義するには、同じbase dev_nameと異なるsuffixを使用し、コロン区切り文字をベース名とsuffixの間に使用します。

Format:

device  dev_name:1 agent [args]
connect dev_name:1 node=nodeid [args]
connect dev_name:1 node=nodeid [args]
connect dev_name:1 node=nodeid [args]

device  dev_name:2 agent [args]
connect dev_name:2 node=nodeid [args]
connect dev_name:2 node=nodeid [args]
connect dev_name:2 node=nodeid [args]

Example:

device  foo:1 fence_foo ipaddr=1.1.1.1 login=x password=y
connect foo:1 node=1 port=1
connect foo:2 node=2 port=2
connect foo:3 node=3 port=3

device  foo:2 fence_foo ipaddr=5.5.5.5 login=x password=y
connect foo:2 node=1 port=1
connect foo:2 node=2 port=2
connect foo:2 node=3 port=3

Unfencing
A node may sometimes need to "unfence" itself when starting.
The unfencing command reverses the effect of a previous fencing operation against it.
An example would be fencing that disables a port on a SAN switch.
A node could use unfencing to re-enable its switch port when starting up after rebooting.
(Care must be taken to ensure it's safe for a node to unfence itself.
A node often needs to be cleanly rebooted before unfencing itself.)
ノードは、起動時に「unfence」する必要があることがあります。
unfencingコマンドは、以前のフェンシング操作の効果を元に戻します。
例えば、フェンシングによってSANスイッチ上のポートをdisableにした場合等で必要になります。
この場合、ノードが再起動後に、スイッチング・ポートを再び有効にするためにunfencingを使用します。
(ノードは、安全に自身をunfenceする必要があります。
状況によっては、ノードをunfenceする前に、そのノードを再起動(クリーンブート)する必要があります。)

To specify that a node should unfence itself for a given device, the unfence line is added after the connect lines.
特定のデバイスでノードがunfenceされないように指定するには、connect行の後にunfence行を追加します。

Format:

device  dev_name agent [args]
connect dev_name node=nodeid [args]
connect dev_name node=nodeid [args]
connect dev_name node=nodeid [args]
unfence dev_name

Example:

device  foo fence_foo ipaddr=1.1.1.1 login=x password=y
connect foo node=1 port=1
connect foo node=2 port=2
connect foo node=3 port=3
unfence foo

Simple devices
In some cases, a single fence device is used for all nodes, and it requires no node-specific args.
This would typically be a "bridge" fence device in which an agent is passing a fence request to another subsystem to handle.
(Note that a "node=nodeid" arg is always automatically included in agent args, so a node-specific nodeid is always present to minimally identify the victim.)
よくあるケースとして、単一のフェンスデバイスがすべてのノードで使用され、ノード固有のパラメータが必要無い、という構成があります。
これは、典型的には、エージェントがフェンス要求を別のサブシステムに渡して処理する「ブリッジ」フェンス装置として機能する場合です。
(fencing対象を識別するために、"node = nodeid"引数は常にagent引数に自動的に含まれます。そのため、ノード固有のnodeidは必ず作成されます。)

In such a case, a simplified, single-line fence configuration is possible, with format:
最も単純なfence構成は、以下のように1行で記載することが可能です。

fence_all agent [args]

Example:

fence_all dlm_stonith

A fence_all configuration is not compatible with a fence device configuration (above).
fence_all設定はフェンスデバイス設定(上記)と互換性がありません。

Unfencing can optionally be applied with:
アンフェンシングは、オプションで次のように指定できます。

fence_all agent [args]
unfence_all

Lockspace configuration
A lockspace definition begins with a lockspace line, followed by a number of master lines.
A blank line separates lockspace definitions.
ロック・スペースの定義は、lockspace行から始まり、その後にいくつかのmaster行が続きます。
空白行は、ロック・スペース定義を区切ります。

Format:

lockspace ls_name [ls_args]
master    ls_name node=nodeid [node_args]
master    ls_name node=nodeid [node_args]
master    ls_name node=nodeid [node_args]

Disabling resource directory
リソースディレクトリを無効にする
Lockspaces usually use a resource directory to keep track of which node is the master of each resource.
The dlm can operate without the resource directory, though, by statically assigning the master of a resource using a hash of the resource name.
To enable, set the perlockspace nodir option to 1.
ロックスペースは通常、リソースディレクトリを使用して、どのノードが各リソースのマスターであるかを追跡します。
ただし、リソース名のハッシュを使用してリソースのマスターを静的に割り当てることによって、dlmはリソース・ディレクトリーなしで動作することができます。
有効にするには、perlockspace nodirオプションを1に設定します。

Example:

lockspace foo nodir=1

Lock-server configuration
ロックサーバー構成
The nodir setting can be combined with node weights to create a configuration where select node(s) are the master of all resources/locks.
These master nodes can be viewed as "lock servers" for the other nodes.
ノード設定をノード加重と組み合わせて、選択ノードがすべてのリソース/ロックのマスターである構成を作成することができます。
これらのマスターノードは、他のノードの「ロックサーバー」とみなすことができます。

Example of nodeid 1 as master of all resources:
すべてのリソースのマスターであるnodeid 1の例:

lockspace foo nodir=1
master foo node=1

Example of nodeid's 1 and 2 as masters of all resources:
すべてのリソースのマスターとしてのnodeidの1と2の例:

lockspace foo nodir=1
master foo node=1
master foo node=2

Lock management will be partitioned among the available masters.
There can be any number of masters defined.
The designated master nodes will master all resources/locks (according to the resource name hash).
When no masters are members of the lockspace, then the nodes revert to the common fully-distributed configuration.
Recovery is faster, with  little disruption, when a non-master node joins/leaves.
ロック管理は、使用可能なマスター間で分割されます。
任意の数のマスタを定義することができます。
指定されたマスターノードは、すべてのリソース/ロックをマスターします(リソース名ハッシュに従って)。
マスターがロックスペースのメンバーでない場合、ノードは共通の完全分散構成に戻ります。
マスターノードではないノードが参加/離脱するときに、リカバリは高速で、中断はほとんどありません。

There is no special mode in the dlm for this lock server configuration, it's just a natural consequence of combining the "nodir" option with node weights.
When a lockspace has master nodes defined, the master has a default weight of 1 and all non-master nodes have weight of 0.
An explicit non-zero weight can also be assigned to master nodes, e.g.
このロック・サーバー構成では、dlmに特別なモードはありません。ノードの重みと "nodir"オプションを組み合わせるのは当然の結果です。
ロック・スペースにマスター・ノードが定義されている場合、マスターのデフォルト重みは1で、非マスター・ノードの重みはすべて0です。
明示的な非ゼロ加重値をマスターノードに割り当てることもできます。

lockspace foo nodir=1
master foo node=1 weight=2
master foo node=2 weight=1

In which case node 1 will master 2/3 of the total resources and node 2 will master the other 1/3.
この場合、ノード1は総リソースの2/3を習得し、ノード2はもう1/3を習得します。
SEE ALSO
dlm_controld(8), dlm_tool(8)

dlm                               2012-04-09                       DLM.CONF(5)
-------------------------------------------------------------------------------------
あと、コマンドラインオプション・confファイルへの記載可能項目の一覧意訳。
daemon_debug
--daemon_debug | -D
enable debugging to stderr and don't fork [0]
stderrへのデバッグを有効にし、forkしません。

log_debug
--log_debug | -K
enable kernel dlm debugging messages [0]
カーネルdlmデバッグメッセージを有効にします。

protocol
--protocol | -r str
dlm kernel lowcomms protocol: tcp, sctp, detect [detect]
dlmカーネルローコムプロトコル:tcp、sctp、detect。

debug_logfile
--debug_logfile | -L
write debugging to log file [0]
ログファイルにデバッグを書き込みます。

enable_plock
--enable_plock | -p 0|1
enable/disable posix lock support for cluster fs [1]
クラスタfsに対するposixロックのサポートを有効または無効にします。

plock_debug
--plock_debug | -P [0]
enable plock debugging
plockのデバッグを可能にする。

plock_rate_limit
--plock_rate_limit | -l int
limit rate of plock operations (0 for none) [0]
plock操作の制限速度(0の場合は無し)。

plock_ownership
--plock_ownership | -o 0|1
enable/disable plock ownership [0]
plockの所有権を有効/無効にします。

drop_resources_time
--drop_resources_time | -t int
plock ownership drop resources time (milliseconds) [10000]
plockの所有権ドロップリソース時間(ミリ秒)。

drop_resources_count
--drop_resources_count | -c int
plock ownership drop resources count [10]
plockの所有権ドロップリソースの数。

drop_resources_age
--drop_resources_age | -a int
plock ownership drop resources age (milliseconds) [10000]
plock所有権ドロップリソースの経過時間(ミリ秒)。

post_join_delay
--post_join_delay | -j int
seconds to delay fencing after cluster join [30]
クラスタ参加後のフェンシングを遅らせる秒数。

enable_fencing
--enable_fencing | -f 0|1
enable/disable fencing [1]
フェンシングを有効/無効にします。

enable_concurrent_fencing
--enable_concurrent_fencing 0|1
enable/disable concurrent fencing [0]
同時フェンシングを有効/無効にします。

enable_startup_fencing
--enable_startup_fencing | -s 0|1
enable/disable startup fencing [1]
起動フェンシングを有効/無効にします。

enable_quorum_fencing
--enable_quorum_fencing | -q 0|1
enable/disable quorum requirement for fencing [1]
フェンシングのための定足数要件を有効/無効にします。

enable_quorum_lockspace
--enable_quorum_lockspace 0|1
enable/disable quorum requirement for lockspace operations [1]
ロックスペース操作のクォーラム要件を有効/無効にします。

--foreground
don't fork [0]
フォークしないでください。

--fence_all str
fence all nodes with this agent
すべてのノードをこのエージェントにフェンスします。

--unfence_all
enable unfencing self with fence_all agent
fence_allエージェントで自己フェンシングを有効にします。

2017年4月7日金曜日

今の調査状況

--2017/04/20追記ココから--
ここで出ている問題は、前回分に追記した内容で解消したっぽい。
なので、無駄な記事になってしまった。
--2017/04/20追記ココまで--

全然解決しねぇ。

今のところ…
  1. corosyncの自動起動にほぼ間違いなく失敗する。
  2. corosyncの自動起動失敗に伴い、dlmも停止する。
  3. o2cbの起動もほぼ間違いなく失敗する。
    (ただし、systemd的には成功しているように見える。)
  4. OSの起動後、手作業でcorosyncを起動することは可能。
  5. 同、手作業でdlmを起動することは可能。
    (corosyncが起動していない状態でdlmを手作業で起動すれば、corosyncも連動して起動する。)
  6. corosyncのsystemd起動ファイル(/lib/systemd/system/corosync.service)のRequiresとAfterにopenvswitch-switchを追加することで、corosync/dlmの自動起動成功率は高まる。
    (必ず成功するわけではなく、自動起動失敗することもある。)
  7. 両ノードでdlmが起動している状態で、片方のノードを停止させると、しばらくしてから生きている方のノードも自動でリブートする。
  8. OS起動後、o2cbを手作業で起動(停止してから起動)は成功する。
  9. corosync/dlmが停止している(起動失敗している)状態で、手作業でgfs2ファイルシステムをマウントしようとすると、corosync/dlmが自動起動してマウント成功する。
  10. o2cbが正常起動している状態でなら、ocfs2ファイルシステムのマウントが可能。
  11. o2cbの起動が上手く行っていない状態でocfs2ファイルシステムをマウントしようとすると、マウント失敗する。
  12. o2cbを正常停止させている状態からocfs2ファイルシステムをマウントしようとすると、o2cbが自動起動してマウント成功する。
  13. いずれも、openvswitch-switchが導入されていない環境では起きない問題。
辺りのことが分かってきた。

考え方的に、corosync/dlmとgfs2はセット、o2cbとocfs2がセット、となる。
今は両方に問題が出ているが、別モノとして整理、調査しないと混乱してしまうな。

2017年4月4日火曜日

共有仮想ディスクの設定

前回、cancer側でocfs2ファイルシステムのマウントが出来なくなった、と書いた。
クラスタ云々っていう理由だと思ったけど、それ以前に共有仮想ディスク(/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追記ココまで--