heartbeat+DRBD+sambaでWindowsファイルサーバを二重化する

はじめに

　前回は、DRBDとheartbeatを使ったクラスタシステムの具体的な構成事例として、メールサーバクラスタを取り上げました。今回はそれに引き続き、2つめの構成事例として、sambaを使ってWindowsファイルサーバを二重化する方法を紹介します。

Windowsファイルサーバの課題

　ファイルサーバは、ネットワークの中でファイルを共有するためのサーバです。最近では、PCは様々な用途で利用され、様々なデータがファイルとして蓄積されます。このファイルをネットワークで共有することで、組織やチームの中で情報や作業の共有を図ることのメリットは、ますます大きくなりつつあります。

　Windowsでファイル共有を利用する場合には、WindowsやWindows Serverなどで提供されるCIFS（Common Internet File System）の機能を利用します。Sambaを使うと、この機能をLinuxで実現することもできます。LinuxでWindowsファイル共有を行うと、Windows Serverのクライアントライセンスに依存せずに、ファイル共有の環境を作ることができるメリットがあります。さらに、本コーナーで紹介しているheartbeatとDRBDのクラスタを使うと、データを二重化し、止まりにくいファイルサーバを実現することができます。これにより、重要なデータの紛失を防ぎ、ファイルサーバの故障による影響を最小限にすることができます。ただ、Windowsファイルサーバをクラスタ化するためには、次のような課題をクリアする必要があります。

Windowsファイルサーバをクラスタ化するための課題

• サーバ間でのデータの引継ぎ

  　障害でサーバが切り替わっても、サーバ上に保管されたファイルを継続して利用することができないと、ファイルサーバとして役に立ちません。したがって、単純に二台のサーバを並べて、負荷分散装置などで冗長化する構成では目的を達成することができません。

• ユーザ認証データの引継ぎ

  　通常のアクティブ・スタンバイ型のクラスタでは、システム部分は二重化されていません。そのため、各システムのユーザは別々のパスワードファイルで管理されています。

  　Sambaは標準では、ファイルを保管する場合にシステムユーザの権限も利用しますので、稼動系と待機系には毎回同じユーザとパスワードを登録しなければなりません。これでは、管理面が非常に面倒になってしまいます。

構成例

　これらの課題は、前回取り上げたメールクラスタとほとんど同じものです。サーバ間でのデータの引継ぎは、前回と同じようにDRBDを使うことで解決します。しかし、ユーザ認証データの管理では、PostfixやDovecotのように特別なユーザ認証ファイルをDRBD領域に作成するという方法を取ることができません。そのため、今回は、ユーザ認証データをLDAPサーバと連携して管理する方法について解説します。

今回の構成イメージ