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

Simple is Beautiful このページをアンテナに追加 RSSフィード Twitter

2005 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2012 | 01 | 02 | 04 | 05 | 07 |
2013 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 09 | 10 | 12 |
2014 | 01 | 02 | 03 | 04 | 07 | 08 | 09 | 11 | 12 |
2015 | 01 | 02 | 04 | 05 | 06 | 12 |
2016 | 01 | 11 | 12 |
2017 | 03 | 04 | 05 | 06 |

2010/12/27 (月)

[]MSC2010のHyper-V関連資料からリソースについてのおさらいをしてみた

Microsoft Conference 2010の資料が(もうちょっと前ですが)公開されたので、Hyper-V関連について資料を斜め読みした内容を取りまとめてみます。

  • CPU

Hyper-Vでは、物理CPUにおける各コアをLP (Logical Processor)、ペアレントパーティションによる管理CPUをRoot VP (Virtual Processor)、ゲストOSに割り当てられたCPUをVPとして管理します。つまり、Hyper-Vが全てのLPを管理しており、ペアレントパーティションについてもメモリの認識は特殊なVPとなっています。

f:id:takaochan:20101226104554p:image

割り当てCPU数に加えて、リソースコントロールとしては、%による予約と上限の設定とシェア値の設定を行うことができます。

Hyper-Vは最大で64LPまで、LPあたり最大8VPまでをサポートします。ただし、同時稼働最大数は384VPまで。

LPとVPについては、それぞれの使用率をパフォーマンスカウンタによって取得することが可能です。

f:id:takaochan:20101226104555p:image

肝は、ペアレントパーティションもCPU負荷を与えているという点。ペアレントパーティションは全てのLPをRoot VPとして認識しているため、ペアレントパーティション側でCPUに負荷をかけると、全てのゲストOSのCPUパフォーマンスに影響を与えることになります。

  • Memory

メモリについては、Windows Server 2008 R2 SP1における新機能の1つ、Dynamic Memoryがポイントとなります。もちろん、これまでどおりの静的なメモリ割り当てをすることも可能です。

Dynamic Memoryは、割り当てメモリサイズを動的に増減させる機能。ゲストOSが認識する形でメモリの増減が行われるため、ゲストOS側もサポートしている必要があります。そのため、残念ながらサポートされるゲストOSは、Windows Server 2003 SP2以降とWindows Vista SP2 (Enterprise以上)以降のみ。当然、ゲストOS側に導入する統合サポートについても、SP1のものにアップグレードが必要です。

f:id:takaochan:20101226104552p:image

アーキテクチャにおける肝は、ペアレントパーティションであるWindows Server 2008 R2 SP1における、ゲストOSごとのメモリマネージャ(vmwp.exe)と、それらの間における調整を行うメモリバランサー(vmss.exe)によってメモリ管理を実装している点。Hyper-V自体は非常にシンプルなHypervisorとなっているため、メモリ管理の機能はペアレントパーティション側に実装されています。

f:id:takaochan:20101226104553p:image

メモリバランサーは、ホスト側のVSP(Virtualization Service Provider)とゲスト側のVSC(Virtualization Service Client)の間でVMBusを通じた連携管理を行います。VSPはメモリリソースの割り当てを、VSCはメモリリソースの追加・削除の要求を管理します。

メモリの追加はゲストOS側の対応と連携したHot add、メモリの回収はバルーニングによる回収となります。回収もVVSP/VSCの組み合わせによるメモリバランサーが実施しています。

f:id:takaochan:20101227004453p:image

仕組みはおおよそVMwareと同様で、バルーンドライバがゲストOS内でメモリページを確保し、それをHypervisor側に(Hyper-Vの場合はVSCからVSPに対して通知することにより)回収させるようです。

f:id:takaochan:20101227004452p:image

  • Disk

Hyper-VにおいてゲストOS側が使用できる仮想ハードディスクは、仮想ハードディスクファイル(.vhd)とパススルーディスクの2パターン。パススルーディスクの場合、特定のパーティションがダイレクトに仮想ハードディスクとしてゲストOSに認識されます。

f:id:takaochan:20101226104556p:image

VHDファイルには固定サイズ(Fixed)、可変サイズ(Dynamic)、差分の3種類があります。

固定サイズはVHDファイルにおける基本パターン。ゲストOSに認識されるディスクサイズほぼそのままのVHDファイルが作成されます。本番環境向けのサーバOS用のゲストOSに対しては、基本的には固定サイズVHDの割り当てが基本となります。

f:id:takaochan:20101226104557p:image

可変サイズはVHDファイルへの書き込みに応じてVHDファイルのサイズが拡大される形式。固定サイズと比較して少しパフォーマンスが低下しますが、初期状態における実際のディスク消費容量を抑えて仮想ディスクファイルを作成することができます。…が、それよりも問題なのはファイルのフラグメンテーション。同一ディスク内に複数の可変サイズVHDファイルを配置した場合、お互いにフラグメンテーションしてしまう可能性があります。

差分VHDファイルは、1つの親VHDファイルに対してそれぞれの子VHDファイルが差分として生成される特殊な形式。子VHDのさらに子VHD(孫VHD)を作成することもできます。

f:id:takaochan:20101226104558p:image

多段チェインした場合におけるパフォーマンス低下も課題でしたが、Windows Server 2008 R2 SP1では可変サイズVHDと同程度ほどのパフォーマンスに改善しているとのことです。使い方はサーバ用途というよりも、仮想デスクトップや開発環境、キオスク端末的な使い方などのためとなるかと思います。

最後にパススルー。こちらはパフォーマンスを最重視する場合には選択肢となり得る方式ですが、固定サイズVHDとそれほどパフォーマンス差があるわけでもなく、特殊な必要性がない限りは選択する必要性はない方式かと思います。

  • ネットワーク

個人的に、Hyper-Vにおいて一番わかりづらい部分がネットワークです。その理由は、仮想スイッチの実体があまり明確に扱われていないからのような気がします。また、他のHypervisor製品がネットワーク機能の強化に力を入れている中、R2 SP1でもそれほど強化されなかったのも残念なところ。

Hyper-Vにおけるネットワークは、外部と通信が可能な「外部」、ペアレントパーティションおよび他の仮想マシンとのみ通信が可能な「内部のみ」、仮想マシンとのみ通信が可能な「プライベート仮想マシンネットワーク」の3種類から選択することができます。

f:id:takaochan:20101226123555p:image

さらにHyper-Vにおいて残念な点が、仮想マシン側に構成される仮想ネットワークアダプタの扱いがまだ制約が多い点。統合サポートを導入することにより使用することができる高パフォーマンスな「統合ネットワークアダプタ」は、ゲストOSが物理デバイスとして認識する「完全な形のNIC」ではなく、ドライバがNICに見せかける「仮想的なNIC」となっているため、PXEの使用や、統合サポート未導入ゲストOSで使用できないなどの問題点があります。そのための回避策として「レガシーネットワークアダプタ」が用意されているわけですが、Windows Server 2008 64bitではドライバが含まれていないために使用できないなど、使い勝手があまり良いとは言えない状況です。

本番環境で使用するためには必須機能とも言えるチーミング対応については、一時期不明確でしたが、サポートされることが明確になっています。

他社が軒並み搭載してきている分散仮想スイッチに対して、Microsoftがどのような対策をうってくるのか、今後注目していきたいと思いますが、まずはR2 SP1ですから、その当たりが打ち出されてくるのはしばらく先になってしまいそうですね。

Live Migrationやクラスタリング、SCVMM関連など、Hyper-Vについてはまだまだ色々な情報が公開されていますので、ぜひMicrosoft Conferenceの資料は一通り目を通されることをオススメします。

http://www.microsoft.com/japan/cloud/msc2010/digital/default.mspx

2010/12/11 (土)

[]10GbEは単なる1GbEの高速化規格…なだけじゃない? - アダプタ編

※いろいろと情報収集しながら、自分のまとめのために書いているので、間違えや認識違いが含まれている可能性が高いです。識者の方、ご指摘頂けると嬉しいです。このエントリーは間違えを修正したり、追記したりを継続的に行っていきたいと思っています。※

すでに各社から10GbE NICがリリースされていますが、面白くなりそうなのはこれからです。それは、今後登場してくるNICが単なるNICではなくCNA (Converged Network Adapter)によるDCB (Data Center Bridging) *1中心の市場に移行していくことになっていくであろうから。ただし、標準的なEthernetと拡張Ethernet仕様とも言えるDCBは仕様として多くの違いがあるため普通には共存できません。また、DCBは完全にL2レベルの仕様となりますので、Routingすることはできません。DCB普及の最大の課題はこの壁を乗り越えるだけの価値を提供できるかどうかといえるのかもしれません。

すでにQLogic 8200シリーズや、Broadcom 87712シリーズなど、各社から続々と新世代NICがリリースされています。HBAをメインで扱っていたベンダー(QLogicなど)とNICをメインで扱っていたベンダー(Broadcomなど)、さらにはInfiniband市場をリードしているMellanoxなどまでが直接的に競合するようになり、市場シェアを巡る争いは熾烈です。いずれの製品もFCoEおよびiSCSIの完全オフロードに対応。当然ながらTCP/IPも使えますし、それらのプロトコルのオフロード処理を同時に行うことができるので、これ1枚でLANとSANのI/Oをすべて統合できます。

ところでCNAをFCoEのためのアダプタであると誤解している方が多いようなのですが、どちらかといえば逆で、FCoEがDCBを必要としていうほうが正しいような気がします。FCoEはプロトコルとしてはFCのままで足回りをFibre Channelから拡張されたEthernetに変更した規格と言えますので、通信は非常にセンシティブ。ロスレス・低遅延が求められますのでどうしてもCNAが必要なわけです。よって、DCBはiSCSIなどを使う場合であっても同様のメリットをもたらします。

  • QLogic 8200シリーズ

f:id:takaochan:20100818140400j:image

http://ascii.jp/elem/000/000/560/560092/

物理的には主に光ファイバーケーブルを使用(銅線の場合もある)しますのでFCのHBAのようですが、ベースはEthernetであり、その中にはFCoEであったり、iSCSIであったり、TCP/IPだったりが流れる…まさに統合インターフェイスです。

このQlogic 8200シリーズのポイントが、NPAR機能を搭載している点。NPARとはNIC Partitioningの略称で、その名の通り、10GbEの1つのインターフェイスを論理的に複数の帯域幅を指定したインターフェイスに区分してしまうことができます*2。OSからはそれぞれの論理インターフェイスがPCIeインターフェイスとして認識されますので、OS側に特別な対応は不要(ドライバは必要!)。どんなOSであっても使用することができます(QLogic 8200の場合は1ポートを最大で4つまで分割することができるようです。Dualポートのカードなので、カード当たり8つに分割できるということになります。)。

CNAはOS側からはネットワークアダプタとストレージアダプタの両方で認識されます。ストレージアダプタの場合、BIOSで構成することによってFCoEとiSCSIそれぞれのアダプタとして認識させることができます。

ちなみにHPのCNAはVirtual Connect FlexFablicと組み合わせることによって再起動したりすることなく帯域幅の再調整が可能であるメリットがありますが、QLogicはダイナミックな帯域調整までは現時点でできない模様。そのかわり、アダプタ側だけで機能していますので、どのベンダーのどのスイッチであっても組み合わせて使用することができます*3

NPARとSR-IOV (Single Root I/O Virtualization)の違いはどこにあるのでしょうか?最大のポイントは、OSもしくはHypervisor側に対応を求めるかどうかという点。NPARはOSに対して透過的なアダプタ側だけで実装されている機能ですので、どのようなOSであっても対応ドライバさえ使用することができればOS側からは単なる複数のアダプタとして可能ですが、SR-IOVは対応OS/Hypervisorとの組み合わせの場合でのみ使用することができる実装となっています。その代わり、SR-IOVはデバイスあたりに構成できる仮想インターフェイス数が128/256と、NPARの4/8よりもかなり柔軟性が高くなっています。「用途毎の通信を区分けする」ことをターゲットとしているNPARに対して、SR-IOVは「仮想マシン毎の通信を区分けする」ことを目的にしていると言えます(仮想マシンごとにSR-IOVによって用意された仮想的なアダプタを割り当て、Hypervisorを経由せずに直接的なI/Oを行う)。ちなみに、QLogic 8200はSR-IOVにも対応しています(その他、NIV(VNtag)、VEPA/VEBなど、とりあえずなんでも対応(^_^;))。

QLogicやBroadcomがCNAをリリースすることには多くのメリットがあります。最大のメリットは、各社からOEM提供されるということでしょうか。CiscoのM81KRなどはとてもよいアダプタだと思いますが、いかんせんCisco UCSでしか使用できないアダプタでした。対して、主にOEMによる販売を主軸とするQLogicやBroadcomなどがCNAの提供を始めれば、爆発的に普及していくことになるでしょう。来年は、DCB元年になるはずです。

次回はDCBを構成する要素である、TRILL、802.1Qxxなどの規格について考えてみたいと思います。

(メモリ管理シリーズもやめた訳じゃないんですが…ちょっと忙しくて止まってしまっています)

12/11 0:40 修正・追記。

12/11 0:54 修正・追記。

*1:ベンダーによってはCEE (Converged Enhanced Ethernet)と呼んだりもする

*2:当然ながら、その合計は10GbEである必要がありますが

*3:その他、FCoEやらiSCSI Boot、VLANサポート数、VLAN構成などの面でいろいろ違うみたいですが。