TimesTen Kubernetesオペレータによるノード障害の処理方法

Kubernetesは、ノードとポッドの障害を検出して解決するのに適しています。ただし、Kubernetesで障害を解決できない場合があります。Kubernetesクラスタの1つ以上のノード上のポッド内のコンテナに存在するTimesTenデータベースに影響を与える可能性のある例を見てみましょう。その後、TimesTenオペレータがこの状況を検出して適切なアクションを実行するようにするためにできることを検討します。

Kubernetesクラスタで、ローカル・ボリューム・プロビジョナを使用して、ノードで実行されているポッドの永続ストレージとして各Kubernetesノードのストレージを使用できるようにするとします。このアプローチの短所は、あるノード上のストレージが他のノードで使用できないことです。次のシナリオを考えてみます:

• クラスタには3つのノード(ノードA、ノードBおよびノードC)があります。

• TimesTenは、ノードAおよびノードBで実行されています。

• ノードAが停止し、使用できなくなります。

KubernetesはノードAの障害を検出しますが、ノードCで新しいポッドを自動的に作成してTimesTenを実行することはできません。これは、TimesTenで使用される永続ボリュームがノードAに対してローカルであるため、ノードCはこれらの永続ボリュームにアクセスできないためです。その結果、ノードAが停止して使用できない場合、KubernetesはノードCで新しいポッドを作成できません。TimesTenオペレータは、データベースをノードBに正しくフェイルオーバーできますが、ノードAのかわりにはできません。このため、ノードAが復帰するまでクラスタに冗長性はありません。

TimesTenオペレータを構成して、このような状況を検出し、ノードCでTimesTenを再構成して自動的に起動するための適切なアクションを実行できます。

手順は次のとおりです:

TimesTenClassicオブジェクトの.spec.ttspec.deleteDbOnNotReadyNodeデータ項目を使用すると、特定の期間ノードの準備ができていない(または不明な)状況を検出するようにTimesTenオペレータに指示できます。このような場合、.spec.ttspec.deleteDbOnNotReadyNodeが指定されていると、TimesTenオペレータによって、状況を修正するための適切なアクションが実行されます。.spec.ttspec.deleteDbOnNotReadyNodeデータ項目の詳細は、表19-3のdeleteDbOnNotReadyNodeのエントリを参照してください。

これをさらに詳しく見てみましょう。

TimesTenオペレータは、.spec.ttspec.pollingInterval秒ごとに各TimesTenClassicオブジェクトを調整します。この調整中に、TimesTenオペレータは、TimesTenClassicオブジェクトに関連付けられている各ポッドの状態を検査します。また、TimesTenオペレータは、ポッドが実行されているノードの状態も取得します。準備ができていない(または不明な)ノードにポッドがスケジュールされている場合、TimesTenオペレータはその時間をTimesTenClassicオブジェクトのステータスに記録します。

次の調整(.spec.ttspec.pollingInterval秒後)中に、ポッドが同じノードに割り当てられ、ノードがまだ準備ができていない(または不明な)場合、TimesTenオペレータは.spec.ttspec.deleteDbOnNotReadyNodeが指定されているかどうかを確認します。指定した場合、TimesTenオペレータは、ノードのnot readyの状況が.spec.ttspec.deleteDbOnNotReadyNode秒を超えて存在しているかどうかをチェックします。その場合、TimesTenオペレータはポッドおよびポッドに関連付けられたPVCを削除します。これにより、Kubernetesは、生存しているノードに新しいポッドと新しいPVCを作成します。ポッドがKubernetesによってスケジュールおよび起動されると、TimesTenオペレータによって通常どおりに構成されます。