#Nutanix の資格まとめ（2017年12月版）

本記事はNutanix Advent Calendar 2017#1の12/21分記事です。

（2019/1/6追記　最新情報はこちらの記事へ）

 Advent Calendarも残り２記事ですね。

前回は全く実務に役に立たない（笑）内容をお届けしましたが、

（いや、プリセのトークネタとしては有用ですが）

今回はNutanixを取り扱うエンジニアは押さえておきたい、

資格の話の最新版まとめでいきたいと思います。

資格はこれまで過去２回ほど書いてきましたが、

徐々に体系が進化してますので、

2017/12時点の最新版としてお届けします。

なお、中の人ではないので、

若干正確性に欠けるかもしれませんが、ご容赦ください。



さて、現在資格体系は大きく４つのカテゴリに分類されています。

１．Sales

２．SE

３．Services

４．Admin


以前の記事執筆時から「１．Sales」と「４．Admin」系は

ありましたが、

それ以外が順次体系化されてきている感じですね。

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


【１．Salesカテゴリ】

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

１－１．NPSR（Nutanix Platform Sales Representative）
１－２．NPSS（Nutanix Platform Sales Specialist）
１－３．NPSC（Nutanix Platform Sales Champion）
１－４．NPSX（The Nutanix Platform Sales eXpert）

基本的に順に取得し、ステップアップしていく格好になります。

以前はNPSS以上の取得にはDeal Registrationの件数要件などがありましたが、

どうやら今はなくなったようです。

なお、NPSCまではオンライントレーニングで取得可能ですが、

最後のNPSXだけはオンラインだけでは取得できず、

英語のプレゼンが待っています。

Nutanixのセールスをする人間としては、

NPSCまでは取得しておきたいですね。

製品の考え方と基本コンセプトをしっかり理解していれば、

営業の方でもそれほど取得ハードルは高くないと考えます。

【２．SEカテゴリ】

こちらのカテゴリは新しく整理されてきたものです。

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

こちらも４カテゴリに分かれています。

２－１．NSEN（Nutanix Systems Engineering Novice）

２－２．NSES（Nutanix Systems Engineering Specialist）

２－３．NSEC（Nutanix Systems Engineering Champion）

２－４．NSEE（The Nutanix Systems Engineering）

例によって、NSEEは実際のデモンストレーションを行う

必要があるのでオンラインで受けられないので、

NSECまで取得した上での切符を獲得する必要があります。

【３．Servicesカテゴリ】

こちらはNutanix Consulting Partner Programの

確立に合わせた資格プログラムとなります。

資格自体はNutanix Consulting Specialistのみのようですが、

前提として、コンピテンシーコースが２つ用意されています。

この資格はNutanixのコンサルティングスペシャリストとして、

コンサルティングサービスを提供する場合に必要な資格となります。

前提として、NPSR、NSEN、NPPが取得していないと

そもそも受講することが出来ないようです。

中身としては、

・Nutanix Core Competency

をまずはオンラインで受講します。

次に、

・Nutanix Core Competency ＋

を受講となりますが、こちらはBootcampを

受ける形式になるようです。

ここではインストレーションなどを実際に実習します。

自身が受講した時は、

（国内ファースト受講者だったようで）

シンガポール在住のトレーニング担当者がきて、

数日間英語の実技を伴う研修を行い、

最後に顧客への引き渡しロールプレイを

英語で実施していました。

多分、今も英語である点は変わらないと思います。

やっと最後のカテゴリです。

【４．Administrationカテゴリ】

こちらはNutanixの管理者として必要な技術的な

背景知識を全体的に網羅した資格で、

Nutanixの案件に関わるエンジニアとしては、

取得しておきたい資格となります。

こちら勉強方法は大きく２つあり、

実際の研修コースを受講する方法と

オンラインでのe-Learningを受講する方法があります。

自分が受講の際は既にNutanixを自社導入等で

かなり背景知識があったので、

オンラインで特にてこずることはありませんでしたが、

初めて関わる場合は研修を受けたほうがいいのではと思います。

研修は以下の研修会社で開催されているようです。

https://www.trainocate.co.jp/reference/course_details.aspx?code=NFC0293V

少々値ははりますね・・・。

さて、今回は2017年12月時点の資格情報をまとめてみました。

今後も資格体系が整理されていくそうなので、

さらに次のステップやカテゴリ体系が分かれていくかと思います。

まずはSales系から始めて、基本を学んでみてください。

また、今は書籍も出ています。

信頼できる著者の方々が書かれている１冊なので、

ここから始めてもいいと思います。

今回の投稿は、以上となります。

みなさまよいクリスマスを。

ハードウェア（＆日本国内）視点から見る #Nutanix の歴史

本記事はNutanix Advent Calendar 2017#1の12/21分記事です。


ある方にお誘いいただきまして、

今年はAdvent Calendarに初挑戦です。

さて、超プロフェッショナルな方々に囲まれて、

ネタが被らないようにどう書こうかと思った時、

誰も書かないであろう、Nutanixの歴史を

Generationを見ながら書こうと思いつきました。

Nutanixとの出会いは2012年も終わりなので、

まだ日本法人もない頃。

日本法人の社員の方々よりも無駄に歴史を歩んできたという

役に立たない（！）ネタをお送りします。

Nutanix愛に溢れる方には、必修科目をお届けします（笑）



さて本題。

本記事の執筆時点、

NXシリーズはG5が提供されています。

じゃあ過去はどうだったか。

どんなHWだったか含め、遡ってみましょう。

なお、執筆者はNutanixの中の人ではないので、

もしかすると誤情報もあるかもしれませんが、

外から目線ですので、そこはご容赦ください。

※（執筆後追記）思ったよりボリューミーでごめんなさい。。。


◆第１世代＜FusionIOが特徴の世代＞

最初の世代はFusionIOが載っていました。

この頃は完全にHWの製品というイメージ。

スピードに関してもFusionIOを載せて、

キャッシングを上手くしているので速い！

というイメージで聞いていました。

分散ファイルシステムは勿論出来上がっていましたが、

この段階ではまだHW依存でスピードを稼いでいた印象です。

国内入りたてなので、

検証で流通したのもまだ僅かだと思います。

当時はまだ日本法人はなく、商社さんがUSから

持ってきて立ち上げ、という時期でした。

（この世代については、自分も触っていませんでした。）


◆第２世代　＜SSDシフト。唯一のQuanta製＞

この世代になってイキナリ、FusionIOが外れました。

Intel SSDに変更され、今の2SSD+4HDDのNode構成

の標準にはこの頃なったイメージです。

大体2013年初からこのHW世代になった覚えがあります。

当時、FusionIOが載っているから速いよ！

みたいな情報をもらっていたので、

急にIntel SSDになった時は一抹の不安を覚えた記憶があります。

しかし、OS（当時はNutanixOS=NOSと呼んでいた)が

3.0にいよいよなりまして、

意外と上手くSSDとHDDのティアリングを活用し、

IOが出ていたイメージ。

VDI環境で利用しましたが、

IOの性能不足に陥る不安がないという当時では画期的な状況でした。

ただし、HWに乗っているCPUが2.2GHzくらいで、

コアも８くらいしかなかったので、

NOSでとられる分を考えるとあまり集約率が高くない

というジレンマに陥っていた印象です。

HWに再びフォーカスしてみると、

この世代だけQuantaのサーバを使っていました。

事情は中の人ではないのでわかりませんが・・・。

サーバメーカーが変わって困ったことが一つ。

（奥行きが）長い！ので、ラックによっては収まらない事態に。

いや、筐体は収まるんですが、

SFP+のケーブルが扉との兼ね合いで

直角に曲げられるという事件に遭遇しました（遠い目）


何か事情があったと思いますが、

Quanta製はこの１世代だけでした。（ホッ）

ちなみにこの頃はまだNOSは現在のPrismの様な

インターフェースとはちょっと異なっていました。

ただ、DISK容量などはGUIで視覚的に

わかる様にしていた点では、当時画期的だったかなと。


この世代で日本国内本番環境の

ファーストリファレンスユーザが出てきました。

この頃からぽつぽつ売れ出したのかなという感じですね。



◆第３世代　本格的な安定普及モデル

2013年後半から第３世代へ。

Supermicroに戻ってきました。

この頃からHW構成もいよいよ現在のNXシリーズの

礎になるモデルラインナップになってきました。

CPUの選択肢も増え、より高クロック・多コアが選択できるようになり、

DISKも高容量モデルの6000シリーズが登場してきたことで、

現実的にVDIで利用できるようになり、

普及を後押ししたモデルと言えるでしょう。

ただし、HWのIPMI機能に少々難があり、

HW障害を上手に通知できないという問題がありました。

（後の世代では解消されています）

この頃にNOSはｖ3.5へ。

いよいよ現在のPrismと同じインターフェースになってきて、

より視覚的に情報を詳しく見れるようになってきました。

ソフトウェアも機能追加から洗練の色が濃くなり

高いパフォーマンスを安定して出せるようになってきました。

この世代の頃で、Nutanixの主要ソフトウェア機能の

バグ出しは概ね終わったと言っても過言ではないと思います。

事実この世代で2,000台規模のVDI環境を実装した事例では、

多ノードでのスケール上の問題も起こらず、

IOもどんなストレージ使った環境より安定したIOを提供しました。

VDIと言えばHCIを確固たるものにした世代です。

なお、この裏でXCシリーズが静かに走りだし始めていまいた。



◆第４世代　多モデル化、更に普及のモデルへ

CPUリフレッシュとして、次の世代へ。

ここからIntelのCPUリフレッシュを考慮した、

モデルチェンジ体制に移ってきました。

更にラインナップも増え、

本格的にエンタープライズアプリケーションの稼働を狙ってきた世代です。

例えば8000シリーズはCPU/MEM/SSDとも

かなりヘビーに載せられるようになり、

DBやExchangeサーバなど積極的に狙いにきました。

また、この頃からHWモデルの混在もサポートされるように。

OSもNOSからAOSと呼ばれるようになるなど、

ソフト面でも１段先に進んでいます。

特にソフト面での変化が、1Clickを本格的に打ち出し始めたことです。

現在ではAOSの代名詞であるSWの1Click Updateも

しっかり実装されてきたのはこの世代の頃に出てきたAOS4.xから。

ここでNutanixとしてはシンプルなインフラを提供するという

世界観を一応完成させた、というところでしょうか。

確かメッセージも単なるHCIではないといい始めたのも

このころだったと思います。

背景には少しずつHPやVMwareがHCIに注目し始めたことがあります。

HPは自社で持っているStoreVirtualベースの製品を世に送り出し、

VMwareはVSANを提供し始めています。

（この時のVSANと今のVSANは中身が別物）

HWにもう少し言及すると、

選択できるパーツやモデルが増えてきた為に、

構成パターンが数万レベルに膨れ上がったこと。

このころからSizerくんが必要になり、

本格的に利用され始めました。

ここでSizerというものを提供し始めた点が、

後々Nutanixが気に入られるポイントの一つに。


この世代ではプライベートクラウドなどでも採用が広がり、

様々な導入事例が広がってきました。

またこの世代から、メーカーのグローバルサポートが

日本でも提供開始となりました。

従来のグローバルサポートは英語のみであったため、

国内では販社のサポートが提供されていましたが、

普及に合わせて、メーカー側で日本人のサポート部隊を

本格的に組織されてきた世代です。

この立ち上げの頃からメーカーサポートを利用していますが、

他のメーカーでは中々ないクオリティのサポートに

感動した覚えがあります。

このサポートがあるから他の方にも紹介したいと思える、

そんな製品に育っていったのではと思います。



◆第５世代　そして定期リフレッシュ、Broadwell世代へ

お約束のIntelのCPUに合わせたリフレッシュです。

第４世代でかなり世界感が完成したので、

第５世代は大きな革新というほどではないですが、

ストレージノードの登場など、

細かなニーズを埋めるようになってきました。

かゆいところに手が届く的な。

パターンもかなり増えてきたので、

構成のバリエーションもかなり増えました。

おかげさまで工夫の余地もかなり増え、

案件によってモデルの組み合わせを工夫することで、

トータルコスト20％程度を抑えたりという職人芸も登場（笑

Sizerの重要性が増しました。

この世代が現在もメインストリームとなり、

販売され続けていますし、

新たにHXやCISCO・HPE対応してくるなど、

HW対応の幅が一気に広がってきています。

それだけ普及したということですね。



◆そして次の世代は？

現時点、NXについてはBroadwell搭載のG５までが提供されています。

一方でHX・XCはSkylake世代をリリース済みです。

これ以上は言及しかねますが、

近い時期にSkylakeも登場してくることは想像に難くないでしょう。

次はCPUだけでなく、新たなHWの進化もあるかも？！




長くなってしましましたが、今回は以上です。

Nutanix自身はソフトウェアの会社ではありますが、

HWの側面からみても面白いですね。


今回は以上です。

NutanixにおけるDISK暗号化の話

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

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

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

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

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

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

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

２．DISKの暗号化を行う


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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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


今回は以上です。

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を検討してみてください。

今回は以上です。