Skip to main content
NetApp Solutions
Se proporciona el idioma español mediante traducción automática para su comodidad. En caso de alguna inconsistencia, el inglés precede al español.

Migre las máquinas virtuales a Amazon EC2 mediante Amazon FSx para ONTAP: Guía de puesta en marcha

Colaboradores
PDF

En este artículo se describe el procedimiento de implementación de estas soluciones de migración.

Configuración de FSx ONTAP y Cirrus Data para las operaciones de migración

Esto "guía de puesta en marcha paso a paso" muestra cómo añadir un volumen de FSx ONTAP a una VPC. Dado que estos pasos son de naturaleza secuencial, asegúrese de que estén cubiertos en orden.

A efectos de esta demostración, “DRaaSDemo” es el nombre del sistema de archivos creado.

Imagen de la interfaz de usuario del sistema de archivos de demostración

Una vez que AWS VPC está configurado y FSx ONTAP se aprovisiona en función de tus requisitos de rendimiento, inicia sesión en "cloud.cirrusdata.com" "cree un nuevo proyecto"un proyecto existente o accede a él.

Imagen de la interfaz de usuario de Cirrus Data Projects

Antes de crear la receta para MigrationOps, hay que añadir la nube de AWS como una integración. CMC proporciona integración integrada con FSx ONTAP y AWS. La integración de FSx ONTAP proporciona las siguientes funcionalidades automatizadas:

Prepara tu sistema de archivos FSX ONTAP:

  • Cree nuevos volúmenes y LUN que coincidan con los volúmenes de origen

Nota: Un disco de destino en el modelo FSX ONTAP FS es un “LUN” que se crea en un “Volumen” que tiene suficiente capacidad para contener el LUN más una cantidad razonable de sobrecarga para facilitar instantáneas y metadatos. La automatización de CMC se encarga de todos estos detalles para crear el volumen y la LUN adecuados con parámetros opcionales definidos por el usuario.

  • Cree una entidad de host (denominada iGroups en FSx) con el IQN del iniciador de host

  • Asigne los volúmenes recién creados a entidades host apropiadas mediante asignaciones

  • Crear todas las demás configuraciones necesarias

Prepare el host de producción para la conexión iSCSI:

  • Si es necesario, instale y configure la función iSCSI y configure el iniciador.

  • Si es necesario, instale y configure multipath (MPIO para Windows) con los identificadores de proveedor adecuados.

  • Ajuste la configuración del sistema, si es necesario, de acuerdo con las mejores prácticas del proveedor, por ejemplo, con la configuración udev en Linux.

  • Cree y gestione conexiones iSCSI como destinos iSCSI persistentes/favoritos en Windows.

Para configurar la integración de CMC para FSx ONTAP y AWS, realice los siguientes pasos:

  1. Inicie sesión en el portal de Cirrus Data Cloud.

  2. Vaya al proyecto para el que desea activar la integración.

  3. Vaya a Integraciones → Goodies.

  4. Desplácese hasta encontrar FSx ONTAP y haga clic en AGREGAR INTEGRACIÓN.

    Imagen de la interfaz de usuario 'Añadir integración' de Cirrus Data

  5. Proporcione un nombre descriptivo (estrictamente para fines de visualización) y agregue las credenciales adecuadas.

    Imagen de la interfaz de usuario 'Añadir integración' de Cirrus Data

  6. Una vez creada la integración, durante la creación de una nueva sesión de migración, seleccione Asignar volúmenes de destino automáticamente para asignar automáticamente nuevos volúmenes en FSx ONTAP.

    Nota: Se crearán nuevas LUN con el mismo tamaño que el tamaño del volumen de origen, a menos que “Migrate to small volumes” (Migración a volúmenes más pequeños) esté habilitado para la migración.

    Nota: Si una entidad host (iGroup) no existe todavía, se creará una nueva. Se añadirán todos los IQN de iniciador iSCSI de host a la nueva entidad de host.

    Nota: Si ya existe una entidad host existente con alguno de los iniciadores iSCSI, se reutilizará.

  7. Una vez hecho esto, agrega la integración para AWS, siguiendo los pasos en la pantalla.

    Imagen de la interfaz de usuario 'Añadir integración' de Cirrus Data

    Nota: Esta integración se utiliza al migrar máquinas virtuales del almacenamiento local a AWS junto con la integración de FSX ONTAP.

    Nota: Utilice relés de administración para comunicarse con Cirrus Data Cloud si no hay conexión saliente directa para migrar instancias de producción.

Con Integraciones agregadas, es hora de registrar hosts con el Proyecto. Vamos a cubrir esto con un escenario de ejemplo.

Escenario de registro de host

Equipos virtuales VMware invitados que residen en vCenter en el centro de datos en las instalaciones:

  • Windows 2016 se ejecuta con SQL Server con tres VMDK, incluidos los sistemas operativos y los discos de datos. Está ejecutando una base de datos activa. La base de datos se encuentra en un volumen de datos respaldado por dos VMDK.

Nota: Dado que el origen es un entorno VMware y se utilizan VMDK, el software del iniciador iSCSI de Windows no está configurado actualmente en esta máquina virtual invitada. Para conectar con nuestro almacenamiento de destino mediante iSCSI, se deberán instalar y configurar tanto iSCSI como MPIO. La integración de Cirrus Data Cloud realizará esta instalación automáticamente durante el proceso.

Nota: La integración configurada en la sección anterior automatiza la configuración del nuevo almacenamiento de destino en la creación de los nuevos discos, la configuración de las entidades host y sus IQN, e incluso la corrección de la aplicación VM (host) para configuraciones iSCSI y multivía.

Imagen de las máquinas virtuales de VMware que se migrarán

Esta demostración migrará los VMDK de aplicación desde cada equipo virtual a un volumen iSCSI aprovisionado y asignado automáticamente desde FSx ONTAP. El VMDK del sistema operativo en este caso se migrará a un volumen de Amazon EBS, ya que las instancias de Amazon EC2 admiten este Amazon EBS solo como disco de arranque.

Nota: El factor de escala con este enfoque de migración es el ancho de banda de la red y la tubería que conecta en las instalaciones a AWS VPC. Como cada equipo virtual tiene configurada 1:1 sesión de host, el rendimiento de migración general depende de dos factores:

  • Ancho de banda de red

  • Tipo de instancia de destino y ancho de banda ENI

Los pasos de migración son los siguientes:

  1. Instalar el agente CMC en cada host (Windows y Linux) designado para la etapa de migración. Esto se puede realizar ejecutando un comando de instalación de una línea.

    Para ello, acceda a Data Migration > Migration Hosts > haga clic en «Deploy Cirrus Migrate Cloud» y seleccione «Windows».

    A continuación, copie el iex Comando al host y ejecutarlo mediante PowerShell. Una vez que el despliegue del agente se realiza correctamente, el host se agregará al proyecto bajo “Hosts de migración”.

    Imagen de la interfaz de instalación de Cirrus Data

    Imagen del progreso de la instalación de Windows

  2. Prepare el YAML para cada máquina virtual.

    Nota: Es un paso vital tener un YAML para cada VM que especifique la receta o el plan necesario para la tarea de migración.

    El YAML proporciona el nombre de la operación, las notas (descripción) junto con el nombre de la receta como MIGRATEOPS_AWS_COMPUTE, el nombre del host (system_name) y nombre de integración (integration_name) y la configuración de origen y destino. Los scripts personalizados se pueden especificar como una acción antes y después de la transición.

    operations:
    -   name: Win2016 SQL server to AWS
        notes: Migrate OS to AWS with EBS and Data to FSx ONTAP
        recipe: MIGRATEOPS_AWS_COMPUTE
        config:
            system_name: Win2016-123
            integration_name: NimAWShybrid
            migrateops_aws_compute:
                region: us-west-2
                compute:
                    instance_type: t3.medium
                    availability_zone: us-west-2b
                network:
                    vpc_id: vpc-05596abe79cb653b7
                    subnet_id: subnet-070aeb9d6b1b804dd
                    security_group_names:
                        - default
                destination:
                    default_volume_params:
                        volume_type: GP2
                    iscsi_data_storage:
                        integration_name: DemoDRaaS
                        default_volume_params:
                            netapp:
                                qos_policy_name: ""
                migration:
                    session_description: Migrate OS to AWS with EBS and Data to FSx ONTAP
                    qos_level: MODERATE
                cutover:
                    stop_applications:
                        - os_shell:
                              script:
                                  - stop-service -name 'MSSQLSERVER' -Force
                                  - Start-Sleep -Seconds 5
                                  - Set-Service -Name 'MSSQLSERVER' -StartupType Disabled
                                  - write-output "SQL service stopped and disabled"

                        - storage_unmount:
                              mountpoint: e
                        - storage_unmount:
                              mountpoint: f
                    after_cutover:
                        - os_shell:
                              script:
                                  - stop-service -name 'MSSQLSERVER' -Force
                                  - write-output "Waiting 90 seconds to mount disks..." > log.txt
                                  - Start-Sleep -Seconds 90
                                  - write-output "Now re-mounting disks E and F for SQL..." >>log.txt
                        - storage_unmount:
                              mountpoint: e
                        - storage_unmount:
                              mountpoint: f
                        - storage_mount_all: {}
                        - os_shell:
                              script:
                                  - write-output "Waiting 60 seconds to restart SQL Services..." >>log.txt
                                  - Start-Sleep -Seconds 60
                                  - stop-service -name 'MSSQLSERVER' -Force
                                  - Start-Sleep -Seconds 3
                                  - write-output "Start SQL Services..." >>log.txt
                                  - Set-Service -Name 'MSSQLSERVER' -StartupType Automatic
                                  - start-service -name 'MSSQLSERVER'
                                  - write-output "SQL started" >>log.txt

  3. Una vez instalados los YAML, crea la configuración de MigrateOps. Para ello, vaya a Data Migration > MigrateOps, haga clic en “Start New Operation” (Iniciar nueva operación) e introduzca la configuración en formato YAML válido.

  4. Haga clic en “Crear operación”.

    Nota: Para lograr el paralelismo, cada host necesita tener un archivo YAML especificado y configurado.

  5. A menos que el scheduled_start_time el campo se especifica en la configuración, la operación se iniciará inmediatamente.

  6. La operación se ejecutará y continuará. Desde la interfaz de usuario de Cirrus Data Cloud, puede supervisar el progreso con mensajes detallados. Estos pasos incluyen automáticamente tareas que normalmente se realizan manualmente, como la asignación automática y la creación de sesiones de migración.

    Imagen del progreso de la migración de Cirrus Data

    Nota: Durante la migración host-a-host, se creará un grupo de seguridad adicional con una regla que permita el puerto 4996 entrante, que permitirá el puerto requerido para la comunicación y se eliminará automáticamente una vez que se complete la sincronización.

    Imagen de la regla de entrada necesaria para la migración de Cirrus Data

  7. Mientras esta sesión de migración se está sincronizando, hay un paso futuro en la fase 3 (transposición) con la etiqueta «Aprobación requerida». En una receta de MigrateOps, las tareas críticas (como los cortes de migración) requieren la aprobación del usuario antes de que puedan ejecutarse. Los operadores o administradores de proyectos pueden aprobar estas tareas desde la interfaz de usuario. También se puede crear una ventana de aprobación futura.

    Imagen de la sincronización de migración de Cirrus Data

  8. Una vez aprobada, la operación de MigrateOps continúa con la transición.

  9. Después de un breve momento, la operación se completará.

    Imagen de la finalización de la migración de Cirrus Data

    Nota: Con la ayuda de la tecnología Cirrus Data cMotion™, el almacenamiento de destino se ha mantenido actualizado con todos los cambios más recientes. Por lo tanto, una vez aprobada, el proceso final de transición llevará muy poco tiempo, menos de un minuto, en completarse.

Verificación posterior a la migración

Veamos la instancia de Amazon EC2 migrada que ejecuta el sistema operativo Windows Server y los siguientes pasos que se han completado:

  1. Los servicios SQL de Windows se han iniciado ahora.

  2. La base de datos vuelve a estar en línea y está utilizando el almacenamiento del dispositivo iSCSI Multipath.

  3. Todos los registros nuevos de la base de datos agregados durante la migración se pueden encontrar en la base de datos recién migrada.

  4. El almacenamiento antiguo ahora se encuentra desconectado.

Nota: Con solo un clic para enviar la operación de movilidad de datos como código, y un clic para aprobar la transposición, la VM ha migrado con éxito de VMware en las instalaciones a una instancia de Amazon EC2 usando FSx ONTAP y sus capacidades iSCSI.

Nota: Debido a la limitación de la API de AWS, las VM convertidas se mostrarían como “Ubuntu”. Esto es estrictamente un problema de visualización y no afecta a la funcionalidad de la instancia migrada. Una próxima versión resolverá este problema.

Nota: Se puede acceder a las instancias migradas de Amazon EC2 utilizando las credenciales que se utilizaron en el lado local.