ノードの管理

ノードは最初、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 つのノードを削除できます。

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

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

オンラインタスク：タスク開始前にストレージクラスタが正常な状態である必要があります。
オフラインタスク：ストレージクラスタをシャットダウンする必要があります。

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 検索アドレスを割り当てます。

HX Data Platform インストーラ仮想マシンにログインします。ssh または vSphere コンソールインターフェイスを使用します。
resolv.conf.d ファイルを編集します。
```
# vi /etc/resolvconf/resolv.conf.d/base
```
変更を確認します。
```
# resolvconf -u
# cat /etc/resolv.conf
```
DNS サーバが IP アドレスまたはホスト名から照会できることを確認します。
```
# nslookup ip_address
# nslookup newhostname
```

ステップ 2

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

HX Data Platform インストーラ仮想マシンにログインします。ssh または vSphere コンソールインターフェイスを使用します。
編集のために hosts ファイルを開きます。
```
# vi /etc/hosts
```
次の行を追加し、ファイルを保存します。

ip_address ubuntu newhostname

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

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 を探します。

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

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

ステップ 4

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

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

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

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

ステップ 5

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

コントローラ VM が DNS サーバの正しい IP アドレスを認識していることを確認します。
コントローラ VM のコマンドラインから。
```
# stcli services dns show
10.192.0.31
```

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

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

ステップ 6

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

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

ステップ 7

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

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

（注）

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

ステップ 8

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

vCenter から、データセンターを右クリックします。[新規クラスタ（New Cluster）] を選択します。
削除したクラスタとまったく同じ名前を [クラスタ名（Cluster Name）] に入力します。これは、ステップ 6 で書き留めた名前です。

ステップ 9

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

vCenter から、データセンター > クラスタを右クリックします。[ホストの追加（Add Host）] を選択します。
FQDN を使用して ESXi ホストを選択します。
クラスタ内の各 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 を有効にします。

admin として HX クラスタ IP にログインし、＃hx_post_install コマンドを実行します。
[Option 1-"New / Existing Cluster" ]を選択し、すべてのログインクレデンシャルを入力します。
新しいライセンスキーを入力する場合は「y」と入力します。
クラスタで HA と DRS を有効にするには、「y」と入力します。
他のすべてのオプションで「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 をサポートするバランスの取れた構成である必要があります。

ノードの削除の準備

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

（注）

5.0（1a）以降では、削除するノードがメンテナンスモードになってから2時間後に再調整が自動的に開始されます。

手順

ステップ 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 が含まれます。

Example:
admin:~$ cat /etc/springpath/storfs.cfg | grep -i ense
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

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

ステップ 5

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

GUI

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

[vSphere メンテナンスモード（vSphere Maintenance Mode）] オプションは、ホストの右クリックメニューの上部にあります。リストの下部までスクロールし、[Maintenance Mode] を選択します。
HX Connectで、[MANAGE] > [System Information] パネルの [Node] タブからノードを選択し、[HX Maintenance Mode] ボタンをクリックします。

CLI

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

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 または名前を見つけます。

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

ストレージクラスタを再調整します。

rebalance コマンドは、使用可能なストレージの変更すべてに対して保存されているデータの分散を再調整し、ストレージクラスタの健全性を回復するために使用されます。ストレージクラスタ内のノードを追加または削除する場合は、stcli rebalance コマンドを使用して、ストレージクラスタの再調整を手動で開始できます。

（注）

障害が発生したノードまたはディスクで使用されるディスク容量によって、再調整に時間がかかる場合があります。再調整が完了したら、クラスタが正常であることを確認します。

管理ユーザーとしてコントローラ VM にログインします。
コントローラ VM のコマンドラインから、次のコマンドを実行します。

# stcli rebalance start --force

ステップ 7

クラスタが正常になるまで待ちます。クラスタが正常であることを確認するには、stcli cluster storage-summary コマンドを実行します。

Example:
admin:~$ stcli cluster storage-summary 
address: 169.254.226.1
name: ucs1118-0004 state: online
uptime: 10 days 22 hours 23 minutes 40 seconds
activeNodes: 4 of 5
compressionSavings: 55.49%
deduplicationSavings: 52.88% freeCapacity: 5.9T healingInfo:
inProgress: False resiliencyInfo:
messages:
Storage cluster is healthy. state: 1
nodeFailuresTolerable: 1
cachingDeviceFailuresTolerable: 2
persistentDeviceFailuresTolerable: 2 
zoneResInfoList: None
spaceStatus: normal 
totalCapacity: 6.0T 
totalSavings: 79.03% 
usedCapacity: 164.9G
zkHealth: online 
clusterAccessPolicy: lenient 
dataReplicationCompliance: compliant 
dataReplicationFactor: 3

次のタスク

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

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

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

（注）

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

（注）

このタスクの手順を実行する前に、コントローラ 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）] になるまで、ストレージクラスタの再調整が行われます。この期間中に障害テストを実行しないでください。ストレージクラスタは引き続き正常です。

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

ステップ 2

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

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

# stcli cluster storage-summary
応答の ActiveNodes エントリを調べ、クラスタのノード数が 1 つ少なくなっていることを確認します。
削除されたノードが Ensemble の一部ではないことを確認します。次に例を示します。
```
Example:
admin:~$ cat /etc/springpath/storfs.cfg | grep -i ense
crmZKEnsemble=10.104.18.37:2181,10.104.18.38:2181,10.104.18.39:2181,10.104.18.41:2181
```
たとえば、削除されたノードが 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）] ビューからホストを削除します。

vSphere Web クライアントナビゲータにログインします。vSphere インベントリの [ホスト（Host）] に移動します。
ホストを右クリックして、[すべての 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 を使用します。

（注）

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

手順

ステップ 1

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

ステップ 2

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

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

任意で、VM を vMotion で移動します。
HX ストレージクラスタノードの非 HX データソースですべての VM を正常にシャットダウンし、マウント解除します。
コントローラ VM コマンドラインから stcli cluster shutdown コマンドを実行します。

# stcli cluster shutdown

ステップ 3

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 など）を削除しません。

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

ステップ 5

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

# stcli cluster start

ステップ 6

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

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

# stcli cluster storage-summary
応答の ActiveNodes エントリを調べ、クラスタのノード数が 1 つ少なくなっていることを確認します。
削除されたノードが Ensemble の一部ではないことを確認します。
```
admin:~$ cat /etc/springpath/storfs.cfg | grep -i ense
crmZKEnsemble=10.104.18.37:2181,10.104.18.38:2181,10.104.18.39:2181
```
たとえば、10.104.18.40 を削除した場合は表示されなくなります。

ステップ 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）] ビューからホストを削除します。

vSphere Web クライアントナビゲータにログインします。vSphere インベントリの [ホスト（Host）] に移動します。
ホストを右クリックして、[すべての 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 ホストをメンテナンスモードにします。
ステップ 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）] ボックスをオンにしてください。

Cisco HyperFlex Data Platform リリース 4.5 アドミニストレーションガイド

偏向のない言語

翻訳について

Book Title

Cisco HyperFlex Data Platform リリース 4.5 アドミニストレーションガイド

Chapter Title