Telefonía IP, ¿Cuando vale la pena?, Parte II: El esquema mixto

En esta segunda entrega, estoy suponiendo el caso de una empresa que tiene algunas sucursales nacionales que desea interconectar para no incurrir en altos gastos de llamadas de Larga Distancia Nacional.

Suposiciones:

1. Cada sede tiene un volumen de llamadas locales (o sea a la ciudad a la cual pertenece) como para ameritar una central telefónica.
2. El volumen de intercambios de voz y de datos entre las sedes es lo suficientemente alto como para ameritar una WAN propietaria (es decir que la interconexión NO se realiza mediante Internet)
3. A todos los empleados se les es permitido llamar a cualquier número de la red pública telefónica
4. Los usuarios de la empresa no tienen mayores destrezas ni necesidades tecnológicas

Bajo estas premisas se necesitarán los siguientes elementos:

• La WAN propiamente (tipicamente una nube Frame Relay si esta tecnología puede llegar a cada sede)
• Una Central telefónica con capacidad IP para cada sede
• Dispositivos de audio o teléfonos IP para todos aquellos que NO tienen teléfonos tradicionales para comunicarse
• Un buen cableado y switches modernos en cada sede, en caso contrario la calidad del sonido de las conversaciones sería pobre
• Una licencia de software para cada PC que se vaya a comunicar mediante VoIP

Con estas premisas y esta configuración, las que hacen el trabajo duro son las centrales telefónicas que, gracias a su capacidad IP, pueden canalizar a un usuario que usa un software para hablar por teléfono con otra persona en otra ciudad que tenga o no teléfono. De esta manera hay un ahorro, que debería ser importante por la premisa #2, ya que no habría llamadas de Larga Distancia Nacional entre las sedes. Inclusive se podrían programar las centrales telefónicas para que los usuarios, discando algún código establecido, pudiésen efectuar una llamada local en la ciudad de otra sede:

• Disca 9 ==> llamada local
• Disca 81 ==> responde la central de la ciudad 1
• Disca 82 ==> responde la central de la ciudad 2
• Disca 83 ==> responde la central de la ciudad 3

De esta manera si un usuario en la ciudad 1 quiere efectuar una llamada a alguien que resida en la ciudad 3, discaría 83 y luego, al escuchar el tono que le manda la central telefónica de la ciudad 3, discaría el número local de esa ciudad... así se ahorarrían las llamadas inter urbanas cuando los destinatarios de las llamadas residan en alguna ciudad donde la empresa tenga sede.

Las inversiones a realizar para poder tener el ahorro señalado son:

• La adquisición de las interfaces IP de todas las centrales telefónicas
• La adquisición de los módulos con micrófono o los teléfonos IP y las licencias de software para los usuarios que no tengan teléfonos tradicionales
• La mejora del cableado y/o de los switches de la LAN (si son muy obsoletos)

Y los costos recurrentes son:

• El relativo a la ampliación de los enlaces de conexión de la WAN ya que ahora pasarían más datos por ella
• La manutención del software (no obligado pero recomendado)

Por lo tanto, para saber si económicamente vale la pena esta configuración, habría que hacer una hoja de cálculo en la cual se coloque la inversión a realizar depreciable a 3 años (período típico para los activos tecnológicos), más el costo de la ampliación de los enlaces, más el costo de la manutención del software de VoIP comparando al ahorro en llamadas de Larga Distancia Nacional.

Personalmente no creo que el ahorro sea tan importante como para ameritar las inversiones mencionadas.

Telefonia IP ¿Cuando vale la pena?, Parte I: Generalidades

Una vez asistí a un seminario de algún fabricante de Hardware (creo que era el que hacía las tarjetas "Irma") y el expositor dijo algo que me pareció muy válido y lo he tenido siempre presente: "Al momento de comprar una solución tecnológica el proceso debe ser Problema ==> Solución y no al revés, tipicamente los gerentes de TI ven una bella solución y mentalmente se dicen a sí mismos: humm, que solución tan buena! Vamos a buscar un problema para usarla!".

En el caso de la telefonía IP tengo la impresión que, muchas veces, se abusa de esta tecnología porque la solución "está allí y hay que usarla". La intención de esta entrada del blog y la siguiente es analizar estos casos.

Transmitir voz por las redes de computadoras, tal como lo es Internet, es algo maravilloso ya que se puede llegar prácticamente a cualquier lugar del mundo a un costo ínfimo y con buena calidad. Hoy en día existen una gran cantidad de soluciones que ofrecen la transmisión de voz sobre redes IP, seguramente el más conocido es Skype pero no hay que olvidar que muchas soluciones de chat también permiten conversaciones y hasta video llamadas, tales como MSN, Yahoo Messanger, gTalk, etc.

La tecnología detrás de la transmisión de la voz en redes TCP/IP se llama VoIP (Voz sobre IP) y es incorporada a los protocolos de transmisión cada vez más en las redes corporativas. Evidentemente para una empresa que tiene sucursales en distintos países, poder hablar y tener video conferencias de una forma económica es una clara necesidad: aprovechando la propia red de comunicación o Internet (cuando se está dispuesto a depender del tráfico en la red mundial) se podrá ahorrar mucho dinero en gastos telefónicos, pero hoy en día las empresas nacionales también usan la misma tecnología para ahorrarse las llamadas interurbanas, valdrá la pena?

Veamos los elementos principales relacionados con las soluciones IP (sin entrar en demasiados tecnicismos):

Centrales Telefónicas:
Las hay de todos los tipos que combinan la telefonía tradicional con la IP, de manera tal que una central de este tipo se comunica con otra a través de una red IP (incluyendo Internet). Claro que la cantidad de llamadas simultáneas IP es limitada por su configuración. Lo importante de estas centrales es que a ellas principalmente se le conectan teléfonos en la forma tradicional y además manejan conversaciones que provienen de algún software que muchas veces es parte de la solución de hardware de la LAN (léase Cisco). Al final la mezcla funciona así que se tienen usuarios hablando por un teléfono normal con alguien, en el mismo edificio o en otra ciudad, que tiene unos audifonos con micrófono.

Gateway:
Como parte de la solución, se necesita un elemento de hardware que permita la conexión entre el mundo IP y el mundo “telefónico” normal, este aparato se denomina Gateway y puede ser parte de la central telefónica o no.

Teléfonos IP:
Aun cuando es evidente tener unos audífonos conectados a un PC para hablar, a veces eso puede ser engorroso y es preferible tener un simple teléfono. Para estas situaciones existen los “Teléfonos IP” que se conectan directamente a la red.

Software:
Hay varias opciones corporativas que construyen una solución en la cual los usuarios pueden conectarse entre si para chatear, intercambiar archivos, hablar, verse, y, por su puesto, llamar a teléfonos tradicionales (gracias a algún tipo de interfaz).

En la próxima parte vamos a comenzar a analizar la solución desde el punto de vista comercial para determinar cuando vale la pena su implementación.

Steve Jobs

Marzo de 1981, sala de la PDP 11/45, piso 2 del MYS en la Universidad Simón Bolívar en Sartenejas, Venezuela… un grupo compuesto por unos estudiantes (Giuseppe, Nelson, Peter, el gusano, el cochino, el gallego y otros), el system operator (el legendario Leopoldo) y algún otro curioso están en silencio viendo un monitor: todos esperan la siguiente jugada de Sargon 2 un excelente programa para jugar ajedrez para la Apple II. Pocos minutos después una pieza parpadea y se mueve, en la salita se escucha la queja de siempre sobre lo inesperado de la jugada y comienza la tertulia para decidir cuál sería nuestra respuesta.

La Apple II fue mi segunda experiencia con un micro computador, antes había trabajado un poco con la Radio Shack modelo 1; se trataba de computadores que tenían 32KBytes de memoria RAM o menos, venían con 0, 1 o 2 unidades de discos flexibles de 360KBytes de capacidad y procesadores de distintos tipos y marcas. Parece increíble, pero el impacto que generaron en la sociedad (sobre todo en la estudiantil) esos aparaticos fue inmensa: se tenía un poder de cómputo apreciable a la mano! Se había pasado de las calculadora de bolsillo, que ya habían sido un gran avance, a verdaderos computadores programables en Basic, Assembler y más tarde en “C”, Pascal y Cobol! Wow, que avance tan espectacular! Recuerdo que mi primer programa fue para calcular la probabilidad que tenía mi equipo de basket de ganar el campeonato interno en las finales.

Más tarde, en el año 1984, estaba trabajando en una unidad de desarrollo de software cuando salió el Macintosh de Apple… estábamos anonadados! Nada de complicados comandos escritos desde el teclado sino simples sistemas de menú que eran seleccionados con un dispositivo adicional nunca visto… y además unas gráficas espectaculares! La verdad que sentimos que los programas que estábamos desarrollando eran tecnológicamente obsoletos y atrasados, así que al poco tiempo cambiamos a un ambiente gráfico disponible para las PC: GEM (Graphic Environment Mangement) de Digital Research, un ambiente tan parecido al de las Macintosh que fue demandado con éxito por Apple. Digital Research tuvo que recoger las copias y pagar la demanda: nunca se recuperó.

Nunca he sido un gran fanático de los productos Apple, hasta ahora no he adquirido ninguno de sus productos para mi (pero si para mis hijos), pero tengo que reconocer que Steve Jobs marcó el rumbo de la computación personal siempre. Steve Jobs le facilitó la vida a muchos millones de personas, no solo a sus clientes, sino también a todos los que usan computadoras personales porque todas, directa o indirectamente, usan  ambientes gráficos que se derivan del primero que el impulsó. Que habría ideado Steve para nuestro futuro? Que nos perderemos?

El chantaje tecnológico

No estoy seguro si este término es de mi genuina invención o si lo escuché en algún momento, lo busqué en Google pero conseguí muy poco y con un significado muy distinto al significado que le doy.

Para mi el chantaje tecnológico es el perverso círculo generado e impulsado por los fabricantes del hardware y del software para que los consumidores queden atrapados y se vean en la “obligación” de renovar su plataforma tecnológica constantemente.

En el año 1995, antes de que apareciera Windows 95, la mayoría de los usuarios se quejaban porque sus computadoras aprovechaban muy poco el Mega Byte de memoria RAM (si, leyeron bien… 1MBytes) que tenían instalados (MS-DOS reconocía únicamente 640KBytes de memoria, pero Windows, con un pequeño driver denominado HIMEM.SYS, podía aprovechar hasta 1 MByte). Eran PCs con procesador Intel 80386 y, las más avanzadas, con 486. Que software se usaba? Microsoft Office!

Si tomamos a un usuario promedio de ese año y viéramos sus trabajos seguramente serían cartas bonitas, formatos simples y funcionales, presentaciones vistosas, etc. si le preguntáramos que cosas les hacen falta para mejorar su trabajo, muy probablemente la respuesta tendría muy pocas innovaciones. Sin embargo a los pocos meses el fabricante de software, en este caso Microsoft, emite una nueva versión con funciones inimaginables que, al instalarse en el PC del usuario, lo condena a unos tiempos de respuesta miserables… que dice Microsoft? “Tiene que migrar a Windows 95… claro, primero tienes que cambiar de PC ya que 1Mbyte es muy poco y el 386 es muy viejo”. Por otro lado si a ese mismo usuario se le daña el PC y, reacio en adoptar nuevas tecnologías, quiere comprar el mismo PC que tenía para instalarle su viejo software… pues no puede, porque al salir a comprar el PC se consigue que ya todos tienen prestaciones mejores, y por qué? Porque los fabricantes de hardware tienen que producir la tecnología que el software requiere (y además para poder vender más cosas puesto que la tecnología se abarata todo el tiempo).

Al final es un vórtice de hardware y software que se van empujando uno al otro manteniendo adentro a los usuarios quienes, la mayoría de las veces, se sienten bien al comprar hardware nuevo e instalar el nuevo software!

Mis respetos señores de Intel, IBM, HP, Microsoft, Symantec, Autodesk, etc., etc.

Eliminación de un Domain Controller de Windows

En cualquier organización que tenga un dominio basado en Windows, puede presentarse la situación en la cual se desee sustituir totalmente un controlador de dominios  (DC) por otro: con el progreso meteórico de la tecnología es muy frecuente que, al pasar un tiempo relativamente corto (un par de años) luego de crearse los DC, al efectuarse una adquisición de un servidor auxiliar o inclusive de un PC para un usuario, éste sea de prestaciones muy superiores a los DC existentes. El departamento de TI se ve entonces sometido a la disyuntiva de siempre: cerrar los ojos e instalar el nuevo hardware para la función que se planificó comprar (seguramente sub aprovechándolo) o efectuar un doble cambio mejorando así dos servicios (claro con mayor trabajo).

Lo cierto es que Microsoft está bien consciente de esta situación y tiene sus procedimientos bien aceitados para enfrentar este tipo de situaciones: se despromociona el servidor en cuestión, se instala el otro y se promociona a Controlador de Dominios el nuevo. Este esquema funciona bastante bien y no se ocasionan grandes traumas. Otra situación que está bien contemplada por Microsoft, es el caso en el cual se desee suprimir un DC que esté activo para siempre… el problema es si se desea remover un DC y éste no esté activo (por ejemplo si le ocurrió un problema irrecuperable tal como un robo).

Efectivamente tuve que pasar por esta situación dos veces puesto que el grupo de empresas que estaba manejado por un solo dominio corporativo se disolvió y cada empresa, que estaba físicamente en localidades distintas, decidió seguir con el mismo dominio pero estando totalmente aparte… es decir, el dominio corporativo se dividiría en tres dominios separados pero manteniendo cada uno el mismo nombre (para que los usuarios no sufriesen ningún impacto).

Para efectuar la separación NO se podía despromocionar al DC de las empresas a desconectar, puesto que más bien se deseaba promocionar a esos DC como Master DC del remanente de sus respectivos dominios.

Así que se tuvo que cortar la comunicación con cada una de las empresas a separar (una a la vez) y entonces proceder a: 1) Promocionar el DC “huérfano” a Master DC, y 2) Borrar todo rastro del DC separado de la red principal.

La primera parte se efectuó siguiendo un procedimiento de Microsoft sin mayores traumas, en cuanto a la parte de remoción se hizo algo forzada: se eliminó el DC en cuestión del directorio activo… al hacerlo Windows Server 2003 presentó una ventana dando tres opciones de eliminación una de las cuales era “este servidor más nunca se volverá a tener en la red” o algo parecido, y esa fue la que se seleccionó.

Dado que el servidor remoto también era un servidor DNS, se tuvo que remover todo rastro del servidor DNS principal y del secundario (no todas las eliminaciones se replicaban), del servidor WINS principal y en algunas rendijas del directorio activo donde seguía apareciendo. La enseñanza de esto es que hay que vigilar los logs del Event Viewer, al ver los errores de replicación o de otro tipo, se puede deducir donde sigue apareciendo el servidor eliminado para tomar las medidas del caso.

Disaster Recovery, Parte IV: El diseño detallado (2 de 2)

Para reproducir exactamente nuestra red en el sitio de contingencia se tendría que implementar los siguientes mecanismos:

-          Direccionamiento de la red de contingencia tipo 10.40.0.0/16 (igual a la de producción) con los servidores a instalar

-          Direccionamiento de la red que une los dos lugares tipo 192.168.0.0/24

-          Definición en los servidores DNS de nuestra red interna de nombres “paralelos” de cada servidor de la red de contingencia con una IP ficticia. Por ejemplo, al servidor de nombre SRV001 e IP 10.40.0.31 que tendría ese nombre y esa IP en ambas redes, se le crearía una entrada en el servidor DNS tipo “SERV001-CON 192.168.0.31” para que fuese referenciado desde la red interna como SRV001-CON

-          En el Firewall de la red interna se definiría en la regla de salida hacia la red de contingencia, un NAT tipo 192.168.0.1.

-          En el Firewall de la red de contingencia se definiría unas IP virtuales para cada servidor residente tipo 192.168.0.31 à 10.40.0.31

De esta manera nuestra red principal NO estaría conectada directamente a la red de contingencia sino mediante una red “puente” que estaría constituida por una de las interfaces de cada Firewall en cada localidad.

Para implementar las actualizaciones de datos de los servidores de producción a los de contingencia se podrían usar software de respaldo inteligentes para efectuar sincronizaciones de directorios (para el caso de archivos independientes). En el caso de las Bases de Datos el tema es más complejo porque lo que se desea es enviar los registros modificados, añadidos o eliminados. En nuestro caso se decidió que, para todas las Bases de Datos distintas al sistema central del Banco, se implementaría un esquema simple de envío periódico de toda la Base de Datos (la frecuencia y la modalidad de envío variaría para cada Base de Datos)  la cual NO sería actualizada en el servidor “espejo” sino en caso de activarse la contingencia. En el caso de las Bases de Datos realmente críticas del Banco, que estaban en Oracle, en cambio se implementaría un esquema propio de Oracle para la réplica de los registros cuyo criterio depende del volumen de datos a actualizar, al definirse un tamaño pequeño la pérdida sería realmente pequeña en caso de un desastre mayor (claro que el impacto estaría en la ocupación del enlace de comunicaciones).

Disaster Recovery, Parte IV: El diseño detallado (1 de 2)

Lamentablemente tuvimos que descartar las opciones espectaculares basadas en hardware con las soluciones de software de los fabricantes por razones de costo: nuestra operación no justificaba inversiones de ese calibre, así que tuvimos que ingeniarnos una “casera”.

Sitio para la contingencia

El lugar que seleccionamos para la posible activación de una contingencia al momento de que ocurriese un desastre, fue la instalación de nuestro ISP; resulta que nuestro ISP también se dedica (de hecho es su actividad primordial) a ser un Data Center para “collocation” de servidores, alquiler de espacio, hosting, etc. así que tiene las instalaciones más que adecuadas para estas funciones (de hecho el Data Center como tal está mucho mejor equipado que el nuestro). Otro factor importante que tomamos en cuenta fue que nosotros teníamos con ellos una doble conexión con dos fibras ópticas de dos proveedores distintos, cada una de 2Mbits… de esta manera teníamos la contingencia de comunicaciones asegurada, las conexiones más que probadas y sobre todo la posibilidad de ampliar o reducir los canales de comunicación con mucha rapidez.

Criterios de selección

Evidentemente no se estaría llevando a la instalación de contingencia al 100% de la operación, se establecieron ciertos criterios para reducir el plan a algo cuyo costo fuese razonable:

1)     Se llevarían prácticamente todos los sistemas menos algunos para proyecciones, análisis, etc.

2)     Se llevarían todas las Bases de Datos de producción

3)     No se llevarían los datos históricos

4)     No se llevarían los ambientes de desarrollo

5)     Se llevarían los “Home Folders” de ciertos usuarios seleccionados (en condiciones normales los Home Folders de todos los empleados estaban en un servidor central)

6)     Se llevarían las carpetas compartidas de los distintos departamentos de acuerdo a lo especificado por sus respectivos jefes

7)     Se llevarían los buzones de correo de ciertos usuarios seleccionados (en condiciones normales todos los empleados tenía sus correos en un servidor central mediante IMAP)

Equipamiento para la contingencia

Los servidores necesarios para el plan de contingencia pueden ser divididos en dos categorías: los basados en Windows/Linux y los basados en HPUX.

Servidores Windows/Linux:

Se decidió que los servidores de este tipo serían todos virtualizados (muchos de hecho ya lo eran), de esta manera solo sería cuestión de dimensionar en cuanto a uso de CPU, memoria y espacio en disco, cada uno de ellos para luego dimensionar uno o más servidores anfitriones que los hospedarían. Luego del estudio mencionado, se llegó a la conclusión que ampliando la memoria y el espacio en disco de dos servidores anfitriones que ya se poseían desde hace 5 años, se podrían hospedar a los servidores virtuales necesarios para seguir haciendo funcionar al banco en situación de contingencia (más abajo daré los detalles).

Servidores HPUX:

En verdad el mundo de “los servidores basados en HPUX” se reduce a uno solo: la idea era instalar lo que en producción estaba en dos servidores en uno. No sería una gran proeza ya que al final se traduciría en cantidad de memoria a tener para poder alojar los servicios necesarios.

Los elementos de comunicaciones necesarios para el funcionamiento del banco, tales como Firewall, Switches y Routers serían proveídos por nuestro ISP. Quedaba por verse la solución de respaldos, pero se decidió dejarla para una segunda fase ya que, al momento de un desastre, no hay que ponerse demasiado exigentes.

Inventario de servidores

En cuanto a los servidores se tenía lo siguiente:

- Siete servidores físicos con Windows a virtualizar

- Cuatro servidores Windows ya virtualizados

- Un servidor físico con Solaris (el del correo) a “transformar” en un servidor Linux virtualizado

- Un servidor físico con Linux a virtualizar

- Un servidor Linux ya virtualizado
-  Dos servidores físicos con HPUX a condensar en uno

Al final se tendría un total de once servidores virtuales con Windows y tres servidores virtuales con Linux.

En la próxima entrega la estructura en el sitio de contingencia  y el esquema de refrescamiento de los datos.

Disaster Recovery, Parte III: Ideas iniciales

Comencé a pensar en una configuración externa a nuestras instalaciones que fuese prácticamente igual a la real de producción: la idea era tener servidores menos poderosos pero virtualmente iguales a los otros tanto en nombres, como en URLs, como en direcciones IP… de esta manera las aplicaciones seguirían refiriéndose a los distintos servidores de la misma manera. Obviamente para los usuarios trabajar en el ambiente de contingencia habría sido exactamente igual: se autenticarían de la misma manera, buscarían los sistemas de la misma manera, las áreas compartidas serían las mismas… en fin, una vez que se declarara el desastre y los usuarios tuviesen que ir a nuevas localidades a trabajar, no notarían mayor diferencia con su ambiente normal.

Evidentemente lo primero que pensé para crear un ambiente de este tipo fue en virtualización de servidores, se podrían virtualizar a todos los servidores que hiciese falta (por lo menos los Windows y Linux), meterlos en algunos servidores físicos con amplia capacidad de disco y de memoria e implementar algún esquema que permitiese su actualización periódica.

Para resolver el caso de los servidores con HP-UX era más complicado: aún cuando HP tiene una solución de virtualización que funciona para servidores Integrity y que permite tener máquinas virtuales con HP-UX y/o Windows y/o Linux de RedHat, económicamente el costo era espeluznante tal como mencioné en otra entrada de este blog (Cluster de Servidores Unix: El proyecto). Total que para resolver el problema de los servidores con HP-UX, se me ocurrió el viejo truco de “matar dos pájaros de un tiro”, es decir tener el ambiente de contingencia en un servidor parecido al de producción pero reproduciendo en él el ambiente de prueba (que también necesitaba una mejora) de esta manera se aprovecharía el servidor de dos maneras: 1) Como servidor de desarrollo, y 2) Como servidor de producción de contingencia.

Otro de los puntos importante a analizar en esta etapa, fue el de la réplica de los datos de la SAN. En la San se encontraban los datos más importantes y críticos de la organización: las Bases de datos Oracle, los archivos compartidos entre las distintas áreas de la organización, los archivos de trabajo de cada usuario y otros archivos de sistemas menores; la réplica de estos datos (sobre todo de las Bases de Datos Oracle) era realmente algo crítico en todo el plan de contingencia. Dado que había realizado algunos contactos con proveedores sobre este asunto, uno de ellos me propuso darme una charla sobre una solución a la réplica de los datos para la SAN: tengo que reconocer que la solución que nos proponían era realmente espectacular! Se trataba de tener a una SAN igual en el sitio remoto y luego, instalando un software en ambos lados, la réplica se producía automáticamente con un gasto en ancho de banda mínimo, sin impacto de rendimiento y se basaba en copiar inteligentemente las zonas de los discos que fuesen cambiando. Una vez más el alto coste del hardware y del software no me permitió utilizar esta solución.

En la próxima entrega el diseño detallado de la solución.

Disaster Recovery, Parte II: Las nuevas premisas

Como mencioné en la primera entrega, se contrataron los servicios de una empresa para que hiciera el trabajo teórico del Plan de Continuidad del negocio; finalmente llega el día de la entrega del informe y me pongo a analizarlo… no lo podía creer… el sistema que resultó ser más prioritario para la organización, el sistema que, según los usuarios, no podía dejar de funcionar porque el impacto hubiese sido tremendo, era PhotoShop! Este diagnóstico se produjo porque los sistemas no quedaron priorizados en la organización, por lo tanto, para el personal de mercadeo, si no tenían PhotoShop, todo se acababa puesto que ellos no podrían hacer nada! La persona a cargo del proyecto me dijo que ahora pasaríamos a la etapa donde la organización pondrían las criticidades de los sistemas y de esta manera se corregirían esos diagnósticos errados… ok… había que esperar unos meses más… en ese momento me dije: “Yo se perfectamente como va a quedar esa lista de los sistemas críticos, puesto que se como funciona la organización y que le hace falta a cada momento, así que voy a tomar la iniciativa”.

De esta manera fue que apelé al menos común de los sentidos y fui elaborando una matriz con la lista de los servicios que prestábamos (en orden decreciente de criticidad) con los elementos tecnológicos necesarios para que funcionaran en términos de servidores, software y enlaces. Organicé la matriz para que los directivos de la organización fácilmente pudiesen escoger lo que querían mantener y lo que no (el Sistema central, los ATM, los POS, los sistemas administrativos, etc.) y también puse los servicios tecnológicos internos para que también pudiesen ser discriminados (Directorio Activo, Distribución de huellas del antivirus, Monitoreo, Respaldos, etc.).

Otra decisión que tomé fue la de NO tomar la filosofía de suponer que, al estar todo destruido, se tendría que volver a levantar la operación desde cero sino que se mantendría una operación paralela funcionando en un lugar a prueba de fallas, esperando por el momento que habría que activarla por la ocurrencia de un desastre.

En la próxima entrega ya comentaré sobre el diseño de la solución.

Disaster Recovery, Parte I: Los preliminares

Se habla mucho de la recuperación de la empresa luego de un desastre, más a partir del 11 de septiembre del 2011 cuando varias empresas fueron literalmente borradas del mapa (instalaciones, equipamiento, respaldos, personal, documentación, etc.), si se le pregunta a la directiva de cualquier empresa al respecto seguramente su respuesta será “Hay que estar preparados! La empresa tiene que estar funcionando 7x24, no importa lo que ocurra! Este proyecto tiene prioridad 1!”, el problema es cuando se le presentan los números a ese mismo directivo y ve como se volatilizan las utilidades de esa empresa para un año o más simplemente para “estar preparados para lo peor”, en ese momento la prioridad del proyecto baja en picada.

En el banco en el cual trabajé el ente regulatorio nos obligó a tener nuestro plan de continuidad del negocio, por lo tanto tuvimos que emprender la tarea completa. Se comenzó contratando a una empresa que, mediante entrevistas al personal, llenando formularios y alimentando a un sistema se detectaría la criticidad de cada aplicación. También, al preguntarle a cada ejecutivo sobre la importancia de los sistemas que usaba, se detectaría la cantidad de tiempo que el negocio podría “soportar” sin la presencia de un sistema determinado.

El trabajo con la empresa contratada duró algunos meses. En mi caso me preguntaron los tiempos que nos tomaría crear la plataforma de servidores necesaria para cada aplicación suponiendo que, llegado el momento del desastre, tuviésemos que recrearla a partir de servidores nuevos que “alguien” nos habría conseguido oportunamente. De nada sirvió que le explicara al analista que me encuestaba que no veía factible en Venezuela que, al momento de un terremoto o de un incendio, fuese realista que “alguien” (reitero esto de “alguien” ya que en la práctica quién llevaba las negociaciones con los proveedores de hardware y de software era yo mismo) llamara a un proveedor de confianza, le pidiera los equipos necesarios y éste nos los suministrara en un corto tiempo (los tiempos normales en Venezuela para la obtención de equipamiento tecnológico NO de consumo masivo como lo pueden ser servidores Unix, una SAN o una unidad de respaldo corporativa son de no menos de 4 semanas) para que entonces nosotros comenzáramos a instalar Oracle, Oracle AS, Flexcube, clientes de respaldos, servicios DNS, DHCP, etc. etc.

Para la reconstrucción de los servidores Unix, luego que el proveedor hubiese entregado en nuestras instalaciones el montón de cajas, cajitas y afines (hay cajas que contienen un cable o un manual!) se tendría que apersonar el analista que los instalaría físicamente (un par de días) y luego el que efectuaría la instalación del software básico  ya que muchas veces vienen con Unix pre instalado, pero hay que parametrizar muchos valores (otro par de días sin ponernos exquisitos instalando el Cluster), entonces vendríamos nosotros a instalar el software mencionado antes (otros 3 o 4 días). En conclusión: suponiendo que se hubiese presentado un terremoto durante un fin de semana o de noche (para que no nos matara el personal!) lo suficientemente fuerte para derrumbar nuestro edificio pero no muchos más (porque si hubiese sido un desastre parecido al de Haití o al tsunami de Japón en Caracas, podemos olvidarnos de contar con equipamiento tecnológico nuevo por meses), suponiendo que gracias a nuestro espectacular plan de contingencia tendríamos en otras instalaciones SEGURAS Y A PRUEBA DE TODO RIESGO respaldos actualizados, el software a instalar, los instructivos, etc. en el mejor de los casos nos tardaríamos unas 6 semanas en volver a tener los servicios tecnológicos funcionando. En la práctica con un desastre real no nos hubiésemos recuperado nunca.

En la próxima entrega seguiré contando sobre los resultados del estudio del Plan de Continuidad del negocio.

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

Software Bancario, Parte II: Flexbranch

Un elemento importante en la solución bancaria ideada por i-Flex, es la relativa al manejo de las agencias. La empresa vende estas soluciones por separado, así que, en teoría, se podría adquirir un software para manejo de las agencias a una empresa distinta a i-Flex y hacer las conexiones pertinentes. Lo cierto es que el banco adquirió a Flexbranch como interfaz con las taquillas en las agencias.

Flexbranch es un software que también se basa en Oracle, requiere de un pequeño servidor en cada agencia el cual se sincroniza periódicamente con el servidor central. Las estaciones de trabajo acceden a este servidor mediante el Internet Explorer (que también tenía limitaciones en cuanto a la versión soportada) en un ambiente con Microsoft Windows 2000 o XP. El error que se cometió en la configuración de los PC en las agencias, fue el de darle los servicios de correo electrónico e Internet: en tecnología siempre se objetaron estas facilidades ya que le abrían las puertas a virus, malware, spyware y afines, pero nunca pudimos con las exigencias de poder consultar Internet (los ejecutivos hasta nos decían que necesitaban poder ir a consultar cualquier sitio “por si el cliente tenía esa necesidad”) y al correo electrónico. Tuvimos verdaderos problemas con las agencias con estas cuestiones (que además contaminaban al servidor) hasta que logramos cerrar el chorro limitando las páginas que podían ser accedidas y los correos.

En una estación de trabajo en un ejecutivo en una agencia, típicamente se tenía configurado Flexbranch (para consultar cosas de taquilla), Flexcube (para hacer consultas a otros sistemas relacionados), Business Objects (para los reportes) y otros sistemas colaterales para ver las tarjetas de crédito, cuestiones relacionadas con Cadivi, etc.

Al darnos cuenta de lo complejo y vulnerable que podía ser la instalación de una PC en una agencia, llegamos a efectuar unas pruebas exitosas en hacer funcionar todo mediante escritorios remotos, de esta manera nos podríamos concentrar en reforzar y hacer funcionar perfectamente la instalación en un servidor que sería accedido por varios usuarios con sus PCs, en caso de dañarse la PC, sería cuestión de únicamente darle otra genérica y configurar el acceso al servidor de Escritorios Remotos… mucho mejor! Esta solución se adoptó totalmente para el caso de poder consultar el sistema pre-reconversión monetaria: se había congelado una versión del sistema al 31/12/2007 con los Bolívares “viejos”; para poderla acceder se tenía que abrir una sesión en un servidor de escritorios remotos el cual estaba configurado para que se conectara únicamente a esa Base de Datos, este esquema funcionó perfectamente y me dejó con la inquietud de hacerlo en la Base de Datos de producción propiamente.

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.