それ、レプリケーションでよろしく。UDPともども。

こんにちは、ホテです。

今日はARCserve High Availabilityを使っている方に覚えておいていただきたい、
スイッチオーバー後の「非アクティブ化」についてお話しします。

ARCserve High Availability のリダイレクション方式はいくつかありますが、
ここでは「IP移動」を例にご説明します。

マサオミです。   
今週のTech Tuesdayを始めたいと思います。

気が付いたらかなりの長期連載になってしまった   
ARCserve RHA r16 新機能紹介シリーズですが    
本日は「レプリケーション用IPアドレスと管理IPアドレスの設定」を    
ご説明したいと思います。 

======== r16 新機能目次 ========

① クラウド環境（Amazon EC2）へのレプリケーション その1 その2    
② レプリケーション中の通信の暗号化機能 その1 その2    
③ カスタムアプリケーション保護機能強化 その1 その2    
④ シナリオ実行中のプロパティ変更    
⑤ レプリケーション用IPアドレスと管理用IPアドレスの設定 （←本日はここ）   
⑥ その他改良および修正点 

==============================

この機能を説明する前にARCserve RHAの主要コンポーネント「コントロールサービス」と   
「エンジン」についておさらいしたいと思います。このコンポーネントを理解していないと    
説明の意味がわからなくなってしまうかと思いますので･･･。

ARCserve RHA コントロール サービス      
シナリオの作成や稼働状況の確認など、レプリケーションの管理に必要なサービスです。
マスタおよびレプリカサーバとTCP/IPで通信が可能なサーバに最低1台インストールします。

※コントロールサービスについては以下のブログ記事も参考になると思います。 
コントロールサービスって何なのさ

ARCserve RHA エンジン      
レプリケーションを実行するコンポーネントです。マスタ サーバ（レプリケーション元）、   
レプリカ サーバ（レプリケーション先）の双方にインストールします。

では、今回追加された「レプリケーション用IPアドレスと管理IPアドレスの設定」とは何か。

こんにちは、ホテです。

これ、何のグラフだかわかりますか？

答えは仮想マシンの台数と必要なARCserve Replicationの仮想専用ライセンスの費用を表したグラフです。何故こんなグラフを作成したかというと、先日こんな質問をいただいたからです。

【質問】
VMware HA で冗長化した仮想マシンにARCserve Replication を導入する予定です。 ライセンスをゲストOSごとに購入するのとホストサーバ単位で購入するのとでは、 どちらが安くなるのでしょうか？ 

そこで、それを確認するために上記のグラフを作ってみたわけです。

マサオミです。   
東京は今日久しぶりに10度を越えたそうです。   
大分暖かくなってきましたね。寒いのが苦手な私からすると   
非常にありがたいことです。

さて本日のTech Tuesdayは「④ シナリオ実行中のプロパティ変更」の内容を   
解説させていただこうと思います。 

======== r16 新機能目次 ========

① クラウド環境（Amazon EC2）へのレプリケーション その1 その2   
② レプリケーション中の通信の暗号化機能 その1 その2   
③ カスタムアプリケーション保護機能強化 その1 その2   
④ シナリオ実行中のプロパティ変更 （←本日はここ）   
⑤ レプリケーション用IPアドレスと管理用IPアドレスの設定   
⑥ その他改良および修正点 

==============================

ARCserve RHAのプロパティはシナリオを停止しなければ   
変更することができない、というのがr15までの仕様でした。 

しかし、ちょっとした変更をしたいと思っても、その都度シナリオを   
停止しなければならないとなると、非常に億劫になります。   
と、いうのもシナリオを停止すれば、次回シナリオを開始する際に   
「同期」を行わなければならないからです。

通知先のメールアドレスを間違えてしまった、   
帯域制御を設定したが制限値をもう少し緩くしたい、   
という状況になったときに、何とかシナリオを止めずに   
設定を変更できないものか、とよくご相談をいただいておりました。 

お待たせいたしました。r16でようやく実現されました！

Koichiです。

最近の傾向として、「リアルタイムでデータを複製し、障害直前までのデータを保護したい」からさらに一歩進んだ対策が注目されてきているようです。

その一歩進んだ対策とは、「障害発生時の自動サーバ切替により、復旧作業から手作業を極力省きミスを減らすことで、安全確実な業務の継続を実現したい」というものです。

たしかに、サーバ（マスタ側）に障害が発生した際に、別のサーバ（レプリカ側）にデータがまるごと複製されて残っていれば、データ自体がなくなるという最悪な事態は防げます。

ただ、業務を止めないという点でいうと、データを複製してある代替サーバへ切り替えてスグに使える状態にしておくことが重要です。

その作業を、マニュアルを確認しながら人が行うという場合は、どうしてもスピードが遅くなりますし、ミスが発生する可能性もあります。また、ユーザへアクセスするサーバを変えて使うよう誘導するといことは IT スキルの高さにもよりますが、混乱が生じるおそれもあります。