「Server」カテゴリーアーカイブ

Active Directory Recycle Binに関して～その1

以前、Active Directory Recycle BinをRCで試したのですが、RTMで更に深く検証してみます。

まず、Active Directory Recycle Binの概要に関して

Active Directory Recycle Binを有効にするための条件としては2つあります。

フォレスト機能レベルを「2008 R2」にする
PowerShellより
PS>Set-ADForestMode –Identity contoso.com –ForestMode Windows2008R2Forest
「ごみ箱」を有効にする
PowerShellより
Enable-ADOptionalFeature –Identity ‘Recycle Bin Feature’ –Scope ForestOrConfigurationSet –Target ‘contoso.com’
＊注意 ADモジュールをPowershellにロードする必要があります。＜Import-Module ActiveDirectory＞

これらの条件が整って初めてActive Directory Recycle Binが有効になります。

試しに、上記条件を満たさない状況でUser1というユーザーオブジェクトを削除してからadrestoreを使用して復旧してみました。この場合は以前と同じようにほとんどの属性は削除されているのでUser1は復旧しましたが、多くの属性は戻りませんでした。

以前は、オブジェクトを削除すると廃棄（Tomstone）となりました。この際の有効期間はフォレストを作成した時のOSのバージョンによって異なります。ですのでたとえWindows Server 2008を導入しているからといって180日とは限りません。アップグレードやサービスパックの適用時にも変更はされないことに注意が必要です。

OS	廃棄の有効期間
Windows 2000 Server	60日
Windows Server 2003	60日
Windows Server 2003 SP1	180日
Windows Server 2003 R2	60日
Windows Server 2003 SP2	180日
Windows Server 2008	180日

この廃棄期間はADに情報が残っているのでバックアップを使用しなくても最悪オブジェクトだけは何とか復旧できました。ただし、ほとんどの属性は削除されているので手作業で属性の追加をしなくてはいけなかったのが現状です。これが少数のオブジェクトなら何とかなりますが、OU毎ごっそり間違って削除してしまった場合はお手上げです。そのような場合はバックアップからの復元を行っていたのが現状です。しかし、この場合はDSRMで再起動してAuthoritative Restoreを行わなくてはいけないのでかなり敷居の高い操作となります。

ではActive Directory Recycle Binが有効になると内部的にはどのように動作するのか？

基本的な考え方は、図にある通りです。削除されるとまずはDeleted Object(削除済)という状態になり、180日が経過するとRecycled Object(リサイクル済)という状態になります。更に180日が経過するとガベージコレクションによって完全削除という仕組みになります。

Deleted Object(削除済)の状態のときは、完全復旧が簡単に行えるということになります。一番簡単な方法は今までと同じようにadrestoreを使う方法でしょうかね～

そのほかには、Poweshellを使う方法があります

・削除されたユーザーを参照する

PS> Get-ADObject -filter {sAMAccountName -eq “user01”} –IncludeDeletedObject

・ユーザーを復旧する

PS> Get-ADObject -filter {sAMAccountName -eq “user01”} -IncludeDeletedObject | Restore-ADObject

更にOU毎ごっそり削除してしまった場合は次のように復旧する

・OUを復活させる（FinanceというOU名だった場合）

Get-ADObject -ldapFilter:"(msDS-LastKnownRDN=Finance)" -IncludeDeletedObjects | Restore-ADObject

・Finance配下のオブジェクト復旧

Get-ADObject -SearchBase "CN=Deleted Objects,DC=contoso,DC=com" –Filter 
{lastKnownParent -eq "OU=Finance,DC=contoso,DC=com"} -IncludeDeletedObjects
 | Restore-ADObject

とまあ、Deleted Object(削除済)の状態での復旧は特に問題ないことが判明しました。

では、Recycled Object(リサイクル済)のときはどうなんでしょうか？普通に考えると以前の廃棄（Tomstone）と同じかな？なんて思うかもしれませんが実は違います。これに関しては現在調査中なので結果が判り次第書こうと思います。

コアパーキングに関して

2件の返信

さて、Windows Server 2008 R2 では新機能としてコアパーキングをサポートしました。

このコアパーキングですが、複数コアのあるCPUに対して全てのコアをフル回転して使用させるのではなく、そのプロセスが動くのに十分なコアを確保する機能になります。結果として少数のコアを使用することになり消費電力を抑える機能になります。

この機能は0.1秒単位で働き、可能な限りCPUの保留状態を作っていきます。

リソースモニターで確認すると一瞬ですが保留状態が確認できました。

さて、この機能の制御はできるのか？

マイクロソフトに問い合わせしたところ、この機能はユーザーによる制御などはできないそうです。また制御を行うためのツールなども今のところ存在しません。レジストリをいじればコアパーキングの機能をやめることなど出来そうな気がするのですがそのような情報もありませんでした。

Hyper-v 2.0 もコアパーキングをサポートします。当然ながら設定作業などは一切必要ありません。

まあ、パフォーマンスは変わらず消費電力を抑えてくれるので気にする必要はないということでしょうかね～

フェールオーバークラスタのフェールオーバー上限値のバグ

コメントを残す

この情報は同僚から調べてほしいと言われた内容なんですが、せっかくなのでアップしておきます。

現象：グループのプロパティでフェールオーバーの上限数を2回に設定したとき、1回しかフェールオーバーしない。

作業手順は下記の通りです。

２ノードクラスタ上にVAN-Printという名前のプリントサーバーのグループを作成。
VAN-Printのプロパティの[フェールオーバー]タブで、[指定した期間内の最大エラー数]を2に。[期間]は6(時間)のままとする。
VAN-Printグループ内の[印刷スプーラ]リソースを右クリックし、[このリソースのエラーをシュミレーションする]ことで意図的に障害を発生させ、フェールオーバー回数を確認。

確認結果：

フェールオーバーの上限数を１～4回まで設定を変えて動作を確認しました。

その結果は下記の通りです。

[指定した期間内の最大エラー数]を1にしたとき　→　1回までフェールオーバー
[指定した期間内の最大エラー数]を2にしたとき　→　1回までフェールオーバー
[指定した期間内の最大エラー数]を3にしたとき　→　3回までフェールオーバー
[指定した期間内の最大エラー数]を4にしたとき　→　4回までフェールオーバー

[指定した期間内の最大エラー数]を１回、３回、４回に指定した時は、予定通りの動作ですが、２回に設定したときだけ、通常より１回少ない回数しかフェールオーバーしません。

というものです。

調べた結果、これは既知の問題としてあがっていました。

The default group failover threshold value in the Windows Server 2008 Failover Cluster Management snap-in is incorrect

どうやらSP2でも直っていないようです。しかしWindows Server 2008 R2 では解消されているようです。

クラスタを構成している場合はこの情報を認識しておいたほうがいいかもしれませんね。

Windows Server バックアップに関して～その5～

コメントを残す

Windows Server 2008 R2 のWSBはかなりの機能が向上されているようです。そこでR2に搭載されたWSBはどのように変わったのかをまとめてみます。

まずはマイクロソフトの情報から

Windows Server バックアップの新機能

個々のファイルをバックアップまたは除外する機能、およびボリュームからファイルの種類とパスを含める機能または除外する機能
増分バックアップのパフォーマンスと使用方法の改善
バックアップの保存場所の多様化
システム状態のバックアップおよび回復についてのオプションとパフォーマンスの改善
コマンドラインのサポートの強化
Windows PowerShell のサポートの強化
これらが新機能になります。
そこで画面を確認しながら変更点を見ていきます。

以前はボリューム単位でのバックアップしかサポートしていませんでしたが、R2からはフォルダおよびファイル単位でのバックアップをサポートするようになりました。更にシステム状態のバックアップもGUIから行うことができるようになりました。以前はwbadminを使用したコマンドでのバックアップしかサポートしていなかったので便利になりましたね。

あと、ベアメタル回復というチェックボックスが新たに追加されました。このチェックを入れるとベアメタル回復に必要なデータを自動的にチェックしてくれます。この図はベアメタル回復にチェックを入れた状態になります。

またスケジュールバックアップの保存場所が拡張されました。以前はバックアップ専用ハードディスクが必要でした。R2では更にボリュームに対するバックアップと共有フォルダに対するバックアップをサポートしました。

しかし、ボリュームに対するバックアップはそのボリュームのパフォーマンス低下が既知の問題としてあります。

そして共有フォルダへのバックアップですが、これは世代管理ができません。よって1回限りのバックアップをスケジュールで行ってくれると理解してもいいでしょう。

バックアップの対象をカスタムにすると詳細設定を行うことができます。

まず除外ではバックアップを行う際の除外ファイルやフォルダを選択できます。そしてVSSの設定では完全とコピーを選択できます。デフォルトではコピーになっています。この違いはバックアップを行った際にアプリのログファイルが削除されるか否かになります。コピーの場合はそのままアプリのログファイルは残ります。

さてスケジュールバックアップではバックアップ専用ハードディスクを使用することが相変わらず推奨になりますが、その際の動作は以前と変わりなく、専用ハードディスクはドライブレターが削除された状態になります。この専用ハードディスクにドライブレターを付けて中身を確認するとこのようになっています。

ここで不思議なことがあります。以前は1つのVHDしか見当たらなかったはずなのですが今回は2つのVHDがあります。これって何かな～ここからは詳細な情報がないので推測になるのですが、たぶんboot領域ですね。VHDを接続してみたら100Mだったんで。Windows7やR2からboot領域として100Mを使うようになったのでそれですね。

さて内部的なお話なんですが、バックアップパフォーマンスの最適化のところが変わりました。

以前はどのようになっていたかというと

常に完全バックアップを実行する
常に増分バックアップを実行する
カスタム

というようになっていました。

新機能の説明には次のように書いてあります

以下抜粋

増分バックアップのパフォーマンスと使用方法の改善

既定で、Windows Server バックアップは、完全バックアップのように機能する増分バックアップを作成します (1 個のバックアップから任意の項目を回復できるが、使用する領域は増分バックアップに必要な領域のみ)。(初回を除いて) すべてのファイル/フォルダーバックアップは増分バックアップであり、変更されたファイルのみが読み取られ、バックアップの保存場所に転送されます。さらに、新しいバックアップ用のディスク領域を確保するために、ユーザーが定期的に手動で古いバックアップを削除する必要はなくなりました。古いバックアップは自動的に削除されます。

ここまで

この説明ですが少々おかしい気がします。まず以前から古いバックアップは自動的に削除されていました。それに以前から完全バックアップでは増分バックアップのように動作していました。それは完全バックアップを保存する際にVSSを使用するので変更分のみを保存していたんですよね～

推測ですが、マイクロソフトさんは増分バックアップを意識させないためにこの文言をインターフェイスより削除したんじゃないかな？この説明でもVSSの動作を言っていますしね。ですのでたぶん機能は変わっていないような気がします（パフォーマンスは上がったかも知れませんが）。ただ文言が変わっただけ。

あとはwbadminの機能強化とPowershellコマンドレット強化あたりでしょうか？

そうそう、個別のシステム状態のバックアップに関しては以前と同じように時間がかかりますね～やはりこれも以前と同様にシステム状態のみをバックアップするのではなくボリューム全体のバックアップのほうが効率がいいみたいです。

Windows System Image Manager を使用して応答ファイルを作成する

コメントを残す

Windows System Image Manager（SIM）を使用すると自動的に応答ファイルを生成してくれます。SIMはWindows AIKをインストールすると入ってきます。

以前はSetup Managerを使用して応答ファイルを作成することができましたが、Vista以降はこのSIMを使用して作成することになります。

しかし、このSIM・・・初心者を寄せ付けない設計です（笑）

以前のSetup Managerは説明書を見なくてもなんとなくウイザードに従っていけばできちゃった感がありました。しかし、これは・・・無理

もうこの時点でパスという人は多いのではないでしょうか？

ということで果敢にも挑戦してみました

今回は私が行うトレーニングコースのセットアップをある程度自動化できればいいと以前から考えていたのでそれを行ってみます。

私が今回行いたいことの条件

・イメージはすでに出来上がっている
・イメージはSYSPREPを行ってから配布
・ノートンゴーストを使用してイメージを配布する
・起動時にライセンス同意とロケールを聞いてくるのでバイパスしたい
・パスワードの入力をバイパスしたい
・コンピューター名やIPアドレス入力をある程度自動化したい
・ドメイン参加をある程度自動化したい

そこでどのようなアプローチがあるか考えてみました

コンピューター名やIPアドレスは全ての端末でことなるのでこれは入力しなくてはならいので全自動は無理。ということで、応答ファイルでのアプローチとしては特にライセンス同意とロケールおよびパスワード入力のバイパスになります。

ではここからSIMを使用した応答ファイルの作り方になります

まずはSIMを起動します

このツールを使用する際の基本としてまず「Windows イメージ」ウインドウから操作します。ここでカタログを選択します。このカタログとはいうなれば、応答ファイルの設定を行うためのひな型になります。各OSごとに用意されているので自分が作成する応答ファイルのOSを選択する必要があります。今回私はWindows Server 2008 R2を選択しました。このカタログはwimファイルから作成することもできますが、OSにはあらかじめカタログファイルが用意されているのでそれを使用します。

そして「応答ファイル」ウインドウで新しい応答ファイルを作成します。

これでとりあえず準備は完了しました

実際の操作はまずカタログのComponentsにある各種設定を応答ファイルに入れ込んでいきます。ここがまず判らないところ・・・

そもそも各種設定が何を行うのか？が判りません。そこは各種設定を開いて名前で判断するか？もしくはそこからヘルプを呼び出せるのでヘルプを参照するしかありません。このヘルプですが英語なんですよね～

そして、応答ファイルには１～７までの段階があります。これは簡単にいうとセットアップフェーズが7段階に分かれていて、各種設定をどの段階で使用するのかを指定する必要があります。ここで難しいのは必ずしも1つのフェーズ設定しか指定できるわけではなく、複数のフェーズ設定が指定できる項目もあります。ですのでこのフェーズの理解も必要になります。

今回インストール済みのイメージに対して実行するコマンドは次のようになる予定です

sysprep /generalize /oobe /reboot /unattend:c:test.xml

generalizeによってSIDの再構成、そして展開を行う際には必ずoobeオプションを付ける必要があります。そこに応答ファイルをくっつける。

ではこの動作はどのようなロジックになるのかは下のフロチャートを見ればなんとなくわかるかな？

このSysprepではOOBEオプションを付けているのでspecialize後にoobesystemに対する設定が適用されることになります。

ここからは試行錯誤で行っていきましたので必ずしも適切ではないかもしれませんがとりあえず、解説していきます。

今回主に使用する設定項目は
amd64_Microsoft-Windows-Shell-Setup
配下になります。

全ての解説は入れませんが設定方法のみ解説します。たとえば、ここのOOBEを選択して右クリックすると応答ファイルに設定項目を渡すことができます。その際にどのフェーズに挿入するかを指定します。この場合は7.oobesystemしかないので迷いません。

そうすると応答ファイルに項目が渡され、右のプロパティに設定を入力できるようになります。この繰り返しを行うことによって応答ファイルを作成することが可能になります。

そして今回目標となる応答ファイルができました

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
    <settings pass="oobeSystem">
        <component name="Microsoft-Windows-International-Core" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">            <InputLocale>ja-JP</InputLocale>
            <SystemLocale>ja-JP</SystemLocale>
            <UILanguage>ja-JP</UILanguage>
            <UserLocale>ja-JP</UserLocale>
        </component>
        <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">            <OOBE>
                <HideEULAPage>true</HideEULAPage>
                <NetworkLocation>Work</NetworkLocation>
                <ProtectYourPC>1</ProtectYourPC>
                <SkipUserOOBE>true</SkipUserOOBE>
            </OOBE>
            <Display>
                <ColorDepth>32</ColorDepth>
                <HorizontalResolution>800</HorizontalResolution>
                <RefreshRate>60</RefreshRate>
                <VerticalResolution>600</VerticalResolution>
            </Display>
            <AutoLogon>
                <Password>
                    <Value>UABhACQAJAB3ADAAcgBkAFAAYQBzAHMAdwBvAHIAZAA=</Value>
                    <PlainText>false</PlainText>
                </Password>
                <Enabled>true</Enabled>
                <LogonCount>1</LogonCount>
                <Username>administrator</Username>
            </AutoLogon>
            <UserAccounts>
                <AdministratorPassword>
                    <Value>UABhACQAJAB3ADAAcgBkAEEAZABtAGkAbgBpAHMAdAByAGEAdABvAHIAUABhAHMAcwB3AG8AcgBkAA==</Value>                    <PlainText>false</PlainText>
                </AdministratorPassword>
            </UserAccounts>
            <TimeZone>Tokyo Standard Time</TimeZone>
            <RegisteredOwner>Learning Solution</RegisteredOwner>
            <RegisteredOrganization>Edifist Learning</RegisteredOrganization>
            <FirstLogonCommands>
                <SynchronousCommand wcm:action="add">
                    <CommandLine>c:vmm.bat</CommandLine>
                    <Order>1</Order>
                    <RequiresUserInput>true</RequiresUserInput>
                </SynchronousCommand>
            </FirstLogonCommands>
        </component>
    </settings>
    <cpi:offlineImage cpi:source="catalog:e:/sources/install_windows server 2008 r2 serverenterprise.clg" xmlns:cpi="urn:schemas-microsoft-com:cpi" /></unattend>

今回はIPアドレスやコンピューター名、ドメイン参加はバッチファイル（vmm.bat）にしました。それを最初のログオン時に実行させています。

資格情報マネージャーについて（70-680試験対策）

1件のフィードバック

Windows7には資格情報マネージャーというものがあります。

Windows XPやWindows Vistaでは、「ユーザー名およびパスワードの保存」というツールがありましたが、その機能アップ版になります。

この資格情報マネージャーを使用することにより、特定のサーバーにログオンするユーザーとパスワードを保存しておくことができ、再度接続する際にはユーザー認証が自動的に行わなわれる。もしくは、ポップアップによりあらかじめユーザーとパスワードが入力された状態になります。

ちなみにこの資格情報マネージャーに保存される情報としては、「Windows資格情報」「証明書に基づいた資格情報」「汎用資格情報」の3つがあります。

簡単に説明すると、Windows資格情報はファイル共有（ワークグループなど）、証明書に基づいた資格情報はその名の通り証明書を使用する認証で主にスマートカードなど、そして汎用資格情報は、Webサービスがおもになります。そうそう、Windows Live ID なども汎用になるようです。

この資格情報マネージャーでは資格情報コンテナーのバックアップおよび復元がサポートされています。よって、マシンのリプレイスなどの際には、バックアップを取っておき、新しいマシンで復元を行えば、以前と同様に認証が行えることになります。

ちなみにコマンドプロンプトで

runas /savecred /user:administrator regedit

と入力すると、最初はパスワードを要求されますが、そのパスワードは資格情報マネージャーに登録され、次回からはパスワードを聞かれることはありません。

もし、この状況がいやならば認証情報を資格情報コンテナから削除すればいいですね。

DNSのラウンドロビン

コメントを残す

DNSのラウンドロビンは枯れた技術で様々な企業で使用されています。

具体的にはDNSの登録する1つのホスト名に対して複数のIPアドレスを登録しておきます。クライアントからの要求に対して順番に先頭のIPを変更して異なるサーバーのIPアドレスを返すことにより負荷分散を行わせるものになります。

ホスト名としてWebserverが以下のように登録してある場合は

Webserver.test.net A 192.168.0.100
Webserver.test.net A 192.168.0.10
Webserver.test.net A 192.168.0.11
Webserver.test.net A 192.168.0.15
Webserver.test.net A 192.168.0.20

クライアント側にこれらのリストが返され、先頭の 192.168.0.100 が使用されます

そして別の端末がWebserverの名前解決を行うと

Webserver.test.net A 192.168.0.10
Webserver.test.net A 192.168.0.11
Webserver.test.net A 192.168.0.15
Webserver.test.net A 192.168.0.20
Webserver.test.net A 192.168.0.100

クライアント側にこれらのリストが返され、先頭の 192.168.0.10が使用されます

このような動作により負荷分散を行います

本日、同僚が研修でテストしていたら思ったような動作にならないと言ってきました。そして調べてみるとWindows Server 2008 と Vista ではラウンドロビンがうまく動かないことがわかりました

どのような動作になるかというと DNSキャッシュの内容が以下のエントリで入ったとします

Webserver.test.net A 192.168.0.100
Webserver.test.net A 192.168.0.10
Webserver.test.net A 192.168.0.11
Webserver.test.net A 192.168.0.15
Webserver.test.net A 192.168.0.20

このようなリストが返されると、一番小さいアドレス（longest match）が選択される仕様になっているようです

2009/11/09 追記
2009/11/18 追記

私の理解が少々間違っていましたので訂正します

実際にはまず自分のIPアドレスを確認します。たとえば、自分のIPアドレスが192.168.0.1だとすると、自分のIPとラウンドロビンのIPを比較します。

11000000 10101000 00000000 00000001 = 192.168.0.1 = Client IP to match.
11000000 10101000 00000000 01100100 = 192.168.0.100 = (24 + 1 = 25 bits matching the client IP)
11000000 10101000 00000000 00001010 = 192.168.0.10 = (24 + 4 = 28 bits matching the client IP)
11000000 10101000 00000000 00001011 = 192.168.0.11 = (24 + 4 = 28 bits matching the client IP)
11000000 10101000 00000000 00001101 = 192.168.0.15 = (24 + 4 = 28 bits matching the client IP)
11000000 10101000 00000000 00010100 = 192.168.0.20 = (24 + 3 = 27 bits matching the client

ここでIPアドレスのマッチングを行います。第3オクテットまでは同じなので第4オクテットに着目します。

192.168.0.10
192.168.0.11
192.168.0.15

が28bit matchなので、この中の先頭のIPアドレスが選択されます。

ですのでこの場合は 192.168.0.10 が選択され続けることになります。

これはVistaよりIPv6がデフォルトで動作する仕様変更に伴い、RFC3484に従ったためにおこるものらしいです

ただし、実機確認してみると意外なことが判明！

この動作は同一セグメントでの動作で、異なるセグメントの場合はちゃんとラウンドロビンが動作しました。

Pingでのテストによると、もしマッチングビットが同じで通信が不可能な場合キャッシュに登録された順番にIPを試します。結果的に通信が確立されたIPがあった場合はそのIPに固定された通信を行います。

192.168.0.10（不可）
192.168.0.11（不可）
192.168.0.15 追記はここまで（2009/11/09）

この動作を以前と同様にするにはレジストリの変更が必要になります

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters
DWORD = OverrideDefaultAddressSelection
Value data: = 1

ちなみに、Windows7 と Windows Server 2008 R2 ではこのレジストリがデフォルトで1になっています（キーは存在しません）。よって、クライアントにWindows7を使用している場合は特に問題はないということになりますね。

参考

DNS Round Robin and Destination IP address selection

いや～、知らなかったな～～～

Hyper-V2.0におけるNLB設計

コメントを残す

NLBを構築する際には注意しなくてはいけないことがあります。それはHyper-Vで構築しようが、物理サーバーで構築しようが同じです。

今回は結論から書きますが、Hyper-VでNLBを設定するサーバーに対してはVLANを使用して専用セグメントを作ることがベストだと考えます。NBLの条件としてはユニキャストモードで構築するとします。

さて、ここでなぜVLANを使用するのか？

ここで考えなくてはいけないのが、NLB（ユニキャストモード）における動作になります。

NLBを構築すると、NLBに参加しているホストのMACアドレスはNLBのMACアドレスに置き換わります。ここで問題なのはスイッチとの関係になります。スイッチはポートごとにMACを登録しますが、この状態だと複数のポートに同じMACアドレスがあることになります。となると、スイッチではMACアドレスが適切に登録されないという事態が発生するのです。そこで、NLBに参加しているホストはフェイクのMACアドレスを送信するようになります。

この図で解説すると、本来のMACアドレス02-bf-a-a-a-aが02-01-a-a-a-aとして送信されることになります。ただし、ARPデータは本来のMACアドレスである02-bf-a-a-a-aをさすんです。よって、クライアント側ではIPとMACアドレスの対応は正常に行われることになります。

ではクライアントからNLBにアクセスする際の動作としては、NLBのMACアドレスはスイッチに登録されていないので、全てのポートにフラッディングされることになります。そうすると、NLBに参加している全てのサーバーにデータは届きます。

ここでNLBのアルゴリズムである、統計的完全分散フィルタリングアルゴリズムによって適切なサーバーでデータが処理されることになります。

ここで問題です

NLBに参加していないPCやServerたちにも、NLB宛てのデータが届いてしまうのです！しかし、自分宛のパケットではないのでドロップ処理を行い受け付けません。要するに同じセグメントに参加しているコンピュータには不要なパケットがバンバン届くんですね。

よって、NLBを構築する際には専用セグメントを作成して、その中だけでNLBパケットを完結させる必要があるんです。

そのためには、Hyper-V環境ではVLANを使用するのが最も効率が良い方法だと考えるからになります。

Hyper-V 2.0 新機能～ネットワーク負荷分散（NLB）設定

コメントを残す

TechED2009ではHyper-V2.0においての設計についての話が結構ありました。そこで検証作業を行いました。

Hyper-V2.0でも1.0と同様の設定が必要になると思っていましたが違う点がありましたので注意する必要があります。

それは、Hyper-V1.0のときはNLBを設定する際にはゲストOSのネットワークのMACアドレスを静的にし、NLBを構成した際に配布されるMACアドレスに書き換える必要がありました。

参考：

http://support.microsoft.com/kb/953828/ja

そこで、Hyper-V2.0でも同じことをしなくてはいけないと思いいざ構成してみると・・・・

ここでNLBのMACアドレスをメモ・・・「02-bf-ac-10-0a-96」

あらかじめゲストOSのネットワークアダプタには「MACアドレスのスプーフィングを有効にする」にチェックを入れておきます

あれれ、静的MACアドレスにしなくても収束してしまった

確認のためにゲストOSのMACアドレスを調べると・・・NLBのMACアドレスになっている！！

まとめ

Hyper-V1.0では静的MACにして、NLBのMACアドレスに書き換える必要がある
Hyper-V2.0では「MACアドレスのスプーフィングを有効にする」にチェックを入れておく

ということになりますね。いや～、知らなかった（汗）

Hyper-V 2.0 新機能～仮想マシンのインポート

コメントを残す

細かい点なんですが、Hyper-V1.0のときはエクスポートした仮想マシンをインポートする際には、必ず目的の場所にコピーをしてからインポートしていました。その理由は1回インポートした仮想マシンは再度インポートできないのでその対策がひとつ。

もう一つは、エクスポートする際には外付けHDDなどに行う場合が多いです。その外付けHDDを別のHyper-Vがインストールされている物理マシンに接続し、インポート作業を行うことになります。もしこのままインポートを行ってしまうと、その外付けHDDが仮想化マシンの保存場所になってしまいます。これは困りますよね～

そんなことから、インポートする際にはエクスポートしたデータを目的の場所にコピーしてからインポートを行うということをしていました。

ではHyper-V2.0ではどうなったか？

「すべてのファイルを複製し、同じ仮想化マシンを再度インポートできるようにする」というオプションが付加されたんです。これで、今まで行っていたコピーする作業は自動的に行われることになります。

ここで注意が必要なのは、「仮想マシンをコピーする」チェックですが、この操作を行うと仮想マシンIDが新たに作られるだけで、インポートするゲストOSには変化がありません。ということはSIDの問題などがあるということになります。

また、インポートした仮想マシンの仮想ネットワークに外部接続ネットワークがつけられていた場合は、再設定が必要になるということでしょうか。

MCTの憂鬱

Microsoft 関連情報サイト

「Server」カテゴリーアーカイブ

Active Directory Recycle Binに関して～その1

コアパーキングに関して

フェールオーバークラスタのフェールオーバー上限値のバグ

Windows Server バックアップに関して～その5～

Windows System Image Manager を使用して応答ファイルを作成する

資格情報マネージャーについて（70-680試験対策）

DNSのラウンドロビン

Hyper-V2.0におけるNLB設計

Hyper-V 2.0 新機能～ネットワーク負荷分散（NLB）設定

Hyper-V 2.0 新機能～仮想マシンのインポート