Nutanix Community Edition（ce-2015.07.16-beta）でのクラスターからのノード追加と削除

Nutanix Community Edition（ce-2015.07.16-beta）でのノード追加と削除を試してみます。
![スクリーンショット 2015-07-12 21.49.23_R.png](https://qiita-image-store.s3.amazonaws.com/0/84474/801f38e6-770b-b351-796c-f0cbcbb9084c.png)


**なお，7月20日現在，ダウンロード可能なNutanix CEは，ce-2015.07.16-betaとなっており，7月20日時点，ce-2015.07.16-betaに基づいて記載しています。そのため，今後新しいバージョンが提供された場合に，当該記載と矛盾が生じる場合がありますのでご注意ください。**
**また，さわりはじめたばかりで認識誤り等があるかもしれません。おかしい，なんか違う等ありましたらご一報を。**



# Nutanix CEのノードの追加・削除において参考にした資料
【要Nutanix Next Communityログイン】[Web Console Guide](https://portal.nutanix.com/#/page/docs/details?targetId=Web_Console_Guide-NOS_v4_1:Web_Console_Guide-NOS_v4_1)
>
PRISM上から行う，Nutanix CE及びAcropolis hypervisorの各種設定，操作について記載されている資料です。Community Meetupの資料やイギリスのTech Groupのインストレーション資料は，あくまでインストールとVMのセットアップまでなので，それ以降の作業は，この辺のマニュアルに頼り切りです。他に何か良い資料があったらおしえて下さい，あと日本語資料求む…

# はじめに
Nutanix CEがce-2015.06.18-betaからce-2015.07.16-betaとなり，いくつかのバグフィックスと機能追加が行われました。その中のうちのバグフィックスで，マルチクラスターにおけるノードの追加ができない問題が修正された模様です。

# Nutanixにおけるノードの追加及び削除における基本的なルール
ノードの追加，削除を試す前に，Nutanix（一部，商用版も含む）におけるノードの追加及び削除における基本的なルールのおさらいです。

## 4ノードクラスター構成時におけるノード障害及び削除について
>
* 4ノード以上を含むクラスターでノード障害発生した場合には，動的に障害ノードを削除することでクラスターの健全性が回復する。
* 障害ノードを削除することで，動的に新たに設定される3ノードクラスターでは，クラスターの完全保護を可能とする規程のノード数3をクリアしているため，引き続きクラスターは保護される。

## 3ノードクラスター構成時におけるノード障害及び削除について
>
* 3ノードクラスターでノード障害発生した場合には，動的に障害ノードを削除するこはできない。
* ただし，クラスターは2つの正常なノードと1つの障害ノードをクラスター内に保持しながら，中断することなく稼動することは可能だが，正常なノードが2つしかないためクラスターの保護は完全ではない。

## シングルノードクラスター構成時におけるノード障害及び削除について
>
* シングルノードクラスターは，クラスターと呼称するものの保護機能はまったく作用しない。シングルノードクラスター時におけるノードの障害は，システムそのものの停止となる。
* シングルノードクラスター構成時におけるノードの削除は，クラスターの削除と同義で，クラスターで保持してるデータが失われる。

## Nutanix CE版におけるノードの削除や追加の制限
>
* 4ノードまでしか対応せず，2ノードクラスターがそもそもあり得ないNutanix CEでは，ノードの追加，削除は，3ノードを4ノードに，または4ノードを3ノードにする操作のみが可能。
* 1ノードから3ノードまたは4ノードにするのは，最初に1ノードでクラスターを作成した際に設定されたRF1（データ冗長性なし）の値を変更することができないため，RF2が設定される3ノード以上のクラスター構成が不可能。


# ノードの追加と削除オペレーション
Nutanix CEにおけるノードの追加と削除は，基本的にPRISM上から行いますが，どちらも数クリック程度で完了します。ただし，ノードが特殊な落ち方をした場合やクラスター内のノード管理情報の整合性に問題が発生するような場合等には，コマンドラインからの情報取得や操作が必要になると思われます。

## ノードの削除
ノードの追加の前にノードの削除を行います。実はce-2015.06.18-betaでノード追加がバグでできなかったため，ノード削除もダメかなぁと試していませんでした（ノード削除はどうもできていたみたいですが）。4ノード構成のクラスターを一気に作成しその後そのまま検証を続けているため，ノード追加を試すには，まずノード削除を行う必要があるので，先にノード削除です。

クラスター及びノードの情報は，メインメニューのHardwareを選択しTableを参照しながら操作を開始します。
![01_add_remove_start.png](https://qiita-image-store.s3.amazonaws.com/0/84474/294f4075-c81c-0511-bf6a-cff972dbf5ea.png)
　
　
クラスターから削除したいノードを選択します。選択されたノードは一覧上で，薄水色に反転し選択状態になります。
![02_select_node.png](https://qiita-image-store.s3.amazonaws.com/0/84474/a260d4b1-147e-b174-ad1c-1d8495434d0c.png)
　
　
選択状態のまま，画面右下のほうから「Remove Host」ボタンを選択します。
![03_remove_button.png](https://qiita-image-store.s3.amazonaws.com/0/84474/b32b2db2-dcf8-ce16-dedf-b1872d0b2757.png)
　
　
ノードの削除の最終確認が行われるので，Yesでノードの削除を開始します。
![04_remove_go.png](https://qiita-image-store.s3.amazonaws.com/0/84474/7bb07a3c-6186-db0d-bc34-c1d86214fde5.png)
　
　
ノードの削除中は，画面中央の通知領域にノード削除の進行状況が表示されます。削除するノードに接続されているディスクの切断やメタデータやレプリケーションデータの同期が進行します。
![05_removing.png](https://qiita-image-store.s3.amazonaws.com/0/84474/43945560-bf7a-af27-e5c6-9d2466e24912.png)
　
　
ノードの削除が完了すると，ノードの一覧から削除対象ノードが消えていることがわかります。
![06_after_remove.png](https://qiita-image-store.s3.amazonaws.com/0/84474/2454dc56-6b96-5150-2500-26b38b26f1d0.png)
　
　
また，TableからOverviewに移動すると，Hostの情報部分に，3 Host，3 MONITORED，1 DISCOVERDと表示されていることがわかります。DISCOVERD部分に表示される数値は，クラスターに参加していない，クラスターに参加可能なノードの数を表しています。
![07_check_node_num.png](https://qiita-image-store.s3.amazonaws.com/0/84474/c8d84815-52ed-6cf0-e3d0-1e029726d97f.png)
　
　
これで，クラスターからのノードの削除が完了しました。

## ノードの追加
いよいよ，ce-2015.06.18-betaでは，できなかったノードの追加です。ce-2015.07.16-betaのChange log上では，IPMIアドレスが取得できない場合に，ノード追加が続行できないい不具合を修正したとありましたが，3ノード構成時から4ノードへの追加は，IPMIアドレスに関係なくダメだったと認識しているので，果たしてこちらも修正されているか確認していきます。

ノードの削除と同様に，Hardwareの画面から操作を開始します。一応，Overviewの方を確認し，DISCOVERD部分に1以上の数値を確認してから操作を開始します。操作は，画面右上のほうから「+ Expand Cluster」ボタンを選択します。
![08_start_expand.png](https://qiita-image-store.s3.amazonaws.com/0/84474/95ec180c-bbe7-1a05-91ce-be0ac9d9b99d.png)
　
　
Expand Clusterのモーダルポップアップ画面が表示され，DISCOVERD状態のノードが表示されます。商用のNutanixの画面と共用のようで，Nutanixアプライアンス製品の基本仕様のように1つの筐体に4つのノードが入るような画面となっています。Nutanix CEでは，常にPositionがAの位置にノードがある表示になるようです（ただし高密度マルチノードサーバーのようにNutanixアプライアンスと同様の物理筐体構成をとるようなハードウェアを利用した場合は，どのような表示になるのかわかりません）。
![09_expand_set.png](https://qiita-image-store.s3.amazonaws.com/0/84474/9936d77d-ceac-13f8-89f0-21850d8809e5.png)
　
　
CommunityEdition (Serial Number:XXXXXXXX)のチェックボックスを選択します。チェックボックスを選択すると，自動的にDISCOVERD状態のノードのHypervisorのIPアドレスとCVMのIPアドレス，取得できればIPMIのアドレスがそれぞれ自動的に入力されます。ce-2015.07.16-betaのバグフィックスで，IPMIアドレスが空欄でもSaveできるように修正されています。
![10_select_node.png](https://qiita-image-store.s3.amazonaws.com/0/84474/376c6824-9538-cf97-9b6c-4c00ef6a1e00.png)
　
　
正常にノード追加の操作ができました。ウィンドウ内上部のメッセージ，最後のbutで切れいるのが気になりますが，とりあえずは追加操作が完了です。
![11_expand_start.png](https://qiita-image-store.s3.amazonaws.com/0/84474/1054d2b3-ef78-e7b3-e689-dc3777f71da6.png)
　
　
PRISMの画面中央，メインメニューの通知エリアからノード追加の進行状況が確認することができます。しばらく待っているとAdding nodeのジョブが100%まで進み，ノード追加が完了したことが分かります。
![12_expand_done.png](https://qiita-image-store.s3.amazonaws.com/0/84474/2eda73e9-8b52-35e1-2ee0-d0402b212d80.png)
　
　
再び，HardwareのTableを見ると，先ほどまで一覧上に3しかなかったノードが4つになっているのが確認できます。
![13_4node_is_back.png](https://qiita-image-store.s3.amazonaws.com/0/84474/73478cdb-66d2-89e6-9bf7-2fb1859a139f.png)
　
　
また，Overviewのほうでは，Hostの情報部分に，4 Host，4 MONITORED，0 DISCOVERDと表示されていることがわかります。今のノード追加で，新たにノード追加可能なノードを全て使い切ったため，DISCOVERD部分に表示される数値は0となります。
なお，Disksのほうは，データのレプリケーションのバックグラウンドの同期処理の問題か単にPRISMの反映までの時間の問題か少し遅れて反映されるようです。
![14_host_num_check.png](https://qiita-image-store.s3.amazonaws.com/0/84474/f9f692ad-22b5-7781-68eb-5b913696ebf5.png)
　
　
これで，無事にノード追加ができました！！
　
***
　
次回以降は，Migrationについて試してみようと思います。

少しいじった感じだと，CPU世代の異なるノード間でのMigrationはできない状況ですが，これはKVMの制限事項なのか，Nutanix CEもしくはAcropolisの制限なのかわかりませんが，少し調べてまた書き残しておきます。