viernes, 19 de septiembre de 2008

Por qué Debian se usa menos en servers ultimamente

Conversando con una amiga surgió hace poco la pregunta, "por qué no se usa mucho Debian últimamente en entornos de servers".

Elegir una distro para un entorno de servers no es lo mismo que elegir una distro para una misión determinada en una organización. El auge de Debian como distro de serves hacia fines de los 90'y principios del 00' se debió a varias razones, al igual que hoy podemos hablar de varias razones por las que no se usa tanto.

¿Se puede resumir en ítems simples las razones por las que no se usa tanto Debian ultimamente?, difícilmente, pero lo intentaremos.

Veamos algunas cuestiones a analizar al elegir Debian para su puesta en producción en sistemas importantes para organizaciones:

  1. Predictibilidad de releases estables a corto, mediano y largo plazo.
  2. Previos - costosos en tiempo - inconvenientes de dependencias al intentar usar determinadas librerías o aplicaciones de versiones muy nuevas.
  3. Motivos organizacionales:
  • soporte pago por incidentes,
  • certificación de compatibilidad de la distro con hardware de server específico del fabricante,
  • certificaciones de compatibilidad de la distro con aplicaciones de terceros determinadas (propietarias generalmente).


Predictibilidad de Releases

Veamos el primer ítem, la predictibilidad en la liberación de releases en una distro que va a utilizarse en un entorno de servers tiene que ver con el papel de los sistemas que corren en los servidores.

En un principio, cuando Linux aún se expandía en los servers de infraestructura (web, dns, ftp, correo, etc.), teníamos la mayoría de los servicios que estaban en producción en servers Linux corriendo hacia Internet u oficiando un papel relativamente simple (firewall, gateway, proxy), y que llegado el caso de un fallo, normalmente se podía contar con cierto (mínimo) tiempo de downtime para realizar los arreglos necesarios (poner en línea una réplica por ejemplo).

Al momento muchos servers Linux corren servicios de misión crítica para una empresa, esos servicios no necesariamente difieren de las funciones ya mencionadas de los sistemas (web, correo, etc.), sin embargo ahora es crítica para la empresa la continuidad de la operación de esos sistemas, so pena de verse en problemas en otros procesos de negocios, incluso más críticos (Ejemplos: sale de servicio el webserver de un hosting, y al momento ya empieza a perder clientes, cae la base de datos de la sucursal de un banco regional y no puede realizar operaciones con otras localidades, etc.).

En estos últimos servers no puede haber downtimes, los sistemas deben estar apropiadamente incorporados en una arquitectura típica de sistemas de misión crítica con fuerte redundancia, replicación y con planes de DR (Disaster Recovery) plenamente operacionales y confiables.

Volvemos ahora a Debian. Cuando se elije una distribución para servers de misión crítica se mira a futuro el momento en que habrá que migrar de versión, incluso de distro. Debian no ofrece al momento y de primera mano garantías de liberar versiones y upgrades de modo planificado a años a futuro (más de 5 años, mínimo 2 años).

Esa falta de predictibilidad convierte en un juego de azar la planificación y coordinación de las futuras migraciones en entornos donde existen muchos servidores en producción.

Teniendo en cuenta los requerimientos de servidores de misión crítica, hay que tener en cuenta que en el proceso de migración hay una considerable etapa de pruebas donde se verifica en los hechos la compatibilidad del nuevo componente del sistema, la distro en este caso, con el resto de los componentes (software y hardware).

Por ejemplo, por el lado del hardware hay que considerar las nuevas tecnologías de punta que surgirán si es que la organización tiene presupuesto y voluntad ("cash & balls", como dice un amigo), para actualizar ese componente. En el mundo de Linux no hay una estricta garantía de que exista un driver para determinado modelo de controladora propietaria X años en el futuro; sin embargo es una apuesta razonable que muchos fabricantes de hardware harán lo (im)posible para tener compatibilidad con versiones de X distro "importante", comercial o no, que tenga un plan de releases consistente y lo esté llevando a la práctica (tal como se estuvo dando en el caso de RHEL y SLES hasta el momento).

Este último argumento no está firme como roca, porque depende mucho de las tendencias de mercado, una de las cuales indica hoy que los fabricantes de hardware de servers están trabajando para tener máxima compatibilidad con Ubuntu Server LTS (la aparente ventaja de esto es ofrecer hardware con sistema operativo certificado sin tener que pasar - o pagar - certificaciones de terceros), que es hoy la única distro con oferta comercial que puede obtenerse y usarse (Y hacer updates y upgrades hasta el final del soporte de la versión sin costos de re-licenciamiento), libremente; plus tiene un plan de releases. De ahí podemos decir que si esto continua, futuras versiones comerciales se verán en la necesidad de contemplar al menos de reojo, las diferentes actualizaciones de arquitectura que se haga en Ubuntu Server LTS.

Originalmente, Debian fue el patrón elegido de facto para esta pseudo-estandarización de compatibilidad, pero en el aspecto software, y es ahora el sistema base usado por HP internamente, y fue muy estudiado y sigue siendo utilizado en IBM (ambos temas a considerar seriamente dado el peso de estos dos jugadores en muchos mercados de software y hardware del mundo). Luego de aparecer en el escenario Ubuntu todo cambió, y al final dió un vuelco definitivo al saberse que Google estaba usando internamente Ubuntu.

Volviendo al tema de la predictibilidad, Debian no ofrece la suficiente aparentemente; al menos no la necesaria para realizar planificaciones y presentarlas fuera del ámbito técnico y comprometer puestos laborales (los de los sysadmin), en decisiones que valen su peso en ganancias o pérdidas para una empresa.


Inconvenientes al usar versiones muy nuevas de software
Si haz usado Debian lo sabes, la versión estable involucra versiones de software consideradas maduras por la comunidad que desarrolla Debian al punto en que pueden ser incorporadas a una versión rock-solid y garantizada en cuanto potencialmente asombrosos up-times. Eso es lo positivo.

Si surgiera la necesidad de usar alguna versión muy nueva de determinado software y quieres continuar usando paquetes precompilados de terceros (vía apt), quedan dos caminos: buscar repositorios de backports o pasar a la versión de Debian que ya tenga esa versión, Testing o Unstable.

Cuando Debian estaba en auge, usar en servers de producción la versión Testing era casi el estándar, por la reputación de estabilidad ganada durante los años anteriores, en los inicios del proyecto Debian. Hace unos años atrás, con el retraso de nuevas versiones Estable, Testing empezó a decaer en cuanto a disponibilidad de nuevas versiones de soft y muchos sysadmin se pasaban a Unstable cuando podían costear el costo de un downtime eventual (lo que podía resultar de un cambio en Unstable que originara una inconsistencia en la base de paquetes disponibles para apt con la consiguiente imposibilidad de poder instalar nuevos paquetes sin perder la integridad del versionado en la instalación actual).

El uso de repositorios de backports no oficiales (justo ahora, no estoy seguro de que sea así, pero hasta hace poco el proyecto Debian no mantenía repositorios oficiales de backports), empezó a cobrar importancia en este escenario. Aquí debemos hacer las consideraciones de valor técnico apropiadas, un server de backports tiene "issues":

  • normalmente los updates/upgrades de seguridad oficiales no concordarán con los del repositorio de backports.
  • si de hecho hay updates, generalmente se dan más tarde de lo que aparecen en los repositorios oficiales (y los "malos" saben eso).
  • si el repositorio no es de buena reputación podría no ser actualizado nunca, desaparecer de improviso, etc.
  • si el repositorio no está en buenos servers, apuntar a ellos descargas diarias (incluso suponiendo un mirror local del repositorio), puede acabar con su volumen de download mensual autorizado y dejarnos sin acceso a él...hasta el próximo mes.
  • etc. etc.
Es decir, la inversa de todos los buenos motivos por los que se elige usar repositorios oficiales para instalar y actualizar una distribución son el potencial punto de fallo de un repositorio de backports no oficial.

Una tercera posibilidad, y la más usada en entornos empresariales, era y es la de montar un entorno completo de recolección de sources (parches de seguridad, upgrades, incluídos), compilación, armado de paquetes y repositorio interno, pasando todas las tareas propias del mantenimiento de paquetes al sysadmin.

Esta última opción es la que no cierra del todo cuando otras distribuciones ya cuentan con mecanismos en el proyecto que se encargan de hacer este trabajo sin las limitaciones de tiempo con que puede contar un sysadmin y que por ejemplo, pueden llegar a retrasar la aplicación de un parche de seguridad crítico a un source en uso (más la compilación, empaquetado y corrida de actualizaciones fuera de agenda - aka CRON - en servers).

Para lo último, tener en cuenta que un parche crítico puede no tener que ver con "seguridad" en sí (overflows, DOS, etc.), sino que podría tratarse por ejemplo de un bug que implica corrupción de datos ya grabados en disco en una base de datos (como se dió en una versión 8.0 de Postgresql hace algun tiempo).

Volviendo a la cuestión de la disponibilidad de software, siempre está "disponible", sin embargo hay cuestiones de importancia a considerar en cuanto a la facilidad de acceso a él.


Motivos Organizacionales

El resto de los motivos se relacionan con la necesidad crucial de muchos sysadmins de añadir una cobertura legal para sus tareas habituales.

La falta de la posibilidad de delegar la responsabilidad en un tercero hace que el sysadmin cargue con la responsabilidad total cuando se produce una variedad de errores derivados del sistema operativo (seleccionado y avalado por él mismo).

Por ejemplo, cuando se adquiere nuevo hardware y el mismo es bastante nuevo y/o propietario, es difícil poder garantizar que estará disponible de primera mano el soporte necesario en el kernel vanilla; también es difícil garantizar que existirá un parche y hacer previsiones de grados de funcionalidad del parche (podría tener poblemas de performance, latencia, etc.). Aquí una distribución (comercial o no), certificada para el hardware es de mucha ayuda para dormir tranquilo sabiendo que lo que uno firmó como recomendación va a ser respaldado por los hechos al arribo de esa compra de miles de dolares.

Conclusión
Hay más motivos, con mayores detalles, pero en general se puede decir que es suficiente considerar los anteriores para sopesar adecuadamente ventajas y desventajas de incorporar Debian como sistema operativo de misión crítica.

El debido update al día de hoy de prácticas actuales del proyecto Debian en cuanto a tiempos de liberación de releases, disponibilidad de versiones, disponibilidad de repositorios de backports, certificaciones (informales cuando menos) para correr en determinadas versiones de hardware puede hacerse en los foros y con la comunidad que mantiene el proyecto.

Finalmente mi experiencia con Debian fue siempre gratificante a pesar de lo anterior que en algun momento me llevó a no optar por el uso de esta magnífica distribución.

Hay por supuesto otros motivos por los cuales los sysadmin elegían frecuentemente a Debian y quiero mencionar un par. Las buenas prácticas de versión a versión de Debian, manteniendo la cohesión de sus herramientas de configuración y documentando cualquier comportamiento o cambio de comportamiento en herramientas de configuración manuales, automáticas o semi-automáticas hacía que trabajar día a día con la distro fuera agradablemente predecible, y esto recien ha sido adoptado como buenas prácticas por otras distribuciones en años recientes; antes de eso se podía esperar cambios totales de ubicación de archivos de configuración, aparición de nuevos "mejorados" parámetros - no documentados - de compilación de nuevos kernels (que llevaron a inesperados downtimes a muchos), etc.

Hace poco ocurrió un incidente con el código fuente de OpenSSH dentro del proyecto Debian, y la seriedad que comenté sobre el manejo de la distribución se vió claramente respaldada por la reacción y pleno control de la crisis.

La vasta cuota de uso de Debian en servidores al día de hoy y su muy fiable comportamiento en el día a día hacen que esté en uso y todavía haya organizaciones y sysadmins que con adecuadas medidas de previsión (planificación y testing extensivo y previo a poner en producción cualquier cosa, soft o hard), usan sin problemas la distribución al más alto nivel.

Tal vez quieras conocer más motivos para usar Debian, entonces puedes ver la mayor comunidad de usuarios Debian en español en:

http://www.esdebian.org/


Saludos y espero que les sea de utilidad, y está abierto el post para hacer aportes y críticas constructivas.

1 comentario:

kf dijo...

Muy buen post, Dardo. Las versiones estables son casi obsoletas cuando se congelan. A lo mejor se pueda zafar con OpenPKG (?). Saludos