カテゴリ:プライベートクラウド( 68 )

今回、HP D2D200i 仮想オートローダー(iSCSI モデル) と NetVault を使った、”プライベートクラウド”のバックアップシステムを検証しました。

HP StorageWorks D2D Backup System

a0056607_13433221.jpg


NetVault 8.51

a0056607_1347524.jpg


引き金の軽い D2D 2000i
まず、HD の D2D iSCSI モデルは導入の気安さが最大の特徴です。何しろ iSCSI 接続なので、ケーブルの取り回し、取り付け、引き抜きが楽です。iSCSI さえ設定してしまえば、バックアップソフトウェアからはオートローダーとして見えるため、XEN 仮想マシンの Domain-U からも利用できるという優れものです。

物理的に動作するのはハードディスクとファンだけですから、非常に安価です。おそらく故障も少ないでしょう。たとえ故障しても、CPU装置を停止せず、iSCSI サービスから切り離せば簡単に交換できます。気を使う光ケーブルも必要としません。RJ45のモジュラケーブルでつなぐだけです。

たいていのオートローダーでは、3年の運用期間の間に必ず一度は壊れます。これはわたくしの経験上の話です。ロボットのメカ部分、ドライブ、高速でスピンしながら薄ぺらなテープを巻き取るリール。どこが壊れても仕方がないわけですから、かなり高額な保守料金を支払って運用するしかありません。しかも最新のDLTメディアは1万円以上するわけです。運用担当者にとって故障交換はたいてい一日がかりの仕事になります。DLTメディア2ダース分で購入できるD2Dはコストパフォーマンスの高い製品です。

引き金の軽さも魅力の一つです。

操作ひとつで簡単に全てのドライブをフォーマットしたりイジェクトすることが出来ます。テープのヘッド合わせもないわけですから、容易にメディアをスキャンしたり、リストアを開始することが出来ます。あの「ガチャコンガチャガチャ、キューン!」という音も出さずに、アクティブになれば、即効で利用開始できます。

逆に引き金の軽さと、メディア交換が出来ない点がデメリットとなります。メディアは固定ディスクなので「取り出して保管」ができないという点です。引き金ひとつで、簡単に上書きできてしまいます。重要なデータはやはり換装可能なDLTテープなどとの組み合わせが必要となります。金庫にしまったテープをフォーマットするのは不可能なわけですね。

NetVault

Novell OES2 に対応したバックアップソフトとしては一番お勧めします。販売店のノックスさんのページ XEN 上の Domain-U でも Domain-0 でも動作し、確実に OES2 の NSS ボリュームをバックアップ、リストアします。

ただし、Novell Target Server Agent (TSA) に対応しているわけではないため、eDirectory のバックアップは出来ません。NSS のボリュームにあるファイル属性、トラスティなどは保護されます。

その他の大手に買収されたバックアップソフトウェアブランドと違い、専業メーカーである BakBone の製品なので、バックアップ運用というものを良く考えて設計されています。特に旧バージョンや異機種との互換性を不具合も含めて一通り検証しているところが素晴らしいと思います。他の製品では、異なるバージョンのオプション製品との互換性は一切保障しないというメーカーもある中で、この姿勢は見習うべきでしょう。当然、運用中のシステムの中には古いバックアップ用のエージェントもあり、マイグレーションが必要なので、旧バージョンのサポートは重要です。

唯一残念なところは、 GUI 上からNSSボリュームの日本語が文字化けされて表示される部分です。これは、元来が UNIX 系のシステムから育ったソフトウェアなので、努力してもらいたい部分です。しかし、ファイルシステム上の日本語ファイルは正しくバックアップ/リストアできました。 GUI 操作の貧弱性は強く感じます。基本的に永久アーカイブすることがコンセプトであるため、メディアのフォーマットなどは、GUI上で手動で行う必要があります。
その代わり、コマンドラインでの操作が豊富なので、メディアのフォーマットやメディア管理を容易にシェルで実行することが出来ます。


-速度-

今回は、D2D 2000i とXEN Domain-U として仮想化されている OES2 の NSS ボリューム( やはり iSCSI ディスク) で NetVault でバックアップとリストアをテストしてみました。平均 40Mb/sec 程度の速度なので、分速 2~3 Gb/min の速度が出ているようです。これがテスト環境ではなく、実際の運用の現場での速度なので、必要十分と考えています。

-KeyWord-

Novell, OES2, バックアップ, NSS, NetVault, iSCSI, Autoloader, お勧め, 推薦

そのほかの情報は Visit Mysite
[PR]
by islandcenter | 2010-08-26 14:11 | プライベートクラウド | Trackback | Comments(0)

NetVault で利用するオートローダーのメディアを、バックアップ前に初期化するシェルです。


English Transrate this page

ただし、 JapaneseEUC でデバイスの設定を行うと Autoloader の Device Name が "doraibe 1(ドライブ1)"とわざわざ日本語になってしまい、 -drive の指定を正しく行うことが出来ません。(全く余計なローカライズだ!)

a0056607_10423220.jpg


# nvconfigurator > General Langage Settings > English

に変えてから、Autoloader や Device の設定を行います。

a0056607_1047435.jpg


Autoloader の設定を行う場合、デフォルトでは (HP 1x8 Autoloader xxxx) などの長い名前がデフォルトになります。間に空白が入る場合は "name" ダブルクォーテーションで括る必要があるため、"LOADER1" のようなシンプルな名前にします。上の絵では "D2D" というシンプルな名前にしました。 Autoloader 内部のデバイスは、システムにより "DRIVE 1" と命名されました。

-sample script-

/usr/netvault/util/nvdevice -eject -drive "DRIVE 1"
sleep 5
/usr/netvault/util/nvblankmedia -servername myserver -medialabel "1MON"
sleep 5
/usr/netvault/util/nvdevice -eject -drive "DRIVE 1"
sleep 5
/usr/netvault/util/nvlabelmedia -servername myserver -slotspec D2D::1 -newlabelname "1MON"
sleep 5
/usr/netvault/util/nvdevice -eject -drive "DRIVE 1"

1) "DRIVE 1" にメディアがあれば、とにかく eject します。
2) スロットにある "1MON" というメディアがあれば、Blank にします。
4) "DRIVE 1" に Blank Media が残っているため、Eject して Home Posision (Slot1) に戻します。
5) Library Name: "D2D" の Slotspec:1 にあるブランクメディアを newlabelname "1MON" に書き直します。
6) ”DRIVE 1” のメディアを排出します。

7) 各操作の間は 5 sec の sleep を入れます。連続すると Device Busy となります。ここでは HP D2D2000i 仮想 Autoloader なので 5 sec 程度で十分です。物理的な DLT ロボットを使う Autoloader の場合は 120 sec 程度の間隔が必要です。また、物理的な DAS 接続 DLT デバイスも同様に利用できますが、 Blank や Labelmedia の操作に時間がかかるため 60sec 程度の sleep を入れると良いでしょう。


このスクリプトを各バックアップジョブの数時間前に cron 実行しておくことで、メディアの Blank/ Reuse が容易に実行できます。


-単体ドライブの場合 in case Single Drive-

! /bin/sh
SERVERNAME=mybackup

/usr/netvault/util/nvblankmedia -servername $SERVERNAME -medialabel "7SUN"
sleep 15
/usr/netvault/util/nvlabelmedia -servername $SERVERNAME -medialabel "BLANK" -newlabelname "7SUN"

1) "7SUN" というラベルを "BLANK"にします。
2) "BLANK"というラベルを "7SUN" という名前の新しいメディア名に変更します。

1) で失敗した場合はうまく動作しません。ただし、挿入されたメディアが "BLANK"だった場合は1) で Fail しますが、2) でラベルが付けられます。

※ JapaneseEUC で動作している場合は "BLANK" が "ぶらんく(buranku)" となるため、正常には動作しません。


-keyword-

Novell SUSE Linux Enterprise Server, SLES11, OES2, NetVault, Backbone, NVBU, eject drive,

そのほかの情報は Visit Mysite
[PR]
by islandcenter | 2010-08-23 18:15 | プライベートクラウド | Trackback | Comments(0)

仮想化を支える3大ソフトウェア群


1)プロプラエタリ、クローズソフトウェア

 VMware, Hyper-V など

メリット
 - 顧客は高い金を払っているため文句が言える、当然トラブルに対する改善提案も受けられる。
 - いくら払ったかはっきりしているため、費用対効果が明確である。
デメリット
- サポート料込みだけどライセンス料が高い
- ライセンスリソースをプール化できない
- 不良資産、固定資産化しやすい

 大企業や大手SIベンダーがクラウドシステムを作るには適当なシステムだと思います。実績もある(ないのもあるけど)。一番問題なのは、本来、IT資産をプール化してスケールアウト、あるいはスケールダウンを試みる場合、高額なライセンス料金に縛られて、簡単に仮想マシンを構築できないところです。たとえサーバーが100台あって、これをハードウェアプール化しても、将来このハードウェアプールを50台に減らそうにも、余ったCPUソケットを増設してスケールアップしようとしてもライセンスのプールがない限り不可能なのですね。たとえ50台に減らしてもライセンス料は安くはならない。
しかも値段が高いから、利用企業としては、ハードウェアと一緒にリースしたり、固定資産化させなければならない。したがってサービスイン、サービスアウト(という言葉があるかどうかは?)が簡単にできないため、当然経営側もこれだけ巨額な出費に慎重になります。このシステム5年以上かけて人材育成から利用するというしっかりした計画が必要です。

 しかもライセンス上の「マル秘スイッチ」みたいなフラグがあるわけで、ライセンスコードを入れないとオンにならない機能なんてのがついている(と想像できる)何しろオープンソースではないので、そういった「ヒミツ」の機能はいくらでも仕込むことができるのです。

2)商用オープンソフトウェア

 SUSE, Citrix, OracleVM, RedHat などさまざまなオープンソースを商用サポートするメーカーの製品があります。

メリット
- 評価からサブスクリプション購入まで自由にできる
- ソースが公開されているため、ライセンスの制限に嘘が付けない。
- SUSE の場合、単年のサブスクリプションライセンスから3年のプレミアムサービスがあり、不良資産化しにくい
- 技術力のあるなしにかかわらず、さまざまな契約が行える。
- 何しろ安い(SLES11 の場合は最低4万円台からだ)しライセンスも柔軟

デメリット
- 何しろ SUSE の場合、1台32ソケットという現代社会ではあって無いようなライセンス体系なので、非常に自由に仮想システムが作れてしまう。ネットワークが仮想マシンだらけになってしまうことが最大の欠点。
- サブスクリプションやサービスが年間だったりスポットだったりするわけなので、IT予算が予算化しづらい。
- 管理ツールは期待できない

 ということで大手から中小まで使いやすいことは使いやすい。たとえプロジェクトが半年でポシャッてしまっても1年のサブスクリプションライセンスであれば、捨ててしまってもかまわない。しかもサブスクリプションを登録すれば、年間単位でパッチの提供も受けられるし、プレミアムサービスを購入すれば、天才と言われなくても、普通のレベルのサポートを期待できる。2年目以降ももしスケールアウトが必要になればサービスを継ぎ足して購入すればよい。その代わり、こういった商用オープンソースにはさまざまな中途半端な管理ツールがついてきて、ほとんど役に立たないのが現実です。だからあまり複雑な大規模システムにはむいていないという面もあるし、いいオープンソースの管理ツールが出てくれば、実装できるわけですから、期待はできるわけです。私のようなヘボな零細事業者がお客に提案できるのはこの程度のシステムしかありません。非IT関連のお客さんで、あまり「金がなさそうな」ところにプライベートクラウドを売り込むには実に優れていると思います。

3)非商用オープンソフトウェア

Ubuntu や CentOS, FreeBSD などフリーのソフトウェアを使った場合。

メリット
- 何しろライセンスがかからないのでライセンスというプールは無制限である。
- サービスイン、サービスアウトが容易
- ソフトウェアのライセンス、資産管理が不要

デメリット
- タダより高くつくことがある

 何しろ技術力が必要である。行き詰まって経営側から「何とかしろ」といわれた以上、自分で何とかしなければならない。情報もコミュニティ頼りだ。もし、「FreeBSD でやってくれ」と言われたら私としてはかなりのリスクを含めた価格を提示しなければならないでしょう。つまり、経営側からすると、システムの費用をほとんど人月で管理するわけで、ITにかけるコストを計るためのゲージがヒトの評価しかないことがネックになります。当然システムも属人化します。

 したがって非IT企業にはお勧めできない。自社で開発者を抱えたり、いかに安価でITサービスを提供するかが目的であれば最適な判断かもしれない。私には自信がないけど。ウワサによればYahooは FreeBSD, はてなは XEN を使っているらしいけど、そういった大規模なITサービスには無料のオープンソースを使いこなす技術、基盤があるということですね。リースが切れるからこの古い FreeBSD のシステムを何とかしてくれ、といわれた時ははっきり言ってお手上げでした。そういう残骸がたくさん残っているIT企業もたくさんあるんだろうなという気がします。

RedHat+KVM で比べた場合の SUSE+XEN のメリット

 私の公開している情報にはさまざまな条件でご訪問していただくリーダーさんがいます。 "XEN+USB, XEN+CDROM XEN+起動できない, XEN+接続できない”、まぁそういった検索条件です。
この XEN という文字を KVM に置き換えてぐぐってほしい。まず見つかるのはキーボード切替え装置(KVM)に関する情報である。KVMというオープンソース仮想化技術の最悪な点は「名前が悪い」のです。技術そのものは大変優れたものであるということは想像できるのだけれど、今のところ RedHat だけが標準で採用しているわけで、技術の蓄積や経験が不足している。おまけに KVM について調べようとすると、ほとんどがキーボード切り替えスイッチの情報しか見当たらない。

KVMは名前で損している。このまままでは仮想化システムの本筋になれるとは思っていません。XENを捨てた RedHat は名前を変えることが大事だと思いますよ。


コンピュータはクロック以上の性能は出ない

 いくらコア数が多くても、コンピュータはクロック以上の性能は出ません。まして、コンパイラやミドルウェアが数年前に開発されたものが主流で当時はシングルコアだったため、マルチコアに最適化されたコードが搭載されているはずがないのです。私のような単細胞、シングルタスクな人間には想像できないのですが、コア数を目いっぱい使ったソフトウェアを使いこなすには相当な発想、プログラミング技術が必要だと思います。

 巨大な仮想イメージをバックアップ取ろうとして tar 圧縮していたのですが、ボーっと観測していたら8コアのうち、実際に動いているのは1コアだけでした。そりゃカーネルはプロセッサを効率よく利用しようとさまざまなジョブを振り分けるわけですから、8コアが無駄だとは思いませんが、ひとつのジョブが8分かかるところ、8コアにしたからといって1分で終わるわけではないのですね。じゃぁ8つのジョブが8分で終わるんじゃないの? という疑問があるのですが、怖くてまだ試していません。たぶんディスクIOでそれほどのパワーは出ないと予測しています。

 メモリもCPUもパワーが出てきている割には、マルチコアを生かすチップセットというものが無いような気がします。サーバーの外のケーブル、HDDはチューニングのし甲斐というものがあるのですが、チップセットはチューニングできません。全てオンメモリで処理してしまおうと思っても、意外とパフォーマンスに恵まれないのはその辺もあるかなと思います。

 もちろん、改善点はいくつでもあるでしょう。スイッチングHUBはできるだけ良いものを、ケーブルもカテゴリ6以上の短いものを、SATA読み込みは遅いのでSAS-RAIDを選ぶとか、読み込みが多いところはSSDを使うとか工夫のしかたはあるのでしょうが、いかんせんそこまで考えると、予算も足りないし、予測していた程度のパフォーマンスが出なくてがっかりするのも嫌で仕様がありません。これだけは、サーバーメーカーさん工夫していい装置を出してよねと考えています。

 ついでにHDDですが、やっぱり3.5インチには敵わないなと思っています。スペースや音、電力では2.5インチに分があるのですが、いくら消費電力が半分でも、台数を倍積むとそれだけ電力も発熱も出てきます。しかも回転数が1万回転でハイエンドだと、やっぱり3.5インチのほうが明らかに使い勝手はよいように思います。厳密にアクセススピードやベンチマークを取っているわけではないのでご了解ください。

 また、SATAドライブを使ったNASなどがありますが、あれはあくまでもDLTに変わるバックアップメディアだと割り切った方がよさそうです。SAS-RAIDだと、壊れたディスクを自動的に再構築してくれる機能は普通にありますが、SATAのRAID1とかは、単にメインのディスクが壊れたときの単純なバックアップなので、あればいい程度に考えたほうがいいでしょう。動きがおかしくなって初めて「壊れていた」ことに気がつくわけです。NTFSでフォーマットしたSATAのディスクは明らかにランクが落ちるLinuxマシンより読み出し速度が遅いようです。書き込みは普通OSがバッファになるので、あまり意識はないのですが、読み出し速度は明らかにSASに軍配が上がります。Windows Storage Server 搭載SATA-NASなんてのもあります。コンソールつなげれば立派な Windows の画面ですが、基本的には NAS の機能しかついていません。じゃないとあんな安価なライセンスで売れませんからね。もっともそういう結果が言えるのは、サーバー室で暇なあまりコンソールばっかり見ている結果なのですけど。ただしSATAは消費電力を下げることができる点は評価していいと思います。

侮れないGbE

 GbEは1Gしか出ないし、FbEなら3Gとか6Gとか出るようです。確かに何百台とある巨大なデータセンターなら、これくらい投資するのが当たり前のようなところがあるのですが、たいていの中小システムはそんな巨大な予算は組めません。ただ、以外に同じディスクの中でコピーペーストするより、サーバにペーストするほうがスピードが速いということはよく感じます。つまり1対1では、まだディスクの転送速度に GbE なら余裕があると考えてもいいと思っています。・単純なシステムで構築するのであれば、ストレージに光ファイバを入れる必要はないなと思います。SAS なら 6Gb とか言いますが、きらきらした円盤から読み出せる速度がそれだけ速いという意味ではないのですね。
 もっとも10GbEも結構世の中に出ていますが、光ファイバを前提としたものが多く、メタル線を使うものはまだ少ないのが残念ですね。NICで8万円くらい、HUBは100万を超えます。ポート単価が1万円台になると急激に普及すると予測します。最近のNICで侮れないのはiSCSIのブート機能がついていることです。iSCSI ブートができると、実質サーバーにはディスクは不要なんですね。小型のシステムだったら1Uで4つのCPUユニットと共有電源があり、それぞれデュアルソケット、メモリ8バンク、2つの Ethernet と管理ポート、RJ45のコンソールポート、あとUSBが二つぐらいがあれば使えるわけですから、「起動しっぱなし」のシステムには非常に有効かもしれません。この1Uのラックの中に30個くらいの仮想マシンが動いているとしたら、ちょっと痛快です。

visite my site
[PR]
by islandcenter | 2010-05-21 03:14 | プライベートクラウド | Trackback | Comments(0)

若い配線専門のエンジニアと話したことがあります。彼は新入社員教育の時代に1時間に60本のパッチケーブルを作ったことがあり、

「あの記録は自分はもう敗れないなぁ」

とおっしゃっていました。そう言いつつ、目の前には大量のパッチケーブルを「製造」しています。単純に1時間に60本というと1分で1本、両端処理ですから1分で2箇所の皮むき、プラグの装着、カシメ、通電チェックを行うわけです。雑談ついでなのですが、より線を並べる作業と通電チェック以外はほとんど手元を見ていません。まるで指先だけでより線の色がわかるような繊細な動きでした。


まだ100BASE時代のことなので、当たり前の仕事かもしれません。

Gigabit の時代になって、ケーブルにも繊細さが要求されるようになりました。ということで、所内の主な機器間を CAT7 (カテゴリ7)のケーブルで配線してみました。小さな字で 10Gbase-T 対応であることが書かれています。

プラグも薄い金属皮膜があります。

a0056607_2175639.jpg


一般に 1Gbps であれば、CAT5e で十分だという意見がありますが、本当にそうなのか、ケーブルの品質で転送速度が変わるのかということを試してみました。


ということで2台の samba サーバ間で Windows クライアントから大量のデータを転送したときの状態です。

a0056607_2059285.jpg


この仕事は長いのですが、1Gbps の帯域をほぼ 100% 使い切る状況は見たことがありません。客先で 50% で張り付いているのはたまに見ますが、通常は12% から 25% 程度なので、これだけ長い間 100% 近い数字を出しているのは初めて見ました。

a0056607_211664.gif


大体、最低 40Mb/s から60Mb/s 程度の速度がでます。数十Gバイトのデータ転送が数分で完了してしまうスピードには、初めてターボ車に乗ったときのようなショックがあります。もっともこの速度は SUSE Linux + Samba 間の転送であり、Windows からのローカル転送はこの半分程度の速度が出れば良いようです。

--
ということで、仮想化システムのボトルネックはディスクIOとネットワークIOだと言われます。最近8コアや12コアのCPUもサンプル出荷されている時代です。このクラスであれば、数台の仮想マシンを動かしても十分なパフォーマンスをだします。クロックがあがらない時代、マルチコア化が今の流れなので、メモリとその周辺のチップセットの性能も重要になります。ただ、これらの性能はハードウェア性能なので、自分たちで改善することができません。

唯一見直す一番簡単なポイントがあるとすれば、サーバーとHUBとの間の通信ケーブルの品質は問題ないかということでしょう。パッチケーブルが足りないからと、ジャンクボックスから取り出した古いケーブルを使っていては十分なパフォーマンスは出ません。
[PR]
by islandcenter | 2010-05-05 21:13 | プライベートクラウド | Trackback | Comments(0)

Transrate English

PowerChute Business Edition 8.0.1最新対応表

小さく書かれていますね。

※Hyper-Vが有効になっている場合、または、VMware ServerもしくはVMware Workstation等のVMware Serverを使用するVMwareアプリケーションがインストールされている場合は、エージェントおよびサーバ・コンポーネントをインストールすることはできません。また、先にPCBEのコンポーネントがインストールされていた場合には、エージェントおよびサーバ・コンポーネントのサービスは強制的に停止され、開始することはできません。

Windows 2000 R2 x64 Hyper-V 環境では Power Chute Bussieness Edition (PCBE) は動かないそうです。つまり Hyper-V では APC 製のUPSは動かないということらしいです。

まぁ APC の Smart UPS がデファクトというわけではありませんが、 Hyper-V は生のハードウェアで動かすわけですから、UPSを使った自動シャットダウンを組み込んでおかなければならないわけです。そうでなければ、サーバールーム全体を無停電化するしか仕方がないと。

Novell SUSE Linux Enterprise Server (SLES) を使った仮想化の場合、パッケージの中にオープンソースの apcupsd が入っていますし、仮想化カーネルでも問題なく動きます。

こういった情報を日本語で探して見当たらないということはやっぱり Windows 2008 R2 の Hyper-V で仮想化するというニーズ自体が非常に少なく、事例がないということを感じさせてくれます。

また、PCBE 8.01 を C: ドライブ以外にインストールすると

a0056607_0252464.jpg


「エージェントサービスのインストール時にエラーが発生しました」となり、セットアップは「完了」してくれるのですが、全くサービスが動いてくれません。これは PCBE が32ビット版で、前提として C:\Program Files(x86)にインストールされることが前提だからのようです。別に PCBE はどこにインストールしてもかまわないのですが、 Windows 2008 R2 が32ビットのインストーラだと認識すると、勝手に C:\Program Files(x86) にインストールしてしまおうとして、アプリケーションのインストール先とは違うディレクトリにサービスをインストールするという、すごい「仕様」によるものです。

だから、ほかのサードパーティのソフトウェアでも間違えて D:\app などを指定してインストールするととんでもない泥沼にはまり込むことになります。つまり Windows 2008 R2 なら、全部C:ドライブにして、データもアプリケーションも同じパーティションにインストールしないと動かないものが相当あるということでしょうか。同じことが Windows 7 の x64 にもあるわけです。まだまだ Windows は奥が深い、というかどんどん深みにはまっていくのがよくわかります。

ということで、まだまだ Windows 2008 R2 x64 が本格的に利用に耐えるようなレベルにあるとはとても思えないことを感じさせてくれました。

PowerChute Network Shutdown v3.0 Enterprise Edition なら動くというご指摘ありがとうございます。
でもこれ、普通のシリアルポートで動くのかなぁ? UPSのカスケードスロットも埋まっているし...電源切れてHUBも止まったら、やっぱりシリアルポートが確実なんですけど。

-Keyword-

Windows 2008 R2 APC PCBE Agent Novell SUSE SLES APCUPSD Citrix VMware 仮想化、無停電電源装置

My Website
[PR]
by islandcenter | 2010-04-17 22:41 | プライベートクラウド | Trackback | Comments(3)

Windows 2000 登場の頃、Sysprep という便利な機能があり、みなさん熱心に勉強したものですが、最近は聞きません。小型PCサーバの場合、プリインストールという選択肢があること、PCの進歩が早く、Sysprep で用意したPCをばら撒くというコンセプト自体があまり注目されなかったという点があるのでしょうか。また、ディスクサイズが大きくなり、 W2K 登場の頃の CDROM 1枚で収まるイメージというのも現実的ではなくなったということもあります。もっともイメージ配信サーバなどがあれば別です。

しかし、仮想環境で、素早く新しい仮想マシンを準備しようと思えば、 Sysprep は実にいい機能を果たしてくれます。ということで、Windows 2003/XP をNovell Suse Linux + XEN で仮想化する場合を前提として、SYsprep の勉強をし直しました。

今の Windows 2008/7 系では DISM というもっと便利なツールがあるようです。

導入の時期も別々で、しかもプリインストール、月に数回しか使わないデスクトップPCベースの「サーバハードウェア」これを支える小さなUPS,貧弱な SATA Raid など、これらの小規模な場所と電気を食う「サーバ」は24時間働く必要のない中小企業のこれらの会計や給与計算などのシステムなので良い仮想化ターゲットです。

-準備-

まず、基本となる Windows のイメージを YaST > VM-Manager から New Machine を Create します。

sysprep は WindowsCD:\support\tools\deploy.cab にあります。この deploy.cab を解凍して、C:ドライブの任意の場所、ここでは C:\Deploy とします、に解凍しておきます。

イメージ作成直後は CD-ROM:i386 ディレクトリもあるので、いつ必要になるかわかりませんから、コピーしておきます。Novell Virtual Driver Machine Pack - VMDP もコピーしておきます。

ここまでできたら

> C:\Deploy\setupmgr.exe を起動します。

a0056607_12462934.gif


Sysprep に必要な Sysprep.inf を作成するレスポンスファイルを作成します。導入時の会社名、ライセンスキー、ネットワークの設定、Administrator のパスワードを指定できます。

ネットワークの設定は「カスタムコンポーネント」を「削除」しておいた方がうまく行くようです。
a0056607_1254176.gif


最後まで設定が終わったら、 sysprep.inf を「保存」して、「終了」ボタンがないので「キャンセル」して終わります。

この状態から C:\Deploy\Sysprep.exe を起動します。

a0056607_12572588.gif


「再シール」ボタンを押すと、指定した方法、ここでは「シャットダウン」が実行されます。Sysprep はインストールしてある SID などの情報を削除して、「クリーンアップ」してシャットダウンします。

ここでできた sysprep イメージを必要な台数分だけ /var/lib/xen/images/My-Vmachine/My-Vmachine.disk0 にコピーします。

あとは YaST > Virtual Machine Manager から Create Virtual Machine > I have a disk Images .... の手順に従って、仮想マシンを次々に作成するだけです。

-注意点-

1) Novell Virtual Machine Driver Pack は仮想マシンが出来上がった後に導入します。自動認識するドライバではないため、sysprep する以前に導入すると、ミニセットアップが起動できなくなります。また別なエントリで書きますが、VMDP を導入した後、追加したディスクが認識できないトラブルがあります。

2) OEM ライセンスはハードウェアに紐付けされているため、利用できません。企業向けライセンスが必要です。

-Key Word-

Novell SUSE Linux SLES 11 XEN Sysprep Windows 仮想化

Visit My Site
[PR]
by islandcenter | 2010-02-27 12:50 | プライベートクラウド | Trackback | Comments(0)

Novell SUSE Linux Enteprise Server 11 で一番気に入っている機能が、XEN 仮想化システムの設定が強化された点です。これまでは、仮想化ブリッジを設定してスクリプトファイルをおまじないのように書き換えて複数ポートを認識させる必要がありました。 SLES 11 からは、この機能がインストール時から YaST で簡単に設定して、仮想化システムにも複数のNICを簡単に認識させることができます。

XEN Host Domain-U のネットワーク設定

一旦 XEN カーネルで起動するとネットワーク設定は変更できないので、ブート時に通常のカーネルで起動します。 または、インストールする際にネットワーク設定をする場合のポイントです。YaST > Network Device を確認しましょう。物理ネットワークポートは Not Configured として、システムの内部ブリッジに IP アドレスの設定を行います。このブリッジ br0, br1 はそれぞれ XEN の Domain-U を作成する際にネットワークポートとして認識させることができます。

a0056607_1402394.gif


XEN カーネルで起動して YaST > VM Manager から、新規仮想マシンを作成します。ネットワークの設定から、Add ボタンを押すと、 br0, br1 がそれぞれ認識されるため、必要に応じて、どちらか一方、または両方の仮想ブリッジを設定します。 Windows の場合は特に MAC アドレスを任意にしても構いませんが SLES を仮想化する場合は、 MAC アドレスを固定した方が良いようです。

a0056607_1405763.gif


これで二つの NIC を仮想マシン Domain-U に認識させることができます。

a0056607_140431.gif


仮想化元年と言われた昨年から始まり、システム仮想化から、ディスクストレージの仮想化が次のレベルとして考えられます。一般的なサーバーハードウェアは2ポート以上のNICを持つものが多いので、IP-SAN との組み合わせを使えば、安価にシステム仮想化、ストレージ、記憶装置の仮想化を行うことができます。

-Key Word-

Novell SUSE Linux SLES 11 XEN iSCSI 仮想化 複数 NIC 設定

Visit My Site
[PR]
by islandcenter | 2010-02-21 14:09 | プライベートクラウド | Trackback | Comments(0)

コンピュータを正確に時刻あわせをするには、ラジオクロックやGPSなどを使う方法が一番正確なのでしょうが、入手方法も作業手続きも面倒なので、一般には公開されているNTPサーバを使います。

仮想環境で動作しているOSは起動時にハードウェアクロックとの同期が取れないことと、実ハードウェアクロックと仮想マシンが動作するクロックの微妙な差で、時刻がずれるという現象が起こります。また、 XEN 環境では xm pause すると、OSのローカルクロックも凍結した状態になりますから、時刻の狂いを修正しなければなりません。本来なら QEMM の仕事なのでしょうが、このあたりはまだこなれていないようです。

時刻は、OSが起動する際にBIOSクロックを拾って起動し、起動中、ハードウェアと同期をとりながらシャットダウンするときに CMOS クロックに書き込むようです。したがって、内部LANの一次NTPサーバは生のハードウェアを選択します。起動時はとりあえずハードウェアのCMOSクロックから拾い、次にNTPで修正するように動作します。このサーバをターゲットに仮想マシンを二次サーバとしてNTP同期を取るのがよいでしょう。

リアルタイムクロック Wikipedia による

※追加補足 KVM でもハードウェアクロックと同期する機能があるようですが openSUSE のドキュメントではハードウェアクロックの同期とNTPとの併用は推奨していません。個人的にはハードウェアクロックは機械のばらつきで信用できるとは思わないのでよほどのことがない限り仮想環境ではNTPを推奨します。いちいち全部のハードウェアの DEL キーを押しながらBios 画面を開いてNTTの117で確認してから起動画面を眺めるのはあまり気持ちのいいものではありません。

第2章 KVM の制限事項

※追加補足その2--
openSUSE 12 を仮想化するときに Time Zone -> Asia/Japan にセットし「ハードウェアクロックを UTC と同期」させない設定(チェックを外す)とこんなダイアログが出ます。
a0056607_149454.jpg

 これは UTC をCMOS に同期させず、ローカル時間とするのは如何なものですかねぇ? という警告です。 UTC は絶対時間ですが、ローカル時間を使う場合、Day Light Saving Time (夏時間ですね)によっては一々 CMOS クロックも、夏時間に合わせてその都度変える必要があるよ、という警告です。

 今の日本では夏時間は使いませんが、よく「夏時間を導入しよう」ということは議論されます。英国の夏時間制度はどうなのかわかりませんが、 UTC と同じ時間帯に属する GMT だってローカルタイムゾーンです。英国だからと言って政治的に保障されているわけではないということです。

 大抵の場合、クロック合わせは JST で行います。私もそうしますし、CEさんがマザーボードを交換した場合も自分の時計を見ながら日本時間に設定します。

 マザーボードのトラブルログ(UTC)と、OSのログ(JST)をモニタした時にハードウェアクロックがOSとは異なる UTC で記録されると、当然、顧客から「なぜ日本時間じゃないんだ」とクレームになります。

 今後「日本に夏時間を導入」されると、ここはシステム屋としては UTC を使うか JST を使うべきかは議論すべき点となるでしょう。

 理解が得られるなら、 UTC に徹底すべきだろうし、今の日本では JST でかまわないと思います。ネットワーク内部のハードウェアクロックに UTC と JST が混在していたら、と考えると怖いので、今のところはやっぱりハードウェアクロックは使わないほうが無難だ、と考えます。

Windows は特に何も考えずにローカルタイムで起動し、ハイパーバイザーからUTCをもらいます。したがって、起動時のログ時間が UTC で表示されるようです。

-- 補足ここまで
-- 余談
このチェックを外しておかないと、Linux と Windows とデュアルブートするようなPCでは、Windows も ハードウェアクロックを拾って UTC になってしまいます。Windows にはUTCという概念はない様です。というか、ひどく時刻に関しては雑に実装されているなという感じです。
-- 余談ここまで


VMware は当所の事業レベルでは手が出ないので試していないのですが、数十MbのハイパーバイザーにNTPの機能があるとは思えない(あるようです)ので、別途、ハードウェアとナマのOSを用意して仮想マシンのNTPソースにするのがよいと思います。ハイパーバイザーだけの仮想ホストとOS付のハイパーバイザーの隠れたコスト差はここにあります。

-公開NTPサーバと同期する-

ローカルネットワークの入り口でポート123番を通す先に一次同期サーバを設定します。できるだけ、仮想化されたシステムではなく、起動時にとりあえずハードウェアとのCMOSクロック同期が行える「生の」ハードウェアが良いでしょう。私はサーバ専門なので、よくは知らないのですが、ルータなどにNTPの機能があれば利用すべきです。ベアのハードウェアはCMOSクロックで起動して、次に公開NTPサーバー(NICT とか mfeed、あるいはISPのタイムサービスあたり)に正確に同期させます。

そうでないときは XEN が動作する SUSE Linux のDom0の ntp の機能を使います。これももちろん正確な時刻を提供する外部の公開NTPサーバーを使います。

同期元の公開サーバは1つではなく二つ以上を設定するのが良いでしょう。Windows ではデフォルトで time.windows.com となり、全世界何十億台ものデフォルトですから、同期が取れないことが多いと思います。また、Windows ではGUIでは単一のNTPサーバしか指定できないようです。経路的に近くにあるISPや国内の公開サーバーから取得すると、狂いが少ないそうです。国外のサーバを使うと遅延計算によってはかなりの狂いが出ます。

Linux, OES NetWare などは複数のサーバを指定できるため、対障害性を考えて二つ以上の同期先を指定しておくことができます。 SUSE Linux の場合 YaST > Network Service > NTP から設定することができます。設定した内容は /etc/ntpd.conf に書き込まれ、この画面を終了すると自動的にリスタートします。NetWare も Linux も普通のNTPのデフォルトのポーリング間隔確認間隔は10分です。

Windows はデフォルトが8時間なので、一度時刻が狂うと次のチャンスまで8時間、時刻が狂ったままになります。大きく時間が狂うと次も時刻同期に失敗するので早めにNTTの117番をダイアルして、大体の時間を合わせてください。また Windows システムは他のプラットフォームとの時刻同期を保障していません。内部に専用の時刻同期用の Windows プラットフォームを用意する必要がありそうでうす。

Windows の場合ポーリング間隔を変更するにはレジストリの変更か undocumented な秘密のコマンドが必要です。

SUSE の時刻同期は YaST > Network Service > NTP から簡単に設定できます
a0056607_15431554.jpg


log ボタンを押して、実際の同期状態をチェックすることができます。ログは /var/log/ntp に書き込まれます。

デフォルトではブート起動しませんので Dulling Boot をチェックします。Add ボタンで ntp.pool から取得するか、内部の同期先をセットします。ルータでもベア一ハードウェアでもRFC標準のNTPでかまいません。番いいのは、Dom0 が稼動する ntp です。Dom0 は少なくとも起動直後にハードウェアクロックから時刻を拾うので、通信経路の問題があってもまぁまぁの時間を配信してくれます。次にNTPソースを指定し正確に同期させます。

DomU の仮想マシンの場合は、ハードウェアクロックのリストをはずしたほうがよいでしょう。仮想上のハードウェアクロックは信用できません。

TEST ボタンを押すと、時刻同期が行えているかどうかチェックできます。
a0056607_15472220.jpg


こうして、LANの入り口近くにDom0 やナマのハードウェアで NTP サービスを稼動させて、他のサーバやPCは全てこのサービスをチェックするようにします。minpoll , maxpoll などのポーリング間隔をここで指定します。注意するのはここで指定する値はビット値だということです。特に指定がなければ、デフォルトで64秒(min-大きくずれた stepmode )から1024秒(max-安定した状態)の間でポーリングを繰り返します。

http://doc.ntp.org/4.2.4/ntpd.html

-OES NetWare の場合-

Monitor > Server Parameter > Time に時刻同期の設定があります。
a0056607_16302689.jpg


デフォルトの最大ポーリング間隔は600秒(10分)です。
TID 2949745 Timesync Frequently Asked Questions

eDirectory はメジャーなPC用システムとしては、初めて時刻同期を導入しました。非常に時刻同期については敏感です。 OES NetWare/Linux 混在環境では Timesync.nlmのNCP同期 と NTPD が混在するため、移行計画は慎重に行います。

-Windowsの場合-

Windows の場合、次のように設定はシンプルです。導入当初はほとんど time.windows.com への同期ですが、この設定が悪評の w32tm のエラーを発生させます。
a0056607_125043.jpg


Windows の場合、つぎのような公式サイトの情報が役に立ちます。

Windows Server 2003 で Windows 以外の NTP サーバーとの同期が成功しない

W32Time サービスのレジストリ エントリ

多くの設定は次のレジストリの値を調整します。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters

a0056607_1104042.jpg


※ もちろんレジストリを操作することはあまりお勧めするものではありません。バックアップを取ってから行うことです。レジストリの内容そのものはあまり期待せずマイクロソフトにお問い合わせください。

Windows にはシンプルな GUI で時刻の設定が行えますが、複数のサーバを同期元としては定義できないようです。ドメインコントローラなら、コントロールパネルのどこかの「詳細」ボタンの秘密のタブの「詳細設定」の中にあるのかも知れません。見つけたらコメントください。Period パラメータは明示しない場合は一日わずか3回同期をとることがデフォルトのようです。その他のパラメータも多くありますが、詳細に解説したものはこちらにあります。
Windows Time サービスの基本処理

Windows タイム サービスを構成する ※追記
https://technet.microsoft.com/ja-jp/library/cc731191.aspx
次のコマンドがよさそうです。

Windows タイム サービスを構成する

w32tm /stripchart /computer:<ターゲット> /samples:<個数> /dataonly
w32tm /config /manualpeerlist:<ピア> /syncfromflags:manual /reliable:yes /update

例えば nict の ntp サービスに切り替える場合
> ntp.nict.jp にサンプリング先を変える
w32tm /stripchart /computer:ntp.nict.jp /samples:1 /dataonly

> ntp.nict.jp に問い合わせ先を変えるためにレジストリを変更する。
w32tm /config /manualpeerlist:ntp.nict.jp /syncfromflags:manual /reliable:yes /update

これでおバカで仮想化されると UTC になりたがるAD の Windows のドメインコントローラーの時刻は JST で、国内の ntp サーバーと同期を取ることができます。

タスクマネージャに

> net time \\MyNTPserver /set /yes
を設定する方法もあります。起動時と一定時間(NTPなみに10分ごと)に実行させるのもよい方法かもしれません。ただ、ntpd のように minpoll から maxpoll までに序々に「時間を寄せていく」というような機用なことはできないので注意が必要です。一度失敗するとその後8時間は同期しない仕様です。

-NTPD, Timesync の同期-

NTPも Timesync.nlm も動作としては、w32tm のように時間の誤差を一度に修正は行いません。一度に行うと多くのシステム時刻に同期しているアプリケーションに予測できない不具合が発生します。最小ポーリング間隔から始めて徐々に正確な時刻に「寄せて同期」します。10分遅れていると5分進め、次のポーリングで2分半、という感じですね。

この間は短い間隔でポーリングします。ほぼ同期が完了すると、デフォルトで10分の最大ポーリング間隔で時刻同期を観測状態に移行します。NTPD の場合、Step mode から Slow mode という言葉で表現されています。maxpoll の時間は調整できるので、同期がシビアではないシステムの場合は max poll を1時間などの値にしても良いでしょう。

Windows の場合、8時間おきの同期チェックに3度続けて失敗すると、いきなり45分に短縮されるというちょっと乱暴な動きを見せます。誤差が3分以上あるといきなり同期してしまうようですね。まだ同期するならいいのですが、余りに違いすぎると、全く同期しない場合があります。8時間で3度ということは最大24時間は時間がずれたまま運用される可能性があるということです。ドメイン管理者がまずやることはPDCうを再起動したら毎朝NTTの117番で正確な時刻を確認することです。

eDirectory では、大きな時間誤差が発生するとディレクトリオブジェクトに不具合が発生するため、 時刻同期が取れていないと、操作を阻止してくれます。Declare Epoch という最終手段でディレクトリオブジェクトの時刻を強制同期させなければ、ディレクトリのエラーがなくなりません。 もっとも数万人の巨大なディレクトリならば、細かに認証ディレクトリツリーの「ブランチ」ごとにパーティションを分けて、パーティションごとに数台で管理し、タイムスタンプの管理もオブジェクト単位ではなくオブジェクトのアイテムごとに管理するため、 declare epoch はでは最小のトラフィックで同期します。まず数十秒以内に綺麗に修正してくれます。

AD の場合はかなり大雑把な時刻同期のメカニズムなのでデフォルトで運用しているとディレクトリオブジェクトの不整合が頻繁に起こりそうな気がします。もっとも作り自体が大雑把なので、同期していなくても操作できてしまうというのも問題です。ADで巨大なドメインを作ると、タイムスタンプ管理が「オブジェクト丸ごと」でオブジェクトのアイテム単位でタイムスタンプを管理できません。eDirectory のように細かく認証ディレクトリをブランチごとにパーティション化できないので、時刻同期に問題が起こるとドメイン全体のタイムスタンプの修正にえらくトラフィックが発生して修正に手間がかかりそうです。

-強制的に時間を合わせる-

-Windows の場合
> w32tm /config /manualpeerlist:My_NTP_Server:0x8 /syncfromflags:MANUAL

-Linux の場合
# ntpdate My_NTP_Server

ということになるようですが、Windows の場合、時計のプロパティからNTTの117番で確認した「おおよそ」の時間を設定してポーリングで時刻同期を行うのがよさそうです。

-OES NetWare の場合
date, time コマンドで大まかに時刻をセットして、set timesync restart flag=on を実行します。後はポーリング間隔で同期することを待ちます。数分以内に時刻同期が完了します。

-同期の確認-

-Windows の場合

> w32tm /rsync を実行します

C:\>w32tm /resync
再同期のコマンドを送信: local computer...
コマンドは正しく完了しました。


失敗した場合はNTTの117に問い合わせます。

ただし、スタンドアローンな Windows サーバの場合、w32tm 自体が信頼できないので、meinverg 氏の ntpd を使った方が無難で便利です。特に複雑なことをしなくても10分おきにポーリングしてこまめに時刻を修正します。
http://www.meinberg.de/english/sw/ntp.htm

実際の使用感はこちらをご参考ください。
仮想化環境でのWindowsの時刻同期の問題

特にラップトップのようにドメインやイントラNTPと同期が取れない状況でもインターネットと繋がれば公開NTPと同期してくれるので愛用しています。何しろ w32tm ではひとつしか同期先を設定できないし、ドメイン管理下ではNTPの設定もできませんので便利です。

Windows のドメインの時刻同期は Windows 以外と相性がよくないようなので、「ナマのWindowsハードウェア」を仮想サーバとは別に用意して時刻サーバにするのがよいかも知れません。うまくいけば、Linux の NTPD と時刻同期ができる場合もあります。

-Linux の場合

# ntpq -p を実行します。
linux-c63e:~ # ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
LOCAL(0) .LOCL. 10 l 36 64 377 0.000 0.000 0.001
softbank2190571 219.188.200.128 3 u 956 1024 377 58.345 7.152 0.626
+ns.doga.co.jp 133.243.238.243 2 u 425 1024 377 67.948 16.031 3.188
*sylph.white-voi 150.26.2.66 2 u 996 1024 337 38.048 10.104 5.491
l inux-c63e:~ #


OES NetWare の場合

: tymesync debug=7 をセットして裏画面の同期状態をチェックします。また DSrepair に「時刻同期のチェック」があるので、この機能で全てのサーバが問題なく同期状態を保持していること確認します。

- 追記 2015/11/19 CMOS クロックの異常が原因 -
実際にあったことなのですが、マザーボードの故障が原因で、親鯖の時刻はあっているのに小鯖の時刻が狂うという現象があります。
Windows Server 2008 on AWS ~時刻同期の罠~
http://www.skyarch.net/blog/?p=1105#

上の例では AWSのインスタンスを別なサーバーに移動したら治った、というケースです。つまりハードウェアの故障です。親鯖のLinux は ntp などで時刻を取得してしまえば、CMOSが狂っていてもOS上では正しい時刻を保持できます。date コマンドを実行すれば、ほぼ正確な時刻を表示するでしょう。しかし完全仮想化された Windows の小鯖はいったん時刻ずれを起こすと親鯖のハイパーバイザーを経由して誤った CMOS クロックを参照しようします。準仮想化ではこのような現象は出ないようです。目の前で時計が早回しされてしまうという、どうしようもない Windows の時刻同期の仕様ですね。
- 追記終わり -


-まとめ-

- 外部の信頼できるタイムプロバイダーを2つ以上指定して社内の参照元とする。
- NTP が動作するPCは仮想マシンではなく、親(ホストコンピュータ)を使う。
- Windows のタイムソースは社内のタイムソースを ZENworks などで配信する。
- NTPD や Timesync ではほとんどデフォルトで運用して問題ないが、Windows は調整の要あり

こんなところでしょうか。

- Keyword -

SUSE Linux SLES 11 NTP Windows W32TM NetWare Timesync.nlm Time Syncronization

Visit my website islandcenter.jp-NTPD, Timesync

お問い合わせは
islandcenter.jp








[PR]
by islandcenter | 2008-07-02 08:10 | プライベートクラウド | Trackback | Comments(0)