eDirectory の同期プロセス

eDirectory 同期のメカニズムの続きで、Novell の eDirectory を説明する試みです。


-外部参照(External Referrence)-

まず、外部参照 - External Referrence - について理解しておく必要があります。

外部参照(X-Ref)はパーティション化(分割)されたツリーのレプリカデーターベースにはないオブジェクト(ユーザなど)の情報です。

言わば「社内で出張してきた(ユーザなどの)オブジェクト」です。

例えばOU=Osaka が OU=Tokyo とは分割されたパーティション(オフィス)で OU=Osaka には CN=Maido.OU=Osaka さんがいるとします。OU=Tokyo にあるAsakusa サーバの、とあるファイルだとか「コピー機」にアクセス権限があったとします。Maido さんがこのリソースに接続しようとすると、このユーザの一時的な外部IDが作成されます。Asakusa オフィスでの、いわゆる「ゲスト入館カード」のようなものです。Maido さんはこのカードで出張中の必要な Asakusa オフィスの資源にアクセスできます。「コピー機を使うならその機械を使ってもいいよ」というような情報です。もちろん Maido さんが正規のユーザかどうかの認証は OU=Osaka パーティションに入館時にチェックされます。

eDirectory は「一枚のカードがあれば全てのどこのオフィスビルにでも自由に入館管理ができる」Windows Directory とは異なり、「オフィスビルごとに身分を確認して入館申請管理が必要」なディレクトリサービスなのです。この時に Maido さんが手に入れるIDカードが External Referrence というIDなのです。

多くの eDirectory の同期障害はこの X-Ref に関する情報交換の失敗によるものです。


-Flat Cleaner プロセス-

このプロセスは、External Referrence などの「無用になった」オブジェクトをクリーンアップするプロセスです。cn=Maido.OU=Osaka さんが退職したら、その情報は OU=Osaka パーティションデータベースの中で「即時」に削除されます。しかし、Asakusa オフィスではそのことは誰も知りません。「そういや大阪の Maido さんって元気かなぁ」みたいな状態ですね。
Maido さんに「コピー機を使ってもいいよ」という権限を与えたとしても、その権限を与えた「記憶」は Asakusa のオフィスにはそのまま残っています。

Flat Cleaner プロセスは 「Maido さんという人が Osaka オフィスから出張してコピー機を使う権限を与えた」という記録を消去するプロセスです。

-Janitor プロセス-

Janitor とは「門番」を意味します。

この同期プロセスは「各オフィス」が抱えているサーバーの最終同期状態などをチェックするもので、簡単に言うと「全社コンプライアンス委員会」の確認の為のプロセスのようなものでしょうか。このプロセスの中で、正しく情報のレプリケーションなどが行われているかをチェックします。関連子会社の誰が今度社長になった(マスターレプリカになったか)と言った情報を交換しあうわけです。

Slow Sync で定期的(Heart Beat)に実行されます。


-Replica Sync プロセス-

このプロセスは一番よく発行されるプロセスです。「ゴリさーん、電話だよ」「あ、ゴリさんなら今、トイレに出かけたよ」というような内容の会話がオフィスの一室(パーティション)の中でよく交わされるわけですが、これが Replica Sync のプロセスです。ここで重要なのは、eDirectory によって同期される内容は「ゴリさんに電話があった」「ゴリさんはトイレにいる」という情報だけが、巨大なディレクトリツリーの、小分けされたパーティションの中のサーバー間だけで交換されるということです。

Windows の Active Directory では cn=Gori さんのオブジェクト情報は全て筒抜けに全ての巨大なドメイン中のサーバに同期されます。「ゴリさんに電話があった」だけの情報に加えて、一切変更されていないゴリさんの本日の出社時間から、アクセス権限ゴリさんの内線番号メールアドレス今朝食べたゆで卵が原因でお腹を壊したという下世話な話題まで、全部の情報を東京のサーバーから大阪、ニューヨーク、世界中のサーバーまでコピー同期します。

ちょっと想像しても解りますね、Active Directory を使っているネットワークはひどく「ウルサイ職場」です。しかもデータベースはパーティション化されないため、「ロケーションを超えて、全社で共有」されるという恐ろしいことをやっているわけです。

eDirecotry では最低限の情報交換だけ小分けされたパーティション内で行い、ゴリさんの腹具合まで全ドメイン社内では交換しません。そんなことは別なオフィス(パーティションデータベース)では話題にすらならないのです。

また、総務部が3Fの大部屋から4Fに引っ越したとしましょう。これがいわゆる「ディレクトリのパーティション化」なのですが、その時、ぞろぞろと什器備品が移動します。この時、「総務部にプロジェクタがあったよなぁ」という情報や「営業部に新しい派遣社員が入った」などの情報はも Replica Sync で同期されます。

即時同期 (Immedate Sync) です。


-Replica Purger プロセス-

このプロセスは、削除したオブジェクトの最終確認に使われる通信プロセスです。

あるオブジェクト OU=Maido さんが退職したためどこかのレプリカリングから「削除」した場合、Obituary (オビチュアリ:死亡通知)としてマークされます。このオビチュアリをレプリカリングから一斉に削除するために Replica Purger の通信が発生します。まず、オビチュアリは全てのパーティション内で共有されます。つまり Maido さんのIDカードは使えなくなった、という情報が共有されます。その後 Replica Purger は Maido さんが使っていたカードIDを全て破棄します。

即時同期(Immedate Sync)します。



-Limber プロセス-

この意味不明な通信プロセスは、Janitor プロセスに似ています。似ている作業をするために別な言葉 Limber プロセスと言われるのでしょうか。この通信プロセスも、それぞれのサーバー間、パーティションの整合性、レプリカリングのIP アドレスなどの整合性をチェックするプロセスです。東京本社では、別に関連子会社でオフィスのレイアウトが変更になって、内線番号(IPアドレス)が変更されたということはすぐに必要な情報ではありませんが、常に連絡先だけは確認しておく必要があるということです。

Limber Process は、お互いのIP情報の確認などを行います。

Slow Sync で定期的(Heart Beat)に実行されます。

そこで、あるサーバーの内戦番号(IPアドレス)を変更した場合、 DStrace コマンドで Limber Process を強制発行して、IP アドレスの変更を各サーバーに通知します。



-BackLinker プロセス-

このプロセスも External Referrence に関する情報交換です。まだ Maido さんというIDが OU=Osaka に居るかどうか、このX-Ref はまだ使われる必要があるかどうか、つまり「Maido さんは Asakusa オフィスのコピー機を使う権限を与えた」ことがまだ継続して必要かどうかを確認するプロセスです。



-Schema Sync プロセス-

ディレクトリスキーマというのは、データベースの「構造体」に関する情報です。C言語を習った方なら Structure/Union の宣言のようなものと理解するとわかり易いでしょう。

eDirectory のスキーマは「初期状態の基本情報で固定」されているわけではありません。eDirectory に新しい「属性」が加わることがあります。例えば、基本情報に加えて。「携帯電話も社内で管理しよう」というポリシーになった場合、ユーザオブジェクトの項目に「携帯電話番号」という属性が付け加わります。この情報は ディレクトリ[root] に権限がない限り変更は許可されません。

Schema プロセスは、このディレクトリスキーマが正しく同期されているか、あるいは項目や属性が追加されたり、削除する通信プロセスで、[root] の Master パーティションから下位へと行われます。

スキーマはデータベースの構造そのものですからスキーマの変更はディレクトリ全体に大きな負担がかかります。スキーマの変更に不具合が発生した場合 reset schema を行ってデータベースの再構築を行います。

大抵大きな外資系企業で連休明けに eDirectory の障害が発生した場合は、なんらかのスキーマの変更(例えば新しいディレクトリアプリケーションの導入)が行われたことによります。


-Time Sync プロセス-

このプロセスは NetWare 4/5/6x 時代のもので、OES Linux では NTP に取って代わりました。ただし、ディレクトリ同士が同期しているかどうかはタイムスタンプで管理されているため、OES Linux ではNTP サーバとの同期が取れているかをお互いに監視するために使われます。極端に時刻がズレている場合は同期エラーとなります。

また、オブジェクトのタイムスタンプが「遠い未来」の時間だった場合、 - これは date コマンドを間違って実行してタイムスタンプを「来年」にしてしまった、など - 同期は長時間の間、失敗します。

そこで、タイムスタンプをリセットするために「エポックの宣言(Declere Epoch)」を明示的に実行します。


-Sub Ordinate Referrence は叔母さんの連絡先-

eDirectory の同期プロセスと密接な関係ですが、プロセスとは違う情報の一つにサブオーディネートレプリカ(Sub-Ref)という機能があります。

Windows のADディレクトリは「ドメイン」という巨大な一軒家に徳川一族の譜代の大名も含む、全ての郎党が一つ屋根の下で暮らしているようなものです。ハトコが今トイレに居るとか、会ったこともない従兄弟の子が巨大な一軒家の裏庭今剣術の修行をしているという情報も全て知っています。というか強制的に知らされます。

一方、eDirectory のシステムは、徳川一族が「紀州」「名古屋」「水戸」に分家している様な形態だと考えれば良いでしょう。

私は独立して、貧乏長屋に両親と離れて暮らしています。両親はまた祖父母とは別な家に住んでいます。これが分割されたパーティションです。

ある日、私は従兄弟が家を新築し、叔母の家から独立したと新年の祝いの日に(Janitor のハートビートプロセスで)聞きました。これが叔母の一族(OU)でのパーティションの分割です。しかし、私は従兄弟がどこに家を新築して、新しい電話番号を使い始めたという情報を知りません。そこで、従兄弟に新築祝いも贈ることもできません。

しかし、両親を経由して、祖父母に連絡すると、おばの家に連絡が届き、従兄弟の新築した家(パーティション)の連絡先を知ることができます。これがディレクトリのツリーウォークです。

しかし私は叔母の家がどこにあって、叔母の家を訪れたこともなく、叔母の誕生日に花束を贈ることもない無精者です。ただ連絡先だけを知っています。それは私の両親も同じことです。

このように一族郎党の中に「知り合い」(ここでは叔母さんの家)はあっても、その実情を知らない家(パーティションのレプリカ)があります。これをサブオーディネート(Sub Ordinate Reference) Sub-Ref レプリカと言います。

私は従兄弟の家を訪れて、彼の家の間取りや家族構成をいつも連絡し合います。つまりこれは私が従兄弟の家の Read/Write レプリカを持っているということです。また、叔母さんは従兄弟の家族構成や家の間取り、果ては台所のどこに何があるかまで知っています。つまり叔母さんも従兄弟の家の R/W レプリカを持っているということです。

私は従兄弟の新築の家(パーティション)を訪問し、お茶をご馳走になり、新築祝いで花束をあげました。この情報は彼の家で X-Ref(外部参照)として彼の家庭の皆なが知っていることです。従兄弟の子供が挨拶に来て、私は彼に恥ずかしいほど少ない小遣い(ファイル)を残します。

しかし、私が東京に戻り、コーヒーカップが洗われ食器棚に片付けられ、花束が枯れてゴミ箱に捨てられると Flat Clear プロセスによってその記録(X-Ref)も消去されますが、私が渡したお小遣い(ファイル)には記録が残ります。

しかし、私の両親は叔母さんの家の実態を知りません。(まぁウチの一族の実際はそんな薄情な事はないのですがそう仮定しましょう)私の両親の家(パーティションのデータベース)は叔母の連絡先だけは知っているということです。これが「実体のないレプリカ」Sub Ordinate Referrenceです。私の両親はボクが従兄弟の家に行ってヨッパらってトイレを汚したとか、従兄弟の子供に小遣いを渡したという事実を知りません。また知る必要もありません。

もし叔母が引っ越した(IPアドレスが変わった)としたら、その情報は Limber Process で知ることができます。

このように、たとえ徳川一族のような巨大な郎党であっても、隅々まで家族構成だとか、(あればのことですが)抱えている家庭内の問題だとかを共有しあうことができます。巨大な組織であっても、途中の連絡先さえわかれば、一族の中のパーティション(家庭)内部の少ない情報量の交換だけで、全て「親戚である」という信頼(トラスティ)を得ることができますし、地の遠いハトコであっても「東京に下宿先を探してくれ」と言われれば紹介することができるのです。

※ eDirectory の実態では「親子」間でレプリカを共有しない場合は Sub-Ref が必要です。兄弟間でレプリカを共有しない場合は Sub-Ref は作られません。私は本家を知らなくて、両親の家の間取りや、食器棚のどこに醤油瓶があるかは知らなく(RWレプリカを持たない状態)ても、両親の住所は知っている( Sub Ordinate Referrence) を持っていなければなりません。

-eDirectory の同期状態を調べる-

eDirectory の同期状態を調べるコマンドは ndstrace と ndsrepair コマンドです。 

ndsrepair コマンドは、同期状態を調べ、修復を実行します。

ndstrace コマンドは同期プロセスをリアルタイムに表示し、必要に応じてプロセスを強制実行します。

Novell Open Enterprise Server の eDirectory 8.8 では現在 iMonitor によってブラウザから操作することができます。iMonitor の Trace コマンドで必要なプロセスだけをフィルターし
a0056607_2303059.jpg


トレースを実行します。
a0056607_2314577.jpg


これによってサーバー上での eDirectory の通信プロセスを確認することができます。


islandcenter.jp
[PR]
トラックバックURL : https://islandcnt.exblog.jp/tb/18658847
トラックバックする(会員専用) [ヘルプ]
※このブログはトラックバック承認制を適用しています。 ブログの持ち主が承認するまでトラックバックは表示されません。
by islandcenter | 2013-09-24 05:45 | Identity Management | Trackback | Comments(0)