サポートコンソール開発者トライアルの開始お問い合わせ

3.5. トラブルシューティング

移行用のカスタムリソース (CR) を表示し、ログをダウンロードして失敗した移行の失敗についてのトラブルシューティングを行うことができます。

移行の失敗時にアプリケーションが停止した場合は、データ破損を防ぐために手作業でアプリケーションをロールバックする必要があります。

注記

移行時にアプリケーションが停止しなかった場合には、手動のロールバックは必要ありません。元のアプリケーションがソースクラスター上で依然として実行されているためです。

3.5.1. 移行カスタムリソースの表示

Cluster Application Migration (CAM) ツールは以下の カスタムリソース (Custom Resource、CR) を作成します。

移行アーキテクチャーの図

20 MigCluster (設定、CAM クラスター): クラスター定義

20 MigStorage (設定、CAM クラスター): ストレージ定義

20 MigPlan (設定、CAM クラスター): 移行計画

MigPlan CR は移行されるソースおよびターゲットクラスター、リポジトリー、および namespace を記述します。これは 0、1 または多数の MigMigration CR に関連付けられます。

注記

MigPlan CR を削除すると、関連付けられた MigMigration CR が削除されます。

20 BackupStorageLocation (設定、CAM クラスター): Velero バックアップオブジェクトの場所

20 VolumeSnapshotLocation (設定、CAM クラスター): Velero ボリュームスナップショットの場所

20 MigMigration (アクション、CAM クラスター): 移行、移行時に作成される

MigMigration CR は、データのステージングまたは移行を実行するたびに作成されます。各 MigMigration CR は MigPlan CR に関連付けられます。

20 Backup (アクション、ソースクラスター): 移行計画の実行時に、MigMigration CR は各ソースクラスターに 2 つの Velero バックアップ CR を作成します。

  • Kubernetes オブジェクトのバックアップ CR #1
  • PV データのバックアップ CR #2

20 Restore (アクション、ターゲットクラスター): 移行計画の実行時に、MigMigration CR はターゲットクラスターに 2 つの Velero リスト CR を作成します。

  • PV データのリストア CR #1 (バックアップ CR #2 の使用)
  • Kubernetes オブジェクトのリストア CR #2 (バックアップ CR #1 の使用)

手順

  1. CR 名を取得します。 

    $ oc get <migration_cr> -n openshift-migration 1
    1
    移行 CR を指定します (例: migmigration)。

    出力は以下の例のようになります。 

    NAME                                   AGE
88435fe0-c9f8-11e9-85e6-5d593ce65e10   6m42s

  2. CR を表示します。 

    $ oc describe <migration_cr> <88435fe0-c9f8-11e9-85e6-5d593ce65e10> -n openshift-migration

    出力は以下の例のようになります。

MigMigration の例

name:         88435fe0-c9f8-11e9-85e6-5d593ce65e10
namespace:    openshift-migration
labels:       <none>
annotations:  touch: 3b48b543-b53e-4e44-9d34-33563f0f8147
apiVersion:  migration.openshift.io/v1alpha1
kind:         MigMigration
metadata:
  creationTimestamp:  2019-08-29T01:01:29Z
  generation:          20
  resourceVersion:    88179
  selfLink:           /apis/migration.openshift.io/v1alpha1/namespaces/openshift-migration/migmigrations/88435fe0-c9f8-11e9-85e6-5d593ce65e10
  uid:                 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
spec:
  migPlanRef:
    name:        socks-shop-mig-plan
    namespace:   openshift-migration
  quiescePods:  true
  stage:         false
status:
  conditions:
    category:              Advisory
    durable:               True
    lastTransitionTime:  2019-08-29T01:03:40Z
    message:               The migration has completed successfully.
    reason:                Completed
    status:                True
    type:                  Succeeded
  phase:                   Completed
  startTimestamp:         2019-08-29T01:01:29Z
events:                    <none>

Velero バックアップ CR #2 の例 (PV データ)

apiVersion: velero.io/v1
kind: Backup
metadata:
  annotations:
    openshift.io/migrate-copy-phase: final
    openshift.io/migrate-quiesce-pods: "true"
    openshift.io/migration-registry: 172.30.105.179:5000
    openshift.io/migration-registry-dir: /socks-shop-mig-plan-registry-44dd3bd5-c9f8-11e9-95ad-0205fe66cbb6
  creationTimestamp: "2019-08-29T01:03:15Z"
  generateName: 88435fe0-c9f8-11e9-85e6-5d593ce65e10-
  generation: 1
  labels:
    app.kubernetes.io/part-of: migration
    migmigration: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
    migration-stage-backup: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
    velero.io/storage-location: myrepo-vpzq9
  name: 88435fe0-c9f8-11e9-85e6-5d593ce65e10-59gb7
  namespace: openshift-migration
  resourceVersion: "87313"
  selfLink: /apis/velero.io/v1/namespaces/openshift-migration/backups/88435fe0-c9f8-11e9-85e6-5d593ce65e10-59gb7
  uid: c80dbbc0-c9f8-11e9-95ad-0205fe66cbb6
spec:
  excludedNamespaces: []
  excludedResources: []
  hooks:
    resources: []
  includeClusterResources: null
  includedNamespaces:
  - sock-shop
  includedResources:
  - persistentvolumes
  - persistentvolumeclaims
  - namespaces
  - imagestreams
  - imagestreamtags
  - secrets
  - configmaps
  - pods
  labelSelector:
    matchLabels:
      migration-included-stage-backup: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
  storageLocation: myrepo-vpzq9
  ttl: 720h0m0s
  volumeSnapshotLocations:
  - myrepo-wv6fx
status:
  completionTimestamp: "2019-08-29T01:02:36Z"
  errors: 0
  expiration: "2019-09-28T01:02:35Z"
  phase: Completed
  startTimestamp: "2019-08-29T01:02:35Z"
  validationErrors: null
  version: 1
  volumeSnapshotsAttempted: 0
  volumeSnapshotsCompleted: 0
  warnings: 0

Velero リストア CR #2 の例 (Kubernetes リソース)

apiVersion: velero.io/v1
kind: Restore
metadata:
  annotations:
    openshift.io/migrate-copy-phase: final
    openshift.io/migrate-quiesce-pods: "true"
    openshift.io/migration-registry: 172.30.90.187:5000
    openshift.io/migration-registry-dir: /socks-shop-mig-plan-registry-36f54ca7-c925-11e9-825a-06fa9fb68c88
  creationTimestamp: "2019-08-28T00:09:49Z"
  generateName: e13a1b60-c927-11e9-9555-d129df7f3b96-
  generation: 3
  labels:
    app.kubernetes.io/part-of: migration
    migmigration: e18252c9-c927-11e9-825a-06fa9fb68c88
    migration-final-restore: e18252c9-c927-11e9-825a-06fa9fb68c88
  name: e13a1b60-c927-11e9-9555-d129df7f3b96-gb8nx
  namespace: openshift-migration
  resourceVersion: "82329"
  selfLink: /apis/velero.io/v1/namespaces/openshift-migration/restores/e13a1b60-c927-11e9-9555-d129df7f3b96-gb8nx
  uid: 26983ec0-c928-11e9-825a-06fa9fb68c88
spec:
  backupName: e13a1b60-c927-11e9-9555-d129df7f3b96-sz24f
  excludedNamespaces: null
  excludedResources:
  - nodes
  - events
  - events.events.k8s.io
  - backups.velero.io
  - restores.velero.io
  - resticrepositories.velero.io
  includedNamespaces: null
  includedResources: null
  namespaceMapping: null
  restorePVs: true
status:
  errors: 0
  failureReason: ""
  phase: Completed
  validationErrors: null
  warnings: 15

3.5.2. 移行ログのダウンロード

CAM Web コンソールで Velero、Restic、および Migration コントローラーログをダウンロードして、移行の失敗についてのトラブルシューティングを行うことができます。

手順

  1. CAM Web コンソールにログインします。
  2. Plans をクリックし、 移行計画の一覧を表示します。
  3. 特定の移行計画の Options メニュー kebab をクリックし、Logs を選択します。
  4. Download Logs をクリックし、すべてのクラスターの Migration コントローラー、Velero、および Restic のログをダウンロードします。

  5. 特定のログをダウンロードするには、以下を実行します。

    1. ログオプションを指定します。

      • Cluster: ソース、ターゲット、または CAM ホストクラスターを選択します。
      • Log source: Velero、Restic、または Controller を選択します。

      • Pod source: Pod 名を選択します (例: controller-manager-78c469849c-v6wcf)。

        選択したログが表示されます。

        選択した内容を変更することで、ログ選択の設定をクリアできます。

    2. Download Selected をクリックし、選択したログをダウンロードします。

オプションで、以下の例にあるように CLI を使用してログにアクセスできます。 

$ oc get pods -n openshift-migration | grep controller
controller-manager-78c469849c-v6wcf           1/1     Running     0          4h49m

$ oc logs controller-manager-78c469849c-v6wcf -f -n openshift-migration

3.5.3. エラーメッセージ

3.5.3.1. Velero Pod ログの Restic タイムアウトエラーメッセージ

Restic のタイムアウトにより移行が失敗する場合、以下のエラーが Velero Pod ログに表示されます。 

level=error msg="Error backing up item" backup=velero/monitoring error="timed out waiting for all PodVolumeBackups to complete" error.file="/go/src/github.com/heptio/velero/pkg/restic/backupper.go:165" error.function="github.com/heptio/velero/pkg/restic.(*backupper).BackupPodVolumes" group=v1

restic_timeout のデフォルト値は 1 時間です。大規模な移行では、このパラメーターの値を大きくすることができます。値を高くすると、エラーメッセージが返されるタイミングが遅れる可能性があることに注意してください。

手順

  1. OpenShift Container Platform Web コンソールで、Operators Installed Operators に移動します。
  2. Cluster Application Migration Operator をクリックします。
  3. MigrationController タブで、migration-controller をクリックします。

  4. YAML タブで、以下のパラメーター値を更新します。 

    spec:
  restic_timeout: 1h 1
    1
    有効な単位は h (時間)、m (分)、および s (秒) です (例: 3h30m15s)。
  5. Save をクリックします。

3.5.3.2. MigMigration カスタムリソースの ResticVerifyErrors

ファイルシステムデータのコピー方法を使用して PV を移行する際にデータ検証が失敗すると、以下のエラーが MigMigration カスタムリソース (CR) に表示されます。 

status:
  conditions:
  - category: Warn
    durable: true
    lastTransitionTime: 2020-04-16T20:35:16Z
    message: There were verify errors found in 1 Restic volume restores. See restore `<registry-example-migration-rvwcm>`
      for details 1
    status: "True"
    type: ResticVerifyErrors 2
1
エラーメッセージはリストア CR 名を識別します。
2
ResticErrors も表示されます。ResticErrors は、検証エラーが含まれる一般的なエラーの警告です。
注記

データ検証エラーによって移行プロセスが失敗することはありません。

ターゲットクラスターのリストア CR を確認して、データ検証エラーのソースを特定できます。

手順

  1. ターゲットクラスターにログインします。

  2. リストア CR を表示します。 

    $ oc describe <registry-example-migration-rvwcm> -n openshift-migration

    出力では、PodVolumeRestore エラーのある PV を特定できます。 

    status:
  phase: Completed
  podVolumeRestoreErrors:
  - kind: PodVolumeRestore
    name: <registry-example-migration-rvwcm-98t49>
    namespace: openshift-migration
  podVolumeRestoreResticErrors:
  - kind: PodVolumeRestore
    name: <registry-example-migration-rvwcm-98t49>
    namespace: openshift-migration

  3. PodVolumeRestore CR を表示します。 

    $ oc describe <migration-example-rvwcm-98t49>

    出力はエラーをログに記録した Restic Pod を特定します。 

      completionTimestamp: 2020-05-01T20:49:12Z
  errors: 1
  resticErrors: 1
  ...
  resticPod: <restic-nr2v5>

  4. Restic Pod ログを表示します。 

    $ oc logs -f restic-nr2v5

3.5.4. 移行の手動ロールバック

移行の失敗時にアプリケーションが停止された場合は、PV でのデータの破損を防ぐために手動でこれをロールバックする必要があります。

移行時にアプリケーションが停止しなかった場合には、この手順は必要ありません。元のアプリケーションがソースクラスター上で依然として実行されているためです。

手順

  1. ターゲットクラスター上で、移行したプロジェクトに切り替えます。 

    $ oc project <project>

  2. デプロイされたリソースを取得します。 

    $ oc get all

  3. デプロイされたリソースを削除し、アプリケーションがターゲットクラスターで実行されておらず、PVC 上にあるデータにアクセスできるようにします。 

    $ oc delete <resource_type>

  4. これを削除せずに DaemonSet を停止するには、YAML ファイルで nodeSelector を更新します。 

    apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: hello-daemonset
spec:
  selector:
      matchLabels:
        name: hello-daemonset
  template:
    metadata:
      labels:
        name: hello-daemonset
    spec:
      nodeSelector:
        role: worker 1
    1
    いずれのノードにも存在しない nodeSelector 値を指定します。

  5. 不要なデータが削除されるように、各 PV の回収ポリシーを更新します。移行時に、バインドされた PV の回収ポリシーは Retain であり、アプリケーションがソースクラスターから削除される際にデータの損失が生じないようにされます。ロールバック時にこれらの PV を削除できます。 

    apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain 1
  ...
status:
  ...
    1
    Recycle または Delete を指定します。

  6. ソースクラスターで、移行したプロジェクトに切り替えます。 

    $ oc project <project_name>

  7. プロジェクトのデプロイされたリソースを取得します。 

    $ oc get all

  8. デプロイされた各リソースのレプリカを開始します。 

    $ oc scale --replicas=1 <resource_type>/<resource_name>
  9. 手順の実行時に変更した場合は、DaemonSet の nodeSelector を元の値に更新します。

3.5.5. カスタマーサポートケース用のデータの収集

カスタマーサポートケースを作成する場合、 openshift-migration-must-gather-rhel8 イメージを使用して must-gather ツールを実行し、クラスターについての情報を収集し、これを Red Hat カスタマーポータルにアップロードできます。

openshift-migration-must-gather-rhel8 イメージは、デフォルトの must-gather イメージで収集されないログおよびカスタムリソースデータを収集します。

手順

  1. must-gather データを保存するディレクトリーに移動します。

  2. oc adm must-gather コマンドを実行します。 

    $ oc adm must-gather --image=registry.redhat.io/rhcam-1-2/openshift-migration-must-gather-rhel8

    must-gather ツールはクラスター情報を収集し、これを must-gather.local.<uid> ディレクトリーに保存します。

  3. 認証キーおよびその他の機密情報を must-gather データから削除します。

  4. must-gather.local.<uid> ディレクトリーの内容を含むアーカイブファイルを作成します。 

    $ tar cvaf must-gather.tar.gz must-gather.local.<uid>/

    圧縮ファイルを Red Hat カスタマーポータル上のサポートケースに添付します。

3.5.6. 既知の問題

本リリースには、以下の既知の問題があります。

  • 移行時に、Cluster Application Migration (CAM) ツールは以下の namespace アノテーションを保持します。

    • openshift.io/sa.scc.mcs
    • openshift.io/sa.scc.supplemental-groups

    • openshift.io/sa.scc.uid-range

      これらのアノテーションは UID 範囲を保持し、コンテナーがターゲットクラスターのファイルシステムのパーミッションを保持できるようにします。移行された UID が、ターゲットクラスターの既存の namespace または今後の namespace 内の UID を重複させるリスクがあります。(BZ#1748440)

  • AWS バケットが CAM Web コンソールに追加された後に削除される場合、MigStorage CR は更新されないため、そのステータスは True のままになります。(BZ#1738564)
  • ほとんどのクラスタースコープのリソースは CAM ツールで処理されません。アプリケーションがクラスタースコープのリソースを必要とする場合、ターゲットクラスターでそれらを手動で作成する必要がある場合があります。
  • 移行に失敗すると、移行計画は休止状態の Pod のカスタム PV 設定を保持しません。移行を手動でロールバックし、移行計画を削除し、PV 設定で新たな移行計画を作成する必要があります。(BZ#1784899)
  • Restic のタイムアウトにより大規模な移行が失敗する場合は、Migration コントローラー CR の restic_timeout パラメーターの値 (デフォルト: 1h）を増やすことができます。
  • ファイルシステムのコピー方法で移行される PV のデータ検証オプションを選択すると、パフォーマンスは大幅に遅くなります。Velero は各ファイルのチェックサムを生成し、ファイルを復元する際に確認します。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.