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

10GbE 時代の到来

いよいよ HP の Proliant シリーズに 10GbE が標準搭載されるようです。

QLogicの3GCNA、HP ProLiant ML/DLに正式採用

ストレージ側も 10GbE が標準搭載されると、ますます iSCSI のニーズがでてくるのでしょうか。
Hub のポート単価が3万円程度に下がれば一気に普及するのでしょうね。


- keyword -

SUSE SLES Novell XEN 仮想化
[PR]
by islandcenter | 2011-02-01 17:06 | プライベートクラウド | Trackback | Comments(0)

とてもいいブログがありましたので紹介します。
仮想化でこれはできない? ・・・ VDI でコスト削減

100 User を VDI で稼動させた場合のそれぞれのライセンス比較です。


それぞれ Windows Server 2008 CAL が付属するので、それを考慮して計算すると、次のようになります。
Windows Server 2008 Standard (5CAL付) × 1 = 140,000 円 (ボリューム ランセンス)
Windows Server 2008 Enterprise (25CAL) × 1= 454,000 円 (ボリューム ランセンス)
Windows Server 2008 CAL × 70 = 350,000 円(1 CAL 5,000 円として)
RDS CAL × 100 = 1500,000 (1 CAL 15,000 円として)
Windows VDA × 100 = 1300,000 (1 ライセンス 13,000 円として)
_________ 合計 3,744,000円, 1 仮想デスクトップあたり 37,440 円 _

続いて、VMware View の場合です。
VMware View 4 Enterprise Bundle 100 Pack × 1 = 2,400,000 円
Windows Server 2008 Standard (5CAL付) × 1 = 140,000 円 (ボリューム ランセンス)
Windows Server 2008 CAL × 95 = 475,000 円(1 CAL 5,000 円として)
Windows VDA × 100 = 1300,000 (1 ライセンス 13,000 円として)
_________ 合計 4,315,000円, 1 仮想デスクトップあたり 43,150 円 _

VMware View のほうが高くつきました。


これは、もちろんソフトウェアライセンスだけの値段です。

もし....あるいは(..を除く)というのはなしよ、というのが本音のようです。実際に1台のハードウェアで100Userを動かすのは難しいだろうし、シンクライアントとして稼動させるPCの値段も含まれていません。
もちろん実装費用だとか、何だとかは含まれていないけれど、やっぱり一千万単位のコストがかかりそうだということが予想できます。

大変いい内容でした。
[PR]
by islandcenter | 2011-01-31 13:47 | プライベートクラウド | Trackback | Comments(0)

JFEシステムズ、プライベートクラウドで「PlateSpin」活用--数千万円削減狙う

JFE システムは Novell の SUSE Linux Enterprise Server + XEN および Platespin シリーズでHAとDR環境を構築したプライベートクラウドシステムを構築するという発表がありました。これほど大規模な顧客規模でDRP(惨事復旧)HA環境構築のために SUSE +XEN + Platespin と言ったNovell 製品が採用されるという日本国内の採用事例もこれから増えてくるでしょう。

これはJFEシステムズ(スチール)のプライベートクラウドの始まりに過ぎません。

重厚長大な日本産業の裾野から広がる Novell の 2011 年初めのニュースでした。


Vist my site

-Key Word-
Novell SUSE SLES Platespin P2V DRP 惨事復旧、高可用性 クラスタリング
[PR]
by islandcenter | 2011-01-10 06:19 | プライベートクラウド | Trackback | Comments(0)

Red Hat Enterprise Linux 6の国内提供が開始~「10年後にも色あせないOS」

Redhat Enterprise Linux が発売されました。

記事によると

ソケットペア・1年で、1RHELゲスト・Premiumが16万3000円(税別)、4RHELゲスト・Standardが15万5900円(同)、4RHELゲスト・Premiumが25万3400円(同)、無制限RHELゲスト・Standardが25万9900円(同)、無制限RHELゲスト・Premiumが42万2400円(同)

明らかに Windows の Hyper-V を意識して「ちょっと安くしました」という値段付けです。

32ソケット無制限でベンダーによっては3万円台からサブスクリプションを購入できる Novelll SUSE Linux (SLES11) に比べると随分強気な価格設定だなぁというのが実感です。もちろん Novell も Premium サービスを購入すれば、これくらいの値付けになりますが、最低 98,000 で1ソケット、仮想化ライセンスなしというのはちょっと私には手が出ません。もちろん顧客にも簡単には手が出ないということです。これで、どんどん自信のあるユーザは CentOS に逃げるでしょう。

RedHat はほとんど日本とインドをはじめとする東アジアでしか使われていないようなので、この値段でも売れるンでしょうね。

Novell, SUSE, XEN, プライベートクラウド
[PR]
by islandcenter | 2010-11-19 15:43 | プライベートクラウド | Trackback | Comments(0)

こんな恐ろしいデバイスがたったの500万円台で購入できるのですよ。ハードウェア買って、高価な VMware とNovell PlateSpin を購入して、仮想化とアプリケーションとプライベートクラウド運用に長けたエンジニアを3人短期で雇って、1年かけて構築し3年運用するつもりだったら、500万円台という価格はまさに「エンジニアキラー」にふさわしいNovell ブランドのデバイスです。

Platespin Forgeの製品ページ

ということで簡単に特徴を説明してみましょう。

-筐体-

筐体は Dell 製のハードウェアに大量のメモリと3.5Tのディスク、6個の Gbe を装備してあり、中には VMware と Windows PE ベースの PlateSpin が同梱されています。DVDとUSBメモリを装着して、起動すれば、あとはネットワークの設定を行えば簡単に設置できます。

-ワークロードのレプリケーション-
まずは、既存の物理サーバー環境を検出して Forge にレプリケーションするワークロードを作成します。最低価格の Model 510 で最大10個のワークロード(システム)をバックアップして、Forge にバックアップすることが可能です。この作業は数クリックで済みます。ワークロードは5つ単位でライセンスを増やすことができます。レプリケーションは差分実施が可能で、数世代の差分バックアップを行うことができます。

a0056607_16534680.gif


顧客には、物理サーバ72G×3のRaid 構成で、Pentium ベースのCPUと1Gbのメモリ、140Gbの物理ディスクを備えていて、実際に使っているデータベースの容量は5Gバイトしかないなんて環境は当たり前のようにあります。逆に1Gのメモリ、1コアCPUでは十分なパフォーマンスが出ないというシステムであっても、Forge のリプリケーションで2コア2Gのメモリを用意するというような変更もできる(はず?)です。この作業はワークロードのリプリケーションの設定パラメータをいくつか変更します。もっとも Plate Spin Recon との組み合わせが効果的なことはいうまでもありません。

中小規模の企業であれば、売り上げとか流通管理、給与人事のシステムなんてそんなものでしょう。もっとも、エンジニアリングのCADのDBとか土木、環境工学なんかの巨大なDBなんかはそんなレベルではないにしても、多くのシステムはその程度なのですね。

ということでトータル140Gbもある巨大なシステムであっても実際に必要なディスク容量なんて30Gもあれば十分、などというケースでも Forge に指定したサイズでレプリケーションを作るワークロードを走らせれば、わずか数十分で、システムを仮想化したバックアップは完了してしまうわけです。

-ワークロードの仮想化・物理移行-

そのまま現行システムを Forge をディザスタリカバリで運用していても構わないのですが、巨大で電気を食う古い4Uのラックスペースを1Uの最新の仮想化マシンに移行したいという場合、Forge は新しいハードウェアで動作する Novell SUSE Linux の XEN など仮想マシンのベースに移行するワークロードを作成することができます。また、Forge には巨大なデバイスドライバのデータベースがあり、今まで物理環境で動作していたシステムを Forge にバックアップして、新しい物理環境に移行させることもできます。これらの作業もほんの数クリックで済むわけで、私のような貧乏なエンジニアの仕事を更に減らすこともできます。

-ワークロードの切り替え-

いよいよ、旧環境 > Forge > 新環境 への移行が終わり、テストが終われば、そのまま旧環境を切り離すことができます。Forge 内部には「テスト運用」のための機能があり、旧環境のワークロードをクローズした仮想環境でテスト環境を構築する機能があります。

-ディザスタリカバリ-

こうして、寿命の切れたバッテリー、ネジ穴が壊れたラック、たまに赤ランプが付くハードウェアを撤去して、サーバールームのスペースと電源容量、空調容量に余裕が出てきたら、Forge は自動的に新たに構築したプライベートクラウドのワークロードのバックアップとDRのための運用継続期間が続きます。

-アプライアンスとしての弱点-

これまで「良いこと」ばかりを説明しましたが、決して万能ではないのでその辺を説明しましょう。

-アプライアンスの賞味期限-

Forge は最大5年のサポートを購入することができますが、3年で元を取るつもりで利用すべきです。そもそも、Forge でできるのはワークロードのリプリケーションです。たとえばサポートの切れた Windows 2000 サーバのシステムを自動的に Windows 2008 R2 の環境にリプリケーションしてくれるような器用なことはできません。

Forge によるリプリケーション、テストを経て、新しいバージョンのテスト、ワークロードのバックアップは行えるでしょうが、全く新しいバージョン、システムのテスト、マイグレーションは必要なのですね。

また、ハードウェアアプライアンスとしての賞味期限も気になるところです。アプライアンスとしてはルータもアプライアンスの一つであるわけですが、数千万円のルータにGbの8ポートカードを1枚増設するだけで数百万の見積もりを見たことがあります。Forge のネットワークポートはGbですから、将来、10Gb環境に移行するようなことになれば当然 Forge がボトルネックになる可能性があります。こういった拡張性の選択肢の少なさがアプライアンスの欠点です。

また、現在、同じ敷地内で運用しているプライベートクラウドを集約化する場合、数年で通信費用(固定費ですよね)が格安なサービスに切り替えたいという場合もあるわけですから、DR環境もPCDAのサイクルの中で検討する必要があります。拡張性(スケールアウト)も iSCSI で確保はできますが、その時点でハードウェア自体が陳腐化してしまう場合もあるわけです。

当然メーカーもSIベンダーも「売り切り」で手離れがいいことが売りやすさのメリットなのですが、数年後に Forge そのものがディスコンになってしまえば、賞味期限の切れたアプライアンスに高価なサポート費用がのしかかってくる可能性もあるわけです。

逆に、ビジネスの縮小という自体も、この不況の時代にはありえることです。その際に余分なサポート費用がコスト面でデメリットになる場合もありえるわけですね。

したがって Forge の賞味期限は3年と割り切って導入すべきでしょう。また、Forge の次の世代が保障されているかどうかは、時間の流れの速いIT産業の中で正しくスケールアウトに期待しておきたい点です。最大保障期間は5年ですが、3年で償却するつもりで運用すべきだと思います。

-DRのためでファイルのバックアップリストアはしない-

あくまでも Forge はワークロードのバックアップと拠点のワークロードの惨事復旧手段を容易にするものです。エンドユーザがや部門が「間違って上書きした」「消してしまった」といった部門の「惨事復旧」には対応していません。

まぁ「ファイルの日付を変えてしまった」という証拠隠滅事件が、日本の司法の信頼を揺るがす社会問題になっていますが、従来のテープバックアップでは、金庫にある膨大なアーカイブテープから「証拠を見つけ出す」というエンジニアの最後の手段があるわけですから、その点も考慮してシステムを設計すべきです。

だからと言って「ファイルサーバのバックアップには向かない」ということではありません。ファイルサーバ全体の「惨事復旧」手段としては十分な能力があるということであり、部門やユーザの「惨事復旧」には別な手段を考慮すべきです。

また Forge 自体の惨事復旧手段がないことネックになります。もっとも Forge を Forge でバックアップする手段も将来的に可能なのだそうですが、テープを使ったアーカイブもどこかに検討の余地を入れておきたいところです。もっともどれだけコストをかけられるかとの天秤です。

-結論-

今まで、「仮想化とは」「プライベートクラウド」とは、と言った観点から見られがちだった仮想化技術ですが、高度な専門知識と運用スキルが豊富なエンジニアが長年かけて実施してきた、クラウドマイグレーションを容易にしてしまった、Novell Plate Spin Forge という製品が出てきてしまったため、どうも私の仕事は減ってしまいそうです(笑)
決して万能とは言えないのですが、これ一つでかなりのワークロードの負荷が減ることを考えると必要十分な機能を備えていると評価しています。

-keyword-

Novell Plate Spin Forge, 仮想化,仮想化マイグレーション, XEN, 仮想化バックアップ,仮想化惨事復旧

Visit My site
[PR]
by islandcenter | 2010-10-09 16:55 | プライベートクラウド | Trackback | Comments(0)

今回、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)

仮想環境だけではなく、物理環境でも、w32tm /resync を実行すると

「時刻データが利用できなかったため、コンピュータは同期を取り直しませんでした。」

となる場合があります。これがドメインコントローラである場合は致命的です。
マイクロソフトの次のドキュメントを参考に

Windows Server 2003 で Windows 以外の NTP サーバーとの同期が成功しない
http://support.microsoft.com/default.aspx?scid=kb;ja;875424

ここから>>>>
デフォルトでは、Windows Server 2003 ドメイン コントローラはタイム サー
バーとして構成され、対称アクティブ モードを使用して同期要求を送信しま
す。Windows が実行されていない一部の NTP サーバーは、クライアント モード
を使用する要求以外には応答しません。

<<<ここまで

Windows が実行されていないNTPサーバ(通常の公開NTPサーバなどは「Windows が実行されていない」のが普通だと思います。UNIX/Linux やNTP内臓のLAN内のコアルータなどからは、Windows は時刻同期が取れない場合があるようです。

上のマイクロソフトドキュメントから次のバッチファイルを作り実行しました。

w32tm /config /manualpeerlist:NTP_server_IP_Address,0x8 
syncfromflags:MANUAL
net stop w32time
net start w32time
w32tm /resync

NTP_server の後ろにある 0x8 はクライアントモードを意味します。

デフォルトでは NTP_server は time.windows.com で、
0x1、「特別なポーリング間隔 SpecialInterval を使用」です。

ただし、0x8 を使用した場合は、クライアントモードとなるため、タイムサーバとしては利用できないことになります。

Windows NTP,SNTP は Windows ネットワーク内部(AD環境)で最適化されて利用されることを前提としているため、ドメインに参加しない Windows サーバは排他的に、他のプラットフォームとは実に相性が悪いよということになります。


-ntpd を使って対策-
オープンソースのWindows 用 NTPD(4.2.4p8) を導入してみました。

NTP Download
http://www.meinberg.de/english/sw/ntp.htm

プログラムは NetWork Time Protocol として自動スタートします。
Windows 標準の Windows Time は「無効」となります。
イベントビューワの「アプリケーション」に NTP というソースの
動作状況が確認できます。

Syncronized to 192.168.1.240 stratum2

とあれば、同期先との通信しています。
わざとローカルクロックをずらすと

time reset NUMxxxxxxx

が記録され、時刻を取り直します。

a0056607_13263244.gif


NTPDの場合、起動後にサービスが開始され、良くあるNTPサーバに同期を開始します。 xm destroy などの処理を行った直後に Windows はハイパーバイザーからハードウェアクロック(RTC)が取れない場合があるので、 w32tm のように「時刻が狂ったまま」になることは少ないようです。

C:\Program Files\NTP\etc に ntpd.conf が作成されます。

# NTP Network Time Protocol
# **** ATTENTION ****: *You have to restart the NTP service when you
change this file to activate the changes*
# PLEASE CHECK THIS FILE CAREFULLY AND MODIFY IT IF REQUIRED
# Configuration File created by Windows Binary Distribution Installer
Rev.: 1.26 mbg
# please check http://www.ntp.org for additional documentation and
background information
# Use drift file
driftfile "C:\Program Files\NTP\etc\ntp.drift"

# your local system clock, could be used as a backup
# (this is only useful if you need to distribute time no matter how
good or bad it is)
#server 127.127.1.0
# but it should operate at a high stratum level to let the clients
know and force them to
# use any other timesource they may have.
#fudge 127.127.1.0 stratum 12

# Use a NTP server from the ntp pool project (see http://www.pool.ntp.org)
# Please note that you need at least four different servers to be at
least protected against
# one falseticker. If you only rely on internet time, it is highly
recommended to add
# additional servers here.
# The 'iburst' keyword speeds up initial synchronization, please check
the documentation for more details!
server 192.168.1.240
server ntp.nict.jp

server 2.asia.pool.ntp.org iburst
server 0.us.pool.ntp.org iburst
server 1.us.pool.ntp.org iburst
server 2.us.pool.ntp.org iburst


# End of generated ntp.conf --- Please edit this to suite your needs


このように server に続けてLAN内の ntp サーバや公開サーバを指定します。公共サービスは公共のトラフィックのことも考えて、予備としておきます。なるべく地理的に近いサーバを指定することが重要です。間違っても地球の反対側のtime.windows.com などのNTPソースを参照すべきではないでしょう。ISP 指定のNTPや nict, mfeed などを指定することをお勧めします。ntp pool を利用する場合もなるべく asia のものを使うのが理想です。
http://www.pool.ntp.org/jp/

-Ping は飛べども同期が取れない?-

Ping は反応するのに port 123 番から反応が受けられない場合があります。なぜか、特定の Windows サーバには反応するのに、ドメインコントローラであれども、ntpd サーバであっても駄目という奇妙な現象です。直接アドレス指定しても駄目なので、どうも Windows の名前解決の問題のようなので、原因は全く不明です。おとなしく再インストールするしかないようです。ファイアウォールも開いているのに何故でしょうね。

あわせて読んでください。
仮想環境で仮想マシンの時刻のズレを修正する
http://islandcnt.exblog.jp/8952179/

-Key word-
Novell SUSE Linux, SLES11, Windows W32tim, 時刻同期,時刻が狂う, 仮想化, プライベートクラウド
問い合わせは
islandcenter.jp

[PR]
by islandcenter | 2010-05-24 10:44 | プライベートクラウド | Trackback | Comments(4)

仮想化を支える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)