JP5848339B2 - プロビジョニングサービスのためのリーダーアービトレーション - Google Patents

Description

本発明は、ディレクトリーサービスにおけるロッキングメカニズムに関する。

ファイルを交換する少数のコンピューターから複雑多目的なシステムへ、ネットワークシステムが進化してきた。種々のコンピューティングデバイスを結合する多種多様かつ大規模なネットワークは、人々の日々の生活をカバーする数々のタスクを実行する。代表的なネットワークは、多数の有線／無線サブネットワーク、少数から大多数のサーバー／クライアント、パーティション、サブネット、およびさらに多くの態様を含みうる。ネットワークシステムの数および種類が増大するにつれて、標準化された管理方策が必要となり、結果、種々のアプローチを発展させることになった。

ディレクトリーサービスは、ネットワーク管理においては強力なツールであり、それによって管理者がポリシーを割り当て、ソフトウェアを配備し、および組織へ重要な更新を適用することができるようになる。ディレクトリーとは異なり、ディレクトリーサービスは、ユーザーへの情報の利用を可能とする情報源および機能の両方である。ディレクトリーサービスは、オブジェクト（例えば、サーバー、ユーザー、およびその他のリソース）に関連する情報や設定を中央データベースに格納する。ネットワークリソースと通信するときに、識別のためにその情報を使用することができるが、また、オブジェクトが全体の階層スキームに適合することの定義としてもその情報を使用することができる。ディレクトリーサービスは、少数のコンピューター、ユーザー、およびプリンターの小規模の設置から、何万ものユーザー、多くの様々なドメイン、および多くの地理的位置にまたがる大規模サーバーファームまで変わるネットワークで実装されうる。

この概要は、以下の「発明を実施するための形態」でさらに説明される概念の中から選択したものを簡略化した形式で紹介するものである。この概要は、特許請求の範囲に記載された内容の重要な特徴または本質的な特徴を専ら特定することを意図としたものではなく、特許請求の範囲に記載された内容の範囲を判定する際の補助となることを意図としたものでもない。

実施例は、ディレクトリーサービス環境におけるプロビジョニングサービスのためのロッキングメカニズムに関する。一部の実施例に準ずると、ドメインで稼動するサービスは、ＲＩＤ（relative identifier）マスターサーバーで保持される共有ファイルへ書き込みを行うことにより、リーダーロール、または別のシングルトンロール（例えば、スキーママスター、ドメインネーミングマスター、インフラストラクチャーマスター、またはプライマリドメインコントローラー（ＰＤＣ：primary domain controller）エミュレーター）を受け持つことが可能となる。リーダーロールを受け持つサービスは、共有ファイルへ定期的に再書き込みを行うことにより、さらに当該サービスのロールを延長することが可能となる。その他のサービスは、同様に定期的にファイルをチェックし、現在リーダーロールを有するサービスがある限り、パッシブのままでいることができる。リーダーサービスがダウンし、および当該サービスのロールの延長に失敗した場合には、別のサービスが、共有ファイル（当該ファイルは、プロビジョニングサービスにおいて単一のリーダーを保証する）へ書き込みを行うことにより、引き継ぐことができる。

これらのおよびその他の特徴および有利な点は、以下の詳細な説明を読むこと、および関連する図面を参照することから明らかになるであろう。上記概要説明および以下の詳細な説明の双方が説明的なものであり、かつ特許請求された態様を制限するものではないことが理解されるであろう。

ディレクトリーサービスを利用することができるネットワークシステムのコンポーネントの例を表す概念図である。 実装例において、ＲＩＤマスターサーバーをどのように使用して、ドメインコントローラーを管理することができるかを表す図である。 単一のリーダーアービトレーション（leader arbitration）システムを基にしたロックファイルの例を概念的に表す図である。 実施例に準じたシステムが実装されうるネットワーク環境を表す図である。 実施例が実装されうるコンピューティングオペレーティング環境の例を表すブロック図である。 実施例に準じて、プロビジョニングサービスのためのリーダーアービトレーションの処理についての論理フロー図である。

上記簡潔に説明したように、ディレクトリーサービス環境におけるプロビジョニングサービスのためのロッキングメカニズムは、ＲＩＤマスターサーバーで保持される共有ファイルへ書き込みを行うことにより、１のサービスがリーダーロールを受け持つことを可能とする。リーダーロールを受け持つサービスは、共有ファイルへ定期的に再書き込みを行うことにより、当該サービスのロールを延長することができる。その他のサービスは、同様に定期的にファイルをチェックし、現在リーダーロールを有するサービスがある限り、パッシブのままでいることができる。リーダーサービスがダウンし、および当該サービスのロールの延長に失敗した場合は、別のサービスが、共有ファイル（当該ファイルは、プロビジョニングサービスにおいて単一のリーダーを保証する）へ書き込みを行うことにより、引き継ぐことができる。以下の詳細な説明では、本明細書の一部をなす添付図面への参照がされ、当該図面は、特定の実施例または例示の方法により示される。これらの態様が組み合わされ、その他の態様が利用され、および本開示の精神または範囲を逸脱せずに構造的な変更がされてもよい。したがって、以下の詳細な説明は、限定的な意味で取り込まれるべきでなく、本発明の範囲は添付の特許請求の範囲およびそれに相当するものにより定義される。

実施例は、パーソナルコンピューター上のオペレーティングシステムで稼動するアプリケーションプログラムとともに実行される、プログラムモジュールという一般的な状況で説明するが、当業者であればその他のプログラムモジュールと共同して実装されてもよいことが認識できるであろう。

一般に、プログラムモジュールは、ルーチン、プログラム、コンポーネント、データ構造、および特定のタスクを実行し、または特定の抽象データ型を実装するその他のタイプの構造を含む。その上、当業者であれば、その他のコンピューターシステム構成（ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースの一般消費者用電子機器、プログラム制御が可能な一般消費者電子機器、ミニコンピューター、メインフレームコンピューターを含む）により実施例が実施されてもよいことが分かるであろう。分散型コンピューティング環境で実施例が実施されてもよく、そこでは、通信ネットワークを通じてリンクされたリモート処理デバイスによってタスクが実行される。分散型コンピューティング環境では、プログラムモジュールはローカルとリモートの双方のメモリーストレージデバイスに位置してもよい。

実施例は、コンピューターにより実装可能なプロセス（方法）、コンピューティングシステム、またはコンピュータープログラム製品もしくはコンピューター可読媒体のような製造品として実装されてもよい。コンピュータープログラム製品は、コンピューターシステムにより読み取り可能であり、かつコンピューターまたはコンピューティングシステムに、サンプルプロセスを実行させる命令を備えるコンピュータープログラムをエンコードするコンピューター記憶媒体であってもよい。コンピューター可読記憶媒体は、例えば、１または複数の揮発性コンピューターメモリー、不揮発性コンピューターメモリー、ハードドライブ、フラッシュドライブ、フロッピディスクもしくはコンパクトディスク、およびそれらと同等の媒体を介して実装されることが可能となる。

本明細書全体を通じて、「プラットフォーム」の用語は、ネットワークシステムを管理するためのソフトウェアコンポーネントとハードウェアコンポーネントとの組み合わせであってもよい。プラットフォームの例には、複数のサーバー上で実行されるホスティングされたサービス、単一のサーバー上で実行されるアプリケーション、およびそれらと同等のシステムが含まれるが、それらに限定されない。「サーバー」の用語は、一般に、主としてネットワーク環境で１または複数のソフトウェアプログラムを実行するコンピューティングデバイスを指す。しかしながら、サーバーは、ネットワーク上で１つのサーバーとしてみなされる、１または複数のコンピューティングデバイス上で実行される仮想サーバー（ソフトウェアプログラム）として実装されてもよい。

図１は、ディレクトリーサービスを利用することができるネットワークシステムのコンポーネントの例を表す概念図である。すでに述べたように、ネットワークシステムは、サイズおよびタイプにおいて変わりうるので、したがって、様々な範囲に及ぶ機能を備える多くの様々なコンポーネントを含んでもよい。略図１００は、ディレクトリーサービス環境を備えるシステムの例を表す。システムの例は、ネットワーク構成、サービスポリシーの品質、セキュリティーポリシー、およびそれらと類似する態様を担当しうるネットワークデバイス１１２を含む。ファイアウォールサービス１１６は、構成、セキュリティーポリシー、および仮想ＶＰＮ（virtual personal network）ポリシーを担当してもよい。アプリケーションサービス１２０は、サーバー構成、認証ポリシー（例えば、シングルサインオン）、アプリケーション特有のディレクトリー情報、およびアプリケーションポリシーを担当してもよい。Ｅメールサービス１１８は、メールボックス情報、アドレス帳、およびそれらと類似するデータを保持してもよい。ネットワークオペレーションコンポーネント１１４は、ユーザーレジストリー、セキュリティーポリシー、およびそれらと類似する特性のものを保持してもよい。その他のディレクトリー１１０は、ホワイトページ（電話帳）、およびＥコマースディレクトリーなどのような特有のディレクトリーサービスを含んでもよい。

ディレクトリーサービス１０２は、上述したこれら全てのコンポーネントと対話してもよく、またポリシーの割り当て、ソフトウェアの配備、組織への更新アプリケーション、およびそれらと類似するタスクを円滑にしてもよい。また、ディレクトリーサービス１０２は、システムユーザー１０４に関連するアカウント情報、特権、プロファイル、およびポリシーを管理してもよい。さらに、ディレクトリーサービス１０２は、管理プロファイル、ネットワーク情報、プリンター、ならびにそれらと類似するリソース、ファイル共有、およびポリシーを統括するシステムサーバー１０６と対話してもよい。その上に、ディレクトリーサービス１０２は、システムクライアント１０８に対応するプロファイルおよびネットワークポリシーの管理を担当するシステムクライアント１０８と対話してもよい。

本出願人提供のアクティブディレクトリー（Active Directory：商標）のようなディレクトリーサービスは、システムコンポーネントをオブジェクトとしてトラッキング（track）する。オブジェクトは、ディレクトリーサービス内でトラッキングされるユーザー、システム、リソース、またはサービスであってもよい。オブジェクトの一部は共通属性を共有してもよく、その他は異なる特性を有してもよい。したがって、ディレクトリーサービス構造は、オブジェクトの階層フレームワークである。各オブジェクトは、単一のエンティティー（例えば、ユーザー、コンピューター、プリンター、またはグループ）、およびそのエンティティーの属性を表してもよい。また、あるオブジェクトは、その他のオブジェクトのコンテナであってもよい。オブジェクトは、オブジェクトの名前により一意に識別されてもよく、スキーマにより定義される属性（例えば、オブジェクトが包含することができる特性および情報）の組を有してもよい。当該スキーマはまた、ディレクトリーサービスが格納することができるオブジェクトの種類を判定してもよい。

ディレクトリーサービス構造内では、サイトは、１または複数のネットワークをホスティングする地理的位置を表すオブジェクトである。サイトは、サブネットと呼ばれるオブジェクトを含んでもよい。サイトは、グループポリシーをオブジェクトに割り当て、リソースの発見を円滑にし、アクティブディレクトリーレプリケーションを管理し、およびネットワークリンクのトラフィックを管理するために使用されてもよい。

オブジェクトを持つディレクトリーサービスフレームワークは、多くのレベルで見ることができる。その構造の上位は、フォレストである。フォレストは、ディレクトリー構造における各オブジェクト、オブジェクトの属性、およびルール（属性構文）の集合である。フォレストはツリーの集合であり、ツリーは１または複数のドメインの集合である。フォレスト、ツリー、およびドメインは、ディレクトリーサービスネットワークにおける論理的な部分である。したがって、サーバーおよびそれに類似するコンポーネント（サービスを含む）に割り当てられるロールは、ディレクトリーサービスの階層構造に基づいて定義されてもよい。例えば、実施例に準じたプロビジョニングサービスにおいて単一のリーダーアービトレーションを円滑にするためのＲＩＤマスターサーバーは、ＲＩＤマスターのシングルトンステータスを保証する特定のドメイン内（複数のドメイン全体にまたがらない）で定義されてもよい。

図２は、実装例において、ＲＩＤマスターサーバーをどのように使用して、ドメインコントローラーを管理することができるかを表す。多数のサービスおよびオペレーションが、ディレクトリーサービス環境内で提供されてもよい。略図２００は、ＲＩＤマスターに関連するドメインコントローラー間相互のレプリケーションサービスの例を表す。下記で説明するが、ＲＩＤマスターサーバー２２２は、定義により各ドメインに対して一意である。したがって、一部の実施例に準じて、ＲＩＤマスターサーバー２２２が配備して、共有ロックファイルを保持する。

略図２００では、様々なドメインコントローラー２２４、２２６、および２２８が、マルチマスターレプリケーション２３０を通じて、当該ドメインコントローラー間で互いにディレクトリーサービスデータベースの変更をレプリケートする。一方、一意なＲＩＤマスターサーバー２２２は、ドメインコントローラー２２４、２２６、および２２８に対してセキュリティーＲＩＤ（security relative identifier）を割り当てるために配備される。

ディレクトリーサービス構造では、各ドメインは、ディレクトリーサービスデータベースの複製を含み、かつその他のドメインコントローラーと変更を同期する（例えば、マルチマスターレプリケーションを通じて）、１または複数のドメインコントローラーを有してもよい。レプリケーションは、ディレクトリーサービス環境内で円滑にされ、かつプルベースで頻繁に発生しうるサービスの例である。ドメインコントローラーサーバーは、フェロー（fellow）ドメインコントローラーからの更新を要求してもよい。１のドメインコントローラー上での情報が変化する場合（例えば、ユーザーがパスワードを変更する）、当該ドメインコントローラーは、その他のドメインコントローラーにシグナルを送り、データのプル（pull）レプリケーションを開始して、ドメインコントローラーが全て最新状態であることを保証してもよい。

ＦＳＭＯ（Flexible Single Master Operation）は、標準のデータ転送および更新手法が不十分である場合に使用される、ドメインコントローラータスクに特化する。上記説明したように、ディレクトリー構造は、通常、複数のピア（peer）ドメインコントローラーに依存し、ディレクトリー構造データベースの複製を有する各ピアドメインコントローラーは、マルチマスターレプリケーションにより同期され得る。マルチマスターレプリケーションには適さず、かつ単一のマスターデータベースのみで実行可能なタスクは、ＦＳＭＯである。ピアドメインＦＳＭＯの１つの例は、ＲＩＤマスターである。ＲＩＤマスターは、ドメインコントローラーに対してセキュリティーＲＩＤをアロケートして、新規のディレクトリー構造セキュリティープリンシパル（directory structure security principal）を割り当ててもよい（例えば、ユーザー、グループ、またはコンピューターオブジェクト）。また、ＲＩＤマスターは、ドメイン間を移動するオブジェクトを管理してもよい。

ＦＳＭＯの別の例は、ドメインにおいてパスワード変更を処理するＰＤＣである。その他のドメインコントローラーで、誤ったパスワードが原因で失敗した認証の試みを拒絶する前に、ＰＤＣに転送し得る。このことにより、ユーザーが任意のドメインコントローラーからパスワードを変更した直後に、その変更がレプリケートされるのに数分待つ必要がなく、即時にログインできることを保証する。ＦＳＭＯのさらなる例は、ドメイン間相互で参照されるオブジェクトについてのセキュリティーＩＤ、グローバルユーザーＩＤ（ＧＵＩＤ）、およびドメインネームを保持するインフラストラクチャーマスターである。インフラストラクチャーマスターは、ユーザーおよびグループリンクを更新してもよい。

図３は、単一のリーダーアービトレーションシステムに基づくロックファイルの例を概念的に表す。ディレクトリーサービス環境におけるプロビジョニングサービスのためのロッキングメカニズムは、略図３００で示すＲＩＤマスターサーバー３２２上に格納される共有ロックファイル３３２を使用して実装されてもよい。ＲＩＤマスターサーバー３２２は、ＦＳＭＯロールであり、ディレクトリーサービス環境における全体のドメインに対してＲＩＤマスターサーバー３２２の１つのみが存在することができる。ドメインにおいて稼動するサービスの組（例えば、３３４、３３６、および３３８）は、共有ロックファイル３３２へ書き込みを行うことにより、リーダーシップをつかみにいこうとしてもよい。リーダーシップをつかむことができる第１のサービスインスタンス３３４は、第１の所定の期間（例えば、Ｘ秒毎）、当該リーダーシップを延長してもよい。その他のサービスインスタンス３３６および３３８は、パッシブのままであり、かつ第２の所定の期間（例えば、Ｙ秒毎）経過後、リーダーシップステータスをチェックしてもよい。第２の所定の期間（Ｙ）は、第１の所定の期間（Ｘ）よりも長くなるように選択されてもよい。ＹがＸよりも短い場合は、Ｘ時間経過後であるアクティブインスタンスがピングを送る前に、パッシブインスタンスがリーダーシップをつかみうることになる。

リーダーサービスが機能しなくなる場合に、パッシブサービスインスタンスはリーダーシップをつかみ、アクティブになることができる。ＲＩＤマスターサーバー３２２が機能しなくなる場合に、ディレクトリーサービスプロシージャーが引き続いて、ロールの転送または剥奪のいずれかを行い、かつその他のサーバーをＲＩＤマスターサーバー３２２とさせてもよい。両プロシージャーは、１つのＲＩＤマスターサーバー３２２のみが存在することを確かにする。ＲＩＤマスターサーバーロールが転送または剥奪される場合に、ディレクトリーサービスの実施を引き続けることを最優先に、情報がドメインにおける全てのサーバーに送信されてもよい。したがっていつでも、システムは単一のリーダーが存在することを保証する。Ｙについての値は、ドメインにおける全てのサーバーに情報が届く、予想される最悪なケースの待ち時間に基づいて選ばれてもよい。

共有ロックファイルをホスティングするＲＩＤマスターサーバーの例とともに、実施例を述べたが、各ドメイン内のその他のシングルトンサーバー（物理または仮想）はまた、ロックファイルを保持するために使用されてもよい。例えば、上述したＰＤＣまたはインフラストラクチャーマスターは、その他の実施例に準じて、ロックファイルをホスティングしてもよい。

図１乃至図３で述べた様々なプロセスおよびシステム構成は、単に例示を目的としているものであり、実施例上の限定を構成するものではない。実施例は、追加または少数のコンポーネント（ソフトウェアまたはハードウェア）、様々な構成、および本明細書で説明したプリンシパルを使用したロール割り当てにより実装されてもよい。

図４は、実施例が実装されうるネットワーク環境の例である。リーダーシップアービトレーションによるプロビジョニングサービスを提供するプラットフォームは、サーバー４１６上（例えば、ホスティングされたサービス）で実行されるソフトウェアを介して実装されてもよい。プラットフォームは、サーバー４１４上で実行されるその他のサービス、および個々のコンピューティングデバイス（例えば、スマートフォン４１１、ラップトップ４１２、デスクトップコンピューター４１３、またはそれらに類似するデバイス（「クライアントデバイス」））上のクライアントアプリケーションと、ネットワーク４１０を通じて通信してもよい。

クライアントデバイス４１１乃至４１３のうちの任意のデバイス上で実行されるクライアントアプリケーションは、サーバー４１６からプロビジョニングサービスを提供するホスティングされたサービスと対話してもよい。サーバー４１４上のその他のサービスは、プロビジョニングサービスとコンタクト（contact）して、プロビジョニングオペレーションにおけるリーダーを判定してもよい。プロビジョニングサービスは、ＲＩＤマスターサーバー上の共有ロックファイルを通じて単一のリーダーを選択することと、選択されたリーダーの確認を定期的に行い、いつでも複数のリーダーがアクティブとならないよう保証することとを提供してもよい。関係するデータは、データ格納部４１９へ格納されること、および／またはデータ格納部４１９から読み出されることが、直接またはデータベースサーバー４１８を通じて行われてもよい。

ネットワーク４１０は、サーバーの任意のトポロジー、クライアント、インターネットサービスプロバイダー、および通信媒体を備えてもよい。実施例に準じたシステムは、静的または動的なトポロジを有してもよい。ネットワーク４１０は、企業ネットワークのようなセキュアなネットワーク、無線オープンネットワークのようなアンセキュアなネットワーク、またはインターネットを含んでもよい。また、ネットワーク４１０は（とりわけ、サーバーとモバイルデバイスとの間では）、セルラーネットワークを含んでもよい。さらに、ネットワーク４１０は、Ｂｌｕｅｔｏｏｔｈ（登録商標）またはそれに類似するネットワークような短距離無線ネットワークを含んでもよい。ネットワーク４１０は、本明細書で説明したノード間における通信を提供してもよい。例として、ネットワーク４１０は、音波、ＲＦ、赤外線、およびその他の無線媒体のような無線媒体を含んでもよいが、それらに限定されない。

コンピューティングデバイス、アプリケーション、データソース、およびデータ配信システムのその他多くの構成が配備されて、プロビジョニングサービスのためのリーダーアービトレーションを提供するプラットフォームを実装してもよい。さらに、図４で述べたネットワーク環境は、単に例示を目的としているものである。実施例は、アプリケーション、モジュール、またはプロセスの例に限定されない。

図５および関連する議論は、実施例が実装されうる適切なコンピューティング環境の簡潔かつ一般的な説明を提供することを意図する。図５を参照すると、実施例に準じて、アプリケーションに対するコンピューティングオペレーション環境のブロック図が表される（例えば、コンピューティングデバイス５００）。基本的な構成では、コンピューティングデバイス５００は、実施例に準じたディレクトリーサービスを提供するサーバーであってもよく、少なくとも１つのプロセッシングユニット５０２およびシステムメモリー５０４を含んでもよい。また、コンピューティングデバイス５００は、実行中のプログラムと協働する複数のプロセッシングユニットを含んでもよい。厳密な構成およびコンピューティングデバイスのタイプに応じて、システムメモリー５０４は揮発性（例えば、ＲＡＭ）、不揮発性（例えば、ＲＯＭおよびフラッシュメモリーなど）、またはその２つの一部の組み合わせであってもよい。システムメモリー５０４は、主としてプラットフォームのオペレーションを制御するのに適したオペレーティングシステム５０５（例えば、本件出願人提供のウインドウズ（登録商標）オペレーティングシステム、またはそれと類似するオペレーティングシステム）を含んでもよい。また、システムメモリー５０４は、１または複数のソフトウェアアプリケーション（例えば、プログラムモジュール５０６、プロビジョニングサービス５２２、およびロックファイル５２４）を含んでもよい。

プロビジョニングサービス５２２は、ディレクトリーサービス環境におけるシステム内でのサービスからの要求を仲裁（arbitrate）してもよい。第１のサービスから要求を受信すると、プロビジョニングサービス５２２は、当該第１のサービスが共有ロックファイル５２４へ書き込みを行うことを可能とさせてもよい。共有ロックファイル５２４は、その他のサービスに対し第１のサービスがリーダーロールを有することを指示する。また、ロックファイル５２４へ再書き込みを行うことにより、第１のサービスがそのサービスのロールを所定の期間、延長することを可能とさせてもよい。その他のサービスは、定期的にファイルをチェックし、第１のサービスがそのサービスのロールを明け渡すまでパッシブのままでいてもよい。それから、別のサービスはロックファイル５２４への書き込みを行い、リーダーロールを引き継ぐなどとしてもよい。この基本的な構成は、波線５０８内のコンポーネントにより図５で表される。

コンピューティングデバイス５００は、追加の特徴および機能性を有してもよい。例えば、コンピューティングデバイス５００はまた、追加のデータストレージデバイス（着脱可能および／または着脱不能）、例えば、磁気ディスク、光学ディスクまたはテープを含んでもよい。このような追加の記憶装置は、着脱可能記憶装置５０９および着脱不能記憶装置５１０により、図５で表される。コンピューター可読記憶媒体は、情報を格納するための任意の方法または技術で実装される揮発性および不揮発性、ならびに着脱可能および着脱不能媒体（例えば、コンピューター可読命令、データ構造、プログラムモジュール、またはその他のデータ）を含んでもよい。システムメモリー５０４、着脱可能記憶装置５０９、および着脱不能記憶装置５１０は、コンピューター可読記憶媒体の全ての例となる。コンピューター可読記憶媒体は、所望の情報を格納するのに使用され、コンピューティングデバイス５００によりアクセスすることができるＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリー、もしくはその他のメモリー技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、もしくはその他の光学記憶装置、磁気テープ、磁気ディスク記憶装置、もしくはその他の磁気記憶装置、またはその他の磁気記憶装置を含むがこれらに限定されない。このような任意のコンピューター可読記憶媒体は、コンピューティングデバイス５００の一部であってもよい。また、コンピューティングデバイス５００は、入力デバイス５１２（例えば、キーボード、マウス、ペン、音声入力デバイス、タッチ入力デバイス、およびこれらと同等の入力デバイス）を有してもよい。また、出力デバイス（例えば、ディスプレイ、スピーカー、プリンター、およびその他のタイプの出力デバイス）が含まれてもよい。これらのデバイスは、当分野において周知であり、本明細書でこれ以上述べる必要はない。

また、コンピューティングデバイス５００は、通信コネクション５１６を包含してもよく、当該通信コネクション５１６により、デバイスがその他のデバイス５１８と通信できるようになる（例えば、分散コンピューティング環境における無線または有線ネットワーク、サテライトリンク、セルラーリンク、短距離ネットワーク、およびこれらと同等のメカニズム上で）。その他のデバイス５１８は、通信アプリケーションを実行するコンピューターデバイス、その他のサーバー、およびこれらと同等のデバイスを含んでもよい。通信コネクション５１６は、通信媒体の１つの例である。通信媒体は、その中にコンピューター可読命令、データ構造、プログラムモジュール、またはその他のデータを含むことができる。例として、通信媒体は無線媒体（例えば、無線ネットワークまたは直接無線通信、ならびに音波、ＲＦ、赤外線およびその他の無線媒体のような無線媒体を含むがこれらに限定されない。

例示的な実施例は、方法をも含む。これらの方法は、本ドキュメントで説明する構造を含む任意の数の方式で実装することができる。このような方式の１つは、本ドキュメントで説明するタイプのデバイスのマシンオペレーションにより実装される。

別の選択的な手法は、一部がヒューマンオペレーションにより実行されるとともに、実行される方法の個々のオペレーションのうちの１つまたは複数に対してなされる。これらのヒューマンオペレーションは、互いになされる必要はなく、各々が単にプログラムの一部分を実行するマシンによりなされる。

図６は、実施例に準じたプロビジョニングサービスのためのリーダーアービトレーションのプロセス６００についての論理フロー図を表す。プロセス６００はディレクトリーサービスの一部として実装されてもよい。

プロセス６００は、オペレーション６１０で始まり、当該オペレーションでは、ドメインにおいてサービスの組のうちの１つから要求が受信される。プロビジョニングサービスは、オペレーション６２０で、要求サービスがＲＩＤマスターサーバーで保持されるロックファイルへ書き込みを行うことを可能とさせ、かつ要求サーバーに対しリーダーとして指令してもよい。リーダーサービスは、ロックファイルへ定期的に再書き込みを行うことにより、当該サービスのポジションを延長してもよい。

オペレーション６３０では、プロビジョニングサービスは、共有ロックファイルへの書き込みを試みる形式で、別のサービスから別の要求を受信してもよい。判定オペレーション６４０で判定するように、リーダーサービスの記録がいまだにロックファイルにある場合に（例えば、サービスがアクティブでありいまだにリーダーである）、プロビジョニングサービスは、新規のサービスがロックファイルへ書き込みを行うことを拒否してもよい。そのサービスは、パッシブのままとなり、所定の期間経過後に再度、チェックを行ってもよい。前のプロビジョニングサービスがもはやアクティブでなく、またはそのリーダーシップが何らかの理由で取り消しとなる場合は、オペレーション６５０で、プロビジョニングサービスにより、新規のサービスがロックファイルへの書き込みを行い、新規のリーダーとなることを許可することができる。

プロセス６００に含まれるオペレーションは、例示目的のためとなる。プロビジョニングサービスのためにリーダーアービトレーションを提供することは、少数のまたは追加ステップと類似するプロセスにより実装されてもよく、また本明細書で説明したプリンシパルを使用して、オペレーションの様々な命令において実装されてもよい。

上記明細書、例、およびデータは、実施例の組成物の製造および使用の完全な説明を提供する。請求対象は、構造的特長および／または方法論的動作に特有の言語において説明されてきたが、添付の請求項において定義される請求対象は、必ずしも説明された特定の特長または動作に限定されないことを理解されたい。そうではなく、上記説明した特定の特長および動作は、請求項を実施する例示的な形態として開示される。

Claims (20)

1. コンピューティングデバイスで実行され、プロビジョニングサービスにおいてリーダーアービトレーションを提供する方法であって、
   第１のサービスから要求を受信するステップと、
   前記第１のサービスが、共有ロックファイルへの書き込みによりリーダーロールを引き受けることを可能とさせるステップと、
   第２のサービスから別の要求を受信するステップと、
   前記共有ロックファイルのレコードに基づき、前記第１のサービスがいまだに前記リーダーロールを有している場合に、前記第２のサービスが前記リーダーロールを引き受けることを拒否するステップと、さもなければ、
   前記第２のサービスが、前記共有ロックファイルへ書き込みを行い、前記第２のサービスが前記リーダーロールを引き受けること、を可能とさせるステップと、
   前記第１のサービスと前記第２のサービスとの間でマルチマスターレプリケーションを通じて前記第１のサービスおよび前記第２のサービスのうちの少なくとも１つにおける変化をレプリケートするステップと、
   を備える方法。
2. 第１の所定の期間経過後、前記第１のサービスが、前記共有ロックファイルへの書き込みにより前記第１のサービスのリーダーロールを延長することを可能とさせるステップをさらに備えることを特徴とする請求項１に記載の方法。
3. 第２の所定の期間経過後、前記第２のサービスが前記共有ロックファイルをチェックすることを可能とさせるステップをさらに備えることを特徴とする請求項２に記載の方法。
4. 前記第２の所定の期間は前記第１の所定の期間よりも長いことを特徴とする請求項３に記載の方法。
5. 前記リーダーロールを引き受けることができない場合に前記第２のサービスはパッシブモードのままであることを特徴とする請求項３に記載の方法。
6. 前記共有ロックファイルは、ディレクトリーサービス環境内におけるドメインのシングルトンサーバーに格納されることを特徴とする請求項１に記載の方法。
7. 前記シングルトンサーバーは、セキュリティー関連識別子（ＲＩＤ）を前記ドメインのドメインコントローラーに割り当てるＲＩＤマスターサーバーであることを特徴とする請求項６に記載の方法。
8. 前記シングルトンサーバーは、物理サーバーおよび仮想サーバーのうちの１つであることを特徴とする請求項６に記載の方法。
9. 前記シングルトンサーバーを別のシングルトンサーバーに置き換えるステップと、
   前記共有ロックファイルをその他のシングルトンサーバーに転送するステップと、
   前記その他のシングルトンサーバーにおける前記共有ロックファイルを通じて、前記リーダーアービトレーションが継続されて、前記リーダーアービトレーションが円滑になるように、前記ドメイン内のサーバーに通知するステップと、
   をさらに備える請求項６に記載の方法。
10. 前記リーダーアービトレーションはディレクトリーサービス環境内でリソース割り当てのために使用される請求項１に記載の方法。
11. プロビジョニングサービスにおいてリーダーアービトレーションを提供するシステムであって、
    ディレクトリーサーバーの第１のプロセッサにおいてディレクトリーサービスをホスティングするディレクトリーサーバーであって、前記ディレクトリーサーバーは、
    リソースアロケーション（resource allocation）のために、リーダーアービトレーションタスクをドメイン内の単一のサーバーに割り当てるように構成され、前記単一のサーバーは、前記リーダーアービトレーションタスクを前記第１のプロセッサにおいて円滑にするために共有ロックファイルを保持する、ディレクトリーサーバーと、
    第１のサーバーの第２のプロセッサにおいて第１のサービスをホスティングする第１のサーバーであって、前記第１のサービスは、
    前記第２のプロセッサにおいて前記共有ロックファイルへの書き込みによりリーダーロールを引き受けることと、
    前記第２のプロセッサにおいて第１の所定の期間経過後、前記共有ロックファイルへの再書き込みにより前記リーダーロールを延長することと、を行うように構成される第１のサーバーと、
    第２のサーバーの第３のプロセッサにおいて第２のサービスをホスティングする第２のサーバーであって、前記第２のサービスは、
    前記第３のプロセッサにおいて前記リーダーロールを引き受けるために前記共有ロックファイルへの書き込みを試みることと、
    前記第３のプロセッサにおける変化のプル（pull）レプリケーションを開始するために前記第１のサーバーにシグナルを送ることと、
    前記第３のプロセッサにおいて前記試みが失敗した場合に、パッシブモードのままでいることと、
    前記第３のプロセッサにおいて第２の所定の期間経過後、前記リーダーロールを引き受けるために前記共有ロックファイルへの書き込みを再度試みることと、を行うように構成される第２のサーバーと、
    を備えるシステム。
12. 前記ディレクトリーサービスは、
    前記単一のサーバーが機能しなくなることに応じて、前記第１のプロセッサにおいて前記単一のサーバーのロールの転送、および剥奪のうちの１つを行うことと、
    前記第１のプロセッサにおいて前記ロールを別の単一のサーバーに割り当てることと、
    前記第１のプロセッサにおいて前記共有ロックファイルをその他の単一のサーバーに転送することと、
    前記第１のプロセッサにおいて前記単一のサーバーの変更に関して、前記ドメイン内のサーバーに通知することと、
    を行うようにさらに構成される請求項１１に記載のシステム。
13. 前記第２の所定の期間は、前記ドメイン内の前記サーバーの通知のために、予想される最悪のケースの待ち時間に基づいて判定されることを特徴とする請求項１２に記載のシステム。
14. 前記単一のサーバーは、
    前記ドメインのドメインコントローラーにセキュリティーＲＩＤを割り当てるように構成されるＲＩＤマスターサーバーと、
    前記ドメインにおけるパスワード変更を処理するように構成されるプライマリドメインコントローラー（ＰＤＣ）サーバーと、
    ドメイン間相互に参照されるオブジェクトについてのセキュリティーＩＤ、グローバルユーザーＩＤ（ＧＵＩＤ）、およびドメインネームの組からのうちの少なくとも１つを保持するように構成されるインフラストラクチャーマスターサーバーと、
    のうちの１つであることを特徴とする請求項１１に記載のシステム。
15. 前記ディレクトリーサービスはアクティブディレクトリーサービスであることを特徴とする請求項１４に記載のシステム。
16. 前記ディレクトリーサービスは、
    前記第１のプロセッサにおいてポリシーを割り当てることと、
    前記第１のプロセッサにおいてソフトウェアを配備することと、
    前記第１のプロセッサにおいて前記ドメイン内の前記サーバーに更新を適用することと、
    を行うようにさらに構成されることを特徴とする請求項１１に記載のシステム。
17. 前記第１のサービスは、前記共有ロックファイルへの書き込みによりリーダーロールを引き受けた後、アクティブモードに遷移することを特徴とする請求項１１に記載のシステム。
18. ディレクトリーサービス環境内のプロビジョニングサービスにおいてリーダーアービトレーションを提供するための命令が格納されたコンピューター可読記憶装置であって、前記命令はコンピューターのプロセッサで実行されると、コンピューターに、
    リソースアロケーションのために、リーダーアービトレーションタスクをドメイン内のシングルトンサーバーに割り当てるステップであって、前記シングルトンサーバーは、前記リーダーアービトレーションタスクを円滑にするために共有ロックファイルを保持する、ステップと、
    第１のサービスインスタンスから要求を受信するステップと、
    前記第１のサービスインスタンスが、前記共有ロックファイルへの書き込みによりリーダーロールを引き受けることを可能とさせるステップと、
    前記第１のサービスインスタンスからの更新の要求を受信することに応じて、変化のプル（pull）レプリケーションを開始するために前記第１のサービスインスタンスにシグナルを送るステップと、
    第２のサービスインスタンスから別の要求を受信するステップと、
    前記共有ロックファイルのレコードに基づき、前記第１のサービスインスタンスがいまだに前記リーダーロールを有している場合に、前記第２のサービスインスタンスが前記リーダーロールを引き受けることを拒否するステップと、さもなければ、
    前記第２のサービスインスタンスが、前記共有ロックファイルへ書き込みを行い、前記第２のサービスインスタンスが前記リーダーロールを引き受けることを可能とさせるステップと、
    前記第２のサービスインスタンスから他の更新要求を受信することに応じて、他の変化の他のプルレプリケーションを開始するために前記第２のサービスインスタンスに他のシグナルを送るステップと、
    を実行させることを特徴とするコンピューター可読記憶装置。
19. 前記命令は、
    第１の所定の期間経過後、前記第１のサービスインスタンスが前記共有ロックファイルへの再書き込みにより前記第１のサービスインスタンスのリーダーシップロールを延長することを可能とさせるステップと、
    第２の所定の期間経過後、前記第２のサービスインスタンスが前記共有ロックファイルをチェック可能にするステップであって、前記第２のサービスインスタンスは、前記リーダーロールの引き受けが不可能な場合にパッシブモードのままでいる、ステップをさらにコンピューターに実行させることを特徴とする請求項１８に記載のコンピューター可読記憶装置。
20. 前記ディレクトリーサービス環境内のディレクトリーサービスはアクティブディレクトリーサービスであり、前記シングルトンサーバーはＲＩＤマスターサーバー、プライマリドメインコントローラー（ＰＤＣ）サーバー、インフラストラクチャーマスターのうち１つを含むことを特徴とする、請求項１８に記載のコンピューター可読記憶装置。

Images