問題のトラブルシューティング
この項では、HyperFlex のコンポーネントおよびプロセスで発生する可能性のある問題とそれらの問題の回避策について説明します。
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
この項では、HyperFlex のコンポーネントおよびプロセスで発生する可能性のある問題とそれらの問題の回避策について説明します。
クラスタのインストール、アップグレード、拡張に関する問題
Description
HX Data Platformの展開中に、IP アドレスページには同じサーバーが 2 回表示されます。
アクション: ペアから1つだけを選択します
これは、UCS Manager の設定をスキップし、HX Data Platformが UCS Manager とインポートした JSON ファイルの両方を参照する場合に発生する可能性があります。IP アドレスの各ペアの 1 つのみを選択します。
Description
展開中に FI を手動で再起動すると、インストールが失敗します。
アクション: 次を再起動する HX Data Platform インストーラ
ステップ 1 |
HX Data Platform インストーラ VM を再起動します。 |
ステップ 2 |
展開を再開します。 |
Description
UCS Manager のみのアップグレード中に、ノードのメンテナンス モードが終了した後で、コントローラ VM の電源がオンにならないことがあります。
アクション:vCenter で EAM サービスを再起動する
VMware vCenter EAM サービスは、コントローラ VM で自動的に電源オンになりません。コントローラ VM は EAM リソース プールの外部にあります。
vCenter で EAM サービスを再起動するには、/etc/init.d/vmware-eam restart
を実行します。
EAM によりすべての EAM エージェント VM が再スキャンされ、これらの VM で発生していたすべての問題(コントローラ VM の電源オンの問題を含む)が解決します。
説明
展開またはアップグレードが「「NoneType」オブジェクトに「scsiLun」属性がありません('NoneType' object has no attribute 'scsiLun')
」というエラーで失敗します。
アクション:切断してから再接続する
これは、VMware の問題です。vCenter からホストとの接続を切断してから、ホストを再接続します。
![]() 重要 |
クラスタからノードを削除しないでください。これは接続の切断のみです。 |
説明
ノードがメンテナンス モードに切り替わらなかったためにアップグレードが失敗します。
アクション:vmware-vpxd サービスを再起動する
その他のすべての検証が正常に完了した場合、これは VMware の問題(VMware VPXD のクラッシュ)の可能性があります。
ステップ 1 |
VPXD が再起動していることを確認し、再起動していない場合は ESX コマンド ラインから手動で再起動します。
|
ステップ 2 |
アップグレードを再試行します。 メンテナンス モードに正常に切り替わるはずです。 |
説明
再試行したアップグレードが、vMotion 互換性検証で失敗します。
アクション:ホストからストレージ システムを再スキャンする
これは vCenter と ESXi の間の同期の問題が原因で発生します。
vCenter クライアントを使用して ESX ホストでストレージ システムを再スキャンします。
次の URL で VMware の記事『Perform Storage Rescan in the vSphere Client』を参照してください:
https://docs.vmware.com/en/VMware-vSphere/6.0/com.vmware.vsphere.hostclient.doc/GUID-FA49E8EF-A3DC-46B8-AA5B-051C80762642.html説明
アップグレードの試行時に、「互換性のあるホストが見つかりませんでした(No compatible host was found)」エラーが発生し、VM の電源がオンになりません。
アクション:VM の電源を手動でオンにする
ステップ 1 |
ESX コマンド ラインから VM の電源をオンにします。 |
ステップ 2 |
コントローラ VM コマンド ラインを使用して次のコマンドを実行します。
|
説明
アップグレード中に 2 つのノードで障害が発生すると、コントローラ VM の電源がオンではないためにアップグレードが失敗します。
アクション:EAM サービスを再起動する
ステップ 1 |
vCenter EAM サービスを再起動します。 ESX コマンド ラインから次のコマンドを実行します。
|
ステップ 2 |
アップグレードを実行します。 |
Description
6.5 よりも古いバージョンの vCenter を使用して HX Data Platform をアップグレードした後に、「ESX エージェント(ESX Agent)」というラベルが付いたリソース プールに一部のコントローラ VM がリストされます。
アクション:必要なし
特に対処の必要はありません。機能への影響はありません。コントローラ VM などすべての仮想マシンは EAM 登録済みであり、HX Clusterに維持されます。すべての HX Clusterの操作は期待どおりに動作します。
グループ操作を実行する必要がある場合は、vCenter インターフェイスからコントローラ VM を ESX エージェント リソース プールにドラッグ アンド ドロップします。
Description
オンライン アップグレード中に、vCenter デーモンがノード上でクラッシュすることがあります。クラッシュした場合は、ノードで HX メンテナンス モードを開始できません。HX メンテナンス モードが開始されないと、ノードでアップグレードを完了できません。vCenter が正常に機能している他のすべてのノードでは、アップグレードが完了します。
アクション:影響を受けたノードでアップグレードを実行し直してください。
ステップ 1 |
vCenter の問題を修正します。 |
ステップ 2 |
クラスタ内の任意のノードからアップグレードを再開します。 HX Data Platform は、すでにアップグレードしているノードをスキップし、先に進んでアップグレードできていないノードのアップグレードを完了します。 |
Description
HX Data Platform インストーラ が、別の vCenter で管理されているホストを表示します。
ホストを vCenter から削除すると、通常はそのホストのサマリー情報から managementServerIP が削除されます。
ホストの削除時にホストのサービスが実行されていなかった場合、vCenter はホストが削除された後もそのホストを表示し続けます。
アクション:vCenter を再起動する
vCenter を再起動すると、問題のホストは vCenter で表示されなくなるはずです。
Description
ストレージ クラスタのインストール、アップグレード、拡張プロセス実行時に、HX Data Platform インストーラは入力された構成の設定と UCS Manager 内の設定を確認します。たとえば次のシナリオで、不一致が生じる場合があります。
検証や設定を適用できるようになるまでに、以前関連付けられていなかったサーバがそうではなくなることがあります。これらのサーバは関連付けを解除する必要があります。
HX Data Platform ストレージ クラスタに以前関連付けられていたサーバを使用しています。これらのサーバは関連付けを解除する必要があります。
既存のストレージ クラスタの設定情報を手動で入力すると、エラーが生じやすくなります。VLAN ID や LAN 設定などの情報は、UCS Manager に表示される情報と一致している必要があります。以前保存した設定ファイルを使用して設定をインポートしてください。
アクション:既存の設定をインポートする
ストレージ クラスタのインストール、アップグレード、拡張を完了すると、設定を保存するオプションが利用できるようになります。このオプションを使ってクラスタの設定情報を保存し、ストレージ クラスタに変更を加える必要が生じたときは、ファイルに保存されている構成の詳細情報をインポートします。
アクション:サーバの関連付けを解除する
UCS Manager を使ってサーバの関連付けを解除する手順については、『Cisco HyperFlex Systems Getting Started Guide』を参照してください。簡単に手順を説明すると以下のようになります。
ステップ 1 |
UCS Manager で、 の順に選択します。 |
ステップ 2 |
ノードの関連付けが解除されていることを確認し、 の場合は移行状態です。 の順に選択します。[removing] |
ステップ 3 |
ノードが関連付けの解除を完了していることを確認します。[Assoc State] が [none] になるまで待機します。[Assoc State]、[removing] のノードは選択しないでください。 |
Description
ストレージ クラスタのオブジェクトを識別するために完全修飾ドメイン名(FQDN)を指定すると、クラスタの作成が失敗することがあります。通常は、指定したドメイン ネーム サービス(DNS)サーバが利用できないために起こります。
これは、ドメイン名または IP アドレスで識別する HX Data Platform インストーラ オブジェクトとして入力されるすべてのドメイン名オブジェクトに当てはまります。これには、vCenter Server、ESX サーバ、コントローラ VM のアドレス、ストレージ クラスタ管理またはデータ ネットワークのアドレス、DNS サーバ、NTP サーバ、メール サーバ、または SSO サーバがあります。
アクション: DNS サーバを確認する
ステップ 1 |
HX Data Platform インストーラ VM のコマンド ラインにログインします。たとえば、 |
ステップ 2 |
指定された DN サーバが動作することを確認します。 |
ステップ 3 |
クラスタの作成に必要な各オブジェクトが、指定された DNS サーバから解決できることを確認します。これらのオブジェクトは、JSON ファイルまたは HX DP インストーラ GUI フィールドを通じて指定されます。 |
ステップ 4 |
手順 2 または手順 3 のいずれかが確認できない場合、HX Data Platform Installer GUI では完全修飾ドメイン名(FQDN)ではなく、IP アドレスのみを使用します。 |
Description
オフライン アップグレード後、VMware EAM の問題により、一部のコントローラ VM が再起動しないことがあります。stcli start cluster
コマンドが「Node not available
」というエラーを返します。
アクション:コントローラ VM の電源を手動でオンにして、ストレージ クラスタを起動してください。
ステップ 1 |
コントローラ VM の電源を手動でオンにします。 |
ステップ 2 |
ストレージ クラスタを再起動します。 |
Description
このエラーは、HX Data Platform プラグインをインストールした後に vSphere Replication プラグインをインストールすると発生します。最初に vSphere Replication プラグインをインストールしてから、HX Data Platform プラグインをインストールすることを推奨します。
アクション:HX Data Platform プラグインの登録を解除する
このタスクでは、HX 拡張機能を vCenter Managed Obejct Browser(MOB)から削除します。
vSphere Replication プラグインを vCenter MOB から削除します。
vSphere Replication 仮想マシンを vCenter インベントリから削除します。
HX vCenter クラスタを vCenter データセンターから削除します。
ステップ 1 |
まだの場合、vSphere ESX Agent Manager SDK をダウンロードします。 |
ステップ 2 |
VCenter から HyperFlexクラスタ オブジェクトを削除します。 |
ステップ 3 |
vCenter サーバ MOB 拡張マネージャにログインします。 |
ステップ 4 |
vCenter Server MOB 拡張マネージャで、MOB と、削除したクラスタに関連付けられている拡張機能を表示します。 |
ステップ 5 |
[ExtensionManager] ページで、拡張機能を登録解除します。 |
ステップ 6 |
削除したクラスタが、vCenter が HX Data Platform プラグインと通信するために使用していた CIP である場合、vsphere-client サービスを再起動します。 |
ステップ 7 |
前のステップで見つけた CIP が、vCenter から削除したクラスタに関連付けられている場合、拡張機能をクリーンアップする必要があります。 |
ステップ 8 |
すべてのセッションからログアウトし、再度ログインします。 |
データセンター クラスタを再作成します。ホストを一度に 1 つずつ HX vCenter クラスタに追加します。
データストアから vSphere Replication 仮想マシンを再登録します。
vSphere Replication アプリケーションの Web フロント エンドで、vSphere Replication プラグインを再作成します。再作成した vSphere Replication プラグインが vCenter 内で使用可能であることを確認します。
HX Data Platform インストーラから HX Data Platform プラグインを再インストールし、ストレージ クラスタを再作成します。
Description
この問題は、vCenter から送信される RemoteException によるものです。この例外の原因として最も可能性が高いのは、HX ストレージ クラスタと vCenter 間のネットワーク接続が断続的に途切れることにあります。
アクション:アップグレードを再試行します
Description
まれに、アップグレードが失敗した HX ストレージ クラスタでオンライン アップグレードを再開しようとすると、アップグレードが再び失敗することがあります。ただし、HX クラスタは障害状態から回復して、正常な状態になっています。
アクション:もう一度アップグレードを再試行する
CLI を使用してアップグレードを再試行する場合は、stcli cluster upgrade
コマンドで -f
または --force
オプションを使用します。あるいは、HX Data Platform プラグインを使用してアップグレードを再試行してください。
Description
vSphere がメンテナンス モードを終了した際、サーバ上の VM の電源がオンにならないことがあります。電源がオンにならない可能性がある VM には、ストレージ コントローラ VM も含まれます。
アクション:コントローラ VM を手動で再起動する
これは、VMware の既知の問題です。詳細については、VMware KB の記事「Auto-Start Is Not Run When Manually Restarting a Host in Maintenance Mode」を参照してください。
Description
UCS ファームウェアのアップグレードが失敗しました。考えられる理由は、サポートされていないボードが HX サーバで使用されていることです。
アクション:ボードをデコミッションしてから再コミッションする。
ステップ 1 |
参照されているボードをデコミッションしてから再コミッションします。 |
ステップ 2 |
サーバが正常であることを確認します。 |
ステップ 3 |
ファームウェアのアップグレードを再試行します。 |
ステップ 4 |
これで問題が解決しない場合は、Cisco TAC に連絡してサポートを求めてください。 |
Description
オンライン アップグレード中に、vCenter デーモンがノード上でクラッシュすることがあります。クラッシュした場合は、ノードで HX メンテナンス モードを開始できません。HX メンテナンス モードが開始されないと、ノードでアップグレードを完了できません。vCenter が正常に機能している他のすべてのノードでは、アップグレードが完了します。
アクション:影響を受けたノードでアップグレードを実行し直してください。
ステップ 1 |
vCenter の問題を修正します。 |
ステップ 2 |
クラスタ内の任意のノードからアップグレードを再開します。 HX Data Platform は、すでにアップグレードしているノードをスキップし、先に進んでアップグレードできていないノードのアップグレードを完了します。 |
Description
LSI のバージョンがバージョン 9 よりも古い場合、ノードでのアップグレード時にディスクが見つからないことがあります。ノードが正常でない場合、アップグレードを続行できません。
LSI バージョン 9 は、UCS ファームウェア バージョン 2.2(6f) と 2.2(7c) に関連付けられています。
アクション:ノードを手動で再起動する
ステップ 1 |
コントローラ VM コマンド ラインにログインします。たとえば |
ステップ 2 |
ディスクが表示されていることを確認します。
|
ステップ 3 |
ノードを手動で再起動します。 |
説明
HX Data Platform のクラスタ拡張ウィザードで、HX ストレージ クラスタが見つかりませんでした。
アクション:クラスタの IP アドレスを手動で入力する
クラスタ拡張ウィザードの [Management IP Address] フィールドに、手動で HX ストレージ クラスタ管理 IP アドレスを入力します。
クラスタ IP アドレスを見つけるには、次のようにします。
ステップ 1 |
vSphere Web クライアントから、 を選択します。 |
ステップ 2 |
ストレージ クラスタ名をクリックして選択します。パネルの最上部にある [Action Menu] から、[Summary] を選択します。 |
ステップ 3 |
表示された概要から、クラスタ管理 IP アドレスを見つけます。 |
Description
ストレージ クラスタの拡張では、新しいノードを FQDN ではなく、IP アドレスを使用して指定する場合でも、DNS サーバが必要です。HX Data Platform インストーラは、クラスタの作成中に指定されたすべての DNS サーバをチェックします。
以前指定された DNS サーバのいずれかが到達不可能な場合、クラスタの拡張は失敗します。
HX Data Platform のインストール時に DNS サーバを指定しなかった場合、クラスタの拡張は失敗します。
これらの条件のいずれかが当てはまる場合は、是正措置を実行します。
アクション:正しい DNS サーバを特定して指定する
ステップ 1 |
任意の HX コントローラ VM のコマンド ラインにログインします。たとえば、 |
ステップ 2 |
ストレージ クラスタに設定されている DNS サーバを特定します。
サンプル応答
DNS のアドレスが表示されない場合は、手順 4 に進みます。 |
ステップ 3 |
ストレージ クラスタで利用できなくなっているすべての DNS サーバを削除します。
|
ステップ 4 |
ストレージ クラスタに新しい DNS サーバを追加します。 ストレージ クラスタを作成したときに DNS サーバを指定しなかった場合は、疑似 DNS サーバを追加します。
|
ステップ 5 |
クラスタの作成に必要な各オブジェクトが、指定された DNS サーバから解決できることを確認します。これらのオブジェクトは、JSON ファイルまたは HX DP インストーラ GUI フィールドを通じて指定されます。 |
ステップ 6 |
指定された DN サーバが動作することを確認します。 |
ステップ 7 |
手順 5 と手順 6 を繰り返し、追加されたすべての DNS サーバが有効で、すべての HXDP オブジェクトが各 DNS サーバを通じて解決できることを確認します。 |
ステップ 8 |
HX Data Platform インストーラに戻り、ストレージ クラスタの拡張を続行します。 |
Description
拡張のために追加したクラスタ ノードが間違ったクラスタに追加されます。これは、複数のクラスタの作成で同じ HX Data Platform インストーラを使用し、その後、その同じ HX DP インストーラを使用してそれらクラスタの 1 つを拡張する場合に起こります。HX DP インストーラは、デフォルトでは最新のクラスタにノードを追加します。
アクション: HX Data Platform インストーラ OVA を再展開する
ステップ 1 |
HX Data Platform インストーラ OVA を再展開します。 |
ステップ 2 |
新しい HX Data Platform インストーラを使用してクラスタを拡張します。 |
ホストの問題
Description
手動で HX Data Platform サーバに ESX を再インストールした後、パフォーマンス統計情報が正しく表示されるように、stats daemon をリセットします。
アクション:stats daemon の再起動
ステップ 1 |
ESX ホストのコントローラ VM のコマンドラインにログインします。 |
ステップ 2 |
restart コマンドを実行します。
|
ステップ 3 |
ストレージ クラスタのすべての ESX ホストのコントローラ VM でステップ 1 およびステップ 2 を繰り返します。 |
説明
services.sh restart
を実行すると、scvmclient
管理サービスが再起動する。
![]() 注意 |
このコマンドを実行すると、特定のホストから HX データストアが接続解除されます。 |
ノードをメンテナンス モードにします。
ESX コマンド ラインにログインします。
サービスを再起動します。
# services.sh restart
ESX ホスト デーモン、vCenter エージェント サービス、およびコントローラ VM を再起動します。
# /etc/init.d/hostd restart
# /etc/init.d/vpxa restart
説明
アップグレード中の ESX サーバの電源リセットにより、アップグレードが終了し、サーバでメンテナンス モードが開始されます。
アクション:メンテナンス モードの手動での終了
手動でサーバのメンテナンス モードを終了します。アップグレードが続行します。
説明
EAM がコンピューティング ノードで自動的に再起動しませんでした。
アクション:EAM を手動で再起動する
説明
3 つのノードだけが稼働している場合にはノードを削除することはできません。
アクション:はじめに交換ノードを追加する
3 ノード クラスタ内のノードを交換する場合は、TAC によるサポートが必要です。ノードで障害が発生しているためにクラスタのノード数が 3 になった場合、ノードを交換するには TAC によるサポートが必要です。
説明
システムがアクセスできないストレージ クラスタのホストの HA を有効にした場合、ESX ホストを再起動すると、ストレージ コントローラ VM の電源がオフになります。
これは、VMware の HA 障害の処理方法と ESX Agent Manager(EAM)設定間の相互作用によるものです。これにより、ストレージ コントローラ VM が、復元後に電源オンにならない現象が生じる可能性があります。
アクション:HA が有効になっている ESX ホスト上でストレージ コントローラ VM の電源をオンにする
ステップ 1 |
最初に障害が発生したホスト上で HA を再設定します。 |
ステップ 2 |
ストレージ コントローラ VM を手動で電源オンにします。 |
説明
既存のストレージ クラスタにノードを追加する場合、ストレージ クラスタは、再調整が完了するまで元のストレージ クラスタと同じ HA 復元力を持ち続けます。
たとえば、3 ノードのストレージ クラスタがあり、2 つのコンバージド ノードをストレージ クラスタに追加する場合などです。再調整が完了するまで、ストレージ クラスタは、5 ノードのストレージ クラスタではなく、3 ノードのストレージ クラスタとして動作します。したがって、バランスの再調整が完了する前にノードで障害が発生すると、ストレージ クラスタのステータスは低下します。
![]() (注) |
再調整は通常、次のような状況で発生します。
|
アクション:ストレージ クラスタの再調整を手動で開始する
ステップ 1 |
ストレージ コントローラ VM のコマンド ラインから次のコマンドを実行します。 # stcli rebalance start --force
|
ステップ 2 |
再調整ステータスをモニタするには、次のコマンドを使用します。 # stcli rebalance status
|
Description
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 インベントリ(vCenter Inventory)] で、 の順に選択します。 |
ステップ 5 |
パススルー用の LSI カードを選択します。
|
ステップ 6 |
ESX ホストをリブートします。 |
ステップ 7 |
HX ストレージ コントローラ VM(StCtlVM)の設定を編集して、PCI デバイスを HX ストレージ コントローラ VM に再マップします。 |
ステップ 8 |
HX メンテナンス モードから ESX ホストを削除します。 ホストが再びアクティブになると、HX ストレージ コントローラ VM が正常にブートして、ストレージ クラスタに再参加します。 |
ディスクの問題
説明
ノード上のすべてのハード ディスクに障害が発生すると、HX Data Platform はノードにデータを割り当てることができません。3 ノードのストレージ クラスタでこの問題が発生した場合、HX Data Platform は、データの整合性を維持する上で最低限必要な 3 つのデータのコピーを維持することができません。その結果、仮想的な ENOSPC 状態となります。
ノード上で複数のハード ディスクに障害が発生し続けた場合、ストレージ クラスタはノードへの書き込みを行おうとし、ディスク上の残りの領域を使用することから、不安定な状態となります。たとえば、3 つのノードすべてに 10 台の HDD があり、3 番目のノード上で 9 台の HDD に障害が発生した場合、不安定な状況が生じた結果、3 番目のノード上のディスクでは、クラスタのサイズが実際のサイズの 10 % に制限されます。これは、物理的な ENOSPC 状態です。また、オール パス ダウン(APD)状態を引き起こす可能性もあります。
アクション:ストレージ クラスタ内のすべてのノード上で、ストレージを物理的に調整します。
ステップ 1 |
破損したディスクを問題のないディスクと交換します。 |
ステップ 2 |
ストレージ クラスタに別のノードを追加します。 |
ステップ 3 |
確実に整合性がとれるように、ノードのストレージ キャパシティを調整します。 |
ステップ 4 |
ストレージ クラスタが自動的に回復しない場合は、ストレージ クラスタを再起動する必要があります。 |
説明
ディスクを削除して、自動再スキャンが完了する前にストレージ コントローラ VM を再起動した場合、ストレージ コントローラ VM の電源がオンにならない場合があります。
アクション:ディスクの削除後にストレージ コントローラ VM の電源をオンにする
ステップ 1 |
ストレージ コントローラ VM の電源がオフになっていることを確認します。 |
ステップ 2 |
スクリプトを実行します。
|
ステップ 3 |
ストレージ コントローラ VM の電源をオンにします。 |
説明
ストレージ コントローラ VM をホストする SSD に障害が発生した場合、SSD を復旧させる必要があります。
アクション:障害が発生した SSD を復旧させる
ステップ 1 |
障害が発生した SSD を搭載したホストのコマンドラインにログインします。 |
ステップ 2 |
SSD のステータスが [dead timeout] になっていることを確認します。
|
ステップ 3 |
ストレージ コントローラ VM の
|
ステップ 4 |
ストレージ アダプタを再スキャンします。
|
ステップ 5 |
同じ仕様の新しい SSD にディスクを置き換えます。 |
ステップ 6 |
hostd を再起動します。 |
ステップ 7 |
ストレージ コントローラ VM の電源をオンにします。 |
VM の問題
Description
vSphere EAM が、リソース不足のためにコントローラ VM の電源をオンにできませんでした。
これは、vSphere HA がオンであり、アドミッション コントロールが [Reserved failover capacity to be at 1 host] に設定されている場合に発生します。この設定では、HA アドミッション コントロールは 1 つのホストが完全にフェールオーバーするのに十分なリソースを予約します。
アクション:vSphere アドミッション コントロールを調整する
VMware ドキュメント『Best Practices for Admission Control』(https://docs.vmware.com/en/VMware-vSphere/6.0/com.vmware.vsphere.avail.doc/GUID-BD6D9434-84C8-4937-BC76-04852F5EA136.html)を参照します。
vSphere を適切に調整します。
Description
この問題は、16 + 16 ノードのクラスタで観察されています。これは、VMware の既知の問題です。詳細については、VMware KB の記事「vMotion of a VM fails with the error: "Timed out waiting for migration data" (2143834)」を参照してください。
アクション:ネットワーク接続を確認する
Description
これは、VMware EAM(ESX Agent Manager)の問題が原因です。EAM がホスト上の VM を正しくマーキングしていません。
アクション:ストレージ クラスタを再登録する
ストレージ クラスタを再登録して vCenter ビューを同期します。ストレージ コントローラ VM で、次のコマンドを実行します。
# stcli cluster register
Description
ユーザ 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 は電源オンになりません。
アクション:次の手順を実行する。
ステップ 1 |
vCenter クラスタから、[DRS Automation] 設定を [Manual] に変更します。 |
ステップ 2 |
ESX ホストから VM の電源を直接オンにします。 |
ステップ 3 |
[Power On] ダイアログ ボックスで、コントローラ VM の電源がオンになっている ESX ホストを選択します。 |
説明
ディスク共有の制限が設定された VM の電源がオンになると、各データストアのパフォーマンスが低下する。
アクション:VMware 単位で想定されている動作です。
ステップ 1 |
mclock スケジューラを無効化します。 |
ステップ 2 |
デフォルトのスケジューラに移動します。 |
説明
ストレージ クラスタが読み取り専用状態になっていると、それらがすでに読み取り専用のストレージ クラスタにある場合であっても、VMware DRS プロセスは VM をデータストアに移行します。その結果 VM は起動不可になります。
アクション:ストレージ クラスタが読み取り専用状態の場合には、DRS を手動で無効にします。
ステップ 1 |
HX Data Platform ストレージ クラスタを選択します。 vSphere Web クライアント ナビゲータから、 の順に選択します。 |
ステップ 2 |
[Summary] タブを選択し、[VC Cluster] リンクをクリックして [vCenter Summary] タブに切り替えます。 をクリックして [Turn ON vSphere DRS] をオフにし、[OK] をクリックします。 の順にクリックします。[Edit] |
Description
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 |
HX クラスタの UUID を指定します。 各エージェンシーには、基盤となる vSphere 拡張機能を参照するフィールド、 ストレージ コントローラ VM コマンド ラインから次のコマンドを実行します。
|
ステップ 4 |
ストレージ クラスタの拡張機能を登録解除する:vCenter サーバ MOB 拡張機能マネージャにログインします。 まず、HyperFlex クラスタを登録解除します。 |
ステップ 5 |
クラスタ ID を持つ HX ストレージ クラスタ拡張機能を探します。 をスクロールして、次のストレージ クラスタ拡張機能を探します
クリップボードに、これらの文字列をそれぞれコピーします。文字列の端に二重引用符(”)がある場合、それを除外します。 |
ステップ 6 |
各ストレージ クラスタ拡張機能の登録を解除します。 |
ステップ 7 |
古い EAM 拡張機能を削除する:vCenter サーバ MOB ESX エージェンシー拡張機能マネージャにログインします。 次に、HyperFlex クラスタに関連付けられていた古い EAM 拡張機能を削除します。 |
ステップ 8 |
当該のクラスタ ID を持つ古い HX ストレージ クラスタの ESX エージェンシー拡張機能を見つけます。 |
ステップ 9 |
古い ESX エージェンシー拡張機能を削除します。 |
ステップ 10 |
[ExtensionManager] タブを更新し、[extensionList] エントリに |
ステップ 11 |
vSphere クライアント サービスを再起動します。 vSphere クライアント サービスが再起動されると、HX Data Platform の拡張機能が削除されます。vSphere クライアント サービスを再起動すると、ブラウザから vCenter へのアクセスが一時的に無効になります。 追加情報については、VMware のナレッジ ベース『Stopping, starting, or restarting VMware vCenter Server Appliance 6.0 services (2109887)』を参照してください。 |
ステップ 12 |
HX Data Platform のインストールを実行し完了します。 古い EAM 拡張の削除に関する追加オプションについては、テクニカル アシスタンス センター(TAC)に確認してください。 |
説明
ユーザ VM が、ファイル システム内に残っているユーザ VM 向けに作成された ESX *.lck ファイルや、vSphere にアクセスできなくなった場合、VM ファイルやフォルダの削除には非常に長い時間がかかる場合があります。
アクション:ESX サーバの VM ロック ファイルをクリアする
ステップ 1 |
ストレージ クラスタ内のすべての VM ロック ファイルを探します。
# find . -name .lck* | xargs -n1 rm |
ステップ 2 |
VM のファイルまたはフォルダの削除を再試行します。 |
Description
VM にスナップショットまたは ReadyClone がある場合、VM ディスク使用率が vCenter の仮想マシン コミット サイズと一致しません。
アクション:なし
データストアの問題
説明
ストレージ クラスタからコンピューティング ノードを削除しても、関連付けられているデータストアが削除されませんでした。
アクション:データストアを手動で削除する
Description
VMware の問題により、同時に複数のデータストアを追加しようとして、一部のデータストアがマウントされないことがあります。
アクション:データストアを再マウントする
一度にマウントするデータストアを減らしてマウントします。
HX プラグインを使用して、最初にマウントされなかったデータストアを再マウントします。
説明
シリアル I/O 制御(SIOC)に関する VMware の問題が原因で、NFS 全パス ダウン(APD)が発生し、次のようなメッセージが表示されます。
NFSLock: 2210: ファイルはホスト host_name 上のコンシューマーによって排他ロックでロックされています。
アクション:[Storage I/O Control] を切り替える
ステップ 1 |
vCenter からデータストア ビューで を選択します。 |
ステップ 2 |
[Storage I/O Control] を反対の状態に切り替えます。 有効な場合は無効にします。無効な場合は有効にします。 |
ステップ 3 |
[Storage I/O Control] を元の状態に戻します。 有効な場合は無効にします。無効な場合は有効にします。 |
ステップ 4 |
NFS ロックが解除されていることを確認します。 |
説明
ストレージ クラスタの作成後に VLAN ID を変更すると、データストアのストレージ クラスタへのマウントに失敗します。既存のデータストアを、ストレージ クラスタからマウント解除することはできます。
アクション:ESX サーバのファイアウォールをリロードします。
ESX サーバのファイアウォールのリロードに関する指示については、VMware ESX のマニュアルを参照してください。
説明
VMware の構成要件ごとに IP アドレスもしくはルールが重複する場合、接続が失われます。
アクション:トラフィックが意図した VM カーネル インターフェイスを使用しているか確認します。
次を設定します。
VM カーネル ポートは、IP サブネットごとに 1 つだけです。
vSphere 5.x を使用している場合、iSCSI マルチパスやマルチ NIC vMotion には適用されません。
ルーティング不可能な専用の VLAN または vMotion 用の専用物理スイッチ。
ルーティング不可能な専用の VLAN または IP ストレージ用の専用物理スイッチ。
ルーティング不可能な専用の VLAN または耐障害性用の専用物理スイッチ。
説明
ストレージ クラスタが正常な状態に戻った後、既存のデータストアが自動的に再マウントされない場合があります。これは、1 つ以上のノードがダウンしている間にストレージ クラスタが再起動されたか、ストレージ クラスタの再起動に長い時間がかかっている場合に発生する場合があります。
アクション:データストアをマウントする。
方法を選択します。
HX Data Platform プラグインを使用する。
コマンド ラインを使用する。
ステップ 1 |
HX Data Platform プラグインを使用する。
|
ステップ 2 |
コマンド ラインを使用する。 |
説明
VMware の Storage I/O RM 機能が有効になっている場合、データストアで Storage I/O RM が有効になっていない場合でも、VMware が Storage I/O RM の追跡ファイルに書き込みを行うバグがあります。これらの追跡ファイルが、HX Data Platform のデータストアのマウント解除を妨げます。
アクション:マウント解除を再試行する。
ステップ 1 |
データストアのマウント解除を再試行します。 |
ステップ 2 |
HX Data Platform のデータストアがマウントされているすべての ESX ホストの Storage I/O RM デーモンを停止します。 |
ステップ 3 |
データストアをマウント解除します。 |
ステップ 4 |
必要に応じて、Storage I/O RM デーモンを再起動します。 |
Description
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 で使用されているかどうかを確認します。
|
ステップ 3 |
|
ステップ 4 |
|
ステップ 5 |
または、vSphere HA を無効にします。
|
ステップ 6 |
データストアの削除を再試行してください。 |
ステップ 7 |
VSphere HA を無効にしていた場合は再度有効にします。 |
ステップ 8 |
可能なソリューションはこれ 1 つです。これで問題が解決しない場合は、テクニカル アシスタンス センター(TAC)にお問い合わせください。 |
ReadyClone、スナップショット、レプリケーションの問題
Description
[Use VMware Tools to quiesce the virtual machine] オプションが選択されている場合、レプリケーションが失敗することがあります。
レプリケーションの開始時に、VM でレイアウト変更などのゲスト ツール関連アクティビティが進行している場合、レプリケーションが失敗することがあります。関連アクティビティには、VMDK の追加、HX Native Snapshot または Redlolog Snapshot の作成、削除、統合、VM の再設定、または vMotion などがあります。これは一時的なステートです。
レプリケーションが失敗すると、自動的に再試行されます。数回繰り返して試行してもレプリケーションが失敗する場合、一時的な VM レイアウト変更が失敗の原因ではない可能性があります。[Use VMware Tools to quiesce the virtual machine] オプションを選択解除することを検討します。
アクション: [Use VMware Tools to quiesce the virtual machine]
オプションを選択解除する
ステップ 1 |
HX Connect にログインします。 |
ステップ 2 |
仮想マシンに使用する保護方式の [Edit Schedule] を選択します。
|
ステップ 3 |
[Use VMware Tools to quiesce the virtual machine] を選択解除し、[Save Changes] を選択します。 |
Description
ターゲット データストアの名前変更直後にリカバリを実行すると、「データストアが見つかりません(Datastore not found)
」というエラーでリカバリが失敗することがあります。
アクション:リカバリを再試行する
データストアの名前の変更後数分間待機してから、リカバリを再試行します。
Description
次のコマンドを実行している間にノードを再起動すると、コマンド アクションが停止し、その後コマンドを再試行しても失敗します。
stcli dp vm recover
stcli dp vm restore
stcli dp vm clone
アクション:仮想マシンをクリーンアップする
ステップ 1 |
vCenter から仮想マシンをクリーンアップします。 適切なオプションを選択します。
|
ステップ 2 |
|
説明
stcli vm recover
を使用して初めて仮想マシンの回復を試行しましたが、完了しませんでした。また、このコマンドを再実行しても完了しませんでした。
部分的に回復した場合、仮想マシンが vCenter に登録されたままになっている可能性があります。これは削除する必要があります。
アクション:残っているファイルをクリーンアップする
ステップ 1 |
vCenter から仮想マシンを削除します。 |
ステップ 2 |
|
ステップ 3 |
リカバリ コマンドを再実行します。
|
説明
REST API を使用して保護グループを検索すると、REST 呼び出しでフィルタを適用するとしても、検索結果としてすべての保護グループが返されます。
アクション:なし
groups:get
では、フィルタの name および type パラメータはサポートされません。
Description
HX ストレージ クラスタ内の VM に関する redo ログ スナップショットを取る場合は、redo ログ スナップショットを保存する ESXi ホストの設定を編集します。この手順が完了していない場合は、VM がスナップショット統合中に機能しなくなる可能性があります。
redo ログ スナップショットは、HX Data Platform のスナップショット機能ではなく、VMware のスナップショット機能を介して作成されるスナップショットです。
アクション:ESXi ホストで snapshot.asyncConsolidate="TRUE" を設定する
ステップ 1 |
ESXi ホストのコマンド ラインにログインします |
ステップ 2 |
ファイル |
ステップ 3 |
|
説明
VM の電源がオンの場合に、Windows 2008 または Windows 2012 サーバでの [Quiesce] オプションを使用したネイティブ スナップショットはサポートされていません。
アクション:[Quiesce] 以外のオプションを使用する
VM の電源をオフにしてから、スナップショットを作成するか、または [Quiesce] 以外のデフォルト オプションを使用します。
説明
vMotion によるネイティブ スナップショットの移動で、関連するデータストアを移動できません。ネイティブ スナップショットのある仮想マシンで、vMotion の使用はサポートされていますが、ストレージ vMotion の選択のみサポートされていません。
アクション:元の VM だけに対して vMotion を使用する
VM を別のデータストアに移動する必要がある場合は、ソースのデータストアからスナップショットを削除し、元の VM に vMotion を実行します。
クラスタの問題
Description
stcli cluster reregister
の実行後に、コントローラ VM が EAM エージェントとしてリストされません。
アクション:クラスタを再作成する
ステップ 1 |
vCenter クラスタを削除します。 |
ステップ 2 |
vCenter クラスタを再作成します。 |
ステップ 3 |
HX クラスタを再登録します。
|
Description
複数のクラスタ再登録を実行すると、クラスタが異常な状態になることがあります。
アクション:クラスタを再作成する
HX Clusterは vCenter 情報を失い、virtCluster および HX Connect ステータスはクラスタがオフラインであることを示します。ただし HX Data Platform クラスタは、クラスタが全体的に正常だったことを示します。
クラスタを再作成します。
# stcli cluster recreate
Description
クラスタからノードを削除した後で、いずれかのコントローラ VM で stcli cluster info
コマンドを実行すると ClusterNotConfigured
と示されます。
アクション:クラスタを更新する
コントローラ VM コマンド ラインから次のコマンドを実行します。
# stcli cluster refresh
説明
表示されるクラスタ使用率の合計が、個々のディスクに対して示される使用率を上回る場合があります。
たとえば、クラスタ使用率は 80% であるのに対し、使用率が最大のディスクでも、使用率が 76% として示されるといった状況です。
アクション:なし
この違いは、管理レイヤの処理に起因する場合があります。使用率関連の決定を行う場合は常に、必ずクラスタ使用率の値を参考にしてください。
Description
この問題はさまざまなシナリオで発生します。考えられるシナリオは次のとおりです。
シナリオ 1
2.1.x より前の古い HX バージョンから開始します。
コンピューティング ノードを追加します。
クラスタを再登録します。
クラスタをアップグレードします。クラスタにコンピューティング ノードを含めるタスクが失敗します。
シナリオ 2
2.1.x より前の古い HX バージョンから開始します。
コンピューティング ノードを追加します。
クラスタをアップグレードします。タスクが完了します。
クラスタを再登録します。EAM レベルでタスクが失敗します。
シナリオ 3
新しい HX バージョン(2.1.x 以降)で開始します。
コンピューティング ノードを追加します。
クラスタを再登録します。EAM レベルでタスクが失敗します。
アクション:コンピューティング ノードを削除してから再登録する
ステップ 1 |
コンピューティング ノードから VM を vMotion で移動し、HX クラスタからコンピューティング ノードを削除します。 |
ステップ 2 |
HX クラスタを再登録します。 |
ステップ 3 |
HX クラスタにコンピューティング ノードを追加します。 |
Description
大量の処理セットがあるワークロードは、キャパシティ階層からデータにアクセスする必要があります。HX Data Platform バージョン 2.1(1b) 以降、バックエンド アクセスが最適化されて、一時的遅延増加の大きさと頻度が大幅に削減されました。
ハイブリッド クラスタの場合:この症状が現れている場合、アップグレードに必要なメンテナンス期間が長くなります。また、デフォルトのアップグレード プロセスではこの最適化が自動的に有効になりません。アップグレード処理中にこのパフォーマンス拡張を有効にするには、Cisco TAC までお問い合わせください。
オール フラッシュ クラスタの場合:アップグレードの時間は大きな影響を受けません。また、デフォルトのアップグレード パスで、このパフォーマンス拡張が自動的に有効にされます。
アクション:2.1(1c) 以降にアップグレードする
説明
ROBO ストレージ クラスタを含め、3 つのノードからなるあらゆるクラスタでは、いずれか 1 つのノードがメンテナンス モードまたは障害状態になると、クラスタのヘルス ステータスが異常として設定されます。この問題は、再調整によって修正されることはありません。
アクション:ノードを正常な状態に戻す
ノードまたはノード内のコンポーネントで障害が発生していないことを確認します。ノードまたはコンポーネントで障害が発生している限り、クラスタの状態は異常のままになります。コンポーネントまたはノードが正常な状態に戻ると、クラスタは回復し、正常な状態に戻ります。
説明
ESXi ホストで電源が再投入された場合、障害が発生した場合、またはメンテナンス モードが開始あるいは終了した場合、NTP サーバが同期されないことがあります。
ESXi ホストで NTP を手動で設定する
NTP クライアントを有効にします。
|
説明
HX Data Platform プラグイン内で、[Summary] タブのクラスタ キャパシティと [Manage] タブのプロビジョニングされたキャパシティに、ストレージ クラスタに割り当てられたストレージ量と異なる数値の表示されることがあります。これは、次のような状況で発生します。
クリーナーが未完了。VM は削除されたが、クリーナーが実行されていない。クリーナーは自動プロセスであり、完了後にクラスタ キャパシティとプロビジョニングされた量が一致する必要があります。クリーナー コマンドに関する情報については、『Cisco HX Data Platform Command Line Interface Reference guide』を参照してください。
シック プロビジョニングまたはシック クローン。シック ディスクまたはクローンが作成された場合、HX Data Platform は領域を確保しません。ソフト予約が使用され、データストアに使用された領域が表示されますが、領域はストレージ クラスタ内で使用されていません。これは、データストアをオーバー プロビジョニングすることがないように、管理者を支援する目的で設計されたものです。
アクション:ありません。
Description
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 で、 |
ステップ 3 |
ストレージ コントローラへのネットワーク接続を確認します(ping、ssh など)。 |
ステップ 4 |
vShield コンポーネントをインストールして設定します。 |
ステップ 5 |
設定が正しく動作することを確認するために、すべての ESXi ホストを同時に再起動してデータストアをオフラインにします。システムをバックアップしてから、手順 3 を繰り返します。 |
Description
vSphere 5.5 および 6.0 u1 の VMware のバグが原因で SSLv3 が無効な場合、バックアップ ソフトウェアが失敗することがあります。
アクション:VMware KB 記事を参照します
VMware の関連記事へのリンクをクリックします。
|
説明
vCenter クラスタ内のノードの電源がオフになっていました。ストレージ クラスタは、ダウン ノード数の許容範囲内であり、正常です。ただし、ストレージ クラスタが vSphere を介して管理できません。
VMware vSphere 6.0 の既知のバグです。次を参照してください。https://communities.vmware.com/thread/514117?start=0&tstart=0
アクション:ノードをリセットする。
ノードの電源をオンにするか、電源がオフのノードを vCenter クラスタから切断します。
インターフェイスの問題
Description
複数の VM 電源操作が原因で、タスク キューでエラーが発生します。
アクション:キューをクリーンアップする
電源操作は HX Connect から開始できますが、vCenter を介して実行されます。vCenter タスク コレクタの最大数は 32 です。これは変更できません。
ステップ 1 |
キュー内のタスクをクリーンアップします。 次の URL の関連記事『VCS vSphere – Check new notifications stuck on Queued – VMware vCenter Update Manager Check Notification』を参照してください:http://www.natestiller.com/2011/02/vcs-vsphere-check-new-notifications-stuck-on-queued-vmware-vcenter-update-manager-check-notification/ |
ステップ 2 |
HX Connect からログアウトし、再度ログインします。 |
ステップ 3 |
電源操作を再試行します。 同時操作の数が 32 を超えないようにします。 |
説明
HX Connect ステータス フィールドの表示データが更新されないことがあります。
アクション:ブラウザのキャッシュをクリアする
Microsoft Internet Explorer
IE ブラウザから
を選択します。適切なチェックボックスをクリックします。
[Delete] をクリックします。
Google Chrome
Chrome ブラウザから
を選択します。適切なチェックボックスをクリックします。
[CLEAR BROWSING DATA] をクリックします。
Mozilla Firefox
Firefox ブラウザから、
を選択します。[Cached Web Content] セクションで [Clear Now] をクリックします。
説明
HX クラスタでのノード再起動などのイベントによって、システム パフォーマンスが影響される場合があります。そのようなイベントが発生している間は、パフォーマンス チャートにデータ ギャップが示されることがあります。
アクション:なし
イベントが完了すると、パフォーマンス チャートのレポート作成が続行されます。
Description
Cisco HyperFlex システムまたは Cisco HX Data Platform が vSphere クライアントまたは Web クライアントに表示されません。この問題が発生する場合には、いくつかの状況が考えられます。該当する状況に対応したアクションを実行してください。
アクション:オプションを選択します
HX ストレージ クラスタの作成後に vCenter サービスを再起動します。
アップグレード後に vCenter サービスを再起動します。
既存のクラスタがある vCenter に別のクラスタを追加した後に vCenter サービスを再起動します。
Firefox ブラウザに最新の Adobe FlashPlayer をインストールします。
ステップ 1 |
vCenter サービスを再起動します。 |
ステップ 2 |
Firefox ブラウザに最新の Adobe FlashPlayer をインストールします。 |
説明
パフォーマンス チャートの表示が 100% のズームでフォーマットされていません。
オプションのメトリックと小さな解像度を同時に選択すると、正しくフォーマットされていないチャートが表示されます。
アクション:チャートのズームを変更する
説明
この問題は、新しいクラスタを作成した既存の vCenter で、別のバージョンの HX Data Platform も使用されている場合に発生することがあります。
アクション:vSphere にログインし直す
vSphere クライアントからログアウトして、もう一度ログインします。