Servidores y hardware commodity - 1ra. Parte

Por Dardo Valdez
Versión 0.9

¿Qué es un commodity?
* http://es.wikipedia.org/wiki/Commodities

Introducción
No importa el tipo de empresa u organización de que se trate la informática de alto nivel ha llegado, o no tardará demasiado en hacerlo, a tu puerta, y traerá consigo los requerimientos asociados a sistemas de misión crítica, básicamente operación contínua y altos niveles de redundancia.

Con bajos presupuestos es difícil acceder a hardware de alto nivel con buenos niveles de redundancia (doble fuente de alimentación, RAID, SMP, hot plugging, etc.), sin embargo persiste su necesidad así como la de operación contínua.


"Bunch" de nodos
*PyME: Pequeña y Mediana Empresa

En otras palabras es el momento del hardware barato (un commodity), y la redundancia vía software commodity (también conocido por el alias "software libre", "FOSS", etc.). Este es el método clásico de provisión de sistemas (hard+soft) en startups (empresas recién nacidas), alrededor del mundo y lo fue en su momento para Google, Yahoo, Amazon, Facebook, etc.; excepto que la inversión inicial/presupuesto aplique como recurso cabal para la adquisición de un datacenter completo.

En un "bunch" (montón) de hardware de infraestructura tenemos muchas pcs baratas con componentes baratos también, trabajando juntas como si fueran "un" (después veremos el porque de las comillas), solo equipo muy potente, sumando recursos, no necesariamente todos sus recursos: AKA, ciclos de procesador o "no hace falta que te montes un cluster para montar una infraestructura mini-google-yahoo en tu PyME".

Cada una de nuestras PCs de muy bajo costo son "nodos", que uniremos sumando sus capacidades, elevando la redundancia y si todo va bien, bajando al mínimo su costo de reemplazo, tanto en términos económicos, como de continuidad de operación del sistema.

Para preservar el bajo costo de mantenimiento de la infraestructura debemos siempre mantenernos dentro del hardware comodity en lo posible (como discos SATA), recuerden, cualquier hardware raro/caro puede ser más tarde el punto débil de la infraestructura al ser difícil de reemplazar. Otro punto es evitar al máximo cualquier tecnología nueva y más rápida, todo lo nuevo es costoso, una infraestructura sostenida en commodities siempre debe ajustarse al hardware estándar del mercado: placas madres baratas, procesadores baratos, discos baratos; principalmente.


¿Bunch o servers económicos?
Aquí es donde hacemos un salto hacia el papel+calculadora (u hoja de cálculo), y verificamos qué opción nos conviene más según el TCO (Total Cost of Ownership, "Costo Total de Propiedad").

Es una realidad que montar un pequeño "bunch" puede llegar a tener un TCO más alto que simplemente pagar de entrada varios miles de $MONEDA-DE-CURSO-LEGAL y obtener hardware de buena calidad, con garantía de varios años, extendible y con soporte garantizado para sistemas operativos y servicios.

Normalmente una PyME típica fuera de Silicon Valley no dispone de RR.HH. como Larry Page o Steve Jobs, así que el TCO puede escalar rápido y hacer un bunch imposible. Sin embargo, si nuestro plan de inversión como PyME contempla un sueldo/cheque regular para un ingeniero o consultor, bien podríamos asegurarnos de que tenga experiencia (o audacia para experimentar y capacidad para lograrlo con éxito), en el montaje de este tipo de infraestructuras de bajo costo de mantenimiento.

Convencida la $AUTORIDAD-JERARQUICA de la factibilidad de usar un bunch hay que ver algunos temas como ya les dije: entonces codo con codo con el contador, capitalista, inversor, socio,etc. DEBEN sentarse con el arquitecto de sistemas (el tipo que te arma el datacenter, vamos); a verificar (según el plan de negocios, el ciclo de re/inversiones, presupuestos, etc.), que la adquisición de múltiples computadoras baratas y la integración/implementación de los servicios que prestará en conjunto con las previsiones económico/financiaras/lógísticas brindarán el presupuesto+recursos necesarios y adecuados a futuro para reemplazo de componentes hardware (corto plazo en adelante necesariamente en este punto), y para el mantenimiento de la infraestructura y RR.HH., internos o tercerizados, y si estos análisis demuestran definitivamente si el Bunch es o no es económicamente viable para la empresa.

Y si no lo fuera, bien, es la hora de empezar a ver esas páginas de Sun, Dell, HP buscando esos lindos servers que son el sueño de todo ingeniero de preventas: equipos baratos, escalables en prestaciones a cualquier costo/requerimiento y con muy buenas prestaciones en su configuración básica.


¿Nos hace falta tener infraestructura informática inhouse?
* inhouse: dentro de la empresa/organización.

No necesariamente una PyME debe tener que instalar un rack y hardware para su infraestructura de sistemas. Todo depende de sus necesidades; si la PyME solo requiere un servidor de correo y una pocas cuentas bien podrías usar o pagar el servicio de Google, también puedes pagar un servicio de hosting+administración que te entregará una linda interfaz web para administrar tus cuentas y se preocupará de todo lo demás. Algo parecido se puede decir de los servidores web.

La historia es distinta si tu PyME necesita servidores de aplicación y bases de datos internas: Intranets, aplicaciones empresariales, groupware, servidores de archivos, mensajería interna, servidores de desarrollo, bases de datos de testing, etc. Hay mucho que puede llevar la infraestructura interna de una organización a necesitar su propio hardware, mantenido y administrado inhouse, incluso aunque ese sea trabajo tercerizado (IBM, Accenture, EDS, etc.)


Planeando el bunch
La redundancia a nivel hardware se combina siempre con el software, pero debemos identificar primeramente nuestra capacidad para adquirir hardware.

Se puede buscar en el mercado hardware commodity, PCs de escritorio baratas, en lo posible y aprovechando la tendencia, con RAID 1+0 onboard, de ese modo comprando dos discos rígidos, nuestro hardware ya tendría un mínimo soporte para fallos.

Aquí entraría en juego nuestra capacidad de adquisición: un gabinete que disponga de dos fuentes de alimentación es un bonus importante en la tarea de añadir redundancia y seguridad en la continuidad del funcionamiento del sistema.

Otra posibilidad podría ser la adquisición de placas de expansión de puertos SATA con soporte RAID (asumimos siempre el uso de la tecnología más barata), que nos podría permitir montar otros tipos de RAID más redundantes (5, 6 típicamente), y/o utilizar más discos rígidos (SATA/baratos).
Incluso una placa de expansión muy barata que soporte solo RAID 1 ya nos puede permitir añadir un nivel extra de redundancia integrando, por ejemplo, ambos arreglos RAID1 en otro arreglo RAID 0 - mirror (por software esta vez, gracias a que tenemos dos controladoras RAID separadas). Hay que poner atención claro, a los requerimientos de redundancia vs. rendimiento (por ejemplo, se podría también configurar como RAID 0 cada arreglo de dos discos y en RAID 1 los dos arreglos 0). Aparte de ello conviene tener una visión concreta de las probabilidades de fallo de arreglos combinados.

Es solo un ejemplo, si nuestro presupuesto llega al nivel adecuado, adquirir una placa con soporte RAID5 se puede mejorar ampliamente lo anterior.


Replicación y Balanceo
Aclarado: este punto obviamente hay que tenerlo presente desde el vamos porque es parte del TCO.

Otra aclaración: también existe hardware de balanceo y replicación, pero de nuevo, podría ser un caro componente a reemplazar en un oscuro momento del futuro del datacenter.

Después de determinar qué hardware será la base de cada equipo individual, debemos ver cuantos vamos a comprar y si ello es técnica y económicamente acertado.

Con eso en mente vamos al siguiente punto, con un hardware barato ya montado, nuestro problema reside en que...es hardware barato, puede fallar en cualquier momento.

En este punto contemplaremos el software. Normalmente y con poco presupuesto (y, de nuevo, RR.HH preparados), la opción de software de base a usar sería software libre, básicamente Linux (porque debería ser lo más barato de proveer en RR.HH. también); pero podemos montar nodos en balanceo y replicación también en plataformas Windows y aunque las licencias sumarán costos evidentemente, según el presupuesto puede ser sostenible su mantenimiento.

Bien, vamos a los hechos: bases de datos, servidores de archivos y servidores de aplicación. Básicamente todo software de estos tres tipos puede ser mantenido en un esquema de replicación y/o balanceo de alguna clase.

Replicación significa que tendremos dos o más nodos con la misma información, si fallara uno se lo puede sacar de línea y poner en producción una réplica. En algunos casos esto se podrá hacer automáticamente, en otros no.

Según el software, la replicación y entrada/salida automática de línea de los servidores (y el servicio) podría ser una característica propia del soft de replicación o el de balanceo. Para esta funcionalidad se replica el contenido de un servidor en otro (la replicación podría o no ser automática), y se lo deja en espera de ser necesitado si llegara a salir de línea el principal (conocido como Master en casi todos los casos).

El balanceo implica el uso en simultáneo de varios servidores con el mismo o similar contenido (en algún momento será el mismo contenido para casi cualquier software, a menos que estemos hablando de contenido distribuído). El software de balanceo se encargará de distribuir la carga de operación del sistema a través de los varios servidores evitando se llegue a limitar de cualquier modo el servicio debido a la falta de recursos computacionales del hardware. Algo que obviamente nos sirve en sobremanera si tenemos pocos recursos de hardware como en el caso de uno de nuestros nodos commodity.

En el caso del software de servicios de infraestructura (bases de datos, web, correo, mensajería, dns, comparticion de archivos, etc.), el 99% de ellos posee funcionalidades de balanceo y/o de replicación de alguna clase o dichas funcionalidades pueden ser implementadas con software de terceros sin inconvenientes mayores.

El caso de los servicios de aplicaciones no es tan favorable, pero con cierto trabajo de fondo (y un buen nivel de atención a los casos de accesos concurrentes claro), fuera del software de aplicación se puede llegar por medio de otro software a tener un buen servicio de replicación al menos del contenido de un servidor, y en el mejor de los casos se puede llegar incluso a implementar "balanceo" por ejemplo, reapuntando tráfico de algunas redes a un server y el de otras redes a una réplica.
--

En la segunda parte de este artículo seguiremos hablando de como implementar servicios en alta redundancia y alta disponibilidad mientras buscamos aprovechar al máximo los recursos de los que disponemos.