El Baúl Del ITPRO

Buenas

El pasado 19/11/2015 salío a la luz la TP4 (Techinical Preview 4) de windows server 2016. Entre otras novedades incluidas en esta Technical Preview me gustaría destacar y comentar la funcionalidad de Hyper-V Containers.

En este primer post de la serie me gustaría hacer una introducción un poco más teórica sobre que son los Hyper-V Containers y en qué se diferencian de los Windows Servers Containers para en la segunda entrada de la serie demostrar de manera práctica como crear un Hyper-V server container sobre Windows Server 2016 TP4.

Primero que todo me gustaría refrescar que son los containers y que nos aportan. Los Containers en sí mismo son otro tipo de virtualización también conocida como virtualización del Sistema operativo en la cual la aplicación que corre bajo un container tiene la percepción de que sea ejecutando sobre un sistema operativo totalmente aislado e independiente.

Dentro de los containers en el mundo Windows encontramos dos tipos:

Windows server containers: Este tipo de containers ya existían en versiones anteriores a la TP4 de Windows server 2016 los cuales comparten el Sistema operativo con otros containers y con el propio host por lo tanto al no existir una capa que aislé realmente unos containers de otros podría suceder que un incidencia en un container afectará al resto o al porpio host. Estos containers son ideales para escenarios en los que el host realmente confía en el comportamiento de los containers que ejecuta y los containers también son confiables entre ellos, también serán la mejor opción para aplicaciones que se dividen en multiples container o micro-services.

Hyper-V containers: Como ya he mencionado anteriormente este tipo de containers han aparecido como novedad en la TP4 de Windows Sever 2016 y la principal diferencia con respecto a los Windows Server Containers es que los Hyper-V containers tienen una copia del kernel y parte de la memoria directamente asignado a los mismos, de esta manera se consigue un nivel de aislamiento total. Al ofrecer un nivel de aislamiento mayor los Hyper-V Containers tardan algo más de tiempo en arrancar y la densidad de consolidación por host es algo menor. Sin embargo, este tipo de containers serán la solución idónea para evitar que un incidente en un container pueda afectar al rendimiento del host o de otros containers.

Igualmente me gustaría menciona que tanto los Windows server container comos los hyper-V Containers se puede administrar tanto con el cliente de docker como con Power Shell y que es posible migrar fácilmente un aplicación de un Windows server Container a un Hyper-V container.

Por último, como normalmente una imagen suele ser más explicativa que 1000 palabras me gustaría dejaros una pequeña imagen que creo que refleja bien la diferencia entre Windows Server Container e Hyper-V Containers.

Espero que os resulte de utilidad, en la segunda entrada de la serie veremos como crear hyper-V container usando Windows server 2016 Tp4.

Un saludo

Buenas
Atendiendo a lo prometido en esta segunda entrada de la serie me gustaría explicar el procedimiento para definir configuraciones usando Puppet con el objetivo de aplicar las mismas a nuestros clientes de Puppet que en este caso serán máquinas virtuales corriendo en azure.

Una vez tenemos la máquinas virtuales con el agente de Puppet instalado y configurado para conectarse con el servidor de Puppet (Procedimiento explicado en el primer Post de la serie el cual podéis encontrar en el siguiente link) el primer paso que debemos realizar en conectarnos a la consola de Puppet y autorizar la solicitud de conexión de los clientes de Puppet para ello seguiremos los siguientes pasos:

1– Accedemos a la consola de Puppet

2– Pinchamos en Node request

3– Aceptamos las solicitudes que tenemos pendientes

Una vez tenemos los clientes de Puppet autorizadas en la consola procederemos a conectarnos al servidor de Puppet y definir una configuración la cual aplicaremos a nuestros clientes. En el siguiente ejemplo mostraré como configurar un simple fichero de texto el cual se copiará en el directorio de los clientes de Puppet, para ello seguiremos los siguientes pasos:

1– Nos logamos en el servidor de Puppet por ssh

2– Indicamos los clientes que recibirán las configuraciones definidas para ello Accedemos al path:
cd /etc/puppetlabs/puppet/manifests/

3 – Editamos el fichero site.pp ejecutando:
nano site.pp

4– Incluimos los clientes Puppet siguiendo el ejemplo del pantallazo adjunto y guardamos los cambios en el fichero site.pp

Una vez definidos los cliente sobre los que aplicaremos las configuraciones procedemos a definir el fichero de texto que aplicaremos a nuestros clientes, para ello seguiremos los siguientes pasos:

1– Accedemos al path
cd /etc/puppetlabs/puppet/modules/windows/manifests/

2– Editamos el fichero init.pp ejecutando
nano init.pp

3– En nuestro caso definiremos el fichero init.pp con la siguiente configuración para crear el fichero de texto

Aunque las configuraciones definidas mediante puppet se refrescan automaticamente, en nuestro caso forzaremos a que se apliquen en el cliente ejecutando el comando puppet agent –test y comprobaremos que el fichero definido aparece en C:

Espero que resulte de utilidad

Un saludo

Buenas,

Hoy me gustaría informaros que hace poco más de una semana Microsoft libero la build 10565 de Windows 10 la cual es la primera versión de Windows 10 que soporta Nested virtualization o lo que es lo mismo virtualización anidada del hypervisor. La posibilidad de anidar el hypervisor nos permite básicamente habilitar el role hyper-v en una máquina virtual de hyper-V.

Esta versión de Windows 10 se encuentra actualmente en fase de insider preview por lo tanto no debemos extrañaros de encontrar algunos bugs en la misma, de hecho el equipo de producto de Hyper-V ya es consciente de algunos que mencionaré a continuación los cuales serán subsanados en futuras releases.

Tras hacer esta breve introducción de la funcionalidad procedo a detallar los pasos que debemos seguir para activar la misma.

1– Descargamos la build 10565 desde el siguiente enlace.

2– Instalamos nuestro pc físico usando esta build.

3– Habilitamos el role de hyper-v en nuestra máquina física.

4– Creamos una máquina y desplegamos la build 10565 en la misma (importante no configurar dinamyc memory en la misma)

5– Apagamos la máquina virtual que acabamos de crear. Este será un prerrequisito para ejecutar el script que ha desarrollado el grupo de producto para habilitar la funcionalidad de una manera súper sencilla.

6– Ejecutamos el siguiente script para habilitar nested virtualization en la máquina virtual que acabamos de crear

7– Arrancamos esta máquina virtual y procedemos a instalar el role de hyper-v en la misma

8– Seguidamente ejecutaremos el siguiente script el cual nos permitirá habilitar el MAC spoofing en esta máquina virtual. Esta funcionalidad nos permitirá conectar a la red las máquinas virtuales desplegadas de manera anidada.

9– Una vez llegados a este punto ya tenemos el entorno listo y podemos crear máquinas virtuales de manera anidada sobre la máquina vritual en la que instalamos Hyper-V previamente.

Como ya comente al comienzo de este post la build 10565 ha sido liberada muy recientemente y tiene algunos bugs, los cuales me gustaría enumerar para vuestra conocimiento.
– No podemos usar dynamic memory en nuestras máquinas virtuales
– Runtime Memory resize tampco funcionaría en este entorno.
– No se puede aplicar checkpoint a las máquinas virtuales.
– De momento no se soporta live migration.

Espero que os resulte de utilidad.

Un saludo

Buenas,

Hoy me gustaría compartir el procedimiento para encender y apagar nuestras máquinas virtuales en azure, para ello programaremos la ejecución de un script de power Shell dentro de los servicios de automatización de Windows Azure.

Como podréis imaginar esta solución resultará especialmente interesante de cara a reducir el consumo de recursos de cómputo en Azure y por consiguiente disminuir el coste de ejecución de nuestras máquinas en Azure.

Una vez hecha esta breve introducción procedo a detallar paso a paso las acciones que debemos realizar

1– Nos logamos en el portal de Azure

2– Accedemos al apartado de automatización y creamos una cuenta de automatización

3– Asiganmos un nombre para la cuenta de automatización y definimos en que región se ejecutará

4– Procedemos a definir los credenciales con los ejecutaremos nuestros scrips accediento al apartdo de assets

5– Pinchamos en “Add Settings” y posteriromente en añadir credenciales “add credentials”

6– En el tipo de crendencial indicamos que se utilizarán para ejecutar scripts de Power Shell y definimos un nombre para las credenciales.

7– Indicamos el usuario y la contraseña de las credenciales que queremos guardar las cuales se usarán posteriormente para ejecutar los scripts. La cuenta utilizada debe tener permisos de Co-Administrador y debemos estar dada de alta en el dominio de nuestra organización

8– Una vez creados y gurdados los credenciales accedemos a runbooks

9– Procedemos a crear un runbook mediante el asistente de creación rápida como se puede observar en el pantallazo adjunto

10– Tras crear el runbook lo seleccionamos para acceder al mismo.

11– Seguidamente pinchamos en Autor

12– En este apartado definiremos el script de power Shell que queremos ejecutar. Como podéis observar en el pantallazo adjunto el script en si mismo es muy sencillo y simplemente obtendremos los credenciales guardados y ejecutaremos el comando en este caso para iniciar la máquinas virtual. Una vez definidos los parámetros del script lo guardaremos, testearemos y si todo es correcto lo publicaremos.

Es importante mencionar que el resultado del test del script debe ser satisfactorio antes de públicarlo, la salida de dicho test será similar a la siguiente

13– Tras tener nuestro runbook definido y guardado tan solo nos queda definir una planificación de ejecución, para ello accederemos a “Schedule” – “link to a new Schedule”

14– Por ultimo procederemos a definir la plafinificación de la ejecución

15– La creación y la planificación del runbook de apagado será exactamente idéntica a la de encendido pero ejecutaremos el comando de power Shell Stop-Azurevm en lugar de Start-AzureVm.

Espero que resulte de utilidad.

Un saludo.

Buenas
Como ya prometí en su momento hoy escribo el siguiente post para explicar cómo configurar Azure site recovery para replicar máquinas de virtuales a Azure desde nuestros host en hyper-v sin necesidad de tener instalado SCVMM en nuestra infraestructura.
Para realizar dicha configuración realizaremos los siguientes pasos.

1– Nos logamos en el portal de azure y accedemos a Recovery Services

2– Creamos un vault

3– Una vez tenemos el vault creado accedemos al mismo y seleccionamos el tipo de “setup recovery” que queremos configurar y automáticamente se cargará una pagina con las instrucciones que debemos seguir.

4– Seguidamente realizamos el primer paso del wizard que es crear un site de Hyper-V

5– Posteriormente debemos descargar el “download provider” que es simplemente un instalable que instalará el agente de hyper-V encargado de realizar la replicación en nuestro de hyper-v y la “registration key” que es un clave cuya función principal es vincular el host de hyper-v con la subcripción de azure

El procedimiento para instalar el download provider es muy sencillo, tan solo debemos seguir el wizard de instalación e indicar como se conectará el host de hyper-V a internet (de manera directa o pasando por un proxy). Una vez realizada la instalación debemos ver el host de hyper-V si pinchamos en Servers – HyperV sites

6– Una vez tenemos nuestro hyper-v conectado con nuestra subcripción de azure debemos de asegurarnos que tenemos al menos una red virtual en azure donde se levantarían las maquinas replicadas y una cuenta de almacenamiento con geo-replicación en la que se almacenarán las cuentas replicadas.

7– Seguidamente debemos configurar un grupo de protección para nuestras vms en el que especificaremos la subcripción y la cuenta de almacenamiento asociados al mismo al igual que la frecuencia de replicación, los puntos de recuperación y si queremos realizar instantáneas coherentes a nivel de aplicación.

8– El último paso necesario sería agragar las máquinas virtuales que queremos replicar en azure, las cuales una vez replicdas veremos de la siguientes manera.

Como podéis observar en la pantallazo de la parte superior, una vez replicada la máquina virtual tenemos la posibilidad de test o realizar una conmutación por error.

Espero que resulte de utilidad.

Un saludo

Buenos días,

Escribo este para recomendaros la inscripción en dos eventos de cuales en uno de ellos estaré participando como ponente.

– El primero evento que me gustaría recomedaros es la Azurecon 2015 que se celebra de manera online el próximo 29 de septimbre. Podéis registraros en el evento usando el siguiente enlace.

Enlace de Registro

– El segundo evento que me gustaría recomendaros y en el que impartire una charla sobre Azure Site recovery Manager junto a mi amigo Juan Jose Diaz Antuña se celebrará en Madrid el proximo 22 de septiembre, a continuación podéis encontrar el link de registro y la agenda del evento.

Enlace de Registro

Espero que os resulte de utilidad y con suerte veros en el evento del día 22

Un saludo