OSSで実現するハイブリッドクラウド4ノードクラスタ～Pacemakerのチケット機能で災害対策～

OSSで実現するハイブリッドクラウド4ノードクラスタ

～Pacemakerのチケット機能で災害対策～

サードウェア技術部小町哲也

株式会社サードウェア設立　　　　　　 1997 年 2 月 7 日

事業内容　　　インターネット / イントラネット活用のための総合的な支援サービス　 Linux オープンソース・ソフトウェアのサポート　コンピュータ・セキュリティのコンサルテーション

DRBD 開発元の LINBIT 社の国内総代理店

Bacula 開発元の Bacula Systems 社の国内総代理店監視サービス

Bacula Enterprise

Edition

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

copyright © 2016 thirdware.Inc

OSS でダウンタイムが最小限になる災害にも強いシステムをつくる方法

本日の内容


リアルタイム同期

リソース自動管理ディスク同期


紹介する構成


目次

1. HA クラスタと DR システムの必要性2. 使用ソフトの機能と構成の説明3. 構築の流れ4. 遠距離レプリケーションを速くする方法


1.HA クラスタと DR システムの必要性


HA クラスタ

ホットスタンバイ

　　　↓片系に障害が発生しても、すぐにもう片系で処理を引き継ぐ

HA クラスタの高可用性



安全な場所

別のサイトにサーバを設置し、メインサイトとデータ同期しておく

　　　　　　　　　↓

・リアルタイムのデータ保護・サイト全体が壊滅してもわずかな　ダウンタイムでサービス継続

即時復旧できる災害対策システム



Pacemaker ・・・リソースを制御するOSS

Corosync ・・・クラスタを制御するOSS

DRBD ・・・データ同期する OSS

コスト圧縮



以上の３つに加えて、

今回は既存環境の DR サイトはクラウド上に作成します。災害対策として意味があり、かつ国内データセンターである、西日本データセンターのある Microsoft Azure を利用します。

クラウド利用でハードルを下げる





紹介する構成





紹介する構成

相互に独立した系のHA クラスタ

※ 災害復旧切り替えは人間系DR サイト

メインサイト


2. 使用ソフトの機能と構成の説明


Pacemaker チケット機能 <1.1.6-1 以降 > を使用します。

指定のリソースが、サイト内にチケットがある時だけ起動できるようにします。（チケットとリソースの起動に依存関係を持たせる )

チケットをサイトに与える / 取り上げると、系が切り替えられます。

チケットを使用して系切り替え


DRBD のスタックデバイスを使用します。

DRBD(Duplicated Replicated Block Device) ･･･ブロックデバイスを複製するソフトウェア。ネットワーク越しのRAID 1 のイメージ。ファイルシステムよりも下位のレイヤーで動作ファイルシステムやアプリケーションに依存しない。そのまま 1つのディスクのように扱える。プライマリ ( コピー元 ) とセカンダリ ( コピー先 )

スタックデバイス・・・DRBD デバイスをスタック ( 積み重ね ) して作成する上位のDRBD デバイス

Primary

スタックデバイスの同期でサイト間同期

Secondary

Primary

Secondary


DRBD のスタックデバイスを使用します。

DRBD(Duplicated Replicated Block Device) ･･･ブロックデバイスを複製するソフトウェア。ネットワーク越しのRAID 1 のイメージ。ファイルシステムよりも下位のレイヤーで動作ファイルシステムやアプリケーションに依存しない。そのまま 1つのディスクのように扱える。プライマリ ( コピー元 ) とセカンダリ ( コピー先 )

スタックデバイス・・・DRBD デバイスをスタック ( 積み重ね ) して作成する上位の DRBDデバイス

Primary

スタックデバイスの同期でサイト間同期

Secondary

Primary

Secondary


ticket

D2 L2L1

DR サイトメインサイト

pacemakercorosync

Primary SecondaryDRBD r0 　

corosyncpacemaker

DRBD r0 　

corosync

PrimaryDRBD r0 　

pacemaker

DRBD rS 　Secondar

y

pacemaker corosync

SecondaryDRBD r0 　

vip DRBD rS 　Primary

MariaDB

D1

データ同期リソース管理

通常時


サービス

vip

データ同期

※ 今回紹介する構成と細部は異なります。


DR サイト

PrimaryDRBD r0 　Secondary

DRBD r0 　

D1

メインサイト壊滅

L2L1

PrimaryDRBD r0 　

DRBD r0 　


メインサイト

D2

ticket

pacemakercorosync

Secondary

corosyncpacemakercorosync pacemakerpacemaker corosync


サービス

DRBD rS 　Primary

vip

MariaDB


MariaDB


ticketDR サイト

DRBD r0 　Secondary

DRBD r0 　

DRBD rS 　

MariaDB

Primary

Primary


DR サイトの D2 がフリーズ

D2 L2L1

メインサイト

PrimaryDRBD r0 　 DRBD

r0 　


D1

vip

pacemakercorosync

Secondary

corosyncpacemakercorosync pacemakerpacemaker corosync

サービス


MariaDB


3. 構築の流れ


1. メインサイト構築2.DR サイト構築

・ Azure での構成上のポイント3. 各パッケージインストール4.DRBD 設定5.Pacemaker 、 Corosync 設定6. スタックリソース作成7. リソース設定

mysql-file

vipproxy

proxyr0 Masterr1 Master

rS Master

mysql

r0 slaver1 Slave

DR メイン

rS Slavemysql-file

mysql

proxyrS

mysql-filemysql mysql-file

proxyrS

mysql

この構成を作る流れです




2 台のマシンを構築

・ CentOS 7.2・ DRBD 用のパーティション・ DRBD のレプリケーション用 NIC( インターコネクト )・ Corosync のハートビート用 NIC ( インターコネクト )・外部通信用の NIC

DR メイン




リソースマネージャーモデルで構築（クラシックモデルでも可能）

・西日本に仮想ネットワークを作成　 ( リソースグループも作成 )　　　　　　　↓・可用性セットを作成　 ( 作成済リソースグループ使用 )　　　　　　　↓・ Virtual Machine2 台作成 (CentOS Based7.0)　 ( 作成済リソースグループと可用性セット使用 )　※作成後、 CentOS 7.2 にアップデート　　　　　　　↓・ロードバランサ作成上記 2 マシンを接続、プローブ規則作成

DR メイン




プローブの補足

DR メイン




　 # yum install drbd kmod-drbd linbit-cluster-stack-corosync2

公開しているソースからビルドしたり、無料の rpm パッケージをダウンロード等いろいろありますが、

LINBIT 公式パッケージを使うのが一番安全で楽です。（有償）

r0r1 r0r1

DR メイン




　 # yum install drbd-proxy 　 mariadb-server

なお、今回は遠距離レプリケーションを効果的に行うためのソフトウェア、 DRBD Proxy （プロプライエタリ）もインストールします。

また、リソースとなる MariaDB もインストールします。※Pacemaker 上では MySQL と同じ扱い

proxyproxy

r0 r1

mysql

r0r1

DR メイン

mysql

proxy

mysql

proxy

mysql




DRBD リソースを定義するファイル（リソース名 .res ）を各マシンに置く

・メインサイトの 2 台のリソースファイル(r0.res)・ DR サイトのリソースファイル (r1.res)・スタックリソースのファイル (rS.res)計 3 つを、 4 台のマシンすべてに配置

↓r0 、 r1 のメタデータを作成

↓DRBD 起動・初期同期

↓いったん停止

vipproxy


rS

mysql

r0 slaver1 Slave

DR メイン

rS

mysql

proxyrS

mysql

proxyrS

mysql


# cat /etc/drbd.d/r0.res

resource r0 { net{ protocol C; } on haticket1 { device /dev/drbd0; disk /dev/sdb1; address 10.0.0.1:7788; meta-disk internal; }

on haticket2 { device /dev/drbd0; disk /dev/sdb1; address 10.0.0.2:7788; meta-disk internal; }}

# cat /etc/drbd.d/rS.res

resource rS { net{ protocol A; } proxy { memlimit 500M; compression on; } stacked-on-top-of r0 { device /dev/drbd10; address 127.0.0.1:7790; proxy on haticket1 haticket2 { inside 127.0.0.1:7791; outside 10.30.102.80:7792; } } stacked-on-top-of r1 { device /dev/drbd10; address 127.0.0.1:7790; proxy on haticket3 haticket4 { inside 127.0.0.1:7791; outside 10.30.102.79:7792; } }}

リソースファイルの例


1. ローカルサイト構築2.DR サイト構築


Corosync の設定ファイルを作成↓

Corosync 、 Pacemaker 起動↓

Pacemaker は設定を対話モードで投入（事前の設定ファイルはない）

↓リソース起動の依存関係を設定

r0 Master rS Master

チケット

vip mysql-file mysql

※DRBD領域マウント

drbd-proxy

※DR側は VIP リソースなし

←今はここまで

vipproxy


rS

mysql

r0 slaver1 Slave

DR メイン

rS

mysql

proxyrS

mysql

proxyrS

mysql




ローカルサイトと DR サイト両方のマスター側のマシンでスタックリソース rS のメタデータを作成

↓起動、初期同期

↓ファイルシステム作成 (xfs)

mysql-file

vipproxy


rS Master

mysql

r0 slaver1 Slave

DR メイン

rS Slavemysql-file

mysql

proxyrS


proxyrS

mysql




リソース起動の依存関係の続きを設定します

r0 Master rS Master

チケット

vip mysql-file mysql

※DRBD領域マウント

drbd-proxy

mysql-file

vipproxy


rS Master

mysql

r0 slaver1 Slave

DR メイン

rS Slavemysql-file

mysql

proxyrS


proxyrS

mysql


切り替えの様子


4. 遠距離レプリケーションを速くする方法


遅延……

WAN での同期には限界がある

帯域幅……

LAN WAN LAN

WAN

時間


・転送するデータを圧縮をする

・スタックリソースの同期は、非同期レプリケーション　自機のディスクへの書き込み +TCP送信バッファに送信で書き込み完了とする　　　　　　　　　　　　　　　　　　　 ↓速度の安定しない回線でも、転送用のバッファーを設けることでボトルネックを回避できる

長距離 WAN での DRBD 使用のために作られたDRBD Proxy を使う

遠距離での DRBD 同期を速くするには？


50Mbps 環境における DRBD による DR 環境と DRBD Proxy による DR 環境との性能比較

DRBD Proxy を使用することで、 10倍以上の性能向上

4. 遠距離レプリケーションを速くする方法

なし 5 10 20 50 1000

1000

2000

3000

4000

5000同期なし DRBD Proxy なし同期 DRBD Proxy あり同期

ネットワークレイテンシ（ミリ秒）

トランザ

クション

毎分（t

pm）


今回の構成の詳細な構築手順は、後日サードウェアのホームページからダウンロードできます。https://www.3ware.co.jp/

その他、・各種構成のホワイトペーパー・ DRBD の日本語マニュアルも公開しています。


事例紹介：アイル様

導入効果・ 100 ギガバイトの新規バックアップが 4 時間ですむ (25GB/ 時間 )・日次バックアップを自動化できた・ Samba サーバによりバックアップデータの確認や非定型処理に対応・他社提示の 1000 万円→ 400 万円以下という圧倒的な低コスト　での導入を実現


350 テラバイトのファイルサーバ事例

導入効果• 200Mbps の IPsec VPN帯域をほぼフルに使い切るレプリケーションを実現• エンタープライズストレージより 1桁安価なコスト• 「外部データセンター」側でも被災時に代替システム起動可能に


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

一部のアイコンは以下から入手

http://www.flaticon.com/copyright © 2016 thirdware.Inc

Software

OSSで実現するハイブリッドクラウド4ノードクラスタ ～Pacemakerのチケット機能で災害対策～

OSSで実現するハイブリッドクラウド4ノードクラスタ～Pacemakerのチケット機能で災害対策～