Nutanixのサイジングにあたり、Nutanix社ではSizerと呼ばれるサイジングツールを提供しております。
当社でもこのサイジングツールを利用してサイジングを実施しておりますが、今回はサイジングにあたり考慮すべき点などをあげさせて頂きます。
まずNutanix社ではEnterprise Cloud Platformとしてマルチクラウド管理の実現を行える製品を多くだしていますが、オンプレミスでNutanix環境を稼働させるにはワークロードをベースにNutanixを選定していきます。
重要なのはハードウェア、Hypervisorというよりもどれだけのワークロードを動かすか？となるわけです。
つまり既存のハードウェアのリプレイスにNutanixを検討されている場合に
既存のハードウェアスペックに対してサイジングを行ってしまうと、既存のハードウェア＝ワークロードとなってしまいます。
もし既存環境が60～70%以下の利用率となっているケースではかなりのオーバースペックが選定されてしまいます。
もう一度繰り返しになりますが、サイジングで必要なのはワークロードとなります。
実際にワークロードの作成までの流れを見ていきましょう。
- シナリオ名、ハードウェアの選定
- ワークロードの登録
- シナリオ結果の確認
Nutanixを稼働させるハードウェアは純正のNXモデル以外にもLenovoHXモデルなど選択が可能となっております。
どのハードウェアを利用したいかを決めてワークロードを登録していきます。
タークロードタイプはどのようなワークロードを稼働させるか？によって決まってきますが、簡単に構成を確認するにはRawと呼ばれるものを利用してワークロード全体の入力を実施するか、仮想サーバの数そして、仮想サーバ単位でのワークロードの入力となります。
本Blogではサーバ仮想化におけるRawの値、またRVtoolsを利用したサイジングについて触れていきます。
サーバの仮想化についてまず知るべきなのはアプリケーションの分類を分ける事です
仮想マシンごとに次のタイプが解っている事がベターです。
[仮想マシンのスペックの例]
- memory , CPU (Mhz) , OS ドライブ, データドライブ(Hot / Cold データ)
ただし、最初の段階でこの辺り(特にCPU やHot / Cold データ)を把握して置くのが難しい場合は
次を基準に登録してみましょう。
[vCPUとmemory]
vCPU と pCPUのRatio比率
- BCAアプリケーションでは 1:1 (または2:1)
- 一般的なサーバ 4:1
- OTA 環境で最大10:1(この場合はパフォーマンステスト事前に実施する事を推奨します）
[ディスク領域のポイント]
データの複製は2重化にするか、3重化にするか？
-RF2の場合はデータは常に2重化されるので、利用可能な領域は50%
-RF3の場合はデータは常に3重化されるので、利用可能な領域は33% －Proライセンスが別途必要
EC-Xを有効にする場合で最小ノード数が変更になる -Proライセンスが別途必要
-RF2 + EC-X では最小スタートノードは4ノード
-RF3 + EC-X では最小スタートノードが6ノード
Hybrid構成の場合はSSD Tierの割り当て量を考慮します。
SSDのTierの領域はExtent Store , Oplog また、Metadeta ,Curatorなども動作するためにサイジングは多めに設定する事を推奨しています。
SSDの目安としてはデータセットの10%程度から開始して状況と予算に合わせて調整するとよいのではないでしょうか
【圧縮・重複排除の扱い】
データセットが不明な場合は考慮に入れない
構成によってはProライセンスが必要になりますし、圧縮率の判断が難しいところですので
最初の段階では無効に設定しておく方が無難なケースが多いです。
(例えばLinked ClonesへのDedupe , jpgファイルへの圧縮効果は期待できません）
[障害考慮のポイント]
NutanixのSizerでは1ノード障害、2ノード障害を考慮したサイジング可能となっております。
構成時は障害を考慮してN+1などで構成しましょう。
次にストレージノードを構成する場合ですが、ストーレジノードの障害時はデータ分散が他のノードにされますので、これに対応できるようにしましょう！
容量の少ないノードとストレージノードの組み合わせだとストレージノード障害時にデータ分散で他のノードの容量が多くなる可能性があります。
既存の環境の状況を把握する場合にはRVToolsを利用するという方法もあります。
ここではRVToolsを利用したRawの入力値の参考になる項目などを記載しています。
Sizerに入力するRawの値を確認するには必要な項目はvInfo, vPartition, vHostとなります。
他の不要な項目はいったん削除しておきましょう。
前提としてサーバのカテゴリ分類をしていませんので、実際に確認される場合はカテゴリ毎にRawの値を見るようにしていただければより最適なものになっていきます。
次に稼働しているワークロードのフィルタをかけるためPower Onのフィルタを実施します。
また、SizerへこのRvtoolsのimportも行えますが、この際も同様にPower OFFの物は除外されます。
Memoryタブでは実際に稼働している仮想マシンに対して合計のメモリーサイズが確認できます。
CPUタブでは仮想マシンのCPU数が確認できます。
vPartitionでは仮想マシンのディスクサイズが確認できます。
ここまでで仮想マシンの合計のCPU数、メモリーサイズ、Diskサイズが確認できました。
つまり、これでRawに登録するvCPU数,メモリーサイズ,Diskサイズが入力できるわけですが、
Diskサイズに関してはSwapファイルを考慮するとDisk サイズ+ Memoryサイズとなります。
この例では登録するアクティブなワークロードの合計としては
vCPU数を145
メモリーサイズ:496GiB (507904/1024)
Diskサイズ:2.24TiB (1841729+507904) / 1024 / 1024
この値は確認する計測期間がながく、確認するタイミングが多ければ多いほどより適正なサイジングに近づいてきます。
次にvCPU:pCPUを見ていきますが、これにはvHost から物理CPUを確認していきます
稼働している仮想マシンと物理コアが確認できましたので、アクティブワークロードのでの
vCPU , pCPUの比率は145 / 48 となります。
が1ノード障害が発生した場合はどうなるかという事をここで考慮してみましょう。
物理コアは48 -> 36 となりますので、1ノード障害時でもすべての仮想マシンが現在正常に稼働していると考えると、145 / 36 = 4.02 この値が最適では無いかと考えられます。
これでRawに入れる値がすべてそろいました。
まとめると
vCPU数:145
vCPU:pCPU: 4
memory:496
Disk:2.24
HotTire:0.24 (10%)
vCPUとpCPUの比率ですが、実際に昔のCPUと新しいCPUではパフォーマンスが異なります。
古いハードウェアほど、vCPU:pCPUコア比率は上げる事が出来るわけです。
ここでは実際に既存のハードウェアのプロセッサをvHostから見てみます。
既存のCPUの値とサイジング結果で出たCPUの結果の値をCPU Benchmarks (外部リンク) というサイトで簡単に比較する事も出来ます。
実際にサイジングで入力してみると今回の最適なモデルはNX1065-G6となりCPUはSilver4114となっています。
ここで先ほどのCPU Benchmarksの値を確認すると以下であることが解ります。
Intel Xeon E5649 @ 2.53GHz スコア：1,170
Intel Xeon Silver 4114 @ 2.20GHz スコア：1,661
既存のCPUから新しいスペックへ置き換えると既存と比較しても凡そ1.42倍のスコアになるわけです。
vCPU:pCPUですが、実際に稼働する場合は4:1ではなく、4x1.42:1となります。
つまり同じスペックをそのまま引き継ぐと4:1ですが、世代がことなるので実稼働は
5.68:1 程度で動作させることが可能となります。
これをサイジングでAuto -> manualに変換してみると CPUの利用率は50%程度まで下がることがわかり、十分余裕のあるサイジングである事が解ります。
RVToolsを利用する事で実際の仮想マシンの利用率ではなく、プロビジョンに対してサイジングを
する事も出来ますし、既存環境がすべてONという状況を想定したサイジングも可能です。
ただし、Nutanix自体はスケールアウトが1クリックで行える製品になります。
様々な角度でサイジングを行ってみて、このタイミングでSizerの利用方法について慣れてみては如何でしょうか？
【あとがき】
この記事はNutanix Advent Calendar 2018の２枚目の12/5日分として投稿しています。
記事担当者 : SI技術本部 カッシー @Networld_NTNX
