2008年4月アーカイブ

前回DRモードとSRモードの比較を行いましたが、XSRモードにて同一のシーンを見た場合の検証を行ってみます。というわけでXSRモードの静止画も追加しました。

静止画としてみた場合はSRモードとあまり大差ないように見えますが、動画の場合はあまり破綻はありません。XSRとSRだとファイルサイズが約25%増しになるのですが、H.246で圧縮するのは録画時の一回限りなので、なるべくなら高画質で保存しておきたい場合はXSRモードの方が良いと思います。

ちなみにうちの神様はアッガイたんです(本当)。
今日は散歩がてら家族で西武新宿戦線上井草駅前に行ってきました。お目当てはこれ。

お賽銭箱もありました。

上井草駅前には(商売敵の)ガンダムが銅像として奉られているのです。
この写真を撮ったときにも他の観光客の方々が写真を撮っておられました。
で、コラボ(笑）

娘も銅像前で敬礼！

最近は統合管理ツールなるものが普及しつつあるので、システム管理者はだいぶ楽になりました。しかしながら、相手がネットワーク機器となると統合監視ツールでは手に余ることもあるかと思います。

私はいまの会社に入るまでシステム管理ツールを使ったことが無く、手作業だったり目視だったりで監視を行っていたのですが、はっきり言って無駄な作業だと感じていました。現在ではTivoliも使用しますし、独自のVBSスクリプトでサーバーの監視も行いますが、それでも面倒だという方(特にネットワーク機器を対象とした場合)はOpManagerというツールをおすすめします。現状では日本語版はVer 7で、30日間のお試し期間か、管理台数限定のフリー版が使用できます。

特筆すべきはWMIによるWindowsの監視とSNMPによるトラップ受信です。
(SNMPの有用性についてはこちらのサイトが参考になるでしょう)
WMIの方はそれほど難しくないのと、プリセットされている監視パターンが多いのであまりカスタマイズすることは無いのですが、SNMPの方も割合強力です。

私はOpManagerを使用するまでSNMPというのがさっぱりわからなかったのですが、使っているうちにトラップやOIDについても理解することが出来ました。SNMPに関する解説本も読んでいません。

私はネットワーク機器についてはすべてSNMPで監視しています。これまでNagios等のフリーの監視ツールの検討も行いましたが、自宅で勉強したり、小規模なネットワーク管理であれば、OpManagerのフリー版を使用するのも悪くないと思います。

ちなみにOpManagerについては出入りしているSIベンダーさんにも強くプッシュしていて、デモもよくやっています。個人的にはユーザー会を立ち上げたいぐらいなんですよ。

こちらで書いたUSBデバイスの認識についてですが、スキャナやプリンタの他にグラフィック系アプリケーションソフトで良く使用されryUSBドングルを使用可能であることを確認しました。

あくまで自己責任での話ですが、こちらで確認した例ではAutocadのMayaは大丈夫でした。これが使えるようになると、USBドングルを管理するサーバーも仮想化できることになります。

このようなサーバーはクライアント側がアプリケーションを起動する際に参照するだけですが、物理サーバーにて稼働させているとハードウェア障害があった際にアプリケーションが起動できないという状況になるので、仮想化してVirtual Centerで管理しておく方が便利です。
(特にMayaを使うようなユーザーは夜間作業が多いので)

エヴァンゲリオン劇場版のDVDが届いていたので早速BDZ-X90とVP12-S1で視聴。これはブルーレイで見たかったかも。
一応アニメーション会社に身を置いているので、アニメ製作技術の方に目が行ってしまいがちなのですが、シナリオ再構築、作画、CGI、演出すべて及第点以上でした。続編に大いに期待しております。
但し、初号機の搭乗時にはやっぱりアルプスの少女ハイジのパロディネタで笑ってしまうのです(笑)

なんだかVMware関連のキーワードでの検索をされて、当サイトにたどり着く方が多いようなので、VMネタでもう一つ。
私の専門は実はネットワークも含めたインフラ全般で、VMwareに特化した技術者ではないです。そこで今回はネットワーク技術者としての視点からVMware導入時における注意点と欠いておきたいと思います。

VMware ESXサーバーのサイジングの際の注意点はこれまでにいくつか書いてきましたが、VMware ESXサーバーを載せる物理的なサーバーを選定する際にはメモリ、CPUをなるべくたくさん載せる以外にもう一つあります。

それはできるだけNIC(Network Interface Card)をたくさん載せておくことです。前回の記事でブレードがVMware ESXにあまり向いていないのでは？という疑問を書きましたが、NICの搭載量が限られるという点にも起因しています。

では、なぜNICがたくさんあると良いのでしょうか？
下記の図は、とあるESXサーバーのNetwork AdapterのConfiguration画面ですが、複数の仮想OSに対して複数のNICが割り当てられています。この例だと、vmnic0、1、3はTeamingとして機能しており、仮にvmnic1が何らかの原因で使用不可になったとしても、0と3が生きているので、システムには全く影響を与えません。(Teamingにより帯域の上限があがるわけではなく、あくまでフェイルオーバーとしてです)

仮想化対象のシステムが複数のNICを持っていたり、複数のネットワークセグメントに存在しているシステムを仮想化する際には、VMware ESXサーバーのVirtual VLAN Switch機能が役に立ちます。私の管理している環境では、ネットワークセグメントは少なくとも40以上あり、それぞれのセグメントに何らかのシステムがあるため、仮想化の際にはNICが複数必要となります。

この点でもラックマウント型のサーバーの方が、NIC増設という点で有利です。但し、PCIカードに1ポートのNICをそれぞれ用意すると、最大搭載NICポートが減ってしまいます。これは一長一短で、カードの故障率を取るか、ポートの故障率を取るかでしょう。これについては最適解が無いので、ESXを構築する際には十分に考慮する必要があると思います。

それと、せっかくNICを多重化したのですから、スイッチも多重化しておきましょう。上記図の例では、vmnic0とvmnic1は別々のスイッチにつなぐべきです。VMwareは非常に便利なツールではありますが、システム障害時のダメージも大きいので、外部要因についても多重化すべきです。

さて、仮想化の話題からBDZ-X90の話題へ移ります。 私は仕事でMPEGの技術的な部分にふれる機会が多いのですが、BDZ-X90の圧縮モードは動画としては良くできていると思います。ところが最近のアニメーションはデジタル化の恩恵を受けて使用している色数が非常に多くなってきており、極彩色のような絵作りも多いです。そこで今回はSRモードとDRモードの比較を行ってみたいと思います。 これはマクロスフロンティアのOP画像の1シーンを一時停止してデジカメで撮影したものです。 上がSRモードでの録画、下がDRモードの動画になります。 一時停止しているタイミングで見え方が異なるのですが、文字テロップの部分でにじみが出ているのがわかるかと思います。実際には動画ですのでこういったにじみは気にならないレベルにはなるのですが、画面が大きければ大きいほど(さらに言えばフルHD環境であれば)気になるレベルになると思います。来週はXSRモードでの比較も行ってみたいと思います。

私の管理してるVMware ESXサーバーは現在3台あります。もうすぐ5台になりますけど。
使っているサーバーはIBMのsystemx 3650というミッドレンジの2CPUのサーバーです。クアッドコアXeonなので1台当たり8コアあるわけです。運用し始めて気がついたのは、CPUリソースよりもメモリリソースの方が消費するという点でした。サーバーの役割にも因りますが、例えばファイルサーバーでは2CPU分、メモリを2GB割り当てているわけですが、メモリはUnlimited設定といって、ハードウェアに余裕がある限り無制限にメモリを使っていいという設定にしています。

この仕組みにより優先順位の高い他のサーバーがメモリをあまり使用していないときに限り、潤沢にメモリを使えるわけです。しかしながらこのような設定のサーバーが多数あった場合にはすぐメモリをフルに使ってしまいます。ところがメモリの使用量を制限するとパフォーマンスが悪くなることがあったため、仮想サーバーのメモリはなるべくUnlimitedにしておきたいわけです。

現在はサーバーのメモリも安くなってきたので、VMware導入時にはサーバーのCPUもメモリもフルに積んでおくのが理想です。最初にどの程度投資できるかで仮想化の成否が決まると主追います。

ところで最近流行のブレードサーバーはCPUとメモリの搭載量がラックマウントサーバーよりも少ないので、個人的にはVMwareには向かないと確信しています。(もちろん用途にも因りますが・・・)。また、ブレードサーバーはディスクI/OもネットワークI/Oもブレードが増えれば増えるほど共有化が進むので、ボトルネックになることが多いのです。

私の経験だと、クアッドコアCPUが2個、メモリが16GBのラックマウントサーバーで10個の仮想OSが快適に動作しました。今後はメモリを32GBにアップグレードする計画があり、その結果はこちらでもレポートしたいと思います。

当ブログに「VMware ESX 弱点」というキーワードで検索された方がいらっしゃったので、BDZ-X90の話題から一転してVMwareについて書きたいと思います。

VMware ESXを用いたサーバー仮想化(クライアント用OSでも良いのですが)で何でもかんでもシステムの仮想化ができるわけではありません。特にOracle Application Cluster(RAC)を使用したシステムは仮想化できないと思います。
それはRACはデータベースに対する負荷を複数のサーバーで分散処理しようという考え方なのですが、仮想化の場合の1台の物理的なハードウェアのリソースをみんなで分散しようという考えとは相反するからです。1台の物理サーバーに複数のデータベースサーバーを仮想化することができるなら、分散せずに1台にまとめてしまった方が仮想ハードウェアのボトルネックが無くなる分、処理が早くなるからです(もちろんネットワークI/OやディスクI/O等の理由により仮想化した方が良いこともありますが)。

仮想化はCPUやメモリが常に100%近く消費されるシステムに対する解決策ではなく、空いているCPUやメモリをいかに効率よく使用するかという点を念頭に置くべきです。

もう一つの例としてはレンダリングファームと呼ばれるシステムにも仮想化は向いていません。
レンダリングファームというのは計算によってCGの表面処理やCGアニメーションの動きを作るための専門のPC(ワークステーション、以下レンダーと呼びます)の集合体です。通常は数台～数十台の同じレンダーで構成され、とにかく計算ばっかりするPCとなります。そのためCPUは高速なものが求められますし、メモリもある程度必要ですが、ディスクはそれほど必要ではありません。

レンダーは計算していない(ジョブがない状態)ならほとんどCPUが稼働していませんから、稼働しているレンダーと組み合わせることで数台のレンダーを一つの物理的なハードウェアに納めることができそうですが、実際にテストしたところでは仮想化しない場合よりパフォーマンスが大幅にダウンしてしまいました。これはレンダーが動くときは複数のレンダリング処理が複数のレンダーで一斉に走るため、仮想化したレンダーすべてが一斉にCPU使用率100%になってしまうからです。これはVMWareのコンセプト(空きリソースを複数の仮想OS でシェアする)とは外れた運用であるため、パフォーマンスダウンは妥当な結果です。

このように、CPUリソースを100%長時間使用するようなシステムは仮想化には向いていません。但しデータベースシステムでもクラスタを組んでいない単一のデータベースシステムや、CPUが100%になる時間があっても2～3秒以内で収まり、それが断続的に続くようなシステムは非常に向いていると云えます。私が持っている事例では、SQL Serverが載っているサーバーや、DHCP、Active Directory、DNS、プリンタサーバー、Webサーバー、ファイルサーバー等を仮想化しており、TCOの削減に大きく貢献しました。

仮想化を成功させるポイントをもう一つ挙げるとするなら、仮想化する対象のOSに対して一つのサービス(またはアプリケーション)のみを動かすことです。例えば、DNSサーバーとファイルサーバーを一つの仮想OSに入れないということです。それぞれのサービスはCPUやメモリ、ネットワークI/Oの消費度合いが異なり、一緒にすることで常に数十％のCPUリソースを消費するからです。その分OSのライセンス料はかかりますが、それぞれのシステムの安定性も抜群に良くなるので是非お試しを。

2回目のレビューはBDZ-X90の売りの一つであるデジタル放送に対する圧縮です。
BDZ-X90はH.246という圧縮用エンコーダを一つ持っています。地上デジタルあるいはBSデジタル放送の録画というのは、従来であれば放送波で送られてくるMPEG2の信号(トランスポートストリームといいます)をそのまま記録する方式がこれまでとられていました。これは放送された時間軸のMPEG信号を丸々保存するということなので、14～24M/bpsのビットレートで送られてきた動画をそのまま録画することができます。そのため、放送された画質がそのまま再現できます。
しかしながら、この方式だと1時間番組で約17GB(地上デジタル放送の場合)のディスクを消費してしまい、ハードディスクがいくらあっても足りなくなります。

そこで考え出されたのが、画質をあまり落とさずにH.246というエンコーダで放送波を圧縮しながら録画してしまおうという方式です。BDZ-X90にはH.246エンコーダが一つしかないので、圧縮しながら録画できるのは同時に1つの番組だけですが、ハードディスクをあまり消費せず、どこまで視聴に耐えうる画質となるのか検証してみました。

BDZ-X90は７つの録画モードを持っています。

• DR(トランスポートストリーム)
• XR(AVC 15M)
• XSR(AVC 12M)
• SR(AVC 8M)(標準)
• LSR(AVC 6M)
• LR(AVC 4M)
• ER(AVC 2M)

DRはトランスポートストリームなので関係ありませんが、圧縮モードはビットレート固定で、RD-X5のような録画する際のビットレートを細かく指定することはできません。そのため、録画する番組によって最適な圧縮モードを決めておく必要があります。

今回はVP-12S1と100インチのスクリーンにて実際に確認してみました。ちなみにVP-12S1は1280×720のワイドパネルを持っていますが、フルハイビジョン対応ではありません。BDZ-X90からコンポーネント出力を接続しています。

VMwareで作成したPCは物理的なUSBポートがないので、ネットワーク経由でUSBデバイスを使用できる機器が必要です。(ここではSilexのSX-2000U2を使用します)

XPをインストールした際にはUSBドライバがインストールされていないので、XPのCD-ROMからUSBドライバをコピーする必要があります。

USBの信号をネットワーク経由で仮想化するためにAnywhere USBというドライバが必要になります。

【インストール方法】

1.SX-2000U2を設定し、VMware上のXPにSX Virtual Linkをインストールしておく
2.XPのCD-ROMのi386フォルダにあるUSBD.SY_をコピーしてVMware上のXPのc:\winnt\system32\driversへコピーする。コピーしたらファイル名をusbd.sysに書き換える。
3. VMware上のXPを再起動する。
4. Anywhere USBをインストールする。ドライバは紹介できませんので各自探してください。(配布されています)
5. SX Virtual LinkにてSX-2000U2のIPアドレスを設定し接続できるかどうか確認する。

この方法はWindows 2000/XP/2003ならOKだと思います。スキャナなどのUSB機器をVMware Infrastructure 3上の仮想マシンで使用したい方は是非どうぞ。

さて、BDZ-X90について何から書こうかと思いましたが、手元にある東芝RD-X5との比較をするのが一番簡単かと思いましたので、GUIから紹介していきたいと思います。

まず東芝とソニーの文化の違い(というよりレコーダにおける目的の違い)というのが如実に表れているのがGUIです。
東芝は録画・保存・編集に重点を置いているのに対し、ソニーは「とにかく」録画・視聴・他メディア(ここではBD-R/RE)への放出もしくは削除という点に重点を置いているように思えます。なので、東芝は録画した素材を見つけ出すのも簡単に行えますが、ソニーは見たら消す(あるいはムーブ)のであまり素材をため込むというのには向いていないという気がします。

さて、RD-X5がWindowsライクなフォルダ構成を取っているのに対し、BDZ-X90はXMB(クロスメディアバー)というPSXから採用された(であろう)インターフェースを採用しています。

RD-X5のフォルダ構成はフォルダ対し自由に名前を付けることができ、なおかつ録画した素材の移動もかんたんに出来ます。BDZ-X90では素材は基本的に録画した順番に表示されるだけで、ユーザーが表示方法や分類をカスタマイズすることはほとんど出来ません。(但しオプションの表示方法でタイトルやジャンルによる分類・表示は可能)

RD-X5はフォルダによる表示とは別にライブラリ機能を持っていて、こちらでは録画した素材を時系列に表示することが可能です。

結論として、使ってみた感想ではX5の方が慣れている分だけ直感的に操作できます。逆にBDZ-X90は後に解説するお任せ録画機能による「どんな番組録ったっけ？」という楽しみがあると思います。一つだけBDZ-X90の弱点を挙げれば、RD-X5ではPCとの連携によりライブラリデータの取得や番組タイトル、フォルダの名前の変更がPCのキーボードから容易に出来るのに対し、BDZ-X90では全く出来ないという点です。これについては機能のアップデートで何とかしてもらいたいものです。

次回はRD-X5との決定的な違いであるデジタル放送の録画機能について書きたいと思います。

東芝のHD DVDが撤退したため、やむなくブルーレイレコーダーを購入しました。
型番はSonyのBDZ-X90です。これまで使っていた東芝のRD-X5が地上デジタル放送やBSデジタルに対応しておらず、デジタル放送に目が慣れてしまうとアナログに戻れないというジレンマもあり、早期導入したわけです。

というわけでこれから数回にわけてレポートをしていきます。

システム管理で一番難しいところは、いくらシステム障害を検知したり予測したりしても想定外のことは起こることです。

先日のことですが、私の管理しているサーバーで時刻同期が原因の障害が発生しました。というわけで今回の障害はntpに関係する話です。
サーバーやネットワークに携わる方ならば、ntpについてはよくご存じのはずです。ntpはNetwork Time Protocolの略で、ネットワーク上にあるマスターとなる時計にみんな合わせましょ～という仕組みです。ntpを使うにはいくつか準備がありますが、良く引っかかるのがネットワークポートをあけていないことです。ファイヤーウォールなどで使わないポートは塞ぐようにしがちでntpもふさがれてしまうことが多いのですが、この辺もふまえてネットワークを設計しましょう。余談ですがsnmpも忘れずに。 ntpサービスのインストールの方法はいろいろなところにありますし、OSによっても異なるのでここでは割愛します。

さて、ntpの弱点は大幅に時間が狂っていると自動的に同期されないという点です。
今回の障害はまさにそれが原因で、サーバーのマザーボードを交換したところ、BIOSで保持している時間とOSの時間が異なってしまい、マザー交換をしたサーバーの方が5分以上他のサーバーと時間がずれておりました。社内システムはkerberos認証を行っているところが多いので、5分以上時間がずれていれば役には立ちません。そのためユーザー認証ができず、各サーバーのサービスやアプリケーションは問題なく動作しているのにログインができないという事態に陥りました。原因究明はすぐに出来たんですが。

というわけで、ハードウェア(特にマザーボード)を交換した際には必ずntpdateで時間を合わせましょうという教訓でした。

最近のDAWは高機能であるため、どうしてもパソコンのパワーを食いがちです。DAWはリアルタイム処理がメインで、しかも録音中にパソコンがフリーズすることは許されないので、できればDAW専門のPCを用意するのが望ましいです。しかしながらDAW専用のパソコンを用意するというのは予算や設置場所の制約もあり、なかなか難しいとも思います。
私のパソコンも1台で何でもできる(さすがに3Dゲームはちと辛いですが)ので参考になればと思いスペックをさらしてみます。

M/B：FoxconnのP965搭載のやつ。安定稼働のためオーバークロックはしません。
CPU:Core 2 Quad E6600
MEM：4GB
ディスク：いっぱい(笑)。CドライブはRAID-1構成にしています。
I/F：UA-25

グラボは適当なものですので割愛します。

さて、パソコンでなにかをするということは、CPUとメモリとディスクを使うということです。アプリケーションによっても違いますがDAWの場合はCPUパワーを要求することが多いので、CPUは極力早いものがあった方がよいです。但し、マルチコアCPUに対応しているアプリなら安くなったクアッドコアも良いかと思います。
メモリはWindows XPを使っている限り2GBあれば十分、4GBあったら文句ありません。それ以上は認識されないので無駄です。もしSONAR 7 Professional Edtionを使っているのであれば、Vista 64ビット版でメモリ8GB積んで動かしてみたいですけどね。
ディスクは必要十分な容量があれば良いです。というわけでDAWはCPUとメモリが重要な要素になります。
最近の3DゲームではCPUとグラボが重要ですし、グラフィックソフトを使うならCPUとメモリですし、動画エンコードならマルチコアCPUと若干メモリの余裕があればということになります。Office系やインターネット、メールは最近のPCなら問題なく動きます。

マルチコアCPUで自作したいという方はご相談には乗れます。DAW専用であれば、モニタ込みでたぶん11～12万あれば作れると思いますよ。

どちらかというとメガマックとメガテリヤキも食べたいですよ。

風林火山って何年前のだったっけかな・・・