Software Bancario, Parte III: Configuraciones

Ya he comentado suficientemente sobre  nuestra instalación de Flexcube – Oracle en el cluster de servidores HP con Service Guard, sin embargo me quedé con las ganas de implementar una solución mucho más “atrevida”, veamos de que se trata…

Requerimientos

Toda instalación de una plataforma tecnológica importante tiene que responder una serie de preguntas en cuanto a:

1)     ¿Los servicios tienen que estar funcionando 7x24?

2)     ¿Los servicios son críticos para el negocio? Es decir ¿si se para la operación se deja de ganar o se pierde dinero?

3)     ¿Los tiempos de respuestas son realmente críticos?

4)     ¿El negocio es tan bueno como para justificar prácticamente cualquier inversión en tecnología?

En nuestro caso las respuestas a esas preguntas eran: Si, No mucho, No mucho y No.

Bajo estas premisas para el departamento de tecnología era muy importante tener algún tipo de Cluster que garantizara el funcionamiento 7x24, por otro lado para estar preparados a una eventual explosión del negocio que volviese las respuestas “No mucho” en “Si”, queríamos tener algo que permitiese mejorara los tiempos de respuesta con relativa facilidad.

La configuración que se me ocurrió fue la de estructurar un cluster de servidores Intel con Linux, compartiendo una SAN y manejados por RAC de Oracle. ¿Cuáles serían los beneficios de una plataforma de este tipo?

1)     RAC de Oracle nos ofrecería:

a.       Implementación de un esquema Activo – Activo entre todos los servidores: se obtiene una distribución de la carga más o menos uniforme entre todos los miembros del cluster

b.       Incorporación o remoción de un servidor sin traumas: excelente para efectuar trabajos de manutención hardware y/o software así como incrementar el poder de cómputo en tiempo real

c.       Estadísticas de uso, picos, etc.: muy cómodo para hacer estudios de capacidad, detección de cuellos de botella, mal funcionamientos, etc.

2)     Linux nos ofrecería:

a.       Disminución del TCO de los servidores  ya que nos libraríamos del costo del licenciamiento del software operativo propiamente pero no así del soporte ya que es casi obligante para este tipo de instalaciones poseer algún tipo de contrato

b.       Tener en servidores de bajo costo un Unix que está prácticamente a la misma altura que HPUX, Solaris o AIX (los servidores que se necesitan para este tipo sistemas operativos son mucho más costosos que los Intel)

Para protegernos las espaldas se habrían podido adquirir servidores de una buena marca reconocida: IBM, HP, Dell con su respectiva solución SAN, todo certificado por Oracle. Una configuración relativamente económica para el año 2007 podría haber sido teniendo servidores DL380 de HP, procesador Xeón, 8GBytes de memoria RAM, dos discos SCSI de 146GBytes en RAID-1 (solo contentivos del sistema operativo), 4 tarjetas de red 10/100/1000 y la tarjeta de Fibra para la conexión a la SAN. La SAN podría haber sido la EVA 4100 que tuvimos luego. ¿Con cuanto servidores se podría comenzar? Yo diría que tres, para que al momento de remover uno para mantenimiento, todavía quedaran dos dando alta disponibilidad.

Expansibilidad

El crecimiento de esta plataforma para Oracle sería de dos tipos Vertical y Horizontal:

Vertical: Se trata de mejorar el hardware de los servidores existentes, para el ejemplo citado los DL380 de HP pueden crecer fácilmente en memoria hasta 96GBytes. Digamos que una configuración razonable para nuestro caso (sobre todo al pasar de Oracle 9i a Oracle 10g) habría sido de 16GBytes. También se puede instalar un segundo CPU para incrementar el poder de cómputo. Adicionalmente, en cuanto al espacio en disco, la SAN de HP crece fácilmente añadiendo más discos y/o más gabinetes para poder añadir discos.

Horizontal: Simplemente añadir más servidores! Esto es lo hermoso de esta solución, se añaden más servidores, se configura RAC para enterarlo de la nueva situación y de inmediato la carga se reparte con los nuevos elementos.

Desventajas

La única desventaja que le veo a este esquema es el del costo, veamos una tabla comparativa (en cuanto a las configuraciones de hardware y software) entre el esquema Activo – Pasivo y el Activo – Activo:

No tengo los números, pero estoy seguro que en cuanto a la inversión a realizar en software, sería sensiblemente más oneroso el esquema Activo – Activo. En cuanto al hardware si me parece que sería más costosa la solución basada en servidores Itanium.

	Activo – Pasivo	Activo – Activo
Cantidad de Servidores	2	3
SAN	HP EVA 4100	HP EVA 4100
Tipo de Servidores	2 x HP rx3600 -       1 x CPU Itanium -       4 x 146GB de HD -       8 x GB de RAM -       4 x 10/100/1000 de red -       2 x Tarjetas FC	3 x HP DL380G5 -       1 x CPU Xeón -       2 x 146GB de HD -       8 x GB de RAM -       4 x 10/100/1000 de red -       2 x Tarjetas FC
Sistema Operativo	HP UX	Linux Red Hat
Software de Cluster	2 x HP Service Guard	3 x Oracle RAC
Bases de Datos	1 x Oracle 10g	3 x Oracle 10g

Cluster de Servidores Unix: el proyecto

Hace algunos años el tema de poner servidores en Cluster era todo un misterio que tenía un halo mítico que los hacía posibles solo en grandes organizaciones con grandes recursos técnicos de hardware, software y humanos. Hoy en día esta tecnología se ha vuelto al alcance de organizaciones medianas y hasta pequeñas; afortunadamente tuve una experiencia muy interesante implantando un Cluster en el Banco.

Antecedentes:

Aun cuando para todo personal técnico que necesita efectuar labores de manutención en la plataforma tecnológica el Cluster es algo muy práctico ya que permite retirar de operación un servidor SIN que la operación deje de funcionar, y, aun cuando para cualquier organización tener la garantía de que la operación siga funcionando a pesar de alguna falla de hardware o de software es lo ideal, lo que finalmente empujó la implementación del Cluster fue la reglamentación tecnológica de la Superintendencia de Bancos que inclusive le pide a los Bancos que posean un centro alterno para la continuidad de la operación en caso de desastres.

Aprovechando el proceso de reconversión monetaria (que necesitaba ambientes adicionales) y aprovechando la necesidad de una renovación y ampliación tecnológica, se planteó entonces la opción de implementar un Cluster de Servidores para lo relacionado con Oracle… es decir la parte crítica del negocio.

Las necesidades:

La necesidad básica era la de tener al motor de Bases de Datos y al servidor de aplicaciones en un ambiente de alta disponibilidad ya que el banco trabaja 7x24 y efectuar labores de mantenimiento en los servidores era siempre complicado.

Las opciones:

En lo relacionado al Hardware las opciones eran solo dos (por requerimientos del proveedor del software): Sun o HP. Hasta los momentos habíamos trabajado con un servidor Sun V440 que había hecho un buen trabajo, a pesar de haber pasado por una falla misteriosa relacionada con la tarjeta de red incrustada en la tarjeta madre que lo reinicializaba de cuando en cuando al azar; los que si habían fallado muchas veces, fueron los servidores de poca envergadura Sun de la familia V65x (con procesadores Intel) y en menor escala un V240… estas fallas nos habían dejado un mal sabor ya que los servidores HP DL380 no habían fallado nunca.

La gran duda, más allá del Hardware, era la de implantar un Cluster del tipo Activo – Activo o del tipo Activo – Pasivo… Oracle posee una solución espectacular, que se llama RAC (Real Application Clusters), que implementa Clusters del tipo Activo – Activo, es decir que todos los miembros del Cluster procesan transacciones en paralelo.

Aun cuando suene paradójico, quién inclinó la balanza a favor del esquema Activo – Pasivo fue el mismo Oracle o, mejor dicho, el esquema de licenciamiento de Oracle: al seleccionar un esquema Activo – Activo, Oracle requiere que se licencie su producto para cada servidor, si además se usa RAC, éste también deberá adquirirse en forma análoga. Yo entiendo que un esquema Activo – Activo se requiera para organizaciones que tienen millares de transacciones por minuto (una telefónica, un gran banco, etc.) pero esa no era nuestra realidad, por lo tanto el costo del licenciamiento de Oracle no era justificado de NINGUNA manera por nuestro negocio.

También se exploró la alternativa de tener no solamente una pareja de servidores gemelos para el Cluster, sino la utilización de servidores virtuales en ellos, de esta manera la portatibilidad y la flexibilidad de la solución eran únicos.  La idea era tener a dos servidores físicos con Unix conectados a una SAN, cada uno de ellos con dos servidores virtuales Unix (uno para Oracle y otro para el Application Server), de esta manera se tendría, además de la alta disponibilidad implementada entre los servidores reales, la alta disponibilidad inherente a la portatibilidad de los servidores virtuales de un servidor anfitrión a otro… una solución realmente espectacular!

Una vez más los sueños se disiparon cuando comenzaron los precios… sobre todo los del software. Parece increíble que a estas alturas, todavía las grandes casas de software no contemplen casos especiales para la virtualización: Oracle licencia sus productos de acuerdo al Hardware sobre el cual están instalados SIN importar si se trata de un servidor virtual que solo utiliza una fracción, HP hace lo mismo con sus productos (incluyendo HP UX) así que la instalación de la solución sobre servidores virtuales se hizo económicamente no viable.

Así que al final se optó por la implementación de un esquema de Cluster del tipo Activo – Pasivo sobre dos servidores HP conectados a una SAN.

El siguiente diagrama ilustra lo que se deseaba implementar (bien sea con servidores virtuales o reales). Los colores tenues indican los servicios en Pasivo:

La próxima semana contaré como fue la implementación propiamente.