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

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 |

2016/01/27 (水)

[] vCenter Server Appliance 6.0 がディスクのエラー(Bad Block)で正常起動できなくなった際の対処メモ(当然ながら自己責任版)

※本エントリーを参考にして操作を実施した結果、問題が発生しても責任は負いません。自己責任で参考にしてください。本操作を実施することにより、VMwareからの正式なサポートを受けられなくなる可能性があります。

vCenter Server Appliance (VCSA) はファイルシステムとしてLVMで構成されているが、突然の電源断やディスク容量の枯渇などによってファイルシステムに破損などが生じた場合に、正常に起動できなくなることがあります。

その場合は、fsckをするしかないのですが、デフォルトではroot権限がDisableとなっていてbashが起動できないため、ちょっと対処が必要となります。

VCSAは複数の仮想ディスクで構成されています。特定のディスクがrwでマウントできないなどの状況となった場合には、roマウントした上で機能が制限されたコマンドプロンプト状態となります。

しかもこの場合にはrootアカウントでログインした上で、"shell.set --enabled True"コマンドでShellを有効化してShellコマンドでShellに入れとメッセージが出るのですが、そもそもshell.setコマンドが"unknown command"として受け入れてくれない場合があります。というか、これが使える状況なら以下の操作は不要です。

f:id:takaochan:20160126102155p:image

この場合はもはやどうにかしてbashにたどり着かないとfsckもなにもないので、以下の手順を行います。

1. Ctrl+Dコマンドで再起動し、GRUBブートローダ画面でスペースキーを押すなどして自動起動を停止する

2. "p"を押してrootのパスワードを入力する

f:id:takaochan:20160126102154p:image

3. "e"を押して起動オプションの編集モードに入る

4. (おそらく2行目にある) "kernel /vmlinuz-3.0.xxxx"で始まる行を選択し、"e"を押す

f:id:takaochan:20160126102153p:image

5. 起動オプションに"init=/bin/bash"を追記する

f:id:takaochan:20160126102152p:image

6. Enterキーを押してGRUBのメニュー画面に戻る

7. "b"を押して起動する

8. Bashで起動するので、まずはroでマウントしてしまっている/dev/sdaXについてfsckを実行する

以下の例では /dev/sda3 にBad Blockが検出されている

f:id:takaochan:20160126102151p:image

f:id:takaochan:20160126102150p:image

9. 再起動する(おそらくCtrl+Dでは正常に再起動できないので、仮想マシンとしてリセットするしかない)→ここで正常にVCSAが起動できた場合は以下の手順は不要。念のためもう一度F12&F11キーで正常操作としての再起動を行って問題ないことを確認する ※ここで再起動をしておかないと、PSCとの間で正常に連携できない状態となっている可能性があります

10. LVMの / (root)がマウントできない状態となっていて再度vCenterが起動しない場合は、改めてCtrl+Dで再起動した上で、1.〜7.までの手順を再度実施する

f:id:takaochan:20160126102156p:image

11. Bash画面で"chsh -s /bin/bash root"を実行し、Shellの変更が設定されたことを確認のうえでVCSAを再起動する(仮想マシンとしてのリセット)

f:id:takaochan:20160126102425p:image

12. rootパスワードを入力してログインすると、ファイルシステムのリカバリが可能なコマンドプロンプト状態(repair filesystem)#で起動するので、"fsck /dev/mapper/log_vg-log"コマンドでチェックを実施する

f:id:takaochan:20160127075828p:image

13. Ctrl+Dコマンドで再起動する

14. めでたく正常にVCSAが起動することを確認する

なお、本手順を踏んでVCSAとしては正常に起動したとしても、vCenterとしての正常動作ができるかどうかまではわかりません。DBレベルで修復不可能な状態になっていた場合は、残念ながらサービスとしては回復できない可能性があります。

また、PSCを分離している場合は、PSCの復旧後にしばらく(10分程度でいいかと思いますが…)時間をあけてからVCSAを起動してください。

2015/12/05 (土)

[] VIX APIってご存知ですか? - vExpert Advent Calendar

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に対して、ネットワークを通すことなく様々な制御をすることができます。いわば公式なバックドア(^_^;)として使用することができる…とまで言うといいすぎですが、まぁ悪いこともできなくはないですね。

Workstation環境だと、こんな感じの仕組みとなります。

f:id:takaochan:20151205172208p:image

この機能はデフォルトが有効です。無効にしたい場合は、vmxファイルに以下の指定します。ESXiホストの場合は、/etc/vmware/config で指定することによってホスト全体で無効化することも可能です。

guest.commands.enabled = "FALSE"

この情報に関するVMwareのKBはこちら。

http://kb.vmware.com/kb/1010103

その他、VIX APIはセキュリティリスクになり得ますので、気になるという方は以下の情報を一読されることをオススメします。

https://www.vmware.com/support/developer/vix-api/vix115_reference/security.html

上記公式サイトにサンプルのコードもあります。以下のリファレンスページに、設定方法や使い方なども載っています。CやPerlC#などに対応しています。

https://www.vmware.com/support/developer/vix-api/vix115_reference/

vSphere 5 からは以下のようにVIX APIはvSphere APIの一部となっています。そのため、vCenterサーバを通じてゲストOSに対して処理を投げることができるようになっています。

f:id:takaochan:20151205171959p:image

そんなわけで、ためしにLinux環境からvCenterを通じてESXiホストで実行される仮想マシン上で動作するゲストOSに対してVIX APIを通じてコマンドを実行してみるサンプルプログラムを作ってみました。

[root@localhost tmp]# ./vixtestcommand http://(vCenter IP Address)/sdk (vCenter Account) (vCenter Password) "[(Datastore)](VM Folder)/(VM Name).vmx" (Guest OS Account) (Guest OS Password) (Script)
DEBUG: Success jobHandle  34603071
DEBUG: Success hostHandle 34603070
DEBUG: Before Opening VM
DEBUG: Opening VM....
DEBUG: Opened the VM
DEBUG: waiting for tools
DEBUG: tools up
DEBUG: logged in to guest
DEBUG: about to execute remote command
DEBUG: about to execute remote command (Script)
DEBUG: with args
Script execution status is 0
Script command exitCode is 0
DEBUG: execution completed....

おー、ちゃんとvCenterを通じて、仮想マシンが実行されているホストに接続し、仮想マシンに接続し、VMware Toolsを通じてゲストOSに接続し、コマンド実行されました。こんな感じで、ゲストOSがネットワークにつながっていなくても、vCenterサーバの管理者アカウントとパスワード、そしてゲストOSのアカウントとパスワードさえわかっていれば、ゲストOSに対する処理を実行できます。管理環境からネットワーク的な接続性のないゲストOS環境に対して処理を実行することができますので、上手く使えば仮想マシン展開後の管理に便利に使えそうです。

ただ、ゴメンナサイ、このサンプルプログラムには一部オープンになっていないコードを含む可能性がある拾い物を8割ぐらい使ってささっと作ってしまったため、コードの公開は残念ながらできません…。ただ、上記のサンプルコードとリファレンスの情報があれば、同じようなプログラムを作ることはそんなに大変ではないのではないかと思います。

Happy Cording!!

え、プログラミングとか面倒?そんな方にはCisco UCS Director(^_^;)。VIX API機能を簡単に使えるワークフローを書くことができる機能が標準で実装されています。すぐにVIX APIを活用できますよ!!

f:id:takaochan:20151205173122p:image

http://www.cisco.com/c/dam/en/us/td/docs/unified_computing/ucs/ucs-director/vix-script/VIXScriptUseCaseGuide.pdf

Enjoy Happy Life!!

2015/12/04 (金)

[] ACI本刊行記念!! ACIとNSX - vExpert Advent Calendar

vExpert Advent Calendar 12/4 エントリーです

本日、皆さま待望の『Cisco ACI ポリシーベースのデータセンター アーキテクチャ/コンセプト/メソドロジー』がついに発売されました!!

よく知りませんが本書は何千部もは刷られていないと思うので、大きな書店かAmazonなどオンラインでぜひお買い求めください(帰りに忘年会行く前に本屋さんへGo!)。なかなか技術書が売れないご時勢ではありますが、ACI関連本もVMware関連本ぐらいは売れる様になるといいんですけどね。

なお、本書の著者の一人 Lucien Avramov は大の日本好きでこれまでも何度も日本に訪問しております。まだ未定ですが、年明け2/24の開催を予定している ACI友の会#3 にもしかしたら…。乞うご期待。なお、Twitterでもつぶやきましたが、何らかのかたちで私とつながっている方で、本書を買ったという方には、ご希望であれば英語版の本書を差し上げます(私の手元に在庫がある限り…)。ACIの理解を深めるついでに英語の勉強にいかがですか?(^_^;) 何らかの方法でご連絡ください。

…と宣伝っぽい内容はそれくらいにして…vExpert Advent Calendarでこのネタはどうなんだってご意見もおありでしょうが…どなたか譲るよ!って書いたのに誰も手を上げないんだから仕方がない!縛りなしってルールだし!そして別に何かをディスるつもりもないし(^_^;)!!

そんなわけで、本エントリーでは『Cisco ACI ポリシーベースのデータセンター アーキテクチャ/コンセプト/メソドロジー』日本語版の出版を記念して?、いいとか悪いとかではない視点のCisco ACI (Application Centric Infrastructure) /VMware NSX論を少し書いてみたいと思います。お約束としては、あくまでも個人の意見、個人の視点です。会社の人間として喋るときにはちょっと別の言い方をしているかもしれません(^_^;)。また、あまりテクニカルに深くは踏み込みません。

本書『Cisco ACI ポリシーベースのデータセンター アーキテクチャ/コンセプト/メソドロジー』の英語版はほぼ1年前に出版されたものですので、ACIの情報としては残念ながらすでに最新の内容ではありません。原著が出版された時点ではまだ対応していなかった機能や構成が可能になっている部分もすでに沢山あります。今月リリース予定の新バージョンでも、すでにこちらのオフィシャルブログなどでも触れられている通り、かなり楽しみな機能が数多く追加・拡張されていく予定です。ACIは新しい製品ですので、まだまだ積極的に様々な機能が追加・拡張されているフェーズにありますが、そうした新機能の学習という目的には本書はあまり適していないかもしれません。しかしタイトルの通り、本書は主にはアーキテクチャ、コンセプト、メソドロジーなどといった、バージョンがあがったり機能が拡張されていったとしても陳腐化することのないそもそもの部分、つまりはACIの根本的な思想・考え方といった内容に比較的比重が多く割かれていますので、ACIを表面的な部分だけでなくしっかりと「どういう考え方に基づいてACIはデザインされているのか」といった基礎的な部分から理解されたい方にとっては、今読んでも十分にお役に立てる内容が詰まっているのではないかと思っています。

さて、本エントリーではACIそのものについてはあまり書くつもりはありません。そのあたりはぜひ本書をお読みください(しつこい?といっても、本書が売れても別に私には1円も入ってきませんけど)。このエントリーで書きたいテーマは「手段としてのネットワークを活用するために」といったようなふわっとした感じの内容です。

OpenStackやDocker、そしてもちろんSDNなど、最近はコンピューティングの側面から見てもネットワーキングの側面から見てもITインフラストラクチャに求められることが大きく変化しつつあります。トレンドや技術動向をしっかりと把握しておくことは大切ですが、そうした情報に流されて「わが社もクラウドだ!」「SDNを導入しよう!」などとそれ自体を目的化させてしまわずに、ぜひ自社のIT基盤に求められているもの、ひいてはビジネスを支える要素として求められているものは何なのか、といった目的をしっかり踏まえたうえで、手段としてこれらの新しい流れを活用することができるのかどうか、冷静に検討頂ければと思います。

この流れを生み出したきっかけはやはりサーバ仮想化技術にあるでしょう。2000年代中ごろから現在にかけてのVMwareの飛躍はまさにそれを体現したものといえます。サーバ仮想化はITインフラリソースをソフトウェア的に構成することができる時代への入り口を開いたと言えます。その流れはインターネットの普及と高速化と相まってパブリッククラウドへとつながり、そして現在では雲の向こう側かこちら側かなどといった違いを超えて、どのような形態であろうとも、ITリソースは「必要なときに、必要な対象に対して、必要なリソースを、必要なだけ」提供することを可能とするサービス化された仕組みが求められるようになりつつあります。

サーバの役割を持つコンピュートリソースは物理サーバであろうと仮想マシンであろうと、そして最近ではコンテナであろうとその上で提供されるサービスという視点から見るとどのような形態で仕組みが作られていようと関係ないわけで、ITインフラリソースの要素の中で最も論理化が進みやすい要素でした。そしてまずは「それまで使われていた」タイプの企業が必要としているいわゆるクライアントサーバ型的なエンタープライズアプリケーションであっても問題なく使用できるサーバ仮想化が普及し、そして「これから使われていく」タイプのモジュール同士がAPIやQueueで結び付きながらブラウザやアプリを通じて柔軟にサービスを提供していく新しいカタチのアプリケーションが次第に広まっていく中で、Dockerのようなもはや仮想化ですらないアプリケーション実行環境そのものを展開する仕組みへと発展しつつあります。

このITリソースのサービス化の流れは当然ストレージやネットワークにも波及し、その流れの中でネットワークの範囲としてはCiscoのACIやVMwareのNSXが登場してきたと言えます。

そんなACIは確かにネットワークのソリューションではあるのですが、その根本的な製品思想はこれまでの企業ネットワーク製品とは大きく異なっています。そういう意味では、既存ネットワークの延長線上として「ソフトウェア的に論理的なネットワークを作ることによってネットワークの構成管理運用の柔軟さと展開の速さを高めよう」という、いわゆるSDNという括りにも収まるのだろうか?と思う部分も多くあります。まぁSDNという括り自体も人それぞれなので、括りに収まるもなにもないのかもしれませんが。

また、SDNをどう捉えるのか、という問題でもあるかと思うのですが、SDNをソフトウェア「だけ」で実現する新たなネットワークと考えるのだとしたら、物理的なハードウェアスイッチであるNexus 9000シリーズに依存したソリューションであるACIはそもそもSDNではないということになってしまいます。しかし、SDNをソフトウェア「によって」実現する新たなネットワークと考えるのであれば、ACIの論理的な側面は完全にAPIによって制御が可能なソフトウェアとしての側面を持ちます。ハードウェアによる処理性能・安定性と、ソフトウェアによる論理的なデザインと構成、その両面をACIは併せ持っています。

ACIは単に「これまでのネットワークの要素をソフトウェア化する」(=ネットワーク仮想化?)ものではありません。ネットワークリソースにサービス化が求められるなら、それはどうあるべきなのか?という根底から検討し、それを実現する手段として最適なかたちを目指して製品化されたソリューションです。そんなわけで、ACIに対しては、わかりづらい/よくわからない、既存のネットワーク管理のノウハウやナレッジが通用しないのではないか、アプリケーション視点のポリシー管理?これまでとまったく違う管理手法を取り入れるのには抵抗がある、など等のご意見が多数あることは事実かと思っていますし、そうであるからこそ、ACIのアーキテクチャ、コンセプト、メソドロジーといった部分をご理解いただくために本書のようなものが必要だと思っています。

会社としても、そして世の中としても、CiscoのACIとVMwareのNSXは競合であるとして色々なところで扱われています。確かに「新しいネットワークのカタチ」としてお客様がいわゆるSDNを検討された際に土俵に上げられるソリューション同士であるという意味では、競合といえる部分はあるかと思います。しかし、両者を見ているとおそらく次第にこの2つのソリューションは別のものであるという認識が少しずつ理解されていくのではないかとも思っています。

NSXの強みの1つは、やはりvSphere環境との高い密結合にあると思います。vSphere環境を前提としたNSX-vとNiciraの流れを持つNSX-MHがありますが、おそらく前者が次第に拡大していく方向で統合されていくことになるのではないかと思われます(中の人じゃないので知りませんけど)。NSXのコンポーネントには仮想アプライアンスとしていわば仮想マシンの一種として存在している要素(主にNorth-South方向の通信に関わる)と、ESXiのVMkernelの中に組み込まれる要素(主にEast-West方向の通信に関わる)の両方がありますが、NSXの肝はVMkernelに組み込まれて動作する分散仮想ルータや分散仮想ファイアウォールにあると思います。VMkernelに組み込まれるからこそ、vSphere環境の仮想マシンとの親和性が非常に高く、かつ他社にはまねできないソリューションを実現することができているわけです*1。NSXはサーバ仮想化のESX同様にハードウェアとしてのネットワークに依存しない(土管化?)仕組みを実現することを基本思想として持っているので、仮想アプライアンスとKernelモジュールでネットワーク機能を実現する仕組みはそれを体現する実装といえると思います。

f:id:takaochan:20151204134109p:image

逆にACIは、特定のホスト側の仕組みには依存しない、ということを設計思想に持つ疎結合型のソリューションです。特定のHypervisor、特定のOS、物理仮想の違いなどに依存せずに、あらゆるコンピューティングの形態に対して統一されたポリシーを提供することができます。しかし逆にハードウェアとしてのネットワークには強く依存する実装であるため、物理スイッチであるNexus 9000、そして物理アプライアンスとして提供されているAPIC (Application Policy Infrastructure Controller)と、ACIを使用するためには前提としてハードウェアが必要です。ACIを多くの基盤でご利用いただきたいと考えていますが、誰もが必要とするものでもないとも考えています。論理的なネットワークを動的に追加・構成・管理・変更していく、いわばネットワークに柔軟性を求める使い方をしたいという場合にはACIはとても有用ですが、静的に安定して個々のスイッチが自立分散して動作していてシンプルに広帯域・低遅延の拡張性のあるネットワークが欲しいという場合には、ACIではなく、いわゆるイーサネットファブリック的な使い方の方が向いているかもしれません。また、これまでどおりの、各ネットワーク機器を個別に構成し、標準化されたルーティングプロトコルなどによって情報交換は行っても各機器は自立して動作する使われ方は、SDNの登場によって使われなくなるということもないと思います。これらの向き不向きは業種や規模というよりも、ネットワークに求めている「使い方」次第といえるでしょう。

f:id:takaochan:20151204135639p:image

この先しばらくの間はSDNという括りでCiscoのACIとVMwareのNSXについては両者の比較やら競り合いやら色々な情報がニュース記事や両社からの発表などによって出てくることになると思います。しかし、5年後ぐらいにはきっと、ルータとスイッチほどとは行かないまでも、CiscoのスイッチでいえばNexusとCatalystぐらいのカタチで目的や使われ方が違うものとして認知されるようになっているのではないでしょうか。

明日のvExpert Advent Calendarもなぜか私なので、明日はまったく今日とは正反対の感じで短めのエントリーでVMwareがらみの小ねたを紹介したいと思います。

*1VMware以外のいわゆるサードパーティベンダーがVMkernelに組み込まれて動作するソフトウェアを実装することができないわけではありませんが、vSphereそのものの進化にきちんとアラインされたかたちで継続的にリリースしていくことはVMware以外にはかなりハードルが高いといえます

2015/06/23 (火)

[]ACIと仮想化環境との連携概要

連携、というタイトルで書き始めましたが、Cisco Application Centric Infrastructure (ACI)は、別に連携を構成しないとvSphere環境やHyper-V環境と組み合わせて使えないわけではありません。ACIは特定の物理的なサーバやHypervisorに依存していませんし、モジュール等をそれらの環境にインストールする必要もありませんので、特に連携を構成せずに使うことはもちろん可能です。この点は結構重要で、今後様々な新たな形態の要素がネットワークに接続してくることになったとしても(たとえばDockerのようなコンテナ単位であったり、様々なIoTデバイス類など)、いちいち連携実装を新たに用意せずともそれらを柔軟に受け入れることが可能であるということを意味します。

同時に、ACIはアプリケーション視点でのネットワーク管理を実現するために、ネットワークにおける「位置情報」となりうる要素についての依存性を極力排除できるように設計されています。残念ながらOSや様々なIP通信を行う端末側ではIPアドレスに紐付いてサブネットマスクやそれと紐付くVLANなどの概念が今現在はまだありますので、それらについて無視するわけにはいかないのですが、ACIにおいてはVLANが違っていても、逆にサブネットが同一であっても、それらが通信可否を決定する要素にはならない実装となっています。

その上で、なぜ連携する機能があるのかといえば、それは連携することによって管理がより便利になるから、です。たとえば、vSphere環境においてはポートグループが、Hyper-V環境においてはVMネットワークが、仮想マシンにおける仮想NICが接続する先となる論理的なネットワークを意味するわけですが、ポリシーに基づいてネットワークを制御するACIといえども、仮想マシンの接続点となるそれらの要素と、ACIにおける制御単位であるEPG (End Point Group) の間でのマッピングが必要となるわけで、ACIのコントローラであるAPIC (Application Policy Infrastructure)と各仮想化環境の管理サーバ(vCenter ServerもしくはSystem Center)と連携することによって、そのマッピングの構成を自動的に行うことが可能となります。逆に言えば、手動でそれらのマッピングを構成するのであれば、連携せずともACIとこれらのHypervisorを組み合わせて使用することが可能となるわけです。

さらには、仮想化環境との連携によって仮想化環境側で保持している識別子をACIで活用することも可能となります。ACIにおけるEPGの識別子はVLANや接続ポートなども使用できますが、たとえば仮想マシン名であったり、ゲストOS種類であったりといった要素に基づいて識別してもよいわけで、より柔軟に対象のEPGへのマッピングが可能となればより柔軟な管理が可能となるわけです。ACIでは、新たにそうした仮想マシン名などを識別子として使用することが可能となっています。

そんなわけで、Interopはお楽しみいただけましたでしょうか?

2015/06/01 (月)

[] TOYOTAのi-ROADに乗ってきた

TOYOTAのi-ROADってご存じですか?私はこのイベントの情報を得る前には知っていたような、知らなかったような…。

i-ROADについてはこちらのTOYOTAのウェブサイトに色々載っていますので詳しくはそちらで。

以下の動画を見て頂ければどんなクルマなのかは一目瞭然なのですが、クルマというかバイクというか…免許要件としてはクルマなのですが、前2輪後1輪の3輪車ですし、なんといっても曲がる際に傾くという車にはない感覚で乗ることができる新しいモビリティです。

D

傾くといっても、これまたバイクのように曲がる際に遠心力に対向するために内側に傾ける、という傾き方ではなく、あくまでもプログラミングによってアクチュエータが作り出す傾きなので倒れてしまうこともないようにソフトウェア制御されており、これまた独特な感じがします。

今回はWIREDがWXD(Wired x Design)プロジェクトの1つとして企画したこちらのイベントに当選したので、参加してきました。八王子にトヨタの東京デザイン研究所なんてものがあるということもまた知らなかったのですが…。

会場に着くとさっそくi-ROADがお出迎え。ホワイト・ピンク・ブルー・グリーン・イエローの5色が並んでいるとなんともカラフルな感じ。

f:id:takaochan:20150530173325j:image

個人的には、ホワイトかブルーが好みかなぁ。オレンジとかあったらいいと思うのだけれども。

f:id:takaochan:20150530141340j:image

i-ROADの仕様については、上記TOYOTAウェブサイトに載っています。リチウムイオンバッテリーによる電動カーで、航続距離は50km程度。

前半のトークセッションでは、このi-ROADを企画したトヨタの未来プロジェクト室の方と製品企画室の方(お名前や経歴などは上記WIREDのページ参照)から、コンセプトや開発段階の試行錯誤などの裏話等について紹介頂く。バイクを手掛けていないトヨタが作る傾く車ということで、色々あったんだなぁと思うとともに、なかなかこういった類の話は聞ける機会がないので興味深かった。そして参加者の側もほとんどが車を持っていなかったり、ペーパードライバーであったり、普段自転車です!みたいな人が多くてこれまた面白い。かく言う私もカーシェアリングなわけですが…。

そしてついに試乗会。運転免許必須ということで、どれだけ乗せてもらえるのか期待していたのだけれども、やっぱりというか敷地内で10分弱走らせてもらえる程度でした…。

f:id:takaochan:20150530141327j:image

車なので運転はハンドルで。当然オートマ。ギアもボタンでD/N/Rがあるだけ。

f:id:takaochan:20150530141410j:image

日本では法規制的に現時点では二人乗りはできないということで、一人乗り。一応運転席の後ろに席はあるので、法規制さえクリアーされれば、ちょっと大きくなった子供の送り迎えにはちょうどいいかも。

前輪は左右で別々のモーターによって回転が制御されており、この前輪が上下することで傾きを生み出したり凸凹道での段差による傾きを抑制したりする仕組み。

f:id:takaochan:20150530144437j:image

車としての完成度は高いんだけど、この面白みのないインテリアとパネルを含めちょっとまだ遊び心は足りないかなぁ…。このあたりはよくも悪くもTOYOTAな感じ。

f:id:takaochan:20150530144127j:image

i-ROADがずらっと並んでいるとちょっとカワイイ感じ。でも街中だとまた違う感じになるのかな。このプロジェクトに関わっているTOYOTAの社員の方は通勤に使ってみたりしているそうですし、今後モニターも数を増やして行われるということなので、もしかすると街中で見かける機会も今後少しだけ増えるのかも。

f:id:takaochan:20150530143105j:image

運転する感覚としては、ハンドルを切ると曲がるのは後輪なので、傾く前輪の動きと合わせてなかなか独特。八の字や旋回走行では、まったくこれまでの車の運転感覚とは違うのだけれども、これはこれですぐ慣れそうだし、運転というより操縦している感覚で走ることができるところは新しい感覚かもしれない。

さて、このi-ROADは都市のモビリティを想定して開発が進められているようですが、果たしてどんな人達が単に「これ面白いね」のフェーズを超えて、実際に購入したり、乗ったりするようになるんでしょうね。そしていくら位だったら買ってもらえるんでしょうね。けっこう中の人達も色々と悩まれている様でしたが。

TOYOTAのOpen Road Projectでモニターを募集されていますので、気になる方は申し込んでみてもいいかもしれません。

私?どうしましょうかねぇ。

f:id:takaochan:20150530141930j:image

2015/05/25 (月)

[] ACI Toolkit (2)

昨年12月に簡単に紹介したCisco Application Centric Infrastructure (ACI)のオープンソースツールである ACI Toolkitだが、リリースから半年が経過してACIの進化と合わせて色々と機能やサンプルアプリケーションも充実してきている。

ACI ToolkitはGitHubで公開されているので、Apache License 2.0の下で誰でもお使いいただける。

GitHub - datacenter/acitoolkit: A basic toolkit for accessing the Cisco APIC

特にサンプルアプリケーションはどれもWeb GUIでACIの情報を参照できたり、ちょっと役立つ管理機能が提供されていたりしてどれもいい感じ。

ちなみに、今日現在で含まれているサンプルアプリケーションは以下の通り。

たとえば、ACI Endpoint Trackerアプリケーションは、APIC経由でACI環境に存在するEndpointの情報を取得してDBに格納してくれる。Endpointが属しているテナント、アプリケーション、EPGの情報や、EndpointのMACアドレスおよびIPアドレス、ACIへの接続パスとなっているLeafのインターフェイス情報などをSQLやWeb GUI経由で取得することができる。

f:id:takaochan:20150520174418p:image

また、Vizualization Examplesは取得した情報を視覚化するサンプルとなっており、様々なダイアグラムやチャートなどをFlaskを使って生成してみることができるPythonスクリプトが用意されている。

f:id:takaochan:20150521132601p:image

…等々、様々なサンプルが提供されている。ある程度の実用性はあるサンプルアプリケーションとなっていて、ACIの構成チェックを行うACI Lintや、構成情報の変化をSnapshotのように取得し続けたりロールバックもできるアプリケーションもあったりなど、バラエティも豊かだ。

もちろん、これらはあくまでもサンプルなので、参考頂いてACIのAPIを活用したツールを色々と作ってみると面白いかもしれない。

2015/04/13 (月)

[]OpenStackとACI

すっかりとプレゼン資料紹介ブログになってしまっていますが…(^_^;)

OpenStackとACIの連携を紹介するセッションを担当しましたので、スライドを公開します。ACIは二面性を持っており、下回りはEthernetファブリック技術とオーバーレイ技術を融合したVXLANオーバーレイファブリックとしての側面を持っていますが、上回りはすべてを論理的にデザインすることができるPolicyデザインとそのすべてをAPIで制御することを可能とするインターフェイスとなっています。OpenStack連携においてもこの下回りを意識する必要のない上回り側の管理性を活かす仕組みが実現されつつあります。

本スライドでご紹介しているGroup-based Policy (GBP)はすでにJunoリリース(2014.2)のOpenStackと組み合わせてお試しいただけますので、ぜひ試してみてください。まだ色々と足りない部分もあることは事実ですが、ACIとOpenStackを連携して使用することによるメリットを本資料で少しでも知っていただけると幸いです。

どんな仮想マシンでも、物理サーバでも、コンテナであっても、どのような技術が今後登場しようとも柔軟に連携できるACIの面白さが伝わるといいなぁ。