Upload
ken-sawada
View
661
Download
0
Embed Size (px)
Citation preview
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日間の評価ライセンスを提供いたしております。
評価版ライセンスの発行依頼は株式会社サードウェアにお問い合わせください。
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
ご清聴ありがとうございました