Data Online Migration:移行に関するよくある質問

移行速度と移行期間の見積もり方法

移行速度について：

• デフォルトでは、Data Online Migration は各タスクに固定の理論上のピーク帯域幅と QPS を割り当てます。詳細については、「タスクの帯域幅と QPS」をご参照ください。ビジネスニーズに基づいて理論上のピーク帯域幅と QPS を設定し、移行トラフィックと本番トラフィック間の競合を回避して、通常の運用に影響が出ないようにしてください。

• 移行速度が理論上のピーク帯域幅と QPS に達することは保証されません。主な要因は次のとおりです。

  • 移行元と移行先の間のネットワークリンクの帯域幅と品質。高レイテンシーまたは高いパケット損失率を伴う長距離リンク (越境のパブリックネットワーク転送など) は、効率を低下させたり、頻繁なファイル転送の失敗を引き起こす可能性があります。パフォーマンスを向上させるには、専用線または OSS アクセラレーションエンドポイントなどのアクセラレーションリンクを使用してください。

  • 移行元と移行先の読み書き能力、および平均ファイルサイズ。移行サービスは、ディレクトリを横断し、移行元からメタデータとコンテンツを読み取り、メタデータとコンテンツを移行先に書き込み、同時にメタデータを読み返します。移行元の横断能力はスキャン速度に影響します。いずれかのエンドでの読み書きパフォーマンスは移行速度に影響します。これは特に、200 KB 未満の数百万の小さなファイルを移行する場合に顕著です。平均ファイルサイズは、移行元の総データ量を総ファイル数で割って見積もります。

  • 移行元のディレクトリ数とファイルの分布。ディレクトリをサポートするファイルシステム (LocalFS や FTP など) の場合、Data Online Migration はディレクトリをレベルごとに並行してスキャンします。ディレクトリが多すぎるか、ファイルの分布がまばらだと、スキャンが遅くなります。

  • ソフトウェアとハードウェアの構成、およびプロキシインスタンスの数。移行元または移行先のデータアドレスがプロキシを使用している場合、プロキシがボトルネックになる可能性があります。プロキシの選択に関するガイダンスについては、「プロキシの選択」をご参照ください。

• これらの要因により、Data Online Migration は移行速度を保証しません。完全な移行を実行する前に、小規模な概念実証 (PoC) でセットアップを検証し、実際のパフォーマンスを正確に見積もってください。

移行期間について：

• 妥当な移行速度を見積もった後、総データ量と総ファイル数を使用して移行期間を計算してください。可能な限り最短の期間を 総ストレージ容量 ÷ 帯域幅 と 総ファイル数 ÷ QPS を使用して見積もり、大きい方の値を取ってください。

• 計算された移行期間は理論値です。帯域幅の変動、失敗後の再試行、およびその他の変数を考慮に入れてください。特にダウンタイムを必要とする本番移行の場合は、常に予備計画を準備し、バッファ時間を確保してください。

• Data Online Migration は、タスクごとのリソース割り当てに上限を設けています。詳細については、「タスクの帯域幅と QPS」をご参照ください。

以下は、包括的な評価の例です。

• シナリオ 1：

  • 質問：移行元は S3 で、約 1 TB のデータと 1,000 万個のファイルがあります。移行先は OSS です。タスクは北京リージョンで作成されます。移行にはどのくらいの時間がかかりますか？

  • 回答：「タスクの帯域幅と QPS」によると、北京での単一タスクの理論上の速度は 2 Gbps および 2,000 ファイル/秒です。計算は次のとおりです。

    • ストレージ容量による期間：1 TB ÷ 2 Gbps ≈ 1.1 時間。

    • ファイル数による期間：10,000,000 ÷ 2,000 ファイル/秒 ≈ 1.4 時間。

    • 理論上の移行期間：大きい方の値、つまり 1.4 時間 を取ります。

• シナリオ 2：

  • 質問：移行元は OSS で、約 1 TB のデータと 100,000 個のファイルがあります。移行先は Alibaba Cloud NAS です。タスクはシンガポールリージョンで作成されます。移行にはどのくらいの時間がかかりますか？

  • 回答：「タスクの帯域幅と QPS」によると、シンガポールでの単一タスクの理論上の速度は 1 Gbps および 2,000 ファイル/秒です。ただし、移行先が LocalFS であるため、理論上の QPS 制限は 200 ファイル/秒です。計算は次のとおりです。

    • ストレージ容量による期間：1 TB ÷ 1 Gbps ≈ 2.3 時間。

    • ファイル数による期間：100,000 ÷ 200 ファイル/秒 ≈ 500 秒。

    • 理論上の移行期間：大きい方の値、つまり 2.3 時間 を取ります。

コンソールにおけるプロキシの異常ステータス

Data Online Migration のプロキシインスタンスは、正常に機能するためにデプロイする必要があります。正しくデプロイした後もプロキシのステータスが [Connection Abnormal] と表示される場合は、以下を確認してください。

• ネットワーク接続。「プロキシを使用した移行」の [Network type] パラメーターを参照して、プロキシマシンから Data Online Migration サービスドメインへの接続性を確認してください。

• 不正確な認証情報または不十分な権限。例：

  • 入力ミス。例えば、コピー＆ペーストのエラーによる不完全または破損した AccessKeyId または SecretAccessKey。

  • 不十分な権限。AccessKeyId には以下のいずれかの権限が必要であり、[Resource scope] は [Account level] に設定する必要があります。

    • mgw:VerifyAgentTunnel

    • AliyunOSSImportReadOnlyAccess

    • AliyunOSSImportFullAccess

  • アカウントの不一致。AccessKeyId が現在の RAM ユーザーまたは同じ Alibaba Cloud アカウント配下の別の RAM ユーザーに属していません。クロスアカウント移行に関係なく、現在の Alibaba Cloud アカウント配下の RAM ユーザーの認証情報を使用する必要があり、その RAM ユーザーは上記の 3 つの権限のいずれかを持っている必要があります。

• RAM の [AccessKey-level network access control policy] によって制限された認証情報。Data Online Migration では、AccessKeyId がすべてのネットワークセグメントからのアクセスを許可する必要があります。パブリックネットワークアクセスを許可するには、[AccessKey-level network access control policy] ページに移動し、[Enable] を選択し、[Allow all public network access] をクリックし (システムは自動的に ::/0 と 0.0.0.0/0 を追加します)、パブリックネットワークポリシータブで [OK] をクリックし、ページ下部の [Submit] をクリックしてください。

• RAM の [Access policy] によって制限された認証情報。この RAM ユーザーに IP アドレス制限を含むカスタムポリシーを割り当てた場合、プロキシの実行に失敗する可能性があります。

• プロキシマシンのシステムクロックが不正確。時刻は実時間から 5 分以上ずれていてはなりません。

• 変更された、または不完全なデプロイコマンド。コンソールから自動生成されたデプロイコマンドを、表示されているとおりに正確にコピー＆ペーストしてください。変更しないでください。

プロキシのステータスが不安定な場合、考えられる原因は次のとおりです。

• 不安定なネットワーク。プロキシと Data Online Migration サービス間のネットワーク品質が悪いと、断続的な接続問題が発生します。プロキシのネットワーク環境が変更された場合は、「プロキシを使用した移行」で説明されているように接続性を再確認してください。

• 高いプロキシ負荷。実行中の移行タスクは、時折接続の異常を引き起こす可能性があります。タスクが正常に実行されている場合、これは想定内です。マシンのロードアベレージが高い場合は、プロキシインスタンスをスケールアウトするか、[Maximum files migrated per second] の設定を下げてください。

• 関連するチャネルインスタンスでレート制限が有効になっている。プロキシのヘルスチェックは少量のチャネル QPS を消費し、移行リクエストと競合して拒否される可能性があります。チャネルの [Requests per second] 制限を増やすか、チャネルレベルのレート制限を無効にしてください。

• プロキシプロセスが終了した。「プロキシプロセスの表示、開始、停止」を参照して、プロセスのステータスを確認してください。プロキシマシンのインスタンスタイプが推奨仕様を下回っている場合、メモリ不足によりプロセスが終了する可能性があります。推奨仕様については、「プロキシの選択」をご参照ください。

• 重複したデプロイ。各プロキシインスタンスは 1 台のマシンでのみ実行する必要があります。同じインスタンスを複数のマシンにデプロイすると、競合と不安定さが発生します。マシンを切り替えるには、まず古いプロキシプロセスを停止してから再デプロイしてください。

移行タスクに進捗が見られない

• バックグラウンドスケジューリング。タスクは通常、開始前にキューで 10〜15 分待機します。しばらくお待ちください。

• ファイルがフィルタリングされた。タスクがファイルフィルターを使用し、基準に一致する移行元ファイルが少ない場合、進捗の更新が遅くなります。

• マニフェストの前処理時間。移行元がマニフェストタイプのデータアドレスの場合、マニフェスト内の総ファイル数が増えるにつれて前処理時間も長くなります。

• 大きなファイルの同時移行。タスク詳細ページの帯域幅グラフが期待される傾向と一致する場合、これは正常です。

• その他の考えられる原因：

  • LocalFS または FTP 移行元の場合、ディレクトリが多すぎるか、ファイルの分布がまばらだとスキャンが遅くなります。権限エラーやディレクトリの破損もスキャンを停止させる可能性があります。

  • LocalFS 移行先の場合、多くのギガバイトサイズのファイルを移行すると、進捗の更新が遅れることがあります。プロキシマシンの実際の帯域幅を確認してください (例：ECS Cloud Monitor 経由)。

  • いずれかのエンドでプロキシを使用している場合、プロキシマシンの高い負荷や接続の問題がタスクの進捗に影響します。

移行に失敗したファイルの表示方法

移行中に、移行元の権限不足、ネットワークの問題、またはその他のエラーにより、一部のファイルが失敗することがあります。失敗したファイルとその原因を特定するには、次のいずれかの方法を使用します。

• 方法 1：移行レポートのプッシュ

タスクを作成する際に、移行レポートの配信を有効にしてください。この設定は後で変更することもできます。タスク完了後、Data Online Migration は完全な移行記録を移行先のデータアドレスの指定された場所に書き込みます。このレポートを確認して、失敗したファイルとその理由を特定してください。

• 方法 2：移行ログのプッシュ

移行タスクを作成する際に、移行ログの配信を有効にしてください。Data Online Migration はリアルタイムのログを Simple Log Service (SLS) にプッシュします。SLS でこれらのログを分析して、失敗したファイルと具体的なエラー詳細を見つけてください。

一般的な移行失敗の理由

次の表は、移行失敗のエラーコードキーワード (一部) を示しています。これらのコードは、以下のような状況で表示されることがあります：

• データアドレスの作成が失敗したときのエラーメッセージ。

• タスクが実行中に失敗したときのタスク履歴のエラーメッセージ。

• 移行レポートの [Failure reason] フィールド。

underscoreUserMetaDropOrSkipUids=<UID>,drop;

移行後のデータ量の不一致

移行完了後に移行元と移行先のデータ量が異なる場合は、以下を調査してください：

移行先のデータ量がより少ない場合、考えられる原因は次のとおりです：

• 移行中にデータが変更された。移行元に新しい書き込みがあったか、移行先で削除 (手動またはライフサイクルポリシーによる) があった可能性があります。

• 移行元に複数のバージョンが含まれている (OSS、S3、または NAS のごみ箱など)。Data Online Migration は最新バージョンのみを移行します。

• 統計の遅延。移行先のメトリクスは数時間から数日遅れることがあります。関連ドキュメントを参照するか、ossutil などのツールを使用して手動で確認してください。

• 一部のデータがスキップされた。例えば、移行元の 1 GB のファイルと移行先の 100 MB のファイルは、タスクの上書き設定に基づいてスキップされることがあります。

• 移行元にフラグメントが含まれている。Data Online Migration は不完全なオブジェクトやフラグメントを移行しません。

• ファイルフィルター設定が不正確。フィルターが有効になっている場合は、意図しないスペースや特殊文字がないかルールを確認してください。

• 移行元のプレフィックスが不正確。プレフィックスを指定すると、そのプレフィックス以下のデータのみが移行されます。

• ストレージクラスの違い。NAS などのファイルシステムは、ディレクトリをストレージ使用量に含みます。OSS などのオブジェクトストレージにはディレクトリの概念がなく、空のオブジェクトはカウントされません。

• 部分的な NAS マウントの失敗。移行元が複数のプロキシを持つ LocalFS であり、一部の NAS マウントが破損している場合、それらのプロキシ経由でアクセスされるファイルは NotFound エラーによりスキップされ、移行される総データが減少する可能性があります。

移行先のデータ量がより多い場合、考えられる原因は次のとおりです：

• 移行中にデータが変更された。移行元で削除 (手動またはライフサイクルポリシーによる) があったか、移行先に新しい書き込みがあった可能性があります。

• 移行先で複数バージョン機能が有効になっている (OSS や NAS のごみ箱など)。Data Online Migration は非複数バージョン API を使用します。複数バージョンが有効になっている場合、各書き込みで新しいバージョンが作成されます。

• 一部のデータがスキップされた。例えば、移行元の 100 MB のファイルと移行先の 1 GB のファイルは、上書き設定に基づいてスキップされることがあります。

• 移行先に残存するフラグメントまたは一時ファイル。タスクが失敗した場合 (ユーザー操作、重大なエラー、またはネットワークの問題による)、フラグメントや一時ファイルが残ることがあります。

• ファイルフィルター設定が不正確。意図しないスペースや特殊文字がないかフィルターのルールを確認してください。

• 移行先のプレフィックス下に既存のデータがある。移行前に移行先のプレフィックスにすでにデータが含まれていた場合、そのデータは残ります (ただし、同名のファイルはタスク設定に基づいて上書きされる場合があります)。

• ストレージクラスの違い。NAS などのファイルシステムは、ディレクトリをストレージ使用量に含みます。OSS などのオブジェクトストレージにはディレクトリの概念がなく、空のオブジェクトはカウントされません。

• 移行レポートのストレージオーバーヘッド。移行レポートの配信を有効にした場合、レポート自体が移行された総ファイル数に比例してスペースを消費します。

移行元の過剰な下りトラフィックまたはファイルの繰り返し移行

通常、Data Online Migration は各移行元ファイルを一度だけダウンロードします。移行後に予想以上の移行元の下りトラフィックが確認された場合、考えられる原因は次のとおりです：

• 内部的な再試行。ネットワークの一時的な切断、読み書きのスロットリング、またはプロキシのボトルネックは、限定的な自動再試行をトリガーすることがあります。

• 外部システムからのアクセス。移行中に他のシステム (アプリケーションや CDN オリジンフェッチなど) が移行元にアクセスすると、下りトラフィックが増加します。

以前に移行されたファイルが、後続の実行でスキップされずに再移行される場合、考えられる原因は次のとおりです：

• 不適切な [Overwrite mode]。 [Force overwrite] に設定されている場合、Data Online Migration は既存のコンテンツに関係なく、常に移行先ファイルを上書きします。

• 移行先のライフサイクルポリシー。タスク作成時に [Preserve last modified time] を選択した場合、移行元ファイルのタイムスタンプが移行先に適用されます。移行先にファイルを削除するライフサイクルポリシーがある場合、移行されたファイルは直後に削除される可能性があります。

• 移行元の頻繁な更新。上書きモードが [Overwrite based on last modified time] の場合、移行元のタイムスタンプが更新されると (コンテンツの変更がなくても)、次回の実行で再移行がトリガーされます。

OSS のクロスアカウント移行に関する問題

クロスアカウントのシナリオには、他のアカウントから自分のアカウントへ、自分のアカウントから他のアカウントへ、および他のアカウントから他のアカウントへの 3 つがあります (複雑なため推奨されません。最初の 2 つのシナリオのいずれかに変換することを推奨します)。認可の問題が発生する可能性があります。概要は次のとおりです：

• 主要な認可手順：

  • RAM コンソールを介して、自分のアカウントに RAM ロールを作成します。「データ移行用の RAM ロールの作成」をご参照ください。

  • RoleName を他のアカウントの管理者と共有します。管理者は、ターゲットバケットに対する権限を付与します。「移行元バケットの認可」または「移行先バケットの認可」をご参照ください。

  • これで認可は完了です。Data Online Migration でバケットのデータアドレスを作成する際に、[Authorization role] フィールドに RoleName を入力します。

• クロスアカウント認可後、RoleName に大文字が含まれている場合、「権限不足」エラーが続くことがあります。RAM の元の RoleName に大文字が含まれている場合でも (例：MyOssImportRole)、バケットの ACL ポリシーではすべて小文字 (例：myossimportrole) を使用してください。

NAS のクロスアカウント移行に関する問題

• Data Online Migration を使用する場合、異なる Alibaba Cloud アカウント間で NAS インスタンスを移行することは、クロスアカウントのシナリオには該当しません。このサービスは、標準の POSIX I/O を使用して指定されたディレクトリを読み書きし、基盤となるストレージが NAS であることやその所有権を認識しません。

• プロキシをデプロイし、NAS をプロキシにマウントしてから、それを LocalFS データアドレスとして扱う必要があります。意図しないディスクパスからの読み取りや書き込みを避けるために、ディレクトリマッピングに細心の注意を払ってください。

• 例：アカウント A の NAS から自分のアカウントの NAS へ移行します。

  • アカウント A の NAS をマシン M1 にマウントします。M1 はアカウント A の ECS インスタンス (推奨) またはアカウント A の NAS をマウントできる任意のマシンにすることができます。

  • Data Online Migration コンソールで、プロキシインスタンス agent1 を作成し、M1 にデプロイします。

  • 自分のアカウントの NAS をマシン M2 にマウントします。M2 は自分のアカウントの ECS インスタンス (推奨) または互換性のある任意のマシンにすることができます。

  • Data Online Migration コンソールで、プロキシインスタンス agent2 を作成し、M2 にデプロイします。

  • 両方のプロキシが「正常」ステータスであることを確認した後、「LocalFS システム間の移行」に従ってデータアドレスと移行タスクを作成します。

OSS は Alibaba Cloud 国際サイトアカウントと中国サイトアカウント間の移行をサポートしていますか？

はい。詳細については、「Alibaba Cloud OSS インスタンス間の移行」をご参照ください。