Global Azure Bootcamp 2019

viernes, 19 de abril de 2019



Este año me siento muy orgulloso de participar por primera vez como organizador y speaker para el Global Azure Bootcamp Bogotá 2019, se trata de un día completo dedicado a compartir información de calidad sobre Microsoft Azure. Muy pronto la agenda será publicada, en esta ocasión nuestros invitados de honor son todos aquellos integrantes de los grupos de estudio de la comunidad ITPros-DC

A continuación la agenda en vídeo:



Un saludo para tod@s!

Cómo instalar el módulo de Azure PowerShell Az

martes, 5 de marzo de 2019


En este artículo explicaré cómo instalar el nuevo módulo de Azure PowerShell Az el cual básicamente es el remplazo del módulo AzureRM que se viene utilizando, la recomendación es desinstalar el módulo AzureRM y continuar usando el nuevo módulo Az, ya que no seguirán saliendo actualizaciones para el anterior, además el nuevo resulta más sencillo de utilizar, ya que los comandos son más cortos.

Si ya viene usando el módulo anterior, es recomendado desinstalarlo primero:

Uninstall-AzureRm


Nota: El comando anterior debe ser usado en el caso de que se haya realizado la instalación con PowerShellGet, si se uso un paquete MSI se debe hacer desde el panel de control

Para instalar nuevo módulo se requiere una versión de PowerShell 5.1 o posterior, así que debemos verificarlo con el siguiente comando:


$PSVersionTable.PSVersion



Ahora si podemos iniciar la instalación, para ello ejecutamos lo siguiente:


Install-Module -Name Az





Una vez instalado, podemos verificarlo de la siguiente forma:


 Get-InstalledModule -Name Az



Y esto es todo, ya podemos empezar a utilizar el nuevo módulo.

Integrar Azure VNet con Windows Server Essentials Dashboard

miércoles, 30 de enero de 2019


Una de las cosas que más me gusta de Windows Server Essentials Dashboard es la posilibidad de hacer integración con los servicios cloud de Microsoft como Office 365 y Azure. En este post precisamente voy a mostrar cómo hacer la integración de Azure Virtual Network al dashboard; esto nos permite tener información sobre el estado de los tuneles VPN que desplegemos en Azure directamente desde Windows Server sin necesidad de tener que ir hasta el portal, aunque los amantes de la línea de comando dirán que con una sola línea pueden traer la misma información, es cierto, pero tener varios servicios cloud integrados en una sola consola y poder ver algo más allá del estado a través de una consola gráfica, para muchos puede ser de utilidad, así que voy a mostrar como integro mi servicio de Azure VNet para ver el estado de mi conexión VPN S2S.

Al abrir el Dashboard, vamos a la parte de Servicios y allí podemos ver la lista de servicios cloud de Microsoft con los cuales podemos hacer la integración, y hacemos clic sobre Azure Virtual Network.



Se desplegará un panel hacia la derecha en el cual debemos hacer clic en Integrate with Azure Virtual Network


Iniciamos sesión en Microsoft Azure, para elllo hacemos clic en el botón Sign in





Ahora debemos seleccionar la suscripción en la cual queremos crear o ver las conexiones VPN y hacemos clic en Next



En la siguiente ventana debemos hacer lo siguiente y luego clic en Next

1. Seleccionar la red virtual
2. Seleccionar la puerta de enlace de red local



En la siguiente ventana seleccionamos el dispositivo de VPN, si hemos utilizado el rol RRAS de Windows Server como dispositivo VPN (que es mi caso), seleccionamos la primera opción y podemos elegir el servidor que tiene instalado el rol, de lo contrario seleccionamos Use my VPN Router y hacemos clic en Finish




Ya con esto tenemos creada la integración.



Y esto es todo, ahora si vamos al dashboard veremos que en la parte superior aparece la opción Azure VNet y al hacer clic allí veremos el estado de la conexión.



Y si hacemos clic en la pestaña Resources podemos ver los equipos que hacen parte de la VNet. E incluso podemos hacer conexión con los mismos si hacemos clic derecho sobre el recurso, tal como se muestra en la siguiente imagen.



Y esto es todo! espero les sea de utilidad.

Tal vez te pueda interesar alguno de estos artículos relacionados:

Crear VPN de punto a sitio en Azure P2S

Crear VPN de sitio a sitio en Azure S2S utilizando RRAS como dispositivo VPN

[webcast]: Beneficios de conectar su red local a Microsoft Azure

lunes, 21 de enero de 2019


Hola a todos, en esta ocasión escribo para invitarlos a mi próximo webcast organizado por O4IT con el apoyo de Microsoft Colombia, en el cual les estaré hablando sobre redes privadas virtuales VPN en Microsoft Azure. No olviden registrase a través de este enlace


Grupos de Estudio 2019


Ya se encuentra abierto el registro para el primer ciclo de grupos de estudio del año, hemos lanzado dos grupos para Microsoft Azure y dos para Oracle, Ambos orientados a obtener una certificación, en el caso de Oracle se estudiarán los objetivos del examen IZ0-071 y para el de Azure se abordarán los objetivos del examen AZ-100. No olviden llevar el bono FABI que para este ciclo son útiles escolares, que como siempre donaremos a la Fundación Las Pulgas.

Para ver la información completa y lo que debes hacer para matricularte visita: https://www.itpros-dc.com/p/informacion.html

Y no olvides seguirnos en Facebook para estar informado de todas nuestras actividades:


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
 

MVP Award

MVP Award
Microsoft Azure

Lo más visto

Certificaciones

Comunidad

Comunidad
Comunidad Técnica

Sobre mi

Mi foto
Microsoft Azure MVP MCT|MCSE|MCSA

Visitantes


flags.es