Software Bancario, Parte I: Flexcube

A finales del año 2002 se presentó la necesidad de tener un nuevo Sistema Central para un Banco que prácticamente estaba siendo creado desde cero (en verdad se trataba de una ampliación de un pequeño banco llamado Eurobanco que no había tenido mayor desarrollo). La dirección de tecnología se enfocó en dos casas de software: i-Flex e Infosys, ambas empresas Indias, ya que lideraban las ventas de este tipo de Sistemas para plataforma medianas (no para Mainframes). Finalmente la decisión recayó en la empresa i-Flex y su producto estrella Flexcube.

Naturalmente Flexcube está compuesto por una constelación de sistemas satelitales que pueden adquirirse o no, para este análisis nos centraremos en los tres módulos principales: Flexcube propiamente, FC@ (la interfaz Web) y Flexbranch (para las oficinas).

Flexcube:

Este sistema es el centro del banco puesto que tiene el manejo de la contabilidad, de las cuentas de los clientes, de los préstamos, etc. La gran ventaja de Flexcube, es que se trata de un sistema parametrizable lo cual, en teoría, hace que la definición de nuevos productos sea independiente de los programadores: los directores del negocio pueden dedicarse a idear nuevos productos los cuales serían implementados por los “parametrizadores” en un ambiente controlado de pruebas, luego de lo cual los cambios podrían ser puestos en producción SIN que interviniese en el proceso programador alguno! En la práctica la programación era frecuente puesto que hacían falta nuevas interfaces, cambiar pantallas de datos, idear reportes o simplemente adecuar el software a nuevos requerimientos regulatorios tales como el IDB (Impuesto al debido Bancario) o el ITF (Impuesto a las Transacciones Financieras).

Los requerimientos técnicos de Flexcube no son muy complicados:

Servidor Central: Un servidor con Unix (la aplicación está certificada con HP-UX, Solaris y AIX y las instalaciones mundialmente están distribuidas exactamente en ese orden) en el cual está Oracle (nosotros llegamos a la versión 10g). También podría estar con Windows Server pero, para este tipo de aplicaciones pesadas, me parece mucho más “sano” tener Flexcube en Unix. En un momento dado plantee efectuar la instalación sobre Linux (aun cuando i-Flex no lo tenía certificado), para ello logré hablar por teléfono con un analista “duro” de i-Flex quién me dijo: “Dame una plataforma que sirva para Oracle y Flexcube funcionará”, con lo cual la opción de Linux era válida, pero no fui autorizado a instalarla. La primera configuración que tuvimos fue con un Sun V440 con 4GBytes de memoria RAM y 4 discos de 36GBytes (luego ampliados a 5 discos de 73GBytes adicionales) con Solaris 9 y Oracle 9i.

Servidor de Aplicaciones: Naturalmente las estaciones de trabajo no se conectarían directamente al servidor Oracle, sino a un Servidor de Aplicaciones. La compañía i-Flex nos dijo que Flexcube funcionaría con “cualquier” servidor de aplicaciones, pero nos recomendaban fuertemente que fuese el de Oracle. El Servidor de Aplicaciones sería el encargado de tener las pantallas propiamente desarrolladas mediante Oracle Forms y Oracle Reports; este servidor sería el “canalizador” principal de las peticiones a la Base de Datos Oracle de los usuarios. Nuestro servidor de aplicaciones inicial fue un Sun V240 con 2GBytes de memoria RAM y 2 discos de 36GBytes también con Solaris 9 y Oracle AS 9i. La ventaja de tener a un servidor de aplicaciones, es que los usuarios que acceden al sistema NO son usuarios de Oracle sino de Flexcube, de esta manera la seguridad la implementa Flexcube propiamente. A la Superintendencia de Bancos (Sudeban) este esquema gustó mucho puesto que un hueco de seguridad permanente en las instalaciones bancarias es que un usuario, con algunas destrezas técnicas, fácilmente podría conectarse directamente a la Base de Datos y traerse todas las tablas que tiene permiso de acceder mediante un programa simple como Microsoft Access o Excel.

Estaciones de trabajo: Las estaciones de trabajo necesitaban tener Windows XP y el Internet Explorer versión 6 (con la 7 o posterior no funcionaban ni tampoco con Firefox u otros exploradores) con ciertos parámetros de seguridad “relajados”. Con la primera conexión al Servidor de Aplicaciones, la estación de trabajo se baja el Oracle Initiator gracias al cual las pantallas pueden funcionar. Dado que los reportes de Flexcube no eran muy “vistosos”, éstos se efectuaban mediante otra herramienta comercial… en nuestro caso se seleccionó Business Objects, así que las estaciones de trabajo que necesitaría ver reportes específicos de Flexcube (como por ejemplo los Estados de Cuenta o los Balances de Contabilidad) tenían que tener instalado este software.

En próxima entregas hablaré sobre los otros sistemas de i-Flex relacionados con Flexcube.

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.

Raid en discos internos de Servidores

Desde hace ya unos años, los mayores fabricantes de Hardware (IBM, HP, Dell, Sun, etc.) han incorporado a sus servidores la inteligencia para la implementación de algún tipo de redundancia: RAID-1, RAID-5, RAID-10 o de manejo adicional de los discos con RAID-0. Nuestra experiencia fue con los servidores HP de la línea DL y RX, los xSerie de IBM y algunos SunFire de Sun.

Los mejores servidores en este aspecto resultaron ser los HP: la implementación de cualquiera de los RAIDs mencionados fue realmente simplemente una cuestión de leer en pantallas lo especificado y seguir los pasos. Con IBM se consiguieron resultados parecidos pero su interfaz de disco “Standard” no tenía la facilidad de RAID-5 por lo cual, a veces, se tuvieron que adquirir otras tarjetas más completas.

Los servidores Sun del año 2004 con procesador UltraSparc eran muy buenos en este sentido (los V240 y V440), pero no así los con Intel (los V65x). Los servidores V65x no tenía la facilidad de RAID-1 “transparente” para el sistema operativo, así que se tuvo que comprar una tarjeta Intel que lo hiciese pero, increíblemente, el sistema operativo Solaris x86 no lo soportaba mientras que el Linux de Red Hat si (de esta manera se implementó Linux en 3 de estos servidores).

Lo cierto es que, una vez implementado el arreglo de discos, la falla de un disco no ocasionaba ningún tipo de interrupción: veíamos el bombillo avisando el problema, se llamaba al proveedor correspondiente (estando en período de garantía), éste venía con un disco, lo cambiaba en caliente y, automáticamente, se disparaba el procedimiento que volvía a copiar la información del disco sano al dañado sin impacto alguno para los usuarios finales.

Mi recomendación es la de no tener ni un servidor de producción en el Data Center que no tenga, al menos, el disco donde está el Sistema Operativo en espejo por hardware; de esta manera se evitan largos procedimientos de reconstrucción de un servidor por una falla a un disco. Para el caso de los discos donde se almacenan los datos, idealmente también deben tener un esquema de protección del tipo RAID-1 o RAID-5, pero, en caso de una falla que los afecte, el daño sería menor puesto que sería simplemente una cuestión de: 1) cambiar el disco dañado, 2) formatear el nuevo disco, y 3) bajar el último respaldo.

Otra recomendación es la de tener un pequeño stock de discos duros para casos de fallas ya que, debido a la constante y meteórica evolución  tecnológica, es muy probable que al cabo de 3-4 años sea difícil conseguir discos de las mismas capacidades y tecnologías de los adquiridos inicialmente.

El Sistema de Correos Electrónicos

Hay mucho que decir a la hora de seleccionar un sistema de correo para una organización, para mi lo más importante es estar claro en el uso que se le va a dar: hay necesidad de tener embebidas las agendas de los usuarios? Se desean tener control sobre los recursos a usar (salas, proyectores, etc.)? Cual es el balance entre mensajes internos y externos? Se desean listas de correos? Se necesita interfaz con SMS?...

Como se puede ver hay muchas variables que pueden inclinar la balanza hacia una solución de mensajería u otra y no nombré una vital: los costo de licenciamiento del software, de manutención y del hardware.

A lo largo de más de ocho años trabajando en una organización multi-compañía, aprendí que los usuarios usan al sistema de mensajería para recibir y mandar correos… todo lo demás, aun cuando se tenga disponible para el uso, raramente es usado… pero si muy bien pagado! Bajo esta premisa la organización mantuvo un sistema de mensajería que hizo el trabajo a la perfección: Postfix, la herramienta de correo que viene con todos los servidores Unix incluyendo Linux.

Comenzamos con un PC (literalmente) IBM Think Centre con un Pentium IV, 512MBytes de memoria RAM, un disco duro de 40GBytes y Linux Red Hat. Este servidor le dio servicio de correo a unos 200 usuarios divididos en 4 dominios distintos quienes tenían configurados sus cuentas en Outlook con IMAP. Tener configuradas las cuentas con IMAP implica que los mensajes no se descargan sino que se mantienen en el servidor: increíblemente el PC con Linux hizo el trabajo por más de dos años sin fallar nunca!

Luego evolucionamos a un ambiente mucho más robusto: un Sun V440, con 2 CPU Ultrasparc IV, 4GBytes de memoria RAM, 4 discos internos de 36GBytes y un arreglo externo de discos Sun 3330 con una capacidad de 5 discos de 72GBytes cada uno los cuales, configurados en RAID-5, dieron un espacio disponible de unos 280GBytes (era nuestro antiguo servidor de producción para Oracle); claro está con sistema operativo Solaris 10 y el mismo sistema de mensajería Postfix.

Si el PC hizo el trabajo bien, el V440 lo hizo mejor aun: se le pusieron cuota de disco a los buzones, segmentados en distintas categorías, se instaló el sistema antivirus ClamAV (gratis), se impidieron los envíos y la recepción de correos superiores a 4MBytes. Como sistema de respaldos se usó el  BrightStore de CA el cual instala un cliente en el servidor Solaris que funciona a la perfección con la consola de respaldos en Windows.

En el momento tope, se tuvieron a unos 500 usuarios, en 8 dominios, la mayoría de los cuales configurados como IMAP (algunos prefirieron POP), también se implementó el acceso mediante Web, así que los usuarios podían consultar sus cuentas a partir de cualquier PC conectado en Internet. Personalmente tenía configurado en mi casa la cuenta con Outlook exactamente igual que en la oficina, de esta manera veía la misma información en ambos sitios SIN necesidad de conexiones especiales vía VPN.

Este servidor siempre dio la talla, nunca tuvimos problemas de exceso de uso del CPU, se tuvieron que aplicar normas restrictivas en cuanto al envío y a la recepción de mensajes personales ya que estos podían colapsar el almacenamiento en disco (la suma de las cuotas de los usuarios era superior a la disponible en disco).

Postfix sirvió a la perfección para lo que se necesitaba, además no se pagó ni un céntimo en licenciamiento de software (las demás soluciones cobran por servidor y por usuario), no se necesitaron clientes especiales en los PC, no hicieron falta grandes requerimientos de hardware, el servidor nunca tuvo amenazas de virus, prácticamente sin mantenimiento, etc.

En mi opinión se dejaron de hacer dos cosas importantes que hubiesen sido una gran mejora al sistema:

1. Integrar los usuarios del correo (que eran los usuarios del servidor Unix) al Directorio Activo de Windows para integrar el esquema de cambio de password, la desactivación, etc. y
2. Ofrecer a los usuarios consultas sobre el directorio corporativo para poder conseguir la dirección de correo de cualquier empleado.