Para realizar con éxito una estrategia de migración de datos en un entorno virtual, las organizaciones necesitan hacer frente a factores tales como la estructura de datos y la contención de recursos.
Cuando llega el momento de virtualizar los servidores de una organización, es importante planificar cualquier migración de datos requerida.
El primer paso en cualquier estrategia de migración de datos es determinar si los datos realmente necesitan ser migrados. Las organizaciones tienen muchas razones diferentes para realizar conversiones de físico a virtual. En función de esas razones, puede ser perfectamente aceptable virtualizar sus servidores de aplicaciones, pero no sus servidores de base de datos back-end. Si una organización está tratando de virtualizar tantos sistemas como sea posible, para que pueda pasar todo a una plataforma estándar, entonces probablemente será necesaria una migración de datos.
Una vez que haya decidido qué datos necesitan ser migrados, las siguientes dos preguntas deben ser abordadas:
¿Los datos son estructurados o no?
El tipo de datos en cuestión puede hacer una gran diferencia con respecto a la logística de la estrategia de migración de datos. Por lo general es más fácil migrar los datos no estructurados (datos de archivos), ya que se pueden migrar gradualmente mediante la replicación del sistema de archivos o usando el respaldo y restauración.
Los datos estructurados (datos de base de datos) son más complicados de migrar porque siempre están en uso. Dada la naturaleza de los datos estructurados, una migración gradual probablemente no será una opción.
En la mayoría de los casos, las bases de datos de misión crítica se configuran como grupos de alta disponibilidad. En tales situaciones, a menudo es posible virtualizar los nodos individuales del clúster de base de datos, creando un clúster invitado en el proceso. Sin embargo, hay dos principales consideraciones al hacerlo:
- Si su hipervisor lo admite, tendrá que establecer algunas reglas anti-afinidad para evitar que los nodos del clúster invitado residan en un host físico común. De lo contrario, un fallo a nivel de host podría, en teoría, causar que su clúster de base de datos falle. Mientras que los nodos del clúster de base de datos deberían conmutar por error a un nodo de clúster de hipervisor diferente en el caso de un fallo del host, usted puede mejorar en gran medida las probabilidades de que la base de datos se mantenga en línea durante un fallo de este tipo dispersando los nodos del clúster huésped a través de múltiples nodos dentro del clúster de hipervisor.
- Los datos en sí. Los nodos dentro de un clúster de base de datos de conmutación por error rara vez almacenan los datos en sí mismos. Los nodos del clúster están vinculados, por lo general, a un volumen compartido de clúster, y usted debe decidir qué hacer con los datos. Dependiendo de dónde se encuentran los datos, es posible que pueda dejarlos en su ubicación original, pero debe evaluar cualquier limitación específica del hipervisor. Por ejemplo, es probable que experimente problemas de respaldo en un entorno Hyper-V si intenta conectar los nodos del clúster invitado a un repositorio de almacenamiento tratando el almacenamiento como un disco de paso SCSI. Las asignaciones de almacenamiento deben ser manejadas desde el interior del sistema operativo invitado.
¿Cómo la estrategia de migración de datos afectará la contención de recursos?
Se puede pensar en la contención de recursos como competencia entre las máquinas virtuales (VM) por los recursos de hardware. Todo el concepto de virtualización de servidores se basa en la contención de recursos. La idea es que el hardware del servidor se ha vuelto lo suficientemente potente como para ejecutar múltiples cargas de trabajo simultáneas. Sin embargo, los recursos de hardware disponibles (CPU, memoria y almacenamiento) deben ser compartidos entre las VM que hacen uso del hardware.
Los servidores de base tienden a consumir más recursos de hardware que otros tipos de VM. Esto es especialmente cierto cuando se trata de IOPS de almacenamiento y capacidad de almacenamiento, por lo que debe planificar esto.
Un error que se comete a menudo en entornos de servidores virtuales es colocar todas las máquinas virtuales y sus datos en un volumen compartido de clúster individual. Los proveedores de hipervisores recomiendan encarecidamente el uso de un volumen compartido de clúster, pero no hay ninguna regla que establece que usted debe limitar su infraestructura de virtualización a un solo volumen compartido de clúster. Generalmente, usted puede mejorar el rendimiento usando múltiples volúmenes compartidos de clúster.
En el caso de una aplicación de base de datos virtualizada, usted podría considerar la distribución de los nodos del clúster de invitados a través de tantos volúmenes compartidos de clúster como tenga disponibles. De esta forma, un error de volumen compartido de clúster (físico o lógico) será menos probable que resulte en un fallo que si todos los nodos del clúster invitado comparten un volumen compartido de clúster común.
Los propios datos se deben colocar en un dispositivo de almacenamientofísico completamente separado, configurado para actuar como un volumen compartido de clúster para el clúster invitado, pero no para el clúster host. De esta manera, usted no tiene que preocuparse por VM no relacionadas generando solicitudes de IOPS que interfieren con el rendimiento de la base de datos. Del mismo modo, aislar los datos a un dispositivo de almacenamiento dedicado elimina la posibilidad de que un fallo de volumen compartido de clúster a nivel de hipervisor tenga impacto en los datos.
En última instancia, usted tendrá que basar su estrategia de migración de datos alrededor de su hipervisor y del hardware en su centro de datos. Tanto si utiliza VMware, Hyper-V o alguna otra cosa, cada hipervisor tiene sus propios matices que afectarán la migración de datos. VM
