Azure Service Bus Topics

Otro servicio que ofrece el Service Bus de Azure, junto con las ‘Queues’, ‘Relays’ e ‘Event Hub’ son los ‘Topics’. A diferencia de las queues, donde sólo hay un receptor, en los topics puede haber múltiples. Esto es así debido al sistema que emplea basado en suscripciones, en el cual un topic  puede tener registradas múltiples suscripciones, estando cada una asociada a un receptor. Dicho receptor solo recibirá los mensajes que hayan sido previamente filtrados por la propia suscripción, lo que permite controlar la información que llega a cada receptor atendiendo, por ejemplo, al perfil del mismo.

Instalación

El proceso de instalación o creación es el mismo que el de una Azure Service Bus Queue. Unicamente tener en cuenta que ‘Messaging Tier’ debe estar establecido como mínimo en ‘Standard’, a diferencia de las queues.
La cadena de conexión se recupera de manera análoga.

Funcionamiento

El funcionamiento es muy similar al visto para las ‘queues’, con lo que todo lo comentado para estas se aplican aquí. De esta manera, este servicio es susceptible de ser empleado con diferentes lenguajes (Java, Node.js, .NET, PHP, Ruby o Python). Para los ejemplos se empleará Python.
La gestión de los topics, así como de las suscripciones pueden hacerse asimismo desde el propio portal.

Un código de ejemplo con las operaciones básicas sería el siguiente:

Conclusiones

Como se ha visto, el funcionamiento es muy similar a las colas de Services Bus, con la diferencia fundamental del número de receptores del mensaje. Esta característica, unida a la posibilidad de establecer filtros en cada suscripción, permite un grado de versatilidad con que la anterior estructura de datos no contaba.

Herramientas Útiles

Me gustaría hablar de dos herramientas muy útiles en el día a día, que pese a su sencillez no por ello dejan de ser útiles.
Una de ellas de un emulador de terminal llamado cmder. Si bien Carlos habló en este post de otro llamado ConEmu, esta otra alternativa también resulta bastante interesante.
La otra herramienta se llama PingInfoView, y su cometido es el de realizar un ping a las máquinas que establezcamos, con lo cual se sabrá en todo momento si éstas están en línea o no.

cmder

Como se ha dicho, el cmder es un emulador de consola, lo que significa que actúa a modo de intermediario con el intérprete. Esto vendría a decir que se puede personalizar y adecuar más a las necesidades y gustos del usuario (siempre dentro de un límite). La configuración es bastante completa, permitiendo alterar diversos aspectos, desde el grado de opacidad, el tipo de fuente a emplear, pasando por la integración de diversas aplicaciones en las múltiples pestañas que se pueden desplegar, etc.
Sin duda, el grado de configruación es lo que le confiere potencia y versatilidad a este emulador de consola, si bien al principio puede resultar algo engorroso debido a la cantidad de opciones.

2016-06-19 20_34_57-Cmder

PingInfoView

Esta aplicación nos permite realizar ping a una serie de máquinas establecidas en una lista a introducir de forma manual o bien desde un archivo externo. El programa permite establecer alarmas visuales y sonoras en el caso de fallos, así como exportar informes en HTML, establecer la frecuencia de los pings, etc.

2016-06-19 20_32_00-PingInfoView

Un programa sencillo pero que cumple su cometido a la perfección.

Azure Service Bus Queues

Qué es

El Azure Service Bus Queues (ASBQ), al igual que el servicio Azure Queue Storage (se habló de el en este post) hace uso de una estructura de datos basada en cola para el envío de mensajes. A diferencia de este último, el ASBQ no requiere de una Storage Account para su funcionamiento.

Instalación

La instalación es bastante directa y sencilla. Hay que llevarla a cabo desde el portal clásico (ya que desde el portal nuevo, nos redirigirá al primero).

De este modo, en el portal clásico, hay que situarse en “Service Bus” y pinchar en “Create”. Hecho esto, aparecerá una pantalla donde se indicarán los datos del servicio.

Creando ASB 1

Se dará un namespace, el tipo será ‘messaging’, se elegirá el nivel acorde a las necesidades, así como la región (el rendimiento será mejor cuanto más cerca). Una vez creado el servicio, aparecerá en el panel.

ASB creado

Lo último que quedaría por hacer sería anotar la cadena de conexión que posteriormente se empleará en el entorno de desarrollo elegido. Para ello, hay que pinchar en el icono “Connection information”, proporcionando dicha información.

ASB connection info

Funcionamiento

Este servicio puede utilizarse mediante diversos lenguajes (Java, Node.js, .NET, etc), a modo de ejemplo se hará en Python.
La instalación de Python y su correspondiente SDK no presenta complicaciones, habiendo versión para Windows, Linux y MacOS.
Una vez instalado el SDK, ya se está en disposición de crear y eliminar colas, así como introducir mensajes y extraerlos. Cabe señalar que en el propio portal clásico se pueden crear y eliminar colas.

Un código de ejemplo en Python sería el siguiente:

Conclusiones

La modalidad que se ha visto aquí es la más simple (paso de mensajes), pero también presenta otras más elaboradas. Comparándola con la Azure Storage Queue, su utilización es si cabe más sencilla y directa, pero no tan potente y versátil. Todo depende en realidad del uso que se le dé.

Hasta la próxima

Como podéis imaginar por el título de esta publicación, efectivamente se trata de una despedida, una que me cuesta muchísimo escribir. Esta semana del 9 de mayo ha sido la última como mánager del equipo de Enterprise IT y como empleado de Plain Concepts.

Sólo tengo buenas palabras para hablar de Plain Concepts, una empresa pura de ingeniería donde el talento corre por todos y cada uno de sus integrantes. Seguramente sea el peor momento para irme ahora que tenemos por las oficinas unas Microsoft Hololens y unas HTC Vive :)

He disfrutado muchísimo en los proyectos y apasionantes retos de esta empresa, de los cuales me he permitido el lujo de compartir detalles con todos los lectores de este blog a través de las publicaciones que he ido haciendo. Y aunque yo me vaya, aquí queda mucho crack: Antonio, Elena, Carlos, Manuel, José María, Jésica… Todos ellos hacen aportaciones interesantísimas en el ámbito de lo que tocan día tras días y consiguen que tenga este sitio en un lugar especial de mi lector RSS. Os echaré mucho de menos.

Inaugurar y escribir en este blog ha sido el más grande de los honores. Como sé que eventualmente nos vamos a ver y que este mundo no es tampoco tan grande, esto no es un adios sino un hasta la próxima.

¡Hasta la próxima cracks!
Carlos

PD: No podía irme sin dejaros algo en PowerShell aquí, así que cortesía de Dave Wilson os pongo algo de música en PowerShell:

Transferencia de datos utilizando Azcopy y Azure CLI

Una operación bastante común en la gestión de una cuenta de almacenamiento o Storage account en Azure es la copia de datos (se trate de un blob, fichero, etc) ya sea entre una cuenta y otra , o bien carga / descarga en local a Azure.
Estas operaciones pueden llevarse a cabo de diferentes maneras, pero aquí voy a centrarme en dos de ellas: AzCopy y Azure CLI. Decir que para los ejemplos sobre este último, se va a emplear el modo ARM, el cual se activa con:

Hay que resaltar que AzCopy resulta mucho más versátil y potente que Azure CLI, lo cual es lógico ya que es una herramienta creada específicamente para este fin, con lo cual contempla más situaciones y cuenta con más parámetros, permitiendo así una configuración mas específica. No obstante, AzCopy solo está disponible para Windows, mientras que Azure CLI es multiplataforma.

Sintaxis básica

Tanto AzCopy como Azure CLI pueden llevar a cabo la copia de blobs y ficheros.
Así, para subir un fichero a un blob y descargar todos los archivos de un blob de un container en Azure CLI en local:

Las opciones disponibles se pueden consultar acudiendo a la ayuda de Azure CLI:

Ayuda storage download Azure CLI

Por su parte, en AzCopy, para la descarga, se admiten más combinaciones más allá de la única descarga de un blob:

Y para la carga de archivos:

Respecto a la copia de blobs entre cuentas, en Azure CLI:

En AzCopy, esta misma operación puede realizarse de forma síncrona (se descarga una copia en local y esta se sube) o asíncrona (por defecto):

Llegados a este punto, a pesar de que Azure CLI también soporta la copia de archivos, al igual que AzCopy, sin embargo, este último también contempla además, otras características, por ejemplo, entre otras:

  • Importación / exportación de tablas en formato CSV o JSON.
  • Uso de un archivo de respuesta: en dicho archivo se permite especificar los parámetros al comando AzCopy, de modo que este los procesa como si hubieran indicado directamente:
  • Carpeta de archivo de diario: esta interesante funcionalidad permite reanudar operaciones inconclusas si detecta la existencia de este archivo.
  • Posibilidad de especificar el número de operaciones simultáneas a iniciar: por defecto, solo se puede llevar a cabo una operación en un mismo equipo. Esto es así para optimizar el uso de los recursos. Para realizar más de una simultáneamente, se emplearía el parámetro ‘/NC’

Conclusiones

Como se dijo al principio, AzCopy es mucho más versátil y potente a la hora de realizar copias. No hay que olvidar que el alcance de Azure CLI es la gestión de los recursos. Aún así, es perfectamente válida para las operaciones de copia habituales debido a su sencillez.

Construyendo una VPN Point-to-Site con autenticación RADIUS y AD en Microsoft Azure

Ya hemos comentado en otras ocasiones en este blog cómo establecemos una VPN Point to Site en Microsoft Azure. Aunque es una forma rápida y versátil de dar a equipos cliente acceso a nuestra red virtual de Azure, lo cierto es que nos enfrentamos a algunas limitaciones que en función del proyecto en que nos encontremos pueden ser todo un stopper para nosotros o nuestro cliente. Concretamente son las siguientes:

  • Sólo admiten 128 clientes como máximo. Como sabéis, las conexiones de App Service cuentan como un cliente.
  • El cliente sólo funciona en Windows 7 o superior (32 y 64 bits). Nos olvidamos de otras plataformas.
  • La autenticación se realiza mediante certificados, no hay nombres de usuario y contraseñas.
  • La comunicación normalmente es en un sentido, del cliente a la infraestructura de Azure y no viceversa.

Si estos puntos no nos suponen un gran problema, el P2S que Azure nos ofrece como servicio es una excelente forma de conectarnos a nuestra red virtual. Pero si resulta que lo es… ¿qué podemos hacer?

Alternativa 1: Máquina Virtual con Windows Server 2012 R2 y RRAS

Es lo primero que se nos viene a la cabeza. Pero no me cansaré de repetir que el rol de RRAS de Windows Server 2012 R2 (y versiones anteriores) no está soportado en Azure. Aunque al instalarlo nos de la sensación de que todo está OK, Azure eventualmente reinicia los adataptadores de red sintéticos asociados a dicha máquina, algo que hace que no sobreviva la configuración que hemos hecho del rol.

Los suficientemente valientes pueden probar a crear un script de autoconfiguración del rol que se ejecute cada vez que se encieda la máquina, pero os encontraréis con que el soporte de PowerShell de este rol es realmente pobre (está pensado para DirectAccess más que para VPN) y no os quedará más remedio que recurrir al viejo amigo netsh. Que la fuerza os acompañe.

Aunque consiguiéramos autoconfigurar la máquina en cada inicio esto es algo que considero bien lejos de ser estable y confiable, por lo que debíamos ir a otra alternativa.

La solución: gateway GNU/Linux con SoftEther VPN

Parece que GNU/Linux no se ve afectado por los cambios de adaptador de red de Azure, algo que nos arroja algo de luz al problema. Acto seguido necesitamos decidir con qué software implementar la solución. Decidí que SoftEther VPN era la mejor. Gracias a esto vamos a superar todas las limitaciones que hemos comentado antes.

¿Qué es SoftEther VPN?

SoftEther VPN es un potente software VPN de código abierto desarrollado por la Universidad de Tsukuba (Japón) que se posiciona como una alternativa poderosa a los sistemas de túneling existentes, ya sean los basados en RRAS de Microsoft o bien el extendido OpenVPN. ¿Qué lo hace tan genial?

  • Multi-protocolo. SoftEther VPN soporta L2TP/IPsec, SSTP, OpenVPN y SSL VPN (a través de un cliente propio).
  • Multi-plataforma, ya que corre bajo Windows, OSX, Linux, FreeBSD y Solaris.
  • Multi-arquitectura, soportando x86, x64, ARM, MIPS, SH-4, PowerPC y SPARC.
  • Multi-authentication backend: soportando usuarios y contraseñas locales, certificados X.509, Active Directory (sólo Windows) y RADIUS.

Como podéis ver se trata de un completísimo sistema de VPN que soporta prácticamente todo lo que podamos imaginar.

Autenticando con Active Directory

Os habrá llamado la atención que SoftEther VPN soporta Active Directory como backend de autenticación, pero lamentablemente sólo en el caso de que estemos ejecutando el servidor bajo Windows. Esto en Azure nos devolvería a la casilla de salida, así que tenemos que asumir que estamos en Linux. Sin embargo, en la lista también estaba RADIUS. ¿Tiene Microsoft algún servidor RADIUS que nos haga de pasarela a la autenticación de ADDS? ¡Sí! ¡El Network Policy Server! NPS para los amigos.

Nuestra arquitectura a alto nivel sería la siguiente:

gaw1

Así que dicho y hecho, nuestro escenario de demo se va a componer de tres máquinas en Azure:

  • SoftEther VPN (Linux)
  • NPS + ADDS (Windows)
  • App Server (no es indiferente el sistema operativo).

La última máquina de la lista es solo para comprobar conectividades y representa nuestra infraestructura en Azure.

Inyectando a nuestros clientes VPN P2S en la red de Azure: el adaptador de red TAP de Linux

Uno de los grandes problemas que nos podemos encontrar a la hora de conectar clientes a nuestra red virtual de Azure es que esta no es precisamente muy amiga de eso. Una red virtual de Azure se encuentra gobernada por el DHCP que Microsoft instaura en ella y por tanto si intentamos conectarlos a través de la máquina virtual que hemos desplegado, no obtendremos ningún resultado satisfactorio.

Aquí entra en juego otra de esas capacidades de Linux que hace que nos maravillemos con él cada vez que hacemos temas de networking: el adaptador de red virtual TAP. Este adaptador de red es una interfaz virtual que se encuentra integrada en el kernel de Linux y que puede ser desplegada por las aplicaciones que lo requieran. Tiene infinidad de usos en software de tunneling y virtualización.

Cuando desplegamos el adaptador, obtenemos algo similar a esto:

gaw3

Como se puede ver en la imagen, la máquina virtual de SoftEther se encuentra dentro de la red virtual de Azure, y así lo refleja el adaptador eth0. Pero… ¿y si creamos un nuevo adaptador TAP? Llamémosle tap_vpn0. Este adaptador virtual no se encuentra realmente dentro de Azure: no ve la red virtual, el DHCP de Azure no tiene efecto sobre él y es agnóstico a nuestro entorno. ¡Es el candidato perfecto para unir nuestros clientes P2S!

Sin embargo, una vez unidos los clientes a este adaptador, debemos establecer comunicación con la red virtual de Azure. Esto lo podemos conseguir fácilmente convirtiendo nuestra máquina Linux en un router a su vez (ya sabéis, activar IP forwarding como hemos comentado otras veces). De esta manera el dibujo se convierte en el siguiente:

gaw2

User Defined Routes e IP forwarding a nivel de Azure

Hecho esto, necesitamos que Azure sepa a qué gateway enviar el tráfico dirigido a los clientes VPN y permitir que esa máquina acepte tráfico que no es necesariamente para ella. A día de hoy, esto es perfectamente posible:

  • User Defined Routes (UDR). No es ni más ni menos que una definición de tablas de rutas en una red virtual de Azure. Nos permite dirigir el tráfico a donde nos interese. Este tema merecerá un artículo del blog en exclusiva.
  • IP ForwardingFundamental si usamos tablas de rutas y enviamos el tráfico a una máquina virtual, ya que por defecto está no aceptará ningún packete de red en el que ella no sea la destinataria.
El resultado

Tras todo el proceso deberíamos tener operativo todo un hub de conexiones VPN que además nos permite superar las limitaciones que comentábamos al inicio del artículo.

gaw4

El resumen y To-Do list

Como el artículo ha constituido una explicación de alto nivel de cómo conseguir en Azure una VPN P2S autenticada mediante ADDS, os dejo con una serie de pasos de alto nivel para hacer la solución más fácil de seguir:

  1. Crear una nueva red virtual de Azure y asignarle un direccionamiento. En nuestro ejemplo 172.16.0.0/24.
  2. Crear máquinas para hospedar los siguientes servicios: SoftEther VPN (Linux), NPS (Windows), ADDS (Windows). Configurar todas las IPs privadas como estáticas.
  3. Configurar SoftEther VPN de la siguiente manera:
    1. Local Bridge hacia un adaptador TAP.
    2. Autenticación basada en RADIUS contra el servidor NPS.
    3. Activar protocolos L2TP/IPsec y SSTP. Opcionalmente podemos activar OpenVPN.
    4. Generar los certificados necesarios para SSTP y distribuirlos en los clientes que vayan a acceder. Recuerda que deben coincidir con el nombre del dominio al que conectas.
  4. Elegir un direccionamiento para nuestro adaptador TAP y asignarle una IP dentro de ese direccionamiento. En nuestro ejemplo 172.17.0.0/24 y el adaptador 172.17.0.1.
  5. Instalar y configurar un servidor DHCP (a mi me encanta dnsmasqque debe ejecutarse tras arrancar SoftEther VPN para que exista la interfaz TAP. Esto es importante porque sólo debe estar enlazado (binding) a la interfaz TAP y NUNCA a eth0, donde entraría en conflicto con el de Azure. Debe servir IPs en el rango del adaptador TAP.
  6. Activar IP forwarding en la máquina Linux en /etc/sysctl.conf.
  7. Activar IP forwarding a nivel de Azure en la máquina virtual Linux.
  8. Crear una UDR que haga que el tráfico para 172.17.0.0/24 se dirija a la IP privada de la máquina virtual con SoftEther.
  9. ¡Listos para funcionar!
Explicándolo en directo

Alberto Marcos y servidor explicamos y demostramos todo esto en directo en la Global Azure Bootcamp 2016. Si te la perdiste tienes la oportunidad de ver en HD la grabación de la sesión justo aquí: https://channel9.msdn.com/Events/Microsoft-Spain-Events/Global-Azure-BootCamp-2016/Construyendo-una-VPN-Point-to-Site-con-autenticacin-RADIUS-y-AD-en-Microsoft-Azure

Happy networking!

DiskSpd, el sucesor de SQLIO

A la hora de medir el rendimiento de una unidad de almacenamiento, una de las herramientas más útiles y fiables (en entornos Windows) era SQLIO. A pesar de lo que su nombre pueda indicar, esta herramienta no servía para medir la E/S generada por una consulta SQL, sino para obtener medidas de rendimiento de disco. Sin embargo, después de algunos años entre nosotros, se podían apreciar señales de que poco a poco se estaba quedando fuera de su tiempo.

Entra DiskSpd

Finalmente, y tras su última actualización a finales del 2015, SQLIO fue retirado, y reemplazado por una nueva herramienta: DiskSPD. Al igual que su predecesor, se utiliza para obtener métricas de rendimiento de unidades de almacenamiento, pero con un conjunto de utilidades adicionales que lo convierten en algo mucho más útil. Además, y para los aficionados al Software Libre, su código fuente está disponible para descarga en GitHub, con una licencia MIT.

Ahora bien, entre todas las funciones, hay una característica particularmente interesante para los que desarrollamos scripts PowerShell: DiskSPD puede volcar la salida en formato XML. Esto es importante, porque facilita enormemente el procesado masivo de datos obtenidos mediante la ejecución de tests de diskspd.

Dentro de la carpeta de GitHub, hay un conjunto de scripts denominados VMFleet, que permite hacer operaciones y tests de forma masiva en máquinas virtuales, pero para aquellas personas menos ambiciosas que se conforman con testear el rendimiento de una única unidad, acompaño el artículo con un par de pequeños scripts para ejecutar baterías de tests. Obviamente, se pueden personalizar los parámetros de DiskSpd para simular lo más fielmente posible la carga de trabajo del servidor destino, pero como ejemplo ilustrativo basta.

El primero, lanza n ejecuciones de diskspd, bajo un cierto set de parámetros y recopila la salida en una serie de archivos XML en una carpeta especificada. Con $iteraciones podemos especificar el número de repeticiones del experimento, que se guarda en la carpeta especificada con $tag (que además personaliza el nombre del fichero xml generado). El parámetro $threads se usa para especificar cuántos hilos de trabajo deseamos lanzar simultáneamente, con lo que podemos poner, por ejemplo, un hilo por core del sistema.

El segundo script toma los XML de dicha carpeta, y calcula la velocidad media (en MB/s) de rendimiento del disco en base a los datos recopilados. Teniendo en cuenta que el rendimiento de un sistema puede variar a lo largo del tiempo por múltiples circunstancias, lo más realista es realizar varios experimentos idénticos, y promediarlos.

Process-SpeedData se encarga de promediar la velocidad de lectura/escritura y mostrar en pantalla el resultado, a partir de los archivos XML generados por el script anterior, para ello simplemente se le pasa como parámetro la carpeta que se desea escanear, y el script leerá y promediará la información de todos los XML que encuentre en la misma.

Resumiendo…

Aunque SQLio nos ha acompañado durante años y sigue siendo igual de funcional que antes, ahora disponemos de una herramienta igual de potente, más flexible y que además es Open Source. La capacidad de generar la salida en formato XML aquí es una característica diferenciadora que permite incorporar muy fácilmente la salida de información en scripts PowerShell que procesen los datos de rendimiento generados (latencia de acceso, velocidades medias, etc).

MDT. Fases de una Standard Task Sequence

MDT (Microsoft Deployment Toolkit) es una herramienta muy útil en el entorno empresarial para el despliegue de sistemas operativos y aplicaciones. Nos permite centralizar la distribución de imágenes desde un entorno controlado. Su gestión se basa en “Deployments Share” o carpetas compartidas, con una estructura predefinida y, que contiene todos los recursos a implementar. Una de estas subcarpetas dentro de la aplicación es “Task Sequences”, en la que se definen todas las acciones a ejecutar. Las tareas más empleadas (entre otras), son la instalación de sistemas operativos (“Standard Client Task Sequence”), instalación de aplicaciones (“Custom Task Sequence”) y la captura de una  imagen generalizada (“Sysprep and Capture”)

Internamente, cada “Task Sequence” se compone de una serie de pasos ordenados, que permiten el desarrollo de la tarea. Cada tipo de “Task Sequence” tiene  predefinidos una serie de pasos. Podemos decir que este elemento (las “Task Sequences”), son el “core” de nuestra implementación y, por tanto es muy importante saber cómo funcionan  si queremos añadir personalizaciones de forma apropiada. Es por ello, que esta semana voy a comentar este punto, poniendo como referencia la tarea de implementación de sistemas operativos.

Standard Task Sequence

Cuando instalamos un Sistema operativo, nuestro sistema pasa por 7 fases bien delimitadas: inicialización, validación, captura de estado, preinstalación, instalación, post instalación y estado de restauración. En MDT, detras de cada tarea predefinida, suele estar (en la mayoría de los casos), un script ubicado en la carpeta Scripts de la implementación.

001

Fases

La tarea de instalación de un Sistema operativo se compone de las etapas que se describen a continuación:

  • Inicialización: En esta fase realiza una recopilación de información del equipo y, toma las reglas definidas en customSettings.ini, para ello hace una llamada al script ZTIGather (script que se ejecutará también para obtener información en las fases de preinstalación y restauración)
003
  • Validación:  Se establecen los requisitos de memoria y de sistema operativo, chequea la BIOS (ZTIBIOSCheck.wsf), y si todo está correcto, pasa a la siguiente fase.

004

  • Captura de estado: En caso de  haber seleccionado la opción para migrar los datos del usuario, lo realiza aquí.
005
  • Preinstall: Realiza la validación de los requisitos previamente establecidos, formatea y particiona nuestro disco duro, y carga los drivers.
006

 

  • Install: Efectúa la instalación del sistema operativo.

007

  • Post Instalación: Instala los drivers previamente cargados, copia los scripts necesarios para la consecución de tareas necesarias en la carpeta y añade los archivos a la partición de recuperación.

008

  • Estado de restauración: es en esta parte donde podremos realizar la mayoría de personalizaciones, como instalar features, agregar scripts de configuración de software, etc. También es aquí donde se instalan las aplicaciones y se añade el equipo a dominio. Como subfase dentro de PostInstall, está la realización de una imagen .wim, en esta parte se copiarían al equipo los archivos necesarios para ejecutar sysprep y para posteriormente capturar la imagen del sistema.009

En este post, me he enfocado en la tarea de instalación de un sistema operativo, pero cada tipo de tarea tiene sus propios pasos que debemos entender; y, con este pequeño apunte me despido.. ¡Hasta el próximo post! ¡Feliz despliegue! :)

Migramos a Geeks.ms

Ante todo, presentarme. Me llamo Carlos Chacón y me he incorporado recientemente al equipo de administración de sistemas internos en Plain Concepts. Aquí os hablaré principalmente de infraestructura, networking, DevOps, Azure, PowerShell, tecnologías Microsoft y un largo etc.

Me considero humildemente todo un geek, y por ello mismo es para mi un honor anunciaros que hemos migrado todos los blogs de nuestros equipos a la comunidad Geeks.ms, una iniciativa de Plain Concepts patrocinada por Microsoft.

Geeks.ms es una comunidad conformada por entusiastas y profesionales de tecnologías Microsoft. En ella podréis encontrar expertos que os tendrán al día en tantas areas como productos pone a vuestra disposición Microsoft y más. Visitando Geeks.ms encontrarás las últimas noticias y eventos de la comunidad Windows y .NET.

Previamente nos podíais encontrar en enterprise.plainconcepts.com. Ahora nos podéis encontrar aquí, geeks.ms/enterprise, sin por ello haber perdido acceso a todos nuestros enlaces anteriores.

Encantado de saludaros, pronto tendréis noticias mías. ¡Saludos!

Azure MP para SCOM 2012

En esta nueva entrada de nuestro blog hoy vamos a comentar una de las mejores soluciones para la monitorización de Microsoft Azure. La integración del nuevo Management Pack de Azure (Techinical Preview) para SCOM.

Antes de empezar a comentar las posibilidades de esta integración, vamos a comentar algunas preguntas básicas.

¿Qué es Microsoft Azure?

Microsoft Azure (anteriormente Windows Azure y Azure Services Platform) es una plataforma ofrecida como servicio y alojada en los Data Centers de Microsoft. Anunciada en el Professional Developers Conference de Microsoft (PDC) del 2008 en su versión beta, pasó a ser un producto comercial el 1 de enero de 2010. Windows Azure es una plataforma general que tiene diferentes servicios para aplicaciones, desde servicios que alojan aplicaciones en alguno de los centros de procesamiento de datos de Microsoft para que se ejecute sobre su infraestructura (Cloud Computing) hasta servicios de comunicación segura y federación entre aplicaciones.

¿Qué es Microsoft SCOM?

System Center Operations Manager (SCOM) es un sistema de administración del centro de datos interplataforma, para sistemas operativos e hipervisores. Utiliza una interfaz simple que muestra información del estado, la salud y el rendimiento del sistema. También proporciona alertas generadas de acuerdo a la identificación de situaciones de disponibilidad, seguridad, configuración o rendimiento. Funciona con Microsoft Windows Server y servidores basados en Unix.

¿Dónde puedo descargar el MP?

https://www.microsoft.com/en-us/download/details.aspx?id=50013

¿Cuáles son los requerimientos mínimos?

· SCOM 2012 SP1 o superior.

· Todos los management servers en el pool tienen que tener salida a Internet.

· Todos los management servers tienen que tener instalado .Net Framework 4.5

· La estación de trabajo que use la consola tiene que tener instalado .Net Framework 4.5 o superior.

· Para recopilar eventos y datos de rendimiento de Azure VM, Web roles y Worker roles tiene que estar habilitado los diagnósticos de Azure.

Proceso de instalación.

Antes de empezar a configurar la integración, necesitamos una cuenta con permisos de administrador de la suscripción o suscripciones a monitorizar. Podemos crear nuevos administradores de la suscripción desde Settings->Subscriptions.

Una vez que dispongamos del usuario administrador de las suscripciones, podemos proceder a la descarga e instalación del Management Pack de Azure de Marzo de 2.016 (Technical Preview).

Una vez importado el Management Pack, tenemos que sumar la suscripción de Azure:

1. Desde la consola de SCOM, vamos al panel de administración y navegamos hasta el nodo de Microsoft Azure.

image

2. Seleccionamos la opción “sumar una suscripción” para conectar Microsoft SCOM con Microsoft Azure e introducimos los credenciales del administrador de la suscripción de Microsoft Azure.

image

3. Elegimos la suscripción a integrar.

image

Una vez asociada la suscripción de Microsoft Azure con SCOM tenemos que seleccionar los elementos a monitorizar de nuestra suscripción de Microsoft Azure.

1. Navegamos hasta el panel de Authoring en la consola de SCOM y seleccionamos la plantilla de monitorización “Microsoft Azure”.

image

2. Elegimos un nombre para el nuevo monitor y un Management Pack donde guardar los cambios.

image

3. Seleccionamos la suscripción de Microsoft Azure a monitorizar.

image

4. Seleccionamos los servicios que queremos monitorizar. En la columna “Instance Count” se muestra las instancias que hay sobre cada servicio.

image

5. A través de “Exclude List” podemos excluir instancias que no queremos monitorizar, ya que por defecto, se monitorizan todas las instancias. Podemos usar caracteres comodín al estilo de *, ?. Cómo por ejemplo: Windows*VM.

image

6. Por último seleccionamos los contadores que queremos activar.

Para finalizar os muestro algunas capturas de un entorno en producción siendo monitorizado por el Management Pack de Azure para Microsoft SCOM.

Estado del grupo de recursos.

image

Vista de topología.

image

Estado de las máquinas virtuales.

image

Espero que esta entrada en el blog os haya sido útil.

José María Genzor.