Arcserve Replication/ High Availability の仕組み 2019 年 6 月 Arcserve (USA) LLC. All rights reserved.

Transcription

1 Arcserve Replication/ High Availability の仕組み 2019 年 6 月 1 1

2 レプリケーションとは ユーザの更新データをリアルタイムに複製 本番サーバ障害時に切り替え運用ですぐに業務を継続 本番サーバ 複製先サーバ 書き込み 複製 2 Arcserve Replication/High Availability (RHA) はレプリケーションを行うソフトウェアです レプリケーションとは本番サーバ ( マスタサーバ ) にある特定のフォルダやファイルを複製先サーバ ( レプリカサーバ ) に複製する技術です マスタサーバに対する変更 (I/O) をリアルタイムに捕捉し それらをネットワークを介してレプリカサーバに送ります レプリカサーバで同じデータを保持しているので 障害や災害が発生した際にもサーバを切り替えることで業務を継続することができます Arcserve RHA はマスタサーバ上の指定したファイルやアプリケーションデータ あるいはサーバ全体を複製します 2

3 同期とレプリケーションについて 同期 (Synchronization) マスタサーバと同じデータをレプリカサーバに作成 ( レプリケーションの前提フェーズ ) レプリケーション マスタサーバのファイルや DB の変更をリアルタイムにキャプチャし レプリカサーバに転送 2: 変更を都度レプリケーション マスタのデータ 1: 同期でデータのベースラインを揃える レプリカのデータ 3 1) 同期とレプリケーションはそれぞれ異なる処理です レプリケーションは変更処理のみしか複製しないため レプリケーション開始時にはその前処理として同期を行う必要があります 2) 同期中にマスタサーバのレプリケーション対象領域で行われたデータの変更は スプールに蓄積されて同期終了後にレプリカサーバに反映されます 注意 同期の実行中はマスタサーバのパフォーマンスに影響が出る可能性がありますので 同期は極力業務時間やバッチ処理などを避けて行ってください 3

4 同期処理の仕組み ( ファイルレベル同期 ) 4: 差分ファイルの転送と レプリカのみに存在するファイルを削除 * マスタ レプリカ 1: ディレクトリのスキャン 2: シグネチャの作成 3: シグネチャの比較 * デフォルト設定 4 同期の種類 同期には以下の種類があり 複製対象によって使い分けます シナリオによって最適な同期方法がデフォルトで選択されているため 特に理由がない場合には変更する必要はありません ファイルレベル同期 ブロックレベル同期 ボリュームレベル同期 オフライン同期 ファイルレベル同期の処理の流れ STEP1: マスタサーバとレプリカサーバのファイルのスキャンを行います STEP2: スキャンした結果をシグネチャファイルに書き出します STEP3: シグネチャファイルをベースにマスタサーバで比較をします STEP4: 比較した結果 レプリカサーバにのみに存在するファイルは削除し マスタサーバにしかないファイルはレプリカサーバに転送します マスタサーバにもレプリカサーバにも同名のファイルが存在している場合には サイズ と タイムスタンプ ( 更新時間 ) を比較し 違いがあればマスタサーバのファイルで上書きします レプリカサーバがマスタサーバと完全に同じデータを持った状態になったらレプリケーションの運用が始まります 同期時のオプション [ 同一サイズ / タイムスタンプのファイルを無視 ] サイズとタイムスタンプ ( 更新時間 ) が同じファイルは同一とみなし 転送対象としないことで同期の処理時間を短縮するオプションです ファイルサーバなどファイルレベル同期がデフォルト設定となっているシナリオではこのオプションも有効になっています 4

5 同期処理の仕組み ( ブロックレベル同期 ) データベースやメールサーバ 仮想マシンなど 比較的大きいサイズで少量のファイルを同期するときに利用 4: レプリカに必要なデータブロックをマスタサーバに要求し 反映 マスタ レプリカ 1: データのスキャン 2: シグネチャの作成 3: シグネチャの比較 5 処理の流れ STEP1: マスタサーバとレプリカサーバのファイルをブロックレベルで分割してスキャンを行います STEP2: スキャンした結果をシグネチャファイルに書き出します STEP3: シグネチャファイルをベースにレプリカサーバで比較をします STEP4: レプリカサーバは比較した結果 必要だと判断されたデータブロックのみをマスタサーバに転送要求を出します 転送されたデータが反映されます レプリカサーバがマスタサーバと完全に同じデータを持った状態になったらレプリケーションの運用が始まります 大きいサイズのファイルでも必要なブロックのみが転送されるため ネットワークに大きな負荷をかけずにデータを一致させることができます 注意 ファイルサーバなど大量にファイルの存在する環境でブロックレベル同期を利用すると 1 つ 1 つのファイルをブロックレベルで分割してスキャンを行うため同期処理に時間がかかります ファイルサーバの場合にはファイルレベル同期を利用ください 5

6 同期処理の仕組み ( ボリュームレベル同期 ) フルシステムシナリオ (Windows) で初回に同期を実行する際に利用 1 マスタ 仮想アプライアンス 2 1: ボリュームのスナップショット作成 スナップショット 2: スナップショットのデータを転送して仮想ディスクを作成 新規仮想ディスク 1 2 回目以降はブロック同期 ( デフォルト ) 2 マスタが Windows OS で Hyper-V 環境が複製先の場合は Hyper-V ホストを転送先に指定 ( 仮想アプライアンス不要 ) 6 処理の流れ STEP1: マスタサーバで VSS スナップショットを作成 STEP2: スナップショットデータを仮想アプライアンス ( ) に転送して 仮想ディスクを作成 マスタサーバと完全に同じデータを持った仮想ディスクが仮想アプライアンス ( ) に作成されたらレプリケーションの運用が始まります マスタサーバ側のデータと仮想アプライアンス ( ) 側の複製先ディスクにあるデータとの比較処理はありません スナップショットされたマスタサーバのデータを仮想アプライアンス ( ) 側にすべて転送します 注意 フルシステムシナリオの初回同期はボリュームレベル同期がデフォルトですが 差分同期の場合はブロックレベル同期がデフォルトです また Linux 環境のフルシステムシナリオでは ボリュームレベル同期は利用できません ( ブロックレベル同期がデフォルトです ) マスタが Windows OS で Hyper-V 環境が複製先の場合は Hyper-V ホストを転送先に指定 ( フルシステムシナリオについては後述を参照 ) 6

7 同期処理の仕組み ( オフライン同期 ) ネットワークを介さずに WAN 超えの同期を実施 マスタ データ輸送中も変更履歴を作成し レプリカ側のスプールに保持 6: 蓄積された変更データを適用 レプリカ 5: スナッショットと比較 1: VSS スナップショット取得 4: コピー 2: 外部メディアにコピー 3: 輸送 < 参考 > 詳しい手順はブログでも解説中! 7 処理の流れ STEP1: マスタサーバで VSS スナップショットが取得され 自動的にマウントされます STEP2: マウントされたデータをテープや外付け HDD NAS などの外部ディスクに手作業でコピーします STEP3: データがコピーされた外部媒体を輸送します 輸送している間 マスタサーバの変更は捕捉され レプリカサーバに転送された後 レプリカサーバのスプールディレクトリに保存されます STEP4: 外部媒体からレプリカサーバにフォルダ構造を崩さないようにデータをコピーします STEP5: STEP1 で取得した VSS スナップショットとコピーされたデータが比較されます STEP6: データが一致していることが確認できたら レプリカサーバのスプールディレクトリに保存されたデータが反映されます レプリカサーバがマスタサーバと完全に同じデータを持った状態になったらレプリケーションの運用が始まります 7

8 レプリケーションの仕組み 1: 変更の捕捉 Application RHA Engine 4: 変更の転送 RHA Engine Application 5 : リワインドポイント記録 XOMF 2: 変更の書込み Kernel File System 3: 書込みの確認 Storage Kernel 5: 変更の再現 File System Storage マスタサーバレプリカサーバ 8 処理の流れ STEP1: ユーザやデータベースなどのアプリケーション OS などからの書き込みをマスタサーバで稼働する Arcserve RHA のコンポーネント XOMF が捕捉し ジャーナルファイルにその内容を書き出します STEP2: 補足された変更はファイルシステムを介してディスクに書き込まれます STEP3: ディスクからは変更が書き込まれたという確認応答が返ります STEP4: XOMF はディスクからの書き込み確認応答を受け Arcserve RHA エンジン ( エージェント ) を通じてジャーナルファイルをレプリカサーバ ( ) に転送します STEP5: 転送されたジャーナルファイルには どのファイルに どんな内容を どんな順序 で書き込みを行うかが手順書のように記録されています この内容を忠実にレプリカサーバで再現します このようにマスタサーバの変更をレプリカサーバ ( ) で再現することで同じデータを常に維持します 補足 データリワインド 機能を利用している場合には リワインドポイントが記録され レプリカ ( ) のスプールディレクトリに蓄積されます (STEP5 ) リワインドポイントはジャーナルファイルの全く逆の内容を 逆順序で記録します データの巻き戻しが必要な場合にはこのリワインドポイントをデータに適用することでデータが巻き戻ります リワインド機能は主にデータベースなどのアプリケーションシナリオやフルシステムシナリオで利用します フルシステムシナリオの場合は 仮想アプライアンスまたは Hyper-V ホスト (Windows フルシステムシナリオ ) に転送 8

9 Arcserve High Availability スイッチオーバーの仕組み 9 9

10 スイッチオーバーの仕組み Arcserve High Availability の提供する 5 つのリダイレクション方式 IP 移動 マスタサーバの IP アドレスをレプリカサーバに移動 IP で接続している DB サーバなどで利用 コンピュータ名の切り替え レプリカサーバのコンピュータ名をマスタサーバのものに変更ファイルサーバや SQL Server の名前付きパイプ環境で利用 DNS リダイレクト マスタサーバの DNS A レコードの IP アドレスを変更 IIS サーバやファイルサーバなどホスト名接続環境で利用 コンピュータエイリアスの切り替え DNS エイリアス または NetBIOS のエイリアス名を移動業務サーバをエイリアス名で運用できる環境で利用 ユーザ定義スクリプト 既存機能でカバーされていない追加の処理が必要な場合カスタムスクリプトやバッチファイルの起動をサポート 10 5 つのリダイレクションは組み合わせて利用することができます 10

11 IP 移動 STEP1: サービスの停止を検知 STEP3: アプリケーションサービスの起動 マスタサーバ スイッチオーバー前 実運用 IP : 固定 IP : PC レプリカサーバ スイッチオーバー前 固定 IP : スイッチオーバー後 固定 IP : STEP2: マスタ レプリカサーバの IP アドレスを変更 スイッチオーバー後 実運用 IP : 固定 IP : このリダイレクションを利用するシステムの例 IP アドレスを指定してアクセスされるデータベースやファイルサーバなど 処理の流れ STEP1: レプリカサーバがサービスの停止を検知します STEP2: マスタサーバで利用されていた IP アドレスをレプリカサーバのネットワークアダプタ (NIC) に追加します 上記の例ではスイッチオーバー後に実運用 IP アドレスとして利用されている がレプリカサーバに移動し マスタサーバでは競合が起こらないように移動した IP アドレスが削除されます STEP3: レプリカサーバでアプリケーションサービスを起動します ( ファイルサーバの場合には特に何もしません ) 以降 ユーザやアプリケーションが実運用 IP アドレスを指定して通信を行うと レプリカサーバに自動的に接続します シナリオ作成前にあらかじめマスタサーバに固定される IP アドレスを同一のネットワークアダプタ (NIC) に付与しておきます 注意 このリダイレクションはマスタとレプリカが同一ネットワークセグメント内になければ利用ができません 11

12 コンピュータ名の切り替え 1 STEP1: サービスの停止を検知 STEP3: アプリケーションサービスの起動 マスタサーバ スイッチオーバー前 MASTER ( ) PC レプリカサーバ スイッチオーバー前 REPLICA ( ) スイッチオーバー後 MASTER-RHA ( ) STEP2: マスタ レプリカサーバのコンピュータ名を変更 スイッチオーバー後 MASTER ( ) 12 このリダイレクションを利用するシステムの例 コンピュータ名を指定してアクセスされるファイルサーバ 名前付パイプを利用してアクセスされる Microsoft SQL Server 稼働するサーバのコンピュータ名に依存しているアプリケーション など 処理の流れ STEP1: レプリカサーバがサービスの停止を検知します STEP2: レプリカサーバは自分自身のコンピュータ名をマスタサーバのコンピュータ名に変更します 競合が起こらないようマスタサーバには元のコンピュータ名に接尾詞 -RHA を付け変更します STEP3: レプリカサーバでアプリケーションサービスを起動します ( ファイルサーバの場合には特に何もしません ) 以降 ユーザやアプリケーションがマスタサーバのコンピュータ名を指定して通信を行うと レプリカサーバに自動的に接続します 注意 このリダイレクションは 複数のファイルサーバを 1 台のレプリカサーバに向かってレプリケーションする (N 対 1) 構成の場合には利用することができません 複製対象がファイルサーバの場合には コンピュータ名の切り替え 2 をご利用ください 12

13 コンピュータ名の切り替え 2 ~ エイリアスの利用 ~ STEP1: サービスの停止を検知 STEP3: アプリケーションサービスの起動 マスタサーバ スイッチオーバー前 MASTER レプリカサーバ スイッチオーバー前 REPLICA スイッチオーバー後 MASTER-RHA PC STEP2: マスタ レプリカサーバのコンピュータ名を変更 スイッチオーバー後 REPLICA( 実コンピュータ名 ) MASTER( エイリアス ) このリダイレクション方式はファイルサーバシナリオのみサポート 13 このリダイレクションを利用するシステムの例 コンピュータ名を指定してアクセスされるファイルサーバ 処理の流れ STEP1: レプリカサーバがサービスの停止を検知します STEP2: レプリカサーバは自分自身のコンピュータ名を維持したまま マスタサーバのコンピュータ名を エイリアス ( 別名 ) として追加します 複数のマスタサーバがスイッチオーバーした場合には それぞれのマスタサーバをエイリアスとして追加します マスタサーバは競合が起こらないよう元のコンピュータ名に接尾詞 -RHA を付けます 以降 ユーザがマスタサーバのコンピュータ名を指定して通信を行うと レプリカサーバに自動的に接続します 複数のファイルサーバを 1 台のレプリカサーバに複製する (N 対 1) 構成の場合に利用します 注意 この方法はファイルサーバシナリオのみ対応しています 13

14 DNS リダイレクト マスタサーバ MASTER ( ) STEP1: サービスの停止を検知 レプリカサーバ REPLICA ( ) STEP2: A レコードの書き換え STEP3: アプリケーションサービスの起動 スイッチオーバー前 MASTER : REPLICA : PC DNS サーバ スイッチオーバー後 MASTER : REPLICA : このリダイレクションを利用するシステムの例 ( クライアントが DNS を参照して名前解決をしている環境で ) ホスト名を指定してアクセスされるメールサーバ データベースサーバ Web サーバ アプリケーションなど 処理の流れ STEP1: レプリカサーバ ( 1) がサービスの停止を検知します STEP2: レプリカサーバ ( 1) は DNS サーバに対して A レコードの書き換えを要求します DNS サーバは要求に従い マスタサーバのレコードに記載された IP アドレスをレプリカ ( 2) の IP アドレスに書き換えます STEP3: レプリカサーバ ( 2) でアプリケーションサービスを起動します ( ファイルサーバの場合には特に何もしません ) 以降 ユーザやアプリケーションがマスタサーバのホスト名を指定して通信を行うと レプリカサーバ ( 2) に自動的に接続します 1 フルシステムシナリオの場合は 仮想アプライアンスまたは Hyper-V ホスト (Windows フルシステムシナリオ ) 2 フルシステムシナリオの場合は 代替用仮想マシン 14

15 コンピュータエイリアスの切り替え 1 ~ DNS エイリアス (CNAME) レコードの利用 ~ マスタサーバ MASTER ( ) STEP1: サービスの停止を検知 レプリカサーバ REPLICA ( ) SERVER1 STEP2: CNAME レコードの書き換え STEP3: アプリケーションサービスの起動 スイッチオーバー前 SERVER1(CNAME) : MASTER MASTER : REPLICA : PC DNS サーバ スイッチオーバー後 SERVER1(CNAME) : REPLICA MASTER : REPLICA : このリダイレクションを利用するシステムの例 ( クライアントが DNS を参照して名前解決をしている環境の ) ファイルサーバなど 処理の流れ STEP1: レプリカサーバがサービスの停止を検知します STEP2: レプリカサーバは DNS サーバに対して CNANE レコードの書き換えを要求します DNS サーバは要求に従い CNAME レコードに記載された振り替え先のホスト名 ( 例では MASTER) をレプリカのホスト名 ( 例では REPLICA) に書き換えます STEP3: レプリカサーバでアプリケーションサービスを起動します ( ファイルサーバの場合には Server サービスを起動します ) 以降 ユーザやアプリケーションが DNS エイリアスを指定して通信を行うと レプリカサーバに自動的に接続します 1) シナリオ作成前にあらかじめ DNS エイリアス (CNAME) レコードを作成し マスタサーバを振り替え先に指定しておきます 2) NetBIOS 名のエイリアスが登録されている環境では あらかじめ対象のエイリアスも同時に移動 ( コンピュータエイリアスの切り替え 2) させるよう設定します 注意 このリダイレクションはファイルサーバおよび DNS エイリアス (CNAME) レコードを参照して名前解決ができるアプリケーションでのみ利用できます ファイルサーバシナリオ以外で利用する場合は予め対象アプリケーションが DNS エイリアスを指定してサーバに接続できることを確認してください 15

16 コンピュータエイリアスの切り替え 2 ~ NetBIOS 名のエイリアスの利用 ~ STEP1: サービスの停止を検知 STEP3: アプリケーションサービスの起動 マスタサーバ SERVER1 レプリカサーバ スイッチオーバー前 MASTER( 実コンピュータ名 ) SERVER1( エイリアス ) PC スイッチオーバー前 REPLICA スイッチオーバー後 スイッチオーバー後 STEP2: マスタのエイリアスをレ REPLICA( 実コンピュータ名 ) MASTER プリカサーバに移動 SERVER1( エイリアス ) 16 このリダイレクションを利用するシステムの例 NetBIOS 名のエイリアス ( 別名 ) を指定してアクセスされるファイルサーバなど 処理の流れ STEP1: レプリカサーバがサービスの停止を検知します STEP2: レプリカサーバは自分自身のコンピュータ名を維持したまま マスタに登録されていた NetBIOS 名のエイリアスを自身のエイリアスとして追加します 複数のマスタサーバがスイッチオーバーした場合には それぞれに登録されていた NetBIOS 名のエイリアスをレプリカサーバ自身に登録します コンピュータ名の競合が起こらないようにマスタサーバのエイリアスを削除します STEP3: レプリカサーバでアプリケーションサービスを起動します ( ファイルサーバの場合には Server サービスを起動します ) 以降 ユーザがマスタサーバに登録されていたエイリアスを指定して通信を行うと レプリカサーバに自動的に接続します 1) NetBIOS 名のエイリアスを事前に登録しておき サーバの利用者がエイリアスを指定してサーバに接続できるようにしておきます 2) Workgroup など DNS エイリアスを利用していない環境で コンピュータ名を変更することができない環境でも利用できます 3) DNS エイリアスも利用されている環境では あらかじめ DNS エイリアスの書き換え ( コンピュータエイリアスの切り替え 1) も行うよう設定します 注意 このリダイレクションはファイルサーバおよび NetBIOS 名のエイリアスを指定して名前解決ができるアプリケーションでのみ利用できます ファイルサーバシナリオ以外で利用する場合は予め対象アプリケーションが NetBIOS 名のエイリアスを指定してサーバに接続できることを確認してください 16

17 < 参考 > シナリオと利用可能なリダイレクション シナリオ IP 移動 コンピュータ名の切り替え リダイレクション DNS リダイレクト コンピュータエイリアスの切り替え ユーザ定義スクリプト ファイルサーバ 可可可可可 Microsoft SQL Server 可可可可可 Microsoft Exchange Server 可不可可可可 Microsoft IIS Server 可可可可可 Oracle データベース可不可可可可 VMware vcenter Server 可可可可可 Hyper-V シナリオ 不可 不可 可 不可 可 フルシステムシナリオ 不可 不可 可 不可 可 ファイルサーバシナリオではコンピュータ名の切り替えと DNS リダイレクトの組み合わせを推奨 17 注意 1) Microsoft Exchange Server および Oracle データベースはアプリケーションの制限により コンピュータ名の切り替え は利用できません 2) コンピュータエイリアスの切り替え をファイルサーバ以外で利用する際は あらかじめ対象アプリケーションがエイリアスを指定してサーバに接続できることを確認してください 17

18 アプリケーションおよび Hyper-V シナリオの仕組み 18 18

19 データベースのレプリケーションの仕組み トランザクションのコミットタイミングで変更内容を転送 DB 自身がファイルに書き込む 整合性のとれたデータをレプリカへ複製 マスタ ( オンライン ) LAN/WAN レプリカ ( オフライン ) SQL DB SQL DB コミット ファイル変更をブロックレベルで捕捉し レプリケーション チェックポイント Log Data File Log Data File 19 処理の流れ STEP1: マスタサーバでトランザクションのコミットによるログファイルへの変更や チェックポイント等によるデータファイルへの変更を捕捉します STEP2: 捕捉した変更をジャーナルファイルを通じてレプリカサーバへ転送し データファイルに変更を再現します コミットされたタイミングで変更を捕捉しているため データの論理的整合性が保たれています また 書き込み順序も保証されているので マスタサーバで行われたデータにする変更は同じ順序でレプリカサーバのデータに適用されます レプリカサーバのデータベースは停止した ( オフライン ) 状態で同期およびレプリケーションが行われます シナリオ実行時 レプリカサーバでデータベースが起動している場合には自動的に停止します 19

20 Hyper-V シナリオの仕組み 本番サイト リカバリサイト 障害時にはスイッチオーバー * マスタ レプリカ VHDX レプリケーション VHDX Point 1 Point 2 Point 3 システム丸ごとの複製でレプリカに基幹システムの構築不要仮想マシンに導入しているアプリを意識する必要なし必要な仮想マシンだけを選んで災害対策を実現 *Arcserve High Availability 利用時 20 処理の流れ STEP1: マスタサーバの Hyper-V 上で稼働する仮想マシン上の変更は 仮想マシンデータファイル ( 仮想ハードディスクや構成ファイルなど ) に反映されます STEP2: 仮想マシンデータファイルに対する変更を Arcserve RHA が捕捉し複製します レプリカサーバにはマスタサーバと同じ仮想マシンデータファイルが保存されます 対象の仮想マシンもしくはマスタサーバ ( 物理 ) に障害が発生した場合には レプリカサーバで複製していた仮想マシンを立ち上げることで業務を継続することができます 1) レプリケーション実行中はレプリカサーバの Hyper-V マネージャ上に仮想マシンは登録されていません 2) Arcserve High Availability を利用すると スイッチオーバー時にレプリカサーバの Hyper-V マネージャに仮想マシンを登録し 起動まで自動的に行います 注意 Arcserve Replication (DR シナリオ ) のみ利用している場合には 切り替えの際に仮想マシンの登録を手作業で行う必要があります 20

21 [Hyper-V シナリオ ] 仮想マシンの IP アドレス変更 スイッチオーバー後に レプリカ上の仮想マシンの IP アドレスを自動で変更 東京 ( XXX) VM の IP アドレス : WAN 大阪 ( YYY) ON VM の元 IP アドレス : スイッチオーバー VM の新 IP アドレス : 異なるネットワークセグメント環境へのスイッチオーバー時に IP アドレス変更の作業不要 21 処理の流れ STEP1: スイッチオーバーを実行します STEP2: 仮想マシン内の IP アドレスを変更してから仮想マシンを起動します 1)Hyper-V シナリオの設定に切り換え後に利用する IP アドレスは事前に指定しておきます 2) スイッチバックを行うと元に IP アドレスに書き戻します 21

22 [Hyper-V シナリオ ] DNS リダイレクト 仮想マシン IP(VM): マスタサーバ STEP1: サービスの停止を検知 WAN レプリカサーバ 仮想マシン IP(VM): ( xx) ( xx) STEP2: A レコードの書き換え スイッチオーバー前 VM: PC スイッチオーバー後 VM: DNS サーバ 22 このリダイレクションを利用するシステムの例 ( クライアントが DNS を参照して仮想マシンの名前解決をしている環境で ) ホスト名を指定してアクセスされる Hyper-V 上の仮想マシン 処理の流れ STEP1: レプリカサーバがサービスの停止を検知します STEP2; レプリカサーバは DNS サーバに対して仮想マシン用に登録されている A レコードの書き換えを要求します DNS サーバは要求に従い 仮想マシンのレコードに記載された IP アドレスを指定された IP アドレスに書き換えます STEP3: レプリカサーバで仮想マシンを起動します 以降 ユーザやアプリケーションが仮想マシンのホスト名を指定して通信を行うと レプリカサーバ上の仮想マシンに自動的に接続します 1) 仮想マシン内の IP アドレスを自動的に変更する設定 (P20) を行うことで ネットワークセグメントが異なる環境への切り替えにも対応できます 2) 切り替え前と切り替え後に仮想マシンの A レコードに登録する IP アドレスは事前にシナリオに設定しておきます 22

23 フルシステムシナリオの仕組み 23 23

24 フルシステムシナリオとは システム全体( データ / アプリ / Windows または Linux OS) をリアルタイム複製 複製先は仮想環境やクラウドを利用 切り替えは自動または手動で仮想マシンを起動するだけ 本番サーバ データ アプリ 切り替え ( スイッチオーバー ) データ アプリ OS 複製先仮想マシン OS サーバ丸ごと複製 切り替え直前のシステムで 直ぐに業務が再開できる (RTO / RPO の短縮 ) 24 このシナリオを利用するシステムや要件の例 障害があった場合のデータ損出を最小化し 直ぐに業務継続したいシステム 仮想環境やクラウドへの移行作業に手間がかからず 直ぐに切り替えられる環境を用意したい 複製先の仮想マシンは自動で作成されます 予め OS やアプリケーションを導入する仮想マシンを用意する必要無し!! 切り替えは 自動 ( 障害検出後 ) もしくは 手動 ( ボタンをクリック ) か選択できます 無停止テスト を利用して 運用中に何時でも切り替え動作や複製されたデータの確認が可能です 24

25 Windows 環境でのフルシステムシナリオのサーバ構成と仕組み 1 VMware / クラウド (AWS, Azure) 環境に Windows マシンを複製する構成 通常時 障害時 マスタ ( 物理 / 仮想 Windows マシン ) ステータス監視 仮想アプライアンス (Windows VM) RHA エンジン 複製先ディスク マスタ 仮想アプライアンス (Windows VM) 1. 異常検知 2. 代替 VM 作成 & ディスク接続切り替え 代替 VM RHA エンジン リアルタイム複製 VMware or クラウド環境 (AWS, Azure) RHA エンジン VMware or 3. 電源 ON クラウド環境 (AWS, Azure) 25 異常発生時の処理の流れ STEP1: 仮想アプライアンスがステータス異常を検知します STEP2: 代替の仮想マシンを作成し 複製先の仮想ディスクを接続します STEP3: 代替仮想マシンを起動します RHA エンジンの導入先はマスタおよび仮想アプライアンスです ( 複製先ディスクおよび代替 VM は RHA が作成 ) 異常発生時に STEP1. ~ 3. の処理を自動実行 もしくは手動で切り替えを実行できます ライセンスはマスタと仮想アプライアンスの台数のみ ( 代替 VM 分は不要 ) 補足 ステータス監視は PING 以外に特定サービスの指定も可能です 切り替え時に代替 VM の IP アドレスを変更できます 複数のマスタと仮想アプライアンスの N 対 1 構成が可能です 25

26 Windows 環境でのフルシステムシナリオのサーバ構成と仕組み 2 Hyper-V 環境に Windows マシンを複製する構成 通常時 障害時 マスタ ( 物理 / 仮想 Windows マシン ) RHA エンジン 複製先ディスク 代替 VM 3. 電源 ON リアルタイム複製 マスタ ステータス監視 RHA エンジン Hyper-V ホスト 1. 異常検知 RHA エンジン Hyper-V ホスト 2. 代替 VM 作成 & ディスク接続切り替え 26 異常発生時の処理の流れ STEP1: Hyper-V ホストの RHA エンジンがステータス異常を検知します STEP2: 代替の仮想マシンを作成し 複製先の仮想ディスクを接続します STEP3: 代替仮想マシンを起動します RHA エンジンの導入先はマスタおよび Hyper-V ホストです ( 複製先ディスクおよび代替 VM は RHA が作成 ) 異常発生時に STEP1. ~ 3. の処理を自動実行 もしくは手動で切り替えを実行できます ライセンスはマスタと Hyper-V ホストの台数のみ ( 代替 VM 分は不要 ) 補足 ステータス監視は PING 以外に特定サービスの指定も可 切り替え時に代替 VM の IP アドレスの変更が可能 複数のマスタと Hyper-V ホストの N 対 1 構成が可能 26

27 Linux 環境でのフルシステムシナリオのサーバ構成と仕組み VMware / Hyper-V / クラウド (AWS, Azure) 環境に Linux マシンを複製する構成 通常時 障害時 マスタ ( 物理 / 仮想 Linux マシン ) ステータス監視 仮想アプライアンス (Linux VM) RHA エンジン 複製先ディスク マスタ 仮想アプライアンス (Linux VM) 1. 異常検知 2. 代替 VM 作成 & ディスク接続切り替え 代替 VM RHA エンジン リアルタイム複製 VMware or クラウド環境 (AWS, Azure) RHA エンジン VMware or 3. 電源 ON クラウド環境 (AWS, Azure) 27 異常発生時の処理の流れ STEP1: 仮想アプライアンスがステータス異常を検知します STEP2: 代替の仮想マシンを作成し 複製先の仮想ディスクを接続します STEP3: 代替仮想マシンを起動します RHA エンジンの導入先はマスタおよび仮想アプライアンスです ( 複製先ディスクおよび代替 VM は RHA が作成 ) 異常発生時に STEP1. ~ 3. の処理を自動実行 もしくは手動で切り替えを実行できます ライセンスはマスタと仮想アプライアンスの台数のみ ( 代替 VM 分は不要 ) 補足 ステータス監視は PING を利用 切り替え時に代替 VM の IP アドレスの変更が可能 複数のマスタと仮想アプライアンスの N 対 1 構成が可能 コントロールサービスは Windows サーバに導入 (Windows 用のシナリオと混在可 ) 27

28 参考 : Arcserve Replication と Arcserve High Availability の違い 28 28

29 自動切換えができると作業負荷が減る! Arcserve Replication 接続先変更は利用者で実施 Arcserve High Availability 接続先を自動切り替え サービス自動開始 こっち使って! 複製先へ自動誘導!? やり方がわからない 自分で変えるのね 面倒だなぁ 普段と同じ操作 29 解説 Arcserve Replication を使用している場合には サーバ管理者は障害が起きたことやレプリカサーバへの接続方法をユーザに通知します それを受けて ユーザはレプリカサーバへ接続先を変更します Arcserve High Availability を利用すると管理者はユーザへの通達などを行う必要がなくなり ユーザはこれまで通りの接続方法で自動的にレプリカサーバにアクセスできるため 管理者 ユーザ共に作業負荷が減ります 29