[Nutanix] Nutanix Technology Champions 2017

光栄なことに、去年に続き今年もNutanix Technology Champions 2017(NTC 2017)プログラムに選ばれました。

 

NTCは、Nutanixのプロダクトを含めクラウドのエキスパートやコミュニティー、ブログなどのソーシャルメディアでNutanixのプロダクトと技術を広めたことを讃える、いわゆる名誉資格です。VMwareのvExpertと同様自薦他薦問いません。:)

 

NTCに選ばれると、誰よりも早くプライベートβテストの参加や新しい製品についてのアーリーブリーフィングに参加できます。またNTC専用Slackに参加し、世界中のNTCやNutanix社員とディスカッションできます。あとはNPP取得サポートや最高上位資格であるNPX取得のためのメンターも求めることができます。

 

今年は世界で約150名が選ばれていて、日本では自分以外に3名(名前に確認した限り…)の方が選ばれているようです。

 

来年はより多くのNutanix関連情報を紹介したいと思いますので、引き続きよろしくお願いします。

 

 

 

広告

[Nutanix] vRealize Automationのエンドポイントとして使ってみよう

このポストは、 Nutanix Advent Calendar 2016に参加しています。

 

先に言っておきます。とにかくやってみました。

何をやってみたかというと… vRealize AutomationのエンドポイントとしてNutanixを追加してみました。(しかもNested CE) なんだか余計なことをしたような気がしてなりませんが…

 

ご存知の方もいらっしゃると思いますが、vRealize Automationは主にプライベートクラウドを構築できるソリューションで、仮想インフラのITサービスを自動化してくれるプロダクトです。
仮想インフラだけではなくクラウドや物理サーバに至るまでマシンのデプロイからvRealize Orchestratorを利用したワークフローまで、インフラ管理者が担っていたルーチンワークをユーザ自身に任せて、管理者が楽になれる ITサービスの質を上げることができます。まあ、要は企業のインフラ環境をより迅速かつ効率的な利用が可能になるということです。

 

このvRAはコンピュートリソースを”エンドポイント”として登録し、利用しますが、vCloud Directorとは違いVMwareソリューションだけではなくHyper-VやKVMといったマルチハイパーバイザーはもちろんAWSやAzureなどのパブリッククラウドも利用が可能です。
ただし、vRAのエンドポイントとしてAHVはサポートしていませんので、今回はOpenStackとしてエンドポイントを作成するという迂回路を選びます。

 

で、ここでです。
失礼ながらOpenStackについては全くと言っていい程知りません。cinder?neutron?Glance?知りません。 (;゚д゚)ァ…. とにかくやってみました。

 

まず、Nutanix AHV環境をOpenStackとして構成します。公式ドキュメントはもちろんちゃんとOpenStack Services VM (OVM)も提供されているので簡単にできます。

vrawithnutanix-01

Nutanix Partner Portalより、Nutanix OpenStack Imageをダウンロードします。

 

vrawithnutanix-02

ダウンロードしたOVMのイメージファイルを”Image Configuration”よりアップロードし、OVM用VMを作成します。作成時の操作はアップロードしたイメージを使えるよう”Clone From Image Service”を選択します。

 

vrawithnutanix-03

無事、OVMの作成終わったら、コンソール接続し、コマンドを実行します。

ログインアカウント:root パスワード:admin

● OVMの追加

ovmctl –add ovm –name ovm名 –ip IPアドレス –netmask サブネットマスク –gateway ゲートウェイ –nameserver DNSサーバ –domain ドメイン名

● OpenStackコントローラの追加

 ovmctl –add controller –name openstackコントローラ名 –ip ovmのIPアドレス

 

vrawithnutanix-04

今度はNutanix AHVクラスタを登録します。

● Nutanix AHV クラスタの登録

ovmctl –add cluster –name クラスタ名 –ip クラスタIPアドレス –username Prismログインユーザ(管理者権限) –password パスワード –container コンテナー名

 

vrawithnutanix-05

正常に登録が終わったら、きちんと構成されたか確認します。

● 構成確認

ovmctl –show

 

vrawithnutanix-06

ちゃんとクラスタが登録されています。

 

vrawithnutanix-07

OpenStackコントローラも正常に登録され状態も有効になっています。

 

ここまでがNutanix AHV環境をOpenStackとして構成する手順です。
OpenStackの準備が整ったら、今度はvRAです。(vRAの構成は割愛します)

 

vrawithnutanix-08

テナント管理者としてポータルにログイン、「インフラストラクチャ」→「エンドポイント」より”OpenStack”を選択します。

 

vrawithnutanix-09

”エンドポイント”の情報を入力します。

– Name:作成するエンドポイント名(なんでもOK)

– Address:http://OpenStackコントローラIPアドレス:5000 (httpsだときちんと登録されません)

– Credentials:OpenStackコントローラログイン情報 (デフォルトログインアカウント:admin パスワード:admin)

– OpenStack project:OpenStackプロジェクト名 (大文字、小文字区別します。間違うと登録されません)

 

vrawithnutanix-10

正常に登録されるか確認しましょう。「View Compute Resources」をクリックします。

 

vrawithnutanix-11

「Start」をクリックし、Dataを収集します。正常にエンドポイントの作成ができていればData Collectionが成功するはずです。

 

vrawithnutanix-12

エンドポイントに正常に登録されると、ファブリックグループ作成時、Nutanix AHV OpenStackのコンピュートリソースが参照できるようになります。

 

エンドポイント、コンピュートリソースが参照できれば、あとはビジネスグループ(誰が使うのか)、ファブリック(どんだけリソースを使わせるのか)を決め、ブループリント(VM、サービスのデプロイ)を作成すれば終わりです。
※ここまで紹介したかったんですが、NestedなAHVなせいか、ちょっと負荷が上がるとすぐOpenStack環境が落ちてしまうため、あいにく紹介できません。すみません。
ここまでがvRAのエンドポイントとしてAHVを利用する方法について紹介しました。

 

Nutanix AHVクラスタをせっかくOpenStackとして構成したならそのまま使えば良いんじゃ?とも思いましたが、vSphere、Hyper-VやNutanix AHVなどが混在する環境ならすべてをvRAのエンドポイントとして登録することで環境全体のリソース管理やユーザへの提供が一つのセルフポータルでできる。これはこれで効率的じゃないかと思います。 🙂

 

[VMware] vRealize Infrastructure Navigatorについて

このポストは、vExpert Advent Calendar に参加しています。

 

VINってご存知ですか? vRealize OperationsのAdvancedエディションやvRealize Suiteに含まれているvRealize
Infrastructure Navigatorのことです。 なんだかvRealize Configuration Managerと共にvRealizeシリ
ーズの中でもあまり存在感のない(?)プロダクトではないかと思います。(実際にこいつを導入しているところを見たことがありません。:))

download

 

なのであえて紹介しようと思います。:)

 

VINが何をするやつかというと、簡単に仮想マシンのアプリケーションやサービスの依存関係を可視化してくれるやつです。
企業内のシステムはいろんなサーバ、サービスで構成されています。WebやApplicationそしてデータベースなどなど…システム開発部門ならこれらがどういう依存関係にあって、どういうフローでデータを処理するのか分かりますが、インフラ管理者がすべてを把握することは難しいです。
例えばメンテナンスのために仮想マシンを停止するインフラ管理者だと想像して見ましょう。
規模が大きいほど、複雑であるほど、下手をしたら地獄を見ることになります。
停止する仮想マシンはがどの仮想マシンと依存関係にあってどういうアプリケーションに影響するのかなどインフラ管理者が全部把握するのは難しいからです。
だからと言って一々開発チームに聞くのも効率が悪すぎます。

このような場面で役に立つのがこのVINです。
このVINは2006年EMCによって買収されたnLayersの製品を2010年VMwareが獲得、2012年vCenter Operations製品群としてリリースされ、2014年現在のvRealize Infrastructure Navigatorに製品名が変更されました。

vCenter ServerはもちろんvROpsやSRMなどの他のVMwareプロダクトと統合ができ、vSphereインフラ上の仮想マシンをマップ化します。またカスタムでアプリケーションを定義しマルチティアのアプリケーションのフローも確認することができます。

このVINは仮想アプライアンスとして提供されるため、簡単に導入することができます。ただし他のプロダクトは違い、vCenterと1:1で紐づきます。なのでインポートをしたvSphereインフラのvCenterが自動的に対象となります。

vin-architecture

VMware vRealize Infrastructure Navigator Documentation

上記の図のように、VINはアプリケーションやサービスの依存関係を把握するため、vmware toolsを利用します。仮想マシンにインストールされているvmware toolsを通じてその仮想マシンにインストールされているアプリケーションやサービスの情報を収集します。当然ながらvmware toolsがインストールされていない仮想マシンの情報が正常に表示されません。

 

vin-10

VIN仮想アプライアンスをインポートすると、vCenterのダッシュボードに”Infrastrcuture Navigator”のアイコンが追加されます。

 

vin-11

“Infrastructure Navigator”アイコンをクリックし、”セッティング”タブより、「仮想マシンへのアクセス」を有効にしないと情報が収集できません。ただし、ライセンスを割り当てないと「仮想マシンへのアクセス」がグレーアウトになっているため、まずはライセンスを割り当てます。ライセンスはvRealize Operations Managerのライセンスを使用します。

 

vin-13

ライセンスを割り当てますと、「仮想マシンへのアクセス」が有効化できます。

 

vin-15

vCenter Server上の仮想マシンへアクセスするわけですので、vCenter Serverの管理者情報を入力します。

 

vin-16

「仮想マシンへのアクセス」を有効にするとまず、”サマリ”に”Infrastructure Navigator”ビューが追加されます。VINが収集した情報を基に仮想マシンのサービスやアプリケーションの統計が表示されます。

 

vin-17

クラスタの”管理”タブにも”Application Services”メニューが追加され、クラスタ全体で稼働している仮想マシンのサービスやディスカバリー情報が表示されます。

 

vin-18

ESXiホストの”管理”タブにも”Application Services”メニューが追加され、そのESXiホスト上で稼働している仮想マシンのサービスやディスカバリー情報が表示されます。

 

vin-19

今度は仮想マシンです。仮想マシンには”Application Dependencies”が追加されます。この”Application Dependencies”をクリックするとその仮想マシンのサービスの依存関係がマップで表示されます。

 

vin-20

依存関係マップはpngファイルとして保存も可能で、ドキュメント作成にそのまま利用できます。

 

複雑な仮想インフラ環境管理で日々苦労している頑張っているインフラ管理者皆さん、ぜひVINをお試しください。

 

 

 

[VMware] インスタントクローンについて

 

このポストは、vExperts Advent Calendar 2016 に参加しています。

 

※少し古い(?)内容かもしれません。

今年3月、Horizon View 7がリリースされました。メジャーバージョンのため沢山の新機能が追加されましたが、個人的には”インスタントクローン”が一番興味深い機能でした。
でな訳で、”インスタントクローン”の話をします。

既にいろんな情報が出ていますが念のため、簡単に”インスタントクローン”について説明します。
”インスタントクローン”は以前は”Project Fargo”とも”VMFork”とも呼ばれていた技術で、ESXiホストのメモリ上で高速にクローンを作成します。

Linuxのforkの’仮想マシン版’とも言えるでしょうか。親仮想マシンの静止点(スナップショット)を取り、メモリ上で子仮想マシンとしてコピー(クローン)を作成します。コピーされる子仮想マシンは親仮想マシンのメモリとディスクを共有します。ここに仮想マシンに書き込みが発生したタイミングで差分ディスクとメモリを確保するCopy-on-Write方式を採用し可能な限りクローン作成時に必要なメモリ、ディスクを抑制します。そのためより、高速で多くのクローンが作成できるというわけです。ちなみにこの”インスタントクローン”ではView Storage AcceleratorとTPSが自動的に有効化されます。

instantclone-overview

↑の図のように”インスタントクローン”プールを作成すると①”マスターイメージ”からスナップショットを作成し、”テンプレート”を作成します。”テンプレート”の作成が終わったら②今度はこの”テンプレート”で”レプリカ”を作成します。この”レプリカ”は”インスタントクローン”プール作成の際に指定したデータストアに保存され’読み取り専用’として共有されます。③この”レプリカ”を基に各ESXiホストのメモリ上に”親仮想マシン”を作成します。”マスターイメージ”から”レプリカ”までは停止状態で処理されますが、”親仮想マシン”はパワーオン状態でESXiホストのメモリ上に常駐します。④”親仮想マシン”より”子仮想マシン”をコピーされます。

実際にプールを作成するとvCenterからは”テンプレート”、”レプリカ”、”親仮想マシン”そして”子仮想マシン”がそれぞれ作成されていることが確認できます。

instantclone-overview02

さて、速い速いとは言ってるけどどれぐらい速いのか比較してみました。(もちろん比較のデータも色々出てますが…)
リンククローンと同じ条件で (1)仮想デスクトッププール作成 (2)仮想デスクトップの追加時の時間を比較しました。

 

まず、検証環境は以下のとおりです。
– ESXiホスト 4台構成のvSAN環境で、ESXiホストあたり1つのディスクグループ(1xSSD、4xHDD)
– vSAN用ネットワークは10Gb

(1)仮想デスクトッププール作成
イニシャルデプロイとして10台の仮想デスクトップを作成するプール作成時間

ic-vs-lc-01_jp

インスタントクローン

ic-vs-lc-02_jp

リンククローン

(2)仮想デスクトップの追加
作成済みのプールに仮想デスクトップを90台追加作成時間

ic-vs-lc-03_jp

インスタントクローン

ic-vs-lc-04_jp

リンククローン

 

上記の結果はハードウェアスペックやESXiホスト数などによって異なりますが、プール作成にかかる時間はリンククローンでもインスタントクローンでもさほど変わらないことが分かります。しかし仮想デスクトップの追加にかかった時間はインスタントクローンがリンククローンより2倍以上速かったことが分かります。(この差はESXiホストが増えるほど大きくなります)
このように仮想デスクトップデプロイの所要時間、メモリ、ディスクなどのリソースを最小限に抑えられるス・テ・キ・な機能ですが、今のところ利用シーンは限られています。それは色々と制限されているためです。

  • ”インスタントクローン”は自動かつ流動プールのみ利用可能です。専用プールでは利用できません。
  • Persistent Diskが利用できませんし、Persona Managementもサポートしません。
  • サポートのゲストOSはWindows 7、Windows 10だけで他のWindows OS バージョンやLinuxそしてRDSHもサポートしません。
  • SysprepもQuickPrepも利用できません。(その変わりインスタントクローン用ClonePrepが提供されます)
  • VVolやNFS、ローカルデータストアもサポートしません。
  • IPv6もサポートしません。

 

フルクローンやリンククローンと比べてかなり条件が厳しいことが分かります。それに”インスタントクローン”特性上、ユーザが仮想デスクトップからログオフするとその仮想デスクトップを削除、新たにクローンを作成するため、ユーザプロファイルを維持するためには工夫が必要です。ちなみにVMware社ではApp Volumesを推奨しています。