Archivo de la etiqueta: migración

Migrando de Azure Classic (ASM) a Azure Resource Manager (ARM)

Aunque esta publicación la materializa servidor, he de comentar que es un trabajo del equipo completo de Enterprise IT de Plain Concepts, donde todos y cada uno de nosotros estuvimos involucrados con las distintas tareas que voy a comentar aquí.

Llevamos ya unos cuántos meses contándoos la potencia y enormes ventajas del nuevo modelo de recursos de Azure, que cambia nuestra forma de entender y trabajar con la plataforma… y lo hace para muy bien. Sin embargo, hacemos una confesión pública en estas líneas: el core de la infraestructura de Plain Concepts aún se encontraba en el modelo clásico. Y es que aunque seguimos totalmente un modelo customer first, lo coherente es predicar con el ejemplo, mas sea dicho que estábamos ansiosos de disponer de todas las ventajas de ARM en nuestro entorno productivo.

No queriendo dilatar más la situación planificamos la migración de toda la infraestructura. ¿Cómo procedimos a ello? Es justamente lo que os voy a contar en esta publicación.

¿Qué servicios necesitan migrarse?

Los servicios sobre los que vamos a tener que trabajar son sobre todo los basados en IaaS y todos los que de alguna manera estén relacionados con los mismos. A continuación os voy a enumerar los más importantes:

  • Storage Accounts.
  • Virtual Machines.
  • Virtual Networks, incluyendo gateways, network security groups, reservas de direcciones IP, etc…
  • Cloud Services. Cuidado aquí, porque si estáis utilizando máquinas virtuales auto-escaladas debéis pasar a utilizar los Azure VM Scale-Sets, que quedan fuera del ámbito de este artículo.
  • Traffic Manager.
  • Backup.

La mayor parte de los servicios basados en PaaS no necesitan atención alguna, ya que automáticamente pasan a beneficiarse del modelo ARM. Entre estos servicios encontramos App Service o SQL Database.

También es interesante mencionar servicios que de momento sólo funcionan en el modo clásico, como StorSimple o Azure Site Recovery.

Estrategias de migración

Muchos ya habréis adivinado lo que voy a comentar a continuación: no hay un botón mágico ni una forma automatizada de mover servicios entre ASM (modo clásico) y ARM. Por tanto, cuando afrontamos un movimiento implica crear de nuevo el servicio en ARM y mover toda la información en un proceso bastante manual.

Hay dos formas de afrontar la migración:

  • Utilizar los scripts de PowerShell de FullScale180 que Microsoft menciona en su documentación oficial. Estos se encuentran en un repositorio de GitHub, justamente aquí.
  • Preparar nosotros mismos un proceso adaptado a las necesidades del entorno.

Después de examinar los scripts y reconocer el enorme trabajo que se llevó a cabo con los mismos, decidimos que era mejor optar por llevar a cabo el proceso de forma manual, fundamentalmente motivados por tener un mayor control.  Los scripts migran una única máquina virtual por ejecución y realizan una serie de asunciones sobre las redes virtuales, los network security groups y los discos que preferíamos tener más controlados. ¡No obstante no dejes de echarles un vistazo por si se adaptan a tus necesidades y te ahorran mucho trabajo!

Para nuestra migración nos marcamos una serie de requisitos:

  • Copiar el entorno 1:1, es decir un clon idéntico del que tenemos en ASM. Esto implica que no vamos a redesplegar y reconfigurar servicios.
  • Como consecuencia del punto anterior, debe mantener el mismo direccionamiento IP y subredes que ya teníamos definidas en la red virtual de ASM.
  • Como no podía ser de otra forma, también debemos tener una configuración similar en la puerta de enlace VPN que creemos en el servicio.

Estos requisitos nos llevan a una estrategia de irremediable corte de servicio, planificado a una hora fuera de oficina. Con otro tipo de requisitos podríamos hacer el movimiento sin prácticamente ningún corte. Y con estos puntos en mente ya podíamos elaborar nuestro backlog particular.

El backlog

Que a alto nivel consistía en lo siguiente:

  1. Asegurarnos de que tenemos acceso administrativo a Azure y Office 365 sin necesidad de ADFS. Dado que nuestros ADFS se encuentran en Azure y ASM, siendo parte de la infraestructura que vamos a migrar, sería muy divertido apagarlos y que se nos cierre o caduque la sesión que tenemos abierta.
  2. Crear el o los grupos de recursos de ARM donde vamos a alojar todos los nuevos elementos de nuestra infraestructura.
  3. Crear las Storage Account necesarias en ARM, tanto las estándar como las premium.
  4. Crear la red virtual en ARM y configurarle el direccionamiento análogo al que ya teníamos en ASM.
  5. Realizar el corte de servicio fuera de oficina y comenzar con la intervención oficial.
  6. Copiar todos los VHDs de las máquinas virtuales existentes de las Storage Account ASM a ARM.
  7. Crear en ARM las máquinas virtuales utilizando los discos que hemos copiado en el paso 6.
  8. Crear los balanceadores de carga internos y externos.
  9. Restablecer las conexiones Site to Site con las distintas localizaciones on-premises de Plain Concepts.
  10. Realizar los cambios DNS oportunos.
  11. Comprobar el funcionamiento del entorno.

Copiando VHDs entre ASM y ARM

La primera tarea es una de las más triviales, pero quizás la que más dolor de cabeza nos dio. Consiste en copiar los VHDs de las máquinas virtuales de una Storage Account basada en ASM a otra que lo esté en ARM. Ambas cuentas de almacenamiento operan de forma indistinta y por tanto se utilizan igual. La herramienta altamente recomendada para esta tarea es AzCopy, que realiza una copia asíncrona entre las cuentas sin necesidad de descargárnosla a nuestra máquina. Su sintaxis es extremadamente simple:

¿Qué nos dio dolor de cabeza? Que la copia fue más lenta de lo que habíamos estimado originalmente, cosa que no nos ocurrió con todas nuestras Storage Account. Es posible, que tal y como advierte TheCodeJunkie es este post, estuviéramos trabajando sobre una Storage Account muy antigua que no tenía ciertas capacidades, pero es un tema en el que no entramos en profundidad. Nos tocó ser pacientes sin más.

Como detalle recordad que copiamos discos y no plantillas de máquinas virtuales. No se trata de imágenes con sysprep aplicado.

Creando máquinas virtuales con nuestro disco como disco del sistema

Cuando ya tenemos nuestros discos en la Storage Account ARM, podemos proceder a crear las máquinas virtuales. Sin embargo, lo primero con lo que nos encontramos es que a día de hoy no hay ninguna opción en el portal para crear una máquina virtual ARM utilizando un disco existente en lugar de las plantillas de la galería. Afortunadamente, la capacidad sí que se encuentra ahí y podemos utilizarla, sólo que para ello tendremos que utilizar una plantilla JSON.

Si vamos al repositorio GitHub de la Azure Quickstart Templates, encontraremos una que nos llama mucho la atención: 101-vm-from-user-image. ¡Justo lo que necesitamos! Si examinamos la plantilla veremos que promete, pero que se nos queda corta para nuestras necesidades debido a que:

  • Está preparada para crear una máquina virtual desde una imagen con sysprep a modo de plantilla, no una VM ya existente.
  • Crea una red virtual por cada máquina que creemos.
  • No especifica dirección IP privada para la máquina.
  • No especifica Storage Account para los diagnósticos.
  • No especifica grupo de disponibilidad.
  • Los nombres de los recursos no se adaptan a nuestra nomeclatura.

¡Pero esto no es ningún problema! La plantilla nos da un estupendo punto de partida para modificarla y adaptarla a nuestras necesidades, que tras pasar por nuestro particular taller quedó así:

ATENCIÓN: Esta plantilla está preparada para máquinas de un solo disco (el del sistema). Necesita una ligera adaptación muy trivial para máquinas donde se usa más de un disco para que estos se desplieguen junto con el resto. ¿Y no nos valdría esta plantilla y ya adjuntamos el resto de discos después? La respuesta es NO. La razón es que al introducir la plantilla en Azure y ejecutarla, este aprovisiona la VM y la arranca. Si al arrancar el sistema no encuentra las unidades donde espera encontrar datos –como por ejemplo, las bases de datos de un controlador de dominio-, la máquina se puede volver inconsistente, pudiendo llegar a perderla.

Aplicando plantillas JSON en Azure

Nada más sencillo que acudir al portal y buscar el elemento Template deployment.

image

Tras lo cual copiamos y pegamos nuestra plantilla en el editor de texto:

image

Tras guardar la plantilla, Azure comprobará que la sintaxis JSON es correcta y en caso afirmativo, nos permitirá pasar a los parámetros. Que quedan tal y como hemos definido:

image

Y tras ello Azure comenzará con el trabajo de implementación de la máquina. Como comentamos en otra ocasión, la potencia de ARM nos permitirá guardar la plantilla que generamos para futuros usos. Es importante reseñar que pueden producirse errores de ejecución en la plantilla, que solo veremos al aplicarla (ej: nombres de recursos que ya se encuentran en uso). Si tenemos el infortunio de caer en esta situación, no tendremos más remedio que eliminar manualmente los elementos creados (o bien el grupo de recursos si trabajábamos de nuevas con él) y comenzar de nuevo.

Conclusiones

Mover infraestructura de ASM a ARM no es a día de hoy un trabajo automático y requiere de un extenso análisis y elaboración de estrategia en función del tamaño y la criticidad del entorno. Las ventajas del movimiento a ARM son evidentes y hacen que en la mayoría de los casos compense el esfuerzo. Por otro lado y desde el punto de vista de seguridad, dado que nunca eliminamos en el entorno original de ASM, siempre existe la posibilidad de hacer rollback si las cosas llegasen a ponerse muy feas durante el proceso.

¿Te ha resultado interesante? ¡Déjanos un comentario si nos quieres decir algo!

Happy ARMing!

Migración de correo con Imapsync

Anteriormente, he hablado acerca de cómo migrar buzones  de correo a Office 365 utilizando las herramientas que esta plataforma nos otorgaba.  Por supuesto, mencioné que  existía más software que  nos permitían realizar migraciones IMAP.  En este artículo,  centrándome en dicho punto, hablaré de  imapsync una aplicación que  permite migrar buzones a distintas plataformas (incluyendo Office365) de forma diferente a las metodologías ya habladas.

¿Que ventajas  nos proporciona imapsync frente a otras herramientas ?

  • Es sencilla.  Tan sólo es necesario ejecutar un único comando para poder realizar una migración de un buzón de una plataforma a otra.
  • Permite el acceso administrativo. Útil en los casos en los que se requiera que  el administrador   sea el que realice el movimiento de buzones y no conozca las contraseñas de los usuarios para poder acceder a sus cuentas.
  • Permite migrar grandes lotes de buzones.
  • Soporta múltiples plataformas de correo como  Dovecot, Cyrus, Yahoo, Google Apps, Office 365 , etc.
  • Se puede instalar en diferentes sistemas operativos como en Mac OS X, Windows o Linux (con Perl previamente instalado).

¿Qué desventaja tiene?

  • Es una aplicación de pago, con lo que tendríamos un gasto extra frente a las herramientas de migración de Office 365 pese a que su precio no es tan caro como si lo comparamos con software similar.

Conocidas las capacidades y los defectos de la aplicación, podemos observar que la herramienta nos es muy útil cuando no deseamos que el usuario intervenga en la migración y  debemos migrar una cantidad significativa de buzones a Office 365 , pese a que ello suponga un gasto extra. Tan sólo nos quedaría la duda de cómo realizaríamos la migración con imapsync .

Como ya se ha dicho, no es una operación compleja  y requiere de un único comando para poder mover un buzón de una plataforma a otra.  Advertir que  los ejemplos que detallaré a continuación se han hecho desde una máquina con un sistema operativo basado en Unix,  existiendo pequeñas diferencias para los usuarios que utilicen la herramienta en Windows.  No se procederá a explicar todas y cada una de las opciones, por lo que se sugiere consultarlas dependiendo de cómo se desea realizar la migración de buzones.

Si se desea  mover un buzón  de una plataforma a otra basta con ejecutar el siguiente comando indicando la información de la plataforma de origen  y destino del buzón (el host IMAP y la información de logado de la cuenta correspondientes) :

Si  no se conoce la información de los usuarios, siempre podemos utilizar el acceso administrativo, permitiéndonos realizar el movimiento sin necesidad de conocer la contraseña del usuario propietario (previamente, deberemos haber otorgado permisos de acceso al administrador a los buzones que queramos migrar, tanto en origen como destino) :

A diferencia, del fragmento de código anterior, se aprecia que  en vez de indicar la contraseña de los usuarios, se indica el identificador de login del administrador y su correspondiente contraseña.

Vistas las dos formas básicas de mover un buzón,  es fácil intuir cómo resultaría la migración de múltiples lotes. De hecho el propio creador,  sugiere realizarlo mediante un sencillo script que a partir de un fichero de texto ir leyendo los datos necesarios  e ir ejecutando el comando por cada buzón a mover :

Una vez hemos comprobado la sencillez del proceso, es inevitable hacernos preguntarnos qué hubiese pasado, si en vez de utilizar el servicio de cuentas conectadas de Office 365 hubiéramos utilizado imapsync.

Como recordaréis, cuando se escribió el artículo, Google Apps no permitía el acceso administrativo, con lo que no hubiese sido factible el emplear dicha herramienta. Sin embargo,  actualmente y gracias al uso de XOAUTH para acceder a las cuentas de los usuarios de dicha plataforma, la aplicación puede  mover el buzón a Office 365 sin problema alguno. Previamente  configurado dicho mecanismo, ejecutaríamos imapsync con las siguientes opciones :

Analizando el código,  se puede ver cómo para la información de la cuenta de Google Apps,  se indica que, mediante la opción authmech1,   se va a utilizar XOAUTH como método de autenticación.  Además,  mediante las opciones ssl1 y ssl2 se indica  que se emplearán una conexión ssl para conectarse a los host y mover el correo de forma segura.

En conclusión, con imapsync se tardaría menos tiempo en ejecutar el proceso de migración, pero requeriría una preparación previa por parte del administrador para que esta migración sea efectiva. Queda en manos de los lectores, elegir el mejor mecanismo que mejor se adapta a sus propósitos a la hora de mover los buzones desde cualquier plataforma de correo a Office 365.

Cómo migrar CORREO de Google Apps Gmail a Office 365

 

Una de las muchas tareas que se realizan al cambiar de Google Apps  a  Office 365 es la migración de correo.  Esto es una buena idea si planteas dejar de utilizar tu vieja cuenta y centrarte en la nueva . De esta forma, es posible tener todo tu correo en un único sitio.

image

Por supuesto, existen múltiples formas de mover tus buzón de correo. Podemos contar con las herramientas propias de Office 365 , utilizar aplicaciones de  terceros que realizan migraciones IMAP o software diseñado para servicios de migración de la nube (si quisiéramos migrar nuestros contactos o el calendario) .

Aparte de lo ofrecido, Office 365 da  a cada usuario la posibilidad de conectar su cuenta de Gmail a su cuenta de Exchange Online desde OWA. Pero,  ¿qué ventajas nos ofrece este método frente a  las otras herramientas mencionadas?

  • Es fácil y rápido. El proceso se puede hacer en cuestión de pocos minutos.
  • No es necesario el acceso administrativo.  Es el usuario quien hace todo el proceso librando carga de trabajo al administrador.
  • Coste cero frente al pago por obtener herramientas de terceros.

Estas ventajas son muy útiles si queremos migrar nuestra correo de Google Apps a Office 365,  dado que el servicio de Google no ofrece acceso administrativo para este tipo de migraciones y la única forma es resetear la contraseñas de todas las cuentas a una clave común tal y como indica Microsoft aquí.

Entonces, ¿cómo puedo  conectar mi cuenta de correo de Google Apps a la de Office 365 para migrar todos mis mensajes?

Antes de iniciar la conexión hay que tener en cuenta lo siguiente :

  1. Debes habilitar el acceso POP en tu cuenta de Google Apps  ya que es el  único acceso soportado si queremos conectar la cuenta de este servicio.
  2. Cuando agreguéis la cuenta de Gmail como cuenta conectada, todo mensaje proveniente será almacenado en la carpeta de Bandeja de Entrada , incluyendo los mensajes enviados. Esto sucede por que Google usa etiquetas para clasificar los mensajes y no carpetas como en Exchange Online.  Es recomendable crear alguna regla que os permita reordenar todo el correo que vais a descargar si queréis que quede almacenado en las carpetas que tengáis.
  3. Sólo puedes conectar hasta cinco cuentas adicionales en Office 365. Con lo que una vez completado el proceso de migración , es recomendable eliminar la conexión si el número de cuentas a migrar supera el límite establecido.

Dicho esto,  para agregar la cuenta de correo de Google Apps como cuenta conectada, basta con acceder mediante OWA a nuestro buzón de Office 365.  Desde ahí, deberemos desplegar el menú de configuración y seleccionar el apartado de Opciones. Dentro de la sección de Cuentas , seleccionamos Cuentas Conectadas.

image

En la página de Cuentas Conectadas, agregamos (haciendo click en el símbolo ‘+’) la cuenta de correo que deseamos conectar e indicamos sus credenciales.

image

No os preocupéis si Office 365 os muestra un mensaje avisando  que no es posible establecer una conexión segura.  Aunque Google no reúne los requisitos de Microsoft para establecer una conexión automática de forma segura, se nos dará la posibilidad de utilizar un asistente de configuración para establecer la conexión de forma manual.

image

Al inicio del asistente,  deberemos indicar que la conexión será POP por los motivos que ya hablábamos al principio del artículo.

image

En el siguiente paso,  rellenamos la información de nuestra cuenta con los siguientes datos para que Office 365 pueda acceder a la cuenta a conectar y descargar el correo :

    • Nombre :  el nombre que queremos que se asigne a la cuenta a conectar.
    • Dirección de correo electrónico :  nuestra dirección de correo de Gmail
    • Nombre de Usuario :  el usuario con el que accedemos a nuestra cuenta.
    • Contraseña : la clave con la que nos logamos para acceder al buzón de correo de Gmail.
    • Servidor entrante : pop.gmail.com
    • Tipo de autenticación : Básica
    • Cifrado : SSL

image

Introducidos  dichos datos, el asistente empezará a importar correo a nuestro buzón de Office 365. Podremos seguir el estado del proceso de migración en la página principal de  Cuentas Conectadas. Una vez finalizado,  (el estado de la conexión mostrará el mensaje   ACEPTAR  u OK)  todo el correo descargado podrá ser consultado en nuestro buzón.

image

image

¡Feliz Migración!