電気通信大学大学院情報システム学研究科博士（工学）の学位申請論文

(1)

災害復旧向けストレージシステムに関する研究

牧晋広

電気通信大学大学院情報システム学研究科博士（工学）の学位申請論文

２０１１年３月

(2)

- 1 -

災害復旧向けストレージシステムに関する研究

博士論文審査委員会

主査吉永努教授

委員田野俊一教授

委員長岡浩司教授

委員大森匡教授

委員笠井裕之教授

(3)

- 2 -

著作権所有者

牧晋広

2011 年

(4)

- 3 -

Study of Storage Based Disaster Recovery System

Nobuhiro Maki

Abstract

Nowadays, major companies and business entities are utilizing new generations of storage-based disaster recovery system that allows an administrator to recover a computer system with short downtime after production system failure. There are most two notables, three data center storage disaster recovery system, and disaster recovery system with virtualized server. Three data center storage disaster recovery system has a shortfall that it consumes huge time for the system configuration. And disaster recovery system with virtualized server has a shortfall which degrades the performance of replication management for plural guest servers’ data.

In this paper, we provide technologies to solve each problem.

For three data center storage disaster recovery system, we provide a control mechanism that virtually builds a replication while data on storage in the

production data center are replicated to the other storages. And evaluation shows that a system with our mechanism can reduce the configuration time to validate readiness for the replication between the other storages shorter in the range from 1/39 to 1/143 with compared to the conventional mechanism.

For disaster recovery system with virtualized server, we provide a new in-band replication management mechanism that (1) detects non-gen’ed volumes, on which guest server cannot access the data, and gen’ed volumes, on which guest

(5)

- 4 -

server can access the data, prior to starting replication control, and that (2)

disperses storage control I/Os among as many detected gen’ed volumes as possible during replication control. Our evaluation shows that the system with our

mechanism can reduce the execution time of replication management 60 percent shorter than the conventional mechanism. And we confirmed that the performance impact of the additional functions to the replication management is practically negligible.

(6)

- 5 -

災害復旧向けストレージシステムに関する研究

牧晋広

概要

企業における情報システムの重要性は高まる一方で、災害等によるシステムの停止やデータの損失は、企業の存亡にかかわる。そのため、災害等によるシステム障害時にも、

短時間にシステムの回復を実現する災害復旧システム（以下、DRシステム：Disaster Recovery system）は必要不可欠である。

本論文はDRシステムに関し、特に、情報システムの進化に合わせ登場した新しいストレージDRシステムが持つ問題を解決する。上記を実現するべく、著者が担当したシステム方式、アーキテクチャの観点で、仮想レプリケーション制御方式、および、サーバ仮想化環境対応型In Bandレプリケーション制御方式の提案および評価を行う。

第１章では、本研究の背景と目的を明らかにする。

第２章では、はじめに、DRシステムの概要と、近年の企業の期待に応える新しいストレージDRシステムとその問題について述べる。具体的に、DRシステムへの期待には、法規制強化への対応と、設備投資抑制への対応があることを示す。また、それらの期待に応えるストレージDRシステムには、「３拠点ストレージDRシステム」と「仮想サーバ対応ストレージDRシステム」があることを説明する。また、これらのストレージDRシステムの問題として、３拠点ストレージDRシステムにはシステムが有効に動作することの確認完了までの時間が多大である問題があること、仮想サーバ対応ストレージDRシステムには性能低下の問題があることを説明する。

(7)

- 6 -

第３章では、第２章で示した３拠点ストレージDRシステムの持つ問題を解決する、

仮想レプリケーション制御方式を提案する。具体的に、3拠点ストレージDRシステムの持つ問題とは、３拠点ストレージDRシステムでシステム被災後に実施する回復手続き（これを引き継ぎ処理とよぶ）で、被災を逃れたストレージ間でデータ２重化（レプリケーション処理とよぶ）を実施するが、このレプリケーション処理が引き継ぎ処理前に、有効に動作するか否かの確認が不可能なことにある。そのため、従来は、被災後に確実な引継ぎ処理を実現するために、テストとして実際にレプリケーション処理の動作テストを実施しており、多大な時間を要していた。この原因は、３拠点ストレージDR システムがレプリケーション処理を実施する対象ストレージの構成が引き継ぎ処理の前後で異なることにある。本方式では、引き継ぎ処理前に上記レプリケーション処理を仮想的に実施する。これにより、引き継ぎ処理前に予め上記レプリケーションの動作検証を可能にする。本方式を実機にて試作し、評価したところ、本方式を適用しない場合

に比べ、1/39 から 1/143 にシステムの動作検証を確認するための時間が短縮されるこ

とを確認した。

第４章では、第２章で示した仮想サーバ対応ストレージDRシステムで、特にメインフレーム計算機向けのストレージDRシステムが持つ問題を解決する、サーバ仮想化環

境対応型In Bandレプリケーション制御方式を提案する。この問題は、上記ストレー

ジDRシステムで、レプリケーション制御のために使用する特別なボリュームに、レプリケーション制御用の指示コマンド（制御コマンドとよぶ）が集中することにある。ここで、特別なボリュームを用意する理由は、本来レプリケーション制御で使用するサーバからアクセス可能なボリュームが、サーバ仮想化適用により頻繁に変化しその特定が困難になり、確実にアクセス可能なボリュームを確保するためである。本方式は、１ゲスト計算機上で動作する管理プログラムから、任意のタイミングで、当該ゲスト計算機からアクセス可能なストレージ内ボリューム構成を取得可能とし、レプリケーション制

(8)

- 7 -

御直前には、上記最新のアクセス可能なボリューム全てを対象に、離散的に制御指示を発行する。本方式を試作し、評価したところ、本方式を適用しない場合に比べ、最大 60％にレプリケーション制御のための時間を短縮できることを確認した。また、本方式実現には追加処理が必要になる。そこで、その影響を確認するべく、追加処理時間を考慮に入れた評価を実施したところ、実質的にその影響は無視できることが分かった。

第５章では、本研究で得られた成果について総括し、今後の研究課題について述べる。

(9)

- 8 -

1. 序論

1.1 背景と目的

企業における情報システムの重要性は高まる一方である。その一方で、テロ、災害等によるシステム停止やデータ損失の発生を避けることは難しく、一旦システムが停止するとその企業は莫大な損失を被る[1]。災害等発生後も短時間にシステム復旧を実現するため、災害復旧システム（Disaster Recovery System：以後、DRシステム）が利用される。DRシステムは地理的に離れた複数拠点にある計算機システムのデータを複数拠点間で冗長に保持するシステムで、災害発生時は被災を逃れた拠点に保持されたデータを使用し、システムの復旧が可能となる[2][3]。

近年DRシステムで注目されている方式に、ストレージベースDRシステムがある。

ストレージベースDRシステムはストレージ間でデータを2重化するDRシステムで、

2重化にはストレージによる2重化機能であるリモートレプリケーション機能が用いられる。ストレージベースDRシステムは、計算機自体がデータを遠隔地に複製する従来の方式に比べ、計算機の処理負荷が少なく、計算機や業務アプリケーションへの修正・

変更も不要であるため、多くの企業で利用されている[4]。本論文では、ストレージベースDRシステムを単にストレージDRシステムとよぶことにする。

近年、企業では法規制の強化や設備投資抑制への強まりからDRシステムにも新たな期待が寄せられている。そこで、ストレージDRシステムでは、法規制強化に耐えうる高い災害からの復旧性を実現する「3拠点ストレージDRシステム」[5]や、設備投資抑制に効果の高い「仮想サーバ対応ストレージDRシステム」が登場している[6]。

(13)

- 12 -

3拠点ストレージDRシステムは、3拠点に配置されたストレージ間でデータを3重化するDRシステムである。このシステムにおける3重化は、2種類のリモートレプリケーション機能を組み合わせることで実現する。すなわち、データ無損失だが転送距離に制限のある同期リモートレプリケーションと、理論上の転送距離に制限はないがデータ損失リスクのある非同期リモートレプリケーションを組み合わせる。上記により、3 拠点ストレージDRシステムは広域にシステムを分散した構成で、災害発生時もデータ損失無くシステム復旧が可能という、両リモートレプリケーション機能の特徴を併せ持つことが出来る。しかしながら、3拠点ストレージDRシステムでは、従来のストレージDRシステムよりも構成が複雑になるため、システム構築が完了するまでに必要となる時間が増大する問題がある。

仮想サーバ対応ストレージDRシステムは、サーバを仮想的な計算機であるゲスト計算機に分割して利用可能にする仮想サーバに対応する。仮想サーバを利用することで、

ゲスト計算機の作成、削除が容易になるため、業務拡大や、業務要件の変更に素早く対応が可能になることもあり、多くの企業で導入が進んでいる。ストレージ DRシステムでは仮想サーバ上で動作するゲスト計算機のデータをリモートレプリケーションの対象とすることで、ゲスト計算機全体のシステム復旧を可能にする。しかしながら、

仮想サーバ対応ストレージDR システムはレプリケーション制御方式によってはリモートレプリケーションの制御性能が劣化する問題があった。リモートレプリケーションの制御性能が劣化すると、災害によるシステム障害の検出や、災害復旧のための時間が増大することにつながる。

本論文の目的は、企業の新しいニーズに応えるべく登場した上記ストレージ DRシステムが抱える問題の解決技術を確立することにある。そこで、本論文では著者が担当したシステム方式、アーキテクチャの観点で上記を論ずる。

(14)

- 13 -

1.2 本論文の構成

第2章では、はじめに、DRシステムへの新たなニーズに法規制強化への対応と設備投資抑制への対応があることを示し、それらに応えるべく「３拠点ストレージDRシステム」と「仮想サーバ対応ストレージDRシステム」が登場していることを説明する。

次に、上記のストレージDRシステムの問題について説明する。

第3章では、３拠点ストレージDRシステムの持つ問題を解決する仮想レプリケーション制御方式を提案する。

第4章では、サーバ仮想化を導入したメインフレーム計算機向けのストレージDRシステムが持つ性能低下問題を解決する、サーバ仮想化環境対応型In Bandレプリケーション制御方式を提案する。

第5章では、本研究で得られた成果について総括する。

(15)

- 14 -

2. ストレージ DR システムとその問題点

本章では、はじめに、本論文の背景技術となる、従来のDRシステム、特にストレージDRシステムについて概要を説明する。従来のDRシステムは、ストレージDRシステム以外にも、テープベースDRシステムやホストベースDRシステムがあり、それぞれの特徴を説明する。その中でも大企業で利用されることが多い、特にストレージDR システムについて、さらに説明する。

次に、企業において情報システムが企業活動に深く浸透するに従い、情報システムへの期待も、従来の処理性能の高さに加え、システム継続性の強化や、システムの低コスト化に広がってきている。また、その情報システムへの期待はストレージDRシステムにも波及しており、結果として、ストレージDRシステムにも上記に対応した新しいシステムが登場していることを示す。

最後に、上記新しいストレージDRシステムについて説明し、そのシステムの問題点を挙げる。

2.1 従来のストレージ DR システム

ここでは、本論文の前提となる従来のストレージDRシステムについて説明する。

2.1.1 概要と構成

災害復旧（DR）の概念は1960年代に登場した。DRを取り入れた計算機システムであるDRシステムが急速に発展したきっかけは、1988年の米国（Los Angels）で起きたファースト・インター・ステートバンクにおけるビル火災と言われている。同銀行は

(16)

- 15 -

DRシステムを導入しており、災害発生の翌日から業務を再開することができたためである。結果として，多くの企業でDRシステムの有効性が認められ、以降、DRシステムは急速に普及していった。

DRシステムでは、災害発生後、どの時点のデータをいつまでに復旧するかを指標として事前に定めておき、その指標が遵守されていることを監視しつつ運用することが重要である。この指標のうち、どの時点のデータを復旧できるべきかを目標復旧時点 (Recovery Point Objective, 以下RPO)、被災してからいつまでに業務を再開できるべきかを目標復旧時間(Recovery Time Objective)とよぶ（図 1参照）。

RPOとRTOは一般にコストをかければかけるほど短縮することが可能であるが、かけられるコストには限界がある。そこで、これらの目標値はITシステム提供者とシステム使用者との間で、被災確率や業務停止時間に応じた損害額とシステム構築に対するコストとを勘案して決定される[2][3]。

障害未来発生時

RTO

RPO

障害発生からシステムが

再開できるまでの時間障害発生からシステム

復旧時に遡る時間

過去

図 1 RPOとRTO

DRシステムはストレージDRシステムの他、テープベースDRシステムやホストベースDRシステム等がある。表 1に代表的なDRシステムを登場年代順に示す[7][8][9]。

テープベースDRシステムは1960年代に登場したDRシステムで、主ホストのデータをバックアッププログラム等によりテープに複製し、テープ媒体をトラックなどで遠

(17)

- 16 -

隔地に搬送、保管する。テープベースDRシステムは、一般的に、大規模システムへの適用が可能で、かつ、システムコストが安く抑えられる反面、RTOが長い。

ホストベースDRシステムは、1980年代に登場しており、業務を実施するホスト計算機上のプログラムが業務で生成されたデータを遠隔地のホスト計算機に転送し、保存するシステムである。ホストベースDRシステムは価格と性能のバランスがとれているが、システム規模に制限がある[10][11]。

ストレージDRシステムは、1994年に同期型[12]が、1999年に非同期型[13]が登場している。ストレージDRシステムは、高価であるが、大規模システムへの対応が可能で、かつ、RPO/RTOが小さい。そのため、ストレージDRシステムは大企業を中心に利用されている。以降、本論文では、ストレージDRシステムについて論ずる。

表 1 代表的なDRシステム

登場時期手段システム規模システムコスト距離の制限 RPO RTO 1960年代テープ搬送小規模～大規模低価格制限なし 24～168

時間

48～168 時間 1980年代ホストベース

DRシステム

中規模

(数百ボリューム)

中間の価格制限なし (非同期方式時)

5～30分未公開

1994年ストレージDRシステム (同期リモートレプリケーション使用時)

大規模

(数万ボリューム) 高価

ストレージや、

専用回線が必要

１００ｋｍ前後理論上0 1～8 時間

1999年ストレージDRシステム (非同期リモート

レプリケーション使用時)

大規模

(数万ボリューム) 高価

ストレージや、

専用回線が必要

制限なし 0～5分 1～8 時間

(18)

- 17 - ストレージDRシステムの構成：

ストレージDRシステムの一般的な構成を図２に示す。

ストレージDRシステムは地理的に離れた２拠点（図では主拠点、遠隔拠点）それぞれにある、(a)ホスト計算機と(b)ストレージからなる拠点計算機システムがストレージネットワークにより相互に接続される構成をとる。ストレージネットワークのプロトコルには一般的に FCP(Fibre Chanel Protocol)や iSCSI(Internet Small Computer System Interface)等が使用される[14][15]。

各拠点には同一構成の機器を配置する。これにより、任意の拠点からのシステム復旧を容易にする。

(a) ホスト計算機、管理計算機：

ホスト計算機には業務アプリケーションプログラム（以下AP）が、管理計算機には管理プログラムが動作する。ただし、ホスト計算機、管理計算機は同一計算機であっても構わない。

管理プログラムはシステム使用者向けの操作手段とストレージ制御手段を備える。

操作手段にはグラフィカルインタフェイス（Graphical User Interface: GUI）やコマンドラインインタフェイス（Command Line Interface: CLI）などがある。システム使用者は状況に応じこれらの操作手段を使い分ける。すなわち、システム使用者は、CLI を組み合わせたスクリプト等により繰り返し実施する操作を行い、GUI によりリモートレプリケーションの処理状態の確認や、障害発生時など特別な場合の操作を行う。

ここで、表 2にCLIの1例として、著者らが研究するレプリケーション制御方式を採用した管理プログラム REMDY（REplication Management mechanism with DYnamic load of OS disk configuration）のCLIを示す[16] [17]。CLIの形式は以下の通りである。

(19)

- 18 -

CLIはオペコード部、オペランド部、そしてオプション部からなる。オペコードは指示内容を規定する。オペランド部はレプリケーション対象を指定する。オプション部はレプリケーション制御で付加的な情報を規定する。

ストレージ制御手段とは、ストレージの諸機能を制御する管理プログラムの１機能を指す。具体的に、図２のレプリケーション機能を制御する場合、管理プログラムがストレージ専用の制御コマンドをレプリケーション元の主ストレージに発行することで実現する。

制御コマンドを受信すると、コマンドを受信したストレージが制御コマンドに指定されたストレージ機能を実施する。例えば、レプリケーション機能の場合、ストレージはボリューム間でレプリケーション処理を実施する。図２では、主ストレージがコマンドを受信し、レプリケーション元である主ストレージ内のボリュームからレプリケーション先の遠隔ストレージボリュームに対し、レプリケーション処理を実施する。これにより、遠隔ストレージのデータを主ストレージのものと一致させる。レプリケーション処理の具体的な処理については後述する。

(b) ストレージ：

ストレージはデータを実際に記憶する記憶装置の他に、制御装置、バッファを備える。

記憶装置はハードディスクドライブ等から論理的な記憶資源であるボリュームを提供する。制御装置はデータ送受信機能、およびレプリケーション機能を備える。バッファはレプリケーションで転送されるデータを一時的に保持するために使用される。また、

バッファは複数のレプリケーション処理に備え、複数系統用意される。

オペコード部オペランド部オプション部

(20)

- 19 - 主拠点

ボリューム

ボリューム主AP

ボリューム

遠隔拠点

主ホスト計算機

主ストレージ遠隔ストレージ

管理Prg 管理計算機

リモートレプリケーション

待機AP 副ホスト計算機

制御装置バッファバッファ制御装置

制御 cmd

図 2 ストレージDRシステムの構成

(21)

- 20 -

表 2 REMDYのレプリケーション操作CLI

コマンド操作単位説明

MAKE

（開始）

指定した１か複数のレプリケーションペア

レプリケーションの構築を開始する

オプションには、レプリケーションの方向逆転、

ペア構築単位変更（複数ペア一括、もしくは、

ペア）単位、制御方式変更(直接、間接)等がある SUSPEND

（一時停止）

レプリケーション処理を一時停止する

レプリケーション先ボリュームの書き込み可否、

一時停止の単位変更（複数ペア一括、もしくは、

ペア）、制御方式変更(直接、間接)等がある RESYNC

（再同期）

レプリケーションペアを再同期する

再同期の単位変更（複数ペア一括、もしくは、

ペア）、制御方式変更(直接、間接)等がある DELETE

（削除）

レプリケーションペアを削除する

オプションには、強制削除、削除単位の変更（複数ペア一括、もしくは、ペア）、レプリケーション先ボリュームのみペア削除、制御方式変更(直接、

間接)等がある QUERY

（状態取得）

レプリケーションペアの処理状態を取得するオプションには、情報取得範囲の制限（レプリケーション先のみ、レプリケーション元のみ）、制御方式変更(直接、間接)等がある

(22)

- 21 -

2.1.2 制御方法

ストレージ DR システムの制御には一般的に２種類の方式がある。In Band 方式と Out Of Band方式である[14] [18]。

図 3に両方式の概念図を示す。

ホスト計算機

Gen

ストレージ Non Gen

AP

ホスト計算機

ストレージ AP

管理計算機管理P

In Band 方式 Out of Band 方式

制御 cmd

管理P

データ通信線

制御用通信線

ホスト計算機

管理P AP

ホスト計算機

管理P AP

管理計算機

管理P

制御 cmd 制御

cmd

Gen Vol の場合

Non Gen Volの場合、

Gen Volを経由

図 3 ストレージDRシステムの制御方式

In Band方式：

In Band方式とはホスト計算機上で動作する管理プログラムが、データ通信線を

介し、ストレージのレプリケーション機能を制御する方式である。In Band方式ではホスト計算機がデータアクセス可能なボリュームに向け制御コマンドを発行する。この制御は上述の通り、システム使用者がレプリケーション制御時に管理

(23)

- 22 -

プログラムの CLI 等で発行先のボリュームを指定することで実現する。ただし、

上記制御が可能なのはメインフレーム計算機のチャネルインタフェイス[19]のみである。SCSI（Small Computer System Interface）インタフェイスの場合、制御コマンド受信可能なボリュームは、制御コマンド受信専用のボリュームに限定される。

ここで、データアクセス可能なボリュームとは、ホスト計算機とストレージとがデータ通信線に接続され、OS が当該ストレージ内のボリュームを認識し、識別子を付与したボリュームを指す。本論文ではこのボリュームをGenボリューム¹とよぶ。一方、データアクセスが不可能なボリュームをNon Genボリューム²とよぶことにする。Non Genボリュームは、例えば、計算機のボリューム識別子（メインフレーム計算機の場合、デバイス番号）資源の枯渇抑止や、後述する計算機資源論理分割（LPAR）や仮想サーバにより計算機内に複数存在するゲスト計算機占有ボリュームを利用する場合等で使用される。ボリューム識別子枯渇抑止は、

ボリューム容量が比較的小容量のメインフレーム計算機で、巨大データを扱う場合に利用される。一般的には、計算機使用者がメインフレーム計算機で管理可能なボリューム数（z/OS1.0の場合64k個）以上のボリュームをストレージのボリューム識別子（物理 IO アドレス、詳細は後述）で管理し、必要に応じメインフレーム計算機のGenボリュームとNon Genを切り替えて使用する。計算機資源論理分割におけるゲスト計算機占有ボリュームは、１ゲスト計算機で主業務を実施し、別ゲストが主業務で生成されたデータをローカルレプリケーションなどで複製し、テープにバックアップする等の場合で使用される。図 4に計算機資源論理分割における Non Gen ボリュームのテープバックアップの使用例を示す。ゲスト計算機2のバックアッププログラムはストレージの全ボリュームをストレー

1 メインフレーム計算機の専門用語で、Generated volumeの略語。

2 メインフレーム計算機の専門用語で、Non Generated volumeの略語。

(24)

- 23 -

ジアドレス（物理 IO アドレス）で管理しており、ストレージアドレス指定によ

り、Gen、Non Genを問わず全てのストレージボリュームを制御する。このスト

レージアドレスはストレージの設定ツールなどから取得し、管理プログラムからはこの情報を人手で指定することにより制御する。

図 4のように、Non GenボリュームのIn Band制御は、管理プログラム稼働OS が認識するGen ボリュームに一旦制御コマンドを発行し、当該Genボリュームを経由することで、対象のボリュームを制御する。これは、管理プログラムが制御コマンドの発行に OS の IO制御機能を利用しているためである。すなわち、

OSのIO制御機能により制御コマンドを発行する場合、発行先は上記OSがボリューム識別子（デバイス番号）を付与したボリュームに限定される。また、制御コマンドに物理 IO アドレスを指定することで、ストレージ内任意のボリューム制御が可能となる。

In Band方式はホスト計算機のデータ入出力とレプリケーション制御が同一通信

線を利用するため、ホスト計算機上の APとレプリケーション制御との同期が取り易いメリットがある。

Out Of Band方式：

Out Of Band方式とは管理計算機上で動作する管理プログラムが、ストレージに

接続された制御用の通信線を介して、レプリケーションを制御する方式である。

Out of band方式では管理計算機とホスト計算機とが同一である必要はない。そ

のため、Out of band方式ではホスト計算機の処理負荷やストレージとのアクセ

ス設定に依存することなくレプリケーションを制御できるメリットがある。その

一方で、Out of Band方式はホスト計算機のデータ入出力とレプリケーション制

御は異なる通信線を使用するため、ホスト計算機上の AP と同期したレプリケーション制御は難しい。

(25)

- 24 - ゲスト計算機１ゲスト計算機２

メインフレーム計算機 LPAR機構

AP _{管理プログラム}^{バックアップ}

ローカルレプリケーション

データデータ

Tape

1234 C002

NonGen VolからGen Volに複製し、

テープ保存

データ

ストレージ

C001 C002

Tape

物理IOアドレス Gen

1234 Non Gen

デバイス番号 Cmd

(C001)

? C001

図 4 Non Genボリュームの使用例（LPARの場合）

レプリケーション機能の処理状態とその変更：

次に、ストレージにおけるレプリケーション機能はいくつかの処理状態を持っており、

それらは制御コマンドで変更できる。

制御コマンドは指示内容と、レプリケーション種別、レプリケーション構成から成る。

指示内容は、リモートレプリケーションの処理動作を規定し、開始、一時停止、再同期、削除、状態取得がある。

レプリケーション種別はローカルレプリケーション、リモートレプリケーションがあり、リモートレプリケーションの場合は、さらに、同期方式、非同期方式のいずれかを規定する。

レプリケーション構成は１か複数のレプリケーション元と、レプリケーション先ボリュームの組から構成される。このボリュームの組をレプリケーションペアもしくは単に

(26)

- 25 - ペアとよぶ。

次に、レプリケーション機能の処理状態を表 3に示す。

レプリケーションの処理状態の変更は情報システムの運用状況（例えば、定期メンテナンス）や、障害発生、システム復旧時などのケースに応じ、実施する。また、レプリケーションの処理状態を確認するには、制御コマンドによりその時点の処理状態を取得すればよい。レプリケーションの処理状態を確認する理由は、機器障害、回線障害等によってレプリケーション処理が停止する可能性があるためである。レプリケーション処理の停止はデータ損失（RTO の増大）につながるため、定期的にレプリケーションの処理状態を確認する必要がある。

次に、図 5にレプリケーション処理の状態遷移を示す。

図中の過渡状態は時間が経過すると、自動的に別の処理状態に遷移する状態を指す。

安定状態は時間経過に依存することなく、その状態から変更しない状態である。特定の制御コマンドにより、安定状態から状態の変更が可能となる。矢印上の記述が各状態から別状態に遷移するときに必要な CLI コマンドである。障害状態は特別な状態で、ストレージハードウェア障害、データ回線の障害等が発生すると任意の状態から遷移する。

障害状態から別の状態への遷移可否は障害の種類や、障害からの復旧状態により異なる。

(27)

- 26 -

表 3レプリケーションの処理状態とその意味処理状態

（括弧はCLIの表示）

意味遠隔ストレージからのシステム復旧

レプリケーション未実施

（SIMPLEX）

レプリケーションが動作していない不可

定常レプリケーション

（DUPLEX）

レプリケーションが再構築した状態可能

ペンディング

（PENDING）

レプリケーションが別状態に遷移中。

一時停止から定常レプリケーションもしくはその逆、任意の状態からレプリケーション未実施、障害状態から定常状態への遷移がある。

不可

一時停止

（SUSPEND）

レプリケーションが一時停止状態可能

障害

（Error）

レプリケーションが障害状態不明

(28)

- 27 - レプリケーション

未実施 (SIMPLEX)

定常レプリケーション

(DUPLEX) 一時停止

(SUSPEND)

ペンディング (PENDING)

凡例

障害 (Error) DELETE

MAKE

DELETE

SUSPEND RESYNC

RESYNC

過渡状態安定状態自動遷移

コマンド遷移

DELETE

初期レプリケーション (PENDING)

図 5 レプリケーション処理の状態遷移

2.1.3 ストレージにおけるリモートレプリケーションの処理

ストレージDRシステムでは、主ストレージが遠隔ストレージと連携し、レプリケーション処理を実施する。一般的に、ストレージDRシステムでは、レプリケーション機能の中でもリモートレプリケーション機能を利用する。そのため、以降はリモートレプリケーション機能の処理を前提に論ずる。

主ストレージは主ホストから制御コマンドを受け付けると、当該制御コマンドの指示内容に従い、リモートレプリケーション処理を実施する。

リモートレプリケーションの処理はボリューム単位に実施される。また、リモートレ

(29)

- 28 -

プリケーション処理は一般的に同期、非同期リモートレプリケーションの２種類があり、

それぞれ異なる処理を行う。また、同期、非同期の両リモートレプリケーション処理は３つの処理状態がある。初期レプリケーション、定常レプリケーション、一時停止である。以下、それぞれについて説明する。

2.1.3.1. 初期レプリケーション

初期レプリケーションとは、レプリケーション先のデータをレプリケーション元のデータに一致させる処理である。従って、初期レプリケーション期間中は両ストレージ間のデータは一致せず、レプリケーション先のストレージからはシステム復旧が不可能となる。

具体的な処理は、ストレージが制御コマンドを受信し、その指示内容が「開始（ＭＡＫＥ）」の場合、制御コマンド内のレプリケーション構成を取りだし、次に、初期レプリケーションを開始する。初期レプリケーションが開始されると、ストレージは「リモートレプリケーション構築可否の確認」と「レプリケーションボリュームの全複製」を順次実施する。

[1] リモートレプリケーション構築可否の確認：

リモートレプリケーションが正常に稼働するための要件（稼働要件）は以下である。

この確認により、人手で実施されるリモートレプリケーションの構成設定や通信設定が有効であるかを判断する。

“制御コマンドに指定されたレプリケーションペアが存在し、当該ストレージ間でデータ送受ができること”

(30)

- 29 -

リモートレプリケーションが正常に稼働することを確認するべく、ストレージDRシステムでは以下を実施する。（図 6参照）

(a) 主ストレージが制御コマンドのレプリケーション構成に規定されるレプリケーション元のボリュームが存在することを確認

(b) レプリケーション元のボリュームが存在する場合、主ストレージが当該制御コマンドをレプリケーション先のストレージに転送

(c) 当該制御コマンドを受け付けたレプリケーション先ストレージが主ストレージ同様に、レプリケーション先のボリュームとして規定されたボリュームが自ストレージ内に存在することを確認

以上、(a)(c)で制御コマンドに指定されたリモートレプリケーションの構成を、(b)の

対象ストレージ間で実施する制御コマンド転送の結果でデータ送受可否を、それぞれ検証でき、動作要件を満たすことが確認できる。

[2] レプリケーションボリュームの全複製：

主ストレージはレプリケーション元ボリューム上の全データを複製し、レプリケーション先のストレージに当該データを分割して順次転送する。レプリケーション先のストレージは受信したデータを順次格納する。主ストレージのデータ転送はレプリケーション先ストレージの応答を待つことなく、連続的に実施される。この処理により、主ストレージは自ストレージに格納されるレプリケーション対象の全データをレプリケーション先ストレージに格納されるデータと一致させる。初期レプリケーションは主ストレ

(31)

- 30 -

ージにあるレプリケーション対象の全ボリュームのデータすべてを複製し終えると完了となり、主ストレージは定常レプリケーション処理を引き続き実施する。初期レプリケーション処理から定常レプリケーション処理への移行には特別な制御コマンドを必要としない。

主拠点

ボリューム

ボリューム主AP

ボリューム

遠隔拠点

管理Prg 管理計算機

待機AP 副ホスト計算機

制御 cmd

レプリ構成レプリ構成

1(a)確認

制御 cmd

1(b)制御cmd 転送

2. 全複製

図 6 初期レプリケーションの処理内容

2.1.3.2. 定常レプリケーション

定常レプリケーション処理では、主ストレージは主ホストによる更新データを受け付けるときのみ当該データを複製し、一方を主ストレージ内ボリュームに格納し、他方をレプリケーション先ストレージに転送する。レプリケーション先ストレージも、主ストレージが受け付けた順序と同じ順序で当該データをボリュームに格納する。

定常レプリケーション処理では、レプリケーション元、先ストレージ間で送受される

(32)

- 31 -

データが主ホストから発行される更新データのみになる。そのため、初期レプリケーションの通信トラヒックに比べ、定常レプリケーションのトラヒックはその量を大幅に削減することができる。また、リモートレプリケーション処理中に、主ホストから発行された更新データが主ストレージとレプリケーション先ストレージで同じ順序で書き込まれるため、主拠点が被災しても被災を逃れた拠点のホスト計算機は主ストレージの障害復旧と同じ手順でシステムを復旧できる。

定常レプリケーションは同期方式、非同期方式で処理内容が異なる。以下、それぞれについて説明する。

（１）同期リモートレプリケーションの処理

図 7に同期リモートレプリケーションの処理概要を以下に示す。

 主ストレージは主ホストから更新データを受信する（①）と、そのデータを複製し、

一方を主ボリュームに書き込み、他方を遠隔ストレージに転送する（②）。

 遠隔ストレージはデータ受信後、そのデータを副１ボリュームに書き込み、その応答を主ストレージに返す。

 主ストレージは応答受信後、主ホストに更新完了を報告する（③）。

以上により、主ホストが更新完了の報告を受けた時点で、遠隔ストレージでは主ストレージと同一データの保持が保証される。詳細は例えば[12]を参照されたい。

(33)

- 32 -

待機AP

遠隔拠点

副２Vol

通信回線

①

主拠点

正２Vol

②

主Vol A

Data 主AP

③ 応答

主ストレージ制御装置

主ホスト遠隔ホスト

制御装置

Data

②

Data

遠隔ストレージ副１Vol

Data

図 7 同期リモートレプリケーションの処理概要

（２）非同期リモートレプリケーションの処理

図 8に非同期リモートレプリケーションの処理概要を示す。

 主ストレージは主ホストから更新データを受信すると（①）、当該更新データを複製し、一方を主２ボリュームに書き込む。

 主ストレージは、もう一方のデータにシリアル番号を付与し転送フレームを作成し、

その転送フレームを自ストレージ内のバッファに格納する。

 バッファ格納後、主ストレージは主ホストに更新完了を報告する（②）。

 上記処理とは非同期に、主ストレージは通信トラヒックの状況に応じ、適切なタイミングでバッファに格納された転送フレームを取り出し、遠隔ストレージに転送する（③）。転送フレームにはシリアル番号が付与されているため、主ストレージは遠隔ストレージからの転送フレームの応答を待つことなく、連続的に転送フレームを転送する。

 遠隔ストレージは、受信した転送フレームのシリアル番号を基に転送フレームをソ

(34)

- 33 -

ートし、副２ボリュームに古い順にデータを書き込む。これにより、主ホストによるデータの更新順序を遠隔ストレージの書き込みでも再現できるため、同期リモートレプリケーションのように主ストレージは転送先ストレージから応答を待つ必要がない。主ホストは主ストレージ内のバッファに更新データ格納後、更新完了の報告を受ける。

以上より、主ホストのアクセス時間はデータ転送距離による影響を理論上受けない。

その反面、主ホストが更新完了の報告を受けた時点では、必ずしも遠隔ストレージに該当データが格納されているとは限らない。

なお、非同期リモートレプリケーションは転送フレームに複数のデータを詰め込む方式[5]と転送フレームとデータが１対１の方式[13]がある。

待機AP

遠隔拠点

副２Vol

通信回線

①

主拠点

主２Vol

②

主Vol A

Data 主AP

応答

③

主ストレージ制御装置

主ホスト遠隔ホスト

制御装置

Data 8 Data 7 Data 6 Data 5 Data 5 Data 4 Data 3 Data 2

Data

遠隔ストレージ副１Vol

Data Data ５

図 8 非同期リモートレプリケーションの処理概要

(35)

- 34 - 2.1.3.3. 一時停止

基本的に、定常レプリケーションは常時その処理が実施される。しかしながら、システムのメンテナンスなど、場合によってその処理を停止する場合がある。このような場合に、一時停止処理を行う。図 9に処理概要を示す。

一時停止処理中は、一般にホスト計算機から主ストレージに対し、データ更新があったとしても、そのデータは主、遠隔ストレージ間で２重化されない。ただし、一時停止から定常レプリケーションに復帰する際、主ストレージは受信した更新データのみを遠隔ストレージに反映し、両ストレージ間で出来る限り短時間に２重化の再開を可能にする処理を行う。

そのために、ホスト計算機から更新データを受信する場合、主ストレージが更新されたボリューム内のデータ領域（ボリュームアドレス、Logical Block Address等）を自ストレージの制御装置内のメモリに保持しておく。

この一時停止処理は同期リモートレプリケーションと非同期リモートレプリケーションで、違いはない。

主拠点遠隔拠点

バッファバッファ

レプリケーション

制御装置制御装置

待機AP 遠隔ホスト主AP

主ホスト

更新データの位置を記憶

副２Vol 正２Vol

主Vol A 副１Vol

data

図 9 一時停止の処理概要

(36)

- 35 -

一時停止処理から定常レプリケーション処理に移行するためには再開処理を実施する。主ストレージは遠隔ストレージとの間でデータの２重化を短時間で実現するべく、

一時停止中に保持していたボリューム内の更新されたデータ領域の情報を使って、遠隔ストレージに主ストレージの該当データのみを転送する。遠隔ストレージは受信したデータをボリュームに書き込む。これにより、主ストレージが一時停止中にホスト計算機から受信した更新データのみを副ストレージに反映させることができる。図 10に処理概要を示す。

この処理中のレプリケーション処理状態はペンディング状態である。この状態は定常レプリケーションから一時停止への移行状態と同じである。ただし、定常レプリケーションから一時停止への移行処理は、特別な処理は必要でなく、再開処理とは異なる。

この再開処理は、同期リモートレプリケーションと非同期リモートレプリケーションで違いはない。

待機AP 遠隔ホスト

主拠点

主AP

遠隔拠点主ホスト

バッファバッファ

制御装置制御装置

更新データのみを転送し、 2 重化

副２Vol 正２Vol

主Vol A 副１Vol

data

レプリケーション

図 10 一時停止から定常状態への移行処理概要

(37)

- 36 -

2.1.4 システム運用管理

ストレージDRシステムの運用管理について説明する。ストレージDRシステムの運用管理とは、システム使用者によるストレージDRシステムの管理手順を指す。ストレージDRシステムの運用管理には、システム構築、システム運用、障害からのシステム回復の３つの段階がある。

[1] システム構築

はじめに、システム構築について説明する。ここで、システム構築とは、ストレージDRシステムを開始し、システム復旧が可能な状態にすることを指す。そのために、ストレージDRシステムでは、主ストレージから遠隔ストレージにリモートレプリケーションを構築する。ここで、リモートレプリケーションを構築するとは、レプリケーション元ストレージとレプリケーション先ストレージとの間でリモートレプリケーションの処理を開始することを指す。上記は、システム使用者が主ホスト上の管理プログラムにより操作する。

例えば、REMDYのCLI操作による同期リモートレプリケーション構築の場合は、システム使用者が管理プログラムに「MAKE 同期リモートレプリケーション」を指示することで実現する。その後、システム使用者はリモートレプリケーションが「定常レプリケーション」に移行することを確認する。REMDYのCLI 操作の場合「QUERY」であり、その結果が「定常レプリケーション」であることを確認する。これにより、災害などによるシステム障害時もシステム復旧ができることを担保する。

[2] システム運用

システム構築完了後、システム運用を行う。システム運用では、レプリケーショ

(38)

- 37 -

ンの処理状態の確認と、レプリケーション制御等がある。これらは、企業における DRシステムの運用方針により異なる。ただし、一般的にシステム運用中にレプリケーション制御を実施しないことが多い。これは、システム構築完了時点で、

主、遠隔ストレージ間でデータ2重化が完了しており、システム復旧が可能なためである。システム運用中にレプリケーション制御を実施するのは、例えば、遠隔ストレージのレプリケーション先ボリュームのある時点のデータを、さらに別のボリュームに複製、保持することで、システム復旧の確度を高める場合などがある。一方、レプリケーションの処理状態確認は定常的に実施される。これは、

一般的に管理プログラムのレプリケーション処理状態の監視機能を利用する。この管理プログラムの機能を利用すると、例えば、レプリケーション処理状態が障害であることを検出すると、システム使用者にメールなどで通知することが出来る。

[3] システム復旧

主拠点被災時、システム復旧を遠隔拠点から行う。システム復旧は主拠点で実施していた処理の引き継ぎが目的である。そのために、図 11 に示すような、遠隔ストレージ、遠隔ホストで、主拠点からの引き継ぎ処理を実施する。以下、引き継ぎ処理を説明する。

 遠隔ストレージの処理：

遠隔ストレージで実施中のリモートレプリケーションの引き継ぎ処理を実施する。リモートレプリケーションの引き継ぎ処理とは、レプリケーション先のボリュームを遠隔ストレージからアクセス可能にする処理である。具体的には、レプリケーションの処理状態をレプリケーション未実施にする場合や、

(39)

- 38 -

レプリケーションの向きを変更する処理を実施する。レプリケーションの向きの変更とは、システム復旧前はレプリケーション先のボリュームをレプリケーション元にする処理を指す。ただし、レプリケーションの向きの変更はレプリケーション先のボリュームをアクセス可能な状態にすることが重要であり、遠隔ストレージから主ストレージにデータ複製が実施されなくてもよい。

遠隔ストレージ上のデータは、同期リモートレプリケーションの場合、被災直前の主ストレージと同一データ（RPOがゼロ）であり、非同期リモートレプリケーションの場合、一般的に被災直前のデータよりも過去時点のデータ

（RPOがゼロ超）である。

 遠隔ホストの処理：

遠隔ホストは遠隔ストレージに格納されたデータを用いて復旧処理を実施する。一般的に、フェールオーバ処理とよばれる。

フェールオーバ処理には、IPネットワークの主拠点から遠隔拠点への引き継ぎ（DNSの書き換え等）処理や、遠隔ホストの復旧処理がある。遠隔ホストの復旧処理はOS や AP が持つ障害復旧機能（例えば、データベース管理システムの場合、クラッシュリカバリ機能）を利用する。フェールオーバ処理が完了すると、遠隔ホストは遠隔ストレージのデータを用いて AP を開始する。

(40)

- 39 -

主拠点

主AP

遠隔拠点

管理Prg 管理計算機

待機AP 遠隔ホスト計算機

レプリ構成

リモートレプリケーション

一時停止

レプリケーションの向きを逆転

・ネットワーク移行

・遠隔ホストのAP活性

副２Vol 正２Vol

主Vol A 副１Vol

災害

図 11 引き継ぎ処理

以後、システム運用における期間、状態を以下のように定義する。

 上記、レプリケーションの構築が完了しシステム運用中の状態を

「システム運用中」

 上記、システム復旧処理の諸手続を「引き継ぎ処理」

(41)

- 40 -

2.2 新たな企業ニーズに対応したストレージ DR システム

とその問題点

2.2.1 情報システムへの新たな企業の期待

近年、企業では益々多くの分野で情報システムが利用されるようになっている。また、そのデータ自体の価値も高まる一方である。結果、企業における情報システムは従来の処理性能向上に加え、新たなニーズが出てきている。

その代表的なものに、システム継続性の強化、システムの低コスト化がある。

 システム継続性の強化：

情報システムが提供するサービスは企業に留まらず公共においても、当たり前に２４時間３６５日、常に利用されるものになっている。そのため、自治体においても、情報システムの継続性を高めるべく、情報システム継続性への指針策定[20]や、法規制を強化する傾向にある[21]。

 システムの低コスト化：

情報システムへの投資は抑制傾向にある。そのため、限られた予算の中で効率的に情報システムを使用する必要がある。これを実現する技術としてサーバ仮想化がある。サーバ仮想化により、ホスト計算機の計算機資源を仮想的に分割し、複数の仮想的な計算機として利用可能にする。これにより、１ホスト計算機に多数の計算機を集約することが出来る。サーバ仮想化を提供するホスト計算機を仮想サーバとよぶことにする。近年、企業における仮想サーバの導入は著しく増加している。例えば、調査会社IDCによると、世界市場で2009年第

(42)

- 41 -

２四半期に出荷されたサーバの16.5％が仮想サーバで、第1四半期の実績からさらに2％増で推移していた。今後も世界的な仮想サーバの出荷増が予想される。

上記のような情報システムへのニーズは高まる一方で、その期待はDRシステムにも広がっている。ストレージDRシステムもいくつか上記に対応したものが登場している。

システム継続性の強化に対応する「3拠点ストレージDRシステム」とシステム低コスト化に対応する「仮想サーバ対応ストレージDRシステム」である。

以下、それぞれのストレージDRシステムについて説明する。

2.2.2 3 拠点ストレージ DR システム

ここでは、3拠点ストレージDRシステムの概要、動作、システム運用管理について説明した後、本システムが潜在的に持つ3拠点ストレージDRシステムの問題点について述べる。

2.2.2.1. システム概要

３拠点ストレージ DR システムは３拠点に配置されたストレージ間でデータを３重化するストレージDRシステムである。３重化は２種類のデータ２重化技術、すなわち、

データ無損失だが転送距離に制限のある同期リモートレプリケーションと、理論上の転送距離に制限はないがデータ損失リスクのある非同期リモートレプリケーションを組み合わせて実現する。これにより、主拠点にあるストレージ（主ストレージ）上のデータは近郊拠点のストレージ（近郊ストレージ）に同一時点の状態で、遠隔拠点のストレージ（遠隔ストレージ）に過去時点の状態で常に複製される。

ここで、３拠点ストレージDRシステムは主ストレージ上のデータ３重化の違いによ

(43)

- 42 -

り、マルチターゲット方式、カスケード方式に分類される。図 12にシステム運用中の、

図 13に引き継ぎ処理時の、両システム構成を示す。

マルチターゲット方式は主ストレージのデータを同期リモートレプリケーションと非同期リモートレプリケーションとで複製し、２拠点のストレージに分散配置する方式である。

カスケード方式は主ストレージのデータを同期リモートレプリケーションで近郊ストレージに複製、近郊ストレージが受信したデータをさらに非同期リモートレプリケーションで遠隔ストレージに複製する方式である。

いずれの方式でも３拠点ストレージ DR システムは広域にシステムを分散した構成で、主拠点被災時もデータ損失のない引き継ぎ処理が近郊拠点から可能という、両２重化技術の特徴を併せ持つ。さらに、近郊、遠隔ストレージの両方が動作可能な場合、主ストレージと同一データが格納される近郊ストレージから遠隔ストレージにリモートレプリケーションを再構築できる。これにより、３拠点ストレージDRシステムは近郊拠点での引き継ぎ処理後に再度被災する場合にも高い確度で遠隔拠点からシステムの復旧が可能となる。

また、３拠点ストレージDRシステムでは引き継ぎ処理時に再構築するリモートレプリケーションの再構築時間を短縮する研究、開発がなされている[5] [7] [23] [24]。本論文では、被災後を逃れた拠点のストレージ間で短時間に再構築するリモートレプリケーションを“デルタリモートレプリケーション”とよぶことにする。

(44)

- 43 -

主ホスト

主ストレージ

近郊ホスト

近郊ストレージ

遠隔ホスト

遠隔ストレージ

主拠点

近郊拠点

遠隔拠点

AP 主ホスト

主ストレージ

近郊ホスト

遠隔ホスト

遠隔ストレージ主拠点

近郊拠点

遠隔拠点 AP

カスケード方式マルチターゲット方式

図 12 マルチターゲット方式とカスケード方式のシステム構成（システム運用中）

(45)

- 44 -

主ホスト

主ストレージ

近郊ホスト

遠隔ホスト

近郊拠点

遠隔拠点主ホスト

主ストレージ

近郊ホスト

遠隔ホスト

近郊拠点

遠隔拠点

AP

カスケード方式マルチターゲット方式

災害

AP

図 13 マルチターゲット方式とカスケード方式のシステム構成（引き継ぎ処理時）

3DC-DDR：

以下、本論文では、3拠点ストレージDRシステムとして、著者らが検討するマルチターゲット方式を基にした 3DC-DDR：Three Data Center storage system with Differential Data Resynchronization mechanismを前提に説明する。

図 14に3DC-DDRのシステム構成を示す。

3DC-DDRのシステム構成は、従来のストレージDRシステムを3拠点の計算機シス

テムに拡張した形態をとる。

3DC-DDRでは、システム運用中に主ストレージが近郊、遠隔の両ストレージに、主

ストレージが受信したデータを転送し、近郊、遠隔ストレージが自身のバッファに受信

電気通信大学大学院情報システム学研究科 博士（工学）の学位申請論文

災害復旧向けストレージシステムに関する研究

牧 晋広