JP2014032576A - ネットワーク装置又はサーバ装置の多重化方式 - Google Patents

ネットワーク装置又はサーバ装置の多重化方式 Download PDF

Info

Publication number
JP2014032576A
JP2014032576A JP2012173568A JP2012173568A JP2014032576A JP 2014032576 A JP2014032576 A JP 2014032576A JP 2012173568 A JP2012173568 A JP 2012173568A JP 2012173568 A JP2012173568 A JP 2012173568A JP 2014032576 A JP2014032576 A JP 2014032576A
Authority
JP
Japan
Prior art keywords
service providing
service
load balancer
identification information
communication
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
JP2012173568A
Other languages
English (en)
Inventor
Hiroyoshi Nakamura
博義 中邑
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.)
Hitachi Solutions Ltd
Original Assignee
Hitachi Solutions 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 Hitachi Solutions Ltd filed Critical Hitachi Solutions Ltd
Priority to JP2012173568A priority Critical patent/JP2014032576A/ja
Publication of JP2014032576A publication Critical patent/JP2014032576A/ja
Pending legal-status Critical Current

Links

Images

Abstract

【課題】ネットワーク装置又はサーバ装置の多重化方式を提供する。
【解決手段】ネットワーク装置又はサーバ装置である複数のサービス提供側装置と、サービス提供側装置とネットワークを介して通信する少なくとも1つのサービス利用側装置と、を備えたシステムにおけるサービス提供側装置の多重化方式であって、サービス提供側装置の各々は、ユニークな実識別情報と全てのサービス提供側装置に共通な仮想識別情報とを予め設定されており、サービス利用側装置は、仮想識別情報により通信先を指定した通信開始要求を送信する識別情報送信部と、通信開始要求を受信したサービス提供側装置の各々から、それぞれの実識別情報を含む各応答を受信したことに応じて、複数のサービス提供側装置のうちのいずれかを通信先として決定する通信先決定部と、を備え、かつ、通信先として決定されたサービス提供側装置との間で実識別情報を使用して通信を行う。
【選択図】図13

Description

本発明は、インターネット又は企業内LAN等のネットワーク関連の情報システムを構成するネットワーク装置又はサーバ装置の多重化方式に関するものである。
非特許文献1の、経済産業省が取りまとめた「情報システムの信頼性向上に関するガイドライン」でも述べられている通り、情報システムの大規模化・ネットワーク化により情報システムが複雑化することで、情報システムの障害(ハードウェアまたはソフトウェアの問題によって正常に稼動できない状態)が国民生活や社会に与える影響が益々大きくなっており、情報システムにとって信頼性および性能の向上が喫緊かつ重要な課題となっている。
情報システムの信頼性および性能を向上させる最も主要な施策として、ネットワーク装置やサーバ装置などのハードウェア装置の多重化がある。例えば、特許文献1、2に開示されている。
インターネットや企業内LAN上で稼動する情報システムにおいて、サーバ装置の多重化の最も一般的な実現方式は、負荷分散装置による方式である。
図2は、負荷分散装置によってサーバ装置の多重化を実現した従来方式の情報システムの構成図である。サービス提供側(201)で示している範囲が、インターネット上のウェブサイトや企業内LAN上の情報システムである。サーバ装置1(202)、サーバ装置2(203)...サーバ装置n(204)は、多重化されたサーバ装置群を示している。サーバ装置を多重化することにより、情報システム全体の信頼性と性能を向上させている。これらのサーバ装置群に対してネットワーク(206)から送られてくるサービス要求を負荷分散装置(205)が振り分ける。ネットワークの先にあるサービス利用側(207)の範囲に含まれるサーバ装置(208)又はクライアントPC(209)が、サービス要求を送信し、サービスの提供を受ける。
例えば、サービス提供側(201)のサーバ装置1台当たりの稼働率(正常に稼動する確率)をaとし、サーバ装置n台で構成された情報システム全体の稼働率は下式で求められる。
[情報システム全体の稼働率]= 1−(1−a)
ここでaを99%、nを4とすると、下式で計算される通り、情報システム全体の稼働率は99.999999%となる。
[情報システム全体の稼働率]= 1−(1−0.99)
このように、サーバ装置の多重化によって稼働率を飛躍的に向上させることができる。
しかし、ここで、負荷分散装置(205)自体の稼働率を考慮しなければならない。図2のように、負荷分散装置とサーバ装置は直列の関係で接続されている。このため、負荷分散装置を含めた全体の稼働率は負荷分散装置の稼働率を超えることはない。負荷分散装置の稼働率をbとした場合の、負荷分散装置を含めた全体の稼働率は下式で求められる。
[情報システム全体の稼働率]= 1−(1−(1−a))×b
前述と同様に、サーバ装置の稼働率を99%、台数を4台、負荷分散装置の稼働率を99%とした場合のサーバ装置、負荷分散装置を含めた全体の稼働率は、下式で計算される通り、98.99999901%となり、99%を下回る。
[情報システム全体の稼働率]= 1− {1−(1−0.99) }×0.99
図2においては、サーバ装置の多重化によって信頼性と性能が確保される一方、負荷分散装置(205)が障害となった場合にサーバ装置へのサービス要求が振り分けられなくなるために、情報システム全体が障害となってしまう。従って、負荷分散装置自体の多重化も併せて実施することが必要となる。
図3は、負荷分散装置自体をも多重化した従来方式の情報システムの構成図である。
図3の構成では、サービス提供側(301)のサーバ装置(302、304)の多重化は、サービス利用側(308)から送られてくるサービス要求を負荷分散装置(305、306)が各サーバ装置へ均等に振り分けることで実現している。この場合、2つの負荷分散装置の多重化は、次のような従来方式により実現している。複数の負荷分散装置は、「アクティブ(Active)」と称される1台の負荷分散装置と、「スタンバイ(Standby)」と称される1台または複数台の負荷分散装置とから構成されている。アクティブ負荷分散装置とは、通常稼動している負荷分散装置であり、サーバの振り分け処理を行っている。スタンバイ負荷分散装置とは、通常は稼動しない負荷分散装置であり、アクティブ負荷分散装置が障害になった場合に、これに替わってサーバ装置の振り分け処理を行う。
図2、図3におけるサーバ装置の多重化は、負荷分散装置がこれらにサービス利用側からのサービス要求を振り分けることで各サーバ装置を均等に実行させている。これに対し、図3における負荷分散装置自体の多重化においては、サービス利用側からのサービス要求を複数の負荷分散装置にどのように均等に振り分けるかが課題になる。
特開平8−316957号公報 特開201290194号公報
経済産業省「情報システムの信頼性向上に関するガイドライン第2版」、2009年3月24日
図4は、アクティブとスタンバイの2種類の負荷分散装置で構成された従来方式による負荷分散装置の多重化のイメージ図である。図4(a)に示すように負荷分散装置を、アクティブ(404)とスタンバイ(405)の2種類に分けている。なお、従来方式における負荷分散装置を、その時点での機能によって「アクティブ負荷分散装置」又は「スタンバイ負荷分散装置」と称するが、特定の負荷分散装置がアクティブかスタンバイかは必ずしも固定的ではない。アクティブ負荷分散装置は、通常時にサービス利用側からのサービス要求を受付け、処理する。これに対してスタンバイ負荷分散装置は、通常時はサービス利用側からのサービス要求を処理しない。一方、図4(b)に示すように、一旦、アクティブ負荷分散装置(412)に障害が発生した場合には、スタンバイ負荷分散装置(413)がアクティブ負荷分散装置に成り替わってサービス要求を処理するようになる。つまり、スタンバイ負荷分散装置がアクティブ負荷分散装置となって処理を行う。
図4に示す負荷分散装置の多重化の従来方式における技術課題として、アクティブ負荷分散装置の障害をどのように検知し、その機能をどのようにスタンバイ負荷分散装置へ引き継がせるかという点がある。
現状では、この障害検知と機能引き継ぎの方式として、主に下記の2つがある。
[従来方式1]アクティブ負荷分散装置(1台)とスタンバイ負荷分散装置(1台)の間をケーブルで接続し、スタンバイ負荷分散装置がアクティブ負荷分散装置の死活(正常に稼動しているか否か)を監視し、「死んだ(障害となった)」ことをスタンバイ負荷分散装置が検知したことを契機に、スタンバイ負荷分散装置がアクティブ負荷分散装置に成り代わる方式(以降、「1対1監視方式」と呼ぶ)
[従来方式2]ネットワークプロトコルであるVRRP(Virtual Router Redundancy Protocil)を使用する方式(以降、「VRRP方式」と呼ぶ)
それぞれの方式について以下に説明し、それぞれの課題を示す。
図5は、1対1監視方式のイメージ図を示した図である。図5(a)に示す通常時には、スタンバイ負荷分散装置(502)がアクティブ負荷分散装置(501)に対して「Heart Beat」または「Keepalive」と呼ばれるパケット(通信メッセージの単位)(以降、「Heart Beatパケット」と称す)を送出する。このHeart Beatパケットに対してアクティブ負荷分散装置は、応答パケットを返送することで「活きている(正常に稼動している)」ことをスタンバイ負荷分散装置に知らせる。
次に、図5(b)に示す障害発生時における負荷分散装置の切り替え動作を説明する。スタンバイ負荷分散装置(504)はアクティブ負荷分散装置(503)にHeart Beatパケットを送出するが、アクティブ負荷分散装置が障害となっている場合にはこれに応答することができない。スタンバイ負荷分散装置はこれによってアクティブ負荷分散装置の障害を検知し、以降、アクティブ負荷分散装置の処理を引き継いでサーバ装置への振り分け処理を開始する。
ここで、ネットワーク上の動作について補足する。ネットワークに接続された装置にはIPアドレスというユニークな識別子が個々に付与されている。アクティブ負荷分散装置は、サービス利用側装置から自分のIPアドレスを宛先としたサービス要求が来た時にこれを取り込み、サーバ装置に振り分ける処理を行う。アクティブ負荷分散装置が障害になった場合には、スタンバイ負荷分散装置がアクティブ負荷分散装置のIPアドレスに宛てたサービス要求を取り込んで代行するようになる。アクティブ負荷分散装置とスタンバイ負荷分散装置は同一のLANセグメント上にあるため、サービス利用側装置が送ってきたサービス要求をいずれもが受信することができ、IPアドレスを参照して自分宛か否かを判定している。
1対1監視方式は、比較的平易な実現方式であるが、以下のような課題がある。
[課題1]アクティブ負荷分散装置が1台であるため、複数台の負荷分散装置を準備しても常に1台分の性能しか出ない。
[課題2]クティブ負荷分散装置が1台であるため、アクティブ負荷分散装置が障害になった場合にはスタンバイ負荷分散装置に切り替わるまでの間、情報システム全体が障害となる。
[課題3]スタンバイ負荷分散装置が1台であるため、アクティブ負荷分散に続いてスタンバイ負荷分散装置も障害になった場合(いわゆる2重障害)には情報システム全体が障害となる。
[課題4]アクティブ負荷分散装置とスタンバイ負荷分散装置では役割が異なることから、装置に設定する情報なども異なり、その分、ネットワーク管理者の設計・運用負担が生じる。
図6は、VRRP方式のイメージ図を示した図である。VRRPとは、もともとはネットワーク装置であるルータ装置の多重化のためにインターネット技術に関する標準化団体IETF(Internet Engineering Task Force)が定めたプロトコルであり(ドキュメント番号:RFC3768)、これを負荷分散装置の多重化に応用した方式である。
VRRP方式においても、負荷分散装置にアクティブとスタンバイの2種類がある。1対1監視方式ではスタンバイ負荷分散装置が1台であったのに対し、VRRP方式では2台以上あってもよい。さらに、1対1監視方式と異なる点は、アクティブ負荷分散装置(601)が活きていることを示すパケットをアクティブ負荷分散装置自身が発信する点である。このパケットを「Advertisementパケット」と言う。
図6(a)の通常時において、スタンバイ負荷分散装置(602、603)は、アクティブ負荷分散装置が発信するAdvertisementパケットを監視している。これが一定間隔で受信できることにより、スタンバイ負荷分散装置はアクティブ負荷分散装置が活きていることを確認する。
次に、図6(b)の障害発生時においては、以下の手順でアクティブ負荷分散装置の障害を検知し、スタンバイ負荷分散装置のアクティブ負荷分散装置への切り替えを行う。
(1)アクティブ負荷分散装置(604)が障害となると、Advertisementパケットが発信されなくなる。
(2)スタンバイ負荷分散装置(605、606)はアクティブ負荷分散装置からのAdvertisementパケットの受信が途絶えると、ある一定時間監視を継続する。
(3)一定時間経過後、それでも同パケットが受信できない場合にはアクティブ負荷分散装置に障害が発生した、アクティブ負荷分散装置が「死んだ(障害となった)」と判断する。続いて、これに成り代わってサーバ装置への振り分け処理を開始する。
(4)ここで、スタンバイ負荷分散装置が複数台ある場合には、いずれをアクティブの負荷分散装置とさせるかを決定しなければならない。予め、負荷分散装置にプライオリティ値(優先順位を示す値)を設定しておき、各スタンバイ負荷分散装置はこのプライオリティ値を設定したAdvertisementパケットを発信する。
(5)互いに他のスタンバイ負荷分散装置のプライオリティ値を確認し合い、その中で最も値の大きなプライオリティ値を有するスタンバイ負荷分散装置を新たなアクティブ負荷分散装置として認識する。
(6)最も高いプライオリティ値を設定されているスタンバイ負荷分散装置がアクティブ負荷分散装置に切り替わる。
1対1監視方式に比較して、VRRP方式では複数台のスタンバイ負荷分散装置を構成できるところが利点であるが、依然として以下の課題がある。
[課題5]アクティブ負荷分散装置が1台であるため、複数台の負荷分散装置を準備しても常に1台分の性能しか出ない。
[課題6]アクティブ負荷分散装置が1台であるため、アクティブ負荷分散装置が障害になった場合にはスタンバイ負荷分散装置に切り替わるまでの間、情報システム全体が障害となる。
[課題7]アクティブ負荷分散装置が障害となった場合に、いずれのスタンバイ負荷分散装置がこれに成り代わるべきかを決定するために、予め、スタンバイ負荷分散装置に対してプライオリティ値を設定しなければならず、これはネットワーク管理者の設計、運用負担になる。
以上の通り、負荷分散装置の多重化に関する2種類の従来方式のいずれにおいても解決するべき課題がある。本発明は、これらの課題を解決することを目的とする。また、これらの課題を解決する多重化方式であって、負荷分散装置に限らず、種々のネットワーク装置又はサーバ装置に適用可能な方式を提供することを目的とする。
上記の目的を実現するべく本発明は、以下の構成を提供する。
本発明の態様は、ネットワーク装置又はサーバ装置である複数のサービス提供側装置と、前記サービス提供側装置とネットワークを介して通信する少なくとも1つのサービス利用側装置と、を備えたシステムにおけるサービス提供側装置の多重化方式であって、前記サービス提供側装置の各々は、ユニークな実識別情報と全てのサービス提供側装置に共通な仮想識別情報とを予め設定されており、前記サービス利用側装置は、前記仮想識別情報により通信先を指定した通信開始要求を送信する識別情報送信部と、前記通信開始要求を受信した前記サービス提供側装置の各々から、それぞれの前記実識別情報を含む各応答を受信したことに応じて、複数の前記サービス提供側装置のうちのいずれかを通信先として決定する通信先決定部と、を備え、かつ、通信先として決定されたサービス提供側装置との間で前記実識別情報を使用して通信を行うことを特徴とする。
上記態様において、前記サービス利用側装置はさらに、通信中のサービス提供側装置に対して監視用情報を送信し、前記監視用情報に対する前記サービス提供側装置からの応答を受信し、前記監視用情報に対する応答が途絶えたことにより前記サービス提供側装置における障害発生を検知する障害監視部を備え、前記障害監視部が障害発生を検知したことに応じて、前記識別情報送信部が再度、通信開始要求を送信し、前記通信先決定部が別のサービス提供側装置を通信先として決定することが、好適である。
上記態様において、前記サービス提供側装置の各々はさらに、前記サービス提供側装置の各々はさらに、現時点の処理負荷を示す処理負荷レベル情報をそれぞれ保有しており、かつ、前記通信開始要求に対する前記サービス提供側装置の各々からの各応答には、それぞれのサービス提供側装置の処理負荷レベル情報が含まれており、前記サービス利用側装置の前記通信先決定部は、前記処理負荷レベル情報に基づいて、現時点の処理負荷が最小のサービス提供側装置を通信先として決定することが、好適である。
本発明による、ネットワーク装置又はサーバ装置であるサービス提供側装置の多重化方式は、従来方式(1対1監視方式、VRRP方式)と比較して以下の効果を奏することができる。ここでは、サービス提供側装置が負荷分散装置の場合について説明するが、後に例示する他の装置であっても、同様の効果を奏する。
従来方式では、サーバ振り分け処理を行うのはアクティブな負荷分散装置1台だけであり、複数台の負荷分散装置を用意したとしても性能向上を図ることはできない。これに対し、本発明による方式では、全ての負荷分散装置がほぼ均等にサーバ振り分けを実行することになるため、台数に比例した性能が得られる。
従来方式では、サーバ振り分け処理を行うのはアクティブな負荷分散装置1台だけであるため、アクティブ負荷分散装置の障害時には、スタンバイ負荷分散装置への切り替えが完了するまでの間は情報システム全体が障害となる。これに対し、本発明による方式では、すべての負荷分散装置が均等にサーバ振り分け処理を行うため、情報システム全体の障害には至らず、その影響は当該負荷分散装置を使用していたサービス利用側装置に限られる。
従来方式では、負荷分散装置に対してアクティブ、スタンバイの区別や、VRRP方式であれば、プライオリティ値を設定しなければならない。一方、本発明による方式では、多重化対象の負荷分散装置はすべて同じ設定でよい。このため、ネットワーク管理者の負担を軽減することができる。(なお、本発明による方式においても、IPアドレスやMACアドレス等の装置個別の識別情報を設定することは、必要である。しかしながら、これらはそもそも、いずれの多重化方式を採用したとしても、一般的なシステムにおいて装置を識別するために必ず設定される項目である。)
以上の通り、本発明によるネットワーク装置又はサーバ装置の多重化方式は、従来方式の課題を解決することができる。
さらに本発明による方式は、負荷分散装置への適用に留まらず、応用範囲が広い。例えば、サービス提供側の複数のサーバ装置自体にも応用することができる。サーバ装置に応用した場合、サービス利用側装置が複数のサーバ装置を均等に使い分けることになることから、もともとそのような役割を担ってきた負荷分散装置自体が不要になる。さらに本発明による方式は、OpenFlowネットワーク技術における複数のOpenFlowコントローラにも応用することができる。このように、本発明の方式の原理は、複数の装置により処理負荷を分散するシステムにおいて、処理を担当する装置を適切に選択して各装置の処理負荷を均等とするために適用することができる。
図1は、本発明による方式を適用して負荷分散装置の多重化を実現したシステム構成の一例を示す図である。 図2は、負荷分散装置によりサーバ装置の多重化を実現した従来方式の情報システムの構成図である。 図3は、負荷分散装置を多重化した従来方式の情報システムの構成図である。。 図4は、アクティブとスタンバイの2種類の負荷分散装置で構成された従来方式による負荷分散装置の多重化のイメージ図である。 図5は、多重化された負荷分散装置の構成における障害検知のための1対1監視方式(従来方式)の実現イメージ図である。 図6は、多重化された負荷分散装置の構成における障害検知のためのVRRP方式(従来方式)の実現イメージ図である。 図7は、図1に示した本発明による負荷分散装置の多重化方式における処理の流れを示す図である。 図8は、本発明方式おける、負荷分散装置に対する障害検知の処理と他の負荷分散装置への切り替え処理を説明する図である。 図9は、負荷分散装置の多重化に関する従来方式と本発明による方式の比較図である。 図10は、負荷分散装置の多重化に関する従来方式と本発明による方式の比較表である。 図11は、サービス提供側装置である複数のサーバ装置の選択に関して本発明の方式を適用したシステム構成の一例を示した図である。 図12は、新しいネットワーク技術であるOpenFlowに対して本発明の方式を適用したシステム構成の一例を示した図である。 図13は、本発明による方式を適用して任意のサービス提供側装置の多重化を実現したシステム構成の一例を示す図である。
以下、本発明によるネットワーク装置又はサーバ装置の多重化方式を、負荷分散装置に適用した多重化方式、サーバ装置に適用した多重化方式、並びに新しいネットワーク技術であるOpenFlowコントローラに適用した多重化方式の各例について説明する。
インターネットや企業内LANなどのTCP/IPネットワークにおいては、ネットワークに接続される装置をIPアドレスやMACアドレスである識別情報により識別し、これによって通信先や通信経路を判定している。本発明による多重化方式では、IPアドレス、MACアドレスのいずれにも適用可能であるため、以降、IPアドレスを例として説明する。
図1は、インターネットや企業内LANの情報システムにおいて、本発明による方式を適用して負荷分散装置の多重化を実現したシステム構成の一例を示す図である。
サービス提供側(101)で示している範囲がインターネット上のウェブサイトや企業LAN上の情報システムである。サーバ装置1(102)、サーバ装置2(103)...サーバ装置n(104)は多重化されたサーバ装置群を示している。サーバ装置を多重化することで情報システム全体の信頼性と性能を向上させている。これらのサーバ群に対してネットワーク(114)から送られてくるサービス要求を、負荷分散装置1(105)、負荷分散装置2(108)...負荷分散装置m(111)が振り分ける。これらは、多重化された負荷分散装置群である。本明細書では、サービス提供側(101)のサーバ装置(102、103、104)又は負荷分散装置(105、108、111)を「サービス提供側装置」と称する場合がある。
ネットワーク114の先にサービス利用側(115)が存在する。サービス利用側(115)の範囲には、実際のサービス要求を送信し、サービスの提供を受けるサーバ装置(116)又はクライアントPC(117)が含まれる。本明細書では、サービス利用側(115)のサーバ装置(116)又はクライアントPC(117)を「サービス利用側装置」と称する場合がある。
個々の負荷分散装置(105、108、111)は、それぞれIPアドレス(106、109、112)を有する。IPアドレス(106、109、112)には、ユニークなIPアドレスと全ての負荷分散装置に共通のIPアドレスの2種類が含まれる。ユニークなIPアドレスを「実IPアドレス」と称し、共通のIPアドレスを「仮想IPアドレス」と称することとする。
さらに個々の負荷分散装置(105、108、111)は、それぞれコネクション数(107、110、113)を保有する。コネクション数は、その負荷分散装置がすでに通信を開始しているサービス利用側装置の数を表す。
本発明において、サービス要求したサービス利用側装置と通信を行う1つの負荷分散装置を決定する手順の概要を述べる。まず、サービス利用側装置は、仮想IPアドレスを用いて通信開始要求を行う。この通信開始要求は全ての負荷分散装置が受け取る。これに対して、各負荷分散装置は稼働情報を送り返す。サービス利用側装置は、各負荷分散装置(105、108、111)から送られてくる稼動情報を取得する。稼動情報には、各負荷分散装置(105、108、111)の実IPアドレスとコネクション数が含まれている。次に、最小のコネクション数をもつ実IPアドレスを選択し、選択された実IPアドレスを有する負荷分散装置を通信先として決定する。その後、サービス利用側装置は、決定された負荷分散装置と通信を開始する。
図7を参照して、本発明による負荷分散装置の多重化方式における処理の流れを説明する。図7では、左端にサービス利用側装置であるクライアントPC(701)、その右側に複数の負荷分散装置(705、709、712)を示している。
本発明による方式では、従来方式と異なり、負荷分散装置にアクティブ、スタンバイという区別はない。図1で説明した通り、負荷分散装置のそれぞれは、ユニークな実IPアドレスと、共通の仮想IPアドレスとからなる2つのIPアドレス(706、710、713)を予め設定されている。
サービス利用側装置であるクライアントPC(701)は、サービス提供側装置であるサーバ装置にサービス要求を送信する時、まず、仮想IPアドレスにより通信先を指定して通信開始要求を送信する(ステップ702)。仮想IPアドレスは全ての負荷分散装置に共通であるので、各負荷分散装置(705、709、712)がそれぞれ通信開始要求を受信する。続いて、各負荷分散装置は、クライアントPCからの通信開始要求に対して応答を返す。この応答において、各負荷分散装置は、自らの実IPアドレスとコネクション数を設定して返す(ステップ707、711、714)。
クライアントPCは、各負荷分散装置からの応答を受信する。各応答に設定されているコネクション数を比較することにより、最も小さいコネクション数をもつ負荷分散装置を選択する(ステップ703)。図7の例では、負荷分散装置1(705)のコネクション数"1"が最も小さいので、負荷分散装置1(705)を選択する。その後、選択した負荷分散装置の実IPアドレスを使用して、負荷分散装置1との間で通信を行う(ステップ704)。
上記のステップ703において、最小のコネクション数が複数ある場合には、ランダムに1つを選択する。ここで選ばれた負荷分散装置は、当該クライアントPCから送信されてくるサービス要求を、サービス提供側装置である複数のサーバ装置(図1の102、103,104)に振り分ける処理を行う。また、選ばれた負荷分散装置は、クライアントPCとの通信を開始したときにコネクション数を1だけ増分する。
この方式においては、クライアントPCが、複数ある負荷分散装置の中から通信先として使用するものを選び出す。さらに、負荷分散装置を選ぶ基準が、最小のコネクション数に基づいている。この結果、各負荷分散装置のコネクション数が均等化される。つまり、各負荷分散装置自体の処理負荷が均等化されることを意味する。これはちょうど、負荷分散装置が複数のサーバ装置の処理負荷を均等化させるために複数のサーバ装置にサービスを振り分けていることと同じことを、複数の負荷分散装置に対してサービス利用側装置自体が行っていることになる。
従来方式では、1台のアクティブ負荷分散装置のみがサーバ振り分け処理を実行するのに対し、本発明では、複数ある負荷分散装置のすべてを均等に使用することとなるので、性能の面で優っている。
図8を参照して、本発明による方式おける、負荷分散装置に対する障害検知処理と他の負荷分散装置への切り替え処理について説明する。
図8(a)は、図7の方式によりクライアントPC(806)が使用する負荷分散装置1(802)を決定した後の状態を示している。この段階では、クライアントPC(806)が、サーバ装置(801)との通信を開始している。クライアントPC(806)が相手の負荷分散装置1(802)に対してHeart Beatパケットを送付することで負荷分散装置の死活を監視している。
図8(b)を参照し、クライアントPC(812)が選択した負荷分散装置1(808)において、通信開始後に障害が発生した場合について説明する。負荷分散装置(808)に障害が発生した場合、Heart Beatパケットに対する応答が返らなくなるので、クライアントPCは通信先の負荷分散装置に障害が発生したと見なす。続いて、クライアントPCは、再度、図7で説明した通信開始要求を負荷分散装置の仮想IPアドレスに対して送出する。仮想IPアドレスは負荷分散装置に共通であるので、全ての負荷分散装置(808、809、810)により受信される。以降、図7で説明した手順にて代替する負荷分散装置(810)を決定する。
負荷分散装置の再選択を行う際、以下のケースについて考慮することが好ましい。
・クライアントPC(812)が障害を検知した負荷分散装置(808)からも応答が返ってくる可能性がある。この場合は、再度同じ障害に陥る可能性があるので、設定されているコネクション数に関わりなく、通信先の候補から負荷分散装置(808)を除外する。
・すべての負荷分散装置(808、809、810)が障害の場合にはいずれの負荷分散装置からも応答がないことが考えられる。この場合は、回避不可能な恒久障害と見なし、クライアントPC(812)の画面にその旨のエラーメッセージを出力するなどによりエンドユーザにその旨を通知する。
図9及び図10の図及び表により、負荷分散装置の多重化に関する従来方式と本発明の方式とを比較した結果を示す。図9(a)は従来方式を、図9(b)は本発明の方式を示す。
図9(a)の従来方式では、サーバ振り分け処理をアクティブ負荷分散装置(902)1台でのみ処理する。これに対し、図9(b)の本発明による方式ではすべての負荷分散装置(908、909、910)をほぼ均等に使用するため、負荷分散装置の台数に見合った性能を発揮させることができる。
また、図9(a)の従来方式では、サーバ振り分け処理をアクティブ負荷分散装置(902)1台でのみ処理するために、これが障害となった場合には、スタンバイ負荷分散装置(903又は904)に切り替わるまでの間、すべてのサービス利用側装置(906)はサーバ装置(901)を使用することができなくなる。これに対し、本発明による方式では、すべての負荷分散装置(908、909、910)が並行してサーバ装置(907)への振り分け処理を行うため、そのうちの1台の負荷分散装置(908)に障害が発生しても、他の負荷分散装置(909、910)を使用しているサービス利用側装置(912)には影響が及ばない。このため、従来方式よりも本発明による方式の方がより信頼性が高いと言える。
さらに、図9(a)の従来方式では、負荷分散方式をアクティブ(902)とスタンバイ(903、904)の2種類に分けて管理しなければならないので、装置の設定情報などもそれぞれに管理して設定する必要がある。これに対し、図9(b)の本発明による方式では、アクティブとスタンバイの区別はなく、全ての負荷分散装置(908、909、910)について同一の設定でよいので、ネットワーク管理者の負担を軽減させる効果がある。
図11及び図12を参照し、本発明を負荷分散装置以外に適用した応用例を説明する。
図11は、サービス提供側装置である多重化されたサーバ装置の選択に関して本発明の方式を適用したシステム構成の一例を示している。
図11(a)に示すように、サービス利用側装置(1105)は、サービス提供側装置である複数のサーバ装置(1101、1102、1103)のいずれを使用するかを決定する。事前の設定として、サーバ装置(1101、1102、1103)の各々に対して、ユニークな実IPアドレスと、共通の仮想IPアドレスの2つのIPアドレスが付与されている。また、各サーバ装置は、通信しているサービス利用側装置の数を示すコネクション数を保有可能である。
まず、クライントPC(1105)が、仮想IPアドレスを指定してサーバ装置との通信開始要求を送信する。通信開始要求を受信した各サーバ装置(1101、1102、1103)は、実IPアドレスと、現時点で保有しているコネクション数を応答する。クライアントPCは、最もコネクション数の少ない実IPアドレスをもつサーバ装置1(1101)を通信先として決定する。
図11(b)に示すように、通信開始後は、クライアントPC(1110)がHeart Beatパケットを送信することにより、通信先のサーバ装置1(1106)の稼働を監視する。
図11(c)に示すように、サーバ装置1(1111)に障害が発生し、Heart Beatパケットが途絶したことにより、クライアントPC(1115)は障害の発生を検知する。
図11(d)に示すように、クライアントPC(1120)は、再び、仮想IPアドレスを用いて通信開始要求を送信する。それに対する応答に含まれるコネクション数に基づいて、クライアントPCは、障害が発生したサーバ装置(1116)以外のサーバ装置(1117又は1118)を通信先として決定する。
本発明をサービス提供側装置である多重化されたサーバ装置に適用することにより、以下の効果がある。
・サービス利用側装置(クライアントPCまたはサーバ装置)が、使用するサービス提供側装置であるサーバ装置を決定するので、上述した負荷分散装置自体が不要となる。
・背景技術で述べた通り、サーバ装置と負荷分散装置を直列に接続することで全体の稼働率は低下する。よって、負荷分散装置を介さないで直接サーバ装置と通信する方が稼働率は高まるという効果がある。
・負荷分散装置にかかる費用も不要となる。
・サービスを提供する多重化されたサーバ装置の性能、信頼性の向上が図れる。
図12は、2つ目の応用例として、新しいネットワーク技術であるOpenFlowに対して本発明の方式を適用したシステム構成の一例を示している。
図12(a)を参照して「OpenFlow」について説明する。「OpenFlow」とは、Open Networking Foundationという標準化団体が標準化を進めている新しいネットワーク技術である。これは、従来のL3スイッチ、L2スイッチで構成されてきたネットワークを、まったく新しい考え方によって刷新するものでる。OpenFlowでは、ネットワークは、「OpenFlowコントローラ」と「OpenFlowスイッチ」という2種類のネットワーク装置で構成される。従来技術では、ネットワークに関する経路情報(ルーティング情報とも言う)はL3スイッチへ個々に設定する必要があった。これに対し、OpenFlowでは、この経路情報をOpenFlowコントローラ(1201)が一元的に管理し、実際の経路制御を行うOpenFlowスイッチ(1202、1203、1204)がOpenFlowコントローラ(1201)に動的に問い合わせることで経路情報を入手する。
このように、管理情報を一元管理することでネットワーク管理者の負担を軽減することができる。しかし、一元管理と性能、信頼性は背反する面がある。つまり、管理情報を特定の装置で一元管理すると、その装置に処理が集中して性能が低下したり、また、その装置が障害となった場合にネットワーク全体に影響が生じたりするという問題がある。
OpenFlowコントローラとOpenFlowスイッチは垂直分散構成となっており、ここに本発明の多重化方式を応用することができる。図12(b)を参照して、本発明の適用形態を説明する。この場合、複数のOpenFlowコントローラ(1205、1206、1207)と、複数のOpenFlowスイッチ(1208、1209、1210)が設けられる。この形態では、OpenFlowコントローラが多重化されている。
事前の設定として、複数のOpenFlowコントローラ(1205、1206、1207)の各々は、ユニークな実IPアドレスと、共通の仮想IPアドレスを付与されている。また、各OpenFlowコントローラは、通信中のOpenFlowスイッチの数をコネクション数として保有可能とする。
例えば、OpenFlowスイッチ1(1208)が、問い合わせ先のOpenFlowコントローラを決定するために、共通の仮想IPアドレスを設定して問い合わせ開始要求を送信する。各OpenFlowコントローラ(1205、1206、1207)は、実IPアドレスとコネクション数を含む応答を行う。OpenFlowスイッチ(1208)は、コネクション数が最小であるOpenFlowコントローラ2(1206)を選択し、問い合わせ先として決定する。上述したように、問い合わせ中は監視を行い、問い合わせ先のOpenFlowコントローラに障害が発生したときは、再度の選択処理を行う。
本発明の方式をOpenFlowに適用することにより、以下の効果が得られる。
・OpenFlowコントローラの負荷を複数のOpenFlowコントローラで分散処理でき、性能面の課題が解決できる。
・利用中のOpenFlowコントローラが障害になった場合にも、別に稼動するOpenFlowコントローラを動的に選び直すことができ、信頼性面での課題が解決できる。
図13は、本発明による方式を適用して任意のサービス提供側装置の多重化を実現したシステム構成の一例を示す図である。
サービス提供側1301には、多重化されたサービス提供側装置(1302、1303、1304)が設けられている。サービス利用側1306には、少なくとも1つのサービス利用側装置(1307)が存在する。多くのシステムでは、複数のサービル利用側装置(1307、1308、1309)が存在する。
なお、図13には、適宜のコンピュータであるこれらの装置の機能のうち、本発明の方式を適用するための機能のみを示しており、これらの装置の本来のサービス等に関連する機能については示していない。本発明の方式に関連する機能は、各装置に導入された所定のプログラムにより実現される。各装置のCPUが、所定のプログラムをメモリに読み込み実行する。
サービス提供側装置(1302、1303、1304)の各々は、ユニークな実識別情報と、共通の仮想識別情報とからなる2つの識別情報を予め設定されており、これらの識別情報は適宜の記憶装置(1302d)に格納されている。これらの識別情報は、適宜のネットワークにおいて通信先や通信経路を指定するために用いられるものである。図13における実識別情報及び仮想識別情報は、上述した例における実IPアドレス及び仮想IPアドレスにそれぞれ対応する。なお、IPアドレスに替えてMACアドレスでもよい。
また、サービス提供側装置の記憶装置(1302d)には、サービス提供側装置の現時点の処理負荷のレベルを示す処理負荷レベル情報も格納される。この処理負荷レベル情報は、上述した例におけるコネクション数に対応する。
一方、サービス利用側装置(1307、1308、1309)の各々は、通信先となり得る複数のサービス提供側装置に共通する仮想識別情報を、適宜の記憶装置(1307d)に予め格納している。
例えば、サービス利用側装置1(1307)が、サービス提供側装置に通信開始要求を送信する時、識別情報送信部(1307a)が、仮想識別情報を記憶装置1307dから取得し、仮想識別情報により通信先を指定して通信開始要求を送信する。
各サービス提供側装置(1302、1303、1304)は、それぞれ通信開始要求を受信する。続いて、各サービス提供側装置の稼働情報応答部(1302a)は、通信開始要求に対する応答として稼働情報をサービス利用側装置1(1307)に返す。この稼働情報には、実識別情報と処理負荷レベル情報が含まれている。
サービス利用側装置1(1307)は、各サービス提供側装置からの応答すなわち稼働情報を受信する。サービス利用側装置1の通信先決定部(1307b)は、各稼働情報に含まれている処理負荷レベル情報を比較することにより、処理負荷が現時点で最小であるサービス提供側装置を選択する。選択したサービス提供側装置を通信先として決定する。その後、決定したサービス提供側装置の実識別情報を使用してそのサービス提供側装置との間で通信を行う。
なお、処理負荷レベル情報の好適例は、上述したコネクション数であるが、これに限られない。例えば、現時点の処理タスク量、メモリ使用量等を処理負荷レベル情報として利用できる。処理負荷レベル情報としては、サービス提供側装置が、通常、当然に保有している数値等をそのまま利用することが好ましい。そして、サービス利用側装置の通信先決定部は、処理負荷レベル情報に基づいて、現時点において処理負荷が最小であるサービス提供側装置を通信先として決定する。これは、複数のサービス提供側装置の処理負荷を均一とするためである。
サービス提供側装置の処理負荷レベル情報管理部(1302b)は、処理負荷レベル情報の記憶装置(1302d)への格納及び更新を管理する。処理負荷レベル情報がコネクション数の場合、処理負荷レベル情報管理部は、1つのサービス利用側装置との通信を開始したとき、記憶装置に格納したコネクション数を1だけ増分して更新する。1つのサービス利用側装置との通信が完了したときは、コネクション数を1だけ減らす。
通信中、サービス利用側装置1(1307)の障害監視部(1307c)は、Heart Beatパケット等の監視用情報をサービス提供側装置に定期的に送信する。サービス提供側装置の監視応答部(1302c)は、監視用情報を受信したとき、それに対して応答を返す。サービス利用側装置1の障害監視部(1307c)は、監視用情報に対する応答が途絶えることにより、障害発生を検知する。
障害発生を検知したサービス利用側装置1では、再度、識別情報送信部(1307a)が仮想識別情報を用いて各サービス提供装置に対して通信開始要求を送信し、最初と同様の手順により通信先のサービス提供側装置を決定する。
図13に示した多重化されたサービス提供側装置は、例えば、図1に示した多重化された負荷分散装置若しくは図12に示したOpenFlowにおける多重化されたOpenFlowコントローラ等の多重化されたネットワーク装置、又は、図11に示したサービス提供側の多重化されたサーバ装置に対応する。
図13に示したサービス利用側装置は、例えば、図1若しくは図11に示したサービス利用側のクライアントPC若しくはサーバ装置、又は、図12に示したOpenFlowにおけるOpenFlowスイッチに対応する。
101、201、301、1301:サビース提供側
102、103、104、202、203、204、302、303、304、401、402、403、409、410、411、801、807、901、907、1101、1102、1103、1106、1107、1108、1111、1112、1113、1116、1117、1118:サービス提供側のサーバ装置
105、108、111、205、305、306、404、405、412、413、501、502、503、504、601、602、603、604、605、606、705、709、712、802、803、804、808、809、810、902、903、904、908、909、910:負荷分散装置
106、109、112:負荷分散装置が保有する仮想IPアドレスと実IPアドレス
107、110、113:負荷分散装置が保有するコネクション数
114、206、307、406、414、805、811、905、911、1104、1109、1114、1119、1305:ネットワーク
115、207、308、1306:サービス利用側
116、208、309、407、415:サービス利用側のサーバ装置
117、209、310、408、416、701、806、812、906、912、1105、1110、1115、1120:サービス利用側のクライアントPC
702、703、704:クライアントPCでの処理
706、707、708、710、711、713、714:負荷分散装置での処理
1001:従来方式と本発明による方式に関する比較表
1201、1205、1206、1207:OpenFlowコントローラ
1202、1203、1204、1208、1209、1210:OpenFlowスイッチ
1302、1302、1304:サービス提供側装置
1302a:識別情報応答部
1302b:コネクション数管理部
1302c:監視応答部
1303d:記憶装置
1307a:識別情報送信部
1307b:通信先決定部
1307c:障害監視部
1307d:記憶装置

Claims (3)

  1. ネットワーク装置又はサーバ装置である複数のサービス提供側装置と、前記サービス提供側装置とネットワークを介して通信する少なくとも1つのサービス利用側装置と、を備えたシステムにおけるサービス提供側装置の多重化方式であって、
    前記サービス提供側装置の各々は、ユニークな実識別情報と全てのサービス提供側装置に共通な仮想識別情報とを予め設定されており、
    前記サービス利用側装置は、
    前記仮想識別情報により通信先を指定した通信開始要求を送信する識別情報送信部と、
    前記通信開始要求を受信した前記サービス提供側装置の各々から、それぞれの前記実識別情報を含む各応答を受信したことに応じて、複数の前記サービス提供側装置のうちのいずれかを通信先として決定する通信先決定部と、を備え、かつ、
    通信先として決定されたサービス提供側装置との間で前記実識別情報を使用して通信を行うことを特徴とするネットワーク装置又はサーバ装置の多重化方式。
  2. 前記サービス利用側装置はさらに、
    通信中のサービス提供側装置に対して監視用情報を送信し、前記監視用情報に対する前記サービス提供側装置からの応答を受信し、前記監視用情報に対する応答が途絶えたことにより前記サービス提供側装置における障害発生を検知する障害監視部を備え、
    前記障害監視部が障害発生を検知したことに応じて、前記識別情報送信部が再度、通信開始要求を送信し、前記通信先決定部が別のサービス提供側装置を通信先として決定することを特徴とする
    請求項1に記載のネットワーク装置又はサーバ装置の多重化方式。
  3. 前記サービス提供側装置の各々はさらに、現時点の処理負荷を示す処理負荷レベル情報をそれぞれ保有しており、かつ、前記通信開始要求に対する前記サービス提供側装置の各々からの各応答には、それぞれのサービス提供側装置の処理負荷レベル情報が含まれており、
    前記サービス利用側装置の前記通信先決定部は、前記処理負荷レベル情報に基づいて、現時点の処理負荷が最小のサービス提供側装置を通信先として決定することを特徴とする請求項1又は2に記載のネットワーク装置又はサーバ装置の多重化方式。
JP2012173568A 2012-08-06 2012-08-06 ネットワーク装置又はサーバ装置の多重化方式 Pending JP2014032576A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2012173568A JP2014032576A (ja) 2012-08-06 2012-08-06 ネットワーク装置又はサーバ装置の多重化方式

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2012173568A JP2014032576A (ja) 2012-08-06 2012-08-06 ネットワーク装置又はサーバ装置の多重化方式

Publications (1)

Publication Number Publication Date
JP2014032576A true JP2014032576A (ja) 2014-02-20

Family

ID=50282345

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012173568A Pending JP2014032576A (ja) 2012-08-06 2012-08-06 ネットワーク装置又はサーバ装置の多重化方式

Country Status (1)

Country Link
JP (1) JP2014032576A (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017502627A (ja) * 2014-01-06 2017-01-19 グーグル インコーポレイテッド ソフトウェア定義ネットワークにおけるマルチマスタ選択
JP2020091618A (ja) * 2018-12-05 2020-06-11 アズビル株式会社 施設監視システム、および、施設監視システムにおける通信方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10105498A (ja) * 1996-10-02 1998-04-24 Nec Corp ネットワークシステム、ネットワークシステムにおける 通信サーバの切り替え方法および通信サーバの切り替え 用プログラムを記憶した記憶媒体
JPH10320355A (ja) * 1997-05-16 1998-12-04 Toshiba Corp 計算機接続方式及び計算機接続用プログラムを記録した記録媒体
JP2000305876A (ja) * 1999-04-26 2000-11-02 Hitachi Ltd コネクション活動監視方法
JP2001216282A (ja) * 2000-02-04 2001-08-10 Nec Corp サーバ、クライアント、クライアントサーバシステム、負荷分散方法、記録媒体

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10105498A (ja) * 1996-10-02 1998-04-24 Nec Corp ネットワークシステム、ネットワークシステムにおける 通信サーバの切り替え方法および通信サーバの切り替え 用プログラムを記憶した記憶媒体
JPH10320355A (ja) * 1997-05-16 1998-12-04 Toshiba Corp 計算機接続方式及び計算機接続用プログラムを記録した記録媒体
JP2000305876A (ja) * 1999-04-26 2000-11-02 Hitachi Ltd コネクション活動監視方法
JP2001216282A (ja) * 2000-02-04 2001-08-10 Nec Corp サーバ、クライアント、クライアントサーバシステム、負荷分散方法、記録媒体

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017502627A (ja) * 2014-01-06 2017-01-19 グーグル インコーポレイテッド ソフトウェア定義ネットワークにおけるマルチマスタ選択
JP2020091618A (ja) * 2018-12-05 2020-06-11 アズビル株式会社 施設監視システム、および、施設監視システムにおける通信方法
JP7316779B2 (ja) 2018-12-05 2023-07-28 アズビル株式会社 施設監視システム、および、施設監視システムにおける通信方法

Similar Documents

Publication Publication Date Title
TWI724106B (zh) 資料中心間的業務流量控制方法、裝置及系統
CN109274707B (zh) 一种负载调度方法及装置
CN107454155B (zh) 一种基于负载均衡集群的故障处理方法、装置以及系统
US10735553B2 (en) Micro-services in a telecommunications network
US6965930B1 (en) Methods, systems and computer program products for workload distribution based on end-to-end quality of service
JP5381998B2 (ja) クラスタ制御システム、クラスタ制御方法、及びプログラム
CN101316236B (zh) Vrrp备份组负载分担方法及路由器
EP3827558B1 (en) Fast failover for gateway instances
US20130332597A1 (en) Reducing virtual ip-address (vip) failure detection time
JP2013090072A (ja) サービス提供システム
JP7348983B2 (ja) 負荷分散システム、方法、装置、電子機器及び記憶媒体
CN111030926B (zh) 一种提高网络高可用性的方法及装置
JP5483029B2 (ja) クラスタシステムの結線作業の煩雑さを軽減するシステム及び方法
JP2014032576A (ja) ネットワーク装置又はサーバ装置の多重化方式
JP4709055B2 (ja) IPテレフォニーシステム、VoIPサービス提供方法
JP2006235837A (ja) 負荷分散システム、負荷分散装置管理サーバ、負荷分散装置の切り替え方法及びプログラム
WO2023207189A1 (zh) 负载均衡方法及系统、计算机存储介质、电子设备
CN114268581B (zh) 一种实现网络设备高可用和负载分担的方法
JP6579608B2 (ja) アドレス変換システム、アドレス変換の二重化方法及びプログラム
CN111835544B (zh) 一种基于用户态协议栈的虚拟路由器的监控方法及系统
EP3022658B1 (en) Failover handling in a content node of a content delivery network
US9019964B2 (en) Methods and systems for routing application traffic
WO2022044546A1 (ja) 通信システムおよびその障害復旧方法
JP2013013032A (ja) 通信制御方法および通信制御プログラム
CN113595760A (zh) 一种系统故障的处理方法和装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20150126

RD03 Notification of appointment of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7423

Effective date: 20150512

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20150413

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20150617

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A712

Effective date: 20150827

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20151124

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20151201

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160121

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20160209