DEMO: De VMware a AWS. Administración de ambientes dentro de la consola de AWS.

Gracias por conectarse el día de hoy. Y pues esta es nuestra segunda parte de la serie de webinars sobre migración de cargas de VMware hacia AWS. Pues la sesión pasada que tuvimos el 10 de octubre fue nuestra sesión comercial acerca sobre la migración de AWS y hoy nos enfocaremos precisamente en la parte técnica y cómo vamos a hacer y lograr esta modernización, este proceso de esa migración de manera efectiva. Muy bien, les platico que esta sesión será grabada precisamente para que ustedes puedan consultar el material, después lo transmitiremos en nuestro canal de YouTube y igual lo pueden consultar a través del link que les vamos a estar mandando con el correo de registro que ustedes se registraron para este Architecture Championship, además de que les mandaremos el material de la sesión y esto con el objetivo de que ustedes puedan volver a tener acceso a la información y la puedan compartir a través de redes sociales. Muy bien, pues damos inicio. El día de hoy nos acompaña el ingeniero Marco Chávez, Solutions Architect de parte de CompuCloud y de parte de Ingram, el ingeniero Edgar González, también Solutions Architect y la ingeniera Ilse Guerrero. Les platico, ellos su principal enfoque tanto en CompuCloud como en Ingram, es que son consultores especializados en la nube de AWS y brindan un asesoramiento técnico y estratégico en cada etapa del proceso que los clientes o las empresas buscan al migrar a la nube. Les platico brevemente quién es CompuCloud, tal vez algunos ya nos conocen, otros no. CompuCloud es un partner Advanced de AWS y nosotros tenemos esta certificación Advanced precisamente en cuanto al objetivo que es brindarles este nivel o conocimiento a las empresas de acuerdo a la nube de AWS. Y pues actualmente tenemos presencia desde el 2012 en México y Centroamérica y actualmente en otros países del extranjero. Somos un partner 100 % enfocado en la nube de AWS y somos especialistas en cuanto al diseño, modernización de arquitecturas, clubes, planeación y migración e implementación, administración, seguridad y monitoreo continuo de la infraestructura en la nube de AWS. Les platico también que Todo el equipo CompuCloud cuenta con estas certificaciones y reconocimientos que avalan el expertise que tenemos en cuanto a todos los servicios de AWS y también que los ingenieros que nos acompañaron el día de hoy cuentan con estas certificaciones. El ingeniero Marco Chávez que nos platicará un poco más sobre la preparación y configuración del entorno.

Muchas gracias Andrea. ¿Qué tal? Buen día a todos y bienvenidos y muchas gracias por participar en este architecture de migración de VMware hacia AWS. Justamente uno de los puntos claves es todo el tema de la preparación y configuración de nuestro entorno, por lo que me gustaría prácticamente mencionarles a grandes rasgos cuáles son esos pasos iniciales que son recomendados que hagamos. Justamente en la siguiente presentación podemos visualizar estos puntos que son esenciales, básicos para poder realizar una migración lo más eficiente posible. Empezando por el tema de hacer un inventario técnico, prácticamente hacer un chequeo de todas las aplicaciones que tengamos, las tecnologías que utilizamos, cómo se mueven los datos en nuestra arquitectura y más que nada las metas que tenemos en nuestro negocio. Esto más que nada nos ayudará mucho para ver cosas buenas, cosas malas que puedan venir con la migración y más que nada poder identificar las herramientas que podemos requerir para hacerlo de una manera más sencilla y automática. Posteriormente tenemos todo lo que es la planificación de la migración, que prácticamente consiste en imaginar cómo queremos nuestra arquitectura, cómo que queremos que quede al final, más que nada para poder encontrar posibles problemas técnicos que pueda haber entre el sistema actual que manejemos y en caso de que lo llevemos ya a la nube, más que nada pensar en todo, todas las dependencias que tiene, desde temas técnicos, temas de seguridad, por ejemplo temas de conectividad, si anteriormente teníamos por ejemplo una VPN side to site, hacer también esa integración a nivel de la migración y posteriormente también de cajón hacer pruebas del ambiente, justamente crear un ambiente de pruebas para que el equipo pueda ir practicando antes de hacer la migración final. Prácticamente esto nos ayuda bastante con lo que es la preparación para poder resolver retos, para que nos den confianza al equipo, para que todo va a salir de manera ágil, más que nada para ver en esas pruebas los resultados que hubo, a lo mejor X aplicativo hubo que customizarlo, etc. Entonces más que nada para asegurarnos de que todo esté perfecto y también que validar que los datos que hayamos o que estemos pasando se encuentren orden. Y digo ya casi uno de los puntos finales es ejecutar la migración, prácticamente ya que tengamos todo listo, mover las cargas de trabajo, más que nada el hecho de moverlos a cloud, pues si es algo más estable para que sean servicios que tengan alta disponibilidad, eso sí, pues hay que avisar a todos cuando hagamos esa migración de que vamos a mover los sistemas hacia cloud. Y finalmente tenemos también una de las fases más importantes que es la supervisión, ya ahora sí que tengo todo mi ambiente migrado, pues prácticamente ir revisando métricas, ir revisando costos, que todo se encuentre de manera funcional y más que nada si de repente nos reportan alguna falla o hay algo que optimizar, pues que prácticamente el equipo lo conozca. Y digo posteriormente tenemos un punto también muy importante para ver a grandes rasgos las diferentes estrategias de migraciones que podemos escoger. Entonces en un momento les presentaré justamente cuáles son estas diferentes estrategias que podemos manejar hacia la migración, que de hecho justamente las voy a ir mencionando de manera superior e inferior. Prácticamente como les comentaba hace un minuto, el tema de la planificación es el momento en donde nosotros prácticamente tenemos que escoger una de estas estrategias para migrar, de hecho estas estrategias también las podemos conocer como las R, ya que todas empiezan con R, entonces es muy famosa todas estas estrategias que igual prácticamente una de las opciones o migraciones, digo que como tal no es migración pero nos ayuda a lo mejor con ciertos aplicativos, es el tema del retener, prácticamente son para aplicaciones que realmente están muy legadas y que es muy difícil migrar hacia la nube, a lo mejor Windows Server 2003 que tienen muchas dependencias a nivel de sistema operativo, es a lo mejor algo muy complejo o a lo mejor también temas de gobierno que hay que tener los datos en sitio, pues es algo de gobierno que no nos deja hacer migración. Otro esquema de migración es el de rehost o también conocido como Leaf and Chief, que justamente es la que vamos a platicar y vamos a presentar una demo de esta migración porque realmente es de las más sencillas, de las más eficientes y de las más costo efectivas, que prácticamente este tema del Leaf and Shift o de rehospedaje prácticamente es una migración porque prácticamente consiste en llevar todo como lo tengo, no hay que modificar casi nada y prácticamente es como una copia de todos los servidores que tengamos en físico o virtualizados. Otra estrategia que existe es el tema del replatform o de cambio de plataforma, que es muy similar al INF, pero prácticamente sí requiere cambios a nivel del aplicativo el caso muy común también que de repente llegamos a hacer es de que OK tengo una aplicación que tiene base de datos, entonces a lo mejor la base de datos en vez de migrarla a un servidor virtual directamente mejor la muevo a un servicio administrado como lo puede ser RDS o Aurora, ya tenemos que preocupar prácticamente por ese servidor físico virtual porque todo es administrado. También hay otro tema que es el de recomprar, prácticamente cambiar una aplicación que ya tenemos en uso y hacer una compra más bien a una aplicación muy parecida a lo que pueda ser un SASE para que tengamos todo ese tema de bondad de nube Y también digo que muy seguramente sean de las más complejas que es la de la rearquitectar o refactorizar también conocida. Prácticamente este tipo de migración la verdad es que son más retadoras, involucran más esfuerzo porque prácticamente hay que hacer la aplicación más orientada a una arquitectura de nube, manejar servicios para desacoplar de mensajería, temas de almacenamiento, etcétera y finalmente tenemos el tema de retirar ya cuando una aplicación a lo mejor ya es extremadamente legacy y que a lo mejor inclusive no vemos que esa aplicación se mantenga posteriormente Como les mencionaba prácticamente este tipo de estrategia como lo es la de rehost o de lease and shift es en la que nos centraremos porque es una de las que prácticamente es más fácil de llevar por allí prácticamente vemos igual a grandes rasgos cómo se lleva una migración de este tipo que prácticamente ya lo mencionaba en la primera fase, prácticamente tenemos que descubrir o analizar cuáles son esos recursos a nivel de servidor, a lo mejor cuánta RAM tienen, cuántos CPU tienen, ver qué aplicaciones están en esos servidores, qué dependencias tengo y ya una vez que digo OK vamos a hacer a lo mejor un leaf and shift prácticamente para re hostearlo yo puedo hacer dos cosas prácticamente que también son muy viables y muy limpias que son las de las instalaciones manuales. Por mencionar también algunos de los casos que nos toca hacer migraciones, a lo mejor el cliente quiere migrarse a cloud y quiere empezar a utilizar su compact, entonces a lo mejor en vez de traernos su servidor, no sé, Windows 2008, migrarlo con la herramienta, a lo mejor hacemos un levantamiento nativo y empezamos a configurar o más que nada el cliente, el proveedor empiezan a configurar todas las aplicaciones desde cero y tenemos una instalación limpia. También este tipo de configuraciones son conocidas como leaf and shift porque prácticamente es levantar nuestro aplicativo en esta nueva infraestructura o bien podemos automatizarlo justamente con alguna de las herramientas que nos provee AWS que prácticamente pudiera ser para a lo mejor si tengo algunas aplicaciones ya instaladas, tengo algún desarrollo in house, etc. Y es más viable que yo haga prácticamente ese clon de mi instancia, entonces mejor lo automatizamos con un agente que se encarga de copiar todos los datos del servidor para justamente llevarlos hacia la nube, hacia AWS. Ya una vez que se hace la instalación del agente y empieza a replicar, pasa la fase de pruebas, ya hicimos la instalación de la gente, estamos la copia total del servidor que vamos a migrar, sigue la fase justamente de hacer pruebas, terminar de validar, OK, tu aplicativo a lo mejor ocupa temas de licenciamiento, ocupa hacer alguna configuración en algún archivo, etc. Entonces por eso es muy indispensable hacer el tema de las pruebas también ver, ah OK, este aplicativo lo consumen desde on premise, VPN, side to site, pero también hay clientes o usuarios finales que se conectan desde su hogar, hacen home office y hay necesidad de hacer más integraciones de red. Entonces justamente para eso es todo el tema de las pruebas, para finalmente ya una vez que todo el equipo haya validado todo, se hace ese tema de la transición, el famoso cutover para que prácticamente, ya sabes qué mencionamos el caso del compact, a lo mejor informar a contabilidad, capacitarlos para que, oye, ya no te vas a conectar desde esta manera, lo vas a hacer de esta manera, vas a utilizar esto y desde el día primero de noviembre vamos a hacer ese movimiento para que se empiece a hacer todo eso. Y ya una vez que hacemos el cudover, ya pasa a ser la carga de producción, a salir todo el tema de la supervisión, ver que toda la carga de métricas se encuentre funcionando de la mejor manera. Ya también para finalizar todo este tema de la preparación y la configuración del retorno, por allí vemos a grandes rasgos una arquitectura del servicio de AWS, Application Migration Service, también conocido como MGN, el cual es esta herramienta que nos permite hacer la copia de nuestro servidor físico o virtual para poderlo llevarlo a la nube. Entonces prácticamente hacemos la instalación de la gente, como les mencionaba, tenemos una área en donde se están sincronizando los datos y donde podemos también lanzar las pruebas para finalmente hacer el tema del switch ya una vez que se hayan realizado todas las pruebas. Justamente por allí el ingeniero Edgar nos trae justamente una demo de cómo es todo este proceso de esta migración hacia AWS, todo este camino y pues igual por allí un gusto presentar toda esta información, igual por allí les cedo los micrófonos al ingeniero Edgar.

Listo, muy bien, ¿Qué tal? ¿Cómo están? Aquí Edgar González. En esta ocasión les voy a presentar una demo de cómo migrar un servidor VMware hacia AWS. En esta ocasión por efectos de practicidad y tiempos voy a estar simulando esta migración haciendo uso de un servidor s, de una instancia s, donde voy a estar migrando hacia otra región e igual por efectos de. De practicidad, cada etapa de la migración la he dividido en diferentes regiones, es decir, la parte de la gente la vamos a ver en una región, la parte del test en otra región y la parte del cotover en otra región. ¿Por qué? Porque ya están preparados sus ambientes por efectos de tiempo y vamos comenzando, aquí el objetivo es migrar un servidor hacia la región de Virginia, es decir, vamos a migrar un servidor VMware on premise hacia Virginia. Como comenté, reitero, me voy a estar apoyando de diferentes regiones en las que ya tengo etapas o stages de la migración ya listas para demostración. Muy bien, aquí me encuentro en. Aquí tengo ya mi servidor, mi servidor on premise, que es una instancia s. Muy bien, lo que vamos a hacer ahora es instalar el agente de replicación, el Application Migration Service Agente. Muy bien, lo que vamos a hacer primero es ingresar a mi servidor premise, vamos a conectarnos, esta es la llave, Listo, aquí ya tengo mi contraseña de mi servidor on premise. Aquí es importante guardar esta contraseña porque como es una migración vamos a ingresar con los mismos accesos, entonces es importante guardar la contraseña y no perderla para poder acceder a este servidor una vez migrado a AWS. Muy bien, tengo mi Remote Desktop, vamos a conectarnos, la contraseña yes y nos conectamos y ya me estoy conectando a mi servidor de VMware. En lo que se carga, vamos a pasarnos a el servicio de Application Migration Service, Lógicamente vamos a estar haciendo este movimiento ya en la región donde vamos a montar nuestro servidor. Aquí estoy en el servicio de Application Migration Service, si me voy aquí al menú de la izquierda, nos vamos a ir a Source Servers perfecto, aquí lo primero que me va a pedir es un rol de un rol o un usuario con permisos para migrar permisos de administración de esta gente, entonces hay que crear previamente este usuario, vamos a poner Setup Service para que me deje entrar y listo, vamos a crear este usuario, voy a abrir otra pestaña, me voy al servicio de IAM, yo ya tengo creado este usuario user AMS, este ya cuenta con esta política que se llama AWS Application Migration Agent Installation Policy va a ser necesario crear un usuario con esta política para que nos deje para darle permisos a la gente de estar replicando la información ¿Cómo creamos este usuario? Igual si gustan vamos a hacer rápido este ejercicio, nos vamos a crear usuario, podemos ponerle agente de replicación por ejemplo Application Migration Service, no vamos a proveerle acceso a la consola, no es necesario Next Y ahora vamos a tacharle la política, en este caso es Installation Policy, es esta que me sale aquí la primera, la seleccionamos, next y creamos el usuario muy bien, una vez creado el usuario vamos a ingresar a este, nos vamos a Security Credentials, bajamos un poquito y nos vamos a Access Key, vamos a crear un Access key para que nos dé una llave de acceso y una contraseña para poder asignarles este usuario a nuestro agente muy bien, aquí vamos a seleccionar una de estas opciones, yo recomiendo seleccionar esta Command line Interface Orbian Other Next vamos poner una descripción, Access Case Agent por ejemplo y listo, aquí ya tengo el usuario, el Access key y el Secret Access Key, vamos a descargarlo porque lo vamos a requerir perfecto, entonces aquí yo ya creé este usuario, ya podemos cerrar esta ventana y regresamos al servicio de Application Migration Service vamos a agregar un servidor de origen, ya estamos aquí en Application Migration Service, en Source Servers y agregamos servidor muy bien, lo primero que tenemos que hacer es seleccionar el sistema operativo, en este caso va a ser un Windows ¿Qué discos vamos a replicar? En este caso vamos a replicar todos los discos que tenemos atachados a ese servidor y aquí vamos a ingresar el Access key y el Secret Access key que acabamos de generar, vamos a ver, me voy a descargas, prolexilitos Copy of his key Secret access movie lo podemos dejar en blanco sin ningún tema y ahora lo que vamos a hacer es descargar el instalador, lo descargamos, tenemos acá descargado y nos lo vamos a llevar a nuestro servidor. Aquí ya está descargado, lo voy a copiar y lo voy a pegar en mi servidor de origen. Ya cargó, ya estoy en mi servidor y vamos a pegar el agente. Muy bien, ya tenemos aquí la gente, voy a quitarle ese número que tiene al final. Muy bien, regresamos al servicio de Application Migration Service y vamos a copiar este comando que está aquí abajo. Este comando nos va a permitir hacer la instalación de la gente y si se fijan ya incluye el access key ID y el secret access key, ya te los pone ahí por perfumes. Vamos a copiar este comandito copy y regresamos a nuestro servidor de origen. Aquí vamos a abrir cmd y vamos a correr nuestro comando. Bueno, en este caso, como mi agente está en el escritorio, lo primero que tengo que hacer es dirigirme al escritorio. Entonces vamos a poner cuad Y listo, ya estoy en mi escritorio, ya me sale akit, mi agente de replicación. Ahora sí voy a pegar el comando y se va a estar instalando nuestro agente. Esto tarda un par de minutos.

Igual si tienen alguna duda nos las pueden comunicar a través del chat y nosotros nos encargaremos de resolver sus dudas.

Aquí nos está indicando que ya se identificaron los discos, tenemos un disco, en este caso un disco de 30 GB y ahora va a ser la replicación hacia el Migration, Application Migration Service. Un minutito más a que termine de instalarse correctamente. Y listo, aquí ya nos indica que ya tenemos activo un servidor de origen de un total de 150, tenemos una cuota de hasta 150 servidores de origen que podemos tener en nuestro Application Migration Service. Y listo, ya está instalado exitosamente la gente. Listo, ya podemos regresar a nuestra consola de AWS, lo voy a minimizar Y listo, aquí ya me voy a back y ya nos va a aparecer nuestro servidor de origen, ya fue detectado con esta gente, ya el Application Migration Service ya está haciendo su trabajo. Si me meto al servidor de origen, aquí vemos información, status, por ejemplo, aquí se están creando los Security Group, ya se lanzó un servidor de replicación, se está booteando este servidor de replicación. Y estas son las fases o el lifecycle que tenemos de la migración. De momento no está listo, es decir, está aprovisionando el servidor de replicación, se va a estar replicando la información esto puede variar dependiendo de la información que tengamos, en este caso como son 30 gb probablemente no tarde tanto, pero bueno en un caso real donde estamos manejando cientos de gigas, incluso teras, puede tardar incluso hasta días esta parte, entonces pues es importante estar ahí monitoreando cómo va el proceso. Una vez que ya esté lista la replicación podemos ir avanzando las siguientes etapas, por ejemplo tenemos la parte de cuando ya está lista la replicación que ya se terminó, vamos a tener encendido el Ready for Testing, aquí vamos a iniciar un test en donde se va a provisionar ya un servidor de pruebas por así decirlo, o sea con las características que hayamos definido se va a provisionar, vamos a ingresar, vamos a ver que todas las aplicaciones estén corriendo correctamente y listo. Ya que hayamos corroborado que todo está en orden podemos pasar a la siguiente fase en donde nosotros ya estamos listos para el cutover. Obviamente cuando estamos en el cutover listos tenemos que notificar a nuestro cliente, ¿Sabes qué cliente? Ya este servidor ya está listo, vamos a ponernos de acuerdo para hacer este cutover, ¿Por qué? Porque tenemos que apagar el servidor que tenemos abajo, entonces esto ya se hace en conjunto con el cliente. Una vez ya estemos listos para iniciar con el cutover, iniciamos con este y vamos a estar en esta fase de cutover in progress, esto también puede tardar un poco de tiempo dependiendo de la data Y listo, ya una vez se termina este proceso va a estar en cutover complete y ya podemos empezar a trabajar ya en AWS. Ahora, algo bien importante también que tenemos que realizar es que por default la Application Migration Service te va a estar aprovisionando un servidor de acuerdo a las características que detectó en tu servidor on premise. Si nosotros queremos por ejemplo aprovisionar instancias en específico, a lo mejor instancias que si abajo estaba muy sobre aprovisionado y queremos a lo mejor aprovisionar instancias más pequeñas, nosotros tenemos que modificar el template de Launch, el launch template. ¿Por qué? Porque nosotros, el Application Management Services va a trabajar con base a una plantilla en donde nosotros le estamos diciendo tienes que aprovisionarme esta instancia en AWS, Entonces nos vamos acá al menú de Application Migration Service, en Launch.