クラスタリングについて#

▶ Watch on YouTube

全体のワークロードを複数のサーバに分散するため、 LXD はクラスタリングモードで動かせます。 このシナリオでは、クラスタメンバーとそのインスタンスの設定を保持する同じ分散データベースを任意の台数の LXD サーバで共有します。 LXD クラスタは lxc クライアントまたは REST API を使って管理できます。

この機能は clustering API 拡張の一部として導入され、 LXD 3.0 以降で利用可能です。

Tip

ベーシックなLXDクラスタを素早くセットアップしたい場合、MicroCloudをチェックしてみてください。

クラスタメンバー#

LXD クラスタは 1 台のブートストラップサーバと少なくともさらに 2 台のクラスタメンバーから構成されます。 クラスタは状態を 分散データベース に保管します。これは Raft アルゴリズムを使用して複製される Dqlite データベースです。

2 台のメンバーだけでもクラスタを作成することは出来なくはないですが、少なくとも 3 台のクラスタメンバーを強く推奨します。 このセットアップでは、クラスタは少なくとも 1 台のメンバーの消失に耐えることができ、分散状態の過半数を確立できます。

クラスタを作成する際、 Dqlite データベースは 3 番目のメンバーがクラスタにジョインするまではブートストラップサーバ上でのみ稼働します。 そして 2 番目と 3 番目のサーバはデータベースの複製を受信します。

詳細は クラスタを形成するには を参照してください。

メンバーロール#

3 台のメンバーのクラスタでは、全てのメンバーがクラスタの状態を保管する分散データベースを複製します。 クラスタのメンバーがさらに増えると、一部のメンバーだけがデータベースを複製します。 残りのメンバーはデータベースへアクセスしますが、複製はしません。

任意の時点で、選出されたリーダーが 1 つ存在し、他のメンバーの健康状態をモニターします。

データベースを複製する各メンバーは voter か stand-by のロールを持ちます。 クラスタリーダーがオフラインになると voter の 1 つが新しいリーダーに選出されます。 voter のメンバーがオフラインになると stand-by メンバーが自動的に voter に昇格します。 データベース (そしてクラスタ) は voter の過半数がオンラインである限り利用可能です。

以下のロールが LXD クラスタメンバーに割り当て可能です。 自動のロールは LXD 自身によって割り当てられユーザによる変更は出来ません。

ロール

自動

説明

database

yes

分散データベースの voter メンバー

database-leader

yes

分散データベースの現在のリーダー

database-standby

yes

分散データベースの stand-by (voter ではない) メンバー

event-hub

no

内部 LXD イベントへの交換ポイント (hub) (最低 2 つは必要)

ovn-chassis

no

OVN ネットワークのアップリンクゲートウェイの候補

voter メンバーのデフォルトの数 (cluster.max_voters) は 3 です。 stand-by メンバーのデフォルトの数 (cluster.max_standby) は 2 です。 この設定では、クラスタを稼働したまま一度に最大で 1 つの voter メンバーの電源を切ることができます。

詳細は クラスタを管理するには を参照してください。

オフラインメンバーと障害耐性#

クラスタメンバーがダウンして設定されたオフラインの閾値を超えると、ステータスはオフラインと記録されます。 この場合、このメンバーに対する操作はできなくなり、全てのメンバーの状態変更を必要とする操作もできなくなります。

オフラインのメンバーがオンラインに戻るとすぐに操作が再びできるようになります。

オフラインになったメンバーがリーダーそのものだった場合、他のメンバーは新しいリーダーを選出します。

サーバを再びオンラインに復旧できないあるいはしたくない場合、クラスタからメンバーを削除 できます。

応答しないメンバーをオフラインと判断する秒数は cluster.offline_threshold 設定で調整できます。 デフォルト値は 20 秒です。 最小値は 10 秒です。

詳細は クラスタを復旧するには を参照してください。

failure domain#

オフラインになったメンバーにロールを割り当てる際に、どのクラスタメンバーを優先するかを指示するために failure domain を使用できます。 例えば、現在データベースロールを持つクラスタメンバーがシャットダウンした場合、 LXD はデータベースロールを同じ failure domain 内の別のクラスターメンバーがあればそれに割り当てようとします。

クラスタメンバーの failure domain を更新するには、 lxc cluster edit <member> コマンドを使って failure_domain プロパティを default から他の文字列に変更します。

メンバー設定#

LXD クラスタメンバーは一般的に同一のシステムと想定されています。 それはクラスタにジョインする全ての LXD サーバはブートストラップサーバとストレージプールとネットワークについて同一の設定を持つ必要があるということです。

少し異なるディスクの順序やネットワークインタフェースの名前付けのようなことに対応するため、ストレージとネットワークに関連してメンバー固有のいくつかの設定が例外的に用意されています。

クラスタ内にそのような設定が存在する場合、追加するサーバにはそれらの設定に対する値を提供する必要があります。 たいていの場合、これはインタラクティブな lxd init コマンドで実行され、ユーザにストレージやネットワークに関連する設定の値の入力を求めます。

通常これらの設定には以下のものが含まれます。

  • ストレージプールのソースデバイスとサイズ

  • ZFS プール、 LVM thin pool、または LVM ボリュームグループの名前

  • ブリッジネットワークの外部インタフェースと BGP の next-hop

  • 管理された physical または macvlan ネットワークの親のネットワークデバイス名

詳細は クラスタのストレージを設定するには と クラスタのネットワークを設定するには を参照してください。

事前に質問を調べたい (スクリプトでの自動化に有用) 場合、 /1.0/cluster API エンドポイントをクエリしてください。 これは lxc query /1.0/cluster あるいは他の API クライアントを使って実行できます。

イメージ#

デフォルトでは、 LXD はデータベースメンバーと同じ数のクラスタメンバーにイメージを複製します。 通常これはクラスタ内で最大 3 つのコピーを持つことを意味します。

障害耐性とイメージがローカルで利用できる確率を改善するためこの数を増やすことができます。 そのためには、 cluster.images_minimal_replica 設定を変更してください。 すべてのクラスタメンバにイメージをコピーするには -1 という特別な値を使用できます。

クラスタグループ#

LXD のクラスタではクラスタグループにメンバーを追加できます。 これらのクラスターグループは、全ての利用可能なメンバーのサブセットに属するクラスタメンバー上で、インスタンスを起動するのに使用できます。 例えば、GPU を持つ全てのメンバーからなるクラスタメンバーを作って、GPU が必要な全てのインスタンスをこのクラスタグループ上で起動できます。

デフォルトでは、全てのクラスタメンバーは default グループに属します。

詳細は クラスタグループをセットアップするには と 特定のクラスタメンバー上でインスタンスを起動する を参照してください。

インスタンスの自動割り当て#

クラスタのセットアップでは各インスタンスはクラスタメンバーの 1 つの上で稼働します。 インスタンスを起動する際、特定のクラスタメンバー、クラスターグループをターゲットにするか、あるいは LXD に自動的にどれかのクラスタメンバーに割り当てさせることもできます。

デフォルトでは、自動的な割り当てはインスタンス数が一番少ないクラスタメンバーを選択します。 複数のメンバーが同じインスタンス数の場合は、それらの 1 つがランダムで選ばれます。

しかし、この挙動を scheduler.instance 設定で制御することもできます。

  • クラスタメンバーの scheduler.instance が all に設定されると、以下の条件でこのクラスタメンバーが選ばれます。

    • インスタンスが --target を指定せずに作成され、かつクラスタメンバーのインスタンス数が最小である。

    • インスタンスがこのクラスタメンバー上で稼働するようにターゲットされた。

    • インスタンスがこのクラスタメンバーが所属するクラスタグループのメンバー上で稼働するようにターゲットされ、かつクラスタメンバーがそのクラスタグループの他のメンバーと比べてインスタンス数が最小である。

  • クラスタメンバーの scheduler.instance が manual に設定されると、以下の条件でこのクラスタメンバーが選ばれます。

    • インスタンスがこのクラスタメンバー上で稼働するようにターゲットされた。

  • クラスタメンバーの scheduler.instance が group に設定されると、以下の条件でこのクラスタメンバーが選ばれます。

    • インスタンスがこのクラスタメンバー上で稼働するようにターゲットされた。

    • インスタンスがこのクラスタメンバーが所属するクラスタグループのメンバー上で稼働するようにターゲットされ、かつクラスタメンバーがそのクラスタグループの他のメンバーと比べてインスタンス数が最小である。