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の話題ということなので、
楽しみです。


今回の記事は以上です。

実運用視点でみる #Nutanix クラスタ作業時の考慮事項

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

昨日は、@shadowhatさんのNutanixに関する噂の検証記事でしたね。
https://infraapp.blogspot.com/2018/12/nutanix.html
記事の通り、正しくない情報をつかまないように、
注意深く情報を入手してください。


さてさて、Nutanixの機能的な解説については
諸先輩方にお任せするとして、
本日の記事ではちょっと珍しい、
実運用現場での運用視点の話題をお届けします。

12/1に投稿された、
@shadowhatさんの記事と合わせてお読みくださいませ。
https://infraapp.blogspot.com/2018/12/aoshomenutanix.html

本題です。
ハイパーコンバージドインフラと言えば、
スケールアウトが売りですよね。
複数台のノードが存在し、
そのノードを追加したり外したりすることで、
柔軟なインフラを実現するなど、
ソフトウェアの技術でノード間が高度に連携し、
全体で統一された機能を実現しています。

特にNutanixでは、「1-Click」コンセプトの下、
Prismのインターフェースを介することで、
非常に簡単にノードの追加削除、
ソフトウェアのアップデートを実行可能です。

この特徴が製品説明機会では、

「1-Clickで実行できます！」
「パスタを作ってる間にアップデートできたぜ！」

と話されていますが、
じゃあ実運用の際にはどうなの？という話があると思います。

答えは、「もっと慎重にやっています」です。

別に製品説明の誇大広告で、
触れ込みが間違っているということではなく、
やはり日本の現場においては、
確実性を重視する傾向にあります。

ではどうしているのかですが、
Nutanixには「NCC」と呼ばれる
クラスタのヘルスチェックツールがあり、
全体の正常性確認をすることが可能です。

図１　NCCの実行画面

※上図では実際にNCCを実行中のため、操作ボタンがグレーアウトしています。


ですので、これを実行してから、
各種クラスタへの作業を行うというのが、まずは基本です。
更に万全を期すためにご紹介したいのが、
次のやり方です。

【作業手順】
①構築完了時点で、正常な状態のNCCデータを取得
②作業実施前にNCCを実行
③①と②の差分を取り、
　　新たにNG項目になっている箇所がないか確認する。
④問題なければクラスタに関わる作業を実行
⑤作業が完了したらNCCを実行
⑥③での確認結果と⑤を突き合わせて、
　　新たにNGになった項目がないか確認する
⑦⑤のデータに不備がなければ
　　現在のクラスタの最新の状況として保管し、
　　次回のクラスタ作業用時の③インプットとする

この①～⑦を実行することで、
クラスタが潜在的に抱えていた課題に起因した
作業の失敗を回避することが可能です。

図２　NCCの結果画面サンプル

※環境における設定によって、構築時点からすべてPassでないケースがあります。
　構築時点の情報を保持しておき、突き合わせをして問題をあぶりだします。
※図右上のリンクからTXTでDLできるので、差分チェックができます。



また、このサイクルは万全を期す、
クリティカルなインフラで使われる場合では、
②～③の作業を作業実施前に複数回実施し、
作業に備えるということも行われています。
作業の流れは次の通りです。

【更に万全を期す場合の作業手順（例）】
(1)１か月前に実施。
　　作業スケジュール自体をたててよいかの確認。
　　この時点で大きな課題がないかの確認と、
　　細かな課題への対処に着手。

(2)２週間前に実施。
　　大きな変化が起きていないかの確認。
　　潜在的に何かを抱えていないかは
　　この段階でクリアされる。

(3)前日に実施。
　　予定通り実行する最終確認。
　　ここで問題があれば、作業は中止し、課題対処に移る。

(4)作業の実施。
　　作業後は⑤～の作業と同様。

こちらの手順はかなり入念に実施していますが、
必ずしもこれが必要だとか、
こうしなければならないというわけではありません。
あくまで作業におけるリスク排除の
一つの手法ということでご紹介させてもらっています。

なお、こう言ったチェックは
Nutanixだけの特別なことではなく、
考え方はvSANなど他のHCIでも同様です。
品質の高い運用を実施する場合には、参考にしてみてください。

今回の投稿は以上です。


明日はWataru Unnoさんの記事です。

Nutanix Beam を触ってみた～その２ #Nutanix #NutanixNTC

前回の投稿はこちら↓
http://presales-hiro.blogspot.com/2018/06/nutanix-beam-nutanix-nutanixntc.html


前回は、Beamにログオンできるようにするところまで到達できました。
本当はAzureアカウントまで追加したかったのですが、
エンタープライズな契約じゃないとダメと怒られたので、
アカウント連携は断念。

さて、今回は気を取り直して、
AWSのアカウントで登録しようと思います。

AWSアカウントはせっかくなので、
クーポン付きのタイミングで作成しておきたかったですが、
トライ時点では残念ながらキャンペーンやってなかったので、
泣く泣く普通に作りました。

ということで、レッツトライ。
なお、AWSのアカウント作成はここでは割愛しますが、
チュートリアル通りに作成したこと、
個人用途で作成したことは書き添えておきます。


Beamへのログインは以下のURLから。
https://beam.nutanix.com/login

アカウント連携してないと、アカウント連携するようにと催促されますので、
どこからやればいいんだろうとかは特に悩まなくて済むかと思います。
設定対象は、コストの情報に関するものです。

今回はAWSを選択してみます。
アカウント追加、最初の画面で、以下の選択肢が。
言語的な障害と個人的な知識力の問題で断念したため
ここの選択の違いは追々理解することにして、
今回は上の選択肢で進むことにします。

次へ進むと、早速AWSアカウントに関する
情報を入力するように促されます。
「その情報はどこを見ればわかるのか？」となりがちですが、
親切なBeam、画像付きで解説があります。
画像を見ながらAWSのアカウントを開きながら操作を進めます。

なお、１点アドバイスはBeamの画面とAWS画面は
マルチウインドウで開いておくこと。
また、AWSの操作画面のリンクがありますが、
クリックして開かず、リンクをコピーして別ウインドウの方で
開くことをおススメします。
そうしない場合、このウイザード画面を何度か
はじめからやり直す、というボードゲームのスタートに戻る画面のような
悲しい気分を味わうことになります。

さて、ガイドでは、請求ダッシュボードからレポートを作成するよう指示されています。

請求情報のレポートはまだ未作成のため、作成に行きましょう。
AWSの管理コンソールの方で、請求ダッシュボードの画面を開きます。

開いた画面の左のメニューからレポートを選択。
まだレポートを作成したことがないので、
画面右側には「レポートの作成」ボタンだけが表示されています。
では、「レポートの作成」を押して、
レポートの作成に移りましょう。

作成画面では、最初にレポート名の入力が求められます。
 レポート名は後々使いますので、控えておきつつ入力しましょう。

あとのこの時に「リソースID」にチェックを入れることもお忘れなく。
デフォルトでは入っていません。

さて、次の画面に進むと、S3のバケットを登録するように指示されます。
アカウントは作りたてですので、勿論、バケットなんか作ってません。
まずはバケットの作成の方を先にやることにします。
（下の画像はS3バケット作成後、に入力した画面です。）

バケットはAWSのサービス一覧から選択して以下の画面に行きます。
下のようにバケットを追加した状態を作りたいので、
バケットの追加を押します。

作成は指示通りに進みます。

ウイザード通りに進みます。

これで完成！レポート作成の画面に戻ってバケット名を入力してみると、
なんとエラー！
操作通りに設定したのになぜ？と思ったら、
ポリシーを投入し忘れていました。
下の画面に書いてある、サンプルポリシーです。

クリックすると下の図のような画面が出てきますので、
このポリシーをコピーします。

で、S3の設定画面のポリシー設定でこれを入力すると、
レポート作成機能側からアクセスできるようになるので、
先の画面でエラーが出なくなります。

次へ進むと、確認画面。このまま進みます。

完了すれば、レポートは無事作成完了です。

ここまで作り終えたら、Beamの画面に戻って、
レポートとS3バケットの情報を入力します。

そのまま進んでいきます。

今度はIAMのところでポリシーの設定をするように
指示が記載されています。

AWSのサービス一覧の方に戻って、
IAMの設定に進みます。

初めて入ったので、こんな感じ。
セキュリティ設定は色々すべきと思いますが、
ここの掲載上では割愛します。
設定は詳しいAWSブログを頼ってください。

次はポリシーの作成に進みます。

作成に進むと以下のように出てきますので、JSONを選択。

JSONファイルを直接入力する仕様になってます。
ここで入力すべき情報は、先のBeamのウイザード画面に掲載されているので、
それを引用して入力します。
一番末尾に入れることにしました。

ちなみに、コピーして貼り付けるだけだと、
インデントがついていない状態で貼り付けされるので、
非常に気持ちが悪い状態になります。
しかし、保存ボタンを押すと勝手にインデントつけてくれるようになっているので、
心配せずにそのまま保存します。

なお、この時にカンマなどの入力漏れなどには、ご注意を
Beamからコピーしてくるコードには誤りがないので、
エラーが出たら、自分の入力に問題があることを疑ってください。
これでポリシーの設定は完了です。

お次はロールの設定です。
ポリシーのすぐ上のメニューから設定に行けます。
ロールの作成に進みましょう。

ID情報を入れるように求められますが、
ここはBeamのウイザード画面の方に
情報の指定があるので、そちらを参照して入力します。

あとは、ウイザード通り進むだけ。
完了したら、Beamの方に戻って、こちらもウイザードを進めます。

最後はS3のバケットポリシー追加です。

S3の画面に戻り、ポリシーの設定に進みます。
バケットポリシー画面でBeamの方から取得したポリシーを
適用していきます。

これを投入すれば、設定完了。
Beamの方に戻り、ウイザードを完了させます。

なお、入力直後は、以下のように情報が何も表示されていないです。
これは、定期的に情報を引っ張ってくるタイミングまでは
待ちなさい、ということでしょうか。

とりあえず今回わかったことは以下の通りです。
・AWSのアカウント自体の情報入力はない
・請求レポートの情報を引っ張ってくる形で吸い上げる
・S3バケットを介して実現している


次回は情報がどんな感じで引っ張ってきているかを
参照してみたいと思います。
なお、無料枠があるので、残念な結果になることも想像されますが・・・。


では、今回は以上です。

Nutanix Beam を触ってみた～その１ #Nutanix #NutanixNTC

毎度久しぶりの投稿です。

今回は、Nutanix　Beamについてちょっと触ってみたので、

その感想などなど。

Nutanix Beamとは？

５月にニューオーリンズで開催された、

.NEXT conference で発表されたNutanixさんの新製品です。

Nutanixさんとしては、始めてのSaaS形態での提供ですね。

先日買収が発表された、Minjar社が提供していたサービスを

元にしているものです。

その為、今回Conferenceで発表された時点で、既にGAされています。

AWSやAzureから課金の情報やセキュリティの

設定情報を引っ張ってきて、

一元管理できるような仕掛けになっています。

例えば、どこのクラウド、リージョン、サービスで

いくらくらい使っているのか、

すぐにわかるような仕掛けになってます。

またセキュリティ面は、ポリシー設定が

甘い箇所の情報を拾って、

ポリシー順守しているかをGUIで見せてくれる、

というものです。

マルチクラウド時代には、便利なマネジメントツールです。

実際、以前からAWSのマーケットプレイスでは

提供されており、マネジメント製品として

最も評価が高いサービスの一つだったようです。

これは期待大。

早速触ってみた

兎にも角にも触ってみよう、ということでレッツトライ。

今回の記事では、ログインしてダッシュボードが見られるところを

ゴールとしてみます。

今回はトライアルを申し込むところからスタート。

まずは以下にアクセスします。

https://www.nutanix.com/products/beam/

と、ここで早速注意。

日本語サイトの方にもBeamのリンクがあるのですが、

本記事執筆時点ではリンクが正しくないようで、

ページが見つかりませんと出ます。（2018.06.02時点）

なので、上記のUSサイトから進みましょう。

トライアルの申し込みボタンがあるので、

そこをクリック。

トライアル申し込みのため、名前や会社名、

メールアドレス入力欄が出てくるので入力。

ここで、試しにフリーメールのアドレス入れてみたら、
見事に先に進めない。
そこらへんはチェックが入る模様です。
ということで、自分は一旦社用アドレスにて対応。


このあと、社用のアドレス宛にアクティベーションの
通知が来ていました。
URLをクリックすれば、アクティベーションが完了し、
そのままログインされます。

次からのログインは以下のURLから。
https://beam.nutanix.com/login

ログイン画面は以下の画面です。
Googleのアカウントでも連携できるんですね。
では早速ログインをば。

ログインをすると最初に聞かれるのが、
AWSかAzureのアカウント。
そもそもマルチクラウドの情報を引っ張ってきて、
一元的に見せてくれるのが売りなので、
分析対象の情報がないではだめですよね、そりゃ。

自分がAzureのアカウントしかもっていないので、
今回はAzureをセレクト。

で、まずはアカウント情報を入れて、


次にそれぞれ引っ張ってくる情報の
細かな設定画面に進みます。
 とりあえずコストの方を引っ張ってみましょうということで、
コストをクリックしてみます。

で、進むと、「Enrollment Number」なるものを聞かれます。
そんな番号どこで見るのか知らんぜよと思ったら、
「How do I・・・・」なんて書いてあるので、クリックしてみると

見かたが表示された。
なんて親切なんだ！
しかも見に行く先は「here」でリンクまである。
ので、クリックしたんですが・・・・

今回は自分のアカウントの問題のようで、
そんなものはないぜ！ってazureさんに怒られた・・・。

この問題はまた別のタイミングで解決するとしよう。


ありがたいことに、トライアルアカウントでは、
デモデータを使用して表示感を確認することができます。
デモデータで表示したところがこれ↓

TOP画面がイキナリこのグラフのダッシュボードになってます。
非常にグラフィカルでわかりやすい！

各グラフの右上の方をクリックすると、グラフの表示形式が切替られます。
見たい方で見られる親切設計。

ということで、今回はここまで。
次回は、どんな情報が見られるのかについて書きたいと思います。

今回はここまで。

#Nutanix のNear Syncについての気づき

また久しぶりの投稿です。

Nutanixのアーキテクチャに関しての

気づきを兼ねて投稿です。


AOS5.5から、Near Syncなる機能が付きました。

これは従来からあるクラスター間でのデータレプリケーションの機能ですが、

実行間隔のパラメータが60分より短くできないものでした。

日次でのバックアップがあればよいというようなケースでは

これでも十分だとは思いますが、

やはりせっかくスナップショットベースでここまでのことが

できるようになったのだから、

少しでも短い間隔で取得し、

RPOを改善したいと思うのは常かと思います。


で、Near Syncというものが出てきたのですが、

どうにも従来のAsyncと違うように見受けられたので、

Nutanix Bibleをひも解いてみました。

http://nutanixbible.com/#anchor-nearsync-93

すると、やはり正解。

従来のAsyncとは異なる実装で、

新しくMesosを使った実装に変更されているようです。

従来と実装が違うので、設定も違うのかと思いきや、

設定は同じでした。

で、いざやってみようと思ったら、

このクラスタではサポートされてないと警告メッセージが。

どうやらSSDが1.2TB以上でないと動かせないようです。

まだ意外とシビア。

また、全体で40TB以上のストレージ容量があるケースもダメですよとのこと。

ここら辺は今後の実装改善に期待したいところ。


今回は以上です。

X-Menとして、NutanixのAPAC勉強会に参加してきました。

ご縁がありまして、

Nutanix（ニュータニックス）さんにご招待をいただき、

APACのSE勉強会＠海外に参加してきました。

ご招待いただいて、ありがとうございます。


実は参加が２回目。

今回は社員の方（Nutants)と一緒の場に、

パートナーSE（X-Men)が参加させていただくという形式でした。

X-Menはディストリビューターや主要パートナーのSEの中で

インビテーションをいただいた方が対象です。

日本からのX-Menは自分を含めて５名の参加でした。


よく海外で新サービスの発表を行ったりする

大きなイベントがありますが、

今回のイベントはそういった類ではありません。

社員の方（Nutants)向けのテクニカルトレーニングに、

パートナーSE（X-Men)も参加させてもらう、

という機会となります。

ほぼ社内会議に参加させてもらっているイメージですね。

日本の勉強会でよくある座学中心の機会をイメージしていましたが、

このイメージは誤っていました。

確かに座学の時間もありましたが、一部であり、

メインは与えられたお題を元に、チームでデモ環境の実装を

行っていくというもの。

ホテルの会議室に一日缶詰になって、

実装を行っていきました。

（内容の細かい部分は触れられませんが）

非常に面白かったことは、デモの実装の中に、

HCI的なことは殆ど触れられなかったこと。

もちろんベースとしては利用しているのですが、

あくまでアプリケーションをどうやって効率的に

提供していくかを中心とした内容でした。

自分にとっては初めて触るツールばかりで

四苦八苦していましたが、

社員の方（Nutants)は流石エースSEさんばかりで、

どんどんと課題をこなしていき、

実力の差を痛感しました。。。。


10時間近い移動時間と現地での缶詰で寝不足がつらかったですが、

非常に良い経験となりました。

また新しい気づきも２つほどありました。

一つは、自社が提供している製品やサービスについて、

SEが定期的に実践トレーニングを行うことは、

増えていく自社の製品やサービスを理解する上では

不可欠であること。

もう一つはこういう機会にパートナーも巻き込んでいくことで、

コミュニティを広げていくことができるということです。

ある意味同じ釜の飯を食った同士ですので、

一緒に頑張ろう、となる雰囲気づくりにもなるわけですね。


参加の機会を提供してくださったNutanixさん、ありがとうございました。


今回は以上です。

SimplivityやvSANは2Node構成が可能なのか

HCIを検討する人も多いかと思いますが、

それほど大きなリソース環境は必要ないので、

最小構成を取りたいと思っている方もいらっしゃるのではと思います。

ある意味最小構成から始めて、よければ段階的に大きくしていく

ということはHCIの有効的なシナリオです。

で、最小構成は？とベンダーさんにリクエストしてみると、

Nutanix：３ノード～

Simplivity：２ノード～

vSAN：２ノード～

と回答が返ってくることでしょう。

これはこれで正しい回答なのですが、

よくよく確認してみないとこんなはずではなかった

となるので、注意が必要です。


まずSimplivityですが、

確かにSimplivityのリソースノードとしては、

最小構成2Nodeなのですが、

Arbiterと呼ばれるサービス監視に使われるノードが存在し、

これは物理的に別サーバである条件がある為、

結果として物理サーバは３台必要となります。

Arbiterは他のノードのように仮想化する

わけではないので安いサーバ構成をとることはできますが、

物理的には存在しますので、

物理的なサーバが２台です、というと実は嘘になります。


次にvSANに目を向けてみると、

ベンダーさんが出している構成で、

確かに２ノードのものがありますが、

よくよくVMを見てみるとこちらも

Witness仮想マシンというものが存在していまして、

サービスの正常稼働の為に必ず稼働させる必要があります。

これはネットワーク的に障害が起こった

スプリットブレインの状態で、

どのノードが正常か判断する第3者が必要であるため、

という存在なのですが、

同じノードの中に入れていいのかは疑問を投げかけたくなる

最小構成案です・・・これサポート対象なのだろうか・・・？


ということで、これら２つの製品の”最小構成２ノード”は

額面通りに受け取ってよいのかというと、

そうではないことがお分かりいただけたかと思います。


そもそも最小構成にする意図は、

予算的なものであったりするかと思いますが、

価格面では実際箱の数だけで決まるものではないところもあるので、

ちゃんと比較してみればと思います。


最後に、比較の際ですが、

価格以外にそれぞれの長所短所の情報をしっかり収集してみてください。

買ってからこんなはずではとならないように・・・。

某MQ的なレポートにおけるvSANの記載について気になった

HCI盛り上がってて、vSANベースにしようか、

Nutanix買おうかなんて悩んでる方もそれなりにいるかと思いますが・・・・

〇ートナーさんが出している

マジックなんちゃらの2018年版-HCI特集を見ていたら、

なかなかvSANに関して、興味深い記載が・・・・。

転用するとアレなのでざっくり言いますと、

いくつかのお客さんでパフォーマンスに難があると報告されている

という記載がありました。

このレポートではいくつかのと書いているので、

当然特定の稀な環境と言い切れないような気もする。

vSANお手軽だし、手を出したいけど、

パフォーマンスに難があるケースがあると

公言されるとちょっと怖い。

気になる方はレポートを読んでみてくださいませ。

ではでは。

NTCを2018年も継続

年明けて立て込んでおり、

こちらの更新もまた滞っていましたが・・・

2018年もNutanix Technology Champion(以下、NTC)を継続させてもらいました。

感謝感謝です。

今年は日本人での受賞者の方が１名増えて、現在５名ですね。


こちらは試験を受けてとれる技術資格ではなくて、

エントリーしてNutanixさんに認めてもらう、

個人向けのアワードになります。

もっともっと盛り上がっていくといいなと思います。


今年は、いよいよCalmも本格的になりはじめ、

Nutanixもまた１フェーズ次に進むのではと思います。

この１年どうなっていくのか、

わくわくです。


今回はライトな投稿ですが、

次回は久しぶりに競合比較などしてもよいかなと思っています。

この辺で。