JP6822706B1 - クラスタシステム、サーバ装置、引継ぎ方法、及びプログラム - Google Patents

Abstract

【課題】現在運用中のサーバ装置においてシステムクラッシュが発生した場合でも高速に他のサーバ装置への引継ぎを行うことが可能なクラスタシステムを提供する。【解決手段】クラスタシステム１は複数のサーバ装置１０，２０及び共有記憶装置３０を備える。サーバ装置１０は、サーバ装置１０における通常稼働時の制御を行う第１カーネル１１と、第１カーネル１１の一部又は全部に障害が発生した場合にメモリダンプ処理を行う第２カーネル１２と、を有する。第１カーネル１１は、起動時に、所定の情報を、上記メモリダンプ処理において出力先とするメモリ１３に書き込む処理を実行する。第２カーネル１２は、上記障害が発生した場合に、メモリ１３内の所定の情報に基づき、共有記憶装置３０からの入出力の切り離し処理と他のサーバ装置２０に障害を通知する通知処理とを実行する。所定の情報は、切り離し処理の対象及び通知処理での通知先を指定する情報を含む。【選択図】図１

Description

本開示は、クラスタシステム、サーバ装置、引継ぎ方法、及びプログラムに関する。

特許文献１には、同じく障害発生時の停止抑制のために、フェイルオーバ機能を有する現用系サーバ及び待機系サーバと、当該現用系サーバ及び待機系サーバにて共有可能なデータを記憶する共有ディスクと、を備えたクラスタシステムが記載されている。ここで、フェイルオーバ機能は、相互に同一のアプリケーションプログラム（アプリケーション）を実行し当該アプリケーションによる他方の処理を引き継ぐことが可能な機能である。

また、特許文献１に記載のシステムでは、現用系サーバの制御装置で障害を検出した場合やＯＳ（Operating System）上のアプリケーションが障害を検出した場合、Ｉ／Ｏフェンシングを実施した後、障害を待機系サーバに通知している。上記制御装置は、ＢＭＣ（Baseboard Management Controller）である。そして、この待機系サーバでは、現用系サーバの制御装置からＩ／Ｏフェンシングが完了した旨の通知を受けて、待機系サーバ上におけるアプリケーションにて現用系サーバ上におけるアプリケーションによる処理が引き継がれる。

特許第６０５６５５４号公報

しかしながら、特許文献１に記載のシステムでは、ＢＭＣがハードウェア障害を認識した場合とＯＳ上のアプリケーション（ソフトウェア）がソフトウェア障害を認識した場合の２点について、高速なフェイルオーバが実現されているに過ぎない。

つまり、特許文献１に記載のシステムでは、システムクラッシュが発生した場合、ＯＳ上のソフトウェアが停止してしまうために障害を認識できず、待機系のハートビートのタイムアウトによって障害を認識する必要がある。しかしながら、ハートビートのタイムアウト時間は、ＯＳの負荷や通信経路の負荷でタイムアウトしないように長めに設定される。そのため、ハートビートのタイムアウトを契機としてフェイルオーバを実行する場合、高速に行うことができない。このように、特許文献１に記載のシステムでは、システムクラッシュが発生した場合には、高速なフェイルオーバを行うことができない。

本開示の目的は、現在運用中のサーバ装置においてシステムクラッシュが発生した場合であっても高速に他のサーバ装置への引継ぎを行うことが可能なクラスタシステム、サーバ装置、引継ぎ方法、及びプログラムを提供することにある。

本開示の第１の態様に係るクラスタシステムは、共有記憶装置と、前記共有記憶装置にアクセス可能で前記共有記憶装置とともに少なくとも可用性を高めるためのクラスタ構成をなす複数のサーバ装置と、を備え、前記サーバ装置は、前記サーバ装置における通常稼働時の制御を行う第１カーネルと、前記第１カーネルの一部又は全部に障害が発生した場合に、メモリダンプ処理を行う第２カーネルと、を有し、前記第１カーネルは、起動時に、所定の情報を、前記第２カーネルが前記メモリダンプ処理において出力先とするメモリに書き込む処理を実行し、前記第２カーネルは、前記第１カーネルの一部又は全部に障害が発生した場合に、前記メモリ内の前記所定の情報に基づき、前記共有記憶装置からの入出力の切り離し処理と前記複数のサーバ装置における他のサーバ装置に障害を通知する通知処理とを実行し、前記所定の情報は、前記切り離し処理の対象及び前記通知処理での通知先を指定する情報を含む、ものである。

本開示の第２の態様に係るサーバ装置は、他のサーバ装置と前記他のサーバ装置からアクセス可能な共有記憶装置とともに少なくとも可用性を高めるためのクラスタ構成をなすサーバ装置であって、前記サーバ装置における通常稼働時の制御を行う第１カーネルと、前記第１カーネルの一部又は全部に障害が発生した場合にメモリダンプ処理を行う第２カーネルと、を有し、前記第１カーネルは、起動時に、所定の情報を、前記第２カーネルが前記メモリダンプ処理において出力先とするメモリに書き込む処理を実行し、前記第２カーネルは、前記第１カーネルの一部又は全部に障害が発生した場合に、前記メモリ内の前記所定の情報に基づき、前記共有記憶装置からの入出力の切り離し処理と前記他のサーバ装置に障害を通知する通知処理とを実行し、前記所定の情報は、前記切り離し処理の対象及び前記通知処理での通知先を指定する情報を含む、ものである。

本開示の第３の態様に係る引継ぎ方法は、他のサーバ装置と共有記憶装置とともに少なくとも可用性を高めるためのクラスタ構成をなすサーバ装置における引継ぎ方法であって、前記サーバ装置は、前記サーバ装置における通常稼働時の制御を行う第１カーネルと、前記第１カーネルの一部又は全部に障害が発生した場合にメモリダンプ処理を行う第２カーネルと、を有し、前記第１カーネルが、起動時に、所定の情報を、前記第２カーネルが前記メモリダンプ処理において出力先とするメモリに書き込む処理を実行し、前記第２カーネルが、前記第１カーネルの一部又は全部に障害が発生した場合に、前記メモリ内の前記所定の情報に基づき、前記共有記憶装置からの入出力の切り離し処理と前記他のサーバ装置に障害を通知する通知処理とを実行し、前記所定の情報は、前記切り離し処理の対象及び前記通知処理での通知先を指定する情報を含む、ものである。

本開示の第４の態様に係るプログラムは、他のサーバ装置と共有記憶装置とともに少なくとも可用性を高めるためのクラスタ構成をなすサーバ装置のコンピュータに実行させるためのプログラムであって、前記サーバ装置における通常稼働時の制御を行う第１カーネルと、前記第１カーネルの一部又は全部に障害が発生した場合にメモリダンプ処理を行う第２カーネルと、を有し、前記第１カーネルは、起動時に、所定の情報を、前記第２カーネルが前記メモリダンプ処理において出力先とするメモリに書き込む処理を実行し、前記第２カーネルは、前記第１カーネルの一部又は全部に障害が発生した場合に、前記メモリ内の前記所定の情報に基づき、前記共有記憶装置からの入出力の切り離し処理と前記他のサーバ装置に障害を通知する通知処理とを実行し、前記所定の情報は、前記切り離し処理の対象及び前記通知処理での通知先を指定する情報を含む、ものである。

本開示により、現在運用中のサーバ装置においてシステムクラッシュが発生した場合であっても高速に他のサーバ装置への引継ぎを行うことが可能なクラスタシステム、サーバ装置、引継ぎ方法、及びプログラムを提供することができる。

実施形態１に係るクラスタシステムの一構成例を示すブロック図である。 図１のクラスタシステムにおける処理例を説明するためのフロー図である。 実施形態２に係るクラスタシステムの一構成例を示すブロック図である。 図３のクラスタシステムの具体例を示す機能ブロック図である。 図４のクラスタシステムにおける現用系サーバのＯＳ起動時の処理例を説明するためのフロー図である。 図４のクラスタシステムにおけるシステムクラッシュ時の処理例を説明するためのフロー図である。 図４のクラスタシステムにおけるシステムクラッシュ時の処理例を説明するための模式図である。 装置のハードウェア構成の一例を示す図である。

以下、図面を参照して、実施形態について説明する。なお、実施形態において、同一又は同等の要素には、同一の符号を付し、重複する説明を省略する場合がある。

＜実施形態１＞
実施形態１について、図１及び図２を参照しながら説明する。
まず、図１を参照しながら、本実施形態に係るクラスタシステムの構成例について説明する。図１は、本実施形態に係るクラスタシステムの一構成例を示すブロック図である。

図１に示すように、本実施形態に係るクラスタシステム１は、２つのサーバ装置（以下、サーバ）１０，２０及び共有記憶装置３０を備えることができ、これらにより少なくとも可用性を高めるためのクラスタ構成（高可用性クラスタ構成）をなす。つまり、クラスタシステム１は、多重化構成（この例では２重化構成）をなし、サーバ１０，２０間での引継ぎ機能（フェールオーバ機能）を有するシステムである。なお、共有記憶装置３０は、サーバ１０，２０のいずれからもアクセス可能になっている。

サーバ１０，２０は、いずれもサーバコンピュータとすることができる。以下では、サーバ１０を現在運用しているサーバ（現用系サーバ）とし、サーバ２０を現在待機中のサーバ（待機系サーバ）として説明する。但し、サーバ１０，２０は、高可用性クラスタ構成をなすためのサーバであり、基本的に同じ機能を有するものとすることができ、いずれを現用系として用いるかは設定しておけばよい。

また、図示しないが、クラスタシステム１には、ＰＣ（Personal Computer）や携帯電話機（スマートフォンと称されるものも含む）等のクライアント装置（以下、クライアント）が接続可能となっている。クライアントは、クラスタシステム４に接続することで、クラスタシステム４から（この例における現時点では現用系サーバ１０から）サービスの提供を受けることができる。

現用系サーバ１０は、第１カーネル（ファーストカーネル）１１、第２カーネル（セカンドカーネル）１２、及びメモリ１３を備えることができる。第１カーネル１１、第２カーネル１２、及びメモリ１３は、現用系サーバ１０の全体を制御する制御部として機能することができる。

この制御部は、例えば、ＣＰＵ（Central Processing Unit）、作業用メモリ、及び、第１カーネル１１及び第２カーネル１２を含むプログラムを記憶した不揮発性の記憶装置などによって実現することができる。第１カーネル１１及び第２カーネル１２は、現用系サーバ１０のＯＳ（Operating System）の一部とすることができる。上記の作業用メモリ又は記憶装置は、メモリ１３として機能させることができる。メモリ１３として機能させる領域を予め確保するなどしておけばよい。なお、この制御部は、その一部又は全部を、例えば集積回路（Integrated Circuit）によって実現することもできる。

待機系サーバ２０も現用系サーバ１０と同様に、第１カーネル２１、第２カーネル２２、及びメモリ２３を備えることができる。第１カーネル２１、第２カーネル２２、及びメモリ２３は、待機系サーバ２０の全体を制御する制御部として機能することができる。

この制御部は、例えば、ＣＰＵ、作業用メモリ、及び、第１カーネル２１及び第２カーネル２２を含むプログラムを記憶した不揮発性の記憶装置などによって実現することができる。第１カーネル２１及び第２カーネル２２は、待機系サーバ２０のＯＳの一部とすることができる。上記の作業用メモリ又は記憶装置は、メモリ２３として機能させることができる。メモリ２３として機能させる領域を予め確保するなどしておけばよい。なお、この制御部は、その一部又は全部を、例えば集積回路によって実現することもできる。

第１カーネル１１は、現用系サーバ１０における通常稼働時の制御を行う。第２カーネル１２は、第１カーネル１１の一部又は全部に障害が発生した場合に、メモリダンプ処理を行うカーネルである。ここで、メモリダンプ処理において出力先とするメモリはメモリ１３とする。

そして、本実施形態の主たる特徴の１つとして、第１カーネル１１は、起動時に、所定の情報を、第２カーネル１２がメモリダンプ処理において出力先とするメモリ１３に書き込む処理を実行する。

第２カーネル１２は、第１カーネル１１の一部又は全部に障害が発生した場合に、メモリ１３内の所定の情報に基づき、共有記憶装置３０からの入出力の切り離し処理と待機系サーバ２０に障害を通知する通知処理とを実行する。この切り離し処理は、現用系サーバ１０を共有記憶装置３０から切り離して入出力が発生しない状態にすることであり、所謂、Ｉ／Ｏフェンシングと称される処理とすることができる。

第１カーネル１１の一部又は全部に障害が発生した場合とは、所謂、システムクラッシュが発生した場合を指すことができる。システムクラッシュは、ここではシステムエラーやバグなどの原因により第１カーネル１１が動かなくなることを指す。また、上述したように、第２カーネル１２は、第１カーネル１１の一部又は全部に障害が発生した場合において、メモリダンプ処理も実行する。

上記所定の情報は、切り離し処理の対象及び通知処理での通知先を指定する情報を含むものとする。このようにして事前にメモリ１３内に記憶された所定の情報に基づき、第２カーネル１２は、第１カーネル１１の一部又は全部に障害が発生した場合に、切り離し処理及び通知処理を実行することができる。

次に、図２を参照しながら、クラスタシステム１における処理例について説明する。図２は、クラスタシステム１における処理例を説明するためのフロー図である。

まず、現用系サーバ１０は、その起動に際し、第１カーネル１１を起動する（ステップＳ１）。第１カーネル１１は、起動時に所定の情報をメモリ１３に書き込む（ステップＳ２）。その後、第２カーネル１２は、第１カーネル１１で障害が発生していないかを監視する（ステップＳ３）。

第２カーネル１２は、障害が発生した場合（ステップＳ３でＹＥＳの場合）には、メモリ１３に記憶された所定の情報に基づき、切り離し処理及び障害通知処理を実行し（ステップＳ４）、処理を終了する。また、ステップＳ４では、上述のように、第２カーネル１２が通常のメモリダンプ処理も実行する。このように、第２カーネル１２は、メモリダンプ処理で使用するメモリ１３にアクセス可能であるため、そのメモリ１３に予め記憶された所定の情報に基づき、切り離し処理及び通知処理を実行することができる。

そして、障害通知処理による通知を受信した待機系サーバ２０は、その受信を契機としてフェイルオーバ処理を行って共有記憶装置３０との入出力を有効にする。これ以降、クライアントは、待機系サーバ２０にアクセスすることでサービスの提供を受けることができる。つまり、クライアントは、現用系サーバ１０の障害により業務が困難になったこと後も、即座に待機系サーバ２０がフェイルオーバ処理を行うことで業務を即座に継続することができる。

このように、待機系サーバ２０は、現用系サーバ１０から通知処理による障害の通知を受信すると、待機系サーバ２０における通常稼働時の制御を行う第１カーネル２１を起動するように構成することができる。換言すれば、待機系サーバ２０は、第１カーネル２１の非稼働時に現用系サーバか１０らの障害の通知を受信した場合に、自身の第１カーネル２１を起動するように構成することができる。ここで、第１カーネル２１は、通常稼働時の制御のために、フェイルオーバ処理を実行することになる。

一方で、高可用性クラスタシステムにおいて、待機系サーバは、現用系サーバとのハートビートがタイムアウトすることで現用系サーバの停止を確認し、フェイルオーバ処理を行うこともできる。これに対し、本実施形態では、現用系サーバ１０のＯＳの能動的な障害通知を契機としてフェイルオーバ処理を実施するため、ハートビートのタイムアウトを契機とした手法に比べて高速にフェイルオーバを実施することができる。

以上のように、本実施形態に係るクラスタシステム１では、現在運用中のサーバ（現用系サーバ１０）においてシステムクラッシュが発生した場合であっても高速に他のサーバ（待機系サーバ２０）への引継ぎを行うことが可能になる。

また、本実施形態に係るクラスタシステム１について、２つのサーバ１０，２０を備えることを前提として説明したが、共有記憶装置にアクセス可能な３つ以上のサーバを備えることもできる。その場合、各サーバにおいて、障害が発生した場合に引継ぎを行う先のサーバを予め指定しておくなどすることで、引継ぎを行うことができる。引継ぎを行う先は、上述した所定の情報に含めておくことができる。

＜実施形態２＞
実施形態２について、図３〜図７を併せて参照しながら、実施形態１との相違点を中心に説明するが、実施形態１で説明した様々な例が適用できる。まず、図３及び図４を参照しながら、本実施形態に係るクラスタシステムの構成例について説明する。図３は、実施形態２に係るクラスタシステムの一構成例を示すブロック図で、図４は、その具体例を示す機能ブロック図である。

図３に示すように、本実施形態に係るクラスタシステム４は、現用系サーバ４０及び待機系サーバ５０の２台のサーバが共有ディスク６０とともにクラスタ構成を形成するシステムである。現用系サーバ４０、待機系サーバ５０、及び共有ディスク６０は、それぞれ実施形態１の現用系サーバ１０、待機系サーバ２０、及び共有記憶装置３０に対応している。その他、現用系サーバ４０、待機系サーバ５０の構成要素のうち、それぞれ現用系サーバ１０、待機系サーバ２０の構成要素に対応する構成要素については、同名称で記載し、その説明を一部省略する。

このように、クラスタシステム４は、基本的に同一の構成を持つ現用系サーバ４０及び待機系サーバ５０と、現用系サーバ４０及び待機系サーバ５０で共有可能な共有ディスク６０から構成されることができる。

また、現用系サーバ４０、待機系サーバ５０は互いにネットワーク７０を介して接続されている。ネットワーク７０は、有線通信、無線通信、有線及び無線の双方の通信のいずれの通信を行うネットワークであってもよい。ネットワーク７０には、クライアントが接続可能となっている。クライアントは、ネットワーク７０に接続することで、クラスタシステム４からサービスの提供を受けることができる。

ここで、提供されるサービスとしては、業務アプリケーション等のアプリケーションの提供サービスが挙げられる。以下では、現用系サーバ４０と待機系サーバ５０が同一の業務アプリケーションを実行することができることを前提に説明を行う。つまり、クライアントは現用系サーバ４０から業務アプリケーションの利用提供を受けておき、現用系サーバ４０に障害が発生した場合、現用系サーバ４０の業務アプリケーションを待機系サーバ５０が引き継ぎ、待機系サーバ５０から利用提供を受ける。無論、クラスタシステム４では、クライアントは、サーバ４０，５０のいずれから業務アプリケーションの利用提供を受けているかに拘わらず同じ制御を行うことができ、クライアントのユーザもいずれから利用提供を受けているかを認識できる必要はない。また、業務アプリケーションの種類は問わない。

現用系サーバ４０及び待機系サーバ５０は、ＣＰＵ等の演算装置と記憶装置を備えた情報処理装置（コンピュータ）として構成されることができる。現用系サーバ４０、待機系サーバ５０はそれぞれＯＳ４０ａ、ＯＳ５０ａを有することができる。ＯＳ４０ａは、中核であるカーネルとして、第１カーネル４１及び第２カーネル４２を有する。ＯＳ５０ａは、中核であるカーネルとして第１カーネル５１及び第２カーネル５２を有する。第１カーネル４１，５１は、それぞれ、ＯＳ４０ａ，５０ａが起動した際に起動し、ＯＳ４０ａ，５０ａに異常（障害）が無い限り稼働するカーネルである。第２カーネル４２，５２は、それぞれ、第１カーネル４１，５１が異常を検知し、処理続行不能と判断した際に起動し、メモリ４３，５３へのメモリダンプを行うカーネルである。

また、現用系サーバ４０、待機系サーバ５０はそれぞれ、共有ディスク６０に接続するためのＨＢＡ（Host Bus Adapter）カード４５，５５を備えている。また、現用系サーバ４０、待機系サーバ５０はそれぞれ、ネットワーク７０に接続するためのＮＩＣ（Network Interface Card）４４，５４を備えている。現用系サーバ４０のＯＳ４０ａ、待機系サーバ５０のＯＳ５０ａはそれぞれ、ＮＩＣ４４，５４とネットワーク７０とを介して互いに通信可能となっている。

現用系サーバ４０、待機系サーバ５０はそれぞれ、業務アプリケーション４６，５６、クラスタ管理ソフトウェア４７，５７、及びＯＳ障害処理プログラム４８，５８を実行可能に搭載している。ここで、第１カーネル４１，５１上では、それぞれ業務アプリケーション４６，５６とクラスタ管理ソフトウェア４７，５７とが動作し、第２カーネル４２，５２上ではそれぞれＯＳ障害処理プログラム４８，５８が動作する。

ＯＳ障害処理プログラム４８，５８又は第２カーネル４２は、メモリダンプ処理を実行するプログラムを含む。ＯＳ４０ａ（実際には第１カーネル４１）においてシステムクラッシュが発生すると、ＯＳ４０ａ上では第２カーネル４２が起動し、第２カーネル４２又は同時に起動されたＯＳ障害処理プログラム４８がメモリダンプ処理を実行する。第２カーネル４２は、第１カーネル４１が使用する記憶領域と異なる記憶領域が記憶先として予め割り当てられており、第１カーネル４１から第２カーネル４２の記憶領域を参照することはできない。そのため、第２カーネル４２又はＯＳ障害処理プログラム４８は、システムクラッシュの影響を受けずにメモリダンプを実行することができる。なお、この方法は、例えば、下記の参考文献に記載されている。なお、ここでＬｉｎｕｘは登録商標である。

“ＯＲＡＣＬＥ（Ｒ） Ｌｉｎｕｘ 管理者ガイド，リリース６ ９．１ Ｋｄｕｍｐについて”、［ｏｎｌｉｎｅ］、ＯＲＡＣＬＥ社、［２０１９年１０月１７日検索］、インターネット＜ＵＲＬ： ｈｔｔｐｓ：／／ｄｏｃｓ．ｏｒａｃｌｅ．ｃｏｍ／ｃｄ／Ｅ３９３６８＿０１／Ｅ４１１３８／ｈｔｍｌ／ｃｈ０９ｓ０１．ｈｔｍｌ＞

上述のようなクラスタシステム４における具体例について、図４を参照しながら説明する。図４に示すように、クラスタ管理ソフトウェア４７は、通知受信モジュール（ＭＤＬ）８１、フェイルオーバ制御モジュール８２、及び通知用情報処理モジュール８３を備えることができる。同様に、クラスタ管理ソフトウェア５７は、通知受信モジュール９１、フェイルオーバ制御モジュール９２、及び通知用情報処理モジュール９３を備えることができる。

ＯＳ障害処理プログラム４８は、ＯＳ障害通知モジュール８４及びＩ／Ｏフェンシング制御モジュール８５を備えることができる。同様に、ＯＳ障害処理プログラム５８は、ＯＳ障害通知モジュール９４及びＩ／Ｏフェンシング制御モジュール９５を備えることができる。

通知用情報処理モジュール８３，９３はそれぞれ、実施形態１で説明した所定の情報に相当する通知用情報を、第２カーネル４２，５２のイメージファイルに書き込む処理を行う。第２カーネル４２，５２のイメージファイルはそれぞれ、メモリ４３，５３に記憶されることができる。つまり、第１カーネル４１，５１はそれぞれ、起動時に、上記通知用情報をイメージファイルとしてメモリ４３，５３に書き込む処理を実行する。また、この書き込み処理は、起動後であってもシステム構成の変更があった場合などには更新するようにしておくこともできる。つまり、この書き込み処理は少なくとも第１カーネル４１，５１の起動時に実行されるようにしておけばよい。

そして、本実施形態において、上記通知用情報は、切り離し処理の対象を指定する情報（切離情報）及び通知先を指定する情報（通知先情報）として、次のような情報を含むことができる。

即ち、切離情報は、現用系サーバ４０、待機系サーバ５０においてそれぞれＩ／Ｏフェンシングの対象となる共有ディスク６０に接続している接続インターフェース（Ｉ／Ｆ）を示す情報を含むことができる。この情報は、例えばそのＩ／Ｆが搭載されたスロットの位置を示す情報とすることができる。この例では、現用系サーバ４０、待機系サーバ５０が書き込む場合には、それぞれ、共有ディスク６０に接続されているＨＢＡカード４５，５５が搭載されているスロット番号がこの情報に該当する。

通知先情報は、他のサーバとの通信を行う通信Ｉ／Ｆを示す情報（例えばそのＩ／Ｆが搭載されたスロットの位置を示す情報）を含むことができる。他のサーバとは、現用系サーバ４０が書き込む場合には待機系サーバ５０を指し、待機系サーバ５０が書き込む場合には現用系サーバ４０を指す。この例では、他系ＯＳ（他のサーバのＯＳ）と通信するためのＮＩＣ４４，５４が搭載されているスロット番号がこの情報に該当する。

さらに、通知先情報は、他のサーバのＩＰ（Internet Protocol）アドレスを示す情報を含むことができる。この情報は、ＯＳ障害を他系のＯＳに通知するためのＩＰアドレスであり、ＯＳ障害通知モジュール８４，９４がそれぞれ他系の通知受信モジュール９１，８１に通知を送信する際に使用する他系ＯＳのＩＰアドレスである。また、この通知先情報は、引継ぎを行う先を意味する情報となる。

また、上記通知用情報は、元々第１カーネル４１，５１が扱う記憶領域にあるが、それぞれ第２カーネル４２，５２上にあるＯＳ障害処理プログラム４８，５８で取り扱えるようにメモリ４３，５３に書き込まれることができる。特に、ここでは第２カーネル４２，５２のイメージファイルとして書き込む処理を挙げている。このような書き込み処理としては、例えば、既知の手法である、専用の設定ファイルを設けてカーネルイメージを更新する方法を用いることができる。なお、この方法は、例えば、下記の参考文献に記載されている。

“Ｒｅｄ Ｈａｔ 導入ガイド ２６．２．３．コマンドライン上でＫＤＵＭＰの設定”、［ｏｎｌｉｎｅ］、Ｒｅｄ Ｈａｔ， Ｉｎｃ．、［２０１９年１０月１７日検索］、インターネット＜ＵＲＬ： ｈｔｔｐｓ：／／ａｃｃｅｓｓ．ｒｅｄｈａｔ．ｃｏｍ／ｄｏｃｕｍｅｎｔａｔｉｏｎ／ｊａ−ｊｐ／ｒｅｄ＿ｈａｔ＿ｅｎｔｅｒｐｒｉｓｅ＿ｌｉｎｕｘ／６／ｈｔｍｌ／ｄｅｐｌｏｙｍｅｎｔ＿ｇｕｉｄｅ／ｓ２−ｋｄｕｍｐ−ｃｏｎｆｉｇｕｒａｔｉｏｎ−ｃｌｉ＞

Ｉ／Ｏフェンシング制御モジュール８５，９５はそれぞれ、メモリ４３，５３内の切離情報を参照し、共有ディスク６０に接続されているＨＢＡカード４５，５５に対してＩ／Ｏフェンシングを実施する。また、Ｉ／Ｏフェンシング制御モジュール８５，９５は、Ｉ／Ｏフェンシング完了後に、ＯＳ障害通知モジュール８４，９４に障害の通知を行う。なお、この通知は、この通知からフェイルオーバ処理が開始される時間を逆算して、Ｉ／Ｏフェンシング開始後完了前の時間に実施しておくこともできる。Ｉ／Ｏフェンシングとは、クラスタシステム４を構成するサーバ（例えば現用系サーバ４０）が停止する場合に、そのサーバが共有ディスク６０に接続したままにならないように、切り離すことである。

ＯＳ障害通知モジュール８４，９４はそれぞれ、Ｉ／Ｏフェンシング制御モジュール８５，９５からＩ／Ｏフェンシング完了の通知を受け取ると、他系ＯＳのＩＰアドレスと障害通知に使用するＮＩＣ４４，５４の搭載スロット番号とを読み取る。これらの情報は、通知用情報処理モジュール８３，９３がそれぞれ予めメモリ４３，５３に書き込んだ通知先情報である。

ＯＳ障害通知モジュール８４，９４はそれぞれ、障害通知に使用するＮＩＣ４４，５４を初期化し、上記ＩＰアドレスに対して、ＮＩＣ４４、ＮＩＣ５４、及びネットワーク７０を経由して、他系の通知受信モジュール９１，８１にＯＳ障害通知を行う。上記ＯＳ障害通知は、例えばＳＮＭＰ（Simple Network Management Protocol） Ｔｒａｐの形式で送信されることができ、以下ではその例を挙げて説明する。

通知受信モジュール９１，８１はそれぞれ、他系のＯＳ障害通知モジュール８４，９４から送信されたＳＮＭＰ Ｔｒａｐを受信し、同系のフェイルオーバ制御モジュール９２，８２に通知を行う。

フェイルオーバ制御モジュール９２，８２はそれぞれ、通知受信モジュール９１，８１からの通知を受けることで、他系でＯＳ障害が発生して業務アプリケーション４６，５６が停止していると判断する。この判断を行ったフェイルオーバ制御モジュール９２，８２はそれぞれ、業務アプリケーション４６から業務アプリケーション５６へのフェイルオーバ処理、業務アプリケーション５６から業務アプリケーション４６へのフェイルオーバ処理を行う。このフェイルオーバ処理は、業務アプリケーションの引継ぎ処理を指す。

なお、このフェイルオーバ処理は、次のような理由から実行される。クラスタシステム４では、両サーバ４０，５０のそれぞれで作動する同じ業務アプリケーション４６，５６のデータを共有ディスク６０に格納する。そのため、現用系サーバ４０と待機系サーバ５０から同時に共有ディスク６０に書き込みを行うと、このデータが破壊されるおそれがあり、それを回避するために通常は現用系サーバ４０からのみ書き込みを行うような排他制御がなされる。そして、クラスタシステム４においてフェイルオーバ処理を行う場合には、障害が発生した現用系サーバ４０からの共有ディスク６０への書き込みを停止し、その後に待機系サーバ５０の業務アプリケーション５６を起動することになる。

例えば、クラスタシステム４において現用系サーバ４０の第１カーネル４１に障害が発生した場合、業務アプリケーション４６から業務アプリケーション５６への切り替えを行う。このとき、待機系サーバ５０のクラスタ管理ソフトウェア５７が業務アプリケーション５６を起動する。

待機系サーバ５０で起動した業務アプリケーション５６は、共有ディスク６０に格納されたデータを使用し、現用系サーバ４０の業務アプリケーション４６が停止した時点から処理を再開する。

なお、この再開には、必要に応じて、メモリダンプ処理により保存された情報を用いることができる。メモリダンプ処理により保存された情報は、例えば、ＯＳ障害通知モジュール８４がＯＳ障害通知とともに或いはＯＳ障害通知の後に、ＮＩＣ４４，５４及びネットワーク７０を介して待機系サーバ５０に送信することができる。なお、メモリダンプ処理により保存された情報は、システムクラッシュの原因の解析にのみ用いられ、上述のような再開には用いないこともできる。

次に、図５〜図７を併せて参照しながら、本実施形態に係るクラスタシステム４における処理例を説明する。図５は、図４のクラスタシステム４における現用系サーバ４０のＯＳ起動時の処理例を説明するためのフロー図である。図６は、図４のクラスタシステム４におけるシステムクラッシュ時の処理例を説明するためのフロー図で、図７は、図４のクラスタシステム４におけるシステムクラッシュ時の処理例を説明するための模式図である。なお、図７は、図６における各ステップの処理を破線で模式的に示している。

現用系サーバ４０のＯＳ４０ａが起動したときの動作は、図５に示すように、次のようになる。まず、現用系サーバ４０のＯＳ４０ａが起動すると、第１カーネル４１が稼働する（ステップＳ１１）。次いで、第１カーネル４１上でクラスタ管理ソフトウェア４７が通知用情報処理モジュール８３を実行する（ステップＳ１２）。

通知用情報処理モジュール８３は、予め登録された設定ファイルからＨＢＡカード４５の搭載スロット番号、待機系サーバ５０のＯＳ５０ａのＩＰアドレス、ネットワーク７０との通信用のＮＩＣ４４の搭載スロット番号を読み取る（ステップＳ１３）。そして、通知用情報処理モジュール８３は、読み取った情報を、第２カーネル４２上のＯＳ障害処理プログラム４８が扱えるように第２カーネル４２のイメージファイルに書き込む（ステップＳ１４）。

システムクラッシュとなる障害が発生した時の動作は、図６及び図７に示すように、次のようになる。現用系サーバ４０のＯＳ４０ａでシステムクラッシュとなる障害が発生すると、第２カーネル４２が動作を開始し（ステップＳ２１）、ＯＳ障害処理プログラム４８が動作を開始する（ステップＳ２２）。ＯＳ障害処理プログラム４８は、ＯＳ４０ａが共有ディスク６０へ書き込むことを防ぐために、Ｉ／Ｏフェンシング制御モジュール８５を実行する。具体的には、通知用情報処理モジュール８３が第２カーネル４２のイメージファイルに書き込んだＨＢＡカード４５の搭載スロット番号を読み取り、ＨＢＡカード４５に対してＩ／Ｏフェンシングを行う（ステップＳ２３）。

Ｉ／Ｏフェンシングが完了した後、Ｉ／Ｏフェンシング制御モジュール８５は、Ｉ／Ｏフェンシングが完了した通知をＯＳ障害通知モジュール８４に送信する。ＯＳ障害通知モジュール８４は、Ｉ／Ｏフェンシング制御モジュール８５からＩ／Ｏフェンシング完了の通知を受け取ると、次の処理を行う。即ち、ＯＳ障害通知モジュール８４は、通知用情報処理モジュール８３が第２カーネル５２のイメージファイルに書き込んだ待機系サーバ５０のＯＳ５０ａのＩＰアドレス、通信用のＮＩＣ４４の搭載スロット番号を読み取る。そして、ＯＳ障害通知モジュール８４は、ＮＩＣ４４を初期化し（ステップＳ２４）、待機系サーバ５０の通知受信モジュール９１に対して、ＳＮＭＰ Ｔｒａｐの形式で障害通知を送信する（ステップＳ２５）。

ここで、ステップＳ２４の初期化について補足的に説明する。ステップＳ２１において、第２カーネル４２は、第１カーネル４１がシステムクラッシュすると起動することになるが、起動しただけでは第１カーネル４１が使用していたＮＩＣ４４を使用することはできない。第２カーネル４２がＮＩＣ４４を使用できるようにするために、ステップＳ２４の初期化が実行されることになる。そして、ＮＩＣ４４の初期化により、ステップＳ２５におけるＮＩＣ４４を使用した障害通知が可能となる。

現用系サーバ４０のＯＳ４０ａは、第２カーネル４２の本来の動作により、メモリダンプ処理を行った後、シャットダウンする（ステップＳ２６）。

一方で、待機系サーバ５０のクラスタ管理ソフトウェア５７は、通知受信モジュール９１でＳＮＭＰ Ｔｒａｐの形式の障害通知を受信すると（ステップＳ３１）、フェイルオーバ制御モジュール９２で、フェイルオーバ処理を実施する（ステップＳ３２）。これにより、待機系サーバ５０は共有ディスク６０への接続を開始するが、この時点で現用系サーバ４０はＩ／Ｏフェンシングにより接続が遮断されているため、共有ディスク６０のデータ破損は発生しない。

以上のように、本実施形態に係るクラスタシステム４では、現用系サーバ４０でシステムクラッシュが発生した際、システムクラッシュ時にメモリダンプを実施する第２カーネル４２においてＩ／Ｏフェンシングと待機系サーバ５０のＯＳへの障害通知を行う。これは主に通知用情報処理モジュール８３、ＯＳ障害通知モジュール８４、及びＩ／Ｏフェンシング制御モジュール８５で例示した処理で実現することができる。特に、本実施形態では、通知用情報処理モジュール８３による上述したようなメモリ４３（又はメモリ５３）への書き込み処理により、Ｉ／Ｏフェンシングと障害通知とに必要な情報を第２カーネル４２（又は第２カーネル５２）へ受け渡すことができる。

このような処理を行うことで、本実施形態に係るクラスタシステム４では、待機系サーバ５０においてハートビートのタイムアウトを待つこともなく、高速なフェイルオーバ処理を実現できる。

＜他の実施形態＞
上述した各実施形態では、サーバ装置の各部の機能について説明したが、サーバ装置としてこれらの機能が実現できればよい。また、上述した各実施形態では、サーバ装置の各部の機能について説明したが、サーバ装置としてこれらの機能が実現できればよい。また、各実施形態において説明した様々な例は、適宜組み合わせることができる。

また、各実施形態に係るサーバ装置は、現用系、待機系のいずれで用いられるかに依らず、次のようなハードウェア構成を有することができる。図８は、各実施形態に係るサーバ装置のハードウェア構成の一例を示す図である。

図８に示すサーバ装置１００は、現用系、待機系のいずれかのサーバ装置とすることができ、プロセッサ１０１、メモリ１０２、及びインターフェース（Ｉ／Ｆ）１０３を有することができる。インターフェース１０３は、例えば、共有記憶装置と接続するための接続インターフェースと、クライアント装置や他のサーバ装置と通信するための通信インターフェースと、を有することができる。各実施形態で説明した各部の機能は、プロセッサ１０１がメモリ１０２に記憶されたプログラムを読み込んで、インターフェース１０３と協働しながら実行することにより実現される。このプログラムは、各実施形態で説明したプログラムとすることができる。

上述の例において、上記プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）を含む。さらに、この例は、ＣＤ−ＲＯＭ（Read Only Memory）、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗを含む。さらに、この例は、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（Random Access Memory））を含む。また、上記プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

なお、本開示は上述した様々な実施形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。また、本開示は、それぞれの実施形態を適宜組み合わせて実施されてもよい。

１、４ クラスタシステム
１０、４０ サーバ装置（現用系サーバ）
１１、２１、４１、５１ 第１カーネル
１２、２２、４２、５２ 第２カーネル
１３、２３、４３、５３ メモリ
２０、５０ サーバ装置（待機系サーバ）
３０ 共有記憶装置
４０ａ、５０ａ ＯＳ
４４、５４ ＮＩＣ
４５、５５ ＨＢＡカード
４６、５６ 業務アプリケーション
４７、５７ クラスタ管理ソフトウェア
４８、５８ ＯＳ障害処理プログラム
６０ 共有ディスク
７０ ネットワーク
８１、９１ 通知受信モジュール
８２、９２ フェイルオーバ制御モジュール
８３、９３ 通知用情報処理モジュール
８４、９４ ＯＳ障害通知モジュール
８５、９５ Ｉ／Ｏフェンシング制御モジュール
１００ サーバ装置
１０１ プロセッサ
１０２ メモリ
１０３ インターフェース

Claims (10)

1. 共有記憶装置と、
   前記共有記憶装置にアクセス可能で前記共有記憶装置とともに少なくとも可用性を高めるためのクラスタ構成をなす複数のサーバ装置と、
   を備え、
   前記サーバ装置は、前記サーバ装置における通常稼働時の制御を行う第１カーネルと、
   前記第１カーネルの一部又は全部に障害が発生した場合に、メモリダンプ処理を行う第２カーネルと、を有し、
   前記第１カーネルは、起動時に、所定の情報を、前記第２カーネルが前記メモリダンプ処理において出力先とするメモリに書き込む処理を実行し、
   前記第２カーネルは、前記第１カーネルの一部又は全部に障害が発生した場合に、前記メモリ内の前記所定の情報に基づき、前記共有記憶装置からの入出力の切り離し処理と前記複数のサーバ装置における他のサーバ装置に障害を通知する通知処理とを実行し、
   前記所定の情報は、前記切り離し処理の対象及び前記通知処理での通知先を指定する情報を含む、
   クラスタシステム。
2. 前記切り離し処理の対象を指定する情報は、前記サーバ装置において前記共有記憶装置に接続している接続インターフェースを示す情報を含み、
   前記通知先を指定する情報は、前記他のサーバ装置との通信を行う通信インターフェースを示す情報と、前記他のサーバ装置のＩＰ（Internet Protocol）アドレスを示す情報と、を含む、
   請求項１に記載のクラスタシステム。
3. 前記第１カーネルは、前記所定の情報をイメージファイルとして前記メモリに書き込む処理を実行する、
   請求項１又は２に記載のクラスタシステム。
4. 前記他のサーバ装置は、前記通知処理による障害の通知を受信すると、前記他のサーバ装置における通常稼働時の制御を行う前記第１カーネルを起動する、
   請求項１から３のいずれか１項に記載のクラスタシステム。
5. 他のサーバ装置と前記他のサーバ装置からアクセス可能な共有記憶装置とともに少なくとも可用性を高めるためのクラスタ構成をなすサーバ装置であって、
   前記サーバ装置における通常稼働時の制御を行う第１カーネルと、
   前記第１カーネルの一部又は全部に障害が発生した場合にメモリダンプ処理を行う第２カーネルと、
   を有し、
   前記第１カーネルは、起動時に、所定の情報を、前記第２カーネルが前記メモリダンプ処理において出力先とするメモリに書き込む処理を実行し、
   前記第２カーネルは、前記第１カーネルの一部又は全部に障害が発生した場合に、前記メモリ内の前記所定の情報に基づき、前記共有記憶装置からの入出力の切り離し処理と前記他のサーバ装置に障害を通知する通知処理とを実行し、
   前記所定の情報は、前記切り離し処理の対象及び前記通知処理での通知先を指定する情報を含む、
   サーバ装置。
6. 前記切り離し処理の対象を指定する情報は、前記サーバ装置において前記共有記憶装置に接続している接続インターフェースを示す情報を含み、
   前記通知先を指定する情報は、前記他のサーバ装置との通信を行う通信インターフェースを示す情報と、前記他のサーバ装置のＩＰ（Internet Protocol）アドレスを示す情報と、を含む、
   請求項５に記載のサーバ装置。
7. 前記第１カーネルは、前記所定の情報をイメージファイルとして前記メモリに書き込む処理を実行する、
   請求項５又は６に記載のサーバ装置。
8. 前記第１カーネルの非稼働時に前記他のサーバ装置からの障害の通知を受信した場合に、前記第１カーネルを起動する、
   請求項５から７のいずれか１項に記載のサーバ装置。
9. 他のサーバ装置と共有記憶装置とともに少なくとも可用性を高めるためのクラスタ構成をなすサーバ装置における引継ぎ方法であって、
   前記サーバ装置は、前記サーバ装置における通常稼働時の制御を行う第１カーネルと、前記第１カーネルの一部又は全部に障害が発生した場合にメモリダンプ処理を行う第２カーネルと、を有し、
   前記第１カーネルが、起動時に、所定の情報を、前記第２カーネルが前記メモリダンプ処理において出力先とするメモリに書き込む処理を実行し、
   前記第２カーネルが、前記第１カーネルの一部又は全部に障害が発生した場合に、前記メモリ内の前記所定の情報に基づき、前記共有記憶装置からの入出力の切り離し処理と前記他のサーバ装置に障害を通知する通知処理とを実行し、
   前記所定の情報は、前記切り離し処理の対象及び前記通知処理での通知先を指定する情報を含む、
   引継ぎ方法。
10. 他のサーバ装置と共有記憶装置とともに少なくとも可用性を高めるためのクラスタ構成をなすサーバ装置のコンピュータに実行させるためのプログラムであって、
    前記サーバ装置における通常稼働時の制御を行う第１カーネルと、
    前記第１カーネルの一部又は全部に障害が発生した場合にメモリダンプ処理を行う第２カーネルと、
    を有し、
    前記第１カーネルは、起動時に、所定の情報を、前記第２カーネルが前記メモリダンプ処理において出力先とするメモリに書き込む処理を実行し、
    前記第２カーネルは、前記第１カーネルの一部又は全部に障害が発生した場合に、前記メモリ内の前記所定の情報に基づき、前記共有記憶装置からの入出力の切り離し処理と前記他のサーバ装置に障害を通知する通知処理とを実行し、
    前記所定の情報は、前記切り離し処理の対象及び前記通知処理での通知先を指定する情報を含む、
    プログラム。

Images