Comments
Description
Transcript
某金融機関向け ITBCP対策におけるデータ同期方式
某金融機関向け ITBCP 対策におけるデータ同期方式 松本 健太郎＊ 森垣 努＊ 高篠 智晴＊ 細川 智洋＊ 山路 晃徳＊ IT BCP data synchronous method of a certain finance company 要 旨 東日本大震災以降，各企業にて事業継続/災害対策が急務 社も含めたシステムを対象としている。エンドユーザーへの となっている。三菱電機インフォメーションシステムズ㈱ 影響やアプリケーション改修による工数増をさけるため， (MDIS)の顧客である某金融機関においても，一部業務に対す BCP サイト（以下災対サイト）のサーバは，関東データセン る BCP(Business Continuity Planning)対策を実施しており， ター（以下本番サイト）のホスト名，IP アドレス等の固有値 首都圏直下型地震の災害による電源供給断等のインフラ途 をそのまま引き継ぐ構成とした。また，既存環境への変更を 絶，データセンター倒壊にて，基幹システムの復旧に１ヶ月 加えないように構築を行うこととなったが，多種多様なシス 以上を要する事態となった場合を想定し，基幹システムにつ テムが対象となっているため，各システム，サーバに合わせ いても 2 重化を行うこととなった。全体の推進，構築は，基 た RPO(Recovery Point Objective)の設定やデータ同期設計 幹系，情報系のインフラ全般にかかわっている MDIS が中心 が必要であった。そこで当案件では，IBM 社の SVC（IBM System となって実施する。 Storage（注 3) SAN Volume Controller)と VMWare(注 4)SRM(VMware 対象システムは基幹システムと基幹システムの稼働に必 要となる周辺システム計 10 システム（UNIX(注 1)系サーバ：約 vCenter(注 4) Site Recovery Manager(注 4)）を利用した同期方 式を採用することで対応した。 (注 2) 15 台，Windows 系サーバ：約 150 台）で，グループ会 災対サイト 本番サイト ストレージ環境 ストレージ環境 データ同期 FC-IP 変換装置 FC-IP 変換装置 SVC 物理Windows サーバ群 VMWareにて仮想化された Windowsサーバ群 SVC データ同期回線 UNIX系サーバ群 物理Windows サーバ群 BCP発令時に 接続 VMWareにて仮想化された Windowsサーバ群 UNIX系サーバ群 ゲートウェイ環境 広域イーサ網 平常時の メンテナンスに使用 各支店／関連会社（既設回線） 基幹システムデータ同期方式 IBM 社製品の SVC の機能にて非同期でデータ連携を行う。災害発生時にはネットワークの切替えにてセンターの切替えとシステム復旧を行う。 平常時の災対サイトメンテナンスはゲートウェイ環境を経由して行うこととする。 (注 1)UNIX は，X/Open Company Limited の登録商標または商標である。 (注 2)Windows は，米国およびその他の国における Microsoft Corporation および/またはその関連会社の登録商標または商標である。 (注 3)System Storage は，ＩＢＭ社の，米国およびその他の国における商標である。 (注 4)VMware，vCenter，Site Recovery Manager，vSphere は，VMware， Inc.の米国および各国での登録商標または商標である。 *三菱電機インフォメーションシステムズ（株） １． ま え が RPO の定義について，システムを構成するサーバによって， き データの更新頻度が異なる点に着目して設計を行った。対象 東日本大震災以降，MDIS の顧客である某金融機関において も，首都圏直下型地震の災害による電源供給断等のインフラ サーバは，更新頻度・周期別に以下の 3 種類に分類した。 ① オンライン，夜間処理中にデータ更新が行われるもの 途絶，データセンター倒壊等を想定し，基幹システムの 2 重 ② 夜間処理中にのみデータ更新が行われるもの 化を行うこととなった。MDIS は，既存の基幹システム構築時， ③ 不定期にデータ更新が行われるもの SIer(System Integrator)としてインフラ全般の設計・構築 ①でオンライン中に被災した場合，1 時間前の状態に復旧 を担当し，また，当基幹システムの構築後から現在に至るま することとするが，①の夜間処理中または，②においては， で，客先のインフラ全般の運用・保守を委託されており，基 夜間処理にて更新されるデータ量が非常に多いため，夜間処 幹システムについての運用ノウハウが多く蓄積されている。 理中のデータ同期は行わず，夜間処理開始前，夜間処理完了 さらに，基幹系・情報系のシステムの運用・保守に加え，端 後に RPO を設定した。③は主に管理系のシステムで不定期に 末管理，ヘルプデスクまで広く顧客の業務に携わっているこ 手動での更新が発生するものであるため，更新時に手動での とから，当案件においては，同じく SIer として，他ベンダ データ反映を行う運用を検討したが，手順漏れによりデータ ーをも取り纏める立場で，全体の推進を行うこととなった。 反映が行えない場合のリスクを考慮し，1 日 1 回データ同期 本システムの利用環境に関しては，既に客先で一部システ を行い，RPO を 1 日前と設定した。 ムの災対サイトとして利用している西日本のデータセンタ ーを使用することとなっており，このような背景の中，当プ ロジェクト推進にあたり，最も苦労したポイントは以下 4 点 である。 2.1.2 被災時間帯別の RPO について オンライン中に被災した場合は 1 時間前の状態へ復旧する こととなっていたが，夜間処理時間帯に切替えが行われた場 ① 多種多様なシステムに合わせた RPO の設定 合は，災対サイトでの復旧後，夜間処理をはじめからやり直 ② 既存環境への変更を抑えた構築方針の策定 す運用としたため，夜間処理前の状態に復旧することとした。 ③ データ更新量と必要回線速度の見極め また，オンライン開始時点で被災した場合は，夜間処理にて ④ 基盤に合わせた統一的なデータ同期方式の設計 更新された状態まで復旧することを要件とした（図１）。 本稿では，これらの課題を踏まえた IT インフラ BCP 対策シ ステムの構築について述べる。 ２． 要件定義 2.1 RPO・RTO について ITBCP の構築においては，目標とする復旧地点である RPO の設定と復旧にかかる時間の目標値である RTO(Recovery Time Objective) の設定が最も重要な部分であり，実現性を 評価しながら慎重に設計を進めていく必要がある。RTO につ いては客先の業務要件を考慮したうえで，対象システムすべ てに対して共通で 5 時間と設定した。一方，RPO については， 図１．RPO について 当案件の対象が基幹系システムとその他周辺システムで， BCP の対象が複数システムであることを考慮して設定を行う 必要があったため，業務時間帯によって異なる値を設定する こととした。例えば，オンライン中は１時間前の状態に復旧 させるが，夜間のオンライン時間外は，対象サーバのデータ 更新頻度等によって要件が異なる RPO 値を設定した。なぜな ら，夜間処理におけるデータ更新量が非常に多く，オンライ ンと同じ RPO を設定した場合，必要なデータを時間内に反映 できなくなってしまうおそれがあるためである。 以降，具体的に実施した“多種多様なシステムに合わせた RPO の設定”について述べる。 2.2 既存環境への変更を抑えた災対サイト構築方針 業務アプリケーションについては，BCP 対象となりうる範 疇が広く，また複数他社のベンダーにて構築・管理されてい る。 これにより，本番環境への変更を加えた場合，エンドユー ザーへの影響を極小化する意味でも， 「既存システムへの 変更は行わない」という方針は客先からの重要な要求であっ た。そのため，災対サイトに構築するサーバのホスト名，IP アドレス等の固有値を変更した場合の，アプリケーションへ の影響範囲を見極めることが重要であったが，そもそも IP アドレスを変更してしまうことで，エンドユーザーの利用に 2.1.1 システム単位別の RPO について も影響が出てしまう恐れがあったため，災対サイトに構築す るシステムは，ホスト名，IP アドレス共に変更せず，本番サ イトのサーバと全く同じ構成のサーバを構築することとし り，以下 2 つの要件を満足し，かつ統一的な同期方式を採用 た。その際，同一ネットワーク上で IP アドレスが重複する する必要があった。 ことにより問題が発生しないように，平常運用時は災対サイ ・システム，サーバ毎に異なる RPO を満たす トに設置するルーターのネットワークケーブルを抜線して ・原則，既存環境への変更を加えない おき，BCP 発動時に接続する運用とした。災対サイトでの訓 そこで，各サーバが利用しているストレージの機能によるデ 練，平常時のメンテナンスを考慮し，一部対処済み BCP にて ータ同期方式と IBM 社の SVC（IBM 構築された環境のネットワークを流用し，ゲートウェイ環境 Volume Controller)を利用したデータ同期方式についての検 を構築することとした（図２）。 討を行ったが，使用しているストレージに左右されないとい うメリットを考慮し，SVC を利用したデータ同期方式を採用 NW監視用 回線 データ連携用 LAN L3SW データ連携用 回線 データ連携用 LAN GateWay環境 基幹系システム（災対環境） バックボーンSW バックボーンSW ルータ ルータ ルータ た。 災対環境用 ネットワーク 基幹システム（災対環境） メンテナンスのため バックボーンSW バックボーンSW ルータ ルータ 切替え時の手順によりデータの最新化が行えるよう対応し L3SW GateWay環境用 ネットワーク 基幹系システム した。なお，SVC の管理下にないサーバについては，運用， 災対サイト センター間データ連携用 ネットワーク 本番サイト ルータ System Storage SAN ルータ ルータ L2SW ルータ ルータ ルータ 同一IPのため 同一IPのため 平常時未接続 平常時未接続 メイン系 広域イーサ網 バックアップ系 広域イーサ網 ルータ SVC を利用したデータ同期の実装にあたり，対象サーバを 以下の 3 つに分け，サーバ毎に災対サイトへ反映が必要なデ ータを洗い出し，それらの反映方法について検討を行った。 ① UNIX 系サーバ ② VMWare にて仮想化されている Windows 系サーバ ③ Windows 系サーバ ルータ 拠点 図 2．災対サイト構築方式 以降，上記グループごとに行った同期対象データの洗い出し と同期方式について紹介する。 2.3 データ更新量とデータ同期用回線について 当案件にて構築するシステムはデータ更新量が非常に多 く，データ同期を行うにあたり，回線帯域不足が懸念された。 そこで RPO を満足する仕組みを構築するため，データ同期の 3.2 UNIX 基盤におけるデータ同期方式 災対サイトの UNIX 系システムにおける同期対象データの 洗い出し，データ同期方式の検討内容を述べる。 シミュレーションを行った。対象は，更新量の多い UNIX 系 当案件の対象となっている UNIX 系サーバはローカルディ システムとし，オンライン中に更新されたデータを規定時間 スクと SVC 管理下のストレージにて構成されている。SVC 管 内に送信完了できるかについて，以下によりシミュレーショ 理下のストレージに保存されているデータは，SVC の機能に ンを実施した（表１）。 より災対サイト側への反映が行えるため，それ以外のローカ ① 各サーバのオンライン時間帯の最大更新量の調査 ルディスクに保存されているデータについてのみ，同期要否 ② １時間あたりに伝送可能なデータ量の算出 と同期方法の検討を行った。 上記の結果から，１ Gbps のデータ同期用回線の 6 割を割 り当てれば効率的に同期を行えることが確認できた。 表１．サーバ毎のデータ更新量の必要回線帯域 ローカルディスクは主にシステム領域とアプリケーショ ンのインストールディレクトリとして利用されており，各デ ータの更新頻度は低いものがほとんどであった。また UNIX 系サーバは切替え作業時間短縮のため，通常時から起動して おく方針としていた。そこで，UNIX 系サーバのローカルディ スクに保存されているデータについては，ゲートウェイ環境 経由で災対サイトの対象サーバにアクセスし，手動にて更新 を反映する運用とした。 UNIX 系システムにおけるデータ同期方式は，データ書き込 みの確実性からリモートコピー方式の中でも MetroMirror が 最有力候補であった。しかし，その仕組みから，遠隔地への 同期を行った場合に性能劣化が懸念され，本番環境の業務へ 影響が出る恐れがあること，また，複数のサーバの同期を同 一タイミングで行うことができないといったデメリットが ３． ITBCP 同期設計 3.1 ストレージ構成とデータ同期方式 前述の通り，災対サイトとのデータ同期方式の検討にあた あった。そこで，本番サイトの対象ボリュームから FlashCopy(注 5)にて取得したボリュームについて MetroMirror を利用して同期を行うことで本番環境業務の性能劣化を回 避し，複数サーバの同期タイミングを揃えたデータ同期が行 象サーバの静止状態のデータを取得できる FCM(IBM Tivoli える仕組みを採用した。また，同期対象データが非常に大き (注 5) いため，MetroMirror 間の同期に FC/IP(Fibre Channel Over へ新規導入した。FCM を用いたバックアップを災対サイト IP)変換装置を採用し，同期データの圧縮と合わせて伝送速 へ送信しておき，万が一，そのバックアップからリストア 度の向上を図った（図３）。 する運用とした。（図４） 本番サイト Storage FlashCopy Manager for VMware)を本番サイト ４． む 災対サイト す び 災対サイトを構築する場合， 「顧客の業務継続性維持」， 「最低限，保持すべきリソースは何か」という視点から顧 SVC SVC 客の業務運用を考慮した上でシステム要件を決定していく Metro Mirror プロセスが必要となる。また，システム的にはできるだけ ストレージ ストレージ 既存環境に変更を加えず，さらに既存システムへの影響を 本番兼 訓練用 DISK 整った断面を取得 本番サーバ FlashCopy 利用領域 転送用 DISK FlashCopy 受信用 DISK Metro Mirror 災対用 DISK 同期を止めずに 訓練の実施が可能 最小限に留めるように設計・構築を行うことが重要となる。 本事例では以下を紹介した。 ・既存システムへの影響を最低限に抑えた災対サイト 構築方針の検討 ・既存システムに適したデータ同期方式の検討 図 3．UNIX 基盤のデータ同期方式 ・データ転送シミュレーション データ同期方式の検討では，原則既存環境を変更できない 3.3 Windows 基盤におけるデータ同期方式 という制約があったが，基幹システムが利用している SVC を 当案件で構築する Windows 系サーバには，VMWare にて仮想 化されている Windows 系サーバ，物理 Windows 系サーバの 2 種類があった。その中で災対サイトへデータの反映が必要な ものは，VMWare にて仮想化されている Windows 系サーバであ り，かつ SVC 管理下のストレージにデータが保存されている もののみであった。統一的な復旧方式を採用し復旧手順を簡 易化するため，VMWareSRM による復旧方式を採用した。SVC の機能によるデータ同期方式を採用し，VMWare SRM を利用す る場合は，Global Mirror with ChangeVolume というデータ 同期方式で同期環境を構成する必要があった。 本番サイト vCenter Server VM VM 災対サイト Site Recovery Manager VM VM VM VM VM VM ストレージ 本番サイト FCMによる イメージの取得 VM FlashCopy (SNAPSHOT) 更新差分 更新差分 リカバリー用データの同期 Metro Mirror 低減も実現することができた。 災対サイトは，今後さらに一般化し，より低コスト，短期 間で構築できるようにするためのノウハウの蓄積，システム 構築プロセスの汎用化が求められるため，今回検討した内容 がおおいに役に立つと考える。また，本プロジェクトのスコ ープは災対サイトの構築であったが，バックアップや準本番 環境としての利用等，リソースの有効利用という活用方法も である。今回運用負荷，運用コストの低減も加味した構築を SVC 行ったが，運用保守を任されているベンダーとして，システ ストレージ ム構築だけにとどまらず，運用改善，コストの低減を行って 訓練用領域 業務用領域 いく。 FlashCopy Global Mirror with Change Volume FlashCopy (SNAPSHOT) 本番サイトと同じものとすることで運用負荷，運用コストの く。BCP 策定時に最も重要視されているコストは運用コスト VM 災対サイト VMWareによる復旧用のデータ同期 本番サーバ 利用領域 VM Site Recovery Manager vSphere SVC させることができた。さらに災対サイトに構築するサーバを 考えられ，今後は，これらも踏まえた提案，構築を行ってい vCenter Server vSphere 利用したデータ同期方式を採用することで，客先要件を満足 今回はデータセンターの被災というリスクに対する対策 問題発生時、 リストア実施 を行ったが，セキュリティリスク等，世の中には他にも多く FlashCopy のリスクが存在する。今後も，運用・保守を通してさらなる 改善を行い，客先システムをより良いものにしていくととも 図 4．VMWare 基盤のデータ同期方式 しかし，Global Mirror with ChangeVolume によるデー に，被災以外のリスクを踏まえた BCP 対策ソリューションの 提供を行っていく所存である。 タ同期方式ではクラッシュ・コンシステンシーレベルの整 合性しか担保されておらず，アプリケーションの稼働を保 障することができなかった。そこで，VMWareSRM にて復旧 できなかった場合の対策として，Global Mirror with ChangeVolume の同期周期と合わせて，オンライン中でも対 （注 5） FlashCopy，Tivoli は, ＩＢＭ社の，米国およびその他の国 における商標である。