この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
次は、テクニカル アシスタンス センター(TAC)でのアシスタンスで扱われることの多いトピックの一覧です。
ストレージ クラスタの作成失敗。
ストレージ クラスタのアンインストール。
HX Data Platform のアンインストール。
HX Data Platform バージョン 1.7.1 より前のバージョンからの HX Data Platform のアップグレード
ストレージ クラスタへのノード追加の失敗。
ストレージ クラスタ内でノードにディスクを追加しても認識されない。
ノードの削除。
ノードの交換。
HX240c サーバ上でのハウスキーピング SSD の交換。
別のストレージ クラスタで削除したノードの再使用。
削除されたノードのディスクの再利用。
サーバ単位でのデフォルトでない大容量 SSD や HDD を使用する際のサイジングのガイダンスがサポート対象。
MTU 値の 9000 以外への設定。
ストレージ クラスタの IP アドレスの変更。
ストレージ クラスタ用に最適化されて導入された VDI または VSI の変更。
ノード再調整のタイムアウトの変更。
ストレージ回復用のクリーナー スケジュールの設定。
whitelist、recreate などの stcli コマンドの使用。
HX Data Platform サポート バンドルは、HX Data Platform 内にあり HX Data Platform により使用される各種コンポーネントのログの集合です。次の内容が含まれています。
HX Data Platform Installer VM:ログには、インストールに関する情報が記録されています。
Controller VM:ログには、HX Data Platform ファイル システム、クラスタ作成、およびクラスタ拡張に関する情報が記録されています。
ESXi サーバ:ログには、ストレージ クラスタのノードに関する情報が記録されています。
vCenter:ログには、HX Data Platform プラグインと vCenter Server に関する情報が記録されています。
サポート バンドルは、コマンド ラインまたは vCenter Web クライアントから生成できます。コマンド ライン オプションは、vCenter Web クライアントで従来のログ収集を実行するよりも大幅に高速です。
通常、コントローラ VM または ESX サーバからログを収集するときには、ストレージ クラスタ内のすべてのコントローラ VM または ESX サーバからログが収集されます。
(通常、コア ファイルのサイズや、以前に生成されたログ ファイルによってスペースが使用されていることが原因で)ストレージ コントローラ VM に、サポート バンドルを生成できる十分なスペースがない場合には、次のエラーが発生します。これは、vm-support コマンドを使用してサポート バンドルを生成するときに表示されます。
error = [Errno 28] No space left
このエラーを受信した場合にサポート バンドルを生成するには、次の手順を実行します。
vSphere Web クライアントから、Cisco HX Data Platform ストレージ クラスタ ESX サーバ、コントローラ VM、および vCenter Server のすべてのログまたは一部のログを選択して収集できます。
vCenter Cisco HX Data Platform プラグインを使用して、ストレージ クラスタ ESX サーバとコントローラ VM のログだけを収集できます。
(注) | ローカル コントローラ VM の時刻で午前 0 時(12:00 a.m)まで、生成したサポート バンドルをダウンロードできます。午前 0 時以降は、テクニカル アシスタンス センター(TAC)バンドルはシステムにより削除されます。 |
サポート バンドルを生成したら、次のいずれかの方法で HX Data Platform FTP サーバにアップロードできます。
サポート バンドルを作成します。
ステップ 1 | FTP クライアント(Filezilla など)を開き、次の情報を使用して HX Data Platform FTP サーバに接続します。
|
ステップ 2 | HX Data Platform FTP サーバに接続したら、サポート ケース番号を使用してフォルダを作成します。 |
ステップ 3 | ディレクトリを新しいフォルダに変更します。 |
ステップ 4 | このフォルダにログ ファイルをアップロードします。 |
ステップ 5 | アップロードが完了したら、テクニカル アシスタンス センター(TAC)に連絡して、そのアップロードのディレクトリ名を通知します。 |
ステップ 6 | ストレージ クラスタのスペースを解放するため、/var/support/ の内容を削除します。 |
サポート バンドルを作成します。
ステップ 1 | FTP クライアント(Filezilla など)を開き、次の情報を使用して HX Data Platform FTP サーバに接続します。
|
ステップ 2 | HX Data Platform FTP サーバに接続したら、サポート ケース番号を使用してフォルダを作成します。 |
ステップ 3 | ディレクトリを新しいフォルダに変更します。 |
ステップ 4 | このフォルダにログ ファイルをアップロードします。 |
ステップ 5 | アップロードが完了したら、テクニカル アシスタンス センター(TAC)に連絡して、そのアップロードのディレクトリ名を通知します。 |
ステップ 6 | ストレージ クラスタのスペースを解放するため、/var/support/ の内容を削除します。 |
サポート バンドルを作成します。
ステップ 1 | ブラウザ ウィンドウを開き、HX Data Platform FTP サーバの URL を開きます。これは Springpath によりホストされます。
ホスト:https://ftp.springpathinc.com |
ステップ 2 | 次のクレデンシャルを使用して FTP サーバにログインします。
ユーザ名:upload、パスワード:upload |
ステップ 3 | HX Data Platform FTP サーバに接続したら、サポート ケース番号を使用してフォルダを作成します。 |
ステップ 4 | ディレクトリを新しいフォルダに変更します。 |
ステップ 5 | このフォルダにログ ファイルをアップロードします。 |
ステップ 6 | アップロードが完了したら、テクニカル アシスタンス センター(TAC)に連絡して、そのアップロードのディレクトリ名を通知します。 |
ステップ 7 | ストレージ クラスタのスペースを解放するため、/var/support/ の内容を削除します。 |
ホストの問題
説明
5 つ以上のノード クラスタで 2 つのノードがダウンしている場合、たとえば 1 つのホストがメンテナンス モードで、別のホストのストレージ コントローラ VM がシャットダウンしている場合に、ストレージ クラスタがシャットダウンする可能性があります。これは、オール パス ダウン(APD)状態の要因となる可能性があります。
回避策
説明
ストレージ コントローラ VM またはホストがダウンしている場合、ダウンしたノード以外のストレージ クラスタ内の別のノードの削除に失敗します。
アクション:はじめに交換ノードを追加する
説明
システムがアクセスできないストレージ クラスタのホストの HA を有効にした場合、ESX ホストを再起動すると、ストレージ コントローラ VM の電源がオフになります。
バックグラウンド
これは、VMware の HA 障害の処理方法と ESX Agent Manager(EAM)設定間の相互作用によるものです。これにより、ストレージ コントローラ VM が、復元後に電源オンにならない現象が生じる可能性があります。
アクション:HA が有効になっている ESX ホスト上でストレージ コントローラ VM の電源をオンにする
説明
既存のストレージ クラスタにノードを追加する場合、ストレージ クラスタは、再調整が完了するまで元のストレージ クラスタと同じ HA 復元力を持ち続けます。
たとえば、3 ノードのストレージ クラスタがあり、2 つのコンバージド ノードをストレージ クラスタに追加する場合などです。再調整が完了するまで、ストレージ クラスタは、5 ノードのストレージ クラスタではなく、3 ノードのストレージ クラスタとして動作します。したがって、バランスの再調整が完了する前にノードで障害が発生すると、ストレージ クラスタのステータスは低下します。
通常、再調整は 24 時間ごとの再調整スケジュール、ノード障害の 2 時間後、またはストレージ クラスタがスペース不足の場合に発生します。
アクション:ストレージ クラスタの再調整を手動で開始する
説明
ストレージ クラスタ内のホストを電源オフにすると、ストレージ コントローラ VM も電源オフになります。ホストの電源を再度オンにした場合、ストレージ コントローラ VM の電源が自動的にオンにならない場合があります。
アクション:ホストのコマンド ラインから手動でストレージ コントローラ VM の電源をオンにする
ディスクの問題
説明
ノード上のすべてのハード ディスクに障害が発生すると、HX Data Platform はノードにデータを割り当てることができません。3 ノードのストレージ クラスタでこの問題が発生した場合、HX Data Platform は、データの整合性を維持する上で最低限必要な 3 つのデータのコピーを維持することができません。その結果、仮想的な ENOSPC 状態となります。
ノード上で複数のハード ディスクに障害が発生し続けた場合、ストレージ クラスタはノードへの書き込みを行おうとし、ディスク上の残りの領域を使用することから、不安定な状態となります。たとえば、3 つのノードすべてに 10 台の HDD があり、3 番目のノード上で 9 台の HDD に障害が発生した場合、不安定な状況が生じた結果、3 番目のノード上のディスクでは、クラスタのサイズが実際のサイズの 10 % に制限されます。これは、物理的な ENOSPC 状態です。また、オール パス ダウン(APD)状態を引き起こす可能性もあります。
アクション:ストレージ クラスタ内のすべてのノード上で、ストレージを物理的に調整します。
説明
ディスクを削除して、自動再スキャンが完了する前にストレージ コントローラ VM を再起動した場合、ストレージ コントローラ VM の電源がオンにならない場合があります。
アクション:ディスクの削除後にストレージ コントローラ VM の電源をオンにする
説明
ストレージ コントローラ 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 の問題
説明
ディスク共有の制限が設定された VM の電源がオンになると、各データストアのパフォーマンスが低下する。
アクション:VMware 単位で想定されている動作です。
説明
ストレージ クラスタが読み取り専用状態になっていると、それらがすでに読み取り専用のストレージ クラスタにある場合であっても、VMware DRS プロセスは VM をデータストアに移行します。その結果 VM は起動不可になります。
アクション:ストレージ クラスタが読み取り専用状態の場合には、DRS を手動で無効にします。
説明
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 向けに作成された ESX *.lck ファイルや、vSphere にアクセスできなくなった場合、VM ファイルやフォルダの削除には非常に長い時間がかかる場合があります。
アクション:ESX サーバの VM ロック ファイルをクリアする
ステップ 1 | ストレージ クラスタ内のすべての VM ロック ファイルを探します。
# cd /vmfs/volumes/my_datastore # find .-name .lck* | xargs -n1 rm |
ステップ 2 | VM のファイルまたはフォルダの削除を再試行します。 |
キャパシティの問題
説明
HX Data Platform プラグイン内で、[Summary] タブのクラスタ キャパシティと [Manage] タブのプロビジョニングされたキャパシティに、ストレージ クラスタに割り当てられたストレージ量と異なる数値の表示されることがあります。これは、次のような状況で発生します。
クリーナーが未完了。VM は削除されたが、クリーナーが実行されていない。クリーナーは自動プロセスであり、完了後にクラスタ キャパシティとプロビジョニングされた量が一致する必要があります。クリーナー コマンドに関する情報については、『Cisco HX Data Platform Command Line Interface Reference guide』を参照してください。
シック プロビジョニングまたはシック クローン。シック ディスクまたはクローンが作成された場合、HX Data Platform は領域を確保しません。ソフト予約が使用され、データストアに使用された領域が表示されますが、領域はストレージ クラスタ内で使用されていません。これは、データストアをオーバー プロビジョニングすることがないように、管理者を支援する目的で設計されたものです。
アクション:ありません。
説明
情報が競合していると考えられる、3 つのシナリオを表示します。
バックグラウンド
ストレージ クラスタとデータストアのキャパシティは個別に定義されます。したがって、各エンティティに関連づけられたメッセージは異なることが見込まれます。
アクション:データストアが満杯です
データストアが満杯の場合、vCenter は新しい VM のプロビジョニング、VM のクローン、VM の電源オンを拒否することができます。これを修正するには、次のオプションを選択します。
アクション:ストレージ クラスタに領域がありません
データストアの可用性は、現在のアクティビティによって追跡されます。クラスタの可用性には、現在のアクティビティと保留中のクリーンアップが含まれます。この状況は、通常クリーンアップ プロセス自身によって自動的に修正されます。ストレージ クラスタの領域が不足していて、保留中のクリーンアップがない場合は、ストレージの追加か VM の削除による使用量の削減のいずれかを行う必要があります。
アクション:異なる使用量のアラート
対処不要です。これは想定されている動作です。使用率に基づいて、メッセージは頻繁にトリガーされます。
次に例を示します。データストアに 100 TB のストレージが割り当てられている場合、ストレージ クラスタのストレージは 10 TB で、イベント メッセージは 80 % の使用量として設定されます。クラスタ メッセージは、8 TB のストレージが使用された場合に発信されます。データストア メッセージは、80 TB のストレージが使用された場合にのみ発信されます。
データストアの問題
説明
これは SIOC に関連している Vmware の問題です。以下のようなメッセージが vmkernel.log に記録されます。
2016-02-19T02:03:04.336Z cpu14:34605 opID=c93c14c5)WARNING: NFSLock: 2210: File is being locked by a consumer on host c220one.ppt.lab.cisco.com with exclusive lock."
アクション:データストアの「ストレージ I/O コントロール」を有効化してから無効化、または無効化してから有効化します。
http://vthink.fr/en/2015/08/vsphere-file-is-being-locked-by-a-consumer-on-host/ で『vSphere : File is being locked by a consumer on host』を参照してください。
説明
ストレージ クラスタの作成後に VLAN ID を変更すると、データストアのストレージ クラスタへのマウントに失敗します。既存のデータストアを、ストレージ クラスタからマウント解除することはできます。
アクション:ESX サーバのファイアウォールをリロードします。
ESX サーバのファイアウォールのリロードに関する指示については、VMware ESX のマニュアルを参照してください。
説明
VMware の構成要件ごとに IP アドレスもしくはルールが重複する場合、接続が失われます。
アクション:トラフィックが意図した VM カーネル インターフェイスを使用しているか確認します。
次を設定します。
説明
vSphere Web クライアントを介してデータストア名を変更すると、ホスト関連の共有名が変更されますが、HX Data Platform プラグイン内の表示名は変更されません。
バックグラウンド
これは想定されている動作です。vSphere 名は、データストアのマウント ポイントのみを対象としたラベルです。これは、ストレージ クラスタのデータストアの機能には影響しません。HX Data Platform プラグインを介して表示されている名前は、マウント ポイント名ではなく、データストア名です。
アクション:HX Data Platform プラグイン内のデータストア名を変更する
データストア名を変更する場合は、データストアのマウント ポイント名と同期させます。
説明
ストレージ クラスタが正常な状態に戻った後、既存のデータストアが自動的に再マウントされない場合があります。これは、1 つ以上のノードがダウンしている間にストレージ クラスタが再起動されたか、ストレージ クラスタの再起動に長い時間がかかっている場合に発生する場合があります。
アクション:データストアをマウントする。
説明
VMware の Storage I/O RM 機能が有効になっている場合、データストアで Storage I/O RM が有効になっていない場合でも、VMware が Storage I/O RM の追跡ファイルに書き込みを行うバグがあります。これらの追跡ファイルが、HX Data Platform のデータストアのマウント解除を妨げます。
アクション:マウント解除を再試行する。
説明
VMware は、データストアをランダムに選択する動作をするよう設計されています。これは、HX Data Platform プラグインのデータストア削除機能に影響します。
アクション:削除を再試行する。
ステップ 1 | データストアの削除を再試行します。 |
ステップ 2 | VM がデータストアで実行されていないことを確認します。 |
ステップ 3 | 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 |
ステップ 4 | storageRM のステータスを確認します。
# /etc/init.d/storageRM status storageRM is running |
ステップ 5 | storageRM サービスを停止します。
# /etc/init.d/storageRM stop watchdog-storageRM: Terminating watchdog process with PID 34096 storageRM stopped |
ステップ 6 | データストアの削除を再試行してください。 |
ステップ 7 | 可能なソリューションはこれ 1 つです。これで問題が解決しない場合は、テクニカル アシスタンス センター(TAC)にお問い合わせください。 |
ReadyClone とスナップショットの問題
説明
デスクトップ プールで VM のスナップショットを削除した後、デスクトップ プールを削除すると、スナップショットの VM フォルダとダイジェスト ファイルが残っていることが確認された。
アクション:ファイルとフォルダを手動で削除します。
VMware のナレッジ ベース『Pool deletion operation does not remove digest vmdk files(2109563)』に記載の手順に従います。http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2109563
vCenter クラスタ内のノードの電源がオフになっていました。ストレージ クラスタは、ダウン ノード数の許容範囲内であり、正常です。ただし、ストレージ クラスタが vSphere を介して管理できません。
VMware vSphere 6.0 の既知のバグです。次を参照してください。https://communities.vmware.com/thread/514117?start=0&tstart=0
アクション:ノードをリセットする。
ノードの電源をオンにするか、電源がオフのノードを vCenter クラスタから切断します。