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

CiscoはVMwareと仲良しなのでლ(´ڡ`ლ)、ACIだけでなくUCSのvCenter Pluginもきっちり提供されている。それがこのUCS Manager Plug-in for VMware vSphere Web Client。もちろんこちらも追加コストなどなく利用頂くことが可能。…とはいえ、ここではこのプラグインの全体像の説明とかはしない。1点だけ、自分が気に入ったVIF Path情報をPluginの画面で確認できるところについてだけ。なお、用語重なりが混乱の元凶なのだが、このエントリー内で書くvNICは仮想マシンにとってのネットワークアダプタを意味するvNICではなく、UCSにインストールしたOS/Hypervisorにとってのネットワークアダプタを意味する。イメージ的には世間一般には物理NIC。でもUCSではVICによって論理的に構成された仮想NICなのでvNIC。あー

再開第2週目…。はてさていつまで続けられるか…(^_^;)。 Ciscoが2008年にNexusシリーズを発表し、LAN/SAN統合スイッチであるNexus7000シリーズとNexus5000シリーズを提供し始めたとき、Nexus7000/5000と合わせて使用することができるNexus2000シリーズというFabric Extender (FEX)が何のために存在しているのか、私にはいまいちよくわかりませんでした。FEX�とはいわばNexus7000/5000に対するリモートラインカード的なデバイスです。 最初は、Nexus7000/5000はハイスペックな分お値段もそれなりに張るし、まだまだ1Gbps接続で十分なサーバなども(その時点では)多数あるのでそれらをまとめて収容することができるようにするモジュールという様な位置づけかな、と思いました。しかし、単に1GbpsのEthernet接

技術的に詳細な紹介は本家におまかせし、こちらでは今後も「そもそも」的な部分を小粒に書いていきたいと思います。別にOfficialなBlogでも仕事でもないですし！ Ciscoのサーバ製品 "Cisco UCS" には、ブレードサーバのBシリーズとラックマウントサーバのCシリーズがあります*1。 以前、サーバ仮想化によってインフラは群体として扱われるモノとなっていく、と書きましたが、まさにこの言葉はUnifiedという言葉で、流行というか流れになってきていると思います。…そして、製品として冠にそのUnifiedという単語を含むUCSをUnifiedたらしめている存在が、UCS Managerです。 UCS ManagerはブレードサーバのBシリーズでは必須、ラックマウントサーバのCシリーズでは必須ではありませんが、あるとないとではだいぶ管理性が違ってきます。 ところで二つの側面があるので最初

※本エントリーを参考にして操作を実施した結果、問題が発生しても責任は負いません。自己責任で参考にしてください。本操作を実施することにより、VMwareからの正式なサポートを受けられなくなる可能性があります。 vCenter Server Appliance (VCSA) はファイルシステムとしてLVMで構成されているが、突然の電源断やディスク容量の枯渇などによってファイルシステムに破損などが生じた場合に、正常に起動できなくなることがあります。 その場合は、fsckをするしかないのですが、デフォルトではroot権限がDisableとなっていてbashが起動できないため、ちょっと対処が必要となります。 VCSAは複数の仮想ディスクで構成されています。特定のディスクがrwでマウントできないなどの状況となった場合には、roマウントした上で機能が制限されたコマンドプロンプト状態となります。 しかもこ

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

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を使ってア

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

仮想化環境のようなインフラ環境を構築する場合、同一モデル・同一構成のサーバを多数並べて使用する場合が多くあります。たとえばVMware vSphereを用いて仮想インフラ環境を構築する場合には、ESXiホストが仮想マシンの実行環境となりますが、基本的にはCPUモデルや搭載メモリ量、ネットワーク構成などが同一である方が様々な面で使い勝手がよいですし、多くの機能が「ESXiホスト間で構成に整合性があること」を前提としています。 単にESXiのHypervisorとしての構成における整合性だけであれば、vCenter Serverによって一元管理され、たとえばHost Profileなどの機能によって構成に差異がないことを確認することができます。しかし、最近のx86/64サーバでは多くの機能がハードウェアオフロードされたりハードウェア仕様に依存するようになってきており、特にCPU仮想化支援機能と

2/27の「TRILLはEthernetになにをもたらすのか」エントリーの続き、みたいな感じです。 Brocade VDX 6720の全体的な解説としては、@ITの記事をご参照下さい。このエントリーではあえてTRILLを中心とした部分にフォーカスするために全体的な説明はしておりませんので、先にこちらの記事を読んで頂いた方がよいかもしれません。 また、より深く知りたい方は、こちらのThinkITの記事がオススメです。 ■TRILLにおけるストレージネットワーク技術の活用 標準技術としてのTRILLはL2ルーティングプロトコルとしてIS-ISを用いることで策定が進められていますが、現在 仕様の確定に先行してリリースされているBrocade VDXではBrocadeが開発したルーティング技術であるFSPF (Fabric Shortest Path First)が使われています*1。FSPFはB

『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は圧

一通り環境チェックをしてくれるので便利でいいんだけれども、vMotionネットワークをvMotion専用のTCP/IPスタックで構成していると失敗ステータスになるのが微妙。ま、そのうち治るんだろうけれども。これはリリースノートにも明記されているので、既知の問…

さて、わかりづらい？Hyper-Vのネットワーク第2弾。今回はチーミングまわりについて…なんて少し思っていたのですが、タイミング良く素晴らしい記事をHP小川さんが@ITで公開されましたので、そちらを参照頂ければもう書くことないです^_^; …ということで、今回のエントリーではHyper-Vにおける仮想スイッチまわりにフォーカスを当ててみます。 前回書いた通り、Hyper-Vの仮想スイッチはネットワークアダプタ―における機能として実装されています。実装というよりも概念的な構成図を描いてみました。この図は物理・論理・仮想のネットワークアダプタ―を中心に書いてあります。実際には、Hyper-VのParent Partitionは仮想スイッチの役割を果たすネットワークアダプタ―を共有しなくてもよいので、必ずしもこのような構成にはなりませんし、またチーミング機能と仮想スイッチ機能は別ですので、このよ

たまにはVMware関連の情報も提供しないとね(^_^;)、ということで、今回はvCenterとCiscoのサーバであるUCSを連携するプラグインのご紹介をば…。 Cisco UCS vCenter Pluginは、まぁその名の通り、vSphere環境に対するUCSのプラグインであり、インターフェイス部分についてはvSphere Web Clientに対する拡張として動作します。本エントリー公開日現在はベータ版のステータスですが、CiscoのDeveloper Networkから無償でダウンロードして使用頂くことができます。 裏側のアーキテクチャとしては、以下の2つのコンポーネントから構成されています。 vSphere Web ClientへUCSに関する情報を提供するUI側のモジュールと UCS ManagerからXML APIを使ってUCSの情報を取得するJava SDKを用いたプラグ

vExpert Advent Calendarも2週目に突入。ちっともやり遂げられるかどうか、ネタが続くのかどうか、どちらも自信がありません！(^_^;) さーて、そんな先の不安なひとまず置いておいて、今週もいってみましょう！ そもそも、自律分散というネットワークの仕組みはよくできている SDNやらOpenFlowやらが流行って？きて、なんだか『旧来のネットワークはもはや古くて、SDNこそが新しいネットワークだ』的な風潮がちょっとあるような気もするのですが、実際のところは今までのネットワークのままで特に困っていない場合も多いのではないでしょうか。各ネットワークデバイスが他に依存することなく「それぞれが自律的に動作」しつつも「標準化プロトコル仕様に基づいて情報交換をする」ことなどによって非常に小規模なものからインターネットのような世界規模のものまでもの「面としてのネットワーク通信を成立させて

VMwareは1つの技術を色々な用途に応用して使うことが得意です。たとえば、VMotionの技術はDRSにおける仮想マシン配置の自動化のために使われていますし、VMware Converterは単なるP2Vツールではなく、VCBによってエクスポートされた仮想マシン構成ファイルのインポートツールとしても使うことができるように作られています。その他、詳細には様々な技術をけっこう上手く使い回しています。 そんな、VMwareが最近、様々な新機能のベース技術として活用しているものが、CBT (Change Block Tracking)という機能です。 CBTはその名の通りで、仮想マシンが使用している仮想ディスクファイルに対しての更新ブロック情報を仮想化レイヤー側(仮想マシン上のゲストOSは関知しない形で)で抽出する機能です。 この技術はESX4.0以降においてVersion7の仮想マシンハードウ

GoogleやらAmazonやらの面白いところは、自社のサービスを支える基盤を作り上げていった結果として、それが他に類を見ない、独自性を持ったITインフラリソースを抱えるに至っているところ。ポイントはそのリソースが「自分」のために作り上げたものであり、今後も「自分」こそが最大のユーザであり、サービスを提供するためにそのリソースを「自分」で作り上げ・維持していくことに拘りを持っているということだ。GoogleやAmazonのサービスが安定的にかつ非常に大規模な処理を捌き続けていること自体がそのインフラの信頼性を実証していることになる。多くの企業がAmazon Web Services(AWS)を活用しているし、自社システムをGoogle Appsに移行してしまう会社もかなり大きな会社を含めてだいぶ出てきている。クラウドとは何か？SaaS？HaaS？IaaS？PaaS？などと思っているうちに、

『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 設定編 +α …の続きです。 戻って参りました、ESX(^_^;)。では、さっそく。今回のお題はバルーニングです。 バルーニングは(5)で取り上げた透過的ページ共有とは全く異なるメモリ管理手法です。透過的ページ共有はゲストOSに対しては透過的に(つまりは仮想マシン上のゲストOS側からは意識されないかたちで

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)で