Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Durante la fase de evaluación, los recursos de datos, las dependencias y el volumen y el uso de datos se inventarian sistemáticamente. Este inventario tiene en cuenta los datos tanto en su estado previo como posterior a la migración. Cada conjunto de datos se genera un perfil según factores como el rendimiento, la resistencia, la seguridad, el costo y los requisitos de uso. Estos atributos ayudan con la evaluación adecuada y la selección del servicio de destino.
La lista siguiente contiene elementos inventariados y catalogados habitualmente para detectar y evaluar los datos de origen.
Inventario de recursos de datos
- Catalogar todos los orígenes de datos que se van a migrar. Estos orígenes incluyen datos de usuario, recursos compartidos de departamento, recursos compartidos de archivos, datos de aplicaciones, sistemas de administración de contenido y bases de datos. También incluyen datos de archivo de copia de seguridad, discos de máquina virtual o datos almacenados en cualquier archivo SAN, NAS, DFS o cinta.
- Calcule el tamaño de los datos en GB/TB/PB para cada origen de datos del catálogo. Incluya el número aproximado de archivos y objetos.
- Capture la jerarquía y la profundidad de las estructuras de directorio.
- Alinee todas las propiedades especiales, como nombres de archivo reservados, longitud de directorio o archivo, rutas deacceso largas o flujos de datos alternativos implicados .
- Registre los métodos de autenticación implicados para los servicios de datos actuales y futuros.
Identificación de patrones de tipo de datos y acceso
- Registre el tipo de datos y el método de acceso para cada origen y la frecuencia de acceso.
- Identifique los métodos y protocolos de acceso en el nivel de archivo, en el nivel de objeto o en el nivel de bloque. Por ejemplo, los protocolos de nivel de archivo pueden incluir SMB o NFS. Los protocolos de nivel de objeto pueden incluir API de REST o S3, y los protocolos de nivel de bloque pueden incluir iSCSI o discos sin procesar o LUN conectados a servidores.
- Registre las dependencias de la aplicación en estos datos para el acceso previo y posterior a la migración, con los protocolos una vez que se hayan migrado a Azure.
- Capturar niveles de permisos y ACL específicos, requisitos de retención de permisos y cualquier soporte específico de características para el archivo, como enumeración basada en acceso o flujos de datos alternativos.
- Observe también los patrones de acceso: secuencial frente a aleatorio; proporción de lectura y escritura
- Mencione si está considerando la consolidación o reorganización de los datos a medida que migra a Azure Storage.
Descripción de las necesidades de rendimiento
- Evaluación del ancho de banda de red y la latencia entre el origen y Azure
- Registrar los límites de rendimiento de lectura y escritura de la fuente o límites de IOPS, requisitos de rendimiento
- Patrones estacionales o de ráfaga
- ¿Cuáles son los requisitos de integración externos e internos para los datos de origen detectados?
Evaluar la replicación, la tasa de cambio, la resistencia y la tolerancia al tiempo de inactividad
- Determine las tasas de cambio de datos para comprender con qué frecuencia cambian los datos y el tiempo de inactividad aceptable para la transición. Si los datos son estáticos y no cambian, se acepta una copia única. Sin embargo, cambiar activamente los datos dinámicos requiere que planee las sincronizaciones incrementales y una ventana de transición final.
- Acepte cualquier período de solo lectura para la migración final para evitar actualizaciones perdidas.
- Capture los requisitos de SLA, RPO y RTO en función de las necesidades de disponibilidad y resistencia de una aplicación.
- Documente las necesidades de protección, recuperación y supervisión de datos existentes.
- Capture las directivas de replicación, como los requisitos de alta disponibilidad o recuperación ante desastres sincrónicos o asincrónicos. Tenga en cuenta también las políticas de instantáneas, si procede, como la frecuencia y el período de retención.
En este punto, considere si los cambios de datos son excesivamente frecuentes y si el ancho de banda de red actual puede admitir los cambios diferenciales después de la inicialización sin conexión. ¿Hay otros parámetros que se deben tener en cuenta para estos sistemas y los datos?
Tener en cuenta los requisitos de seguridad y cumplimiento
- Documente los permisos y ACL en los datos. Asegúrese de que el método de migración puede conservarlos o cree un plan para volver a aplicarlos en Azure.
- Planee usar ExpressRoute o Private Link para los datos en tránsito que no deben transitar por Internet pública.
- Tenga en cuenta que el cumplimiento normativo podría dictar regiones específicas de Azure como destino para cumplir con los requisitos de residencia de datos. Clasifique los datos en función de las necesidades de seguridad y cumplimiento, como la auditoría o la cadena de custodia. Si está considerando la migración sin conexión, revise y documente las necesidades específicas.
- Describa las decisiones clave de diseño técnico que deben revisarse y establecerse para avanzar con las selecciones de destino.
- Tenga en cuenta si algún sistema está a punto de finalizar la vida útil. Aunque es posible que los sistemas en desuso no se migren, es posible que los datos del sistema se almacenen durante un período determinado para cumplir con el cumplimiento normativo.
Al final de la fase de evaluación, debe tener un documento que describa claramente los requisitos de cada origen de datos. Estos requisitos incluyen sus necesidades actuales y futuras, y sus conjuntos específicos de requisitos después de migrar a un sistema o servicio de destino. El documento evaluación define claramente las funcionalidades que deben estar presentes en los sistemas de destino para hospedar correctamente los datos.