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

移行速度と所要時間の見積もり方法

移行速度について：

• デフォルトでは、データオンライン移行は各タスクに固定の理論上のピーク帯域幅と QPS を割り当てます。詳細については、「タスクの帯域幅と QPS」をご参照ください。移行トラフィックと本番トラフィックが競合し、通常の運用に影響を与えることを避けるため、ビジネスニーズに基づいて理論上のピーク帯域幅と QPS を設定してください。

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

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

  • ソースと送信先の読み書き性能、および平均ファイルサイズ。移行サービスは、ディレクトリを走査し、ソースからメタデータとコンテンツを読み取り、送信先にメタデータとコンテンツを書き込むと同時に、メタデータを再度読み取ります。ソースの走査能力はスキャン速度に影響します。どちらかの側の読み書き性能は移行速度に影響します。これは特に、200 KB 未満の数百万の小規模ファイルを移行する場合に顕著です。平均ファイルサイズは、ソースの総データ量を総ファイル数で割って見積もります。

  • ソースディレクトリの数とファイルの分散。ディレクトリをサポートするファイルシステム (LocalFS や FTP など) の場合、データオンライン移行はディレクトリをレベルごとに同時にスキャンします。ディレクトリが多すぎる、またはファイルの分散がまばらであると、スキャンが遅くなります。

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

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

移行時間について：

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

• 計算された移行時間は理論値です。帯域幅の変動、障害発生後のリトライ、その他の変数を考慮に入れる必要があります。特にダウンタイムを必要とする本番環境の移行では、常に予備計画を準備し、バッファ時間を確保してください。

• データオンライン移行は、タスクごとのリソース割り当てに上限を設けています。詳細については、「タスクの帯域幅と 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 のデータと 10 万個のファイルがあります。送信先は Alibaba Cloud NAS です。タスクはシンガポールリージョンで作成されます。移行にはどのくらいの時間がかかりますか？

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

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

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

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

コンソールでのプロキシの異常ステータス表示

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

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

• 認証情報が正しくない、または権限が不十分な場合。例：

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

  • 権限不足。AccessKeyId には以下のいずれかの権限が必要で、[リソース範囲] は [アカウントレベル] に設定する必要があります。

    • mgw:VerifyAgentTunnel

    • AliyunOSSImportReadOnlyAccess

    • AliyunOSSImportFullAccess

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

• RAM の [ネットワークアクセス制御ポリシー] によって制限されている認証情報。データオンライン移行では、AccessKeyId がすべてのネットワークセグメントからのアクセスを許可する必要があります。パブリックネットワークアクセスを許可するには、[AccessKey レベルのネットワークアクセス制御ポリシー] ページに移動し、[有効] を選択し、[すべてのパブリックネットワークアクセスを許可] をクリックします (システムが自動的に ::/0 と 0.0.0.0/0 を追加します)。パブリックネットワークポリシーテーブルで [OK] をクリックし、ページ下部の [送信] をクリックします。

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

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

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

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

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

• プロキシの高負荷。実行中の移行タスクが、時折接続異常を引き起こすことがあります。タスクが正常に実行されている場合、これは想定内の動作です。マシンのロードアベレージが高い場合は、プロキシインスタンスをスケールアウトするか、[1秒あたりの最大移行ファイル数] の設定を下げてください。

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

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

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

移行タスクの進捗がない

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

• ファイルがフィルターで除外されている。タスクがファイルフィルターを使用しており、条件に一致するソースファイルが少ない場合、進捗の更新が遅くなります。

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

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

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

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

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

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

移行に失敗したファイルの確認方法

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

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

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

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

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

一般的な移行失敗の原因

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

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

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

• 移行レポートの [失敗理由] フィールド。

underscoreUserMetaDropOrSkipUids=<UID>,drop;

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

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

送信先のデータ量が小さい場合、考えられる原因は次のとおりです。

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

• ソースに複数のバージョンが含まれている (OSS、S3、または NAS のゴミ箱など)。データオンライン移行は最新バージョンのみを移行します。

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

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

• ソースにフラグメントが含まれている。データオンライン移行は、不完全なオブジェクトやフラグメントを移行しません。

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

• ソースのプレフィックスが正しくない。プレフィックスを指定すると、そのプレフィックス以下のデータのみが移行されます。

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

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

送信先のデータ量が大きい場合、考えられる原因は次のとおりです。

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

• 送信先でマルチバージョン管理機能が有効になっている (OSS や NAS のゴミ箱など)。データオンライン移行は非マルチバージョン API を使用します。マルチバージョン管理が有効になっている場合、各書き込みで新しいバージョンが作成されます。

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

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

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

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

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

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

ソースの過剰な送信トラフィックまたはファイルの繰り返し移行

通常、データオンライン移行は各ソースファイルを一度だけダウンロードします。移行後に予想以上のソース送信トラフィックが観測された場合、考えられる原因は次のとおりです。

• 内部リトライ。ネットワークの瞬断、読み書きのスロットリング、またはプロキシのボトルネックが、限定的な自動リトライをトリガーします。

• 外部システムからのアクセス。移行中に他のシステム (アプリケーションや CDN の back-to-origin など) がソースにアクセスすると、送信トラフィックが増加します。

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

• [上書きモード] が正しくない。[強制上書き] に設定されている場合、データオンライン移行は既存のコンテンツに関係なく、常に送信先ファイルを上書きします。

• 送信先のライフサイクルポリシー。タスク作成時に [最終更新日時を保持] を選択した場合、ソースファイルのタイムスタンプが送信先に適用されます。送信先にファイルを削除するライフサイクルポリシーがある場合、移行されたファイルは直後に削除される可能性があります。

• ソースの頻繁な更新。上書きモードが [最終更新時間に基づいて上書き] の場合、ソースのタイムスタンプが更新されると (コンテンツの変更がなくても)、次の実行で再移行がトリガーされます。

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

クロスアカウントシナリオには、他のアカウントから自分のアカウントへ、自分のアカウントから他のアカウントへ、そして他のアカウントから他のアカウントへ (複雑で推奨されません。最初の 2 つに変換してください) の 3 つがあります。権限付与の問題が発生する可能性があります。概要：

• 主要な権限付与手順：

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

  • RoleName を他のアカウントの管理者と共有します。管理者はターゲットバケットに対する権限を付与します。詳細については、「ソースバケットの権限付与」または「送信先バケットの権限付与」をご参照ください。

  • これで権限付与は完了です。データオンライン移行でバケットのデータアドレスを作成する際に、[権限付与ロール] フィールドに RoleName を入力します。

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

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

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

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

• 例：アカウント A の NAS を自分のアカウントの NAS に移行する。

  • アカウント A の NAS をマシン M1 にマウントします。M1 はアカウント A 配下の ECS インスタンス (推奨) またはアカウント A の NAS のマウントをサポートする任意のマシンでかまいません。

  • データオンライン移行コンソールで、プロキシインスタンス agent1 を作成し、M1 にデプロイします。

  • 自分のアカウントの NAS をマシン M2 にマウントします。M2 は自分のアカウント配下の ECS インスタンス (推奨) または互換性のある任意のマシンでかまいません。

  • データオンライン移行コンソールで、プロキシインスタンス agent2 を作成し、M2 にデプロイします。

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

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

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