狠狠撸

狠狠撸Share a Scribd company logo

顿搁叠顿で始める灾害対策(顿搁)

?
?
株式会社サードウェア
株式会社サードウェア

2011年7月15日に開催されたオープンソースカンファレンス2011 Kansai@Kyotoで発表したときのプレゼン資料です。DRBD、DRBD Proxyを災害対策に応用する可能性、

1 of 27
Downloaded 32 times
DRBD で始める災害対策 (DR) 株式会社サードウェア 久保 元治 Your Way to High Availability 1 OSC 2011 Kansai@Kyoto
もくじ ● 災害対策の概要 ● DRBD の概要と特徴 ● 災害対策向けの DRBD Proxy ● いくつかのシナリオ紹介 ● まとめ Your Way to High Availability 2 OSC 2011 Kansai@Kyoto
意外に多いディザスタ ● 自然災害 ● 地震、洪水、落雷 .... ● 人災 ● 火災、水ぬれ ● 巻き添え ● 立ち入り規制 ● ハード障害 ● ディスク、電源系 Your Way to High Availability OSC 2011 Kansai@Kyoto 3
RPO と RTO ● リカバリポイント目標 (RPO) ● 被災前のどの時点のデータに復旧できるか ● 理想はゼロ ● リカバリタイム目標 (RTO) ● 被災後いつからシステムを再開できるか ● 決断までの時間、データチェック、 DNS 切り替えなど Your Way to High Availability OSC 2011 Kansai@Kyoto 4
RPO と RTO 2 日前 1 日前 被災 メインサイト　　　　　　　　　　　　　　　　　 rsync その他の 定時バックアップ バックアップ バックアップ バックアップサイト リカバリポイント目標 リカバリタイム目標 2 日前 1 日前 被災 メインサイト　　　　　　　　　　　　　　　　 リアルタイム レプリケーション DRBD レプリケーション バックアップサイト Your Way to High Availability OSC 2011 Kansai@Kyoto 5
WAN 通信回線 ● 回線品質 ● バンド幅 ● 大きな RTT ( 遅延 ) ● 安定性 ● サービスとしての考慮点 ● 転送量の制約 RTT?=?Round?Trip?Time?(ping で計測 ) Your Way to High Availability OSC 2011 Kansai@Kyoto 6
DR 検討の要点 ● RPO の策定 ● リアルタイムレプリケーションは理想的だが .... ● クラッシュタイミングでのデータ整合性も考慮 ● 回線品質、コストを考慮する必要がある ● RTO の策定 ● 代替システム立ち上げの決断 ● データやシステムのチェック ● DNS などアクセス環境を変更 ● DR サイトで代替システムを立ち上げ Your Way to High Availability OSC 2011 Kansai@Kyoto 7
DRBD プライマリ ① ⑤ ③ メタデータ セカンダリ ② ⑥ ④ メタデータ ?ブロックデバイスレベル =? ファイルシステムやデータを問わない ?リアルタイム ?変更されたディスクブロックをただちにリモート複製 通信切断時はプライマリ側のメタデータに記録、再接続後同期 Your Way to High Availability OSC 2011 Kansai@Kyoto 8
DRBD の通信 ● TCP を利用 ● プライマリ?セカンダリ間の距離は問わない ● 通信中 ● プライマリ側の書き込みをただちにセカンダリに転送 ● 通信切断時 ● セカンダリへの転送はできない ● プライマリにのみ書き込み、通信回復後にまとめて同期 ● 軽さとスピードを重視 ● データ圧縮や暗号化には非対応 Your Way to High Availability OSC 2011 Kansai@Kyoto 9
DRBD のレプリケーションプロトコル プロトコル A 非同期レプリケーション プロトコル B プロトコル C 同期レプリケーション ?ディスク I/O パフォーマンス A>B>C ?通信障害時のデータ信頼性 C>B>A ?遅延が大きくなるほどプロトコル B 、 C のパフォーマンスは低下 Your Way to High Availability OSC 2011 Kansai@Kyoto 10
アクティビティログ アクティブエクステント レプリケーションが完了していない可能性があるブロックを含む 領域 =? 通信切断?再開後の同期対象になる Your Way to High Availability OSC 2011 Kansai@Kyoto 11
ビットマップ プライマリ 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1 1 セカンダリ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ?通信切断中は、変更があったブロックに対応するビットが 1 になる ?通信再開後に変更箇所だけをセカンダリに転送すればよい =? 同期 ?変更内容をキューに溜める方式ではないため、切断時間が長くなっても大丈夫 Your Way to High Availability OSC 2011 Kansai@Kyoto 12
WAN 対応オプション ● use-rle ● csums-alg ● DRBD 8.4 ● 複数のレプリケーション?セットの同期 Your Way to High Availability OSC 2011 Kansai@Kyoto 13
DRBD の限界 ● クラッシュ時のデータ整合性 ● ファイルシステムやアプリケーションが保証する必要 ● WAN 回線の制約をモロに受ける ● 大きな遅延 --- パフォーマンスの低下 ● 狭帯域 --- 単位時間のレプリケーション量が減少 Your Way to High Availability OSC 2011 Kansai@Kyoto 14
DRBD Proxy ● DRBD 通信プロトコルを理解するプロキシ ＝ DRBD 専用の WAN アクセラレータ ● パケット圧缩 ● ユーザ空間のバッファ Your Way to High Availability OSC 2011 Kansai@Kyoto 15
パケット圧缩 ● テキスト主体データで約 50 ％の圧縮率 ● 単位時間に約 2 倍のデータが送れる ● 遅延の影響が約半分になる 圧縮率は DRBD?Proxy を使った LINBIT およびサードウェアの実測にもとづく値 Your Way to High Availability OSC 2011 Kansai@Kyoto 16
バッファ ● ディスク書き込みのピーク対応 ● 帯域をあふれるデータをメモリバッファに格納 ● プロトコル A に対応 ● バッファのデータは被災時に失われる ● 一時的な通信断は再送で整合性を確保 ● クラッシュセーフなファイルシステム、アプリケーションが 必要 – ジャーナルファイルシステム – クラッシュを考慮したデータベースなど Your Way to High Availability OSC 2011 Kansai@Kyoto 17
DRBD Proxy の性能検証 (1) DRBD Proxy の効果 (MySQL ベンチマーク ) 0 100 200 300 400( 秒 ) 2 - nod e １ G bps 直結 0ms Proxy 使用 10ms Proxy なし 20ms 50M bps 30ms 50ms 100ms 10ms 20ms 30M bps 30ms 50ms 100ms 10ms 20ms 10M bps 30ms 50ms 100ms Your Way to High Availability OSC 2011 Kansai@Kyoto 18
DRBD Proxy の性能検証 (2) Your Way to High Availability OSC 2011 Kansai@Kyoto 19
DRBD Proxy の性能検証 (2) 5000 5000 基準値（DRなし） 基準値（DRなし） 100Mbps DRBDによるDR環境 50Mbps DRBDによるDR環境 トランザクション毎分（ tpm ） トランザクション毎分（ tpm ） 4000 4000 DRBD ProxyによるDR環境 DRBD ProxyによるDR環境 3000 3000 2000 2000 1000 1000 0 0 なし 5 10 20 50 100 なし 5 10 20 50 100 ネットワーク レイテンシ（ミリ秒） ネットワーク レイテンシ（ミリ秒） 5000 5000 20Mbps 基準値（DRなし） DRBDによるDR環境 10Mbps 基準値（DRなし） DRBDによるDR環境 トランザクション毎分（ tpm ） トランザクション毎分（ tpm ） 4000 4000 DRBD ProxyによるDR環境 DRBD ProxyによるDR環境 3000 3000 2000 2000 1000 1000 0 0 なし 5 10 20 50 100 なし 5 10 20 50 100 ネットワーク レイテンシ（ミリ秒） ネットワーク レイテンシ（ミリ秒） Your Way to High Availability OSC 2011 Kansai@Kyoto 20
DRBD による DR システム メインサイト WAN バックアップサイト サービス サービス DRBD Proxy DRBD Proxy DRBD と DRBD?Proxy を使って、データを 常時メインサイトからバックアップサイトに DRBD レプリケートしておきます。 DRBD 被災時には、バックアップサイトでサービス を継続できるため、リカバリタイム目標を短 くできます。 Your Way to High Availability OSC 2011 Kansai@Kyoto 21
DRBD による DR システム メインサイト バックアップサイト WAN サービス メインサイトは高可用クラスタ構成にして、どちらか１台がダウンしても サービスを継続できるようにします。 メインサイトのデータは DRBD と DRBD?Proxy でバックアップサイト Pacemaker Pacemaker にレプリケートされます。 Heartbeat Heartbeat DRBD Proxy DRBD Proxy DRBD DRBD DRBD DRBD Your Way to High Availability OSC 2011 Kansai@Kyoto 22
DRBD による DR システム メインサイト バックアップサイト WAN iSCSI Linux?HA と iSCSI を使うと、 Windows を含 む複数の既存サーバのデータをバックアップサ イトにレプリケートできるようになります。 Pacemaker Pacemaker Heartbeat Heartbeat DRBD Proxy DRBD Proxy DRBD DRBD DRBD DRBD Your Way to High Availability OSC 2011 Kansai@Kyoto 23
DRBD による DR システム メインサイト バックアップサイト WAN サービス サービス Pacemaker Pacemaker Pacemaker Pacemaker Heartbeat Heartbeat Heartbeat Heartbeat DRBD Proxy DRBD Proxy DRBD DRBD DRBD DRBD DRBD DRBD メインサイトとバックアップサイトの両方に高可用クラスタを置いて、サイト 間でデータをレプリケートする構成は、とくにミッションクリティカルなシス テム向けのソリューションです。 Your Way to High Availability OSC 2011 Kansai@Kyoto 24
导入ガイドライン ● データ保全のみか、業務二重化まで行うか ● RPO 、 RTO を策定する ● 対象データの絞り込み ● データ総量、データ変更量 ( 、ピーク時の変更量 ) ● 転送中にクラッシュしたときの整合性の確保方法 Your Way to High Availability OSC 2011 Kansai@Kyoto 25
导入ガイドライン ● WAN 回線の選択 ● 平均的なバンド幅と RTT の測定 ( 推定 ) ● 暗号化などの方式選定 ● 製品?方式選定 ● データ変更量を十分に回線がカバーできる 　　 ==> DRBD のみでも実現できる ● 遅延大、データ変更量多い、日時変動が大きい 　　 ==> DRBD Proxy 併用が望ましい ● HA も必要か Your Way to High Availability OSC 2011 Kansai@Kyoto 26
まとめ ● DRBD は WAN 越しのリアルタイム?レプリケーショ ンにも利用できる ● WAN 回線の狭帯域、遅延、不安定さ、転送量制限 などに配慮する必要がある ● クラッシュしたときのデータ整合性確保も重要 ● DRBD Proxy は WAN 回線の制約を緩和できる ● Windows などのアプリケーションやデータにも適 用できる Your Way to High Availability OSC 2011 Kansai@Kyoto 27

More Related Content

顿搁叠顿で始める灾害対策(顿搁)

  • 1. DRBD で始める災害対策 (DR) 株式会社サードウェア 久保 元治 Your Way to High Availability 1 OSC 2011 Kansai@Kyoto
  • 2. もくじ ● 災害対策の概要 ● DRBD の概要と特徴 ● 災害対策向けの DRBD Proxy ● いくつかのシナリオ紹介 ● まとめ Your Way to High Availability 2 OSC 2011 Kansai@Kyoto
  • 3. 意外に多いディザスタ ● 自然災害 ● 地震、洪水、落雷 .... ● 人災 ● 火災、水ぬれ ● 巻き添え ● 立ち入り規制 ● ハード障害 ● ディスク、電源系 Your Way to High Availability OSC 2011 Kansai@Kyoto 3
  • 4. RPO と RTO ● リカバリポイント目標 (RPO) ● 被災前のどの時点のデータに復旧できるか ● 理想はゼロ ● リカバリタイム目標 (RTO) ● 被災後いつからシステムを再開できるか ● 決断までの時間、データチェック、 DNS 切り替えなど Your Way to High Availability OSC 2011 Kansai@Kyoto 4
  • 5. RPO と RTO 2 日前 1 日前 被災 メインサイト　　　　　　　　　　　　　　　　　 rsync その他の 定時バックアップ バックアップ バックアップ バックアップサイト リカバリポイント目標 リカバリタイム目標 2 日前 1 日前 被災 メインサイト　　　　　　　　　　　　　　　　 リアルタイム レプリケーション DRBD レプリケーション バックアップサイト Your Way to High Availability OSC 2011 Kansai@Kyoto 5
  • 6. WAN 通信回線 ● 回線品質 ● バンド幅 ● 大きな RTT ( 遅延 ) ● 安定性 ● サービスとしての考慮点 ● 転送量の制約 RTT?=?Round?Trip?Time?(ping で計測 ) Your Way to High Availability OSC 2011 Kansai@Kyoto 6
  • 7. DR 検討の要点 ● RPO の策定 ● リアルタイムレプリケーションは理想的だが .... ● クラッシュタイミングでのデータ整合性も考慮 ● 回線品質、コストを考慮する必要がある ● RTO の策定 ● 代替システム立ち上げの決断 ● データやシステムのチェック ● DNS などアクセス環境を変更 ● DR サイトで代替システムを立ち上げ Your Way to High Availability OSC 2011 Kansai@Kyoto 7
  • 8. DRBD プライマリ ① ⑤ ③ メタデータ セカンダリ ② ⑥ ④ メタデータ ?ブロックデバイスレベル =? ファイルシステムやデータを問わない ?リアルタイム ?変更されたディスクブロックをただちにリモート複製 通信切断時はプライマリ側のメタデータに記録、再接続後同期 Your Way to High Availability OSC 2011 Kansai@Kyoto 8
  • 9. DRBD の通信 ● TCP を利用 ● プライマリ?セカンダリ間の距離は問わない ● 通信中 ● プライマリ側の書き込みをただちにセカンダリに転送 ● 通信切断時 ● セカンダリへの転送はできない ● プライマリにのみ書き込み、通信回復後にまとめて同期 ● 軽さとスピードを重視 ● データ圧縮や暗号化には非対応 Your Way to High Availability OSC 2011 Kansai@Kyoto 9
  • 10. DRBD のレプリケーションプロトコル プロトコル A 非同期レプリケーション プロトコル B プロトコル C 同期レプリケーション ?ディスク I/O パフォーマンス A>B>C ?通信障害時のデータ信頼性 C>B>A ?遅延が大きくなるほどプロトコル B 、 C のパフォーマンスは低下 Your Way to High Availability OSC 2011 Kansai@Kyoto 10
  • 11. アクティビティログ アクティブエクステント レプリケーションが完了していない可能性があるブロックを含む 領域 =? 通信切断?再開後の同期対象になる Your Way to High Availability OSC 2011 Kansai@Kyoto 11
  • 12. ビットマップ プライマリ 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1 1 セカンダリ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ?通信切断中は、変更があったブロックに対応するビットが 1 になる ?通信再開後に変更箇所だけをセカンダリに転送すればよい =? 同期 ?変更内容をキューに溜める方式ではないため、切断時間が長くなっても大丈夫 Your Way to High Availability OSC 2011 Kansai@Kyoto 12
  • 13. WAN 対応オプション ● use-rle ● csums-alg ● DRBD 8.4 ● 複数のレプリケーション?セットの同期 Your Way to High Availability OSC 2011 Kansai@Kyoto 13
  • 14. DRBD の限界 ● クラッシュ時のデータ整合性 ● ファイルシステムやアプリケーションが保証する必要 ● WAN 回線の制約をモロに受ける ● 大きな遅延 --- パフォーマンスの低下 ● 狭帯域 --- 単位時間のレプリケーション量が減少 Your Way to High Availability OSC 2011 Kansai@Kyoto 14
  • 15. DRBD Proxy ● DRBD 通信プロトコルを理解するプロキシ ＝ DRBD 専用の WAN アクセラレータ ● パケット圧缩 ● ユーザ空間のバッファ Your Way to High Availability OSC 2011 Kansai@Kyoto 15
  • 16. パケット圧缩 ● テキスト主体データで約 50 ％の圧縮率 ● 単位時間に約 2 倍のデータが送れる ● 遅延の影響が約半分になる 圧縮率は DRBD?Proxy を使った LINBIT およびサードウェアの実測にもとづく値 Your Way to High Availability OSC 2011 Kansai@Kyoto 16
  • 17. バッファ ● ディスク書き込みのピーク対応 ● 帯域をあふれるデータをメモリバッファに格納 ● プロトコル A に対応 ● バッファのデータは被災時に失われる ● 一時的な通信断は再送で整合性を確保 ● クラッシュセーフなファイルシステム、アプリケーションが 必要 – ジャーナルファイルシステム – クラッシュを考慮したデータベースなど Your Way to High Availability OSC 2011 Kansai@Kyoto 17
  • 18. DRBD Proxy の性能検証 (1) DRBD Proxy の効果 (MySQL ベンチマーク ) 0 100 200 300 400( 秒 ) 2 - nod e １ G bps 直結 0ms Proxy 使用 10ms Proxy なし 20ms 50M bps 30ms 50ms 100ms 10ms 20ms 30M bps 30ms 50ms 100ms 10ms 20ms 10M bps 30ms 50ms 100ms Your Way to High Availability OSC 2011 Kansai@Kyoto 18
  • 19. DRBD Proxy の性能検証 (2) Your Way to High Availability OSC 2011 Kansai@Kyoto 19
  • 20. DRBD Proxy の性能検証 (2) 5000 5000 基準値（DRなし） 基準値（DRなし） 100Mbps DRBDによるDR環境 50Mbps DRBDによるDR環境 トランザクション毎分（ tpm ） トランザクション毎分（ tpm ） 4000 4000 DRBD ProxyによるDR環境 DRBD ProxyによるDR環境 3000 3000 2000 2000 1000 1000 0 0 なし 5 10 20 50 100 なし 5 10 20 50 100 ネットワーク レイテンシ（ミリ秒） ネットワーク レイテンシ（ミリ秒） 5000 5000 20Mbps 基準値（DRなし） DRBDによるDR環境 10Mbps 基準値（DRなし） DRBDによるDR環境 トランザクション毎分（ tpm ） トランザクション毎分（ tpm ） 4000 4000 DRBD ProxyによるDR環境 DRBD ProxyによるDR環境 3000 3000 2000 2000 1000 1000 0 0 なし 5 10 20 50 100 なし 5 10 20 50 100 ネットワーク レイテンシ（ミリ秒） ネットワーク レイテンシ（ミリ秒） Your Way to High Availability OSC 2011 Kansai@Kyoto 20
  • 21. DRBD による DR システム メインサイト WAN バックアップサイト サービス サービス DRBD Proxy DRBD Proxy DRBD と DRBD?Proxy を使って、データを 常時メインサイトからバックアップサイトに DRBD レプリケートしておきます。 DRBD 被災時には、バックアップサイトでサービス を継続できるため、リカバリタイム目標を短 くできます。 Your Way to High Availability OSC 2011 Kansai@Kyoto 21
  • 22. DRBD による DR システム メインサイト バックアップサイト WAN サービス メインサイトは高可用クラスタ構成にして、どちらか１台がダウンしても サービスを継続できるようにします。 メインサイトのデータは DRBD と DRBD?Proxy でバックアップサイト Pacemaker Pacemaker にレプリケートされます。 Heartbeat Heartbeat DRBD Proxy DRBD Proxy DRBD DRBD DRBD DRBD Your Way to High Availability OSC 2011 Kansai@Kyoto 22
  • 23. DRBD による DR システム メインサイト バックアップサイト WAN iSCSI Linux?HA と iSCSI を使うと、 Windows を含 む複数の既存サーバのデータをバックアップサ イトにレプリケートできるようになります。 Pacemaker Pacemaker Heartbeat Heartbeat DRBD Proxy DRBD Proxy DRBD DRBD DRBD DRBD Your Way to High Availability OSC 2011 Kansai@Kyoto 23
  • 24. DRBD による DR システム メインサイト バックアップサイト WAN サービス サービス Pacemaker Pacemaker Pacemaker Pacemaker Heartbeat Heartbeat Heartbeat Heartbeat DRBD Proxy DRBD Proxy DRBD DRBD DRBD DRBD DRBD DRBD メインサイトとバックアップサイトの両方に高可用クラスタを置いて、サイト 間でデータをレプリケートする構成は、とくにミッションクリティカルなシス テム向けのソリューションです。 Your Way to High Availability OSC 2011 Kansai@Kyoto 24
  • 25. 导入ガイドライン ● データ保全のみか、業務二重化まで行うか ● RPO 、 RTO を策定する ● 対象データの絞り込み ● データ総量、データ変更量 ( 、ピーク時の変更量 ) ● 転送中にクラッシュしたときの整合性の確保方法 Your Way to High Availability OSC 2011 Kansai@Kyoto 25
  • 26. 导入ガイドライン ● WAN 回線の選択 ● 平均的なバンド幅と RTT の測定 ( 推定 ) ● 暗号化などの方式選定 ● 製品?方式選定 ● データ変更量を十分に回線がカバーできる 　　 ==> DRBD のみでも実現できる ● 遅延大、データ変更量多い、日時変動が大きい 　　 ==> DRBD Proxy 併用が望ましい ● HA も必要か Your Way to High Availability OSC 2011 Kansai@Kyoto 26
  • 27. まとめ ● DRBD は WAN 越しのリアルタイム?レプリケーショ ンにも利用できる ● WAN 回線の狭帯域、遅延、不安定さ、転送量制限 などに配慮する必要がある ● クラッシュしたときのデータ整合性確保も重要 ● DRBD Proxy は WAN 回線の制約を緩和できる ● Windows などのアプリケーションやデータにも適 用できる Your Way to High Availability OSC 2011 Kansai@Kyoto 27