はてなブックマーク

vExpert Advent Calendar 12/5 エントリーです。 VMwareの仮想マシンを実行する製品には、共通してVIX APIというAPIが用意されています。公式のVMwareウェブサイトではこちら。 https://www.vmware.com/support/developer/vix-api/ このAPIは、vSphere ESXiはもちろん、WorkstationやPlayer、そしてFusionでも使用することができる共通のものとなっています。 …で、このAPIを使うと何ができるかといいますと、VMware Toolsがインストールされて動作しているゲストOSに対して、ネットワークを通すことなく様々な制御をすることができます。いわば公式なバックドア(^_^;)として使用することができる…とまで言うといいすぎですが、まぁ悪いこともできなくはないですね。 Workst

vExpert Advent CalendarもWeek3に入り、皆さんのステキなエントリーが続いていますね！今回は「分散スイッチングと分散ルーティング」のシリーズは１回お休み？して、今回は閑話休題 的なTipsエントリーをば。 Cisco UCSサーバを統合管理する機能といえばUCS Managerです。実体は Fabric InterConnect (FI) のフラッシュメモリに格納されたプログラムであり、FIに接続されたブレードサーバやラックマウントサーバ、シャーシ、各モジュール、FI自身に対する管理機能を提供しています。 UCS Managerは標準のGUIおよびCLIを提供していますが、バックエンドの処理インターフェイスはすべてXML APIとなっていますので、やろうと思えば、XML APIをダイレクトに叩いて操作することも可能ですし、UCS Managerを叩くAPIを使ってア

クリスマスシーズン到来ですね。vExpert Advent Calendar に参加することにしましたので、ちょっと怠け気味のこのBlogについても、一応4回以上、12月にエントリーをUpできれば…と考えております。果たして穴を開けずに乗り切る？ことができるのでしょうか(^_^;)。では、第1回の @mihochannel さんの エントリー『Fusion 6 で OSX Marvericks ゲストを立ててみた』 に続いて2日はこんな感じでまずは…。 分散ってどういうこと？ VXLANやNVGREなどのオーバーレイプロトコルが登場し、データセンターにおけるネットワークの考え方が変わってきたことに伴い、データセンターのネットワークでは分散スイッチングと分散ルーティングといった仕組みが一般化していくことになりそうです。分散スイッチングは、VMware vSphereでいえば いわゆるvDS

勢いで(3)です。...といっても、2週間ぶりですかね。(1)はこちら、(2)はこちら。なお、おきまりのお約束ですが、ここは個人ブログ。会社の見解などは含まれていませんし、情報の正確性も保証されませんのでそこのところはよろしく。 さて、(1), (2), と多分に推測や個人的な認識を元に色々と自由気ままに書いてきましたが、先々週に ipSpace.net で NSX Architecture というタイトルでWebinarがあり、さらに参加者向けにVMworld2013資料の公開も始まるなど、だいぶNSXの仕様などについて理解を深めることができましたので、(3)として書くことにします。なお、WebinarのプレゼンターはipSpaceを管理しているIvan Pepelnjakさん( @ioshints )に加え、VMwareのBrad Hedlund( @bradhedlund / Blo

結局8月は1本もエントリー書けませんでした…。反省。 San Franciscoで8/25-29に開催されたVMworld 2013。やはり今年の目玉はVMware NSXということになりましたが、リリース予定はCY2013Q4。年内ではありますが、まだしばらくは待つ必要がありそうです。この段階で推測を多分に含んだカタチでエントリーを書くことはちょっと躊躇われるのですが、まぁ特に責任ある？企業ブログというわけでもなし、個人ブログに自由に書くなら盛り上がっているときでしょ！ということでタイトルもあえてちょっと挑発的にいってみることにします(^_^;)。 VMwareは2012年にNiciraを買収し、2013年3月にvCloud Network & SecurityとNicira NVPを統合するVMware NSXを発表、そして今回のVMworldにおいて製品としての提供開始予定時期が発表

ご存じ Nexus 1000V は Cisco が提供する仮想スイッチラインナップです。当初は VMware vSphere 向けの分散仮想スイッチを拡張・置き換える 3rd Party 製スイッチモジュール Nexus 1000V Switch for VMware vSphere だけが提供されていましたが、今年 次男坊として Nexus 1000V for Microsoft Hyper-V の提供が始まりました。今後 三男坊？ Nexus 1000V for KVM の提供も予定されています。これらは各Hypervisorに対応するNexus 1000Vであるという意味で、共通の仕組みを持った仮想スイッチといえます。もちろん、各製品独自の実装に合わせるためであったり、想定される使われ方などにも基づいて、それぞれの構成に微妙な違いはありますが、可能な限りNexus 1000Vとしての

FCoEは "Fibre Channel over Ethernet" の略称ですので、その名の通り、主にストレージネットワークに使用されてきたFCをEthernetに統合するための仕様／プロトコルです。このあたりのページを参照頂くと、わかりやすい説明が図付きで掲載されています。 Ethernetといっても、標準Ethernet(もしくはClassic Ethernet)ではカバーできないサイズのFCフレームがペイロードとなりますので、単純にタイプがFCoEとなるというだけではありませんが…まぁEthernetとFCを統合するための新しいEthernetだと思っておけばよいかとは思います。 FCoEは仕様としては、Data Center Bridigng (DCB) と FCをNetworkに乗せるための仕様*1の2つから構成されており、DCBはIEEE802.1における3つの仕様*2に基

エントリーを書き始めたら前置き部分だけでちょっと長めの文章となってしまったので、グダグダ感は多少ありますが…公開しちゃいます…。最近、Blogエントリー書けていなかったもので…。3月に1つもエントリーも公開していないってのも…寂しいな、とm(_ _)m Hypervisorにおける仮想スイッチはその名の通り、論理的な(ソフトウェア)スイッチです。基本的には、L2レベルでEthernetフレームをスイッチングする処理を行います。VLANタグの付加や取り外し、トラフィックシェーピング、QoS制御、ACLコントロール、SPAN/RSPAN等々、様々な機能を提供していることもありますが、とはいっても基本はMACアドレスに基づく通信制御を行うことこそが役割といえます。そういう意味では、物理スイッチと物理サーバの関係性をそのままソフトウェア化したものが仮想スイッチと仮想マシンの関係、ともいえます。 物

さっそく週1回更新の目安から遅れが生じ始めております…(^_^;) まぁ無理してまでは書くつもりはないのですが、なによりもアウトプットすることによって自分の中で整理がつけられるメリットは大きいので、気合いを入れすぎずに続けられたらとも思っています。自分のために…m(_ _)m さて、ちょうど数日前に最新バージョンの日本語版のNexus 1000V 4.2(1)SV2(1.1) インストレーション アップグレードガイドがリリースされましたので、今回はNexus 1000Vについてです。というか、Nexus 1000Vは実は？かなり奥深いので、今回のエントリーではほんのさわり部分についての紹介までとなります。 本当は、まずはとても簡単に行うことができる「Nexus 1000Vのインストール方法」について書こうかと思っていたのですが、インストールそのものは簡単でも まずはNexus 1000Vの

Windows Server 2012で一番面白そうに感じる機能が、SMB over Remote Direct Memory Access (RDMA) まわり。Hyper-Vにしろ、SQLにしろ、SMBの下回りとしてRDMAを使おうという実装がとても次世代的(^_^;)。ファイルシステムとしての実装なので、アプリケーション側には一切の変更・対応が必要ない、という点がよい。 対応ネットワークについては、現時点ではInfinibandが最も普及したハードウェア要件かもしれないが、次第にiWARPやRoCEもサーバ用インターフェイスとしては普及が進み、RDMAがサーバ用途の通信における下回りとしてSMBのみならずNFSやiSER (iSCSI Extentions for RDMA)などが実用化されていくと面白くなるのではないかと思う。 Microsoftがここで公開している資料(PDF)で

忙しくてちょっとエントリーが遅れ気味です。 さて、前回はESX ServerにおけるCPUの同期スケジューリング処理について書きましたが、今回はそれ以外のESXにおけるCPU管理の要点について、ざっと書いてみたいと思います。 (1) - ゲストOSは自分が完全にCPUを管理していると思っている (2) - CPUスケジューリングは色々 (3) - CPU同期スケジューリング …の続きです。 ■スケジューラセル単位での分散ロック ESXホストでは、スケジューリング処理を"スケジューラセル"と呼ばれる単位で管理しています。CPUにおけるスケジューラセルとは、ローカルな物理プロセッサ群におけるスケジューリング領域として機能する単位(ドメイン)を意味します。言い換えれば、CPUスケジューリングはセル単位で処理されており、他のセルには影響を与えることはありません。スケジューラセルの仕組みは、多くのC

Networkに続いてStorage(ホワイトペーパーとしては、「記憶域」と「記憶域と可用性」がベース)。Windows Server 2012では大幅にストレージ関連の機能も強化されるが、Linuxにおいて実装が進んでいる機能の後追いといえる部分も多数ある。しかし、Windowsにおいてこれらの機能が実装されることには大きな意味があり、OSとして新しい次元に進んでいることがわかる。サーバ仮想化によってOSの存在は単なるアプリケーションの実行環境になってしまうかと思われたが、こうして進化した次世代OSはまだまだコンピューティングの中心に位置することになるのかもしれない。 ノード メモリエラーの分離：特定ユーザモードアプリケーションのメモリエラーを分離することによるデータ整合性の維持 NICチーミング：SMB通信などにおける可用性の向上 記憶域 記憶域プールと記憶域スペースから構成される論理

niciraがステルスモードを脱し情報を出し始めましたね。取材も実施しているだけあって、日本語ではPublickeyの記事が一番詳細に報じているようです。 …で、まだ詳細な資料が出てきているわけではありませんし、もちろん技術に触れたわけでもありませんので、ざっと公開資料を眺めた感想程度ですが、思ったことを書いておこうかと思います。1年後ぐらいには恥ずかしくて消したくなるかもしれませんが…(^_^;)。 興味深いのが、DVNI (Distributed Virtual Network Infrastructure) 。OpenFlowの課題は「いかに既存ネットワークと融合するのか」だと思っているのですが、この点について対応する仕組みがきちんと考えられているようです。 "1. Virtual Networks" として物理的なネットワークとは切り離された仮想的で柔軟なネットワークを構成できるこ

あー…忙しさに追われて、1ヶ月以上エントリーに間隔が空いてしまいました。本当はvSphere 5.0 概要シリーズをリリース前に終えるつもりでいたのですが、終えるどころかStorageだけ書いてそこで止まってしまっています…(もし楽しみにして頂けていたとしたら、すみません)。アウトプットするのも大変なんですが、アウトプットしないのもいろんなモノを溜め込んでしまうのでなんとも悶々としてしまいます。 さて、今回は概要シリーズからちょっとはずれてAuto Deployについて絞り込んで短めのエントリーを書きたいと思います。 Auto Deploy機能のベースはPXEブートによるイメージの展開なので、そこには特に新しさはありませんが、ポイントはイメージとホストのプロファイル情報の管理を統合したことによってディスクレスサーバに対するパッチやモジュールの展開や、設定情報の修正などの「運用フェーズにおけ

VMwareからvSphere5.0が発表になりました。2.xから3.xへのバージョンアップは比較的劇的でしたが、3.xから4.xへは比較的シームレスなバージョンアップとなり、今回も同様となりそうです。やはりソフトウェアはバージョン3.xぐらいから成熟するということなのでしょうか(^_^;)。各仕様についてまとめたホワイトペーパーが発表されましたので、そこから情報を掻い摘んで見ていきたいと思います。まずはストレージ関連から。ホワイトペーパーはこちら。 ■VMFS5 まずはVMFS5から。3.xから4.xでは継続してVMFS3を使用し、マイナーバージョンアップのみでしたが、今回はバージョンアップに合わせてVMFSもアップデートされました。vSphereに合わせて、VMFSも3.xから5.xへと4を飛ばしてバージョンが上げられています。 主な変更点としては、64TBまでサポートされた単一ボリュ

(1) - ゲストOSは自分が完全にCPUを管理していると思っている …の続きです。 OSにおけるCPUのスケジューリング機能は、複数のプロセスを「いかに効率的に」処理するかという目的のためにあります。OSの種類や目的によりスケジューリングアルゴリズムは異なり、OSによっては何種類かのスケジューリングアルゴリズムを搭載しています。 CPUのスケジューリングにおいて、すべての要件を満たす理想のアルゴリズムはありません。各要件は相反する条件を持っており、それら全てを満たすことはできないためです(一定の範囲で、制約付きながらなるべく満たすアルゴリズムの中から最適なものを選択することとなります)。 CPUスケジューリングに求められる要件としては、下記のようなものがあります。 リソースの割り当てが公平であること CPUリソースを最大限プロセスのために使うこと より沢山のプロセスを処理できること プロ

『VMware ESXにおけるメモリ管理』シリーズ (1) - 序：他のリソースとの違いはなに？ (2) - 仮想化インフラにおけるメモリ管理って？ (3) - メモリに関する仮想化支援機能(Intel EPT/VPID, AMD RVI/Tagged TLB) …の続きです。 物理マシンにOSが直接インストールされている場合、OSは全ての物理メモリを管理します。OSによってその管理方法は異なりますが、基本的には「割り当てた」メモリページを管理するか、「割り当てていない」(フリーの)メモリページを管理するかのいずれかの方法でメモリ管理を行います。いずれにしろ、OSはOS自身とOS上で実行される複数のアプリケーションのプロセスそれぞれに対してどの物理メモリページを割り当てているか把握していますし、プロセスは必要なメモリをOSに依頼して割り当ててもらい、そして「基本的には」不要となったメモリペ

CPUの性能がクロックの向上ではない指標で測られるようになってからすでに数年が経過しています。2004年にIntelがPentium4の4GHzのリリースを中止して以来、IntelのCPUはいまだに2GHz台〜3GHz台のクロック性能に留まっています。しかしその後現在に至るまでの間、CPU性能に進化がなかったのかといえばご存じの通りそんなことはありません。半導体の集積度が18-24ヶ月で倍増するというムーアの法則は未だにおおよそ維持されており、マルチコア化を筆頭に、NUMAやQPIといったメモリ関連の革新、CPUレベルでの仮想化支援機能の実装などなど、時代の流れに即してCPUは「単純にクロック性能だけを伸ばす」状況から、メモリやチップセットなどのハードウェア的な面と命令セットや制御アルゴリズムなどのソフトウェア的な面の両面で「総合的な性能を伸ばす」状況へと変化してきました。これらの結果、C

NIC Partitioning (NPAR)とは、その名の通りNICを論理的に分割して複数の論理ポートとして扱う技術です*1。このような技術は、HPがFlex-10 / Virtual Connectにて2008年末頃にすでに提供していましたが、実装方式は異なるものの、同じ様なことができる仕組みといえます。DELLはブレードサーバM710HDに10GbE Converged Network Daughter Card "Broadcom 57712-k"を搭載することによりNPARを実装しました。本エントリーのソース資料はこちらのSetup Guide (PDF)とWhite Paper (PDF)です。 Broadcom 57712-kによるNPARはOSに対して1つの物理デバイスを複数の論理デバイスとして「見せかける」技術ですので、NPARの構成はFirmwareレベルで行います*2

北京にあるMicrosoftリサーチアジアと精華大学が共同論文 "ServerSwitch: A Programmable and High Performance Platform for Data Center Networks"を公開しています。わずか15ページの論文ですが、なかなか面白い内容です。 ハードウェアベースのネットワーク制御アプローチにおいては、専用ASICによる高パフォーマンスが可能でしたが柔軟性が制限されることや、ASIC開発に多大なコストがかかるために製品が高価となるなどの課題がありました。対して、ソフトウェアベースのネットワーク制御アプローチにおいては、プログラマブルとなることやコストが抑えられることなどのメリットがありますが、ソフトウェア処理によるオーバーヘッドや遅延などのデメリットが大きな課題でした。 ServerSwitchはこの問題に対する解決策の1つとし

『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) (11) - 仮想TLB方式ってどういうこと？ …の続きです。メモリ圧縮(2)じゃないのはご愛敬！ 仮想マシン毎でメモリ圧縮がどれだけ使われるかは、ゲストOSのメモリ使用率に基づいて決定されます。ESXは圧

『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) - バルーニング …の続きです。 い、一ヶ月半ぶりでございます(^_^;)。まさか年をまたぐことになるとは思ってもいませんでした…。あと3回ぐらいで終わりにできるのではないかと思っているのですが…どうなることやら。 透過的ページ共有(TPS)やバルーニングでもメモリの確保が難しいとV