#odc16 Essence of Maximum Availability Architecture @Oracle Database Connect 2016まとめ
「Oracle Database」のエンジニアを対象にデータベース運用のためのテクニックなどに関するノウハウを紹介するイベントOracle Database Connect 2016に参加してきました。
その時のMAAについてのセッションのまとめです。
オラクルコーポレーション
High Availabilityテクノロジー バイスプレジデント
ウェイ・フー (Wei Hu)様
MAAの標準アーキテクチャ
- 今まではRACだったが、最近ではActiveDataGuardで構築され、GoldenGateで結ばれる事が多い
データ障害は発生しうる
- 複雑なシステムによりデータ破損は不可避に
- ディスクドライブには既知の問題がある
- ディスクがデータにたいして悪いこと（Corrupted WriteやLost Write）をするのが問題
- ソフトウェアであればバグはつきものだが、これらの問題によるビジネスへの影響は大きい
- 海外大手オンラインバンキングが2日停止したりした
- 政府機関は何が起こったかを公表した
- バージニア州で5日間 SANが停止
- EMCのストレージアレイでファームウェアの問題があり、障害が起こった
- 27の政府機関が影響を受けた
- ビジネスの影響は自然災害よりも大変な場合がある
- DataGuardによるデータ保護は自然災害に 対する対策だけではない
データ保護の要件
- データのコピーを複数持つ
- 1つのところで破損があってもデータを失わないようにする
- コピーに変更を加える際には厳密なチェックが行えるインターフェースを経由すること
- 問題が発生した場合にはフォールバックで迅速に回復
最適化されたデータ保護
- 2つのバージョンを比較して一貫性を確認する方法がデータ保護の基本アプローチ
- ストレージはビットパターンだけをみることしかできないが、Oracleはブロックの中もみれるので正しい方を選択できる
Oracle Active Data Guard
- redoが書かれた内容をActive Data Guardのスタンバイデータベースに非同期で送る
- ActiveDataGuardがリアルタイムのデータのクエリを可能に
- スタンバイデータベースからプライマリのデータベースのブロックを修復もできる
データ保護の内部
- ストレージレプリケーションはビットをコピーするが、プライマリデータが破損したらレプリカにも破損したものも伝搬してしまう
- ActiveDataGuardはRedoベースのレプリケーションなので、スタンバイ側で、一貫性がないというのを判断して伝搬された時点で破損を防ぐことが可能
MAAはActive-Active
- Active/Activeの原則にのっとている
- ActiveDataGuardのスタンバイデータベースも本番データベースと同期しながら同時に検索ができる
- 従来の可用性技術ではアイドル・スペアが必要だが、アクティブパッシブなアーキテクチャは使っていないハードウェアやソフトウェアを買わないといけない
- 必要な時にバックアップシステムが動くかどうかがわからないため、災害対策サイトを使うことをためらってしまう
Flashbackテクノロジー
- OracleDatabaseの巻き戻しボタンのようなもの
- テーブルの変更やDBの巻き戻し、エラーの調査、トランザクションを取り消したりなどができる
RMAN
- 12cではrecover tableコマンドでテーブル一つ戻すことができるようになりました
性能影響が少なくしたいがデータロスは無くしたい
- 長距離レプリケーションの性能影響の懸念がある
- 非同期で送る方法が考えられるが、災害発生時にいくらかのデータロスは発生する
- 12cではFar syncという機能を使うと、Far syncインスタンス（制御ファイルとログファイルだけのインスタンスでDBファイルは不要。転送時の圧縮をオフロードする）を経由して非同期でスタンバイサイトに書き込みを行う
- Far syncインスタンスには同期でログを送る
Global Data Services
- データベースへのロードバランサに関してはGlobalDataServicesを使う
- 複数のRAC、非RACDBにまたがって動作が可能
- Golden gateのactive/activeはリクエストのロードバランスを行うが、負荷が低い方にアクセスをふることもできる
計画停止のオプション
- メンテナンス性や計画停止にも使えるのではないかと思っている
- 例えばパッチセットをスタンバイにあてて、動かしてみてパフォーマンス、パッチに問題がないかを予め確認できたら、プライマリに適用するといったこともできる
- ただし、メジャーリリースではできない
- それにたいしてはTransient Logicalローリングアップグレードを行う
- お客様はパッチ適用に時間がかかることに不安をもっているが、Oracle Cloudでもパッチを行うことをしている
Oracle GoldenGate
- ロジカルレベルでのレプリケーション
- DataGuardは物理的なレプリケーション
- 異機種間でもレプリケーションができる
- ActiveDataGuardは非計画停止への対策に最適
- 本番とスタンバイはSCNのレベルで同じなので、データ破損やLostWriteの検知に有効
- AutomaticBlockRepairや、スタンバイからのバックアップを本番環境にも適用できる
- GoldenGateは計画停止の対策に最適
- GoldenGateのレプリカは物理的には同じではない
- SQLレベルでのレプリケーション
- プライマリとセカンダリのブロックは決して同じではないが、アップグレードのようなバージョンが違うものに対してパッチをあてたりするときなどには最適
顧客事例
アメリカ銀行の事例
- いくつかの層に分けている
- 0と1層は最重要層で、DataGuard+RACでやっている
- 2~6層はRACは運用はしていないが、DataGuardを使っている
- RACよりもDataGuardのほうが運用をしている
- RACはサーバの障害を保証してくれて、新しいサーバを設定するのに1日以内でできるが、データ破損した場合は数日〜数週間リカバリに時間がかかってしまうためにDataGuardを使っている
- MAAのアーキテクチャはハードウェアに依存しない作りにしている
- アメリカ銀行はexadataでDataGuardを構築している
- キャパシティも構成も同じ
- スタンバイが同じ構成を持ってないとフェイルオーバーしたくなくなる
- 専用のシステムを開発も同じように持っている
- 全ての変更点を本番と同様の環境とやることで本番に影響を与えないようにしている
- このテストシステムがなければ本番でテストしなければならないのでとてもリスキー
Salesforce
- プライマリDBがRAC化されていて、DataGuardを使ってスタンバイにレプリケーションを行っている
- 他のプロバイダによっても使われている
PayPal
- 12cのMAAを導入している
- インターネットを介してサービスを提供しているのでミッションクリティカルを重要視している
- 2つのDCをもっているが1000km離れている
- 11gの時
- 決済のプロセスはプライマリDBで処理されたらActiveDataGuardで同一DCにあるスタンバイDBにデータを送る。
- また、DR側のDC上にDataGuardのAsyncでスタンバイDBにデータを送る
- スタンバイ側のDCもプライマリと同じ構成になっていて、プライマリのデータを貰ってスタンバイDBにデータを送る
- 12cの時
- ActiveDataGuardStandbyにはFasySyncでシンクする
- 11gの構成にさらに、FarSyncを使ってプライマリでのデータをスタンバイに送っている
- DR側のDCではリアルタイム・カスケードを使ってスタンバイREDOのログをリアルタイムに転送している
まとめ
- 多くの企業がOracleMAAで標準化済み
- MAAはオンプレミスだけではなく、クラウド構成でも最高の可用性を実現している
- 本当のミッションクリティカル顧客で有効に活用
- 最大規模で最も要求の厳しいワークロードで運用されている
- MAAはクラウドで検証済みのアーキテクチャ
@mogmetの所感
今まで可用性などではRACでサービスが継続できていることに満足していましたが、それだけじゃなくデータを保護する意味でもActiveDataGuardが重要というのがとても伝わるセッションでした。
また、PayPalの構成が複数のActiveDataGuardを幾重にも使っていてとても興味深い構成でした。
