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

連載バックナンバー

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

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

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

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

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

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

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

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

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

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

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

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

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