ノードの管理

ノードの管理

ノードは最初、HX Data Platform インストーラのクラスタの作成機能を使用してストレージ クラスタに追加されます。ノードを既存のストレージ クラスタに追加する場合は、HX Data Platform インストーラのクラスタの展開機能を使用します。ストレージ クラスタに対してノードを追加または削除すると、HX Data Platform がそれに応じてストレージ クラスタのステータスを調整します。

  • 障害が発生したノードのメンテナンスに関するタスク。

    • ESXi または HX ソフトウェアを再インストールする必要がある。

    • ノード コンポーネントを交換する必要がある。

    • ノードを交換する必要がある。

    • ノードを取り外す必要がある。

  • 障害が発生していないノードのメンテナンスに関するタスク。

    • ノードをメンテナンス モードにする。

    • ESX パスワードを変更する。


（注）  

若干の違いはありますが、サーバ、ホスト、およびノードという用語が HyperFlex のマニュアルを通して区別されずに使われています。一般に、サーバは、特定の目的専用のソフトウェアを実行する物理ユニットです。ノードは、ソフトウェア クラスタやサーバのラックなどのより大きなグループ内のサーバです。シスコのハードウェア マニュアルでは、ノードという用語が使われる傾向があります。ホストは、仮想化または HyperFlex ストレージ ソフトウェアを実行しているサーバで、仮想マシンにとっての「ホスト」です。VMware のマニュアルでは、ホストという用語が使われる傾向があります。

手順

ステップ 1

クラスタ内のノードをモニタします。

HX ストレージ クラスタ、ノード、およびノード コンポーネントのステータスがモニタされ、HX Connect、HX Date Platform Plug-in、vCenter UI、およびさまざまなログに、動作ステータス（オンライン、オフライン）値と復元力ステータス値（正常、警告）として報告されます。

（注）  

 

機能状態の区別は、HX Connect と HX Data Platform Plug-in のビューに表示されるストレージ クラスタの動作ステータスと復元力ステータスに影響しますが、それらのステータスとは別個のものです。データ レプリケーション係数（2 または 3）、クラスタ アクセス ポリシー（寛容（lenient）または厳格（ strict））、およびストレージ クラスタ内の特定の数のノードごとに、障害が発生したノードの数またはノード内の障害が発生したディスクの数に応じて、ストレージ クラスタの状態が読み取りと書き込み、読み取り専用、またはシャットダウンの間で変化します。

（注）  

 

Hyperflex Edge を除くすべての環境で複製ファクタ 3 を強く推奨しています。複製ファクタ 2 では、可用性と復元性のレベルが低くなり、実稼働環境で使用してはなりません。コンポーネントまたはノードの障害による停電のリスクは、アクティブかつ定期的なバックアップを作成することにより軽減されます。

ステップ 2

ノード障害を分析して、実行するアクションを決定します。

これには、HX Connect、HX Data Platform Plug-in, 、vCenter、または ESXi を介したノード状態のモニタリングと、サーバー ビーコンのチェック、ログの収集と分析が必要になります。

ステップ 3

特定されたタスクを実行します。

  • ソフトウェアを再インストールまたはアップグレードします。

    ESXi または HX Data Platform を再インストールする手順については、『VMware ESXi 用 Cisco HyperFlex システム インストール ガイド』を参照してください。ソフトウェアのアップグレード手順については、『Cisco HyperFlex Systems Upgrade Guide』を参照してください。

  • ノード内のコンポーネントを修理します。

    ノード コンポーネント（ソリッド ステート ドライブ（SSD）、ハード ディスク ドライブ（HDD）、電源装置（PSU）、ネットワーク インターフェイス カード（NIC）コンポーネントなど）は、HX Connect または HX Data Platform Plug-in では設定できませんが、HX Data Platform はこれらのコンポーネントをモニタして、いずれかのアイテムの中断、追加、取り外し、または交換が発生すると、ストレージ クラスタ ステータスを調整します。

    ディスクを追加または取り外す手順は、ディスクのタイプによって異なります。PSU や NIC などの現場交換可能ユニット（FRU）を交換するには、サーバ ハードウェア ガイドで説明される手順に従います。

  • クラスタ内のノードを交換するには、 ノード コンポーネントの交換を参照してください。

    通常、ストレージ クラスタ内のノードを交換する際は、TAC によるサポートが必要です。要件が満たされていれば、ストレージ クラスタがオンライン（5 ノード以上のクラスタのみ）中またはオフライン（4 ノード以上のクラスタ）中に、ノードを TAC の支援なしで交換できます。

  • クラスタ内のノードを削除するには、 オンライン ストレージ クラスタからのノードの削除 または オフライン ストレージ クラスタからのノードの削除 を参照してください。

    （注）  

     

    ノードを削除する際は、使用可能なノードの数が最小数の 3 を下回らないようにしてください。3 を下回るとストレージ クラスタが正常に動作しなくなります。3 ノード クラスタ内のノードを削除する際は、常に TAC の支援が必要です。

    オフライン クラスタから最大 2 つのノードを削除できます。

ノードのメンテナンス方法の特定

ノード メンテナンス タスクには、ストレージ クラスタがオフラインのときに実行されるもの、クラスタがオンラインであり、ノードが HXDP メンテナンス モードであることだけが必要である場合に実行できるものがあります。

  • オンライン タスク：タスク開始前にストレージ クラスタが正常な状態である必要があります。

  • オフライン タスク：ストレージ クラスタをシャット ダウンする必要があります。

    2 つ以上のノードがダウンしている場合、ストレージ クラスタは自動的にオフラインになります。

  • TAC 支援によるタスク：通常は、TAC 担当員によって実施される手順が必要になります。

次の表に、関連するノード メンテナンス タスクを実行するときに使用できる方法を示します。

ノード ソフトウェアの修復

ESX と HX Data Platform ソフトウェアは、ストレージ クラスタ内の各ノードにインストールされます。ノード障害分析後にいずれかのソフトウェア項目を再インストールする必要があることが判明した場合は、『VMware ESXi 用 Cisco HyperFlex システム インストール ガイド』を参照してください。ソフトウェアのアップグレード手順については、『Cisco HyperFlex Systems Upgrade Guide』を参照してください。

ノード ハードウェアの修復

ノード上の修理可能なアイテムで障害が発生した場合です。これには FRU やディスクが該当します。一部のノード コンポーネントには TAC の支援が必要です。たとえば、ノードのマザーボードの交換には TAC の支援が必要です。

クラスタ内のノードの数

クラスタ内の障害発生ノードの数

方法

注記

3

1 つ以上

TAC の支援によるノード修復のみ。

修復作業のためにノードを取り外す必要はありません。ノード上のディスクの交換が含まれます。

4-8

1

オンラインまたはオフラインでのノードの修復。

修復作業のためにノードを取り外す必要はありません。ノード上のディスクの交換が含まれます。

ノードの削除

ノード上の修理不可能なアイテムで障害が発生した場合です。取り外したノードのディスクは、ストレージ クラスタで再利用されません。

クラスタ内のノードの数

クラスタ内の障害発生ノードの数

方法

注記

4

1

オフラインでのノードの取り外し。

4 ノード クラスタで 2 つのノードがダウンしている場合は、TAC の支援が必要です。

5 つ以上

1

オンラインまたはオフラインでのノードの取り外し。

5 つ以上

2

オフラインでの 2 ノードの取り外し。

5 ノード クラスタで 3 つのノードがダウンしている場合は、TAC の支援が必要です。

ノードの交換とストレージの廃棄

ノード上の修理不可能なアイテムで障害が発生した場合です。取り外したノードのディスクは、ストレージ クラスタで再利用されません。

クラスタ内のノードの数

クラスタ内の障害発生ノードの数

方法

注記

3

1

TAC の支援によるノード交換のみ。

クラスタを最小限の 3 ノードに戻すには、TAC の支援によってノードを交換する必要があります。

3 ノード クラスタで 1 つのノードがダウンしている場合は、TAC の支援が必要です。

4

1

オフラインでのノードの交換。

ディスクは再利用されません。

新しいノードを追加するにはクラスタ拡張を使用します。他のすべてのノードが稼働している必要があります。

4 ノード クラスタで 2 つのノードがダウンしている場合は、TAC の支援が必要です。

5 つ以上

1

オンラインまたはオフラインでのノードの交換。

ディスクは再利用されません。

新しいノードを追加するにはクラスタ拡張を使用します。他のすべてのノードが稼働している必要があります。

5 つ以上

2

オフラインでの 1 または 2 ノードの交換。

ディスクは再利用されません。

新しいノードを追加するにはクラスタ拡張を使用します。他のすべてのノードが稼働している必要があります。

最大 2 つのノードの交換がサポートされています。3 つ以上のノードを交換するには、TAC の支援が必要です。

ノードの交換とストレージの再利用

ノード上の修理不可能なアイテムで障害が発生した場合です。取り外したノードのディスクをストレージ クラスタで再利用します。

クラスタ内のノードの数

クラスタ内の障害発生ノードの数

方法

注記

3以上

1 つ以上

TAC の支援のみ。

クラスタを最小限の 3 ノードに戻すには、TAC の支援によってノードを交換する必要があります。

（注）  

 

ディスクを再利用するには、古いノードの UUID を新しいノードに割り当てる必要があります。ディスク UUID とノード UUID の関係は固定されているため、再割り当てできません。これは、TAC 支援によるタスクです。

DNS アドレスまたはホスト名による検索

トラブルシューティングの目的では、DNS サーバ アドレスまたは DNS サーバ ホスト名で検索できることが便利な場合があります。これはオプションのタスクです。

手順

ステップ 1

DNS 検索アドレスを割り当てます。

  1. HX Data Platform インストーラ仮想マシンにログインします。ssh または vSphere コンソール インターフェイスを使用します。

  2. resolv.conf.d ファイルを編集します。 

    # vi /etc/resolvconf/resolv.conf.d/base

  3. 変更を確認します。

    # resolvconf -u
# cat /etc/resolv.conf

  4. DNS サーバが IP アドレスまたはホスト名から照会できることを確認します。

    # nslookup ip_address
# nslookup newhostname

ステップ 2

DNS ホスト名を割り当てます。

  1. HX Data Platform インストーラ仮想マシンにログインします。ssh または vSphere コンソール インターフェイスを使用します。

  2. 編集のために hosts ファイルを開きます。

    # vi /etc/hosts

  3. 次の行を追加し、ファイルを保存します。

ip_address ubuntu newhostname

各ホストの ip_address に対して、ホストの newhostname を入力します。

  1. newhostname を hostname に追加します。 

    # hostname newhostname

ESXi ホストのルート パスワードの変更

次のシナリオで、デフォルトの ESXi パスワードを変更できます。

  • 標準およびストレッチ クラスタの作成時（コンバージド ノードのみをサポート）

  • 標準クラスタの拡張時 （コンバージド ノードまたはコンピューティング ノードの両方の拡張をサポート）

  • エッジ クラスタの作成時


（注）  

上記の場合、インストールが完了するとすぐに ESXi のルート パスワードが保護されます。後続のパスワード変更が必要である場合、下に概要を示している手順をインストール後に使用して、ルート パスワードを手動で変更することができます。

ESXi は工場出荷時のデフォルト パスワードで提供されているため、セキュリティ上の理由からパスワードを変更する必要があります。インストール後のデフォルトの ESXi ルート パスワードを変更するには、次の手順を実行します。


（注）  

ESXi ルート パスワードを忘れた場合は、パスワードの復旧について Cisco TAC にお問い合わせください。

手順

ステップ 1

SSH を使用して ESXi ホスト サービス制御にログインします。

ステップ 2

ルート権限を取得します。

su -

ステップ 3

現在のルート パスワードを入力します。

ステップ 4

ルート パスワードを変更します。

passwd root

ステップ 5

新しいパスワードを入力し、Enter キーを押します。確認のためにパスワードを再入力します。

（注）  

 

2 回目に入力したパスワードが一致しない場合は、最初からやり直す必要があります。

ノード ソフトウェアの再インストール

既存のストレージ クラスタのメンバーであるノードでソフトウェアを再インストールするには、TAC にお問い合わせください。このタスクは TAC アシスタンスと共に実行する必要があります。

手順

ステップ 1

TAC からの指示に従って ESX を再インストールします。

サーバがホスト ESX サーバ設定要件に記載されている必要なハードウェアおよび設定を満たしていることを確認します。HX 構成の設定は HX Data Platform プロセス中に適用されます。

ステップ 2

TAC からの指示に従って HX Data Platform を再インストールします。

HX Data Platform の再インストールは常に ESX を再インストールした後で行う必要があります。

IP から FQDN への vCenter クラスタ内のノード識別フォームの変更

このタスクでは、vCenter によるクラスタ内のノードの識別方法を IP アドレスから完全修飾ドメイン名（FQDN）に変更する方法について説明します。

手順

ステップ 1

このタスクを実行するためのメンテナンス ウィンドウをスケジュールします。

ステップ 2

ストレージ クラスタが正常であることを確認します。

ストレージ クラスタのステータスを HX Connect、HX Data Platform プラグイン、またはストレージ コントローラ VM の stcli cluster info コマンドのいずれかにより確認します。

ステップ 3

ストレージ クラスタ内の各 ESXi ホストの FQDN を探します。

  1. ESXi ホスト コマンド ラインから。 

    # cat /etc/hosts

    この例では、FQDN は sjs-hx-3-esxi-01.sjs.local です。 

    # Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1         localhost.localdomain localhost
::1               localhost.localdomain localhost
172.16.67.157     sjs-hx-3-esxi-01.sjs.local  sjs-hx-3-esxi-01

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

ステップ 4

各 ESXi ホストの FQDN を vCenter、他の ESXi ホストから互いに、およびコントローラ VM から解決できることを確認します。

  1. vCenter のコマンド ラインから。

    # nslookup <fqdn_esx_host1>
# nslookup <fqdn_esx_host2>
# nslookup <fqdn_esx_host3>
...

  2. ESXi ホストから各 ESXi ホストに対して繰り返します。

  3. 各コントローラ VM から各 ESXi ホストに対して繰り返します。

ステップ 5

FQDN 名が解決できない場合は、各 ESXi ホストと各コントローラ VM 上の DNS 設定を確認します。

  1. コントローラ VM が DNS サーバの正しい IP アドレスを認識していることを確認します。

    コントローラ VM のコマンド ラインから。

    # stcli services dns show
10.192.0.31

  1. ESXi ホストの DNS 設定がコントローラ VM と同じであることを確認します。

    vCenter から、各 ESXi ホストを選択してから、[構成（Configuration）] > [DNS サーバ（DNS Servers）] を選択します。

ステップ 6

データセンター名とクラスタ名を探してメモします。

vCenter クライアントまたは Web クライアントから、データセンター名とクラスタ名が表示されるまでスクロールします。それらを書き留めておきます。これらは後の手順で使用します。

ステップ 7

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

vCenter から、データセンター > クラスタを選択します。クラスタを右クリックし、[削除（Delete）] を選択します。

（注）  

 

データセンターは削除しないでください。

ステップ 8

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

  1. vCenter から、データ センターを右クリックします。[新規クラスタ（New Cluster）] を選択します。

  2. 削除したクラスタとまったく同じ名前を [クラスタ名（Cluster Name）] に入力します。これは、ステップ 6 で書き留めた名前です。

ステップ 9

FQDN 名を使用して、クラスタに ESXi ホスト（ノード）を追加します。すべての ESXi ホストに対してこの手順を繰り返します。

  1. vCenter から、データ センター > クラスタを右クリックします。[ホストの追加（Add Host）] を選択します。

  2. FQDN を使用して ESXi ホストを選択します。

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

ステップ 10

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

#  #  stcli cluster reregister  
--vcenter-datacenter <datacenter_name> 
--vcenter-cluster <hx_cluster_name> 
--vcenter-url <FQDN_name> 
--vcenter-user <vCenter_username> 
--vcenter-password <vCenter_Password>

HX バージョン 1.8.1c 以降では、SSO URL が必要ありません。クラスタの再登録の詳細については、新しい vCenter クラスタによるストレージ クラスタの登録を参照してください。

ステップ 11

インストール後のスクリプトを使用して、VMware クラスタ HA および DRS を有効にします。

  1. admin として HX クラスタ IP にログインし、＃hx_post_install コマンドを実行します。

  2. [Option 1-"New / Existing Cluster" ]を選択し、すべてのログイン クレデンシャルを入力します。

  3. 新しいライセンス キーを入力する場合は「y」と入力します。

  4. クラスタで HA と DRS を有効にするには、「y」と入力します。

  5. 他のすべてのオプションで「n」を選択し、スクリプトを終了します。

ノード コンポーネントの交換

ノード上の選択したコンポーネントを交換できます。コンポーネントの中には、ノードが稼働中でも交換できるものがあります。一部のコンポーネントを交換するには、ノードをメンテナンス モードにするか、シャットダウンする必要があります。すべての現場交換可能ユニット（FRU）のリストについては、ご使用のサーバのハードウェア インストール ガイドを参照してください。コンポーネントによっては、交換できないものや、TAC の支援がある場合にのみ交換できるものもあります。次に示すのは、ノードで交換可能なコンポーネントの一般的なリストです。


（注）  

ディスクを取り外した場合、ディスクが物理的には存在しない状態でも、ディスク UUID が引き続きリストされます。同一クラスタ内の別のノードでディスクを再利用するには、TAC にサポートを依頼してください。

  • ノードをシャット ダウンする必要がないコンポーネント。これらはホットスワップ可能です。

    • HDD データ ドライブ。前面ベイ

      ストレージ クラスタのタスクについては TAC にお問い合わせください。ハードウェアを中心とするタスクについては『ディスクの管理』を参照してください。このコンポーネントを交換するには、両方のタスクが必要です。

    • SSD キャッシュ ドライブ。前面ベイ 1

      ストレージ クラスタのタスクについては TAC にお問い合わせください。ハードウェアを中心とするタスクについては『ディスクの管理』を参照してください。このコンポーネントを交換するには、両方のタスクが必要です。

    • ファン モジュール

      このコンポーネントを交換するには、ハードウェア インストール ガイドを参照してください。

    • 電源

      このコンポーネントを交換するには、ハードウェア インストール ガイドを参照してください。

  • ノードをメンテナンス モードにしてシャットダウンする必要があるコンポーネント。

    次に示すすべてのコンポーネントについては、ハードウェア インストール ガイドを参照してください。

    • ハウスキーピング SSD

      このコンポーネントを交換するには、ストレージ クラスタ タスクとハードウェア中心のタスクの両方が必要です。

    • マザーボード上の RTC バッテリ


      （注）  

      マザーボード自体は交換可能コンポーネントではありません。ローカル ハードウェア ストアからバッテリを購入し、交換する必要があります。

    • DIMMS

    • CPU とヒートシンク

    • 内部 SD カード

    • 内部 USB ポート

    • モジュラ HBA ライザー（HX 220c サーバ）

    • モジュラ HBA カード

    • PCIe ライザー アセンブリ

    • PCIe カード

    • トラステッド プラットフォーム モジュール

    • mLOM カード

    • RAID コントローラ

    • 仮想インターフェイス カード（VIC）

    • グラフィック処理ユニット（GPU）

ノードの削除

ノードの削除は、次のクラスタタイプでサポートされています。

表 1. ノードの削除をサポートするクラスタタイプ

クラスタ タイプ

コンバージド

コンピューティング

Standard

はい

はい

ストレッチ

非対応

はい

Edge

はい（注を参照）

（注）  

 
ノード（コンピューティングまたはコンバージド）の削除は、3 ノードよりも大きなクラスタでのみサポートされます。4 ノードのエッジ クラスタの場合は、オフライン ノード削除プロセスに従います。5 つ以上のノードを持つエッジ クラスタの場合、オンラインおよびオフラインのノード削除プロセスがサポートされています。ただし、オンライン ノード削除方法をお勧めします。

クラスタ内のノードの数に応じて、クラスタがオンラインの場合、またはクラスタをオフラインにする必要がある場合に、ノードを削除できます。その前に、必要な準備手順が完了していることを確認する必要があります。

影響するコンテキストは、コンバージド ノードの数に基づきます。コンピューティング ノードの数は、ノード削除のプロセスに影響しません。

一度に 1 つのコンバージド ノードのみを削除できます。

4 つのコンバージド ノードがあるクラスタの場合は、オフライン ノード削除プロセスに従います。5 つ以上のコンバージド ノードを持つクラスタの場合は、オンライン ノード削除プロセスに従います。


（注）  
3 ノード クラスタからのコンバージド ノードの削除はサポートされていません

（注）  
クラスタがオフラインのときにノードを削除すると、そのノードをクラスタに戻すことはできません。

論理アベイラビリティゾーン（LAZ）が設定された HyperFlex クラスタのノードを削除する前に、LAZ を無効にする必要があります。

LAZ が HyperFlex クラスタで使用される場合、LAZ を再有効化する前に、残りのノードの数が、LAZ のガイドラインと考慮事項に従って LAZ をサポートするバランスの取れた構成である必要があります。

ノードの削除の準備

ストレージ クラスタからノードを削除する前に、次の手順を実行します。

手順

ステップ 1

クラスタが正常であることを確認します。

# stcli cluster info

次の例の応答は、ストレージ クラスタがオンラインで正常であることを示します。 

locale: English (United States)
state: online
upgradeState: ok
healthState: healthy
state: online
state: online

ステップ 2

SSH がストレージ クラスタ内のすべてのノード上の ESX で有効になっていることを確認してください。

ステップ 3

分散リソース スケジューラ（DRS）が有効になっていることを確認してください。

DRS は、電源がオンの VM だけを移行します。ネットワークで VM の電源がオフになっている場合は、削除されないストレージ クラスタ内のノードにこれらの VM を手動で移行する必要があります。

（注）  

 

DRS を使用できない場合は、仮想マシンをそのノードから手動で移動します。

ステップ 4

zkEnsemble をメモします。これには、コントローラ VM（CVM）のデータ IP が含まれます。

削除されたノードが ucs-308 で、その CVM データ IP が 10.104.18.40 の場合、ノードの削除後に上記のコマンドを実行すると、その CVM データ IP は表示されなくなります。

ステップ 5

削除するノードをメンテナンス モードにします。次の方法を選択します。vSphereGUI、コントローラVMコマンドライン（CLI）、または HyperFlex Connect システム情報パネル:

GUI

  1. 各ホストを右クリックし、リストを下にスクロールし、[ メンテナンス モード（Cisco Maintenance Mode）] > [メンテナンス モードの開始（Enter Maintenance Mode）] の順に選択します。

    [vSphere メンテナンス モード（vSphere Maintenance Mode）] オプションは、ホストの右クリック メニューの上部にあります。リストの下部までスクロールし、[Maintenance Mode] を選択します。

  2. HX Connectで、[管理（MANAGE）] > [システム情報（System Information）] パネルの [ノード（Node）] タブからノードを選択し、[HXDP メンテナンス モード（HXDP Maintenance Mode）] ボタンをクリックします。

CLI

  1. 管理ユーザーとしてコントローラ VM にログインします。

  2. stcli cluster info 実行し、stNodes: セクション を探します。

    # stcli cluster info 

    stNodes:
    ----------------------------------------
    type: node
    id: 689324b2-b30c-c440-a08e-5b37c7e0eefe
    name: ucs-305
    ----------------------------------------
    type: node
    id: 9314ac70-77aa-4345-8f35-7854f71a0d0c
    name: ucs-306
    ----------------------------------------
    type: node
    id: 9e6ba2e3-4bb6-214c-8723-019fa483a308
    name: ucs-307
    ----------------------------------------
    type: node
    id: 575ace48-1513-0b4f-bfe1-e6abd5ff6895
    name: ucs-308
    ---------------------------------------
    type: node
    id: 875ebe8-1617-0d4c-afe1-c6aed4ff6732 
    name: ucs-309

    stNodes セクションで、id がクラスタ内の各ノードがリストされます。削除する必要があるノード ID または名前を見つけます。

  3. ESX ホストをメンテナンス モードに移行します。

    # stcli node maintenanceMode (--id ID | --ip NAME) --mode enter

    （stcli node maintenanceMode --help も参照してください）

    たとえば、ノード ucs-308 を削除するには、次の手順を実行します。
    Example:
stcli node maintenanceMode –id 575ace48-1513-0b4f-bfe1-e6abd5ff6895
or
stcli node maintenanceMode –ip 10.104.18.40

ステップ 6

2時間待機し、stcli cluster storage-summaryで修復情報をモニタします。「ストレージ クラスタが正常です」と表示されるまで待機する必要があります。次の例に示すように、

Example:
admin:$ stcli cluster storage-summary | grep -i heali -A 8
healingInfo:
    inProgress: False
resiliencyInfo:
    messages:
        ----------------------------------------
        Storage node 10.104.18.40 is unavailable.
        ----------------------------------------
        Storage cluster is healthy.
        ----------------------------------------

Before the healing starts you will see following:

admin:$ date; stcli cluster storage-summary | grep -i heali -A 8
Thu Sep 30 12:33:57 PDT 2021 
healingInfo:
inProgress: False
resiliencyInfo:
messages:
----------------------------------------
Storage cluster is unhealthy   .
----------------------------------------
Storage node 10.104.18.40 is unavailable   .
----------------------------------------

After 2 hours + you will see following:

admin:$ stcli cluster storage-summary | grep -i heali -A 8
healingInfo:
messages:
Space rebalanc   ing in progress, 83 % completed.
inProgress: True
percentComplete: 83 
estimatedCompletionTimeInSeconds: 211 
resiliencyInfo:
messages:

次のタスク

ノードの削除に進みます。ストレージクラスタ内のノードの数に基づいて、オンラインまたはオフラインの方法を選択します。

オンライン ストレージ クラスタからのノードの削除

導入環境をクリーンアップするか、またはストレージ クラスタからノードを削除するには、stcli node remove を使用します。


（注）  

連続して複数のノードを削除できます。ただし、一度に 1 つのノードを削除する場合、および連続する各ノード削除の間にクラスタが正常な状態である場合に限り。また、ノードを削除するための準備に必要な手順を実行している必要があります。詳細については、ノードの削除の準備 を参照してください。


（注）  

論理アベイラビリティゾーン（LAZ）が設定された HyperFlex クラスタのノードを削除する前に、LAZ を無効にする必要があります。

LAZ が HyperFlex クラスタで使用される場合、LAZ を再有効化する前に、残りのノードの数が、LAZ のガイドラインと考慮事項に従って LAZ をサポートするバランスの取れた構成である必要があります。


（注）  

このタスクの手順を実行する前に、コントローラ VM またはその他の HX Data Platform コンポーネントを削除しないでください。

手順

ステップ 1

stcli cluster info コマンドを実行し、stNodes: section を探して、削除する必要があるノードを見つけます。この情報は、ノードをメンテナンスモードにした場合にも使用できます。 

Example:
    ----------------------------------------
stNodes:
type: node
id: 689324b2-b30c-c440-a08e-5b37c7e0eefe 
name: ucs305

type: node
id: 9314ac70-77aa-4345-8f35-7854f71a0d0c
name: ucs306

type: node
id: 9e6ba2e3-4bb6-214c-8723-019fa483a308
name: ucs307

type: node
id: 575ace48-1513-0b4f-bfe1-e6abd5ff6895
name: ucs308

type: node
id: 875ebe8-1617-0d4c-af
name: ucs 309

5 -ノード クラスタからノードを削除するには、 stcli node remove コマンドを次のように実行します。

  • stcli node remove –ip-1 ucs 308 または

  • stcli node remove –-id-1 575ace48-1513-0b4f-bfe1-e6abd5ff6895

stcli node remove コマンドが正常に完了すると、システムにより、ストレージ クラスタの状態が [正常（Healthy）] になるまで、ストレージ クラスタの再調整が行われます。この期間中に障害テストを実行しないでください。ストレージ クラスタは引き続き正常です。

ストレージ クラスタ内にノードがないため、HXDP メンテナンス モードを終了する必要はありません。

（注）  

 

ストレージ クラスタ内のコンバージド ノードを取り外す場合は、TAC と一緒に作業することを強くお勧めします。取り外したコンバージド ノードやディスクは、元のクラスタで再利用しないでください。

（注）  

 

削除したノードを別のストレージ クラスタ内で再利用するには、テクニカル アシスタンス センター（TAC）にご連絡ください。ノードを別のストレージ クラスタで利用できるように準備するには、追加手順が必要です。

ステップ 2

ノードがストレージ クラスタから削除されていることを確認します。

  1. ストレージ クラスタ情報を確認します。

    # stcli cluster storage-summary

  2. 応答の ActiveNodes エントリを調べ、クラスタのノード数が 1 つ少なくなっていることを確認します。

  3. 削除されたノードが Ensemble の一部ではないことを確認します。次に例を示します。

    たとえば、削除されたノードが ucs-308 で、その CVM データ IP が 10.104.18.40 の場合、上記のようにノード削除後に上記のコマンドを実行すると、その CVM データ IP は表示されなくなります。

    .

    5 つ以上のノードがあり、削除されたノードがアンサンブルの一部であった場合、新しいノード IP が crmZKEnsemble に表示されます。たとえば、クラスタに最初に 7 つのノード（10.104.18.37〜10.104.18.43）があり、crmZKEnsemble に 10.104.18.37:2181,10.104.18.38:2181,10.104.18.39:2181、10.104.18.40:2181、10.104.18.41 がある場合：2181、その後、10.104.18.40 の削除後、crmZKEnsemble は次のいずれかを持ちます。

    10.104.18.37:2181,10.104.18.38:2181,10.104.18.39:2181、10.104.18.42:2181、10.104.18.41:2181 または

    10.104.18.37:2181,10.104.18.38:2181,10.104.18.39:2181、10.104.18.43:2181、10.104.18.41:2181

ステップ 3

hxcli disk list コマンドを実行して、削除されたノードのディスクが表示されなくなったことを確認します。 

admin:~$ hxcli disk list --no-loader
+-----------+-------------------+------+----------+---------+------------+-------------+
| NODE NAME | HYPERVSIOR STATUS | SLOT | CAPACITY | STATUS | TYPE | USAGE |
+-----------+-------------------+------+----------+---------+------------+-------------+
| ucs305 | ONLINE | 1 | 111.8 GB | Claimed | Solidstate | System |
| ucs305 | ONLINE | 2 | 894.3 GB | Claimed | Solidstate | Caching |
| ucs305 | ONLINE | 3 | 1.1 TB | Ignored | Rotational | Persistence |
| ucs305 | ONLINE | 4 | 1.1 TB | Ignored | Rotational | Persistence |
| ucs305 | ONLINE | 5 | 1.1 TB | Ignored | Rotational | Persistence |
| ucs305 | ONLINE | 6 | 1.1 TB | Ignored | Rotational | Persistence |
| ucs305 | ONLINE | 7 | 1.1 TB | Ignored | Rotational | Persistence |
| ucs305 | ONLINE |8|0B| Unknown | | |
| ucs306 | ONLINE | 1 | 111.8 GB | Claimed | Solidstate | System |
| ucs306 | ONLINE | 2 | 894.3 GB | Claimed | Solidstate | Caching |
| ucs306 | ONLINE | 3 | 1.1 TB | Claimed | Rotational | Persistence |
| ucs306 | ONLINE | 4 | 1.1 TB | Claimed | Rotational | Persistence |
| ucs306 | ONLINE | 5 | 1.1 TB | Claimed | Rotational | Persistence |
| ucs306 | ONLINE | 6 | 1.1 TB | Claimed | Rotational | Persistence |
| ucs306 | ONLINE | 7 | 1.1 TB | Claimed | Rotational | Persistence |
| ucs306 | ONLINE |8|0B| Unknown | | |
| ucs307 | ONLINE | 1 | 111.8 GB | Claimed | Solidstate | System |
| ucs307 | ONLINE | 2 | 894.3 GB | Claimed | Solidstate | Caching |
| ucs307 | ONLINE | 3 | 1.1 TB | Claimed | Rotational | Persistence |
| ucs307 | ONLINE | 4 | 1.1 TB | Claimed | Rotational | Persistence |
| ucs307 | ONLINE | 5 | 1.1 TB | Claimed | Rotational | Persistence |
| ucs307 | ONLINE | 6 | 1.1 TB | Claimed | Rotational | Persistence |
| ucs307 | ONLINE | 7 | 1.1 TB | Claimed | Rotational | Persistence |
| ucs307 | ONLINE |8|0B| Unknown | | |
| ucs309 | ONLINE | 1 | 111.8 GB | Claimed | Solidstate | System |
| ucs309 | ONLINE | 2 | 894.3 GB | Claimed | Solidstate | Caching |
| ucs309 | ONLINE | 3 | 1.1 TB | Claimed | Rotational | Persistence |
| ucs309 | ONLINE | 4 | 1.1 TB | Claimed | Rotational | Persistence |
| ucs309 | ONLINE | 5 | 1.1 TB | Claimed | Rotational | Persistence |
| ucs309 | ONLINE | 6 | 1.1 TB | Claimed | Rotational | Persistence |
| ucs309 | ONLINE | 7 | 1.1 TB | Claimed | Rotational | Persistence |
| ucs309 | ONLINE |8|0B| Unknown | | |
+-----------+-------------------+------+----------+---------+------------+-------------+

たとえば、ucs-308 を削除すると、そのディスクは表示されなくなります。

ステップ 4

VCenter の [ホストおよびクラスタ（Hosts and Cluster）] ビューからホストを削除します。

  1. vSphere Web クライアント ナビゲータにログインします。vSphere インベントリの [ホスト（Host）] に移動します。

  2. ホストを右クリックして、[すべての vCenter アクション（All vCenter Actions））] > [インベントリから削除（Remove from Inventory）] を選択しオンます。[はい（Yes）] をクリックします。

ステップ 5

すべてのノード関連データストアが削除されていることを確認します。たとえば、ESXiで次のコマンドを実行します。

[root@ucs308:~] esxcfg-nas -l
ds4 is 169.254.226.1:ds4 from 6894152532647392862-8789011882433394379 mounted available
ds3 is 169.254.226.1:ds3 from 6894152532647392862-8789011882433394379 mounted available
ds2 is 169.254.226.1:ds2 from 6894152532647392862-8789011882433394379 mounted available
ds5 is 169.254.226.1:ds5 from 6894152532647392862-8789011882433394379 mounted available
ds1 is 169.254.226.1:ds1 from 6894152532647392862-8789011882433394379 mounted available

（注）  

 

ノード関連データストアが表示されている場合は、それらのデータストアを手動でマウント解除して削除します。

オフライン ストレージ クラスタからのノードの削除

導入環境をクリーンアップするか、またはストレージ クラスタからノードを削除するには、stcli node remove を使用します。


（注）  

ストレージ クラスタ内のコンバージド ノードを取り外す場合は、TAC と一緒に作業することを強くお勧めします。

クラスタ内のノードの数

クラスタ内の障害が発生したノードの数

方法

注記

3

1

ノードを削除して交換するには、TAC にご連絡ください。

-

4

1

オフラインでのノードの取り外し。

（注）  

 

「ストレージ クラスタ マネージャが構成されていません（storage cluster manager is not configured）」というエラーが hxconnect で表示されるか、stcli cluster storage-summary | grep -i Heali -A 8 コマンドの一部として表示される場合は、TAC にお問い合わせください。

4 ノード クラスタで 2 つのノードがダウンしている場合は、TAC の支援が必要です。

5 つ以上

1

クラスタをオフラインにする必要があります。

オンライン モードが推奨されます。

5 つ以上

2

クラスタをオンラインにすることができます。

5 ノード クラスタで 3 つのノードがダウンしている場合は、TAC の支援が必要です。

（注）  

このタスクの手順を実行する前に、コントローラ VM またはその他の HX Data Platform コンポーネントを削除しないでください。

手順

ステップ 1

ノードの削除を準備するプロセスに従います。詳細については、ノードの削除の準備 を参照してください。

ステップ 2

(4 ノード クラスタのみ) シャットダウンの準備をしてから、ストレージ クラスタをシャットダウンします。

  1. すべての HX データストアのすべての常駐 VM を正常にシャットダウンします。

    任意で、VM を vMotion で移動します。

  2. HX ストレージ クラスタ ノードの非 HX データソースですべての VM を正常にシャットダウンし、マウント解除します。

  3. コントローラ VM コマンド ラインから stcli cluster shutdown コマンドを実行します。

    # stcli cluster shutdown

ステップ 3

stcli cluster info コマンドを実行し、stNodes: section を探して、削除する必要があるノードを見つけます。この情報は、ノードをメンテナンスモードにした場合にも使用できます。 

Example:
    ----------------------------------------
    type: node
    id: 569c03dc-9af3-c646-8ac5-34b1f7e04b5c
    name: example1
    ----------------------------------------
    type: node
    id: 0e0701a2-2452-8242-b6d4-bce8d29f8f17
    name: example2
    ----------------------------------------
    type: node
    id: a2b43640-cf94-b042-a091-341358fdd3f4
    name: example3
----------------------------------------
    type: node
    id: d2d43691-daf5-50c4-d096-941358fede374
    name: example5

ステップ 4

stcli node remove コマンドを使用して該当するノードを取り外します。

次に例を示します。

1 つのノードを削除するには

  • stcli node remove: ip-1 example5 または

  • stcli node remove –id-1 d2d43691-daf5-50c4-d096-941358fede374

Response:
    Successfully removed node: EntityRef(type=3, id='', name='10.10.2.4')
このコマンドは、すべてのデータストアをマウント解除し、クラスタ アンサンブルから削除し、このノードの EAM をリセットし、すべてのサービス（ストア、クラスタ管理 IP）を停止し、すべてのファイアウォール ルールを削除します。

このコマンドは、vCenter からノードを削除しません。ノードは vCenter に残ります。このコマンドはまた、インストールされている HX Data Platform 要素（コントローラ VM など）を削除しません。

ストレージ クラスタ内にノードがないため、HXDP メンテナンス モードを終了する必要はありません。

（注）  

 

削除したノードを別のストレージ クラスタ内で再利用するには、テクニカル アシスタンス センター（TAC）にご連絡ください。ノードを別のストレージ クラスタで利用できるように準備するには、追加手順が必要です。

ステップ 5

クラスタを再起動します。

# hxcli cluster start

ステップ 6

クラスタが起動したら、ノードがストレージ クラスタクラスタから削除されていることを確認してください。

  1. ストレージ クラスタ情報を確認します。

    # stcli cluster storage-summary

  2. 応答の ActiveNodes エントリを調べ、クラスタのノード数が 1 つ少なくなっていることを確認します。

  3. 削除されたノードが Ensemble の一部ではないことを確認します。

  4. ノード数が 5 以下のクラスタでノード削除アクションが成功した場合、アンサンブルには 4 つの参加者ノードと 1 つのオブザーバ ノードが含まれている可能性があります。参加者ノードのみが stMgr.cfg で更新されます。オブザーバ ノードの詳細は更新されません。

    例:

    ノード削除後のアンサンブル server.0=10.107.16.111:2888:3888:participant;10.107.16.111:2181

    server.1=10.107.16.107:2888:3888:participant;10.107.16.107:2181

    server.2=10.107.16.108:2888:3888:participant;10.107.16.108:2181

    server.4=10.107.16.110:2888:3888:participant;10.107.16.110:2181

    server.5=10.107.16.109:2888:3888:observer;10.107.16.109:2181

    version=10000558b

ステップ 7

hxcli disk list コマンドを実行して、削除されたノードのディスクが表示されなくなったことを確認します。 

admin:~$ hxcli disk list --no-loader
+-----------+-------------------+------+----------+---------+------------+-------------+
| NODE NAME | HYPERVSIOR STATUS | SLOT | CAPACITY | STATUS | TYPE | USAGE |
+-----------+-------------------+------+----------+---------+------------+-------------+
| ucs305 | ONLINE | 1 | 111.8 GB | Claimed | Solidstate | System |
| ucs305 | ONLINE | 2 | 894.3 GB | Claimed | Solidstate | Caching |
| ucs305 | ONLINE | 3 | 1.1 TB | Ignored | Rotational | Persistence |
| ucs305 | ONLINE | 4 | 1.1 TB | Ignored | Rotational | Persistence |
| ucs305 | ONLINE | 5 | 1.1 TB | Ignored | Rotational | Persistence |
| ucs305 | ONLINE | 6 | 1.1 TB | Ignored | Rotational | Persistence |
| ucs305 | ONLINE | 7 | 1.1 TB | Ignored | Rotational | Persistence |
| ucs305 | ONLINE | 8 | 0 B | Unknown | | |
| ucs306 | ONLINE | 1 | 111.8 GB | Claimed | Solidstate | System |
| ucs306 | ONLINE | 2 | 894.3 GB | Claimed | Solidstate | Caching |
| ucs306 | ONLINE | 3 | 1.1 TB | Claimed | Rotational | Persistence |
| ucs306 | ONLINE | 4 | 1.1 TB | Claimed | Rotational | Persistence |
| ucs306 | ONLINE | 5 | 1.1 TB | Claimed | Rotational | Persistence |
| ucs306 | ONLINE | 6 | 1.1 TB | Claimed | Rotational | Persistence |
| ucs306 | ONLINE | 7 | 1.1 TB | Claimed | Rotational | Persistence |
| ucs306 | ONLINE | 8 | 0 B | Unknown | | |
| ucs307 | ONLINE | 1 | 111.8 GB | Claimed | Solidstate | System |
| ucs307 | ONLINE | 2 | 894.3 GB | Claimed | Solidstate | Caching |
| ucs307 | ONLINE | 3 | 1.1 TB | Claimed | Rotational | Persistence |
| ucs307 | ONLINE | 4 | 1.1 TB | Claimed | Rotational | Persistence |
| ucs307 | ONLINE | 5 | 1.1 TB | Claimed | Rotational | Persistence |
| ucs307 | ONLINE | 6 | 1.1 TB | Claimed | Rotational | Persistence |
| ucs307 | ONLINE | 7 | 1.1 TB | Claimed | Rotational | Persistence |
| ucs307 | ONLINE | 8 | 0 B | Unknown | | |
+-----------+-------------------+------+----------+---------+------------+-------------+

たとえば、ucs-308 を削除すると、そのディスクは表示されなくなります。

ステップ 8

VCenter の [ホストおよびクラスタ（Hosts and Cluster）] ビューからホストを削除します。

  1. vSphere Web クライアント ナビゲータにログインします。vSphere インベントリの [ホスト（Host）] に移動します。

  2. ホストを右クリックして、[すべての vCenter アクション（All vCenter Actions））] > [インベントリから削除（Remove from Inventory）] を選択しオンます。[はい（Yes）] をクリックします。

ステップ 9

すべてのノード関連データストアが削除されていることを確認します。たとえば、ESXiで次のコマンドを実行します。

[root@ucs308:~] esxcfg-nas -l
ds4 is 169.254.226.1:ds4 from 6894152532647392862-8789011882433394379 mounted available
ds3 is 169.254.226.1:ds3 from 6894152532647392862-8789011882433394379 mounted available
ds2 is 169.254.226.1:ds2 from 6894152532647392862-8789011882433394379 mounted available
ds5 is 169.254.226.1:ds5 from 6894152532647392862-8789011882433394379 mounted available
ds1 is 169.254.226.1:ds1 from 6894152532647392862-8789011882433394379 mounted available

（注）  

 

ノード関連データストアが表示されている場合は、それらのデータストアを手動でマウント解除して削除します。

コンピューティング ノードの削除

手順

ステップ 1

削除する必要があるコンピューティング ノードからすべての VM を移行します。

ステップ 2

コンピューティング ノードからのデータストアをマウント解除します。

ステップ 3

次のコマンドを実行して、クラスタが健全な状態であることを確認します。

stcli cluster info --summary

ステップ 4

ESXi ホストを HXDP メンテナンス モードにします。

ステップ 5

CIMP (クラスタ IP アドレスのように Cisco HX Connect IP アドレスを使用) から stcli node remove コマンドを使用して、コンピューティング ノードを削除します。 

stcli node remove --id-1

Or

stcli node remove --ip-1

IP は、削除されるノードの IP アドレスです。

ステップ 6

DVS が存在する場合、vCenter の EXSi ホストから DVS を削除します。

ステップ 7

vCenter から ESXi ホストを削除します。

ステップ 8

次のコマンドを実行して、クラスタが健全な状態であることを確認します。

stcli cluster info --summary

ステップ 9

stcli cluster info の情報出力に計算ノードの virtnode エントリーがまだ存在する場合は、次を実行します。

SCVM で priv service stMgr restart を使用して、stMgr 管理サービスを再起動します。

ステップ 10

Cisco HX Connect をログアウトし、Cisco HX Connect にログインして、コンピューティング ノードの古いエントリを消去します。

ステップ 11

高可用性 (HA) および分散リソース スケジューラ (DRS) サービスを無効にしてから再度有効にして、ノードを削除した後にサービスを再設定します。

同じクラスタ内で以前に削除されたノードを再利用する

以前に削除した同じクラスタ内のノードを再利用するには、次の手順を実行します。

始める前に

  • 同じクラスタで再利用するには、HXDP 4.5(2b) 以降を実行しているクラスタでノードを削除する必要があります。

  • HX ノードは、クラスタがオンラインのときに削除しなければなりません。クラスタがオフラインのときにノードを削除した場合、そのノードは同じクラスタ内で再利用できなくなる可能性があります。

  • HX ノードの削除は、管理ガイドに記載されている stcli node コマンドを使用して実行する必要があります。ノードがクラスタから適切に削除されなかった場合、同じクラスタ内で再利用できなくなる可能性があります。

  • 4 ノード クラスタの場合には、オフライン ストレージ クラスタからのノードの削除 のみ使用します。ノードの再利用は、4 ノード クラスタではサポートされていません。

手順

ステップ 1

vCenter Cluster インベントリから ESXi ホストを削除します。

ステップ 2

HX クラスタの残りの部分とマッチする、同一のバージョンの ESXi を再インストールします。

ステップ 3

この削除されたノードに以前に関連付けられていた UCS Manager から UCS サービス プロファイルのみを削除します。

ステップ 4

同じバージョンの HX インストーラを使用して、拡張ワークフローを実行します。

（注）  

 

拡張ワークフロー中は、必ず [ディスク パーティションをクリア（Clear Disk Partitions）] ボックスをオンにしてください。