Nutanix Guest Toolsに関する話

今日は細かい話です。

Nutanixでは、AHVをハイパーバイザで使う時に、

仮想マシンにはNutanix Guest Toolsを入れます。

VMware Toolsと同じ感じですね。

こいつが、AOS5.ｘと4.xで大きな違いがあることを

ご存知でしょうか？

実は4.x系ではJREの導入が必要でした。

5.x系では不要になりました。

業務系サーバではセキュリティ観点でも

不用意にソフトウェア追加したくなかったので、

4.x系の頃はちょっとAHV提案しにくいと思ってましたが、これで安心です。

いよいよAHVもTurbo Modeとか、

DRS的な機能とか揃ってきて、

満を持して、という感じで整ってきました。

いよいよ活用のフェーズですかね。


今回は以上です。

ニュータニックスのアーキテクチャはここで勉強するべし #Nutanix

今回は短文投稿です。

ニュータニックスのソフトウェアは実際、

多くのオープンソースソフトウェアを組み合わせて構成されています。

一つ一つは既成品の組み合わせですが、

それらを上手くつなぎあわせることで、

新しい世界観を作っています。

じゃあ何かどのように組み合わされて仕掛けが提供されているのでしょうか？

アーキテクチャを学びたい方は、以下にアクセスしてみてください。

http://nutanixbible.com/

どのような考え方で構成され、分散や重複排除、

レプリケーションなどがどう実現されているか、

仕組みを学ぶことができます。

まるでオープンソースだとも言えるような、

アーキテクチャの公開っぷり。

仕組みを公開までしているのは、

その根底にある世界観までは真似できないという自信の表れでしょうか。

量が多いので、挫折する方が多いですが（笑）

ご興味のある方はぜひ。

自分も挙動の基本はここで確認するようにしています。

もっとライトに学びたい方は、「神殿本（俗称）」と呼ばれる、

ソフトバンクコマース＆サービス社のSEさん達が書いた、

日本語の本をお読みいただくと良いと思います。

私と同じX-Men（Nutanixに関してのトップエンジニア）の方が

執筆の中心で書かれているので、

しっかりとした内容になっていますので安心です。

今回は、かなりあっさりですが、以上です。

ストレージとサービスパスは分けてデザインすべきか？

先日、X tour in Osakaというニュータニックスジャパンさん主催のイベント会場でのこと。

あるNutanixを検討されているユーザさんから、

次のようなご質問を頂きました。

「ストレージ通信とサービス通信は分けようと思っているのですが、

　やはりわけるべきでしょうか？」

この疑問は多くあります。

この方は、社内でVDI用途としてNutanixを検討されているとのこと。

考え方や気にされている背景も色々と伺いました。

こちらからお伝えしたこととして、

最終的には好みやデザインの考え方次第ですが、

容量的な観点では、パスを10GbEで構成するのであれば、

特に分けることは必須ではないことをお伝えしました。

実際、ストレージパスで、ノード間のデータ配置トラフィックが

非常に多いのでは？という懸念をされる方がいます。

例えばvMotionした時、

仮想マシンのデータローカリティを維持する為に、

一気にデータが移動してしまうと、ストレージパスに

多大な負荷がかかってしまうのではないか？と。

まずvMotionした時に一気にデータが流れるかという方を考えると、

答えはNOです。

ローカリティは維持しようとしますが、

すべてのデータを一斉に引っ越しするのではなく、

順次ローカリティを実現するように移っていきます。

ですので、引っ越ししたからと言って、

高い負荷がかかるようなアクションはしないようになっています。

あと、そもそも論も考えると、

vMotionをする機会は、かなりレアケースだと思います。

何かメンテナンスをするか、DRSをアグレッシブにするか。

DRSも有効化しただけでは、

よほどのことがないと、仮想マシンの移動はしないです。

VDIであっても、アグレッシブまでやるのは、

あまりお勧めではないです。（というか必要性がないかと）

さて、話は戻ってパスをわける話です。

実際、VDIのサービストラフィックってどの程度なのでしょうか？

１デスクトップ、画面転送が1Mbpsも出れば贅沢な方です。

一般的に１ホストは100VDにするのが、

運用面・負荷面等考えると現実的な数なので、

（これ以上は経験からおススメしません）

100Mbpsですね。

あとは外部のシステムでの通信が主体ですが、

現実的に１Gbps以上使うケースは何か動画とか

大容量ファイル転送しない限り不要でしょう。

さて、ストレージの通信ですが、

こっちは使い方次第で、平均がどうとか言えないので、

計算は割愛して、実際テストしてどうだったか、

ということを考えてみます。

LoginVSIというソフトを使い、

かなり過負荷をかけるシナリオをトライしました。

実際の利用環境を疑似的に再現するというテストです。

対象は500VD、シナリオデータが置かれるファイルサーバは、

スイッチ介した、別のクラスター上のWindowsサーバです。

この時、サービス・ストレージ双方の通信合計を見た時に、

最もバーストした時で7Gbpsまででした。

しかも１回だけしか測定されず。

つまり、テスト結果からも、10Gbpsのパスであれば、

ストレージとサービスパスは

帯域面で見た時は分けなくともひっ迫の心配はないようです。

このテストを行った環境は過去３年ほど本番で安定稼働していますが、

帯域不足に出会うこともなく、問題なく動き続けています。

事実ベースではありますが、

10Gbpsのパスは特に分けなくても良さそうだということが

お分かりいただけたでしょうか。

なお、モデルによって、例えばNX-1065とかだと、

1Gbpsで構成することもサポートされるモデルもあります。

この場合は流石に帯域不足になる可能性があるので、

パスを分けて構成することをおススメします。

ここまで書きましたが、

最終的には設計ポリシーなどあると思いますので、

そのあたりも加味して、自社でご判断くださいませ。 

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

【要チェック！】HCI選び、本当にそれでいいの？！

あちこちの案件で増えてきたハイパーコンバージドインフラ（以下、HCI）の採用案件。

主要メーカー各社ともHCI製品を展開し、

ますます盛り上がりを見せています。

盛り上がりと選択肢多様化の一方で、

実際は玉石混合なのが今の市場の状況。

では、どういう観点で製品を選ぶべきなのか、

悩んでいる方も多いのではないでしょうか。

今回は、HCIは使おうと思ったものの、

選びきれない方に向けて、

４つのポイントでご紹介します。

１．製品は安定しているか

HCI製品はどれも、ソフトウェア技術に支えられています。

ソフトウェアと言えば皆さまピンとくる、バグ。

どの製品もソフトウェアでできている為、

ハードウェア製品に比べてバグが発生しがちなのは、

皆さまも感覚的に気になっていると思います。

実際の案件で見ても、確かにバグが発生しています。

致命的なもの、軽微なもの様々です。

人間の作ったものですから、

当然100％は有りませんが、

ここで重要なのが、

「バグが出尽くして安定まで至っているか」

という観点です。

各社製品が出てからどのくらい経っているか、

過去にどんなバグが出て、解決されたか、

といった情報を集めてみてください。

ちなみに製品のバージョンは信用してはいけません。

製品によっては途中のバージョンで

アーキテクチャがまるっきり変わっているものがあります。

名前がそのままなだけで、中身は別物です。

ですので、バージョンの数字が大きいからと安心せず、

キチンと成熟しているかを評価しましょう。

２．保守サポートが満足できるものか

ソフトウェア中心になるので、どうしてもユーザさんから

見えない部分が多くなります。

物理サーバが仮想化された時に、

目に見えなくなったのとかなり似ていますね。

見えないものに対して重要なのが、サポートです。

そのメーカーがどんなサポートを提供しているのか、

よく確認してみてください。

満足度の高い保守を提供することを約束してもらえるか、

例えば実際にその製品を使っている会社に、

サポートがどうなのか、聞いてみるのもいいでしょう。

また、普段そのメーカーの別製品を使っていれば、

自ずとレベルがわかるかもしれません。

サポートは重要な観点として、

充実したものが提供されるのか、

十分情報提供を受けましょう。

３．HCIのメリットを最大限享受できるのか

そもそもHCIを採用することになったのは、

HCIに期待する効果があった為だと思います。

本当にそれらの効果が得られているでしょうか？

運用管理の負担が下がりそうか、

拡張が簡単か、制限がないか

基盤更改をシンプルにしてくれるか、

性能は高くなるのか、

など、観点は様々だと思いますが、

本来の目的が満たせているのか、

ぜひ確認してみてください。

４．顧客満足度は高いか

サポートなどかなり総合的な評価になりますが、

顧客満足度を聞いてみてください。

これはHCIに関わらずその製品を採用してよかったと思えるか、

ユーザの声を聞いてみてください。

１～３のすべての観点が十分満たされていて初めて、

これらの満足度に反映してきますので、わかりやすい観点です

ここでの注意は、採用したての企業に

意見を求めてはいけません。

採用したての場合はまだ実態が伴っていない場合があります。

ぜひ採用してから１～２年つかってみた感想を

聞いてみるのがベストです。

思わぬ話が聞けるかもしれません。

いかがでしたか。

比較というと、ついつい細かな機能を比較しがちですが、

使ってよかったといえる為のポイントをまとめてみました。

比較検討の際に考慮してみてください。

今回、は以上です。

【読んでおきたい】HCI導入を上申する時に書きたい2つのポイント

ガートナー社から発表されたハイプサイクル※にもある通り、

日本でも盛り上がりの様相を見せているWebスケールIT。

※2017/10/03ガートナー ジャパン株式会社「日本におけるテクノロジのハイプ・サイクル：2017年」https://www.gartner.co.jp/press/html/pr20171003-01.html

その一つの製品形態であるハイパーコンバージド（以下HCI）は、

国内でも少しずつ盛り上がりを見せています。

従来の3Tierと呼ばれるサーバやストレージを調達して構成される

システム構成から脱却して構成を置き換える訳ですが、

そんな時に情報システム部の担当者必ずぶつかるのが、

「どう上申するか？」かと思います。

HCIと3Tierシステムを比較し、

当然良いものであることを客観的に示さなければ、

簡単には調達できませんよね。

今回は、HCIと3Tier構成を比較しつつ、

HCI導入の上申時に書きたい、

ポイントを２つ紹介していきます。

（クラウドとの比較はボリューム多くなるので別記事で）

特に技術的な観点よりは決裁者（経営者）の視点で

まとめみたつもりです。

完全な網羅性までは追求していませんので、

一つの参考となる考え方としてお読みください。

なお、本分析は一個人の見解ですので、

正確性を保証するものではないことを

予め明記しておきます。

１．社内システムの将来的な拡大への対応

買収・合併、ビジネス拡大に伴う社員の増加など、

ビジネス環境が変化した際に、

社内システムも必ず変化を余儀なくされます。

それは多くのケースで、

必要なリソース量の「増加」を招きます。

本当に増えるかどうかは誰にも予測はできないことですが、

いざ増えた時にどう対応するか、

これは情報システム部門にとって重要な命題です。

従来の3Tier構成においてどうしていたかと言えば、

ｘｘ％程度増えるかもしれないので、

バッファを持って導入しよう、

ということが行われるわけです。

至って当たり前のことですが、

これも「これ以上は増えないだろう」という前提を作り、

導入しているので、将来的なリスクを許容して選択しています。

或いは予算的な都合も鑑みて、

ギリギリを攻めて導入し、「増えない前提」という

導入を行うケースもあります。

この結果どうなるかと言えば、

１、２年後、経営側から、新しいシステムを導入してみろ、

利用者を拡大できるようにせよ、

といった指示から前提が崩れます。

結果としてリソース（容量・性能）が不足する為、

新しい基盤をもう１セット導入して運用負荷を倍にするか、

お買い物をし直しさせてくれ、

という稟議を経営者にしにいくわけです。

経営者側も自分が要求している以上NOと

言いづらいですが、

なぜ買わなければいけないのかをしっかり説明を要求し、

情報システム担当者は材料集めに苦心するシナリオです。

ここで救世主はHCIです。

HCIはWebスケールと言われたりするように、

拡張する前提で作られています。

その為、あとから増やしたいニーズを容易に満たします。

つまり、「足りなければ足せばいい」

「欲しいものを欲しい分だけ」というお買い物の

仕方ができる訳です。

日本企業は欧米に比べると

（個人的印象ですが）

まとめて多くを調達せず、必要な分だけ買って、

やりくりしていくスタイルだと思います。

まさに日本的な調達スタイルに合っているのが、

HCIでの基盤づくりです。

また、情報システム担当者を個人的に救う観点で見ると、

何かしら考慮漏れや手違いがあって不足する事態になったとしても、

足すというアプローチで、

構成の見直しなど大惨事になることも回避できる点も魅力かと思います。

前置きが長くなりましたが、

これをまとめた文案としては

「将来的なビジネス変化やITリソースの需要増に対して、

　社内のITインフラに柔軟性を持たせ、

　経営方針に沿ったIT活用を後押しする為、

　HCIを採用します。」

という様な文言になるのではと思います。

クラウドを取り入れたいけど、

セキュリティ的にNGとなっている会社であれば、

「自社の社内システムにクラウドのような拡張性を導入できます」

と言ってみるのはいかがでしょうか。

ここまででおなか一杯感はありますが、

次にいきます。

２．５年毎のリプレースプロジェクトからの解放

一般的にハードウェアの保守は５年までと設定されていることが多いです。

（例外として７など調整するケースはあります）

その為、５年毎に機器交換の１大プロジェクトが発生します。

RFIを出して、RFPを出して、

ベンダーの比較検討、経営会議での承認、

専任担当をつけて何か月もかけての更改プロジェクト遂行、

リスクをはらんだシステムの切替日、

そしてトラブルによる切り戻し・・・

考えただけでも胃の痛くなる大仕事です。

従来の3Tier構成では、

必ずこの大仕事が待っていました。

システムが仮想化したことで、

幾分この作業は和らいだ点がありますが、

異なるアーキテクチャ上に移すリスクは必ず残ります。

HCIに切り替えることで、

この考え方から脱却する手段があります。

必要な分だけ足せるメリットを生かし、

基盤の「新陳代謝」を行う方法です。

考え方としては、

従来の基盤に新しいハードウェアを足し、

仮想マシンをライブマイグレーションします。

古い機械の上から仮想マシンをすべて移動させた上で、

リソースから古い機械を外す。

まさに「新陳代謝」です。

このやり方では、同じアーキテクチャを元にして、

ライブマイグレーションだけを行うという

非常に簡単なお引越しで基盤更改ができるメリットがあります。

これを上手く活用することで、

切替の大規模プロジェクトをしなくとも、

普段のリソース拡張と同じ調達のレベルで、

機器更改が完了してしまいます。

これを経営者目線で見ると、

「５年毎の機器更改における人件費の大幅圧縮と

　機器切替における業務停止リスクを最小化する為に、

　HCIでの基盤導入を行います」

ということになるでしょうか。

この「お祭り」を避ける人件費どのくらい圧縮できるか？

という話で言えば、

１日当たりの情報システム担当者の人件費を

仮に６万円と設定すると例えばこんなイメージです。

（割と控えめな現実的な試算をしたつもりです）

RFP作成：６万円×（作成10日＋レビュー2日＋修正8日）＝120万円

ベンダー選定：６万円×（説明２日＋QA３日＋プレゼン対応２日

　　　　　　　　　　　＋比較表作成５日＋稟議資料作成８日

　　　　　　　　　　　＋社内説明４日＋指摘修正８日

　　　　　　　　　　　＋事務手続き２日）＝２０４万円

PJ管理：６万円×（定例会0.25日×４回×４か月＋レビュー１０回×0.25日

　　　　　　　　　　＋社内での進捗報告＆資料作成0.5日×４回×４か月

　　　　　　　　　　＋事務手続き１日×４か月＋課題管理と回答１日×４回×４か月

　　　　　　　　　　＋リリースの社内判定３日）＝３２１万円

このくらいの大ごとをしています。

HCI化すると、今後リソース拡張等の入れ替えだけなので、

PJ管理程度で、計算を割愛しますが、

1か月程度のPJで済むので、費用も4分の1くらいと

見てもよいでしょう。

またこれだけの人件費をかける一方で、

人的リソースがこの「価値を生まない」PJに

確保されてしまうリスクもあります。

本来経営者としては、情報システム部門に

経営を引っ張ていくようなIT活用を検討することを

期待していると思います。

人手不足が深刻化する中で、

その人的リソースを有効活用し、

情報システム部門の役割をより経営に貢献する

変化を促す為にも、

この取り組みは重要です、

と上申してもいいかもしれませんね。

少々長くなってしまったので、

２つだけにしました。

他にもHCI化することで、

3Tierで複数メーカーの機器を使っていた所から、

１社にサポートを集約できること、

採用する会社によっては、

サポート品質を向上させられること、

フラッシュも活用されることで、

インフラの性能向上＝システムの性能向上、

運用の簡素化による運用体制の見直し、

技術者育成の簡素化、

などなどメリットはいっぱいです。

折角なので、社内インフラを更改する時は、

HCIを検討してみてください。

今回は以上です。