ブログトップ 記事一覧 ログイン 無料ブログ開設

仮想化でプリセールスしてるSEの一日 このページをアンテナに追加 RSSフィード Twitter

2015年07月31日

ガートナー社による仮想化製品の格付け 「Magic Quadrant」 2015年版

f:id:ogawad:20121001003300p:image:right

毎年恒例 Gartner Magic Quadrant

例年通り、今年も夏の初めに
x86 仮想化製品の新版が公開されました。


2011 年版の記事は こちら
2012 年版の記事は こちら
2013 年版の記事は こちら
2014 年版の記事は こちら


2015 年の格付け結果は...

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


f:id:ogawad:20150801131613p:image

Source: Gartner (July 2015), Magic Quadrant for x86 Server Virtualization Infrastructure



昨年までの遷移はこちらです。*1

f:id:ogawad:20150801133243j:image:w450


Gartner でいう「安定期」に入っているだけあり、さすがにもう硬直状態です。

これまで Microsoft が本気を出すと先行メーカーは速攻で駆逐されてきましたが、ある程度大きな市場にもかかわらず「時代は クラウドファースト だし!」と Microsoft はオンプレよりパブリックに傾いていますので、1位が入れ替わることは当分来ないでしょう。

テクノロジーもありますが、VMware 社は何より営業担当者のモチベーションを高め・維持させるセールスストラテジーに長けていると感じます。


なお、そのクラウドファースト市場はこんな感じです。

f:id:ogawad:20150801135717p:image

Source: Gartner (May 2015), Magic Quadrant for Cloud Infrastructure as a Service, Worldwide



データセンターインフラ製品の格付け

例年どおり、データセンターインフラ (Server, Storage, Networking) の最新 MQ を載せておきます。

サーバー

f:id:ogawad:20150801223901p:image

Source: Gartner (May 2015), Magic Quadrant for Modular Servers


ガートナーはこれまで、HP / IBM / Cisco で三強だった Blade Server のみ調査していましたが、下記のような様々なサーバーが登場していることから、「Modular Servers」としてリニューアルされ、順位が少し入れ替わりました。

  • "bricks" server ... Density-Optimized、Multi-node、Hyper-Converged など
  • "cartridges" server ... HP Moonshot など


ストレージ

f:id:ogawad:20150801223642p:image

Source: Gartner (November 2014), Magic Quadrant for General-Purpose Disk Arrays*2


最近、ストレージは SSD の低価格化による All Flash が流行りです。Gartner も昨年より「Magic Quadrant for Solid-State Arrays」をリリースしています。

f:id:ogawad:20150801225948p:image

Source: Gartner (June 2015), Magic Quadrant for Solid-State Arrays



ネットワーク

f:id:ogawad:20150801222214p:image

Source: Gartner (May 2015), Magic Quadrant for Data Center Networking


毎年のことながら、DC ネットワークはかなり日本とのギャップを感じます。

*1https://twitter.com/rspruijt/status/519867925709484032/ より

*2:reprint の公開が無いため HDS による再頒布版

2015年06月03日

vSphere 6.0 の覚え書き - vCenter Server 中間 CA 環境でホスト追加できない

f:id:ogawad:20100717202036g:image:right

一昨日、vCenter Server 6.0 の CA 機能(VMCA)をオレオレから正規 CA で署名する手順を紹介しましたが、少し考慮点があるようです。

海外のエンジニアも早々に 言及 していますが、

  • VMCA を中間認証局に設定してから 24 時間は正規 SSL 証明書を発行できない
  • この間は、vCenter 管理下に ESXi ホストを追加できない

とのこと。
私もハマりましたので、こちらも残しておきます。


vCenter 6.0 環境でホストの追加します。

f:id:ogawad:20150603212921p:image


途中、下記のようにホストの SSL 証明書の置き換えが伝えられます。

f:id:ogawad:20150603164330p:image


しかしながら、VMCA を中間認証局に設定してから 24 時間以内の場合は、
次のエラーでホストの追加に失敗してしまいます。

一般的なシステムエラーが発生しました:

Unable to get signed certificate for host: hostname.fqdn.
Error: Start Time Error (70034).

f:id:ogawad:20150603212920p:image


f:id:ogawad:20150603212919p:image
クリックすると拡大します。


24 時間経過後に実行すると、今度は問題なく成功します。

f:id:ogawad:20150603212918p:image
クリックすると拡大します。


マニュアルにもあるとおり、
vCenter の SSL 証明書を置き換えはホストを追加する前に実施した方が良い
のですが、この不具合により作業後 24 時間は次のステップに進めません。

いずれ修正されると思いますが、
それまでは構築作業が一日ストップしかねないのでご注意ください。

2015年05月31日

vSphere 6.0 の覚え書き - vCenter Server の SSL 証明書を正規版に差し替える

f:id:ogawad:20100717202036g:image:right

以前より何回か紹介した vCenter オレオレ証明書 の差し替え手順が、vSphere 6.0 でまた大幅に方法が変わったようです。
備忘録を兼ねて残しておきます。


f:id:ogawad:20150601222950p:image


vSphere 5.5 はアプライアンス版であれば驚くほど簡単になったと喜んでいたのですが、vSphere 6.0 ではオレオレ証明書というか、vCenter Server 自体に「VMCA」という認証局機能が搭載されています。

つまり、オレオレCA に格上げされてしまいました。

したがって、vSphere 6.0 では単なる SSL サーバー証明書の署名というより、vCenter VMCA を中間認証局として署名する作業となります。


f:id:ogawad:20150601223917p:image
http://pubs.vmware.com/vsphere-60/topic/com.vmware.vsphere.security.doc/...


なお、CA になったことからも推察できるとおり、vCenter Server の管理下になった ESXi ホストは SSL 証明書が自動で置き換えられるそうです。

ですので、社内 CA など正規の SSL 証明書を使う予定の場合は vCenter Server インストール後速やかに作業する ことを強くお勧めします。

※ vCenter はアプライアンス版(VCSA)を想定しています。
※ 所要時間は 20 分弱です(証明書関連に明るい場合)。



CSR の生成

vCenter Server 6.0 は、アプライアンス版・Windows 版共に CSR を自動生成してくれる「vSphere 6.0 Certificate Manager」が付属しています。


1. ssh で VCSA に接続します。ユーザーは administrator@vsphere.local ではなく、必ず root でログインしてください。

2. 表示される画面のとおりに bash シェルを有効にします。

f:id:ogawad:20150601230932p:image


3. 警告が表示された後 [vcserver:~ #] のプロンプトに変われば OK です。。

4. /usr/lib/vmware-vmca/bin/certificate-manager を実行します

f:id:ogawad:20150601233012p:image


5. 2. Replace VMCA Root Cert... を選択します。

6. SSO のパスワードを入力し、1 Generate Certificate Sign... を選択します。

7. /tmp などの適当な場所に出力し、一旦ツールを終了します。

8. 出力された CSR をダウンロードします。

※ WinSCP を利用する場合は KB2107727 の方法でログインシェルを一時的に変える必要がありますが、ファイルの中身はテキストですのでターミナル上でクリップボードコピーしても構いません。



CSR による署名

私の環境(Windows Server 2012 R2 ADCS)の場合、
KB2112009 にあるような専用のテンプレートを用意しなくても、既定の「下位の証明機関」テンプレートで要件を満たしていました。


f:id:ogawad:20150602025238p:image


署名されたファイルは単体ではなく、チェーン (*.p7b) でダウンロードします。DER と BASE64 はどちらでも構いません。



PEM ファイルの生成

上から「VMCA」「上位CA」「ルート証明書」と BASE64 文字列が並ぶ PEM 証明書を生成します。

1. 先ほどダウンロードした *.p7b ファイルをダブルクリックで開きます。

2. スナップインにて、2つの証明書それぞれを X.509 BASE64 で出力します。

3. 以前の記事 を参考にしつつ、CA 証明書チェーン certnew.p7b をダウンロードし、こちらも X.509 BASE64 で出力します。

4.  「2 で出力した CA」→「2 で出力したもう片方」 → 「3 で出力した CA 証明書チェーン」 の順で 単一のテキストファイル に統合します (concat) 。



PEM ファイルのアップロード

1. SCP やクリップボードを通じて PEM ファイルを転送します。

2. 再び certificate-manager を実行し、22 の順に選択します。

3. PEM ファイルと KEY ファイルの場所を指定します。KEY ファイルは CSR を出力したディレクトリにあるはずです。

4. 証明書の発行先情報を埋めると、証明書の置き替えが開始され、vCenter サービスが再起動します。


f:id:ogawad:20150602022635p:image


上記のメッセージが出たら、置き換え正常終了です。

ブラウザを開いて証明書エラーが出ないことを確認してください。


f:id:ogawad:20150602022629p:image


f:id:ogawad:20150602075811p:image:left






階層構造は左のようになるはずです。



なお、執筆時点の vCenter 6.0 では、vCenter Server を中間 CA にするとしてから 24 時間はホストを追加できない不具合があるようです。詳しくは こちら で。



参考情報:

2015年04月30日

Software-Defind xx と対応ハードウェア - VXLAN オーバーヘッド (2)

f:id:ogawad:20121001003301p:image:right

「仮想スイッチの負荷」編: (1)
「VXLAN オーバーヘッド」編: (1) (2)


前回、サーバー上での VXLAN の利用は CPU にそれなりの負荷が掛かることをご紹介しました。今回は後半ということでこの課題の解決策を探っていきたいと思います。


VXLAN のオーバーヘッドの軽減方法

VXLAN によるサーバー過負荷の対策方法をいくつかまとめてみましょう。


  • RSS (Receive Side Scaling)
    データ転送処理を単一のプロセッサコアに集中させないように
    複数のコアに分散させるマルチスレッド的技術
  • LSO/TSO (TCP Segmenation Offload)
    MTU サイズに収めるためのパケット分割を CPU で処理するのはなく
    NIC に任せるハードウェアオフロード技術
  • VXLAN Task Offload
    VXLAN を仮想スイッチで終端させる場合に CPU で処理するのはなく
    NIC に任せるハードウェアオフロード技術

RSS はロスを抑えるというより負荷分散なので、ちょっと違うかもしれません。

次のグラフは NIC/HBA のメーカーである Emulex の資料から引用したものです。
16 コアのサーバー機に仮想マシンを 8 台収容し、vSphere 5.5 で VXLAN を利用した場合に、オーバーヘッドがどれくらいかについて言及されています。


f:id:ogawad:20150401015356p:image

f:id:ogawad:20150401015355p:image
VXLAN on Emulex OCe14000 Network Adapters Support VMware NSX


利用している CPU は E5-2690 ですので、かなり良いものです。

RSS だけだと CPU 使用率が 50% を超えますが、VXLAN Offload を利用できると半分くらいに抑えられるとのこと。

VXLAN の終端を仮想スイッチに置く場合に CPU パワーが奪われると、業務性能や統合率に大きく影響しますので VXLAN Task Offload はとても重要です。



VMware 環境での VXLAN Packet Offload の設定方法

もちろんベンダー依存ではありますが、VMware 環境でどのように設定するかについては下記のドキュメントがお勧めです。スクリーンショット付きで詳しく書かれていますのでイメージしやすくなっています。


対応製品は?

VXLAN Task Offload の対応状況ですが、各社の最新モデルで利用可能です。

上記 Emulex の資料では Intel NIC を槍玉に挙げられていますが、その Intel も 20G/40Gbps 対応の最新シリーズ XL710 でようやく対応するそうです。

f:id:ogawad:20130311084603j:image:right

  • Emulex: OCe14000 シリーズ
  • Qlogic: 3400/8400 シリーズ
  • Intel: XL710 シリーズ
  • Mellanox: ConnectX-3 Pro シリーズ

※上記は代表的なものです


NIC 選びの際、端子形状と速度、あとはメーカーくらいしか気にしないのがほとんどですが、同じメーカーでも色々と機能差があります。今回の VXLAN のようにパフォーマンスを大きく左右することも。。。

とは言っても、NIC の最新状況まで把握してられないと思いますので、販売する OEM メーカーに確認するのが安全かもしれません。




正直なところ、オフロード系は効果・安定稼働ともにデバイスドライバの出来や OS との相性に大きく左右されます。下記にもありますが、相性問題が広く知られているのは何と言っても「VMQ」です。

マイクロソフト Network & AD サポートチーム公式ブログ
仮想マシンの通信速度遅延 - VMQ 無効化手順
http://blogs.technet.com/b/jpntsblog/archive/2013/04/12/vmq.aspx


こう書いてしまうと「どの NIC ベンダーが安全なの?」と聞かれそうですが、この場で書くとさすがに怒られてしまいます。気になる方はどこかで私を見つけた際にこそっと聞いてください(笑)

2015年03月31日

Software-Defind xx と対応ハードウェア - VXLAN オーバーヘッド (1)

f:id:ogawad:20121001003301p:image:right

「仮想スイッチの負荷」編: (1)
「VXLAN オーバーヘッド」編: (1) (2)


前回 から3か月が経ってしまいましたが、VMware NSX などで脚光を浴びている L3 オーバーレイの「VXLAN」について、サーバーハードウェアの視点から考えてみたいと思います。


VXLAN はトンネリング技術

L3 オーバーレイと書きましたが、簡単に言えば VXLAN は トンネリング です。

"トンネリング" と言うと、私は Web フォームからの送信データを暗号化する SSL が思い浮かびます。

昔の話になりますが、Web サーバーが SSL (HTTPS) が話せるようにすると、CPU 負荷が一気に上がる課題がありました。SSL を使うか使わないかでサイジングやレンタルサーバー費用が大きく変わると言われたほどです。


f:id:ogawad:20150401002747p:image
※ 「安心」と伝えるための SSL の利用有無でサーバー負荷が大きく変わった時代がありました。。。


ネットワークの世界での「トンネリングする」は、パケットを カプセリング することになります。つまり、ネットワーク機器にとって余分な仕事が増えるわけで、設計する側としてはオーバーヘッドが気になるところ。


試しに Google 検索で「VLAN オ」までキーを打ち込んでみました。


f:id:ogawad:20150401004859p:image

。。。検証でハマった人もいるのか、かなり注目を浴びているようです。


誰でも見れるベンチマーク結果として挙げられるのが次の VMware 社資料。
メッセージサイズが小さい場合で CPU 負荷は 60% 増しだそうです。


f:id:ogawad:20150401010524p:image
VMware VXLAN Performance Evaluation on VMware vSphere 5.1


では、どうすればこの過負荷を抑えられるでしょう?
最新テクノロジーを交えて 次回 解説してみたいと思います。