グローバル・データ・プラットフォーム・サービスの問題

このセクションでは、 IBM Fusion ストレージを使用する際のトラブルシューティングのヒントとコツを紹介します。

警告: IBM Storage Scale ポッドは削除しないでください。多くの状況でのスケール・ポッドの削除は、可用性とデータ保全性に影響します。

リモートファイルシステムからのファイルシステムのステータスがConnecting（接続中）状態で止まっている

原因: セキュアブートはScaleとCNSAではサポートされていない。

解決策

ノードがセキュアブートで動作しているかどうかをチェックする：
```
mokutil --sb-state
```
```
SecureBoot 使用可能
```

rootパスワードとして、以下のコマンドでセキュアブートを無効にできる：

mokutil --disable-validation

パスワードの長さ: 8~16
パスワードを入力する： 
もう一度パスワードを入力してください：

Cloud Pak for IntegrationCP4I へのアップグレード後、Scale ポッドで CPU 使用率が増加しました

問題ステートメント: MQストリーム・アプリケーションの変更により、Scale pod の CPU 使用率が増加しました。これは、IBM MQのライブネスとレディネス・プローブのためである。

解決策: ファイル・ハンドルの予約は、環境変数 'AMQ_NO_RESERVE_FD=1 を設定することによってオフにすることができる。 CPU使用率の高さを修正する。

スケール・オペレーターがクォーラム・ラベルの追加に失敗しました

問題ステートメント: ストレージ構成中に、リカバリー・グループの状況が「Waiting on some daemons in the recovery group to be restarted」になることがあります。

解決策

以下のコマンドを実行して、クォーラム・ノードの数を確認します。
```
oc get nodes -l scale.spectrum.ibm.com/designation=quorum
```
クォーラム・ノードの数を確認します。ノード数が 10 未満の場合は、必ず 3 つのクォーラム・ノードが必要です。そうでない場合は、欠落しているノードに以下のクォーラム・ラベルを適用します。
```
scale.spectrum.ibm.com/designation=quorum
```

リモート・ファイル・システム接続が切断状態になる

問題ステートメント: ノードの再始動やその他の問題が原因で 1 つのスケール・コア・ポッドでも準備ができていない場合は、そのノードのファイル・システム・マウントで問題が発生し、ファイル・システム CR がエラーを報告します。その結果、ファイルシステムはDisconnectedになり、 IBM Fusionのユーザーインターフェイスにも同じように表示されます。

解決策: スケール・コア・ポッドが Ready 状態になり、ファイル・システムが自動的に Connected 状態に変わります。

保留状態のままになっている PVC

解決策: PVC が長時間保留状態になっている場合は、Scale GUI ポッドを再始動します。

ポッドがストレージ用にスケジュールされているノードで `crashloobackoff` またはコンテナーでエラーが発生する

問題ステートメント: インストール、アップグレード、またはサイズ変更の操作が進行中で、ストレージ構成がまだ実行されていない場合、ストレージ用にポッドがスケジュールされているノードでは、 crashloobackoff またはコンテナーでエラーが発生します。

解決策: この問題を解決するには、これらの操作を開始する前にこれらのノードでスケジュールを無効にし、ストレージ用に構成されているノードでポッドをスケジュールします。

ファイル・システムが一部のノードにマウントされていません

問題ステートメント: IBM Storage Scale のアップグレード後、ファイル・システムが一部のノードにマウントされません。

解決策

以下の回避策の手順を実行します。

ファイル・システムがマウントされていない問題のあるポッドを削除します。一度に 1 つのポッドを削除します。
ポッドが表示されるまで、ポッドの概要ページを最新表示します。 watch oc get podsを実行します。

問題のポッドが起動したら、 ibm-spectrum-scale-operator 名前空間の Spec セクションでレプリカを 0 に設定します。オペレーターのデプロイメントを即時に停止する必要があります。

ibm-spectrum-scale-operator

名前空間でオペレーター・ポッドが実行されていないことを確認します。オペレーター・レプリカを 0 に設定するためのコマンド:

oc patch deploy ibm-spectrum-scale-controller-manager \
 --type='json' -n ibm-spectrum-scale-operator \
 -p='[{"op": "replace", "path": "/spec/replicas", "value": 0}]'

oc get deployment -n ibm-spectrum-scale-operator

サンプル出力:


I0420 16:56:23.579340    4184 request.go:645] Throttling request took 1.192496025s, request: GET:https://api.isf-rackk.rtp.raleigh.ibm.com:6443/apis/nmstate.io/v1beta1?timeout=32s
NAME                                    READY   UP-TO-DATE   AVAILABLE   AGE
ibm-spectrum-scale-controller-manager   0/0     0            0           28h

問題のポッドが init コンテナー状態になるまで待機し、以下のコマンドを実行します。
```
oc exec podname -- mmsdrrestore -p <any working core ip/name[Specify pod IP where FS is mounted]>
```

前のステップが成功したら、 ibm-spectrum-scale-operator デプロイメントでレプリカを再度 1 に設定します。

オペレーター・ポッドが ibm-spectrum-scale-operator 名前空間で実行されていることを確認します。

オペレーター・レプリカを 0 に設定するには、以下のコマンドを実行します。

oc patch deploy ibm-spectrum-scale-controller-manager \
 --type='json' -n ibm-spectrum-scale-operator \
 -p='[{"op": "replace", "path": "/spec/replicas", "value": 1}]'

oc get deployment -n ibm-spectrum-scale-operator

サンプル出力:

I0420 16:56:23.579340    4184 request.go:645] Throttling request took 1.192496025s, request: GET:https://api.isf-rackk.rtp.raleigh.ibm.com:6443/apis/nmstate.io/v1beta1?timeout=32s
NAME                                    READY   UP-TO-DATE   AVAILABLE   AGE
ibm-spectrum-scale-controller-manager   1/1     0            0           28h

問題のあるポッドが実行状態になり、ファイル・システムがこの問題のあるノードにマウントされるまでしばらく待ちます。

IBM Storage Scale ユーザー・インターフェースが正しくロードされない、または IBM Storage Scale CSI ポッドが `CrashLoopBack` 状態になる

問題ステートメント: 場合によっては、 IBM Storage Scale ユーザー・インターフェースが正しくロードされなかったり、 IBM Storage Scale CSI ポッドが CrashLoopBack 状態になったりすることがあります。

解決策

回避策として、以下のステップを実行します。

GUI ポッドを再始動し、正常に機能しているかどうかを確認します。
GUI ポッドの再始動で IBM Storage Scale コンソールが開かない場合は、 ibm-spectrum-scale-controller-manager ポッドを再始動してから GUI ポッドを再始動します。

IBM Storage Scale ユーザー・インターフェースにログインできない

原因

GUI ポッドの /etc/gui-oauth/oauth.properties ファイルにマウントされているシークレットと、 ibm-spectrum-scale-gui-oauthclient に存在するシークレットが異なります。

gui-1
sh-4.4$ cd /etc/gui-oauth/
sh-4.4$ cat oauth.properties
secret=tjCK6kE0pmCe2d8b7azw
oauthServer=https://oauth-openshift.apps.isf-racka.rtp.raleigh.ibm.com
redirectURI=https://ibm-spectrum-scale-gui-ibm-spectrum-scale.apps.isf-racka.rtp.raleigh.ibm.com/auth/redirect
clientID=ibm-spectrum-scale-gui-oauthclient
k8sAPIServer=https://172.30.0.1:443
sh-4.4$
gui_0
secret=tjCK6kE0pmCe2d8b7azw
oauthServer=https://oauth-openshift.apps.isf-racka.rtp.raleigh.ibm.com
redirectURI=https://ibm-spectrum-scale-gui-ibm-spectrum-scale.apps.isf-racka.rtp.raleigh.ibm.com/auth/redirect
clientID=ibm-spectrum-scale-gui-oauthclient
k8sAPIServer=https://172.30.0.1:443
Oauth client config (API Explorer -> OAuthClient -> ibm-spectrum-scale-gui-oauthclient)
kind: OAuthClient
apiVersion: oauth.openshift.io/v1
metadata:
  name: ibm-spectrum-scale-gui-oauthclient
  uid: a9eb9d85-33b9-4cd7-99c8-ae0213032380
  resourceVersion: ‘314932’
  creationTimestamp: ‘2022-03-29T17:09:38Z’
  labels:
    app.kubernetes.io/instance: ibm-spectrum-scale
    app.kubernetes.io/name: gui
  ownerReferences:
apiVersion: scale.spectrum.ibm.com/v1beta1
      kind: Gui
      name: ibm-spectrum-scale-gui
      uid: da23c696-5c71-405b-b9ac-c7d0ccb4dd43
      controller: true
      blockOwnerDeletion: true
  managedFields:
manager: ibm-spectrum-scale/ibm-spectrum-scale-gui
      operation: Apply
      apiVersion: oauth.openshift.io/v1
      time: ‘2022-03-29T17:09:38Z’
      fieldsType: FieldsV1
      fieldsV1:
        ‘f:grantMethod’: {}
        ‘f:metadata’:
          ‘f:labels’:
            ‘f:app.kubernetes.io/instance’: {}
            ‘f:app.kubernetes.io/name’: {}
          ‘f:ownerReferences’:
            ‘k:{“uid”:“da23c696-5c71-405b-b9ac-c7d0ccb4dd43"}’:
              .: {}
              ‘f:apiVersion’: {}
              ‘f:blockOwnerDeletion’: {}
              ‘f:controller’: {}
              ‘f:kind’: {}
              ‘f:name’: {}
              ‘f:uid’: {}
        ‘f:redirectURIs’:
          ‘v:“https://ibm-spectrum-scale-gui-ibm-spectrum-scale.apps.isf-racka.rtp.raleigh.ibm.com/auth/redirect”’: {}
        ‘f:secret’: {}
*secret: bk2_q1FqwhVhoNqOl7ob*
redirectURIs:
>-
    https://ibm-spectrum-scale-gui-ibm-spectrum-scale.apps.isf-racka.rtp.raleigh.ibm.com/auth/redirect
grantMethod: auto

解決策

解決策として、以下のステップを実行します。

解決策として、GUI ポッドを再始動します。
前のステップ (ステップ 1) で問題が解決しない場合は、 IBM Storage Scale Operator ポッドを再始動してから、GUI ポッドを再始動します。

すべてのデプロイメントのログ・ファイルのダウンロード

すべてのデプロイメントのログ・ファイルをダウンロードできない場合は、ログ・ファイルを個別にダウンロードしてください。

ノード・ドレーンおよびノード再始動の問題

解決策: このようなノード関連の問題を解決するには、 IBM Fusion HCIノードのドレインに関する問題を参照してください。

IBM Storage Scale クラスターは、コンピュート・ノードの電源をオフにした後にリカバリーに失敗しました。

診断

クラスターに結合するノードが許容範囲外の状態にあるかどうかを識別します。

mmhealth は、一部のノードで UNKNOWN RG 状況を報告しました。
mmrepquota コマンドは、おそらく GUI によって繰り返し生成されており、これが原因で多くの長時間待機が発生しています。
長時間の待機が多いため、クラスター・マネージャー・ノードは tsctl nqStatus以外の ts cmd に応答しませんでした。
解決策として、計画外の複数ノードの再起動または障害からストレージクラスタを回復するで定義されている手順に従ってください。

スケール・アップグレード中に MCO ロールアウトが 5 時間を超えて進行しない

原因: ノードがオーバーコミットされ、ポッド制限が使用できない場合は常に、ポリシー・ロールアウト、ICSP、プル・シークレット、および MCO ロールアウトの変更で遅延が発生する可能性があります。

解決策

解決策として、以下のステップを実行します。

IBM Fusion HCI ノードは、デフォルトで定義されているノード上のポッドの最大数を許可します。 OpenShift® Container Platform を許可し、その数を制限内に保つようにします。そうしないと、この問題が発生する可能性があります。

IBM Storage Scale クラスターの状況が「クリティカル」状態になる

原因: filesystem CR に unmounted_fs_check が存在するため、 IBM Storage スケールクラスターの状況がクリティカル状態になっています。

解決策: 解決策として、この filesystem CR 状況がクリアされるまで待ちます。クリアされると、 IBM Storage Scale クラスター状況は自動的に正常な状態に戻ります。この問題が長く続くようであれば、 IBM までご連絡ください。

ディスクのアップサイズの問題

/dev マウントをテストするための手動ステップ:
新規 NVMe ディスクをサーバーに追加した後、 IBM Storage Scale ポッドで新規ディスクをディスカバーできません。ディスクは、ポッド内の /dev/nvme* デバイス名とともに表示されません。 IBM Storage Scale では、ディスクにアクセスするためにデバイス名 /dev/nvme* が必要です。 /dev/nvme* 装置名がないと、新規ディスクをリカバリー・グループに追加できません。
解決策
ポッド内の /dev にディスクをマウントするには、以下の手動ステップを実行します。
1. 各 IBM Storage Scale ストレージ・ポッドにログインします。
  oc exec -it <pod name> -c <container> /bin/sh
2. 1 つ以上のノードで GPFS デーモンを停止します。
  mmshutdown
3. 以下のコマンドを実行して、ホストから /dev をマウントします。
  mount -t devtmpfs none /dev
4. /dev の内容がホストからのものであること、および block、bus、char などのサブディレクトリーが表示されていることを確認します。
  mmstartup

グローバル・データ・プラットフォーム ・サービスの問題

リモートファイルシステムからのファイルシステムのステータスがConnecting（接続中）状態で止まっている

Cloud Pak for IntegrationCP4I へのアップグレード後、Scale ポッドで CPU 使用率が増加しました

スケール・オペレーターがクォーラム・ラベルの追加に失敗しました

リモート・ファイル・システム接続が切断状態になる

保留状態のままになっている PVC

ポッドがストレージ用にスケジュールされているノードで crashloobackoff またはコンテナーでエラーが発生する

ファイル・システムが一部のノードにマウントされていません

IBM Storage Scale ユーザー・インターフェースが正しくロードされない、または IBM Storage Scale CSI ポッドが CrashLoopBack 状態になる

IBM Storage Scale ユーザー・インターフェースにログインできない

すべてのデプロイメントのログ・ファイルのダウンロード

ノード・ドレーンおよびノード再始動の問題

IBM Storage Scale クラスターは、コンピュート・ノードの電源をオフにした後にリカバリーに失敗しました。

スケール・アップグレード中に MCO ロールアウトが 5 時間を超えて進行しない

IBM Storage Scale クラスターの状況が「クリティカル」状態になる

ディスクのアップサイズの問題

グローバル・データ・プラットフォーム・サービスの問題

ポッドがストレージ用にスケジュールされているノードで `crashloobackoff` またはコンテナーでエラーが発生する

IBM Storage Scale ユーザー・インターフェースが正しくロードされない、または IBM Storage Scale CSI ポッドが `CrashLoopBack` 状態になる