自宅サーバ更改その２ Windows Server 2012 R2でNICチーミング＆Hyper-V仮想スイッチでのVLAN [Windowsメモ]
前回から引き続き、自宅サーバ更改について触れる。
ネットワークに関しては、Windows Server 2012以降ではOSレベルでNICチーミングをサポートするようになったので、それを使ってやや凝った構成にしてみた。
更改前のサーバネットワーク論理図は下に示すものとなっていた。
それぞれの物理NICに仮想スイッチを１つずつ割り当てたシンプルな構成である。
インターネットへ接続するには必ずDebianを経由させるため、AUひかりレンタルルータである NEC Aterm BL190HW からVM上のDebianまでは1本のルートで接続している。
192.168.2.0/24のネットワークは他の場所で使用しているため、ここには記載していない。
192.168.3.0/24のネットワークは自分ではほとんど使わないため、オンボードでも構わないだろうとしてそのまま使っている（ひどい話だ…ｗ）。
NETGEAR GS108EではVLANを用いて192.168.1.0/24と192.168.3.0/24を分離していたが、サーバに対してはアクセスポートで接続しているで、サーバ内はVLANを扱っていない。
それに対して、更改後のサーバネットワーク論理図は次のようになっている。
Pro/1000 PT Dual Portの2つのポートをLBFO (Load Balancing and Failover）でチーミングして、2本のLANケーブルをリンクアグリゲーションによって論理的には1本に束ね、さらにその内部には2つのVLANネットワークを流すという形にした。
VLANの分離は Corega CG-SSW08GTR 及びHyper-V仮想スイッチで行っている。
リンクアグリゲーションに対応したスイッチである CG-SSW08GTR は以前から入手していたが、Windows Server 2012 R2のNICチーミングと組み合わせて遊べそうな事に気付いたので、このような構成にしてみた。
上記構成設定は、以下の手順で行った。
なお、構築途中のスナップショットであるため、本番構成とはやや異なる。
まずはLBFOによるNICチーミング設定から行う。
サーバーマネージャーを開き、ローカルサーバを選択して、NICチーミングの「無効」をクリック。
NICチーミングの設定が行えるので、参加させたいNICを複数選択し右クリックしてメニューを開き、「新しいチームに追加」をクリック。
チームの新規作成ウィンドウが開くので、チーム名を入力し、「追加のプロパティ」を開いて、適切な設定を選択する。
チーミングモードは、対向スイッチに合わせて選択するが、CG-SSW08GTR のリンクアグリゲーションはLACPには対応していないので、「静的チーミング」とした。
負荷分散モードは、ほとんどの場合で「動的」を選んでおけば問題ない。
「OK」ボタンをクリックすれば、NICチーミングが構成される。
次に、仮想スイッチの設定を行う。
Hyper-Vマネージャーを呼び出して、仮想スイッチマネージャーを開く。
「新しい仮想ネットワークスイッチ」として、「外部」で「仮想スイッチの作成」を行うと、「新しい仮想スイッチ」の設定画面が開く。
名前を適宜設定し、接続の種類は「外部ネットワーク」－「Microsoft Network Adapter Multiplexor Driver」を選択し、「管理オペレーティングシステムにこのネットワークアダプターの共有を許可する」にチェックを入れる。
VLAN IDは、「管理オペレーティングシステムの仮想VLAN IDを有効にする」にチェックを入れて、ひとまず「1」を入力し、「OK」ボタンをクリックすると、ホストOSにはVLAN1に対応した仮想NICが作成される。
仮想スイッチマネージャーからは、仮想スイッチ一つに対してホストOSへの仮想NICは一つしか設定できないので、もう一つはPowerShellから設定する。
PowerShellを管理者権限で起動し、VLAN2に対応した「Intel Pro1000 PT #2」という名前の仮想NICを新たに作るとして、以下のコマンドを打ち込んだ。
SwitchNameが分からなければ、 Get-VMSwitch のコマンドで仮想スイッチの一覧を表示して確認できる。
Get-VMNetworkAdapterVlan でVLANがきちんと割り振られていることがわかる。
これで、仮想スイッチ経由でホストOSと接続する、vEthernetから始まる仮想NICが二つ出来ているので、必要なIPアドレス等の設定を行う。
ゲストOSにNICを設定する際には、Hyper-Vマネージャーから仮想マシンの設定画面を開き、各ネットワークアダプターの「仮想VLAN IDを有効にする」にチェックを入れて、対応させたいVLAN IDを入力する。
続いて、対向スイッチとなる CG-SSW08GTR でも必要な設定を行う。
ここでは、ポート1、2をリンクアグリゲーションで束ねトランクポートとしてサーバに接続、ポート3～5をVLAN2、ポート6～8をVLAN1のアクセスポートとする。
そのため、WebGUIにアクセスして、まず「Aggregation」の設定でPort1、2をGroup1として、リンクアグリゲーションを組む。
次に「802.1Q VLANs」を開いて、デフォルトではVLAN1しかないため、VLAN2を追加する。
そして、それぞれのVLANの設定を次のようにした。
VLAN1はPort6～8及びTrunk1にチェックを入れる。
VLAN2はPort3～5及びTrunk1にチェックを入れる。
続いて、「802.1Q VLANs」の画面から「Port Config」ボタンをクリックして、ポートごとのタグVLAN設定を行う。
Trunk1のみタグを付けたまま送受信を行うので、「VLAN aware Enabled」、「Member Check」にチェックを入れ、Accept Frame Typeは「Tagged Only」、Pvidは「None」とした。
なお、Pvidで「None」を選択するには、一度「VLAN aware Enabled」にチェックを入れて「Apply」をクリックした後、再度「Port Config」をクリックしてこの画面に戻ってこないと駄目なようだ。
Trunk1の設定は自動的にPort1、2にも反映されるので、そちらの設定はいじる必要はない。
以上で設定は完了したはずなので、Pingを打ちながらLANケーブルを抜いたり挿すポートを替えたりして、リンクアグリゲーションによる冗長化、VLANによるネットワーク分離がきちんと機能していることの確認を行った。
さて、機能確認が終了したら、パフォーマンスの確認も行う必要があるだろう。
仮想スイッチでVLANの処理をさせるとCPU負荷が高くなって大変だという事はよく言われているが、実際にどんなものなのかはやってみなければわからない。
ということで、構築途中に一旦VLANなしの更改前構成にしてCPU負荷を測定し、上記手順にて構築したNICチーミング＆Hyper-V仮想スイッチでのVLAN構成でも同様に測定して、比較してみることとした。
テスト方法として、異なるセグメントのクライアント2台から同時に、ホストOSに対してiperfでパケットを送り続けてネットワーク負荷を掛けた。
まずは、NICチーミング＆VLANなしの更改前と同等構成で、物理NICに仮想スイッチを１つずつ割り当て、仮想NICもその仮想スイッチから１つずつ割り当てている状態での測定結果である。
CPU使用率はアクティブコアで50～60%程度といったところだ。2Gbps近い通信量だと、単純に仮想スイッチに流すだけでもCore2系ではそれなりのCPU負荷となるのだろう。
続いて本命の、NICチーミング＆VLANありの更改後構成では次の結果となった。
あれ？何だか予想外にCPU使用率が低いな…、と思ってよく見ると、受信速度がそれぞれ400Mbpsも出ていない。
一体どういう事だと、クライアント1台ずつで速度測定すると、単体接続では900Mbps以上出る。
これはひょっとして CG-SSW08GTR できちんとロードバランスされず、1本のLANケーブルを共有している状態になっているのではないかと考え、IPアドレスや宛先ポート番号を変えてみるが、状態は変わらない。
Webの製品情報やPDFのマニュアルを読んでも必要な情報がなかったが、色々と探したところ、WebGUIのヘルプ内にてAggregationの項目に以下の記述を見つけた。
MACアドレスベースでロードバランスしていると分かれば話は簡単なので、クライアントの該当NICのMACアドレスを、デバイスマネージャの設定画面で既存のものから末尾を一つずらしたものへと変更した。
それからもう一度測定をやり直したところ、以下の結果が得られた。
今度はきちんとロードバランスされ、受信速度がそれぞれ900Mbps以上となった。
肝心のCPU使用率は、アクティブコアで70～80%程度となり、チーミング＆VLANなしと比べて20%ぐらい上昇している。
以上より、噂通りチーミング＆VLANによってCPU負荷が上昇することが裏付けられた。
2つのコアのCPU使用率は結構なものとなったが通信速度自体に問題はなく、残り2つのコアは遊んでいるので、別の負荷が掛かる作業を同時に行っても、速度への影響はさほど出ないと思われる。
また、CG-SSW08GTR でのMACアドレスベースのロードバランスは、クライアント台数が少ないと偏りが大きくなる可能性がある。
しかし、実際の利用シーンではサーバからクライアントへの送信が通信量の大半を占め、そちらはWindows Serverの「動的」負荷分散となるため、問題はないであろう。
テスト時のようなクライアント2台同時にフルスピードでの通信を行う事も滅多にないので、多少のCPU負荷上昇は許容できるものとして、これで運用環境へと移すこととした。
さて、予定通りNICチーミング＆Hyper-V仮想スイッチでのVLANの構築は完了したが、これがネットワークの冗長性に寄与するのかというと、他にSPOF（単一障害点）となる場所が多すぎて実際にはほとんど意味がなく、自己満足で終わっている。
サーバのメンテナンス等でLANケーブルを一旦抜いた後、接続し直す時に Pro/1000 PT Dual Port の2つあるポートにはどのケーブルを繋ぐか悩まなくて良くなるというメリットがあるぐらいだろうか。
あとは、このブログネタとなったというのも大きいかもしれない。
ネットワークに関しては、Windows Server 2012以降ではOSレベルでNICチーミングをサポートするようになったので、それを使ってやや凝った構成にしてみた。
更改前のサーバネットワーク論理図は下に示すものとなっていた。
それぞれの物理NICに仮想スイッチを１つずつ割り当てたシンプルな構成である。
インターネットへ接続するには必ずDebianを経由させるため、AUひかりレンタルルータである NEC Aterm BL190HW からVM上のDebianまでは1本のルートで接続している。
192.168.2.0/24のネットワークは他の場所で使用しているため、ここには記載していない。
192.168.3.0/24のネットワークは自分ではほとんど使わないため、オンボードでも構わないだろうとしてそのまま使っている（ひどい話だ…ｗ）。
NETGEAR GS108EではVLANを用いて192.168.1.0/24と192.168.3.0/24を分離していたが、サーバに対してはアクセスポートで接続しているで、サーバ内はVLANを扱っていない。
それに対して、更改後のサーバネットワーク論理図は次のようになっている。
Pro/1000 PT Dual Portの2つのポートをLBFO (Load Balancing and Failover）でチーミングして、2本のLANケーブルをリンクアグリゲーションによって論理的には1本に束ね、さらにその内部には2つのVLANネットワークを流すという形にした。
VLANの分離は Corega CG-SSW08GTR 及びHyper-V仮想スイッチで行っている。
リンクアグリゲーションに対応したスイッチである CG-SSW08GTR は以前から入手していたが、Windows Server 2012 R2のNICチーミングと組み合わせて遊べそうな事に気付いたので、このような構成にしてみた。
上記構成設定は、以下の手順で行った。
なお、構築途中のスナップショットであるため、本番構成とはやや異なる。
まずはLBFOによるNICチーミング設定から行う。
サーバーマネージャーを開き、ローカルサーバを選択して、NICチーミングの「無効」をクリック。
NICチーミングの設定が行えるので、参加させたいNICを複数選択し右クリックしてメニューを開き、「新しいチームに追加」をクリック。
チームの新規作成ウィンドウが開くので、チーム名を入力し、「追加のプロパティ」を開いて、適切な設定を選択する。
チーミングモードは、対向スイッチに合わせて選択するが、CG-SSW08GTR のリンクアグリゲーションはLACPには対応していないので、「静的チーミング」とした。
負荷分散モードは、ほとんどの場合で「動的」を選んでおけば問題ない。
「OK」ボタンをクリックすれば、NICチーミングが構成される。
次に、仮想スイッチの設定を行う。
Hyper-Vマネージャーを呼び出して、仮想スイッチマネージャーを開く。
「新しい仮想ネットワークスイッチ」として、「外部」で「仮想スイッチの作成」を行うと、「新しい仮想スイッチ」の設定画面が開く。
名前を適宜設定し、接続の種類は「外部ネットワーク」－「Microsoft Network Adapter Multiplexor Driver」を選択し、「管理オペレーティングシステムにこのネットワークアダプターの共有を許可する」にチェックを入れる。
VLAN IDは、「管理オペレーティングシステムの仮想VLAN IDを有効にする」にチェックを入れて、ひとまず「1」を入力し、「OK」ボタンをクリックすると、ホストOSにはVLAN1に対応した仮想NICが作成される。
仮想スイッチマネージャーからは、仮想スイッチ一つに対してホストOSへの仮想NICは一つしか設定できないので、もう一つはPowerShellから設定する。
PowerShellを管理者権限で起動し、VLAN2に対応した「Intel Pro1000 PT #2」という名前の仮想NICを新たに作るとして、以下のコマンドを打ち込んだ。
Add-VMNetworkAdapter -ManagementOS -Name "Intel Pro1000 PT #2" -SwitchName "Intel Pro1000 PT Dual"
Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "Intel Pro1000 PT #2" -Access -VlanId 2
Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "Intel Pro1000 PT #2" -Access -VlanId 2
SwitchNameが分からなければ、 Get-VMSwitch のコマンドで仮想スイッチの一覧を表示して確認できる。
Get-VMNetworkAdapterVlan でVLANがきちんと割り振られていることがわかる。
これで、仮想スイッチ経由でホストOSと接続する、vEthernetから始まる仮想NICが二つ出来ているので、必要なIPアドレス等の設定を行う。
ゲストOSにNICを設定する際には、Hyper-Vマネージャーから仮想マシンの設定画面を開き、各ネットワークアダプターの「仮想VLAN IDを有効にする」にチェックを入れて、対応させたいVLAN IDを入力する。
続いて、対向スイッチとなる CG-SSW08GTR でも必要な設定を行う。
ここでは、ポート1、2をリンクアグリゲーションで束ねトランクポートとしてサーバに接続、ポート3～5をVLAN2、ポート6～8をVLAN1のアクセスポートとする。
そのため、WebGUIにアクセスして、まず「Aggregation」の設定でPort1、2をGroup1として、リンクアグリゲーションを組む。
次に「802.1Q VLANs」を開いて、デフォルトではVLAN1しかないため、VLAN2を追加する。
そして、それぞれのVLANの設定を次のようにした。
VLAN1はPort6～8及びTrunk1にチェックを入れる。
VLAN2はPort3～5及びTrunk1にチェックを入れる。
続いて、「802.1Q VLANs」の画面から「Port Config」ボタンをクリックして、ポートごとのタグVLAN設定を行う。
Trunk1のみタグを付けたまま送受信を行うので、「VLAN aware Enabled」、「Member Check」にチェックを入れ、Accept Frame Typeは「Tagged Only」、Pvidは「None」とした。
なお、Pvidで「None」を選択するには、一度「VLAN aware Enabled」にチェックを入れて「Apply」をクリックした後、再度「Port Config」をクリックしてこの画面に戻ってこないと駄目なようだ。
Trunk1の設定は自動的にPort1、2にも反映されるので、そちらの設定はいじる必要はない。
以上で設定は完了したはずなので、Pingを打ちながらLANケーブルを抜いたり挿すポートを替えたりして、リンクアグリゲーションによる冗長化、VLANによるネットワーク分離がきちんと機能していることの確認を行った。
さて、機能確認が終了したら、パフォーマンスの確認も行う必要があるだろう。
仮想スイッチでVLANの処理をさせるとCPU負荷が高くなって大変だという事はよく言われているが、実際にどんなものなのかはやってみなければわからない。
ということで、構築途中に一旦VLANなしの更改前構成にしてCPU負荷を測定し、上記手順にて構築したNICチーミング＆Hyper-V仮想スイッチでのVLAN構成でも同様に測定して、比較してみることとした。
テスト方法として、異なるセグメントのクライアント2台から同時に、ホストOSに対してiperfでパケットを送り続けてネットワーク負荷を掛けた。
まずは、NICチーミング＆VLANなしの更改前と同等構成で、物理NICに仮想スイッチを１つずつ割り当て、仮想NICもその仮想スイッチから１つずつ割り当てている状態での測定結果である。
CPU使用率はアクティブコアで50～60%程度といったところだ。2Gbps近い通信量だと、単純に仮想スイッチに流すだけでもCore2系ではそれなりのCPU負荷となるのだろう。
続いて本命の、NICチーミング＆VLANありの更改後構成では次の結果となった。
あれ？何だか予想外にCPU使用率が低いな…、と思ってよく見ると、受信速度がそれぞれ400Mbpsも出ていない。
一体どういう事だと、クライアント1台ずつで速度測定すると、単体接続では900Mbps以上出る。
これはひょっとして CG-SSW08GTR できちんとロードバランスされず、1本のLANケーブルを共有している状態になっているのではないかと考え、IPアドレスや宛先ポート番号を変えてみるが、状態は変わらない。
Webの製品情報やPDFのマニュアルを読んでも必要な情報がなかったが、色々と探したところ、WebGUIのヘルプ内にてAggregationの項目に以下の記述を見つけた。
Default port selection method is XOR of source MAC address and destination MAC address.
MACアドレスベースでロードバランスしていると分かれば話は簡単なので、クライアントの該当NICのMACアドレスを、デバイスマネージャの設定画面で既存のものから末尾を一つずらしたものへと変更した。
それからもう一度測定をやり直したところ、以下の結果が得られた。
今度はきちんとロードバランスされ、受信速度がそれぞれ900Mbps以上となった。
肝心のCPU使用率は、アクティブコアで70～80%程度となり、チーミング＆VLANなしと比べて20%ぐらい上昇している。
以上より、噂通りチーミング＆VLANによってCPU負荷が上昇することが裏付けられた。
2つのコアのCPU使用率は結構なものとなったが通信速度自体に問題はなく、残り2つのコアは遊んでいるので、別の負荷が掛かる作業を同時に行っても、速度への影響はさほど出ないと思われる。
また、CG-SSW08GTR でのMACアドレスベースのロードバランスは、クライアント台数が少ないと偏りが大きくなる可能性がある。
しかし、実際の利用シーンではサーバからクライアントへの送信が通信量の大半を占め、そちらはWindows Serverの「動的」負荷分散となるため、問題はないであろう。
テスト時のようなクライアント2台同時にフルスピードでの通信を行う事も滅多にないので、多少のCPU負荷上昇は許容できるものとして、これで運用環境へと移すこととした。
さて、予定通りNICチーミング＆Hyper-V仮想スイッチでのVLANの構築は完了したが、これがネットワークの冗長性に寄与するのかというと、他にSPOF（単一障害点）となる場所が多すぎて実際にはほとんど意味がなく、自己満足で終わっている。
サーバのメンテナンス等でLANケーブルを一旦抜いた後、接続し直す時に Pro/1000 PT Dual Port の2つあるポートにはどのケーブルを繋ぐか悩まなくて良くなるというメリットがあるぐらいだろうか。
あとは、このブログネタとなったというのも大きいかもしれない。
コメント 0