web-dev-qa-db-ja.com

RHCS：共通ストレージを備えたA / Aクラスター内のGFS2。 rgmanagerを使用したGFSの構成

クラスター化されたLVM上でGFS2を使用するiSCSI経由で接続された共通ストレージを使用して2ノードA/Aクラスターを構成しています。これまでのところ、簡単な構成を準備しましたが、gfsリソースを構成する正しい方法がわかりません。

/etc/cluster/cluster.confのrmセクションは次のとおりです。

<rm>
    <failoverdomains>
        <failoverdomain name="node1" nofailback="0" ordered="0" restricted="1">
            <failoverdomainnode name="rhc-n1"/>
        </failoverdomain>
        <failoverdomain name="node2" nofailback="0" ordered="0" restricted="1">
            <failoverdomainnode name="rhc-n2"/>
        </failoverdomain>
    </failoverdomains>
    <resources>
        <script file="/etc/init.d/clvm" name="clvmd"/>
        <clusterfs name="gfs" fstype="gfs2" mountpoint="/mnt/gfs"  device="/dev/vg-cs/lv-gfs"/>
    </resources>
    <service name="shared-storage-inst1" autostart="0" domain="node1" exclusive="0" recovery="restart">
        <script ref="clvmd">
            <clusterfs ref="gfs"/>
        </script>
    </service>
    <service name="shared-storage-inst2" autostart="0" domain="node2" exclusive="0" recovery="restart">
        <script ref="clvmd">
            <clusterfs ref="gfs"/>
        </script>
    </service>
</rm>

これが私が意味することです。clusterfsリソースエージェントを使用してGFSパーティションを処理する場合、デフォルトではアンマウントされません（force_unmountオプションが指定されていない場合）。私が発行するときにこのように

clusvcadm -s shared-storage-inst1

clvmは停止しますが、GFSはアンマウントされないため、ノードは共有ストレージ上のLVM構造を変更できなくなりますが、データにはアクセスできます。また、ノードはそれを非常に安全に実行できますが（dlmはまだ実行中です）、clustatは特定のノードのサービスが停止していると報告するため、これは私にはかなり不適切なようです。さらに、後でそのノードでcmanを停止しようとすると、GFSによって生成されたdlmロックが検出され、停止に失敗します。

Force_unmount = "1"を追加するだけでもかまいませんが、デフォルトの動作の背後にある理由を知りたいのですが。なぜマウント解除されないのですか？そこにある例のほとんどは、force_unmount = "0"を黙って使用していますが、使用していないものもありますが、決定がどのように行われたかについての手がかりはありません。

それとは別に、gfs2initスクリプトを使用してGFSパーティションを管理するサンプル構成を見つけました--- https://alteeve.ca/w/2-Node_Red_Hat_KVM_Cluster_Tutorial#Defining_The_Resources

または、clvmやgfs2などのサービスが起動時に自動的に開始するようにするのと同じくらい簡単です（ http://pbraun.nethence.com/doc/filesystems/gfs2.html ）、次のようになります。

chkconfig gfs2 on

最新のアプローチを正しく理解していれば、そのようなクラスターはノードがまだ生きているかどうかを制御するだけで、誤ったノードをフェンスできますが、そのようなクラスターはそのリソースのステータスを制御できません。

私はPacemakerの使用経験があり、すべてのリソースがクラスターによって制御され、接続の問題があるだけでなく、リソースのいずれかが誤動作した場合にアクションを実行できることに慣れています。

だから、これは私が行く正しい方法です：

  1. gFSパーティションをマウントしたままにします（そうする理由はありますか？）
  2. force_unmount = "1"を設定します。これは何も壊しませんか？なぜこれがデフォルトではないのですか？
  3. スクリプトリソースを使用する<script file="/etc/init.d/gfs2" name="gfs"/>GFSパーティションを管理します。
  4. 起動時に開始し、cluster.confに含めないでください（そうする理由はありますか？）

これは明確に答えることができない一種の質問かもしれないので、あなたがあなたの経験を共有したり、問題についてあなたの考えを表明したりするならば、それは私にとっても非常に価値があります。たとえば、/ etc/cluster/cluster.confは、Congaまたはccsを使用してgfsを構成する場合、どのように見えますか（今のところ、クラスターにUbuntuを使用する必要があるため、これらは使用できません）。

どうもありがとうございます！

gfs2shared-storagerhcs
5
Pavel A

私はクラスターで少し作業しました。これらはこの件に関する私の意見です。

could have simply added force_unmount="1",  but I would like to know what is
the reason behind the default behavior. Why is it not unmounted?

Gfsをクラスター化されたリソースとして構成し、clvmdおよびgfsディスクをリソースとして追加することを選択した場合、rgmanagerでフェイルオーバーするとwill =ディスクをアンマウントしようとするので、最初に行うのは、アンマウントが失敗した理由を示すログ（またはlsof/fuserなど）を確認することです。ファイルを開いているなどのプロセスがあり、「クリーンな」アンマウントが妨げられている可能性があります。

Rgmanagerを使用してクラスター化アプリケーションを起動していないことが原因でしょうか？ cluster.confに表示されません。それが本当なら、その振る舞いを説明するでしょう。

force_unmountを選択した場合、フェイルオーバー/リカバリ時にrgmanagerが行うことは、ディスクをアンマウントする前に、ディスクを使用しているすべてのリコースを強制的に強制終了することです。良いアイデアかどうかは天気によって異なります。

clvm is stopped, but GFS is not unmounted, so a node cannot alter LVM structure 
on shared storage anymore, but can still access data. And even though a node can 
do it quite safely (dlm is still running), [...]  
Moreover if I later try to stop cman on that node, it will find a dlm locking,
produced by GFS, and fail to stop.

このシナリオでLVM構造を変更したい場合は、clvmdデーモンを手動で再起動できます。 cmanを停止する前にgfsディスクをアンマウントすると、それは機能するはずです。一方、実稼働シナリオでは、クラスター化されたノードでCMANを停止したい状況に陥ることはめったにありません。

私の好みはオプション4で行くことです。

If I understand the latest approach correctly, such cluster only controls 
whether nodes are still alive and can fence errant ones, but such cluster
has no control over the status of its resources.

確かに、gfs2およびclvmdリソースをクラスターリソースとして追加しないと、rgmanagerはそれを制御できません。 （もちろん場合によっては）p A/Aクラスターをセットアップするときに私が通常行うことは、クラスター化されたリソースとしてサービスの開始スクリプトを追加することです。 （次に、rgmanagerは、status引数を指定してスクリプトを定期的に呼び出し、構成されたアクションを実行する必要がある天気を判別します）。私のスクリプトはgfsファイルシステムに依存しているため、マウントしないと失敗します。

4つのアプローチは、clvmd、cman、およびgfs2（および状況によっては他のデーモンも）を手動で有効にすることを意味します。

GFSファイルシステムはiSCSIデバイスの上にあるため、_netdevのマウントに/etc/fstabオプションを追加することが機能するための要件です。

  • このようにして、過度に複雑なクラスター構成を取得することはありません。後でサービスを追加することで、頭痛の種が少なくなります（たとえば、同じディスクを使用する2つのサービスなど）
  • 何かが起こったとき、私の経験では、リソースを使用すると手動による介入がはるかに簡単になりますnotrgmanagerによって管理されます
  • 私の経験では、クラスターで最も問題が発生するのはgfs2またはclvmdサービスではなく、最上位のサービスであるため、それらを再起動/マウントするのに時間がかかるだけです。

私も考えることができるいくつかの欠点があります：

  • あなたが言ったように、rgmanagerはこれらのリソースを管理せず、たとえばgfsファイルシステムが何らかの理由で失敗/マウント解除された場合はアクションを実行しません
  • gfsファイルシステムを大量にマウントすると、たとえばupdatedbやファイルシステムをトラバースする可能性のあるその他のジョブによってデバイスに不要な負荷が発生し、ドライブの遅延（トラフィックのロック）が発生する可能性があります。

あなたが何を決めても

Initスクリプトをクラスター化されたリソースとして追加し、gfsとclvmをリソースとしてクラスターに追加することを選択した場合は、 __ independent_subtree を追加することを検討します。そのため、失敗した場合、rgmanagerはgfsファイルシステムを再マウントしません。もちろん、これは特定の状況によって異なります。リンク内のネストされた構成に注意して、一種の依存関係ツリーをマークします。

1
Petter H