1
2017年 06月 19日
Windows10激重、HDD アクセスが 100% になりっぱなしを何とかして！
-現象-
WIndows10 (1607) で、ディスクアクセスが１００％になる。全く処理を受け付けなくなる。アプリケーションを全部強制終了させてもダメ。
1) どうもこの現象は、Windows Update をやった後に起こりやすい(やる前にも時々あるので、だからってわけでもないな)
2) FTP や Bit torrent で Linux のディストリビューションのような、数Ｇｂのデータをダウンロードしている最中に発生しやすい（ような気がする）
特に FTP や Windows Store からダウンロードしながら、ヒマこいて YouTube なんか見ていると、あぼん。(痛いなぁ...やり直しか)
3) 大きなファイルを別なメディアにコピー、移動、削除などの処理をした後に陥る（ような気がする）
4) こういう時間がかかる処理でヒマこいている時に、暇つぶしに何かぼーっとしている時に大抵こういう状態に陥る。
5) ディスクの空き容量が少ないＰＣに出やすい現象(のようだ)
6) リブートすらできない。そもそも、リブートボタンまでたどり着けない。仕方がないので DOS 窓から > shutdown /r /t 0 してものろのろお帰りのお仕度を初めて、エラク反応が遅い。
7) そういう時にかぎって、急な用事を思い出して、こなさなければならない。で、トラブルシューティングを始めたら、「急いでやるべきこと」を忘れてしまうというオマケ付き。
8) ディスクの空きが余裕のヨッちゃんなＰＣでは現象出ず。
9) Windows Update Service を無効にしてみる。ただし手動アップデートもエラーになるし、やっぱりHDD 100% 病は治らない。 (確かになぁあり得るんだよな)
こんなのが何時間も続くと、イライラが募って、もう昼間っから酒飲んじゃうぞって気分になるのですよ。
- 色々な対策 -
でも日曜日の昼間っから酒飲んでも問題は片付かないわけですね。という事で色々調べてみたのですが、皆様つぎのようなご苦労を色々しているようです。
1) 極悪の OneDrive を殺す (既に無効にしてるんだが)
極悪 Windows10 の OneDrive を無効にする
2) タスクマネージャでディスクに必死こいて、アクセスしまくるサービスを止めてみる(と言っても一番しつこいサービス停止は拒否されることが多いし...)
3) IPv6 を無効にしてみる(インストールしたら、即時そうしていますよ....)
Windows7 からWindows10 にアップデートしたらまずするべき事。
4) リソースモニタ > 「ディスクタブ」を開くと、ページファイルに必死に書き込んでいるので、ページファイルのサイズをいじってみた(効果なし)
当然、ファイルがジャンスカ書かれるので、アンチウィルス系のソフトウェアもビンビンで大忙しの様だ。
5) 仕方なく、物理的な電源ボタンから「強制終了」して、あるいはコンセントを引っこ抜いて、お祈りしながら起動できるかナぁ...
6) サービスの中の Superfetch を無効にする（とっくにしている）
Windows10 の停止しておきたいサービスとタスク
という事で前後の状況から、どうも「システムディスクに余裕がないときに大きなファイル操作をしている時に、ヒマこいて 「YouTube なんか」をぼーっと見ていると現象が出るわけなで、そういう時にこそ、急な調べものなんかをしたくなるのですね。
そこでアイドリングプロセス中にやっていそうな、一番アヤシいプロセス。「自爆(あ自動だ)メンテナンス」を止めてみました。
コントロールパネル > セキュリティとメンテナンス > 「メンテナンス」を開くと「自爆メンテナンス」が「進行中」です。思わず００７のロジャームーアになった気分。
で、「自動メンテナンス」を「停止」したら、あれれ。
２，３０秒後に見事に嵐が止みはじめました。
もっとも、アイドリング状態から、いきなり使い始めても、すぐには戻りません。
これも「停止」させようにも、激重中に「停止」すら押せない事もあるので、もう致命的です。まるでオシッコが止まらないアル中患者のようにしつこく動き続けることがあります。
そういう時は、電源スイッチを長押しして「南無阿弥陀仏」を唱えながら、もう一度電源を投入するしか方法がありません。
無事お祈りが利いて起動できたら、「自爆....」あ、いや「自動メンテナンス」を「停止」させます。
あらら、やっぱりこうだったか、とまた HDD 100% 状態です。逃げろロジャームーア。
ただ、この「メンテナンス」ってヤツは「自動」で、アイドリング状態になると、ノラ猫のようにゴミ箱あさりを始めるので、また「停止」させなければなりません。しかも、この設定を弄れるのは、管理者アイコンが示す通り、「管理者のみ」です。
ユーザに「一般ユーザ」でログオンさせて使わせています、という様な、一般企業の環境では大変な大騒ぎとなるわけですね。
デフォルトでは、夜中の３時に、スリープ中のＰＣをたたき起こして「働かせる」という、プアなＰＣだったら「過酷な仕様」ですし、ほおーっておくと、また「勝手に開始」されてしまうようです。タスクスケジューラから「無効」にしても効き目はないようです。
ノートＰＣの Bios パスワードをかけて、「帰宅や外出で離席する時は、コンセントとネットワークケーブルを外してＰＣを机の中にしまっておく事」なんて、企業の運用ルールなんか無視しまくりです。
朝いちばんにノートPCを引き出しから出したら、奇妙に本体があったかいンだからぁ～、おまけにバッテリーは消耗しまくっているし。
となると、また朝いちばんからヘルプデスクの電話は鳴りっぱなしになるわけです。
試しにタスクスケジューラを止めてみてもだめでした。
全くお節介で厄介な仕様なんですね。しかもコントロールできない、無敵の Microsoft 仕様なのです。
レジストリをツツけば「自動メンテナンス」を無効にできるようですが
How to disable Automatic Maintenance in Windows 10 and 7
によると
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\Maintenance]
に " MaintenanceDisabled" という DWORD のキーを作って、値に 1 を設定してリブートすると、この「自動運転の嵐」は止むようなのです。ただし一応「システムメンテナンス」は、あの悪名高い NFTS のフラグメンテーションの補正だとか、あまり役に立つとはおもえないけれど Windows Defender のスキャン、いらなくなったシステムファイルやパッチなどのクリーンアップをするようなので、止めておくことは決して勧められるものではないようです。
だからシステムの変更があった時や大きなファイルを操作した時に、大幅な「席替え」をせっせとやるわけですね。もっとも、こんな事できるのは「管理者」だけなので、一般ユーザにこんなフクザツな作業をやらせたくない。
そもそもそんなのＵＩに常備しろよと言いたくなるのですが、あまり公にはしたくない、かなり怪しい機能なんですね。
だから、もし上のレジストリを弄ったら、もう一度 Value を 0 にして、メンテナンスをして放置プレーするしかないようです。お勧めはしませんよ。
- まず一番効果的と思われるのは-
とにかく、エンドユーザさんには「ローカルディスクの空きを沢山空けておけ」空きに余裕があれば、そう滅多に自動メンテナンスはしない(ような気がする)。何しろフラグメントの起こりやすい事で有名で、２５年以上昔に開発されて厚化粧を繰り返してきた Windows の NTFS だ。重くなって仕方がない。またデカいファイルなんか、特に Hyper-V とか動かすと、４Ｇの ISO だとか 4０Gb の VHD 仮想ディスクイメージなんかが、ごっちょりあるので少しは整理して、放置プレーということでしょうかね。
まぁ、除虫剤のように「お出かけ前に」メンテナンスモードにして「帰ったら窓開け換気」じゃないな、メンテナンスモードを解除するのが、この暴れ馬を乗りこなす一つの方法かも知れません。
それにしても、こんな現象ってやっぱり Windows サーバーでも起こるのでしょうか。だから Windows (Storage 版の NAS も含む)のファイルサーバーって信用できないンですけどね。Hyper-V なんぞで、ディスクの容量ギリギリでスナップショットなんか取ったら、悲惨そう....
それから Windows のログも見てチョウダイネ、という事です。
- 結局そういうことだったのか -
やっぱり Windows Log はみるべきだった。ディスクエラー出てるんじゃん！
という事で、ディスクエラーがでているので、バックグラウンドタスクが何度もリトライするわけですね。という事で、このPCもうダメじゃんということが判りました。
PS:その後見事に昇天し、最後を遂げましたトサ。南無南無............
OES 2018 Linux で SMB ファイルサーバーのフォルダ容量制限(ディレクトリクォータ)
openSUSE Leap 15 Install : インストールファーストインプレッション
https://islandcnt.exblog.jp/238548280/
--
Windows10 HDD 100% 重い、遅い、Hyper-V Windows 制御不能 メンテナンスモード
■
[PR]
▲
by islandcenter
| 2017-06-19 15:29
| Windows
|
Trackback
|
Comments(0)
2016年 04月 11日
Hyper-V の仮想化でメモリリークがあり、異常に遅くなる。
- 現象 -
Hyper-V が動作すコンピュータのメモリ利用状態が９０％を超えた状態で、全てのレスポンスが異常に遅い。すべてのアプリケーションを終了させたが、メモリ利用状況は変わらず 90% を超えている。
.png)
なんじゃこれ！
- 内容 -
やむを得ずシステム全体を再起動したが、状況は２日程度で再現する。
Hyper-V で仮想マシンが動いていたのでシャットダウンしたら現象が回避できた。
.png)
なんじゃこれ！
- 原因 -
Hyper-V で仮想マシンをシャットダウンしたら修復できた。 Windows + Hyper-V のメモリリークと思われる。ちなみに動作していた仮想マシンは 768Mb のメモリしか占有していなかったにも関わらず6G以上のメモリがリークされ、ガーベジコレクションも行われない。ちなみに同じ仮想システムイメージは他のハイパーバイザーでは再現しない。
- 対策 -
- Hyper-V ハイパーバイザーを定期的にリブートする
- 仮想コンピューターを定期的に夜中にリブートする。
- Hyper-V から別なハイパーバイザーに乗り換える。
なお、仮想コンピューターをシャットダウン、リブートするコマンドラインはないので、VBscript などを書くか GUIから手動で行わなければならない。夜中の業務時間外にリブートするコマンドは標準では実装できないので、深夜出勤してGUIで操作するか、 Hyper-V 自体のハードウェアを UPS や Shutdown コマンドで定期的に業務時間外にリブートする方法が最適と考えられる。
だから、 Hyper-V だけは絶対やめた方がいいと言っただろうが。
関連記事
■
[PR]
▲
by islandcenter
| 2016-04-11 06:41
| Windows
|
Trackback
|
Comments(5)
2013年 01月 29日
Hyper-V に手を出せない理由
キーボードも触ったことのない私が初めて携わった仕事が、某記憶装置の「DOS＋FAT」のデバイスドライバーの開発でした。
ちなみにこの某記憶装置、実は現代の最新鋭のジェット戦闘爆撃機でも使われているのですね。そもそも、航空機のアビオニクスなどは何十年も使われることが前提なので「最新鋭のアビオニクス」と言っても、私たちの使っている５０００円のデジカメやスマートフォン並の性能、記憶容量でもバイクのエンジンと同じくらいの重さがあるのです。そもそもが１９９０年代に開発された代物です。
それはそうとして、「DOS+FAT」はインパクトが強烈だったので、今でも大体の機能は説明できます。何しろＦＡＴ１２とは言え記憶装置のデバイスドライバのソースを書いた本人です。
DOS+FAT のシステムは「初めてのＣ」を読んだ程度の３ヶ月プログラマでも書けるオモチャみたいな仕組みだったわけです。
ところで、「DOS＋FAT」を刷り込まれて育った私が不思議に思うのは
「なぜ Linux のシステムではデフラグが必要ないのだろう」
ということです。ずいぶん調べたのですが、「そもそもそんなことをする必要が無いように最初からファイルが最適化されている」ものだからだそうです。これは EXT2,3,4 も RaiserFS などもそのように作られているそうで、かつて Linux 用デフラグツールも存在したようですが、今では完全にプロジェクト自体が崩壊している（ニーズがない）物なのだそうです。ただし、ディスクの空き容量が極端に少なくなると、途端に空きセクタを求めてパフォーマンスが落ちます。私も随分経験がありますが、「妙に遅いな」と思って df -h をやると空き容量 98% などと出てあわててしまいます。
ところで Windows の NTFS は情報が非公開なので「謎のファイルシステム」です。オープンでないからソースも読めないので、ここからは想像するしかないのですが FAT -> NTFS に変更する Convert なるコマンド一発で変換できる、ということは、基本的に NTFS が FAT を基本にデータアロケーションテーブル作られているということなのですね。もし、データを書き込んでいるセクタの再配置、最適化を行うなら、 量にもよりますが数百ＧバイトのパーティションのConvert が数十分で終わるわけがない。つまりデータの再アロケーション（再配置、最適化）は行われません。
つまり NTFS は FAT システムの DET(ディレクトリエントリテーブル)を拡張してセキュリティ機能を追加して、安全性のため FATを強化しただけのシステムである、ということは薄々気が付いていました。（追記:MFTというそうです。つまり、FATシステムのセクタをミミズのようにたどって必要なセクタにアクセスするという基本的なアクセス方法は全く８０年代のＦＤ主力時代のＰＣの技術そのものなのですね。確かにFAT よりは細かなファイルは高速にアクセスできますが、大きなファイルのセクタ管理は、それほど優れているわけでない。もちろんその後の「味付け」によって重戦車並に化粧されて重くなったと思います。追記:XML によるメタファイル化されただけのようです。
NFTS は何のことはない、３０年前のFATの基本設計の延長上にある物理ディスクのセクタの管理システムにジャーナリングやセキュリティ機能だとか様々なモノを付け加えただけのものなのでしょう。あくまで推測ですが。
「Windows のディスクの"プロパティ"＞"ツール"＞"最適化"を見るといつも断片率は０％じゃないか」と反論する貴方は鋭い。しかし0% と言っても、サードパーティのデフラグツールでは 30% 以上のフラグメンテーションが起きているということも当たり前にあります。純正ソフトウェアの機能なんてそんな程度なのですね。この騙しには驚きました。
そもそもフラグメンテーションが起こるからそういうツールがあるわけです。アイドリング中だろうが高負荷時でも、どうせ必死になってウラでデフラグしているわけでしょう。デスクトップだと、アイドリング時間は長いから、そんなに気にならないのですが、サーバーとして２４Ｈ負荷がかかっているバックグラウンドでデフラグしていると思うと、ちょっと怖くなります。スナップショットのマージなんか始まったら、もう Raid のリビルド並のストレスがディスクにかかります。
-切り離せない過去-
マイクロソフトがＮＴＦＳを捨てられないのはあまりにも多すぎるステークスホルダーにあります。アップルのように簡単にDockコネクタを捨てられないわけです。なぜ後方互換性を無視したファイルシステムを新規に開発しないのでしょう。
-だから Hyper-V は止めとく-
GroupWise のドキュメントにあったのですが、同じ条件でインストールした Windows 版の GroupWise と NetWare 版では遥かに性能が違ったそうです。また聞きなのですが、とあるＳＩ屋さんで、グループウェアを導入する場合、 Windows 版と Linux 版があれば、企業規模で５０人程度なら Windows 版でも十分だけど１００人を超えると必ず Linux 版を提案するそうです。理由はまた聞きなのではっきりしないのですが、やっぱり問題の基本は NTFS の効率の悪さにあるのだろうなと想像しています。
そこで問題になるのは「仮想化環境」です。仮想化環境で高い負荷をかけると明らかにディスクＩＯがボトルネックになります。ですから実験環境やごく小規模環境ではＳＡＴＡディスクで問題ないと思っていますが、実運用環境ではＳＡＳ＋ＲＡＩＤ、お金と償却期間（メーカーの保障期間）を無視して短い間使えればよければＳＳＤアクセラレータをお勧めしています。さもなければもっとＤＲＡＭを積んで仮想マシンに目いっぱいメモリを与えるようにアドバイスしています。１２８ＧｂのＳＬＣのＳＳＤを使うより６４ＧｂのＤＲＡＭを使ったほうがお金も効率がいいと考えています。
それでも最後はＨＤＤにデータを書きに行くわけで、書きに行くのはキャッシュが利くのでまだしも、読み出しとなると、ミミズのようなＦＡＴベースのセクタ管理を使ってノロノロとディスクから読み出すＮＴＦＳではどんなものなのでしょう。明らかに Novell Openenterprise Server (OES) の NSS や EXT3 より読み出しのパフォーマンスは落ちます。ましてや、効率の悪いＮＴＦＳ上に作られたWindows仮想マシンのＶＨＤ形式も中身はＮＴＦＳですから、まさに二重苦なのです。泥沼に立てた砂のお城なのですね。IT系の Hyper-V の性能向上に関するメディア記事やベンダーのサポートページでは、「システムディスクと仮想ディスクは別な物理ディスクに作成しろ」とか「各物理ディスク１個に１つの仮想マシンを割り当てろ」とか、「全部の仮想システムをシャットダウンしてデフラグしろ」とか「資源をプール化するための仮想化のメリットのどこに役立つンだ」という？？？で珍妙で本末転倒な解決策が色々陳列されています。
これらのシステムはEXTは別として互換性はありません。 NetWare 5.0 から も NWFS -> NSS へ移行はセキュリティを含めてコピーはできても、はコンバートできませんでした。
-それでも必要悪-
それでも Hyper-V による仮想化は３匹の子豚の藁の家のようなニーズがあるでしょう。 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% 程度までは上がることはあってもです。
4.5Gの iso ファイルをコピー中の Hyper-V ホストのディスク利用状態
ネットワークがボトルネックになっている気配は全然ないしなぁ
これで Hyper-V は複数のシステムの仮想化ホストとして切り替えて実用的に役に立つのでしょうか。
もちろん、仮想ディスクが DAS 接続の場合は、ディスクシステム自体が NTFS なのでしょうが、SAN（ストレージネットワーク）であれば、iSCSI や PCoE(ファイバーチャネル) のSANのシステム自体が独自OSでNTFSを使っていない（たぶん）ので、仮想化ホストからは、NTFSに見えても、（たぶん）中身は EXT3 だとかだと思います。RAID 構成はまた違う意味で効率的なのかもしれません。
ということで大手のSI事業者なんかは必死に高価なファイバーチャネルのSANシステムを、事業規模にかかわらず売り込んできます。もちろん高価だし、ハードウェアのサポート料金も高い。私がベンダーのセールスマンだったら、間違えなく Hyper-V をおすすめします。そのほうがお客様からの手離れはいいですし、彼らは高価なパッケージやハードウェアを沢山買ってくれるからです。何しろ SUSE Linux の無制限仮想化アクティベーションは僅か４万円ほどなのです。
もちろん、2008S/2012S の Hyper-V とはクライアント Hyper-V はチューニングが違うのよ、と言われればその通りなのですが、Hyper-V 3.0 は、メディアでは「滅茶苦茶に高機能高性能になってスケーラビリティと言ったら、そりゃもう何個の仮想CPUが使えて何TBのメモリが使えて最大何TBの仮想ディスクが使える」というカタログスペックを語る記事をよく見ます。
しかし彼らの記事はカタログスペックを記事にしただけで、実際に運用をしてみたわけではない。本当に１台のハードウェアで何台の仮想マシンが「運用に耐えられるか」と考えた場合、やはり Linux/Unix 系で動作する XEN や KVM, VMware などに軍配が上がりそうです。
何しろ「Hyper-V 遅い ディスクIO」などのキーワードで検索すると出てくる出てくる、運用者の嘆き。諦めて VMware に乗せ換えたとか、KVM に乗せ換えた事例がゴロゴロ出てきます。結局、SASディスクを諦めて、SSD-Raid に乗せ換えたら爆速に解決した（それって根本的に重大な問題じゃん）とか、いかに Hyper-V が金食い虫なのかの事例がボロボロ出ているのが実情の様です。
実際は「単機能をコンパクトに仮想化してアプライアンス化」することを考えれば、別に仮想ディスクなんて僅かで済んでしまいます。実際 SLES11 を導入してみましたが、僅か 512Mbのメモリと４Gの仮想ディスクでインストールできてしまいました。おそらくこの程度なら簡単な LAMP や DNS/DHCP として利用することには何の問題もないでしょう。
リモートで使うと操作が「お、重すぎる」
スナップショットも使えるようですが、これだけディスクIOが大きいと、スナップショットを取った後のマージ処理が怖そうです。
百歩譲ってＧＵＩの親切さ、使い易さは賞賛する価値はありますが、いかんせん 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 はライブマイグレーションを前提で考える必要がありそうです。１１９万円しますからね。二つ購入するのはちょっと勇気が必要です。
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 は低くないのか？
関連記事
ちなみにこの某記憶装置、実は現代の最新鋭のジェット戦闘爆撃機でも使われているのですね。そもそも、航空機のアビオニクスなどは何十年も使われることが前提なので「最新鋭のアビオニクス」と言っても、私たちの使っている５０００円のデジカメやスマートフォン並の性能、記憶容量でもバイクのエンジンと同じくらいの重さがあるのです。そもそもが１９９０年代に開発された代物です。
それはそうとして、「DOS+FAT」はインパクトが強烈だったので、今でも大体の機能は説明できます。何しろＦＡＴ１２とは言え記憶装置のデバイスドライバのソースを書いた本人です。
DOS+FAT のシステムは「初めてのＣ」を読んだ程度の３ヶ月プログラマでも書けるオモチャみたいな仕組みだったわけです。
ところで、「DOS＋FAT」を刷り込まれて育った私が不思議に思うのは
「なぜ Linux のシステムではデフラグが必要ないのだろう」
ということです。ずいぶん調べたのですが、「そもそもそんなことをする必要が無いように最初からファイルが最適化されている」ものだからだそうです。これは EXT2,3,4 も RaiserFS などもそのように作られているそうで、かつて Linux 用デフラグツールも存在したようですが、今では完全にプロジェクト自体が崩壊している（ニーズがない）物なのだそうです。ただし、ディスクの空き容量が極端に少なくなると、途端に空きセクタを求めてパフォーマンスが落ちます。私も随分経験がありますが、「妙に遅いな」と思って df -h をやると空き容量 98% などと出てあわててしまいます。
ところで Windows の NTFS は情報が非公開なので「謎のファイルシステム」です。オープンでないからソースも読めないので、ここからは想像するしかないのですが FAT -> NTFS に変更する Convert なるコマンド一発で変換できる、ということは、基本的に NTFS が FAT を基本にデータアロケーションテーブル作られているということなのですね。もし、データを書き込んでいるセクタの再配置、最適化を行うなら、 量にもよりますが数百ＧバイトのパーティションのConvert が数十分で終わるわけがない。つまりデータの再アロケーション（再配置、最適化）は行われません。
つまり NTFS は FAT システムの DET(ディレクトリエントリテーブル)を拡張してセキュリティ機能を追加して、安全性のため FATを強化しただけのシステムである、ということは薄々気が付いていました。（追記:MFTというそうです。つまり、FATシステムのセクタをミミズのようにたどって必要なセクタにアクセスするという基本的なアクセス方法は全く８０年代のＦＤ主力時代のＰＣの技術そのものなのですね。確かにFAT よりは細かなファイルは高速にアクセスできますが、大きなファイルのセクタ管理は、それほど優れているわけでない。もちろんその後の「味付け」によって重戦車並に化粧されて重くなったと思います。追記:XML によるメタファイル化されただけのようです。
NFTS は何のことはない、３０年前のFATの基本設計の延長上にある物理ディスクのセクタの管理システムにジャーナリングやセキュリティ機能だとか様々なモノを付け加えただけのものなのでしょう。あくまで推測ですが。
「Windows のディスクの"プロパティ"＞"ツール"＞"最適化"を見るといつも断片率は０％じゃないか」と反論する貴方は鋭い。しかし0% と言っても、サードパーティのデフラグツールでは 30% 以上のフラグメンテーションが起きているということも当たり前にあります。純正ソフトウェアの機能なんてそんな程度なのですね。この騙しには驚きました。
そもそもフラグメンテーションが起こるからそういうツールがあるわけです。アイドリング中だろうが高負荷時でも、どうせ必死になってウラでデフラグしているわけでしょう。デスクトップだと、アイドリング時間は長いから、そんなに気にならないのですが、サーバーとして２４Ｈ負荷がかかっているバックグラウンドでデフラグしていると思うと、ちょっと怖くなります。スナップショットのマージなんか始まったら、もう Raid のリビルド並のストレスがディスクにかかります。
-切り離せない過去-
マイクロソフトがＮＴＦＳを捨てられないのはあまりにも多すぎるステークスホルダーにあります。アップルのように簡単にDockコネクタを捨てられないわけです。なぜ後方互換性を無視したファイルシステムを新規に開発しないのでしょう。
-だから Hyper-V は止めとく-
GroupWise のドキュメントにあったのですが、同じ条件でインストールした Windows 版の GroupWise と NetWare 版では遥かに性能が違ったそうです。また聞きなのですが、とあるＳＩ屋さんで、グループウェアを導入する場合、 Windows 版と Linux 版があれば、企業規模で５０人程度なら Windows 版でも十分だけど１００人を超えると必ず Linux 版を提案するそうです。理由はまた聞きなのではっきりしないのですが、やっぱり問題の基本は NTFS の効率の悪さにあるのだろうなと想像しています。
そこで問題になるのは「仮想化環境」です。仮想化環境で高い負荷をかけると明らかにディスクＩＯがボトルネックになります。ですから実験環境やごく小規模環境ではＳＡＴＡディスクで問題ないと思っていますが、実運用環境ではＳＡＳ＋ＲＡＩＤ、お金と償却期間（メーカーの保障期間）を無視して短い間使えればよければＳＳＤアクセラレータをお勧めしています。さもなければもっとＤＲＡＭを積んで仮想マシンに目いっぱいメモリを与えるようにアドバイスしています。１２８ＧｂのＳＬＣのＳＳＤを使うより６４ＧｂのＤＲＡＭを使ったほうがお金も効率がいいと考えています。
それでも最後はＨＤＤにデータを書きに行くわけで、書きに行くのはキャッシュが利くのでまだしも、読み出しとなると、ミミズのようなＦＡＴベースのセクタ管理を使ってノロノロとディスクから読み出すＮＴＦＳではどんなものなのでしょう。明らかに Novell Openenterprise Server (OES) の NSS や EXT3 より読み出しのパフォーマンスは落ちます。ましてや、効率の悪いＮＴＦＳ上に作られたWindows仮想マシンのＶＨＤ形式も中身はＮＴＦＳですから、まさに二重苦なのです。泥沼に立てた砂のお城なのですね。IT系の Hyper-V の性能向上に関するメディア記事やベンダーのサポートページでは、「システムディスクと仮想ディスクは別な物理ディスクに作成しろ」とか「各物理ディスク１個に１つの仮想マシンを割り当てろ」とか、「全部の仮想システムをシャットダウンしてデフラグしろ」とか「資源をプール化するための仮想化のメリットのどこに役立つンだ」という？？？で珍妙で本末転倒な解決策が色々陳列されています。
これらのシステムはEXTは別として互換性はありません。 NetWare 5.0 から も NWFS -> NSS へ移行はセキュリティを含めてコピーはできても、はコンバートできませんでした。
-それでも必要悪-
それでも Hyper-V による仮想化は３匹の子豚の藁の家のようなニーズがあるでしょう。 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 は複数のシステムの仮想化ホストとして切り替えて実用的に役に立つのでしょうか。
もちろん、仮想ディスクが DAS 接続の場合は、ディスクシステム自体が NTFS なのでしょうが、SAN（ストレージネットワーク）であれば、iSCSI や PCoE(ファイバーチャネル) のSANのシステム自体が独自OSでNTFSを使っていない（たぶん）ので、仮想化ホストからは、NTFSに見えても、（たぶん）中身は EXT3 だとかだと思います。RAID 構成はまた違う意味で効率的なのかもしれません。
ということで大手のSI事業者なんかは必死に高価なファイバーチャネルのSANシステムを、事業規模にかかわらず売り込んできます。もちろん高価だし、ハードウェアのサポート料金も高い。私がベンダーのセールスマンだったら、間違えなく Hyper-V をおすすめします。そのほうがお客様からの手離れはいいですし、彼らは高価なパッケージやハードウェアを沢山買ってくれるからです。何しろ SUSE Linux の無制限仮想化アクティベーションは僅か４万円ほどなのです。
もちろん、2008S/2012S の Hyper-V とはクライアント Hyper-V はチューニングが違うのよ、と言われればその通りなのですが、Hyper-V 3.0 は、メディアでは「滅茶苦茶に高機能高性能になってスケーラビリティと言ったら、そりゃもう何個の仮想CPUが使えて何TBのメモリが使えて最大何TBの仮想ディスクが使える」というカタログスペックを語る記事をよく見ます。
しかし彼らの記事はカタログスペックを記事にしただけで、実際に運用をしてみたわけではない。本当に１台のハードウェアで何台の仮想マシンが「運用に耐えられるか」と考えた場合、やはり Linux/Unix 系で動作する XEN や KVM, VMware などに軍配が上がりそうです。
何しろ「Hyper-V 遅い ディスクIO」などのキーワードで検索すると出てくる出てくる、運用者の嘆き。諦めて VMware に乗せ換えたとか、KVM に乗せ換えた事例がゴロゴロ出てきます。結局、SASディスクを諦めて、SSD-Raid に乗せ換えたら爆速に解決した（それって根本的に重大な問題じゃん）とか、いかに Hyper-V が金食い虫なのかの事例がボロボロ出ているのが実情の様です。
実際は「単機能をコンパクトに仮想化してアプライアンス化」することを考えれば、別に仮想ディスクなんて僅かで済んでしまいます。実際 SLES11 を導入してみましたが、僅か 512Mbのメモリと４Gの仮想ディスクでインストールできてしまいました。おそらくこの程度なら簡単な LAMP や DNS/DHCP として利用することには何の問題もないでしょう。
スナップショットも使えるようですが、これだけディスクIOが大きいと、スナップショットを取った後のマージ処理が怖そうです。
百歩譲ってＧＵＩの親切さ、使い易さは賞賛する価値はありますが、いかんせん 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 はライブマイグレーションを前提で考える必要がありそうです。１１９万円しますからね。二つ購入するのはちょっと勇気が必要です。
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 は低くないのか？
関連記事
■
[PR]
▲
by islandcenter
| 2013-01-29 16:24
| プライベートクラウド
|
Trackback
|
Comments(4)
1
