#Nutanix 資格 まとめー2019/01版

自身のブログに定期的にアクセスいただく、資格に関するもの。
この半年で大きく変わってきているので、
再度まとめ直しを行います。

１．変更点の概要

大きく入れ替わりまして、
名称も含めて大刷新をされました。
ほとんど過去を捨てたレベルです（大げさ）

技術資格系はテスト時の受講環境チェックが実施されるようになるなど、
認定取得をより厳格に行う制度へと移行しました。

基本的に名称に「Certified」が入るように
変わってきていますので、
新資格かどうかは「Certified」表記の有無で
ある程度判断ができるという点があります。

２．資格体系

大きく４つのカテゴリに分類されています。

A．Sales
B．Technical

C．SE

D．Services

各カテゴリ、順に見ていきましょう。


【A．Salesカテゴリ】

Salesのカテゴリには以下４つの資格が属しています。

A－１．Nutanix Certified Sales Representative (NCSR): Level 1
A－２．Nutanix Certified Sales Representative (NCSR): Level 2
A－３．Nutanix Certified Sales Representative (NCSR): Level 3
A－４．Nutanix Certified Sales eXpert(NCSX)

以前はA-1～A-3まで個別名称でしたが、
今回からレベル表記に変更となりました。

NCSRは基本的にはオンラインでのセルフペーステストのままで、
受講自体は大きく変わっていません。
NCSXは過去同様、プレゼンテーションを含む仕掛けになっており、
現在日本国内では開催されていないため、
取得が実施的にできない状況です。

【B．Technicalカテゴリ】

このカテゴリが新設されましたが、ある意味旧のAdminカテゴリですね。
中身は技術系の資格体系になっています。

B－１．Nutanix Certified Professional (NCP)

B－２．Nutanix Certified Advanced Professional (NCAP)

B－３．Nutanix Platform Expert (NPX)

B-1のNCPがすべての技術系資格の基礎資格になりました。
VMwareで言えばVCP-DCVのような位置づけですね。
この基礎資格の取得が、
C,Dカテゴリの資格の取得前提条件となっていますので、
まずはNCPの取得から始めましょう。
なお、経過期間措置として、旧NPP5を取得済みの方は、
NCP取得と同等として扱われ、同様に後続資格を
取得する権利はあるようです。

NCP,NCAPともオンラインで受講できますが、
受験中の状況を「カメラ」「マイク」「画面キャプチャ」で
監視されるような仕掛けに変更となり、
さながらテストセンターのような受験方式に変更されています。
その為、周囲に話声があったり、
人が通ったり、関係ないウインドウを開いていたりすると、
不合格になるような形に変わっています。

NPXはBoot Camp等を受けるところから
というものなのは相変わらずです。
これの取得は語学等の壁も高いので・・・もうこれ以上はふれません。

【C．SEカテゴリ】

Nutanixに関わるSEやアーキテクト向けの資格カテゴリです。

よりプリセールス向けの内容が濃くなった印象です。
受験前提に、NCP（もしくは現時点ではNPP5でもOK）の
取得が含まれています。

C－１．Nutanix Certified Systems Engineer (NCSE): Level 1

C－２．Nutanix Certified Systems Engineer (NCSE): Level 2

C－３．Nutanix Platform Expert (NPX)　※B-3に同じ

なお、Nutanixの販売パートナーは、
このNCSE Lv.1の取得が必須だったりしますので、

各パートナーは資格保有の人材を一定数揃える必要があります。

【D．Servicesカテゴリ】

このカテゴリはNutanixのデリバリーを行う上で、

より実践的な技術を問うものです。

D-1,D-2は資格というよりは、トレーニングに位置付けられます。

D－１．Nutanix Core Competency

D－２．Nutanix Consulting Partner Installation (NCPI) 

D－３．Nutanix Consulting Specialist

D-1はWebにてセルフペースで受講が可能です。

D-2,D-3は実際のハンズオンが伴います。

講師が英語圏の方なので、英語の授業と口頭テストを受ける必要があります。

３．その他（資格じゃないけど）

資格、ではないですが、

技術者本人を認定するものとして、次のようなものも存在しています。

基本的になりたいです、というものではなく、

ベンダー側からのノミネートされるものですので、

り取るというよりは、いただく称号と考えるべきです。

E－１．Nutanix Technology Champion

E－２．X-Men

今回の投稿は、以上です。

運用目線で見る #Nutanix のバージョン選びの注意点と以後のバージョンアップ

明けましておめでとうございます。
今年もゆるめに更新していきます。

今回もまた運用者目線シリーズです。
Nutanixは運用が非常に楽になるというメリットがありますが、
そのノウハウやTipsが日本国内では
まだあまり多くないのが実情です。
少しでもシェアすることで、
Nutanixを上手く扱える人が増えれば、
そしてファンが増えればよいと思い、
投稿しています。

今回はAOSのバージョン選びについて取り上げます。


１．AOSのバージョンの読み方と投入サイクル

本稿執筆時点では、最新が5.10.0.2です。
ざっくり言うと、「5」のところがメジャーバージョン、
「10」のところがマイナーバージョン、
それ以降が細かな修正パッチを含む
VMで言えばUPDATEのようなイメージですね。

AOSはクラウドライクな機能追加を目指しており、
現在は四半期ごとに新しいバージョンが投入されるようになりました。
基本的にはカレンダーイヤーの四半期ですので、
1～3月、4～6月、7～9月、10～12月に
1度ずつということになります。
直近の10～12月のリリースとして、
「5.10」がリリースされています。
この四半期リリースごとに、
メジャーかマイナーのいずれかの形で、
バージョンアップ版が投入されていきます。

次は1-3月期になりますので、
また直近新しい機能が投入されてくることになりますね。


２．運用者が押さえておきたいSTSとLTS

ソフトウェアで必ずつきものであり、
運用者が必ず把握しておかないといけないことは、
サポートサイクルです。

Nutanixでは、２種類のサポート期間が設定されています。
　・STS(Short Term Support)
　・LTS(Long Term Support)

STSの方は、
　フルサポート：3か月
　追加サポート：3か月
　　　　　　→計6か月
のサポート期間となります。

一方のLTSは、
　フルサポート：15か月
　追加サポート： 6か月
　　　　　　→計21か月

です。

最長で21か月のサポートになります。

このSTSかLTSかは、

メジャーバージョンに紐づいているわけではなく、

マイナーバージョンも含めたバージョンに付与されます。

比較的直近のバージョンで見てみると、

　5.5→LTS

　5.6→STS

　5.8→STS

　5.9→STS

　5.10→LTS

ということになります。

※5.7はNutanix社内の都合でリリースバージョンとして飛ばされています。

つまり、今回採用しようとしているバージョンが、

LTSなのかSTSなのかは都度確認するようにしましょう。

３．初期導入時にハマりがちなバージョン選択の罠

Nutanixの導入経験が浅いSIerや

利用者がやりがちなこととして、

バージョン番号と投入されている機能だけ見て、

投入するバージョンを選ぶ、ということがあります。

例えば

「ベンダーが売りにしている最新機能を使いたいが、

　ソフトウェアは最新バージョンだと怖いので、

　ひとつ前のマイナーバージョンを選ぼう、

　これなら目的の機能も搭載されている」

というような選び方です。

安易だ・・・と思われるかもしれませんが、

現場あるあるだったりします。

この選び方ですと、STSにあたる可能性もあり、

購入→SIerによる構築をやっている間に、

　・次のバージョンが出ました

　・構築作業にはバージョンアップ作業は見込んでません

　・顧客側もやったことがありません

　・そのバージョンを提案してきたのはSIerなので、

　　やるのが当たり前だ

というような、不毛な争いになりかねません。

採用時にはLTSとSTSのどちらのバージョンかを確認し、

導入計画やその後の運用計画まで含めて、

バージョンの選択を行うようにしましょう。

４．メンテナンスについて考える

前項までに、LTSやSTSのサポート期間について触れました。

誤解を恐れずに言えば、どんな環境であっても、

1年～1年半に1度は必ずバージョンアップを行う必要があります。

こう聞くと、Nutanixの運用は負荷が上がると考えてしまいがちです。

しかしながら、Nutanixでは、パッチのダウンロードや、

適用作業の自動化機能が搭載されており、

バージョンアップ作業を楽にする工夫がされています。

更に、ソフトウェアのバージョンアップと言えば

失敗のリスクが伴いますが、

Nutanixではヘルスチェックツールが標準で実装されており、

事前にこれを活用することで、

失敗するリスク要因を排除できます。

運用者に非常にやさしい作りです。

適用作業についての詳しくはこちらの記事もご覧ください。

加えて、短期間でのバージョンアップの対応は、

「サイバーセキュリティ」に対する対策としても効果を発揮します。

多くのシステムは何らかの形で外部と、

インターネットとつながっている時代です。

ソフトウェア脆弱性の放置をしてしまうと、

攻撃対策にかけた何億円ものお金を水の泡にしてしまいます。

AOSのバージョンアップ時には、

セキュリティ対策に関する修正も含まれています。

計画的なバージョンアップを実施することで、

これらの対応も合わせて行えるメリットがあります。

ですので、決してバージョンアップをネガティブにとらえず、

やらなけばならないことを実行する期限を

むしろ設定してもらっているような感じです。

ESXiのバージョンアップが導入以来されておらず、

脆弱性を放置しているケースは少なくないと思います。

特に導入時にUpdate Managerを入れていないケースは多いので、

バージョンアップは少々面倒な作業となります。

そこにきて、先日あったような、

インターネットにESXiが公開されてしまっていたようなことがあると

色々終わり・・・ですね。

サイバー攻撃を受けて情報漏洩した場合、

どうしても責任は運用をしている部隊に向けられがちです。

バージョンアップをしていなかったことが、

運用者の怠慢だと言われることは避けなければなりません。

AOSやAHVに変更することで、

バージョンアップ作業自体の負担を軽減しつつ

定期的なセキュリティ対応をさぼらない環境を作り、

自分たちの身を守るという考え方もぜひ持ってみてください。

今回の投稿は、以上です。

2019 Nutanix Technology Champions (NTC)をいただきました。

今回はアドベントカレンダーとか関係なく・・・。

昨日、2019 Nutanix Technology Champions (NTC)が発表され、
今回も無事いただくことができました。
ありがとうございます。精進しないとです。
今年で３回目、３年目のNTC生活となります。

少々外部発信活動が少ないかとも反省しながら、
今年はアドベントカレンダーに気合を入れて、
ボリュームあり気味の記事を書くなど、
気合を入れなおしています。

どちらか言えば元々ユーザとしての出会いから
始めてここまで来ました。
今後も超専門技術特化ではなく、
運用目線・実務目線を忘れることなく、
各所に情報をお届けしていきたいと思います。

と、今回の記事は報告のみですので、以上です。

運用目線で見る 大規模VDI向けの #Nutanix 設計

本記事は　Nutanix Advent Calendar 2018　#1 12月19日分の記事です。

今回はHCI、殊Nutanixには定番なVDIなお話です。
設計に関するちょっとした小ネタを紹介します。

１．VDIとHCIの相性の良さについてのおさらい

様々なところでVDIとHCIの相性の良さは語られているので、
ここでは簡単に紹介、となりますが、
次の理由でHCIが採用されています。

①段階的な拡張に対応できる
　VDIは特定部門から徐々に全社展開となるケースが多い。
　また、展開するうちに新たな要求事項が発生し、
　当初の計画通りでなければならない基盤では、
　余計な投資を招くリスクがある。

②IOPS性能の余力と拡張
　ユーザがどのような利用をするのかは予測ができない為、
　基本的にVDIをサイジングする場合は一般論からの
　推測でサイジングを行うケースが多い。
　集中型のストレージ装置を用意したケースでは、
　費用圧縮の観点から、推測値ギリギリでサイジングが行われ、
　致命的な性能不足に陥るリスクを、
　ユーザがその性能リスクを負う提案になりがちである。
　もしくは、余力はあるが、過剰コストの提案になる可能性がある。
　HCIではノードごとでI/O処理が行われ、
　その処理はノード内の仮想マシンだけに基本的に注力できる。
　その為、性能余力が十分に確保された状況を、
　余計な費用なしに実現できるメリットがある。

といったところで、よほど規模や計画が確定的でない限りは、
HCIにしておくことがベストな選択と言えるでしょう。


２．大規模VDI向けのNutanix設計
今回の本題です。
まずは基本的事項から。
VDIにおいてのNutanixの設計は
それほど特別に気を付けなければいけない
設計事項はありません。
そのままでも十分使ってもらえます。

ただ、ここでご紹介したいことは、
環境が大規模（数十ノードレベルの環境）になった時の話です。

基本的に、Nutanixには他の製品と違って、
クラスタ内の拡張レベルに制限はありません。
何十ノードを一つのクラスターとして、
大きなクラスターを構成してもらっても構いません。
ただし、少し考慮した設計をすることで、
運用のしやすさを向上することができます。

例えば、AOSのバージョンアップを考えると、
日本のお客様はエンドユーザさんに
「システム停止するので、使わないで」
と停止調整をするケース、多いのではないでしょうか。
AOSのバージョンアップも比較的高速なので、
休日の時間を使えば何とかなるのでは、
ということありますが、
もし「停止可能な時間がまちまち」だった場合は
どうしますか？
このようなケースでは、
年末年始やゴールデンウイーク、お盆など、
全社的な休みを狙って実施することになりますが、
情報システム部門の方は、貴重なお休みを
費やす結果となってしまいます。

これを回避する簡単な設計方法が、
サービス提供日程の違うNutanixクラスターを複数用意して、
それぞれのデスクトッププールも、
そのクラスタに合わせて所属させる、という設計です。
つまり利用傾向を揃える、ということですね。
分割の仕方は以下のイメージです。

このやり方をすると、
メンテナンス単位が各Nutanixクラスターに限定されるため、
実運用する上では停止調整をする範囲が、
かなり限定されます。
事業部ごとで同じような利用傾向を
予めまとめていますので、
停止調整の計画が非常に立てやすくなります。
＃ここれは例で事業部にまとめていますが、
＃職種などで傾向が付けばそれでもOKです。

また、サイズが小さくなるために、
１メンテナンスあたりの所要時間が短くなったり、
万が一の障害時も、影響範囲を限定することで、
全社的な業務が止まるリスクを回避できる、
といったメリットもあります。

これらのメリットから、
通常の休日や平日夜間を利用した
メンテナンスを実行しやすくなり、
かなり運用しやすい基盤となります。

ちなみにNutanixではノードの切り離しや
再参加がしやすいという特徴があります。
業務特性に変化があった場合は、
クラスター間でノードを融通することで、
調達したノードを無駄なく利用可能です。


今回は、VDIの設計について、
TIPS的な話を取り上げてみました。
VDIは止まると即業務影響という点では、
かなりミッションクリティカル度の高いインフラです。
こういった工夫も欠かさないことを、
ぜひおすすめしたいです。

今回は以上です。
明日は、沢山のNutanix関連記事を供給し続けている、
レノボ小宮さんの記事です！

#Nutanix Xi Frameを触ったことない人がFrameへの期待を語る何か

本記事は　Nutanix Xi Frame Advent Calendar 2018 12月13日分の記事です。

今回は、急遽参戦することになった、
Xi Frameに関する話題です。

投稿日前日にいきなり投稿することになったことと、
実はAirなFramerなため、
Frame解説しちゃうぜ的な何かはお届けできませんが、
ご容赦くださいませ。

ですので、Frameの説明聞いたり解説読んだりした
ユーザとしてこんなことが期待できそうかなという点を、
自分なりの視点で書き連ねてみようと思います。


１．働き方改革と情報システム部門の悩み
まずはXi Frame関係ないところから。

日本国内では働き方改革が盛り上がっており、
仕事の効率化のために出先でワークができるようにしたり、
そもそも在宅での働き方を認めようという流れが強くなっていますね。
それを裏付けように、総務省・経済産業省が連携して開催する
テレワークデイズの参加状況を見てみると、
第1回目の2017年は、約950団体・6.3万人
第2回目の2018年は、1,682団体、延べ約30.2万人

と順調に拡大していることが見て取れます。

政府が発表しているIT国家創造宣言でも
テレワークの目標比率が具体的に明記されており、
今後の東京オリンピックを見据えて、
ますます拡大するものと推察されます。

そんな社会背景において、
安全に仕事をできるような仕組みを提供する要求が
情報システム部門には下りてくるわけで、
その手段の一つがVDIですね。

VDIの導入自体はもはや一般化しているものの、
エンドユーザにとって悩みがないわけではありません。
例えば次のようなことが挙げられます。

①まとまった規模の導入が必要
②読めない需要の変動
③VDI基盤の運用の負担
④レスポンスとユーザからの問い合わせ
⑤冗長性の考慮をし過ぎた結果の、高コスト化

顧客の環境によって課題の方向性は様々ですが、
上に挙げたようなケースは
比較的あるのではないでしょうか。

全体的に何とかしようと考えると、
やはりわかりやすい解決策としては、
外部のサービス＝DaaSを活用できないか、
ということで、DaaSへの期待が高まります。


２．DaaSへの期待と現実

様々課題があるところを、
ある程度DaaSで解決できないかと
問い合わせをしてみた方も多いはずです。

確かにDaaSを採用することで、
・基盤のアーキテクチャを気にしなくてよい
・基盤運用からの解放
・足りなくなったら増強のリクエストをすれば、
　短期間で足してもらえ、SIは発生しない
・数台規模の小規模からも足せる
・専門家のヘルプが受けられる
・高速化のチューニングがしてあるので、
　レスポンスも良さそう
といった点の期待値もあるのではないでしょうか。

で、現実はといえば、
・まとまった規模での増設しかできなかった
・数台規模での増設ができない
・パフォーマンスがむしろ悪かったり、
　性能が安定しないケースがある
・運用のサービスレベルが悪く乗り換えたいが、
　サービスにロックインされてしまい、
　乗り換えできなくなるリスクがある。
・基盤の設置場所が遠く離れており、
　サーバ環境も考えるレスポンスの懸念がある
・１台単位の利用ができる場合、大規模になると
　むしろ高コストで利用できない
・GPUが使えない
というようなところで、
DaaSの採用を断念したケースもあるのではないでしょうか。

つまり、DaaSに期待を寄せつつも、
期待と現実のギャップから実際の採用に至ってこなかった
という事実はあるのではないでしょうか。


３．Xi Frameへの期待
（ここまでが長かったですが・・・・）
DaaSの現実を踏まえつつ、
もしかしたらそのうちのいくつかを解消してくれるかもしれない、
Xi Frameへの期待を書きたいなと思います。

①特定プラットフォームへのロックインリスク回避
単純なクラウド基盤でもそうですが、
特定のサービスだけに依存すると、
様々な面でのリスクを負う可能性があります。
その為、経営者としての観点で言えば、
リスクヘッジのために選択性を常に持つことが重要となります。

特に大手のサービスとなるほどロックインの仕様が強く、
選択性を阻害する仕掛けとなっています。
その点で、Xi Frameはプラットフォームの選択性を持っている為、
万が一の際にも他の選択をする余地があり、
リスクヘッジをする有力な手段ではないかと期待できます。


②小規模から大規模まで、シーンに応じた基盤の選択ができる
現時点ではAWSとAzureへの対応ということですが、
将来的にはNutanixのオンプレミス環境も
デプロイ対象として利用できるようになるようです。

つまり固定的な数はオンプレミス、
変動分はクラウドのリソースを一時的に、
というハイブリッドDaaSを構築できるようになります。
例えば安定した性能を発揮する必要があったり、
コスト面は抑えたい、変動の少ないものは
オンプレミス上に展開し、
プロジェクトなどによる一時的なデスクトップの調達など、
長期性がないと思われるものなどに、
クラウドのリソースを活用する、
といったやり方ができるわけで、
まさにいいとこどりです。


③サクサク動いてキレイなVDI
VDIと言えば、以前より如何に狭帯域で
利用できるかというところに主眼が置かれ、
それに適したプロトコルかどうか、
という観点で話がされてきました。

一方で、モバイル通信は4G全盛時代。
もうすぐ5Gになろうとしています。
下手な固定回線より速度が出るかもしれない
環境に変化してきました。
またユーザのすそ野も広がった結果、
パフォーマンスへの要求も厳しくなってきており、
それらが従来の方式で対応できるか、という話です。

Xi Frameのデモを以前見ましたが、
驚くほどスムーズに動いていました。
イベント会場のそれほど速くないであろう
インターネット回線を使い、
まるでローカルで使うかのような
Google Earthの滑らかさは驚愕のひとこと。

Xi FrameをDaaSと捉えるのではなく、
実は現在の事情に合った新しいVDI基盤の
ソフトウェアが出てきたと考えて、
普通にVDI製品としてその快適なユーザ環境を評価して、
選択肢に入れてもよいのではと感じました。


長くなってしましましたが、
３点ほど、Frameへの期待を書き連ねました。
まだ買収して間もない為、
Nutanix全体の戦略や仕掛けとどう統合されてくるのか、
どういった世界観を示してくれるのかは、
もう少し様子を見る必要があります。

冒頭には書きませんでしたが、
実は私、（株）ワーク・ライフバランス社の
認定ワーク・ライフバランスコンサルタントだったりしまして、
企業様の働き方改革のお手伝いを
させていただいたこともあります。

そんな日本の働き方改革を応援する立場としても、
Xi Frameの新たな力が、
日本のテレワークを支える新たな仕組みの一つとして、
次世代の可能性を示してくれることに期待し、
今回の投稿を締めくくろうと思います。

今回の投稿は以上です。

#Nutanix でソフトウェアライセンスを節約する方法

本記事は　Nutanix Advent Calendar 2018　#1 12月11日分の記事です。

今日もマスターNutanixな@shadowhatさんからバトンを引き継ぎまして、

Nutanixの中の人は書かないであろうテーマで

お届けして参ります。

今回は非常にセンシティブな話題を敢えて・・・。

さて、HCIもすっかり普及してきまして、
数年前はVDI、VDIという感じでしたが、
最近は通常の社内サーバ用の環境として
当然のように選択されるようになってきました。

それでお客様と話していてぶつかる壁が、
ソフトウェアのライセンス問題。
新しくも、古い問題で、仮想化が始まった頃から
ずっと取り上げられている問題です。

ちょっとセンシティブですが、
今回はこれを節約するアイディアについて、
取り上げてみます。


１．ライセンス問題をそもそもおさらい

そもそもソフトウェアのライセンス問題がなぜ起こるかと言えば、
課金方式に、「物理CPU数（コアやソケット）」を基にした
カウント方式がされている場合があるからですね。

通常物理サーバですと、
１CPUか２CPUが載っているケースが多いですが、
２CPU搭載サーバだけであれば、
２CPU分のライセンスでよかったわけです。

これが仮想化の登場で少し様子が変わりました。
複数台の物理サーバを束ねて、
一つのリソースプールとして仮想のサーバ稼働環境を
構築するケースが増えてきました。
また、技術の進歩により、
複数の物理サーバ間で仮想化されたサーバ
を自由に動かすことができるようになりました。

これでハードウェアの障害と
仮想化されたサーバが切り離され、
飛躍的な可用性の向上が図られたわけです。

これで解決であればよかったのですが、
この場合、複数の物理サーバが登場しますので、
実際複数の物理サーバでそのソフトウェアが
動作するという状況が生まれてきました。

ソフトウェア企業はこの場合に例えば、
「稼働する可能性のある物理サーバのCPUコア数分、
　ライセンスが必要なので購入してください」
というポリシーを出してきました。
これがライセンス問題の発端です。


２．ライセンス数の考え方のおさらい

例えば前述のように、
「稼働する可能性のある物理サーバのCPUコア数分、
　ライセンスが必要なので購入してください」
ということで、ポリシーが設定されていたとします。
物理的なサーバは３台、各２CPU数分搭載されています。

この場合には、３台＊２CPU＝６CPUが合計になりますので、
計６CPU数分のライセンスが必要になるわけです。
※ソフトウェアメーカーのポリシー次第ですので、
　必ずこうなるとは限りません

重要なことは、この考え方は仮想化していれば
共通的な考え方ですので、
何かしらの特例的なポリシー設定が
されていない限りはどんな仮想環境でも同じです。

時折、Nutanixではどういう考え方に
なるかと問われることがありますが、
基本的には工夫をしなければ全く同じであり、
有利になることも不利になることもないです。



３．なぜHCIの商談でライセンスの話題が出やすいのか

HCIにおいて、ライセンスの話題が出やすい理由は、
HCIの特性にあります。

まずは１つ目の理由。
通常、HCIを選択する理由として、
将来的な拡張の可能性に対して柔軟性を提供する
という考え方をメリットとして選択するケースは多くあります。
つまり、物理的なサーバを後から「増やす」ということです。

多くのケースでソフトウェアライセンスは一部のサーバにおいて、
初回の構築時には購入するものの、
後からの増設においては「忘れられがち」です。
このため増設するHCI製品の価格だけ見てしまいますが、
ソフト分も実は必要だっと後から気づき、
予定していなかったと感じて割高になった「気になる」わけです。

次に２つ目の理由です。
HCIの商談において、運用性が非常によいことも踏まえ、
この機に仮想環境を統合して運用も楽ちんだ！という
ケースが増えつつあります。
この場合、トータルの物理サーバ数は減っているのですが、
リソースプールは大きくなるので、
「稼働する可能性のある物理サーバ」の候補が増え、
結果的に購入しなければならないライセンス数が増える、という仕掛けです。

例を以下に挙げてみます。

　　【当初】
　　　・仮想環境１＝物理サーバ３台（各２CPUずつ）
　　　・仮想環境２＝物理サーバ３台（各２CPUずつ）＋CPUコア課金のソフトを６CPU分購入
　　　・仮想環境３＝物理サーバ３台（各２CPUずつ）

　　【統合化】
　　　・統合環境＝物理サーバ７台（各２CPUずつ）＋CPUコア課金のソフトを１４CPU分購入
　　　　→物理ホストは減らせたが、ソフトの費用は上がった

物理的には統合したことで、冗長な物理サーバを減らせたのですが、
逆にソフトの費用が増えるのがわかると思います。
ここがひっかかってしまい、話が進まないケースは少なくないものと思われます。

何度か書きますが、この事情は仮想化に紐づくものであり、
NutanixやHCI独特ではないことを気を付けてください。


４．ライセンスを節約する考え方

非常に単純な考え方としては、
プール分割があります。
稼働する可能性のある物理サーバ分のコスト、
という条件ですから、
先の例であれば、７台の物理サーバを
４台と３台と分割したプールとすれば、
稼働する可能性がある台数を絞れるという理屈です。

自由に動く＝DRSやHA機能と捉えれば、
そもそも自動で動く範囲であるリソースのプールを
分割してしまえば、稼働しないからOKという理屈です。
実際、これで回避可能なケースもあります。

しかし、残念ながら問題はそう簡単ではありません。

プール間の移動というものは、
ライブマイグレーション機能などを利用すれば、
幸か不幸か、簡単に実現できてしまいます。
つまり、プールの分割だけでは、稼働の可能性のある
ホストは減っていない！という認識で
判断されるケースもあるのです。
＃これは一例ですので必ずそういう判断されるとは限りません

また、今回のような構成を意図せず、
同じ状況になってしまうケースもあります。
例えばすでに仮想環境を構築していたとします。
別の機会で、別の用途の仮想化用の物理サーバを購入し、
たまたま初回に構築した環境のストレージ装置に、
新しく買った物理サーバを接続。
そちらはそちらの用途でプールを作成した、
なんて状況も結局は同じことなのです。

これらはソフトウェアメーカー側のポリシーの問題なので、
仮想化側、HCI側ではどうこう手出しができない問題です。
（屁理屈では？と思われるかもしれませんが・・・・）
必ずソフトウェアメーカーに
ポリシーを確認することをお勧めします。


５．結局、ソフトウェアライセンスは減らせないのか？

ここまで見てきた通り、
ソフトウェアメーカーのポリシーがあり、
統合の仮想基盤のようなケースでは、
負担が増えてしまうリスクがあることがわかりました。

では、ライセンスの節約はできないのか？
実は３つの手段があります。
うち２つは、Nutanixだからこそ選択できる手段です。


①Nutanix Volumes (旧Acroplis Block Service)の活用
これは紹介されているところもありますが、
ライセンスが発生するサーバを物理サーバに直接インストールし、
ストレージはNutanixの環境から提供しようというものです。

対象のサーバが単なる物理サーバですので、
ライセンスはそこしかかからないようになります。
わかりやすい手段ですが、ストレージの管理が
Nutanixに統合されるのみなので、
運用管理面のメリットが薄くなる欠点があります。

この手段は当然ながら、
Nutanixを利用する場合でのみ選択可能です。


②アプライアンスの活用
ライセンス問題が難しいなら、それに特化した、
専用のアプライアンスを用意してしまえ！というのが
こちらの手段です。
例えば某大手データベースの会社さんは、
データベースのアプライアンスを出しており、
それを活用することで、統合の仮想環境から
ライセンス問題を切り離すことが可能です。

専用のアプライアンスを活用することで、
デフォルトでチューニングされており、
性能向上する場合があります。
また、単なるサーバに入れる場合と比べ、
パッチ等の運用管理機能が最適化される場合もあり、
効率的になります。

正直、ライセンス問題のリスクを負うよりは、
この手法を選択するのが安全です。
ただし、ハードウェア管理は種類ができてしまうので、
その点の運用管理負担は残ります。
この手法はNutanix以外でも選択可能です。


③マルチハイパーバイザの活用
最後にご紹介するのが、
マルチハイパーバイザの活用です。
プール間の移動によるライセンスリスクがあるのは、
簡単に移動ができてしまうが故、です。
つまり、ハイパーバイザが異なれば、
簡単に移動ができないということになります。

Nutanixでは、クラスタを構成する際、
ESXiとAHVの混在というような構成をとることが可能です。
これを逆手に取ると、
例えばデータベースはESXiクラスタで、
それ以外はAHVクラスタでというような合わせ技が可能です。
＃ただし、最低４ノード構成にはしたい

ハイパーバイザまで構成を変えていれば、
流石に稼働の可能性のある先とは言いづらくなりますので、
ライセンス問題を回避できる可能性がぐっと高まります。
（ない断言しないのは、メーカー見解に左右されるため）


ということで、今回はライセンスの話を取り上げてみました。
Nutanixでは３つも選択肢が使える点が正直魅力的です。
うまく活用して、コスト削減してみましょう。


今回の記事は以上です。

明日はNutanixからVM、オラクルまで、
様々な技術に精通するgowatanaさんの記事です！

#Nutanix のデータ暗号化の話

本記事は　Nutanix Advent Calendar 2018　12月8日分の記事です。

Nutanix関連、で様々な技術的な記事がありますが、
暗号化に関する記事を見かけないので、
今回は取り上げようと思います。
なお、昨年2017年時点でも取り上げていますが、
改めて詳細に投稿するという感じです。


１．そもそもデータの暗号化をする意味は？

ずばり、盗難や交換後のディスクからの
情報漏洩リスクを排除するという、
物理的な情報漏洩対策です。

必ず必要？と言われると
最早ユーザさんの考え方です。
また、従来のストレージ製品でも
考え方は全く同じであり、
Nutanixの特有のお話ではないです。

その一方で、セキュリティ関連の
認証取得の観点で暗号化の機能の利用が
必須となる場合があります。
例えば個人情報の取り扱いや、
クレジットカードといった金融情報の
取り扱いに関わる認証を取得する場合です。

ワールドワイドでは、高セキュリティを必要とする場合、
特に金融系の案件ではかなりの確率で利用されているようです。

国内では、実際採用実績がほとんどなく、
著者が所属する会社でしか構築経験がないような状況です。
もっと広がってほしいという意図から、
本記事を執筆しています。


なお、今回の記事の背景となる利用ケースでは、
クレジットカード向けのセキュリティ基準である、
「PCI DSS」という認証を取得する為に、
Nutanixのデータ暗号化機能を活用しています。



２．Nutanixのデータ暗号化２方式

Nutanixではデータの暗号化において、
大きく２つの手法があります。
　①暗号化機能付きのディスクを利用したハードウェア方式
　②AOSの機能によるソフトウェア方式

①はAOS4.xの頃から利用可能な機能でした。
　確実性は高いのですが、
　自己暗号化機能付きのディスクを選択する必要があるので、
　後から急にやりたいと言ってもダメなやつです。

②については5.xから実装されてきており、
　AOSの機能でソフトウェア的に暗号化を実装します。
　こちらはハードウェアに頼らない為、
　当初のお買い物で暗号化ディスクを選択していなくとも、
　後から挑戦できるものです。


３．暗号化における鍵管理

暗号化をするための２方式を解説しましたが、
もう一つ理解する必要があるのが、
「鍵管理の方式」です。

データ暗号化をする場合、
外に暗号化を解除する持つサーバがおり、
そのサーバと会話することで、
データが復号化され、正常にアクセスできるようになります。

この鍵管理の仕組みが、
AOS5.5まではAOSには実装されておらず、
サードパーティの製品に頼る必要がありました。
※サードパーティについての説明は次項目にて。

つまり、Nutanix製品だけで完結せず、
構築を行う会社側が取り扱えないケースがあり、
残念ながら提案に組み込まれていない
傾向にあるのかもしれません。

一方で、AOS5.8(だったはず)からは鍵管理機能が
実装されてきましたので、
Nutanixの中で完結して管理ができるようになりましたので、
利用のハードルはぐっと下がりましたね。



４．データ暗号化に利用するサードパーティ製品

最新のAOS5.10でサポートされるサードパーティの
鍵管理製品を確認(2018/12/8時点)すると、

　IBM Security Key Lifecycle Manager 
　SafeNet KeySecure　/　Virtual KeySecure
　Vormetric　Data Security Manager
　
が対応しているとのこと。
以前に確認したときも同じだったので、
まあ顔ぶれは変わらなさそうですね。

国内実績（というか弊社実績）はSafenetさんの
製品での実績となります。
これは問題なく使えてます。
製品によっては、仮想アプライアンスの
選択肢もありますので、
うまく選択して使ってください。

ただし、10万円とかそんな安価なものではないので、
調達を検討している時は予めしっかり価格を確認してください。

また、鍵管理サーバの障害時、
AOSのクラスターを停止しない限りは
アクセス継続できますが、
何らか止めた瞬間からアクセスできなくなる
リスクがあります。
鍵管理サーバは必ず冗長性の考慮や
鍵情報の保管などのリスク対策を行ってください。

ここまで書くと、鍵管理製品入れる必要ないのでは？
という疑問が沸くと思いますが、
次のようなケースには鍵管理サーバをサードパーティで
採用する必要があります。

　①セキュリティ認証の要件で、同一筐体内での
　　鍵管理が認められていない。
　　また鍵の定期的なライフサイクルが定められている。
　　（PCI DSSではこのケースに該当します）

　②Nutanixに限らず、クラウドや複数の環境の
　　暗号鍵管理が必要である。

提案のケースによっては、サードパーティも
選択肢に加えておきたいところです。


５．データ暗号化以外の物理的な対策は？

データの暗号化機能を選択しないケースで
物理的な情報漏洩で気になるのは、
HW交換で交換したDISKの行方ですよね。
特段外部に漏洩したという話は聞きませんが、
気になる方もいるのではないでしょうか。

この場合は、保守のオプションとして、
ディスク返却不要のオプションを
有償で付与できます。
これにより、DISK交換時、
交換前のDISKは手元に残るようになるので、
あとは自社の所定のルールに基づいて処分が可能です。

自分が関わる金融系の案件では、
最低限でもこのオプションを選択しており、
選択しない案件は０です。
このあたりは、利用者のポリシー次第ですので、
要件に合わせて対応してくださいませ。


今回は、本番業務を意識した、
セキュリティの話をお届けしました。
海外の金融×Nutanix案件では普通に使われていることなので、
押さえておきたい内容です。

明日は、dozonotさんのNutanix CEの話題ということなので、
楽しみです。


今回の記事は以上です。