ちょっと古い内容ですが、Linux + XEN での VDI ホストを sysprep で作成する方法です。

SUSE Linux上で SYSPREPを利用したシンクライアントの配布手順


islandcenter.jp


Windows 7 XEN SUSE シンクライアント
[PR]
by islandcenter | 2013-07-14 00:37 | プライベートクラウド | Trackback | Comments(0)

SLES 11sp3 のリリースノートはこちらをご覧ください。

Release Notes for SUSE Linux Enterprise Server 11 Service Pack 3 (SP3)

一番大きな変更点はUEFI Secure Boot に対応したところですか。

その他はそれほど変わっていません。換わってばっかりの他のシステムより「変わらない正しさ」を感じます。

細かなカーネルの変更は以下のとおり

-SLES11sp2-

sles11:~ # uname -a
Linux sles11 3.0.13-0.27-xen #1 SMP Wed Feb 15 13:33:49 UTC 2012 (d73692b) x86_64 x86_64 x86_64 GNU/Linux
sles11:~ #
sles11:~ # cat /etc/SuSE-release
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 2
sles11:~ #


-SLES11sp3-

sles11:~ # uname -a
Linux sles11 3.0.76-0.11-xen #1 SMP Fri Jun 14 08:21:43 UTC 2013 (ccab990) x86_64 x86_64 x86_64 GNU/Linux
sles11:~ # cat /etc/SuSE-release
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 3
sles11:~ #


SUSE Linux Enterprise Server 11 の XEN ハイパーバイザー導入手順(PDF)を公開しています。それほど変わっていません。※ 7/12 一部修正追加しました。

SLESの安心は「大きな変化がない」にもかかわらず見えないところで改良しているところ。御不動様のような安定感、信頼性です。



islandcenter.jp


-Keyword-
Novell SUSE Linux XEN SLES11sp3 Virtulization How to setup
[PR]
by islandcenter | 2013-07-11 19:31 | SUSE | Trackback | Comments(0)

Suse.com より入り、プロダクトページへ行くと Novell.com のサイトにリダイレクトされます。

SUSE Linux Enterprise Server 11 SP3
[PR]
by islandcenter | 2013-07-10 16:05 | SUSE | Trackback | Comments(0)

この6、7年、SUSE+XEN という仮想化システムに携わり、かつLANの黎明期から従事してきた経験から、プライベートクラウドに必要なハードウェアや問題点をまとめてみました。突っ込みどころ満載なので、コメントいただけると幸いです。

-ディスクはケチるな-

まず、HDDの速度はケチってはいけません。# sar 1 -p コマンドで見ている限り、「遅い」と感じるのはほとんどディスクのIOです。できれば 15,000 rpm の 3.5inch SAS HDD の一番大きなサイズのものをRAID1 (二重)構成したものをお勧めします。安くても 7,200 rpm の SATA ディスクを使うとひどい目に逢います。できればRAID コントローラもお金を掛けたいところです。

もちろんサービスレベルと予算、規模、利用量の問題もあるので、必ずそうだとは言い切れないことは承知しています。

問題は SATA も SSD も、ハードウェアベンダーとしては「消耗品」扱いしている点です。

HP の場合はSSDの最大保障期間3年+アクセスバイト数によって保障期間が決まっています。

HP ProLiant用SSD、PCIe IOアクセラレータ製品の標準保証期間


特に MLC タイプの保障期間は短いようです。一般的には MLC より一桁値段が違う SLC タイプの方が長期利用できそうです。固定データのインフラ系サーバや、開発用で保存容量が必要なければ、DRAM をたっぷり乗せて RAMディスクを使った方が安そうですね。

Dell のストレージシステムも SATA ディスクは1年保障です。
壊れた時点でアウトだし、延長保障もなければ5年で償却したいサーバ向けのディスクではありません。

SSD の歴史はまだ短くサーバーでの実績もありません。「壊れることが前提」で構築すべきです。

一般的な(古い言い方で)「SCSI」 はタグ・キューイングの機能を持っており、SCSI をシリアル化した、SAS にもそのその機能は継続されています。
タグキューイングというのは、昔 NetWare 時代に有名になったエレベーターシーキングのようなものですね。とても長い歴史があります。エレベータは「行き先階を押したものの早いもの勝ち」ではなく、みんなが1階で「押された順番に関わらずランプのついた階には順番で止まる」というHDDシークを効率化するマルチタスクには必須の機能です。ヘッダの動きと円盤の動きを見て、リクエスト順ではなく、もっとも短い経路で拾ってくるセクタを優先する方法です。ランダムアクセスには絶大な威力を発揮します。

この機能は圧倒的にディスクそのもののマルチタスク性能に影響します。

ところがシングルタスクを基本とした ATA を基にした SATA にも Native Command Cueing という機能が実装されていますが、DMA コントローラの制御にいちいちCPUが関与しなければならないようで、「負荷が高くなりがち」になるようです。

Tagged Command Queuing英語版 Wikipedia


よく、SOHO や コンスーマ向けのNAS を真面目に「ファイルサーバー」と称しているお客様を見ますが、どこか勘違いしているようです。コストを掛けられないなら、バックアップを毎日取るなりの「人的コスト」をかけて欲しいものです。

本来は SSD を使ってみたいものですが、読み出し性能は良いとしても、書き込み性能に問題があればお勧めできないし、通常書き込み量に応じて保障期間が決まっているので、SSDは消耗品として割り切って仮想化システムのブートシステムとして構築すべきです。「いつ壊れても困らない」仮想イメージを保存して、定期的にHDDにバックアップするのが良いでしょう。どうせ3年しか使えない記憶装置です。

Linux システムなら6~10Gほどで十分ですから、停止から再起動までの時間も数分で済みます。困るのは Windows 7/2008 系です。システムだけで30G程度用意しないといけないので、バックアップ時間も停止時間も、用意するSSDの容量も考慮しなければなりません。もっとも Windows サーバーはパフォーマンスがよくないので、無理してSSDを使う必要はないというご意見もあります。どうせアイドリングしていても頻繁に細かな書き込みがあるのでSSD化はちょっと問題ありですね。

どっちにしても、同じ円盤の中にファイルコピーするより違うデバイスにコピーしたほうが性能がきっちり出ます。

SATAディスクはシーケンシャル書き込みには強いのですが、読み出し性能に問題がありそうなので、単純な「バックアップ用ファイルサーバー」として考えて良いでしょう。一日1回しか動かないシステムだとすれば、発熱もパフォーマンスもそれほど要求しません。

-意外と使わないCPU性能-

sar 1 -p コマンドを実行して観察していると、ほとんどのお客さんの仮想サーバーのCPUの利用率は 1% 以下です。つまりほとんど働いていない。情報系のシステムとはそんなものですね。タマに90% を割り込むことがありますが、ほとんど %iowait の時間です。つまり、どれだけ i//o が重要かがよくわかります。コア数が少ないと、コアを奪い合う %steal の量が増えます。安い SATA ディスクと貧弱なCPUを使った当所のテスト環境では如実に出てきます。

そもそもインフラ系のサーバーは、IO 性能より「あればいい」程度のサーバなのであまりリッチな環境は必要としません。DNS や ドメインコントローラがどれほど重要かと言っても、冗長性が重要で、性能ではありません。

ただし、コア数が多いとそれなりに「サーバを詰め込む」ことができるので、低電圧、低電源、多コアのハードウェアをお勧めしています。所詮ファイルサーバのIOはメモリの多寡に左右されますし、マザーボードを始めとしたIOのDMAクロック転送速度が問題となるので、同じマザーボードなら制御のためのCPU性能はあまり重要視されるものではありません。同じマザーボードなら「そこそこ早くて安くて電源食わない低クロック低発熱CPU」をお勧めしています。

-一番難しいクライアント仮想化-

クライアント仮想化、いわゆるシン・クライアントは、BYODのニーズともマッチし、ホットで一番悩む問題です。何しろ小さいファイルアクセスがガリガリとあり、GPU性能も必要で、軽い動作ならまだしも、ディープなバッチ処理もこなさなければなりません。

しかし非力なマシンやタブレットからも、強大なマシンパワーを使えるというメリットが出てきます。特にメディア系の時間がかかるエンコード処理だとか高度な画像処理なんかですね。もっとも最終的な処理は手元のハイエンドマシンで行う必要はあるでしょう。高解像度の処理をどうするかが今後の問題です。こうなるとやはりCP性能とディスク性能がモノを言うわけです。

大事なのは、ユーザのグルーピングです。ヘビーユーザなのかライトユーザなのかで構成を考えてみることです。レスポンスを重要視するか、バッチ処理を優先するかです。混在すると、色々問題が出てきそうです。

Windows7 sp1 では remoteFX の機能が搭載されました。これはサーバー側のGPUの機能で3Dグラフィックスを利用できる機能ですが、一般的な「サーバーハードウェア」はCUIや「映ればいい」程度のグラフィックス性能しか持ち合わせていません。逆にコンスーマ向けグリグリゲームマシンであれば高価なグラフィックスカードがモノを言います。私の手元の機材では XEN+Windows 2008 R2 環境でも Google Earth の 3D 描画がうまく動きました。これは AMD のCPUに内蔵されたGPUの性能のおかげです。

サーバにそこそこのGPUを追加して乗せた場合、ノマドワークやシンクライアントでのリモート3D機能も試してみたいところです。

-意外と進まないクライアントの 1Gbe 化-

かつて1時間にパッチケーブルを100本終端加工する職人の凄技というのを見たことがありますが、ケーブルのフロア敷設というのは結構面倒なものです。パイプに通線する際は裸線を配線してから終端をモジュラなりローゼット加工しなければなりません。モジュラーをつけた状態では床下やパイプ配線は不可能です。通線してから終端加工をします。

100Mbeの時代なら、まだ終端加工もマージンがありましたが、1Gbeの時代では、なかなか職人技を必要とします。CAT6以上のクラスになると単線の「撚り」をほどいて圧着するには素人ではまず無理です。シールドもぎりぎりまで残さなければなりません。何しろ数ミリ単位で加工が必要です。

私は壊れたCAT6のモジュラを自分で圧着して100Mしか出なかった時はショックでした。そのあたりのPCショップで売っているプラグや圧着工具では、まず1Gbeの速度は出ません。秋葉原の「愛三電気」の親父に「工具が違うんだよ」って怒られそうですね。「アカアオオレシロミドアオ...」とついに覚えられなかった素人配線ですが。ケーブルは導線の性能だけではありません。ローゼットやプラグのカシメのテクニックがモノを言います。職人技ですから工賃が高価になります。よく素人ブログで「自作ケーブル」の記事を見ますが、「繋がった」とヨロコンでいるだけで、性能までは評価されていないようです。

ということでデスクトップマシンもHUBも Gbe 化しているにも関わらず、床下配線はCAT5というところはまだ意外と多いようです。それほど高度な「職人さん」がいないということですね。引っ越したばかりのオフィスであればCAT6配線も発注できますが、10年前に引っ越したオフィスビルでは未だにCAT5クラスでしょう。

こういったところでサーバルーム内でファイルサーバと、工場加工出荷されたケーブルで直接配線されているシン・クライアントは威力を発揮します。

ということで、ほとんどの場合フル1Geという恵まれた状況はなかなかなく、途中に遅いケーブルやHUBが介在するわけですね。

ただし、画面転送の速度が遅いと利用者側はいらつくでえしょう。目の前のマシンならリブートしてしまえば良い話なのですが、リモートマシンは簡単にリブートというわけにはいかないのですね。Windows を使う以上、「使っていると重くなる」のは必然的なことで、定期的なバックアップや再起動といった処理が必要となるか、管理者がクレームを把握して再起動するなどの処理が重要になります。

今はBYODの世の中ですから、タブレットからちょっとこの処理がをしたいとかと言ったニーズが増えることも考慮しなければなりません。


ということでSSD は仮想環境で実力を出すか SUSE+XEN で検証してみました。



islandcenter.jp
[PR]
by islandcenter | 2013-07-07 16:00 | Trackback | Comments(0)

サーバから取り除いたディスクを完全に消去するには dd コマンドでランダムな数字を書き込むことが一番確実です。

Novell Open Enterprise Server(OES) には Data Shredding という属性があり、
http://www.novell.com/documentation/oes11/stor_nss_lx/data/bqq4w37.html
この機能を有効にすれば削除ファイルを自動的にランダムな数字でうめあわせてくれます。廃棄期限が来たサーバであれば、この属性を付けて Purge を行えば、自動的にファイルのシュレッディングを行ってくれるようです。
a0056607_21173845.jpg

素の SUSE Linux ではこの機能はありません。

例えば、現在の開き領域のほぼ全てのブロックに巨大なランダムファイルを作って空き領域を埋め尽くすというのも一つの方法です。

-dd による方法-

ここでは 80Gb の空きを全て /dev/randam で埋めてみました。もちろん、廃棄するディスクをつないで of=/dev/sdX としてもいいわけですが....

sles11:~/tmp # dd if=/dev/random of=deleteme.file bs=1M count=80000 iflag=fullblock

^C4374+0 records in <--- あまりにも時間がかかりすぎるので中止
4374+0 records out
4586471424 bytes (4.6 GB) copied, 3141.68 s, 1.5 MB/s

sles11:~/tmp # ls -l
total 4483364
-rw-r--r-- 1 root root 4586471424 Aug 23 12:06 deleteme.file
sles11:~/tmp #


30分くらいかけてやっと4Gバイトほど埋めただけです。もっとも dd で /dev/randam で埋め尽くすことがHDDを下取りに出す場合一番推奨されることなのですが、(アメリカ国防省ではこの処理を三度やるのがルールらしい)いかにも時間がかかりすぎます。まぁこれだけやればどれほどのフォレンジック調査をしてもデータの復旧は不可能でしょう。

-Shred コマンド-

shred コマンドはディスク全体ではなく、「ファイル」を完全削除するのに最適な方法です。


sles11:~/tmp # ls -l
total 3249728
-rwxr--r-- 1 root root 3324467200 Aug 23 10:47 test.file
sles11:~/tmp # shred --help
Usage: shred [OPTION]... FILE...
Overwrite the specified FILE(s) repeatedly, in order to make it harder
for even very expensive hardware probing to recover the data.

Mandatory arguments to long options are mandatory for short options too.
-f, --force change permissions to allow writing if necessary
-n, --iterations=N overwrite N times instead of the default (3)
--random-source=FILE get random bytes from FILE
-s, --size=N shred this many bytes (suffixes like K, M, G accepted)
-u, --remove truncate and remove file after overwriting
-v, --verbose show progress
-x, --exact do not round file sizes up to the next full block;
this is the default for non-regular files
-z, --zero add a final overwrite with zeros to hide shredding
--help display this help and exit
--version output version information and exit

If FILE is -, shred standard output.

: 中略



ということなので -u (削除) -n 3(3回) -z (最後はNull書き) -v (進捗を表示) で約3.3Gのファイルを「シュレッダ」にかけてみました。


sles11:~/tmp #
sles11:~/tmp # shred -u -n 3 -z -v test.file
shred: test.file: pass 1/4 (random)...
shred: test.file: pass 1/4 (random)...2.9GiB/3.1GiB 94%
shred: test.file: pass 1/4 (random)...3.0GiB/3.1GiB 96%
shred: test.file: pass 1/4 (random)...3.1GiB/3.1GiB 100%
shred: test.file: pass 2/4 (random)...
shred: test.file: pass 3/4 (random)...
shred: test.file: pass 4/4 (000000)...
shred: test.file: removing
shred: test.file: renamed to 000000000
shred: 000000000: renamed to 00000000
shred: 00000000: renamed to 0000000
shred: 0000000: renamed to 000000
shred: 000000: renamed to 00000
shred: 00000: renamed to 0000
shred: 0000: renamed to 000
shred: 000: renamed to 00
shred: 00: renamed to 0
shred: test.file: removed
sles11:~/tmp #


3回目まではランダムな数字で産めて、最後に Null 書きして痕跡も消します。処理は数分で終わりました。

※追記 dd の進捗状態を調べることができます。こちらをご覧ください。
dd で進捗状態を確認するには
感触では dd if=/dev/random ... を使うより shred コマンドの方が早いという感じがしました。
以上追記終わり。


「削除証明書」を出すには dd でランダム埋めをするしかありませんが、ハイパーバイザーを使っている場合、仮想マシンのディスクイメージを shred するだけで、重要なデータを完全に破壊することが短時間でできるわけです。(もっともバックアップはどうするという問題もあるわけですが)

個人的には一番面倒のない「ディスクをバラしてプラッタを割る」のが一番確実だとおもうのですが、その上、HDDの外部のアルミ筐体とコントローラーボードを分別して処理業者に出せば喜ばれるのかなぁ。まぁそれはわかりませんが、捨てるのはもったいない、しリサイクルして欲しいな、という気持ちであれば、このような方法もありだということです。中にはアームを動かす強力な磁石があるので、子供の「夏休みの宿題」に使えるかもしれません。

また、なんらかの形でOSを起動してもOSが認識しない領域にデータが残っているじゃないか、だからハードウェア機器で完全消去するのがいいとおっしゃる方もいらっしゃいますが、一般的にそこまで必要かどうかは読者の皆さんのご判断に任せます。

実際にクラウドでレンタルサーバーなどを使っている場合、どのような形で運営事業者の中で扱われているかは不明です。「これはまずい」というデータがあれば「シュレッダにかけて解約する」こともかんがえておかなければならないと思います。



islandcenter.jp
[PR]
by islandcenter | 2013-07-07 11:01 | Trackback | Comments(0)