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

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

2014年08月18日

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

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

毎年恒例の「Gartner Magic Quadrant」

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


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


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

Gartner Magic Quadrant for x86 Server Virtualization Infrastructure (July 2014)
http://www.gartner.com/technology/reprints.do?id=1-1WR7CAC&ct=140703


f:id:ogawad:20140817011812p:image

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



過去 5 年間の遷移を見てみましょう。

「Microsoft MVP」「Citrix CTP」「VMware vExpert」三冠でおなじみ、PQR の Ruben Spruijt 氏が 用意 してくれています。


f:id:ogawad:20140817011108p:image


Microsoft (Hyper-V) が良い調子ですね。

Oracle と Citrix が評価を下げていますが、これは会社の評価ではなく "Server Virtualization Infrastructure" 、つまり「Oracle VM」「XenServer」を指しているものと思います。




データセンター製品の格付け

今年も仮想化に欠かせないデータセンター製品 (Server, Storage, Network) についても載せておきます。



Server

f:id:ogawad:20130707203159p:image
Source: Gartner (April 2013), Magic Quadrant for Blade Servers
(こちらは 2013 年のものです。今年は Q3 に更新するようなので リリースされたら差し替えます)


データセンターで仮想化と言えば ブレードサーバー
実際、ガートナー社は x86 サーバーでブレードサーバーしか調査していません。



Storage

f:id:ogawad:20140817010700p:image
Source: Gartner (March 2014), Critical Capabilities for General-Purpose, Midrange Storage Arrays


ストレージは今回より MQ ではなく「Critical Capabilities」というレイティングに変わりました。Midrange Storage Arrays と High-End Storage Arrays がありますが、上記は「Server Virtualization and VDI」カテゴリのある前者のものです。

色々詳しく分析されていますが、仮想化, OLTP, Analytics なら HP 3PAR
ストレージ統合やクラウドは NetApp FAS がベストな選択とのこと。



Network

f:id:ogawad:20140817013743p:image

Source: Gartner (April 2014), Magic Quadrant for Data Center Networking


こちらはネットワークの中でも、データセンター向けのネットワーク機器です。
ダウンリンクポートが 10Gbps なスイッチが中心ですので、Cisco であれば Catalyst ではなく Nexus になるかと思います。

その Cisco さんも "leaders" ではない、まだ発展途上な領域ですが、
ソフトウェアベンダーの VMware が NSX で突如良いポジションでノミネートされたのが興味深いところです。

2014年07月28日

AD ドメインコントローラーと同居できないアプリ - (2) vSphere Client 5.5

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

(1) (2)

vSphere 環境の管理コンソールは、
従来からの Win32 (C#) 版 vSphere Client から
ブラウザベースの vSphere Web Client に移行していることはご存じのとおり。

現行バージョンである vSphere Client 5.5 は、起動時に下記のような警告メッセージが表示されることに気づかれた方も多いと思います。


f:id:ogawad:20140728092135p:image


起動画面の警告表示のほかに、vSphere Clinet 5.5 では Active Directory
ドメインコントローラーマシンへインストールができなくなりました。

インストールしようとするとエラー終了してしまいます。

つまり、vSphere Client 5.5 はインストール要件が厳しくなったのです。


f:id:ogawad:20140728093939p:image

f:id:ogawad:20140728100237p:image:w376



環境チェックを回避する方法

vSphere 5.5 のインストール環境のチェックは、回避する方法が用意されています。
これは非常にシンプルで、インストーラーに次の引数を渡すだけです。

VMware-viclient.exe /v "SKIP_OS_CHECKS=1"

この引数を付けてインストーラーを起動すると、先ほどの環境チェックが実施されないため、ドメインコントローラーに vSphere Client 5.5 をインストールできます。


f:id:ogawad:20140728100633p:image:w400

f:id:ogawad:20140728100236p:image:w400

f:id:ogawad:20140728100235p:image:w400


最近は仮想アプライアンスの浸透により、OS コストの掛かる Windows Server はインフラの世界で少しずつ減っているような気がします。PoC などの検証環境では、AD 1台しか Windows OS が無いケースもあり、覚えておいて損はないと思います。

もちろん、本番環境では利用しないようにしましょう。

2014年06月30日

AD ドメインコントローラーと同居できないアプリ - (1) RD 接続ブローカー

f:id:ogawad:20121001003258p:image:right

(1) (2)

プリセールスは、その営業活動の一環として
商材の動作検証やデモンストレーションのために小さな環境を構築することが多々あります。

“デモセンター”といった自社のショールーム施設を活用できれば良いですが、
様々な理由でそうもいかないケースもあります。特に、インフラ系の商材は管理サーバーが増えがちで、少ないリソースでどれだけ安定かつリッチな環境を整えられるかがエンジニアとして腕の見せどころです。

したがって、各種管理サーバーをできるだけ同居してまとめる必要がありますが、当初の計画を崩されてしまいがちなのが「Active Directory ドメインコントローラーにインストールできない」問題。


f:id:ogawad:20140701072552p:image


本番環境であればドメインコントローラーはできるだけクリーンな方が良いのは分かるのですが、上の写真のように影響があるとは考えづらい 管理コンソール ですら弾かれてしまうケースが増えてきています。

ということで、Active Directory ドメインコントローラー上で動かないアプリとその対策方法についての Tips です。



RD 接続ブローカーのみドメインコントローラーと共存できない

「ドメインコントローラー上で動かないアプリ」として、個人的に最初に思いつくのは Windows Server 2012 の RD 接続ブローカー (RDB)

Windows Server 2012 は旧バージョンでは可能であったドメインコントローラーと RDS コンポーネントの同居ができなくなっています。


f:id:ogawad:20140701074722p:image


例えば、MS-VDI の小規模環境を作ろうと思った際に、

  • リモートデスクトップ Web アクセス
  • リモートデスクトップ ゲートウェイ
  • リモートデスクトップ ライセンス
  • リモートデスクトップ 仮想化ホスト*1
  • リモートデスクトップ 接続ブローカー

が必要になりますが、なぜか「リモートデスクトップ 接続ブローカー」のみがドメインコントローラーと同居できないのです。ちなみに、ドメインコントローラー以外のマシンであればこれらはすべて同居できます。

この制約を知らないでやってしまうと、インストール処理が始まって他の RD コンポーネントのインストールが終わったところで「失敗」とだけ表示されます。失敗した理由は表示されません。

同居できないのであれば RD コンポーネント群専用に 1 つ仮想マシンを用意するので、事前に弾いてくれれば助かるのですが、、、



修正パッチがリリース

Windows Server 2012 の役割サービスウィザードであればいくらでも事前チェックできるのに不親切だな、と思っていたところ、どうもこれはバグだったようです。
1年掛かりましたがパッチがリリースされました。


Microsoft Article ID 2871777: A servicing stack update is available for Windows RT, Windows 8, and Windows Server 2012: September 2013
http://support.microsoft.com/kb/2871777


これで無事に管理サーバーマシンの数を減らすことができました。


f:id:ogawad:20140701080647p:image

f:id:ogawad:20140701080645p:image

f:id:ogawad:20140701080644p:image

*1:Hyper-V 親パーティションにインストール

2014年05月31日

Windows Server 2012 R2 のネットワークの注意事項 - SMB Multichannel (3)

f:id:ogawad:20121001003258p:image:right


Windows Server 2012 以降、SMB Multichannel は既定値は On です。

バグかアルゴリズムを完全に掴めていないか分かりませんが、Multichannel はたまに変な動きをします。SOFS など、少し手の込んだシステムを組んでいる場合は経験があるかもしれません。トラブルを最小限に抑えるためにも、ネットワーク管理者やサーバー管理者は挙動とルールを把握し、安易に "自動" に任せずコントローラブルな状態にしておきたいところです。



SMB Multichannel によって意図しない通信経路になる?

例えば、1 台のサーバーに次のような 4 つの NIC が搭載されているとします。

  • NIC A: 10 Gbps
  • NIC B: 10 Gbps
  • NIC C: 1 Gbps
  • NIC D: 1 Gbps

この場合、NIC A〜D の 4 枚がすべて SMB を有効にしていたとしても、既定の Multichannel On の場合は A と B しか使われません。
Multichannel は最も速い NIC を自動選択します。


f:id:ogawad:20140429223527p:image


より正確に述べると、多種多様な NIC がある場合、速度や機能 (RSS, RDMA, ...) が最も優れている NIC のみが利用されます。

もし、この図において「NIC A は RSS 対応」「NIC B は RSS 非対応」であった場合、A のみの通信となるようです。Active-Active にならないだけでなく、A に障害が発生した場合は B に切り替わらない可能性もあります。


また、この図で A/B は業務系ネットワーク、C/D は管理系ネットワークだったとします。ご存じのとおり、Windows サーバーはドメインログオンなどの関係で管理系でも SMB が必要とされますが、管理系通信をしたいために C/D の IP アドレスに接続しても、勝手に A/B のネットワークで通信されてしまうのです。

このように、アーキテクトの方が時間を掛けてきちんとネットワーク設計を行ったとしても、Windows Server 2012 以降では、既定で有効にされている SMB Multichannel によって意図しない通信経路が使われてしまい、ネットワークバランスが崩れてしまうことがあります。


Hyper-V や NIC Team を利用する場合も注意が必要です。

Team や仮想スイッチ配下の仮想 NIC は RSS などの機能が無効化されることが多々あります。この場合、RSS 対応の物理 NIC とは Multichannel にならず、物理 NIC 側のみが使わてしまいます。トラブルに発展しやすいので注意しましょう。



SMB Multichannel をコントローラブルな状況にする

前述のようなトラブルを回避し、管理者がコントローラブルな状態にしておくために、いくつかの設定方法を残しておきたいと思います。


SMB Multichannel を一切使わない

当たり前ですが、最もシンプルなのは Multichannel を元から切ることです。

前者はネゴシエーション送信の On/Off、後者はネゴシエーション受信の On/Off であり、いずれかを off にすれば Multichannel 通信は行いません。


現在の設定確認

Get-SmbClientConfiguration | fl *Multichannel
Get-SmbServerConfiguration | fl *Multichannel

有効化

Set-SmbClientConfiguration -EnableMultiChannel $true
Set-SmbServerConfiguration -EnableMultiChannel $true

無効化

Set-SmbClientConfiguration -EnableMultiChannel $false
Set-SmbServerConfiguration -EnableMultiChannel $false

実行例

PS C:\> Get-SmbClientConfiguration | fl *Multichannel

EnableMultiChannel : True

PS C:\> Set-SmbClientConfiguration -EnableMultiChannel $false

確認
この操作を実行しますか?
ターゲット 'Modify' で操作 'SMB Client Configuration' を実行しています。
[Y] はい(Y)  [A] すべて続行(A)  [N] いいえ(N)  [L] すべて無視(L)  [S] 中断(S)  [?] ヘルプ
(既定値は "Y"):
PS C:\> Get-SmbClientConfiguration | fl *Multichannel

EnableMultiChannel : False

PS C:\> Set-SmbClientConfiguration -EnableMultiChannel $true

確認
この操作を実行しますか?
ターゲット 'Modify' で操作 'SMB Client Configuration' を実行しています。
[Y] はい(Y)  [A] すべて続行(A)  [N] いいえ(N)  [L] すべて無視(L)  [S] 中断(S)  [?] ヘルプ
(既定値は "Y"):
PS C:\> Get-SmbClientConfiguration | fl *Multichannel

EnableMultiChannel : True

PS C:\>


SMB Multichannel の通信経路を制御する

Multichannel を完全に無効にするのではなく、有効にしながら管理下に置きたい場合は、次のコマンドを利用して Multichannel に含めるパスと除外するパスを手動でコントロールしましょう。宛先サーバーごとに静的設定が可能です。


現在の通信経路の確認

Get-SmbMultichannelConnection

Multichannel による通信経路の静的指定

New-SmbMultichannelConstraint -ServerName <接続先> -InterfaceIndex <NIC#>

NIC# はカンマ区切りで入力します。
Get-SmbClientNetworkInterface で確認可能です。

PS C:\> Get-SmbClientNetworkInterface | sort *Index

Interface Index  RSS Capable  RDMA Capable  Speed    IpAddresses       Friendly Name
---------------  -----------  ------------  -----    -----------       -------------
14               False        False         0  bps   {fe80::5efe:1...  isatap.{726DB36...
15               False        False         0  bps   {fe80::5efe:1...  isatap.{5D52604...
16               False        False         3 Gbps   {2002:1092:5d...  6TO4 Adapter
19               False        False         0  bps   {fe80::200:5e...  isatap.{845AB79...
21               True         False         0  bps   {192.168.0.1,...  Team (192.168.0...
24               False        False         10 Gbps  {16.146.93.81     vEthernet (16.1...
26               False        False         10 Gbps  {192.168.11.2     vEthernet (192....

PS C:\>


route の静的設定を思い出しますね。

なお、設定は Persistent、つまり、マシンを再起動しても設定が永続的に保持されるそうです。不揮発領域にはレジストリを利用しているとのこと。手動で指定した静的設定をすべてリセットするには、下記のコマンドを利用します。

Get-SmbMultichannelConstraint | Remove-SmbMultichannelConstraint

2014年04月29日

Windows Server 2012 R2 のネットワークの注意事項 - SMB Multichannel (2)

f:id:ogawad:20121001003258p:image:right


前回 の内容から、SMB 通信限定、かつ障害対応を無視できるのであれば Multichannel の方が優れているように感じたでしょう。

しかし、その決断をするにはまだ早いかもしれません。
確かに机上ではそうなのですが、実環境では実はそう簡単ではないのです。



複数のネットワークでラウンドロビン?

下図は前回も紹介した SMB Multichannel によるラウンドロビン。
ファイルを細切れにして並列転送することでワイヤースピード超えを実現します。


f:id:ogawad:20140330164826p:image


仕組みは非常に簡単であり、実装は難しそうには見えません。
ではなぜ、多くの NIC Team ではラウンドロビンを実装しないのでしょうか?


上図は2台のサーバーだけの世界でしたが、
実際の環境では各セグメントに様々なデバイスが繋がっています。

ここで少し考えてみてください。


  • Multichannel を構成する複数のネットワークは全く同格でしょうか?
  • 一部のネットワークは業務系や管理系だったりしないでしょうか?
  • それぞれの負荷は均等でしょうか?
  • 一部のネットワークだけ高性能なスイッチにしていないでしょうか...?

f:id:ogawad:20140429191015p:image


そうです。実際の環境では、複数のネットワークパスを利用してラウンドロビンで並列転送しても、なかなか順番どおりに届かない のです。

この図のとおり、宛先ホストはランダムに届くピースをジグゾーパズルのように埋めていかなければなりません。


「シーケンシャルでもパラレルでも、遅いネットワークに引きずられるので結局同じなのでは?」と思われる方もいるでしょう。しかし、ピースがランダムで虫食い状態に埋めていくのと、端から順番にピースが届くのでは、受信サーバーの負担は全然違います。


道路にバイパスができて到着地までルートが増えると渋滞は減るでしょう。
しかし、2つのルートの所要時間は全く同じとは限りません。走行する時間帯によって差も生じます。

もし、ゴール地点ではゼッケンの順番どおりに駐車しなければならない場合、
駐車場は虫食いだらけ。広大の駐車スペースを確保して各車の到着を待つことになってしまいます。

これに対し、NIC Team はシーケンシャル転送です。
送られて来るピースは順序保証されているため、各車はゼッケンの番号どおりに到着します。適度に溜まったところで解散できるため(メモリ解放)、駐車スペースがそれほど確保できなくても回していけるのです。


実環境では1台のサーバーがやり取りする相手は1台だけではないでしょう。
“サーバー” なのですから複数の相手と同時にやり取りすることの方が多いはず。
広大な駐車スペースとジグゾーパズルが何セットも必要になりますが、はたしてそのサーバーは効率的に動けるでしょうか...?



検証環境と本番環境は違う

1 対 1 の検証環境では、Multichannel でスループットが綺麗に倍増するでしょう。但し、本番環境ではそう上手くいかないだけでなく、トラブルの種になり得ます。

以前も同じ表現をしましたが、「世界の限られた検証環境と本番環境は違う」ということを意識して設計する必要がありそうです。

逆に言えば、「自宅ネットワーク」のように帯域が常にガラ空きであったり、「ストレージ専用」ように途中で輻輳を起こしにくいクローズネットワークであれば、トラブルなく運用できるかもしれません。実際、比較的クローズと言える SAN の世界では、マルチパスにラウンドロビンが広く採用されています。



トラブルの多い SMB Multichannel の挙動を理解する

「ファイル分割 + ラウンドロビン」によるパフォーマンストラブルはさておき、
現行の Windows では Multichannel は既定で On になっています。Off にする方法はコマンドのみですので、Multichannel 有効のままで動かしている Windows Server も多いと思ってます。

こういった背景もあり、サーバー管理者もネットワーク管理者も SMB Multichannel の「挙動」を理解しておく必要がありそうです。

このあたりを 次回 まとめてみたいと思います。