Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
DRBDを活用したAzure上でのデータ保護
~他のリージョンや、他のクラウド、自社データセンターとのデータ同期~
株式会社サードウェア 澤田 健
自己紹介
2
氏名: 澤田 健 (sawada ken)
所属: 株式会社サードウェア
経歴: 2013.04 ~ 現職
Twitter: @ksawada1979
「DRBD関連の情報を発信中!」
Facebook: ken.sawada.1...
会社紹介
3
設立 1997年2月7日
事業内容 オープンソースをコアにしたデータ保護事業
- LinbitクラスタスタックによるLinux-HAソリューション
- Bacula Enterprise Editionによるバックアップ
ソリュー...
会社紹介
4
サードウェアはオープンソースによる
Enterprise Data Protectionを実現します。
Zabbix
Bacula
Enterprise
Edition
LINBIT クラスタス
タックサポート
高可用性
監視バッ...
本日のテーマ
5
DRBDを活用した
Azure上でのデータ保護
データ保護
6
データを保護する手法
サーバの重要なデータを保護する方法には「バックアップ」「サーバ冗長化(高可用性)」「監
視」「遠隔地へのデータ保管」などさまざまな方法があります。
今日は遠隔地へのデータ保管による「災害対策システム」のご紹...
災害対策
7
災害対策システムとは?
災害時(地震、火災、人災)でもシステムのサービスダウン時間が少ないシステムのことを指し
ます。
RPOとRTO
8
災害対策システムを考える上で重要なこと
RPO (目標復旧時点)と
RTO (目的復旧時間)
を考えた上でシステムを構築する。
RPO (目標復旧時点)
9
いつの時点へシステムを戻すかもしくは戻すことが可能か、できれば障害発生直前が望まし
い。
RTO (目的復旧時間)
10
システムの復旧までにかかる時間です。
復旧までにかかる時間は少ない方が良いですので、できる限り短くできるようなシステムが望
ましくなります。
RTO (目的復旧時間)
11
障害復旧からの流れ (バックアップからの復旧の例)
OS再インストールが必要なほど重大な障害が発生した場合は、当然OSインストールから
再実施、サーバ再設定、データリストア、動作試験も必要。
また、場合によっては...
RTO (目的復旧時間)
12
障害復旧からの流れ (バックアップからの復旧の例)
OS再インストールが必要なほど重大な障害が発生した場合は、当然OSインストールから
再実施、サーバ再設定、データリストア、動作試験も必要。
また、場合によっては...
災害対策
13
今すでに行われている災害対策は?
夜間にバックアップをテープなどに取得
→遠隔地へ保管
→耐火金庫
災害対策
14
災害対策にテープを使用した際の問題点
・運用に手間(コスト)がかかる
・しっかりリストアできますか?
15
DRBD/DRBD Proxy
による
災害対策システム
目的
16
RPO (目標復旧時点)を直近にし
RTO (目的復旧時間)を短くする
災害時でもサービス継続できるシステムを
Azure上に構築
基本構成
17
物理サーバ
DRBD Proxy
レプリケーション(データ複製)Active機
VPN接続
ローカルDC
192.168.0.20
Standby機
Virtual Server (Asianux)
データセンター(東日本)
ロ...
DRBDとは?
18
DRBD
サーバデータをリアルタイムにレプリケーション(複製)するLinuxのオープンソースソフトウェアで
す。
ブロック単位でリプリケーションするため、ファイルシステムに影響を受けません。
xfs,ext3,ext4など...
DRBD Proxyとは?
19
DRBD Proxy
DRBDのオプションソフトウェア
遠隔地へサーバデータをリアルタイムにレプリケーション(複製)するために使用されます。
※DRBD Proxyは有償ソフトウェアになります。
現在LINBI...
DRBD Proxyとは?
20
特徴
データ圧縮(テキストベースで50%)
帯域をあふれるデータをメモリバッファに格納
一時的な通信断は再送で整合性を確保
基本構成
21
物理サーバ
DRBD Proxy
レプリケーション(データ複製)Active機
VPN接続
ローカルDC
192.168.0.20
Standby機
Virtual Server (Asianux)
データセンター(東日本)
ロ...
障害発生時
22
物理サーバ
DRBD Proxy
レプリケーション(データ複製)Active機
VPN接続
ローカルDC
192.168.0.20
Standby機
Virtual Server (Asianux)
データセンター(東日本)
...
障害発生時
23
物理サーバ
Standby機
ローカルDC
192.168.0.20
Active機
Virtual Server
データセンター(東日本)
ローカルDC(データセンター)とAzure上で
障害発生時の構成概要
Active機...
サービスダウン時間の比較
24
障害復旧からの流れ (災害対策システムでの復旧)
DRBD/DRBD Proxyを使った災害対策システムの場合は手動でActiveとStandbyを切
り替えを実施しサービスを再開します。
これによりサービスのダ...
サービスダウン時間の比較
25
障害復旧からの流れ (災害対策システムでの復旧)
DRBD/DRBD Proxyを使った災害対策システムの場合は手動でActiveとStandbyを切
り替えを実施しサービスを再開します。
これによりサービスのダ...
サービスダウン時間の比較
26
障害復旧からの流れ (テープバックアップからの復旧)
OS再インストールが必要なほど重大な障害が発生した場合は、当然OSインストールから
再実施、サーバ再設定、データリストア、動作試験も必要。
また、場合によって...
DRBD/DRBD Proxyのメリット
27
RPO (目標復旧時点)が直近となる
障害発生時はプライマリ機からセカンダリ機に切り替えることによって障害復旧が可能。
障害発生の直前までデータの同期を行っているために、障害発生直前の状態で復旧す...
DRBD/DRBD Proxyのメリット
28
RTO (目的復旧時間)の短縮ができる
障害発生時はプライマリ機からセカンダリ機に切り替えることによって障害復旧が可能。
テープなどのデータバックアップから復旧するよりも大幅にシステムの復旧時間が...
基本構成
29
DRBD Proxy
レプリケーション(データ複製)Active機
VPN接続
192.168.0.20
Standby機
Virtual Server (Asianux)
データセンター(東日本)
AzureとAzure上で
...
基本構成
30
東日本(Azure)と西日本(Azure)でのパフォーマンス測定
Netperfによるスループット計測
約100M bits/sec
データ同期速度
500MB 5分
31
事例
事例1 株式会社アイル様
32
東京と大阪間で相互に遠隔地へデータコピー
バックアップサーバのデータを相互にコピーしデータ保護を実現
日々の新規データ100GBを夜間に約4時間で同期
※夜間のみDRBD/DRBD Proxyを動かしている
事例2 建設設計コンサルタント会社様
33
Hyper-V
Red Hat Enterprise Linux
Windows
Server
+ DRBD Proxy
お客様本社(札幌) データセンター(仙台)
札幌から仙台へ遠隔地データコピー
...
34
DRBD/DRBD Proxy
注意点
DRBD/DRBD Proxy注意点
35
DRBDとDRBD Proxyは
オペーレーションミスに
対応していません。
申し訳ございません
DRBD/DRBD Proxy注意点
36
DRBD同期
例えば
Active機 Standby機
Active機で「rm –rf /etc」コマンドを間違って実行!
DRBD/DRBD Proxy注意点
37
DRBD同期
Active機 Standby機
当然Standby機側でもデータが削除されます。
削除されたデータは帰ってきません。
DRBD/DRBD Proxy注意点
38
バックアップは重要!
DRBD/DRBD Proxy注意点
39
オープンソースであり世界で一番
ダウンロードされている
バックアップソフト「Bacula」
40
CMDBuild(ITIL構成管理)
OTRS(チケット管理)
JobScheduler(JOB管理)
Ansible(自動構成ツール)
Bacula Enterprise Edition(バックアップ)
Zabbix(監視)
さまざまな...
41
ご清聴ありがとうございました
Upcoming SlideShare
Loading in …5
×

DRBDを活用したAzure上でのデータ保護

911 views

Published on

20015/11/26に開催しました「Microsoft Azure+「Linux」による企業情報システムの作り方、徹底解説!」の中で「DRBDを活用したAzure上でのデータ保護」のお話をさせていただきました。
その時の資料になります。

Published in: Software
  • Be the first to comment

DRBDを活用したAzure上でのデータ保護

  1. 1. DRBDを活用したAzure上でのデータ保護 ~他のリージョンや、他のクラウド、自社データセンターとのデータ同期~ 株式会社サードウェア 澤田 健
  2. 2. 自己紹介 2 氏名: 澤田 健 (sawada ken) 所属: 株式会社サードウェア 経歴: 2013.04 ~ 現職 Twitter: @ksawada1979 「DRBD関連の情報を発信中!」 Facebook: ken.sawada.14 @ITにて「DRBDの仕組みを学ぶ」を連載中 http://www.atmarkit.co.jp/ait/series/2185/index.html 「@IT DRBD」で検索!
  3. 3. 会社紹介 3 設立 1997年2月7日 事業内容 オープンソースをコアにしたデータ保護事業 - LinbitクラスタスタックによるLinux-HAソリューション - Bacula Enterprise Editionによるバックアップ ソリューション - Zabbixによるサーバー監視ソリューション 上記に関わる構築・運用サポート・監視サービスの提供 主な顧客 エンタープライズ、データセンター、ホスティング事業者、 クラウド提供者 特記事項 DRBD開発元であるLINBIT社の国内総代理店 Bacula 開発元である Bacula Systems社の国内総代理店
  4. 4. 会社紹介 4 サードウェアはオープンソースによる Enterprise Data Protectionを実現します。 Zabbix Bacula Enterprise Edition LINBIT クラスタス タックサポート 高可用性 監視バックアップ
  5. 5. 本日のテーマ 5 DRBDを活用した Azure上でのデータ保護
  6. 6. データ保護 6 データを保護する手法 サーバの重要なデータを保護する方法には「バックアップ」「サーバ冗長化(高可用性)」「監 視」「遠隔地へのデータ保管」などさまざまな方法があります。 今日は遠隔地へのデータ保管による「災害対策システム」のご紹介をします。
  7. 7. 災害対策 7 災害対策システムとは? 災害時(地震、火災、人災)でもシステムのサービスダウン時間が少ないシステムのことを指し ます。
  8. 8. RPOとRTO 8 災害対策システムを考える上で重要なこと RPO (目標復旧時点)と RTO (目的復旧時間) を考えた上でシステムを構築する。
  9. 9. RPO (目標復旧時点) 9 いつの時点へシステムを戻すかもしくは戻すことが可能か、できれば障害発生直前が望まし い。
  10. 10. RTO (目的復旧時間) 10 システムの復旧までにかかる時間です。 復旧までにかかる時間は少ない方が良いですので、できる限り短くできるようなシステムが望 ましくなります。
  11. 11. RTO (目的復旧時間) 11 障害復旧からの流れ (バックアップからの復旧の例) OS再インストールが必要なほど重大な障害が発生した場合は、当然OSインストールから 再実施、サーバ再設定、データリストア、動作試験も必要。 また、場合によっては導入から期間がたっており、引継ぎなどが上手く行われておらずリストア 手順が不明なんてことも・・・・
  12. 12. RTO (目的復旧時間) 12 障害復旧からの流れ (バックアップからの復旧の例) OS再インストールが必要なほど重大な障害が発生した場合は、当然OSインストールから 再実施、サーバ再設定、データリストア、動作試験も必要。 また、場合によっては導入から期間がたっており、引継ぎなどが上手く行われておらずリストア 手順が不明なんてことも・・・・ サービスダウンは数時間~数日
  13. 13. 災害対策 13 今すでに行われている災害対策は? 夜間にバックアップをテープなどに取得 →遠隔地へ保管 →耐火金庫
  14. 14. 災害対策 14 災害対策にテープを使用した際の問題点 ・運用に手間(コスト)がかかる ・しっかりリストアできますか?
  15. 15. 15 DRBD/DRBD Proxy による 災害対策システム
  16. 16. 目的 16 RPO (目標復旧時点)を直近にし RTO (目的復旧時間)を短くする 災害時でもサービス継続できるシステムを Azure上に構築
  17. 17. 基本構成 17 物理サーバ DRBD Proxy レプリケーション(データ複製)Active機 VPN接続 ローカルDC 192.168.0.20 Standby機 Virtual Server (Asianux) データセンター(東日本) ローカルDC(データセンター)とAzure上で 災害対策用システムを構築する場合の構成概要 192.168.0.10 ユーザアクセス
  18. 18. DRBDとは? 18 DRBD サーバデータをリアルタイムにレプリケーション(複製)するLinuxのオープンソースソフトウェアで す。 ブロック単位でリプリケーションするため、ファイルシステムに影響を受けません。 xfs,ext3,ext4などは何でもOKです。
  19. 19. DRBD Proxyとは? 19 DRBD Proxy DRBDのオプションソフトウェア 遠隔地へサーバデータをリアルタイムにレプリケーション(複製)するために使用されます。 ※DRBD Proxyは有償ソフトウェアになります。 現在LINBIT社との契約が無い場合でも、30日間の評価ライセンスを提供いたしております。 評価版ライセンスの発行依頼は株式会社サードウェアにお問い合わせください。 sales@3ware.co.jp
  20. 20. DRBD Proxyとは? 20 特徴 データ圧縮(テキストベースで50%) 帯域をあふれるデータをメモリバッファに格納 一時的な通信断は再送で整合性を確保
  21. 21. 基本構成 21 物理サーバ DRBD Proxy レプリケーション(データ複製)Active機 VPN接続 ローカルDC 192.168.0.20 Standby機 Virtual Server (Asianux) データセンター(東日本) ローカルDC(データセンター)とAzure上で 災害対策用システムを構築する場合の構成概要 192.168.0.10 ユーザアクセス
  22. 22. 障害発生時 22 物理サーバ DRBD Proxy レプリケーション(データ複製)Active機 VPN接続 ローカルDC 192.168.0.20 Standby機 Virtual Server (Asianux) データセンター(東日本) ローカルDC(データセンター)とAzure上で 障害発生時の構成概要 192.168.0.10 ユーザアクセス 障害発生
  23. 23. 障害発生時 23 物理サーバ Standby機 ローカルDC 192.168.0.20 Active機 Virtual Server データセンター(東日本) ローカルDC(データセンター)とAzure上で 障害発生時の構成概要 Active機を切り替えて数分で復旧 192.168.0.10 ユーザアクセス 障害発生 切り替え
  24. 24. サービスダウン時間の比較 24 障害復旧からの流れ (災害対策システムでの復旧) DRBD/DRBD Proxyを使った災害対策システムの場合は手動でActiveとStandbyを切 り替えを実施しサービスを再開します。 これによりサービスのダウンタイムは少なく、数分~数十分でサービスを復旧することができます。 手動切替障害発生 サービス再開
  25. 25. サービスダウン時間の比較 25 障害復旧からの流れ (災害対策システムでの復旧) DRBD/DRBD Proxyを使った災害対策システムの場合は手動でActiveとStandbyを切 り替えを実施しサービスを再開します。 これによりサービスのダウンタイムは少なく、数分~数十分でサービスを復旧することができます。 手動切替障害発生 サービス再開 サービスダウンは数分~数十分
  26. 26. サービスダウン時間の比較 26 障害復旧からの流れ (テープバックアップからの復旧) OS再インストールが必要なほど重大な障害が発生した場合は、当然OSインストールから 再実施、サーバ再設定、データリストア、動作試験も必要。 また、場合によっては導入から期間がたっており、引継ぎなどが上手く行われておらずリストア 手順が不明なんてことも・・・・ サービスダウンは数時間~数日
  27. 27. DRBD/DRBD Proxyのメリット 27 RPO (目標復旧時点)が直近となる 障害発生時はプライマリ機からセカンダリ機に切り替えることによって障害復旧が可能。 障害発生の直前までデータの同期を行っているために、障害発生直前の状態で復旧するこ とができる。 テープなどのデータバックアップから復旧する場合はバックアップ取得時が復旧点となる。
  28. 28. DRBD/DRBD Proxyのメリット 28 RTO (目的復旧時間)の短縮ができる 障害発生時はプライマリ機からセカンダリ機に切り替えることによって障害復旧が可能。 テープなどのデータバックアップから復旧するよりも大幅にシステムの復旧時間が短くなります。
  29. 29. 基本構成 29 DRBD Proxy レプリケーション(データ複製)Active機 VPN接続 192.168.0.20 Standby機 Virtual Server (Asianux) データセンター(東日本) AzureとAzure上で 災害対策用システムを構築する場合の構成概要 ユーザアクセス 192.168.0.10 Virtual Server (Asianux) データセンター(西日本)
  30. 30. 基本構成 30 東日本(Azure)と西日本(Azure)でのパフォーマンス測定 Netperfによるスループット計測 約100M bits/sec データ同期速度 500MB 5分
  31. 31. 31 事例
  32. 32. 事例1 株式会社アイル様 32 東京と大阪間で相互に遠隔地へデータコピー バックアップサーバのデータを相互にコピーしデータ保護を実現 日々の新規データ100GBを夜間に約4時間で同期 ※夜間のみDRBD/DRBD Proxyを動かしている
  33. 33. 事例2 建設設計コンサルタント会社様 33 Hyper-V Red Hat Enterprise Linux Windows Server + DRBD Proxy お客様本社(札幌) データセンター(仙台) 札幌から仙台へ遠隔地データコピー 仮想環境上のWindwosデータを遠隔地にコピーしデータ保護を実現 iSCSIターゲット 書き込み Hyper-V Red Hat Enterprise Linux Windows Server + DRBD Proxy ユーザアクセス WAN DRBD Proxy レプリケーション (データ複製)
  34. 34. 34 DRBD/DRBD Proxy 注意点
  35. 35. DRBD/DRBD Proxy注意点 35 DRBDとDRBD Proxyは オペーレーションミスに 対応していません。 申し訳ございません
  36. 36. DRBD/DRBD Proxy注意点 36 DRBD同期 例えば Active機 Standby機 Active機で「rm –rf /etc」コマンドを間違って実行!
  37. 37. DRBD/DRBD Proxy注意点 37 DRBD同期 Active機 Standby機 当然Standby機側でもデータが削除されます。 削除されたデータは帰ってきません。
  38. 38. DRBD/DRBD Proxy注意点 38 バックアップは重要!
  39. 39. DRBD/DRBD Proxy注意点 39 オープンソースであり世界で一番 ダウンロードされている バックアップソフト「Bacula」
  40. 40. 40 CMDBuild(ITIL構成管理) OTRS(チケット管理) JobScheduler(JOB管理) Ansible(自動構成ツール) Bacula Enterprise Edition(バックアップ) Zabbix(監視) さまざまなOSS(オープンソース)をご紹介! セミナーご紹介 12/1 15:00~ http://connpass.com/event/22810/ OSS December Festa
  41. 41. 41 ご清聴ありがとうございました

×