Sybase WarmStandby System
0.改訂履歴
- 2003.04.23 新規作成
1.はじめに
このドキュメントでは,Sybase ASEとReplication Serverを使ったウォームスタンバイサーバの概略について説明する.
2.Sybasのウォームスタンバイ
- Sybase社の製品のReplication Serverを使った応用システム.
- データベースの更新内容を待機系サーバに転送し反映させ,「ほぼ同じ状態のコピーシステム」を作成する.
- 稼働系と待機系がそれぞれ1対1でクラスタ(収束)されている高可用性システム.
- 「1対多」などの構成は対応していない.
- クラスタについてはドキュメント「クラスタサーバ」を参照.
- Sybaseのウォームスタンバイシステムはこのドキュメントの「3.3.相互切り替え方式」に近い.
- クラスタについてはドキュメント「クラスタサーバ」を参照.
- IPアドレスを引き継ぐなどの仕組みはない.
- レプリケーションの方向は1方向(Active to Standby)である.
- 自動でActiveとStandbyが切り替わることはないが,コマンド1つで切り替わる.
3.システム構成概略について
- 簡単に図に書くと次の通り.
- Adaptive Server Enterprise(いわゆるSybaseというデータベースの事. 以降ASE)からReplication Server(以降Rep)にデータが転送され,それがさらにStandbyのASEに転送される.
4.システム構成考察
4.1.サイベース社推奨構成
- ASE-Rep-ASEの構成を行う時,サイベース社では次のようなハードウェア構成を推奨している.
- それぞれのコンポーネントが独立して稼働することによって,パフォーマンスと対障害性に強くなる.
- しかし,実際には絵には描いていないが,Repのデータを管理するために3号機でもASEが必要となり,ライセンス的に高額になる.
4.2.アクティブ側のデータベースにRepを搭載
- システムをサーバ2台で構成する.
- Repを,1号機(アクティブ)に載せる場合には次のようなイメージになる.
- Repが稼働している分だけ,アクティブのASEのパフォーマンスがダウンする.
- この時,サイベース社はそれぞれにCPUを割り当てるために,2CPU構成を推奨している.
- するとASEとRepでそれぞれ2CPUライセンス必要となるのでライセンス料は倍となり高額.
- Repのステーブルデバイス(キュー)のディスクI/Oが発生するので,パフォーマンスがダウンする.
- 1号機でRepに障害が発生した場合は,アクティブのASEが影響を受けてサービスが停止することも考えられる.
4.3.スタンバイ側のデータベースにRepを搭載
- システムをサーバ2台で構成する.
- Repを,2号機(スタンバイ)に載せる場合には次のようなイメージになる.
- 1号機では,アクティブのASEの処理に専念しておけばよいので,パフォーマンスに影響のある事はない.
- Repの故障があっても,1号機のASEには影響がない.
- この構成が一番現実的だと考えている.
5.動作の概略
- ここでは,ASEによるウォームスタンバイシステムがどのような順序で動作していくかを見ていく.
- まず,次のようなデータベースがある.
- 通常のASEでは,データ格納用セグメントと,トランザクションログ格納用セグメントがある.
- データが更新される.
- トランザクションログがlogsegmentに格納される.
- Repが稼働しているシステムでは,ASEの中にRepAgentというスレッドがいる.
- そのRepAgentが,定期的にトランザクションログを吸い出す.
- RepAgentは,吸い出したトランザクションデータを,Repに転送する.
- 転送されたデータは,Repの情報を管理する為のASE上に作成されたRSSDというデータベース上に格納される.
- RDDSに格納されたデータは,「ステーブルデバイス」というキューに格納される.
- 不揮発性のキュー領域. データベースとは違う.
- ステーブルデバイスに入った者は,スタンバイ用のASEに順次転送されていく.
- 転送されたデータが,反映される.
6.全体図
- ワシが考えた,費用対コストを考えた推奨システム構成と,動作内容を整理すると次のようなイメージとなる.
- アクティブとスタンバイを切り替えると,流れが逆になる.
- その時に,スタンバイで稼働しているRepAgentがOnになったりする.
- データベースのバックアップも,普段はスタンバイ側で行っていればよい.