Día conferencias TIC Unipiloto

viernes, 19 de octubre de 2018


Los invitamos el próximo sábado 20 de Octubre al Día de Conferencias TIC Unipiloto, un evento organizado por la Escuela de Ingenierías TIC, en alianza con Microsoft.

Prográmate para conocer más de estos temas:
  • Cloud
  • Analítica de Datos
Un evento abierto, donde podrás hacer relacionamiento con profesionales del sector Industrial, académico y público, o encontrarse con compañeros y docentes de la universidad y recordar gratos momentos.

Los esperamos e invitamos a visitar la página del evento y hacer tu registro.


Página del Evento
http://diaconferenciastic.webflow.io/



A continuación la presentación usada durante la charla:



Intelligent Cloud: Architect Boot Camp

lunes, 15 de octubre de 2018



He tenido la fortuna de asistir este año al evento Intelligent Cloud Architect Boot Camp llevado a cabo en el campus de Microsoft en Redmond WA.

Fueron 5 días llenos de sesiones muy técnicas (Nivel 400), en el evento la gran mayoria de participantes eran empleados de Microsoft, y un porcentaje muy pequeño de Partners, que era mi caso y el de mis compañeros de trabajo.

El evento fue divido en varios tracks:


En mi caso asistí a todas las sesiones del track de infra, donde se habló de temas como: Containers, Kubernetes, Compute, Storage, Netqorking, Identity, entre otros. No solamente se trataba de sesiones técnicas de Azure, sino que además se realizarón workshops y desafíos muy interesantes, nos unimos a equipos de desarrollo y trabajamos sobre un reto DevOps.

A continuación algunas fotos del evento:





Un saludo para todos!


Configurar Cloud Witness en Failover Cluster

miércoles, 26 de septiembre de 2018


Si tenemos una implementación de Failover Cluster en Windows Server 2016, y cada uno de los nodos tiene salida a Internet, tal vez resulte de utilidad configurar un téstigo de nube (Cloud Witness) en Microsoft Azure. Esto nos habilita distintos escenarios, por ejemplo si tenemos dos centros de datos,  anteriormente utilizábamos un testigo de file share en un tercer sitio, el cual nos servía de testigo y contaba como voto,  en caso de que alguno de los sitios perdiera comunicación aún teníamos quorum al contar con el voto del file share en el tercer sitio, con cloud witness no hay necesidad de contar con un tercer centro de datos, simplemente podemos utilizar almacenamiento blob de Azure como testigo de nube para lograr lo mismo.

Su implementación es bastante sencilla, lo primero que debemos hacer es crear la cuenta de almacenamiento en Azure, para ello vamos al portal, y en el Marketplace seleccionamos  Storage  y luego Storage Account - blob, file, table, queue






Luego, diligenciamos la información para crear la cuenta. A continuación solamente describiré los detalles más importantes a modificar, entre ellos vale la pena resaltar que el tipo de cuenta debe ser de propósito general, y la replicación es suficiente con que tenga redundancia local.

Name: Ponemos el nombre que deseamos para la cuenta, en mi caso la llamé witnesslab

Account kind: Storage (general purpose v1)

Replication: Locally-redundant storage (LRS)

A continuación la imagen de la configuración que realicé para mi cuenta de almacenamiento:



De esta cuenta recién creada vamos a necesitar las llaves de acceso (Access Keys) y solo en caso de requerirse el endpoint. Veamos cómo obtener la llave.

En la cuemta de almacenamiento tenemos la opción Access Keys allí observaremos 2 llaves, en este caso usaremos la primera de ellas.




Esta llave de acceso debemos tenerla lista ya que más adelante la vamos a necesitar, ahora vamos a la consola de Failover Cluster para agregar nuestro nuevo testigo de nube.

Hacemos clic derecho sobre el nombre del cluster, seleccionamos More Actions y luego Configure Cluster Quorum Settings




En el asistente hacemos clic en Next para empezar


En Select Quorum Configuration Options hacemos clic en la tercer opción Advanced quorum configuration y hacemos clic en Next



Seleccionamos los nodos que tendrán votos en el quorum, en esta caso todos los nodos y hacemos clic en Next


En la siguiente ventana seleccionamos Configure a cloud witness y hacemos clic en Next




A continuación, debemos poner el nombre de la cuenta de almacenamiento que previamente creamos en Azure, así como la llave de acceso que podemos copiar desde el portal, el Azure service point no lo necesitaremos en este caso, esto solo se debe cambiar bajo circunstancias específicas, como por ejemplo si estamos usando un datacenter en China, el cual tendrá un endpoint diferente, de lo contrario debe quedar algo similar a lo que se muestra en la siguiente imagen.



Revisamos la configuración y hacemos clic en Next




Para finalizar nos mostrará un mensaje indicando que todo salió bien, tal como se muestra a continuación.



Ahora, si revisamos los recursos del cluster, podemos observar que ya tenemos nuestro Cloud Witness en línea.



Y esto es todo. Espero esta información les sea de utilidad.

[ASR] Recuperación de VMs de Hyper-V administradas con Virtual Machine Manager - Parte 5

lunes, 24 de septiembre de 2018


Post en esta serie:

[ASR] Recuperación de VMs de Hyper-V administradas con Virtual Machine Manager - Parte 1
[ASR] Recuperación de VMs de Hyper-V administradas con Virtual Machine Manager - Parte 2
[ASR] Recuperación de VMs de Hyper-V administradas con Virtual Machine Manager - Parte 3
[ASR] Recuperación de VMs de Hyper-V administradas con Virtual Machine Manager - Parte 4


En las entregas anteriores vimos cómo preparar toda la infraestructura de Azure Site Recovery, en esta última entrega dela serie vamos a realizar un failover de prueba (Test Failover).

Para ello basta con seleccionar cualquiera de las máquinas ya replicadas, y en las opciones de la parte superior podemos ver que contamos con 3:


  1. Planned Failover
  2. Failover
  3. Test Failover 
En este caso vamos a utilizar Test Failover


Como se puede apreciar en la imagen anterior, contamos con un RPO bastante bajo,de tan solo 3 segundos en este caso.

A continuación podemos seleccionar un punto de restauración, y la red virtual sobre la cual haremos el failover.

Nótese la recomendación, al identificar que se trata de un test, me sugiere utilizar una red diferente a la de producción, ya que en mi caso estoy usando el mismo segmento, lo ideal es que la red para pruebas se mantenga en un segmento aislado, pero para efectos de esta demostración no tengo lío en utilizar la misma red, ya que no tengo comunicación alguna entre estas dos redes.




Luego, solamente debemos esperar hasta que se complete el proceso de Failover.


Algo interesante durante este proceso es que podemos ver cuánto tarda, con lo cual podemos tener valores de RTO para nuestro DRP


Al finalizar, ya tenemos las máquinas encendidas y listas para hacer pruebas, observen que se agrega la palabra test al final del nombre de la máquina.


Los pasos siguientes pueden ser agregar direcciones IP públicas a las interfaces en caso de que no tengamos conectividad entre los sitios para alcanzar las máquinas, ASR también incluye planes de ejecución en los cuales se puede determinar el orden de encendido de las máquinas en el caso de existan dependencias, como por ejemplo un servidor de SQL o Sharepoint que requieren de un controlador de dominio, etc. También es posible en medio del proceso la solicitud de acciones manuales, como actualizar algún registro DNS, o modificación de archivos de configuración. Estos temas no los veremos en esta serie de entregas,ya se sería más extenso de los que ya está, sin embargo para una futura ocasión crearé un post hablando sobre ello.

Por ahora, y para finalizar, veamos cómo se verifica el estado dela replicación desdeVMM

Si hacemos clic derecho sobre una de las máquinas protegidas, veremos la opción Manage Protection



Y desde allí podemos configurar la frecuencia de replicación.


En la parte de estado de la máquina, además de ver el estado de la protección, tenemos información acerca  de los errores, y cuando se realizó la última sincronización.



Bien, y esto es todo! Hasta aquí hemos llegado con esta serie de 5 artículos, un poco larga, pero seguro les será de utilidad si desean proteger máquinas administradas por VMM.

Un saludo para todos!

[ASR] Recuperación de VMs de Hyper-V administradas con Virtual Machine Manager - Parte 4

sábado, 22 de septiembre de 2018


Post en esta serie:

[ASR] Recuperación de VMs de Hyper-V administradas con Virtual Machine Manager - Parte 1
[ASR] Recuperación de VMs de Hyper-V administradas con Virtual Machine Manager - Parte 2
[ASR] Recuperación de VMs de Hyper-V administradas con Virtual Machine Manager - Parte 3
[ASR] Recuperación de VMs de Hyper-V administradas con Virtual Machine Manager - Parte 5

Bien, en esta parte ya estamos cerca de terminar la implementación, Lo que vamos hacer ahora es mapear nuestra red de VMM en Azure Site Recovery, para ello en la parte de administración seleccionamos Site Recovery Infrastructure - Network Mapping




En la parte superior hacemos clic en + Network Mapping



Ahora seleccionamos las redes de origen y destino como se muestra a continuación:



1.  Seleccionamos el servidor VMM de origen SCVMM01A.cloud
2.  El destino que será Azure
3.  Seleccionamos la suscripción
4.  El método de implementación después del failover será Resource Manager
5.  Seleccionamos la red de origen, en este caso en VMM mi red se llama LABNET
6.  Por último la red de destino en Azure será VNet4. Como se puede apreciar en Azure conservaré         el mismo segmento de red que utilizo en mi ambiente on-premise con VMM.


Con lo anterior, hemos terminado la preparación de toda la infraestructura a nivel de Azure. Lo cual significa que ya tenemos el entorno local con VMM conectado con Azure Site Recovery, con ello ya podemos empezar el proceso de replicación de las máquinas virtuales hacia Azure.

En la parte de Site Recovery, ahora vamos a continuar con el paso 1 (Replicate Application) para máquinas on-premises y en Azure, como se muestra en la siguiente imagen:




Para habilitar la replicación, necesitamos completar las siguientes acciones, primero debemos configurar nuestro origen de replicación:


1. Source: Seleccionamos el origen On-premises
2. Source location: Seleccionamos el servidorVMM On-premises de origen.
3. Cloud: Seleccionamos la nube de VMM en la cual se encuentran las máquinas a replicar.


Ahora que ya tenemos el origen listo, debemos configurar el destino (Azure), con los datos necesarios como la suscripción, el grupo de recursos, entre otros que se muestran a continuación:


1. Target: Ya nos aparecerá el destino marcado con Azure
2. Subscription: Seleccionamos la suscripción
3. Post-failover resource group: Seleccionamos el grupo de recursos que usaremos para desplegar        las máquinas cuando se realice la conmutación por error.
4. Post-failover deployment model: Seleccionamos el modelo de implementación que usaremos            cuando se realice la conmutación por error, simplemente Resource Manager.
5. Storage account: Seleccionamos la cuenta de almacenamiento para nuestra infraestructura.


En la parte 3 Virtual Machines nos mostrará todas las máquinas existentes en la nube de VMM que elegimos, en este caso solamente replicaré dos VMs LAB-SRVSQL y LAB-SRV5 las cuales contienen la base de datos y la aplicación que deseo proteger con Azure Site Recovery.




En el paso 4 vamos a configurar las propiedades de ñas máquinas que vamos a replicar.



Básicamente aquí seleccionamos el sistema operativo de las máquinas y los discos a replicar.



En el quinto y último paso, vamos a configurar la replicación, donde lo único que debemos hacer es seleccionar la directiva de relplicación que creamos en el post anterior.



Una vez finalizado este último paso, solo nos resta hacer clic en el botón Enable Replication



Si todo sale bien veremos algo similar a lo que se muestra en la siguiente imagen:



Ahora solo resta esperar, depende del canal, cantidad y tamaño delas máquinas. Cabe aclarar que esto se trata de la sincronización inicial, una vez replicadas las máquinas solamente se replicarán los cambios.



Una vez finalice la replicación veremos las máquinas en estado protegido, como muestra la siguiente imagen:



Esto es todo, solo nos falta hacer una prueba (test) simulando una situación de recuperación de desastres, Azure Site Recovery permite hacer este tipo de pruebas sin afectar el entorno de producción on-premise, pero eso lo haremos en la siguiente y última parte de la serie. Por ahora para finalizar este post, veamos el diagrama que construye Azure de la solución.


Continúa en:
[ASR] Recuperación de VMs de Hyper-V administradas con Virtual Machine Manager - Parte 5

[Video] Introducción a ARM (Azure Resource Manager)

miércoles, 22 de agosto de 2018


En esta ocasión quiero agradecer al colega Iván Martínez (MVP Perú), por invitarme por segunda vez consecutiva a la Gira de Speakers de Latinoamérica. Iniciativa creada por el mismo y la cual ha tenido gran acogida en LATAM, debido a que diferentes speakers de habla hispana comparten su conocimiento sobre diferentes temas tecnológicos de vanguarida. Les recomiendo que visiten su canal de YouTube donde pueden ver todas las charlasa on-demand. Por lo pronto a continuación les dejo la grabación de mi charla:  Introducción a ARM ( Azure Resource Manager)


A continuación las diapositivas de la sesión:


[ASR] Recuperación de VMs de Hyper-V administradas con Virtual Machine Manager - Parte 3

martes, 24 de julio de 2018



Post en esta serie:

[ASR] Recuperación de VMs de Hyper-V administradas con Virtual Machine Manager - Parte 1
[ASR] Recuperación de VMs de Hyper-V administradas con Virtual Machine Manager - Parte 2
[ASR] Recuperación de VMs de Hyper-V administradas con Virtual Machine Manager - Parte 4
[ASR] Recuperación de VMs de Hyper-V administradas con Virtual Machine Manager - Parte 5


En la parte 2 de esta serie finalizamos instalando el proveedor de ASR en los servidores de VMM, en esta parte vamos a continuar con la instalación del agente de Site Recovery (Microsoft Azure Recovery Services Agent) en los servidores de Hyper-V.  En la siguiente imagen he marcado el paso 1 como finalizado. Al tener listo el servidor de VMM podemos pasar al paso 2 y elegir una de las nubes de VMM, pero antes vamos a realizar las actividades del paso 3, es decir instalar el agente en cada unos de los host que conforman la nube que vamos a utilizar.


En el paso3, simplemente debemos confirmar cuando ya tengamos el agente instalado en cada uno de los host, allí mismo encontramos el enlace para descarga, el cual apunta a la siguiente URL: http://aka.ms/downloadmarsagent_eus


Se descargará el archivo MARSAgentInstaller.msi



Una vez descargado lo instalamos en cada uno de los host:


Seleccionamos la ruta de instalación y de cache y hacemos clic en Next




Seleccionamos cómo conectarnos a Internet, en caso de que tengamos un proxy debemos especificarlo, de lo contrario se conectará con la configuración de proxy por defecto.


Se deben cumplir los pre-requisitos que se muestran en la siguiente imagen antes de continuar, una vez se cumplan, hacemos clic en Install


Una vez finalice la instalación, hacemos clic en el botón Proceed to Regsitration



Cuando finalicemos la instalación del agente en cada uno de los host de Hyper-V, vamos al portal y terminamos de seleccionar la información que nos falta, tal como se muestra a continuación:


En este caso, he seleccionado la nube llamada Lab y como ya he instalado el agente en cada uno de los host, selecciono: Yes, I have installed the agent

Esta parte que acabamos de terminar, es tal vez la parte más larga del proceso, que es la configuración del origen (source). A continuación podemos ver como aparece una vez hemos finalizado los 3 pasos que componen esta parte de la configuración, y pasamos inmediatamente a la siguiente instancia que es el destino, en este caso Azure.





Como podemos observar, esta parte de la configuración Target - Azure también se compone de tres pasos:

1. Seleccionar una suscripción de Azure.
2. Asegurarse de que exista al menos una cuenta de almacenamiento compatible (ya la tenemos).
3. Asegurarse de que exista al menos una red virtual de Azure compatible (ya la tenemos).

Recuerden que en la parte 1 de esta serie hemos creado tanto la cuenta de almacenamiento como la red virtual. También se puede observar que si se encuentran cuentas de almacenamiento o redes virtuales compatibles, se informa cuántas fueron encontradas, para este caso fueron encontradas 2 cuentas de almacenamiento y 4 redes virtuales compatibles.

Si observamos en la parte superior de la imagen anterior tenemos la opción para agregar la red y la cuenta de almacenamiento.


Ahora, ya vamos a pasar al 5 paso y último del proceso Replication Settings



Hacemos clic en Create and Associate



Debemos crear la política como se muestra a continuación:


Configuramos nuestra política de replicación, la cual incluye cada cuánto tiempo va a replicar los cambios a Azure, la retención, entre otros. Esto se debe configurar según las necesidades de cada negocio.

Name: ponemos un nombre descriptivo, en este caso ReplicationPolicy
Copy frequency: 5 Minutos
Recovery point ratention in hours: 2
App-consistent snapshot frequency in hours: 1
Initial replication start time: Immediately

Con esto terminamos la configuración!


Bien, esto es todo para esta tercera parte. Espero que no se esté haciendo muy extenso. Nos vemos en la próxima parte.

Continúa en:
[ASR] Recuperación de VMs de Hyper-V administradas con Virtual Machine Manager - Parte 4
 

Temas por fecha

Lo más visto

Comunidad

Comunidad
Comunidad Técnica

Visitas