Red Hat Summitデバイスの置き換え
動作中または故障したデバイスを安全に交換するための手順
概要
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社の CTO、Chris Wright のメッセージ を参照してください。
Red Hat ドキュメントへのフィードバックの提供
弊社のドキュメントについてのご意見をお聞かせください。ドキュメントの改善点があれば、ぜひお知らせください。フィードバックをお寄せいただくには、以下をご確認ください。
特定の部分についての簡単なコメントをお寄せいただく場合は、以下をご確認ください。
- ドキュメントの表示が Multi-page HTML 形式になっていていることを確認してください。ドキュメントの右上隅に Feedback ボタンがあることを確認してください。
- マウスカーソルを使用して、コメントを追加するテキストの部分を強調表示します。
- 強調表示されたテキストの下に表示される Add Feedback ポップアップをクリックします。
- 表示される指示に従ってください。
より詳細なフィードバックをお寄せいただく場合は、Bugzilla のチケットを作成してください。
- Bugzilla の Web サイトに移動します。
- Component (コンポーネント) として Documentation を使用します。
- Description フィールドに、ドキュメントの改善に向けたご提案を記入してください。ドキュメントの該当部分へのリンクも追加してください。
- Submit Bug をクリックします。
はじめに
デプロイメントのタイプに応じて、以下のいずれかの手順を選択してストレージノードを置き換えることができます。
AWS にデプロイされた動的に作成されたストレージクラスターについては、以下を参照してください。
- VMware にデプロイされた動的に作成されたストレージクラスターについては、「VMware インフラストラクチャーで動作するストレージデバイスまたは失敗したストレージデバイスの置き換え」を参照してください。
- Red Hat Virtualization にデプロイされた動的に作成されたストレージクラスターについては、「Red Hat Virtualization のインストーラーでプロビジョニングされるインフラストラクチャーで動作するストレージデバイスまたは障害のあるストレージデバイスの置き換え」を参照してください。
- Microsoft Azure にデプロイされた動的に作成されたストレージクラスターについては、「Azure のインストーラーでプロビジョニングされるインフラストラクチャーで動作するストレージデバイスまたは失敗したストレージデバイスの置き換え」を参照してください。
ローカルストレージデバイスを使用してデプロイされたストレージクラスターについては、以下を参照してください。
OpenShift Container Storage は異なる OSD サイズをサポートしません。
第1章 AWS への OpenShift Container Storage の動的プロビジョニング
1.1. AWS のユーザーによってプロビジョニングされるインフラストラクチャーで動作するストレージデバイスまたは失敗したストレージデバイスの置き換え
AWA のユーザーによってプロビジョニングされるインフラストラクチャーの動的に作成されたストレージクラスターのデバイスを置き換える必要がある場合は、ストレージノードを置き換える必要があります。ノードを置き換える方法は、以下を参照してください。
1.2. AWS のインストーラーでプロビジョニングされるインフラストラクチャーで動作するストレージデバイスまたは失敗したストレージデバイスの置き換え
AWA のインストーラーでプロビジョニングされるインフラストラクチャーの動的に作成されたストレージクラスターのデバイスを置き換える必要がある場合は、ストレージノードを置き換える必要があります。ノードを置き換える方法は、以下を参照してください。
第2章 VMware への OpenShift Container Storage の動的プロビジョニング
2.1. VMware インフラストラクチャーで動作するストレージデバイスまたは失敗したストレージデバイスの置き換え
この手順は、VMware インフラストラクチャーに動的にデプロイされる OpenShift Container Storage で 1 つまたは複数の仮想マシンディスク (VMDK) を置き換える必要がある場合に使用します。この手順は、新規ボリュームで新規の Persistent Volume Claim(永続ボリューム要求、PVC) を作成し、古いオブジェクトストレージデバイス (OSD) を削除するのに役立ちます。
前提条件
データに耐久性があることを確認します。
- OpenShift Web コンソールで、Storage → Overview にナビゲートします。
- Status カードの Persistent Storage で、Data Resiliency に緑色のチェックマークが付いていることを確認します。
手順
置き換える必要がある OSD と、その OSD がスケジュールされている OpenShift Container Platform ノードを特定します。
$ oc get -n openshift-storage pods -l app=rook-ceph-osd -o wide出力例:
rook-ceph-osd-0-6d77d6c7c6-m8xj6 0/1 CrashLoopBackOff 0 24h 10.129.0.16 compute-2 <none> <none> rook-ceph-osd-1-85d99fb95f-2svc7 1/1 Running 0 24h 10.128.2.24 compute-0 <none> <none> rook-ceph-osd-2-6c66cdb977-jp542 1/1 Running 0 24h 10.130.0.18 compute-1 <none> <none>この例では、
rook-ceph-osd-0-6d77d6c7c6-m8xj6を置き換える必要があり、compute-2は OSD がスケジュールされる OpenShift Container platform ノードです。注記置き換える OSD が正常である場合、Pod のステータスは
Runningになります。置き換えられる OSD の OSD デプロイメントをスケールダウンします。
OSD を置き換えるたびに、
osd_id_to_removeパラメーターを OSD ID で更新してこの手順を繰り返します。$ osd_id_to_remove=0 $ oc scale -n openshift-storage deployment rook-ceph-osd-${osd_id_to_remove} --replicas=0ここで、
osd_id_to_removeはrook-ceph-osd接頭辞の直後にくる Pod 名の整数です。この例では、デプロイメント名はrook-ceph-osd-0です。出力例:
deployment.extensions/rook-ceph-osd-0 scaledrook-ceph-osdPod が停止していることを確認します。$ oc get -n openshift-storage pods -l ceph-osd-id=${osd_id_to_remove}出力例:
No resources found.注記rook-ceph-osdPod がterminating状態にある場合は、forceオプションを使用して Pod を削除します。$ oc delete pod rook-ceph-osd-0-6d77d6c7c6-m8xj6 --force --grace-period=0出力例:
warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely. pod "rook-ceph-osd-0-6d77d6c7c6-m8xj6" force deleted新規 OSD を追加できるようにクラスターから古い OSD を削除します。
古い
ocs-osd-removalジョブを削除します。$ oc delete -n openshift-storage job ocs-osd-removal-job出力例:
job.batch "ocs-osd-removal-job" deletedopenshift-storageプロジェクトを変更します。$ oc project openshift-storageクラスターから以前の OSD を削除します。
$ oc process -n openshift-storage ocs-osd-removal \ -p FAILED_OSD_IDS=<failed_osd_id> FORCE_OSD_REMOVAL=false | oc create -n openshift-storage -f -<failed_osd_id>rook-ceph-osd接頭辞の直後の Pod 名の整数です。コマンドにコンマ区切りの OSD ID を追加して、複数の OSD を削除できます (例:FAILED_OSD_IDS=0,1,2)OSD が 3 つしかないクラスター、または OSD が削除された後にデータの 3 つのレプリカすべてを復元するにはスペースが不十分なクラスターでは、
FORCE_OSD_REMOVAL値をtrueに変更する必要があります。警告この手順により、OSD はクラスターから完全に削除されます。
osd_id_to_removeの正しい値が指定されていることを確認します。
ocs-osd-removalPod のステータスをチェックして、OSD が正常に削除されたことを確認します。Completedのステータスで、OSD の削除ジョブが正常に完了したことを確認します。$ oc get pod -l job-name=ocs-osd-removal-job -n openshift-storage注記ocs-osd-removalが失敗し、Pod が予想されるCompletedの状態にない場合、追加のデバッグのために Pod ログを確認します。以下に例を示します。$ oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1'暗号化がインストール時に有効にされている場合は、それぞれの OpenShift Container Storage ノードから削除された OSD デバイスから
dm-cryptで管理されるdevice-mapperマッピングを削除します。ocs-osd-removal-jobPod のログから、置き換えられた OSD の PVC 名を取得します。$ oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1 |egrep -i ‘pvc|deviceset’以下に例を示します。
2021-05-12 14:31:34.666000 I | cephosd: removing the OSD PVC "ocs-deviceset-xxxx-xxx-xxx-xxx"手順 #1 で特定されたノードごとに、以下を実行します。
デバッグPod を作成し、ストレージノードのホストに対してchrootを作成します。$ oc debug node/<node name> $ chroot /host直前の手順で特定された PVC 名に基づいて関連するデバイス名を検索します。
sh-4.4# dmsetup ls| grep <pvc name> ocs-deviceset-xxx-xxx-xxx-xxx-block-dmcrypt (253:0)マップ済みデバイスを削除します。
$ cryptsetup luksClose --debug --verbose ocs-deviceset-xxx-xxx-xxx-xxx-block-dmcrypt注記権限が十分にないため、コマンドがスタックした場合には、以下のコマンドを実行します。
-
CTRL+Zを押して上記のコマンドを終了します。 スタックしたプロセスの PID を検索します。
$ ps -ef | grep cryptkillコマンドを使用してプロセスを終了します。$ kill -9 <PID>デバイス名が削除されていることを確認します。
$ dmsetup ls
-
ocs-osd-removalジョブを削除します。$ oc delete -n openshift-storage job ocs-osd-removal-job出力例:
job.batch "ocs-osd-removal-job" deleted
データ暗号化で外部の鍵管理システム (KMS) を使用する場合は、古い OSD 暗号化キーは孤立したキーであるために Vault サーバーから削除できます。
検証手順
新しい OSD が実行されていることを確認します。
$ oc get -n openshift-storage pods -l app=rook-ceph-osd出力例:
rook-ceph-osd-0-5f7f4747d4-snshw 1/1 Running 0 4m47s rook-ceph-osd-1-85d99fb95f-2svc7 1/1 Running 0 1d20h rook-ceph-osd-2-6c66cdb977-jp542 1/1 Running 0 1d20hBound状態の新しい PVC が作成されていることを確認します。$ oc get -n openshift-storage pvc出力例:
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE ocs-deviceset-0-0-2s6w4 Bound pvc-7c9bcaf7-de68-40e1-95f9-0b0d7c0ae2fc 512Gi RWO thin 5m ocs-deviceset-1-0-q8fwh Bound pvc-9e7e00cb-6b33-402e-9dc5-b8df4fd9010f 512Gi RWO thin 1d20h ocs-deviceset-2-0-9v8lq Bound pvc-38cdfcee-ea7e-42a5-a6e1-aaa6d4924291 512Gi RWO thin 1d20h(オプション) クラスターでクラスター全体の暗号化が有効な場合には、新規 OSD デバイスが暗号化されていることを確認します。
新規 OSD Pod が実行しているノードを特定します。
$ oc get -o=custom-columns=NODE:.spec.nodeName pod/<OSD pod name>以下に例を示します。
oc get -o=custom-columns=NODE:.spec.nodeName pod/rook-ceph-osd-0-544db49d7f-qrgqm直前の手順で特定されたノードごとに、以下を実行します。
デバッグ Pod を作成し、選択したホストの chroot 環境を開きます。
$ oc debug node/<node name> $ chroot /hostlsblk を実行し、
ocs-deviceset名の横にある crypt キーワードを確認します。$ lsblk
OpenShift Web コンソールにログインし、ストレージダッシュボードを表示します。
図2.1 デバイスの置き換え後の OpenShift Container Platform ストレージダッシュボードの OSD ステータス
第3章 Red Hat Virtualization への OpenShift Container Storage の動的プロビジョニング
3.1. Red Hat Virtualization のインストーラーでプロビジョニングされるインフラストラクチャーで動作するストレージデバイスまたは障害のあるストレージデバイスの置き換え
この手順は、Red Hat Virtualization インフラストラクチャーにデプロイされる OpenShift Container Storage で 1 つまたは複数の仮想マシンディスク (VMDK) を置き換える必要がある場合に使用します。この手順は、新規ボリュームで新規の Persistent Volume Claim(永続ボリューム要求、PVC) を作成し、古いオブジェクトストレージデバイス (OSD) を削除するのに役立ちます。
前提条件
データに耐久性があることを確認します。
- OpenShift Web コンソールで、Storage → Overview にナビゲートします。
- Status カードの Persistent Storage で、Data Resiliency に緑色のチェックマークが付いていることを確認します。
手順
置き換える必要がある OSD と、その OSD がスケジュールされている OpenShift Container Platform ノードを特定します。
$ oc get -n openshift-storage pods -l app=rook-ceph-osd -o wide出力例:
rook-ceph-osd-0-6d77d6c7c6-m8xj6 0/1 CrashLoopBackOff 0 24h 10.129.0.16 compute-2 <none> <none> rook-ceph-osd-1-85d99fb95f-2svc7 1/1 Running 0 24h 10.128.2.24 compute-0 <none> <none> rook-ceph-osd-2-6c66cdb977-jp542 1/1 Running 0 24h 10.130.0.18 compute-1 <none> <none>この例では、
rook-ceph-osd-0-6d77d6c7c6-m8xj6を置き換える必要があり、compute-2は OSD がスケジュールされる OpenShift Container platform ノードです。注記置き換える OSD が正常である場合、Pod のステータスは
Runningになります。置き換えられる OSD の OSD デプロイメントをスケールダウンします。
OSD を置き換えるたびに、
osd_id_to_removeパラメーターを OSD ID で更新してこの手順を繰り返します。$ osd_id_to_remove=0 $ oc scale -n openshift-storage deployment rook-ceph-osd-${osd_id_to_remove} --replicas=0ここで、
osd_id_to_removeはrook-ceph-osd接頭辞の直後にくる Pod 名の整数です。この例では、デプロイメント名はrook-ceph-osd-0です。出力例:
deployment.extensions/rook-ceph-osd-0 scaledrook-ceph-osdPod が停止していることを確認します。$ oc get -n openshift-storage pods -l ceph-osd-id=${osd_id_to_remove}出力例:
No resources found.注記rook-ceph-osdPod がterminating状態にある場合は、forceオプションを使用して Pod を削除します。$ oc delete pod rook-ceph-osd-0-6d77d6c7c6-m8xj6 --force --grace-period=0出力例:
warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely. pod "rook-ceph-osd-0-6d77d6c7c6-m8xj6" force deleted新規 OSD を追加できるようにクラスターから古い OSD を削除します。
古い
ocs-osd-removalジョブを削除します。$ oc delete -n openshift-storage job ocs-osd-removal-job出力例:
job.batch "ocs-osd-removal-job"openshift-storageプロジェクトを変更します。$ oc project openshift-storageクラスターから以前の OSD を削除します。
$ oc process -n openshift-storage ocs-osd-removal \ -p FAILED_OSD_IDS=<failed_osd_id> FORCE_OSD_REMOVAL=false | oc create -n openshift-storage -f -<failed_osd_id>rook-ceph-osd接頭辞の直後の Pod 名の整数です。コマンドにコンマ区切りの OSD ID を追加して、複数の OSD を削除できます (例:FAILED_OSD_IDS=0,1,2)OSD が 3 つしかないクラスター、または OSD が削除された後にデータの 3 つのレプリカすべてを復元するにはスペースが不十分なクラスターでは、
FORCE_OSD_REMOVAL値をtrueに変更する必要があります。警告この手順により、OSD はクラスターから完全に削除されます。
osd_id_to_removeの正しい値が指定されていることを確認します。
ocs-osd-removalPod のステータスをチェックして、OSD が正常に削除されたことを確認します。Completedのステータスで、OSD の削除ジョブが正常に完了したことを確認します。$ oc get pod -l job-name=ocs-osd-removal-job -n openshift-storage注記ocs-osd-removalが失敗し、Pod が予想されるCompletedの状態にない場合、追加のデバッグのために Pod ログを確認します。以下に例を示します。$ oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1'暗号化がインストール時に有効にされている場合は、それぞれの OpenShift Container Storage ノードから削除された OSD デバイスから
dm-cryptで管理されるdevice-mapperマッピングを削除します。ocs-osd-removal-jobPod のログから、置き換えられた OSD の PVC 名を取得します。$ oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1 |egrep -i ‘pvc|deviceset’以下に例を示します。
2021-05-12 14:31:34.666000 I | cephosd: removing the OSD PVC "ocs-deviceset-xxxx-xxx-xxx-xxx"手順 #1 で特定されたノードごとに、以下を実行します。
デバッグPod を作成し、ストレージノードのホストに対してchrootを作成します。$ oc debug node/<node name> $ chroot /host直前の手順で特定された PVC 名に基づいて関連するデバイス名を検索します。
sh-4.4# dmsetup ls| grep <pvc name> ocs-deviceset-xxx-xxx-xxx-xxx-block-dmcrypt (253:0)マップ済みデバイスを削除します。
$ cryptsetup luksClose --debug --verbose ocs-deviceset-xxx-xxx-xxx-xxx-block-dmcrypt注記権限が十分にないため、コマンドがスタックした場合には、以下のコマンドを実行します。
-
CTRL+Zを押して上記のコマンドを終了します。 スタックしたプロセスの PID を検索します。
$ ps -ef | grep cryptkillコマンドを使用してプロセスを終了します。$ kill -9 <PID>デバイス名が削除されていることを確認します。
$ dmsetup ls
-
ocs-osd-removalジョブを削除します。$ oc delete -n openshift-storage job ocs-osd-removal-job出力例:
job.batch "ocs-osd-removal-job" deleted
データ暗号化で外部の鍵管理システム (KMS) を使用する場合は、古い OSD 暗号化キーは孤立したキーであるために Vault サーバーから削除できます。
検証手順
新しい OSD が実行されていることを確認します。
$ oc get -n openshift-storage pods -l app=rook-ceph-osd出力例:
rook-ceph-osd-0-5f7f4747d4-snshw 1/1 Running 0 4m47s rook-ceph-osd-1-85d99fb95f-2svc7 1/1 Running 0 1d20h rook-ceph-osd-2-6c66cdb977-jp542 1/1 Running 0 1d20hBound状態の新しい PVC が作成されていることを確認します。$ oc get -n openshift-storage pvc(オプション) クラスターでクラスター全体の暗号化が有効な場合には、新規 OSD デバイスが暗号化されていることを確認します。
新規 OSD Pod が実行しているノードを特定します。
$ oc get -o=custom-columns=NODE:.spec.nodeName pod/<OSD pod name>以下に例を示します。
oc get -o=custom-columns=NODE:.spec.nodeName pod/rook-ceph-osd-0-544db49d7f-qrgqm直前の手順で特定されたノードごとに、以下を実行します。
デバッグ Pod を作成し、選択したホストの chroot 環境を開きます。
$ oc debug node/<node name> $ chroot /hostlsblk を実行し、
ocs-deviceset名の横にある crypt キーワードを確認します。$ lsblk
OpenShift Web コンソールにログインし、ストレージダッシュボードを表示します。
図3.1 デバイスの置き換え後の OpenShift Container Platform ストレージダッシュボードの OSD ステータス
第4章 Microsoft Azure への OpenShift Container Storage の動的プロビジョニング
4.1. Azure のインストーラーでプロビジョニングされるインフラストラクチャーで動作するストレージデバイスまたは失敗したストレージデバイスの置き換え
Azure のインストーラーでプロビジョニングされるインフラストラクチャーの動的に作成されたストレージクラスターのデバイスを置き換える必要がある場合は、ストレージノードを置き換える必要があります。ノードを置き換える方法は、以下を参照してください。
第5章 ローカルストレージデバイスを使用した OpenShift Container Storage のデプロイ
5.1. Amazon EC2 インフラストラクチャーでの障害のあるストレージノードの置き換え
Amazon EC2(ストレージ最適化 I3) インフラストラクチャーのストレージデバイスを置き換える必要がある場合は、ストレージノードを置き換える必要があります。ノードを置き換える方法については、Amazon EC2 インフラストラクチャーでの障害のあるストレージノードの置き換え を参照してください。
5.2. ローカルストレージデバイスがサポートするクラスターで動作するストレージデバイスまたは障害のあるストレージデバイスの置き換え
以下のインフラストラクチャーでローカルストレージデバイスを使用してデプロイされた OpenShift Container Storage のオブジェクトストレージデバイス (OSD) を置き換えることができます。
- ベアメタル
- VMware
- Red Hat Virtualization
基盤のストレージデバイスを 1 つまたは複数置き換える必要がある場合は、この手順を使用します。
前提条件
- Red Hat は、交換用デバイスを、交換するデバイスと同様のインフラストラクチャーおよびリソースで設定することを推奨します。
-
以前のバージョンから OpenShift Container Storage 4.7 にアップグレードし、デバイスの自動プロビジョニングを有効にするために
LocalVolumeSetオブジェクトを作成していない場合は、ローカルストレージでサポートされるクラスターの更新後の設定の変更 についての以下の手順に従って、これを実行します。 -
以前のバージョンから OpenShift Container Storage 4.7 にアップグレードし、
LocalVolumeDiscoveryオブジェクトを作成していない場合は、 ローカルストレージでサポートされるクラスターの更新後の設定の変更 についての以下の手順に従って、これを実行します。 データに耐久性があることを確認します。
- OpenShift Web コンソールで、Storage → Overview にナビゲートします。
- Status カードの Persistent Storage で、Data Resiliency に緑色のチェックマークが付いていることを確認します。
手順
- 関連するワーカーノードから基礎となるストレージデバイスを削除します。
関連する OSD Pod が CrashLoopBackOff 状態になったことを確認します。
置き換える必要がある OSD と、その OSD がスケジュールされている OpenShift Container Platform ノードを特定します。
$ oc get -n openshift-storage pods -l app=rook-ceph-osd -o wide出力例:
rook-ceph-osd-0-6d77d6c7c6-m8xj6 0/1 CrashLoopBackOff 0 24h 10.129.0.16 compute-2 <none> <none> rook-ceph-osd-1-85d99fb95f-2svc7 1/1 Running 0 24h 10.128.2.24 compute-0 <none> <none> rook-ceph-osd-2-6c66cdb977-jp542 1/1 Running 0 24h 10.130.0.18 compute-1 <none> <none>この例では、
rook-ceph-osd-0-6d77d6c7c6-m8xj6を置き換える必要があり、compute-2は OSD がスケジュールされる OpenShift Container platform ノードです。置き換えられる OSD の OSD デプロイメントをスケールダウンします。
$ osd_id_to_remove=0 $ oc scale -n openshift-storage deployment rook-ceph-osd-${osd_id_to_remove} --replicas=0ここで、
osd_id_to_removeはrook-ceph-osd接頭辞の直後にくる Pod 名の整数です。この例では、デプロイメント名はrook-ceph-osd-0です。出力例:
deployment.extensions/rook-ceph-osd-0 scaledrook-ceph-osdPod が停止していることを確認します。$ oc get -n openshift-storage pods -l ceph-osd-id=${osd_id_to_remove}出力例:
No resources found in openshift-storage namespace.注記rook-ceph-osdPod が数分以上terminating状態である場合は、forceオプションを使用して Pod を削除します。$ oc delete -n openshift-storage pod rook-ceph-osd-0-6d77d6c7c6-m8xj6 --grace-period=0 --force出力例:
warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely. pod "rook-ceph-osd-0-6d77d6c7c6-m8xj6" force deleted新規 OSD を追加できるようにクラスターから古い OSD を削除します。
古い
ocs-osd-removalジョブを削除します。$ oc delete -n openshift-storage job ocs-osd-removal-job出力例:
job.batch "ocs-osd-removal-job" deletedopenshift-storageプロジェクトを変更します。$ oc project openshift-storageクラスターから以前の OSD を削除します。
$ oc process -n openshift-storage ocs-osd-removal \ -p FAILED_OSD_IDS=<failed_osd_id> FORCE_OSD_REMOVAL=false | oc create -n openshift-storage -f -<failed_osd_id>rook-ceph-osd接頭辞の直後の Pod 名の整数です。コマンドにコンマ区切りの OSD ID を追加して、複数の OSD を削除できます (例:FAILED_OSD_IDS=0,1,2)OSD が 3 つしかないクラスター、または OSD が削除された後にデータの 3 つのレプリカすべてを復元するにはスペースが不十分なクラスターでは、
FORCE_OSD_REMOVAL値をtrueに変更する必要があります。警告この手順により、OSD はクラスターから完全に削除されます。
osd_id_to_removeの正しい値が指定されていることを確認します。
ocs-osd-removalPod のステータスをチェックして、OSD が正常に削除されたことを確認します。Completedのステータスで、OSD の削除ジョブが正常に完了したことを確認します。$ oc get pod -l job-name=ocs-osd-removal-job -n openshift-storage注記ocs-osd-removalが失敗し、Pod が予想されるCompletedの状態にない場合、追加のデバッグのために Pod ログを確認します。以下に例を示します。$ oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1暗号化がインストール時に有効にされている場合は、それぞれの OpenShift Container Storage ノードから削除された OSD デバイスから
dm-cryptで管理されるdevice-mapperマッピングを削除します。ocs-osd-removal-jobPod のログから、置き換えられた OSD の PVC 名を取得します。$ oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1 |egrep -i ‘pvc|deviceset’以下に例を示します。
2021-05-12 14:31:34.666000 I | cephosd: removing the OSD PVC "ocs-deviceset-xxxx-xxx-xxx-xxx"手順 #1 で特定されたノードごとに、以下を実行します。
デバッグPod を作成し、ストレージノードのホストに対してchrootを作成します。$ oc debug node/<node name> $ chroot /host直前の手順で特定された PVC 名に基づいて関連するデバイス名を検索します。
sh-4.4# dmsetup ls| grep <pvc name> ocs-deviceset-xxx-xxx-xxx-xxx-block-dmcrypt (253:0)マップ済みデバイスを削除します。
$ cryptsetup luksClose --debug --verbose ocs-deviceset-xxx-xxx-xxx-xxx-block-dmcrypt注記権限が十分にないため、コマンドがスタックした場合には、以下のコマンドを実行します。
-
CTRL+Zを押して上記のコマンドを終了します。 スタックしたプロセスの PID を検索します。
$ ps -ef | grep cryptkillコマンドを使用してプロセスを終了します。$ kill -9 <PID>デバイス名が削除されていることを確認します。
$ dmsetup ls
-
コマンドで削除する必要のある永続ボリューム (PV) を検索します。
$ oc get pv -L kubernetes.io/hostname | grep localblock | grep Released local-pv-d6bf175b 1490Gi RWO Delete Released openshift-storage/ocs-deviceset-0-data-0-6c5pw localblock 2d22h compute-1永続ボリュームを削除します。
$ oc delete pv local-pv-d6bf175b- 物理的に新規デバイスをノードに追加します。
以下のコマンドを使用して、
deviceInclusionSpecに一致するデバイスの永続ボリュームのプロビジョニングを追跡します。永続ボリュームをプロビジョニングするのに数分かかる場合があります。$ oc -n openshift-local-storage describe localvolumeset localblock出力例:
[...] Status: Conditions: Last Transition Time: 2020-11-17T05:03:32Z Message: DiskMaker: Available, LocalProvisioner: Available Status: True Type: DaemonSetsAvailable Last Transition Time: 2020-11-17T05:03:34Z Message: Operator reconciled successfully. Status: True Type: Available Observed Generation: 1 Total Provisioned Device Count: 4 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Discovered 2m30s (x4 localvolumeset- node.example.com - NewDevice over 2m30s) symlink-controller found possible matching disk, waiting 1m to claim Normal FoundMatch 89s (x4 localvolumeset- node.example.com - ingDisk over 89s) symlink-controller symlinking matching disk永続ボリュームがプロビジョニングされると、新しい OSD Pod がプロビジョニングボリューム用に自動作成されます。
ocs-osd-removalジョブを削除します。$ oc delete -n openshift-storage job ocs-osd-removal-job出力例:
job.batch "ocs-osd-removal-job" deleted
データ暗号化で外部の鍵管理システム (KMS) を使用する場合は、古い OSD 暗号化キーは孤立したキーであるために Vault サーバーから削除できます。
検証手順
新しい OSD が実行されていることを確認します。
$ oc get -n openshift-storage pods -l app=rook-ceph-osd出力例:
rook-ceph-osd-0-5f7f4747d4-snshw 1/1 Running 0 4m47s rook-ceph-osd-1-85d99fb95f-2svc7 1/1 Running 0 1d20h rook-ceph-osd-2-6c66cdb977-jp542 1/1 Running 0 1d20h注記数分後に新規 OSD が
Runningと表示されない場合は、rook-ceph-operatorPod を再起動して強制的に調整を行います。$ oc delete pod -n openshift-storage -l app=rook-ceph-operator出力例:
pod "rook-ceph-operator-6f74fb5bff-2d982" deleted新規 PVC が作成されていることを確認します。
$ oc get -n openshift-storage pvc | grep localblock出力例:
ocs-deviceset-0-0-c2mqb Bound local-pv-b481410 1490Gi RWO localblock 5m ocs-deviceset-1-0-959rp Bound local-pv-414755e0 1490Gi RWO localblock 1d20h ocs-deviceset-2-0-79j94 Bound local-pv-3e8964d3 1490Gi RWO localblock 1d20h(オプション) クラスターでクラスター全体の暗号化が有効な場合には、新規 OSD デバイスが暗号化されていることを確認します。
新規 OSD Pod が実行しているノードを特定します。
$ oc get -o=custom-columns=NODE:.spec.nodeName pod/<OSD pod name>以下に例を示します。
oc get -o=custom-columns=NODE:.spec.nodeName pod/rook-ceph-osd-0-544db49d7f-qrgqm直前の手順で特定されたノードごとに、以下を実行します。
デバッグ Pod を作成し、選択したホストの chroot 環境を開きます。
$ oc debug node/<node name> $ chroot /hostlsblk を実行し、
ocs-deviceset名の横にある crypt キーワードを確認します。$ lsblk
OpenShift Web コンソールにログインし、ストレージダッシュボードで OSD のステータスを確認します。
図5.1 デバイスの置き換え後の OpenShift Container Platform ストレージダッシュボードの OSD ステータス
データの完全復旧には、復元されるデータ量により、時間がかかる場合があります。
5.3. IBM Power Systems で動作するストレージデバイスまたは障害のあるストレージデバイスの置き換え
IBM Power Systems でローカルストレージデバイスを使用してデプロイされた OpenShift Container Storage のオブジェクトストレージデバイス (OSD) を置き換えることができます。基礎となるストレージデバイスを置き換える必要がある場合は、この手順を使用します。
前提条件
データに耐久性があることを確認します。
- OpenShift Web コンソールで、Storage → Overview にナビゲートします。
- Status カードの Persistent Storage で、Data Resiliency に緑色のチェックマークが付いていることを確認します。
手順
置き換える必要がある OSD と、その OSD がスケジュールされている OpenShift Container Platform ノードを特定します。
$ oc get -n openshift-storage pods -l app=rook-ceph-osd -o wide出力例:
rook-ceph-osd-0-86bf8cdc8-4nb5t 0/1 crashLoopBackOff 0 24h 10.129.2.26 worker-0 <none> <none> rook-ceph-osd-1-7c99657cfb-jdzvz 1/1 Running 0 24h 10.128.2.46 worker-1 <none> <none> rook-ceph-osd-2-5f9f6dfb5b-2mnw9 1/1 Running 0 24h 10.131.0.33 worker-2 <none> <none>この例では、
rook-ceph-osd-0-86bf8cdc8-4nb5tを置き換える必要があり、worker-0は OSD がスケジュールされる RHOCP ノードです。注記置き換える OSD が正常である場合、Pod のステータスは
Runningになります。置き換えられる OSD の OSD デプロイメントをスケールダウンします。
$ osd_id_to_remove=0 $ oc scale -n openshift-storage deployment rook-ceph-osd-${osd_id_to_remove} --replicas=0ここで、
osd_id_to_removeはrook-ceph-osd接頭辞の直後にくる Pod 名の整数です。この例では、デプロイメント名はrook-ceph-osd-0です。出力例:
deployment.apps/rook-ceph-osd-0 scaledrook-ceph-osdPod が停止していることを確認します。$ oc get -n openshift-storage pods -l ceph-osd-id=${osd_id_to_remove}出力例:
No resources found in openshift-storage namespace.注記rook-ceph-osdPod がterminating状態にある場合は、forceオプションを使用して Pod を削除します。$ oc delete -n openshift-storage pod rook-ceph-osd-0-86bf8cdc8-4nb5t --grace-period=0 --force出力例:
warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely. pod "rook-ceph-osd-0-86bf8cdc8-4nb5t" force deleted
新規 OSD を追加できるようにクラスターから古い OSD を削除します。
置き換える OSD に関連付けられた
DeviceSetを特定します。$ oc get -n openshift-storage -o yaml deployment rook-ceph-osd-${osd_id_to_remove} | grep ceph.rook.io/pvc出力例:
ceph.rook.io/pvc: ocs-deviceset-localblock-0-data-0-64xjl ceph.rook.io/pvc: ocs-deviceset-localblock-0-data-0-64xjlこの例では、PVC 名は
ocs-deviceset-localblock-0-data-0-64xjlです。古い
ocs-osd-removalジョブを削除します。$ oc delete -n openshift-storage job ocs-osd-removal-job出力例:
job.batch "ocs-osd-removal-job" deletedopenshift-storageプロジェクトを変更します。$ oc project openshift-storageクラスターから以前の OSD を削除します。
$ oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_IDS=${osd_id_to_remove} | oc -n openshift-storage create -f -コマンドにコンマ区切りの OSD ID を追加して、複数の OSD を削除できます。(例: FAILED_OSD_IDS=0,1,2)
警告この手順により、OSD はクラスターから完全に削除されます。
osd_id_to_removeの正しい値が指定されていることを確認します。
ocs-osd-removalPod のステータスをチェックして、OSD が正常に削除されたことを確認します。Completedのステータスで、OSD の削除ジョブが正常に完了したことを確認します。$ oc get pod -l job-name=ocs-osd-removal-job -n openshift-storage注記ocs-osd-removalが失敗し、Pod が予想されるCompletedの状態にない場合、追加のデバッグのために Pod ログを確認します。以下に例を示します。$ oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1置き換える OSD に関連付けられた Persistent Volume Claim (永続ボリューム要求、PVC) リソースを削除します。
PVC に関連付けられた PV を特定します。
$ oc get -n openshift-storage pvc ocs-deviceset-<x>-<y>-<pvc-suffix>ここで、
x、y、およびpvc-suffixは、ステップ 4(a) で特定されたDeviceSetの値です。出力例:
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE ocs-deviceset-localblock-0-data-0-64xjl Bound local-pv-8137c873 256Gi RWO localblock 24hこの例では、関連付けられた PV は
local-pv-8137c873です。置き換えるデバイスの名前を特定します。
$ oc get pv local-pv-<pv-suffix> -o yaml | grep pathここで、
pv-suffixは、前のステップで特定された PV 名の値です。出力例:
path: /mnt/local-storage/localblock/vdcこの例では、デバイス名は
vdcです。置き換える OSD に関連付けられた
prepare-podを特定します。$ oc describe -n openshift-storage pvc ocs-deviceset-<x>-<y>-<pvc-suffix> | grep Mountedここで、
x、y、およびpvc-suffixは、直前の手順で特定されたDeviceSetの値です。出力例:
Mounted By: rook-ceph-osd-prepare-ocs-deviceset-localblock-0-data-0-64knzkcこの例では、
prepare-podの名前はrook-ceph-osd-prepare-ocs-deviceset-localblock-0-data-0-64knzkcです。関連付けられた PVC を削除する前に
osd-preparePod を削除します。$ oc delete -n openshift-storage pod rook-ceph-osd-prepare-ocs-deviceset-<x>-<y>-<pvc-suffix>-<pod-suffix>ここで、
x、y、pvc-suffix、およびpod-suffixは、直前の手順で特定されたosd-preparePod 名の値です。出力例:
job.batch "ocs-osd-removal-job" deletedopenshift-storageプロジェクトを変更します。$ oc project openshift-storageクラスターから以前の OSD を削除します。
$ oc process -n openshift-storage ocs-osd-removal \ -p FAILED_OSD_IDS=<failed_osd_id> FORCE_OSD_REMOVAL=false | oc create -n openshift-storage -f -<failed_osd_id>rook-ceph-osd接頭辞の直後の Pod 名の整数です。コマンドにコンマ区切りの OSD ID を追加して、複数の OSD を削除できます (例:FAILED_OSD_IDS=0,1,2)OSD が 3 つしかないクラスター、または OSD が削除された後にデータの 3 つのレプリカすべてを復元するにはスペースが不十分なクラスターでは、
FORCE_OSD_REMOVAL値をtrueに変更する必要があります。警告この手順により、OSD はクラスターから完全に削除されます。
osd_id_to_removeの正しい値が指定されていることを確認します。
ocs-osd-removal-jobPod のステータスをチェックして、OSD が正常に削除されたことを確認します。Completedのステータスで、OSD の削除ジョブが正常に完了したことを確認します。pod "rook-ceph-osd-prepare-ocs-deviceset-localblock-0-data-0-64knzkc" deleted置き換える OSD に関連付けられた PVC を削除します。
$ oc delete -n openshift-storage pvc ocs-deviceset-<x>-<y>-<pvc-suffix>ここで、
x、y、およびpvc-suffixは、直前の手順で特定されたDeviceSetの値です。出力例:
persistentvolumeclaim "ocs-deviceset-localblock-0-data-0-64xjl" deleted
先の手順で特定された、置き換えるデバイスに関連付けられた PV を削除します。この例では、PV 名は
local-pv-8137c873です。$ oc delete pv local-pv-8137c873出力例:
persistentvolume "local-pv-8137c873" deleted古いデバイスを置き換え、新規デバイスを使用して新規の OpenShift Container Platform PV を作成します。
置き換えるデバイスで OpenShift Container Platform ノードにログインします。この例では、OpenShift Container Platform ノードは
worker-0です。$ oc debug node/worker-0出力例:
Starting pod/worker-0-debug ... To use host binaries, run `chroot /host` Pod IP: 192.168.88.21 If you don't see a command prompt, try pressing enter. # chroot /host先に特定したデバイス名
vdcを使用して置き換える/dev/diskの内容を記録します。# ls -alh /mnt/local-storage/localblock出力例:
total 0 drwxr-xr-x. 2 root root 17 Nov 18 15:23 . drwxr-xr-x. 3 root root 24 Nov 18 15:23 .. lrwxrwxrwx. 1 root root 8 Nov 18 15:23 vdc -> /dev/vdcLocalVolumeSetCR の名前を見つけ、置き換えるデバイス/dev/diskを削除またはコメントアウトします。$ oc get -n openshift-local-storage localvolumeset NAME AGE localblock 25h
置き換えるデバイスで OpenShift Container Platform ノードにログインし、古い
symlinkを削除します。$ oc debug node/worker-0出力例:
Starting pod/worker-0-debug ... To use host binaries, run `chroot /host` Pod IP: 192.168.88.21 If you don't see a command prompt, try pressing enter. # chroot /host置き換えるデバイス名の古い
symlinkを特定します。この例では、デバイス名はvdcです。# ls -alh /mnt/local-storage/localblock出力例:
total 0 drwxr-xr-x. 2 root root 17 Nov 18 15:23 . drwxr-xr-x. 3 root root 24 Nov 18 15:23 .. lrwxrwxrwx. 1 root root 8 Nov 18 15:23 vdc -> /dev/vdcsymlinkを削除します。# rm /mnt/local-storage/localblock/vdcsymlinkが削除されていることを確認します。# ls -alh /mnt/local-storage/localblock出力例:
total 0 drwxr-xr-x. 2 root root 6 Nov 18 17:11 . drwxr-xr-x. 3 root root 24 Nov 18 15:23 ..重要OpenShift Container Storage 4.5 以降の新規デプロイメントでは、LVM が使用されていないため、
ceph-volumeraw モードが動作します。そのため、追加の検証は不要であり、次のステップに進むことができます。
- デバイスを新しいデバイスに置き換えます。
正しい OpenShift Container Platform ノードにログインし、新規ドライブのデバイス名を特定します。同じデバイスを使用しない限り、デバイス名は変更する必要があります。
# lsblk出力例:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 252:0 0 40G 0 disk |-vda1 252:1 0 4M 0 part |-vda2 252:2 0 384M 0 part /boot `-vda4 252:4 0 39.6G 0 part `-coreos-luks-root-nocrypt 253:0 0 39.6G 0 dm /sysroot vdb 252:16 0 512B 1 disk vdd 252:32 0 256G 0 diskこの例では、新しいデバイス名は
vddです。-
新しい
/dev/diskが利用可能になると、localvolumeset によって自動検出されます。 新規 PV が
Available状態にあり、正しいサイズであることを確認します。$ oc get pv | grep 256Gi出力例:
local-pv-1e31f771 256Gi RWO Delete Bound openshift-storage/ocs-deviceset-localblock-2-data-0-6xhkf localblock 24h local-pv-ec7f2b80 256Gi RWO Delete Bound openshift-storage/ocs-deviceset-localblock-1-data-0-hr2fx localblock 24h local-pv-8137c873 256Gi RWO Delete Available localblock 32m新規デバイス用に新規 OSD を作成します。
rook-ceph-operatorを再起動して Operator の調整を強制的に実行して新規 OSD をデプロイします。rook-ceph-operatorの名前を特定します。$ oc get -n openshift-storage pod -l app=rook-ceph-operator出力例:
NAME READY STATUS RESTARTS AGE rook-ceph-operator-85f6494db4-sg62v 1/1 Running 0 1d20hrook-ceph-operatorを削除します。$ oc delete -n openshift-storage pod rook-ceph-operator-85f6494db4-sg62v出力例:
pod "rook-ceph-operator-85f6494db4-sg62v" deletedこの例では、rook-ceph-operator Pod 名は
rook-ceph-operator-85f6494db4-sg62vです。rook-ceph-operatorPod が再起動していることを確認します。$ oc get -n openshift-storage pod -l app=rook-ceph-operator出力例:
NAME READY STATUS RESTARTS AGE rook-ceph-operator-85f6494db4-wx9xx 1/1 Running 0 50s新規 OSD の作成には、Operator が再起動するまでに数分かかる場合があります。
ocs-osd-removalジョブを削除します。$ oc delete -n openshift-storage job ocs-osd-removal-job出力例:
job.batch "ocs-osd-removal-job" deleted
検証手順
新しい OSD が実行されており、新規 PVC が作成されていることを確認します。
$ oc get -n openshift-storage pods -l app=rook-ceph-osd出力例:
rook-ceph-osd-0-76d8fb97f9-mn8qz 1/1 Running 0 23m rook-ceph-osd-1-7c99657cfb-jdzvz 1/1 Running 1 25h rook-ceph-osd-2-5f9f6dfb5b-2mnw9 1/1 Running 0 25h$ oc get -n openshift-storage pvc | grep localblock出力例:
ocs-deviceset-localblock-0-data-0-q4q6b Bound local-pv-8137c873 256Gi RWO localblock 10m ocs-deviceset-localblock-1-data-0-hr2fx Bound local-pv-ec7f2b80 256Gi RWO localblock 1d20h ocs-deviceset-localblock-2-data-0-6xhkf Bound local-pv-1e31f771 256Gi RWO localblock 1d20hOpenShift Web コンソールにログインし、ストレージダッシュボードを表示します。
図5.2 デバイスの置き換え後の OpenShift Container Platform ストレージダッシュボードの OSD ステータス
5.4. IBM Z または LinuxONE インフラストラクチャーで動作するストレージデバイスまたは失敗したストレージデバイスの置き換え
IBM Z または LinuxONE インフラストラクチャーの動作するストレージデバイスまたは障害のあるストレージデバイスを、新規 SCSI ディスクに置き換えることができます。
IBM Z または LinuxONE は、外部ディスクストレージからの永続ストレージとして SCSI FCP ディスク論理ユニット (SCSI ディスク) に対応します。SCSI ディスクは、FCP デバイス番号、2 つのターゲットのワールドワイドポート名 (WWPN1 および WWPN2) と、論理ユニット番号 (LUN) を使用して識別できます。詳細は、次を参照してください。https://www.ibm.com/support/knowledgecenter/SSB27U_6.4.0/com.ibm.zvm.v640.hcpa5/scsiover.html
前提条件
データに耐久性があることを確認します。
- OpenShift Web コンソールで、Storage → Overview にナビゲートします。
- Status カードの Persistent Storage で、Data Resiliency に緑色のチェックマークが付いていることを確認します。
手順
以下のコマンドを使用してすべてのディスクを一覧表示します。
$ lszdev出力例:
TYPE ID zfcp-host 0.0.8204 yes yes zfcp-lun 0.0.8204:0x102107630b1b5060:0x4001402900000000 yes no sda sg0 zfcp-lun 0.0.8204:0x500407630c0b50a4:0x3002b03000000000 yes yes sdb sg1 qeth 0.0.bdd0:0.0.bdd1:0.0.bdd2 yes no encbdd0 generic-ccw 0.0.0009 yes noSCSI ディスクは、
IDセクションの<device-id>:<wwpn>:<lun-id>構造でzfcp-lunとして表されます。最初のディスクはオペレーティングシステムに使用されます。1 つのストレージデバイスに障害が発生した場合は、これを新しいディスクに置き換えることができます。ディスクを削除します。
ディスクで以下のコマンドを実行し、
scsi-idを、置き換えるディスクの SCSI ディスク識別子に置き換えます。$ chzdev -d scsi-idたとえば、以下のコマンドはデバイス ID
0.0.8204、WWPN0x500507630a0b50a4、および LUN0x4002403000000000のディスクを 1 つ削除します。$ chzdev -d 0.0.8204:0x500407630c0b50a4:0x3002b03000000000以下のコマンドを使用して新規 SCSI ディスクを追加します。
$ chzdev -e 0.0.8204:0x500507630b1b50a4:0x4001302a00000000注記新規ディスクのデバイス ID は、置き換えるディスクと同じである必要があります。新規ディスクは、WWPN および LUN ID で識別されます。
すべての FCP デバイスを一覧表示して、新規ディスクが設定されていることを確認します。
$ lszdev zfcp-lun TYPE ID ON PERS NAMES zfcp-lun 0.0.8204:0x102107630b1b5060:0x4001402900000000 yes no sda sg0 zfcp-lun 0.0.8204:0x500507630b1b50a4:0x4001302a00000000 yes yes sdb sg1
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}