-
null
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年10月19日
章のタイトル： HX Data Platform のトラブルシューティング
- 一般的な TAC 支援サポート トピック
- Cisco TAC への連絡
- Cisco HX Data Platform サポート バンドル
- 複数のデータストア追加時のエラー：ホスト上にマウント ポイントが見つからない
- NFS 全パス ダウンが発生し [File Locked by Consumer on Host] メッセージが表示される
- VLAN ID の変更後、データストアのマウントに失敗する
- データ vSwitch に IP アドレス設定済みの VM カーネル ポートがある場合、データストアのマウントが失敗する
- クラスタ再起動後のデータストアのマウント解除
- ストレージ I/O RM デーモンの実行時にデータストアのマウント解除ができない
- エラー「com.vmware.vim25.PlatformConfigFault」を伴うデータストア削除の失敗
HX Data Platform のトラブルシューティング
- 一般的な TAC 支援サポート トピック
- Cisco TAC への連絡
- Cisco HX Data Platform サポート バンドル
- クラスタのインストール、アップグレード、拡張に関する問題
- ホストの問題
- ディスクの問題
- VM の問題
- キャパシティの問題
- データストアの問題
- ReadyClone とスナップショットの問題
- クラスタの問題
一般的な TAC 支援サポート トピック
以下に、テクニカル アシスタンス センター（TAC）の支援によって扱われることの多いサポート トピックの一覧を示します。
-
HX ストレージ クラスタ内のノードにディスクを追加しても認識されない。
-
HX ストレージ クラスタへのノードの追加が失敗する。
-
HX ストレージ クラスタの IP アドレスを変更する。
-
暗号化されたクラスタの破壊を含む、クラスタの破壊。
-
HX Data Platform のバージョンのダウングレード。
-
HX ストレージ クラスタ作成の失敗。
-
ノード再調整のタイムアウトの変更。
-
HX ストレージ クラスタ用に最適化されて導入された VDI または VSI の変更。
-
3 ノード クラスタ内のノードの削除。
-
4 ノード クラスタ内のノードの交換。
-
HX240c サーバ上でのハウスキーピング SSD の交換。
-
別の HX ストレージ クラスタで削除したノードの再使用。
-
削除されたノードのディスクの再利用。
-
ストレージ回復用の cleaner スケジュールの設定。
-
MTU 値の 9000 以外への設定。
-
サーバ単位でのデフォルトでない大容量 SSD や HDD を使用する際のサイジングのガイダンスがサポート対象。
-
HX Data Platform のアンインストール。
-
HX ストレージ クラスタのアンインストール。
-
HX Data Platform バージョン 1.7.1 より古いバージョンからの HX Data Platform のアップグレード。
-
stcli コマンドの whitelist または recreate の使用。
Cisco TAC への連絡
問題解決時間を短縮するために Cisco Technical Assistance Center（TAC）のケースをオープンして、Cisco PRIME コラボレーション アプリケーションから直接効率的なサポートを受けることができます。
シスコ サービス契約が有効なお客様、パートナー、リセラー、ディストリビュータは、Cisco Technical Support で受賞暦のあるテクニカル サポート サービスを 24 時間体制で受けることができます。Cisco Technical Support Web サイトでは、シスコ製品やシスコ テクノロジーに関する技術的な問題を解決するためのオンラインのドキュメントやツールをご利用いただけます。
http://www.cisco.com/techsupport
TAC Support Case Manager オンライン ツールを利用することで、最も素早く S3 および S4 のサポート ケースを開くことができます（S3 および S4 サポート ケースは、最小限のネットワーク障害の問題と製品情報リクエストから構成されます）。状況をご説明いただくと、TAC Support Case Manager が自動的に推奨する解決方法を提供します。推奨リソースを使っても問題を解決することができなかった場合、TAC Support Case Manager がお客様のサポート ケースを Cisco TAC のエンジニアに割り当てます。以下の場所から、TAC Support Case Manager にアクセスできます。
https://mycase.cloudapps.cisco.com/case
S1 または S2 のサポート ケースに関して、またはインターネット アクセスがない場合は、電話で Cisco TAC にご連絡ください（S1 または S2 サポート ケースは、著しいパフォーマンスの低下または停止などの製品のネットワークの問題から構成されています）。お客様の業務を円滑に続行できるように、S1 および S2 のサポート ケースは、迅速に Cisco TAC エンジニアに割り当てられます。
電話でサポート ケースを開く場合は、次のいずれかの電話番号をご利用ください。
-
アジア太平洋地区：+61 2 8446 7411
-
オーストラリア：1 800 805 227
-
EMEA：+32 2 704 55 5555
-
USA: 1 800 5532447
企業およびサービス プロバイダー製品に関する Cisco TAC の連絡先の一覧については、http://www.cisco.com/c/en/us/support/web/tsd-cisco-worldwide-contacts.html を参照してください。
Cisco Small Business Support Center（SBSC）の連絡先の一覧については、http://www.cisco.com/c/en/us/support/web/tsd-cisco-small-business-support-center-contacts.html を参照してください。
Cisco HX Data Platform サポート バンドル
サポート バンドルは、コマンドライン インターフェイス、または vCenter Web クライアントから生成できます。コマンドライン オプションは、vCenter Web クライアントを使った従来のログ収集よりも大幅に高速です。
また、HX Connect ユーザ インターフェイスでは、HX ストレージ クラスタにあるすべてのコントローラ VM および ESXi ホスト からログを収集するサポート バンドルを生成することもできます。vCenter ログは HX Connect からは収集されません。
すべてのサポート バンドルのタイムスタンプは、クラスタのタイムゾーンまたはサーバのタイムゾーン設定に関係なく、UTC タイムゾーンで表示されます。
生成したサポート バンドルは、TAC で使用するために HX Data Platform FTP サーバにアップロードできます。既存のサポート バンドルをダウンロードすることもできます。
- コントローラ VM からのログの収集
- ESXi ホストからのログの収集
- Cisco HX Data Platform インストーラ VM からの導入ログの収集
- vCenter Server からのログの収集
- vSphere Web Client からのログの収集
- Cisco HX Data Platform Plug-in からのログ収集
- 既存のサポート バンドルのダウンロード
- サポート バンドルのアップロード
コントローラ VM からのログの収集
コントローラ VM のログを収集するオプションは 2 つあります。
ESXi ホストからのログの収集
ESXi ホストのログを収集するオプションは 2 つあります。
サポート バンドル生成時のスペース不足エラー
コア ファイルのサイズや以前に生成されたログ ファイルによってスペースが使用されていることなどが原因で、ストレージ コントローラ VM にサポート バンドルを生成できる十分なスペースがない場合、スペース不足エラーが発生します。サポート バンドルを生成するために vm-support コマンドを使用すると、次のエラーが表示されます。
error = [Errno 28] No space left
このエラーを受信した場合にサポート バンドルを生成するには、次の手順を実行します。
Cisco HX Data Platform インストーラ VM からの導入ログの収集
vCenter Server からのログの収集
vSphere Web Client からのログの収集
vSphere Web Client から、Cisco HX データ プラットフォーム ストレージ クラスタ ESXi ホスト、コントローラ VM、vCenter サーバのログの一部またはすべてを選択的に収集できます。
Cisco HX Data Platform Plug-in からのログ収集
HX Data Platform Plug-in を使用して、HX ストレージ クラスタ ESXi ホストとコントローラ VM のログを収集できます。
既存のサポート バンドルのダウンロード
 （注） | 生成したサポート バンドルは、ローカル コントローラ VM の時刻で午前 0 時（12:00 a.m）までダウンロードできます。午前 0 時を過ぎると、システムはサポート バンドルを削除します。 |
サポート バンドルのアップロード
サポート バンドルを生成したら、次のいずれかの方法で HX Data Platform FTP サーバにアップロードできます。
ftp または stfp を使用したサポート バンドルのアップロード
サポート バンドルを生成します。
| ステップ 1 | FTP クライアント（Filezilla など）を開き、次の情報を使用して HX Data Platform FTP サーバに接続します。
| ||||||||||
| ステップ 2 | HX Data Platform FTP サーバに接続したら、サポート ケース番号を使用してフォルダを作成します。 | ||||||||||
| ステップ 3 | ディレクトリを新しいフォルダに変更します。 | ||||||||||
| ステップ 4 | このフォルダにサポート バンドルのログ ファイルをアップロードします。 | ||||||||||
| ステップ 5 | アップロードが完了したら、Cisco テクニカル アシスタンス センター（TAC）に連絡して、そのアップロード ディレクトリの名前を通知します。 | ||||||||||
| ステップ 6 | HX ストレージ クラスタのスペースを解放するため、/var/support/ の内容を削除します。 |
sftp を使用したサポート バンドルのアップロード
サポート バンドルを作成します。
| ステップ 1 | FTP クライアント（Filezilla など）を開き、次の情報を使用して HX Data Platform FTP サーバに接続します。
|
| ステップ 2 | HX Data Platform FTP サーバに接続したら、サポート ケース番号を使用してフォルダを作成します。 |
| ステップ 3 | ディレクトリを新しいフォルダに変更します。 |
| ステップ 4 | このフォルダにログ ファイルをアップロードします。 |
| ステップ 5 | アップロードが完了したら、テクニカル アシスタンス センター（TAC）に連絡して、そのアップロードのディレクトリ名を通知します。 |
| ステップ 6 | ストレージ クラスタのスペースを解放するため、/var/support/ の内容を削除します。 |
https を使用したサポート バンドルのアップロード
サポート バンドルを生成します。
| ステップ 1 | ブラウザ ウィンドウを開き、Springpath でホストされている HX Data Platform FTP サーバの URL に移動し、次の情報を使用してログインします。
| ||||||||
| ステップ 2 | HX Data Platform FTP サーバに接続したら、サポート ケース番号を使用してフォルダを作成します。 | ||||||||
| ステップ 3 | ディレクトリを新しいフォルダに変更します。 | ||||||||
| ステップ 4 | このフォルダにサポート バンドルのログ ファイルをアップロードします。 | ||||||||
| ステップ 5 | アップロードが完了したら、Cisco テクニカル アシスタンス センター（TAC）に連絡して、そのアップロード ディレクトリの名前を通知します。 | ||||||||
| ステップ 6 | HX ストレージ クラスタのスペースを解放するため、/var/support/ の内容を削除します。 |
クラスタのインストール、アップグレード、拡張に関する問題
HX Data Platform と UCS Manager 間で異なる構成の設定
説明
ストレージ クラスタのインストール、アップグレード、拡張プロセス実行時に、HX Data Platform インストーラは入力された構成の設定と UCS Manager 内の設定を確認します。たとえば次のシナリオで、不一致が生じる場合があります。
-
検証や設定を適用できるようになるまでに、以前関連付けられていなかったサーバがそうではなくなることがあります。これらのサーバは関連付けを解除する必要があります。
-
HX Data Platform ストレージ クラスタに以前関連付けられていたサーバを使用しています。これらのサーバは関連付けを解除する必要があります。
-
既存のストレージ クラスタの設定情報を手動で入力すると、エラーが生じやすくなります。VLAN ID や LAN 設定などの情報は、UCS Manager に表示される情報と一致している必要があります。以前保存した設定ファイルを使用して設定をインポートしてください。
アクション：既存の設定をインポートする
ストレージ クラスタのインストール、アップグレード、拡張を完了すると、設定を保存するオプションが利用できるようになります。このオプションを使ってクラスタの設定情報を保存し、ストレージ クラスタに変更を加える必要が生じたときは、ファイルに保存されている構成の詳細情報をインポートします。
アクション：サーバの関連付けを解除する
UCS Manager を使ってサーバの関連付けを解除する手順については、『Cisco HyperFlex Systems Getting Started Guide』を参照してください。簡単に手順を説明すると以下のようになります。
FQDN による DNS エラーでクラスタの作成に失敗する
説明
ストレージ クラスタのオブジェクトを識別するために完全修飾ドメイン名（FQDN）を指定すると、クラスタの作成が失敗することがあります。通常は、指定したドメイン ネーム サービス（DNS）サーバが利用できないために起こります。
これは、ドメイン名または IP アドレスで識別する HX Data Platform インストーラ オブジェクトとして入力されるすべてのドメイン名オブジェクトに当てはまります。これには、vCenter Server、ESX サーバ、コントローラ VM のアドレス、ストレージ クラスタ管理またはデータ ネットワークのアドレス、DNS サーバ、NTP サーバ、メール サーバ、または SSO サーバがあります。
アクション: DNS サーバを確認する
| ステップ 1 | HX Data Platform インストーラ VM のコマンド ラインにログインします。たとえば、ssh を使用します。 |
| ステップ 2 | 指定された DN サーバが動作することを確認します。 |
| ステップ 3 | クラスタの作成に必要な各オブジェクトが、指定された DNS サーバから解決できることを確認します。これらのオブジェクトは、JSON ファイルまたは HX DP インストーラ GUI フィールドを通じて指定されます。 |
| ステップ 4 | 手順 2 または手順 3 のいずれかが確認できない場合、HX Data Platform Installer GUI では完全修飾ドメイン名（FQDN）ではなく、IP アドレスのみを使用します。 |
DNS サーバが見つからないためにクラスタの拡張が失敗する
説明
ストレージ クラスタの拡張では、新しいノードを FQDN ではなく、IP アドレスを使用して指定する場合でも、DNS サーバが必要です。HX Data Platform インストーラは、クラスタの作成中に指定されたすべての DNS サーバをチェックします。
-
以前指定された DNS サーバのいずれかが到達不可能な場合、クラスタの拡張は失敗します。
-
HX Data Platform のインストール時に DNS サーバを指定しなかった場合、クラスタの拡張は失敗します。
これらの条件のいずれかが当てはまる場合は、是正措置を実行します。
アクション：正しい DNS サーバを特定して指定する
| ステップ 1 | 任意の HX コントローラ VM のコマンド ラインにログインします。たとえば、ssh を使用します。 |
| ステップ 2 | ストレージ クラスタに設定されている DNS サーバを特定します。
# stcli services dns show サンプル応答 10.64.1.8 10.64.1.9 DNS のアドレスが表示されない場合は、手順 4 に進みます。 |
| ステップ 3 | ストレージ クラスタで利用できなくなっているすべての DNS サーバを削除します。
# stcli services dns remove --dns <dns_server> |
| ステップ 4 | ストレージ クラスタに新しい DNS サーバを追加します。
ストレージ クラスタを作成したときに DNS サーバを指定しなかった場合は、疑似 DNS サーバを追加します。 # stcli services dns add --dns <dns_server> |
| ステップ 5 | クラスタの作成に必要な各オブジェクトが、指定された DNS サーバから解決できることを確認します。これらのオブジェクトは、JSON ファイルまたは HX DP インストーラ GUI フィールドを通じて指定されます。 |
| ステップ 6 | 指定された DN サーバが動作することを確認します。 |
| ステップ 7 | 手順 5 と手順 6 を繰り返し、追加されたすべての DNS サーバが有効で、すべての HXDP オブジェクトが各 DNS サーバを通じて解決できることを確認します。 |
| ステップ 8 | HX Data Platform インストーラに戻り、ストレージ クラスタの拡張を続行します。 |
古い HX インストーラによりクラスタの拡張が失敗する
説明
拡張のために追加したクラスタ ノードが間違ったクラスタに追加されます。これは、複数のクラスタの作成で同じ HX Data Platform インストーラを使用し、その後、その同じ HX DP インストーラを使用してそれらクラスタの 1 つを拡張する場合に起こります。HX DP インストーラは、デフォルトでは最新のクラスタにノードを追加します。
アクション： HX Data Platform インストーラ OVA を再展開する
| ステップ 1 | HX Data Platform インストーラ OVA を再展開します。 |
| ステップ 2 | 新しい HX Data Platform インストーラを使用してクラスタを拡張します。 |
クラスタ起動コマンド エラー：Node Not Available
説明
オフライン アップグレード後、VMware EAM の問題により、一部のコントローラ VM が再起動しないことがあります。stcli start cluster コマンドが「Node not available」というエラーを返します。
アクション：コントローラ VM の電源を手動でオンにして、ストレージ クラスタを起動してください。
vCenter の問題によりノードがアップグレードに失敗する
説明
オンライン アップグレード中に、vCenter デーモンがノード上でクラッシュすることがあります。クラッシュした場合は、ノードで HX メンテナンス モードを開始できません。HX メンテナンス モードが開始されないと、ノードでアップグレードを完了できません。vCenter が正常に機能している他のすべてのノードでは、アップグレードが完了します。
アクション：影響を受けたノードでアップグレードを実行し直してください。
1. vCenter の問題を修正します。
2. クラスタ内の任意のノードからアップグレードを再開します。
手順の詳細
| ステップ 1 | vCenter の問題を修正します。 |
| ステップ 2 | クラスタ内の任意のノードからアップグレードを再開します。
HX Data Platform は、すでにアップグレードしているノードをスキップし、先に進んでアップグレードできていないノードのアップグレードを完了します。 |
ノードが正常な状態に戻るのを待機してアップグレードが停止する
説明
LSI のバージョンがバージョン 9 よりも古い場合、ノードでのアップグレード時にディスクが見つからないことがあります。ノードが正常でない場合、アップグレードを続行できません。
LSI バージョン 9 は、UCS ファームウェア バージョン 2.2(6f) と 2.2(7c) に関連付けられています。
アクション：ノードを手動で再起動する
| ステップ 1 | コントローラ VM コマンド ラインにログインします。たとえば ssh を使用します。 |
| ステップ 2 | ディスクが表示されていることを確認します。lsscsi コマンドを実行します。
# lsscsi [2:0:0:0] disk ATA INTEL SSDSC2BB12 CS01 /dev/sdb [2:0:1:0] disk SEAGATE ST1200MM0088 N003 /dev/sdc [2:0:2:0] disk SEAGATE ST1200MM0088 N003 /dev/sdd [2:0:3:0] disk SEAGATE ST1200MM0088 N003 /dev/sde [2:0:4:0] disk SEAGATE ST1200MM0088 N003 /dev/sdf [2:0:5:0] disk SEAGATE ST1200MM0088 N003 /dev/sdg [2:0:6:0] disk SEAGATE ST1200MM0088 N003 /dev/sdh [2:0:7:0] disk ATA INTEL SSDSC2BX48 CS01 /dev/sdi [3:0:0:0] disk VMware Virtual disk 1.0 /dev/sda |
| ステップ 3 | ノードを手動で再起動します。 |
ホストの問題
手動による ESX インストール後の statsd の再起動
説明
手動で HX データ プラットフォーム サーバに ESX を再インストールした後、パフォーマンス統計情報が正しく表示されるように、stats daemon をリセットします。
アクション：stats daemon の再起動
services.sh restart 実行時の scvmclient 管理サービスの再起動
説明
services.sh restart を実行すると、scvmclient 管理サービスが再起動する。
アクション：方法を選択する
ESX サーバの再起動によるアップグレードの終了とメンテナンス モードの開始
説明
アップグレード中の ESX サーバの電源リセットにより、アップグレードが終了し、サーバでメンテナンス モードが開始されます。
アクション：メンテナンス モードの手動での終了
手動でサーバのメンテナンス モードを終了します。アップグレードが続行します。
EAM がコンピューティング ノードで起動しない
説明
EAM がコンピューティング ノードで自動的に再起動しませんでした。
アクション：EAM を手動で再起動する
ノードがダウンした場合、ノードの削除に失敗する
説明
3 つのノードだけが稼働している場合にはノードを削除することはできません。
アクション：はじめに交換ノードを追加する
3 ノード クラスタ内のノードを交換する場合は、TAC によるサポートが必要です。ノードで障害が発生しているためにクラスタのノード数が 3 になった場合、ノードを交換するには TAC によるサポートが必要です。
HA が有効になっている ESX ホストの再起動
説明
システムがアクセスできないストレージ クラスタのホストの HA を有効にした場合、ESX ホストを再起動すると、ストレージ コントローラ VM の電源がオフになります。
これは、VMware の HA 障害の処理方法と ESX Agent Manager（EAM）設定間の相互作用によるものです。これにより、ストレージ コントローラ VM が、復元後に電源オンにならない現象が生じる可能性があります。
アクション：HA が有効になっている ESX ホスト上でストレージ コントローラ VM の電源をオンにする
クラスタへの別ノード同時追加時のノード障害
説明
既存のストレージ クラスタにノードを追加する場合、ストレージ クラスタは、再調整が完了するまで元のストレージ クラスタと同じ HA 復元力を持ち続けます。
たとえば、3 ノードのストレージ クラスタがあり、2 つのコンバージド ノードをストレージ クラスタに追加する場合などです。再調整が完了するまで、ストレージ クラスタは、5 ノードのストレージ クラスタではなく、3 ノードのストレージ クラスタとして動作します。したがって、バランスの再調整が完了する前にノードで障害が発生すると、ストレージ クラスタのステータスは低下します。
通常、再調整は 24 時間ごとの再調整スケジュール、ノード障害の 2 時間後、またはストレージ クラスタがスペース不足の場合に発生します。
アクション：ストレージ クラスタの再調整を手動で開始する
vNIC または vHBA の変更後の PCI パススルーの設定
説明
vNIC または vHBA を手動で HX サービス プロファイルまたはサービス プロファイル テンプレートに追加すると、PCI デバイスが再列挙され、VMware directpath I/O 設定が失われます。サービス プロファイルを変更すると、ホスト ハードウェアが更新されるため、PCI パススルーを再設定する必要があります。サービス プロファイルを変更した ESX ホストごとに次の手順を実行します。
変更した ESX ホストのストレージ コントローラ VM で次の手順を実行します。
アクション：ESX ホスト上で vSphere サービス プロファイルを更新する
| ステップ 1 | ESX ホストを HX メンテナンス モードにします。 |
| ステップ 2 | サービス プロファイルで変更（ハードウェアの追加など）を行うか、変更を確認します。 |
| ステップ 3 | ESX ホストをリブートします。
このホストのダイレクト パス設定が失われます。 |
| ステップ 4 | vCenter にログインして、[DirectPath I/O Configuration] ページを選択します。
vCenter クライアントで、 の順に選択します。 vCenter Web クライアントの [vCenter Inventory] で、 の順に選択します。 |
| ステップ 5 | パススルー用の LSI カードを選択します。 |
| ステップ 6 | ESX ホストをリブートします。 |
| ステップ 7 | HX ストレージ コントローラ VM（StCtlVM）の設定を編集して、PCI デバイスを HX ストレージ コントローラ VM に再マップします。 |
| ステップ 8 | ESX ホストの HX メンテナンス モードを終了します。
ホストが再びアクティブになると、HX ストレージ コントローラ VM が正常にブートして、ストレージ クラスタに再参加します。 |
vNIC または vHBA の変更後の PCI パススルーの設定
説明
vNIC または vHBA を手動で HX サービス プロファイルまたはサービス プロファイル テンプレートに追加すると、PCI デバイスが再列挙され、VMware directpath I/O 設定が失われます。サービス プロファイルを変更すると、ホスト ハードウェアが更新されるため、PCI パススルーを再設定する必要があります。サービス プロファイルを変更した ESX ホストごとに次の手順を実行します。
変更した ESX ホストのストレージ コントローラ VM で次の手順を実行します。
アクション：ESX ホスト上で vSphere サービス プロファイルを更新する
| ステップ 1 | ESX ホストを HX メンテナンス モードにします。 |
| ステップ 2 | サービス プロファイルで変更（ハードウェアの追加など）を行うか、変更を確認します。 |
| ステップ 3 | ESX ホストをリブートします。
このホストのダイレクト パス設定が失われます。 |
| ステップ 4 | vCenter にログインして、[DirectPath I/O Configuration] ページを選択します。
vCenter クライアントで、 の順に選択します。 vCenter Web クライアントの [vCenter Inventory] で、 の順に選択します。 |
| ステップ 5 | パススルー用の LSI カードを選択します。 |
| ステップ 6 | ESX ホストをリブートします。 |
| ステップ 7 | HX ストレージ コントローラ VM（StCtlVM）の設定を編集して、PCI デバイスを HX ストレージ コントローラ VM に再マップします。 |
| ステップ 8 | ESX ホストの HX メンテナンス モードを終了します。
ホストが再びアクティブになると、HX ストレージ コントローラ VM が正常にブートして、ストレージ クラスタに再参加します。 |
ディスクの問題
3 ノードのストレージ クラスタ上で、すべてまたは大半のディスクに障害が発生すると、データの割り当てができない
説明
ノード上のすべてのハード ディスクに障害が発生すると、HX Data Platform はノードにデータを割り当てることができません。3 ノードのストレージ クラスタでこの問題が発生した場合、HX Data Platform は、データの整合性を維持する上で最低限必要な 3 つのデータのコピーを維持することができません。その結果、仮想的な ENOSPC 状態となります。
ノード上で複数のハード ディスクに障害が発生し続けた場合、ストレージ クラスタはノードへの書き込みを行おうとし、ディスク上の残りの領域を使用することから、不安定な状態となります。たとえば、3 つのノードすべてに 10 台の HDD があり、3 番目のノード上で 9 台の HDD に障害が発生した場合、不安定な状況が生じた結果、3 番目のノード上のディスクでは、クラスタのサイズが実際のサイズの 10 % に制限されます。これは、物理的な ENOSPC 状態です。また、オール パス ダウン（APD）状態を引き起こす可能性もあります。
アクション：ストレージ クラスタ内のすべてのノード上で、ストレージを物理的に調整します。
ディスクを削除するとストレージ コントローラ VM の再起動に失敗する
説明
ディスクを削除して、自動再スキャンが完了する前にストレージ コントローラ VM を再起動した場合、ストレージ コントローラ VM の電源がオンにならない場合があります。
アクション：ディスクの削除後にストレージ コントローラ VM の電源をオンにする
ストレージ コントローラ VM 上で障害が発生した SSD を復旧させる
説明
ストレージ コントローラ VM をホストする SSD に障害が発生した場合、SSD を復旧させる必要があります。
アクション：障害が発生した SSD を復旧させる
| ステップ 1 | 障害が発生した SSD を搭載したホストのコマンドラインにログインします。 |
| ステップ 2 | SSD のステータスが [dead timeout] になっていることを確認します。
esxcli storage core device list -d SSD_ID | grep 'Status:' Status: dead timeout |
| ステップ 3 | ストレージ コントローラ VM の vmx をすべて強制終了させます。
ps | grep vmx | grep -i stCtlvm kill -9 process_id_of_controller_vm |
| ステップ 4 | ストレージ アダプタを再スキャンします。
esxcli storage core adapter rescan -a |
| ステップ 5 | 同じ仕様の新しい SSD にディスクを置き換えます。 |
| ステップ 6 | hostd を再起動します。 |
| ステップ 7 | ストレージ コントローラ VM の電源をオンにします。 |
VM の問題
HA および DRS が有効な状態でホストに VM を追加できない
説明
ユーザ VM の電源オンが「All required agent virtual machines are not currently deployed on host 'hostname' and the controller VM on the same ESX host is down.」で失敗します。
HA では、エージェントとしてマークされているいずれかの VM（この場合はコントローラ VM）の電源がオンではない場合には、ホスト上で VM の電源をオンにすることはできません。
DRS がこのホストにユーザ VM を配置する場合、この VM は電源オンになりません。
アクション：次の手順を実行する。
ディスク共有の制限が設定された VM でのパフォーマンス低下
説明
ディスク共有の制限が設定された VM の電源がオンになると、各データストアのパフォーマンスが低下する。
アクション：VMware 単位で想定されている動作です。
ストレージ クラスタが読み取り専用状態の場合の DRS による VM の移行
説明
ストレージ クラスタが読み取り専用状態になっていると、それらがすでに読み取り専用のストレージ クラスタにある場合であっても、VMware DRS プロセスは VM をデータストアに移行します。その結果 VM は起動不可になります。
アクション：ストレージ クラスタが読み取り専用状態の場合には、DRS を手動で無効にします。
古い EAM 拡張により VM の電源オンに失敗する
説明
HX Data Platform を部分的にインストールまたはアンインストールした場合、HX Data Platform 拡張用の古い ESX Agent Manager（EAM）が残る場合があります。これにより、HX Data Platform のインストール完了後に、仮想マシンの電源オンが妨げられる場合があります。Managed Object Browser（MOB）拡張マネージャを使用して、古い拡張を削除します。
アクション：古い EAM HX Data Platform 拡張を削除する
| ステップ 1 | まだの場合、vSphere ESX Agent Manager SDK をダウンロードします。 |
| ステップ 2 | vSphere クラスタからデータセンターを削除します。 |
| ステップ 3 | vCenter サーバ MOB 拡張マネージャにログインします。 |
| ステップ 4 | 以前のストレージ クラスタ拡張を探します。リストをスクロールして、ストレージ クラスタ拡張を探します。
com.springpath.sysgmt.cluster_uuid |
| ステップ 5 | ストレージ クラスタ拡張の登録を解除します。 |
| ステップ 6 | [ExtensionManager] タブを更新し、[extensionList] エントリに com.springpath.sysgmt.cluster_uuid が含まれていないことを確認します。 |
| ステップ 7 | HX Data Platform のインストールを実行し完了します。
古い EAM 拡張の削除に関する追加オプションについては、テクニカル アシスタンス センター（TAC）に確認してください。 |
VM フォルダやファイルの削除に非常に長い時間がかかる
説明
ユーザ VM が、ファイル システム内に残っているユーザ VM 向けに作成された ESX *.lck ファイルや、vSphere にアクセスできなくなった場合、VM ファイルやフォルダの削除には非常に長い時間がかかる場合があります。
アクション：ESX サーバの VM ロック ファイルをクリアする
VM ディスク使用率と vCenter VM コミット サイズの不一致
説明
VM にスナップショットまたは ReadyClone がある場合、VM ディスク使用率が vCenter の仮想マシン コミット サイズと一致しません。
アクション：なし
キャパシティの問題
プロビジョニングとは異なるクラスタ キャパシティ
説明
HX Data Platform プラグイン内で、[Summary] タブのクラスタ キャパシティと [Manage] タブのプロビジョニングされたキャパシティに、ストレージ クラスタに割り当てられたストレージ量と異なる数値の表示されることがあります。これは、次のような状況で発生します。
-
クリーナーが未完了。VM は削除されたが、クリーナーが実行されていない。クリーナーは自動プロセスであり、完了後にクラスタ キャパシティとプロビジョニングされた量が一致する必要があります。クリーナー コマンドに関する情報については、『Cisco HX Data Platform Command Line Interface Reference guide』を参照してください。
-
シック プロビジョニングまたはシック クローン。シック ディスクまたはクローンが作成された場合、HX Data Platform は領域を確保しません。ソフト予約が使用され、データストアに使用された領域が表示されますが、領域はストレージ クラスタ内で使用されていません。これは、データストアをオーバー プロビジョニングすることがないように、管理者を支援する目的で設計されたものです。
アクション：ありません。
データストアの問題
複数のデータストア追加時のエラー：ホスト上にマウント ポイントが見つからない
説明
VMware の問題により、同時に複数のデータストアを追加しようとして、一部のデータストアがマウントされないことがあります。
アクション：データストアを再マウントする
-
一度にマウントするデータストアを減らしてマウントします。
HX プラグインを使用して、最初にマウントされなかったデータストアを再マウントします。
NFS 全パス ダウンが発生し [File Locked by Consumer on Host] メッセージが表示される
説明
シリアル I/O 制御（SIOC）に関する VMware の問題が原因で、NFS 全パス ダウン（APD）が発生し、次のようなメッセージが表示されます。
NFSLock: 2210: File is being locked by a consumer on host host_name with exclusive lock.
アクション：[Storage I/O Control] を切り替える
VLAN ID の変更後、データストアのマウントに失敗する
説明
ストレージ クラスタの作成後に VLAN ID を変更すると、データストアのストレージ クラスタへのマウントに失敗します。既存のデータストアを、ストレージ クラスタからマウント解除することはできます。
アクション：ESX サーバのファイアウォールをリロードします。
ESX サーバのファイアウォールのリロードに関する指示については、VMware ESX のマニュアルを参照してください。
データ vSwitch に IP アドレス設定済みの VM カーネル ポートがある場合、データストアのマウントが失敗する
説明
VMware の構成要件ごとに IP アドレスもしくはルールが重複する場合、接続が失われます。
アクション：トラフィックが意図した VM カーネル インターフェイスを使用しているか確認します。
次を設定します。
クラスタ再起動後のデータストアのマウント解除
説明
ストレージ クラスタが正常な状態に戻った後、既存のデータストアが自動的に再マウントされない場合があります。これは、1 つ以上のノードがダウンしている間にストレージ クラスタが再起動されたか、ストレージ クラスタの再起動に長い時間がかかっている場合に発生する場合があります。
アクション：データストアをマウントする。
方法を選択します。
ストレージ I/O RM デーモンの実行時にデータストアのマウント解除ができない
説明
VMware の Storage I/O RM 機能が有効になっている場合、データストアで Storage I/O RM が有効になっていない場合でも、VMware が Storage I/O RM の追跡ファイルに書き込みを行うバグがあります。これらの追跡ファイルが、HX Data Platform のデータストアのマウント解除を妨げます。
アクション：マウント解除を再試行する。
エラー「com.vmware.vim25.PlatformConfigFault」を伴うデータストア削除の失敗
説明
VSphere がランダムなデータストアを選択してハートビートに使用する、既知の VMware の問題があります。これはデータ ストアを削除しようとする HX Data Platform の操作をブロックします。VMware KB の「Unmounting or removing a datastore in a HA cluster fails with the error: The vSphere HA agent on host failed to quiesce file activity on datastore (2055137)」を参照してください。
アクション：ESXi ホストと vCenter をチェックしてからデータストアの削除を再試行する
| ステップ 1 | VM がデータストアで実行されていないことを確認します。 |
| ステップ 2 | ESX ホストから、HX Data Platform のデータストアが VMware サービス storageRM で使用されているかどうかを確認します。
# ls -ltra /vmfs/volumes/stfs-ds1/ | grep -i iorm -rwxr-xr-x 1 root root 16511 Jan 20 20:05 .iormstats.sf drwxr-xr-x 1 root root 1125 Jan 20 20:06 .iorm.sf |
| ステップ 3 | storagerm のステータスを確認します。
# /etc/init.d/storageRM status storageRM is running |
| ステップ 4 | storageRM サービスを停止します。
# /etc/init.d/storageRM stop watchdog-storageRM: Terminating watchdog process with PID 34096 storageRM stopped |
| ステップ 5 | または、vSphere HA を無効にします。
|
| ステップ 6 | データストアの削除を再試行してください。 |
| ステップ 7 | VSphere HA を無効にしていた場合は再度有効にします。 |
| ステップ 8 | 可能なソリューションはこれ 1 つです。これで問題が解決しない場合は、テクニカル アシスタンス センター（TAC）にお問い合わせください。 |
ReadyClone とスナップショットの問題
[Quiesce] オプションを使用したネイティブ スナップショット
説明
VM の電源がオンの場合に、Windows 2008 または Windows 2012 サーバでの [Quiesce] オプションを使用したネイティブ スナップショットはサポートされていません。
アクション：[Quiesce] 以外のオプションを使用する
VM の電源をオフにしてから、スナップショットを作成するか、または [Quiesce] 以外のデフォルト オプションを使用します。
vMotion がネイティブ スナップショット データストアを移動できない
説明
vMotion によるネイティブ スナップショットの移動で、関連するデータストアを移動できません。ネイティブ スナップショットのある仮想マシンで、vMotion の使用はサポートされていますが、ストレージ vMotion の選択のみサポートされていません。
アクション：元の VM だけに対して vMotion を使用する
VM を別のデータストアに移動する必要がある場合は、ソースのデータストアからスナップショットを削除し、元の VM に vMotion を実行します。
クラスタの問題
vShield 使用時のストレージ コントローラ VM への接続
説明
vShield は HX Data Platform のアクティビティを妨げます。HX Data Platform クラスタへの vShield のインストールは推奨されません。
アクション：選択した HX コンポーネントを除外する
vShield をインストールする必要がある場合は、HX ストレージ コントローラ VM および vCenter を vShield の保護から除外します。https://www.vmware.com/support/pubs/vshield_pubs.html にある、VMware vCloud ネットワークとセキュリティ ドキュメントを参照してください。
| ステップ 1 | vShield Manager をインストールします。 |
| ステップ 2 | HyperFlex ストレージ コントローラ VM および vCenter Server を vShield App の保護から除外します。
vCenter で、 の順に選択します。各コントローラ VM を stCtlVM<name> で選択します。 |
| ステップ 3 | ストレージ コントローラへのネットワーク接続を確認します（ping、ssh など）。 |
| ステップ 4 | vShield コンポーネントをインストールして設定します。 |
| ステップ 5 | 設定が正しく動作することを確認するために、すべての ESXi ホストを同時に再起動してデータストアをオフラインにします。システムをバックアップしてから、手順 3 を繰り返します。 |
SSLv3 が無効な状態でソフトウェアのバックアップが失敗する
説明
vSphere 5.5 および 6.0 u1 の VMware のバグが原因で SSLv3 が無効な場合、バックアップ ソフトウェアが失敗することがあります。
アクション：VMware KB 記事を参照する。
|
クラスタ ノードの電源をオフにした後、vCenter クラスタからストレージ クラスタが見えなくなる
説明
vCenter クラスタ内のノードの電源がオフになっていました。ストレージ クラスタは、ダウン ノード数の許容範囲内であり、正常です。ただし、ストレージ クラスタが vSphere を介して管理できません。
VMware vSphere 6.0 の既知のバグです。次を参照してください。https://communities.vmware.com/thread/514117?start=0&tstart=0
アクション：ノードをリセットする。
ノードの電源をオンにするか、電源がオフのノードを vCenter クラスタから切断します。
vSphere クライアントに HX Data Platform プラグインが表示されない
説明
Cisco HyperFlex システムまたは Cisco HX Data Platform が vSphere クライアントまたは Web クライアントに表示されません。この問題が発生する場合には、いくつかの状況が考えられます。該当する状況に対応したアクションを実行してください。
アクション：オプションを選択する
パフォーマンス チャートの表示が 100% のズームでフォーマットされていない
説明
パフォーマンス チャートの表示が 100% のズームでフォーマットされていません。
オプションのメトリックと小さな解像度を同時に選択すると、正しくフォーマットされていないチャートが表示されます。
アクション：チャートのズームを変更する
フィードバック