StorSimple 8100 および 8600 から Azure File Sync への移行

StorSimple 8000 シリーズは、8100 または 8600 の物理オンプレミス アプライアンス、およびそれらのクラウド サービス コンポーネントによって表されます。 この移行ガイドでは、StorSimple 8010 と 8020 の仮想アプライアンスについても説明します。 これらのいずれかのアプライアンスから、オプションの Azure File Sync を使って Azure ファイル共有にデータを移行できます。Azure File Sync は、StorSimple オンプレミス機能を置き換える既定の戦略的な長期 Azure サービスです。

StorSimple 8000 シリーズは 2022 年 12 月にサポート終了となります。 できるだけ早く移行の計画を開始することが重要です。 この記事では、Azure File Sync への移行を成功させるために必要な背景知識と移行手順について説明します。

フェーズ 1:移行を準備する

このセクションでは、StorSimple ボリュームから Azure ファイル共有への移行の開始時に実行する必要がある手順について説明します。

インベントリ

移行の計画を始めるときは、まず、移行する必要がある StorSimple のすべてのアプライアンスとボリュームを明らかにします。 それが終わった後で、最適な移行パスを決定できます。

移行コストの概要

StorSimple Data Manager リソースでの移行ジョブによる StorSimple ボリュームから Azure ファイル共有への移行は無料です。 移行中および移行後に、他のコストが発生する可能性があります。

  • ネットワーク エグレス: StorSimple のファイルは、特定の Azure リージョン内のストレージ アカウントに存在します。 移行先の Azure ファイル共有を、同じ Azure リージョン内にあるストレージ アカウントにプロビジョニングする場合は、エグレス コストは発生しません。 この移行の一環として、異なるリージョン内のストレージ アカウントにファイルを移動することができます。 その場合は、エグレス コストがかかります。
  • Azure ファイル共有のトランザクション: ファイルを Azure ファイル共有にコピーするとき (移行の一部として、またはその外部で)、ファイルとメタデータが書き込まれるときに、トランザクション コストがかかります。 ベスト プラクティスとしては、移行の間にトランザクション最適化レベルで Azure ファイル共有を開始します。 移行が完了した後で、目的のレベルに切り替えます。 以下のフェーズでは、適切なポイントでこれが示されています。
  • Azure ファイル共有レベルの変更: Azure ファイル共有のレベルを変更すると、トランザクションのコストがかかります。 ほとんどの場合、前のポイントのアドバイスに従う方がコスト効率が高くなります。
  • ストレージ コスト: この移行で Azure ファイル共有へのファイルのコピーが開始されるときに、ストレージが使用され、課金されます。 移行されたバックアップは、Azure ファイル共有スナップショットになります。 ファイル共有スナップショットでは、含まれている差異に対するストレージ容量のみが消費されます。
  • StorSimple: StorSimple のデバイスとストレージ アカウントをプロビジョニング解除できるようになるまで、ストレージ、バックアップ、アプライアンスに対する StorSimple のコストが引き続き発生します。

直接共有アクセスと Azure File Sync

Azure ファイル共有を使用すると、ファイル サービスのデプロイを構築するためのまったく新しい機会が開けます。 Azure ファイル共有はクラウド内の SMB 共有であり、使い慣れた Kerberos 認証と既存の NTFS アクセス許可 (ファイルとフォルダーの ACL) を使用してネイティブで動作する SMB プロトコルを介してユーザーが直接アクセスできるように設定できます。 Azure ファイル共有への ID ベースのアクセスの詳細について参照してください。

直接アクセスの代わりに、Azure File Sync を使用できます。Azure File Sync は、頻繁に使用されるファイルをオンプレミスにキャッシュする StorSimple の機能に直接相当します。

Azure File Sync は、次の 2 つの主要なコンポーネントに基づく Microsoft のクラウド サービスです。

  • Windows Server でパフォーマンス アクセス キャッシュを作成するためのファイルの同期とクラウドの階層化。
  • SMB や file REST などの複数のプロトコルを介してアクセスできる、Azure でのネイティブ ストレージとしてのファイル共有。

Azure ファイル共有により、属性、アクセス許可、タイムスタンプなど、格納されるファイルに対する重要なファイルの忠実性が保持されます。 Azure ファイル共有を使用すると、クラウドに格納されているファイルやフォルダーをアプリケーションやサービスで解釈する必要がなくなります。 使い慣れたプロトコルと Windows エクスプローラーなどのクライアントを使用してネイティブにそれらにアクセスできます。 Azure ファイル共有を使用すると、汎用のファイル サーバー データとアプリケーション データをクラウドに格納することができます。 Azure ファイル共有のバックアップは組み込みの機能であり、Azure Backup によってさらに拡張できます。

この記事では、移行手順を中心に説明します。 移行前に Azure File Sync について詳しく知りたい場合は、次の記事を参照してください。

StorSimple のサービス データ暗号化キー

最初に StorSimple アプライアンスを設定するときに、"サービス データ暗号化キー" が生成され、キーを安全に格納するように指示されます。 このキーは、関連付けられている Azure ストレージ アカウント内のすべてのデータを暗号化するために使用され、そこに StorSimple アプライアンスによってファイルが格納されます。

移行が成功するには、"サービス データ暗号化キー" が必要です。 インベントリ内の各アプライアンスに対してこのキーを 1 つレコードから取得するには、今がよいタイミングです。

レコード内にキーが見つからない場合は、アプライアンスから新しいキーを生成できます。 各アプライアンスには一意の暗号化キーがあります。

サービス データ暗号化キーの変更

サービス データ暗号化キーを使用して、StorSimple Manager サービスから StorSimple デバイスに送信される、顧客の機密データ (ストレージ アカウントの資格情報など) を暗号化します。 IT 組織にストレージ デバイスに関するキー ローテーション ポリシーがある場合は、これらのキーを定期的に変更する必要があります。 キーの変更プロセスは、StorSimple Manager サービスが 1 つのデバイスを管理しているか、または複数のデバイスを管理しているかによって多少異なります。 詳細については、「StorSimple のセキュリティとデータの保護」を参照してください。

サービス データ暗号化キーの変更は、次の 3 つの手順からなるプロセスです。

  1. Azure Resource Manager 用の Windows PowerShell スクリプトを使用して、サービス データ暗号化キーを変更するデバイスを承認します。
  2. StorSimple 用 Windows PowerShell を使用して、サービス データ暗号化キーの変更を開始します。
  3. StorSimple デバイスを複数使用している場合は、他のすべてのデバイスでサービス データ暗号化キーを更新します。

手順 1:Windows PowerShell スクリプトを使用してサービス データ暗号化キーを変更するデバイスを承認する

通常、デバイスの管理者は、サービス データ暗号化キーを変更する場合、デバイスの承認をサービス管理者に依頼します。 その後、サービス管理者は、キーの変更をデバイスに承認します。

この手順は、Azure Resource Manager ベースのスクリプトを使用して実行します。 サービス管理者は、承認するのに適したデバイスを選択できます。 選択したデバイスは、サービス データ暗号化キー変更プロセスを開始できるようになります。

スクリプトの使用の詳細については、「Authorize-ServiceEncryptionRollover.ps1」を参照してください

サービス データ暗号化キーの変更を許可できるデバイス

デバイスは、サービス データ暗号化キーの変更開始の承認に先立ち、次の条件を満たす必要があります。

  • デバイスがサービス データ暗号化キーの変更の承認の対象となるようにオンラインである必要があります。
  • キーの変更が開始されなかった場合は、30 分経過後にもう一度同じデバイスを承認できます。
  • 別のデバイスを承認するには、既に承認済みのデバイスによってキーの変更が開始されていないことが条件となります。 新しいデバイスが承認された後に、以前のデバイスが変更を開始することはできません。
  • サービス データ暗号化キーのロールオーバーの実行中に、デバイスを承認することはできません。
  • サービスに登録されているデバイスの中に、暗号化をロールオーバーしたデバイスと、ロールオーバしていないデバイスがある場合、デバイスを承認できます。

手順 2:StorSimple 用 Windows PowerShell を使用してサービス データ暗号化キーの変更を開始する

この手順は、承認済みの StorSimple デバイスの StorSimple 用 Windows PowerShell インターフェイスで実行されます。

Note

キーのロールオーバーが完了するまで、StorSimple Manager サービスの Azure Portal では操作を行うことができません。

デバイスのシリアル コンソールを使用して Windows PowerShell インターフェイスに接続している場合は、次の手順を実行します。

サービス データ暗号化キーの変更を開始するには

  1. オプション 1 を選択して、フル アクセスでログオンします。

  2. コマンド プロンプトに、次のコマンドを入力します。

    Invoke-HcsmServiceDataEncryptionKeyChange

  3. コマンドレットが正常に完了すると、新しいサービス データ暗号化キーが表示されます。 このキーをコピーし、このプロセスの手順 3. で使用するために保存します。 このキーは、StorSimple Manager サービスに登録されている残りのすべてのデバイスの更新に使用されます。

    注意

    このプロセスは、StorSimple デバイスを承認してから 4 時間以内に開始する必要があります。

    4 時間を経過すると、この新しいキーはサービスに送信され、サービスに登録されているすべてのデバイスにプッシュされます。 そのようになると、サービスのダッシュボードにアラートが表示されます。 このサービスにより、登録済みのデバイス上でのすべての操作が無効になります。その後、デバイスの管理者は、他のデバイスのサービス データ暗号化キーを更新する必要があります。 ただし、I/O (データをクラウドに送信するホスト) は中断されません。

    サービスに登録されているデバイスが 1 台の場合は、ロールオーバー プロセスが完了し、次の手順をスキップできます。 サービスに登録されているデバイスが複数ある場合は、手順 3. に進みます。

手順 3:他の StorSimple デバイス上のサービス データ暗号化キーを更新する

StorSimple Manager サービスに登録されているデバイスが複数ある場合は、StorSimple デバイスの Windows PowerShell インターフェイスで次の手順を実行する必要があります。 手順 2. で取得したキーを使用して、StorSimple Manager サービスに登録されている残りのすべての StorSimple デバイスを更新する必要があります。

デバイスのサービス データ暗号化を更新するには、次の手順を実行します。

物理デバイス上のサービス データ暗号化キーを更新するには

  1. StorSimple 用 Windows PowerShell を使用して、コンソールに接続します。 オプション 1 を選択して、フル アクセスでログオンします。
  2. コマンド プロンプトに Invoke-HcsmServiceDataEncryptionKeyChange – ServiceDataEncryptionKey を入力します。
  3. 手順 2. StorSimple 用 Windows PowerShell を使用してサービス データ暗号化キーの変更を開始する」で取得したサービス データ暗号化キーを指定します。

すべての 8010/8020 クラウド アプライアンス上のサービス データ暗号化キーを更新するには

  1. Update-CloudApplianceServiceEncryptionKey.ps1 PowerShell スクリプトをダウンロードして設定します。
  2. PowerShell を開き、コマンド プロンプトに次のように入力します。Update-CloudApplianceServiceEncryptionKey.ps1 -SubscriptionId [subscription] -TenantId [tenantid] -ResourceGroupName [resource group] -ManagerName [device manager]

このスクリプトは、デバイス マネージャーにあるすべての 8010/8020 クラウド アプライアンスで、サービス データ暗号化キーが設定されていることを確認します。

注意事項

StorSimple アプライアンスに接続する方法を決定するときは、次の点を考慮してください。

  • HTTPS セッション経由での接続は、最も安全であり、推奨されるオプションです。
  • デバイスのシリアル コンソールへの直接接続はセキュリティで保護されていますが、ネットワーク スイッチ経由での接続は保護されていません。
  • HTTP セッションの接続はオプションですが "暗号化されません"。 閉じた信頼できるネットワーク内で使用されている場合を除き、推奨されません。

既知の制限事項

StorSimple Data Manager と Azure ファイル共有には、移行を妨げる可能性があるため移行を始める前に考慮する必要がある、いくつかの制限があります。

  • StorSimple アプライアンスの NTFS ボリュームのみがサポートされています。 ReFS ボリュームはサポートされていません。
  • Windows Server のダイナミック ディスクに配置されているボリュームはサポートされていません。 (Windows Server 2012 前では非推奨)
  • このサービスは、BitLocker で暗号化されたボリュームや、データ重複除去が有効になっているボリュームでは機能しません。
  • 破損した StorSimple バックアップは移行できません。
  • ファイアウォールやプライベート エンドポイントのみの通信などの特別なネットワーク オプションは、StorSimple のバックアップが格納されているソース ストレージ アカウントでも、Azure ファイル共有が保持されているターゲット ストレージ アカウントでも、有効にすることはできません。

ファイルの忠実性

既知の制限事項」のどの制限によっても移行が妨げられない場合。 Azure ファイル共有に格納できるものについて、注意が必要な制限がまだあります。 "ファイルの忠実性" とは、ファイルを構成する多数の属性、タイムスタンプ、データを指します。 移行におけるファイルの忠実性は、ソース (StorSimple ボリューム) の情報をターゲット (Azure ファイル共有) にどの程度正確に変換 (移行) できるかの尺度です。 NTFS ファイルのプロパティサブセットが Azure Files ではサポートされています。 ACL、共通メタデータ、および一部のタイムスタンプが移行されます。 次の項目は、移行を妨げることはありませんが、移行の間に項目ごとの問題が発生します。

  • タイムスタンプ: ファイルの変更日時は設定されません。現在、REST プロトコルでは読み取り専用になっています。 ファイルの最後のアクセス タイムスタンプは移動されません。現在、Azure ファイル共有に格納されているファイルでサポートされている属性ではありません。
  • 代替データ ストリームを Azure ファイル共有に格納することはできません。 代替データ ストリームを保持しているファイルはコピーされますが、代替データ ストリームはプロセスでファイルから除去されます。
  • シンボリック リンク、ハード リンク、ジャンクション、再解析ポイントは、移行の間にスキップされます。 移行のコピー ログに、スキップされた各項目と理由の一覧が記録されます。
  • EFS で暗号化されたファイルはコピーされません。 コピー ログに、"アクセス拒否" でコピーできなかった項目が示されます。
  • 破損したファイルはスキップされます。 コピー ログでは、StorSimple ディスクで破損している項目ごとに異なるエラーが示される場合があります。"デバイスで重大なハードウェア エラーが発生したため、要求が失敗しました"、"ファイルまたはディレクトリが破損しているか、読み取れません"、"アクセス制御リスト (ACL) の構造が無効です" などです。
  • 個別のファイルで 4 TiB を超えるものはスキップされます。
  • ファイル パスの長さは、2,048 文字以下でなければなりません。 パスが長いファイルとフォルダーはスキップされます。

StorSimple ボリュームのバックアップ

StorSimple により、ボリューム レベルでの差分バックアップが提供されます。 Azure ファイル共有にもこの機能があり、共有スナップショットと呼ばれます。 移行ジョブで移動できるのはバックアップだけであり、ライブ ボリュームからのデータはできません。 そのため、最新のバックアップが、移行で移動されるバックアップの一覧に常に存在する必要があります。

移行の間に古いバックアップを移動する必要があるかどうかを判断します。 移行ジョブが速く完了するよう、この一覧をできるだけ小さくしておくのがベスト プラクティスです。

移行する必要がある重要なバックアップを特定するには、バックアップ ポリシーのチェックリストを作成します。 次に例を示します。

  • 最新のバックアップ。 (注: 最新のバックアップがこのリストに常に含まれている必要があります。)
  • 12 か月分の月次バックアップ。
  • 3 年分の年次バックアップ。

後で移行ジョブを作成するときに、このリストを使用して、リストの要件を満たすために移行する必要がある正確な StorSimple ボリューム バックアップを識別できます。

注意事項

50 個より多くの StorSimple ボリューム バックアップを選択することはサポートされていません。 移行ジョブで移動できるのはバックアップだけであり、ライブ ボリュームからのデータはできません。 したがって、ライブ データに最も近いのは最新のバックアップなので、移行で移動されるバックアップのリストに常にそれを含める必要があります。

注意事項

移行するバックアップを選択する前に、すべての StorSimple バックアップ保持ポリシーを中断することをお勧めします。
バックアップの移行には数日または数週間かかります。 StorSimple には、バックアップを削除するバックアップ保持ポリシーが用意されています。 この移行のために選択したバックアップは、移行する前に削除される可能性があります。

既存の StorSimple ボリュームを Azure ファイル共有にマップする

この手順では、必要な Azure ファイル共有の数を決定します。 1 つの Windows Server インスタンス (またはクラスター) では、最大 30 個の Azure ファイル共有を同期できます。

現在、SMB 共有としてユーザーとアプリに対してローカルに共有しているボリュームには、さらに多くのフォルダーが存在する場合があります。 このシナリオを理解する最も簡単な方法は、1:1 で Azure ファイル共有にマップするオンプレミスの共有を想像することです。 1 つの Windows Server インスタンスの共有数が 30 以下と十分に少ない場合は、1 対 1 のマッピングをお勧めします。

共有の数が 30 を超える場合、通常オンプレミスの共有を 1 対 1 で Azure ファイル共有にマッピングする必要はありません。 次のオプションを検討してください。

共有のグループ化

たとえば、人事 (HR) 部門に 15 個の共有がある場合、すべての HR データを 1 つの Azure ファイル共有に格納することを検討できます。 1 つの Azure ファイル共有にオンプレミスの共有を複数格納しても、ローカルの Windows Server インスタンスに通常の 15 個の SMB 共有を作成できます。 これは、単にこれらの 15 個の共有のルート フォルダーを共通フォルダーの下のサブフォルダーとして整理することを意味します。 その後、この共通フォルダーを Azure ファイル共有に同期します。 そうすることで、このオンプレミスの共有グループに必要なのは、クラウド内の 1 つの Azure ファイル共有のみとなります。

ボリュームの同期

Azure File Sync では、ボリュームのルートを Azure ファイル共有に同期することをサポートしています。 ボリューム ルートを同期した場合、すべてのサブフォルダーとファイルは同じ Azure ファイル共有に格納されます。

ボリュームのルートを同期することが常に最適なオプションであるとは限りません。 複数の場所に同期することには利点があります。 たとえば、そうすることで、同期スコープあたりの項目数を少なく抑えることができます。 Azure ファイル共有と Azure File Sync は、共有ごとに 1 億個の項目 (ファイルとフォルダ) を保持できるようテストされています。 ただし、ベスト プラクティスとしては、1 つの共有に保持する項目数は、2000 万から 3000 万個未満にすることをお勧めします。 Azure File Sync に含める項目数を少数に設定することは、ファイルの同期にとって有益というだけではありません。項目の数が少ないと、次のようなシナリオでも利点があります。

  • クラウド コンテンツの初期スキャンの完了までの時間が短くなり、その結果、Azure File Sync 対応のサーバーに名前空間が表示されるまでの待機時間が短縮されます。
  • Azure ファイル共有スナップショットからのクラウド側の復元が高速になります。
  • オンプレミスサーバーのディザスター リカバリーが大幅にスピードアップされます。
  • Azure ファイル共有 (同期以外) で直接行われた変更が、より高速に検出、同期されます。

ヒント

ファイルとフォルダーの数が不明な場合は、JAM Software GmbH の TreeSize ツールをぜひご利用ください。

デプロイ マップへの構造化アプローチ

後の手順でクラウド ストレージをデプロイする前に、オンプレミス フォルダーと Azure ファイル共有の間にマップを作成することが重要です。 このマッピングを行うと、プロビジョニングする Azure File Sync の "同期グループ" リソースの数と名称が通知されます。 同期グループは、Azure ファイル共有とサーバー上のフォルダーを連携させ、同期接続を確立します。

必要な Azure ファイル共有の数を決めるには、次の制限事項とベストプラクティスをレビューしてください。 そのことが、マップの最適化に役立ちます。

  • Azure File Sync エージェントがインストールされているサーバーは、最大 30 個の Azure ファイル共有と同期できます。

  • Azure ファイル共有は、ストレージ アカウント内にデプロイされます。 この配置により、このストレージ アカウントが、IOPS やスループットなどのパフォーマンス数のスケール ターゲットになります。

    理論的には、1 つの標準 Azure ファイル共有により、ストレージ アカウントが提供できる最大パフォーマンスが飽和状態になる可能性があります。 1 つのストレージ アカウントに複数の共有を配置することは、これらの共有について IOPS とスループットの共有プールを作成することを意味します。 これらのファイル共有への Azure File Sync のみのアタッチを計画している場合は、複数の Azure ファイル共有を同じストレージ アカウントにグループ化しても問題は発生しません。 関連メトリックの詳細については、Azure ファイル共有のパフォーマンス ターゲットを参照してください。 これらの制限は、パフォーマンスが明示的にプロビジョニングされ、各共有に対して保証される Premium Storage には適用されません。

    Azure ファイル共有をネイティブで使用する Azure にアプリをリフトする場合は、Azure ファイル共有のパフォーマンスをさらに上げる必要があります。 将来的にでもこのように使用することが考えられる場合は、1 つの標準の Azure ファイル共有を独自のストレージ アカウントに作成するのが最善です。

  • 1 つの Azure リージョンにつき、1 サブスクリプションあたりのストレージ アカウント数は 250 に制限されています。

ヒント

この情報を考慮して、ボリューム上の複数のトップレベル フォルダーを共通の新しいルート ディレクトリにグループ化することがしばしば必要になります。 次に、この新しいルート ディレクトリと、その中にグループ化したすべてのフォルダーを、1 つの Azure ファイル共有に同期します。 この手法を使用すると、サーバーあたり 30 個の Azure ファイル共有同期の制限内に抑えることができます。

共通のルートの下でのこのグループ化は、データへのアクセスにはいっさい影響しません。 ACL はそのまま維持されます。 今ここで共通のルートに変更したローカル サーバー フォルダー上に必要共有パス (SMB 共有や NFS 共有など) がある場合に限り、その調整が必要となります。 それ以外の変更はありません。

重要

Azure File Sync の最も重要なスケール ベクターは、同期が必要な項目 (ファイルとフォルダー) の数です。 詳細については、「Azure File Sync のスケール ターゲット」を確認してください。

ここでのベストプラクティスは、同期スコープあたりの項目数を少なくしておくことです。 これは、フォルダーを Azure ファイル共有にマッピングする際に考慮する必要がある重要な要素です。 Azure File Sync は、共有ごとに 1 億個の項目 (ファイルとフォルダー) を使用して検証済みです。 ただし、多くの場合、1 つの共有に保持する項目数は、2000 万から 3000 万個未満にすることをお勧めします。 これらの数値を超え始めた場合は、名前空間を複数の共有に分割します。 これらの数値をほぼ下回っている場合、複数のオンプレミスの共有を同じ Azure ファイル共有にグループ化することを続行できます。 この方法により、拡大する余地が得られます。

状況によっては、一連のフォルダーが同じ Azure ファイル共有に論理的に同期される可能性があります (前述の新しい共通のルート フォルダーのアプローチを使用します)。 ただし、1 つの Azure ファイル共有ではなく 2 つに同期されるように、フォルダーを再グループ化することをお勧めします。 このアプローチを使用すると、ファイル共有あたりのファイルとフォルダーの数をサーバー間に分散させることができます。 オンプレミスの共有を分割し、より多くのオンプレミス サーバー間で同期させることもできます。これにより、追加のサーバーごとに 30 を超える Azure ファイル共有と同期することができます。

マッピング テーブルを作成する

Diagram that shows an example of a mapping table. Download the following file to experience and use the content of this image.

前述の情報を使用して、必要な Azure ファイル共有の数を決定し、既存のデータのどの部分がどの Azure ファイル共有に格納されるかを判断します。

必要に応じて参照できるように、自分の考えを記録しておく表を作成します。 一度に多数の Azure リソースをプロビジョニングするときは、マッピング計画の詳細がおろそかになりがちなので、情報が整理された状態を維持することが重要です。 次の Excel ファイルをダウンロードして、マッピングの作成に役立つテンプレートとして使用します。


Excel icon that sets the context for the download. 名前空間マッピング テンプレートをダウンロードします。

ストレージ アカウントの数

複数のストレージ アカウントをデプロイし、それぞれに少数の Azure ファイル共有を保持すると、移行にとってメリットになる可能性があります。

ファイル共有が非常にアクティブである (多くのユーザーやアプリケーションによって使用されている) 場合、2 つの Azure ファイル共有でストレージ アカウントのパフォーマンス制限に達する可能性があります。 このため、ベスト プラクティスは、それぞれが個別に独自のファイル共有を持つ複数のストレージ アカウントに移行し、通常はストレージ アカウントごとに 2 または 3 個以下の共有を使用することです。

ベスト プラクティスは、それぞれ 1 つのファイル共有を持つストレージ アカウントをデプロイすることです。 アーカイブできる共有がある場合は、複数の Azure ファイル共有を同じストレージ アカウントにプールすることができます。

これらの考慮事項は、Azure File Sync の場合より、(Azure VM またはサービス経由での) クラウドへの直接アクセスの場合に、よりいっそう適用されます。これらの共有で Azure File Sync だけを使用する場合は、いくつかを 1 つの Azure ストレージ アカウントにグループ化するのが適切です。 将来的には、アプリをクラウドにリフト アンド シフトし、そこでファイル共有に直接アクセスできます。このシナリオには、IOPS とスループットが向上するメリットがあります。 または、IOPS とスループットをより高くするとメリットのある Azure のサービスの使用を始めることもできます。

共有のリストを作成してある場合は、各共有を、それらが配置されるストレージ アカウントにマップします。

重要

Azure リージョンを決定し、各ストレージ アカウントと Azure File Sync リソースが選択したリージョンと一致するようにします。 ここでは、ストレージ アカウントのネットワークとファイアウォールの設定を構成しないでください。 この時点でこれらの構成を行うと、移行が不可能になります。 これらの Azure Storage の設定は、移行が完了した後で構成します。

Storage アカウントの設定

ストレージ アカウントには多くの構成を行います。 ストレージ アカウントの構成を確認するには、次のチェックリストを使用する必要があります。 たとえば、移行の完了後にネットワーク構成を変更できます。

  • 大型ファイルの共有: 有効 - 大きなファイルを共有すると、パフォーマンスが向上し、共有に最大 100 TiB を格納できます。 この設定は、Azure ファイル共有を持つターゲット ストレージ アカウントに適用されます。
  • ファイアウォールと仮想ネットワーク: 無効 - IP 制限を構成したり、ストレージ アカウントの特定の VNET へのアクセスに制限したりしません。 ストレージ アカウントのパブリック エンドポイントは、移行中に使用されます。 Azure VM からのすべての IP アドレスを許可する必要があります。 移行後は、ストレージ アカウントでファイアウォール規則を構成するのが最善です。 ソースとターゲットの両方のストレージ アカウントをこの方法で構成します。
  • プライベート エンドポイント: サポートされている - プライベート エンドポイントを有効にできますが、パブリック エンドポイントは移行に使用され、引き続き使用できる必要があります。 この考慮事項は、ソース ストレージ アカウントとターゲット ストレージ アカウントの両方に適用されます。

フェーズ 1 の概要

「Phase 1:

  • StorSimple のデバイスとボリュームの概要を理解しました。
  • 各 StorSimple デバイスの "サービス データ暗号化キー" を取得したので、Data Manager サービスでクラウド内の StorSimple ボリュームにアクセスする準備ができています。
  • 移行する必要があるボリュームとバックアップ (最新のもの以外の場合) についての計画があります。
  • ボリュームを適切な数の Azure ファイル共有およびストレージ アカウントにマップする方法がわかっています。

フェーズ 2:Azure Storage と移行リソースをデプロイする

このセクションでは、Azure で必要なさまざまなリソースの種類のデプロイに関する考慮事項について説明します。 一部は移行後にデータを保持し、一部は移行にだけ必要です。 デプロイ計画が完成するまで、リソースのデプロイを始めないでください。 デプロイした後で Azure リソースの特定の側面を変更することは困難です (場合によっては不可能です)。

ストレージ アカウントをデプロイする

多くの場合、複数の Azure ストレージ アカウントをデプロイする必要があります。 この記事の前のセクションで作成したデプロイ計画に従って、それぞれで少数の Azure ファイル共有を保持します。 Azure portal で計画したストレージ アカウントをデプロイします。 新しいストレージ アカウントについては、次の基本的な設定に従って検討してください。

重要

ここでは、ストレージ アカウントのネットワークとファイアウォールの設定を構成しないでください。 この時点でそれらの構成を行うと、移行が不可能になります。 これらの Azure Storage の設定は、移行が完了した後で構成します。

サブスクリプション

StorSimple のデプロイに使用したものと同じサブスクリプションを使用することも、別のサブスクリプションを使用することもできます。 唯一の制限は、サブスクリプションが StorSimple サブスクリプションと同じ Azure Active Directory テナントに存在する必要があることです。 移行を始める前に、StorSimple サブスクリプションを適切なテナントに移動することを検討してください。 サブスクリプション全体を移動することだけができます。個々の StorSimple リソースを別のテナントまたはサブスクリプションに移動することはできません。

Resource group

リソース グループは、リソースと管理アクセス許可の編成を支援します。 詳細については、Azureでのリソース グループに関するページを参照してください。

ストレージ アカウント名

ストレージ アカウントの名前は URL の一部になり、特定の文字制限があります。 名前付け規則では、ストレージ アカウント名は世界中で一意にする必要があり、小文字と数字のみを使用でき、3 から 24 文字で指定する必要があり、ハイフンやアンダースコアなどの特殊文字は使用できないことを考慮してください。 詳細については、Azure Storage リソースの名前付け規則に関する記事を参照してください。

場所

ストレージ アカウントの場所つまり Azure リージョンは非常に重要です。 Azure File Sync を使用する場合は、すべてのストレージ アカウントがストレージ同期サービス リソースと同じリージョンに存在する必要があります。 選択する Azure リージョンは、ローカル サーバーやユーザーの近くにあるか、中央にある必要があります。 リソースをデプロイした後で、そのリージョンを変更することはできません。

StorSimple のデータ (ストレージ アカウント) が現在存在する場所とは別のリージョンを選択できます。

重要

現在の StorSimple ストレージ アカウントの場所とは別のリージョンを選択した場合は、移行中にエグレス料金が発生します。 データは StorSimple のリージョンから出て、新しいストレージ アカウントのリージョンに入ります。 同じ Azure リージョン内にある場合は、帯域幅の料金はかかりません。

パフォーマンス

Azure ファイル共有には、Premium Storage (SSD) または Standard Storage を選択できます。 Standard Storage には、ファイル共有用の複数の階層が含まれています。 StorSimple から移行するほとんどのお客様には、Standard Storage が適切なオプションです。

まだ決められない場合は、次のようにしてください。

  • Premium Azure ファイル共有のパフォーマンスを必要とする場合は、Premium Storage を選択します。
  • ホット データやアーカイブ データなど、汎用的なファイル サーバーのワークロードには、Standard Storage を選択します。 また、クラウド内の共有上のワークロードが Azure File Sync だけである場合も、Standard Storage を選択します。
  • Premium ファイル共有の場合は、ストレージ アカウントの作成ウィザードで [ファイル共有] を選択します。

レプリケーション

いくつかのレプリケーション設定を使用できます。 さまざまなレプリケーションの種類を確認してください。

次の 2 つのオプションのいずれかのみを選択してください。

  • ローカル冗長ストレージ (LRS)
  • "ゾーン冗長ストレージ (ZRS) " は、すべての Azure リージョンで使用できるわけではありません。

Note

LRS と ZRS の冗長の種類のみが、大きな 100 TiB の Azure ファイル共有と互換性があります。

すべてのバリエーションの geo 冗長ストレージ (GRS) は、現在はサポートされていません。 冗長性の種類は後で切り替えることができ、Azure でサポートされるようになったら GRS に切り替えることができます。

100 TiB のファイル共有を有効にする

An image showing the Advanced tab in the Azure portal for the creation of a storage account.

Azure portal の新しいストレージ アカウント ウィザードの [詳細] セクションで、このストレージ アカウントでの [大きいファイルの共有] のサポートを有効にすることができます。 このオプションが使用できない場合は、通常、正しくない冗長性の種類を選択しています。 このオプションを使用できるようにするには、LRS または ZRS だけを選択してください。

大きな 100 TiB のファイル共有を選択すると、次のような利点があります。

  • 小さい容量 5 TiB のファイル共有と比較して、パフォーマンスが大幅に向上します (たとえば、10 倍の IOPS)。
  • 移行の完了にかかる時間が大幅に短縮されます。
  • 差分バックアップで必要なストレージ容量など、移行するすべてのデータを保持するのに十分な容量がファイル共有にあることが保証されます。
  • 将来の拡張に対応できます。

重要

移行前または移行中に、ストレージ アカウントに特別なネットワークを適用しない。 パブリック エンドポイントには、ソースとターゲットのストレージ アカウントでアクセスできる必要があります。 特定の IP 範囲または VNET への制限はサポートされていません。 移行後にストレージ アカウントのネットワーク構成を変更できます。

Azure ファイル共有

ストレージ アカウントが作成されたら、ストレージ アカウントの [ファイル共有] セクションに移動し、フェーズ 1 の移行プランに従って、適切な数の Azure ファイル共有をデプロイできます。 Azure での新しいファイル共有については、次の基本的な設定に従って検討してください。

An Azure portal screenshot showing the new file share UI.




小文字、数字、ハイフンがサポートされています。



ここでのクォータは、Windows Server インスタンスでの SMB ハード クォータに相当します。 ベスト プラクティスとして、ここではクォータを設定しないでください。クォータに達すると、移行や他のサービスが失敗します。



新しいファイル共有に対して
を選択します。 移行の間に、多くのトランザクションが発生します。 後でワークロードに最適なレベルに変更する方が、コスト効率がよくなります。

StorSimple Data Manager

移行ジョブが保持される Azure リソースは、StorSimple Data Manager という名前です。 [新しいリソース] を選択して、それを検索します。 [作成] を選択します。

この一時的なリソースは、オーケストレーションに使用されます。 移行が完了した後でプロビジョニングを解除します。 StorSimple ストレージ アカウントと同じサブスクリプション、リソース グループ、リージョンに、デプロイする必要があります。

Azure File Sync

Azure File Sync を使用すると、最も頻繁にアクセスされるファイルのオンプレミス キャッシュを追加できます。 StorSimple のキャッシュ機能と同様に、Azure File Sync のクラウドを使った階層化機能を使用すると、Windows Server インスタンスとマルチサイトの同期で使用可能なキャッシュ容量に対する制御の強化との組み合わせで、ローカル アクセスの待機時間が向上します。オンプレミスのキャッシュを使用することが目的である場合は、ローカル ネットワークに十分な直接接続ストレージ容量を備えた Windows Server VM を準備します (物理サーバーとフェールオーバー クラスターもサポートされます)。

重要

Azure File Sync はまだ設定しないでください。 共有の移行が完了した後で Azure File Sync を設定するのが最善です。 移行のフェーズ 4 より前に、Azure File Sync のデプロイを始めないでください。

フェーズ 2 の概要

フェーズ 2 が終了すると、ストレージ アカウントとすべての Azure ファイル共有がデプロイされています。 また、StorSimple Data Manager リソースも作成されています。 フェーズ 3 で移行ジョブを構成するとき、後者を使用します。

フェーズ 3: 移行ジョブを作成して実行する

このセクションでは、移行ジョブを設定し、選択したターゲットの Azure ファイル共有にコピーする必要がある StorSimple ボリューム上のディレクトリを、慎重にマップする方法について説明します。 作業を始めるには、StorSimple Data Manager に移動し、メニューで [ジョブ定義] を見つけて、 [+ ジョブ定義] を選択します。 正しいターゲット ストレージの種類は既定値です: [Azure ファイル共有]

StorSimple 8000 series migration job types.

Screenshot of the new job creation form for a migration job.

ジョブ定義名この名前は、移動しているファイルのセットを示すものである必要があります。 Azure ファイル共有に似た名前を付けることをお勧めします。



リージョンを選択するときは、StorSimple のストレージ アカウントと同じリージョンを選択する必要があります。または、利用できない場合は、それに近いリージョンを選択します。

source

ソース サブスクリプションStorSimple デバイス マネージャー リソースを格納するサブスクリプションを選択します。



アプライアンスが登録されている StorSimple デバイス マネージャーを選択します。




を確認してください。



移行するボリュームが保持されている StorSimple デバイスを選択します。



ソース ボリュームを選択します。 後で、ボリューム全体またはサブディレクトリをターゲットの Azure ファイル共有に移行するかどうかを決定します。

ボリューム バックアップ
[Select volume backups] (ボリューム バックアップの選択) を選択して、このジョブの一部として移動する特定のバックアップを選択できます。 詳細なプロセスについては、後のこの記事の専用セクションを参照してください。

Target

この移行ジョブのターゲットとして、サブスクリプション、ストレージ アカウント、Azure ファイル共有を選択します。

ディレクトリのマッピング

関連するすべての詳細は、この記事の専用セクションで説明します。

移行するボリューム バックアップの選択

移行する必要があるバックアップの選択には、次の重要な側面があります。

  • 移行ジョブで移動できるのはバックアップだけであり、ライブ ボリュームのデータはできません。 そのため、ライブ データに最も近いのは最新のバックアップなので、移行で移動されるバックアップのリストに常にそれを含める必要があります。 バックアップの選択ダイアログを開くと、既定で選択されています。
  • ライブ共有への差分ができるだけ小さくなるように、最新のバックアップが最近のものであることを確認します。 移行ジョブを作成する前に、別のボリューム バックアップを手動でトリガーして完了することをお勧めします。 ライブ共有への差分が小さいと、移行エクスペリエンスが向上します。 この差分を 0 にすると、最新のバックアップがリストに作成された後に、StorSimple ボリュームへの変更は行われません。その後、フェーズ 5: ユーザーのカットオーバーが大幅に簡素化され、スピードアップされます。
  • バックアップを、古いものから最新のものまで、Azure ファイル共有に対して再生する必要があります。 移行ジョブを実行した後、古いバックアップを Azure ファイル共有上のバックアップの一覧に "分類する" ことはできません。 そのため、ジョブを作成する "前に"、バックアップのリストが完全であることを確認する必要があります。
  • ジョブを作成した後では、たとえジョブが実行されていない場合でも、ジョブのこのバックアップのリストを変更することはできません。
  • バックアップを選択するには、移行する StorSimple ボリュームがオンラインである必要があります。

A screenshot of the new job creation form detailing the portion where StorSimple backups are selected for migration.

移行ジョブに StorSimple ボリュームのバックアップを選択するには、ジョブ作成フォームで [Select volume backups](ボリューム バックアップの選択) を選択します。

An image showing that the upper half of the blade for selecting backups lists all available backups. A selected backup will be grayed-out in this list and added to a second list on the lower half of the blade. There it can also be deleted again.

バックアップ選択ブレードが開くと、2 つのリストに分割されています。 最初のリストには、利用可能なすべてのバックアップが表示されます。 特定の時間範囲でフィルター処理することにより、結果セットを広げたり狭めたりできます。 (次のセクションを参照)

選択されたバックアップは淡色表示され、ブレードの下半分にある 2 番目のリストに追加されます。 2 番目のリストには、移行用に選択されたすべてのバックアップが表示されます。 誤って選択したバックアップは再度削除することもできます。

注意事項

移行するバックアップを "すべて" 選択する必要があります。 古いバックアップを後で追加することはできません。 ジョブの作成後に、ジョブを変更して選択内容を変更することはできません。

A screenshot showing the selection of a time range of the backup selection blade.

既定では、この一覧はフィルター処理されており、過去 7 日以内の StorSimple ボリュームのバックアップが表示されます。 過去 7 日以内に行われなかった場合でも、最新のバックアップが既定で選択されます。 古いバックアップの場合は、ブレードの上部にある時間範囲フィルターを使用します。 既存のフィルターから選択するか、またはカスタム時間範囲を設定して、この期間内に作成されたバックアップのみにフィルター処理できます。

注意事項

50 個より多くの StorSimple ボリューム バックアップを選択することはサポートされていません。 バックアップの数が多いジョブは失敗するおそれがあります。 選択したバックアップが移行される前に、バックアップ保有ポリシーによって削除されていないことを確認してください。

ディレクトリのマッピング

ディレクトリのマッピングは、移行ジョブでは省略可能です。 セクションを空のままにすると、StorSimple ボリュームのルートにある "すべての" ファイルとフォルダーが、ターゲットの Azure ファイル共有のルートに移動されます。 ほとんどの場合、ボリュームの内容全体を 1 つの Azure ファイル共有に格納することは、最適な方法ではありません。 多くの場合、Azure の複数のファイル共有にボリュームの内容を分割することをお勧めします。 プランをまだ作成していない場合は、最初に「既存の StorSimple ボリュームを Azure ファイル共有にマップする」を参照してください。

移行計画の一環として、StorSimple ボリューム上のフォルダーを複数の Azure ファイル共有に分割する必要があると決定している場合があります。 その場合は、次のように分割することができます。

  1. 1 つのボリューム上のフォルダーを移行するために、複数のジョブを定義します。 それぞれの StorSimple ボリューム ソースは同じですが、ターゲットとしての Azure ファイル共有は異なります。
  2. ジョブ作成フォームの「ディレクトリ マッピング」セクションを使用し、特定のマッピング セマンティクスに従って、StorSimple ボリュームのフォルダーを指定したファイル共有に移行する必要があることを正確に指定します。

重要

このフォームのパスとマッピング式を、フォームの送信時に検証することはできません。 マッピングが正しく指定されていない場合、ジョブは完全に失敗するか、望ましくない結果を生成する可能性があります。 その場合は、通常、Azure ファイル共有を削除して再作成してから、その共有に対する新しい移行ジョブでマッピングのステートメントを修正するのが最善の方法です。 修正したマッピングのステートメントを使用して新しいジョブを実行すると、省略されたフォルダーを修正し、既存の共有に移動できます。 ただし、この方法で対処できるのは、パスのスペルミスのために省略されたフォルダーのみです。

セマンティックの要素

マッピングは左から右に表記されます: [\ソースパス] > [\ターゲットパス]。

セマンティックの文字 意味
\ ルート レベル インジケーター。
> [ソース] と [ターゲット マッピング] の演算子。
| または RETURN (改行) 2 つのフォルダー マッピング命令の区切り記号。
または、この文字を省略し、
キーを押して、次のマッピング式を独自の行に作成することもできます。

フォルダー User data の内容を、ターゲット ファイル共有のルートに移動します。

\User data > \

ボリュームの内容全体を、ターゲット ファイル共有の新しいパスに移動します。

\ > \Apps\HR tracker

ソース フォルダーの内容を、ターゲット ファイル共有の新しいパスに移動します。

\HR resumes-Backup > \Backups\HR\resumes

複数のソースの場所を、新しいディレクトリ構造に並べ替えます。

\HR\Candidate Tracker\v1.0 > \Apps\Candidate tracker
\HR\Candidates\Resumes > \HR\Candidates\New
\Archive\HR\Old Resumes > \HR\Candidates\Archived

セマンティックのルール

  • フォルダーのパスは、常にルート レベルを基準にして指定します。
  • 各フォルダーのパスは、ルート レベル インジケーター "\" で開始します。
  • ドライブ文字は含めません。
  • 複数のパスを指定するとき、ソースまたはターゲットのパスを重複することはできません。:
    無効なソース パスの重複の例:




    無効なターゲット パスの重複の例:
    >


  • 存在しないソース フォルダーは無視されます。
  • ターゲットに存在しないフォルダー構造は作成されます。
  • Windows と同様に、フォルダー名は大文字と小文字が区別されませんが、大文字と小文字は維持されます。

Note

StorSimple ボリュームの \System Volume Information フォルダーと $Recycle.Bin の内容は、移行ジョブによってコピーされません。

移行ジョブを実行する

移行ジョブは、リソース グループにデプロイした Data Manager リソースの [ジョブ定義] の下に一覧表示されます。 ジョブ定義の一覧から、実行するジョブを選択します。

開かれたジョブ ブレードで、ジョブの現在の状態と、選択したバックアップの一覧を確認できます。 バックアップの一覧は、最も古いものから順に並べられており、この順序で Azure ファイル共有に移行されます。

Screenshot of the migration job blade with a highlight around the command to start the job. It also displays the selected backups scheduled for migration.

移行ジョブの最初の状態は [Never ran](未実行) です。
準備ができたら、この移行ジョブを開始できます。 (解像度の高いバージョンのイメージを選びます)。
バックアップが正常に移行されると、Azure ファイル共有のスナップショットが自動的に作成されます。 StorSimple バックアップの元のバックアップの日付が、Azure ファイル共有のスナップショットの "コメント" セクションに配置されます。 このフィールドを使用すると、元のデータがバックアップされた日時と、ファイル共有スナップショットが取得された日時を比較できます。

注意事項

バックアップは、最も古いものから順に処理する必要があります。 移行ジョブが作成されたら、選択した StorSimple ボリューム バックアップの一覧を変更することはできません。 バックアップの一覧が正しくないか、不完全である場合は、ジョブを開始しないでください。 ジョブを削除し、正しいバックアップを選択して新しいジョブを作成します。 選択したバックアップごとに、保有期間のスケジュールを確認します。 バックアップは、移行される前に 1 つ以上の保持ポリシーによって削除される可能性があります。

項目ごとのエラー

移行ジョブには、コピー中に発生した可能性のある問題の一覧を示す 2 つの列があります。

  • コピー エラー
    この列には、コピーされる必要があったがコピーされなかったファイルまたはフォルダーの一覧が表示されます。 多くの場合、これらのエラーは復旧できます。 バックアップでこの列に項目の問題が一覧表示される場合は、コピー ログを確認してください。 これらのファイルを移行する必要がある場合は、 [Retry backup](バックアップの再試行) を選びます。 このオプションは、バックアップの処理が完了した後で使用できるようになります。 オプションについては、「移行ジョブを管理する」セクションで詳しく説明します。
  • サポートされていないファイル
    この列には、移行できないファイルまたはフォルダーの一覧が表示されます。 Azure Storage には、ファイル名、パスの長さ、および現在または論理的に Azure ファイル共有に格納できないファイルの種類の制限があります。 この種のエラーがあっても、移行ジョブは一時停止しません。 バックアップの移行を再試行しても結果は変わりません。 バックアップでこの列に項目の問題が一覧表示される場合は、コピー ログを確認して記録を残してください。 前回のバックアップでこのような問題が発生し、ファイル名、パスの長さ、または影響を受けたその他の問題によってエラーが発生したことがエラー ログでわかった場合は、ライブ StorSImple ボリュームで問題を解決し、StorSimple ボリュームのバックアップを取得し、そのバックアップだけで新しい移行ジョブを作成することができます。 その後、この修復した名前空間を移行すると、それが Azure ファイル共有の最新バージョンまたはライブ バージョンになります。 これは、手動で時間のかかるプロセスです。 コピー ログを慎重に確認し、その価値があるかどうかを評価します。

これらのコピー ログは *.csv ファイルで、コピーに成功した名前空間項目と失敗した項目の一覧が示されています。 エラーは、前に説明したカテゴリにさらに分割されます。 ログ ファイルの場所で "failed" を検索することで、失敗したファイルのログを見つけることができます。 結果は、コピーに失敗したファイルのログのセットです。 これらのログをサイズで並べ替えます。 サイズが 17 バイトになると、追加のログが生成される場合があります。 これらは空であり、無視することができます。 並べ替えると、内容が含まれるログに注目できます。

成功したコピーを記録するログファイルにも同じ処理が適用されます。

移行ジョブを管理する

移行ジョブには次の状態があります。

  • Never ran (未実行)新しいジョブ。定義されていますが、まだ実行されていません。
  • 待機中この状態のジョブは、移行サービスでリソースがプロビジョニングされるのを待機しています。 準備ができると、自動的に別の状態に切り替わります。
  • 失敗失敗したジョブで致命的エラーが発生し、それ以上多くのバックアップを処理できません。 ジョブがこの状態になることは想定されていません。 サポート リクエストが最善の措置です。
  • キャンセル済みキャンセル中移行ジョブ全体またはジョブ内の個々のバックアップをキャンセルすることができます。 キャンセルされたバックアップは処理されず、移行ジョブがキャンセルされると、バックアップはそれ以上処理されなくなります。 ジョブの取り消しには長い時間がかかることを想定してください。 その場合、新しいジョブを作成できなくなることはありません。 最善の対応は、ジョブが完全にキャンセル済み状態になるまで辛抱することです。 失敗したジョブまたはキャンセルされたジョブは無視するか、後で削除することができます。 StorSimple の移行が終わって Data Manager リソースを削除できるようになる前に、ジョブを削除する必要はありません。

Screenshot of the migration job blade with a large status icon on the top in the running state.

実行中
実行中のジョブは、現在、バックアップを処理しています。 ブレードの下半分にあるテーブルを参照して、現在処理されているバックアップと、既に移行された可能性があるバックアップを確認します。
既に移行されたバックアップには、コピー ログへのリンクを含む列があります。 バックアップでエラーが報告されている場合は、そのコピー ログを確認する必要があります。

Screenshot of the migration job blade with a large status icon on the top in the paused state.

一時停止
移行ジョブは、決定が必要なときは一時停止されます。 この状態では、ブレード上部の 2 つのコマンド ボタンが有効になります。
移動されるはずのファイルが移動されなかったことがバックアップで示されている場合は ([Copy error](コピー エラー) 列)、
を選びます。
バックアップが見つからない場合 (移行ジョブを作成した後でポリシーによって削除された)、またはバックアップが破損している場合は、
を選びます。 失敗したバックアップをクリックすると開くブレードで、詳細なエラー情報を確認できます。

現在のバックアップを "
" または "
" すると、移行サービスによってターゲットの Azure ファイル共有に新しいスナップショットが作成されます。 前のものは、おそらく不完全なので、後で削除してかまいません。

An image showing the migration job blade with a large status icon on the top in the complete state.

[Complete](完了)[Complete with warnings](完了 (警告あり)\ジョブのすべてのバックアップが正常に処理されると、移行ジョブは [Complete](完了) と表示されます。

は、次の場合に発生する状態です。

  • バックアップで回復可能な問題が発生しました。 このようなバックアップは、"部分的成功" または "失敗" とマークされます。
  • ユーザーが、示された問題を含むバックアップをスキップすることで、一時停止中のジョブを続行することを決定しました。 (ユーザーが [Retry backup](バックアップの再試行) ではなく [Skip backup](バックアップのスキップ) を選択しました)
移行ジョブが警告ありで完了した場合は、常に、関連するバックアップのコピー ログを確認する必要があります。

ジョブを並列実行する

複数の StorSimple ボリュームがあり、それぞれに Azure ファイル共有に移行する必要がある独自の共有が含まれることがあります。 並列で実行できる範囲を理解しておくことが重要です。 複数のジョブを同時に実行する場合、ユーザー エクスペリエンスでは適用されない制限があり、完全な移行が機能低下したり、抑制されたりします。

移行ジョブの定義では制限はありません。 同じ、または異なる StorSimple アプライアンスで、同じ StorSimple ソース ボリュームと同じ Azure ファイル共有を定義できます。 ただし、それらの実行には次の制限があります。

  • ソースの StorSimple ボリュームが同じ移行ジョブを、同時に複数実行することはできません。
  • ターゲットの Azure ファイル共有が同じ移行ジョブを、同時に複数実行することはできません。
  • 次のジョブを開始する前に、以前のジョブのいずれかが copy stage であり、少なくとも 30 分間は、ファイルの移動の進行状況が表示されていることを確認しました。
  • 前の規則に従っている限り、StorSimple デバイス マネージャーごとに最大で 4 つの移行ジョブを並列実行できます。

移行ジョブを開始しようとすると、前の規則がチェックされます。 実行中のジョブがある場合、現在のジョブを開始できない可能性があります。 現在実行中のジョブのうち、それが完了してからでないと新しいジョブを開始できないものの名前の一覧を含むアラートを受け取ります。

ヒント

Data Manager リソースの [ジョブ定義] タブで移行ジョブを定期的にチェックし、一時停止していて、完了するにはユーザーの入力が必要なものがあるかどうか確認することをお勧めします。

フェーズ 3 のまとめ

フェーズ 3 が終了すると、StorSimple ボリュームから Azure ファイル共有への少なくとも 1 つの移行ジョブが実行されています。 実行により、指定したバックアップが Azure ファイル共有のスナップショットに移行されます。 共有のための Azure File Sync の設定 (共有への移行ジョブが完了した後) またはインフォメーション ワーカーとアプリのための Azure ファイル共有への直接共有アクセスの設定に集中できるようになります。

フェーズ 4: Azure ファイル共有にアクセスする

Azure ファイル共有へのアクセスには、主に次の 2 つの方法があります。

  • Azure File Sync:オンプレミスの Windows Server インスタンスに Azure File Sync をデプロイします。 Azure File Sync には、StorSimple と同様に、ローカル キャッシュのすべての利点があります。
  • 直接共有アクセス: 直接共有アクセスをデプロイします。 特定の Azure ファイル共有のアクセス シナリオでローカル キャッシュにメリットがない場合、またはオンプレミスの Windows Server インスタンスをホストする機能がなくなった場合は、この方法を使用します。 この場合、ユーザーとアプリは引き続き SMB プロトコルを使用して SMB 共有にアクセスします。 これらの共有はオンプレミスのサーバー上にはなくなっており、クラウドのものを直接使用します。

このガイドの「フェーズ 1」で、どのオプションが最適であるかを既に決定しておく必要があります。

このセクションの残りの部分では、デプロイの手順について説明します。

Azure File Sync のデプロイ

ここでは、Azure File Sync の一部をデプロイします。

  1. Azure File Sync クラウド リソースを作成します。
  2. オンプレミス サーバーに Azure File Sync エージェントをデプロイします。
  3. クラウド リソースにサーバーを登録します。

同期グループはまだ作成しないでください。 Azure ファイル共有での同期の設定は、Azure ファイル共有への移行ジョブが完了した後でのみ行う必要があります。 移行が完了する前に Azure File Sync の使用を開始した場合は、カットオーバーを開始するタイミングを簡単に判断できないため、移行が不必要に難しくなります。

Azure File Sync クラウド リソースをデプロイする

この手順を完了するには、Azure サブスクリプションの資格情報が必要です。

Azure File Sync を構成するためのコア リソースは、"ストレージ同期サービス" と呼ばれます。 同じファイル セットを今すぐ、または今後同期するすべてのサーバーに対して、1 つのみをデプロイすることをお勧めします。 データを交換する必要のない個別のサーバー セットがある場合のみ、複数のストレージ同期サービスを作成します。 たとえば、同じ Azure ファイル共有を同期しないようにする必要があるサーバーがある場合です。 それ以外の場合は、1 つのストレージ同期サービスを使用することをお勧めします。

ストレージ同期サービスには、自分の場所に近い Azure リージョンを選択します。 他のすべてのクラウド リソースは、同じリージョンにデプロイする必要があります。 管理が簡単になるように、サブスクリプションに新しいリソース グループを作成し、同期リソースとストレージ リソースを格納します。

詳細については、「Azure File Sync のデプロイ」の記事にあるストレージ同期サービスのデプロイに関するセクションを参照してください。記事のこのセクションのみに従います。 後の手順に、この記事の他のセクションへのリンクがあります。

ヒント

移行が完了した後でデータが存在する Azure リージョンを変更する場合は、この移行のターゲット ストレージ アカウントと同じリージョンに、ストレージ同期サービスをデプロイします。

オンプレミスの Windows Server インスタンスをデプロイする

  • 仮想マシンまたは物理サーバーとして、Windows Server 2019 (最低でも 2012R2) のサーバーを作成します。 また、Windows Server フェールオーバー クラスターもサポートされています。 StorSimple 8100 または 8600 の前面にあるサーバーを再利用しないでください。
  • 直接接続ストレージをプロビジョニングまたは追加します。 ネットワーク接続ストレージはサポートされていません。

StorSimple 8100 または 8600 アプライアンスがローカルでキャッシュに使用できる容量以上のストレージを新しい Windows Server インスタンスに用意することをお勧めします。 StorSimple アプライアンスを使用したときと同じ方法で、Windows Server インスタンスを使用します。 アプライアンスと同じ容量のストレージがある場合、キャッシュ エクスペリエンスは同じでなくても似ているはずです。 Windows Server インスタンスのストレージは、いつでも追加または削除できます。 この機能により、ローカル ボリューム サイズとキャッシュに使用できるローカル ストレージの容量をスケールできます。

ファイル同期のために Windows Server インスタンスを準備する

このセクションでは、Azure File Sync エージェントをご利用の Windows Server インスタンスにインストールします。

デプロイ ガイドでは、 [Internet Explorer セキュリティ強化の構成] を無効にする必要があることが説明されています。 このセキュリティ対策は、Azure File Sync には該当しません。これをオフにすると、Azure への認証が問題なく行えるようになります。

PowerShell を開きます。 次のコマンドを使用して必須の PowerShell モジュールをインストールします。 プロンプトが表示されたら、完全なモジュールと NuGet プロバイダーを必ずインストールしてください。

Install-Module -Name Az -AllowClobber
Install-Module -Name Az.StorageSync

サーバーからインターネットへの接続で問題が発生した場合は、この段階で解決する必要があります。 Azure File Sync は、インターネットへの任意の使用可能なネットワーク接続を使用します。 インターネットに接続するためにプロキシ サーバーを要求することもサポートされています。 今すぐにマシン全体のプロキシを構成することも、エージェントのインストール中に Azure File Sync だけが使用するプロキシを指定することもできます。

プロキシを構成することが、このサーバーに対してファイアウォールを開く必要があることを意味する場合は、その方法を採用しても問題ありません。 サーバー インストールの終了時、サーバー登録が完了した後に、選択したリージョン用に Azure File Sync が通信する必要がある Azure 内の正確なエンドポイント URL を示すネットワーク接続レポートが示されます。 このレポートには、なぜ通信が必要なのかも示されています。 このレポートを使用して、このサーバーのファイアウォールを特定の URL にロック ダウンできます。

また、ファイアウォール全体を開かない、より保守的なアプローチを採用することもできます。 代わりに、上位レベルの DNS 名前空間と通信するようサーバーを制限できます。 詳細については、「Azure File Sync のプロキシとファイアウォールの設定」をご覧ください。 ご自分のネットワークのベスト プラクティスに従ってください。

サーバーのインストール ウィザードの終了時に、サーバーの登録ウィザードが開きます。 以前からご利用のストレージ同期サービスの Azure リソースにサーバーを登録します。

最初にインストールする必要がある PowerShell モジュールを含め、これらの手順については、デプロイ ガイドで詳しく説明されています。Azure File Sync エージェントのインストール

最新のエージェントを使用してください。 Microsoft ダウンロード センターからダウンロードできます。Azure File Sync エージェント

インストールとサーバーの登録が正常に完了したら、この手順が正常に完了したことを確認できます。 Azure portal のストレージ同期サービス リソースに移動します。 左側のメニューで、 [登録済みサーバー] に移動します。 ご利用のサーバーがそこに一覧表示されます。

Windows Server インスタンスで Azure File Sync を構成する

このプロセスのために、登録済みのオンプレミス Windows Server インスタンスを準備して、インターネットに接続しておく必要があります。

重要

作業を続ける前に、ファイルとフォルダーの Azure ファイル共有への StorSimple 移行が完了している必要があります。 ファイル共有への変更がそれ以上行われないことを確認します。

このステップでは、前の手順で Windows Server インスタンスに設定したすべてのリソースとフォルダーを結び付けます。

  1. Azure portal にサインインします。
  2. ストレージ同期サービスのリソースを見つけます。
  3. 各 Azure ファイル共有のストレージ同期サービス リソース内に新しい "同期グループ" を作成します。 Azure File Sync の用語では、Azure ファイル共有は、同期グループの作成と共に記述する同期トポロジの "クラウド エンドポイント" になります。 同期グループを作成する際に、ここで同期するファイルのセットを認識できるように、わかりやすい名前を付けます。 名前が一致する Azure ファイル共有を参照していることを確認します。
  4. 同期グループを作成すると、同期グループの一覧にその行が表示されます。 名前 (リンク) を選択して、同期グループの内容を表示します。 [クラウド エンドポイント] の下に Azure ファイル共有が表示されます。
  5. [サーバー エンドポイントの追加] ボタンを見つけます。 プロビジョニングしたローカル サーバー上のフォルダーは、この "サーバー エンドポイント" のパスになります。

重要

クラウドを使った階層化を必ず有効にしておきます。 クラウドを使った階層化は、ローカル サーバーが、クラウドに格納されているよりもストレージ容量が少なくても、完全な名前空間を使用できるようにする Azure File Sync 機能です。 ローカルの関心のあるデータもローカルにキャッシュされ、高速でローカルのアクセス パフォーマンスが実現します。 このステップでクラウドを使った階層化を有効にするもう 1 つの理由は、このステージではファイルの内容を同期したくないためです。 この時点では、名前空間のみを移動する必要があります。

直接共有アクセスをデプロイする

このビデオは、簡単な 5 つのステップでインフォメーション ワーカーやアプリに直接 Azure ファイル共有を安全に公開する方法についてのガイドとデモです。
ビデオでは、いくつかのトピックに関する専用のドキュメントが参照されています。

フェーズ 4 のまとめ

このフェーズの終わりには、StorSimple Data Manager で複数の移行ジョブを作成して実行しました。 それらのジョブによって、ファイルとフォルダーおよびそれらのバックアップが、Azure ファイル共有に移行されました。 また、Azure File Sync をデプロイするか、直接共有アクセスのためのネットワークとストレージ アカウントを準備しました。

フェーズ 5:ユーザーのカットオーバー

このフェーズでは、移行を完了します。

  • ダウンタイムを計画します。
  • フェーズ 3 の移行ジョブが実行されている間に、StorSimple 側で生成されたユーザーとアプリのすべての変更をキャッチアップします。
  • Azure File Sync または直接共有アクセスによる Azure ファイル共有を使用して、ユーザーを新しい Windows Server インスタンスにフェールオーバーします。

ダウンタイムを計画する

この移行アプローチを使用すると、ユーザーとアプリに若干のダウンタイムが発生します。 目標は、ダウンタイムを最小限に抑えることです。 次の考慮事項が役に立つ場合があります。

  • 移行ジョブの実行中に、StorSimple ボリュームを使用可能な状態に保ちます。
  • 共有へのデータ移行ジョブの実行が完了したら、StorSimple ボリュームと共有からユーザー アクセス (少なくとも書き込みアクセス) を削除します。 最後の RoboCopy により Azure ファイル共有がキャッチアップされます。 その後、ユーザーをカットオーバーできます。 どこで RoboCopy を実行するかは、Azure File Sync または直接共有アクセスのどちらの使用を選択したかによって異なります。 後の RoboCopy のセクションで、そのことについて説明します。
  • RoboCopy のキャッチアップを完了すると、Azure ファイル共有で直接、または Azure File Sync を使用して Windows Server インスタンス上の SMB 共有で、新しい場所をユーザーに公開できる状態になります。多くの場合、DFS-N のデプロイは、迅速かつ効率的にカットオーバーを実行するのに役立ちます。 これにより、既存の共有アドレスの一貫性が維持され、移行されたファイルとフォルダーが含まれる新しい場所がポイントされるようになります。

アーカイブ データの場合は、StorSimple ボリューム (またはサブフォルダー) でダウンタイムを開始し、StorSimple ボリュームのバックアップをさらに 1 つ取得し、移行してから、ユーザーとアプリによるアクセス用に移行先を開く、完全に実行可能なアプローチです。 この場合、このセクションで説明したようなキャッチアップのための RoboCopy は不要です。 ただし、この方法には、移行の必要なファイルとバックアップの数によっては、ダウンタイムが数日以上の長さになる可能性があるという短所があります。 これは、長期間書き込みアクセスを行わずに実行できるアーカイブ ワークロードに対してしか選択できないかもしれません。

名前空間がサーバーに完全に同期されたことを確認する

Azure ファイル共有への Azure File Sync を使用する場合は、ローカルの RoboCopy を始める "" に、名前空間全体のサーバーへのダウンロードが完了したことを確認することが重要です。 名前空間のダウンロードにかかる時間は、Azure ファイル共有内の項目の数によって異なります。 サーバーに名前空間が完全に移動されたかどうかを確認するには、次の 2 つの方法があります。

Azure portal

Azure portal を使用して、名前空間が完全に移動されたことを確認できます。

  • Azure portal にサインインし、同期グループに移動します。 同期グループとサーバー エンドポイントの同期状態を確認します。
  • 注目する方向はダウンロードです。 サーバー エンドポイントが新しくプロビジョニングされている場合、名前空間がまだダウンロードされていることを示す初期同期が表示されます。 その状態が初期同期以外に変わった後、名前空間はサーバーに完全に設定されます。 これで、ローカルの RoboCopy に進むことができます。

Windows Server イベント ビューアー

Windows Server インスタンスのイベント ビューアーを使用して、名前空間が完全に移動されたことを確認することもできます。

  1. イベント ビューアーを開き、 [アプリケーションとサービス] に移動します。
  2. Microsoft\FileSync\Agent\Telemetry に移動して開きます。
  3. 完了した同期セッションに対応する、最新のイベント 9102 を探します。
  4. [詳細] を選択し、SyncDirection の値が Download であるイベントを確認します。
  5. サーバーへの名前空間のダウンロードを完了すると、Scenario の値が FullGhostedSyncHResult0 である 1 つのイベントが発生します。
  6. そのイベントがない場合は、SyncDirectionDownload および Scenario"RegularSync" である他の 9102 イベント を調べることもできます。 これらのイベントのいずれかが見つかったら、現時点では、名前空間のダウンロードが完了し、同期するものがあるかどうかに関係なく、通常の同期セッションの進行中であることを示しています。

最終的な RoboCopy

この時点で、オンプレミスの Windows Server インスタンスと StorSimple 8100 または 8600 アプライアンスには違いがあります。

  1. 移行の進行中にユーザーやアプリが StorSimple 側で生成した変更を取得する必要があります。
  2. Azure File Sync を使用している場合: StorSimple アプライアンスにはキャッシュがありますが、Windows Server インスタンスは名前空間のみであり、現時点ではファイル コンテンツはローカルに格納されていません。 最後の RoboCopy により、使用可能なローカルにキャッシュされたファイルの内容を取得することによってローカルの Azure File Sync キャッシュをすぐに開始でき、Azure File Sync サーバーに格納できます。
  3. 無効な文字があるため、一部のファイルが移行ジョブによって残されている可能性があります。 その場合は、Azure File Sync が有効になっている Windows Server インスタンスにコピーします。 これらは、後で同期するように調整できます。特定の共有に Azure File Sync を使用していない場合は、StorSimple ボリュームで無効な文字を使用してファイルの名前を変更することをお勧めします。 次に、Azure ファイル共有に対して RoboCopy を直接実行します。

警告

Windows Server 2019 の Robocopy では、現在、Robocopy の/MIR 関数を使用すると、ターゲット サーバー上の Azure File Sync によって階層化されたファイルがソースから再コピーされ、Azure に再アップロードされる問題が発生しています。 2019 以外の Windows Server では、Robocopy を使用する必要があります。 Windows Server 2016 を選択することをお勧めします。 このメモは、Windows Update を通じてこの問題が解決されると更新されます。

警告

サーバーに Azure ファイル共有の名前空間が完全にダウンロードされる前に、RoboCopy を開始することは "できません"。 詳細については、「名前空間がサーバーに完全に同期されたことを確認する」を参照してください。

移行ジョブが最後に実行されてから変更されたファイルと、前にこれらのジョブで移動されていないファイルをコピーするだけです。 移行が完了した後で、サーバーに移動されなかった問題を解決できます。 詳細については、Azure File Sync のトラブルシューティングに関する記事を参照してください。

RoboCopy にはいくつかのパラメーターがあります。 以下の例では、完全なコマンドと、これらのパラメーターを選択する理由の一覧を示します。

robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName> 
Switch 説明
/MT:n Robocopy をマルチスレッドを実行できるようにします。 n の既定値は 8 です。 スレッドの最大数は 128 です。 スレッド数が多いと使用可能な帯域幅を飽和させるのに役立ちますが、スレッド数が多ければ必ず移行が速くなるというわけではありません。 Azure Files を使ったテストでは、8 から 20 の間で、最初のコピー実行のパフォーマンスのバランスが取れていることが示されています。 後続 /MIR の実行は、使用可能なコンピューティングと使用可能なネットワーク帯域幅の影響を徐々に受けます。 後続の実行では、スレッド数の値をプロセッサのコア数およびコアあたりのスレッド数とより厳密に一致させます。 実稼働サーバーに存在する可能性のある他のタスク用にコアを予約する必要があるかどうかを検討してください。 Azure Files を使ったテストでは、最大 64 スレッドで良好なパフォーマンスが得られますが、プロセッサがそれらを同時に維持できる場合のみです。
/R:n 最初の試行でコピーに失敗したファイルの最大再試行回数です。 Robocopy では、実行中にファイルが完全にコピーに失敗するまで n 回試行します。 実行のパフォーマンスを最適化することができます。過去にタイムアウトの問題で失敗したと思われる場合は、2 または 3 の値を選んでください。 これは、WAN リンク上でより一般的である可能性があります。 ファイルが使用中であったためにコピーに失敗したと思われる場合は、[再試行しない] または 1 の値を選びます。 数秒後に再試行しても、ファイルの使用中の状態が変更されるのに十分な時間がない場合があります。 ファイルを開いているユーザーまたはアプリには、さらに時間がかかることがあります。 このような場合、ファイルがコピーされていないことを受け入れ、その後に予定されている Robocopy の実行のいずれかで試行すれば、最終的にファイルを正常にコピーするのに成功する可能性があります。 これにより、再試行のタイムアウトを過ぎてもファイルが開いているために、最終的にコピー失敗の大部分を占めることになる多数の再試行で長引かせることなく、現在の実行をより短時間で完了することができます。
/W:n 前の試行時に正常にコピーされなかったファイルのコピーを試行する前に、RoboCopy が待機する時間を指定します。 n は再試行の間の待機時間 (秒数) です。 /W:n は、多くの場合、/R:n と共に使用されます。
/B バックアップ アプリケーションが使用するのと同じモードで Robocopy を実行します。 このスイッチを使用すると、現在のユーザーがアクセス許可を持っていないファイルを、Robocopy によって移動できます。 バックアップのスイッチは、管理者特権のコンソールまたは PowerShell ウィンドウで Robocopy コマンドを実行する場合によって異なります。 Azure Files に Robocopy を使用する場合は、ストレージ アカウントのアクセス キーとドメイン ID のどちらを使用して Azure ファイル共有をマウントするかを確認します。 そうしないと、エラー メッセージが直感的でなくなり、問題解決につながらないことがあります。
/MIR (ソースをターゲットにミラーリング。) RoboCopy でソースとターゲット間の差分のみをコピーします。 空のサブディレクトリがコピーされます。 変更された、またはターゲットに存在しない項目 (ファイルまたはフォルダー) がコピーされます。 ターゲットに存在する一方でソースには存在しない項目は、ターゲットから消去 (削除) されます。 このスイッチを使用する場合は、ソースとターゲットのフォルダー構造を正確に一致させます。 "一致" とは、正しいソースおよびフォルダー レベルから、コピー先の一致するフォルダー レベルにコピーすることを意味します。 その場合にのみ、"キャッチ アップ" コピーを正常に実行することができます。 ソースとターゲットが一致しない場合に /MIR を使用すると、大規模な削除と再コピーが行われます。
/IT 特定のミラー シナリオで、忠実性が維持されることを保証します。
たとえば、Robocopy を 2 回実行する間に、ファイルで ACL の変更と属性の更新があった場合、非表示とマークされます。 /IT を使用しない場合、ACL の変更が Robocopy で見逃されて、ターゲットの場所に転送されない可能性があります。
/COPY:[copyflags] ファイル コピーの忠実性。 既定値:/COPY:DAT。 コピー フラグ: D = データ、A = 属性 T = タイムスタンプ、S = セキュリティ = NTFS ACL O = 所有者情報、U= D監査情報。 監査情報を Azure ファイル共有に格納することはできません。
/DCOPY:[copyflags] ディレクトリのコピーの忠実性。 既定値:/DCOPY:DA。 コピーフラグ: D = データ A = 属性、T = タイムスタンプ。
/NP 各ファイルとフォルダーのコピーの進行状況を表示しないよう指定します。 進行状況を表示すると、コピーのパフォーマンスが大幅に低下します。
/NFL ファイル名をログに記録しないことを指定します。 コピーのパフォーマンスを向上させます。
/NDL ディレクトリ名をログに記録しないことを指定します。 コピーのパフォーマンスを向上させます。
/XD 除外するディレクトリを指定します。 ボリュームのルートで Robocopy を実行する場合、隠しフォルダー System Volume Information を除外することを検討してください。 設計どおりに使用した場合、そこにあるすべての情報は、この正確なシステム上の正確なボリュームに固有であり、オンデマンドで再構築することができます。 この情報をコピーしても、クラウドや、データを別の Windows ボリュームにコピー バックするときには役に立ちません。 この内容を放置しておくことは、データ損失と見なさないようにする必要があります。
/UNILOG:<file name> 状態を Unicode 形式でログ ファイルに書き込みます。 (既存のログを上書きします)。
/L テスト実行の場合のみ ファイルは一覧表示されるだけです。 コピーも削除もされず、タイム スタンプも付きません。 コンソール出力には /TEE とよく使用されます。 テスト結果を適切に文書化するには、サンプル スクリプトのフラグ (/NP/NFL/NDL など) の削除が必要になる場合があります。
/LFSM 階層型ストレージを持つターゲットの場合のみ。 宛先がリモート SMB 共有の場合はサポートされません。
RoboCopy を "低空き領域モード" で動作するよう指定します。このスイッチは、RoboCopy が完了する前にローカル容量が不足する可能性がある、階層型ストレージを持つターゲットにのみ有効です。 これは、Azure File Sync のクラウドの階層化が有効なターゲットで使用するために特別に追加されました。 これは、Azure File Sync とは別に使用できます。このモードでは、ファイルのコピーによって宛先ボリュームの空き領域が "床" 値よりも小さくなるたびに、Robocopy が一時停止します。 この値は /LFSM:n のフラグ形式で指定できます。 パラメーター n は、ベース 2: nKBnMB、またはnGB で指定します。 明示的な床値を示さずに /LFSM を指定した場合、床は宛先ボリュームのサイズの 10% に設定されます。 低空き領域モードは、/MT/EFSRAW または /ZB では利用できません。 /B のサポートは Windows Server 2022 で追加されました。
/Z 慎重に使用する再起動モードでファイルをコピーします。 このスイッチは、ネットワーク環境が不安定な場合にのみ、使用することをお勧めします。 追加のログ記録が原因で、コピーのパフォーマンスが大幅に低下します。
/ZB 慎重に使用する再起動モードを使用します。 アクセスが拒否された場合、このオプションではバックアップ モードが使用されます。 このオプションでは、チェックポイント処理が原因で、コピーのパフォーマンスが大幅に低下します。

重要

Windows Server 2022 の使用をお勧めします。 Windows Server 2019 を使う場合、最新のパッチ レベルまたは少なくとも OS 更新プログラム KB5005103 がインストールされていることを確認してください。 特定の RoboCopy シナリオに対する重要な修正プログラムが含まれています。

RoboCopy コマンドのソースとターゲットの場所を構成する場合は、ソースとターゲットの構造が一致していることを確認してください。 移行ジョブのディレクトリ マッピング機能を使用した場合は、ルート ディレクトリの構造が StorSimple のボリュームの構造と異なる場合があります。 その場合は、サブディレクトリごとに 1 回ずつ、複数の RoboCopy ジョブが必要になることがあります。 コマンドが想定どおりに実行されるかどうかわからない場合は、 /L パラメーターを使用できます。これにより、実際に変更を行わずに、コマンドがシミュレートされます。

この RoboCopy コマンドでは /MIR を使用しているため、同じファイル (階層化されたファイルなど) は移動されません。 ただし、ソースとターゲットのパスが間違っている場合、/MIR により、StorSimple のソース パスに存在しない Windows Server インスタンスまたは Azure ファイル共有のディレクトリ構造も削除されます。 移行中に行われた最新の変更で移行された内容を更新するという RoboCopy ジョブの目的を達成できるように、それらを正確に一致させる必要があります。

RoboCopy のログ ファイルを調べて、ファイルが残っているかどうかを確認します。 問題がある場合は修正し、RoboCopy コマンドを再実行します。 対象のファイルまたはフォルダーの未解決の問題を解決する前に、StorSimple リソースのプロビジョニングを解除しないでください。

問題の特定の Azure ファイル共有をキャッシュするために Azure File Sync を使用せずに、直接共有アクセスを選択した場合は、次のようにします。

  1. ローカルの Windows コンピューターにネットワーク ドライブとして Azure ファイル共有をマウントします。
  2. StorSimple とマウントされた Azure ファイル共有の間で RoboCopy を実行します。 ファイルがコピーされない場合は、StorSimple 側で名前を修正して無効な文字を削除します。 その後で、RoboCopy を再試行します。 前に示した RoboCopy コマンドは、StorSimple に対する不要な呼び出しを再度行うことなく、複数回実行できます。

トラブルシューティングと最適化

指定された RoboCopy 実行の速度と成功率は、複数の要因によって決まります。

  • ソース ストレージとターゲット ストレージの IOPS
  • ソースとターゲットの間で使用可能なネットワーク帯域幅
  • 名前空間内のファイルとフォルダーを迅速に処理する機能
  • RoboCopy 実行間の変更の数

IOPS と帯域幅に関する考慮事項

このカテゴリでは、ソース ストレージターゲット ストレージ、およびそれらを接続するネットワークの能力を考慮する必要があります。 達成可能な最大スループットは、これら 3 つのコンポーネントのうち、最も低速なものによって決まります。 最大能力に応じた最適な転送速度をサポートするようにネットワーク インフラストラクチャが構成されていることを確認してください。

注意事項

多くの場合、可能な限り高速にコピーすることが望ましいですが、他のビジネス クリティカルなタスクに使用されることの多いローカル ネットワークと NAS アプライアンスの使用状況を考慮してください。

可能な限り高速にコピーすることは、移行によって使用可能なリソースを独占するリスクがある場合には望ましくない可能性があります。

  • ご使用の環境において移行を実行する最適なタイミングを考慮します (日中、時間外、または週末)。
  • また、RoboCopy の速度を調整するための Windows Server のネットワーク QoS も考慮してください。
  • 移行ツールのための不要な作業を行わないようにします。

RobCopy では /IPG:n スイッチを指定することによってパケット間の遅延を挿入できます。n は、RoboCopy パケット間においてミリ秒単位で測定されます。 このスイッチを使用すると、IO が制限されたデバイスと過密したネットワーク リンクの両方でリソースの独占を回避できます。

/IPG:n は、特定の Mbps に対する正確なネットワーク調整には使用できません。 代わりに Windows Server のネットワーク QoS を使用してください。 RoboCopy では、すべてのネットワーク ニーズに関して SMB プロトコルに完全に依存します。 SMB を使用する理由は、RoboCopy がネットワーク スループット自体に影響を与えることができないためですが、使用速度が低下する可能性はあります。

同様の考えが、NAS で観察される IOPS にも当てはまります。 NAS ボリュームのクラスター サイズ、パケット サイズ、およびその他のさまざまな要因が、観察される IOPS に影響します。 多くの場合、パケット間の遅延を導入することが、NAS の負荷を制御する最も簡単な方法です。 たとえば、約 20 ミリ秒 (n = 20) からその数値の倍数まで、複数の値をテストします。 遅延を導入すると、他のアプリが期待どおりに動作できるようになったかどうかを評価できます。 この最適化戦略により、ご使用の環境内で最適な RoboCopy 速度を見つけることができます。

処理速度

RoboCopy では、指し示されている名前空間を走査し、各ファイルとフォルダーをコピーに対して評価します。 すべてのファイルは、最初のコピー中およびキャッチアップ コピー中に評価されます。 たとえば、同じソースおよびターゲット ストレージ場所に対して RoboCopy/MIR の実行が繰り返されます。 これらの繰り返される実行は、ユーザーとアプリのダウンタイムを最小限に抑え、移行されるファイルの全体的な成功率を向上させるために役立ちます。

多くの場合、既定で帯域幅を移行における最も制限の厳しい要因と見なしています。実際にそのとおりだと考えられます。 ただし、名前空間を列挙する機能により、小さなファイルを含む大規模な名前空間の場合は、コピーの合計時間に与える影響がはるかに大きくなる可能性があります。 1 TiB 分の小さなファイルをコピーする時間は、1 TiB 分の数少ない大きなファイルをコピーする時間よりもはるかに長くなることを考慮します。 他のすべての変数が同じままであることを前提としています。

この違いの原因は、名前空間内を通過するために必要な処理能力です。 RoboCopy では、/MT:n パラメーターを使用したマルチスレッド コピーがサポートされます。ここで、n は使用されるスレッドの数を表します。 そのため、RoboCopy 専用のマシンをプロビジョニングする場合は、プロセッサ コアの数と、それらが提供するスレッド数との関係を考慮します。 最も一般的なのは、コアあたり 2 つのスレッドです。 マシンのコア数とスレッド数は、指定する必要のあるマルチスレッド値 /MT:n を決定するための重要なデータ ポイントです。 また、特定のマシンで並列実行する予定の RoboCopy ジョブの数も考慮します。

スレッドが多くなるほど、1 TiB 分の小さなファイルは、スレッドが少ない場合よりも高速にコピーされます。 一方、1 TiB 分の大きなファイルにリソースを追加投資しても、相応のメリットは得られない場合があります。 スレッド数が多いと、ネットワーク経由で大きなファイルを同時により多くコピーしようとします。 この追加のネットワーク アクティビティによって、スループットまたはストレージ IOPS による制約を受ける可能性が高くなります。

空のターゲットへの最初の RoboCopy 中、または多数の変更されたファイルを使用した差分実行中に、ネットワーク スループットによって制限される可能性があります。 最初の実行では、スレッド数を多くしてください。 スレッド数が多いと、コンピューター上で現在使用可能なスレッドを超えても、使用可能なネットワーク帯域幅が飽和状態になります。 後続の/MIR の実行は、アイテムを処理することによって徐々に影響を受けます。 差分実行の変更が少ないほど、ネットワーク経由でのデータ転送が減少します。 ネットワーク リンク上で移動する機能よりも、名前空間項目を処理する機能によって速度が向上するようになりました。 後続の実行では、スレッド数の値をプロセッサのコア数およびコアあたりのスレッド数と一致させます。 実稼働サーバーに存在する可能性のある他のタスク用にコアを予約する必要があるかどうかを検討してください。

ヒント

経験則: 最初の RoboCopy 実行ではより高遅延のネットワークのデータを大量に移動するため、スレッド カウントをオーバープロビジョニングすることでメリットが得られます (/MT:n)。 その後の実行ではコピーされる差異が少なくなり、おそらくは、ネットワーク スループット制約からコンピューティング制約に移行するでしょう。 こうした状況では多くの場合、RoboCopy のスレッド カウントをマシンで実際に利用できるスレッドに合わせることが推奨されます。 そのシナリオでのオーバープロビジョニングはプロセッサのコンテキスト移動を増やす場合があり、おそらくコピーが遅くなるでしょう。

不要な作業の回避

名前空間の大規模な変更は避けてください。 ディレクトリ間でのファイルの移動、プロパティの大規模な変更、アクセス許可 (NTFS ACL) の変更などです。 特に ACL の変更は、フォルダー階層の下位にあるファイルに対して変更が連鎖的に影響することが多いため、大きな影響を及ぼす可能性があります。 次のような影響が考えられます。

  • ACL の変更によって影響を受けた各ファイルおよびフォルダーを更新する必要があるため、RoboCopy ジョブの実行時間が長くなる
  • 以前に移動したデータを再利用するには、再コピーが必要になる場合がある。 たとえば、ファイルが既にコピーされた後にフォルダー構造が変更される場合、より多くのデータをコピーする必要があります。 RoboCopy ジョブでは、名前空間の変更を "再生" できません。 次のジョブで、古いフォルダー構造へ以前に転送されたファイルを削除し、新しいフォルダー構造でファイルを再度アップロードする必要があります。

もう 1 つの重要な側面は、RoboCopy ツールを効果的に使用することです。 推奨される RoboCopy スクリプトでは、エラー用のログ ファイルを作成して保存します。 コピー エラーは発生する可能性があります。それが普通です。 多くの場合、これらのエラーによって、RoboCopy などのコピー ツールを複数ラウンド実行することが必要になります。 最初の実行 (NAS からファイル、サーバーから Azure ファイル共有、など)。 コピーされなかったファイルをキャッチして再試行するための /MIR スイッチを使用した 1 回以上の追加実行。

特定の名前空間スコープに対して RoboCopy を複数ラウンドを実行する準備を整えておく必要があります。 後続の実行は、コピー対象が少なくなるので迅速に完了しますが、名前空間の処理速度によって次第に制約されます。 複数ラウンドを実行する場合は、RoboCopy の特定の実行で非合理的にすべてをコピーしようとしないようにすることで、各ラウンドを高速化できます。 これらの RoboCopy スイッチにより、大きな違いがもたらされる可能性があります。

  • /R:n n = 失敗したファイルのコピーを再試行する頻度
  • /W:n n = 再試行を待機する秒数

/R:5 /W:5 が合理的な設定ですが、自由に調整できます。 この例では、失敗したファイルは 5 回再試行され、再試行間の待機時間は 5 秒です。 それでもファイルのコピーに失敗した場合は、次の RoboCopy ジョブで再試行されます。 多くの場合、使用中であることまたはタイムアウトの問題が原因で失敗したファイルは、最終的にこの方法でコピーされる可能性があります。

ユーザーのカットオーバー

Azure File Sync を使用している場合は、その Azure File Sync が有効になっている Windows Server インスタンスに、StorSimple のボリュームに存在していた共有と一致する SMB 共有を作成することが、必要になる可能性があります。 ここで時間を無駄にしないために、このステップを前倒しし、早期に実行することができます。 ただし、この時点より前に、Windows Server インスタンスが変更されないよう、誰もアクセスできないようにする必要があります。

DFS-N のデプロイがある場合、DFN 名前空間を新しいサーバー フォルダーの場所に指すようにすることができます。 DFS-N のデプロイがなく、Windows Server インスタンスを使用するローカル環境に 8100 または 8600 アプライアンスを配置した場合、そのサーバーをドメインから削除できます。 次に、Azure File Sync を有効にした新しい Windows Server インスタンスをドメインに参加させます。 そのプロセスの間に、そのサーバーに古いサーバーと同じサーバー名と共有名を指定し、カットオーバーがユーザー、グループ ポリシー、スクリプトに対して透過的なままになるようにします。

DFS-N の詳細を参照してください。

フェーズ 6: プロビジョニング解除

リソースのプロビジョニングを解除すると、そのリソースおよびそのデータの構成にアクセスできなくなります。 プロビジョニング解除を元に戻すことはできません。 次のことを確認するまで続行しないでください。

  • 移行が完了しました。
  • プロビジョニングを解除しようとしている StorSimple ファイル、フォルダー、またはボリューム バックアップに関する依存関係がありません。

始める前に、運用環境の新しい Azure File Sync のデプロイを少し観察することをお勧めします。 その間に、発生する可能性のある問題を修正できます。 Azure File Sync のデプロイを少なくとも数日間観察した後、リソースのプロビジョニング解除を次の順序で開始できます。

  1. Azure portal を使用して StorSimple Data Manager リソースのプロビジョニングを解除します。 それによりすべての DTS ジョブが削除されます。 コピー ログを簡単に取得することができなくなります。 それらがレコードにとって重要な場合は、プロビジョニングを解除する前に取得します。
  2. StorSimple の物理アプライアンスが移行されていることを確認してから、登録を解除します。 移行されたことを確認できない場合は、続行しないでください。 まだ必要な間にこれらのリソースのプロビジョニングを解除した場合、データやその構成を回復することはできません。
    必要に応じて、最初に StorSimple ボリューム リソースのプロビジョニングを解除できます。これにより、アプライアンス上のデータがクリーンアップされます。 このプロセスには数日かかることがあり、アプライアンス上のデータが科学捜査的にゼロに設定されることはありません。 このことが重要な場合は、リソースのプロビジョニング解除とは別に、ポリシーに従って、ディスクのゼロ設定を処理する必要があります。
  3. StorSimple デバイス マネージャーに登録されているデバイスがこれ以上ない場合は、そのデバイス マネージャー リソース自体を削除することができます。
  4. それから、Azure の StorSimple ストレージ アカウントを削除します。 やはり、続行する前に、移行が完了していることと、このデータに依存しているものやユーザーがないことを確認してください。
  5. StorSimple 物理アプライアンスをデータ センターから取り外します。
  6. StorSimple アプライアンスを所有している場合は、PC を自由にリサイクルできます。 デバイスがリースされている場合は、リース元に通知し、必要に応じてデバイスを返却します。

移行が完了しました。


Note

まだ質問があるか、問題が発生していますか。
その場合は、
にご連絡ください

次の手順