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

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

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 の「挙動」を理解しておく必要がありそうです。

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

2014年03月31日

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

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


前回 の最後にも少し触れたとおり、今回は「SMB マルチチャネル」について。

SMB Multichannel は Windows Server 2012 からの新機能で、 SMB トラフィックのロードバランスや帯域増強、パス障害に対応するマルチパス技術です。“NIC チーミングの SMB/CIFS プロトコル限定版”と言えばイメージしやすいかもしれません。

デフォルト設定は On。つまり、デフォルトでは通信相手に対して SMB の通信パスが複数ある場合、そのすべてのパスが自動的に使われます。


Multichannel の特徴

Multichannel は SMB/CIFS プロトコルに限定で、しかもマルチホーム。
更にパス障害時の切り離しが遅い。。。

良いところが無いように思えますが、Multichannel の特徴は次の2つ。


  • Ethernet フレームを持たない InfiniBand の IPoIB や RDMA でも利用できる
  • 単一セッションのスループットが向上する可能性がある

前者については 前回 の記事のとおり。

今回取り上げたいのは後者です。NIC Team では 1Gbps のパスをリンクアグリゲーションでいくら束ねても、セッションあたりのスループットは 1Gbps から増えません。これに対し、Multichannel は単一セッションでもスループットが倍増します。


@IT Windows Insider:
Column「チーミングを行っても単一スループットは倍増しない?」
http://www.atmarkit.co.jp/ait/articles/1402/06/news129_2.html



単一セッションなのにスループットが倍増する理由

では、どうして Multichannel だとスループットが倍増するのでしょう?


f:id:ogawad:20140330164828p:image


これを理解するには、NIC Team と Multichannel がそれぞれどのレイヤーでコントロールしているか考えてみると早いです。

前回も解説したとおり、NIC Team は Ethernet (L2) ヘッダーの情報で送信パスを決定しますが*1、Multichannel は L7 ベースでコントロールするため、この時点では送信元や宛先に関するヘッダー情報は持っていません。このため、宛先などは一切考えず、到達できるすべてのパスを用いてラウンドロビン的に送ろうとします。


言葉では伝えにくいため図にしてみました。

まず、送信ファイルは、SMB プロトコルのブロックサイズ(ウィンドウサイズ)である 64 〜 1,024 KB に分割されます。

f:id:ogawad:20140330145344p:image


そして、分割されたファイルを転送する*2 のですが、、、


NIC Team の場合: 1 つのパスしか利用されません。

f:id:ogawad:20140331232848p:image


Multichannel の場合: 到達できるすべてのパスを利用します。

f:id:ogawad:20140330164826p:image


これが、NIC Team では不可能な "ワイヤースピード超え" を Multichannel であれば実現できる理由です。

では、SMB 限定用途の場合、NIC Team より Multichannel にすべきでしょうか?
このあたりについて 次回 触れたいと思います。

*1:場合によっては L3 ヘッダーも使います

*2:実際は Ethernet MTU で更に分割しますが、ややこしくなるため省略します