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

DRBDを活用したAzure上でのデータ保護～他のリージョンや、他のクラウド、自社データセンターとのデータ同期～

株式会社サードウェア 澤田 健

自己紹介

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

設立 1997年2月7日

事業内容 オープンソースをコアにしたデータ保護事業- LinbitクラスタスタックによるLinux-HAソリューション

- Bacula Enterprise Editionによるバックアップ

ソリューション

- Zabbixによるサーバー監視ソリューション

上記に関わる構築・運用サポート・監視サービスの提供

主な顧客 エンタープライズ、データセンター、ホスティング事業者、

クラウド提供者

特記事項 DRBD開発元であるLINBIT社の国内総代理店Bacula 開発元である Bacula Systems社の国内総代理店

会社紹介

4

サードウェアはオープンソースによる

Enterprise Data Protectionを実現します。

ZabbixBacula

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)

データセンター(東日本)

ローカルDC(データセンター)とAzure上で

災害対策用システムを構築する場合の構成概要

192.168.0.10

ユーザアクセス

DRBDとは？

18

DRBDサーバデータをリアルタイムにレプリケーション(複製)するLinuxのオープンソースソフトウェアです。ブロック単位でリプリケーションするため、ファイルシステムに影響を受けません。xfs,ext3,ext4などは何でもOKです。

DRBD Proxyとは？

19

DRBD ProxyDRBDのオプションソフトウェア遠隔地へサーバデータをリアルタイムにレプリケーション(複製)するために使用されます。

※DRBD Proxyは有償ソフトウェアになります。

現在LINBIT社との契約が無い場合でも、30日間の評価ライセンスを提供いたしております。

評価版ライセンスの発行依頼は株式会社サードウェアにお問い合わせください。

sales@3ware.co.jp

DRBD Proxyとは？

20

特徴データ圧縮(テキストベースで50%)帯域をあふれるデータをメモリバッファに格納一時的な通信断は再送で整合性を確保

基本構成

21

物理サーバ

DRBD Proxyレプリケーション(データ複製)Active機

VPN接続

ローカルDC

192.168.0.20

Standby機

Virtual Server (Asianux)

データセンター(東日本)

ローカルDC(データセンター)とAzure上で

災害対策用システムを構築する場合の構成概要

192.168.0.10

ユーザアクセス

障害発生時

22

物理サーバ

DRBD Proxyレプリケーション(データ複製)Active機

VPN接続

ローカルDC

192.168.0.20

Standby機

Virtual Server (Asianux)

データセンター(東日本)

ローカルDC(データセンター)とAzure上で

障害発生時の構成概要

192.168.0.10

ユーザアクセス

障害発生

障害発生時

23

物理サーバ

Standby機

ローカルDC

192.168.0.20

Active機

Virtual Server

データセンター(東日本)

ローカルDC(データセンター)とAzure上で

障害発生時の構成概要

Active機を切り替えて数分で復旧

192.168.0.10

ユーザアクセス

障害発生 切り替え

サービスダウン時間の比較

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上で

災害対策用システムを構築する場合の構成概要

ユーザアクセス

192.168.0.10

Virtual Server (Asianux)

データセンター(西日本)

基本構成

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

WindowsServer

+ DRBD Proxy

お客様本社(札幌) データセンター(仙台)

札幌から仙台へ遠隔地データコピー

仮想環境上のWindwosデータを遠隔地にコピーしデータ保護を実現

iSCSIターゲット書き込み

Hyper-V

Red Hat Enterprise Linux

WindowsServer

+ DRBD Proxy

ユーザアクセス

WAN

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（監視）

さまざまなOSS(オープンソース)をご紹介！

セミナーご紹介

12/1 15:00～

http://connpass.com/event/22810/

OSS December Festa

41

ご清聴ありがとうございました