2017年11月15日水曜日

NutanixにおけるDISK暗号化の話

NutanixではCVMがデータをDISKに書き込む時、

MBサイズに分割して書き込みしてくれます。

ただし、このブロックサイズの中身が必ずしも

読めないという訳ではありません。

その為、DISK交換等による情報漏洩を防ぐ為、

一般的に次の2つの選択肢があります。

1.DISK返却不要のオプションを付けて、
  保守時に交換したDISKを手元に残せるようにする
  (そして適切な破棄を行う)

2.DISKの暗号化を行う


1はわかりやすい対策ですが、

結局はそのDISKの取り扱いを誤ったら同じことなので、

根本対策とは言えないのがホンネです。

しっかりとした仕組みで対策するなら、

2のDISK暗号化が現実的な選択肢となります。

現時点ではソフトウェア的に暗号化機能が実装されていないので、

DISKレベルの暗号化製品を調達し、

合わせて外部の暗号鍵管理製品を導入する、

というのが具体的な手法となります。

特に、現在非常にHOTなキーワードである、

PCI DSSでは定期的な鍵管理の必要性が

要件として組み込まれている為、

今後も引き続き、鍵管理製品を活用することになるでしょう。


では鍵管理製品は何を使うかですが、

筆者の知る中では、日本国内では、

SafenetのKeySecureがNutanixとの組み合わせでの

本番実装の実績があります。

Safenet製品は従来からPCI DSS準拠の為の

セキュリティ製品として実装の実績が多く、

製品としては信頼できるものであり、

またNutanixとの連携も認証がとれている点も◎。

暗号化をやる時は、この組み合わせにすれば

安心ですので、やってみてください。


今回は以上です。

2017年10月29日日曜日

Nutanix Guest Toolsに関する話

今日は細かい話です。

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

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

VMware Toolsと同じ感じですね。

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

ご存知でしょうか?

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

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

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

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

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

いよいよAHVもTurbo Modeとか、

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

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

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


今回は以上です。

2017年10月26日木曜日

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

今回は短文投稿です。

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

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

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

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

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

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

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


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

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

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

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

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

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

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

量が多いので、挫折する方が多いですが(笑)

ご興味のある方はぜひ。

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


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

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

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

私と同じX-MenNutanixに関してのトップエンジニア)の方が

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

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



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

2017年10月24日火曜日

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

例えばvMotionした時、

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

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

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

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

答えはNOです。

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

運用面・負荷面等考えると現実的な数なので、
(これ以上は経験からおススメしません)

100Mbpsですね。

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

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

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

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

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

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

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

LoginVSIというソフトを使い、

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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


ここまで書きましたが、

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

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


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

2017年10月9日月曜日

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

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

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

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

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

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

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

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

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

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

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


1.製品は安定しているか

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

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

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

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

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

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

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

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

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

ここで重要なのが、

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

という観点です。

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

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

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

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

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

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

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

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

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



2.保守サポートが満足できるものか

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

性能は高くなるのか、

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

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

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



4.顧客満足度は高いか

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

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

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

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

1~3のすべての観点が十分満たされていて初めて、

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

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

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

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

ぜひ採用してから1~2年つかってみた感想を

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

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



いかがでしたか。

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

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

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

今回、は以上です。

2017年10月6日金曜日

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

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

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

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

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

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


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

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

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

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

HCI3Tierシステムを比較し、

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

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

今回は、HCI3Tier構成を比較しつつ、

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

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

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


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

まとめみたつもりです。

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

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

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

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

予め明記しておきます。


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

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

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

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

それは多くのケースで、

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

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

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

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

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

xx%程度増えるかもしれないので、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

言いづらいですが、

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

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

ここで救世主はHCIです。

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

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

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

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

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

仕方ができる訳です。

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

(個人的印象ですが)

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

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

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

HCIでの基盤づくりです。

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

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

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

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


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

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

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

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

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

 HCIを採用します。」

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

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

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

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

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

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

次にいきます。

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

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

(例外として7など調整するケースはあります)

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

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

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

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

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

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

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

従来の3Tier構成では、

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

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

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

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

HCIに切り替えることで、

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

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

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

考え方としては、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

という話で言えば、

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

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

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

RFP作成:6万円×(作成10日+レビュー2日+修正8日)=120万円

ベンダー選定:6万円×(説明2日+QA3日+プレゼン対応2日

           +比較表作成5日+稟議資料作成8日

           +社内説明4日+指摘修正8日

           +事務手続き2日)=204万円

PJ管理:6万円×(定例会0.25日×4回×4か月+レビュー10回×0.25

          +社内での進捗報告&資料作成0.5日×4回×4か月

          +事務手続き1日×4か月+課題管理と回答1日×4回×4か月

          +リリースの社内判定3日)=321万円

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

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

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

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

見てもよいでしょう。

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

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

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

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

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

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

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

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

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

変化を促す為にも、

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

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



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

2つだけにしました。

他にもHCI化することで、

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

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

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

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

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

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

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

技術者育成の簡素化、

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

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

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


今回は以上です。