huawei-cloud-mrs-redis-meta-check

MRS Redis メタデータチェック スキル

MRS Redis メタデータファイルのチェックを専門とし、Redis クラスターのメタデータ設定ファイル（nodes-*.conf）の整合性を確認します。Redis インスタンスの起動失敗、接続異常、障害アラートの原因となる7種類のメタデータの問題を正確に特定し、診断できます。

1. 概要

アーキテクチャ：このスキルでは、ファイル収集 → 解析と分析 → ルールエンジン（7つのチェックポイント）→ レポート生成の3段階パイプラインを使用します。

適用シナリオ：

• Redis インスタンスの起動失敗アラート
• Redis 接続異常アラート
• Redis インスタンスの障害アラート
• ユーザーが nodes-*.conf ファイルのチェックを明示的に依頼した場合
• Redis クラスターの定期的なメタデータ整合性チェック

一般的なユースケース：

• 「host-01 の Redis インスタンスが起動に失敗しました。メタデータファイルをチェックしてください」
• 「この nodes-22400.conf が正しいかチェックしてください」
• 「Redis の接続が異常です。クラスター設定をチェックしてください」
• 「Redis クラスターのメタデータの整合性を検証してください」
• 「nodes.conf ファイルのスロットが網羅されているかチェックしてください」

チェックポイント（7項目）：

チェック ID	名前	レベル	説明
CHK001	スロットの完全性	ERROR	すべてのマスターインスタンスのスロット範囲が0～16383（合計16384スロット）を網羅し、欠落や重複がないこと
CHK002	マスター／スレーブ数の整合性	ERROR	マスターとスレーブのインスタンス数が等しく、合計が偶数であること
CHK003	ファイル形式の完全性	ERROR	ファイルに4つのセクション（Connection、Epoch、Whitelist、Cluster-name）が含まれていること
CHK004	ファイル名とポートの整合性	ERROR	ファイル名（例：nodes-22400.conf）のポートが、myself とマークされた行のポートと一致すること
CHK005	ポートの関係	ERROR	各インスタンスで、クラスターのポートからサービスのポートを引いた値が1950であること
CHK006	マスターとスレーブの関係	ERROR	各マスターのスレーブが最大1台であること
CHK007	myself マーカー	ERROR	ファイルに myself とマークされた行がちょうど1つ含まれていること

デフォルトのチェックパス：/srv/BigData/redis_meta/Redis_*/nodes-224*.conf

ユーザーは、チェック対象のファイルパスを個別に指定することもできます。

2. 前提条件

2.1 環境要件

• MRS クラスターのホストにアクセスできること（ファイル収集用）
• Redis メタデータファイルを読み取るための omm ユーザー権限
• 追加のソフトウェアや Python パッケージは不要

2.2 セキュリティルール

• このスキルでは静的ファイル分析のみを行い、Redis クラスターへの接続は不要です
• ファイルの内容はローカルで処理され、外部に送信されることはありません
• チェック自体に認証情報や認証は不要です
• クラスターホストからファイルを収集するには、適切なアクセス権限が必要です

3. ワークフロー

ステップ1：ファイルを収集する

ユーザーが nodes-*.conf ファイルをすでに提供している場合は、このステップを省略してステップ2に進みます。

ユーザーがファイルを提供していない場合は、必要なファイルが保存されているディレクトリを伝え、以下の手順に従ってファイルを提供するよう依頼します。

1.1 対象ホストを特定する

MRS Console → Redis → Redis Management → Redis 論理クラスター名 → Abnormal instances にログインし、異常インスタンスのホスト IP を確認します。

通常、Redis 論理クラスターは複数のホストにまたがってデプロイされます。同じクラスター内の各ホストにある nodes-*.conf ファイルの内容は共通です（同じクラスター内のすべてのインスタンスでクラスターのトポロジーは共通ですが、myself フラグは異なります）。そのため、クラスター内のいずれか1台のホストから収集すれば十分です。ただし、どのホストが同じクラスターに属しているか不明な場合は、異常インスタンスがあるホストから収集することをおすすめします。正常なインスタンスの node-conf ファイルを収集したら、まずこのスキルでファイルを検証してから、修復に進んでください。

1.2 ファイルの収集

このスキルは静的解析のみを行い、コマンドを実行するために MRS クラスターホストへ接続することはできません。ls／cp などを実行しようとせず、代わりに必要なファイルがあるディレクトリを伝え、ファイルを提供するようユーザーに依頼してください。

必要なファイルは、対象ホスト上の次のディレクトリにあります。

/srv/BigData/redis_meta/Redis_*/nodes-224*.conf

ホスト上の一般的な配置：

/srv/BigData/redis_meta/Redis_1/nodes-22400.conf
/srv/BigData/redis_meta/Redis_2/nodes-22401.conf
/srv/BigData/redis_meta/Redis_3/nodes-22402.conf
...

シナリオ A：インスタンスが正常に稼働している場合（定期チェック）

上記のディレクトリを伝え、任意の nodes-*.conf ファイルを1つ提供するようユーザーに依頼してください（同じホスト上のファイルは内容が同一です）。

シナリオ B：インスタンスに異常があり、起動できない場合（解析用ファイルの収集が必要）

インスタンスに異常がある場合でも、ファイルはディスク上に残っています。上記のディレクトリを伝え、次のファイルを提供するようユーザーに依頼してください。

1. 異常のあるインスタンスに対応するファイル。例：/srv/BigData/redis_meta/Redis_1/nodes-22400.conf
2. 比較用として、同じホスト上の正常なインスタンスのファイル。例：/srv/BigData/redis_meta/Redis_2/nodes-22401.conf

注：ホスト上でこれらのファイルを読み取るには、omm ユーザーの権限が必要です。

1.3 よくある問題

問題	原因	解決策
No such file or directory	インスタンスがインストールされていないか、パスが間違っています	ホスト上で ls /srv/BigData/redis_meta/ を実行し、存在する Redis_X ディレクトリを確認します
ディレクトリは存在するが、nodes-*.conf ファイルがない	インスタンスが初期化されていないか、ファイルが削除されています	同じホスト上の別の正常なインスタンスからコピーします（使用前に myself マーカーが正しいことを必ず確認してください）
Permission denied	omm ユーザーの権限が必要です	ホスト上で su - omm を使ってユーザーを切り替えてから操作します

ステップ 2：ファイルの特定

ユーザーが特定のファイルを指定していない場合：

1. ユーザーが指定したディレクトリまたはファイル内で nodes-224*.conf ファイルを検索します
2. 見つからない場合は検索範囲を広げ、ディレクトリとサブディレクトリ内で nodes-*.conf または *.conf ファイルを検索します
3. 一致するファイルをすべて一覧表示します
4. どのファイルをチェックするかユーザーに選んでもらうか、すべてのファイルをチェックします

ユーザーがファイルを指定している場合：

1. まず指定されたパスで検索します
2. 見つからない場合は、指定されたディレクトリとサブディレクトリを再帰的に検索します
3. ファイルが1つ見つかった場合は、ファイル名が命名規則に準拠しているかどうかにかかわらず、内容を直接読み取って解析します
4. 内容が Redis メタデータ形式（ノード ID、ロール、スロット情報などを含む）に準拠している場合は、チェックを実行します

ステップ 3：ファイルの解析

セクション 4.1 の解析コマンドを使用して、主要な情報を抽出します。

• すべてのノード行（Connection モジュール）
• Myself 行
• Vars 行（Epoch モジュール）
• Whitelist 行
• Cluster-name 行

ステップ 4：7つのチェック項目を実行

CHK001：スロットの完全性

チェック内容：

• すべてのマスターインスタンスのスロット範囲が 0～16383 をカバーし、合計で 16384 スロットである必要があります
• マスターインスタンスにはスロット情報（例：0-5460）が必要です
• スレーブインスタンスにはスロット情報がないことが必要です

チェック方法：

1. すべてのマスターノードのスロット範囲を抽出します
2. すべてのスロット範囲を統合し、0～16383 を隙間や重複なくカバーしていることを確認します
3. スレーブノードに誤ってスロットが割り当てられていないか確認します

合格基準：スロット範囲が 0～16383 を完全にカバーしていること

CHK002：マスター／スレーブ数の整合性

チェック内容：

• マスターとスレーブのインスタンス数が一致している必要があります
• 合計数は偶数である必要があります

チェック方法：

1. マスターノードを数えます（myself,master またはスタンドアロンのマスターを含む）
2. スレーブノードを数えます
3. 数が一致し、合計が偶数であることを確認します

合格基準：マスター数 = スレーブ数、かつ合計が偶数であること

CHK003：ファイル形式の完全性（4 モジュール）

チェック内容：ファイルに次の 4 モジュールが完全な形式で含まれていること

モジュール 1：接続モジュール

• 形式：NodeID "IP:port@cluster_port" role master_nodeID ... connected
• 例：155ce4426e976bc65240829943a2acd8c05806ce "hosts1:22401@24351" slave df37138a11e6708563fdb0962a73a6ae20281b60 0 1777455797875 3 connected

モジュール 2：エポックモジュール

• 形式：vars currentEpoch N lastVoteEpoch N
• 例：vars currentEpoch 10 lastVoteEpoch 10

モジュール 3：ホワイトリストモジュール

• 形式：whitelist "IP1" "IP2" ...
• 例：whitelist "hosts3" "hosts2" "hosts1"

モジュール 4：クラスター名モジュール

• 形式：cluster-name name
• 例：cluster-name test

チェック方法：

1. vars 行が存在するか確認します（エポックモジュール）
2. whitelist 行が存在するか確認します（ホワイトリストモジュール）
3. cluster-name 行が存在するか確認します（クラスター名モジュール）
4. 接続モジュールの行に異常な文字（壊れたエントリ、特殊文字など）がないか確認します

合格基準：4 つのモジュールがすべて存在し、形式が正しいこと

CHK004：ファイル名とポートの整合性

チェック内容：

• ファイル名に含まれるポート番号（例：nodes-22400.conf）が、myself マーク付き行のポートと一致していること
• 例：nodes-22400.conf では、myself マークが hosts1:22400 であること

チェック方法：

1. ファイル名からポート番号を抽出します（例：22400）
2. myself マーク付き行からポート番号を抽出します
3. 両者が一致していることを確認します

合格基準：ファイル名のポート = myself マーク付きポート

CHK005：ポートの関係

チェック内容：

• 各マスター・スレーブインスタンスのペアで、ポートの関係が次の条件を満たすこと：cluster_port - service_port = 1950
• 例：22401@24351、24351-22401=1950

チェック方法：

1. すべてのノードの service_port@cluster_port を抽出します
2. 各ペアのポート差が 1950 であることを確認します

合格基準：すべてのポートペアの差が 1950 であること

CHK006：マスター・スレーブの関係

チェック内容：

• 各マスターインスタンスに対応するスレーブインスタンスは 1 つのみであること
• マスターに複数のスレーブが対応している場合は、不合格となります

チェック方法：

1. 各スレーブのマスターノード ID を抽出します
2. 各マスターノードに対応するスレーブの数を数えます
3. 各マスターノードに対応するスレーブが最大 1 つであることを確認します

合格基準：各マスターに対応するスレーブが最大 1 つであること

CHK007：Myself マーカー

チェック内容：

• ファイルに myself マーカーを含む行があること
• この行は現在のノードの識別情報を表します

チェック方法：

1. "myself" を含む行を検索します
2. myself 行の形式が正しいことを確認します
3. ファイル全体に myself マーカーがちょうど 1 つあることを確認します

合格基準：myself マーク付き行がちょうど 1 つ存在すること

ステップ 5：レポートの生成

セクション 8：出力形式で定義された形式に従ってチェックレポートを生成します。

全体の結果が FAIL の場合、レポートの末尾に修復ガイダンスを追記する必要があります。修復ガイダンスでは、次の内容を示します。

• 不合格となった各チェック項目の問題の説明
• セクション 6の一般的な修復方法への参照
• myself マーカーの修正手順では、汎用的なプレースホルダー（xxxxxxxx など）ではなく、解析対象ファイルの実データ（ノード ID、IP、ポート、ロール、マスターノード ID）に基づいた修正前／修正後の例を提示します

myself マーカーの例を作成する具体的な手順：

1. 異常なインスタンスのノード ID、IP、ポート、ロール、マスターノード ID を myself 行から抽出します
2. 同じホスト上の別の正常なインスタンスからコピーすると仮定し、修正前／修正後の比較例を作成します
3. 例には、異常なインスタンスのポート行と正常なインスタンスのポート行の修正前／修正後の比較を少なくとも含めます

4. コアコマンド

4.1 ファイル内容の解析

# Extract all node lines (Connection module)
grep -v "^vars\|^whitelist\|^cluster-" "$file"

# Extract myself line
grep "myself" "$file"

# Extract vars line (Epoch module)
grep "^vars" "$file"

# Extract whitelist line
grep "^whitelist" "$file"

# Extract cluster-name line
grep "^cluster-name" "$file"

5. よくある問題とトラブルシューティング

問題	原因	影響	解決方法
スロットの空き／重複	マスターノードのスロット範囲の設定ミス	Redis インスタンスを起動できず、クラスターの状態が異常になります	一般的な修復方法
マスター／スレーブ数の不一致	ノードがクラスターに正しく参加していない、またはマスターとスレーブの関係の設定ミス	クラスターのマスターとスレーブの関係が異常になり、フェイルオーバーに失敗する可能性があります	一般的な修復方法
myself マーカーがない	ファイルの破損、またはノードが初期化されていない	Redis インスタンスが自身を識別できず、起動に失敗します	一般的な修復方法
ポートの関係の誤り	ポート設定の誤り。サービスポートとクラスターのポートの差が 1950 ではない	クラスターノード間の通信が異常になります	一般的な修復方法
ファイル形式が不完全	vars／whitelist／cluster-name モジュールがない、または connection モジュールの行に異常な文字がある	Redis インスタンスが起動時にメタデータを解析できません	一般的な修復方法
ファイル名とポートの不一致	nodes-*.conf ファイルが誤ってコピーまたは名前変更された	Redis インスタンスが正しいメタデータファイルを見つけられません	一般的な修復方法

6. 一般的な修復方法（例付き）

すべての問題は、次の一般的な方法で修復できます。

シナリオ：ホスト host-01 上の Redis_1 インスタンス（ポート 22400）に異常があります。同じホスト上の Redis_2（ポート 22401）は正常です。

1. 異常なインスタンスを停止する：MRS Console → Redis → Instances → 異常なインスタンスを選択 → Stop Instance
2. メタデータファイルをバックアップする（ホスト上で omm として実行）：

   cd /srv/BigData/redis_meta/Redis_1 && mv nodes-22400.conf nodes-22400.conf_bak
   

3. 正常なインスタンスからメタデータファイルをコピーする：

   cp /srv/BigData/redis_meta/Redis_2/nodes-22401.conf /srv/BigData/redis_meta/Redis_1/nodes-22400.conf
   

4. コピーしたファイルを検証する：このスキルを使って、/srv/BigData/redis_meta/Redis_1/nodes-22400.conf に対して 7 つのチェックポイントを実行します。検証に失敗した場合は、別の正常なインスタンスからコピーし、続行する前にもう一度検証してください。
5. /srv/BigData/redis_meta/Redis_1/nodes-22400.conf の myself マーカーを修正する：
   • 既存の myself, を削除します（コピー元の正常なインスタンスに属するものです）
   • 異常なインスタンスのポート（host-01:22400）を含む行のロールマーカーの前に myself, を追加します。例：myself,master ／ myself,slave
   • ファイル全体で myself が現れるのはちょうど 1 回である必要があります
6. 異常なインスタンスを起動する：MRS Console → Redis → Instances → インスタンスを選択 → Start Instance
7. 復旧を確認する：インスタンスのステータスが Good に戻り、Redis 論理クラスターのステータスが正常に戻ることを確認します
8. バックアップファイルを削除する（ホスト上で実行）：

   rm -f /srv/BigData/redis_meta/Redis_1/nodes-22400.conf_bak
   

7. パラメーター

パラメーター	必須／任意	説明	デフォルト
file_path	任意	nodes-*.conf ファイル、またはそのファイルを含むディレクトリのパス	/srv/BigData/redis_meta/Redis_*/nodes-224*.conf
check_points	任意	実行する特定のチェックポイント ID（CHK001-CHK007、カンマ区切り）	7 つすべてのチェックポイント

8. 出力形式

チェックレポートはプレーンテキスト形式で出力されます。

========================================
Redis Metadata File Check Report
File: /path/to/nodes-22400.conf
========================================

[CHK001: Slot Completeness]
Result: PASS/FAIL
Details: ...

[CHK002: Master/Slave Count Consistency]
Result: PASS/FAIL
Details: ...

... (other check points)

========================================
Overall Result: PASS/FAIL
========================================

各チェック結果には、チェック ID、チェック名、結果（PASS／FAIL）、および検出された問題の詳細な説明が含まれます。

全体の結果が FAIL の場合は、末尾に [Repair Guidance] セクションを追加します。修復ガイダンスには、失敗した各チェックポイントの問題の説明を記載したうえで、セクション 6 の一般的な修復方法を参照します。myself マーカーの修正手順には、解析対象ファイルの実際のデータを使った変更前／変更後の例を含める必要があります。

[Repair Guidance]

(List each failed check point's issue description)

The above issues are applicable to the general repair method (see Section 6):
  Step 1: Stop the abnormal instance
  Step 2: Back up the metadata file
  Step 3: Copy metadata file from a normal instance on the same host
  Step 4: Verify the copied file (run this skill's 7 check points)
  Step 5: Correct the myself marker (see example below)
  Step 6: Start the abnormal instance
  Step 7: Confirm recovery
  Step 8: Clean up backup file

  Step 5 myself marker modification example (must use actual data, not placeholders):

  vi /srv/BigData/redis_meta/Redis_1/nodes-22400.conf

  Before modification (copied from normal instance, myself is on normal instance port line):
  <actual node ID> "<actual IP>:<abnormal port>@<cluster port>" <role> <master node ID> 0 <epoch> <epoch> connected
  <actual node ID> "<actual IP>:<normal port>@<cluster port>" myself,<role> <master node ID> 0 <epoch> <epoch> connected

  After modification (remove myself from normal port, add myself to abnormal port line):
  <actual node ID> "<actual IP>:<abnormal port>@<cluster port>" myself,<role> <master node ID> 0 <epoch> <epoch> connected
  <actual node ID> "<actual IP>:<normal port>@<cluster port>" <role> <master node ID> 0 <epoch> <epoch> connected

  Key points:
  - Remove the existing "myself," (belongs to the copied normal instance)
  - Add "myself," before the role marker on the line with the abnormal instance port
  - "myself," must immediately precede the role marker, e.g., myself,master or myself,slave
  - "myself" can only appear once in the entire file

重要な要件：myself マーカーの変更例には、一般的なプレースホルダーではなく、解析対象ファイルの実際のデータ（ノード ID、IP、ポート、ロール、マスターノード ID）を使用する必要があります。

9. ベストプラクティス

1. 同じ論理クラスターから収集する：コピー元のインスタンスは、異常なインスタンスと同じ論理クラスター内にあり、正常な状態でなければなりません
2. 修復前に検証する：myself マーカーを変更する前に、必ずこのスキルを使用してコピーしたファイルを検証してください
3. 必ずバックアップする：ロールバックできるよう、修復作業を行う前に元のファイルをバックアップしてください
4. myself を正確に修正する：myself マーカーはファイル全体で1回だけ、対象インスタンスのポートに対応する行に記述する必要があります
5. ホスト間でコピーする：同じホストに正常なインスタンスがない場合は、同じクラスター内の別のホストにあるインスタンスからコピーできます。ただし、myself マーカーの修正方法は変わりません
6. まずファイル形式を確認する：複数のチェックポイントに不合格となった場合は、ほかの問題より先にファイル形式の問題（CHK003）を修正してください

10. 参考資料

参考資料	説明	関連セクション
正しい形式の例	7つのチェックポイントすべてを示す、有効な nodes-*.conf ファイルの完全な例	3. ワークフロー、4. コアコマンド
MRS Redis 製品ドキュメント	Redis クラスターのトポロジー、nodes-*.conf メタデータファイルの構造、障害診断	1. 概要
Redis クラスター運用ガイド	Redis Cluster のスロット割り当て（0-16383）、マスターとスレーブの関係、ポート計画	3. ワークフロー、6. 一般的な修復方法

10.1 正しい形式の例

有効な nodes-*.conf ファイルの完全な例：

155ce4426e976bc65240829943a2acd8c05806ce "hosts1:22401@24351" slave df37138a11e6708563fdb0962a73a6ae20281b60 0 1777455797875 3 connected
df37138a11e6708563fdb0962a73a6ae20281b60 "hosts2:22400@24350" master - 0 1777455797000 3 connected 10922-16383
f45e8f5d2f89684f9918eb48f60aa5529f2eb498 "hosts3:22400@24350" master - 0 1777455797558 10 connected 5461-10921
8ac5474a124cb0163d92d6921caca52543bcc2f4 "hosts2:22401@24351" slave f45e8f5d2f89684f9918eb48f60aa5529f2eb498 0 1777455797000 10 connected
933540f40adf21a0d580ab5d6d65252da72f6c0d "hosts1:22400@24350" myself,master - 0 1777455797000 1 connected 0-5460
d3da600c0db267fdb18776e44347fa5140cdde21 "hosts3:22401@24351" slave 933540f40adf21a0d580ab5d6d65252da72f6c0d 0 1777455797672 1 connected
vars currentEpoch 10 lastVoteEpoch 10
whitelist "hosts3" "hosts2" "hosts1"
cluster-name test

11. 注意事項

1. このスキルは静的なファイル分析のみを行います。Redis クラスターへの接続は不要です
2. 同じクラスター内のファイルは、myself マーカーを除いて同一です：同じ Redis 論理クラスター内のすべての nodes-*.conf ファイルは、myself フラグの位置を除いて内容が同一です
3. ポート差分は1950です：MRS Redis では、クラスターのポートは常にサービスのポート + 1950 です
4. スロット範囲は0-16383です：Redis Cluster には16384個のスロット（0-16383）があり、すべてのスロットをマスターノードでカバーする必要があります
5. myself は一意です：各 nodes-*.conf ファイルには、現在のノードを示す myself マーカーがちょうど1つ必要です
6. ファイル収集には omm 権限が必要です：クラスターのホストから Redis メタデータファイルを読み取るには、omm ユーザーの権限が必要です
7. 修復の案内には実際のデータを使用する必要があります：修復方法を提示する際、myself マーカーの変更例には汎用的なプレースホルダーではなく、分析対象ファイルに記載された実際のノード ID、IP、ポートを使用する必要があります