Оценка миграции хранилища

На этапе оценки систематически инвентаризируются данные, их зависимости, объем и использование. Эта инвентаризация учитывает данные как в состоянии до миграции, так и после нее. Каждый набор данных профилируется в соответствии с такими факторами, как производительность, устойчивость, безопасность, затраты и требования к использованию. Эти атрибуты помогают в соответствующей оценке и целевом выборе службы.

В следующем списке содержатся распространенные и каталогированные элементы для обнаружения и оценки исходных данных.

Ресурсы данных инвентаризации

  1. Каталог всех источников данных , которые переносятся. К этим источникам относятся данные пользователей, общие папки отделов, общие папки, данные приложения, системы управления содержимым и базы данных. Они также включают резервные копии архивных данных, диски виртуальных машин или данные, хранящиеся в любой сети SAN, NAS, DFS или ленточных архивах.
  2. Оцените размер данных в ГБ/ТБ/ТС для каждого источника данных в каталоге. Включите приблизительное количество файлов и объектов.
  3. Захват иерархии и глубины структур каталогов.
  4. Выстройте все специальные свойства, такие как зарезервированные имена файлов, длина каталога или файла, длинные пути или альтернативные потоки данных .
  5. Запишите методы проверки подлинности , участвующие в текущих и будущих службах данных.

Определение типов данных и шаблонов доступа

  1. Запишите тип данных и метод доступа для каждого источника и частоту доступа.
  2. Определите методы и протоколы доступа на уровне файлов, на уровне объекта или на уровне блока. Например, протоколы уровня файлов могут включать SMB или NFS. Протоколы уровня объектов могут включать S3 или REST API, а протоколы уровня блоков могут включать iSCSI или необработанные диски или LUN, подключенные к серверам.
  3. Записывайте зависимости приложений от этих данных для доступа до и после миграции, а также протоколы после их переноса в Azure.
  4. Учет определенных уровней разрешений и списков управления доступом, требований к хранению разрешений, а также конкретной поддержки функций для файла, таких как перечисление на основе доступа или альтернативные потоки данных.
  5. Кроме того, обратите внимание на шаблоны доступа— последовательные и случайные; Коэффициент чтения и записи
  6. Обратите внимание, если вы рассматриваете возможность консолидации или реорганизации данных при переходе в хранилище Azure.

Понимание потребностей в производительности

  1. Оценка пропускной способности сети и задержки между источником и Azure
  2. Записывайте производительность чтения и записи источника или ограничения по IOPS, требования к пропускной способности
  3. Сезонные или всплесковые паттерны
  4. Каковы требования к внешней и внутренней интеграции для обнаруженных исходных данных

Оценка репликации, частоты изменений, устойчивости и отказоустойчивости

  1. Определите частоту изменений данных, чтобы понять, как часто изменяются данные, и допустимое время простоя для переключения. Если данные являются статическими и не изменяются, однократная копия является приемлемой. Однако активное изменение динамических данных требует планирования добавочных синхронизаций и окончательного окна переключения.
  2. Договоритесь о любом периоде только для чтения для окончательной миграции, чтобы избежать пропущенных обновлений.
  3. Сбор требований по SLA, RPO, RTO в зависимости от нужд приложения в доступности и устойчивости.
  4. Документируйте существующие потребности в защите данных, восстановлении и мониторинге.
  5. Учтите любые политики репликации, такие как синхронная или асинхронная высокая доступность или требования к аварийному восстановлению. Кроме того, обратите внимание на любые политики моментальных снимков, если это применимо, например частоту и период хранения.

На этом этапе рассмотрите, являются ли изменения данных чрезмерно частыми, и может ли текущая пропускная способность сети поддерживать разностные изменения после первоначального автономного засеивания. Существуют ли другие параметры, которые следует учитывать для таких систем и данных?

Учитывайте требования безопасности и соответствия

  1. Задокументируйте все разрешения и списки управления доступом (ACL) к данным. Убедитесь, что метод миграции может сохранить их или создать план для повторного их использования в Azure.
  2. Запланируйте использовать ExpressRoute или Приватный канал для любых данных в полете, которые не должны транзитировать общедоступный Интернет.
  3. Учитывайте, что соответствие нормативным требованиям может диктовать определенные целевые регионы Azure для соблюдения требований к месту расположения данных. Классифицируйте данные на основе требований безопасности и соответствия требованиям, таких как аудит или цепочка хранения. Если вы рассматриваете автономную миграцию, просмотрите и задокументируйте все такие конкретные потребности.
  4. Очертания ключевых технических решений по проектированию , которые необходимо проверить и установить, чтобы перейти к выбору целевых объектов.
  5. Рассмотрим, приближается ли любая система к концу жизни. Хотя устаревшие системы могут не переноситься, возможно, что системные данные должны храниться в течение определенного периода, чтобы обеспечить соответствие нормативным требованиям.

В конце этапа оценки должен быть документ, который четко описывает требования для каждого источника данных. К этим требованиям относятся его нынешние и будущие потребности, а также его конкретные наборы требований после миграции в целевую систему или службу. Документ оценки четко определяет возможности, которые должны присутствовать в целевых системах для успешного размещения данных.

См. также

  • Last updated on