JP3674351B2 - マスタサーバ - Google Patents
マスタサーバ Download PDFInfo
- Publication number
- JP3674351B2 JP3674351B2 JP00315499A JP315499A JP3674351B2 JP 3674351 B2 JP3674351 B2 JP 3674351B2 JP 00315499 A JP00315499 A JP 00315499A JP 315499 A JP315499 A JP 315499A JP 3674351 B2 JP3674351 B2 JP 3674351B2
- Authority
- JP
- Japan
- Prior art keywords
- server
- version
- data
- new version
- format
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
Description
【０００１】
【発明の属する技術分野】
本発明は、新旧バージョンのオフィスサーバを混在させた状態で相互接続を可能とさせながら、大規模なオフィスサーバシステムを旧バージョンから順次新バージョンへ移行させる際に有効な、オフィスサーバの移行方式に関する。
【０００２】
【従来の技術】
従来、大規模なオフィスサーバシステムを旧バージョンから新バージョンへ移行する場合、システムに存在する複数のサーバを一括して旧バージョンから新バージョンへ移行する方法や、マスタサーバをまず新バージョンへ移行し、その後各スレーブサーバを順次新バージョンへ移行してゆく方法などが知られている。後者の場合、新バージョンへ移行したスレーブサーバは使用可能なるも、新バージョンへ移行していないスレーブサーバは、システムから切り離されていて、使用できないという運用制限があった。
【０００３】
【発明が解決しようとする課題】
大規模なオフィスサーバシステムを一括して旧バージョンから新バージョンに移行する場合、移行のためのサーバ台数に比例した大量のシステム保守要員の確保が必要となる。
【０００４】
しかしながら、システム保守要員はオフィスサーバシステムの専門的知識が必要であり、一時に大量のシステム保守要員を確保することは非常に困難なことである。また、この方法による移行では、すべてのサーバを旧バージョンから新バージョンへ移行してしまうまではオフィスサーバシステムの運用は停止しておかねばならない。
【０００５】
そのため、一時に大量のシステム保守要員が確保ができないと各サーバを順次バージョンを変えざるを得なくなり、オィスサーバシステムの運用停止期間は長期化する。
【０００６】
一方、旧バージョンのサーバを運用しながら各サーバを順次新バージョンに移行していく場合、新バージョンのオフィスサーバと旧バージョンのオフィスサーバで使用する利用者情報を格納するディレクトリの形式などは第２図で示すように一般的には異なっており、新旧バージョンサーバ間の相互接続ができないという運用制限があった。
【０００７】
本発明の目的は、極力少ないシステム保守要員の確保で、システムを極力停止させずに、オフィスサーバシステムを新バージョンへ移行させることを可能とするシステムを提供することにある。
【０００８】
【課題を解決するための手段】
第１のプログラム（旧バージョン）で扱う第１の形式のデータと、第１のプログラムと類似の処理を実行する第２のプログラム（新バージョン）で扱う、第１の形式のデータと異なる形式の第２の形式の、第１の形式のデータと類似のデータとを共存させながら、第１のプログラムから第２のプログラムへ移行させる課題は、前記第１のプログラムおよび第２のプログラムが動作中で予め設定されている第１の事象の発生を契機に、前記第１の形式のデータを第２の形式のデータへ変換する第１の変換手段と、前記第１のプログラムおよび第２のプログラムが動作中で予め設定されている第２の事象の発生を契機に、前記第２の形式のデータを第１の形式のデータへ変換する第２の変換手段とにより解決される。
【０００９】
【発明の実施の形態】
図１は、本発明の一実施例に係わる新旧データ共存システムの構成を示す図であり、図３は、オフィスサーバシステム全体が旧バージョンのサーバである時の状態を示す図である。図１は、図３で示した旧バージョンのオフィスサーバシステムのマスタサーバ(MS)を新バージョンに移行した状態を示している。
【００１０】
まず、図３について説明する。マスタサーバ(MS)は本社に設置されている。支社Ａにはスレーブサーバ１(SS1) 、支社Ｂにはスレーブサーバ２(SS2) が設置され、おのおの回線を経由してマスタサーバ(MS)に接続されている。
【００１１】
各サーバには、全社の利用者001 〜180 の180 人分の利用者情報が、それぞれのサーバに接続された例えばディスクメモリ(12, 42, 52)に記憶されている。さらに各サーバには、各サーバの設置された支社の利用者情報がやはりディスクメモリ(13, 43, 53)に記憶されている。また、各サーバには、サーバ処理部であるサーバプログラム(11, 44, 54)とリプリケートプログラムであるリプリケータ(15, 41, 51)が備えられている。
【００１２】
サーバプログラムは、アプリケーション処理を実行するものであって、自己のサーバ内で管理するデータについて更新データが発生した場合に、自己のサーバ内で管理するデータを更新する。また、リプリケータは、通知を受けたデータの更新について、自己のサーバと接続されている他のサーバ（データの更新の通知をしたサーバ以外）にデータの更新を行わせる処理を行う。
【００１３】
図３におけるシステムの動作について説明する。例えば、支社Ｂの利用者151 が本社の利用者001 にメールを発信する場合、スレーブサーバ２(SS2) の旧バージョンサーバ処理部（54）は利用者151 から利用者001 に対してメール発信依頼を受けると、先ず旧バージョンローカルディレクトリ（53）を参照する。
【００１４】
ところが、スレーブサーバ２(SS2) の旧バージョンローカルディレクトリ（53）には支社Ｂの利用者情報しか記憶していないため、利用者001 の利用者情報は存在しない。そのため、スレーブサーバ２(SS2) の旧バージョンサーバ処理部（54）は全社の利用者情報を記憶している旧バージョンマスタディレクトリの写し（52）を参照し利用者001 の存在するマスタサーバへ該メールを送信する。
【００１５】
このように、複数のサーバ間で情報をサーバ毎に区分して管理し、他のサーバのデータの記憶している場合には、一つのサーバで発生したデータの更新を他のサーバにも反映させる必要がある。
【００１６】
例えば、上記のように、利用者151 の利用者情報に修正があった場合には、マスタサーバ(MS)だけでなく、他のスレーブサーバにも利用者151 の利用者情報の修正をさせる必要がある。さもなければ、利用者151 へのメール発信ができないことになってしまう。
【００１７】
そこで、このシステムでは、自己のサーバ内で管理しているデータに更新や追加が発生すると、サーバプログラムは、自己のサーバ内で管理するデータを更新する処理と、データの更新があったことをリプリケータに通知する処理を行なう。そして、リプリケータは、自己のサーバに接続されている他のサーバにデータの更新を行わせる処理を行う。
【００１８】
また、接続されている他のサーバからデータの更新依頼の通知を受けたリプリケータは、自己のサーバ内で管理するデータの更新をサーバプログラムに行わせ、自己のサーバに接続されている他のサーバであって、当該データの更新依頼を通知をしたサーバ以外に対して、データの更新を行わせる処理を行う。
【００１９】
これらのリプリケータの処理は、更新対象のデータを情報格納領域(14)に格納して行われる。
【００２０】
図１について説明する。図１は図３で示した旧バージョンのオフィスサーバシステムのマスタサーバ(MS)を新バージョンへの移行の途中状態を示している。マスタサーバ(MS)は、ＣＰＵ、メモリ、ディスクを含むハードウェアから構成されており、その中には旧バージョンサーバ(10)、新バージョンサーバ(20)、およびポンプ機構(30)、旧バージョン形式のマスタディレクトリ(12)を変換して新形式のマスタディレクトリ(22)、およびローカルディレクトリ(23)を生成する変換手段(60)が含まれている。更に各々のサーバ(10 、20) にはそれぞれオフィスシステム全体の利用者の情報が格納されているマスタディレクトリ(12 、22) 、該サーバに直接接続されている利用者の情報が格納されているローカルディレクトリ(13 、23) が接続されている。
【００２１】
旧バージョンサーバ(10)はサーバの処理を行う旧バージョンサーバ処理部(11)、更新対象のデータであって旧バージョン形式のデータ( 旧形式データ) が格納される情報格納領域(14)と、旧バージョン形式のデータの送受信を司る旧バージョンリプリケータ(15)から構成されている。新バージョンサーバ(20)も同様にサーバの処理を行う新バージョンサーバ処理部(21)、更新対象のデータであって新バージョン形式データ（新形式データ）を格納する情報格納領域(24)と、新バージョン形式のデータの送受信を司る新バージョンリプリケータ(25)から構成されている。
【００２２】
なお、上記の情報格納領域(14 、24) については、以下の実施の形態の説明では、他のサーバにデータを更新させる処理が終了すると、情報格納領域の内容を削除されるようになっているが、必ずしも更新処理終了後に削除する必要はなく、どのデータまで更新処理が終了したかを記憶しておいてもよい。さらに、情報格納領域の配置場所についても、主記憶である必要はなく、外部記憶装置にあってもよい。
【００２３】
ポンプ機構(30)は指定された時刻に新バージョンサーバ(20)の新バージョン形式のデータを取り出し旧バージョン形式に変換して旧バージョンサーバ(10)に送り出す、または旧バージョンサーバ(10)の旧バージョン形式のデータを取り出し新バージョン形式のデータに変換し新バージョンサーバ(20)へ送り出すものであり、指定された時間に処理を開始するためのイベントトリガ機構(33)、新バージョン形式のデータを旧バージョン形式のデータへ、または旧バージョン形式のデータを新バージョン形式のデータへ変換するための変換テーブル(31)と、新バージョンサーバ(20)上の新バージョン形式、または旧バージョンサーバ(10)上の旧バージョン形式のデータを旧バージョン形式、または新バージョン形式のデータに変換し旧バージョンサーバ(10)、または新バージョンサーバ(20)に送り出す情報変換処理部(32)から構成されている。
【００２４】
スレーブサーバ(SS1、SS2)は、ＣＰＵ、メモリ、ディスクを含むハードウェアから構成されており、その中にはサーバの処理を行う旧バージョンサーバ処理部(44 、54) と旧バージョン形式のデータの送受信を司る旧バージョンリプリケータ(41 、51) が含まれる。更にこのスレーブサーバ(SS1、SS2)にはマスタサーバ(MS)上にあるオフィスシステム全体の利用者情報が格納されている新バージョンマスタディレクトリ(22)が旧バージョン形式に変換された旧バージョンマスタディレクトリの写し(42 、52) 、およびスレーブサーバ(SS1、SS2)に直接接続されている利用者情報が格納されている旧バージョンローカルディレクトリ(43 、53) が接続されている。
【００２５】
スレーブサーバ(SS1、SS2)を新バージョンに移行すると、旧バージョンサーバ処理部(44 、54) は新バージョン処理部に、旧バージョンリプリケータ(41 、51) は新バージョンリプリケータに、旧バージョンマスタディレクトリの写し(42 、52) は新バージョンマスタディレクトリの写しに、旧バージョンローカルディレクトリ(43 、53) は新バージョンローカルディレクトリに置き換えられる。
【００２６】
この時、接続すべき上位のサーバの新バージョンのシステムに、新バージョンに移行したスレーブサーバを登録すると共に、これまで接続していた上位のサーバの旧バージョンのシステムから当該スレーブサーバの登録を削除する。
【００２７】
マスタサーバ、およびマスタサーバ配下の複数のスレーブサーバの１つのまとまりをエリアと呼ぶ。エリア内の移行順番は、最初にマスタサーバの移行を行うことを除き、各スレーブサーバの移行順番は任意である。
【００２８】
図４はエリア内の各スレーブサーバの移行例の推移を示してある。
【００２９】
図４の（１）は、図３の状態と同じで、エリア全体が旧バージョンのままの状態である。
【００３０】
（２）は、図１の状態と同じで、マスターサーバを新バーションに移行した状態である。スレーブサーバはいずれもマスタサーバの旧バージョンサーバ側に接続されている。
【００３１】
（３）は、スレーブサーバ２を新バージョンに移行した状態であり、スレーブサーバ２はマスタサーバの新バージョンサーバ側に接続されている。
【００３２】
（４）は、スレーブサーバ１を新バージョンに移行した状態であり、スレーブサーバ１もマスタサーバの新バージョンサーバ側に接続されている。
【００３３】
（５）は、エリア内のすべてのサーバのプログラムを新バージョンに移行し、マスタサーバ上の旧バージョンサーバとポンプ機構を削除し、エリア全体の新バージョンへの移行が完了した状態である。
【００３４】
本実施例では、1 つのエリアで構成されたオフィスサーバシステムについて説明しているが、実際のオフィスサーバシステムの構成は複数のエリアが並列、階層構造、またはその組み合わせで接続されている場合が一般的である。各エリアを、それぞれ前記のように旧バージョンから新バージョンに移行するとオフィスサーバ全体の移行が可能となる。
【００３５】
以下に、旧バージョン形式と新バージョン形式のデレクトリ共存を許す本発明の詳細について図面を参照して説明する。
【００３６】
図１において、マスタサーバ(MS)に新バージョンがインストールされると、マスタサーバ(MS)のハードウェアには新バージョンサーバ(20)とポンプ機構(30)、および旧バーョンマスタディレクトリ(12)から新バージョンマスタディレクトリ(22)と新バージョンローカルディレクトリ(23)を生成する変換手段(60)が追加される。元から存在する旧バージョンサーバ(10)は旧バージョンのスレーブサーバ(SS1、SS2)に対応し、新バージョンサーバ(20)は今後、移行される新バージョンのスレーブサーバと対応することにより、スレーブサーバが新旧いずれのバージョンであっても接続することが可能となる。
【００３７】
マスタサーバ(MS)上の新バージョンサーバ(20)を動作可能とするためには、旧バージョンサーバ(10)に接続されている旧バージョンマスタディレクトリ(12)を変換手段(60)を使用して新バージョンマスタディレクトリ(22)と新バージョンローカルディレクトリ(23)を生成する。以後マスタサーバ(MS)上では新バージョンマスタディレクトリ(22)と新バージョンローカルディレクトリ(23)のみが有効なディレクトリとなる。なお、この作業を実施している間はマスタサーバの旧バージョンリプリケータ(15)とスレーブサーバ１(SS1) の旧バージョンリプリケータ(41)、およびスレーブサーバ２(SS2) の旧バージョンリプリケータ(51)との接続は無効にしておくため、この間のみはオフィスサーバシステムは運用停止となる。
【００３８】
図５は、図３におけるスレーブサーバ２(SS2) に新たな利用者181 が追加された時の処理フローを示している。スレーブサーバ２（SS2)に新たに利用者181 が追加されると、旧バージョンサーバ処理部(44)はスレーブサーバ２(SS2) に接続されている旧バージョンローカルディレクトリ(53)に利用者181 の利用者情報を追加し（図5-S501) 、マスタサーバ(MS)に利用者181 が追加されたことを通知するために、旧バージョンリプリケータ(51)に旧バージョンローカルディレクトリ(53)の更新情報を通知する（図5-S502) 。
【００３９】
旧バージョンリプリケータ(51)はマスタサーバの旧バージョンリプリケータ(15)にスレーブサーバ２(SS2) の旧バージョンローカルディレクトリ(53)の更新情報を転送する（図5-S503) 。
【００４０】
マスタサーバ(MS)の旧バージョンリプリケータ(15)はスレーブサーバ２(SS2) の旧バージョンローカルディレクトリ(53)の更新情報を情報格納領域(14)に蓄積格納する（図5-S504) 。
【００４１】
この状態ではスレーブ２(SS2) のローカルディレクトリには利用者181 の利用者情報が追加されているため、スレーブ２(SS2) に直接接続されているクライアントからは利用者181 へのメール送信は可能であるが、マスタサーバ(MS)やスレーブサーバ１(SS1) に接続されているクライアントからは利用者181 へのメール送信はできない。
【００４２】
なお、図５には図示していないが、情報格納領域(14)に格納されている変更情報は、この後、ポンプ機構からの指示により、旧バージョンリプリケータ(15)が、当該旧バージョンに接続されるスレーブサーバの旧バージョンリプリケータに変更情報を通知する。例えば、この変更通知を受けたスレーブサーバ１(SS1) の旧バージョンリプリケータ(41)が旧バージョンサーバ処理部(44)を介して自己の旧バージョンマスタディレクトリの写し(42)を更新する。
【００４３】
本実施例では、更新を頻繁に発生しないように、ポンプ機構の指示により更新を実行しているが、更新の発生の度に旧バージョンに接続されるスレーブサーバの旧バージョンリプリケータに変更情報を通知してもよい。
【００４４】
図６は、図１において旧バージョン形式のディレクトリ更新情報をマスタサーバ(MS)の新バージョンマスタディレクトリ(22)に反映させる処理を示している。１日当たりのディレクトリ更新回数、ディレクトリの更新時刻、ディレクトリの更新時間間隔、ＣＰＵの使用状況をモニタし、システムの負荷が低い時間など設定された時刻が来る（図6-S601) と、イベントトリガ機構(33)が働き、情報変換処理部(32)を起動する。
【００４５】
情報変換処理部(32)は起動されると、情報格納領域(14)に変換すべき旧バージョン形式のスレーブサーバ(SS1、SS2)のディレクトリ更新情報があるかどうか調べ（図6-S602）、変換すべき情報が存在する場合は、変換テーブル(31)を参照し、旧バージョン形式のディレクトリ更新情報を新バージョン形式のディレクトリ更新情報に変換し、新バージョンリプリケータ(25)に通知すると共に、情報格納領域(14)の旧バージョン形式のディレクトリ更新情報をクリアする（図6-S603) 。
【００４６】
新バージョンリプリケータ(25)は、新バージョン形式に変換されたディレクトリ変更情報を情報格納領域(24)に蓄積格納すると共に、新バージョンサーバ処理部(21)に新バージョンマスタディレクトリ(22)の更新依頼する（図6-S604）。新バージョンサーバ処理部(21)は情報格納領域(24)に蓄積格納されている新バージョン形式のディレクトリ更新情報を新バージョンマスタディレクトリ(22)に反映させると共に、情報格納領域(24)に蓄積格納されている新バージョン形式のディレクトリ更新情報をクリアする（図6-S605) 。
【００４７】
図６には図示していないが、新バージョンのリプリケータ(25)は、情報格納領域(24)に格納されている変更情報に基づいて、当該新バージョンに接続されるスレーブサーバの新バージョンリプリケータに変更情報を通知する。
【００４８】
図７は、図１においてマスタサーバ(MS)の既存の利用者001 の利用者情報が更新された場合の処理フローを示している。マスタサーバ(MS)に接続されているクライアントの利用者001 の利用者情報が更新されると、マスタサーバ(MS)の新バージョンサーバ処理部(21)は新バージョンローカルディレクトリ(23)の利用者001 の利用者情報を更新する（図7-S701) 。新バージョンサーバ処理部(21)はマスタサーバ(MS)の新バージョンリプリケータ(25)に新バージョンローカルディレクトリ(23)の更新情報を通知する（図7-S702) 。
【００４９】
マスタサーバ(MS)の新バージョンリプリケータ(25)は新バージョンローカルディレクトリ(23)の更新情報を情報格納領域(24)に蓄積格納する（図7-S703) 。
【００５０】
第８図は、第１図において新バージョンマスタディレクトリ(22)の更新情報の各スレーブサーバ(SS1、SS2)への配信処理を示している。１日当たりのディレクトリ更新回数、ディレクトリの更新時刻、ディレクトリの更新時間間隔、ＣＰＵの使用状況をモニタしシステムの負荷が低い時間など設定された時刻が来る（図8-S801) と、イベントトリガ機構(33)が働き、情報変換処理部(32)を起動する。
【００５１】
情報変換処理部(32)は起動されると、先ず情報格納領域(14)に旧バージョン形式の更新情報の未変換データがないかどうか確認する（図8-S802) 。もし未だ新バージョン形式に変換されていない旧バージョン形式の更新情報が残っている場合には、図５、図６で示したように旧バージョン形式の更新情報を新バージョン更新情報に変換し、スレーブサーバ(SS1、SS2)のローカルディレクトリ(43 、53) への更新情報がマスタサーバ(MS)の新バージョンマスタディレクトリ(22)への反映処理を行う（図8-S803) 。
【００５２】
スレーブサーバ(SS1、SS2)のローカルディレクトリ(43 、53) の更新がマスタサーバ(MS)の新バージョンマスタディレクトリ(22)に反映できると、情報変換処理部(32)は情報格納領域(24)に変換すべき新バージョン形式のディレクトリ更新情報があるかどうか調べ（図8-S804) 、変換すべき情報が存在する場合は、変換テーブル(31)を参照し、新バージョン形式のディレクトリ更新情報を旧バージョン形式のディレクトリ更新情報に変換し、旧バージョンリプリケータ(15)に通知すると共に、情報格納領域(24)の新バージョン形式のディレクトリ更新情報をクリアする（図8-S805) 。
【００５３】
旧バージョンリプリケータ(15)は、旧バージョン形式に変換されたディレクトリ変更情報を、スレーブサーバ(SS1、SS2)の旧バージョンリプリケータ(41 、51) に旧バージョン形式のディレクトリ更新情報を転送する（図8-S806) 。
【００５４】
スレーブサーバ(SS1、SS2)の旧バージョンリプリケータ(41 、51) は、旧バージョンサーバ処理部(44 、54) にマスタディレクトリの写しの更新依頼を行う（図8-S807) 。
【００５５】
それぞれの旧バージョンサーバ処理部(44 、54) は、各々の旧バージョンマスタディレクトリの写し(42 、52) の更新処理を行う（図8-S808) 。
【００５６】
各サーバに直接接続されているクライアントの利用者の利用者更新情報は、その利用者が接続されているサーバのローカルディレクトリには利用者情報が更新された時点で更新される。ところが、マスタサーバのマスタディレクトリ、およびスレーブサーバのマスタディレクトリの写しはマスタサーバのローカルディレクトリ、またはスレーブサーバのローカルディレクトリの更新時点においては通常更新はされない。
【００５７】
一般的に、利用者の利用者更新情報はリアルタイムに反映されなければならないことは少なく、オフィスサーバシステム全体の負荷や、特徴などに合わせた運用の方が効果的なためである。本実施例では、旧バージョン形式の更新情報と新バージョン形式の更新情報の形式変換のトリガはそれぞれ別に指定することができるようになっており、もし、ローカルディレクトリとマスタディレクトリを同期を取って更新させたい場合にはイベントトリガ機構の時間監視をそのように設定すればよい。
【００５８】
スレーブサーバを旧バージョンから新バージョンに移行する場合は、各スレーブサーバのハードウェアに新バージョンのオフィスサーバのリソースのみが旧オフィスサーバと置き換えられる。スレーブサーバの移行時は移行中のスレーブサーバの利用者のみオフィスサーバシステムの利用ができなくなるが、オフィスサーバシステムの運用は続行可能である。スレーブサーバが新バージョンに置き代わるとスレーブサーバ側の新バージョンリプリケータとマスタサーバ側の新バージョンリプリケータが接続されスレーブサーバ側のオフィスサーバシステムの運用が開始される。
【００５９】
なお、接続前に予め、マスタサーバの新バージョンに対して、当該スレーブサーバを登録を行うと共に、マスタサーバの旧バージョンから当該スレーブサーバの登録を削除する。また、当該スレーブサーバの新バージョンについても、接続するマスタサーバを登録する。
【００６０】
上記のように、スレーブサーバを順次新バージョンへ移行し、すべてのスレーブサーバの移行が完了すると旧バージョンマスタサーバを削除し、エリア全体の新バージョンへの移行が完了する。そして、最後にポンプ機構を削除して全ての移行処理が完了する。
【００６１】
上記では、２階層の例で説明したが、３階層以上であっても同様に行う。但し、第２階層のサーバにさらに下位の第３階層のサーバ（スレーブサーバ）が接続されている場合には、まず、第２階層のサーバに、新バージョンとポンプ機構をインストールする。そして下位の第３階層のサーバがすべて新バージョンに移行した後にはじめて第２階層のサーバを新バージョンのみにする（旧バージョンとポンプ機構を削除する）。
【００６２】
さらに、第２階層のサーバが全て新バージョンに移行してはじめて最上位の第１階層のサーバを新バージョンのみにする（旧バージョンとポンプ機構を削除する）。
【００６３】
【発明の効果】
以上説明したように、本発明によれば、一時期にオフィスサーバの専門的知識を要するシステム保守要員を大量に確保する必要はなく、極力少ないシステム保守要員の確保でオフィスサーバシステムの旧バージョンから新バージョンへの移行が可能となる。
【００６４】
なお、新バージョン形式のデータを旧バージョン形式のデータへ、または旧バージョン形式のデータを新バージョン形式のデータへ変換する場合には、変換テーブルを利用することにより処理スピードの向上、およびＣＰＵの負荷削減を実現している。
【００６５】
また、オフィスサーバシステムの旧バージョンから新バージョンの移行時に発生するオフィスサーバシステムの運用停止時間はマスタサーバの移行時にのみに局所化でき、新旧バージョンのスレーブサーバが混在したオフィスサーバシステムの運用可能となる。
【００６６】
更に、指定した時刻に前記変換手段（ポンプ機構) を起動させることができるため、該オフィスサーバシステムの特徴に合わせて、例えばマスタサーバのマスタディレクトリの更新は１時間置きに、スレーブサーバのマスタディレクトリの写しの更新は夜間バッチで行うなど、オフィスサーバシステム全体のシステム効率を考慮した運用が可能となる。
【図面の簡単な説明】
【図１】本発明に係わるシステム構成図
【図２】新旧バージョンのディレクトリ内容の相違例
【図３】旧バージョンシステム構成例
【図４】サーバの移行例
【図５】スレーブサーバ２に利用者181 が追加された場合の処理フロー
【図６】スレーブサーバの利用者情報（旧バージョン形式）更新のマスタディレクトリへの反映処理
【図７】新バージョン形式の更新情報（マスタサーバの利用者001 の利用者情報が更新された場合）の処理フロー
【図８】新バージョン形式の更新情報の配信処理フロー
【符号の説明】
１０ 旧バージョンサーバ
１１ 旧バージョンサーバ処理部
１４、２４ 情報格納領域
１５ 旧バーションリプリケータ
２０ 新バージョンサーバ
２１ 新バージョンサーバ処理部
２５ 新バージョンリプリケータ
３１ 変換テーブル
３２ 情報変換処理部
３３ イベントトリガ機構
【発明の属する技術分野】
本発明は、新旧バージョンのオフィスサーバを混在させた状態で相互接続を可能とさせながら、大規模なオフィスサーバシステムを旧バージョンから順次新バージョンへ移行させる際に有効な、オフィスサーバの移行方式に関する。
【０００２】
【従来の技術】
従来、大規模なオフィスサーバシステムを旧バージョンから新バージョンへ移行する場合、システムに存在する複数のサーバを一括して旧バージョンから新バージョンへ移行する方法や、マスタサーバをまず新バージョンへ移行し、その後各スレーブサーバを順次新バージョンへ移行してゆく方法などが知られている。後者の場合、新バージョンへ移行したスレーブサーバは使用可能なるも、新バージョンへ移行していないスレーブサーバは、システムから切り離されていて、使用できないという運用制限があった。
【０００３】
【発明が解決しようとする課題】
大規模なオフィスサーバシステムを一括して旧バージョンから新バージョンに移行する場合、移行のためのサーバ台数に比例した大量のシステム保守要員の確保が必要となる。
【０００４】
しかしながら、システム保守要員はオフィスサーバシステムの専門的知識が必要であり、一時に大量のシステム保守要員を確保することは非常に困難なことである。また、この方法による移行では、すべてのサーバを旧バージョンから新バージョンへ移行してしまうまではオフィスサーバシステムの運用は停止しておかねばならない。
【０００５】
そのため、一時に大量のシステム保守要員が確保ができないと各サーバを順次バージョンを変えざるを得なくなり、オィスサーバシステムの運用停止期間は長期化する。
【０００６】
一方、旧バージョンのサーバを運用しながら各サーバを順次新バージョンに移行していく場合、新バージョンのオフィスサーバと旧バージョンのオフィスサーバで使用する利用者情報を格納するディレクトリの形式などは第２図で示すように一般的には異なっており、新旧バージョンサーバ間の相互接続ができないという運用制限があった。
【０００７】
本発明の目的は、極力少ないシステム保守要員の確保で、システムを極力停止させずに、オフィスサーバシステムを新バージョンへ移行させることを可能とするシステムを提供することにある。
【０００８】
【課題を解決するための手段】
第１のプログラム（旧バージョン）で扱う第１の形式のデータと、第１のプログラムと類似の処理を実行する第２のプログラム（新バージョン）で扱う、第１の形式のデータと異なる形式の第２の形式の、第１の形式のデータと類似のデータとを共存させながら、第１のプログラムから第２のプログラムへ移行させる課題は、前記第１のプログラムおよび第２のプログラムが動作中で予め設定されている第１の事象の発生を契機に、前記第１の形式のデータを第２の形式のデータへ変換する第１の変換手段と、前記第１のプログラムおよび第２のプログラムが動作中で予め設定されている第２の事象の発生を契機に、前記第２の形式のデータを第１の形式のデータへ変換する第２の変換手段とにより解決される。
【０００９】
【発明の実施の形態】
図１は、本発明の一実施例に係わる新旧データ共存システムの構成を示す図であり、図３は、オフィスサーバシステム全体が旧バージョンのサーバである時の状態を示す図である。図１は、図３で示した旧バージョンのオフィスサーバシステムのマスタサーバ(MS)を新バージョンに移行した状態を示している。
【００１０】
まず、図３について説明する。マスタサーバ(MS)は本社に設置されている。支社Ａにはスレーブサーバ１(SS1) 、支社Ｂにはスレーブサーバ２(SS2) が設置され、おのおの回線を経由してマスタサーバ(MS)に接続されている。
【００１１】
各サーバには、全社の利用者001 〜180 の180 人分の利用者情報が、それぞれのサーバに接続された例えばディスクメモリ(12, 42, 52)に記憶されている。さらに各サーバには、各サーバの設置された支社の利用者情報がやはりディスクメモリ(13, 43, 53)に記憶されている。また、各サーバには、サーバ処理部であるサーバプログラム(11, 44, 54)とリプリケートプログラムであるリプリケータ(15, 41, 51)が備えられている。
【００１２】
サーバプログラムは、アプリケーション処理を実行するものであって、自己のサーバ内で管理するデータについて更新データが発生した場合に、自己のサーバ内で管理するデータを更新する。また、リプリケータは、通知を受けたデータの更新について、自己のサーバと接続されている他のサーバ（データの更新の通知をしたサーバ以外）にデータの更新を行わせる処理を行う。
【００１３】
図３におけるシステムの動作について説明する。例えば、支社Ｂの利用者151 が本社の利用者001 にメールを発信する場合、スレーブサーバ２(SS2) の旧バージョンサーバ処理部（54）は利用者151 から利用者001 に対してメール発信依頼を受けると、先ず旧バージョンローカルディレクトリ（53）を参照する。
【００１４】
ところが、スレーブサーバ２(SS2) の旧バージョンローカルディレクトリ（53）には支社Ｂの利用者情報しか記憶していないため、利用者001 の利用者情報は存在しない。そのため、スレーブサーバ２(SS2) の旧バージョンサーバ処理部（54）は全社の利用者情報を記憶している旧バージョンマスタディレクトリの写し（52）を参照し利用者001 の存在するマスタサーバへ該メールを送信する。
【００１５】
このように、複数のサーバ間で情報をサーバ毎に区分して管理し、他のサーバのデータの記憶している場合には、一つのサーバで発生したデータの更新を他のサーバにも反映させる必要がある。
【００１６】
例えば、上記のように、利用者151 の利用者情報に修正があった場合には、マスタサーバ(MS)だけでなく、他のスレーブサーバにも利用者151 の利用者情報の修正をさせる必要がある。さもなければ、利用者151 へのメール発信ができないことになってしまう。
【００１７】
そこで、このシステムでは、自己のサーバ内で管理しているデータに更新や追加が発生すると、サーバプログラムは、自己のサーバ内で管理するデータを更新する処理と、データの更新があったことをリプリケータに通知する処理を行なう。そして、リプリケータは、自己のサーバに接続されている他のサーバにデータの更新を行わせる処理を行う。
【００１８】
また、接続されている他のサーバからデータの更新依頼の通知を受けたリプリケータは、自己のサーバ内で管理するデータの更新をサーバプログラムに行わせ、自己のサーバに接続されている他のサーバであって、当該データの更新依頼を通知をしたサーバ以外に対して、データの更新を行わせる処理を行う。
【００１９】
これらのリプリケータの処理は、更新対象のデータを情報格納領域(14)に格納して行われる。
【００２０】
図１について説明する。図１は図３で示した旧バージョンのオフィスサーバシステムのマスタサーバ(MS)を新バージョンへの移行の途中状態を示している。マスタサーバ(MS)は、ＣＰＵ、メモリ、ディスクを含むハードウェアから構成されており、その中には旧バージョンサーバ(10)、新バージョンサーバ(20)、およびポンプ機構(30)、旧バージョン形式のマスタディレクトリ(12)を変換して新形式のマスタディレクトリ(22)、およびローカルディレクトリ(23)を生成する変換手段(60)が含まれている。更に各々のサーバ(10 、20) にはそれぞれオフィスシステム全体の利用者の情報が格納されているマスタディレクトリ(12 、22) 、該サーバに直接接続されている利用者の情報が格納されているローカルディレクトリ(13 、23) が接続されている。
【００２１】
旧バージョンサーバ(10)はサーバの処理を行う旧バージョンサーバ処理部(11)、更新対象のデータであって旧バージョン形式のデータ( 旧形式データ) が格納される情報格納領域(14)と、旧バージョン形式のデータの送受信を司る旧バージョンリプリケータ(15)から構成されている。新バージョンサーバ(20)も同様にサーバの処理を行う新バージョンサーバ処理部(21)、更新対象のデータであって新バージョン形式データ（新形式データ）を格納する情報格納領域(24)と、新バージョン形式のデータの送受信を司る新バージョンリプリケータ(25)から構成されている。
【００２２】
なお、上記の情報格納領域(14 、24) については、以下の実施の形態の説明では、他のサーバにデータを更新させる処理が終了すると、情報格納領域の内容を削除されるようになっているが、必ずしも更新処理終了後に削除する必要はなく、どのデータまで更新処理が終了したかを記憶しておいてもよい。さらに、情報格納領域の配置場所についても、主記憶である必要はなく、外部記憶装置にあってもよい。
【００２３】
ポンプ機構(30)は指定された時刻に新バージョンサーバ(20)の新バージョン形式のデータを取り出し旧バージョン形式に変換して旧バージョンサーバ(10)に送り出す、または旧バージョンサーバ(10)の旧バージョン形式のデータを取り出し新バージョン形式のデータに変換し新バージョンサーバ(20)へ送り出すものであり、指定された時間に処理を開始するためのイベントトリガ機構(33)、新バージョン形式のデータを旧バージョン形式のデータへ、または旧バージョン形式のデータを新バージョン形式のデータへ変換するための変換テーブル(31)と、新バージョンサーバ(20)上の新バージョン形式、または旧バージョンサーバ(10)上の旧バージョン形式のデータを旧バージョン形式、または新バージョン形式のデータに変換し旧バージョンサーバ(10)、または新バージョンサーバ(20)に送り出す情報変換処理部(32)から構成されている。
【００２４】
スレーブサーバ(SS1、SS2)は、ＣＰＵ、メモリ、ディスクを含むハードウェアから構成されており、その中にはサーバの処理を行う旧バージョンサーバ処理部(44 、54) と旧バージョン形式のデータの送受信を司る旧バージョンリプリケータ(41 、51) が含まれる。更にこのスレーブサーバ(SS1、SS2)にはマスタサーバ(MS)上にあるオフィスシステム全体の利用者情報が格納されている新バージョンマスタディレクトリ(22)が旧バージョン形式に変換された旧バージョンマスタディレクトリの写し(42 、52) 、およびスレーブサーバ(SS1、SS2)に直接接続されている利用者情報が格納されている旧バージョンローカルディレクトリ(43 、53) が接続されている。
【００２５】
スレーブサーバ(SS1、SS2)を新バージョンに移行すると、旧バージョンサーバ処理部(44 、54) は新バージョン処理部に、旧バージョンリプリケータ(41 、51) は新バージョンリプリケータに、旧バージョンマスタディレクトリの写し(42 、52) は新バージョンマスタディレクトリの写しに、旧バージョンローカルディレクトリ(43 、53) は新バージョンローカルディレクトリに置き換えられる。
【００２６】
この時、接続すべき上位のサーバの新バージョンのシステムに、新バージョンに移行したスレーブサーバを登録すると共に、これまで接続していた上位のサーバの旧バージョンのシステムから当該スレーブサーバの登録を削除する。
【００２７】
マスタサーバ、およびマスタサーバ配下の複数のスレーブサーバの１つのまとまりをエリアと呼ぶ。エリア内の移行順番は、最初にマスタサーバの移行を行うことを除き、各スレーブサーバの移行順番は任意である。
【００２８】
図４はエリア内の各スレーブサーバの移行例の推移を示してある。
【００２９】
図４の（１）は、図３の状態と同じで、エリア全体が旧バージョンのままの状態である。
【００３０】
（２）は、図１の状態と同じで、マスターサーバを新バーションに移行した状態である。スレーブサーバはいずれもマスタサーバの旧バージョンサーバ側に接続されている。
【００３１】
（３）は、スレーブサーバ２を新バージョンに移行した状態であり、スレーブサーバ２はマスタサーバの新バージョンサーバ側に接続されている。
【００３２】
（４）は、スレーブサーバ１を新バージョンに移行した状態であり、スレーブサーバ１もマスタサーバの新バージョンサーバ側に接続されている。
【００３３】
（５）は、エリア内のすべてのサーバのプログラムを新バージョンに移行し、マスタサーバ上の旧バージョンサーバとポンプ機構を削除し、エリア全体の新バージョンへの移行が完了した状態である。
【００３４】
本実施例では、1 つのエリアで構成されたオフィスサーバシステムについて説明しているが、実際のオフィスサーバシステムの構成は複数のエリアが並列、階層構造、またはその組み合わせで接続されている場合が一般的である。各エリアを、それぞれ前記のように旧バージョンから新バージョンに移行するとオフィスサーバ全体の移行が可能となる。
【００３５】
以下に、旧バージョン形式と新バージョン形式のデレクトリ共存を許す本発明の詳細について図面を参照して説明する。
【００３６】
図１において、マスタサーバ(MS)に新バージョンがインストールされると、マスタサーバ(MS)のハードウェアには新バージョンサーバ(20)とポンプ機構(30)、および旧バーョンマスタディレクトリ(12)から新バージョンマスタディレクトリ(22)と新バージョンローカルディレクトリ(23)を生成する変換手段(60)が追加される。元から存在する旧バージョンサーバ(10)は旧バージョンのスレーブサーバ(SS1、SS2)に対応し、新バージョンサーバ(20)は今後、移行される新バージョンのスレーブサーバと対応することにより、スレーブサーバが新旧いずれのバージョンであっても接続することが可能となる。
【００３７】
マスタサーバ(MS)上の新バージョンサーバ(20)を動作可能とするためには、旧バージョンサーバ(10)に接続されている旧バージョンマスタディレクトリ(12)を変換手段(60)を使用して新バージョンマスタディレクトリ(22)と新バージョンローカルディレクトリ(23)を生成する。以後マスタサーバ(MS)上では新バージョンマスタディレクトリ(22)と新バージョンローカルディレクトリ(23)のみが有効なディレクトリとなる。なお、この作業を実施している間はマスタサーバの旧バージョンリプリケータ(15)とスレーブサーバ１(SS1) の旧バージョンリプリケータ(41)、およびスレーブサーバ２(SS2) の旧バージョンリプリケータ(51)との接続は無効にしておくため、この間のみはオフィスサーバシステムは運用停止となる。
【００３８】
図５は、図３におけるスレーブサーバ２(SS2) に新たな利用者181 が追加された時の処理フローを示している。スレーブサーバ２（SS2)に新たに利用者181 が追加されると、旧バージョンサーバ処理部(44)はスレーブサーバ２(SS2) に接続されている旧バージョンローカルディレクトリ(53)に利用者181 の利用者情報を追加し（図5-S501) 、マスタサーバ(MS)に利用者181 が追加されたことを通知するために、旧バージョンリプリケータ(51)に旧バージョンローカルディレクトリ(53)の更新情報を通知する（図5-S502) 。
【００３９】
旧バージョンリプリケータ(51)はマスタサーバの旧バージョンリプリケータ(15)にスレーブサーバ２(SS2) の旧バージョンローカルディレクトリ(53)の更新情報を転送する（図5-S503) 。
【００４０】
マスタサーバ(MS)の旧バージョンリプリケータ(15)はスレーブサーバ２(SS2) の旧バージョンローカルディレクトリ(53)の更新情報を情報格納領域(14)に蓄積格納する（図5-S504) 。
【００４１】
この状態ではスレーブ２(SS2) のローカルディレクトリには利用者181 の利用者情報が追加されているため、スレーブ２(SS2) に直接接続されているクライアントからは利用者181 へのメール送信は可能であるが、マスタサーバ(MS)やスレーブサーバ１(SS1) に接続されているクライアントからは利用者181 へのメール送信はできない。
【００４２】
なお、図５には図示していないが、情報格納領域(14)に格納されている変更情報は、この後、ポンプ機構からの指示により、旧バージョンリプリケータ(15)が、当該旧バージョンに接続されるスレーブサーバの旧バージョンリプリケータに変更情報を通知する。例えば、この変更通知を受けたスレーブサーバ１(SS1) の旧バージョンリプリケータ(41)が旧バージョンサーバ処理部(44)を介して自己の旧バージョンマスタディレクトリの写し(42)を更新する。
【００４３】
本実施例では、更新を頻繁に発生しないように、ポンプ機構の指示により更新を実行しているが、更新の発生の度に旧バージョンに接続されるスレーブサーバの旧バージョンリプリケータに変更情報を通知してもよい。
【００４４】
図６は、図１において旧バージョン形式のディレクトリ更新情報をマスタサーバ(MS)の新バージョンマスタディレクトリ(22)に反映させる処理を示している。１日当たりのディレクトリ更新回数、ディレクトリの更新時刻、ディレクトリの更新時間間隔、ＣＰＵの使用状況をモニタし、システムの負荷が低い時間など設定された時刻が来る（図6-S601) と、イベントトリガ機構(33)が働き、情報変換処理部(32)を起動する。
【００４５】
情報変換処理部(32)は起動されると、情報格納領域(14)に変換すべき旧バージョン形式のスレーブサーバ(SS1、SS2)のディレクトリ更新情報があるかどうか調べ（図6-S602）、変換すべき情報が存在する場合は、変換テーブル(31)を参照し、旧バージョン形式のディレクトリ更新情報を新バージョン形式のディレクトリ更新情報に変換し、新バージョンリプリケータ(25)に通知すると共に、情報格納領域(14)の旧バージョン形式のディレクトリ更新情報をクリアする（図6-S603) 。
【００４６】
新バージョンリプリケータ(25)は、新バージョン形式に変換されたディレクトリ変更情報を情報格納領域(24)に蓄積格納すると共に、新バージョンサーバ処理部(21)に新バージョンマスタディレクトリ(22)の更新依頼する（図6-S604）。新バージョンサーバ処理部(21)は情報格納領域(24)に蓄積格納されている新バージョン形式のディレクトリ更新情報を新バージョンマスタディレクトリ(22)に反映させると共に、情報格納領域(24)に蓄積格納されている新バージョン形式のディレクトリ更新情報をクリアする（図6-S605) 。
【００４７】
図６には図示していないが、新バージョンのリプリケータ(25)は、情報格納領域(24)に格納されている変更情報に基づいて、当該新バージョンに接続されるスレーブサーバの新バージョンリプリケータに変更情報を通知する。
【００４８】
図７は、図１においてマスタサーバ(MS)の既存の利用者001 の利用者情報が更新された場合の処理フローを示している。マスタサーバ(MS)に接続されているクライアントの利用者001 の利用者情報が更新されると、マスタサーバ(MS)の新バージョンサーバ処理部(21)は新バージョンローカルディレクトリ(23)の利用者001 の利用者情報を更新する（図7-S701) 。新バージョンサーバ処理部(21)はマスタサーバ(MS)の新バージョンリプリケータ(25)に新バージョンローカルディレクトリ(23)の更新情報を通知する（図7-S702) 。
【００４９】
マスタサーバ(MS)の新バージョンリプリケータ(25)は新バージョンローカルディレクトリ(23)の更新情報を情報格納領域(24)に蓄積格納する（図7-S703) 。
【００５０】
第８図は、第１図において新バージョンマスタディレクトリ(22)の更新情報の各スレーブサーバ(SS1、SS2)への配信処理を示している。１日当たりのディレクトリ更新回数、ディレクトリの更新時刻、ディレクトリの更新時間間隔、ＣＰＵの使用状況をモニタしシステムの負荷が低い時間など設定された時刻が来る（図8-S801) と、イベントトリガ機構(33)が働き、情報変換処理部(32)を起動する。
【００５１】
情報変換処理部(32)は起動されると、先ず情報格納領域(14)に旧バージョン形式の更新情報の未変換データがないかどうか確認する（図8-S802) 。もし未だ新バージョン形式に変換されていない旧バージョン形式の更新情報が残っている場合には、図５、図６で示したように旧バージョン形式の更新情報を新バージョン更新情報に変換し、スレーブサーバ(SS1、SS2)のローカルディレクトリ(43 、53) への更新情報がマスタサーバ(MS)の新バージョンマスタディレクトリ(22)への反映処理を行う（図8-S803) 。
【００５２】
スレーブサーバ(SS1、SS2)のローカルディレクトリ(43 、53) の更新がマスタサーバ(MS)の新バージョンマスタディレクトリ(22)に反映できると、情報変換処理部(32)は情報格納領域(24)に変換すべき新バージョン形式のディレクトリ更新情報があるかどうか調べ（図8-S804) 、変換すべき情報が存在する場合は、変換テーブル(31)を参照し、新バージョン形式のディレクトリ更新情報を旧バージョン形式のディレクトリ更新情報に変換し、旧バージョンリプリケータ(15)に通知すると共に、情報格納領域(24)の新バージョン形式のディレクトリ更新情報をクリアする（図8-S805) 。
【００５３】
旧バージョンリプリケータ(15)は、旧バージョン形式に変換されたディレクトリ変更情報を、スレーブサーバ(SS1、SS2)の旧バージョンリプリケータ(41 、51) に旧バージョン形式のディレクトリ更新情報を転送する（図8-S806) 。
【００５４】
スレーブサーバ(SS1、SS2)の旧バージョンリプリケータ(41 、51) は、旧バージョンサーバ処理部(44 、54) にマスタディレクトリの写しの更新依頼を行う（図8-S807) 。
【００５５】
それぞれの旧バージョンサーバ処理部(44 、54) は、各々の旧バージョンマスタディレクトリの写し(42 、52) の更新処理を行う（図8-S808) 。
【００５６】
各サーバに直接接続されているクライアントの利用者の利用者更新情報は、その利用者が接続されているサーバのローカルディレクトリには利用者情報が更新された時点で更新される。ところが、マスタサーバのマスタディレクトリ、およびスレーブサーバのマスタディレクトリの写しはマスタサーバのローカルディレクトリ、またはスレーブサーバのローカルディレクトリの更新時点においては通常更新はされない。
【００５７】
一般的に、利用者の利用者更新情報はリアルタイムに反映されなければならないことは少なく、オフィスサーバシステム全体の負荷や、特徴などに合わせた運用の方が効果的なためである。本実施例では、旧バージョン形式の更新情報と新バージョン形式の更新情報の形式変換のトリガはそれぞれ別に指定することができるようになっており、もし、ローカルディレクトリとマスタディレクトリを同期を取って更新させたい場合にはイベントトリガ機構の時間監視をそのように設定すればよい。
【００５８】
スレーブサーバを旧バージョンから新バージョンに移行する場合は、各スレーブサーバのハードウェアに新バージョンのオフィスサーバのリソースのみが旧オフィスサーバと置き換えられる。スレーブサーバの移行時は移行中のスレーブサーバの利用者のみオフィスサーバシステムの利用ができなくなるが、オフィスサーバシステムの運用は続行可能である。スレーブサーバが新バージョンに置き代わるとスレーブサーバ側の新バージョンリプリケータとマスタサーバ側の新バージョンリプリケータが接続されスレーブサーバ側のオフィスサーバシステムの運用が開始される。
【００５９】
なお、接続前に予め、マスタサーバの新バージョンに対して、当該スレーブサーバを登録を行うと共に、マスタサーバの旧バージョンから当該スレーブサーバの登録を削除する。また、当該スレーブサーバの新バージョンについても、接続するマスタサーバを登録する。
【００６０】
上記のように、スレーブサーバを順次新バージョンへ移行し、すべてのスレーブサーバの移行が完了すると旧バージョンマスタサーバを削除し、エリア全体の新バージョンへの移行が完了する。そして、最後にポンプ機構を削除して全ての移行処理が完了する。
【００６１】
上記では、２階層の例で説明したが、３階層以上であっても同様に行う。但し、第２階層のサーバにさらに下位の第３階層のサーバ（スレーブサーバ）が接続されている場合には、まず、第２階層のサーバに、新バージョンとポンプ機構をインストールする。そして下位の第３階層のサーバがすべて新バージョンに移行した後にはじめて第２階層のサーバを新バージョンのみにする（旧バージョンとポンプ機構を削除する）。
【００６２】
さらに、第２階層のサーバが全て新バージョンに移行してはじめて最上位の第１階層のサーバを新バージョンのみにする（旧バージョンとポンプ機構を削除する）。
【００６３】
【発明の効果】
以上説明したように、本発明によれば、一時期にオフィスサーバの専門的知識を要するシステム保守要員を大量に確保する必要はなく、極力少ないシステム保守要員の確保でオフィスサーバシステムの旧バージョンから新バージョンへの移行が可能となる。
【００６４】
なお、新バージョン形式のデータを旧バージョン形式のデータへ、または旧バージョン形式のデータを新バージョン形式のデータへ変換する場合には、変換テーブルを利用することにより処理スピードの向上、およびＣＰＵの負荷削減を実現している。
【００６５】
また、オフィスサーバシステムの旧バージョンから新バージョンの移行時に発生するオフィスサーバシステムの運用停止時間はマスタサーバの移行時にのみに局所化でき、新旧バージョンのスレーブサーバが混在したオフィスサーバシステムの運用可能となる。
【００６６】
更に、指定した時刻に前記変換手段（ポンプ機構) を起動させることができるため、該オフィスサーバシステムの特徴に合わせて、例えばマスタサーバのマスタディレクトリの更新は１時間置きに、スレーブサーバのマスタディレクトリの写しの更新は夜間バッチで行うなど、オフィスサーバシステム全体のシステム効率を考慮した運用が可能となる。
【図面の簡単な説明】
【図１】本発明に係わるシステム構成図
【図２】新旧バージョンのディレクトリ内容の相違例
【図３】旧バージョンシステム構成例
【図４】サーバの移行例
【図５】スレーブサーバ２に利用者181 が追加された場合の処理フロー
【図６】スレーブサーバの利用者情報（旧バージョン形式）更新のマスタディレクトリへの反映処理
【図７】新バージョン形式の更新情報（マスタサーバの利用者001 の利用者情報が更新された場合）の処理フロー
【図８】新バージョン形式の更新情報の配信処理フロー
【符号の説明】
１０ 旧バージョンサーバ
１１ 旧バージョンサーバ処理部
１４、２４ 情報格納領域
１５ 旧バーションリプリケータ
２０ 新バージョンサーバ
２１ 新バージョンサーバ処理部
２５ 新バージョンリプリケータ
３１ 変換テーブル
３２ 情報変換処理部
３３ イベントトリガ機構
Claims (3)
- マスタスレーブサーバのシステム構成における、複数形式のデータを共存させて処理を行うマスタサーバであって、
第１のプログラムと、
第１のプログラムで扱うデータを第１の形式として格納する第１形式データ格納部と、
前記第１のプログラムとバージョンが異なる第２のプログラムと、
前記第２のプログラムで扱うデータを、第１の形式と異なる第２の形式として格納する第２形式データ格納部と、
前記第１のプログラムおよび第２のプログラムが動作中で予め設定されている第１の事象の発生を契機に、前記第１形式データ格納部にあるデータを第２の形式のデータへ変換する第１の変換手段と、
前記第１のプログラムおよび第２のプログラムが動作中で予め設定されている第２の事象の発生を契機に、前記第２形式データ格納部にあるデータを第１の形式のデータへ変換する第２の変換手段と
を有することを特徴とするマスタサーバ。 - 前記第１の事象および前記第２の事象は、システム負荷が低い時間に設定された時刻である
ことを特徴とする請求項１記載のマスタサーバ。 - 前記第１のプログラムは、第１のスレーブサーバと、前記第２のプログラムは、第２のスレーブサーバと接続され、それぞれデータの送受信を行う
ことを特徴とする請求項１記載のマスタサーバ。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP00315499A JP3674351B2 (ja) | 1999-01-08 | 1999-01-08 | マスタサーバ |
| US09/475,772 US6738801B1 (en) | 1999-01-08 | 1999-12-30 | Master server facilitating communication between slave servers in incompatible data formats, and method for upgrading slave servers |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP00315499A JP3674351B2 (ja) | 1999-01-08 | 1999-01-08 | マスタサーバ |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000207191A JP2000207191A (ja) | 2000-07-28 |
| JP3674351B2 true JP3674351B2 (ja) | 2005-07-20 |
Family
ID=11549447
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP00315499A Expired - Fee Related JP3674351B2 (ja) | 1999-01-08 | 1999-01-08 | マスタサーバ |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6738801B1 (ja) |
| JP (1) | JP3674351B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20230171441A1 (en) * | 2020-04-22 | 2023-06-01 | Orange | Method providing to a user terminal a target multimedia content available at a master server |
Families Citing this family (31)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4004211B2 (ja) * | 2000-06-19 | 2007-11-07 | 三洋電機株式会社 | ネットワークサーバおよびネットワークシステム |
| US20020062377A1 (en) * | 2000-11-20 | 2002-05-23 | Hillman Matthew F. | Scalable directory, master and slave server based architecture for hosting application services |
| US20020073188A1 (en) * | 2000-12-07 | 2002-06-13 | Rawson Freeman Leigh | Method and apparatus for partitioning system management information for a server farm among a plurality of leaseholds |
| US20020073187A1 (en) * | 2000-12-07 | 2002-06-13 | Rawson Freeman Leigh | Method and apparatus for time decay monitoring of application, network and system behavior |
| US20020105548A1 (en) * | 2000-12-12 | 2002-08-08 | Richard Hayton | Methods and apparatus for creating a user interface using property paths |
| US7305669B2 (en) * | 2002-09-27 | 2007-12-04 | Sun Microsystems, Inc. | Software upgrades with multiple version support |
| US7194728B1 (en) * | 2002-11-18 | 2007-03-20 | Bmc Software, Inc. | System and method for packaging updates |
| AU2003246111A1 (en) * | 2003-07-07 | 2005-01-21 | Lg Electronics, Inc. | Upgrade apparatus and its method for home network system |
| US7801947B2 (en) * | 2004-12-28 | 2010-09-21 | Taiwan Semiconductor Manufacturing Co., Ltd. | Software deployment system and method |
| US20070027936A1 (en) * | 2005-07-28 | 2007-02-01 | Stakutis Christopher J | Determining changes made to a source file to transmit to a target location providing a mirror copy of the source file |
| JP4819475B2 (ja) * | 2005-10-18 | 2011-11-24 | Ｎｅｃエンジニアリング株式会社 | プログラム更新装置 |
| US8806472B2 (en) * | 2007-09-27 | 2014-08-12 | Ericsson Ab | In-service software upgrade utilizing metadata-driven state translation |
| US7895428B2 (en) * | 2007-09-28 | 2011-02-22 | International Business Machines Corporation | Applying firmware updates to servers in a data center |
| JP5132292B2 (ja) * | 2007-12-07 | 2013-01-30 | キヤノン株式会社 | 情報処理装置および情報処理方法 |
| US9772784B2 (en) | 2011-08-10 | 2017-09-26 | Nutanix, Inc. | Method and system for maintaining consistency for I/O operations on metadata distributed amongst nodes in a ring structure |
| WO2014209078A1 (en) * | 2013-06-28 | 2014-12-31 | Samsung Electronics Co., Ltd. | Method and apparatus for updating application |
| US9590843B2 (en) | 2014-03-12 | 2017-03-07 | Nutanix, Inc. | Method and system for providing distributed management in a networked virtualization environment |
| WO2015172107A1 (en) | 2014-05-09 | 2015-11-12 | Nutanix, Inc. | Mechanism for providing external access to a secured networked virtualization environment |
| US9733958B2 (en) * | 2014-05-15 | 2017-08-15 | Nutanix, Inc. | Mechanism for performing rolling updates with data unavailability check in a networked virtualization environment for storage management |
| US9740472B1 (en) * | 2014-05-15 | 2017-08-22 | Nutanix, Inc. | Mechanism for performing rolling upgrades in a networked virtualization environment |
| US10642507B2 (en) | 2015-01-30 | 2020-05-05 | Nutanix, Inc. | Pulsed leader consensus management |
| US11218418B2 (en) | 2016-05-20 | 2022-01-04 | Nutanix, Inc. | Scalable leadership election in a multi-processing computing environment |
| US10613849B2 (en) * | 2016-09-23 | 2020-04-07 | Visa International Service Association | Update migration system and method |
| US10362092B1 (en) | 2016-10-14 | 2019-07-23 | Nutanix, Inc. | Entity management in distributed systems |
| US11194680B2 (en) | 2018-07-20 | 2021-12-07 | Nutanix, Inc. | Two node clusters recovery on a failure |
| US11089098B2 (en) * | 2018-07-24 | 2021-08-10 | Vmware, Inc. | Migration as a service-based server and agent applications migration |
| US11770447B2 (en) | 2018-10-31 | 2023-09-26 | Nutanix, Inc. | Managing high-availability file servers |
| US10715541B2 (en) | 2018-11-05 | 2020-07-14 | cmdSecurity Inc. | Systems and methods for security monitoring processing |
| CN113391759B (zh) * | 2020-03-13 | 2024-04-09 | 华为云计算技术有限公司 | 一种通信方法和设备 |
| US11768809B2 (en) | 2020-05-08 | 2023-09-26 | Nutanix, Inc. | Managing incremental snapshots for fast leader node bring-up |
| CN113452665B (zh) * | 2020-07-10 | 2022-09-16 | 北京新氧科技有限公司 | 权限处理方法、系统及设备 |
Family Cites Families (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0476754A (ja) * | 1990-07-18 | 1992-03-11 | Nec Corp | 情報処理システムのレビジョン機能差制御方式 |
| JPH0556149A (ja) * | 1991-08-28 | 1993-03-05 | Nec Corp | 交換システムにおけるフアイル更新方法 |
| JPH05342155A (ja) * | 1992-06-10 | 1993-12-24 | Nec Corp | オンラインメッセージの分岐・切換装置 |
| US5410703A (en) * | 1992-07-01 | 1995-04-25 | Telefonaktiebolaget L M Ericsson | System for changing software during computer operation |
| JPH06119224A (ja) * | 1992-10-08 | 1994-04-28 | Nri & Ncc Co Ltd | データ・ベースをともに有するホスト・コンピュータとワーク・ステーションとからなるオンライン・システム |
| JP3183987B2 (ja) * | 1993-01-28 | 2001-07-09 | 日本電気株式会社 | 交換機のソフトウェアファイル更新方法 |
| US5493671A (en) * | 1993-06-04 | 1996-02-20 | Marcam Corporation | Method and apparatus for conversion of database data into a different format on a field by field basis using a table of conversion procedures |
| JP3425724B2 (ja) * | 1993-11-30 | 2003-07-14 | 日本電信電話株式会社 | システム無中断プログラム切替え方法 |
| JPH0895772A (ja) * | 1994-09-22 | 1996-04-12 | Toshiba Corp | 計算機システム及びプログラム置換方法 |
| JPH08235049A (ja) * | 1995-02-27 | 1996-09-13 | Nec Corp | 通信システム |
| JP3611894B2 (ja) * | 1995-03-30 | 2005-01-19 | 富士通株式会社 | 二重化構成をもつシステム制御装置 |
| US5625804A (en) * | 1995-04-17 | 1997-04-29 | International Business Machines Corporation | Data conversion in a multiprocessing system usable while maintaining system operations |
| GB2301744B (en) * | 1995-06-02 | 2000-01-12 | Dsc Communications | Software download for a subscriber terminal of a wireless telecommunications system |
| US6185197B1 (en) * | 1995-06-02 | 2001-02-06 | Airspan Networks, Inc. | Control message transmission in telecommunications systems |
| CA2170564A1 (en) * | 1996-02-28 | 1997-08-29 | Frank Michael Kappe | Method of propagating data through a distributed information network |
| JP2002503361A (ja) * | 1996-04-09 | 2002-01-29 | ヴァイアソフト・インコーポレーテッド | データの仮想的変換システム |
| JPH1011271A (ja) * | 1996-06-27 | 1998-01-16 | Hitachi Ltd | バージョンダウン入力方式 |
| US5995980A (en) * | 1996-07-23 | 1999-11-30 | Olson; Jack E. | System and method for database update replication |
| JP2000099384A (ja) * | 1998-09-17 | 2000-04-07 | Nippon Telegr & Teleph Corp <Ntt> | 異なる通信ネットワーク間の高セキュリティのデータ連携方法及び異なる通信ネットワーク間における高セキュリティのデータ連携システム及びデータ連携プログラムを格納した記憶媒体 |
-
1999
- 1999-01-08 JP JP00315499A patent/JP3674351B2/ja not_active Expired - Fee Related
- 1999-12-30 US US09/475,772 patent/US6738801B1/en not_active Expired - Fee Related
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20230171441A1 (en) * | 2020-04-22 | 2023-06-01 | Orange | Method providing to a user terminal a target multimedia content available at a master server |
Also Published As
| Publication number | Publication date |
|---|---|
| US6738801B1 (en) | 2004-05-18 |
| JP2000207191A (ja) | 2000-07-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3674351B2 (ja) | マスタサーバ | |
| AU640029B2 (en) | Distributed data processing systems | |
| JP2948496B2 (ja) | データ処理システム内で複写データ一貫性を維持するためのシステムおよび方法 | |
| FI101432B (fi) | Vikasietoinen tietokonejärjestelmä | |
| US7028078B1 (en) | System and method for performing virtual device I/O operations | |
| EP1179770B1 (en) | File system | |
| US7392421B1 (en) | Framework for managing clustering and replication | |
| US7562100B2 (en) | Maintaining coherency in a symbiotic computing system and method of operation thereof | |
| JP4173673B2 (ja) | ファイルバックアップ方法および記憶装置 | |
| JPS59133663A (ja) | 分散マルチプロセツサ・コンピユ−タの障害許容システムにおけるタスク実行手段間のメツセ−ジ転送方法 | |
| US7734878B1 (en) | System and method for performing virtual device I/O operations | |
| WO2003044697A1 (en) | Data replication system and method | |
| JPH11167510A (ja) | レプリケーション方法、レプリケーションツール、および、レプリケーションサーバ | |
| JP2014522513A (ja) | マルチサーバ予約システムにおける同期化メカニズムのための方法及びシステム | |
| JPH04271454A (ja) | 疎結合計算機システム | |
| JPH0776939B2 (ja) | 通信ネットワークシステム | |
| TW497062B (en) | System and method for communications and process management in a distributed telecommunications switch | |
| WO2000070465A1 (fr) | Systeme informatique reparti et procede d'application de donnees de maintenance | |
| CN116257380A (zh) | 跨数据中心的Kubernetes联邦管理控制平面的高可用方法和系统 | |
| JP5480046B2 (ja) | 分散トランザクション処理システム、装置、方法およびプログラム | |
| JP2005050298A (ja) | 計算機システム、計算機、データ通信方法及びプログラム | |
| JP2001027951A (ja) | マルチプロセッサ構成の情報処理システムにおけるファイルロード装置と記録媒体 | |
| JP3718273B2 (ja) | メンテナンスデータ管理方法 | |
| JP3308210B2 (ja) | 分散処理システムとその処理方法 | |
| CN112069160B (zh) | 一种基于cap数据清洗同步方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20041015 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050111 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050304 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050405 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050418 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080513 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090513 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090513 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100513 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100513 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110513 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120513 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130513 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140513 Year of fee payment: 9 |
|
| LAPS | Cancellation because of no payment of annual fees |