検索
連載

今さら聞けない、「Sambaサーバーの冗長化」をDRBDでサクッと実現してしまう方法DRBDの仕組みを学ぶ(4)(1/4 ページ)

サービスを止めてはならない環境で活躍する冗長化支援ツール「DRBD」。今回は、利用頻度が高い「Sambaサーバー」をDRBDで冗長化して運用する方法をイチから解説します。

PC用表示 関連情報
Share
Tweet
LINE
Hatena

連載バックナンバー

 前回まで、DRBD(Distributed Replicated Block Device)の基礎と概要、よく使われるDRBDの例である「高可用性システムの場合」と「災害対策システムの場合」の運用イメージを解説しました。しかし、高可用性システムとなると、自分の担当ではなかったり、規模が大きすぎて運用イメージがなかったりする人がいたかもしれません。

 では、「Sambaファイルサーバーを冗長化する」ならばいかがでしょう。



 今回は、こういったより身近な運用シーンからまずは「即導入」し、今後、自然災害などで被害を受けたシステムを復旧・修復する「DR(ディザスタリカバリ)」対策まで含めてイメージできるよう、OSの準備からDRBDのインストール手順、設定ファイルの記述方法と解説、構築や運用テクニックまで、順を追って説明します。

 今回の構成イメージを図1に示します。二台のSambaサーバーのうち、メインの一号機(ホスト名:drbd-one)を「プライマリ機」に、他方の二号機(ホスト名:drbd-two)を「セカンダリ機」として、二重化する構成です。サーバーのOSはCentOS 7かCentOS 6、DRBDはバージョン8.4を使って解説します。

photo 図1 今回構築するDRBD×Sambaサーバー冗長化システムの構成図

 ユーザーは普段、プライマリ機である一号機へアクセスしてファイルを保存します。一号機へ保存されたファイルは、DRBDによってリアルタイムにレプリケーション(複製)され、セカンダリ機である二号機にも保存されます。なお、この例ではそれぞれのSambaサーバーの共有領域(ファイルの保存先)を「/home/share」とし、共有名を「Share」にしています。こちらは、自身が運用するSambaサーバーの設定に応じて読み替えてください。

 ネットワーク構成は以下の通りです。インターフェース名はよく使われるeth0、eth1の記述を用いますが、CentOS 7では「enXXX」のようになります。CentOS 7で運用する人は、同じく読み替えてください。

インターフェース 一号機:drbd-one(プライマリ機) 二号機:drbd-two(セカンダリ機) 用途
eth0 192.168.0.11 192.168.0.12 サービス用LAN
eth1 10.0.0.1 10.0.0.2 DRBD同期用

 ネットワークインターフェースは2系統用意します。eth0はSambaサーバーへアクセスするためのサービス用インターフェースで、もう一つのeth1は、DRBDのレプリケーション(同期)用インターフェースです。1系統でも運用は可能ですが、どちらかが帯域を占有してしまうのを防ぐためにも、分けることを推奨しています。

 障害発生時は図2のようになります。

photo 図2 障害発生時のイメージ

 一号機に障害が発生したら、システム上のプライマリ機とセカンダリ機を切り替えます。つまり、二号機をプライマリ機にします。DRBDによって二号機にも障害が発生する直前までデータが同期されているので、ユーザーは192.168.0.12へアクセスすることで、障害発生直前の状態から再開できることになります。

 なお、この切り替えは自動化も可能です。自動で切り替える際はVIP(Virtual IP Address)を使いますのでIPアドレスの変更も不要になります。切り替えの自動化にはDRBDの他に「Pacemeker」「Corosync」というソフトウエアを併用して運用します。こちらの運用テクニックは、次回以降で解説する予定です。なお、それぞれのソフトウエアの詳細はバックナンバー「高可用性システムで、DRBDをどう活用するか」でも解説しましたので、併せてご覧下さい。



 では、次のページから「実装の手順」とテクニックを紹介します。

Copyright © ITmedia, Inc. All Rights Reserved.

       | 次のページへ
ページトップに戻る