Descripción del Escenario
Partimos de una infraestructura básica de Microsoft Dynamics AX 2009, formada por los siguientes elementos y configuraciones:
- SQL Server. Está corriendo sobre una Máquina Virtual dedicada a SQL Server, denominada VSQL08, ejecutándose sobre un Cluster de Hyper-V.
- Application Object Server (AOS). Existen dos Máquinas Virtuales dedicadas exclusivamente para AOS, denominadas VAX01 y VAS02, ejecutándose sobre un Cluster de Hyper-V. Estas dos máquinas forman un Cluster AOS sin ningún balanceador de carga dedicado (recordemos que la funcionalidad de Load Balancing de AX es propietaria, y ajena al Network Load Balancing y al Failover Cluster). Además, la máquina VAX01 es la única configurada como Batch Server.
- Application Files. Los Application Files están montados sobre la Máquina Virtual VAX01, de tal modo, que el AOS de la máquina VAX01 está configurado contra los Application Files de C:\Program Files, mientras que el AOS de la máquina VAX02 está configurado contra los Application Files de un Share existente en la máquina VAX01.
- Cliente AX. Los Clientes AX, actualmente están montados sobre los propios servidores AOS (está pendiente montarlos sobre servidores Remote Desktop Session Host), es decir, sobre las máquinas VAX01 y VAX02. El Cliente AX de la máquina VAX01 está configurado para atacar al servidor AOS de VAX01 (que es como lo deja la instalación), y el Cliente AX de la máquina VAX02 está configurado para atacar al servidor AOS de VAX02 (que es como lo deja la instalación).
La versión de Sistema Operativo de todas las máquinas del Laboratorio es Windows Server 2008 R2, excepto los controladores de dominio, que actualmente son Windows Server 2003 R2 SP2.
La versión instalada del software es Microsoft Dynamics AX 2009 RTM, es decir, sin ningún Service Pack ni ningún Rollup instalado.
La versión de SQL Server instalada es SQL Server 2008 R2 Cummulative Update 6. El motivo por el que se ha subido a esta versión de SQL Server, tiene origen en ciertas mejoras introducidas en el Cummulative Update 2, en relación con las consultas parametrizadas y el Parameter Sniffing, como se describe en el contenido de los siguientes enlaces:
Este es el scenario de Microsoft Dynamics AX 2009 sobre el que vamos a realizar la siguienter pruebas básicas de Alta Disponibilidad. Empezamos.
Prueba I - Reinicio del servicio del Application Object Server (AOS)
La primera prueba es verificar qué ocurre al reiniciar el servicio de Windows de AOS, ya sea por un simple reinicio de dicho servicio de Windows, o bien, por el reinicio de la máquina (ej: después de un parcheo de Sistema Operativo).
El resultado que hemos obtenido es que después de reiniciar el servicio AOS, al interactuar con un Cliente AX que tenía una sesión abierta sobre el AOS que se acaba de reiniciar, se mostrará un error como el siguiente: The Application Object Server is unavailable. Check your configuration and network connection and try again. A continuación se muestra una pantalla capturada del mismo.
Click sobre el botón OK (que es el único botón que tenemos), y el Cliente AX se cierra. Tras esto, podemos volver a abrir el Cliente AX, y podremos trabajar con total normalidad (al menos, esa ha sido nuestra experiencia en las pruebas realizadas).
Prueba II - Pérdida de acceso de AOS a los Application Files
La segunda prueba consiste en comprobar qué ocurre al producirse una pérdida de acceso del AOS a los Application Files, algo que nos puede ocurrir por diferentes motivos, ya sean cortes de red, o reinicio de la máquina que hospeda la Shared Folder (incluso en un Failover Cluster, al producirse el Balanceo de Grupo de Recursos que hospeda la Shared Folder de los Application Files, habrá una pequeña pérdida de servicio).
Recordemos, que en nuestro escenario, el AOS de la máquina VAX01 accede a los Application Files en local, mientras que el AOS de la máquina VAX02 accede a una Shared Folder.
En nuestra prueba, con un Cliente AX conectado al AOS de VAX02, simulamos la pérdida de acceso a los Application Files existentes en una Shared Folder de VAX01, aislando dicha Máquina Virtual (a nivel de Red) en Hyper-V. Al seguir trabajando con nuestro Cliente AX, nos encontramos con el siguiente error: Error in file: \\VAX01\AX\Application\appl\DynamicsAxGuilleSQL\axapd.aoi while reading in record = 18B9A80. Windows error: =. Error code: 64 = The specified network name is no longer available. A continuación se muestra una pantalla capturada del error en el Cliente AX.
Los resultados de las pruebas realizada, han sido que en algunas ocasiones, una vez recuperado el acceso al Share, al reintentar hemos conseguido aparentemente funcionar correctamente con el Cliente AX, pero al seguir trabajando (ej: mostrando ventanas, introduciendo datos, etc), nos hemos encontrado con errores como el siguiente en el Visor de Sucesos del AOS: EventID 110, Source Dynamics Server 01, Object Server 01: Error while Reading file \\VAX01\AX\Application\appl\DynamicsAxGuilleSQL\axSYSen-us.ali, if the problema persists your administrator should regenérate the corresponding .ali file.
Además, este error del Visor de Sucesos del AOS, lo hemos encontrado incluso en nuevas sesiones del Cliente AX (hasta que reiniciemos el servicio de AOS, momento en que hemos vuelto a la normalidad, aún con lo que implica). Otro detalle, es que al seguir trabajando sin reiniciar el AOS, aleatoriamente, se han producido mensajes de error en el Cliente AX, por ejemplo, al abrir nuevos formularios.
También, en los resultados de las pruebas realizadas, nos hemos encontrado algún caso, que por mucho que le demos a reintentar tras el anterior error de Error in file: \\VAX01\AX\Application\appl\DynamicsAxGuilleSQL\axapd.aoi while reading in record = 18B9A80. Windows error: =. Error code: 64 = The specified network name is no longer available, el Cliente AX nos volvía a mostrar el mismo mensaje de error una y otra vez, hasta que finalmente reiniciamos el servicio AOS, con lo que eso implica.
Prueba III - Configuración del Cliente AX y el Balanceo de Carga de AOS
La siguiente prueba, consiste en detener un servidor AOS, e intentar conectarse a AX con un Cliente AX configurado sólo contra dicho servidor AOS, y evidenciar qué es lo que pasa (está claro, el Cliente AX no se podrá conectar, puesto que el único servidor AOS que conoce no está disponible). Tras esto, configurar el Cliente AX con los dos servidores AOS existentes en el Cluster, y comprobar que el Cliente AX puede conectarse siempre y cuando exista al menos un servidor AOS disponible, indiferentemente de cuál sea el servidor AOS que esté vivo.
Para esta prueba, en la máquina VAX02 detenemos el servicio AOS, y seguidamente desde dicha máquina arrancamos el Cliente AX (que está configurado sólo con el AOS VAX02). Como el servicio AOS está detenido, y el Cliente AX no conoce de más servidores AOS, es incapaz de conectarse, aúnque esté funcionando correctamente el servidor AOS de VAX01. El error de conexión obtenido es el siguiente: Logon error: Connection with the Application Object Server could not be established. A continuación se muestra una pantalla capturada del mismo.
Para corregir esta situación, desde la herramienta administrativa Microsoft Dynamics AX Configuration Utility, seleccionaremos la opción Create configuration, del menú Manage.
En el diálogo Create Configuration, especificaremos un nombre para la nueva configuración (ej: HAconfig), y especificaremos también qué configuración deseamos utilizar como plantilla para crear la nueva (ej: Active configuration). Click OK.
Creada la nueva configuración de Microsoft Dynamics AX 2009, click en el botón Add de la pestaña Connection, para añadir un nuevo servidor AOS al fichero de configuración de nuestro Cliente AX.
En el diálogo Add Application Object Server Instance, especificaremos los datos de conexión al servidor AOS deseado, en nuestro caso, los correspondientes al servidor VAX01. Click OK.
Una vez añadido el nuevo servidor AOS, click Apply para guardar y aplicar los cambios.
Ahora, si ententamos conectarnos, no tendremos ningún problema, y además podremos comprobar que la sesión AX se establecerá contra el servidor VAX01 (ya que el servidor VAX02 está detenido), como se puede apreciar en la barra de título del Cliente AX (ver en la siguiente pantalla capturada).
Prueba IV – Pérdida de acceso de AOS a SQL Server
Otra prueba realizada fue simular la pérdida de acceso de un servidor AOS al SQL Server (ej: deteniendo la instancia de SQL Server, o matando las conexiones y poniendo OffLine la base de datos), algo que podría ocurrir en la práctica, por ejemplo por un balanceo del Grupo de Recursos de SQL Server, o por un parcheo de la instancia de SQL Server. Al realizar esta prueba, con un Cliente AX conectado, al intentar interactuar con el Cliente AX se obtenían errores como: Cannot select a record in LastValue (SysLastValue). UserID: , . Error accessing database connection. A continuación se muestra una pantalla capturada del mismo.
Sin embargo, en la prueba realizada, una vez restablecido el acceso a la base de datos de SQL Server, se pudo continuar trabajando con el Cliente AX sin mayor problema (ej: abrir formularios, informes, etc.).
Conclusiones
Son varias las conclusiones obtenidas de estas pruebas, algunas de ellas:
- El reinicio de un servicio AOS ha implicado la desconexión de los usuarios que estaban conectados al mismo, que debieron volver a conectarse si deseaban seguir trabajando.
- La pérdida de acceso a los Application Files desde un servicio AOS, ha implicado que dicho servicio AOS debiera ser reiniciado, y en consecuencia los usuarios que estaban conectados a dicho AOS fueron desconectados y debieron volver a conectarse si deseaban continuar trabajando.
- La pérdida de acceso a SQL Server desde un servicio AOS, no ha implicado mayor problema, es decir, tras recuperar la disponibilidad del SQL Server se ha podido continuar trabajando satisfactoriamente.
- La configuración de los Clientes AX en un Cluster de servidores AOS sin servidores de balanceo de carga dedicados, debe incluir todos los servidores AOS existentes, de tal modo, que si un servidor AOS no está disponible, el Cliente AX pueda conectarse a otro servidor AOS.
Evidentemente, la configuración de Alta Disponibilidad de un ERP como Microsoft Dynamics AX 2009, es algo delicada, por el impacto que puede llegar a tener la falta de disponibilidad de un sistema de estas características para una compañía (ej: ¿una empresa de logística en la que no pueden salir los camiones por no poder generarse los Albaranes y Rutas?).
En el presente artículo, tan sólo hemos presentado algunos detalles muy básicos a tener en cuenta en un diseño de Alta Disponibilidad de Microsoft Dynamics AX 2009, resultados de las pruebas realizadas. Existen diferentes alternativas de configuración para los componentes tratados en el presente artículo (y que quedan fuera de alcance del mismo), así como existen otros componentes a tener en cuenta (ej: Workflows), detalles que intentaremos tratar más adelante.
De momento poco más. Como siempre, confío que la lectura resulte de interés.
