2012年12月13日木曜日

Windows Server 2012 のサーバーマネージャー

Windows Server 2012の「サーバーマネージャー」で管理できるのは、Active Directoryドメイン内のWindows Server 2012だけ、と思っていたのですが、違うようです。

ただいま、Windows Server 2012の書籍を執筆中でして、その原稿をチェックしていて知りました(担当の方、どうもありがとうございます)。なお、私自身は検証していませんので、あしからずご了承ください。

●管理対象

  • Windows Server 2003はオンラインまたはオフラインのみ表示可能
  • Windows Server 2008/2008 R2はWindows Management Framework 3.0をインストールすれば管理可能

●ワークグループの場合

  • Windowsファイアウォールで「Windows リモート管理 (HTTP 受信)」を有効化
  • 管理されるサーバーで、以下のPowerShellコマンドレットを実行
    Set-Item WSMan:\localhost\Client\TrustedHosts 管理するサーバー –concatenate

書籍の発売は、来年を予定しています。詳細が決まれば正式に告知させていただきます。

2012年11月27日火曜日

Windows Server 2012のNICチーミング

今回も、保留していたお客様からの質問に対する回答です。

Windows Server 2012には、OSネイティブのNICチーミング機能が含まれます。これは、複数のNIC(同一速度のイーサネットに限られます)をまとめた仮想的なNICを作ることで、可用性と性能を向上させる機能です。

NICチーミングには、スイッチングハブ(スイッチ)の構成を必要とする「スイッチ依存モード」と、スイッチングハブの設定が不要な「スイッチ非依存モード」があります。スイッチ非依存モードは、同じスイッチでも別々のスイッチでも構成できます。

スイッチには、MACアドレステーブルが構成されますが、複数のポートに同じMACアドレスがあることは想定されていません。「スイッチ依存モード」はこの問題を解決するために、IEEE 802標準の規約を利用します。

一方のスイッチ非依存モードは、スイッチ側の設定が一切不要です。これは、以下の原理で動作しているためです。

まず、インバウンドデータ(チーミングNICへの着信)は、チーミングNIC構成時に自動的に選択された「プライマリNIC」のみが処理します。チーミングNICのMACアドレスはプライマリNICのMACアドレスになります。ARP要求に対する応答は単一NICのみが応答するため、スイッチは混乱しません。負荷分散モードでもプライマリNICは1枚に限定されます。

2枚のNICを使ったアクティブ・スタンバイ構成の場合、常にプライマリNICのMACアドレスが使われます。アクティブなNICのリンクがダウンした場合は、プライマリNICのMACアドレスがスタンバイ側で使われるため、チーミングNICのMACアドレスは(およびもちろんIPアドレスも)変化しません。同時には1枚のNICしか使わないので、アウトバウンド(チーミングNICからの発信)でも不都合は生じません。

負荷分散をしている場合のアウトバウンド接続(発信)は、指定のアルゴリズムによって負荷分散されます。この時、イーサネットフレームにはNICハードウェア固有のMACアドレスが使われ、スイッチのMACアドレステーブルにはこれが登録されます。単一IPアドレスに複数MACアドレスが対応してしまいますが、これで問題は起きないようです(理由は後述)。

NIC-Team

図は、スイッチ非依存モード、アドレスによるハッシュでチーミングNICを構成し、負荷分散した状態で、ネットワークデータをキャプチャしたものです。送信元MACアドレスが2つあるので、赤と青で色分けしました。接続ごとに負荷分散されていることが分かります。

L2スイッチ内部では、MACアドレスとポートが紐付きますが、IPアドレスとは無関係です。ARPに対する応答はプライマリNICのみが行うため、IPアドレスとMACアドレスの対応も問題ありません。既存のARPテーブルと矛盾を起こす可能性はありますが、IPアドレスとMACアドレスの対応は、もともと変化する可能性があるものなので(たとえばフェールオーバークラスター)、こちらも問題にはならないはずです。

以上のことから分かるように、スイッチ非依存モードでは着信の負荷分散ができません。そのため、効果的に利用できるのは以下の場合に限られます。

  • アクティブ/スタンバイモード…2枚のNICのうち、一方のみを使い、障害発生時に自動切り替え
  • サーバーからの発信データが多い場合(たとえばWebサーバー)

以上です。見落としている条件があるかもしれませんので、お気づきの点があればブログにコメントをいただくか、メールアドレスをご存じの方はメールでお問い合わせください。

回答が遅くなって申し訳ありませんでした。

【参考】 http://www.aidanfinn.com/?p=12924 (英語)

2012年11月18日日曜日

Windows Server 2012 Hyper-VとNICチーミング

どうしても分からなかったので、ogawadさんに助けを求めました。

Windows Server 2012は、OSレベルでNICチーミングがサポートされます。チーミングされたNICは、1つのNICに見えるので、それをHyper-Vの外部仮想スイッチ(仮想ネットワーク)として割り当てることができます。

また、Hyper-V仮想マシンに割り当てた仮想NIC同士でもチーミングが可能です。つまり、複数の物理NICそれぞれに仮想スイッチを割り当てて、仮想マシン内でチーミングを行なうこともできます。

MSC0374G-T1-01-2

この時、仮想マシンでチーミングすると、仮想スイッチを通っているためVMで物理NICのリンクダウンが検出できないのではないか、というご質問をいただき、即答できないでいました。

結論を言うと、後者の場合でもリンクダウンを検出できます。

NIC-TEAM-2

SR-IOVの有無とか、いろいろ考えてる前に試してみればすぐ分かることでした。お恥ずかしい限りです。

Hyper-V仮想マシンの設定に「NICチーミングを許可」する設定があります。これがオンになっていると、物理NICの状態を伝えてくれるようです。

逆に、SR-IOV を利用する場合、自身にスイッチ相当の機構が埋め込まれるので、利用するNICによっては、ホストOSにすらリンクダウンが通知されないものがあるそうです。

SR-IOVの方がハードウェア情報を伝えやすいと思っていたのですが、そうでもないようです。

SR-IOVについてはogawadさんのブログの「Windows Server 2012 Hyper-V の SR-IOV 構築手順 (3)」に詳しいので、そちらを参照してください。コメント欄には私の質問も載っていて、ちょっと格好悪いのですが、分からなかったものは仕方ありません。

ところがここでもうひとつの疑問が生まれます。物理NICのリンクがダウンしていても、仮想スイッチは生きているので、仮想マシン同士は通信できるはずです。しかし、チーミングドライバが物理NICのリンクダウンを伝えると、通信ができなくなってしまいます。

今度調べようと思っていたら、これまたogawadさんが調べてくれました。

ゲストチーミングしていない場合は、アップリンクとなる物理NICがダウンしても同一の仮想スイッチにつながっていれば引き続き通信できます(従来通りの動作です)。

c

ゲストチーミングしている場合は、アップリンクとなる物理NICがダウン(全滅)すると)、同一の仮想スイッチにつながっていても通信できないということです。これは、ゲストOSからリンクダウン状態として認識されるためのようです。

ogawadさん、いろいろどうもありがとうございました。

2012年10月26日金曜日

Windows Server 2012 Hyper-Vのレプリケーション

一部お客様向けに Windows Server 2012 の研修が始まり、私が担当しています。

さて、先週Hyper-Vレプリケーションで誤解を招く(というより、ほとんど間違っている)表現があったので、この場を借りて補足しておきます。

Windows Server 2012では、Hyper-V仮想マシンを他の物理マシンに連続的に複製できます。複製間隔はおよそ5分、さらに1時間に1回スナップショットを指定した世代分だけ残せます。

また、オプションとしてVSSによる「整合性のある」スナップショットを指定した時間毎に残せます(最短1時間)。

この複製は、前回との差分を複製しますが、実際に差分ディスクを作成するわけではありません。あくまでもイメージです。実際にはデータベースの「ログ」の方が近いようです(これもイメージですが)。

スナップショットを取ると、内部的に差分ディスクを作ります。しかし、5分に1回の複製は、スナップショットを作るわけではなく、差分ディスクも作成されません。

Windows Server 2012の新機能の詳細は、マイクロソフトTechNet Webサイト内の「Windows Server 2012」に掲載されています(日本語です)。

2012年10月22日月曜日

ターミナルサービスのシングルサインオン

あまり知られていないようなので、再掲載します。

Windows Server 2008では、Active Directoryドメインにログオンしたユーザーは、ターミナルサービスに対してシングルサインオン、つまりユーザー名とパスワードを省略し、現在のユーザーアカウントでてログオンできます。

これにはサーバーとクライアントの両方の設定が必要です。
ただし、サーバーの構成は既定値でシングルサインオンが可能ですので、実際に必要なのはクライアントの設定だけです。

グループポリシーで以下の値を設定してください。

[コンピュータの構成]-[ポリシー]-[管理テンプレート]-[システム]-[資格情報の委任]を開く

  • [既定の資格情報の委任を許可する]を[有効]に設定
  • サーバ一覧に「termsrv/ターミナルサーバのホスト名」を追加

ホスト名は、実際にアクセスするときの名前に一致している必要があります。

クライアントでドメインサフィックスまで含めて指定する場合は、ホスト名もFQDNでなければいけません。

グループポリシーで登録した名前と、クライアントで接続時に指定したホスト名が違う場合はシングルサインオンが機能しません。

詳しくは@ITの記事「Windows Server 2008の基礎知識」第10回ターミナル・サービスによるクライアントの仮想化(後編)へどうぞ。

この機能は、RemoteAppを使う時に特に重要です。アプリケーションを使うたびにアカウント情報を入力するのは面倒ですからね。

なお、Windows Server 2012でも基本は同じですが、VDI環境やRemoteAppなどでは自動的に委任が行われるようで、特別な設定は必要ありません。

2012年10月15日月曜日

マイクロソフト「ラーニングパートナーアワード」

今年もマイクロソフトのラーニングパートナーアワードをいただきました。

受賞者は昨年に引き続き、トレーナーアワードに伊藤将人が受賞しました。

これで、「マイクロソフト ラーニング パートナー アワード」創立以来、前回関連アワード毎年受賞の記録が一応更新されました。17回目です。

懇親会が、品川にある日本マイクロソフト本社の社員食堂で開催されました。残念ながら写真公開は禁止されているので、セミナールームでの表彰写真を載せておきます。

DSC00840S

副賞の盾は、後日名前を入れて返送ということです。

DSC00835S

ステンドグラスみたいでいい感じですね。

2012年8月10日金曜日

Windows Server 2008 R2トラブルシューティング(基礎編)

新コース「Windows Server 2008 R2トラブルシューティング(基礎編)」コースが8月15日(水)から始まります。

演習では、STOPエラーの簡単な解析や(本当に初歩の初歩ですが)、アプリケーションエラーの挙動を体験します。

STOPエラーを起こすのは難しいため、Sysinternalsのツール「NotMyFault」を使います。NotMyFaultについては拙ブログ「死の青い画面」で紹介しているので、こちらをどうぞ。

ユーザーモードのエラーは自分で作ろうと思い、Visual C++ Expressをダウンロードしてきました。他にもパフォーマンスモニターの演習用プログラムも必要だったので、以下の4本を作成しました。

  • ゼロ除算と記憶保護例外を起こすWindows Formアプリケーション
  • メモリを食いつぶすコマンドラインアプリケーション
  • CPU時間を食いつぶすコマンドラインアプリケーション
  • 何もしないダミーのアプリケーション

最近のコンパイラは、無意味な演算や変数を自動的に削除するので、最適化を抑制する必要があります。今回は変数に対してvolatile宣言を使いました。コンパイルオプションだと、あとで他の人が悩んでしまうかもしれませんので。

エラーを起こすアプリケーションは、1つで複数のエラーを起こすため、Windows Formを使ってボタンを並べました。

UserError

その他のアプリケーションは、ビルド後の実行ファイルにダミーデータを追加し、ファイルサイズを合わせ、ファイル名を変更しました。どういう風に使うのかは受講者だけの秘密です。

どれも数行から十数行のプログラムなのですぐにできましたが、受講者PC環境に持っていくとうまく動きません。

Windows Formアプリケーションは、NET Framework 4.0がないので動作しない、コマンドラインアプリケーションはVIsaul C++のランタイムライブラリがないので動作しない、ということです。

仕方がないので、受講者PCに両者をインストールしました。

ランタイムはともかく、.NETのバージョンはビルド時に変更できるはずなんですが、やり方が分かりません。Twitterでつぶやいたところ、マイクロソフトMVPの小野さんはじめ、何人かの方からアドバイスをいただきました。

この時、間違えて「C#」と書いてしまっために、特に小野さんにはかなりのご迷惑をおかけしました。改めてお詫びします。

結局、C#やVBはVisual Studioから変更できるが、C++は構成ファイルをエディタで編集しなければならない、ということでした。

実際に構成してみると、確かに「対象フレームワーク」が変更されます。

そこでビルドしてみたら以下のエラー

.NET Framework 2.0/3.0/3.5 は、v90 のプラットフォーム ツールセットを対象としています

VIsual Studio 2008を使え、ということのようです。

そういうわけで、演習環境には.NET 4.0とVIsual Studio 2010のランタイムがインストールされています。