次の方法で共有


ストレージ移行の評価

評価フェーズでは、データ資産、依存関係、およびデータの量と使用状況が体系的にインベントリされます。 このインベントリでは、移行前と移行後の両方の状態のデータが考慮されます。 各データセットは、パフォーマンス、回復性、セキュリティ、コスト、使用要件などの要因に従ってプロファイリングされます。 これらの属性は、適切な評価とターゲット サービスの選択に役立ちます。

次の一覧には、ソース データを検出して評価するために、一般的にインベントリされたアイテムとカタログ化されたアイテムが含まれています。

インベントリ データ資産

  1. 移行されるすべての データ ソース をカタログ化します。 これらのソースには、ユーザー データ、部門共有、ファイル共有、アプリケーション データ、コンテンツ管理システム、データベースが含まれます。 また、バックアップ アーカイブ データ、仮想マシン ディスク、SAN、NAS、DFS、またはテープ アーカイブに格納されているデータも含まれます。
  2. カタログ内の 各データ ソースのデータ サイズ を GB/TB/PB 単位で見積もります。 ファイルとオブジェクトの概数を含めます。
  3. ディレクトリ構造の階層と深さをキャプチャします。
  4. 予約済みファイル名ディレクトリまたはファイルの長さ長いパス、関連する代替データ ストリームなどの特別なプロパティを下に行います。
  5. 現在および将来のデータ サービスに関連する 認証方法 を記録します。

データ型とアクセス パターンを識別する

  1. 各ソースの データ型アクセス方法 、および アクセスの頻度を記録します。
  2. ファイル レベル、オブジェクト レベル、またはブロック レベルで アクセス方法とプロトコル を識別します。 たとえば、ファイル レベルのプロトコルには SMB や NFS が含まれる場合があります。 オブジェクト レベルのプロトコルには S3 または REST API が含まれる場合があり、ブロック レベルのプロトコルには、iSCSI、またはサーバーに接続されている生ディスクまたは LUN が含まれる場合があります。
  3. 移行前と移行後のアクセスのために、このデータに対する アプリケーションの依存関係 を記録します。このプロトコルは、いったん Azure に移行されました。
  4. 特定のアクセス許可レベルと ACL、アクセス許可の保持要件、および アクセス ベースの列挙代替データ ストリームなどのファイルに対する特定の機能のサポートをキャプチャします。
  5. また、 アクセス パターン (シーケンシャルとランダム) にも注意してください。読み取り/書き込み比率
  6. Azure Storage に移行するときに、データの 統合または再編成 を検討している場合に言及してください。

パフォーマンスのニーズを理解する

  1. ソースと Azure の間のネットワーク 帯域幅と待機時間 を評価する
  2. レコード ソースの読み取り/書き込みのパフォーマンスまたは IOPS の制限、スループットの要件
  3. 季節パターンまたは バースト パターン
  4. 検出されたソース データの 外部および内部統合 の要件

レプリケーション、変更率、回復性、ダウンタイムの許容度を評価する

  1. データ 変更率を 決定して、データ変更の頻度と、カットオーバーの許容される ダウンタイム を把握します。 データが静的であり、変更されない場合は、1 回限りコピーを使用できます。 ただし、動的データを積極的に変更するには、増分同期と最終的なカットオーバー ウィンドウを計画する必要があります。
  2. 更新が見逃されないように、最終移行のための読み取り専用期間について合意する。
  3. アプリケーションの可用性と回復性のニーズに基づいて、SLA、RPO、RTO の要件をキャプチャします。
  4. 既存のデータ保護、回復、監視のニーズを文書化します。
  5. 同期または非同期の高可用性やディザスター リカバリーの要件など、レプリケーション ポリシーをキャプチャします。 また、頻度や保有期間など、該当する場合はスナップショット ポリシーにも注意してください。

この時点で、データの変更が過度に頻繁かどうか、および初期オフライン シード処理後に現在のネットワーク帯域幅が差分変更をサポートできるかどうかを検討します。 このようなシステムとデータに関して考慮すべきその他のパラメーターはありますか?

セキュリティとコンプライアンスの要件を考慮する

  1. データに 対するアクセス許可ACL を 文書化します。 移行方法で保持できることを確認するか、Azure で 再適用 する計画を作成します。
  2. パブリック インターネットを転送してはならないすべての機内データに ExpressRoute または Private Link を使用することを計画します。
  3. 規制コンプライアンスによって、データ所在地の要件に準拠するように特定のターゲット Azure リージョンが決まる可能性があることを検討してください。 監査や保管チェーンなど、セキュリティとコンプライアンスのニーズに基づいてデータ分類します。 オフライン移行を検討している場合は、そのような特定のニーズを確認して文書化します。
  4. ターゲット選択を進めるためにレビューおよび確立する必要がある 主要な技術的設計 上の決定について概説します。
  5. システムの寿命が近いかどうかを検討します。 非推奨のシステムは移行されない可能性がありますが、規制コンプライアンスを満たすためにシステム データを一定期間保存する必要がある可能性があります。

評価フェーズの最後には、各データ ソースの要件を明確に示すドキュメントが必要です。 これらの要件には、現在および将来のニーズ、およびターゲット システムまたはサービスに移行した後の特定の要件セットが含まれます。 評価ドキュメントでは、データを正常にホストするためにターゲット システムに存在する必要がある機能を明確に定義します。

こちらも参照ください