DRBDで実現する高可用性システムと災害対策

株式会社サードウェア

澤田 健

Japan SoftLayer Summit 2015

2015/02/12

自己紹介

2

氏名: 澤田 健 (sawada ken)

所属: 株式会社サードウェア (フツーの社員)

経歴: 省略 (インフラ関連の職歴が無いので)

2013.04 ～ 現職

Softlayer歴: 3ヶ月

Twitter: @ksawada1979

Facebook: ken.sawada.14

備考: 別にギターは得意ではありません

むしろまったくできません

株式会社サードウェアについて

3

設立 1997年2月7日

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

- Bacula Enterprise Editionによるバックアップソリューション

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

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

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

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

株式会社サードウェアについて

4

サードウェアはOpen sourceによる

Enterprise Data Protectionを実現します。

Zabbix

Bacula

Enterprise Edition

LINBIT クラスタスタックサポート

高可用性

監視 バックアップ

本日のテーマ

5

・高可用性システム

・災害対策

Softlayerを使った

高可用性システム

6

そもそも高可用性システムって？

システムなどにおいて、サービスダウンの時間が少ないことを指します。 つまり可用性が高いので、高可用性となります。 また、高可用性のシステムをHA(High Availability)構成、HAサーバ、HAクラスターと呼ばれることもあります。

高可用性システム

7

そもそも高可用性システムって？

システムなどにおいて、サービスダウンの時間が少ないことを指します。 つまり可用性が高いので、高可用性となります。 また、高可用性のシステムをHA(High Availability)構成、HAサーバ、HAクラスターと呼ばれることもあります。

サービスダウン時間が少ない

信頼性の高いシステム

サービスダウン時間比較

8

障害復旧からの流れ (バックアップからの復旧)

OS再インストールが必要なほど重大な障害が発生した場合は、当然OSインストールから再実施、サーバ再設定、データリストア、動作試験も必要。 また、場合によっては導入から期間がたっており、引継ぎなどが上手く行われておらずリストア手順が不明なんてことも・・・・

サービスダウン時間比較

9

障害復旧からの流れ (バックアップからの復旧)

OS再インストールが必要なほど重大な障害が発生した場合は、当然OSインストールから再実施、サーバ再設定、データリストア、動作試験も必要。 また、場合によっては導入から期間がたっており、引継ぎなどが上手く行われておらずリストア手順が不明なんてことも・・・・

サービスダウンは数時間～数日

サービスダウン時間比較

10

障害復旧からの流れ クラウド編

クラウドの登場によりOS再インストールが必要なほど重大な障害が発生した場合でも、OSインストール、サーバ再設定は大幅に作業軽減されました。 システムダウン時間はかなり少なくなりましたが、数分での復旧はやはり難しくなります。 また、クラウド環境でもクラウド基盤側に障害があった場合はサービスダウンが長期化するケースあります。

サービスダウン時間比較

11

障害復旧からの流れ クラウド編

クラウドの登場によりOS再インストールが必要なほど重大な障害が発生した場合でも、OSインストール、サーバ再設定は大幅に作業軽減されました。 システムダウン時間はかなり少なくなりましたが、数分での復旧はやはり難しくなります。 また、クラウド環境でもクラウド基盤側に障害があった場合はサービスダウンが長期化するケースあります。

サービスダウンは数十分～数時間

サービスダウン時間比較

12

障害復旧からの流れ 高可用性システム編

高可用性システムの場合は障害発生を検知するとフェールオーバを行い、待機系でサービスの起動を行います。 これによりサービスのダウンタイムは少なく、数十秒～数分でサービスを復旧することができます。 また、仮にクラウド上でクラウドサービス基盤側のHypervisorで何か作業があっても別Hypervisor上でサービスしていればダウンタイムが少なくなります。

サービスダウン時間比較

13

障害復旧からの流れ 高可用性システム編

高可用性システムの場合は障害発生を検知するとフェールオーバを行い、待機系でサービスの起動を行います。 これによりサービスのダウンタイムは少なく、数十秒～数分でサービスを復旧することができます。 また、仮にクラウド上でクラウドサービス基盤側のHypervisorで何か作業があっても別Hypervisor上でサービスしていればダウンタイムが少なくなります。

サービスダウンは数十秒～数分

構成概要

14

Softlayer上で高可用性システムを構築する場合の構成概要

Active機 192.168.0.11

DRBD同期 クラスタ切り替え

Standby機 192.168.0.12

VIP 192.168.0.10

Virtual Server Virtual Server

データセンター(東京)

ソフトウェア

15

DRBD/Heartbeat/Pacemaker３つのソフトウェアを組み合わせて実現します。

Active機、Standby機共にインストールし、基本的にはまったく同一の設定をします。

高可用性を実現するソフトウェア

ソフトウェア

16

DRBD

サーバデータをリアルタイムにリプリケーション(複製)します。

ブロック単位でリプリケーションするため、ファイルシステムに影 響を受けません。xfs,ext3,ext4などは何でもOKです。

Heartbeat

Active機、Standby機で、相互監視を行います。

Pacemaker

リソースエージェントを使いActive機、Standby機の 制御を行います。

ソフトウェア

17

Active機、Standby機の制御を行います。 例えばMYSQLサーバでActive機側で障害が発生したとします。

その際はActive機側のMYSQLを停止、次にStandby側のMYSQLを起動させ、処理を継続します。

リソースエージェント

ソフトウェア

18

Active機、Standby機の制御を行います。 例えばMYSQLサーバでActive機側で障害が発生したとします。

その際はActive機側のMYSQLを停止、次にStandby側のMYSQLを起動させ、処理を継続します。

リソースエージェント

リソースエージェントは

サービスレベルの監視、制御

クラウド環境（仮想化環境）でのHAはOSレベルで監視、制御している。

リソースエージェント

19

DRBD同期

例えばMYSQLサーバの高可用性システム

Active機 Standby機

MYSQL起動中 MYSQL停止中

リソースエージェント

20

DRBD同期

例えばMYSQLサーバの高可用性システム

Active機 Standby機

MYSQL起動中 MYSQL停止中

障害発生

リソースエージェント

21

フェールオーバー

で切り替え

例えばMYSQLサーバの高可用性システム

Active機→Stanbdy機 Standby機→Active機

MYSQL停止中 MYSQL起動中

障害発生

データはリアルタイムで同期しているため、継続して障害発生前と同じ状態で使えます。

リソースエージェント

22

対応アプリケーション Apache

Postfix

Oracle

Postgresql

MySQL

NFS

サイボウズOffice

IPaddr2 (VIP)

その他のリソースエージェントに関しては以下を参照ください

https://www.3ware.co.jp/product/linbit-cluster-support/resource

災害対策

23

災害対策を考える

高可用性システムによりサービスダウン時間の低下は可能になりました。 しかし災害が発生し、Active機、Standby機サーバが共に故障した場合にはサービスの継続ができません。

災害対策

24

災害対策を考える

高可用性システムによりサービスダウン時間の低下は可能になりました。 しかし災害が発生し、Active機、Standby機サーバが共に故障した場合にはサービスの継続ができません。

遠隔地へデータ保存

災害対策

25

災害対策を考える

高可用性システムによりサービスダウン時間の低下は可能になりました。 しかし災害が発生し、Active機、Standby機サーバが共に故障した場合にはサービスの継続ができません。

遠隔地へデータ保存

構成概要

26

サーバ

DRBD Proxy リプリケーション

Active機

VPN

ローカルDC

192.168.0.20

Standby機

Virtual Server

データセンター(東京)

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

DRBD Proxyによる災害対策

27

DRBD Proxy

遠隔地へサーバデータをリアルタイムにリプリケーション(複製) するために使用されます。 リプリケーション時にデータを圧縮することにより遅延(レイテン シ)を少なくし効率よく同期できます。

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

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

sales@3ware.co.jp

災害対策を実現するソフトウェア

DRBD Proxyによる災害対策

28

対応アプリケーション リソースエージェントを使用しないために基本的に

Linuxサーバなら構築可能です。

参考例

29

WAN

KVM

Red Hat Enterprise Linux Windows Server

+ DRBD Proxy

KVM

Red Hat Enterprise Linux Windows Server

+ DRBD Proxy

既存データセンター(MAIN)

Windowsを活用しDRBD領域を複数設定する例になります。

資料ダウンロード

30

https://www.3ware.co.jp

Softlayerを使った詳しい高可用性システムの構築手順を弊社ホームページにてホワイトペーパーとして公開中です。是非ご活用ください。

資料ダウンロード

31

弊社ホームページより ダウンロード → ホワイトペーパーをクリックします。 「検証レポート、HOWTO」項目に該当資料があります。

・SoftLayer上でのLinux-HAクラスタ構築手順書

資料ご案内

ハンズオン

32

日時 3月16日 (月)

13:00～18:00

受講料 無料

場所 @HZ

申し込み Connpass

Softlayer上でDRBDを使用した高可用性システムを構築

参考情報

Bacula

34

DRBDとDRBD Proxyは

オペーレーションミスに

対応していません。

申し訳ございません

Bacula

35

DRBD同期

例えば

Active機 Standby機

Active機で「rm –rf /etc」なんてコマンドを間違って実行！

Bacula

36

データ削除を同期

例えば

Active機 Standby機

当然Standby機側でもデータが削除されます。

削除されたデータは帰ってきません。

Bacula

37

バックアップは重要！

Bacula

38

オープンソースであり世界で一番

ダウンロードされている

バックアップソフト「Bacula」

オープンソースバックアップカンファレンス

39

Baculaの詳しいご紹介をさせていただきます。 http://connpass.com/event/11546/

ハッシュタグ#ossbk

End

40

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