2.6. オプションコンポーネントのアップグレード
EFK ロギングスタックまたはクラスターメトリクスをインストールしている場合、コンポーネントを別々にアップグレードする必要があります。
2.6.1. EFK ロギングスタックのアップグレード
既存の EFK ロギングスタックデプロイメントをアップグレードするには、パラメーターを確認してから openshift-logging/config.yml Playbook を実行します。
アップグレードで logging-fluentd と logging-curator ConfigMaps が置き換えられます。現在の logging-fluentd と logging-curator ConfigMaps を保持する必要がある場合は、インベントリーホストファイル の openshift_logging_fluentd_replace_configmap と openshift_logging_curator_replace_configmap のパラメーターを no に設定します。
EFK アップグレードも Elasticsearch をバージョン 2 からバージョン 5 にアップグレードします。Elasticsearch 5 の変更に関する重要な情報については、Elasticsearch breaking changes を確認する必要があります。
Elasticsearch 5 では、インデックス構造に大きな変更がある点に留意することが重要です。以前のバージョンでは、Elasticsearch はフィールド名のドット文字 . を許可していました。バージョン 5 では、Elasticsearch は Elasticsearch フィールド名のすべてのドットをネストされた構造として解釈します。フィールドにドットが含まれる場合は、ドットの後の文字列はフィールドの型として解釈され、アップグレード中にマッピングの競合が発生します。
競合の可能性を特定できるように、OpenShift Container Platform は Elasticsearch フィールドを検査して、フィールド名にドットが含まれるかどうかを判別します。
たとえば、以下のフィールドは Elasticsearch 2 では使用できていました。
{
"field": 123 // "field" is of type number
}
// Any dot in field name is treated as any other valid character in the field name.
// It is just part of the field name.
{
"field.name": "Bob" // "field.name" is of type String
Elasticsearch 5 以降では、field 文字列がフィールドになり、name 文字列はフィールドのタイプになります。
{
"field": 123 // "field" is of type number
}
// Any dot in field name is always interpreted as nested structure.
{
"field" : { // "field" is of type Object
"name": "Bob" // "name" is of type String
}
}
この場合にアップグレードすると、field フィールドには 2 つの異なるタイプが指定されてしまいます。
競合するインデックスを保持する必要がある場合は、データを再インデックスし、競合するデータ構造を取り除くように、ドキュメントを変更してください。詳細は、Upgrading fields with dots to 5.x を参照してください。
2.6.1.1. フィールド名にドットがあるかどうかの判別
以下のスクリプトを実行して、インデックス名にドットが付いたフィールドが含まれるかどうかを判別できます。
以下のコマンドは、jq JSON プロセッサーを使用して必要なデータを直接取得します。バージョンによっては、Red Hat Enterprise Linux (RHEL) では jq のパッケージが提供されない場合があります。外部のソースからインストール、またはサポート対象外の場所からインストールする必要がある場合があります。
oc exec -c elasticsearch -n $LOGGING_NS $pod -- es_util --query='_mapping?pretty&filter_path=**.mappings.*.properties' \ | jq '.[].mappings[].properties | keys' \ | jq .[] \ | egrep -e "\."
2.6.1.2. フィールド名にドットがある場合のアップグレード
上記のスクリプト で、インデックスから、名前にドットが含まれるフィールドがあることが分かると、以下の手順を使用してこの問題を修正し、アップグレードしてください。
EFK スタックをアップグレードするには、以下を実行します。
ロギング Ansible 変数を指定する 方法を確認し、少なくとも
[OSEv3:vars]セクション内で以下の必要な変数を設定するように Ansible インベントリーファイルを更新します。[OSEv3:vars] openshift_logging_install_logging=true 1- 1
- ロギングスタックをアップグレードする機能を有効にします。
Specifying Logging Ansible Variablesで説明されているように、デフォルトの値を上書きするために指定する必要のあるその他の openshift_logging_* 変数を更新します。openshift_logging_elasticsearch_replace_configmapパラメーターをtrueに設定すると、logging-elasticsearchConfigMap を現在のデフォルト値に置き換えることができます。場合によっては、古い ConfigMap を使用するとアップグレードが失敗する場合があります。デフォルトはfalseに設定されます。詳細は、ロギング Ansible 変数を指定するパラメーター を参照してください。注記EFK コンポーネントの Fluentd
DeploymentConfigオブジェクトおよびDaemonSetオブジェクトがすでに以下で設定されている場合:image: <image_name>:<vX.Y> imagePullPolicy: IfNotPresent最新バージョン
<image_name>は、Pod の再デプロイ先のノードにローカルに保存される<image_name:vX.Y>と同じ名前のイメージが存在する場合にプルされないことがあります。イメージのバージョンが v3.11 であり、Playbook を使用して最新バージョンにアップグレードする必要がある場合には、openshift_image_tag=v3.11.<Z>またはoreg_url=registry.access.redhat.com/openshift3/ose-${component}:v3.11.<Z>Ansible パラメーターを設定します。データの取得を停止する Fluentd Pod のスケジュールを解除して、クラスターの状態が変更しないようにします。
たとえば、Fluentd Pod のノードセレクターを、いずれのノードにも一致しないものに切り換えることができます。
oc patch daemonset logging-fluentd -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'- 関連するすべてのインデックスで Elasticsearch インデックスのフラッシュ を実行します。フラッシュプロセスでは、すべてのログをメモリーからディスクに永続化し、アップグレード時に Elasticsearch がシャットダウンしてもログが失われないようにできます。
オンラインまたはオフラインバックアップを実行します。
- 特定の Elasticsearch クラスターの オンラインバックアップ を実行します。
オフラインバックアップを実行します。
すべての Elasticsearch DeploymentConfig を
0にスケールダウンします。$ oc scale dc <name> -n openshift-logging --replicas=0
- 組織に適した方法を使用して、外部永続ボリュームをバックアップします。
ドット文字を含むファイル名については、アップグレード前に以下のいずれかのアクションを実行する必要があります。
- インデックスを削除します。この方法は、アップグレード時にマッピングの競合回避に適しています。
- データを再インデックス化して、ドキュメントを変更し、競合するデータ構造を削除します。このメソッドはデータを保持します。マッピングの競合の可能性は、Elasticsearch ドキュメントの Mappging changes を参照してください。
- オンラインまたはオフラインでバックアップを繰り返します。
- EFK スタックのデプロイの説明に従って openshift-logging/config.yml Playbook を実行し、ロギングのアップグレードを完了します。ロギングデプロイメントをアップグレードするには、新規 OpenShift Container Platform バージョンのインストール Playbook を実行します。
2.6.1.3. フィールドにドットが含まれない場合のアップグレード
上記のスクリプト で、インデックスから名前にドットが含まれるフィールドがあることが分かると、以下の手順を使用してアップグレードを行います。
ロギング Ansible 変数を指定する 方法を確認し、少なくとも
[OSEv3:vars]セクション内で以下の必要な変数を設定するように Ansible インベントリーファイルを更新します。[OSEv3:vars] openshift_logging_install_logging=true 1- 1
- ロギングスタックをアップグレードする機能を有効にします。
Specifying Logging Ansible Variablesで説明されているように、デフォルトの値を上書きするために指定する必要のあるその他の openshift_logging_* 変数を更新します。openshift_logging_elasticsearch_replace_configmapパラメーターをtrueに設定すると、logging-elasticsearchConfigMap を現在のデフォルト値に置き換えることができます。場合によっては、古い ConfigMap を使用するとアップグレードが失敗する場合があります。デフォルトはfalseに設定されます。詳細は、ロギング Ansible 変数を指定するパラメーター を参照してください。注記EFK コンポーネントの Fluentd
DeploymentConfigオブジェクトおよびDaemonSetオブジェクトがすでに以下で設定されている場合:image: <image_name>:<vX.Y> imagePullPolicy: IfNotPresent最新バージョン <image_name> は、Pod の再デプロイ先のノードにローカルに保存される
<image_name:vX.Y>と同じ名前のイメージが存在する場合にプルされないことがあります。イメージのバージョンが v3.11 であり、Playbook を使用して最新バージョンにアップグレードする必要がある場合には、openshift_image_tag=v3.11.<Z>またはoreg_url=registry.access.redhat.com/openshift3/ose-${component}:v3.11.<Z>Ansible パラメーターを設定します。オプションとして、Fluentd Pod のスケジュールを解除して Elasticsearch Pod をスケールダウンし、データの処理を停止してクラスターの状態が変更されないようにします。
たとえば、Fluentd Pod のノードセレクターを、いずれのノードにも一致しないものに切り換えることができます。
oc patch daemonset logging-fluentd -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'必要に応じて、オンラインまたはオフラインバックアップを実行します。
- 特定の Elasticsearch クラスターの オンラインバックアップ を実行します。
オフラインバックアップを実行します。
すべての Elasticsearch DeploymentConfig を
0にスケールダウンします。$ oc scale dc <name> -n openshift-logging --replicas=0
- 組織に適した方法を使用して、外部永続ボリュームをバックアップします。
- EFK スタックのデプロイの説明に従って openshift-logging/config.yml Playbook を実行し、ロギングのアップグレードを完了します。ロギングデプロイメントをアップグレードするには、新規 OpenShift Container Platform バージョンのインストール Playbook を実行します。
- オプションで、Elasticsearch restore module を使用して、スナップショットから Elasticsearch インデックスを復元します。
