第6章 OpenShift のダウングレード
6.1. 概要
OpenShift Container Platform の アップグレード後に、極端なケースではあるものの、クラスターを直前の状態にダウングレードする必要がある場合があります。以下のセクションでは、OpenShift Container Platform 3.9 から 3.7 へのダウングレードパスなどの、クラスターの各システムでダウングレードを実行するために必要な手順について説明します。
3.9 から 3.7 には直接ダウングレードできますが、etcd バックアップから復元している必要があります。
アップグレードが 3.8 の手順で失敗している場合、同じダウングレード手順が適用されます。
現時点で、これらの手順は OpenShift Container Platform の RPM ベースのインストールでのみサポートされており、クラスター全体のダウンタイムが生じることが前提とされています。
6.2. バックアップの確認
アップグレードプロセスで使用される Ansible Playbook は master-config.yaml ファイルと etcd データディレクトリーのバックアップを作成している必要があります。これらがマスターと etcd メンバーに存在していることを確認します。
/etc/origin/master/master-config.yaml.<timestamp> /var/lib/etcd/openshift-backup-pre-upgrade-<timestamp> /etc/origin/master/scheduler.json.<timestamp>
さらに、 (ノードコンポーネントを持つマスターを含む) 各ノードでタイムスタンプの付いた node-config.yaml ファイルをバックアップします。
/etc/origin/node/node-config.yaml.<timestamp>
(単一の組み込み etcd ではなく) 外部 etcd クラスターを使用している場合、リカバリー用には 1 つのバックアップのみが必要となりますが、バックアップはすべての etcd メンバーで作成される可能性があります。
以下のファイルの .rpmsave バックアップのコピーを保持します。
/etc/sysconfig/atomic-openshift-master-api /etc/sysconfig/atomic-openshift-master-controller /etc/etcd/etcd.conf
アップグレードの実行日に作成されたアップグレード前の最初のバックアップから復元します。
6.3. クラスターのシャットダウン
すべてのマスター、ノードおよび etcd メンバー (外部 etcd クラスターを使用している場合) で、関連するサービスが停止していることを確認します。
# systemctl stop atomic-openshift-master-api atomic-openshift-master-controllers
すべてのマスターおよびノードホストで、以下を実行します。
# systemctl stop atomic-openshift-node
外部 etcd ホストで、以下を実行します。
# systemctl stop etcd
6.4. RPM の削除
*-excluder パッケージは、インストール時に、エントリーをホストの /etc/yum.conf ファイルの exclude ディレクティブに追加します。
すべてのマスター、ノードおよび etcd メンバー (専用 etcd クラスターを使用している場合) で、以下のパッケージを削除します。
# yum remove atomic-openshift \ atomic-openshift-clients \ atomic-openshift-node \ atomic-openshift-master-api \ atomic-openshift-master-controllers \ openvswitch \ atomic-openshift-sdn-ovs \ tuned-profiles-atomic-openshift-node\ atomic-openshift-excluder\ atomic-openshift-docker-excluder
外部 etcd を使用している場合は、etcd パッケージも削除します。
# yum remove etcd
6.5. Docker のダウングレード
OpenShift Container Platform 3.9 には Docker 1.13 が必要で、OpenShift Container Platform 3.7 には Docker 1.12 が必要です。
Docker 1.13 を実行するすべてのホストで、以下の手順で Docker 1.12 にダウングレードします。
ホストのすべてのローカルコンテナーおよびイメージを削除します。レプリケーションコントローラーでサポートされるすべての Pod が再作成されます。
警告以下のコマンドは破壊的動作をするため、注意して使用する必要があります。
すべてのコンテナーを削除します。
# docker rm $(docker ps -a -q) -f
すべてのイメージを削除します。
# docker rmi $(docker images -q)
(
yum downgrade
の代わりに)yum swap
を使用して Docker 1.12.6 をインストールします。# yum swap docker-* docker-*1.12.6 -y # sed -i 's/--storage-opt dm.use_deferred_deletion=true//' /etc/sysconfig/docker-storage # systemctl restart docker
Docker 1.12.6 がインストールされており、ホスト上で実行されているはずです。以下で確認します。
# docker version # systemctl status docker
6.6. RPM の再インストール
OpenShift Container Platform 3.8 および 3.9 リポジトリーを無効にし、3.7 リポジトリーを再び有効にします。
# subscription-manager repos \ --disable=rhel-7-server-ose-3.8-rpms \ --disable=rhel-7-server-ose-3.9-rpms \ --enable=rhel-7-server-ose-3.7-rpms
各マスターで、以下のパッケージをインストールします。
# yum install atomic-openshift \ atomic-openshift-clients \ atomic-openshift-node \ atomic-openshift-master-api \ atomic-openshift-master-controllers \ openvswitch \ atomic-openshift-sdn-ovs \ tuned-profiles-atomic-openshift-node \ atomic-openshift-excluder \ atomic-openshift-docker-excluder
各ノードで、以下のパッケージをインストールします。
# yum install atomic-openshift \ atomic-openshift-node \ openvswitch \ atomic-openshift-sdn-ovs \ tuned-profiles-atomic-openshift-node \ atomic-openshift-excluder \ atomic-openshift-docker-excluder
外部 etcd クラスターを使用している場合、各 etcd メンバーで以下のパッケージをインストールします。
# yum install etcd
6.7. etcd の復元
etcd 設定ファイルの復元手順では、適切なファイルを置き換えてからサービスを再起動します。
etcd ホストが破損し、/etc/etcd/etcd.conf
ファイルが失われる場合は、以下を使用してこれを復元します。
$ ssh master-0 # cp /backup/yesterday/master-0-files/etcd.conf /etc/etcd/etcd.conf # restorecon -Rv /etc/etcd/etcd.conf # systemctl restart etcd.service
この例では、バックアップファイルは /backup/yesterday/master-0-files/etcd.conf
パスに保存されます。ここでは外部 NFS 共有、S3 バケットまたは他のストレージソリューションとして使用できます。
6.7.1. etcd v2 および v3 データの復元
以下のプロセスでは正常なデータファイルを復元し、etcd クラスターを単一ノードとして起動してから、etcd クラスターが必要な場合に残りのノードを追加します。
手順
すべての etcd サービスを停止します。
# systemctl stop etcd.service
適切なバックアップが復元されていることを確認するには、etcd ディレクトリーを削除します。
ディレクトリーを削除する前に現在の etcd データをバックアップするには、以下のコマンドを実行します。
# mv /var/lib/etcd /var/lib/etcd.old # mkdir /var/lib/etcd # chown -R etcd.etcd /var/lib/etcd/ # restorecon -Rv /var/lib/etcd/
または、ディレクトリーおよび etcd、データを削除するには、以下のコマンドを実行します。
# rm -Rf /var/lib/etcd/*
注記オールインワンクラスターの場合、etcd データディレクトリーは
/var/lib/origin/openshift.local.etcd
ディレクトリーに置かれます。
正常なバックアップデータファイルをそれぞれの etcd ノードに復元します。この手順は、etcd と同じ場所に配置されているマスターホストを含むすべての etcd ホストで実行します。
# cp -R /backup/etcd-xxx/* /var/lib/etcd/ # mv /var/lib/etcd/db /var/lib/etcd/member/snap/db # chcon -R --reference /backup/etcd-xxx/* /var/lib/etcd/ # chown -R etcd:etcd /var/lib/etcd/R
各ホストで etcd サービスを実行し、新規クラスターを強制的に実行します。
これにより etcd サービスのカスタムファイルが作成されます。これにより、
--force-new-cluster
オプションを追加して実行コマンドが上書きされます。# mkdir -p /etc/systemd/system/etcd.service.d/ # echo "[Service]" > /etc/systemd/system/etcd.service.d/temp.conf # echo "ExecStart=" >> /etc/systemd/system/etcd.service.d/temp.conf # sed -n '/ExecStart/s/"$/ --force-new-cluster"/p' \ /usr/lib/systemd/system/etcd.service \ >> /etc/systemd/system/etcd.service.d/temp.conf # systemctl daemon-reload # systemctl restart etcd
エラーメッセージの有無を確認します。
$ journalctl -fu etcd.service
健全性のステータスを確認します。
# etcdctl2 cluster-health member 5ee217d17301 is healthy: got healthy result from https://192.168.55.8:2379 cluster is healthy
クラスターモードで etcd サービスを再起動します。
# rm -f /etc/systemd/system/etcd.service.d/temp.conf # systemctl daemon-reload # systemctl restart etcd
健全性のステータスとメンバーの一覧を確認します。
# etcdctl2 cluster-health member 5ee217d17301 is healthy: got healthy result from https://192.168.55.8:2379 cluster is healthy # etcdctl2 member list 5ee217d17301: name=master-0.example.com peerURLs=http://localhost:2380 clientURLs=https://192.168.55.8:2379 isLeader=true
- 最初のインスタンスの実行後に、残りの etcd サーバーを復元できます。
6.7.1.1. peerURLS
パラメーターの修正
データの復元および新規クラスターの作成後に、peerURLs
パラメーターは、 etcd がピア通信をリッスンする IP の代わりに localhost
を示します。
# etcdctl2 member list 5ee217d17301: name=master-0.example.com peerURLs=http://*localhost*:2380 clientURLs=https://192.168.55.8:2379 isLeader=true
6.7.1.1.1. 手順
etcdctl member list
を使用してメンバー ID を取得します。`etcdctl member list`
etcd がピア通信をリッスンする IP を取得します。
$ ss -l4n | grep 2380
メンバー情報をこの IP で更新します。
# etcdctl2 member update 5ee217d17301 https://192.168.55.8:2380 Updated member with ID 5ee217d17301 in cluster
検証するには、IP がメンバーの一覧にあることを確認します。
$ etcdctl2 member list 5ee217d17301: name=master-0.example.com peerURLs=https://*192.168.55.8*:2380 clientURLs=https://192.168.55.8:2379 isLeader=true
6.7.2. v3 の etcd の復元
v3 データの復元手順は v2 データの復元プロセスと同様です。
スナップショットの整合性については、復元時にオプションで検証できます。スナップショットが etcdctl snapshot save
を使用して取得される場合、これには etcdctl snapshot restore
でチェックされる整合性ハッシュが含まれます。スナップショットがデータディレクトリーからコピーされる場合には整合性ハッシュはなく、復元は --skip-hash-check
を使用して実行されます。
v3 データのみを復元する手順は単一 etcd ホストで実行される必要があります。その後に残りのノードをクラスターに追加することができます。
手順
すべての etcd サービスを停止します。
# systemctl stop etcd.service
古いデータについては、
etcdctl
が復元手順が実行されるノードでその再作成を実行するため、それらすべてをクリアします。# rm -Rf /var/lib/etcd
snapshot restore
コマンドを実行し、/etc/etcd/etcd.conf
ファイルの値を置き換えます。# etcdctl3 snapshot restore /backup/etcd-xxxxxx/backup.db \ --data-dir /var/lib/etcd \ --name master-0.example.com \ --initial-cluster "master-0.example.com=https://192.168.55.8:2380" \ --initial-cluster-token "etcd-cluster-1" \ --initial-advertise-peer-urls https://192.168.55.8:2380 2017-10-03 08:55:32.440779 I | mvcc: restore compact to 1041269 2017-10-03 08:55:32.468244 I | etcdserver/membership: added member 40bef1f6c79b3163 [https://192.168.55.8:2380] to cluster 26841ebcf610583c
パーミッションおよび
selinux
コンテキストを復元ファイルに復元します。# chown -R etcd.etcd /var/lib/etcd/ # restorecon -Rv /var/lib/etcd
etcd サービスを起動します。
# systemctl start etcd
エラーメッセージの有無を確認します。
$ journalctl -fu etcd.service
6.8. OpenShift Container Platform サービスの再オンライン化
変更を終了した後に、OpenShift Container Platform をオンラインに戻します。
手順
それぞれの OpenShift Container Platform マスターで、バックアップからマスターおよびノード設定を復元し、すべての関連するサービスを有効にしてから再起動します。
# cp ${MYBACKUPDIR}/etc/sysconfig/atomic-openshift-master-api /etc/sysconfig/atomic-openshift-master-api # cp ${MYBACKUPDIR}/etc/sysconfig/atomic-openshift-master-controllers /etc/sysconfig/atomic-openshift-master-controllers # cp ${MYBACKUPDIR}/etc/origin/master/master-config.yaml.<timestamp> /etc/origin/master/master-config.yaml # cp ${MYBACKUPDIR}/etc/origin/node/node-config.yaml.<timestamp> /etc/origin/node/node-config.yaml # cp ${MYBACKUPDIR}/etc/origin/master/scheduler.json.<timestamp> /etc/origin/master/scheduler.json # systemctl enable atomic-openshift-master-api # systemctl enable atomic-openshift-master-controllers # systemctl enable atomic-openshift-node # systemctl start atomic-openshift-master-api # systemctl start atomic-openshift-master-controllers # systemctl start atomic-openshift-node
- それぞれの OpenShift Container Platform ノードで、バックアップから node-config.yaml ファイルを復元し、atomic-openshift-node サービスを有効にし、再起動します。
# cp /etc/origin/node/node-config.yaml.<timestamp> /etc/origin/node/node-config.yaml # systemctl enable atomic-openshift-node # systemctl start atomic-openshift-node
6.9. ダウングレードの検証
ダウングレードを検証するには、すべてのノードに Ready のマークが付けられていることを確認します。
# oc get nodes NAME STATUS AGE master.example.com Ready,SchedulingDisabled 165d node1.example.com Ready 165d node2.example.com Ready 165d
次に、予想されるバージョンの docker-registry および router イメージを実行していることを確認します (デプロイされている場合)。
# oc get -n default dc/docker-registry -o json | grep \"image\" "image": "openshift3/ose-docker-registry:v3.7.23", # oc get -n default dc/router -o json | grep \"image\" "image": "openshift3/ose-haproxy-router:v3.7.23",
診断ツールをマスターで使用し、共通の問題を検索し、提案される方法を確認します。
# oc adm diagnostics ... [Note] Summary of diagnostics execution: [Note] Completed with no errors or warnings seen.