Hyper-V に手を出せない理由

キーボードも触ったことのない私が初めて携わった仕事が、某記憶装置の「DOS+FAT」のデバイスドライバーの開発でした。

PR



ちなみにこの某記憶装置、実は現代の最新鋭のジェット戦闘爆撃機でも使われているのですね。そもそも、航空機のアビオニクスなどは何十年も使われることが前提なので「最新鋭のアビオニクス」と言っても、私たちの使っている5000円のデジカメやスマートフォン並の性能、記憶容量でもバイクのエンジンと同じくらいの重さがあるのです。そもそもが1990年代に開発された代物です。

それはそうとして、「DOS+FAT」はインパクトが強烈だったので、今でも大体の機能は説明できます。何しろFAT12とは言え記憶装置のデバイスドライバのソースを書いた本人です。

DOS+FAT のシステムは「初めてのC」を読んだ程度の3ヶ月プログラマでも書けるオモチャみたいな仕組みだったわけです。

ところで、「DOS+FAT」を刷り込まれて育った私が不思議に思うのは

「なぜ Linux のシステムではデフラグが必要ないのだろう」

ということです。ずいぶん調べたのですが、「そもそもそんなことをする必要が無いように最初からファイルが最適化されている」ものだからだそうです。これは EXT2,3,4 も RaiserFS などもそのように作られているそうで、かつて Linux 用デフラグツールも存在したようですが、今では完全にプロジェクト自体が崩壊している(ニーズがない)物なのだそうです。ただし、ディスクの空き容量が極端に少なくなると、途端に空きセクタを求めてパフォーマンスが落ちます。私も随分経験がありますが、「妙に遅いな」と思って df -h をやると空き容量 98% などと出てあわててしまいます。

ところで Windows の NTFS は情報が非公開なので「謎のファイルシステム」です。オープンでないからソースも読めないので、ここからは想像するしかないのですが FAT -> NTFS に変更する Convert なるコマンド一発で変換できる、ということは、基本的に NTFS が FAT を基本にデータアロケーションテーブル作られているということなのですね。もし、データを書き込んでいるセクタの再配置、最適化を行うなら、 量にもよりますが数百GバイトのパーティションのConvert が数十分で終わるわけがない。つまりデータの再アロケーション(再配置、最適化)は行われません。

つまり NTFS は FAT システムの DET(ディレクトリエントリテーブル)を拡張してセキュリティ機能を追加して、安全性のため FATを強化しただけのシステムである、ということは薄々気が付いていました。(追記:MFTというそうです。つまり、FATシステムのセクタをミミズのようにたどって必要なセクタにアクセスするという基本的なアクセス方法は全く80年代のFD主力時代のPCの技術そのものなのですね。確かにFAT よりは細かなファイルは高速にアクセスできますが、大きなファイルのセクタ管理は、それほど優れているわけでない。もちろんその後の「味付け」によって重戦車並に化粧されて重くなったと思います。追記:XML によるメタファイル化されただけのようです。

NFTS は何のことはない、30年前のFATの基本設計の延長上にある物理ディスクのセクタの管理システムにジャーナリングやセキュリティ機能だとか様々なモノを付け加えただけのものなのでしょう。あくまで推測ですが。

「Windows のディスクの"プロパティ">"ツール">"最適化"を見るといつも断片率は0%じゃないか」と反論する貴方は鋭い。しかし0% と言っても、サードパーティのデフラグツールでは 30% 以上のフラグメンテーションが起きているということも当たり前にあります。純正ソフトウェアの機能なんてそんな程度なのですね。この騙しには驚きました。

そもそもフラグメンテーションが起こるからそういうツールがあるわけです。アイドリング中だろうが高負荷時でも、どうせ必死になってウラでデフラグしているわけでしょう。デスクトップだと、アイドリング時間は長いから、そんなに気にならないのですが、サーバーとして24H負荷がかかっているバックグラウンドでデフラグしていると思うと、ちょっと怖くなります。スナップショットのマージなんか始まったら、もう Raid のリビルド並のストレスがディスクにかかります。

-切り離せない過去-

マイクロソフトがNTFSを捨てられないのはあまりにも多すぎるステークスホルダーにあります。アップルのように簡単にDockコネクタを捨てられないわけです。なぜ後方互換性を無視したファイルシステムを新規に開発しないのでしょう。

-だから Hyper-V は止めとく-

GroupWise のドキュメントにあったのですが、同じ条件でインストールした Windows 版の GroupWise と NetWare 版では遥かに性能が違ったそうです。また聞きなのですが、とあるSI屋さんで、グループウェアを導入する場合、 Windows 版と Linux 版があれば、企業規模で50人程度なら Windows 版でも十分だけど100人を超えると必ず Linux 版を提案するそうです。理由はまた聞きなのではっきりしないのですが、やっぱり問題の基本は NTFS の効率の悪さにあるのだろうなと想像しています。

そこで問題になるのは「仮想化環境」です。仮想化環境で高い負荷をかけると明らかにディスクIOがボトルネックになります。ですから実験環境やごく小規模環境ではSATAディスクで問題ないと思っていますが、実運用環境ではSAS+RAID、お金と償却期間(メーカーの保障期間)を無視して短い間使えればよければSSDアクセラレータをお勧めしています。さもなければもっとDRAMを積んで仮想マシンに目いっぱいメモリを与えるようにアドバイスしています。128GbのSLCのSSDを使うより64GbのDRAMを使ったほうがお金も効率がいいと考えています。

それでも最後はHDDにデータを書きに行くわけで、書きに行くのはキャッシュが利くのでまだしも、読み出しとなると、ミミズのようなFATベースのセクタ管理を使ってノロノロとディスクから読み出すNTFSではどんなものなのでしょう。明らかに Novell Openenterprise Server (OES) の NSS や EXT3 より読み出しのパフォーマンスは落ちます。ましてや、効率の悪いNTFS上に作られたWindows仮想マシンのVHD形式も中身はNTFSですから、まさに二重苦なのです。泥沼に立てた砂のお城なのですね。IT系の Hyper-V の性能向上に関するメディア記事やベンダーのサポートページでは、「システムディスクと仮想ディスクは別な物理ディスクに作成しろ」とか「各物理ディスク1個に1つの仮想マシンを割り当てろ」とか、「全部の仮想システムをシャットダウンしてデフラグしろ」とか「資源をプール化するための仮想化のメリットのどこに役立つンだ」という???で珍妙で本末転倒な解決策が色々陳列されています。

これらのシステムはEXTは別として互換性はありません。 NetWare 5.0 から も NWFS -> NSS へ移行はセキュリティを含めてコピーはできても、はコンバートできませんでした。

-それでも必要悪-

それでも Hyper-V による仮想化は3匹の子豚の藁の家のようなニーズがあるでしょう。 Windows 8 では Hyper-V 上で複数のシステムが「簡単に切り替えられる」のがメディアが言う「売り文句」だというし、それはちょっと興味があります。

-ということでクライアント Hyper-V を試してみた-

何とか Windows8 の 64 ビット版の Hyper-V が動く環境ができたので、早速試してみました。ちなみに Intel/AMD の仮想化支援機能(VT) が機能するマシンでも Hyper-V は動かないケースがあります。SUSE + XEN の完全仮想化も問題ない機材でもあり得る事なので、Hyper-V が動くかどうかはしっかりカタログスペックを調べておくことです。

コントロールパネル>プログラムと機能>Windowsの機能の有効化/無効化から「Hyper-V」をチェックして再起動、Windows Update をして再起動で Hyper-V が使えるようになります。Hyper-V 管理ツールのアイコンができるので、このツールから管理します。

SUSE で XEN などの仮想化機能を使った方なら、すぐ仮想マシンの作成を行うことができるでしょう。もともとが XENの機能構造をそのまま真似て作ったので、今まで XEN をやってきた人であればすぐ使い方に慣れるかもしれません。Linux のパッケージに付いてくる Virt-Manager より「分かりやすい」(<-ここ重要)なインターフェースです。しかもスナップショットも取れる。

-しかし重すぎる-

しかし、最初に Windows 2003 を試しに入れて早速、Windows Update の重いことには驚きます。仮想化ホスト(Domain-0に相当)のディスク IO がほぼ 100% に近い数字です。決して子ホスト(Dom-Uに相当)が遅いわけではありません。試しに「共有」を作ってopenSUSE の iso ファイルを転送したところ、ディスク io は100% に張り付いたままです。明らかに Windows の NTFS ファイルシステムがボトルネックになっているようなんですね。SUSE + XEN に慣れていれば iostat コマンドで iowait が 100% 張り付きということはまず見ません。大抵、瞬間的に 5/60% 程度までは上がることはあってもです。
Hyper-V に手を出せない理由_a0056607_15203347.jpg
4.5Gの iso ファイルをコピー中の Hyper-V ホストのディスク利用状態


Hyper-V に手を出せない理由_a0056607_15254065.jpg

ネットワークがボトルネックになっている気配は全然ないしなぁ



これで Hyper-V は複数のシステムの仮想化ホストとして切り替えて実用的に役に立つのでしょうか。

もちろん、仮想ディスクが DAS 接続の場合は、ディスクシステム自体が NTFS なのでしょうが、SAN(ストレージネットワーク)であれば、iSCSI や PCoE(ファイバーチャネル) のSANのシステム自体が独自OSでNTFSを使っていない(たぶん)ので、仮想化ホストからは、NTFSに見えても、(たぶん)中身は EXT3 だとかだと思います。RAID 構成はまた違う意味で効率的なのかもしれません。

ということで大手のSI事業者なんかは必死に高価なファイバーチャネルのSANシステムを、事業規模にかかわらず売り込んできます。もちろん高価だし、ハードウェアのサポート料金も高い。私がベンダーのセールスマンだったら、間違えなく Hyper-V をおすすめします。そのほうがお客様からの手離れはいいですし、彼らは高価なパッケージやハードウェアを沢山買ってくれるからです。何しろ SUSE Linux の無制限仮想化アクティベーションは僅か4万円ほどなのです。

もちろん、2008S/2012S の Hyper-V とはクライアント Hyper-V はチューニングが違うのよ、と言われればその通りなのですが、Hyper-V 3.0 は、メディアでは「滅茶苦茶に高機能高性能になってスケーラビリティと言ったら、そりゃもう何個の仮想CPUが使えて何TBのメモリが使えて最大何TBの仮想ディスクが使える」というカタログスペックを語る記事をよく見ます。

しかし彼らの記事はカタログスペックを記事にしただけで、実際に運用をしてみたわけではない。本当に1台のハードウェアで何台の仮想マシンが「運用に耐えられるか」と考えた場合、やはり Linux/Unix 系で動作する XEN や KVM, VMware などに軍配が上がりそうです。

何しろ「Hyper-V 遅い ディスクIO」などのキーワードで検索すると出てくる出てくる、運用者の嘆き。諦めて VMware に乗せ換えたとか、KVM に乗せ換えた事例がゴロゴロ出てきます。結局、SASディスクを諦めて、SSD-Raid に乗せ換えたら爆速に解決した(それって根本的に重大な問題じゃん)とか、いかに Hyper-V が金食い虫なのかの事例がボロボロ出ているのが実情の様です。

実際は「単機能をコンパクトに仮想化してアプライアンス化」することを考えれば、別に仮想ディスクなんて僅かで済んでしまいます。実際 SLES11 を導入してみましたが、僅か 512Mbのメモリと4Gの仮想ディスクでインストールできてしまいました。おそらくこの程度なら簡単な LAMP や DNS/DHCP として利用することには何の問題もないでしょう。

Hyper-V に手を出せない理由_a0056607_1531384.jpg
リモートで使うと操作が「お、重すぎる」


スナップショットも使えるようですが、これだけディスクIOが大きいと、スナップショットを取った後のマージ処理が怖そうです。

百歩譲ってGUIの親切さ、使い易さは賞賛する価値はありますが、いかんせん openSUSE+XEN と Windows Hyper-V をデュアルブートして(つまり全く同じ環境で)動かすと体感上 Hyper-V で Linux を動かすと "Is there anyone home ? knock knock..." と頭を殴りつけたいくらい重い。これで実用に耐えられるのかしらって思わず考え込んでしまいます。


仮想化の脅威、「ハイパーバイザー攻撃」を防ぐ3つの対策

仮想データセンターのセキュリティ対策における最初の1歩は、ホストサーバの攻撃対象を狭めることだ。特に米MicrosoftのHyper-Vは、Windows Serverにロールとしてインストールされることも多く、攻撃対象を減らすことが重要になる。

この記事では Hyper-V 以外のハイパーバイザーの記載はありません。つまり Hyper-V は脅威に対して何等かのマルウェア、ウィルス対策が必要だということです。つまり、サーバーで一番重いジョブ。つまりハイパーバイザー管理者にとって悪夢とも言える何らかの対策が必要なのです。そして、Windows Update ととアンチウィルスソフトウェアを更新すると訪れる悪夢のような「再起動」のダイアログ。やっぱり Hyper-V はライブマイグレーションを前提で考える必要がありそうです。119万円しますからね。二つ購入するのはちょっと勇気が必要です。

Windows Update とアンチウィルスソフトウェアのない Windows Server を運用するのは、冬のススキノの街をゴムなしの皮靴で歩くような危なさがあります。

一方で、 Unix/Linux 系のハイパーバイザーでも脆弱性はあるでしょう。SSH や DNS ポイズニングです。しかしこの様な対策は、ウィルス対策で何とかなるものではありません。基本的には、脆弱性のあるパッケージをアップデートして、サービスを立ち上げ直すだけです。カーネルに致命的な欠陥がなければまず再起動は必要ないでしょう。


-Hyper-V を誉めてみる-

それでも Hyper-V のニーズがあることは事実でしょう。少なくとも Hyper-V の管理コンソールは動作もキビキビしているし、わかりやすい。リモートデスクトップでも管理操作はそこそこ軽快だと思います。それによく出来ている。Linux で

「putty で入って xm create してくれ」

というよりは分かりやすいわけです。ここに Windows 「しか」知らない管理者と Linux「も」知っている管理者との違いが出てきます。

まぁそれでも GUI 操作がうまくいかない場合 vbscript や PowerShell でスクリプト作らなければならない Hyper-V よりは楽だと思うのですが....

-俄か管理者とエンジニアの違い-

少なくとも 「Linux を扱うエンジニアで Windows には全く無知」という人はほとんどいないと思います。かく言う自分自身がやっぱり Windows の GUI は文句がいっぱいあっても使いやすいと思っています。

あるいは「Mac は好きだけど Windows は大嫌い」という方もいらっしゃいます。彼らに言えることは「あなたたちは少なくとも他のプラットフォームと比較できるだけのスキルがある」ということなのですね。

逆に 「Windows は知っているけど Linux はなぁ...」という方は沢山いらっしゃる。特に Windows 以降の世代でコンピューターを扱った方にはそういう「エンジニア」の方々も多いと思います。

よく言われることですが「Linux は管理コストが高い」と言われます。逆に言えば「Linuxの管理者なら高い単価で仕事ができる」ということになります。また 「Windows しか知らないエンジニアはいつまで経っても単価が安い」ということになるのでしょうか。 あくまでも技術者としての視点ですね。

もし「エンジニア」としてキャリアを積みたい「システム管理者」や「ベンダーのエンジニア」がいれば Windows しか知らないのはどうなんでしょう。

しかし「社内でキャリアを積みたい」あるいは「エンジニアとしてのキャリアには興味がない」のなら Hyper-V は良い選択です。決して「俄か管理者」を否定するものではありません。そういう生き方もあるということです。

続き: 実はお金が無いのが最大の理由だったりしますが...
仮想化のお値段:無制限インスタンスに払うお値段

続きはこちらで
一度は経験したい仮想化の別世界:SIベンダーが教えたくない実情

その続きはこちらで
Hyper-V のハイパーバイザーでは MTBF は低くないのか?

関連記事

Hyper-V の仮想化でメモリリークがあり、異常に遅くなる。


初めての Linux, openSUSE Leap を Hyper-V で動かす


hyper-v sqlserver 遅いのはディスクio, vmware hyper-v 比較 2019, hyper v オーバーヘッド, virtualbox, ディスク速度が遅い,マウスが遅い、linux と Hyper-V



Commented by 3 at 2015-07-29 14:33 x
無理です

ファイルが壊れまくりです。

くっそーどうすんねん
Commented by islandcenter at 2015-08-02 18:02
そりゃバックアップから戻すことでしょうね。
Commented by IT-BOY at 2015-10-15 11:56 x
MSのバグ取りて、ほんとクソレベルwwwwww
Commented by islandcenter at 2015-10-16 06:57
コメントありがとうございます。 w
Commented by ななし at 2018-09-25 16:40 x
>よく言われることですが「Linux は管理コストが高い」と言われます。
>逆に言えば「Linuxの管理者なら高い単価で仕事ができる」ということになります。
>また 「Windows しか知らないエンジニアはいつまで経っても単価が安い」という
>ことになるのでしょうか。 あくまでも技術者としての視点ですね。

その「技術者」を使う側の観点でいうと、そんな維持にカネかかるシステムなら、
維持にカネかからないWindows「とやら」で組んで、安いエンジニアとか内製で
やろうず、って考えも割とあるもんですよ。
まぁ彼らはWindows「も」できるらしいので、単価下がることに文句いわなければ
その仕事もできるんですが、案外Windows「は」そんなに知らないLinuxエンジニア
は居るんですよ。
Commented by islandcenter at 2018-10-07 13:10
コメントありがとうございます。承認がおそくなりました。Windows は嫌いというエンジニア「も」Linux は嫌いというエンジニアもいるのでしょうが、知りたいという欲求が薄いとあまりいじりたくないわけですね。もっともなご意見ありがとうございます。
Commented by まる at 2019-04-08 11:10 x
この記事がアップされて6年。
その後の評価は変わらずでしょうか。
WSFCか、vSphere Essentials Plus か悩み中です。
うちみたいな弱小ベンダーは、贅沢なインフラは無理そうだし。
・取り扱うのがHyper-V ばかりになってしまったなか、今更VMwareは大丈夫か
・vCenter はアプライアンスで追加のHWは不要だが、ライセンスが意外とする。
 バックアップソフトの選定によっては、やっぱり追加のサーバーが必要になりそうな感じだし。
ん~。
Commented by islandcenter at 2019-04-12 06:51
他人のブログ記事って割とタメになるもので、"Hyper-V 遅い"で検索すると色々な事象が出てくるようです。一方で、KVM や XEN, VMware が遅いという記事を見ないので、やっぱり Hyper-V は違うのでしょう。
一番「手が出ない」理由は、ライセンスコストですね。私の事業規模では気楽に手が出ません。
Commented by aki at 2019-08-23 16:52 x
NTFSの断片化について
> この騙しには驚きました。
Windowsのデフラグツールは64MB以上大きな断片はパフォーマンスに影響ないとしてカウントしない仕様であり、騙しではありませんよ。(コマンドライン版では利用のたびに仕様について明示されます)

> 「なぜ Linux のシステムではデフラグが必要ないのだろう」
10年以上前ですが、同じことが気になって調べたことがあります。

Windowsでは空き領域の先頭(ディスク外周)に詰めてファイルを配置します。
Linuxなどではファイルをディスク全体に間を空けて配置します。
(空き容量が減ったとき、空き容量が非常に細かく分断されている理由です)

HDDの時代だと、Windows方式は外周に詰めているぶん、単純にパフォーマンスが出やすかったんです(定期的なデフラグが必須ですが)。
Linuxは、アクセスの遅い内周部も均等に使うかわり、ログファイルの追記などちょっとしたファイルサイズの変更程度では断片化が生じないため、デフラグの必要性が下がります。
つまりこれは、ファイルシステムの差ではなく、クライアント向けのWindowsとマルチユーザ・サーバ向けLinuxの思想の差による「ファイル配置の方法」の差です。
Extだろうとなんだろうと、断片化するようにファイルを書き込めば断片化します。原理的に可能なんですから。

まぁ、SSDだと(OSから見たのセクタ配置と実際の配置が異なるなどで)あまり意味のない差になりつつありますが…。
by islandcenter | 2013-01-29 16:24 | プライベートクラウド | Comments(9)