JP2018182582A

JP2018182582A - コンフィグ管理装置、コンフィグ管理システム、および、コンフィグ管理方法

Info

Publication number: JP2018182582A
Application number: JP2017081020A
Authority: JP
Inventors: 浩亮坂田; Hiroaki Sakata
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2017-04-17
Filing date: 2017-04-17
Publication date: 2018-11-15
Anticipated expiration: 2037-04-17
Also published as: JP6817876B2

Abstract

【課題】随時更新される通信装置の設定内容を、低負荷でバックアップして信頼性を向上すること。【解決手段】管理装置２は、対象期間Ｔ１の経過後に対象期間Ｔ１において受け付けた設定データの対象である通信装置３を特定し、その特定した通信装置３から装置コンフィグ９を受信してバックアップコンフィグ９１として保存するとともに、通信装置３の装置コンフィグ９に異常が発生したときには、保存したバックアップコンフィグ９１を通信装置３に送信することで、通信装置３の装置コンフィグ９を復元し、その復元後に設定キュー２２に格納された設定データを格納した順に通信装置３に送信することで、通信装置３内の装置コンフィグ９を更新させるバックアップ受付部２５を有する。【選択図】図４

Description

本発明は、コンフィグ管理装置、コンフィグ管理システム、および、コンフィグ管理方法の技術に関する。

装置に障害が発生してしまい、その装置内のファイルが消失してしまう前に、ファイルをバックアップすることが行われる。そして、バックアップされたファイルは、正常な状態の装置へとリストア（復元）される。このバックアップ処理は、ファイルのデータ量が多くなるほど、ディスクアクセス時間や、ファイル転送時の使用帯域などに影響する負荷も高くなってしまう。

そのため、バックアップ対象となるファイルを一部の重要なファイルに絞り込むことで、バックアップ処理の負荷を低減する手法が提案されている。例えば、特許文献１には、ファイルの更新回数、作成日、最終更新日等のファイル処理履歴に基づいて自動的にバックアップの要否を判断する自動バックアップシステムが記載されている。

特開２００４−１３３５３８号公報

なお、キャリアのネットワーク運用においては、ファイルの種類によっては、障害が発生したとしても、その障害発生直前の最新状態を復元できる前提のバックアップ処理が要求されることもある。例えば、通信装置の設定内容を記述したコンフィグファイルは、外部から投入されるコマンドなどにより随時更新される。このコンフィグファイルは、一部の更新内容が欠落しただけでも、サービスを提供しているユーザ通信に影響を及ぼしうる重要なファイルである。

一方で、通信装置のコンフィグファイルが更新される度に、その最新のコンフィグファイルをバックアップ対象としてしまうと、バックアップ処理の負荷も大きくなってしまう。よって、通信装置はバックアップ処理に多くの処理能力を消費してしまうことで、本来の役割であるパケット転送処理に支障が出てしまう。あるいは、バックアップ処理時間が長くなることにより、ネットワークの保守業務に支障が出てしまう。

そこで、本発明は、随時更新される通信装置の設定内容を、低負荷でバックアップして信頼性を向上することを、主な課題とする。

前記課題を解決するために、本発明のコンフィグ管理装置は、以下の特徴を有する。
本発明は、通信装置の装置コンフィグのバックアップ契機を決定する対象期間において受け付けた設定データを、受け付けた順に設定キューに格納するとともに、前記通信装置に送信することで、前記通信装置内の前記装置コンフィグを更新させるコンフィグ更新部と、
前記対象期間の経過後に前記対象期間において受け付けた設定データの対象である前記通信装置を特定し、その特定した通信装置から前記装置コンフィグを受信してバックアップコンフィグとして保存するとともに、
前記通信装置の前記装置コンフィグに異常が発生したときには、保存した前記バックアップコンフィグを前記通信装置に送信することで、前記通信装置の前記装置コンフィグを復元し、その復元後に前記設定キューに格納された設定データを格納した順に前記通信装置に送信することで、前記通信装置内の前記装置コンフィグを更新させるバックアップ制御部と、を有することを特徴とする。

これにより、バックアップ処理の信頼性を向上することができる。つまり、随時更新される通信装置の設定内容は、バックアップコンフィグおよび設定キューに格納されているので、通信装置の装置コンフィグに異常が発生したときでも、バックアップコンフィグと設定キュー内の順序性が守られた設定データとをもとに、最新の装置コンフィグを復元できる。
さらに、装置コンフィグ全体を保存するバックアップ処理は対象期間ごとに行われるため、設定データにより装置コンフィグが更新される度にバックアップ処理を頻繁に起動させる方式に比べ、バックアップ処理の負荷を削減できる。

本発明は、前記コンフィグ更新部が、受け付けた設定データを前記通信装置に送信する際に、受け付けた設定データの内容を前記通信装置の動作環境に適合するコマンドに変換し、その変換後のコマンドを前記通信装置に送信することを特徴とする。

これにより、通信装置の障害前後で別の動作環境の通信装置が使われることになっても、新しい通信装置に適合したコマンドにより適切な装置コンフィグを作成できる。

本発明は、前記バックアップ制御部が、前記特定した通信装置から前記装置コンフィグを受信して前記バックアップコンフィグとして保存する際に、前記装置コンフィグの受信に成功したときには、前記対象期間において受け付けた設定データを前記設定キューから削除し、前記装置コンフィグの受信に失敗したときには、前記対象期間において受け付けた設定データを前記設定キューに残すことを特徴とする。

これにより、通信装置は正常に動作するものの、一時的な通信障害で装置コンフィグのバックアップ送信が失敗してしまった場合でも、次回の対象期間でバックアップ送信をリトライできる。

本発明は、前記コンフィグ管理装置と、前記通信装置とを含めて構成されるコンフィグ管理システムであって、
前記バックアップ制御部が特定した通信装置が、バックアップ対象の前記装置コンフィグを送信する際に、現在動作させているランニングコンフィグを、前記通信装置が起動するときに読み込まれるスタートアップコンフィグとしてコピーし、そのコピーしたスタートアップコンフィグを送信することを特徴とする。

これにより、通信装置が通信処理に用いるためにアクセスが頻繁に発生するランニングコンフィグへのデータアクセス負荷が、バックアップ処理ではスタートアップコンフィグに分散される。よって、通信装置が現在動作させているランニングコンフィグそのものをバックアップ送信する方式に比べ、安定したバックアップ処理ができる。

本発明によれば、随時更新される通信装置の設定内容を、低負荷でバックアップして信頼性を向上することができる。

本実施形態に係わるコンフィグ管理システムにおけるバックアップ時の構成図である。本実施形態に係わるコンフィグ管理システムにおけるリストア時の構成図である。図３（ａ）は、バックアップ回数が多い場合を示す図である。図３（ｂ）は、バックアップの対象期間を設けて、バックアップ回数を減らす場合を示す図である。図３（ｃ）は、図３（ｂ）に対して、さらにバックアップ回数を減らす場合を示す図である。図３（ｄ）は、対象期間の途中で装置コンフィグが障害で消失してしまった場合を示す図である。本実施形態に係わるコンフィグ管理システムの詳細を示す構成図である。本実施形態に係わるコンフィグ管理システムにおけるバックアップ処理とそのリストア処理の概要を示すシーケンス図である。本実施形態に係わるバックアップ処理の各時点におけるデータ内容の具体例を示すテーブルである。本実施形態に係わる図６の具体例に対してバックアップ処理が失敗したときの例を示すテーブルである。本実施形態に係わる図６の具体例に対して設定キューが空であるときのリストア処理の例を示すテーブルである。本実施形態に係わる図６の具体例に対して設定キューに１つの設定があるときのリストア処理の例を示すテーブルである。本実施形態に係わる図６の具体例に対して設定キューに２つの設定があるときのリストア処理の例を示すテーブルである。

以下、本発明の一実施形態について、図面を参照して詳細に説明する。

図１は、コンフィグ管理システムにおけるバックアップ時の構成図である。
コンフィグ管理システムは、設定端末１と、管理装置２と、通信装置３とがネットワークで接続されて構成される。このコンフィグ管理システムを構成する各装置は、ＣＰＵ（Central Processing Unit）と、メモリと、ハードディスクなどの記憶手段（記憶部）と、ネットワークインタフェースとを有するコンピュータとして構成される。
このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラム（アプリケーションや、その略のアプリとも呼ばれる）を実行することにより、各処理部により構成される制御部（制御手段）を動作させる。

各通信装置３は、他の通信装置３との間でパケットを中継する。管理装置２は、各通信装置３であるＮＥ（Network Element）を管理するＥＭＳ（Element Management System）として動作する。具体的には、管理装置２は、設定端末１からの設定指示を受けて生成されるコマンドを各通信装置３に送信する。各通信装置３は、受信したコマンドを実行することにより、自身の装置コンフィグ９を更新する。さらに、各通信装置３に発生する障害に備えるために、管理装置２は各通信装置３から受信した装置コンフィグ９をバックアップとして保存する。

図２は、コンフィグ管理システムにおけるリストア時の構成図である。障害が発生した通信装置３（またはその通信装置３の役割を新たに担う交換後の通信装置３）に対して消失してしまった装置コンフィグ９の代わりに、バックアップしておいた装置コンフィグ９を投入（再設定）することにより通信装置３の設定をリストアする。これにより、通信装置３は、障害直前の状態に復旧される。
以下、図２を参照して、コンフィグ管理システムにおけるバックアップ負荷と、装置コンフィグ９の信頼性との関係を説明する。

図３（ａ）は、バックアップ回数が多い場合を示す図である。この例では、管理装置２は、コマンドＳＣ１１，ＳＣ１２，ＳＣ１３が発行される度に、つまり、装置コンフィグ９が更新される度に、その更新処理を契機として通信装置３の装置コンフィグ９のバックアップを取得する。
これにより、通信装置３の装置コンフィグ９が障害で消失してしまっても、最新の装置コンフィグ９を管理装置２からリストアできるので、更新内容の消失を予防し、装置コンフィグ９の信頼性を高めることができる。一方で、装置コンフィグ９のバックアップの送信回数が多くなってしまうので、バックアップ負荷は上昇してしまい、通信装置３の本来の機能である通信処理を圧迫してしまうこともある。

図３（ｂ）は、バックアップの対象期間を設けて、バックアップ回数を減らす場合を示す図である。まず、バックアップの前準備として、管理装置２はバックアップの対象となる対象期間Ｔ１〜Ｔ３を例えば定期的に設ける。１つの対象期間Ｔ１において何回装置コンフィグ９が更新されたとしても、その更新時刻でのバックアップは行わない。一方、各対象期間Ｔ１〜Ｔ３の期間終了時点を契機として、その最新時点での装置コンフィグ９をバックアップする。つまり、３回の対象期間Ｔ１〜Ｔ３で、３回のバックアップが行われる。なお、図３（ｂ）では３回目のバックアップの図示を省略している。
これにより、装置コンフィグ９の更新頻度が局所的に高くなってしまっても、バックアップの送信回数は一定で済むので、バックアップ負荷を下げることができる。

図３（ｃ）は、図３（ｂ）に対して、さらにバックアップ回数を減らす場合を示す図である。図３（ｂ）と図３（ｃ）との共通点は、バックアップの対象となる対象期間Ｔ１〜Ｔ３を設け、１つの対象期間中に１回以上装置コンフィグ９が更新された場合に、その更新時刻ごとのバックアップは行わず、対象期間後にまとめて１回バックアップを実行する点である。例えば、対象期間Ｔ１ではコマンドＳＣ３１，ＳＣ３２，ＳＣ３３により合計３回の更新が行われたが、その更新内容が反映された装置コンフィグ９がバックアップされるのは、対象期間Ｔ１の終了時点の１回である。
一方、図３（ｃ）では、１つの対象期間（例えば期間Ｔ２）中に装置コンフィグ９が一度も更新されなかったときには、その対象期間Ｔ２の終了時点でのバックアップを省略する。これにより、図３（ｂ）でのバックアップ負荷を下げる効果をさらに高めることができる。
以上、図３（ｃ）で説明したバックアップ回数を減らす効果を得るための構成要素として、後記する図４の対象リスト２３が用いられる。

図３（ｄ）は、対象期間Ｔ２の途中で通信装置３の装置コンフィグ９が障害で消失してしまった場合を示す図である。
まず、装置コンフィグ９に反映されたコマンドＳＣ４１，ＳＣ４２，ＳＣ４３の更新内容は、対象期間Ｔ１の終了時点の装置コンフィグ９に反映された後、バックアップされているので、リストアで復旧できる。
一方、対象期間Ｔ２の開始後に行われたコマンドＳＣ４４の更新内容は、バックアップされる前に消失してしまうことで、装置コンフィグ９の信頼性は低下してしまう。
以上、図３（ｄ）で説明した更新内容の消失による信頼性低下を防ぐための構成要素として、後記する図４の設定キュー２２が用いられる。

図４は、コンフィグ管理システムの詳細を示す構成図である。
管理装置２は、設定受付部２１と、設定キュー２２と、対象リスト２３と、コマンド生成部（コンフィグ更新部）２４と、バックアップ受付部（バックアップ制御部）２５とを含めて構成される。
通信装置３は、コマンド適用部３１と、バックアップ依頼部３２とを含めて構成される。

通信装置３内の設定内容は、装置コンフィグ９によってファイル単位の大まかな更新がなされた後、その装置コンフィグ９をコマンドの実行により細かく修正される。まず、装置コンフィグ９について説明する。
管理装置２と通信装置３との間でやりとりされる装置コンフィグ９は、管理装置２内にバックアップされた状態のバックアップコンフィグ９１と、通信装置３内で現在動作している状態のランニングコンフィグ９２と、通信装置３内で起動時に読み込まれる状態のスタートアップコンフィグ９３とに分類できる。

バックアップ受付部２５は、バックアップ時には、バックアップ依頼部３２から受信した装置コンフィグ９を、バックアップコンフィグ９１として管理装置２に保存する。なお、バックアップ依頼部３２が送信する装置コンフィグ９は、バックアップ時にランニングコンフィグ９２をコピーしたスタートアップコンフィグ９３でもよいし、ランニングコンフィグ９２でもよい。
バックアップ依頼部３２は、リストア時には、バックアップ受付部２５から受信した装置コンフィグ９（バックアップコンフィグ９１）を、通信装置３のランニングコンフィグ９２およびスタートアップコンフィグ９３に適用する。

次に、設定端末１から送信される個々の設定と、その設定を通信装置３に適用するために具体化したコマンドについて説明する。
設定キュー２２には、設定受付部２１が設定端末１から受け付けた個々の設定が、受け付けた順序で格納される。つまり、投入された設定の順序性は、設定キュー２２というＦＩＦＯ（First In, First Out）のデータ構造により保証される。１つの設定は、例えば以下に示すように、項目名とその項目内容とのペアが、１つ以上含まれている。
・対象ユーザ：AAA
・サービス名：サービスX
・変更内容：新規
・パラメータ１：10.50.10.2
・パラメータ２：192.168.10.2
・パラメータ３：1548
・パラメータ４：dhcp_svr
・パラメータ５：id
・パラメータ６：500
なお、設定データは、ＣＳＶ（Comma-Separated Values）形式、ＸＭＬ（Extensible Markup Language）形式、ＲＥＳＴ（REpresentational State Transfer）のＪＳＯＮ（JavaScript（登録商標） Object Notation）形式などの構造化データとして、設定端末１の操作者などの人間が編集しやすいように作成される。

コマンド生成部２４は、設定を読み込み、その設定を通信装置３に適用するためのコマンドを生成し、コマンド適用部３１に実行させる。なお、コマンド生成部２４は、通信装置３の正常時には設定受付部２１から読み込み、障害時には設定キュー２２から読み込む。以下に設定されるコマンドを例示する。telnetコマンドで通信装置３にログインし、その後の各種コマンドで装置コンフィグ９を更新し、最後にexitコマンドで通信装置３からログアウトするコマンド群である。
telnet XXXX
(user;:XX)
(pass:XX)
enable
(pass:XX)
set terminal pager disable
configure
:
Interface port-channel XX…
no shutdown
pppoe sessions XXX
:
end
exit

なお、コマンド生成部２４が設定からコマンドに変換するための解釈ロジックは、通信装置３の環境ごとに個別に用意する。ここでの環境とは、例えば、通信装置３ごと（装置ベンダごと、機種ごと、OSごと）に実装されている。これにより、バックアップ時の通信装置３と、その通信装置３に障害が発生したときに代替する通信装置３とで環境が異なった場合でも、最新の装置コンフィグ９をリストアするためのコマンドを生成できる。つまり、障害が発生した通信装置３が古い機種であり現在は調達ができない場合でも、新しい別の環境の通信装置３を採用できる。

対象リスト２３は、図３（ｃ）で説明したように、対象期間Ｔ１〜Ｔ３ごとに設定され、各期間で装置コンフィグ９が更新された通信装置３のリストである。つまり、各期間の終了時点において、バックアップ処理の対象となる通信装置３のリストである。
ある対象期間において設定受付部２１がある通信装置３に対する設定データを受け付けたとき、設定受付部２１は、その通信装置３を対象リスト２３に追加する。対象リスト２３は、通信装置３のリストであり、例えば、ホスト名などの装置ＩＤと、そのＩＰアドレスなどの対応データとして構成される。以下、３台の通信装置３の情報が含まれる対象リスト２３を例示する。
・装置A「1.1.1.1」
・装置B「2.2.2.2」
・装置E「3.3.3.3」

図５は、コンフィグ管理システムにおけるバックアップ処理とそのリストア処理の概要を示すシーケンス図である。
対象期間Ｔ１において、１回目の設定処理が行われる。この設定処理では、管理装置２は設定端末１からＳ１１１ａで送信された設定データを設定キュー２２に保存し（Ｓ１１１ｂ）、設定データを適用する通信装置３を対象リスト２３に追加し、コマンド生成部２４にコマンドを生成させる（Ｓ１１２ｂ）。通信装置３のコマンド適用部３１は、生成されたコマンドを受信すると、そのコマンドを実行することで、自身のランニングコンフィグ９２を更新する（Ｓ１１２ｃ）。
対象期間Ｔ１において、２回目の設定処理も１回目と同様に行われる（Ｓ１１３ａ，Ｓ１１３ｂ，Ｓ１１４ｂ，Ｓ１１４ｃ）。ここで、Ｓ１１３ｂで設定キュー２２に保存される設定データは、Ｓ１１１ｂの設定データよりも後の順序でエンキューされる。

ここで、対象期間Ｔ１が終了することで設定端末１はバックアップ契機を認識する（Ｓ１１５ａ）。この設定端末１からのバックアップ指示などにより、対象リスト２３にエントリされている通信装置３は自身の装置コンフィグ９を管理装置２に送信することで（Ｓ１１５ｃ）、管理装置２内にバックアップコンフィグ９１として保存させる（Ｓ１１５ｂ）。
さらに、管理装置２はバックアップの成功に伴い、対象期間Ｔ２での対象リスト２３からバックアップに成功した通信装置３を削除するとともに、Ｓ１１１ｂ，Ｓ１１３ｂで設定キュー２２に保存しておいた設定データも削除する。一方、バックアップに失敗してしまった場合は、該当する設定キュー２２のデータと、対象リスト２３のデータは削除せずに残しておく。
以上で対象期間Ｔ２に行われる各処理を説明した。

一方、対象期間Ｔ２では、設定端末１から新たな設定が送信されなかったため、対象リスト２３に通信装置３は追加されなかった。よって、設定端末１がバックアップ契機を認識しても（Ｓ１２１ａ）、そのバックアップの対象となる通信装置３は存在しないため、対象期間Ｔ２でのバックアップは省略される。

対象期間Ｔ３において、前記した対象期間Ｔ１の設定処理と同様に、１回目の設定処理が行われる（Ｓ１３１ａ，Ｓ１３１ｂ，Ｓ１３２ｂ，Ｓ１３２ｃ）。その後、通信装置３に障害が発生してしまい、通信装置３内のランニングコンフィグ９２とスタートアップコンフィグ９３とが消失してしまう（Ｓ１３３ｃ）。
そこで、設定端末１は生存確認信号などでＳ１３３ｃの障害を検知すると、管理装置２に対してリストアの起動を指示する（Ｓ１３４ａ）。管理装置２は、対象期間Ｔ２のＳ１１５ｂにおいて保存しておいたバックアップコンフィグ９１を通信装置３に送信することで（Ｓ１３４ｂ）、スタートアップコンフィグ９３、ランニングコンフィグ９２を通信装置３に再設定させる（Ｓ１３４ｃ）。

しかし、Ｓ１３４ｃで再設定された装置コンフィグ９は、対象期間Ｔ２の終了時点での古いデータであり、対象期間Ｔ３の設定処理（Ｓ１３１ａ）が反映されていない。よって、管理装置２は、Ｓ１３１ｂで設定キュー２２に保存しておいた設定データをデキューし、コマンド生成部２４で設定データから生成させたコマンドを（Ｓ１３５ｂ）通信装置３に送信することで、Ｓ１３４ｃで再設定されたランニングコンフィグ９２を通信装置３に更新させる（Ｓ１３５ｃ）。
これにより、Ｓ１３３ｃの障害発生の直前の装置コンフィグ９（ランニングコンフィグ９２とスタートアップコンフィグ９３）が通信装置３内に復旧できたので、通信装置３の運用を再開することができる。

図６は、バックアップ処理の各時点におけるデータ内容の具体例を示すテーブルである。このテーブルは最左列の時刻ごとに、その時刻における各装置の各データの内容を列挙したものである。さらに、第２列の「イベント」は、その時刻において発生した各種処理を簡潔に説明するものである。
例えば、時刻「10:00」は説明を開始する初期状態である。対象期間の開始時点として、管理装置２内のバックアップコンフィグ９１と、通信装置３内のスタートアップコンフィグ９３と、ランニングコンフィグ９２とはそれぞれ同じ装置コンフィグ９「F1(9:30)」の内容である。なお、「F1(9:30)」は、コンフィグのファイルを示す「F」と、そのバージョン「1」と、その更新時点「(9:30)」との組み合わせを意味する。

次に、時刻「10:10」には、イベントとして設定端末１から新たな設定S1(10:10)が投入される。なお、「S1(10:10)」は、設定（Setting）を示す「S」と、投入順序を示す「1」と、その投入時点「(10:10)」との組み合わせを意味する。この「S1(10:10)」は、この時点ではランニングコンフィグ９２にだけ適用され、「F1(9:30)」から「F2(10:10)」に更新される。なお、図中の「↑SC1」という表記は、矢印の先の装置コンフィグ９に対して、矢印の元の設定データが適用されることを意味する。なお、「SC1」は、設定S1からコマンド生成部２４が生成したコマンド（Setting Command）を示す。
同様に、時刻「10:12」には、イベントとして設定端末１から新たな設定S2(10:12)が投入され、その内容がランニングコンフィグ９２の「F3(10:12)」に更新される。

なお、対象期間を１５分ごとに設定しているため、対象期間Ｔ１（10:00-10:15）の終了時点（10:15）において、バックアップが実行される。ここでは、通信装置３は最新のランニングコンフィグ９２である「F3(10:12)」をスタートアップコンフィグ９３にコピーするとともに、管理装置２に送信する。管理装置２は受信した「F3(10:12)」を自身のバックアップコンフィグ９１に反映する。
次の対象期間Ｔ２（10:15-10:30）では、設定端末１から新たな設定S3(10:24)が投入され、その内容がランニングコンフィグ９２の「F4(10:24)」に更新される。この「F4(10:24)」は、対象期間Ｔ２の終了時点（10:30）において、バックアップ対象となる。

さらに、次の対象期間Ｔ３（10:30-10:45）では、設定端末１から新たな設定が投入されなかったため、設定キュー２２や対象リスト２３には新たなエントリが追加されない。よって、対象期間Ｔ３の終了時点（10:45）では、バックアップコンフィグ９１は最新の「F4(10:24)」のままなので、バックアップは省略される。
以上、図６を参照して、通常時のバックアップ処理の流れを説明した。以下では、図６の通常処理に対して、各種の問題が発生する例を場合分けして説明する。

図７は、図６の具体例に対してバックアップ処理が失敗したときの例を示すテーブルである。
時刻「10:24」までは図６と同じ状態である。
対象期間Ｔ２の終了時点（10:30）において、図６とは異なり、通信回線の切断などにより、「F4(10:24)」のバックアップに失敗してしまう。その結果、ランニングコンフィグ９２からスタートアップコンフィグ９３への装置内のコピーには成功するものの、スタートアップコンフィグ９３は、バックアップ前の古い「F3(10:12)」のままである。このバックアップ失敗に伴い、管理装置２は、設定キュー２２内の設定S3(10:24)と、対象リスト２３内の通信装置３のエントリを削除しないようにする。
これにより、次の対象期間Ｔ３の終了時点（10:45）において、前回失敗してしまったバックアップ処理をリトライする。このリトライには成功することで、バックアップコンフィグ９１も最新の「F4(10:24)」に更新できる。

図８は、図６の具体例に対して設定キュー２２が空であるときのリストア処理の例を示すテーブルである。
時刻「10:30」までは図６と同じ状態である。
対象期間Ｔ３（10:30-10:45）の開始直後（10:31）に装置Ａの障害が発生したため、対象期間Ｔ３における設定キュー２２も対象リスト２３もエントリが存在しない。

この場合には、管理装置２は障害で消失してしまった「F4(10:24)」のバックアップコンフィグ９１を、通信装置３に送信するだけで、通信装置３のスタートアップコンフィグ９３を新規作成する。そして、そのスタートアップコンフィグ９３を再起動で通信装置３に読み込ませることで、ランニングコンフィグ９２も復元させることができる。

図９は、図６の具体例に対して設定キュー２２に１つの設定があるときのリストア処理の例を示すテーブルである。
時刻「10:24」までは図６と同じ状態である。
対象期間Ｔ２（10:15-10:30）の途中（10:26）に装置Ａの障害が発生したため、対象期間Ｔ２における設定キュー２２には設定S3(10:24)が格納されており、対象リスト２３には装置Ａがエントリされている。

この場合には、管理装置２は障害で消失してしまった「F3(10:12)」のバックアップコンフィグ９１を、時刻「10:27」において通信装置３に送信することでスタートアップコンフィグ９３を復元する。さらに、通信装置３の再起動により、スタートアップコンフィグ９３がランニングコンフィグ９２として読み込まれた後に、設定キュー２２内の設定S3(10:24)をコマンド（SC3）としてコマンド適用部３１に投入させる。これにより、ランニングコンフィグ９２を障害直前の「F4(10:24)」と同じ状態に復元（現行化）できる。

図１０は、図６の具体例に対して設定キュー２２に２つの設定があるときのリストア処理の例を示すテーブルである。
時刻「10:12」までは図６と同じ状態である。
対象期間Ｔ１（10:00-10:15）の後半（10:13）に装置Ａの障害が発生したため、対象期間Ｔ１における設定キュー２２には設定データが設定S1(10:10)→設定S2(10:12)の順に（投入された順に）格納されており、対象リスト２３には装置Ａがエントリされている。

この場合には、管理装置２は障害で消失してしまった「F1(9:30)」のバックアップコンフィグ９１を、時刻「10:14」において通信装置３に送信することでスタートアップコンフィグ９３を復元する。さらに、通信装置３の再起動により、スタートアップコンフィグ９３がランニングコンフィグ９２として読み込まれた後に、設定キュー２２内の設定S1(10:10)→設定S2(10:12)を順にコマンド適用部３１に投入させる。これにより、ランニングコンフィグ９２を障害直前の「F3(10:12)」と同じ状態に復元（現行化）できる。

これにより、対象期間Ｔ１（10:00-10:15）の終了時点（10:15）において、復元されたランニングコンフィグ９２である最新の「F3(10:12)」がバックアップされる。なお、設定データの順序性を復元時にも守ることにより、設定S1＝データＸの追加、設定S2＝データＸの削除であるときに、設定順序により結果が変わってしまう場合でも、正しいデータを復元できる。

以上説明した本実施形態では、管理装置２は、対象期間ごとに装置コンフィグ９の更新の有無を対象リスト２３で管理し、対象期間ごとの装置コンフィグ９を更新するための設定データを、設定キュー２２で順序づけて管理する。
そして、通信装置３の障害時には、対象リスト２３から装置コンフィグ９を復元する通信装置３を絞り込むとともに、設定キュー２２から読み込んだ設定データを順に適用する。これにより、随時更新される通信装置３の設定内容を、低負荷でバックアップして信頼性を向上することができる。

１設定端末
２管理装置
３通信装置
２１設定受付部
２２設定キュー
２３対象リスト
２４コマンド生成部（コンフィグ更新部）
２５バックアップ受付部（バックアップ制御部）
３１コマンド適用部
３２バックアップ依頼部
９装置コンフィグ
９１バックアップコンフィグ
９２ランニングコンフィグ
９３スタートアップコンフィグ

Claims

通信装置の装置コンフィグのバックアップ契機を決定する対象期間において受け付けた設定データを、受け付けた順に設定キューに格納するとともに、前記通信装置に送信することで、前記通信装置内の前記装置コンフィグを更新させるコンフィグ更新部と、
前記対象期間の経過後に前記対象期間において受け付けた設定データの対象である前記通信装置を特定し、その特定した通信装置から前記装置コンフィグを受信してバックアップコンフィグとして保存するとともに、
前記通信装置の前記装置コンフィグに異常が発生したときには、保存した前記バックアップコンフィグを前記通信装置に送信することで、前記通信装置の前記装置コンフィグを復元し、その復元後に前記設定キューに格納された設定データを格納した順に前記通信装置に送信することで、前記通信装置内の前記装置コンフィグを更新させるバックアップ制御部と、を有することを特徴とする
コンフィグ管理装置。
前記コンフィグ更新部は、受け付けた設定データを前記通信装置に送信する際に、受け付けた設定データの内容を前記通信装置の動作環境に適合するコマンドに変換し、その変換後のコマンドを前記通信装置に送信することを特徴とする
請求項１に記載のコンフィグ管理装置。
前記バックアップ制御部は、前記特定した通信装置から前記装置コンフィグを受信して前記バックアップコンフィグとして保存する際に、前記装置コンフィグの受信に成功したときには、前記対象期間において受け付けた設定データを前記設定キューから削除し、前記装置コンフィグの受信に失敗したときには、前記対象期間において受け付けた設定データを前記設定キューに残すことを特徴とする
請求項１または請求項２に記載のコンフィグ管理装置。
請求項１ないし請求項３のいずれか１項に記載のコンフィグ管理装置と、前記通信装置とを含めて構成されるコンフィグ管理システムであって、
前記バックアップ制御部が特定した通信装置は、バックアップ対象の前記装置コンフィグを送信する際に、現在動作させているランニングコンフィグを、前記通信装置が起動するときに読み込まれるスタートアップコンフィグとしてコピーし、そのコピーしたスタートアップコンフィグを送信することを特徴とする
コンフィグ管理システム。
コンフィグ更新部と、バックアップ制御部とを有するコンフィグ管理装置によって実行されるコンフィグ管理方法であって、
前記コンフィグ更新部は、
通信装置の装置コンフィグのバックアップ契機を決定する対象期間において受け付けた設定データを、受け付けた順に設定キューに格納するとともに、前記通信装置に送信することで、前記通信装置内の前記装置コンフィグを更新させ、
前記バックアップ制御部は、
前記対象期間の経過後に前記対象期間において受け付けた設定データの対象である前記通信装置を特定し、その特定した通信装置から前記装置コンフィグを受信してバックアップコンフィグとして保存するとともに、
前記通信装置の前記装置コンフィグに異常が発生したときには、保存した前記バックアップコンフィグを前記通信装置に送信することで、前記通信装置の前記装置コンフィグを復元し、その復元後に前記設定キューに格納された設定データを格納した順に前記通信装置に送信することで、前記通信装置内の前記装置コンフィグを更新させることを特徴とする
コンフィグ管理方法。