JP2010191690A - 伝送装置データベースのバックアップ管理方法およびリストア管理方法 - Google Patents

伝送装置データベースのバックアップ管理方法およびリストア管理方法 Download PDF

Info

Publication number
JP2010191690A
JP2010191690A JP2009035434A JP2009035434A JP2010191690A JP 2010191690 A JP2010191690 A JP 2010191690A JP 2009035434 A JP2009035434 A JP 2009035434A JP 2009035434 A JP2009035434 A JP 2009035434A JP 2010191690 A JP2010191690 A JP 2010191690A
Authority
JP
Japan
Prior art keywords
backup
file
database
transfer
rmbu
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.)
Pending
Application number
JP2009035434A
Other languages
English (en)
Inventor
Takeshi Ishida
毅 石田
Hideki Kajitani
英樹 梶谷
Hideyuki Sora
秀幸 空
Yoshinori Furuko
美則 古府
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2009035434A priority Critical patent/JP2010191690A/ja
Publication of JP2010191690A publication Critical patent/JP2010191690A/ja
Pending legal-status Critical Current

Links

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

【課題】伝送装置のデータベース更新を行ってからデータベースバックアップを実施するまでのタイムラグを抑圧し、バックアップデータベースのデータの信頼性と操作性を向上させる。
【解決手段】伝送装置データベースをリモートメモリバックアップするオペレーションシステムにおいて、ネットワーク登録時にネットワーク管理テーブルとリモートメモリバックアップ管理テーブルを具備し、オペレーションシステムからの指示により同一ネットワーク内の隣接伝送装置間でデータベースファイルをバックアップする管理方法。
【選択図】図２

Description

本発明は、伝送装置データベースのバックアップ管理方法およびリストア管理方法に関し、特に、複数の伝送装置で構成されるリングネットワークと、これらのリングネットワークを複数監視して制御するオペレーションシステムにおいて用いると好適である。
リング型ネットワークを構成する複数の伝送装置(ＮＥ：Network Element)とそれを遠隔から監視制御するオペレーションシステム（ＯｐＳ：Operation System）は、１台以上のゲートウェイとなる伝送装置(ＧＮＥ：Gateway Network Element)で接続される。
オペレーションシステム（ＯｐＳ：Operation System）は、ここでは伝送装置(ＮＥ：Network Element)を監視制御するクライアントサーバ構成のシステムを意味する。
図２３は、本発明が対象とするリングネットワークの構成図である。図２３において、ＯｐＳクライアント７１〜７ｎは、ＤＣＮ（Data Communication Network)６を経由してＯｐＳサーバ５１、５２に接続され、ＯｐＳサーバ５１、５２は、ＤＣＮ（Data Communication Network)４を経由してゲートウェイとなる伝送装置（ＧＮＥ）１１，２１に接続される。ＤＣＮ４，６は、ＴＣＰ／ＩＰのプロトコル通信により信号が伝送され、また、リングネックワーク内の装置間ではＤＣＣ(Data Communication Channel)通信により信号が伝送される。
上記構成のもと、従来は、架前制御端末（ＣＩＴ：Claft Interface Terminal）８を用いて各伝送装置１１〜１ｎ、２１〜２ｎのＲＡＭディスク領域に、伝送装置１１〜１ｎ、２１〜２ｎの運用データベースをバックアップしていたが、伝送装置１１〜１ｎ、２１〜２ｎに故障が発生した場合にバックアップした情報が消滅してしまうことを防ぐ事を目的として、伝送装置の運用データベースをリモートでＯｐＳサーバ５にバックアップする機能（以下、ＲＭＢＵ：Remote Memory Backup）や、逆にＯｐＳサーバ５にバックアップしたデータベースをリモートで伝送装置１１〜１ｎ、２１〜２ｎにリストアして伝送装置１１〜１ｎ、２１〜２ｎを復旧する機能（以下、ＲＭＲＳ：Remote Memory Restore）がある。
また、ＲＭＢＵにはオペレータがＯｐＳクライアント７１〜７ｎからＯｐＳサーバ５を経由して伝送装置１１〜１ｎ、２１〜２ｎにプロビジョニング設定を行った後などに任意に行う手動バックアップ機能(以下、手動ＲＭＢＵ)と、オペレータの保守作業の負担軽減やバックアップ漏れを防ぐため、比較的ネットワーク負荷が低い深夜帯にＯｐＳサーバ５が定期的に行う自動バックアップ機能(以下、自動ＲＭＢＵ)がある。
図２４は、従来技術によるリモートメモリバックアップ方法を示す説明図である。図２４に示すように、従来のＲＭＢＵでは、ＲＭＢＵ開始時刻になると伝送装置１１〜１３毎に直列でＲＭＢＵを実施し、伝送装置１１〜１３毎に運用データベース１４１〜１４３をメモリーコピーしてＲＡＭディスク１１１〜１１３上にバックアップＤＢファイル１３１〜１３３を作成し、さらにＧＮＥ１１経由でＯｐＳサーバ５にファイル転送することでＯｐＳサーバ５で各ＮＥ１１〜１ｎのバックアップＤＢファイル５３１〜５３３と管理情報を一元管理していた。（例えば、特許文献１参照）
図２５に従来技術によるリモートメモリバックアップのシーケンス図である。
自動ＲＭＢＵはリングネットワーク内の全ＮＥ１１〜１ｎに対して繰り返しＲＭＢＵを行うが、対象ＮＥ１１〜１ｎがＧＮＥ#01１１の場合とＮＥ#02１２〜ＮＥ#ｎ１ｎの場合でシーケンスが異なる。
ＧＮＥ＃01１１の場合は、バックアップＤＢを直接ＯｐＳサーバ５へファイル転送するが、ＮＥ#02１２〜ＮＥ#ｎ１ｎの場合は一旦ＧＮＥ#01１１へファイル転送してから、さらにＧＮＥ＃01１１からＯｐＳサーバ５へファイル転送するという２段階の手順となる。
図２５ではＧＮＥ#01１１とＮＥ#02１２のバックアップＤＢをＯｐＳサーバ５にＲＭＢＵするシーケンスを代表的に記述している。
以下に、ＧＮＥ#01１１のＲＭＢＵ手順を以下に示す。
Ｓ１．ＯｐＳサーバ５からバックアップ対象のＧＮＥ#01１１に対しファイル削除要求を送信し、ＲＡＭディスク上のファイルを全て削除する。
Ｓ２．ＯｐＳサーバ５からバックアップ対象のＧＮＥ#01１１に対しメモリコピー要求を送信し、ＦＬＡＳＨメモリのＤＢをＲＡＭディスクにコピーしてバックアップＤＢファイルを作成する。
Ｓ３．ＯｐＳサーバ５からＧＮＥ#01１１に対してファイル転送要求を送信し、ＧＮＥ#01１１のＲＡＭディスク上にあるバックアップＤＢファイルをＯｐＳサーバ５のＨＤＤ上にファイル転送する。
次に、ＮＥ#02１２のＲＭＢＵ手順を以下に示す。
Ｓ４．ＯｐＳサーバ５からバックアップ対象のＮＥ#02１２に対しファイル削除要求を送信し、ＲＡＭディスク上のファイルを全て削除する。
Ｓ５．ＯｐＳサーバ５からバックアップ対象のＮＥ#02１２に対しメモリコピー要求を送信し、ＦＬＡＳＨメモリのＤＢをＲＡＭディスクにコピーしてバックアップＤＢファイルを作成する。
Ｓ６．ＯｐＳサーバ５からＧＮＥ#01１１に対してファイル削除要求を送信し、ＲＡＭディスク上のファイルを全て削除する。
Ｓ７．ＯｐＳサーバ５からＧＮＥ#01１１に対してファイル転送要求を送信し、ＮＥ#02１２のＲＡＭディスク上にあるバックアップＤＢファイルをＧＮＥ#01１１のＲＡＭディスク上にファイル転送する。
Ｓ８．ＯｐＳサーバ５からＧＮＥ#01１１に対して再びファイル転送要求を送信し、ＧＮＥ#01１１のＲＡＭディスク上にあるバックアップＤＢファイルをＯｐＳサーバ５のＨＤＤ上にファイル転送する。
なお、ＮＥ#03１３〜ＮＥ#n１ｎの手順もＮＥ#02１２の手順と同様である。
このようにＧＮＥ＃01１１以外のＮＥ#02１２〜ＮＥ#ｎ１ｎのＲＭＢＵでは、一旦ＧＮＥ#01１１へファイル転送してから、さらにＧＮＥ＃01１１からＯｐＳサーバ５へファイル転送するという２段階の手順をとるため、同一リングネットワーク内のＮＥ１１〜１ｎに対するＲＭＢＵは、必ずシーケンシャルに１ＮＥずつ実施する必要があった。
また、ＲＭＢＵではリングネットワーク内のＮＥ間に比べて通信速度が遅いＯｐＳサーバ５〜ＧＮＥ１１間に大量のデータを伝送するため、他の監視／制御データの伝送性能を劣化させないような配慮がなされていた。例えば、リングネットワークをまたがってＲＭＢＵを同時実行させるＮＥ１１〜１ｎ台数に制限を設けたり、自動ＲＭＢＵで１日に実施するＮＥ１１〜１ｎ台数や実施時間帯に制限を設けて実行し、その日に終わらなかったＮＥ１１〜１ｎは翌日以降に持ち越して実行していた。
図２６は、従来技術によるリモートメモリリストアのシーケンス図である。図２６に従来のＲＭＲＳのシーケンスの一例を示す。
ＧＮＥ＃01１１の場合は、バックアップＤＢを直接ＯｐＳサーバ５からファイル転送するが、ＮＥ#02１２〜ＮＥ#ｎ１ｎの場合は一旦ＧＮＥ#01１１へファイル転送してから、さらにＧＮＥ＃01１１からＮＥ#02１２〜ＮＥ#ｎ１ｎへファイル転送するという２段階の手順となる。
図２６ではＮＥ#02１２のバックアップＤＢをＯｐＳサーバ５からＲＭＲＳするシーケンスを代表的に記述している。
以下に、ＮＥ#02１２のＲＭＲＳ手順を以下に示す。
Ｓ１．ＯｐＳサーバ５からＧＮＥ#01１１に対してファイル削除要求を送信し、ＲＡＭディスク上のファイルを全て削除する。
Ｓ２．ＯｐＳサーバ５からＧＮＥ#01１１に対してファイル転送要求を送信し、ＯｐＳサーバ５のＨＤＤ上にあるバックアップＤＢファイルをＧＮＥ#01１１のＲＡＭディスク上にファイル転送する。
Ｓ３．ＯｐＳサーバ５からＮＥ#02１２に対してファイル削除要求を送信し、ＲＡＭディスク上のファイルを全て削除する。
Ｓ４．ＯｐＳサーバ５からＧＮＥ#01１１に対してファイル転送要求を送信し、ＧＮＥ#01１１のＲＡＭディスク上にあるバックアップＤＢファイルをＮＥ#02１２のＲＡＭディスク上にファイル転送する。
Ｓ５．ＯｐＳサーバ５からＮＥ#02１２に対しメモリコピー要求を送信し、ＲＡＭディスクのバックアップＤＢファイルをＦＬＡＳＨメモリにコピーしてリストアする。
このようにＧＮＥ＃01１１以外のＮＥ#02１２〜ＮＥ#ｎ１ｎのＲＭＲＳでは、一旦ＧＮＥ#01１１へファイル転送してから、さらにＧＮＥ＃01１１からＮＥ#02１２〜ＮＥ#ｎ１ｎへファイル転送するという２段階の手順をとるため、リストア時のファイル転送にも時間がかかっていた。
また、ネットワーク管理システムのデータベース復旧方式に関して、障害発生時に、予め保存しておいた管理情報データベースを再ロードすると共に、現在のネットワーク機器情報との不一致がある場合はネットワーク機器に格納されている管理情報をアップロードし、その管理情報でネットワーク管理システムに格納されている管理情報を更新する内容が開示されている。（例えば、特許文献２参照）
特開２００７−５８８１４号公報 特開平１０−２５４９３４号公報
近年では、ＯｐＳで管理するＮＥ台数が増加したことや、ＯｐＳサーバに大量のデータをバックアップすることでＯｐＳ〜ＧＮＥ間のデータ通信トラフィックが増大することになり、従来技術のように一日にＯｐＳがバックアップするＮＥ台数に制限をかけ、数日にわたり自動ＲＭＢＵを実施する方法では、ＯｐＳからＮＥにプロビジョニング設定（ＤＢ更新）を行ってから自動ＲＭＢＵが実施されるまでに１日以上のタイムラグが生ずる場合があった。
従って、その間にＮＥに障害が発生し、バックアップＤＢファイルをＮＥにリストアする必要性が生じても、ＯｐＳには最新のバックアップファイルが存在しない事態に陥る可能性があった。
従来方式ではこのような事態に陥った場合、ＯｐＳにある少し古いバックアップＤＢファイルをＮＥにリストアした後、ＯｐＳとＮＥのＤＢを比較して差分をＯｐＳから再設定してデータを合わせ込む必要があるため、復旧に時間がかかることがあった。
本発明の目的は、自動ＲＭＢＵにより１日に１回、全てのＮＥのＤＢバックアップを行うことにより、プロビジョニング設定(ＤＢ更新)を行ってからＤＢバックアップを実施するまでのタイムラグを２４時間以内に抑えることにより、バックアップＤＢのデータの信頼性と保守性を向上させる伝送装置の運用データベースのバックアップ管理方法およびリストア管理方法を提供することである。
上記課題を解決するための本発明は、リング型ネットワークを構成する複数の伝送装置の運用データベースを前記伝送装置間でバックアップするバックアップ管理方法であって、前記伝送装置のネットワーク登録時とネットワーク更新時に、指定されたネットワーク情報をオペレーションシステムに保持するステップと、前記ネットワーク毎にバックアップデータベース情報を前記オペレーションシステムに保持するステップと、前記オペレーションシステムからの指示で同一の前記ネットワーク内の隣接する前記伝送装置間でデータベースファイルをバックアップするステップとを含んでいる。
この本発明によれば、他の制御／監視データの伝送性能を劣化させることがなく、自動ＲＭＢＵの大幅な時間短縮が可能となる伝送装置データベースのバックアップ管理方法を提供できる。
また、本発明は、リング型ネットワークを構成する複数の伝送装置の運用データベースを前記伝送装置間でリストアするリストア管理方法であって、前記伝送装置のネットワーク登録時とネットワーク更新時に、指定されたネットワーク情報をオペレーションシステムに保持するステップと、前記ネットワーク毎にバックアップデータベース情報を前記オペレーションシステムに保持するステップと、前記オペレーションシステムからの指示でリストアを行うデータベースファイル格納先の前記伝送装置を検索するステップと、前記伝送装置のデータベースをリストアするステップとを含んでいる。
本発明によれば、復旧伝送装置のリストアの大幅な時間短縮が可能となる伝送装置データベースのリストア管理方法を提供できる。
以上、開示の技術によれば、ＯｐＳ〜ＧＮＥ間に大量のデータを伝送することがなくなるため、他の制御／監視データの伝送性能を劣化させることがなく、さらに、ＧＮＥを経由してファイル転送する必要がないため、リングネットワーク内でもＲＭＢＵグループ単位でパラレルに実施することができ、自動ＲＭＢＵの大幅な時間短縮が可能となる。
従って、自動ＲＭＢＵにより短時間で全てのＮＥのＤＢバックアップを行えるようになるため、プロビジョニング設定(ＤＢ更新)を行ってからＤＢバックアップを実施するまでのタイムラグを２４時間以内に抑えることができる。
また、従来、オペレータがＯｐＳからＮＥにプロビジョニング設定を行った後に繰り返し手動ＲＭＢＵを行っていたのに対し、本発明では、ネットワーク単位に自動ＲＭＢＵ開始時刻を設定(ネットワーク登録時)／変更(ネットワーク更新時)できるため、オペレータがＯｐＳからＮＥにプロビジョニング設定を行った後に自動ＲＭＢＵ開始時刻を変更(例えば10分後)すれば、容易に予約した時間に短時間で自動ＲＭＢＵを行えるようになり、保守作業の負担軽減につながる。
また、バックアップＤＢファイルの格納先がＯｐＳからＮＥ側に変わっても、今まで通りの運用が可能である。
さらに、ＯｐＳでＮＥ毎にＤＢのバックアップ先を管理しており、対象ＮＥの復旧時に、バックアップ先である隣接ＮＥから対象ＮＥにバックアップＤＢをファイル転送して復旧するため、復旧時間も短縮される効果がある。
本発明の一実施形態における伝送装置の運用データベースバックアップ管理方法の説明図（その１）である。 本発明の一実施形態における伝送装置の運用データベースバックアップ管理方法の説明図（その２）である。 本発明による通常運用中のリモートメモリのバックアップ方法（実施例１）を示すシーケンス図（その１）である。 本発明による通常運用中のリモートメモリのバックアップ方法（実施例１）を示すシーケンス図（その２）である。 本発明によるＤＢファイルコピーが失敗した場合のリモートメモリのバックアップ方法（実施例２）を示すシーケンス図（その１）である。 本発明によるＤＢファイルコピーが失敗した場合のリモートメモリのバックアップ方法（実施例２）を示すシーケンス図（その２）である。 本発明によるファイル転送が失敗した場合のリモートメモリのバックアップ方法（実施例３）を示すシーケンス図（その１）である。 本発明によるファイル転送が失敗した場合のリモートメモリのバックアップ方法（実施例３）を示すシーケンス図（その２）である。 本発明によるファイル転送が失敗した場合のリモートメモリのバックアップ方法（実施例３）を示すシーケンス図（その３）である。 本発明によるファイル転送が失敗した場合のリモートメモリのバックアップ方法（実施例３）を示すシーケンス図（その４）である。 本発明によるネットワーク登録時のリモートメモリのバックアップ方法（実施例４）を示すシーケンス図（その１）である。 本発明によるネットワーク登録時のリモートメモリのバックアップ方法（実施例４）を示すシーケンス図（その２）である。 本発明による装置増設時のリモートメモリのバックアップ方法（実施例５）を示すシーケンス図（その１）である。 本発明による装置増設時のリモートメモリのバックアップ方法（実施例５）を示すシーケンス図（その２）である。 本発明による装置増設時のリモートメモリのバックアップ方法（実施例５）を示すシーケンス図（その３）である。 本発明による装置減設時のリモートメモリのバックアップ方法（実施例６）を示すシーケンス図（その１）である。 本発明による装置減設時のリモートメモリのバックアップ方法（実施例６）を示すシーケンス図（その２）である。 本発明による装置減設時のリモートメモリのバックアップ方法（実施例６）を示すシーケンス図（その３）である。 本発明による定期監視時のリモートメモリのバックアップ方法（実施例７）を示すシーケンス図（その１）である。 本発明による定期監視時のリモートメモリのバックアップ方法（実施例７）を示すシーケンス図（その２）である。 本発明による定期監視時のリモートメモリのバックアップ方法（実施例７）を示すシーケンス図（その３）である。 本発明による装置復旧時のリモートメモリのリストア方法（実施例８）を示すシーケンス図である。 本発明が対象とするリングネットワークの構成図である。 従来技術によるリモートメモリのバックアップ方法を示す説明図である。 従来技術によるリモートメモリのバックアップのシーケンス図である。 従来技術によるリモートメモリのリストアのシーケンス図である。
以下、本発明の実施の形態について、図を参照しながら説明する。
図１は、本発明の一実施形態における伝送装置の運用データベースバックアップ管理方法の説明図（その１）である。
ネットワーク管理テーブル５４は、各種ネットワーク情報を保持しているテーブルでネットワーク登録／更新時に指定されたネットワーク名称の他にＲＭＢＵ開始時刻とＲＭＢＵグループ数を管理する。
ＲＭＢＵ開始時刻は、自動ＲＭＢＵが開始される予約時刻を示す。
ＲＭＢＵグループ数は、指定された数でネットワーク構成装置をほぼ均等にグループ分割し、自動ＲＭＢＵで並列で実行されるグループ数を示す。
また、ＲＭＢＵ管理テーブル５２は、１ネットワーク毎に存在するＲＭＢＵの実行管理テーブルであり、ネットワーク登録／更新時に指定された情報をもとにＮＥ名、グループ番号、自ＮＥバックアップＤＢファイル名、他ＮＥバックアップＤＢファイル名、自ＮＥバックアップＤＢファイルの作成結果／作成日時／作成サイズ、自ＮＥバックアップＤＢファイルの転送結果／転送日時／転送サイズを管理する。
グループ番号は、自動ＲＭＢＵにて並列で実行されるグループを示している。
自ＮＥバックアップＤＢファイル名は、対象ＮＥ自身のバックアップＤＢファイルを示し、ＮＥ毎に一意に決まり、ファイル名からどのＮＥのバックアップＤＢファイルかを特定できる。また、自ＮＥバックアップＤＢファイルの管理情報としてＤＢ作成結果／作成日時／作成サイズおよびＤＢ転送結果／転送日時／転送サイズがある。前者は自ＮＥのＦＬＡＳＨメモリからＲＡＭディスクに運用ＤＢをコピーしたときの情報であり、後者は自ＮＥのＲＡＭディスクから他ＮＥへファイル転送したときの情報である。
他ＮＥバックアップＤＢファイル名は、対象ＮＥがバックアップしている隣接ＮＥのバックアップＤＢファイルを示す。
また、自動ＲＭＢＵする際のバックアップ先ＮＥは、基本的にネットワークを構成するＮＥの並びで決まり（例えば右回り）、グループ毎に転送先ＮＥが一意に決まる。
図２は、本発明の一実施形態における伝送装置の運用データベースバックアップ管理方法の説明図（その２）である。
図２に示すように本発明の自動ＲＭＢＵでは、ＲＭＢＵ開始時刻になるとＮＥ１１〜１３毎に並列でＲＭＢＵを実施し、ＮＥ１１〜１３毎に運用ＤＢをメモリーコピーしてＲＡＭディスク上にバックアップＤＢファイルを作成し、さらに隣接ＮＥにファイル転送して各ＮＥ１１〜１３間でバックアップＤＢファイルを保持し合うことでＯｐＳサーバ５では各ＮＥ１１〜１３のＲＭＢＵ管理情報のみを一元管理する。
本発明では、ネットワーク管理テーブル５４とＲＭＢＵ管理テーブル５２を用いて、ネットワーク登録／更新時やＲＭＢＵ開始時刻に自動的にＲＭＢＵを実行してＮＥ１１〜１３間でバックアップＤＢを保持し合う機能を有し、さらにバックアップＤＢファイルの信頼性を向上するため、ＮＥのバックアップＤＢファイル状態を定期監視し、バックアップＤＢの消失を防止する機能を有する。
また、ＮＥ１１〜１３復旧時には他のＮＥ１１〜１３に保持しているバックアップＤＢファイルを対象ＮＥ１１〜１３にファイル転送してリストアする機能を有する。
図３と図４は、本発明による通常運用中のリモートメモリバックアップ方法（実施例１）を示すシーケンス図（その１）と（その２）である。
以下、図３と図４を用いて通常運用中のＲＭＢＵの手順を説明する。
手順１：ＲＭＢＵ開始時刻になったタイミングで不要なファイル削除
Ｓ1-1．ネットワーク管理テーブルの“ＲＭＢＵ開始時刻”になったタイミングで、該当ＲＭＢＵ管理テーブルの“ＤＢファイル作成結果”が未実施の場合は、不要なファイルを削除する。本実施例は“ＤＢファイル作成結果”が正常であるため、スキップして手順２へ進む。
手順２：ＲＡＭディスクへ自ＮＥのＤＢファイル作成（＝コピー）
Ｓ2-1．ＲＭＢＵ管理テーブルにおいて、バックアップＤＢファイルの作成結果を“作成中”に書き換え、作成日時と作成サイズを初期化する。
Ｓ2-2．ネットワーク内のＮＥの運用ＤＢをバックアップＤＢファイルとしてＲＡＭディスクにコピーする。そして、バックアップＤＢファイルの作成結果をＲＭＢＵ管理テーブルに設定する。
なお、各ＮＥ３１〜３ｎへの処理は並列で処理を行なう。
手順３：転送先ＮＥへＤＢファイル転送
Ｓ3-1．ＲＭＢＵ管理テーブルにおいて、バックアップＤＢファイルの転送結果を“転送中”に書き換え、転送日時と転送サイズを初期化する。 Ｓ3-2．手順２で作成したバックアップＤＢファイルをバックアップ先ＮＥに転送する。
Ｓ3-3．ＲＭＢＵ管理テーブルにおいてバックアップＤＢファイルの転送結果と他ＮＥバックアップＤＢファイル名を設定する。
なお、各ＮＥ３１〜３ｎへの処理はグループ単位に並列で処理を行ない、同一グループ内では直列で処理を行う。
手順４：手順２でコピーしたＤＢファイルと手順３で転送したＤＢファイルの日時とサイズ取得
Ｓ4-1．ＮＥからバックアップＤＢファイルの作成日時と作成サイズおよび転送日時と転送サイズを読み出す。
Ｓ4-2．ＲＭＢＵ管理テーブルにおいてＤＢファイル作成日時と作成サイズおよび転送日時と転送サイズを設定する。
なお、各ＮＥ３１〜３ｎへの処理は並列で処理を行なう。
手順５：次回のＲＭＢＵ開始時刻まで待機、開始時刻に手順１〜４の繰り返し
図５と図６は、本発明によるＤＢファイルコピーが失敗した場合のリモートメモリバックアップ方法（実施例２）を示すシーケンス図（その１）と（その２）である。
以下、図５と図６を用いてＤＢファイルコピーが失敗した場合のＲＭＢＵの手順を説明する。
手順1：ＲＭＢＵ開始時刻になったタイミングで不要ファイルの削除
Ｓ1-1．ネットワーク管理テーブルの“ＲＭＢＵ開始時刻”になったタイミングで、該当ＲＭＢＵ管理テーブルの“ＤＢファイル作成結果”が未実施の場合は、不要なファイルを削除する。本実施例は“ＤＢファイル作成結果”が正常であるため、スキップして手順２へ進む。
手順２：自ＮＥのＤＢファイルをＲＡＭディスクに作成（=コピー）
Ｓ2-1．ＲＭＢＵ管理テーブルにおいて、バックアップＤＢファイルの作成結果を“作成中”に書き換え、作成日時と作成サイズを初期化する。
Ｓ2-2．ネットワーク内のＮＥの運用ＤＢをバックアップＤＢファイルとしてＲＡＭディスクにコピーする。
Ｓ2-3．バックアップＤＢファイルの作成結果をＲＭＢＵ管理テーブルに設定する。ここでは、ＮＥ#32３２の作成結果のみコピー失敗で設定される。
なお、各ＮＥ３１〜３ｎへの処理は並列で処理を行なう。
手順３：転送先ＮＥへＤＢファイルを転送
Ｓ3-1．ＲＭＢＵ管理テーブルにおいて、バックアップＤＢファイルの転送結果を“転送中”に書き換え、転送日時と転送サイズを初期化する。但し、ＮＥ#32３２はコピーに失敗しているため初期化しない。
Ｓ3-2．手順２で作成したバックアップＤＢファイルをバックアップ先ＮＥに転送する。
Ｓ3-3．ＲＭＢＵ管理テーブルにおいてバックアップＤＢファイルの転送結果と他ＮＥ
バックアップＤＢファイル名を設定する。
なお、各ＮＥ３１〜３ｎへの処理はグループ単位に並列で処理を行ない、同一グループ内では直列で処理を行う。
手順４：手順２でコピーしたＤＢファイルと手順３で転送したＤＢファイルの日時とサイズを取得
Ｓ4-1．ＮＥからバックアップＤＢファイルの作成日時と作成サイズおよび転送日時と転送サイズを読み出す。
Ｓ4-2．ＲＭＢＵ管理テーブルにおいてＤＢファイル作成日時と作成サイズおよび転送日時と転送サイズを設定する。
なお、各ＮＥ３１〜３ｎへの処理は並列で処理を行なう。
手順５：次回のＲＭＢＵ開始時刻になるまで待機し、開始時刻になったら手順１〜４を繰り返す
※ＮＥ#32３２のＤＢファイルのコピーが失敗しているためＮＥ#32３２のＤＢファイルは一世代前のＤＢファイルがＮＥ#31３１に保存された状態のままとなる。
図７〜図１０は、本発明によるファイル転送が失敗した場合のリモートメモリバックアップ方法（実施例３）を示すシーケンス図（その１）〜（その４）である。
以下、図７〜図１０を用いてファイル転送が失敗した場合のＲＭＢＵの手順を説明する。
手順1：ＲＭＢＵ開始時刻になったタイミングで不要なファイルを削除
Ｓ1-1．ネットワーク管理テーブルの“ＲＭＢＵ開始時刻”になったタイミングで、該当ＲＭＢＵ管理テーブルの“ＤＢファイル作成結果”が未実施の場合は、不要なファイルを削除する。
本実施例は“ＤＢファイル作成結果”が正常であるため、スキップして手順２へ進む。
手順２：自ＮＥのＤＢファイルをＲＡＭディスクに作成（＝コピー）
Ｓ2-1．ＲＭＢＵ管理テーブルにおいて、バックアップＤＢファイルの作成結果を“作成中”に書き換え、作成日時と作成サイズを初期化する。
Ｓ2-2．ネットワーク内のＮＥの運用ＤＢをバックアップＤＢファイルとしてＲＡＭディスクにコピーする。
Ｓ2-3．バックアップＤＢファイルの作成結果をＲＭＢＵ管理テーブルに設定する。
なお、各ＮＥ３１〜３ｎへの処理は並列で処理を行なう。
手順３：転送先ＮＥへＤＢファイルを転送
Ｓ3-1．ＲＭＢＵ管理テーブルにおいて、バックアップＤＢファイルの転送結果を“転送中”に書き換え、転送日時とサイズを初期化する。
Ｓ3-2．手順２で作成したバックアップＤＢファイルをバックアップ先ＮＥに転送する。
Ｓ3-3．ＲＭＢＵ管理テーブルにおいてバックアップＤＢファイルの転送結果と他ＮＥ
バックアップＤＢファイル名を設定する。但し、ＮＥ#32３２のＤＢファイルをＧＮＥ#31３１に転送できなかったため、ＮＥ#32３２の“ＤＢファイル転送結果”に転送失敗を設定する。同時に、転送先のＧＮＥ#31３１の“他ＮＥバックアップＤＢファイル名”にハイフンを設定する。
なお、各ＮＥ３１〜３ｎへの処理はグループ単位に並列で処理を行ない、同一グループ内では直列で処理を行う。
手順４：転送失敗となったＮＥ#32３２のＤＢファイルを臨時のバックアップ先ＮＥへ転送
Ｓ4-1．ＲＭＢＵ管理テーブルにおいて、同一グループ内/他グループ内の優先順番で、ＧＮＥ#31３１のＤＢファイルの臨時のバックアップ先ＮＥを検索し、ディスクの空き容量を確認する。空きがあれば、臨時のバックアップ先ＮＥ（ここではＮＥ#33３３とする）に手順３と同様にＤＢファイルを転送する。
なお、ディスクの空き容量が不足している場合や、再度転送で失敗した場合は、別の転送先ＮＥを再度検索し直す。
手順５：手順２でコピーしたＤＢファイルと手順３および手順４で転送したＤＢファイルの日時とサイズを取得
Ｓ5-1．ＮＥからバックアップＤＢファイルの作成日時と作成サイズおよび転送日時と転送サイズを読み出す。
Ｓ5-2．ＲＭＢＵ管理テーブルにおいてＤＢファイル作成日時と作成サイズおよび転送日時と転送サイズを設定する。
なお、各ＮＥ３１〜３ｎへの処理は並列で処理を行なう。
手順６：次回のＲＭＢＵ開始時刻になるまで待機し、開始時刻になったら手順１〜５を繰り返す
※ＮＥ#32３２のＤＢファイルをＧＮＥ#31３１に転送できなかったため、臨時でＮＥ#33３３に転送を行なった。このため、ＮＥ#33３３にはＧＮＥ#31３１とＮＥ#34３４のＤＢファイルが存在する。
図１１と図１２は、本発明によるネットワーク登録時のリモートメモリバックアップ方法（実施例４）を示すシーケンス図（その１）と（その２）である。
以下、図１１と図１２を用いてネットワーク登録時のＲＭＢＵの手順を説明する。
手順1：ネットワーク登録のタイミングで不要なファイルを削除
Ｓ1-1．ネットワーク登録直後のため、不要なファイルを一括削除する。
なお、各ＮＥ３１〜３ｎへの処理は並列で処理を行なう。
手順２：自ＮＥのＤＢファイルをＲＡＭディスクに作成（＝コピー）
Ｓ2-1．ＲＭＢＵ管理テーブルにおいて、バックアップＤＢファイルの作成結果を“作成中”に書き換え、作成日時と作成サイズを初期化する。
Ｓ2-2．ネットワーク内のＮＥ３１〜３ｎの運用ＤＢをバックアップＤＢファイルとしてＲＡＭディスクにコピーする。
Ｓ2-3．バックアップＤＢファイルの作成結果をＲＭＢＵ管理テーブルに設定する。
なお、各ＮＥ３１〜３ｎへの処理は並列で処理を行なう。
手順３：転送先ＮＥへＤＢファイルを転送
Ｓ3-1．ＲＭＢＵ管理テーブルにおいて、バックアップＤＢファイルの転送結果を“転送中”に書き換え、転送日時と転送サイズを初期化する。
Ｓ3-2．手順２で作成したバックアップＤＢファイルをバックアップ先ＮＥに転送する。
Ｓ3-3．ＲＭＢＵ管理テーブルにおいてバックアップＤＢファイルの転送結果と他ＮＥ
バックアップＤＢファイル名を設定する。
なお、各ＮＥ３１〜３ｎへの処理はグループ単位に並列で処理を行ない、同一グループ内では直列で処理を行う。
手順４：手順２でコピーしたＤＢファイルと手順３で転送したＤＢファイルの日時とサイズを取得
Ｓ4-1．ＮＥからバックアップＤＢファイルの作成日時と作成サイズおよび転送日時と転送サイズを読み出す。
Ｓ4-2．ＲＭＢＵ管理テーブルにおいてＤＢファイル作成日時と作成サイズおよび転送日時と転送サイズを設定する。
なお、各ＮＥ３１〜３ｎへの処理は並列で処理を行なう。
手順５：次回のＲＭＢＵ開始時刻になるまで待機し、開始時刻になったら手順１〜４を繰り返す
図１３〜図１５は、本発明による装置増設時のリモートメモリバックアップ方法（実施例５）を示すシーケンス図（その１）〜（その３）である。
以下、図１３〜図１５を用いて装置増設時のＲＭＢＵの手順を説明する。
手順１：ネットワーク構成変更のタイミングで不要なファイルを削除
Ｓ1-1．該当ＲＭＢＵ管理テーブルに増設したＮＥ情報を追加する。そして、増設したＮＥに対して不要なファイルを削除する。
手順２：グループ番号＝１の自ＮＥのＤＢファイルをＲＡＭディスクに作成（＝コピー）
Ｓ2-1．ＲＭＢＵ管理テーブルにおいて、グループ番号＝１のバックアップＤＢファイルの作成結果を“作成中”に書き換え、作成日時とサイズを初期化する。
Ｓ2-2．ネットワーク内のＮＥの運用ＤＢをバックアップＤＢファイルとしてＲＡＭディスクにコピーする。
Ｓ2-3．バックアップＤＢファイルの作成結果をRMBU管理テーブルに設定する。
なお、各ＮＥ３１〜３ｎへの処理は並列で処理を行なう。
手順３：グループ番号＝１のＮＥのＤＢファイルを転送先ＮＥへ転送
Ｓ3-1．ＲＭＢＵ管理テーブルにおいて、グループ番号＝１のバックアップＤＢファイルの転送結果を“転送中”に書き換え、転送日時とサイズを初期化する。
Ｓ3-2．手順２で作成したバックアップＤＢファイルをバックアップ先ＮＥに転送する。
Ｓ3-3．ＲＭＢＵ管理テーブルにおいてバックアップＤＢファイルの転送結果と他ＮＥ
バックアップＤＢファイル名を設定する。
なお、各ＮＥ３１〜３ｎへの処理はグループ単位に並列で処理を行ない、同一グループ内では直列で処理を行う。
手順４：手順２でコピーしたＤＢファイルと手順３で転送したＤＢファイルの日時とサイズを取得
Ｓ4-1．ＮＥからバックアップＤＢファイルの作成日時と作成サイズおよび転送日時と転送サイズを読み出す。
Ｓ4-2．ＲＭＢＵ管理テーブルにおいてＤＢファイル作成日時と作成サイズおよび転送日時と転送サイズを設定する。
なお、各ＮＥ３１〜３ｎへの処理は並列で処理を行なう。
手順５：次回のＲＭＢＵ開始時刻になるまで待機し、開始時刻になったら手順１〜４を繰り返す
図１６〜図１８は、本発明による装置減設時のリモートメモリバックアップ方法（実施例６）を示すシーケンス図（その１）〜（その３）である。
以下、図１６〜図１８を用いて装置減設時のＲＭＢＵの手順を説明する。
撤去されたＮＥ情報が削除されたＲＭＢＵ管理テーブルに従って、グループ構成が変更になったグループ番号＝１のみＲＭＢＵを実施する。
手順1：ネットワーク構成変更のタイミングで不要なファイルを削除
Ｓ1-1．該当ＲＭＢＵ管理テーブルから撤去したＮＥ#35３5を削除する。
手順２：グループ番号＝１の自ＮＥのＤＢファイルをＲＡＭディスクに作成(=コピー)
Ｓ2-1．ＲＭＢＵ管理テーブルにおいて、グループ番号＝１のバックアップＤＢファイルの作成結果を“作成中”に書き換え、作成日時とサイズを初期化する。
Ｓ2-2．ネットワーク内のＮＥの運用ＤＢをバックアップＤＢファイルとしてＲＡＭディスクにコピーする。
Ｓ2-3．バックアップＤＢファイルの作成結果をＲＭＢＵ管理テーブルに設定する。
なお、各ＮＥ３１〜３ｎへの処理は並列で処理を行なう。
手順３：グループ番号＝１のＮＥのＤＢファイルを転送先ＮＥへ転送
Ｓ3-1．ＲＭＢＵ管理テーブルにおいて、グループ番号＝１のバックアップＤＢファイルの転送結果を“転送中”に書き換え、転送日時とサイズを初期化する。
Ｓ3-2．手順２で作成したバックアップＤＢファイルをバックアップ先ＮＥに転送する。
Ｓ3-3．ＲＭＢＵ管理テーブルにおいてバックアップＤＢファイルの転送結果と他ＮＥ
バックアップＤＢファイル名を設定する。
なお、各ＮＥ３１〜３ｎへの処理はグループ単位に並列で処理を行ない、同一グループ内では直列で処理を行う。
手順４：手順２でコピーしたＤＢファイルと手順３で転送したＤＢファイルの日時とサイズを取得
Ｓ4-1．ＮＥからバックアップＤＢファイルの作成日時と作成サイズおよび転送日時と転送サイズを読み出す。そして、ＲＭＢＵ管理テーブルにおいてＤＢファイル作成日時と作成サイズおよび転送日時と転送サイズを設定する。
なお、各ＮＥ３１〜３ｎへの処理は並列で処理を行なう。
手順５：次回のＲＭＢＵ開始時刻になるまで待機し、開始時刻になったら手順１〜４を繰り返す
図１９〜図２１は、本発明による定期監視時のリモートメモリバックアップ方法（実施例７）を示すシーケンス図（その１）〜（その３）である。
ＯｐＳ内のＲＭＢＵ管理テーブルで管理しているＤＢファイルがバックアップ先のＮＥに保存されていることを定期的（例えば１時間周期）に監視する。
以下、図１９〜図２１を用いて定期監視時のＲＭＢＵの手順を説明する。
手順1：定期監視時刻にＮＥにバックアップしたＤＢファイルの情報を取得しチェック
Ｓ1-1．例えば1時間周期で、ＮＥにバックアップしたＤＢファイルの作成日時と作成サイズおよび転送日時と転送サイズが、ＲＭＢＵ管理テーブルの管理情報と一致しているかチェックする。
−ＧＮＥ#31３１のＤＢファイル作成日時とサイズが不一致の場合は、手順２と手順４を実施
−ＮＥ#32３2のＤＢファイルの転送日時とサイズが不一致の場合は、手順３と手順４を実施
手順２：ＧＮＥ#31３1のバックアップを実施（ＤＢファイルのコピー＆転送）
Ｓ2-1．ＲＭＢＵ管理テーブルにおいて、ＧＮＥ#31３1のバックアップＤＢファイルの作成結果を“作成中”に書き換え、作成日時と作成サイズを初期化する。
Ｓ2-2．ＧＮＥ#31３1の運用ＤＢをバックアップＤＢファイルとしてＲＡＭディスクにコピーする。
Ｓ2-3．バックアップＤＢファイルの作成結果をＲＭＢＵ管理テーブルに設定する。
Ｓ2-4．ＤＢファイルの転送結果を“転送中”に書き換え、転送日時と転送サイズを初期化する。
Ｓ2-5．ＧＮＥ#31３1のＤＢファイルをＮＥ#32３２へ転送する。
Ｓ2-6．ＲＭＢＵ管理テーブルにおいてバックアップＤＢファイルの転送結果と他ＮＥバックアップＤＢファイル名を設定する。
手順３：ＮＥ#32３２のバックアップを実施（ＤＢファイルの転送）
Ｓ3-1．ＲＭＢＵ管理テーブルにおいて、ＮＥ#32３２のバックアップＤＢファイルの転送結果を“転送中”に書き換え、転送日時と転送サイズを初期化する。
Ｓ3-2．ＮＥ#32３２のDBファイルをＮＥ#31３１へ転送する。
Ｓ3-3．ＲＭＢＵ管理テーブルにおいてバックアップＤＢファイルの転送結果と他ＮＥバックアップＤＢファイル名を設定する。
手順４：ＧＮＥ#31３１とＮＥ#32３２のＤＢファイルの日時とサイズを取得
Ｓ4-1．ＲＭＢＵ管理テーブルにおいて、ＧＮＥ#31３１とＮＥ#32３２のバックアップＤＢファイルの作成日時と作成サイズおよび転送日時と転送サイズを読み出す。
Ｓ4-2．ＲＭＢＵ管理テーブルにおいてＤＢファイル作成日時と作成サイズおよび転送日時と転送サイズを設定する。
図２２は、本発明による装置復旧時のリモートメモリリストア方法（実施例８）を示すシーケンス図である。
以下、図２２を用いて装置復旧時のＲＭＲＳの手順を説明する。
手順1：復旧するＮＥ#32３２の不要なファイルを削除
Ｓ1-1．ＯｐＳサーバ５からのＲＭＲＳ要求により復旧するＮＥ#32３２の不要なファイルを削除する。
手順２：ＧＮＥ#31３１からＮＥ#32３２のバックアップＤＢファイルを転送
Ｓ2-1．ＧＮＥ#31３１に存在するＮＥ#32３２のＤＢファイルをＮＥ#32３２のＲＡＭディスクに転送する。
手順３：ＮＥ#32３２のリストアを実施
Ｓ3-1．ＮＥ#32３２のＤＢファイルをＲＡＭディスクからＦＬＡＳＨメモリにコピーする。
本発明は、短時間で全てのＮＥのＤＢバックアップを自動で行うことができ、且つ、プロビジョニング設定を行った場合にも予約した時間内にリモートメモリバックアップを自動で行えるとともに、ＮＥが故障時には短時間にリモートメモリリストアを行えるため、保守作業の軽減化に利用できる。
１１〜１ｎ ネットワーク１に設置された伝送装置（ＧＮＥ，ＮＥ）
２１〜２ｎ ネットワーク２に設置された伝送装置（ＧＮＥ，ＮＥ）
３１〜３ｎ ネットワーク３に設置された伝送装置（ＧＮＥ，ＮＥ）
４ オペレーション用情報伝送網（ＤＣＮ）
５１，５２ オペレーションシステム用サーバ（ＯｐＳ）
６ オペレーション用情報伝送網（ＤＣＮ）
７ オペレーションクライアント
８ 架前制御端末（ＣＩＴ）
１１１〜１１ｎ ＲＡＭディスク
１２１〜１２ｎ ＦＬＡＳＨメモリ
５１ 設定ファイル（Ｃｏｎｆｉｇファイル）
５２ リモートメモリバックアップ管理テーブル（ＲＭＢＵ管理テーブル）
５３ バックアップＤＢファイル
５４ ネットワーク管理テーブル

Claims (5)

  1. リング型ネットワークを構成する複数の伝送装置の運用データベースを前記伝送装置間でバックアップするバックアップ管理方法であって、
    前記伝送装置のネットワーク登録時とネットワーク更新時に、指定されたネットワーク情報をオペレーションシステムに保持するステップと、
    前記ネットワーク毎にバックアップデータベース情報を前記オペレーションシステムに保持するステップと、
    前記オペレーションシステムからの指示で同一の前記ネットワーク内の隣接する前記伝送装置間でデータベースファイルをバックアップするステップと
    を含むことを特徴とする伝送装置データベースのバックアップ管理方法。
  2. 請求項１記載の伝送装置データベースのバックアップ管理方法において、
    隣接する前記伝送装置へのデータベースのバックアップが失敗した場合、前記オペレーションシステムから別のバックアップ先伝送装置を検索してバックアップすることを特徴とする伝送装置データベースのバックアップ管理方法。
  3. 請求項１記載の伝送装置データベースのバックアップ管理方法において、
    前記バックアップデータベース情報は、複数のグループに分割して管理し、前記伝送装置の増設/減設時に、変更されたグループのみをバックアップすることを特徴とする伝送装置データベースのバックアップ管理方法。
  4. 請求項１記載の伝送装置データベースのバックアップ管理方法において、
    更に、定期的に前記伝送装置のデータベースバックアップ情報を読み出すステップと、読み出した前記伝送装置のデータベースバックアップ情報を、前記オペレーションシ
    ステムに保持された前記バックアップデータベース情報と比較するステップと、
    前記伝送装置の前記データベースファイルに異常があれば、再度バックアップするステップと、
    を含むことを特徴とする伝送装置データベースのバックアップ管理方法。
  5. リング型ネットワークを構成する複数の伝送装置の運用データベースを前記伝送装置間でリストアするリストア管理方法であって、
    前記伝送装置のネットワーク登録時とネットワーク更新時に、指定されたネットワーク情報をオペレーションシステムに保持するステップと、
    前記ネットワーク毎にバックアップデータベース情報を前記オペレーションシステムに保持するステップと、
    前記オペレーションシステムからの指示でリストアを行うデータベースファイル格納先の前記伝送装置を検索するステップと、
    前記伝送装置のデータベースをリストアするステップと、
    を含むことを特徴とする伝送装置データベースのリストア管理方法。
JP2009035434A 2009-02-18 2009-02-18 伝送装置データベースのバックアップ管理方法およびリストア管理方法 Pending JP2010191690A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2009035434A JP2010191690A (ja) 2009-02-18 2009-02-18 伝送装置データベースのバックアップ管理方法およびリストア管理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2009035434A JP2010191690A (ja) 2009-02-18 2009-02-18 伝送装置データベースのバックアップ管理方法およびリストア管理方法

Publications (1)

Publication Number Publication Date
JP2010191690A true JP2010191690A (ja) 2010-09-02

Family

ID=42817669

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009035434A Pending JP2010191690A (ja) 2009-02-18 2009-02-18 伝送装置データベースのバックアップ管理方法およびリストア管理方法

Country Status (1)

Country Link
JP (1) JP2010191690A (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013162470A (ja) * 2012-02-08 2013-08-19 Fujitsu Telecom Networks Ltd 伝送装置管理システムおよびデータバックアップ方法

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000163344A (ja) * 1998-11-27 2000-06-16 Nec Corp ネットワーク管理システムのデータベース復旧方式
JP2004236030A (ja) * 2003-01-30 2004-08-19 Fujitsu Ltd ネットワーク状況に基づくポリシー適用方式及びそのプログラム
JP2005512346A (ja) * 1999-05-26 2005-04-28 フジツウ ネットワーク コミュニケーションズ，インコーポレイテッド ネットワーク要素管理システム
JP2005234937A (ja) * 2004-02-20 2005-09-02 Sony Corp コンピュータ機器、コンピュータネットワークシステム、パーティション分割方法、パーティション分割変更方法、パーティション分割用プログラムおよびパーティション分割変更用プログラム
JP2005301857A (ja) * 2004-04-15 2005-10-27 Hitachi Ltd バックアップ方法
JP2007006291A (ja) * 2005-06-27 2007-01-11 Mitsubishi Electric Corp ゲートウェイ装置及び中継方法及びプログラム
JP2007174119A (ja) * 2005-12-20 2007-07-05 Mitsubishi Electric Corp レイヤ２ネットワーク
WO2008003596A1 (en) * 2006-07-07 2008-01-10 Alcatel Lucent Distributed hashing mechanism for self-organizing networks

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000163344A (ja) * 1998-11-27 2000-06-16 Nec Corp ネットワーク管理システムのデータベース復旧方式
JP2005512346A (ja) * 1999-05-26 2005-04-28 フジツウ ネットワーク コミュニケーションズ，インコーポレイテッド ネットワーク要素管理システム
JP2004236030A (ja) * 2003-01-30 2004-08-19 Fujitsu Ltd ネットワーク状況に基づくポリシー適用方式及びそのプログラム
JP2005234937A (ja) * 2004-02-20 2005-09-02 Sony Corp コンピュータ機器、コンピュータネットワークシステム、パーティション分割方法、パーティション分割変更方法、パーティション分割用プログラムおよびパーティション分割変更用プログラム
JP2005301857A (ja) * 2004-04-15 2005-10-27 Hitachi Ltd バックアップ方法
JP2007006291A (ja) * 2005-06-27 2007-01-11 Mitsubishi Electric Corp ゲートウェイ装置及び中継方法及びプログラム
JP2007174119A (ja) * 2005-12-20 2007-07-05 Mitsubishi Electric Corp レイヤ２ネットワーク
WO2008003596A1 (en) * 2006-07-07 2008-01-10 Alcatel Lucent Distributed hashing mechanism for self-organizing networks

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013162470A (ja) * 2012-02-08 2013-08-19 Fujitsu Telecom Networks Ltd 伝送装置管理システムおよびデータバックアップ方法

Similar Documents

Publication Publication Date Title
US7428657B2 (en) Method for rolling back from snapshot with log
WO2010106991A1 (ja) データの複製管理方法及びシステム
CN103546914B (zh) 一种hss主备管理的方法及装置
CN103580915B (zh) 集群系统中确定主控节点的方法及装置
CN104486319B (zh) 适用于高可用系统的配置文件实时同步方法及其系统
CA2922665A1 (en) Distributed file system using consensus nodes
CN111427728B (zh) 状态管理方法、主备切换方法及电子设备
CN107357681B (zh) 基于salt的Zookeeper备份管理系统及方法
CN110545207B (zh) 一种同步自动化的智能dns系统及配置方法
CN112463448A (zh) 分布式集群数据库同步方法、装置、设备及存储介质
CN105635216A (zh) 分布式应用的升级方法、设备和分布式系统
CN105610566A (zh) 主备节点间数据实时同步的方法及系统
CN104899116A (zh) 数据备份的方法、源服务器、目标服务器及系统
CN115658390A (zh) 容器容灾方法、系统、装置、设备及计算机可读存储介质
CN114422418B (zh) 基于sdn的卫星网络路由切换方法、装置及存储介质
CN110716828B (zh) 一种数据库实时备份方法
JP2010191690A (ja) 伝送装置データベースのバックアップ管理方法およびリストア管理方法
WO2017016196A1 (zh) 同步数据方法、装置及系统
WO2002001347A2 (en) Method and system for automatic re-assignment of software components of a failed host
CN110247862B (zh) Sdn集群故障时业务快速连续切换系统及方法
CN112612650B (zh) 一种基于文件系统的字节级实时复制的快速恢复方法及系统
CN112087343B (zh) 一种坐席管理系统的组网与通讯方法
CN110688259A (zh) 一种私有云备份恢复系统及其备份恢复方法
JP2010016597A (ja) ノード及びネットワークシステム
CN116723104A (zh) 一种配置恢复方法以及装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20111006

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20130422

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130528

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20131203