Rajoy, Ruiz-Gallardón, Sun Microsystems, MySQL AB, Oracle y BEA

En el planeta Tierra, en el país España, estoy seguro que en los próximos días el asunto de la no inclusión del alcalde de Madrid, Alberto Ruiz-Gallardón en las listas del Partido Popular al congreso va a generar verdaderos ríos de tinta (vaya expresión más bonita y al mismo tiempo cada vez más obsoleta). Al fin y al cabo los españoles somos adictos a la truculencia, a la contemplación del sufrimiento.

Pero en el planeta en el que vivo, el planeta Internet, en el que, por cierto, no existen los países; se producen noticias de mucho mayor calado, mucho más interesantes sin necesidad de que nadie sufra. Y hoy es uno de esos días en los que se produce no una gran bomba informativa, sino dos.

Sun Microsystems ha anunciado la adquisición de MySQL por mil millones de dólares y Oracle ha anunciado la adquisición de BEA Systems por 7.500 8.500 millones de dólares.

Me enteré primero de la adquisición de MySQL por Sun Microsystems. Me lo comentó mi compañero de trabajo Félix Velasco (saluda Félix, a ver cuando creas tu propio blog para que pueda enlazarte). La noticia es importante y habrá mucho debate acerca del impacto que en el mundo Open Source va a tener esta adquisición. ¿Es buena o es mala para el mundo Open Source?. Yo ahora mismo me inclino a pensar que es buena. Las acciones de Sun Microsystems en los últimos meses, la más importante liberando el código de Java con una licencia Open Source, me hacen pensar que esta adquisición podría permitir eliminar algunas sombras que siempre han acompañado a MySQL (léase licenciamiento dual) y convertir realmente MySQL en un proyecto gestionado y construido por una comunidad abierta y no por una empresa privada como hasta ahora. Ya se verá.

Pero hete ahí que cuando en casa me pongo a leer los feeds para terminar de enterarme de la noticia me encuentro en Barrapunto con el otro bombazo. Oracle anuncia hoy mismo la adquisición de BEA Systems por 7.500 millones de dólares. Ésto si que tiene tela y requerirá mucha reflexión para ir vislumbrando el impacto que puede llegar a tener, esta vez no en el mundo Open Source, sino en la Industria (escrito así, con mayúscula) de las Tecnologías de la Información.

Oracle lleva muchos años intentando posicionarse en segmentos distintos al de puro proveedor de un motor de base de datos. No es el primer intento (ni el segundo) que hace de incorporar a su catálogo de productos un servidor de aplicaciones J2EE competitivo, hasta ahora nunca lo había conseguido y el resultado ha sido que, dejando de lado las alternativas Open Source, el mercado se había decantado por la dualidad IBM WebSphere versus BEA WebLogic.

Esta será la tercera vez que Oracle adquiere un servidor de aplicaciones J2EE. En las dos ocasiones anteriores los servidores adquiridos eran buenos productos con mucho potencial pero la, a mi juicio, equivocada estrategia de Oracle los hundió. A lo mejor a la tercera va la vencida.

Tengo la impresión de que los empleados de BEA Systems no deben de estar dando saltos de alegría con la noticia. No creo tampoco que los clientes de BEA Systems estén contentos con las perspectivas. Sinceramente creo que los únicos que posiblemente estén emborrachándose con champán ahora mismo sean los chicos del gigante azul y los del sombrero rojo. Los apaches lo estarán celebrando bebiendo agua de fuego y fumando alucinógenos en las pipas de la paz.

Otro script para cacti. Contando el número de conexiones CVS

Acabo de crearme un pequeño script para Cacti para contar el número de sesiones CVS establecidas en un momento determinado.

El script es muy simplón y realmente habría mejores formas de hacerlo, pero el caso es que necesitaba contar el número de sesiones CVS y hacerlo con un shell script no me ha llevado más de 2 minutos.

#!/bin/sh
#
# File     : CountCVSConnections.sh
# Version  : 1.0
# Date     : November 22th 2007
# Author   : Jorge Tomé Hernando <jorge@jorgetome.info>
#
# Description
# ===========
#
# Connect to a host via SNMP and count the number
# of TCP sessions in state "established" over the
# 2401 port.
#
# Usage
# =====
# CountCVSConnections [COMMUNITY] [HOST]</pre>
<pre>snmpwalk -Os -c $1 -v 1 $2 .1.3.6.1.2.1.6.13.1.1 | \\  # Get the full list of TCP connections
grep -e ".2401..*established" | \\      # Filter the established connections over 2401 port (CVS)
wc -l | \\      # Count the number of connections
awk '{printf "Active CVS connections: " int($1)}'     # Print the result

eBay procesa 5.700 millones de invocaciones al mes a su API

Últimamente ando involucrado en varios proyectos en los que debo analizar la arquitectura de sistemas de información de grandes multinacionales. Un denominador común de estos proyectos es que tarde o temprano recibo la tópica respuesta “con nuestros inmensos volúmenes eso no es posible”.

Siempre reacciono de la misma forma, preguntando cuáles son (cifras) esos enormes volúmenes y muy a menudo resulta que la respuesta no está muy a mano. La enormidad es una sensación que no se concreta en cifras.

Y entonces llego a artículos como éste (la fuente original es ésta) en el que se informa de que eBay atiende mas de 5.700 millones de invocaciones mensuales a su API y pienso – esto si que es volumen y no los que gastamos por aquí – 🙂

En este otro artículo podéis encontrar información acerca de cómo eBay es capaz de hacer esto. Para los impacientes, el stack tecnológico es Java, IBM WebSphere Application Server y Oracle Enterprise Server; nada demasiado cool 😉. Lo cool está en la forma de usarlo, lo estrictos que son en el cumplimiento de los principios de diseño. Algunas pinceladas:

  • La base de datos es el cuello de botella, hay que llevarse todo el proceso posible a las capas superiores (incluso joins).
  • La estrategia de escalado es horizontal.
  • El desacoplamiento es vital. Integración asíncrona entre los componentes.
  • Hay que virtualizar todos los componentes posibles. Reduce las dependencias de los elementos físicos y facilita el despliegue y la evolución de la plataforma.

RAIDb

RAIDb (Redundant Array of Inexpensive Databases) es un concepto propuesto en Septiembre de 2003, por Emmanuel Cecchet, Julie Marguerite y Willy Zwaenepoel y recogido en un documento de 27 páginas de lectura obligada.

En este documento los autores definen el concepto de RAIDb como una extensión del concepto de RAID (Redundant Array of Inexpensive Disks) aplicado a los repositorios de datos y presentan la implementación que han realizado de su concepto bajo el nombre de C-JDBC.

El problema a resolver es la escalabilidad de las bases de datos y la propuesta es hacerlo de forma horizontal utilizando hardware (y software) de bajo coste.

Tradicionalmente se ha avanzado mucho en la escalabilidad de las capas superiores de una arquitectura de sistemas de información moderna (multi-capa). Así el escalado de la capa de presentación (servidores web) y de la capa de aplicaciones/procesos (servidores de aplicaciones) está bastante bien resuelta. Mientras que la escalabilidad de la capa de datos normalmente se aborda mediante el escalado vertical (agrupaciones con un número de nodos pequeño, típicamente 2, y muy potentes).

Así es “fácil” encontrar instalaciones en las que existen centenares de servidores web atendiendo la presentación, decenas de servidores de aplicaciones ejecutando la aplicación/los procesos y un macro-cluster de base de datos soportando todo eso.

Ese macro-cluster acaba siendo la hardware más potente del fabricante de turno (IBM pSeries, Sun Fire Enterprise Server 25K, HP Superdome, etc.) con decenas de procesadores (sino cientos), cantidades ingentes de memoria y de almacenamiento. En estos clusters casi siempre y por definición, la mitad de la capacidad de proceso está desperdiciada. En un cluster de 2 nodos cada uno de los nodos tiene que ser capaz de asumir la carga completa del cluster ante la caída del otro nodo. Esto significa que se intenta mantener la carga del cluster de forma que ninguno de sus nodos supere el 50% de carga y, por lo tanto, el otro 50% de su capacidad no se usa en condiciones normales.

El planteamiento de RAIDb es llevar el concepto de escalabilidad horizontal a la capa de datos. Permitir el escalado horizontal (añadir más servidores, más pequeños, más baratos) de una forma sencilla, eficaz y económica. RAIDb viene a cubrir las necesidades de escalabilidad y de tolerancia a fallos de la capa de datos.

Al igual que en el caso de RAID, los creadores de RAIDb identifican tres tipos de agrupamiento: RAIDb-0, RAIDb-1 y RAIDb-2. RAIDb-0 es un modelo en el que las bases de datos se particionan pero no se distribuyen (no hay redundancia), RAIDb-1 implica un mirrorring completo de las bases de datos (redundancia completa); mientras que RAIDb-2 define un escenario de replicación incompleta de las bases de datos.

Adicionalmente los autores identifican distintos subtipos: RAIDb-1ec, RAIDb-2ec

Relación rendimiento/tolerancia a fallos de las distintas variedades de RAIDb

En el documento mencionado no solo se explica y define todo lo dicho hasta ahora, sino que también recoge información acerca de un conjunto de benchmarks realizados por los autores (concretamente han utilizado el benchmark TCP-W) y que ilustran las capacidades de escalado de las distintas alternativas dependiendo del número de nodos en el cluster.

 

raidb-02.gif

Como os decía antes os recomiendo la lectura del documento original.

OpenDocument ya es un estandar oficial ISO

< ?xml version="1.0" encoding="utf-8"?> < !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> Untitled document

Leo en un artículo en Slashdot que el formato OpenDocument acaba de alcanzar el estado de "Published standard" del ISO. Sigue leyendo