2015年8月23日日曜日

VMware NSX 6.2リリース!

VMworldの発表後かと持っていましたら、8/20に、NSX 6.2(for vSphere)がリリースされていました。

今回の一番のアップデートは、

vSphere6に対応したことで、Closs vCenter 周りに対応した点が最も大きなアップデートだと思います。

NSX for vSphereは、vCenter Serverに管理下におけるESXiで、VX-LANが利用できる点がポイントですが、別のvCneter Serverの管理下にあるVX-LANとは、直接的に連携ができないのが現行までのNSX for vSphereの特徴でした。

ある程度の規模がないとVX-LANは、利用しないと思いますが、ある程度の規模を1つのvCenter Serverですべて管理するというのもまた非現実的で、このあたりは改善の余地がありました。

しかし、今回のアップデートにて、vCenterを跨いで1つの論理スイッチが作成可能になったと記載があるところは、NSXの本領がようやっと発揮できるようになったと言っても過言では無いと思います。

vCenterまたぎのVX-LANが管理できるようになった事により
  • Universal Security Groups
  • Universal Logical Switch (ULS)
  • Universal Distributed Logical Router (UDLR)
の各機能が新たに、追加されています。

また、改善された点として
  • Standalone Edge L2 VPN client CLI
  • New IP address discovery mechanisms for VMs
とあります。

Standalone Edge L2 VPN client CLIは、6.1.xバージョンまでは、L2-VPN-ClinetバーチャルアプライアンスをOVFから展開する際に、延伸するVLANを設定することしかできず、OVF展開後は、一切設定変更ができないという柔軟性に欠ける側面がありましたが、CLIが搭載されOVF展開後の設定変更が可能となったようです。

New IP address discovery mechanisms for VMsは、今まで仮想マシンを対象オブジェクトとしたファイアウォールルールを書いたときに、実際のIPアドレスは、VMware Tools経由でIPを取得していたのが、DHCP/ARP Snoopingで取得するように実装が加わったと記載があります。
これで、VMware Toolsがインストールがインストールされていない仮想マシンも動作の対象となりました。

また、気になるキーワードとして「Ability to keep VLAN tags over VXLAN」という記載があります。
VX-LANは、VLAN上に乗っかるもので有り、VX-LANの上にVLANの構成はできませんでした。
この表現は、VLAN on VXLAN on VLANといった、VXLAN上でのVLANトランクが可能な構成になるのかもしれません。こちらは別途ドキュメントを確認してみたいと思います。

VMware NSXも、どんどんと進歩してきていますね。


2015年8月8日土曜日

vRealize Operations Manager を見てみよう(5) vROpsは何が凄いのか(その3)

前回に引き続き、さらにvROpsの凄いところを見ていきましょう

[その5]
リソース不足の時、どれくらい増やせばいいかを教えてくれる!
過剰リソースをこれだけ押さえられますというのと同様に、リソース不足が生じている仮想マシンの場合は、これだけ増やすといいですよという情報も教えてくれます。
今までですと、経験豊富なSEさんのいわゆるKKD(勘と経験と度胸)により、割り当てられていたリソースも、経験不要で無駄なくリソースを割り当てることができます。
 
この場合ですと、vCPUが1コアで構成された仮想マシンに対して、CPUのリソース不足が生じており、3vCPUに割り当てを変更しましょうという推奨が出ています。

[その6]
これから追加するリソースをシミュレーションできる

これは、どういった意味かというと、現行のリソースに4vCPUでvRAM 24GBの仮想マシンを構築予定なんだけど、リソース足りるかな?大丈夫かな?といった場合、また既存の仮想マシンのスペック不足の際に、同じ仮想マシンをコピーしてESXiホストに配置した場合、ESXiホストのリソース不足にならないかなどをあらかじめ、シミュレーションが可能です。
こちらの例は、8/15に、仮想マシンを追加するシミュレーションを行った際に、ESXiホストのメモリーが不足することがわかる状態ですね。
追加対象は、クラスターでも可能です。
これらの、vROpsの機能を利用することで、リソースの現状を把握するだけではなく、適切なリソースの割り付けを行い、無駄を減らすことと、全体的にリソース不足の場合は、追加機器を購入する際の稟議決裁におけるエビデンスとして利用することも可能ですね。
これらは、従来の監視ツールではできないことです。
逆に言うと従来の監視ツールと同じことは、vROpsではできません。

2つの監視ツールと運用管理ツールであるvROpsをうまく組み合わせることで、無駄のないIT投資と、トラブルの減るデーターセンター運用が可能になると思います。


vRealize Operations Manager を見てみよう(4) vROpsは何が凄いのか(その2)

前回に引き続き、vROpsがなんで凄いのかの続きを見ていきたいと思います。

[その3]
オンプレだけじゃない、vCloud Airはもちろん、AWSも含めたパブリッククラウドも統合的に管理可能!

専用エージェントを入れて監視を行う監視ツールと異なり、vROpsは、vCenter Serverとの接続だけでOKという話をしましたが、オンプレのvCenter Server以外にも、vCloud AirやAWSなどのパブリッククラウドを同じように統合監視することができます。
時代は、用途に応じたマルチクラウド時代に突入しようとしています。従来のエージェント型の監視システムでだけで対応できないエリアを、vROpsで運用管理するのもよいかと思います。
ちなみに、VMware社は、Azureの対応も行うとの話しを聞いたことがあります。
そうなれば、主要パブリッククラウドにほとんど対応することになりますね。

[その4]
リソースの無駄を教えてくれる!

通常の監視ツールは、リソースが不足した際に閾値に基づきアラートが発せられます。
vROpsは、全体のリソースを把握しますので、いわゆる「リソースの無駄」 を教えてくれる機能があります。

こちらの例ですと、4GBのメモリーを割り当てていますが、実質1GBも利用していない時間が多いので、これだけメモリーの割り当てを少なくできるよ!というおすすめ情報が出ています。
同じく、vCPUも、4コア割当たっていますが、2コア相当しか利用為ていないので、vCPUは2コアでいいですよという、情報を出しています。

これをうまく活用することで、いわゆるオーバースペックによるリソースの無駄を削減することが可能です。これは、今までの監視ツールできはできなかった事のなります。




vRealize Operations Manager を見てみよう(3) vROpsは何が凄いのか(その1)

さて、vROpsは他の監視ツールと違うと言うこと、また、vROpsは、監視ツールと組み合わせて利用することで、潜在的な問題と突発的な問題の両方を把握できると言うことがわかりました。

では、運用管理ツールとしてvROpsは何が凄いのかを見ていきたいと思います。

[その1]
vCenter Serverに接続されているデバイスや仮想マシンは、1つ設定するだけで、すべて監視対象に!

通常の監視ツールは、IPアドレスに基づき、1つずつ監視ノードの追加し、閾値の設定が必要ですが、vROpsは、vCenter Serverアダプタの設定1つするだけで、ESXiホストから、接続されたストレージ、仮想マシンまでvCenter Serverで管理できるオブジェクトはすべて管理対象となります。
これは、楽です。

vCenter Serverを複数設定できますので1つのvROpsで、複数のデータセンターを管理するような事も可能です。


[その2]
今まで見えにくかった、IOPSやネットワーク通信料を見ることができる!

ネットワークトラフィックは、SNMPを利用することである程度の通信料は見る個はできましたが、すべての仮想マシンを対象にすると、設定がかなり大変かと思います。
IOPSは、ストレージにツールがある場合ぐらいでしか見る事ができないことが多いかと思います。

しかし、vROpsを利用すれば、ESXiホスト単位はもちろん、仮想マシン単位でもIOPSやネットワークトラフィックを見ることができます。


このスクリーンショットでは、思ったほどネットワークやIOPSは負荷が少ないようで、数値も少なめですね。
状態を常に取得し、状況を元に判断するというvROpsならではであり、このようなIOPSや、ネットワークトラフィック情報など細かくとりづらかったものが取得できるというのは、vROpsの凄いところだと思います。



vRealize Operations Manager を見てみよう(2) vROpsは、監視ツールと何が違うのか?

vRealize Operations Manager(vROps)は、VMware社が力を入れている、管理ソリューションソフトウェアです。

vROpsって監視ツールなんでしょ。監視ツールななんて、今までもたくさんあったじゃないですか!と思われる方も多いことでしょう。たしかに、JP1やSystem Walker、Web管理画面ですとOPManagerや、最近ではZabbixなど、有名どころはたくさんあります。

ただ、vROpsは、運用監視ツールと表現するには多少語弊があります。
先ほどあげたようなたとえば、JP1やZabbixに求める機能は何でしょうか?

これらの運用監視ツールに求めるものは、
  • サーバーやその上のアプリケーションの稼働状態を監視し、閾値に基づきアラートをあげるツール
  •  障害発生時には、この監視ツールが取得した定期的な情報を元に、何が起きたのかを解析する原因調査の1つのツール
なのではないかと思います。

この場合、閾値を超えた場合は何らかの異常が発生したという認識を監視ツールは行いますが、閾値は管理者自らが設定するもので有り、監視ツール自身が閾値を自動調整することはありません。今まで、運用側のエンジニアは、この閾値を設定することが大変な作業であったかと思います。
  • アプリケーション用途や利用人数に応じた閾値の設定
  • 昼と夜間で異なる閾値の把握
  • 閾値を高く設定することによる、トラブル未検知
  • 閾値を低く設定することによる、誤検知
これは、保守運用(特にデーターセンター管理者)にとっては、新しいシステムを導入するたびに発生する永遠の悩みだと思います。

vROpsは、これらの監視ツールとは違い「運用管理ツール」という位置づけになります。
監視ツールとの最大の違いは、違いという点で大まかに言うと「閾値は、vROpsが自動で設定する」 ということです。

これは、デフォルトで閾値の設定を持っているだけでしょ?と思われる方も居るかもしれませんが、確かにある程度のデフォルト値を持ってはいますが、監視するサーバーや仮想マシンの状況を定期的に取得し、そのマシン状態の平均を割り出し、その平均値をアラートの閾値として稼働するロジックが組み込まれております。

実際の現場で考えてみましょう。
夜間3時から6時まで処理を行うバッチ処理サーバーがあったとしましょう。
3時から6時までは常に90%程度のCPU利用率がありますが、バッチが終了したらCPU負荷率は0%になる状況です。
この場合、通常の監視ツールですと、閾値を90%にすると、3時から6時の間でひょっとするとアラートが上がる可能性があります。

vROpsは、今まで取得した統計情報を元に閾値を考えますので、3時から6時までのCPU高負荷は、異常とはとらえません。但し、通常処理のない日中にCPUが高負荷になった場合などは、今までと違う動きをしますので、異常ととえられます。

いわゆる、全体の動作を把握して、いつもと違うか否かで異常を判断する仕組みとなります。

言い換えますと、長くvROpsを利用為ていればいるほど、「いつもの」状態がわかるわけですが、vROpsを構築してすぐに監視ツールとして使えるかと言えば使えないというのが答えになります。

vROpsは、状態を監視して、いつもの動作をしていない環境をリストアップすることで、通常では気がつきにくい負荷の状態や、隠れているトラブルの種を検知することができます。


監視は、今までの監視ツールで行い、状態を管理するシステムとしてvROpsを導入することで、潜在的なトラブルと突発的なトラブルを検出し、安心して夜眠れる運用管理者のためのシステムが、vROpsと言ってよいでしょう。



vRealize Operations Manager を見てみよう(1) vSOM? vCOps? vROps? 皆同じツールです

VMwareから発売されている管理ソフトとして、vRealize Operations Managerがあります。
VMwareユーザーであれば、おそらくプロモーション等でこんな画面を一度は見たことがあるのではないでしょうか?


バッジの色とスコアで、状態が把握できるツールとして大変人気です。

あれ、これって、vCenter Operations Manager(vCOps)ですよね?
いやいや、vSOMですよね。

と思われる方も...。

この製品、VMwareの注力ソリューションではあるのですが、製品名称が変わったり複雑な販売体系のため、名前が錯綜しています。それぞれの名前を一度確認してみたいと思います。

  • vROps
    vRealize Operations Managerの略。
    この管理ソフト単体の現在の名称。(2014年の秋に名称変更によりこの名前に)
    バッジとスコアで状態が把握できるVMware製のソフトといえば、現行「vRealize Operations Manaher (vROps)」が正しい形になります。
  • vSOM
    vSphere with Operations Managerの略
    つまり、vSphereとvRealize Operations Managerのセット商品となります。
    そのため、この画面をvSOMですと言われる方もいらっしゃいますが、厳密に言うと、vSOMではなく、vROpsの画面という方が正しいことになります。
  • vCOps
    vCenter Operations Managerの略
    この製品が出た時代(2012年?)当時は、vCenter Serverの拡張製品という位置づけの元、vCenterシリーズに属していました。
    2014年11月のVMware社の発表により、vCOpsは、vRealizeシリーズにブランドが変わることになり、現行ではvCOpsという製品は販売終了になっているという事になります。
vROps(vRealize Operations Manager)が現行の正しい名称となるわけですが、「ヴイアールオプツ」というのは、正直日本人には言いにくい感はあります。
前は、「ヴイコップス(vCOps)」でしたが、「ヴイソム(vSOM)」のほうが言いやすいため、この画面を見るとvSOMと言ってしまうのは、日本人ならではなのではないかと思います。

単純に言うと、vROpsが現行の正しい名称。vCOpsは、昔の名前。vSOMは、vSphereとvROpsのセット商品と覚えておきましょう。

共通点は、みな、vRealize Operations Managerのこと(複合製品の一部)ということです。









2015年8月2日日曜日

謎の VMware Workspace Air !?

VMware社のドキュメントページを見ていると、ある日突然、「VMware Workspace Air」なるものが、追加されていました。

リンクをクリックすると、Not Foundになってしまいます。



Communityを見てみると、
「Workspace Air is a cloud service that provides an integrated platform for users to access their applications, data, and virtual desktops on any of their devices. With Workspace Air, IT can easily manage entitlements and policy controls from a single management console」
と、説明があります。

アプリケーションや仮想デスクトップなどのデーターにアクセスできる統一的プラットフォームを提供との記載があるので、およそHorizon Workspaceのクラウド版になると想定されます。


(参考)
https://communities.vmware.com/community/vmtn/workspace-air/overview

ただし、このWorkspace Airのコミュニティ自体は、投稿0件とまだ、製品としてリリースされていない感が読み取れます。

VMWorld 2015を見てみるとEUCのセッションで、こっそりEUCの製品紹介群に含まれています。



VM World 2015の発表で、詳細が発表されそうですね。
もし、予想通りvCloud Airシリーズのようなクラウドサービスとして提供されるとなると、VMware社のクラウドサービスも、IaaSからPasSを含めた充実したサービス群になりますね。

(参考)
https://vmworld2015.lanyonevents.com/connect/sessionDetail.ww?SESSION_ID=6101






VMware社が、x86仮想化インフラストラクチャ Magic Quadrant で、リーダーに

ガートナーが発表した、x86仮想化インフラストラクチャのMagic Quadrantで、VMware社が6年連続でリーダーに選出されたとのニュースがありました。

(参考)VMware、2015年のx86サーバ仮想化インフラのマジック クアドラントで6年連続でリーダーに選出される
http://www.vmware.com/jp/company/news/releases/vmw-vmw-mq-072215.html

実際に、ガートナーのMagic Quadrantを見てみましょう。

(参考)Magic Quadrant for x86 Server Virtualization Infrastructure
http://www.gartner.com/technology/reprints.do?id=1-2JFZ1KP&ct=150715&st=sb



VMwareがリーダーであることに変わりはありませんが、マイクロソフトの位置も変わっていませんね。特徴的であることは、RedHatやOracleがニッチプレーヤーに下がっているところが気になりますね。いわゆる仮想化インフラストラクチャとしてのプレーヤーではなく、それぞれが違うソリューションでプレーしているのを感じられますね。

市場では、

 サービスプロバイダーに適しているコストがかからない、KVM。
 小さく始められる、Hyper-V。
 安定性とサポートの幅広さ、情報もたくさんあるvSphere。

といった感じでしょうか...。
 




Horizon View Administratorに残ったゴミな仮想マシン情報やプールを消す

Horizon Viewを利用して、仮想マシンを自動デプロイした上で、vCenter Server経由で直接仮想マシンを消したり、前回の投稿で行ったように、View Administratorに登録する際に、間違って同じマシンが何台も登録されてしまい、画面から消せなくなったことはありませんか?

今回はそういった、不整合になったデーターを消す方法をお教えします。

1.まずは、View Administratorのマシンにログインします。

2. コントロールパネル→管理ツール→ADSIエディタを開きます。


3.画面内の「ADSIエディタ」を右クリックし、接続をクリックします。
4. 識別名または名前付けコンテストを選択または入力するを選択し、
dc=vdi,dc=vmware,dc=int
を入力します。
続けて、ドメインまたはサーバーを選択または入力するを選択し、
localhost:389
と入力します。
名前は、好きな名称で結構です。

全部入力したら、OKをクリックします。


5.ツリーを展開して、必要な情報を探します。

OU=Server Group は、デスクトッププールの情報
OU=Servers は、各仮想マシンの情報
OU=Appliactionsは、RDSH公開アプリケーション

が格納されています。



オブジェクトが多いとちょっと大変ですが、中を見ながら必要ないものはDeleteキーで削除することで、View Administratorの画面から不要なオブジェクトが消えます!



Horizon for Linux を試す(3) Redhat Enterprise Linux 7.1 に Horizon View Agentを入れてVDIとして利用する。

では実際に、RHEL7.1を利用して、LinuxVDIを構築してみたいと思います。

まずは、仮想マシンを作成するときのポイントです。
ViewAdministratorによる自動展開機能が使えませんので、作成する仮想マシンの設定をポイントがあります。それは、ビデオメモリーのところです。マルチモニターにするときには特に注意が必要です。

ビデオメモリーの参考値は以下の通りとなります。

VRAM サイズモニタ数最大解像度
10 MB11600x1200 または 1680x1050
12 MB11920x1440
16 MB12560x1600
32 MB22048x1536 または 2560x1600
48 MB32048x1536
64 MB32560x1600
64 MB42048x1536
128 MB42560x1600
RHEL および CentOS は、vSphere 5.5 でのみこの構成をサポートします。
この構成を Ubuntu でサポートするには、カーネルを再コンパイルする必要があります。 NeoKylin では、この構成はサポートされません。

(参考)Horizon 6 for Linux のシステム要件
https://pubs.vmware.com/horizon-61-view/index.jsp#com.vmware.horizon-view.linuxdesktops.doc/GUID-E268BDBF-1D89-492B-8563-88936FD6607A.html



さらに、マルチモニターに対応できるパラメーターを追加します。


マルチモニターに対応するパラメーター
svga.maxWidth="10240"
svga.maxHeight="2048"

さて、ではOSインストールをしていきましょう。

RHEL7.1のインストール自体は普通でよいのですが、GUIが必須ですので、かならずGUI使用を選択します。


インストールが終わりましたら、必ず「VMware Tools」インストールします。
これが入っていないと、Viewのagentもインストールできません。

これで、インターネットに繋がっていることを確認します。
なぜかというと、View Agentが、JRE1.7をインターネットからダウンロードする仕組みが組み込まれているためです。
もし、インターネットに繋がる環境でない場合は、あらかじめ自分でJRE1.7をインストールしておく必要があります。このときは、必ずrpm版をインストールしてください。

また、自分のホスト名がDNSで正引きできることが必要です。
DNSの準備ができない場合は、hostsファイルに記入することで対応することも可能です。


ここまで準備ができたら、次はView Agentのインストールです。
tar xvf VMware-viewagent-linux-x86_64-6.1.1-2772438.tar

で、解凍します。

続いて、Agentをインストールします。

./install_viewagent.sh -b 10.10.10.10 -d labo.local -u administrator -p password -n RHEL71CL

パラメータがたくさん必要ですね。必要なパラメータは以下の通りです。


パラメーター解説
-bView ConnectionサーバーのIP or FQDN
-dActiveDirectoryのドメイン
(ViewConnectionサーバーが属しているADドメインをFQDNで記入)
-uVIewAdministratorの管理者ユーザー
-p-uで指定した管理者ユーザーのパスワード
-nViewAdministratorに登録する名称

さて、これでView Administratorに登録されたかを確認したいのですが、その前に、RHEL7から、サービス起動手法がsystemdに変わっているのですが、このViewAgentは、まだsystemdに対応していません。そのためRHEL7.xに互換として残されている旧来からのinit.dに起動スクリプトを配置しておきます。

cp viewagent /etc/rc.d/init.d/
chmod +x /etc/rc.d/init.d/viewagent

これで、コピーと実行権限を付与します。

サービスとして起動する必要もありますので、

chkconfig --add viewagent
chkconfig viewagent on

もやっておきましょう。

さて、VMwareのドキュメントでは、以下の記載があります。

前提条件
  1. View Agent が Linux ゲスト OS にインストールされていることを確認します。Linux 仮想マシンに View Agent をインストールするを参照してください。
  2. Linux 仮想マシンが View 接続サーバに登録されていることを確認します。View Administrator で、[View 構成] > [登録済みのマシン] を選択して、[その他] タブを選択します。各仮想マシンの状態が 使用可能 であることを確認します。
(参考)
Linux 仮想マシンを含むデスクトップ プールを作成する
https://pubs.vmware.com/horizon-61-view/index.jsp#com.vmware.horizon-view.linuxdesktops.doc/GUID-0E3E3C7F-620B-496F-8C20-BAE6F93B817C.html

しかし、実際の画面を見ても一覧に上がってきません。

ここはポイントです
しかし、大丈夫です。エラーが出ていなければちゃんと登録されています。
たぶん、これはバグかドキュメントの記載ミスだと思います。
ちなみに、プールに登録された仮想マシンはこちらの一覧にマシンが追加表示されます。

ここは無視して、プールを作成したいと思います。

まず、プールの種類は「手動」を選択します。


専用か、流動かはお好きな方でどうぞ。

さて、ここがポイントです。仮想マシンでRHELを稼働していたとしても、必ず「その他のソース」を選択します。

IDや表示名は自由でよいです

さて、詳細な設定ですが、この画面はWindowsでしか適用できないパラメーターが数多く表示されています。プロトコルはRDPでもPCoIPでもありませんし、HTML Accessも現行対応しておりません。
無視して、次に進みましょう。


次に仮想マシンの選択です。
ViewAdministratorに出ていなくても、ちゃんとプールの選択からは出てくるんです!!
私はこれを知らずに、何度もAgentの再インストールをしたら、ゴミがいっぱい残ってしまいました。

さて、サマリーが出ますので確認してOKを押します。
さて、これで完成です。
あとは、Horizon Clientから接続できればOKです!!


今回は、VMwareではサポートされていないRedhat Enterprise Linux 7.1でしたがきちんと動作しましたね。

ポイントは、
  • 仮想マシン構成時は、ビデオメモリの設定とマルチモニター用のパラメーターを設定する
  • ホスト名がDNSもしくはhostsで名前解決ができること
  • あらかじめインターネットに接続できるもしくはJREをインストールしておくこと
  • Agentのインストール完了後、ViewAdministratorを見てもマシンが登録されていなくても焦らない!
  • プールは、手動プールでその他のソースを選択する
というところですかね。

2015年8月1日土曜日

vCenter Server Aplliance 6 で自由を手に入れる(3) [続] vShere Web Clientで自動ログイン

前回、inputタグにvalueを直接記入して、ログイン時に必要なログインIDやパスワードを記入することで、ログイン時に必要なアカウント入力の手間を省く技をご紹介しました。

ご存じないかは、まずはこちらをご覧ください。
vCenter Server Aplliance 6 で自由を手に入れる(2) vShere Web Clientで自動ログイン 


しかし、これですと、ログインするためには、ユーザー名テキストボックスを一度マウスでフォーカスをONにする必要がありちょっと手間が残っていました。

今回は、この手間すらも省く技を追加でお知らせ致します。

編集するファイルは
/usr/lib/vmware-sso/vmware-sts/webapps/websso/resources/js/websso.js
となります。

まずは、SSHでvCenter Server Applianceにログインします。

※SSHでログインする前に、こちらの手順がすんでいる必要があります。
vCenter Server Aplliance 6 で自由を手に入れる(1) 準備編 (SSHでroot操作)


まずは、viで、上記のファイルを開きます。

vi /usr/lib/vmware-sso/vmware-sts/webapps/websso/resources/js/websso.js
JavaScriptの50行目を参照します

      $('#submit').prop('disabled',true);
このtrueの部分をfalseに変更します。
      $('#submit').prop('disabled',false);

たったこれだけの話しですが、これで最初からログインボタンが押せるようになります。 ちょっとした手間ですが、時間短縮にどうぞ!!