La transformación tecnológica en la empresa

Hola a todos,
Para el equipo de Ncora es un placer recibir colaboraciones y consultas en el blog. Nos encanta que mes a mes nos escribáis para contarnos vuestras dudas e inquietudes :)

En esta ocasión, nos gustaría compartir con todos vosotros la colaboración ganadora del concurso mensual en el mes de mayo. Francesc Bernal, el responsable de tecnologías y sistemas de CIFDSA (empresa propietaria de la marca Venca), nos cuenta como se ha transformado todo el departamento tecnológico de su compañía en un tiempo récord gracias a la virtualización.

¡Muchas gracias a todos por participar! ¡Esperamos que disfrutes de tu Kit de Ncora y de tu nuevo iPod, Francesc!

Si hay alguna cosa que sin la virtualización hubiera sido imposible conseguir, es la transformación que hemos experimentado en el departamento de TI de CIFDSA, empresa propietaria de la marca Venca en los últimos 10 meses.

Haciendo un poco de historia, he de decir que nosotros ya empezamos en esto de la virtualización allá por el año 2004, con un par de servidores IBM x3650 y una cabina IBM DS4300 (también conocida como Fast600) para virtualizar con VMware el correo y poco más. Venimos del mundo del AS/400, hoy en día conocido como IBM i, donde todo nuestro core empresarial (ERP, CRM, etc) ha estado viviendo allí dentro bien encapsulado y desarrollado en perfecto RPG, mientras que nuestra web ha ido creciendo por su parte de forma casi aislada de nuestros sistemas en un conocido hosting. A día de hoy, seguimos confiando ciegamente en VMware puesto que es el entorno que conocemos, y el que ha hecho posible nuestro desarrollo.

Poco a poco fuimos creciendo en virtualización y la consolidación definitiva nos la dio Ncora en 2010, instalándonos nuestro vCenter, asegurándonos nuestra instalación de Directorio Activo de Windows Server 2008 R2 y migrando nuestro correo de Domino a Exchange 2010, traspasándonos todo el conocimiento necesario para sobrevivir en este entorno. Todo esto bajo un entorno de PowerEdge Blades Dell y una cabina de discos Dell AX4-5.

Por aquella época, todavía seguíamos con dos mundos separados y con casi una única máquina crítica: nuestro flamante AS/400. Esto fue así hasta que, a raíz de un cambio de estrategia de la empresa, acompañado de un cambio de dirección en el Departamento de TI se decidió algo tan simple como:

La Web y el core no pueden vivir de forma separada, y hay que hacer desarrollos únicos que sean usados por ambos entornos.

Aquí empieza lo que comentaba al principio, la necesidad de llevar a buen puerto lo que esta frase significa, hecho que hubiera sido imposible sin tener una infraestructura virtualizada que diera respuesta a semejante reto.

¿Por qué? Pues por todo esto: 

• La forma de hacer convivir los dos entornos, se decidió realizarla mediante servicios web o “web services”( en adelante WS ), desarrollados en Microsoft .NET por el equipo de Venca. Por lo tanto, los servidores que los alojen serían Windows 2008 Servers con Microsoft IIS 7. La web atacaría directamente a estos servicios, los cuales deberían realizar el acceso a la base de datos de nuestro AS/400 en DB2 y devolver la respuesta a los programas de la web. Por arquitectura, los WS estarían ubicados cerca de la Base de Datos. 

• Lo primero que hicimos en Sistemas fue diseñar la arquitectura y crear los primeros servidores de desarrollo. Eran servidores “independientes”, y hasta la tercera versión de los mismos no nos dieron el OK los equipos de desarrollo. 

• Cuando los desarrolladores tuvieron sus primeras versiones de WS listas, pasamos a implementar el entorno de pre-producción. Aquí se introdujo la dificultad de tener varios servidores balanceados que soportaran una determinada carga de peticiones, según requerimientos testeados en pruebas de estrés. 

• Como el presupuesto para balanceadores era limitado (cercano a 0), no podíamos contar ni con F5, ni con Barracuda ni similares. NLB de Microsoft no funcionaba como los desarrolladores querían, con lo que nuestra salvación fue HAproxy, un servicio de balanceo en Linux (en nuestro caso sobre Ubuntu Server) que nos da todo lo que querían los desarrolladores, a coste 0 (cero Euros y cero problemas!!!)

• Una vez superadas todas las pruebas de estrés de las aplicaciones y después de varias versiones de máquinas W2008, tuvimos montado el entorno de pre-producción tal como lo queríamos.

• Inmediatamente, tuvimos que crear el de producción, pero para eso están las plantillas, los clones y los “Delete from Disk”, para tener el entorno creado en una mañana. 

• A todo esto hay que añadir, que entre medio, se migró la plataforma web de hosting, también virtualizada con VMware, otro gran reto para los equipos para hacerlo de forma que los clientes notaran las mínimas paradas posibles. Todo este proceso conseguimos culminarlo en aproximadamente 6 meses, y actualmente seguimos transformando nuestro entorno día a día.

• Paralelamente, la transformación no fue sólo de formas de programar o entender los sistemas, sino que los equipos han transformado su forma de trabajar, adoptando metodologías ágiles como Scrum y Kanban, desarrollando con Pair Programming y otros. ¡Ha sido casi un cambio cultural!

• Como resultado de todo ello, nuestra web está integrada con nuestros sistemas de core cosa que también nos ha permitido publicar nuestra plataforma web para móvil, para satisfacción de todos.

• ¿Os imagináis todo este proceso con máquinas físicas? ¿Cuánto tiempo hubierais dedicado a manejar presupuestos de hardware? ¿Qué hubiera ocurrido en el momento en que una versión de máquina no cumplía con las expectativas del proyecto? ¿Hubiéramos podido ni tan siquiera pensar en un proyecto así?

¡Muchas gracias de nuevo Francesc por esta interesante reflexión!
Recordad que si estáis interesados en participar en nuestro concurso mensual, no tenéis más que enviarnos artículos o consultas y tendréis la posibilidad de ganar un estupendo iPod y un Kit de camisetas, bolis, libretas y mochilas de Ncora.

¡Buena semana a todos!

vSphere CPU Affinity

Hola,

Hoy daremos un poco de luz a una consulta formulada por Raúl Mata, desde Hernani (Gipúzkoa):

Buenos días, 

Te pongo en situación. Tenemos una granja de servidores terminal server 2008 r2 virtualizados con vmware. Tenemos las cpus configuradas por afinidad para que mejore el rendimiento ya que con 4 cpus por máquina virtual si no poníamos afinidad había mucho ready y los usuarios se quejaban de lentitud. Tenemos asumido que el core 0 en la versión 4.1 de vmware lo utiliza para procesos del host y no lo tenemos en máquinas de explotación. 

La pregunta es tenemos que asumir que el core 0 la tenemos perdida para maquinas en explotación para este entorno? O si ponemos esxi (que el consumo es menos) o subimos de la 4.1 a la 5 mejora el rendimiento del host? 

Un saludo,

Raúl Mata

En respuesta a la consulta formulada por Raúl, comentarle que a priori y sin conocer el dimensionamiento hardware de su entorno ni la cantidad de servidores Remote Desktop Services en Windows Server 2008 R2 que tiene, le aconsejaría no usar la afinidad de CPUs.

Aunque tiene sus virtudes, son más las desventajas que suele conllevar. Por eso mejor evitar tal función a no ser que no haya otra forma mejor de remediar los valores altos de Ready.

En los siguientes enlaces verás la lista, según el fabricante, de los principales efectos no deseados. Verás que se calcan tanto en versión vSphere 4.1 como en vSphere 5.

Tiene incluso efectos adversos en máquinas virtuales ubicadas en en un clúster HA o HA & DRS. También en la funcionalidad de vMotion.

Posibles soluciones a esta problemática podría ser optar por el uso de los CPU Shares o de Resource Pools donde ubicar los servidores aplicando los Shares correspondientes. Dejando estos en High para las máquinas RDS y en Low para el resto.

Si la aplicación de los Shares no resultara suficiente, también puedes llegar a aplicar Reservas que garantice ciclos de CPU para estas.

Se puede dar el caso que la problemática radique en una muy alta carga de CPU constante (>70%) en todos los hosts, lo que podría indicar que la adición de un nuevo host aliviaría el conjunto de la infraestructura.

De vital importancia resulta remarcar que no siempre la asignación de mayor número de vCPU a las máquinas virtuales va a resultar en un mayor rendimiento de estas. Es muy recomendable tener un mayor número de máquinas con asignación de hardware más modesto que no pocas de ellas con grandes asignaciones de vCPU y vRAM.

Mediante el comando esxtop podéis revisar los valores de %RDY - %MLMTD, teniendo en cuenta que el valor dado en %RDY tendrá un significado distinto en función del número de vCPU asignadas a cada máquina virtual.

Os aconsejamos encarecidamente la actualización a ESXi5, pues como bien comentas está más optimizada, resulta más liviana, amén de incorporar mejoras en muchos ámbitos así como la desaparición de la Service Console, vinculada al core 0.

Espero que os haya servido de orientación.

Saludos,

Utilizar directivas de grupo para controlar el comportamiento de Microsoft Office

Hola a todos,
En el artículo de esta semana utilizaremos los archivos de plantillas administrativas de Microsoft Office 2010 para controlar, de manera centralizada y usando directivas de grupo, muchos parámetros y atributos de las aplicaciones Office de los equipos de nuestros usuarios.

Podemos utilizar estas plantillas para controlar prácticamente cualquier valor de configuración de las aplicaciones Word, Excel, Outlook, etc. de los equipos cliente, permitiendo a los administradores predefinir ciertas opciones y prohibir que los usuarios cambien sus valores desde la estación de trabajo.

Uno de los valores que podemos modificar, por ejemplo, deshabilitaría el modo caché de Exchange de las cuentas de Microsoft Outlook 2010, evitando así que se generen archivos OST en los equipos de nuestros usuarios, siendo este un punto particularmente interesante en despliegues de escritorios virtuales utilizando tecnologías como VMware View.

¡Vamos allá!


El primer paso que tendremos que realizar es descargar las plantillas administrativas de Office 2010 para la versión que corresponda a nuestra infraestructura: x86 o x64. Podemos descargar ambos archivos desde el Centro de Descargas de Microsoft. Fijaos que además de los dos binarios que contienen estas plantillas, en esa misma dirección podemos descargar un fichero de Microsoft Excel que contiene una guía de referencia de todos los valores que podemos modificar usando esta extensión de la directiva de grupo.

Ejemplo de parámetros que podemos modificar

Una vez descargado y descomprimido el archivo en uno de nuestros controladores de dominio, deberemos copiar el contenido de la carpeta ADMX del paquete hasta la carpeta %systemroot\PolicyDefinitions (habitualmente esta carpeta será C:\Windows\PolicyDefinitions). Es importante respetar la estructura de directorios, incluidas las carpetas con los diferentes idiomas de Office 2010.

Copiando los archivos de plantilla al lugar adecuado

Tras realizar este paso ya podemos abrir la consola de Administración de directivas de grupo y crear un nuevo objeto de directiva. Al haber copiado las plantillas de directiva de grupo a su ruta por defecto, ya podremos ver dentro de la configuración de usuario y de equipo, en el apartado Directivas | Plantillas administrativas, ciertas configuraciones que hacen referencia a los productos incluídos en Office 2010.

Directivas de Office 2010

Si, por ejemplo, quisiéramos desactivar el modo caché de Exchange, podríamos hacerlo dentro de la Configuración de Usuario | Directivas | Plantillas administrativas | Microsoft Outlook 2010 | Configuración de la cuenta | Exchange | Modo de intercambio en caché. Allí podríamos deshabilitar el parámetro Usar el modo de intercambio en caché para todos los perfiles nuevos y ya existentes de Outlook, como se muestra en la imagen siguiente.

Cambiando una directiva de Outlook 2010

Tras vincular el objeto a la Unidad Organizativa correspondiente, los usuarios ya tendrían deshabilitada esa opción en su Outlook y no podrían modificarla desde allí. Además, cualquier cuenta nueva que crearan en su aplicación, tendría desactivada esa opción.


¡Y eso es todo!
Como veis es un procedimiento muy sencillo que nos ayudará a automatizar esas pequeñas configuraciones corporativas que siempre debemos realizar cuando llega un nuevo equipo a nuestro parqué informático. Un poco de automatización hace la vida de los administradores de sistemas mucho más feliz :)

¡Buena semana a todos!