335.2 クラスタファイルシステム

今回は300試験の試験範囲から「335.2 クラスタファイルシステム」についての例題を解いてみます。

■トピックの概要
このトピックの内容は以下の通りです。

＜390.1 OpenLDAPのレプリケーション＞
重要度 3

＜説明＞
OpenLDAPで利用可能なサーバのレプリケーションに習熟していること。

＜主要な知識範囲＞
・レプリケーションの概念
・Open LDAPのレプリケーションの設定
・レプリケーション ログファイルの分析
・レプリカ ハブの理解
・LDAPの参照
・LDAP同期のレプリケーション

＜重要なファイル、用語、ユーティリティ＞
・マスターサーバとスレーブサーバ
・マルチマスターレプリケーション
・コンシューマー
・レプリカハブ
・ワンショットモード
・referral
・syncrepl
・PULL型レプリケーションとPUSH型レプリケーション
・refreshOnlyとrefreshAndPersist
・replog

■例題
OpenLDAPのレプリケーションの説明として間違っているものを選びなさい。

1. コンシューマーが多数ある場合、レプリカハブを用意することで負荷を低減できる
2. スレーブサーバがマスターサーバに接続して差分データを取得する
3. マルチマスターレプリケーションではデータの整合性が取れなくなる可能性がある
4. refreshAndPersistを設定すると複製したデータが永続化される

※この例題は実際のLinuC試験とは異なります。

ディレクトリのデータを複数のOpenLDAPサーバで保持し、利用したい場合にレプリケーションを構成します。

データの更新はマスターサーバで行われ、スレーブサーバはマスターサーバから更新情報を取得して自分のデータを変更していきます。このようにマスタースレーブ方式で構成するのが一般的な方法です。マスターのことを「プロバイダー」、スレーブのことを「コンシューマー」とも呼びます。

プロバイダーとコンシューマーは1対多の関係になるため、コンシューマーの数が多いとマスターサーバの負荷が高くなります。このような時には、マスターとスレーブの間をつなぐ「レプリカハブ」を用意し、レプリカハブが取得したデータをさらにコンシューマーに渡すような、多段構成でマスターサーバの負荷を低減することも可能です。

マスターのデータ更新に関する冗長性を高めたい場合、Active-Activeなマルチマスターレプリケーションを構成できます。ただし、同じデータに対して同時に更新を行った時に発生する「更新競合」を解決することができないので、通常運用時は片方だけをマスターとして利用し、障害が発生した時にもう一方のマスターを有効にするなど、あくまで障害発生時のデータ更新継続性を想定した構成・運用が必要になります。

コンシューマーがデータ更新のためにマスターに接続する際、接続・更新を行った後に接続を切断するrefreshOnlyと、接続を継続して適宜更新を継続するrefreshAndPersistの、2つの設定が選択できます。データ更新の頻度やより最新の同期状態にしておきたいかなど、必要に応じて設定を変えるとよいでしょう。