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

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 |

2011/02/27 (日)

[]TRILLはEthernetに何をもたらすのか?

餅は餅屋に、とも思うのですが、今回のエントリーは(も?)自分の学習メモ程度のクオリティということで斜めに読んで下さい(&間違いがあったら是非ご指摘ください。大歓迎。というか、ぜひ教えて下さい…。)。また、現時点で私はTRILLが実装されたスイッチを実際に触ってみたことはありません。完全に机上の情報ベースです…。

IETFのウェブサイトに最新の情報はありますが、まだTRILLはすべてが確定した仕様ではありません。…が、そこは世の常というか、各ベンダーは先行的に対応製品のリリースを開始しています。

http://datatracker.ietf.org/wg/trill/charter/

また、本エントリーの絵は"Brocade IP Primer"資料より使用させて頂いています。また、内容についても本書から学んだ内容が多く盛り込まれています。

「Brocade IP Primer」はネットワークの基礎からTCP/IP、DCBやTRILL、L2スイッチング機能としてLAGやVLAN、STPなど、L3スイッチング/ルーティング機能としてOSPFやMPLS、BGPなど、さらに上位レイヤー機能としてロードバランシングなどまで、非常に幅広い内容を、約400ページにわたってまとめた、無償で入手できる資料としてはとてもよい資料です(もちろん英語ですけど)。Brocadeウェブサイトで特に登録などもすることなく参照およびダウンロードが可能です(PDF版は約20MB)。

f:id:takaochan:20110224005504p:image

TRILLとは "Transparent Interconnection of Lots of Links" *1 の略称です。意訳的には、「多接続構成における透過的相互接続仕様」といった感じでしょうか。メッシュ的に接続されたネットワークにおいて、STPのように「論理的にツリー構造のパス構成とすることによりループのないネットワークにする」というやり方ではなく、「多接続構成をそのまま活用して成立するマルチパスなネットワーク構成にする」というやり方を実現するために策定が進められている仕様です。マイナス思考なSTPとプラス思考なTRILLとかいったらいいすぎでしょうか…(^_^;)。個人的にはベンダーによる独自拡張や様々な種類があることなど色々な理由でSTPは早く消え去って欲しいと願っていますので、そういう意味でもTRILLには期待しております。

TRILLのポイントをまとめると、以下の通りです。

  • 最短パスルーティング方式(Shortest path routing)を用いる
  • L2レベルで機能する
  • マルチホップに対応する
  • 任意の接続形態で使用することができる
  • 既存のリンク状態に基づいたルーティングプロトコル(IS-IS)を使用する
  • STPを用いた既存のEthernetにおいても互換性を確保する

L2レベルの仕様ですので、IPを用いないFCoEであってもTRILLは有効です。…というか、FCoEでも使えることが求められて策定が進められているマルチパス仕様といえるかもしれません。

「Transparent / 透過的」とあるとおり、TRILLは接続ノード側での対応は不要で、ノードはTRILLを一切意識することなく普通のEthernetフレームを送受信することができます。TRILLは「TRILLが構成されたスイッチ間」で機能し、いわば複数スイッチから構成されたFabricを構成します。Fabric内のスイッチ間接続パスがそれぞれコスト判断されてマルチホップが構成されるため、接続ノードは送信元も送信先もFabric内でどの経路を伝ってEthernetフレームが転送されてきたのかを意識することなく通信が成立します。基本的には最もパスの少ない最短経路が使用されますが、パスコストが等価な接続経路が複数あった場合は、それらのパスをどちらも使用する、いわば負荷分散が行われます(もちろん、意図してパスを指定することもできます)。

TRILLはL2レベルのマルチホップルーティングプロトコルです。ルーティングプロトコルといってもIPに依存したL3レベルではなくL2レベルで行われているルーティングであるところがポイントです。このため、IPを使用しないFCoEであってもTRILLの恩恵を得ることができます(もちろん、IPパケットであっても下回りでTRILLを使用することは可能です)。また、お互いのルーティング情報やリンクステート情報を交換しあってTRILL Fabricが自動的に再構成されるため、スイッチ追加の際に、STPのように「事前に設定をした上で接続する」必要がありませんし、STPのようにブロックポートの選定を行う必要はないので再計算中に通信がBlockingされてしまうようなこともありません。

f:id:takaochan:20110224005505p:image

TRILLにおけるマルチホップルーティングは、MACアドレスヘッダとTRILLヘッダをノードから送出されたEthernetフレームに付加する(つまりEthernetフレームをEthernetフレームでカプセル化する)ことによりL2レベルのルーティングを実現しています。元々のEthernetフレームのヘッダとして指定されている送信元MACアドレスおよび送信先MACアドレスには手を加えずに、ヘッダを付加しているという点がポイントです。IPパケットがEthernetフレームにIPヘッダを付加しているのと同じように、EthernetフレームにさらにTRILLヘッダを付加することによりノードで送受信されるEthernetフレームはそのままで、TRILL対応スイッチを経由する毎に書き換えられるヘッダはカプセル化している「外側のMACアドレスヘッダ」とすることにより整合性を維持したままでルーティングが行われます。

f:id:takaochan:20110227135001p:image

TRILLスイッチはノードから受け取ったEthernetフレームに、VLAN Tagにも対応したMACアドレスヘッダを付加してカプセル化します。この部分ではTRILLのルーティングテーブルに基づいてネクストホップとするスイッチが送信先として指定され、ホップしていく度に送信元と送信先のMACアドレスが書き換えられていきます。合わせて、EthernetフレームにはTRILLヘッダが付加されており、こちらには最初のスイッチと最終的に到達させるスイッチがそれぞれRBridge (Routing Bridge)として指定されます。RBridgeはTRILLを構成するFabric内でIDとして相互に識別が行われ、いわばL3におけるIPアドレスのように機能します。

TRILLが使用されている場合、Ethernetフレームの転送は「ルーティングテーブルに基づいて」行われるため、物理的なループ構成は問題となりません。TRILLにおけるルーティングは送信先とするRBridgeごとにホップ数と送出元とするEthernetポートがルーティングテーブルに基づいて管理されているため、物理的にループ構成となっていてもEthernetフレームは(複数の経路があるとしても)必ず決まった経路で送受信されることとなるためです。基本的にはFCのFabricでループが発生しない仕組みをEthernetに持ち込む仕様がTRILLであるといえるかもしれません。

すでに各社からTRILLの仕様確定を見越した実装が進んでいますが、(当初はともかく)ぜひ各社には独自仕様などに走らず、最終的にはTRILLを高い互換性・相互利用性のある規格としいって欲しいと思います。そして早くSpanning Treeを駆逐して下さい。スパツリ嫌い(^_^;)。

*1日経BPにおけるTRILLの解説はこちら

2011/02/06 (日)

[]VMware ESXにおけるメモリ管理(11) - 仮想TLB方式ってどういうこと?

VMware ESXにおけるメモリ管理』シリーズ

(1) - 序:他のリソースとの違いはなに?

(2) - 仮想化インフラにおけるメモリ管理って?

(3) - メモリに関する仮想化支援機能(Intel EPT/VPID, AMD RVI/Tagged TLB)

(4) - メモリを割り当てるのは簡単だが、回収するのは難しい

(5) - 透過的ページ共有

(6) - Dynamic Memory on Hyper-V 実装編

(7) - Dynamic Memory on Hyper-V 設定編 +α

(8) - バルーニング

(9) - スワッピング

(10) - メモリ圧縮 (1)

…の続きです。

「メモリ圧縮(1)」と来たんだから、今回は「メモリ圧縮(2)」かと思いきや、再度脱線。今回のエントリーは下記『プロセッサを支える技術』(Hisa Ando/技術評論社)を読んでお勉強した内容の取りまとめにさせて頂きます。

プロセッサを支える技術  ??果てしなくスピードを追求する世界 (WEB+DB PRESS plus)

プロセッサを支える技術  ??果てしなくスピードを追求する世界 (WEB+DB PRESS plus)

(3) - メモリに関する仮想化支援機能(Intel EPT/VPID, AMD RVI/Tagged TLB)の内容のもうちょっと深いところといったところでしょうか。本書、とても内容が深く難しい部分も多く、正直理解し切れていない箇所も多くあるのですが、それでもとても面白い1冊でした。CPUは単なる電子計算トランジスタが超高密度に集積されただけのものだと思っていたのですが、いやいやCPUって奥深いんですね。マルチコア化することの考慮点や、なぜ1次・2次キャッシュの容量を大きくしないのか、いかに無駄なく計算サイクルを有効活用するかなど、CPUがとても「考えられて」作られているんだと思い知らされました。

さて、本書を読んでより深く理解できたのがTLB (Translation Lookaside Buffer)でした。

CPUはメモリのデータを読み書きしながら計算を行うわけですが、各プログラムが必要とするデータサイズはそれぞれ異なるため、最近のほとんどのOSはそれらのメモリ上データをページと呼ばれる単位で区切って管理する方式を採用しています。OSはどのプログラム(プロセス)のためのメモリデータがどのページに書かれているかをページテーブルを使って管理し、論理アドレスによってアクセスされたメモリデータを物理アドレスに変換しています。ページテーブルによって物理アドレスが隠匿されていることにより、プログラムから見るとフラットなメモリ空間が提供されることとなり、メモリ管理をシンプルに行うことができるようになります。

しかしページ方式におけるページテーブルにはデメリットもあります。OSがプログラム(プロセス)からの要求に対してメモリアクセスを行う場合に、毎回ページテーブルを参照していると1回のメモリアクセスのためにさらに1回の(メモリ上に保存されている)ページテーブルの参照が必要になってしまします。この問題を改善するために用意されている仕組みがTLBで、CPUはページテーブル用のキャッシュを用意することによって頻繁にアクセスされるページのインデックスを管理することにより、都度ページテーブルを参照しなくてもよいような仕組みを提供しています。

このTLBの仕組みは、仮想化においてもとても重要です。ゲストOS上のアプリケーションは論理アドレスに基づいてメモリページへのアクセスを要求するわけですが、TLBの仕組みがなければゲストOS上のアプリケーションからの要求はゲストOS側のページテーブルで「ゲストOSは物理メモリだと認識してるが実際にはHypervisor側のVMM (Virtual Machine Monitor)によって用意された仮想メモリアドレス」に変換され、さらにHypervisor/VMMは自身のページテーブルに基づいて実際の物理メモリページアドレスに変換するという2重のアドレス変換が必要となってしまいます。TLBにより、ゲストOS上から要求された論理アドレスとHypervisor/VMMによって紐づけられている物理アドレスを直接キャッシュテーブルとすることができれば、メモリアクセスに関しては「TLBにヒットする限り」は仮想化されていない場合とまったく同じ性能を発揮することができることになります。

ところが、これにてめでたしめでたしとはならないところが残念なところ。x86プロセッサではページテーブルをハードウェア的にTLBに書き込むハードウェアテーブルウォーク機構(Hardware Table Walk)を持っているため、ページテーブルとしてゲストOS上のアプリケーションが使用する論理アドレスとHypervisor/VMMが管理する物理アドレスを結びつけたページテーブル(SPT / Shadow Page Table)を用意する必要があります。また、ページテーブルはプログラム(プロセス)単位で作られるため、ゲストOS側でページテーブルが切り替えられる度にSPTを作り直すとするとオーバーヘッドが大きくなってしまいます*1

このSPTにおけるオーバーヘッド問題に対して上手くページテーブルを構成する仕組みが「仮想TLB方式」です。仮想TLB方式では、ページテーブルについてはゲストOSが自由に管理できるようにしますが、SPTはHypervisor/VMM側が管理します。ゲストOS上のアプリケーションは論理アドレスに基づいてメモリアクセスを要求しますが、最初の時点では対応する物理アドレスの情報はTLBにもSPTにも存在していないためページフォルトにより制御がHypervisor/VMMに移ります。Hypervisor/VMMはゲストOS側のページテーブルを参照し、Hypervisor/VMMが管理するページテーブルにおいて紐づけられた物理アドレスの情報をSPTに書き込みます。このような仕組みとすることで、SPTをTLBのように構成する(アクセスがあったページテーブルのエントリーを都度書き込んでいく)ことができるようになります。

仮想TLB方式ではゲストOS側のページテーブルはゲストOSが自由に変更するために仮想TLB/SPTとの間で矛盾が発生することになります。しかしこの点については、TLBのクリア処理を行う特権命令を例外とすることによって処理をHypervisor/VMMに移し、ゲストOS側のページテーブルにおける変更を仮想TLB/SPTに反映することにより問題がないように処理されます。

さて、だいぶ論理に走ってしまっていました。次回は具体的なvSphereにおける実装内容に戻りたいと思います。

上述した『プロセッサを支える技術』にはこうした解説が山のように含まれています(しかも、メモリとの話は重要な要素ではありますが、それでも主題ではない部分のほんの一部です)。このエントリーを読むような方にはとてもオススメです。

*1VMwareが他社に先行して「実用的な」ハードウェア仮想化ソフトウェアをリリースできたのは、SPTオーバーヘッドをとても上手く管理する仕組みを作ることができたからでしょう。少なくとも、初期のハードウェア仮想化支援機能におけるVMX exit/entryよりも高速に処理できるレベルであったこっとは凄いと思います。

2011/02/05 (土)

[]オール電化:電気代017,018,019 - 2010/10/22〜2010/11/21 (31日間),11/22〜12/19(28日間),12/20〜2011/1/23(35日間)

11月に10月分までをまとめて以来、さぼっていました…。唯一続いている?家関連エントリーなんですが…。ということで、17回〜19回としてまとめてエントリーさせて頂きます…。

オール電化戸建て住宅/夫婦+子1人世帯の参考情報です。契約メニューは電化上手、契約容量は10kVA、割引対象機器容量は通電制御型2kVAのIHコンロです。なお、基本料金は2100円です。

電気式床暖房、洗濯乾燥機、食洗機、オイルヒーターなど、2歳児がいることもあり少々「しっかり」使いすぎているので、子育て中の方向けの参考情報です。大人だけならもっと少なく済むはず。

なお、年度比較グラフでは1月が最初のプロットとなるため、グラフが表示されていません。文中に使用量を書いておきます(& Google Chart的にはデータを含ませてあります)。

  • 電気代:請求額

まずは電気代から。(まだない)黒線が2011年、緑線が2010年、赤線が前年(2009年)となります。

つ、ついに電気代が20,000円オーバー…。2011/1分の電気代は21,973円でした。まぁ年末年始に家にいましたし、遠慮なく床暖房とオイルヒーターを使っていましたので、まぁ想定された結果ではあります。請求も35日分とちょっと普段よりも期間が長めだということもあるかとは思いますが、それでもやはりそうですか…といった感じです。ということで、グラフ幅を20,000円リミットから30,000円リミットに修正しました。まだプロットは表示されていないけど…。

月別電気代(前年比較):折れ線グラフ

  • 電気代:時間帯別内訳

続いて、時間帯別の内訳。

あ、1月分の朝晩枠の電気代が対前月比で2倍以上ってどゆことぉぉぉぉ。まぁ昼間も倍、夜間も1.5倍ぐらいですからまぁそれだけ寒かった&家にいたってことだとは思いますが、それにしてもこのグラフの線の変化はすさまじいことになってしもうた…。唯一の救いは、電化上手プランだと電気代が増えるとその分割引額も多くなってくれることぐらいですね。

時間帯別内訳:棒グラフ

  • 電気使用量

最後にkWh単位での電気使用量の推移。今年は実線、2010年は太めの点線、2009年は細めのて点線で示しています。

2011/1月の電気使用量は1390kWhでした。朝晩が597kWh、昼が149kWh、夜が644kWh。夜間の使用量はほぼ洗濯乾燥機と夜間に使っていた分の暖房器具だと思うので、それほど大きく変化しないのですが、朝晩は…。12月分に対して1月分の電気使用量が倍なんですが、なんでしょうかね?

時間帯別使用量変移:折れ線グラフ

さて、2011年に入りましたのでこれで年間を通じた比較ができるようになりました。今年も細々とこのエントリーは続けていきたいと思います。誰かの参考になっているかどうかは知りませんが、単に記録としても必要なので。