トラブルシューティング項目

問題のインストールおよびアップグレード

IP アドレスを展開するページに重複したサーバが表示される

Description

HX Data Platformの展開中に、IP アドレスページには同じサーバーが 2 回表示されます。

アクション: ペアから1つだけを選択します

これは、UCS Manager の設定をスキップし、HX Data Platformが UCS Manager とインポートした JSON ファイルの両方を参照する場合に発生する可能性があります。IP アドレスの各ペアの 1 つのみを選択します。

FI を手動で再起動するとインストールが失敗する

Description

展開中に FI を手動で再起動すると、インストールが失敗します。

アクション: 次を再起動する HX Data Platform インストーラ

手順


ステップ 1

HX Data Platform インストーラ VM を再起動します。

ステップ 2

展開を再開します。


UCS Manager だけをアップグレード中に、コントローラ VM の電源がオンにならないことがある

Description

UCS Manager のみのアップグレード中に、ノードのメンテナンス モードが終了した後で、コントローラ VM の電源がオンにならないことがあります。

アクション:vCenter で EAM サービスを再起動する

VMware vCenter EAM サービスは、コントローラ VM で自動的に電源オンになりません。コントローラ VM は EAM リソース プールの外部にあります。


(注)  

HyperFlex リリース 4.0 (1a) 以降で新しく導入された HX クラスタは、HyperFlex ストレージコントローラ VM の vSphere ESX Agent Manager (EAM) を利用できなくなりました。HX 4.0(1a) より前に構築された HX クラスタは引き続き EAM を使用します。そのクラスタが新しい vCenter に移行された場合、EAM 連携は設定されません。アップグレードされたクラスタの EAM 依存関係を削除する方法の詳細については、『HX 4.0 および vCenter EAM 変更の転送』を参照してください。


  • vCenter で EAM サービスを再起動するには、/etc/init.d/vmware-eam restart を実行します。

    EAM によりすべての EAM エージェント VM が再スキャンされ、これらの VM で発生していたすべての問題(コントローラ VM の電源オンの問題を含む)が解決します。

展開またはアップグレードが「「NoneType」オブジェクトに「scsiLun」属性がありません('NoneType' object has no attribute 'scsiLun')」というエラーで失敗する

説明

展開またはアップグレードが「「NoneType」オブジェクトに「scsiLun」属性がありません('NoneType' object has no attribute 'scsiLun')」というエラーで失敗します。

アクション:切断してから再接続する

これは、VMware の問題です。vCenter からホストとの接続を切断してから、ホストを再接続します。


重要

クラスタからノードを削除しないでください。これは接続の切断のみです。


アップグレードでメンテナンス モードに切り替わらない

説明

ノードがメンテナンス モードに切り替わらなかったためにアップグレードが失敗します。

アクション:vmware-vpxd サービスを再起動する

その他のすべての検証が正常に完了した場合、これは VMware の問題(VMware VPXD のクラッシュ)の可能性があります。

手順


ステップ 1

VPXD が再起動していることを確認し、再起動していない場合は ESX コマンド ラインから手動で再起動します。

# service vmware-vpxd status

# service vmware-vpxd start

ステップ 2

アップグレードを再試行します。

メンテナンス モードに正常に切り替わるはずです。


アップグレードが vMotion 互換性検証で失敗する

説明

再試行したアップグレードが、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

VM 電源オン時のエラーのアップグレード:「互換性のあるホストが見つかりませんでした

説明

アップグレードの試行時に、「互換性のあるホストが見つかりませんでした(No compatible host was found)」エラーが発生し、VM の電源がオンになりません。

アクション:VM の電源を手動でオンにする

手順


ステップ 1

ESX コマンド ラインから VM の電源をオンにします。

ステップ 2

コントローラ VM コマンド ラインを使用して次のコマンドを実行します。

# stcli cleaner start


アップグレード時に 2 つのノードで障害が発生すると、コントローラ VM の電源オンが失敗する

説明

アップグレード中に 2 つのノードで障害が発生すると、コントローラ VM の電源がオンではないためにアップグレードが失敗します。

アクション:EAM サービスを再起動する

手順


ステップ 1

vCenter EAM サービスを再起動します。

ESX コマンド ラインから次のコマンドを実行します。

# /etc/init.d/vmware-eam restart

ステップ 2

アップグレードを実行します。


6.5 より前の vCenter のアップグレードで、一部のコントローラ VM がグループ化される

Description

6.5 よりも古いバージョンの vCenter を使用して HX Data Platform をアップグレードした後に、「ESX エージェント(ESX Agent)」というラベルが付いたリソース プールに一部のコントローラ VM がリストされます。

アクション:必要なし

特に対処の必要はありません。機能への影響はありません。コントローラ VM などすべての仮想マシンは EAM 登録済みであり、HX Clusterに維持されます。すべての HX Clusterの操作は期待どおりに動作します。

グループ操作を実行する必要がある場合は、vCenter インターフェイスからコントローラ VM を ESX エージェント リソース プールにドラッグ アンド ドロップします。

vCenter の問題によりノードがアップグレードに失敗する

Description

オンライン アップグレード中に、vCenter デーモンがノード上でクラッシュすることがあります。クラッシュした場合は、ノードで HX メンテナンス モードを開始できません。HX メンテナンス モードが開始されないと、ノードでアップグレードを完了できません。vCenter が正常に機能している他のすべてのノードでは、アップグレードが完了します。

アクション:影響を受けたノードでアップグレードを実行し直してください。

手順


ステップ 1

vCenter の問題を修正します。

ステップ 2

クラスタ内の任意のノードからアップグレードを再開します。

HX Data Platform は、すでにアップグレードしているノードをスキップし、先に進んでアップグレードできていないノードのアップグレードを完了します。


HX Data Platform インストーラが別の vCenter によって管理されているホストを表示する

Description

HX Data Platform インストーラ が、別の vCenter で管理されているホストを表示します。

ホストを vCenter から削除すると、通常はそのホストのサマリー情報から managementServerIP が削除されます。

ホストの削除時にホストのサービスが実行されていなかった場合、vCenter はホストが削除された後もそのホストを表示し続けます。

アクション:vCenter を再起動する

vCenter を再起動すると、問題のホストは vCenter で表示されなくなるはずです。

HX Data Platform と UCS Manager 間で異なる構成の設定

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 で、[Associated] タブ > [node] > [Actions] > [Disassociate Server] の順に選択します。

ステップ 2

ノードの関連付けが解除されていることを確認し、[Unassociated] タブ > [node] > [Assoc State] の順に選択します。[removing] の場合は移行状態です。

ステップ 3

ノードが関連付けの解除を完了していることを確認します。[Assoc State] が [none] になるまで待機します。[Assoc State]、[removing] のノードは選択しないでください。


FQDN による DNS エラーでクラスタの作成に失敗する

Description

ストレージ クラスタのオブジェクトを識別するために完全修飾ドメイン名(FQDN)を指定すると、クラスタの作成が失敗することがあります。通常は、指定したドメイン ネーム サービス(DNS)サーバが利用できないために起こります。

これは、ドメイン名または IP アドレスで識別する HX Data Platform インストーラ オブジェクトとして入力されるすべてのドメイン名オブジェクトに当てはまります。これには、vCenter Server、ESX サーバ、コントローラ VM のアドレス、ストレージ クラスタ管理またはデータ ネットワークのアドレス、DNS サーバ、NTP サーバ、メール サーバ、または SSO サーバがあります。

アクション: DNS サーバを確認する

手順


ステップ 1

HX Data Platform インストーラ VM のコマンド ラインにログインします。たとえば、ssh を使用します。

ステップ 2

指定された DN サーバが動作することを確認します。

  1. DNS サーバの IP アドレスを確認します。

    # nslookup <dns_server>

  2. ストレージ クラスタで使用するように設定されているすべての DNS サーバについて繰り返します。

ステップ 3

クラスタの作成に必要な各オブジェクトが、指定された DNS サーバから解決できることを確認します。これらのオブジェクトは、JSON ファイルまたは HX DP インストーラ GUI フィールドを通じて指定されます。

  1. クラスタ オブジェクトの IP アドレスを特定します。

    # nslookup <object> <dns_server>

    <object> は、クラスタの設定で HX Data Platform インストーラに指定する可能性があるすべてのオブジェクト、つまり、vCenter Server、ESX サーバ、コントローラ VM のアドレス、ストレージ クラスタ管理またはデータ ネットワークのアドレス、DNS サーバ、NTP サーバ、メール サーバ、SSO サーバなどの FQDN または IP アドレスです。

  2. クラスタの設定オブジェクトごとに繰り返します。

ステップ 4

手順 2 または手順 3 のいずれかが確認できない場合、HX Data Platform Installer GUI では完全修飾ドメイン名(FQDN)ではなく、IP アドレスのみを使用します。


オフライン アップグレードでのクラスタ起動コマンド エラー:ノードを利用できません(Node Not Available)

Description

オフライン アップグレード後、VMware EAM の問題により、一部のコントローラ VM が再起動しないことがあります。stcli start cluster コマンドが「Node not available」というエラーを返します。

アクション:コントローラ VM の電源を手動でオンにして、ストレージ クラスタを起動してください。

手順


ステップ 1

コントローラ VM の電源を手動でオンにします。

  1. vSphere Web クライアントにログインします。

  2. 電源がオンになっていないコントローラ VM を見つけ出します。

    ナビゲータで [vCenter Inventory Lists] > [Virtual Machines] > [vm] を選択します。

    ストレージ コントローラ VM の名前には、stCtlVM というプレフィックスが付きます。

  3. 右クリックするか、または [Actions] メニューから、[Power] > [Power On] を選択します。

  4. すべてのストレージ コントローラ VM の電源がオンになるまで、この手順を繰り返します。

ステップ 2

ストレージ クラスタを再起動します。

  1. 任意のコントローラ VM のコマンド ラインにログインします。

  2. コマンドを実行します。

    # stcli クラスタ開始


HX プラグインの導入後に vSphere Replication プラグインが失敗する

Description

このエラーは、HX Data Platform プラグインをインストールした後に vSphere Replication プラグインをインストールすると発生します。最初に vSphere Replication プラグインをインストールしてから、HX Data Platform プラグインをインストールすることを推奨します。

アクション:HX Data Platform プラグインの登録を解除する

このタスクでは、HX 拡張機能を vCenter Managed Obejct Browser(MOB)から削除します。

始める前に

  1. vSphere Replication プラグインを vCenter MOB から削除します。

  2. vSphere Replication 仮想マシンを vCenter インベントリから削除します。

  3. HX vCenter クラスタを vCenter データセンターから削除します。

手順


ステップ 1

まだの場合、vSphere ESX Agent Manager SDK をダウンロードします。

ステップ 2

VCenter から HyperFlexクラスタ オブジェクトを削除します。

ステップ 3

vCenter サーバ MOB 拡張マネージャにログインします。

  1. ブラウザで、パスとコマンドを入力します。

    https://vcenter_server/mob/moid=ExtensionManager&doPath=extensionList

  2. ログイン クレデンシャルを入力します。

ステップ 4

vCenter Server MOB 拡張マネージャで、MOB と、削除したクラスタに関連付けられている拡張機能を表示します。

  1. rootFolder を見つけて (Datacenters) リンクをクリックします。

    [Data Object Type: ServiceContent] ページで [Name] 列をスクロールして、[Value] 列に示されているリンクをクリックします。

  2. childEntity を見つけて (datacenter_name) リンクをクリックします。

    [Managed Object Type: ManagedObjectReference:Folder] ページで [Name] 列をスクロールして、[Value] 列に示されているリンクをクリックします。

  3. hostFolder を見つけて (host) リンクをクリックします。

    [Managed Object Type: ManagedObjectReference:Datacenter] ページで [Name] 列をスクロールして、[Value] 列に示されているリンクをクリックします。

  4. childEntity を見つけて、(datacenter_name) に対応する値をメモします。この値は、登録解除するクラスタのドメイン ID です。

    [Managed Object Type: ManagedObjectReference:Folder] ページで [Name] 列をスクロールして、[Value] 列に示されているリンクをクリックします。

ステップ 5

[ExtensionManager] ページで、拡張機能を登録解除します。

  1. ブラウザで、パスとコマンドを入力します。

    https://vcenter_server/mob/moid=ExtensionManager&method=unregisterExtension

  2. 拡張キーの値または (datacenter_name_link) を入力し、[Invoke Method] をクリックします。

ステップ 6

削除したクラスタが、vCenter が HX Data Platform プラグインと通信するために使用していた CIP である場合、vsphere-client サービスを再起動します。

  1. vCenter Server MOB 拡張マネージャで、MOB と、削除したクラスタに関連付けられている拡張機能を表示します。

  2. extensionManager を見つけて ExtensionManager リンクをクリックします。

    [Data Object Type: ServiceContent] ページで [Name] 列をスクロールして、[Value] 列に示されているリンクをクリックします。

  3. extensionLIst["com.springpath.sysmgmt"] リンクを見つけます。

    [Managed Object Type: ManagedObjectReference:ExtensionManager] ページで [Value] 列をスクロールして、この列に示されているリンクをクリックします。完全なリストを表示する必要がある場合は、(more...) をクリックします。

  4. server を見つけて server リンクをクリックします。

    [Data Object Type: Extension] ページで [Name] 列をスクロールして、[Value] 列に示されているリンクをクリックします。

  5. /plugins/stGui-1.0.zip で終わる URL を見つけます。これは HX Data Platform プラグインに使用される CIP です(例:"https://cs002-cip-m.eng.storvisor.com/plugins/stGui-1.0.zip")。

    [Data Object Type: ExtensionServerInfo[]] ページで明細リストをスクロールして、[Name: url]、[Type: string] で [Value] が /plugins/stGui-1.0.zip のものを見つけます。

ステップ 7

前のステップで見つけた CIP が、vCenter から削除したクラスタに関連付けられている場合、拡張機能をクリーンアップする必要があります。

  1. ssh を使用して vCenter にログインします。

  2. HX Data Platform プラグイン拡張機能フォルダをクリーンアップします。バージョンは古いものの、まだ互換性のある HX Data Platform プラグインを別のクラスタが実行している場合は、この作業が必要です。

  3. vSphere サービスを再起動します。コマンドを実行します。

    # service vsphere-client restart

ステップ 8

すべてのセッションからログアウトし、再度ログインします。


次のタスク

  1. データセンター クラスタを再作成します。ホストを一度に 1 つずつ HX vCenter クラスタに追加します。

  2. データストアから vSphere Replication 仮想マシンを再登録します。

  3. vSphere Replication アプリケーションの Web フロント エンドで、vSphere Replication プラグインを再作成します。再作成した vSphere Replication プラグインが vCenter 内で使用可能であることを確認します。

  4. HX Data Platform インストーラから HX Data Platform プラグインを再インストールし、ストレージ クラスタを再作成します。

アップグレードは失敗するが、すべてのノードが最新であると報告される

Description

この問題は、vCenter から送信される RemoteException によるものです。この例外の原因として最も可能性が高いのは、HX ストレージ クラスタと vCenter 間のネットワーク接続が断続的に途切れることにあります。

アクション:アップグレードを再試行します

オンライン アップグレードの再開が失敗する

Description

まれに、アップグレードが失敗した HX ストレージ クラスタでオンライン アップグレードを再開しようとすると、アップグレードが再び失敗することがあります。ただし、HX クラスタは障害状態から回復して、正常な状態になっています。

アクション:もう一度アップグレードを再試行する

CLI を使用してアップグレードを再試行する場合は、stcli cluster upgrade コマンドで -f または --force オプションを使用します。あるいは、HX Data Platform プラグインを使用してアップグレードを再試行してください。

Cisco UCS のアップグレード中にコントローラ VM の電源がオンにならない

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 に連絡してサポートを求めてください。


vCenter の問題によりノードがアップグレードに失敗する

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 コマンド ラインにログインします。たとえば 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

ノードを手動で再起動します。


クラスタの拡張エラー:クラスタが見つからない

説明

HX Data Platform のクラスタ拡張ウィザードで、HX ストレージ クラスタが見つかりませんでした。

アクション:クラスタの IP アドレスを手動で入力する

クラスタ拡張ウィザードの [Management IP Address] フィールドに、手動で HX ストレージ クラスタ管理 IP アドレスを入力します。

クラスタ IP アドレスを見つけるには、次のようにします。

手順


ステップ 1

vSphere Web クライアントから、[vCenter Inventory Lists] > [Cisco HyperFlex Systems] > [Cisco HX Data Platform] を選択します。

ステップ 2

ストレージ クラスタ名をクリックして選択します。パネルの最上部にある [Action Menu] から、[Summary] を選択します。

ステップ 3

表示された概要から、クラスタ管理 IP アドレスを見つけます。


DNS サーバが見つからないためにクラスタの拡張が失敗する

Description

ストレージ クラスタの拡張では、新しいノードを 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 フィールドを通じて指定されます。

  1. クラスタ オブジェクトの IP アドレスを特定します。

    # nslookup <object> <dns_server>

    <object> は、クラスタの設定で HX Data Platform インストーラに指定する可能性があるすべてのオブジェクト、つまり、vCenter Server、ESX サーバ、コントローラ VM のアドレス、ストレージ クラスタ管理またはデータ ネットワークのアドレス、DNS サーバ、NTP サーバ、メール サーバ、SSO サーバなどの FQDN または IP アドレスです。

  2. クラスタの設定オブジェクトごとに繰り返します。

  3. オブジェクトが解決に失敗する場合は、DNS サーバ ファイルにエントリを追加します。

ステップ 6

指定された DN サーバが動作することを確認します。

  1. DNS サーバの IP アドレスを確認します。

    # nslookup <dns_server>

  2. ストレージ クラスタで使用するように設定されているすべての DNS サーバについて繰り返します。

ステップ 7

手順 5 と手順 6 を繰り返し、追加されたすべての DNS サーバが有効で、すべての HXDP オブジェクトが各 DNS サーバを通じて解決できることを確認します。

ステップ 8

HX Data Platform インストーラに戻り、ストレージ クラスタの拡張を続行します。


古い HX インストーラによりクラスタの拡張が失敗する

Description

拡張のために追加したクラスタ ノードが間違ったクラスタに追加されます。これは、複数のクラスタの作成で同じ HX Data Platform インストーラを使用し、その後、その同じ HX DP インストーラを使用してそれらクラスタの 1 つを拡張する場合に起こります。HX DP インストーラは、デフォルトでは最新のクラスタにノードを追加します。

アクション: HX Data Platform インストーラ OVA を再展開する

手順


ステップ 1

HX Data Platform インストーラ OVA を再展開します。

ステップ 2

新しい HX Data Platform インストーラを使用してクラスタを拡張します。


ホストの問題

手動による ESX インストール後の statsd の再起動

Description

手動で HX Data Platform サーバに ESX を再インストールした後、パフォーマンス統計情報が正しく表示されるように、stats daemon をリセットします。

アクション:stats daemon の再起動

手順


ステップ 1

ESX ホストのコントローラ VM のコマンドラインにログインします。

ステップ 2

restart コマンドを実行します。

# /etc/init.d/statsd restart

ステップ 3

ストレージ クラスタのすべての ESX ホストのコントローラ VM でステップ 1 およびステップ 2 を繰り返します。


services.sh restart 実行時の scvmclient 管理サービスの再起動

説明

services.sh restart を実行すると、scvmclient 管理サービスが再起動する。


注意    

このコマンドを実行すると、特定のホストから HX データストアが接続解除されます。


  1. ノードをメンテナンス モードにします。

  2. ESX コマンド ラインにログインします。

  3. サービスを再起動します。

    # services.sh restart

  4. ESX ホスト デーモン、vCenter エージェント サービス、およびコントローラ VM を再起動します。

    # /etc/init.d/hostd restart

    # /etc/init.d/vpxa restart

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 の電源をオンにする

手順


ステップ 1

最初に障害が発生したホスト上で HA を再設定します。

ステップ 2

ストレージ コントローラ VM を手動で電源オンにします。


クラスタへの別ノード同時追加時のノード障害

説明

既存のストレージ クラスタにノードを追加する場合、ストレージ クラスタは、再調整が完了するまで元のストレージ クラスタと同じ HA 復元力を持ち続けます。

たとえば、3 ノードのストレージ クラスタがあり、2 つのコンバージド ノードをストレージ クラスタに追加する場合などです。再調整が完了するまで、ストレージ クラスタは、5 ノードのストレージ クラスタではなく、3 ノードのストレージ クラスタとして動作します。したがって、バランスの再調整が完了する前にノードで障害が発生すると、ストレージ クラスタのステータスは低下します。


(注)  

再調整は通常、次のような状況で発生します。

  • 24 時間の再調整スケジュールごとに行われ、ノードに障害が発生した場合の 2 時間後、またはストレージ クラスタの領域が不足している場合にも行われます。

  • 1 つのディスクの使用率が 50 % を超えた場合またはディスク クラスタの集約使用率が 50 % 未満の場合。


アクション:ストレージ クラスタの再調整を手動で開始する

手順


ステップ 1

ストレージ コントローラ VM のコマンド ラインから次のコマンドを実行します。

# stcli rebalance start --force
ステップ 2

再調整ステータスをモニタするには、次のコマンドを使用します。

# stcli rebalance status

vNIC または vHBA の変更後の PCI パススルーの設定

Description

vNIC または vHBA を手動で Cisco HyperFlex (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 クライアントで、[ESX host] > [Configuration] タブ > [Hardware] ペイン > [Advanced Settings] > [Edit] の順に選択します。

vCenter Web クライアントの [vCenter Inventory] で、[Resources] > [Hosts] > [ESX host] > [Manage] > [Settings] > [Hardware] > [PCI Devices] > [Edit] の順に選択します。

ステップ 5

パススルー用の LSI カードを選択します。

  1. [DirectPath I/O Configuration] ページから、[Configure Passthrough] を選択します。

  2. [Mark devices for passthrough] リストから、パススルー用の LSI カードを選択します。

  3. [OK] をクリックします。

ステップ 6

ESX ホストをリブートします。

ステップ 7

HX ストレージ コントローラ VM(StCtlVM)の設定を編集して、PCI デバイスを HX ストレージ コントローラ VM に再マップします。

  1. 不明な PCI デバイスを見つけて削除します。

    vCenter クライアントで、[HX storage controller VM] を右クリックして [Edit Settings] > [PCI device 0] > [Remove] > [OK] の順に選択します。

    vCenter Web クライアント:[HX storage controller VM] を右クリックし、[Edit Settings] > [Remove PCI device 0] > [OK] の順に選択します。

  2. LSI ロジック PCI デバイスを見つけて追加し直します。

    vCenter クライアント:[HX storage controller VM] を右クリックし、[Edit Settings] > [Add] > [PCI Device] > [LSI Logic PCI device] > [OK] の順に選択します。

    vCenter Web クライアント:[HX storage controller VM] を右クリックし、[Edit Settings] > [PCI Device] > [Add] > [LSI Logic PCI device] > [OK] の順に選択します。

ステップ 8

HX メンテナンス モードから ESX ホストを削除します。

ホストが再びアクティブになると、HX ストレージ コントローラ VM が正常にブートして、ストレージ クラスタに再参加します。


ディスクの問題

3 ノードのストレージ クラスタ上で、すべてまたは大半のディスクに障害が発生すると、データの割り当てができない

説明

ノード上のすべてのハード ディスクに障害が発生すると、HX Data Platform はノードにデータを割り当てることができません。3 ノードのストレージ クラスタでこの問題が発生した場合、HX Data Platform は、データの整合性を維持する上で最低限必要な 3 つのデータのコピーを維持することができません。その結果、仮想的な ENOSPC 状態となります。

ノード上で複数のハード ディスクに障害が発生し続けた場合、ストレージ クラスタはノードへの書き込みを行おうとし、ディスク上の残りの領域を使用することから、不安定な状態となります。たとえば、3 つのノードすべてに 10 台の HDD があり、3 番目のノード上で 9 台の HDD に障害が発生した場合、不安定な状況が生じた結果、3 番目のノード上のディスクでは、クラスタのサイズが実際のサイズの 10 % に制限されます。これは、物理的な ENOSPC 状態です。また、オール パス ダウン(APD)状態を引き起こす可能性もあります。

アクション:ストレージ クラスタ内のすべてのノード上で、ストレージを物理的に調整します。

手順


ステップ 1

破損したディスクを問題のないディスクと交換します。

ステップ 2

ストレージ クラスタに別のノードを追加します。

ステップ 3

確実に整合性がとれるように、ノードのストレージ キャパシティを調整します。

ステップ 4

ストレージ クラスタが自動的に回復しない場合は、ストレージ クラスタを再起動する必要があります。

  1. クラスタ内のいずれかのノード上で、ストレージ コントローラ VM のコマンド ラインにログインします。

  2. ストレージ クラスタをシャットダウンします。

    stcli cluster shutdown

  3. ストレージ クラスタを再起動します。

    stcli cluster start


ディスクを削除するとストレージ コントローラ VM の再起動に失敗する

説明

ディスクを削除して、自動再スキャンが完了する前にストレージ コントローラ VM を再起動した場合、ストレージ コントローラ VM の電源がオンにならない場合があります。

アクション:ディスクの削除後にストレージ コントローラ VM の電源をオンにする

手順


ステップ 1

ストレージ コントローラ VM の電源がオフになっていることを確認します。

ステップ 2

スクリプトを実行します。

/opt/springpath/support/rescanLuns.sh

ステップ 3

ストレージ コントローラ 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 の電源をオンにします。


インストール後に SCVM クロックを同期する方法

インストール後に SCVM クロックを同期するには、次の手順に従います

  1. Storfs を停止する前に、ユーザの VM の電源を切ります。

  2. 各ノードで、次のコマンドを実行します。

    
    Stop storfs
    ntpsync -yfs.
  3. すべてのノードが NTP と同期するのを待ちます。

  4. storfs を開始します。

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 を適切に調整します。

自動 vMotion 移行がタイムアウト エラーで失敗する

Description

この問題は、16 + 16 ノードのクラスタで観察されています。これは、VMware の既知の問題です。詳細については、VMware KB の記事「vMotion of a VM fails with the error: "Timed out waiting for migration data" (2143834)」を参照してください。

アクション:ネットワーク接続を確認する

2 つのノードの障害によりストレージ コントローラ VM の電源オンに失敗する

Description

これは、VMware EAM(ESX Agent Manager)の問題が原因です。EAM がホスト上の VM を正しくマーキングしていません。

アクション:ストレージ クラスタを再登録する

ストレージ クラスタを再登録して vCenter ビューを同期します。ストレージ コントローラ VM で、次のコマンドを実行します。

# stcli cluster reregister

HA および DRS が有効な状態でホストに VM を追加できない

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 でのパフォーマンス低下

説明

ディスク共有の制限が設定された VM の電源がオンになると、各データストアのパフォーマンスが低下する。

アクション:VMware 単位で想定されている動作です。

手順


ステップ 1

mclock スケジューラを無効化します。

ステップ 2

デフォルトのスケジューラに移動します。


ストレージ クラスタが読み取り専用状態の場合の DRS による VM の移行

説明

ストレージ クラスタが読み取り専用状態になっていると、それらがすでに読み取り専用のストレージ クラスタにある場合であっても、VMware DRS プロセスは VM をデータストアに移行します。その結果 VM は起動不可になります。

アクション:ストレージ クラスタが読み取り専用状態の場合には、DRS を手動で無効にします。

手順


ステップ 1

HX Data Platform ストレージ クラスタを選択します。

vSphere Web クライアント ナビゲータから、[vCenter Inventory Lists] > [vCenter Inventory Lists] > [Cisco HyperFlex Systems] > [Cisco HX Data Platform] > [cluster] の順に選択します。

ステップ 2

[Summary] タブを選択し、[VC Cluster] リンクをクリックして [vCenter Summary] タブに切り替えます。[Manage] > [Services] > [vSphere DRS] の順にクリックします。[Edit] をクリックして [Turn ON vSphere DRS] をオフにし、[OK] をクリックします。


古い EAM 拡張により VM の電源オンに失敗する

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 拡張機能を参照するフィールド、cluster_domain_id があります。この拡張機能 ID には、Managed Object ID(moid)が使用されています。

ストレージ コントローラ VM コマンド ラインから次のコマンドを実行します。

# stcli cluster info | grep vCenterClusterId:
vCenterClusterId: domain-c26
ステップ 4

ストレージ クラスタの拡張機能を登録解除する:vCenter サーバ MOB 拡張機能マネージャにログインします。

まず、HyperFlex クラスタを登録解除します。

  1. ブラウザで、パスとコマンドを入力します。

    https://vcenter_server/mob/?moid=ExtensionManager

    vcenter_server は、ストレージ クラスタが現在登録されている vCenter の IP アドレスです。

  2. 管理者用のログイン資格情報を入力します。

ステップ 5

クラスタ ID を持つ HX ストレージ クラスタ拡張機能を探します。[Properties] > [extensionList] をスクロールして、次のストレージ クラスタ拡張機能を探します

com.springpath.sysmgmt.cluster_domain_id および com.springpath.sysmgmt.uuid.cluster_domain_id

クリップボードに、これらの文字列をそれぞれコピーします。文字列の端に二重引用符(”)がある場合、それを除外します。

ステップ 6

各ストレージ クラスタ拡張機能の登録を解除します。

  1. [Methods] テーブルから [UnregisterExtension] をクリックします。

  2. [UnregisterExtension] ポップアップに拡張機能のキー値である com.springpath.sysgmt.cluster_domain_id を入力します。

    例:com.springpath.sysgmt.domain-26

  3. [Invoke Method] をクリックします。

ステップ 7

古い EAM 拡張機能を削除する:vCenter サーバ MOB ESX エージェンシー拡張機能マネージャにログインします。

次に、HyperFlex クラスタに関連付けられていた古い EAM 拡張機能を削除します。

  1. ブラウザで、パスとコマンドを入力します。

    https://vcenter_server/eam/mob/

    vcenter_server は、ストレージ クラスタが現在登録されている vCenter の IP アドレスです。

  2. 管理者用のログイン資格情報を入力します。

ステップ 8

当該のクラスタ ID を持つ古い HX ストレージ クラスタの ESX エージェンシー拡張機能を見つけます。

  1. [Properties] > [agency] > [Value] をスクロールします。

  2. エージェンシーの値をクリックします。

  3. [Agency] ウィンドウで、[Properties] > [solutionID] > [Value] の拡張機能を確認します。正しい cluster_domain_id があることを確認します。

    例:com.springpath.sysgmt.domain-26

ステップ 9

古い ESX エージェンシー拡張機能を削除します。

  1. [Agency] ウィンドウの [Methods] テーブルからメソッドを選択します。

    古い ESX エージェンシーは、destroyAgency または uninstall のいずれかを使用すると削除できます。

  2. [method] ポップアップで、[Invoke Method] をクリックします。

ステップ 10

[ExtensionManager] タブを更新し、[extensionList] エントリに com.springpath.sysgmt.cluster_domain_id という拡張機能が含まれていないことを確認します。

ステップ 11

vSphere クライアント サービスを再起動します。

vSphere クライアント サービスが再起動されると、HX Data Platform の拡張機能が削除されます。vSphere クライアント サービスを再起動すると、ブラウザから vCenter へのアクセスが一時的に無効になります。

ステップ 12

HX Data Platform のインストールを実行し完了します。

古い EAM 拡張の削除に関する追加オプションについては、テクニカル アシスタンス センター(TAC)に確認してください。


VM フォルダやファイルの削除に非常に長い時間がかかる

説明

ユーザ VM が、ファイル システム内に残っているユーザ VM 向けに作成された ESX *.lck ファイルや、vSphere にアクセスできなくなった場合、VM ファイルやフォルダの削除には非常に長い時間がかかる場合があります。

アクション:ESX サーバの VM ロック ファイルをクリアする

手順


ステップ 1

ストレージ クラスタ内のすべての VM ロック ファイルを探します。

# cd /vmfs/volumes/my_datastore

# find . -name .lck* | xargs -n1 rm

ステップ 2

VM のファイルまたはフォルダの削除を再試行します。


VM ディスク使用率と vCenter VM コミット サイズの不一致

Description

VM にスナップショットまたは ReadyClone がある場合、VM ディスク使用率が vCenter の仮想マシン コミット サイズと一致しません。

アクション:なし

VM タスクの移行が失敗し、結果としてレプリケーションエラー10001が発生する

説明

最大 32 個のレプリケーションジョブを同時に実行できます。VM の移行を開始すると、新しいレプリケーションジョブがトリガーされます。アグレッシブなレプリケーション間隔で多数の VM でデータレプリケーションを設定し、スケジュールされたレプリケーションジョブが継続的に実行されている場合は、新しいレプリケーションジョブが失敗し、レプリケーションエラーが発生する可能性があります。

回避策

システムで実行されているレプリケーションジョブが 32 個未満の場合は、[VM の移行 (migrate VM)] タスクを再び開始します。また、既存のレプリケーションスケジュールのレプリケーション間隔を増やして、ウィンドウを作成し、移行タスクの完了後に元のレプリケーション間隔に戻すこともできます。

VM の移行でエラーが発生しました

説明

VM を移行すると、新しいスナップショットが取得され、新しいレプリケーションタスクが開始されます。既存のレプリケーションタスクが現在進行中であり、別のスナップショットがまだ複製されていない場合、移行タスクは失敗し、次のエラーメッセージが表示されます。

PrepareFailover が失敗しました。最新の VM の失敗していないスナップショット: xx ~ xx-xx は複製されていません。

回避策

進行中のすべての複製タスクが完了したら、VM の移行を再開始します。古いスナップショットがある場合は、次のコマンドを使用して手動で削除します。

stcli dp vm スナップショットの削除: vmid xxx--スナップショット id xxx

データストアの問題

コンピューティング ノードを削除してもデータストアが削除されない

説明

ストレージ クラスタからコンピューティング ノードを削除しても、関連付けられているデータストアが削除されませんでした。

アクション:データストアを手動で削除する

複数のデータストア追加時のエラー:ホスト上にマウント ポイントが見つからない

Description

VMware の問題により、同時に複数のデータストアを追加しようとして、一部のデータストアがマウントされないことがあります。

アクション:データストアを再マウントする

  • 一度にマウントするデータストアを減らしてマウントします。

    HX プラグインを使用して、最初にマウントされなかったデータストアを再マウントします。

NFS 全パス ダウンが発生し [File Locked by Consumer on Host] メッセージが表示される

説明

シリアル I/O 制御(SIOC)に関する VMware の問題が原因で、NFS 全パス ダウン(APD)が発生し、次のようなメッセージが表示されます。

NFSLock: 2210: ファイルはホスト host_name 上のコンシューマーによって排他ロックでロックされています。

アクション:[Storage I/O Control] を切り替える

手順


ステップ 1

vCenter からデータストア ビューで [datastore] > [Configuration] > [Properties] を選択します。

ステップ 2

[Storage I/O Control] を反対の状態に切り替えます。

有効な場合は無効にします。無効な場合は有効にします。

ステップ 3

[Storage I/O Control] を元の状態に戻します。

有効な場合は無効にします。無効な場合は有効にします。

ステップ 4

NFS ロックが解除されていることを確認します。


NFS のキューの深さの最大制限が最適ではありません

[説明(Description)]

Hyperflex クラスタを Hyperflex 2.5 以前のリリースからアップグレードする場合、ホストごとの NFS データストアのキュー深度の上限はデフォルトで 256 に設定されます。この設定は、パフォーマンスの問題となる可能性があります。


(注)  

このセクションは、VDI 固有の展開には適用されません。


アクション(Action)

キュー深度が 1024 未満のすべてのノードに対して次の手順を実行して、NFS キューの最大深度を確認し、必要に応じて最大制限を増やします。

esxcli system settings advanced list -o /NFS/MaxQueueDepth
maxQDepth:256 <- Low value

Hyperflex メンテナンス モードでノードを配置し、次のコマンドを実行します。次の変更を有効にするには、ノードと ESXi ホストを再起動します。

esxcli system settings advanced set -o /NFS/MaxQueueDepth -i 1024
esxcli system settings advanced list -o /NFS/MaxQueueDepth
maxQDepth:1024 <- Optimal value

VLAN ID の変更後、データストアのマウントに失敗する

説明

ストレージ クラスタの作成後に VLAN ID を変更すると、データストアのストレージ クラスタへのマウントに失敗します。既存のデータストアを、ストレージ クラスタからマウント解除することはできます。

アクション:ESX サーバのファイアウォールをリロードします。

ESX サーバのファイアウォールのリロードに関する指示については、VMware ESX のマニュアルを参照してください。

データ vSwitch に IP アドレス設定済みの VM カーネル ポートがある場合、データストアのマウントが失敗する

説明

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 プラグインを使用する。

  1. vSphere Web クライアントの [Navigator] から、[vCenter Inventory Lists] > [Cisco HyperFlex Systems] > [Cisco HX Data Platform] > [cluster] > [Manage] > [Datastores] の順に選択します。

  2. [datastore] を選択します。

  3. [データストアのマウント(mount datastore)] アイコンをクリックするか、[アクション(Actions)] メニューから選択します。

  4. データストアのマウントを確認し、[OK] をクリックします。

ステップ 2

コマンド ラインを使用する。

  1. ストレージ クラスタ内のノードのストレージ コントローラ VM にログインします。

  2. コマンドを実行します。

    # stcli datastore mount datastore_name


ストレージ I/O RM デーモンの実行時にデータストアのマウント解除ができない

説明

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 デーモンを再起動します。


エラー「com.vmware.vim25.PlatformConfigFault」を伴うデータストア削除の失敗

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 で使用されているかどうかを確認します。

# 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 を無効にします。

  1. vSphere クライアントの [Home] から、[vCenter Inventory Lists] > [Resources] > [Clusters > storage cluster > Manage] > [Settings] > > [Services] の順に選択します。

  2. [vSphere HA] をクリックします。[Edit] をクリックします。

  3. 選択されている場合は、[Turn on vSphere HA] の選択を解除します。

ステップ 6

データストアの削除を再試行してください。

ステップ 7

VSphere HA を無効にしていた場合は再度有効にします。

ステップ 8

可能なソリューションはこれ 1 つです。これで問題が解決しない場合は、テクニカル アシスタンス センター(TAC)にお問い合わせください。


ReadyClone、スナップショット、レプリケーションの問題

VMware ツールを使用して VM を停止するとレプリケーションが失敗する

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] を選択します。

  • 独立して保護されている場合:[Replication] > [Protected Virtual Machines] > [vm_name] > [Edit Schedule] を選択します。

  • 独立して保護されている場合:[Replication] > [Protection Groups] > [protection_group] > [Edit Schedule] を選択します。

ステップ 3

[Use VMware Tools to quiesce the virtual machine] を選択解除し、[Save Changes] を選択します。


ターゲット データストアの名前を変更すると、タスクの移行が失敗する

説明

vCenter から保護された VM のターゲット データストアの名前を変更し、VM で移行が実行されると、移行タスクはエラー応答で回復時に失敗します。

Failover: Failover failed for VM: KD-3. Reason: Clone files failed with error 10031 for <VMID>

操作(Action)

同じ VM で移行を再試行します。


(注)  

最新のスナップショットがデータストアの名前を変更した後に予定通り策定された場合、移行は問題なく動作します。


Workflows のバックアップが失敗しエラー メッセージが表示されます。

説明

場合によっては、スナップショット ワークフローまたはバックアップ ワークフロー中に、差分ディスクが正確にクリーンアップされないことがあります。この時点で、ワークフローは完全に実行できず失敗します。次のエラー メッセージも表示されます。

Non-native snapshots exists – Error” 

Action:

差分ディスクを指すスナップショットを削除するか、すべてのスナップショットを削除してバックアップ ワークフローを再開します。

データストアの名前変更後にリカバリが失敗する

Description

ターゲット データストアの名前変更直後にリカバリを実行すると、「データストアが見つかりません(Datastore not found)」というエラーでリカバリが失敗することがあります。

アクション:リカバリを再試行する

データストアの名前の変更後数分間待機してから、リカバリを再試行します。

ノードを再起動すると、リカバリ、復元、複製が停止する

Description

次のコマンドを実行している間にノードを再起動すると、コマンド アクションが停止し、その後コマンドを再試行しても失敗します。

  • stcli dp vm recover

    stcli dp vm restore

    stcli dp vm clone

アクション:仮想マシンをクリーンアップする

手順


ステップ 1

vCenter から仮想マシンをクリーンアップします。

適切なオプションを選択します。

  • 仮想マシンが登録されている場合は、vCenter から仮想マシンを削除します。

  • 仮想マシンが登録されていない場合は、データストアから VM フォルダを削除します。

ステップ 2

stcli dp vm コマンドを再実行します。


stcli vm recover コマンドを再実行すると失敗する

説明

stcli vm recover を使用して初めて仮想マシンの回復を試行しましたが、完了しませんでした。また、このコマンドを再実行しても完了しませんでした。

部分的に回復した場合、仮想マシンが vCenter に登録されたままになっている可能性があります。これは削除する必要があります。

アクション:残っているファイルをクリーンアップする

手順


ステップ 1

vCenter から仮想マシンを削除します。

ステップ 2

/vmfs/volumes/<volume>/<vmname> ディレクトリを削除します。

ステップ 3

リカバリ コマンドを再実行します。

# stcli vm recover


REST API 保護グループ フィルタがすべてのグループを返す

説明

REST API を使用して保護グループを検索すると、REST 呼び出しでフィルタを適用するとしても、検索結果としてすべての保護グループが返されます。

アクション:なし

groups:get では、フィルタの name および type パラメータはサポートされません。

VM がスナップショット統合中に機能しなくなる

Description

HX ストレージ クラスタ内の VM に関する redo ログ スナップショットを取る場合は、redo ログ スナップショットを保存する ESXi ホストの設定を編集します。この手順が完了していない場合は、VM がスナップショット統合中に機能しなくなる可能性があります。

redo ログ スナップショットは、HX Data Platform のスナップショット機能ではなく、VMware のスナップショット機能を介して作成されるスナップショットです。

アクション:ESXi ホストで snapshot.asyncConsolidate="TRUE" を設定する

手順


ステップ 1

ESXi ホストのコマンド ラインにログインします

ステップ 2

ファイル /etc/vmware/config を探して編集用に開きます。

ステップ 3

snapshot.asyncConsolidate パラメータを TRUE に設定します。

snapshot.asyncConsolidate="TRUE"

[Quiesce] オプションを使用したネイティブ スナップショット

説明

VM の電源がオンの場合に、Windows 2008 または Windows 2012 サーバでの [Quiesce] オプションを使用したネイティブ スナップショットはサポートされていません。

アクション:[Quiesce] 以外のオプションを使用する

VM の電源をオフにしてから、スナップショットを作成するか、または [Quiesce] 以外のデフォルト オプションを使用します。

vMotion がネイティブ スナップショット データストアを移動できない

説明

vMotion によるネイティブ スナップショットの移動で、関連するデータストアを移動できません。ネイティブ スナップショットのある仮想マシンで、vMotion の使用はサポートされていますが、ストレージ vMotion の選択のみサポートされていません。

アクション:元の VM だけに対して vMotion を使用する

VM を別のデータストアに移動する必要がある場合は、ソースのデータストアからスナップショットを削除し、元の VM に vMotion を実行します。

保護状態では、VM に対する再保護オプションは使用できません

保護状態では、VM に対する再保護オプションは使用できません。

アクション: VM の保護を解除し、再度保護します。

手順


ステップ 1

VM (サイト B のローカル VM) を選択し、[保護解除(unprotect)] をクリックします。仮想マシンが保護されていないことが表示され、セカンダリサイト (つまり、プライマリサイトのリモート) に対してローカルにも消失し、プライマリ サイトでリモートであり、サイト B の [仮想マシン (Virtual machine)] セクションに表示されることを示すメッセージが表示されます。

ステップ 2

VM を選択し、再度保護します。

ターゲットサイトへの VM のフルコピーは、この方法を使用して実現できます。VM のコピーは、ターゲットサイトに存在します。


クラスタの問題

クラスタの再登録後にコントローラ VM が EAM エージェントではなくなっている

Description

stcli cluster reregister の実行後に、コントローラ VM が EAM エージェントとしてリストされません。

アクション:クラスタを再作成する

手順


ステップ 1

vCenter クラスタを削除します。

ステップ 2

vCenter クラスタを再作成します。

ステップ 3

HX クラスタを再登録します。

# stcli cluster reregister


複数の再登録後にクラスタが異常な状態になる

Description

複数のクラスタ再登録を実行すると、クラスタが異常な状態になることがあります。

アクション:クラスタを再作成する

HX Clusterは vCenter 情報を失い、virtCluster および HX Connect ステータスはクラスタがオフラインであることを示します。ただし HX Data Platform クラスタは、クラスタが全体的に正常だったことを示します。

クラスタを再作成します。

# stcli cluster recreate

ノードの削除後に ClusterNotConfigured エラーが発生する

Description

クラスタからノードを削除した後で、いずれかのコントローラ VM で stcli cluster info コマンドを実行すると ClusterNotConfigured と示されます。

アクション:クラスタを更新する

コントローラ VM コマンド ラインから次のコマンドを実行します。

# stcli cluster refresh

クラスタ容量が個々のディスクよりも大きい

説明

表示されるクラスタ使用率の合計が、個々のディスクに対して示される使用率を上回る場合があります。

たとえば、クラスタ使用率は 80% であるのに対し、使用率が最大のディスクでも、使用率が 76% として示されるといった状況です。

アクション:なし

この違いは、管理レイヤの処理に起因する場合があります。使用率関連の決定を行う場合は常に、必ずクラスタ使用率の値を参考にしてください。

クラスタを再登録してもコンピューティング ノードが EAM に再登録されない

Description

この問題はさまざまなシナリオで発生します。考えられるシナリオは次のとおりです。

シナリオ 1

  1. 2.1.x より前の古い HX バージョンから開始します。

  2. コンピューティング ノードを追加します。

  3. クラスタを再登録します。

  4. クラスタをアップグレードします。クラスタにコンピューティング ノードを含めるタスクが失敗します。

シナリオ 2

  1. 2.1.x より前の古い HX バージョンから開始します。

  2. コンピューティング ノードを追加します。

  3. クラスタをアップグレードします。タスクが完了します。

  4. クラスタを再登録します。EAM レベルでタスクが失敗します。

シナリオ 3

  1. 新しい HX バージョン(2.1.x 以降)で開始します。

  2. コンピューティング ノードを追加します。

  3. クラスタを再登録します。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 サーバが同期されないことがあります。

ESXi ホストで NTP を手動で設定する

手順


NTP クライアントを有効にします。

  1. vSphere Web クライアントから、[host] > [Manager] > [System] > [Time Configuration] > [User Network Time Protocol] を選択します。

  2. [NTP Service Startup Policy] フィールドから、[Start and stop with host] を選択します。[OK] をクリックします。

  3. ストレージ クラスタ内の各 ESXi ホストに対して繰り返します。


プロビジョニングとは異なるクラスタ キャパシティ

説明

HX Data Platform プラグイン内で、[Summary] タブのクラスタ キャパシティと [Manage] タブのプロビジョニングされたキャパシティに、ストレージ クラスタに割り当てられたストレージ量と異なる数値の表示されることがあります。これは、次のような状況で発生します。

  • クリーナーが未完了。VM は削除されたが、クリーナーが実行されていない。クリーナーは自動プロセスであり、完了後にクラスタ キャパシティとプロビジョニングされた量が一致する必要があります。クリーナー コマンドに関する情報については、『Cisco HX Data Platform Command Line Interface Reference guide』を参照してください。

  • シック プロビジョニングまたはシック クローン。シック ディスクまたはクローンが作成された場合、HX Data Platform は領域を確保しません。ソフト予約が使用され、データストアに使用された領域が表示されますが、領域はストレージ クラスタ内で使用されていません。これは、データストアをオーバー プロビジョニングすることがないように、管理者を支援する目的で設計されたものです。

アクション:ありません。

vShield 使用時のストレージ コントローラ VM への接続

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 で、[Host & Clusters] > [Settings & Reports] > [vShield App] > [Exclusion List] > [Add] の順に選択します。各コントローラ VM を stCtlVM<name> で選択します。

ステップ 3

ストレージ コントローラへのネットワーク接続を確認します(ping、ssh など)。

ステップ 4

vShield コンポーネントをインストールして設定します。

ステップ 5

設定が正しく動作することを確認するために、すべての ESXi ホストを同時に再起動してデータストアをオフラインにします。システムをバックアップしてから、手順 3 を繰り返します。


SSLv3 が無効な状態でソフトウェアのバックアップが失敗する

Description

vSphere 5.5 および 6.0 u1 の VMware のバグが原因で SSLv3 が無効な場合、バックアップ ソフトウェアが失敗することがあります。

アクション:VMware KB 記事を参照します

手順


VMware の関連記事へのリンクをクリックします。


クラスタ ノードの電源をオフにした後、vCenter クラスタからストレージ クラスタが見えなくなる

説明

vCenter クラスタ内のノードの電源がオフになっていました。ストレージ クラスタは、ダウン ノード数の許容範囲内であり、正常です。ただし、ストレージ クラスタが vSphere を介して管理できません。

VMware vSphere 6.0 の既知のバグです。次を参照してください。https://communities.vmware.com/thread/514117?start=0&tstart=0

アクション:ノードをリセットする。

ノードの電源をオンにするか、電源がオフのノードを vCenter クラスタから切断します。

インターフェイスの問題

複数の VM 電源操作が原因でタスク キューでエラーが発生する

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 接続データが更新されない

説明

HX Connect ステータス フィールドの表示データが更新されないことがあります。

アクション:ブラウザのキャッシュをクリアする

  • Microsoft Internet Explorer

    1. IE ブラウザから [Settings](歯車) > [Safety] > [Delete browsing history] を選択します。

    2. 適切なチェックボックスをクリックします。

    3. [Delete] をクリックします。

  • Google Chrome

    1. Chrome ブラウザから [Menu](縦に並ぶ 3 つのドット) > [More tools] > [Clear browsing data] を選択します。

    2. 適切なチェックボックスをクリックします。

    3. [CLEAR BROWSING DATA] をクリックします。

  • Mozilla Firefox

    1. Firefox ブラウザから、[Menu](縦に並ぶ 3 本の棒) > [Options](歯車) > [Advanced] > [Network] を選択します。

    2. [Cached Web Content] セクションで [Clear Now] をクリックします。

パフォーマンス チャートにノードを再起動している間のギャップが表示される

説明

HX クラスタでのノード再起動などのイベントによって、システム パフォーマンスが影響される場合があります。そのようなイベントが発生している間は、パフォーマンス チャートにデータ ギャップが示されることがあります。

アクション:なし

イベントが完了すると、パフォーマンス チャートのレポート作成が続行されます。

vSphere クライアントに HX Data Platform プラグインが表示されない

Description

Cisco HyperFlex システムまたは Cisco HX Data Platform が vSphere クライアントまたは Web クライアントに表示されません。この問題が発生する場合には、いくつかの状況が考えられます。該当する状況に対応したアクションを実行してください。

アクション:オプションを選択します

  • HX ストレージ クラスタの作成後に vCenter サービスを再起動します。

  • アップグレード後に vCenter サービスを再起動します。

  • 既存のクラスタがある vCenter に別のクラスタを追加した後に vCenter サービスを再起動します。

  • Firefox ブラウザに最新の Adobe FlashPlayer をインストールします。

手順


ステップ 1

vCenter サービスを再起動します。

  1. vCenter Server コマンド ラインにログインします。

  2. vCenter サービスを再起動します。

    # ssh root@vc_address # service vsphere-client restart

  3. vCenter が再起動するまで待ちます。通常、これには数分かかります。

  4. vCenter からログアウトしてから再度ログインし、vCenter インターフェイスが更新されることを確認します。

ステップ 2

Firefox ブラウザに最新の Adobe FlashPlayer をインストールします。

  1. Shockwave Flash のバージョンを確認します。

    Firefox ブラウザのアドレス バーに about:addons と入力します。

  2. バージョンを確認し、最新の Flash Player を https://get.adobe.com/flashplayer/ からダウンロードしてインストールします。

  3. Shockwave Flash のバージョンを再度確認します。

  4. 最新の Flash バージョン以外のバージョンがリストされている場合は、古いバージョンを無効にします。

  5. vSphere Web クライアントをリロードします。


パフォーマンス チャートの表示が 100% のズームでフォーマットされていない

説明

パフォーマンス チャートの表示が 100% のズームでフォーマットされていません。

オプションのメトリックと小さな解像度を同時に選択すると、正しくフォーマットされていないチャートが表示されます。

アクション:チャートのズームを変更する

HX Data Platform プラグインが機能しない

説明

この問題は、新しいクラスタを作成した既存の vCenter で、別のバージョンの HX Data Platform も使用されている場合に発生することがあります。

アクション:vSphere にログインし直す

vSphere クライアントからログアウトして、もう一度ログインします。