適用項目 SUSE Linux Enterprise High Availability 15 SP6

26 Sambaクラスタリング #

クラスタ対応のSambaサーバは、異種混合ネットワークにHigh Availabilityソリューションを提供します。この章では、背景情報とクラスタ対応Sambaサーバの設定方法を説明します。

26.1 概念の概要 #

TDB (Trivial Database)は、長年にわたって、Sambaによって使用されてきました。TDBでは、複数のアプリケーションが同時に書き込むことができます。すべての書き込み操作を正常に実行し、互いに衝突させないため、TDBは、内部ロッキングメカニズムを使用しています。

CTDB (Cluster Trivial Database)は、既存のTDBの小規模な拡張です。CTDBは、プロジェクトによって、「一時データの保存のために、Sambaなどのプロジェクトによって使用されるTDBデータベースのクラスタ実装」として説明されています。

各クラスタノードは、ローカルCTDBデーモンを実行します。Sambaは、そのTDBに直接書き込むのではなく、そのローカルCTDBデーモンと通信します。それらのデーモンは、ネットワークを介してメタデータを交換しますが、実際の読み取り/書き込み操作は、高速ストレージでローカルコピー上で行われます。CTDBの概念は、図26.1「CTDBクラスタの構造」に表示されています。

注記: Samba専用CTDB

CTDBリソースエージェントの現在の実装では、Sambaの管理のためだけにCTDBを設定します。他の機能(IPフェールオーバーなど)はすべて、Pacemakerで設定する必要があります。

CTDBは、同種のクラスタに関してのみサポートされます。たとえば、クラスタのすべてのノードが同じアーキテクチャを持つ必要があります。x86とAMD64を混合することはできません。

図 26.1: CTDBクラスタの構造 #

クラスタ対応Sambaサーバは、一定のデータを共有する必要があります。

UnixのユーザとグループIDをWindowsのユーザとグループに関連付けるマッピングテーブル。
ユーザデータベースをすべてのノード間で同期する必要があります。
Windowsドメイン内のメンバーサーバの参加情報をすべてのノードで利用できる必要があります。
メタデータをすべてのノードで利用できる必要があります(アクティブSMBセッション、共有接続、ロックなど)。

クラスタ対応SambaサーバがN+1ノードを持っている場合、Nノードだけのサーバより高速になることを目的としています。1つのノードは、クラスタ非対応のSambaサーバより遅くなることはありません。

26.2 基本的な設定 #

注記: 変更された設定ファイル

CTDBリソースエージェントは、自動的に/etc/sysconfig/ctdbを変更します。crm ra info CTDBを使用して、CTDBリソースに指定できるすべてのパラメータを一覧表示してください。

クラスタ対応Sambaサーバをセットアップするには、次の手順に従います。

手順 26.1: クラスタ対応Sambaサーバの基本セットアップ #

クラスタを準備します。
1. 続行する前にctdb、tdb-tools、およびsambaの各パッケージがインストールされていることを確認します(smbリソースおよびnmbリソースに必要です)。
2. このガイドのパートII「設定および管理」で説明されているように、クラスタ(Pacemaker、OCFS2)を設定します。
3. OCFS2などの共有ファイルシステムを設定し、マウントします(たとえば、/srv/clusterfsにマウント)。詳細については、第21章「OCFS2」を参照してください。
4. POSIX ACLをオンにする必要がある場合は、それを有効にします。
  - 新しいOCFS2ファイルシステムの場合は、次のコマンドを使用します。
    # mkfs.ocfs2 --fs-features=xattr ...
  - 既存のOCFS2ファイルシステムの場合は、次のコマンドを使用します。
    # tunefs.ocfs2 --fs-feature=xattr DEVICE
    ファイルシステムリソースには、必ず、aclオプションを指定します。次のように、crmシェルを使用します。
    crm(live)configure# primitive ocfs2-3 ocf:heartbeat:Filesystem params options="acl" ...
5. サービスctdb、smb、およびnmbが無効になっていることを確認します。
```
# systemctl disable ctdb
# systemctl disable smb
# systemctl disable nmb
```
6. すべてのノードのファイアウォールのポート4379を開きます。これは、CTDBが他のクラスタノードと通信するために必要です。
共有ファイルシステムにCTDBロックのディレクトリを作成します。
```
# mkdir -p /srv/clusterfs/samba/
```
/etc/ctdb/nodesに、クラスタ内の各ノードの全プライベートIPアドレスを含むすべてのノードを挿入します。
```
192.168.1.10
192.168.1.11
```

Sambaを設定します。/etc/samba/smb.confの[global]セクションに次の行を追加します。CTDB-SERVERの代わりに、選択したホスト名を使用します(クラスタ内のすべてのノードは、この名前を持つ1つの大きなノードとして表示されます)。

[global]
    # ...
    # settings applicable for all CTDB deployments
    netbios name = CTDB-SERVER
    clustering = yes
    idmap config * : backend = tdb2
    passdb backend = tdbsam
    ctdbd socket = /var/lib/ctdb/ctdb.socket
    # settings necessary for CTDB on OCFS2
    fileid:algorithm = fsid
    vfs objects = fileid
    # ...

csync2を使用して、設定ファイルをすべてのノードにコピーします。
```
# csync2 -xv
```
詳細については、手順4.9「Csync2による設定ファイルの同期」を参照してください。

CTDBリソースをクラスタに追加します。

# crm configure
crm(live)configure# primitive ctdb CTDB params \
    ctdb_manages_winbind="false" \
    ctdb_manages_samba="false" \
    ctdb_recovery_lock="/srv/clusterfs/samba/ctdb.lock" \
    ctdb_socket="/var/lib/ctdb/ctdb.socket" \
      op monitor interval="10" timeout="20" \
      op start interval="0" timeout="90" \
      op stop interval="0" timeout="100"
crm(live)configure# primitive nmb systemd:nmb \
    op start timeout="60" interval="0" \
    op stop timeout="60" interval="0" \
    op monitor interval="60" timeout="60"
crm(live)configure# primitive smb systemd:smb \
    op start timeout="60" interval="0" \
    op stop timeout="60" interval="0" \
    op monitor interval="60" timeout="60"
crm(live)configure# group g-ctdb ctdb nmb smb
crm(live)configure# clone cl-ctdb g-ctdb meta interleave="true"
crm(live)configure# colocation col-ctdb-with-clusterfs inf: cl-ctdb cl-clusterfs
crm(live)configure# order o-clusterfs-then-ctdb Mandatory: cl-clusterfs cl-ctdb
crm(live)configure# commit

クラスタ対応のIPアドレスを追加します。
```
crm(live)configure# primitive ip IPaddr2 params ip=192.168.2.222 \
    unique_clone_address="true" \
    op monitor interval="60" \
    meta resource-stickiness="0"
crm(live)configure# clone cl-ip ip \
    meta interleave="true" clone-node-max="2" globally-unique="true"
crm(live)configure# colocation col-ip-with-ctdb 0: cl-ip cl-ctdb
crm(live)configure# order o-ip-then-ctdb 0: cl-ip cl-ctdb
crm(live)configure# commit
```
unique_clone_addressがtrueに設定されている場合、IPaddr2リソースエージェントはクローンIDを指定のアドレスに追加し、3つの異なるIPアドレスを設定します。これらは通常必要とされませんが、負荷分散に役立ちます。この項目の詳細については、17.2項「Linux仮想サーバによる負荷分散の設定」を参照してください。
変更をコミットします。
```
crm(live)configure# commit
```

結果を確認します。

# crm status
Clone Set: cl-storage [dlm]
     Started: [ factory-1 ]
     Stopped: [ factory-0 ]
Clone Set: cl-clusterfs [clusterfs]
     Started: [ factory-1 ]
     Stopped: [ factory-0 ]
 Clone Set: cl-ctdb [g-ctdb]
     Started: [ factory-1 ]
     Started: [ factory-0 ]
 Clone Set: cl-ip [ip] (unique)
     ip:0       (ocf:heartbeat:IPaddr2):       Started factory-0
     ip:1       (ocf:heartbeat:IPaddr2):       Started factory-1

クライアントコンピュータからテストを行います。次のコマンドをLinuxクライアントで実行して、システムからファイルをコピーしたり、システムにファイルをコピーできるかどうか確認します。
```
# smbclient //192.168.2.222/myshare
```

26.3 Active Directoryドメインへの追加 #

Active Directory (AD)は、Windowsサーバシステムのディレクトリサービスです。

次の手順は、CTDBクラスタをActive Directoryドメインに追加する方法を概説しています。

手順26.1「クラスタ対応Sambaサーバの基本セットアップ」の説明に従って、CTDBリソースを作成します。
samba-winbindパッケージをインストールします。
winbindサービスを無効にします。
```
# systemctl disable winbind
```

winbindクラスタリソースを定義します。

# crm configure
crm(live)configure# primitive winbind systemd:winbind \
    op start timeout="60" interval="0" \
    op stop timeout="60" interval="0" \
    op monitor interval="60" timeout="60"
crm(live)configure# commit

g-ctdbグループを編集し、winbindをnmbリソースとsmbリソースの間に挿入します。
```
crm(live)configure# edit g-ctdb
```
:–w (vim)でエディタを保存して閉じます。

Active Directoryドメインのセットアップ方法については、Windows Serverのマニュアルを参照してください。この例では、次のパラメータを使用します。

ADおよびDNSサーバ	win2k3.2k3test.example.com
ADドメイン	2k3test.example.com
クラスタADメンバーのNETBIOS名	CTDB-SERVER

手順26.2「Active Directoryへの参加」

最後に、クラスタをActive Directoryサーバに参加させます。

手順 26.2: Active Directoryへの参加 #

次のファイルが、すべてのクラスタホストにインストールされるように、Csync2設定に含まれていることを確認します。
```
/etc/samba/smb.conf
/etc/security/pam_winbind.conf
/etc/krb5.conf
/etc/nsswitch.conf
/etc/security/pam_mount.conf.xml
/etc/pam.d/common-session
```
この作業には、YaSTのCsync2の設定モジュールを使用することもできます。4.7項「すべてのノードへの設定の転送」を参照してください。
YaSTを実行し、ネットワークサービスエントリからWindowsドメインメンバーシップモジュールを開きます。
ドメインまたはワークグループの設定を入力して、OKをクリックして終了します。

26.4 クラスタ対応Sambaのデバッグとテスト #

クライアント対応Sambaサーバのデバッグには、次のツールを使用できます。これらのツールは、さまざまなレベルで動作します。

ctdb_diagnostics

このツールを実行して、クラスタ対応Sambaサーバを診断します。詳細なデバッグメッセージが出力されるので、問題を追跡するのに役立ちます。

ctdb_diagnosticsコマンドは、次のファイルを検索します。これらのファイルは、すべてのノードで利用できる必要があります。

/etc/krb5.conf
/etc/hosts
/etc/ctdb/nodes
/etc/sysconfig/ctdb
/etc/resolv.conf
/etc/nsswitch.conf
/etc/sysctl.conf
/etc/samba/smb.conf
/etc/fstab
/etc/multipath.conf
/etc/pam.d/system-auth
/etc/sysconfig/nfs
/etc/exports
/etc/vsftpd/vsftpd.conf

ファイル/etc/ctdb/public_addressesおよび/etc/ctdb/static-routesが存在する場合、これらもチェックされます。

ping_pong

ping_pongでは、ファイルシステムがCTDBに適合しているかどうかチェックできます。クラスタファイルシステムの一定のテスト(コヒーレンスやパフォーマンスなどのテスト)を実行して(https://wiki.samba.org/index.php/Ping_pong参照)、高負荷の状況下におけるクラスタの動作を示す情報を提供します。

send_arpツールとSendArpリソースエージェント

SendArpリソースエージェントは/usr/lib/heartbeat/send_arp (または/usr/lib64/heartbeat/send_arp)にあります。send_arpツールはGratuitous ARP (余計なアドレス解決プロトコル)パケットを送信し、他のマシンのARPテーブルを更新するために使用できます。これは、フェールオーバープロセス後の通信問題の識別に役立ちます。Sambaのクラスタ化されたIPアドレスを表示しているのにも関わらず、ノードに接続またはpingできない場合は、send_arpコマンドを使用して、ノードはARPテーブルの更新のみが必要であるのかをテストします。

詳細については、https://gitlab.com/wireshark/wireshark/-/wikis/homeを参照してください。

クラスタファイルシステムの特定の側面をテストするには、次の手順に従います。

手順 26.3: クラスタファイルシステムのコヒーレンスとパフォーマンスをテストする #

1つのノードでping_pongコマンドを開始します。プレースホルダNはノード数+1で置き換えます。共有ストレージではABSPATH/data.txtファイルが使用可能で、すべてのノード上でアクセスできます(ABSPATH は絶対パスを示しています)。
```
# ping_pong ABSPATH/data.txt N
```
1つのノードでだけ実行しているので、ロッキングレートは非常に高いと予想してください。プログラムがロッキングレートを出力しない場合は、クラスタファイルシステムを置き換えます。
同じパラメータを使用して、別のノードでping_pongの2つ目のコピーを開始します。
ロッキングレートが大幅に下がることを予想できます。使用しているクラスタファイルシステムに次のどれかが当てはまる場合は、クラスタファイルシステムを置き換えます。
- ping_pongがロッキングレート(秒単位)を出力しない。
- 2つのインスタンスのロッキングレートがほぼ同じではない。
- 2つ目のインスタンスの開始後にロッキングレートが下がらなかった。
ping_pongの3つ目のコピーを開始します。もう1つノードを追加し、ロッキングレートの変化に注目します。
ping_pongコマンドを1つずつキャンセルします。単一ノードの状態に戻るまで、ロッキングレートの増加が観察されるはずです。予想したような振る舞いが見られなかった場合には、第21章「OCFS2」に記されている詳細を参照してください。