2013年 09月 13日
eDirectory 同期のメカニズム
eDirectory の基本は 1990 年代に開発された NetWare 4x シリーズから基本的な構造、コンセプトは変わりません。この基本設計の優れた点が eDirectory 8.x に継承されています。
この巨大なディレクトリシステムが（おそらく世界最大の）フランス国税局が管理する４０００万人とも言われる納税者のプロファイル管理に利用されています。
何をいまさらなのですが、eDirectory は Novell/NetIQ のＩＤ管理システムの根幹なので、そのメカニズムを「知ったかぶり」で Windows Active Directory と比較して説明します。
-パーティションとレプリカ-
eDirectory の最大の特徴がこのパーティションとレプリカの概念です。
単一の「ディレクトリツリー」空間は、ツリーのブランチ（O/OU：組織/部門オブジェクト）ごとに複数のパーティションデータベースに「分割」して連続した単一のツリー空間の一部を構築することができます。
Windows の Active Directory はこのように「単一の"ドメイン空間"」を「ドメインツリー」としてトラスティドされた連続空間として管理できるだけです。ドメインを「分割」することはできません。
eDirectory のパーティション化（分割）され、分散化されたデータベースは「パーティションレプリカ」と呼ばれます。
また、各 eDirectory サーバーは複数のレプリカデータベースを保持することができます。
データベースはパーティション化して分割（レプリカ）を作成できる
Windows の単一の Active Directory サーバーは同じ「ドメインツリー」内部であっても複数のドメインデータベースを保持することができません。たとえ同一のドメインツリーであっても複数のドメインに所属することができないからですね。従って同じドメインツリーであってもユーザなどのオブジェクトを「移動」することはできません。「削除」と「再作成」が必要です。
各 eDirectory データベースは、パーティション化して細分化されます。極端な例かも知れませんが、各 OU (部門)オブジェクト単位でパーティション化して複数の複数拠点に配置した eDirectory サーバーに分割して同期コストとを削減させ、ＤＲ（耐障害性）を保つことができます。そのため、巨大なディレクトリであっても、少ないサーバー資源に有効に LDAP オブジェクトを分割配置することができます。
少ないサーバーで耐障害性、冗長性が確保できる
パーティションのレプリカデータベースは一般に単一の Master レプリカと複数の Read Write (RW) レプリカによって構成されます。耐障害性と同期コストを考慮して、最低３台から、数台以内のサーバーにレプリカデータベースを持たせることが推奨されます。パフォーマンスを考慮しないとして、３台のサーバーで３拠点以上のパーティションを保持することができます。拠点数とサーバ数が増えれば、更にそれだけ少ないサーバーで細分化されたレプリカデータベースを分散配置できます。
一般には Master レプリカと RW レプリカは一般ユーザや管理者が行う同じ役割（ログイン認証、オブジェクトの新規追加、更新、削除）を実行します。 Master レプリカは、サーバーの追加や削除、レプリカデータベースの分割などのレプリカベースの操作を行うときの操作元となります。
Master レプリカが障害を起して取り除き、RWレプリカから Master に変更する必要がある場合、ndsrepair -P コマンド(NetWare では dsrepair) で "Designate this server as the new master replica"を「選択して実行」するだけです。
ntdsutil ツールで難解なコマンドラインを駆使して「"FSMO"の切り替え」の複雑な操作を行う必要はありません。
-同期コスト-
eDirectory の特徴として、同期コストの低さがあります。
例えば LDAP の属性として cn=user : UID のようにオブジェクト毎に含まれる item/Attribute がありますが、eDirectory はこれらの Object の Item ごとにタイムスタンプが設定されており、オブジェクトの変更は変更されたオブジェクト内部の Item ごとに行われます。例えば、cn=myuser の電話番号を変更しても同期にかかるコストは「電話番号」という Item であり、 cn=myuser 全てのオブジェクトがコピーされるわけではありません。
オブジェクトの同期は Object.item 単位で行われ同期コストを下げている
意外なことなのですが、ユーザなどのディレクトリのオブジェクトは一つあたり割と大きなサイズがあるものなのです。
例えば大量のオブジェクトのパスワードをリセットしても、eDirectory ではリセットされるのはパスワードの情報だけで、オブジェクト全てが同期されるわけではありません。最小の Item だけが限定されたレプリカリング内だけでリセットされるだけです。
一方で、 Windows の Active Directory の場合、「全オブジェクト」の情報がドメインＤＢを持つサーバ全体に同期しようとするため、「ログインできない」「アクセスできない」などのトラブルが大量のドメインコントローラに伝えられ、収束して同期が完全に完了するまで障害として残ります。
eDirectory ではこの「同期状態」を確認するための ndstrace というコマンドインターフェースがあり、「まだ同期中だな」というのが「見て解る」のですが、残念ながら Windows Active Directory ではこういう「今何してるの？」という確認に必要なツールがありません。（というか知らないのは私だけなのかもしれないけれど）
つまり、Windows の Active Directory の管理者は「この操作が正しいかどうか」の確認を「待つのも仕事」「クレームを聞くのも仕事」として諦めて待つしかありません。
これらのディレクトリツリーの障害が発生した場合、ほとんどの場合、細分されたレプリカリング内での問題で、ツリー全体で発生することは非常にまれです。 Windows ドメインであれば、ドメイン全体の修復が必要となる場合があります。、
これらの同期情報のうち、「ログインした」などの情報は即時に同期されます。Immidiate Sync （即時同期）と呼ばれます。一方、郵便番号だとかの情報は即時に同期する必要がないため Slow Sync とか Heart Beat などと呼ばれ、一定時間に数台に分割されたレプリカリング内の提示情報としてまとめて定時同期(Heart Beat Sync)されます。
ここで重要なのは、他のディレクトリ製品でも同様に、時刻が一定のタイミングで同期しているということです。
eDirectory の言わば「最終手段」として行う作業は Decrea Epoch (エポックの宣言)です。この操作は、最終同期した時刻をレプリカリング内で強制的に時刻をリセットして同期する作業です。巨大なレプリカリング内では全てのサーバーに対してこの操作が受け付けられ、大量のパケットと同期コストがかかりますが、ディレクトリーツリーを細分化したレプリカで管理している場合は、その小さなレプリカリング内だけで実行されるため、規模にもよりますが、タイムスタンプのリセットと同期は数十秒から数秒以内で完了します。例えば１０台のサーバーでeDirectory を保持していた内の３台のサーバーが管理するパーティションで Decrea Epoch を実施すると３台のサーバーだけで処理が完了します。また、パーティション自体がブランチごとに細分化されている場合、そのブランチ単位のレプリカで実施されるため、他の OU 単位には少ない影響で完了することができます。
Active Directory のように大量の「オブジェクト全体の強制リセットと同期」が発生しないため、少ない同期コストでオブジェクトの同期が完了します。
-ディレクトリサービスで重要な時刻同期-
Novell eDirectory は NetWare ベースでは NCP(TCP/IP Port 524)あるいはipx を使った時刻同期を行っていましたが、Novell Open Enterprise Server 以降、Linux/Unix ベースのシステムでは一般的な NTP プロトコルを使います。標準的な NTP プロトコルは、時刻ずれが発生した場合、Step Mode という「時間寄せ」のプロセスで、数秒ごとから数分ごと、最終的にはデフォルトの１０分ごと(600秒)の時間確認のプロセスに移行します。これを Slew Mode と言います。Slew モードはNTP の設定でデフォルトの600秒から、１時間とか２４時間とかに自由に設定できます。
一方 Windows システムは w32tm プロセスで時刻同期を行います。このプロセスはデフォルトで８時間（！）ごとに時刻同期を確認し、大幅な同期エラーが発生すると、単に「エラー」を記録して同期は行えなかった事を報告するだけです。このパラメータを変更するためには Windows のレジストリの変更が必要です。Active Directory システムでは、大幅に時刻同期に問題が発生している事を確認するツールがないため、各ドメインコントローラを保持するサーバーに「リモートデスクトップ」ログインを行って、時刻を確認する必要があります。
eDirectory では ndsrepair -T コマンドをいくつかのサーバー上で実行するだけで、時刻同期に問題のあるサーバーを容易に特定することができます。
-権利継承-
eDirectory の特徴として「権利継承(Inherit Right)」の概念があります。[root]管理者 cn=admin が全ての管理を行うのではなく、特定の OU(部門オブジェクト)レベルで管理者権限を与えることにより、この低いレベルでのサーバーの追加、削除、ユーザなどのオブジェクト管理を実施することができます。
admintokyo ユーザはこの内部で自由にサーバやユーザを追加、削除できる。
-eDirectory の最大の欠点：コスト-
Windows サーバーを購入すると CAL が必要となります。同じように eDirectory を購入すると、ユーザごとにライセンスが必要となります。AD のように数百から数千ライセンス程度で十分な場合はＣＡＬは必要悪として受け入れるべきものですが、eDirectory のライセンスは利用者の桁違うため、ライセンス料金自体もそこそこかかります。
また Windows ドメインでは無償で「グループポリシーの管理」が行うことができますが、eDirectory では Novell ZENworks という追加製品でグループポリシーの管理を行います。ポリシー管理だけで Active Directory を巨大なツリーに実装すると、手痛い失敗をすることがあるということです。またポリシーの管理ベースがＯＵ単位であると言う点も大きな問題を生み出します。
もっとも、「認証」だけに必要なライセンス料金は低価格で提供されているようですが、サーバーのサービスを受け入れる必要がある場合、 Windows の ユーザCAL のような形態のライセンス料金が発生します。NetWare 6.5 までは「同時接続ライセンス」として厳密に管理されていましたが、OES Linux に移行してからはペーパーライセンスに変わっています。が、実際に契約したライセンス以上のユーザ利用はライセンス違反となるため、「認証だけ」必要なライセンスが必要なのか、サーバーを利用するためのライセンスが必要なのかは厳密に計画して予算化する必要があります。もちろん、共有ファイル、プリントサーバーとして Windows を使わず、Novell Open Enterprise Server (OES) を使う場合は Windows のユーザ CAL は不要です。
また、公共機関などの認証システム向けに専用の特別に安価な認証のみのライセンスが用意されているため、この場合は特別な価格交渉を行うことができます。
-レプリカごとに異なるソルト-
Windows システムではユーザＩＤは SID という名前で管理されます。この SID はどのドメインコントローラでも共通です。これはユーザに限らず、オブジェクトそのものを「丸ごとコピー」するメカニズム上仕方の無いことです。
一方、eDirectory は UID ごとに異なるオブジェクトＩＤが保持されます。レプリカＡでは cn=user1 が 11223344 なのに レプリカＢでは 66778855 となるわけです。このオブジェクトＩＤは認証での solt (塩) となるわけなのですが、レプリカごとに異なるオブジェクトＩＤ、ソルトを認証に使うため、一つのセッションをハッキングされても、他のサーバーへのいわゆる「なりすまし」「セッションの乗っ取り」が難しくなります。
Active Directory ではオブジェクトのＳＩＤが共通で、ドメインコントローラに「コピー」されるため、ＳＩＤという共通の「鍵」でなりすましが可能です。もっとも今はもう少し賢い方法を使っているのでしょうが。
eDirectory の同期プロセスに続く
この巨大なディレクトリシステムが（おそらく世界最大の）フランス国税局が管理する４０００万人とも言われる納税者のプロファイル管理に利用されています。
何をいまさらなのですが、eDirectory は Novell/NetIQ のＩＤ管理システムの根幹なので、そのメカニズムを「知ったかぶり」で Windows Active Directory と比較して説明します。
-パーティションとレプリカ-
eDirectory の最大の特徴がこのパーティションとレプリカの概念です。
単一の「ディレクトリツリー」空間は、ツリーのブランチ（O/OU：組織/部門オブジェクト）ごとに複数のパーティションデータベースに「分割」して連続した単一のツリー空間の一部を構築することができます。
Windows の Active Directory はこのように「単一の"ドメイン空間"」を「ドメインツリー」としてトラスティドされた連続空間として管理できるだけです。ドメインを「分割」することはできません。
eDirectory のパーティション化（分割）され、分散化されたデータベースは「パーティションレプリカ」と呼ばれます。
また、各 eDirectory サーバーは複数のレプリカデータベースを保持することができます。
Windows の単一の Active Directory サーバーは同じ「ドメインツリー」内部であっても複数のドメインデータベースを保持することができません。たとえ同一のドメインツリーであっても複数のドメインに所属することができないからですね。従って同じドメインツリーであってもユーザなどのオブジェクトを「移動」することはできません。「削除」と「再作成」が必要です。
各 eDirectory データベースは、パーティション化して細分化されます。極端な例かも知れませんが、各 OU (部門)オブジェクト単位でパーティション化して複数の複数拠点に配置した eDirectory サーバーに分割して同期コストとを削減させ、ＤＲ（耐障害性）を保つことができます。そのため、巨大なディレクトリであっても、少ないサーバー資源に有効に LDAP オブジェクトを分割配置することができます。
パーティションのレプリカデータベースは一般に単一の Master レプリカと複数の Read Write (RW) レプリカによって構成されます。耐障害性と同期コストを考慮して、最低３台から、数台以内のサーバーにレプリカデータベースを持たせることが推奨されます。パフォーマンスを考慮しないとして、３台のサーバーで３拠点以上のパーティションを保持することができます。拠点数とサーバ数が増えれば、更にそれだけ少ないサーバーで細分化されたレプリカデータベースを分散配置できます。
一般には Master レプリカと RW レプリカは一般ユーザや管理者が行う同じ役割（ログイン認証、オブジェクトの新規追加、更新、削除）を実行します。 Master レプリカは、サーバーの追加や削除、レプリカデータベースの分割などのレプリカベースの操作を行うときの操作元となります。
Master レプリカが障害を起して取り除き、RWレプリカから Master に変更する必要がある場合、ndsrepair -P コマンド(NetWare では dsrepair) で "Designate this server as the new master replica"を「選択して実行」するだけです。
ntdsutil ツールで難解なコマンドラインを駆使して「"FSMO"の切り替え」の複雑な操作を行う必要はありません。
-同期コスト-
eDirectory の特徴として、同期コストの低さがあります。
例えば LDAP の属性として cn=user : UID のようにオブジェクト毎に含まれる item/Attribute がありますが、eDirectory はこれらの Object の Item ごとにタイムスタンプが設定されており、オブジェクトの変更は変更されたオブジェクト内部の Item ごとに行われます。例えば、cn=myuser の電話番号を変更しても同期にかかるコストは「電話番号」という Item であり、 cn=myuser 全てのオブジェクトがコピーされるわけではありません。
意外なことなのですが、ユーザなどのディレクトリのオブジェクトは一つあたり割と大きなサイズがあるものなのです。
例えば大量のオブジェクトのパスワードをリセットしても、eDirectory ではリセットされるのはパスワードの情報だけで、オブジェクト全てが同期されるわけではありません。最小の Item だけが限定されたレプリカリング内だけでリセットされるだけです。
一方で、 Windows の Active Directory の場合、「全オブジェクト」の情報がドメインＤＢを持つサーバ全体に同期しようとするため、「ログインできない」「アクセスできない」などのトラブルが大量のドメインコントローラに伝えられ、収束して同期が完全に完了するまで障害として残ります。
eDirectory ではこの「同期状態」を確認するための ndstrace というコマンドインターフェースがあり、「まだ同期中だな」というのが「見て解る」のですが、残念ながら Windows Active Directory ではこういう「今何してるの？」という確認に必要なツールがありません。（というか知らないのは私だけなのかもしれないけれど）
つまり、Windows の Active Directory の管理者は「この操作が正しいかどうか」の確認を「待つのも仕事」「クレームを聞くのも仕事」として諦めて待つしかありません。
これらのディレクトリツリーの障害が発生した場合、ほとんどの場合、細分されたレプリカリング内での問題で、ツリー全体で発生することは非常にまれです。 Windows ドメインであれば、ドメイン全体の修復が必要となる場合があります。、
これらの同期情報のうち、「ログインした」などの情報は即時に同期されます。Immidiate Sync （即時同期）と呼ばれます。一方、郵便番号だとかの情報は即時に同期する必要がないため Slow Sync とか Heart Beat などと呼ばれ、一定時間に数台に分割されたレプリカリング内の提示情報としてまとめて定時同期(Heart Beat Sync)されます。
ここで重要なのは、他のディレクトリ製品でも同様に、時刻が一定のタイミングで同期しているということです。
eDirectory の言わば「最終手段」として行う作業は Decrea Epoch (エポックの宣言)です。この操作は、最終同期した時刻をレプリカリング内で強制的に時刻をリセットして同期する作業です。巨大なレプリカリング内では全てのサーバーに対してこの操作が受け付けられ、大量のパケットと同期コストがかかりますが、ディレクトリーツリーを細分化したレプリカで管理している場合は、その小さなレプリカリング内だけで実行されるため、規模にもよりますが、タイムスタンプのリセットと同期は数十秒から数秒以内で完了します。例えば１０台のサーバーでeDirectory を保持していた内の３台のサーバーが管理するパーティションで Decrea Epoch を実施すると３台のサーバーだけで処理が完了します。また、パーティション自体がブランチごとに細分化されている場合、そのブランチ単位のレプリカで実施されるため、他の OU 単位には少ない影響で完了することができます。
Active Directory のように大量の「オブジェクト全体の強制リセットと同期」が発生しないため、少ない同期コストでオブジェクトの同期が完了します。
-ディレクトリサービスで重要な時刻同期-
Novell eDirectory は NetWare ベースでは NCP(TCP/IP Port 524)あるいはipx を使った時刻同期を行っていましたが、Novell Open Enterprise Server 以降、Linux/Unix ベースのシステムでは一般的な NTP プロトコルを使います。標準的な NTP プロトコルは、時刻ずれが発生した場合、Step Mode という「時間寄せ」のプロセスで、数秒ごとから数分ごと、最終的にはデフォルトの１０分ごと(600秒)の時間確認のプロセスに移行します。これを Slew Mode と言います。Slew モードはNTP の設定でデフォルトの600秒から、１時間とか２４時間とかに自由に設定できます。
一方 Windows システムは w32tm プロセスで時刻同期を行います。このプロセスはデフォルトで８時間（！）ごとに時刻同期を確認し、大幅な同期エラーが発生すると、単に「エラー」を記録して同期は行えなかった事を報告するだけです。このパラメータを変更するためには Windows のレジストリの変更が必要です。Active Directory システムでは、大幅に時刻同期に問題が発生している事を確認するツールがないため、各ドメインコントローラを保持するサーバーに「リモートデスクトップ」ログインを行って、時刻を確認する必要があります。
eDirectory では ndsrepair -T コマンドをいくつかのサーバー上で実行するだけで、時刻同期に問題のあるサーバーを容易に特定することができます。
-権利継承-
eDirectory の特徴として「権利継承(Inherit Right)」の概念があります。[root]管理者 cn=admin が全ての管理を行うのではなく、特定の OU(部門オブジェクト)レベルで管理者権限を与えることにより、この低いレベルでのサーバーの追加、削除、ユーザなどのオブジェクト管理を実施することができます。
-eDirectory の最大の欠点：コスト-
Windows サーバーを購入すると CAL が必要となります。同じように eDirectory を購入すると、ユーザごとにライセンスが必要となります。AD のように数百から数千ライセンス程度で十分な場合はＣＡＬは必要悪として受け入れるべきものですが、eDirectory のライセンスは利用者の桁違うため、ライセンス料金自体もそこそこかかります。
また Windows ドメインでは無償で「グループポリシーの管理」が行うことができますが、eDirectory では Novell ZENworks という追加製品でグループポリシーの管理を行います。ポリシー管理だけで Active Directory を巨大なツリーに実装すると、手痛い失敗をすることがあるということです。またポリシーの管理ベースがＯＵ単位であると言う点も大きな問題を生み出します。
もっとも、「認証」だけに必要なライセンス料金は低価格で提供されているようですが、サーバーのサービスを受け入れる必要がある場合、 Windows の ユーザCAL のような形態のライセンス料金が発生します。NetWare 6.5 までは「同時接続ライセンス」として厳密に管理されていましたが、OES Linux に移行してからはペーパーライセンスに変わっています。が、実際に契約したライセンス以上のユーザ利用はライセンス違反となるため、「認証だけ」必要なライセンスが必要なのか、サーバーを利用するためのライセンスが必要なのかは厳密に計画して予算化する必要があります。もちろん、共有ファイル、プリントサーバーとして Windows を使わず、Novell Open Enterprise Server (OES) を使う場合は Windows のユーザ CAL は不要です。
また、公共機関などの認証システム向けに専用の特別に安価な認証のみのライセンスが用意されているため、この場合は特別な価格交渉を行うことができます。
-レプリカごとに異なるソルト-
Windows システムではユーザＩＤは SID という名前で管理されます。この SID はどのドメインコントローラでも共通です。これはユーザに限らず、オブジェクトそのものを「丸ごとコピー」するメカニズム上仕方の無いことです。
一方、eDirectory は UID ごとに異なるオブジェクトＩＤが保持されます。レプリカＡでは cn=user1 が 11223344 なのに レプリカＢでは 66778855 となるわけです。このオブジェクトＩＤは認証での solt (塩) となるわけなのですが、レプリカごとに異なるオブジェクトＩＤ、ソルトを認証に使うため、一つのセッションをハッキングされても、他のサーバーへのいわゆる「なりすまし」「セッションの乗っ取り」が難しくなります。
Active Directory ではオブジェクトのＳＩＤが共通で、ドメインコントローラに「コピー」されるため、ＳＩＤという共通の「鍵」でなりすましが可能です。もっとも今はもう少し賢い方法を使っているのでしょうが。
eDirectory の同期プロセスに続く
by islandcenter
| 2013-09-13 14:44
| OES Linux
|
Comments(0)
