How to: Windows Azure HPC Scheduler: Getting started & “Parametric Sweep” model

HPC

Muy buenas,

Después de unos cuantos días con este post el borrador, no quiero irme de vacaciones sin completarlo.

Una de las ventajas que ofrece el Cloud Computing es el alto procesamiento/rendimento, es decir, aprovechar la elasticidad que este nos ofrece para sacarle gran partido. Ya he comentado ciertos de estos aspectos en posts anteriores: Autoscalado, Caching I y Caching II, sin embargo, en este caso hablaremos de HPC (High Performance Computing). Microsoft ya dispone de esta tecnología en On-Premisse (Windows HPC Server 2008 R2) desde hace ya bastante tiempo, para Azure (a partir del SP1. La versión más reciente es la SP3), relativamente poco, y menos aún, si hablamos de tener todo en la nube, incluso el “Head Node”. La diferencia entre ambos, radica principalmente en el despliegue.

Antes de comenzar a trabajar con Windows Azure HPC, es necesario tener claros los conceptos en los que este se apoya (y que puede profundizar aquí):

1) La ventaja de utilizar HPC sobre Windows Azure nos permite pagar sólamente por lo que usamos (“Pay as you go”) y  Elasticidad.

2) Windows Azure HPC Scheduler: Cluster HPC completamente en Azure y cuya arquitectura es:

  • Head Node: Gestión y scheduling de Jobs para el cluster HPC. Proporciona “Failover”, control y acceso a los recursos del Cluster. Compute Node: Realiza las tareas asignadas por el “Job Scheduler”.
  • Job Scheduler: Colas de Jobs y tareas asociadas. Asigna recursos a estos Jobs, inicializa las tareas en los “Compute Nodes” y monitoriza el estado de los Jobs, tareas y “Compute Nodes”.
  • Broker Node: Actúa como intermediario entre la aplicación y los servicios.  Balancea la carga de peticiones a servicios y finalmente retorna los resultados a la aplicación.

Azure-HPCimage

3) Modelos de aplicación:  Sabiendo que  Windows HPC SP3 soporta Jobs que permiten la integración de diferentes escenarios, y donde cada Job tiene sus propiedades, herramientas y APIs (con sus modelos de desarrollo y despliegue), los modelos de aplicación soportados son:

  • Parametric sweep:>  Tareas independientes y sin interacción entre ellas. No se hace uso del “Broker Node”.  Basicamente, reciben datos de entrada, los procesa y retorna el resultado almacenándolo en un “storage” accesible por los clientes. (Ej.: Windows Azure Storage o SQL Azure).
  • MS-MPI (Microsoft Message Passing Interface): Intercambio de mensajes usado en aplicaciones paralelas (ejecutables que corren en multiples cores o nodos y que tienen dependencia entre ellos y necesitan comunicarse). Usado principalmente para el intercambio de resultados intermedios.
  • SOA Applications. Orientación a servicios  basada en WCF. Aplicaciones candidatas para el escalado en un cluster.  La obtención de resultados puede producirse de manera:
    • Interactiva”: Intercambio de mensages request/response.
    • Durable”: Para una petición asíncrona, los resultados puedan ser consultados en cualquier momento incluso después de haber estado desconectado.  Para ello, el “Broker” hace uso de colas MSMQ.
  • Microsoft Excel Offloading.
    • UDF’s: (XLL)
    • WCF Services Call: (VSTO)
      •  

image image

4) Prerrequisitos

Para poder trabajar con Windows Azure HPC Scheduler son necesarios algunos prerrequisitos:

  1. Windows Azure SDK (v1.7)
  2. Windows Azure HPC Scheduler SDK (v1.7)
  3. HPC Pack 2008 R2 Client Utilities Redistributable Package with Service Pack 4. Necesario para interactuar con  el “Job Scheduler”
  4. [Opcional] HPC Pack 2008 R2 MS-MPI Redistributable Package with Service Pack 4 Ejecución de aplicaciones MPI sin tener que crear un cluster HPC.

IMPORTANTE: Me gustaría aclarar en este punto, que Windows Azure HPC no dispone de un portal propio para la adminstración del cluster HPC. Sin embargo, este se genera automáticamente durante el despliegue de la aplicación. Será necesario incluir un “Web Role” e insertar la instrucción “<VirtualApplication name=”Portal”… dentro de nuestro fichero “ServiceDefinition.csdef”  tal y como indico a continuación:

   1: <WebRole name="FrontEnd" vmsize="Small">

   2:     <Sites>

   3:       <Site name="Web">

   4:         <VirtualApplication name="Portal" physicalDirectory="C:Program FilesWindows Azure HPC Scheduler SDKv1.7hpcportal" />

   5:         <Bindings>

   6:           <Binding name="HPCWebServiceHttps" endpointName="Microsoft.Hpc.Azure.Endpoint.HPCWebServiceHttps" />

   7:         </Bindings>

   8:       </Site>

   9:     </Sites>

Se trata simplememente de levantar el portal HPC que incluye el SDK HPC.

5) Configuración y Deploy en Azure PARAMETRIC SWEEP

5.1) En primper lugar, y partiendo del ejemplo Parametric Sweep, necesitaremos realizar algunos cambios para adaptarlo a las últimas versiones (“v1.7” tanto de “Windows Azure SDK” como de “Windows Azure HPC Scheduler SDK”):

  • ServiceDefinition.csdef: Cambiar la versión “v1.6” por “v1.7”: <VirtualApplication name=”Portal” physicalDirectory=”C:Program FilesWindows Azure HPC Scheduler SDKv1.7hpcportal” />
  • AzureSampleService: BuildEvents – Pre-Build Event:  Cambiar la ruta del “cspack” para que pase a ser esta: “C:Program FilesMicrosoft SDKsWindows Azure.NET SDK2012-06bincspack.exe…
  • AppConfigure – BuildEvents – Post-Build Event: Cambiar la versión v1.6 por v1.7: “HKLMSoftwareMicrosoftWindows Azure HPC Schedulerv1.7 …”.
  • AppConfigure.CreateCscfgFile(cs). Comentar la línea  “config.EnableL2H();”.  Al ser un elemento beta es posible que haya sido eliminado en la v1.7, como puede verse aquí.

5.2) El deploy de un entorno HPC requiere varios pasos y tener claros ciertos aspectos de preparación y configuración. Todos ellos podemos encontrarlos identificados aquí. Debido a todos estos pasos, como veremos en los ejemplos, no optaremos por la publicación estandar que ofrece Visual Studio.

Para este ejemplo, o cualquier otro, los pasos a seguir para la configuración y despliegue del HPC en Azure son siempre los mismos. Es más, cada una de nuestras nuevas aplicaciones que hagan uso de Windows Azure HPC podrían contener siempre un solution Folder llamado “Deployment” con los proyectos “AppConfigure” y “CertificateGenerator” encargados de la configuración y despliegue. Adicionalmente, también contaremos con un “Web Role” destinado al Portal según he comentado anteriormente.

Los pasos son los siguientes:

  • Abrir el el proyecto desde Visual Studio 2010 ó 2012 RC
  • Compilar la solución.
  • Haber generado un “Hosted Service” desdel el portal de azure. Para este ejemplo “elguerrehpc”.
  • Ejecutar del Proyecto “AppConfigure” e introducir los parámetros de configuración para la subscripción de Azure a utilizar
  • Configurar (“Configure”) y cuando esta haya finalizado, Publicar (“Publish”). Esta acción creará un Storage y una BBDD SQL Azure, ambos con el mismo nombre del host, “elguerrehpc” en nuestro caso.

image

5.3) Durante la publicación, entre los mensajes asociados al “progress bar”, aparecerá, “Coping HPC package to blog storage…”, que nos hará esperar unos cuantos minutos y, tras el, veremos este otro, “Creating Azure Deployment…”, lo que significa, que si vamos al portal de Azure veremos el progreso de creación de los tres nodos configurados: Head Node, Compute Node y Frontend.

image

5.4) Tras varios minutos, tendremos nuestro despliegue listo para que comience automáticamente la creación de los nodos y configuración del HPC en Azure.

Finalizado el despligue, podremos acceder a la url: https://elguerrehpc.cloudapp.net, donde accederemos a una pagina de bienvenida(nuestro Web Role) desde donde podremos realizar la conexión remota con el Head Node o acceder al portal de HPC Scheduler. Importante, siempre con HTTPS.

image

Para este enlace al portal, en la página “Default.aspx” de nuestro “Web Role” se ha incluido una instrucción similar a la siguiente y que se corresponde con la configuración indicada anteriormente en el punto (4):

<a href="~/portal" runat="server" ID="PortalButton1" >

De la misma manera, el link “remote desktop connection” habrá que generarlo explícitamente en la página “Default.aspx” aunque requiere de un poco más código que veremos en alguno de los ejemplos. No obstante, y como siempre, podremos acceder a través de Portal de Azure.

5.5) Mediante esta conexión remota  podremos acceder directamente a la VM donde comprobaremos:

  • Herramientas de HPC instaladas y Dlls y ejecutables desplegados según cada nodo/role.

image

  • En el “Head Node”, adicionalmente, podremos comprobar la ubicación física del Portal de HPC.

image

  • Variables de entorno relacionadas con HPC y posiblemente necesarias para algunas de nuestras aplicaciones/procesos.

image

  • HPC Job Manager:

image

6) Ejecución de un Job

Mediante el link https://elguerrehpc.cloudapp.net/portal, tendremos acceso directo al cluster que hemos configurado y desplegado sin tener que acceder a alguna de las maquinas virtuales en particular.

image

A partir de aquí, seguiremos los siguientes pasos:

Importante: Recuerda incluir un “*” en el paso 2, en “Commmand Line”.

6.1) Submission Pages

imageimageimageimage

image

6.2) New Job

image

imageimage

7) Resultado de la ejecución del Job

Una vez hemos realizado el “Submit” según el paso anterior, si accedemos al listado de “My Jobs” y seleccionamos “CPUSpinner” veremos que:

  • Se han ejecutado las 1000 tareas correctamente en 18 minutos.

imageimage

imageimage

Si ahora dejamos sólo una instancia de Azure para el “Compute Node” la duración de ejecución del Job será del doble (30min para ser exactos, es decir 12min más), y a la inversa, es decir si subimos el número de instancias, el tiempo será menor.  De esta manera y extrapolando estos resultados a aplicaciones/procesos en el mundo reaal y con altos requerimientos en cuanto a los tiempos de ejecución, obtendríamos una ganancia que de otra forma sería casi imposible.

Aunque esto podemos conseguirlo con HPC en un datacenter en “On-Premise”, si el numero de máquinas necesarias fuera elevado, podríamos no disponer del hardware adecuado  o incluso no disponer de espacio para más máquinas virtuales en un entorno Virtual, teniendo en cuenta además, la configuración necesaria que ello conlleva. Por tanto, la escalabilidad se complicaría teniendo que esperar hasta recibir físicamente la(s) nueva(s) máquina(s)/servidor(es). Es aquí, donde Windows Azure una vez más aquiere gran importancia. Con Windows Azure este problema dejaría de existir y, si este Job se lanzara en determinados momentos (una vez al día, o a la semana, o al més), sólo pagaríamos por el tiempo de uso, así que el ahorro de costes podría llegar a ser enorme.

Finalmente se ha alargado un poco el Post, pero creo que la situación lo ha requerido y ha merecido la pena. En posts sucesivos iremos viendo cada uno de los restantes modelos de aplicación que soporta Windows Azure HPC Scheduler.

 

Saludos @Home & Happy HPC Coding !
Juanlu, ElGuerre

“PINGing…” desde “On-Premisse” hacia máquinas virtuales de Windows Azure

imageMuy buenas,

Seguro que en más de una ocasión has intentado hacer un ping desde tu PC, o desde una máquina “On-Premisse” hacia una máquina concreta en Windows Azure. Para ello, y, aunque no es una buena practica en situaciones normales, es necesario habiltar una de las reglas de Firewall. Como puedes imaginar, ahora con las nuevas carácteríscias de Azure y, concretamente, gracias a la persistencia de VM’s, bastará con hacerlo de manera manual. Claro está, esto será válido siempre que estés trabajando en un tipo de Cloud “IaaS”.

Para hacerlo en un modelo de Cloud “PaaS”, seguiremos los siguientes pasos:

  • Crearemos nuestro proyecto  de tipo “Clolud” desde Visual Studio 2010 ó 2012.
  • Haremos uso de las “Startup Tasks” tal y como ya comentaba en este post anterior, con la diferencia en este caso, de que nuestro fichero “Startup.cmd” tendrá el siguiente contenido y que no necesitaremos ningún otro instalable adicional:
   1: Echo Enable ICMP

   2: netsh advfirewall firewall add rule name="ICMPv6" dir=in action=allow enable=yes protocol=icmpv6

   3: exit /b 0

  • Configurar “Windows Azure Connect” (“Virtual Network”).
  • Listo. A partir de ahora, ya tendrás visibilidad directa con  tu máquina virtual de Azure. No sólo para hacer un Ping, si no para acceder a ella directamente, recueda, ¡ahora tienes una “VPN” !

IMPORTANTE: La gran ventaja de hacer esta labor como “Startup Task” es el automatismo ante posibles reciclados de las máquina de Azure.

Y, adicionalmente como siempre, puedes encontrar más detalle aquí.

Saludos y a seguir esperando las vacaciones…
Juanlu