eDirectory の運用で重要な要素に時刻同期(TimeSync)があります。従来の NetWare では Timesync.nlm がこの要素を構成していましたが、OES Linux 環境では、標準の ntpd を使って時刻同期を行います。

従来、Single Reference と呼ばれるサーバは存在しなくなり、共通のNTPサーバから時刻の配信を行うように設定しなければなりません。 OES Linux 上で ntpd を走らせることも重要ですし、できれば同期先サーバーは構内ネットワークの、(時刻の狂いやすい)仮想マシンではなく、物理マシンを指定すべきです。また、ntpd は Windows とやけに相性が悪いので 相手が Windows の場合、w32tm ではなくフリーの ntpd をインストールすべきでしょう。

OES Linux で時刻同期を確認するには ndsrepair -T を使います。-T は必ず uppercase(大文字)です。

rs2511:~ # ndsrepair -T

[1] Instance at /etc/opt/novell/eDirectory/conf/nds.conf: rs2511.OU=System.O=ACE.ACE-TREE
Repair utility for Novell eDirectory 8.8 - 8.8 SP5 v20504.04
DS Version 20504.06 Tree name: ACE-TREE
Server name: .rs2511.System.ACE

Size of /var/opt/novell/eDirectory/log/ndsrepair.log = 168376 bytes.

Building server list
Please Wait...
Preparing Log File "/var/opt/novell/eDirectory/log/ndsrepair.log"
Please Wait...
Collecting time synchronization and server status
Time synchronization and server status information
Start: Monday, October 18, 2010 13:23:14 Local Time

---------------------------+---------+---------+-----------+--------+-------
DS Replica Time Time is Time
Server name Version Depth Source in sync +/-
---------------------------+---------+---------+-----------+--------+-------
Processing server: .SRV04.System.ACE
.SRV04.System.ACE 10551.78 -1 Single No -15
Processing server: .SRV02.System.ACE
.SRV02.System.ACE - - - - -
ERROR: Could not connect to server, Error : -625
Processing server: .rs2521.System.ACE
.rs2521.System.ACE 20504.06 0 Non-NetWare Yes 0
Processing server: .rs2511.System.ACE
.rs2511.System.ACE 20504.06 0 Non-NetWare Yes 0
---------------------------+---------+---------+-----------+--------+-------
Total errors: 1
NDSRepair process completed.
rs2511:~ #


ここでは SRV04 サーバは OES NetWare で Single Reference となっています。そのため、eDirectory の時刻同期が正しく行われていません。Time is in sync が No と表示されます。このように時刻同期が取れていない、従来の NetWare サーバに接続すると、クライアントの時刻も狂う可能性があります。

OES NetWare から OES Linux へ移行するためには、ntpd が動作している同期先サーバに対して NetWare が Secondary になる必要があります。Single Reference がないのはちょっと不思議な気がしますが、これで問題はありません。
a0056607_1571391.gif


OES NetWare > Monitor > Server Parameters > Time からこれらの項目を変更することができます。
a0056607_1573545.gif


-Keyword-
NetWare, OES Linux, Migration, timesync, eDirectory, ntpd,

Visit Mysite
[PR]
by islandcenter | 2010-10-20 14:49 | OES2 Linux/NetWare | Trackback | Comments(0)

-現象-

Windows ユーザ権限でログインしたユーザのローカルタイムが狂う。
この現象は PowerUser, Administrator グループでは発生しない。
サーバの時刻は問題なく同期している。


参考文書
Error: "The workstation time could not be set"


-原因-

Windows のグループポリシーでは、デフォルトでエンドユーザグループに時刻の
変更を許していないようです。

おそらく、ログインスクリプト中に「時刻の変更が許されない」というようなエ
ラーが出ている可能性があります。

-対策-

Assign user rights for your local computer

C:\> mmc (マイクロソフト管理コンソールの起動)


ファイル > スナップインの追加と削除 > 「グループポリシー」を選択

追加 > 閉じる

a0056607_1392412.gif


コンソールルートから > ローカルコンピュータ > コンピュータの構成

> Windows の設定 > セキュリティの設定 > ローカルポリシー >

ユーザ権利

の中に

「システム時刻の変更」

という項目があります。デフォルトでは Administrators と PowerUsers にしか
許可されていないため

「ユーザの追加」> オブジェクトの追加 "everyone" > 場所の確認で下線が引
かれていることを確認して Everyone に時刻の変更を許可します。

OKボタンを押して、ローカルポリシーを保存します。mmc を終了する際は「保
存しますか」というダイアログが出ますが無視して「いいえ」を選びます。

おそらく、この権限を与えないと、DOSプロンプトから date, time コマンド
で時刻変更ができないと思います。

ローカルユーザ権限でログインして、プロンプトから date と time コマンドで
時刻が設定できるようになるはずです。

-keyword-

Novell Client Error: "The workstation time could not be set" 時刻が狂う
[PR]
by islandcenter | 2010-10-13 13:11 | Windows | 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)