JP2019197352A - サービス継続システムおよびサービス継続方法 - Google Patents

サービス継続システムおよびサービス継続方法 Download PDF

Info

Publication number
JP2019197352A
JP2019197352A JP2018090437A JP2018090437A JP2019197352A JP 2019197352 A JP2019197352 A JP 2019197352A JP 2018090437 A JP2018090437 A JP 2018090437A JP 2018090437 A JP2018090437 A JP 2018090437A JP 2019197352 A JP2019197352 A JP 2019197352A
Authority
JP
Japan
Prior art keywords
service
virtual server
standby
active
server
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.)
Granted
Application number
JP2018090437A
Other languages
English (en)
Other versions
JP6856574B2 (ja
Inventor
伸夫 小内
Nobuo Kouchi
伸夫 小内
直幸 丹治
Naoyuki Tanji
直幸 丹治
直樹 武
Naoki Take
直樹 武
高橋謙輔
Kensuke Takahashi
謙輔 高橋
田中　宏幸
Hiroyuki Tanaka
宏幸 田中
加藤　浩
Hiroshi Kato
浩 加藤
啓之 矢崎
Hiroyuki Yazaki
啓之 矢崎
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.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
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 Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2018090437A priority Critical patent/JP6856574B2/ja
Priority to PCT/JP2019/017292 priority patent/WO2019216210A1/ja
Priority to US17/053,628 priority patent/US11954509B2/en
Publication of JP2019197352A publication Critical patent/JP2019197352A/ja
Application granted granted Critical
Publication of JP6856574B2 publication Critical patent/JP6856574B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1438—Restarting or rejuvenating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751—Error or fault detection not based on redundancy
    • G06F11/0754—Error or fault detection not based on redundancy by exceeding limits
    • G06F11/0757—Error or fault detection not based on redundancy by exceeding limits by exceeding a time limit, i.e. time-out, e.g. watchdogs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1479—Generic software techniques for error detection or fault masking
    • G06F11/1482—Generic software techniques for error detection or fault masking by means of middleware or OS functionality
    • G06F11/1484—Generic software techniques for error detection or fault masking by means of middleware or OS functionality involving virtual machines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45591—Monitoring or debugging support
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/815—Virtual

Abstract

【課題】クラウド上の高可用クラスタ構成においてスプリットブレイン問題やサービス停止故障に対処可能とする。【解決手段】運用系仮想サーバ（サーバ３１０）は、待機系仮想サーバ（サーバ３２０）からのハートビートの停止を検知した場合に、連携装置１００に通知する。また、運用系仮想サーバは、サービスの稼働中か非稼働かを連携装置に報告する。連携装置は、ハートビートの停止とサービス稼働中とを受信した場合には、待機系仮想サーバにシステム再起動を指示する。待機系仮想サーバは、システム再起動の指示を受け、サービスの再起動、オペレーティングシステムの再起動、または、サービスの再起動に失敗した場合のオペレーティングシステムの再起動を実行する。【選択図】図４

Description

本発明は、クラウド上で高可用システムを実現するためのサービス継続システムおよびサービス継続方法に関する。
ネットワーク事業者やクラウド事業者が提供するネットワーク、仮想サーバ、ストレージ、Ｗｅｂサーバなどの様々なサービス（卸サービス）を組み合わせて新たなサービスを提供するＢ２Ｂ２Ｘ（Business to Business to X）への対応が、通信キャリアに求められている。サービス提供事業者は、通信キャリアが提供する連携装置（連携サービス）にサービスを要求し、連携装置が、卸サービスのＡＰＩ（Application Programming Interface）を用いて卸サービスを組み合わせて、サービスを構築して最終利用者に提供する（非特許文献１参照）。
一方、ネットワークを利用したミッションクリティカルなサービスについては、ハードウェアの障害やソフトウェアの不具合が発生したとしても、サービスが中断されることなく２４時間３６５日提供されることが求められている。このようなサービスでは、ネットワークやハードウェアを運用系と待機系とに二重化し、運用系に故障が生じた場合に待機系に切り替えて、サービス提供を継続することを可能とする高可用（性）クラスタ構成にしている。
高可用クラスタ構成においては、サービスを提供するプロセスを監視したり、ハートビートを用いてサーバを監視したりして、故障（サービスやサーバの停止）を検知したときに待機系に切り替える。切り替える際には、サービスの二重稼働やネットワークアドレスの二重使用を防ぐため、運用系のサービスを停止する。
しかしながら、ハートビートを転送するネットワーク（インターコネクト）に不具合が生じると、運用系のサービスが稼働しているにもかかわらず、ハートビートが停止して待機系のサービスが稼働してしまい、サービスが二重稼働になってしまうというスプリットブレインの問題が発生する。また、運用系のサービスに故障が発生し、サービスを停止しようとしても停止できないというサービス停止故障が発生すると、待機系への切替えができないという問題が発生する。このような場合には、ＩＰＭＩ（Intelligent Platform Management Interface）を用いて運用系または待機系のサーバを物理的に停止または再起動する。
高橋謙輔他, "複数事業者間サービス連携を柔軟にするアーキテクチャ," 2017年電子情報通信学会通信ソサイエティ大会, B-14-8, P.245, 2017年9月12日.
連携装置が高可用クラスタ構成のサービスを提供する場合、物理サーバに替えて仮想マシンを二重化してクラウド上で高可用クラスタを構成することが考えられる。しかしながら、従来技術を仮想マシンに適用しようとしても、仮想マシンの提供サービスではＩＰＭＩのような物理マシンを操作するインタフェースが卸サービスのＡＰＩとしては提供されていない。このため、スプリットブレインの問題やサービス停止故障に対処できないという問題が生じる。仮にＡＰＩが提供されるとしても、仮想マシンサービスを提供するクラウド事業者に依存することになる。
このような背景を鑑みて本発明がなされたのであり、本発明は、クラウド上の高可用クラスタ構成においてスプリットブレイン問題やサービス停止故障に対処可能とするサービス継続システムおよびサービス継続方法を提供することを課題とする。
前記した課題を解決するため、請求項１に記載の発明は、ネットワークを介してサービスを提供する運用系仮想サーバ、前記運用系仮想サーバとハートビートを相互に送信し、前記運用系仮想サーバからのハートビートが停止した場合に前記サービスを提供する待機系仮想サーバ、および前記運用系仮想サーバと前記待機系仮想サーバと通信可能に接続された連携装置から構成されるサービス継続システムであって、前記運用系仮想サーバが、前記サービスを提供する運用系サービス部と、前記待機系仮想サーバからのハートビートを所定時間受信しない場合、前記連携装置にハートビート停止を通知する運用系ノード監視部と、前記運用系サービス部が稼働中であるか非稼働であるかを前記連携装置に報告する運用系サービス監視部とを備え、前記待機系仮想サーバが、前記サービスを提供する待機系サービス部と、前記連携装置からシステム再起動の指示を受信した場合、前記待機系サービス部の再起動と、前記待機系仮想サーバのオペレーティングシステムの再起動と、前記待機系サービス部の再起動および当該再起動に失敗した後の前記待機系仮想サーバのオペレーティングシステムの再起動との何れか１つを実行する待機系サービス復旧部とを備え、前記連携装置が、前記運用系仮想サーバから前記ハートビート停止を受信し、かつ前記稼働中であるとの報告を受信した場合、前記待機系仮想サーバに前記システム再起動を指示する連携制御部を備えることを特徴とするサービス継続システムとした。
また、請求項８に記載の発明は、ネットワークを介してサービスを提供する運用系仮想サーバ、前記運用系仮想サーバとハートビートを相互に送信し、前記運用系仮想サーバからのハートビートが停止した場合に前記サービスを提供する待機系仮想サーバ、および前記運用系仮想サーバと前記待機系仮想サーバと通信可能に接続された連携装置から構成されるサービス継続システムのサービス継続方法であって、前記運用系仮想サーバが、前記サービスを提供するステップと、前記待機系仮想サーバからのハートビートを所定時間受信しない場合、前記連携装置にハートビート停止を通知するステップと、前記サービスが稼働中であるか非稼働であるかを前記連携装置に報告するステップとを実行し、前記待機系仮想サーバが、前記連携装置からシステム再起動の指示を受信した場合、前記待機系仮想サーバのサービスの再起動と、前記待機系仮想サーバのオペレーティングシステムの再起動と、前記待機系仮想サーバのサービスの再起動および当該再起動に失敗した後の前記待機系仮想サーバのオペレーティングシステムの再起動との何れか１つを実行するステップを実行し、前記連携装置が、前記運用系仮想サーバから前記ハートビート停止を受信し、かつ前記稼働中であるとの報告を受信した場合、前記待機系仮想サーバに前記システム再起動を指示するステップを実行することを特徴とするサービス継続方法とした。
このような構成にすることで、サービス継続システムは、運用系仮想サーバがハートビートを受信せず、サービスが稼働している場合には、待機系のシステムを再起動することで、スプリットブレインの問題を回避することが可能となる。また、サービス継続システムは、待機系仮想サーバを再起動する場合に比べて、短時間で待機系のシステムを再起動したり、強制停止によるシステム破壊を回避して再起動したりすることが可能となる。
請求項２に記載の発明は、前記待機系サービス復旧部が前記待機系仮想サーバのオペレーティングシステムの再起動に失敗した場合、前記連携装置が、前記待機系仮想サーバが稼働する仮想化環境の管理システムに前記待機系仮想サーバの再起動を指示することを特徴とする請求項１に記載のサービス継続システムとした。
このような構成にすることで、サービス継続システムは、待機系のシステムにおいて強制停止によるシステム破壊を回避する再起動が失敗した場合には待機系仮想サーバを強制再起動することが可能となる。
請求項３に記載の発明は、前記運用系仮想サーバが、さらに運用系サービス復旧部を備えており、前記運用系サービス監視部が、前記運用系サービス部が、サービス停止が不可能なことを示すサービス停止故障を検知して前記連携装置に通知し、前記連携制御部が、前記運用系仮想サーバから前記サービス停止故障を受信した場合、前記運用系仮想サーバにシステム停止を指示し、前記運用系サービス復旧部が、前記連携装置から前記システム停止の指示を受信した場合、前記運用系仮想サーバのオペレーティングシステムの停止を実行することを特徴とする請求項１に記載のサービス継続システムとした。
このような構成にすることで、サービス継続システムは、スプリットブレインの問題を回避するとともに、運用系仮想サーバにおいてサービスが停止できない場合には、強制停止によるシステム破壊を回避しながらシステムを停止することで、サービス停止故障に対応することが可能となる。
請求項４に記載の発明は、前記運用系サービス復旧部が前記運用系仮想サーバのオペレーティングシステムの停止に失敗した場合、前記連携装置が、前記運用系仮想サーバが稼働する仮想化環境の管理システムに前記運用系仮想サーバの停止を指示することを特徴とする請求項３に記載のサービス継続システムとした。
このような構成にすることで、サービス継続システムは、運用系のシステムにおいて強制停止によるシステム破壊を回避する停止が失敗した場合には運用系仮想サーバを強制停止することが可能となる。
請求項５に記載の発明は、ネットワークを介してサービスを提供する運用系仮想サーバ、前記運用系仮想サーバとハートビートを相互に送信し、前記運用系仮想サーバからのハートビートが停止した場合に前記サービスを提供する待機系仮想サーバ、および前記運用系仮想サーバと前記待機系仮想サーバと通信可能に接続された連携装置から構成されるサービス継続システムであって、前記運用系仮想サーバが、前記サービスを提供する運用系サービス部と、前記運用系サービス部がサービス停止が不可能なことを示すサービス停止故障を検知して前記連携装置に通知する運用系サービス監視部と、前記連携装置からシステム停止の指示を受信した場合、前記運用系仮想サーバのオペレーティングシステムの停止を実行する運用系サービス復旧部とを備え、前記連携装置が、前記運用系仮想サーバから前記サービス停止故障を受信した場合、前記運用系仮想サーバに前記システム停止を指示する連携制御部を備えることを特徴とするサービス継続システムとした。
このような構成にすることで、サービス継続システムは、運用系仮想サーバにおいてサービスが停止できない場合には、強制停止によるシステム破壊を回避しながらシステムを停止することで、サービス停止故障に対応することが可能となる。
請求項６に記載の発明は、ネットワークを介してサービスを提供する運用系仮想サーバ、および、前記運用系仮想サーバとハートビートを相互に送信し、前記運用系仮想サーバからのハートビートが停止した場合に前記サービスを提供する待機系仮想サーバから構成されるサービス継続システムであって、前記運用系仮想サーバが、前記待機系仮想サーバからのハートビートを所定時間受信せず、前記サービスが稼働中である場合、前記待機系仮想サーバへのシステム再起動の指示と、前記待機系仮想サーバが稼働する仮想化環境の管理システムへの前記待機系仮想サーバの再起動の指示と、前記待機系仮想サーバへのシステム再起動および当該システム再起動が失敗した後の前記待機系仮想サーバが稼働する仮想化環境の管理システムへの前記待機系仮想サーバの再起動の指示との何れか１つを実行する制御部を備え、前記待機系仮想サーバが、前記システム再起動の指示を受信した場合、前記サービスを提供するプロセスの再起動と、前記待機系仮想サーバのオペレーティングシステムの再起動と、前記サービスを提供するプロセスの再起動および当該再起動に失敗した後の前記待機系仮想サーバのオペレーティングシステムの再起動との何れか１つを実行する制御部を備えることを特徴とするサービス継続システムとした。
このような構成にすることで、サービス継続システムは、運用系仮想サーバがハートビートを受信せず、サービスが稼働している場合には、待機系のシステムを再起動することで、スプリットブレインの問題を回避することが可能となる。また、サービス継続システムは、待機系仮想サーバを再起動する場合に比べて、短時間で待機系のシステムを再起動したり、強制停止によるシステム破壊を回避して再起動したり、当該再起動が不可能な場合には強制再起動したりすることが可能となる。
請求項７に記載の発明は、ネットワークを介してサービスを提供する運用系仮想サーバ、および、前記運用系仮想サーバとハートビートを相互に送信し、前記運用系仮想サーバからのハートビートが停止した場合に前記サービスを提供する待機系仮想サーバから構成されるサービス継続システムであって、前記運用系仮想サーバが、前記サービスを提供する運用系サービス部と、前記運用系サービス部がサービス停止が不可能なことを示すサービス停止故障を検知する運用系サービス監視部と、前記運用系サービス監視部が前記サービス停止故障を検知した場合、前記運用系仮想サーバのオペレーティングシステムの停止と、前記運用系仮想サーバが稼働する仮想化環境の管理システムへの前記運用系仮想サーバの停止指示との何れか１つを実行する運用系サービス復旧部とを備えることを特徴とするサービス継続システムとした。
このような構成にすることで、サービス継続システムは、運用系仮想サーバにおいてサービスが停止できない場合には、強制停止によるシステム破壊を回避しながら運用系システムを停止する、または運用系仮想サーバを強制停止することで、サービス停止故障に対応することが可能となる。
本発明によれば、クラウド上の高可用クラスタ構成においてスプリットブレイン問題やサービス停止故障に対処可能とするサービス継続システムおよびサービス継続方法を提供することができる。
従来技術における高可用クラスタ構成を説明するための図である。 従来技術における、運用系のデータベースサービス部に故障が発生した場合に、運用系のサーバから待機系のサーバへ切り替える処理のシーケンス図である。 従来技術における、運用系のサーバに故障が発生した場合に、運用系のサーバから待機系のサーバへ切り替える処理のシーケンス図である。 本実施形態に係るサービス継続システムの全体構成を示す図である。 本実施形態に係るサービス継続システムのスプリットブレイン問題発生時の対応処理を示すシーケンス図である。 本実施形態に係るサービス継続システムのサービス停止故障発生時の対応処理を示すシーケンス図である。
本発明の実施形態を説明する前に、従来技術の高可用（性）クラスタ構成における切替え処理やスプリットブレイン問題、サービス停止故障を説明する。
≪従来技術の高可用クラスタの構成≫
図１は、従来技術における高可用クラスタ構成を説明するための図である。図１を参照して、データベースサービスを提供する物理サーバの高可用クラスタ構成を説明する。サーバ９１０は、運用系のサーバであり、サーバ９２０は、待機系のサーバである。サーバ９１０とサーバ９２０とは、インターコネクト９４０で相互に接続されており、ハートビートを送信し合うことで、相手のサーバが動作していることを確認する。インターコネクト９４０は、通常２つ以上のネットワークで構成される。また、サーバ９１０とサーバ９２０とは、外部のネットワークＮＥＴに接続されており、サービスを要求する端末（不図示）と通信することができる。
サーバ９１０とサーバ９２０とは、それぞれデータベースサービス部（図１ではＤＢ（Database）サービス部と記載）９１１，９２１、サービス監視部９１２，９２２、ノード監視部９１３，９２３、およびサービス復旧部９１４，９２４を含んで構成される。最初に運用系のサーバ９１０の構成、次に待機系のサーバ９２０の構成を説明する。
運用系のサーバ９１０のデータベースサービス部９１１は、ネットワークＮＥＴに接続された端末から要求を受け付けてデータベースサービスを提供している運用中のサービス（プロセス）である。
サービス監視部９１２は、データベースサービス部９１１が動作していることを監視するプロセス（エージェント）である。サービス監視部９１２は、データベースサービス部９１１にクエリを定期的に送信するなどして、データベースサービス部９１１が動作していることを確認して監視する。データベースサービス部９１１の動作が確認できない場合、サービス監視部９１２は、故障が発生したと判断して後記するサービス復旧部９１４に通知する。
ノード監視部９１３は、インターコネクト９４０を介してサーバ９２０とハートビートを送受信し、待機系のサーバ９２０が動作していることを確認する。
サービス復旧部９１４は、故障が発生した場合に、後記するサーバの切替えを実行する。
続いて、待機系のサーバ９２０の構成を説明する。データベースサービス部９２１は、運用系のサーバ９１０のデータベースサービス部９１１に故障が発生した場合にサービスを提供するサービス（プロセス）である。データベースサービス部９２１は、切替え時にプロセスを起動してサービスを開始してもよいし、起動済みのプロセスが待機していて、切替え後にサービスを開始してもよい。
サービス監視部９２２は、データベースサービス部９２１が動作していることを監視するプロセス（エージェント）である。
ノード監視部９２３は、インターコネクト９４０を介してハートビートを送受信し、サーバ９１０が動作していることを確認する。また、ノード監視部９２３は、ハートビートを受信しない場合には、サーバ９１０に故障が発生したと判断して後記するサービス復旧部９２４に通知する。
サービス復旧部９２４は、運用系のサーバ９１０に故障が発生した場合に、後記するサーバの切替えを実行する。
ストレージ９３０は、運用系のサーバ９１０に接続されており、データベースサービスのデータを記憶する装置である。
≪切替え処理：サービスに故障発生≫
以下に、データベースサービス部９１１または運用系のサーバ９１０に故障が発生した場合の切替え処理（フェイルオーバ）を説明する。
図２は、従来技術における、運用系のデータベースサービス部９１１に故障が発生した場合に、運用系のサーバ９１０から待機系のサーバ９２０へ切り替える処理のシーケンス図である。図２を参照して、サービス故障時の切替え処理を説明する。
運用系のサーバ９１０のデータベースサービス部９１１に故障が発生すると、サービス監視部９１２が故障を検知して（ステップＳ９０１）、サービス復旧部９１４に通知する（ステップＳ９０２）。次に、サービス復旧部９１４は、データベースサービス部９１１に停止を指示する（ステップＳ９０３）。データベースサービス部９１１が停止した（ステップＳ９０４）後に、サービス復旧部９１４は、ストレージ９３０との接続を解除して（ステップＳ９０５）、待機系のサーバ９２０にサーバ９１０のサービスが停止したことを通知する（ステップＳ９０６）。
待機系のサーバ９２０のサービス復旧部９２４は、ストレージ９３０と接続して（ステップＳ９０７）、データベースサービス部９２１へサービス開始を指示する（ステップＳ９０８）。データベースサービス部９２１がサービスを開始する（ステップＳ９０９）ことで切替えが完了する。
上記した切替え処理においては、運用系のサーバ９１０は、サービス停止後に待機系のサーバ９２０に通知していたが（ステップＳ９０６参照）、通知せず、ハートビートの送信を止めるようにしてもよい。後記する図３で説明するように、ハートビートを停止することで、サービス停止を通知することなく、待機系のサーバ９２０で切替え処理が実行される。
≪切替え処理：サーバに故障発生≫
図３は、従来技術における、運用系のサーバ９１０に故障が発生した場合に、運用系のサーバ９１０から待機系のサーバ９２０へ切り替える処理のシーケンス図である。図３を参照して、サーバ故障時の切替え処理を説明する。
サーバ９１０からのハートビートを受信しなくなると、待機系のサーバ９２０のノード監視部９２３がサーバ９１０の故障を検知して（ステップＳ９２１）、サービス復旧部９２４に通知する（ステップＳ９２２）。次に、サービス復旧部９２４は、ストレージ９３０を接続して（ステップＳ９２３）、データベースサービス部９２１へサービス開始を指示する（ステップＳ９２４）。データベースサービス部９２１がサービスを開始する（ステップＳ９２５）ことで切替え（フェイルオーバ）が完了する。
≪スプリットブレイン問題と対処処理≫
続いて、インターコネクト９４０に故障が発生した場合に発生するスプリットブレイン問題を説明する。インターコネクト９４０に故障が発生すると、図３で説明したように待機系のサーバ９２０は、運用系のサーバ９１０が故障したと判断して（ステップＳ９２１参照）、サービスを開始する（ステップＳ９２５参照）。しかしながら、運用系のサーバ９１０でもサービスは稼働しているため、二重にデータベースのサービスが稼働していることになり、ストレージ９３０にサーバ９１０，９２０の双方から書き込みが発生してデータが破壊されるという、スプリットブレイン問題が発生する。これは、ストレージ９３０に対するサーバ９１０とサーバ９２０と間の排他制御ができていないという問題でもある。
従来技術では、運用系のサーバ９１０のサービス復旧部９１４は、ハートビートが停止し、サービスが稼働中である場合は、サービスが二重に稼働することを回避するために、ＩＰＭＩを用いて待機系のサーバ９２０を強制的に再起動する。なお、再起動後の待機系のサーバ９２０は、運用系のサーバ９１０からのハートビートが停止していてもフェイルオーバしないように設定されている。
≪サービス停止故障と対処処理≫
次に、図２を参照しながら、サービス（リソース）停止故障を説明する。データベースサービス部９１１に故障が発生すると、サービス復旧部９１４はサービスを停止する（ステップＳ９０３〜Ｓ９０４参照）。しかしながら、故障したデータベースサービス部９１１が停止せず（サービス停止が不可能）、ハングアップした状態に陥る場合がある。これがサービス停止故障である。サービス停止故障が発生すると、サーバ９１０がストレージ９３０に接続したままの状態になる。このため、待機系のサーバ９２０への切替えができず、サービスが停止した状態になってしまう。
従来技術では、サーバ９１０のサービス復旧部９１４が、ＩＰＭＩを用いて自身であるサーバ９１０を停止または再起動することで、待機系のサーバ９２０に切り替える。切り替える手順は、図３で説明したとおりである（サーバ９１０の停止または再起動によりハートビートが停止し、ステップＳ９２１以下の処理が開始される）。
≪従来技術をクラウド上の仮想マシンに適用する場合の課題≫
仮想マシンの提供サービスではＩＰＭＩのような物理マシンを操作するインタフェースが、卸サービスのＡＰＩとしては提供されていないため、スプリットブレインの問題やサービス停止故障に対処できないという問題が生じる。仮にＡＰＩが提供されるとしても、仮想マシンサービスを提供するクラウド事業者に依存することになる。
≪本発明の実施形態の全体構成≫
以下に、本発明を実施するための形態（実施形態）におけるサービス継続システムを説明する。図４は、本実施形態に係るサービス継続システム１０の全体構成を示す図である。サービス継続システム１０は、連携装置１００、運用系のサーバ（運用系仮想サーバ）３１０および待機系のサーバ（待機系仮想サーバ）３２０を含んで構成される。
サーバ３１０，３２０は、クラウド事業者が提供する仮想マシンであり、不図示の仮想的なＣＰＵ（Central Processing Unit）、メモリ、通信インタフェースを備える。サーバ３１０とサーバ３２０とは、インターコネクト３４０で相互に接続されており、ハートビートを送信し合うことで、相手のサーバが動作していることを確認する。また、サーバ３１０とサーバ３２０とは、ネットワークＮＥＴに接続されており、サービスを要求する端末や卸サービスのサーバと通信することができる。
ストレージ３３０は、運用系のサーバ３１０に接続されているデータベースサービスのデータを記憶する装置ないしはストレージのサービスである。
≪運用系のサーバの全体構成≫
運用系のサーバ３１０は、仮想的なＣＰＵ（制御部）で動作するデータベースサービス部３１１、サービス監視部３１２、ノード監視部３１３およびサービス復旧部３１４を備える。
データベースサービス部（運用系サービス部）３１１は、図１記載のデータベースサービス部９１１と同様である。
サービス監視部（運用系サービス監視部）３１２は、図１記載のサービス監視部９１２と同様に、データベースサービス部３１１の動作を監視し、動作が確認できない場合には、故障が発生したと判断してサービス復旧部３１４に通知する。サービス監視部９１２とは異なる機能として、連携装置１００からの問い合わせに対して、データベースサービス部３１１の動作状況を報告する。また、データベースサービス部３１１にサービス停止故障が発生した場合に、連携装置１００に通知する。
ノード監視部（運用系ノード監視部）３１３は、図１記載のノード監視部９１３と同様に、ハートビートを送受信して、待機系のサーバ３２０が動作していることを確認する。所定時間ハートビートを受信しない場合、連携装置１００に通知する。
サービス復旧部（運用系サービス復旧部）３１４は、図１記載のサービス復旧部９１４と同様に、故障が発生した場合に、サーバの切替えを実行する。また、連携装置１００からの指示により、データベースサービス部３１１やサーバ３１０のＯＳ（Operating System、不図示）を停止する。
≪待機系のサーバの全体構成≫
続いて、待機系のサーバ３２０の構成を説明する。サーバ３２０は、仮想的なＣＰＵ（制御部）で動作するデータベースサービス部（待機系サービス部）３２１、サービス監視部（待機系サービス監視部）３２２、ノード監視部（待機系ノード監視部）３２３およびサービス復旧部（待機系サービス復旧部）３２４を備え、図１記載のデータベースサービス部９２１、サービス監視部９２２、ノード監視部９２３およびサービス復旧部９２４とそれぞれ同様の構成である。但し、サービス復旧部３２４は、連携装置１００からの指示により、データベースサービス部３２１を再起動する機能を有する。
運用系のサーバ３１０に故障が発生して、待機系のサーバ３２０に切り替わり、サーバ３１０の故障が取り除かれて待機状態になると、運用系と待機系が入れ替わる。データベースサービス部３１１，３２１、サービス監視部３１２，３２２、ノード監視部３１３，３２３およびサービス復旧部３１４，３２４を分けて説明したが、それぞれは相互に同じ機能を有する。
≪その他のサーバの構成≫
上記では、データベースサービスを提供するサーバの高可用クラスタ構成を示したが、Ｗｅｂサーバや仮想端末サーバなど、他のサービスのサーバにおいてもデータベースサービス部３１１，３２１が入れ替わることを除いて同様の構成となる。また、サーバ３１０とサーバ３２０とは、ネットワークＮＥＴを監視して障害発生時にサービス復旧部３１４，３２４に通知するネットワーク監視部を備えてもよい。また、ストレージについても同様の機能を有するストレージ監視部を備えてもよい。
≪連携装置≫
連携装置１００は、サーバ３１０，３２０から故障の通知を受信し、サービスやサーバの停止または再起動を指示する。連携装置１００は、物理サーバとは限らず、仮想マシンであってもよい。また、連携装置１００は、サーバ３１０，３２０と同じクラウド事業者の仮想マシンであってもよいし、別のクラウド事業者にあってもよい。
連携装置１００は、サービス状態管理部１１０およびＡＰＩオーダ実行管理部１２０を備える。なお、サービス状態管理部１１０およびＡＰＩオーダ実行管理部１２０を合わせて連携制御部とも記す。
サービス状態管理部１１０は、サーバ３１０，３２０から故障の通知を受信したり、サービスの動作状況をサーバ３１０，３２０に問い合わせたりする。さらに、動作状況に応じてＡＰＩオーダ実行管理部１２０にサーバやサービスの停止または再起動を指示する。
ＡＰＩオーダ実行管理部１２０は、サービス状態管理部１１０の指示を受けて、サーバ３１０，３２０にサーバやサービスの停止または再起動を指示する。
≪切替え処理≫
スプリットブレイン問題やサービス停止故障が発生しない場合のサービス継続システム１０における切替え処理は、図２と図３とで説明した従来技術における切替え処理と同様である。以下では、スプリットブレイン問題が発生した場合の処理（後記する図５参照）およびサービス停止故障が発生した場合の切替え処理（後記する図６参照）を説明する。
≪スプリットブレイン問題への対応≫
図５は、本実施形態に係るサービス継続システム１０のスプリットブレイン問題発生時の対応処理を示すシーケンス図である。図５を参照して、運用系のサーバ３１０と待機系のサーバ３２０との間でハートビートが送受信されるインターコネクト３４０（図４参照）に故障が発生して、ハートビートが停止した後の処理の流れを説明する。
ステップＳ１０１において、運用系のサーバ３１０のノード監視部３１３は、所定時間ハートビートを受信しないときは、故障が発生したと検知する。
ステップＳ１０２において、ノード監視部３１３は、故障が発生したことを連携装置１００に通知する。
ステップＳ１０３において、連携装置１００のサービス状態管理部１１０は、通知を受信し、サービスの状態をサーバ３１０に問い合わせる。
ステップＳ１０４において、サーバ３１０のサービス監視部３１２は、問い合わせを受信し、データベースサービス部３１１（図５には不図示）の状態（正常稼働か否か）を連携装置１００に報告する。
ステップＳ１０５において、サービス状態管理部１１０は、データベースサービス部３１１が正常稼働であれば（ステップＳ１０５→ＯＫ）ステップＳ１０７に進み、正常稼働でなければ（ステップＳ１０５→ＮＧ）ステップＳ１０６に進む。
ステップＳ１０６に進んだ時点において、データベースサービス部３１１は正常稼働ではないため、待機系のサーバ３２０への切替え処理が実行されることになる。この切替え処理は、図３記載のステップＳ９２１〜Ｓ９２５と同様である。
ステップＳ１０７において、サービス状態管理部１１０は、ＡＰＩオーダ実行管理部１２０に、待機系のサービスを再起動するように指示する。
ステップＳ１０８において、ＡＰＩオーダ実行管理部１２０は、待機系のサーバ３２０にサービスの再起動を指示する。
ステップＳ１０９において、待機系のサーバ３２０のサービス復旧部３２４は、指示を受信し、データベースサービス部３２１に再起動を指示する。
ステップＳ１１０において、データベースサービス部３２１が再起動する。
≪スプリットブレイン問題への対応の特徴≫
ハートビートが停止していて、運用系のサービスが稼働中である場合には、サービス継続システム１０は、待機系のサービスを再起動する。これにより、サービス継続システム１０は、運用系と待機系との双方でサービスが二重に稼働することを防ぐことができ、延いてはストレージ３３０上のデータ破壊を防ぐことができる。
従来技術では、運用系のサーバのサービス復旧部は、ＩＰＭＩを用いて待機系のサーバを強制的に再起動している。クラウド環境ではサーバ（ハードウェア）を操作するＡＰＩが一般的に提供されておらず、再起動できない。これに対して、サービス継続システム１０では、待機系のサービスを再起動可能である。また、データベースサービス部（プロセス）を再起動しているので、仮想マシンである待機系のサーバを再起動するよりも短時間で再起動の処理を終えることができる。このため、サービス継続システム１０では、待機系のサービスの停止時間を短くすることができ、待機系への切替えができない時間を短くすることできる。
≪スプリットブレイン問題への対応の変形例≫
運用系のサービス監視部３１２は、連携装置１００の問い合わせ（ステップＳ１０３）に対してデータベースサービス部３１１の状態を報告している（ステップＳ１０４）。これに対して、サービス監視部３１２は、ノード監視部３１３の故障発生の通知（ステップＳ１０２）とともに、データベースサービス部３１１の状態を報告するようにしてもよい。こうすることにより、サービス継続システム１０は、より速やかにステップＳ１０５以下の処理を実行することができる。
ハートビートが停止していて、運用系のサービスが稼働中である場合には、サービス継続システム１０は、待機系のサービスを再起動することで、二重のサービス稼働を防いでいる。これに対して、連携装置１００が、待機系のサーバ３２０に運用系のサービスが稼働中であることを通知して、待機系のサービス復旧部３２４が切替え処理（図３記載のステップＳ９２３〜Ｓ９２５）を実行しないようにしてもよい。
切替え処理（ステップＳ１０６）においては、待機系のサーバ３２０がハートビートの停止を検知して（図３記載のステップＳ９２１）、切替え処理（図３記載のステップＳ９２３〜Ｓ９２５）が開始される。これに対して、ＡＰＩオーダ実行管理部１２０が、サーバ３２０に指示して、サービス復旧部３２４が切替え処理（図３記載のステップＳ９２３〜Ｓ９２５）を開始するようにしてもよい。
上記実施形態では、連携装置１００の指示により待機系のサーバ３２０においてデータベースサービス部３２１が再起動していた。これに替わり、サービス復旧部３２４が待機系のサーバ３２０のＯＳを再起動してもよい。また、サービス復旧部３２４がデータベースサービス部３２１を再起動し、これに失敗した場合にＯＳを再起動するようにしてもよい。以上に説明したサービスやＯＳの再起動を（待機系）システム再起動とも記す。
システム再起動が失敗した場合に、連携装置１００は、仮想マシンサービスのＡＰＩを用いて（仮想化環境の管理システムに指示して）、待機系のサーバ３２０を再起動するようにしてもよい。なお、システム再起動が成功したか否かは、仮想マシンサービスのＡＰＩを用いて待機系のサーバ３２０の稼働状況を監視することで判定できる。
上記の実施形態では、サービス監視部３１２は、ハートビートが停止し、故障を検知したときに連携装置１００に通知していた。これに対して、データベースサービス部３１１が稼働中であるならば、サービス監視部３１２は、連携装置１００に通知せず、待機系のサーバ３２０にシステム再起動を指示するようにしてもよいし、仮想マシンサービスのＡＰＩを用いてサーバ３２０を再起動するようにしてもよい。または、サービス監視部３１２は、待機系のサーバ３２０にシステム再起動を指示し、システム再起動が失敗した場合には、仮想マシンサービスのＡＰＩを用いてサーバ３２０を再起動するように仮想化環境の管理システムに指示してもよい。何れの場合においても、待機系に切り替わることはなく、スプリットブレイン問題を回避できる。なお、上記したサービス監視部３１２の再起動指示の処理は、サービス復旧部３１４が実行してもよい。
≪サービス停止故障への対応≫
図６は、本実施形態に係るサービス継続システム１０のサービス停止故障発生時の対応処理を示すシーケンス図である。図６を参照して、運用系のサーバ３１０でサービスに故障が発生し、さらにサービス停止故障が発生（後記するステップＳ２０４参照）する場合の処理の流れを説明する。
データベースサービス部３１１に故障が発生した後のステップＳ２０１〜Ｓ２０３の処理は、図２記載のステップＳ９０１〜Ｓ９０３と同様である。
ステップＳ２０４において、データベースサービス部３１１に、サービスが停止不能となるサービス停止故障が発生する。
ステップＳ２０５において、サービス監視部３１２は、サービス停止故障を検知する。
ステップＳ２０６において、サービス監視部３１２は、サービス停止故障を連携装置１００に通知する。
ステップＳ２０７において、サービス状態管理部１１０は、通知を受信し、ＡＰＩオーダ実行管理部１２０に、運用系のサーバ３１０を停止するように指示する。
ステップＳ２０８において、ＡＰＩオーダ実行管理部１２０は、運用系のサーバ３１０にＯＳ停止を指示する。
ステップＳ２０９において、運用系のサーバ３１０のサービス復旧部３１４は、指示を受信し、サーバ３１０のＯＳ（不図示）を停止する。
ステップＳ２１０において、待機系のサーバ３２０が切替え処理を実行する。この切替え処理は、図３記載のステップＳ９２１〜Ｓ９２５と同様である。
≪サービス停止故障への対応の特徴≫
運用系でサービスに故障が発生し、さらにサービス停止故障が発生した場合には、サービス継続システム１０は、運用系のサーバ３１０のＯＳを停止する。これにより、サービス継続システム１０は、運用系から待機系へ切り替えることができ、サービス提供を継続することができる。
従来技術では、運用系のサーバのサービス復旧部は、ＩＰＭＩを用いて運用系のサーバ（ハードウェア）を強制的に停止または再起動している。クラウド環境ではサーバ（ハードウェア）を操作するＡＰＩが一般的に提供されておらず、再起動できない。サービス継続システム１０では、ＯＳを停止しているので、サーバの強制停止によるファイルシステムの破壊などを防ぐことができ、サーバ３１０の復旧をより迅速に行うことができる。
≪サービス停止故障への対応の変形例≫
サービス停止故障が発生した場合、連携装置１００は、運用系のサーバ３１０にＯＳの停止を指示する。指示後の所定時間内に停止しない場合には、連携装置１００は、仮想マシンサービスのＡＰＩを用いて（仮想化環境の管理システムに指示して）サーバ３１０を停止するようにしてもよい。なお、運用系のサーバ３１０が停止したか否かは、仮想マシンサービスのＡＰＩを用いてサーバ３１０の稼働状況を監視することで判定できる。さらに、サーバ３１０の仮想マシンが所定時間内に停止しない場合であって、クラウド事業者がハイパーバイザの再起動のＡＰＩを提供している場合には、このＡＰＩを用いてサーバ３１０の仮想マシンが稼働しているハイパーバイザを再起動するようにしてもよい。
サービス復旧部３１４が指示するサービス停止（図６記載のステップＳ２０３参照）に複数の手法がある場合には、ＯＳ停止（図６記載のステップＳ２０８〜Ｓ２０９参照）に替えて、ステップＳ２０３（第１のサービス停止指示）とは別の手法（第２のサービス停止指示）でデータベースサービス部３１１を停止してもよい。または、サービス復旧部３１４は、ステップＳ２０３とは別の手法でサービス停止をデータベースサービス部３１１に指示し、停止しなかった場合にＯＳを停止するようにしてもよい。これら、サービス停止やＯＳ停止を（運用系）システム停止とも記す。
切替え処理（ステップＳ２１０）においては、待機系のサーバ３２０がハートビートの停止を検知して（図３記載のステップＳ９２１）、切替え処理（図３記載のステップＳ９２３〜Ｓ９２５）が開始される。これに対して、ＡＰＩオーダ実行管理部１２０が、サーバ３２０に指示して、サービス復旧部３２４が切替え処理（図３記載のステップＳ９２３〜Ｓ９２５）を開始するようにしてもよい。
上記の実施形態では、サービス監視部３１２は、サービス停止故障を検知したときに連携装置１００に通知していた。これに対して、連携装置１００に通知せず、サービス復旧部３１４に通知して、サービス復旧部３１４がＯＳを停止するようにしてもよい。または、仮想マシンサービスのＡＰＩを用いてサーバ３１０を停止するようにしてもよい。何れの場合においても、ハートビートが停止するので、待機系のサーバ３２０に切り替わる（図６のステップＳ２１０参照）。
≪変形例：複数の高可用クラスタシステム≫
上記した実施形態では、クラスタを構成するサーバは１ペアであった。１つの連携装置が、複数の運用系と待機系とのペアに対応するようにしてもよい。この場合、連携装置は、ペアごとに、サーバの識別情報やネットワークアドレスなどを関連付けて、クラスタ構成情報として記憶部（不図示）に記憶する。連携装置は、運用系のサーバから故障の通知を受信した場合には、このクラスタ構成情報を参照して、通知した運用系のサーバに対応する待機系のサーバに、サービスの再起動を指示する（図５のＳ１０８参照）。
≪変形例：連携装置の高可用クラスタ化≫
上記した実施形態では、連携装置１００は１つの物理サーバまたはクラウド上の仮想マシンとしていたが、連携装置自体をクラスタ構成にして、運用系と待機系とに二重化して高可用化してもよい。この場合、連携装置であるクラスタ構成に対する連携装置を設けてもよいし、連携装置におけるスプリットブレイン問題やサービス停止故障を無視してクラスタ構成に対する連携装置を設けなくてもよい。また、連携装置と待機系を１つの仮想マシンに同居させてもよい。
≪変形例：サービス継続システムの動作環境≫
サーバ３１０，３２０および連携装置１００は、同一クラウド事業者が提供する仮想マシンであってもよいし、同一クラウド事業者の異なるリージョン（またはアベイラビリティゾーン）の仮想マシンであってもよいし、異なるクラウド事業者が提供する仮想マシンであってもよい。待機系のサーバと運用系のサーバとを異なるリージョン、異なるアベイラビリティゾーンまたは異なるクラウド事業者に設置することで、電源断、通信断、災害などによる運用系と待機系との同時の障害発生のリスクを削減することができる。
また、サーバ３１０，３２０の双方または一方が、仮想マシンではなく、ベアメタルサーバであってもよい。例えば、運用系のサーバをベアメタルサーバとすることで、仮想化技術によるオーバヘッドをなくし、より効率的なサービス提供を行うことができる。
ノード監視部３１３，３２３は、所定時間、ハートビートを受信しないと、相手のサーバに故障が発生したと判断する。一方、運用系と待機系のサーバとが、異なるリージョン、異なるアベイラビリティゾーンまたは異なるクラウド事業者に設置されると、ネットワーク輻輳の影響を受けてハートビートの送信から受信までの時間（転送時間）が変動する可能性がある。これを考慮し、ノード監視部３１３，３２３は、ハートビートの受信が停止して故障と判断するまでの時間を、受信停止前のハートビートの転送時間に応じて変化させてもよい。転送時間は、ハートビートに送信時刻を含めることにより測定できる。
１０ サービス継続システム
１００ 連携装置
１１０ サービス状態管理部（連携制御部）
１２０ ＡＰＩオーダ実行管理部（連携制御部）
３１０ サーバ（運用系仮想サーバ）
３１１ データベースサービス部（運用系サービス部）
３１２ サービス監視部（運用系サービス監視部）
３１３ ノード監視部（運用系ノード監視部）
３１４ サービス復旧部（運用系サービス復旧部）
３２０ サーバ（待機系仮想サーバ）
３２１ データベースサービス部（待機系サービス部）
３２２ サービス監視部（待機系サービス監視部）
３２３ ノード監視部（待機系ノード監視部）
３２４ サービス復旧部（待機系サービス復旧部）

Claims (8)

  1. ネットワークを介してサービスを提供する運用系仮想サーバ、前記運用系仮想サーバとハートビートを相互に送信し、前記運用系仮想サーバからのハートビートが停止した場合に前記サービスを提供する待機系仮想サーバ、および前記運用系仮想サーバと前記待機系仮想サーバと通信可能に接続された連携装置から構成されるサービス継続システムであって、
    前記運用系仮想サーバは、
    前記サービスを提供する運用系サービス部と、
    前記待機系仮想サーバからのハートビートを所定時間受信しない場合、前記連携装置にハートビート停止を通知する運用系ノード監視部と、
    前記運用系サービス部が稼働中であるか非稼働であるかを前記連携装置に報告する運用系サービス監視部とを備え、
    前記待機系仮想サーバは、
    前記サービスを提供する待機系サービス部と、
    前記連携装置からシステム再起動の指示を受信した場合、前記待機系サービス部の再起動と、前記待機系仮想サーバのオペレーティングシステムの再起動と、前記待機系サービス部の再起動および当該再起動に失敗した後の前記待機系仮想サーバのオペレーティングシステムの再起動との何れか１つを実行する待機系サービス復旧部とを備え、
    前記連携装置は、
    前記運用系仮想サーバから前記ハートビート停止を受信し、かつ前記稼働中であるとの報告を受信した場合、前記待機系仮想サーバに前記システム再起動を指示する連携制御部を備える
    ことを特徴とするサービス継続システム。
  2. 前記待機系サービス復旧部が前記待機系仮想サーバのオペレーティングシステムの再起動に失敗した場合、前記連携装置が、前記待機系仮想サーバが稼働する仮想化環境の管理システムに前記待機系仮想サーバの再起動を指示する
    ことを特徴とする請求項１に記載のサービス継続システム。
  3. 前記運用系仮想サーバは、さらに運用系サービス復旧部を備えており、
    前記運用系サービス監視部は、前記運用系サービス部が、サービス停止が不可能なことを示すサービス停止故障を検知して前記連携装置に通知し、
    前記連携制御部は、前記運用系仮想サーバから前記サービス停止故障を受信した場合、前記運用系仮想サーバにシステム停止を指示し、
    前記運用系サービス復旧部は、前記連携装置から前記システム停止の指示を受信した場合、前記運用系仮想サーバのオペレーティングシステムの停止を実行する
    ことを特徴とする請求項１に記載のサービス継続システム。
  4. 前記運用系サービス復旧部が前記運用系仮想サーバのオペレーティングシステムの停止に失敗した場合、前記連携装置が、前記運用系仮想サーバが稼働する仮想化環境の管理システムに前記運用系仮想サーバの停止を指示する
    ことを特徴とする請求項３に記載のサービス継続システム。
  5. ネットワークを介してサービスを提供する運用系仮想サーバ、前記運用系仮想サーバとハートビートを相互に送信し、前記運用系仮想サーバからのハートビートが停止した場合に前記サービスを提供する待機系仮想サーバ、および前記運用系仮想サーバと前記待機系仮想サーバと通信可能に接続された連携装置から構成されるサービス継続システムであって、
    前記運用系仮想サーバは、
    前記サービスを提供する運用系サービス部と、
    前記運用系サービス部がサービス停止が不可能なことを示すサービス停止故障を検知して前記連携装置に通知する運用系サービス監視部と、
    前記連携装置からシステム停止の指示を受信した場合、前記運用系仮想サーバのオペレーティングシステムの停止を実行する運用系サービス復旧部とを備え、
    前記連携装置は、
    前記運用系仮想サーバから前記サービス停止故障を受信した場合、前記運用系仮想サーバに前記システム停止を指示する連携制御部を備える
    ことを特徴とするサービス継続システム。
  6. ネットワークを介してサービスを提供する運用系仮想サーバ、および、前記運用系仮想サーバとハートビートを相互に送信し、前記運用系仮想サーバからのハートビートが停止した場合に前記サービスを提供する待機系仮想サーバから構成されるサービス継続システムであって、
    前記運用系仮想サーバは、
    前記待機系仮想サーバからのハートビートを所定時間受信せず、前記サービスが稼働中である場合、前記待機系仮想サーバへのシステム再起動の指示と、前記待機系仮想サーバが稼働する仮想化環境の管理システムへの前記待機系仮想サーバの再起動の指示と、前記待機系仮想サーバへのシステム再起動および当該システム再起動が失敗した後の前記待機系仮想サーバが稼働する仮想化環境の管理システムへの前記待機系仮想サーバの再起動の指示との何れか１つを実行する制御部を備え、
    前記待機系仮想サーバは、
    前記システム再起動の指示を受信した場合、前記サービスを提供するプロセスの再起動と、前記待機系仮想サーバのオペレーティングシステムの再起動と、前記サービスを提供するプロセスの再起動および当該再起動に失敗した後の前記待機系仮想サーバのオペレーティングシステムの再起動との何れか１つを実行する制御部を備える
    ことを特徴とするサービス継続システム。
  7. ネットワークを介してサービスを提供する運用系仮想サーバ、および、前記運用系仮想サーバとハートビートを相互に送信し、前記運用系仮想サーバからのハートビートが停止した場合に前記サービスを提供する待機系仮想サーバから構成されるサービス継続システムであって、
    前記運用系仮想サーバは、
    前記サービスを提供する運用系サービス部と、
    前記運用系サービス部がサービス停止が不可能なことを示すサービス停止故障を検知する運用系サービス監視部と、
    前記運用系サービス監視部が前記サービス停止故障を検知した場合、前記運用系仮想サーバのオペレーティングシステムの停止と、前記運用系仮想サーバが稼働する仮想化環境の管理システムへの前記運用系仮想サーバの停止指示との何れか１つを実行する運用系サービス復旧部とを備える
    ことを特徴とするサービス継続システム。
  8. ネットワークを介してサービスを提供する運用系仮想サーバ、前記運用系仮想サーバとハートビートを相互に送信し、前記運用系仮想サーバからのハートビートが停止した場合に前記サービスを提供する待機系仮想サーバ、および前記運用系仮想サーバと前記待機系仮想サーバと通信可能に接続された連携装置から構成されるサービス継続システムのサービス継続方法であって、
    前記運用系仮想サーバは、
    前記サービスを提供するステップと、
    前記待機系仮想サーバからのハートビートを所定時間受信しない場合、前記連携装置にハートビート停止を通知するステップと、
    前記サービスが稼働中であるか非稼働であるかを前記連携装置に報告するステップとを実行し、
    前記待機系仮想サーバは、
    前記連携装置からシステム再起動の指示を受信した場合、前記待機系仮想サーバのサービスの再起動と、前記待機系仮想サーバのオペレーティングシステムの再起動と、前記待機系仮想サーバのサービスの再起動および当該再起動に失敗した後の前記待機系仮想サーバのオペレーティングシステムの再起動との何れか１つを実行するステップを実行し、
    前記連携装置は、
    前記運用系仮想サーバから前記ハートビート停止を受信し、かつ前記稼働中であるとの報告を受信した場合、前記待機系仮想サーバに前記システム再起動を指示するステップを実行する
    ことを特徴とするサービス継続方法。
JP2018090437A 2018-05-09 2018-05-09 サービス継続システムおよびサービス継続方法 Active JP6856574B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2018090437A JP6856574B2 (ja) 2018-05-09 2018-05-09 サービス継続システムおよびサービス継続方法
PCT/JP2019/017292 WO2019216210A1 (ja) 2018-05-09 2019-04-23 サービス継続システムおよびサービス継続方法
US17/053,628 US11954509B2 (en) 2018-05-09 2019-04-23 Service continuation system and service continuation method between active and standby virtual servers

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2018090437A JP6856574B2 (ja) 2018-05-09 2018-05-09 サービス継続システムおよびサービス継続方法

Publications (2)

Publication Number Publication Date
JP2019197352A true JP2019197352A (ja) 2019-11-14
JP6856574B2 JP6856574B2 (ja) 2021-04-07

Family

ID=68468039

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018090437A Active JP6856574B2 (ja) 2018-05-09 2018-05-09 サービス継続システムおよびサービス継続方法

Country Status (3)

Country Link
US (1) US11954509B2 (ja)
JP (1) JP6856574B2 (ja)
WO (1) WO2019216210A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113867815B (zh) * 2021-09-17 2023-08-11 杭州当虹科技股份有限公司 服务器挂起监测和自动重启方法以及应用其的服务器

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010026714A (ja) * 2008-07-17 2010-02-04 Toshiba Corp クラスタシステムを構成する計算機及びプログラム
JP2016062140A (ja) * 2014-09-16 2016-04-25 日本電信電話株式会社 仮想機器管理装置、仮想機器管理方法及び仮想機器管理プログラム

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000324121A (ja) * 1999-05-11 2000-11-24 Kyushu Nippon Denki Tsushin System Kk ネットワーク管理システムにおける系切り替え装置および方法
GB2353113B (en) * 1999-08-11 2001-10-10 Sun Microsystems Inc Software fault tolerant computer system
JP2004171370A (ja) * 2002-11-21 2004-06-17 Nec Corp 冗長構成におけるクライアント／サーバ間のアドレス制御方式および方法
US8201169B2 (en) * 2009-06-15 2012-06-12 Vmware, Inc. Virtual machine fault tolerance
US10228959B1 (en) * 2011-06-02 2019-03-12 Google Llc Virtual network for virtual machine communication and migration
JP5707355B2 (ja) * 2012-03-13 2015-04-30 株式会社東芝 ホットスタンバイ方式によるクライアントサーバシステム
US11025483B1 (en) * 2016-09-27 2021-06-01 Amazon Technologies, Inc. Fault tolerant virtual private network endpoint node

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010026714A (ja) * 2008-07-17 2010-02-04 Toshiba Corp クラスタシステムを構成する計算機及びプログラム
JP2016062140A (ja) * 2014-09-16 2016-04-25 日本電信電話株式会社 仮想機器管理装置、仮想機器管理方法及び仮想機器管理プログラム

Also Published As

Publication number Publication date
JP6856574B2 (ja) 2021-04-07
US20210247996A1 (en) 2021-08-12
WO2019216210A1 (ja) 2019-11-14
US11954509B2 (en) 2024-04-09

Similar Documents

Publication Publication Date Title
CN102708018B (zh) 一种异常处理方法及系统、代理设备与控制装置
CA2339783C (en) Fault tolerant computer system
EP3210367B1 (en) System and method for disaster recovery of cloud applications
CN105933407B (zh) 一种实现Redis集群高可用的方法及系统
CN106330475B (zh) 一种通信系统中管理主备节点的方法和装置及高可用集群
CN111953566B (zh) 一种基于分布式故障监控的方法和虚拟机高可用系统
EP2637102B1 (en) Cluster system with network node failover
CN104503861A (zh) 一种异常处理方法及系统、代理设备与控制装置
JP5285045B2 (ja) 仮想環境における故障復旧方法及びサーバ及びプログラム
JP2005301436A (ja) クラスタシステムおよびクラスタシステムにおける障害回復方法
CN113438111A (zh) 基于Raft分布式恢复RabbitMQ网络分区的方法及应用
WO2019216210A1 (ja) サービス継続システムおよびサービス継続方法
CN101442437A (zh) 一种实现高可用性的方法、系统及设备
JP2001022709A (ja) クラスタシステム及びプログラムを記憶したコンピュータ読み取り可能な記憶媒体
JP2016066303A (ja) サーバ装置、冗長構成サーバシステム、情報引継プログラム及び情報引継方法
JP2015114952A (ja) ネットワークシステム、監視制御装置およびソフトウェア検証方法
JP5691248B2 (ja) タスク引継プログラム、処理装置及びコンピュータ・システム
KR101883251B1 (ko) 가상 시스템에서 장애 조치를 판단하는 장치 및 그 방법
CN115499296B (zh) 一种云桌面热备管理方法、装置及系统
CN107783855B (zh) 虚拟网元的故障自愈控制装置及方法
CN112491570A (zh) 一种虚拟网卡链路状态设置方法、装置及存储介质
JP6822706B1 (ja) クラスタシステム、サーバ装置、引継ぎ方法、及びプログラム
JP2013156963A (ja) 制御プログラム、制御方法、情報処理装置、制御システム
KR101401006B1 (ko) 고가용성 시스템에서 소프트웨어 업데이트를 수행하기 위한 방법 및 장치
WO2023228233A1 (ja) 障害発生時における自動復旧のためのネットワーク管理

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20191029

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210105

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210225

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: 20210316

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210318

R150 Certificate of patent or registration of utility model

Ref document number: 6856574

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150