Hay otros como él, pero éste es el mío
Aunque muchas veces digo que soy usuario de Linux (desde 2002 en casa, 2011 en el trabajo), la verdad es que lo que soy es usuario de Debian (también uso CentOS en algunos servidores).
Debian aspira a ser el sistema operativo universal- su versión “testing” contiene la friolera de 58.000 paquetes de software, que incluyen un entorno tipo UNIX y el kernel de Linux, todo en un formato fácilmente instalable. Cantidad no equivalente siempre a calidad, pero al menos para mi, Debian cubre prácticamente todas mis necesidades informáticas con un coste mínimo en tiempo y dinero: en un momento tengo acceso a la mayoría del software que necesito en un entorno eficiente y agradable.
Sin embargo, el mundo de la informática de escritorio sigue dominado por Microsoft Windows. Es un sistema que he usado bastante y realmente tiene muchas virtudes, pero para mi su mayor defecto es que no es Debian. Windows dispone de mucho software interesante que no se puede usar en un sistema Debian, sí- pero Debian también tiene mucho software que es una lata utilizar en Windows- especialmente el que compone el entorno “UNIX” de GNU (los shells y utilidades, que uso intensivamente).
Son dos filosofías completamente diferentes. Debian aspira a empaquetar todo el software libre del universo (e incluso no libre) y Windows te proporciona un sistema operativo y unas migajas de software para que te busques la vida.
¿No podemos tener lo mejor de cada mundo?
Hasta ahora, obtener los beneficios de Windows y Debian suponía mantener dos sistemas. Yo personalmente tengo máquinas virtuales Windows que utilizo para acceder a software que sólo está disponible en Windows- como Microsoft Office, pero en general evito en la medida de lo posible usar Windows porque es un tostón trabajar dentro de una máquina virtual y por tanto aprovecho poco todo el software disponible para Windows.
Ahora bien, Microsoft está cambiando y comienza a contemplar Linux como algo diferente a un enemigo a destruir. Curiosamente, Microsoft parece escoger Debian cuando comienza a acercarse a Linux (sin ir más lejos, han sacado un contenedor Docker para ejecutar aplicaciones de ASP.NET que es Debian Wheezy).
Por otra parte, Debian está preparada para correr bajo otros sistemas operativos. Sin ir más lejos Debian GNU/kFreeBSD es Debian corriendo sobre FreeBSD. También anda por ahí un intento de ejecutar Debian sobre Hurd, el kernel de GNU que quizá algún día sea relevante.
¿Por qué no Debian GNU/Windows?
Existen “distribuciones” para Windows, como por ejemplo Cygwin y MinGW/MSYS, que traen mucho del software GNU y del que incluye Debian, pero que palidecen en comparación con Debian- mucho menos software y mucho menos cariño en su mantenimiento.
No existen imposibles para correr Debian sobre Windows- se requeriría un enorme esfuerzo y hay aún muchas diferencias políticas a limar, pero un Windows, con su enorme soporte de hardware y el acceso a mucho software importante, con un entorno Debian encima sería un entorno que me tentaría seriamente a abandonar Linux.
En este mundo extraño con un Microsoft desconocido que saca software para sus competidores y que emplea Linux… no es algo completamente descabellado.
…
Postdata: soy plenamente consciente que OS X sería una alternativa a Windows en un escenario así. Sin embargo, debo decir que prefiero Windows. Apple y su entorno comienza a disgustarme más de lo que me disgustaba Microsoft. Y desde luego, creo que Apple sería infinitamente menos cooperativa.
En las últimas semanas he estado jugando bastante con Vagrant. Se trata de una herramienta para automatizar el uso de VirtualBox (de momento).
Básicamente, uno define en un Vagrantfile un conjunto de máquinas virtuales, basándose en unas máquinas virtuales plantilla (boxes, en su terminología), especificando los parámetros de virtualización (configuración de red, principalmente) y un mecanismo de provisionado (soporta Puppet y Chef, pero también podemos usar scripts de shell de toda la vida, por ejemplo).
Hacer boxes nuevos es bastante sencillo (básicamente, hay que usar unos usuarios y contraseñas establecidos, instalar las Guest Additions de VirtualBox y poco más), si bien un poco laborioso, aunque existen repositorios como www.vagrantbox.es que tienen bastantes boxes listos para descargar.
Con los boxes y el Vagrantfile, podemos arrancar rápidamente templates de, pongamos, Centos 6.3 con la red configurada y una carpeta compartida con el host (por defecto, la carpeta donde está el Vagrantfile se ve como /vagrant en la máquina virtual), algo que realmente no ahorra muchísimo tiempo respecto a hacerlo con VirtualBox desde cero, pero que es más conveniente.
Mediante el provisionado o el uso de boxes “tuneados”, podemos resolver bastante bien el típico problema de montar entornos de desarrollo en proyectos complejos. Podemos empaquetar un entorno ya configurado como box o box + script de provisionado, junto con un Vagrantfile que se puede editar fácilmente para adaptarlo a la máquina de cada desarrollador en concreto, con el que levantar la máquina ya configurada será cuestión de minutos, cuando anteriormente podían ser horas o llevarnos a la tentación de tener entornos de desarrollo más sencillos y menos parecidos que el de producción.
Pero yo el uso que le veo más interesante es para la administración de sistemas, pues nos permite adoptar un modelo bastante parecido al de desarrollo de software con test unitario. Podemos “desarrollar” nuestros sistemas como Vagrantfiles + scripts de provisionado; idóneamente con esto deberíamos conseguir levantar el sistema desarrollado completamente automatizadamente. Si conseguimos esto, el Vagrantfile y el script de provisionado es una documentación “perfecta” de lo que es el servidor; recoge al detalle cómo se configura todo e incluso podemos ejecutar el provisionado en el sistema “de producción” y asegurarnos entonces que disponemos de una máquina virtual y un sistema de producción idénticos. Tras tener esto, podemos hacer todas las pruebas que queramos en el entorno virtual, como instalar actualizaciones, probar cambios de configuración, sustituir programas… y las podemos probar simplemente destruyendo el entorno y recreándolo a partir del Vagrantfile y el provisionado. Podemos hacer pruebas una y otra vez de scripts para actualizar la configuración en el entorno virtual y luego lanzarlas en producción con un gran nivel de seguridad.
Lo único que le faltaría sería soportar algún mecanismo de verificación automático, pero es un detalle pequeño.
Aún así, Vagrant no es perfecto. Al parecer, ahora mismo sólo soporta VirtualBox (en teoría están trabajando en abstraer el código que trata con el sistema de virtualización, pero no queda claro su status); sería fantástico que se integrase con sistemas de virtualización más “de servidor” como VSphere o KVM, para poder pasar los sistemas montados con Vagrant a producción más automatizadamente (y poderlos probar sobre el hipervisor “final”). También echaría de menos un mecanismo para automatizar la actualización de boxes (e.g. hacer un yum update periódicamente a los box y que se reempaquetase, de manera que estuviesen siempre al día).
También cabe argumentar que realmente Vagrant es una capa muy fina sobre VirtualBox, y que se podría conseguir algo similar mediante las herramientas de línea de comandos de VirtualBox, pero aún así considero que más allá del detalle técnico, los desarrolladores de Vagrant han conseguido una herramienta muy usable y que resulta atractiva… algo que muchas veces es un gran factor a la hora de adoptar una herramienta nueva que te permite hacer cosas de una manera nueva.
En definitiva, ánimo a que probéis Vagrant, tanto para desarrollo como para administración de sistemas. Seguramente para lo segundo no aporte demasiado en entornos “serios”, pero para el “aficionado” puede ser muy interesante.
Como todo buen informático que se precie, llevo un tiempo trabajando en un proyecto “PC enchufado a la tele”. Detallo aquí un poco mi montaje actual.
El punto de partida es uno de estos PCs pequeñitos con Atom. En mi caso escogí por disponibilidad un Giada SLIM-N10, con chipset Nvidia ION, que en teoría debería compensar la poca potencia del Atom para reproducir vídeo- dispone de descodificadores de vídeo que permiten reproducir ciertos formatos de vídeo por hardware, permitiendo ver vídeos 1080p suavemente.
A este aparato le añadí un pequeño dongle Bluetooth y un teclado inalámbrico Bluetooth para controlarlo. Adicionalmente, amplié mi red con un par de dispositivos Powerline (los más baratos que encontré, 50€ el par); mi red inalámbrica no llega muy bien a la zona del televisor y la antena del Giada parece ser bastante horrible; la conexión no era nada estable y el ancho de banda bastante lamentable- el powerline, aún en malas condiciones, me da entre 3-5 megabytes/s de transferencias sostenidas sobre NFS. Esto no siempre da para streaming perfecto, especialmente de vídeos en HD, pero al menos permite copiar un vídeo para reproducción local rápida e indoloramente. Añadimos también una sintonizadora USB barata.
Finalmente, conectamos el PC al televisor vía HDMI, lo que nos da 1920×1080 + audio y añadimos unos altavoces de escritorio conectados por jack de audio; esto nos da una segunda salida de audio que usaremos más adelante.
En el software, escogimos Mythbuntu. MythTV parece ser la solución estándar para mediacenter con TDT (XBMC tiene arreglos para reproducir TDT, pero no parecen muy soportados). Dado que MythTV no está en Debian, parece apropiado usar Mythbuntu para instalarlo sobre Ubuntu, pues parece bastante usado y con una buena comunidad detrás.
La instalación es indolora, lo único complicado fue la configuración de la sintonizadora, pues el modelo concreto que encontramos no está soportado directamente por Linux, pero existen instrucciones para hacerlo funcionar e integrarlo con DKMS (con lo que se actualiza automáticamente con las actualizaciones del kernel). Hace falta un poquito de trasteo con MythTV para que el audio vaya por defecto por la salida HDMI y no por la salida de audio estándar y que utilice el ION para tratamiento de vídeo.
A partir de aquí, añadimos MythWeb que nos da un interfaz web que permite ver la programación y programar grabaciones de programas con un interfaz muy práctico.
Otra funcionalidad que añadimos es un servidor de MPD. MPD es un reproductor de audio controlable por red, del que existen varios controladores; web, móvil, escritorio, etc. Configurándolo para que envíe su audio por la salida minijack, podemos encender los altavoces, usar nuestro PC/móvil/tablet para controlar la música sin tener que encender el televisor.
También configuramos Mame, un emulador de máquinas recreativas que pese a la limitada potencia del procesador Atom funciona bastante bien.
Otro añadido es configurar Flash para que utilice VDPAU, un interfaz que permite la reproducción de vídeo por hardware. Con esto, usando Chrome de escritorio podemos, por ejemplo, ver vídeos 1080p de Youtube suavemente; el teclado inalámbrico que usamos dispone de un minijoystick que podemos usar de ratón, con lo que podemos navegar sin mucho problema.
Cosas de futuro en las que hay que investigar más:
Si seguisteis la entrega anterior de esta saga, deberíais estar con una lista de requerimientos y una decisión más o menos en firme de qué distribución de Linux usaremos para cumplir nuestros requerimientos (seguramente Debian o CentOS).
El paso siguiente es lanzarse a la piscina. Como dijimos anteriormente, una herramienta muy interesante a utilizar es la virtualización. La virtualización nos permite poder hacer instalaciones de sistemas operativos dentro de nuestro ordenador habitual, completamente aisladas del resto de nuestro entorno y con posibilidad de crear tantas instancias como queramos, de los sistemas operativos que queramos y crearlas, eliminarlas, arrancarlas y pararlas con total libertad. El único requisito duro que necesitamos es memoria; una máquina virtual consume en general tanta memoria como la que tenga la máquina que estemos virtualizando. A pesar de ello, hasta los ordenadores modernos más asequibles cuentan con respetables cantidades de memoria, y para muchas cosas, nos bastará para los habitualmente modestos requerimientos de lo que queramos montar (los ordenadores de hoy en día vienen con 4gb de RAM o más, y para una típica máquina con Linux, Apache, MySQL, etc. nos pueden bastar 256 o 512mb). Otro punto a tener en cuenta es la CPU- si bien en general no necesitaremos una CPU muy potente (una vez más, los requerimientos de CPU de los montajes habituales son bastante modestos), es interesante que nuestra CPU cuente con las extensiones de virtualización, que nos pueden facilitar la vida. Por último, en disco con unos 20-30gb libres por máquina virtual que deseemos suelen ser más que suficientes.
Respecto a los sistemas de virtualización, ciertamente existen muchos, pero cuando quiero virtualizar sistemas “de prueba” a los que quiero acceder desde mi ordenador de escritorio, me decanto por VirtualBox, un excelente sistema de virtualización de Sun Oracle, totalmente gratuito y perfectamente funcional, que cubre perfectamente todo lo que le podamos pedir a un sistema de virtualización “de escritorio”.
Con VirtualBox instalado y la ISO del sistema operativo que queramos instalar, nos podemos poner en marcha; creamos la máquina virtual, le conectamos la ISO y nos ponemos con el proceso de instalación. La instalación de sistemas operativos Linux se ha simplificado mucho en los últimos tiempos y, especialmente en una máquina virtual donde prácticamente no hay problemas de hardware, la instalación tiende a ser extremadamente sencilla. Unos puntos a tener en cuenta:
En todo caso, ya durante la instalación debemos aplicar una mecánica imprescindible para que todo sea correcto. Se trata de documentar. Debemos ser capaces de reproducir exactamente todo lo que realicemos para poner nuestros servicios en funcionamiento. Tras el proceso de instalación y configuración, debemos obtener un documento que contenga todo lo que hacemos y que nos permita instalar otra máquina exactamente igual. Esta documentación es extremadamente útil:
Esta guía no tiene que ser algo más complicado que un fichero de texto plano elaborado a base de copiar y pegar con el bloc de notas. Recomiendo incluir enlaces web a la documentación que hayamos usado (manuales, HOWTOs, etc.), pero aún así incluir lo que hemos hecho (el referente puede desaparecer o cambiar). Personalmente utilizo Redmine, un sistema de gestión de proyectos que incluye un correcto wiki, que hace bastante cómodo mantener esta documentación.
Con la guía podemos tranquilamente instalar en nuestra máquina virtual, hacer pruebas, etc. y luego ser capaces de reproducir el proceso (sin pasos en falso) en nuestra máquina en producción. Una herramienta útil que nos proporciona la virtualización son los snapshots. Fácil y cómodamente podemos guardar estados de la máquina y volver a ellos posteriormente. Esto nos permite experimentar y luego volver atrás rápidamente; así pues podemos experimentar sin miedo a “ensuciar” la máquina, tomando un snapshot antes de comenzar.
Tras instalar, y en cuanto tengamos la guía para configurar nuestros servicios en producción, podemos realizar estas operaciones en nuestro entorno de producción y obtener un sistema limpio que cumple los requisitos.
Una vez aquí, tenemos que ser capaces de:
Con estos puntos cubierto, podemos dar un servicio que, pese a no ser completamente profesional, sin un uptime perfecto y sin redundancias, puede ser más que adecuado para la mayoría de los propósitos.
Tradicionalmente se divide el campo de la informática en dos grandes áreas: programación y administración. El programador idea software nuevo o modifica el existente para cumplir con requisitos que no cubre ningún sistema disponible, mientras que el administrador utiliza software existente para cubrir estos requisitos. El entusiasta informático (o pringado de turno) a veces adquire alguna de estas (o ambas) funciones, aunque con mayor frecuencia suele desempeñar la segunda.
Mantener nuestro equipo funcionando e instalar el software que queremos es, por supuesto, administración de sistemas, así como otros temas de hardware doméstico, como mantener una red local. Esta serie de artículos, sin embargo, se centrará en la administración de sistemas no doméstica.
Mucha gente desea tener un blog, una web, un sistema de correos propio, etc. por los más diversos motivos. Por supuesto, para la mayoría de cosas se pueden encontrar proveedores que por un módico precio (o en ocasiones, incluso gratis) podrá proporcionarnos estos servicios fácilmente, pero en ocasiones no encontraremos a alguien que cumpla nuestros requisitos, no querremos depender de un tercero o simplemente querremos experimentar.
Cabe decir, que salvo la última situación o variantes, probablemente estemos cometiendo un error. Pero si estás leyendo esto, probablemente sea tarde para disuadirte. Así que, sigamos adelante (nota: iré recordándote esto periódicamente).
Lo primero es determinar tus requisitos. ¿Queremos tener un blog? ¿Quizás unos foros? ¿Queremos almacenamiento online? ¿Un servidor de correo?
Especifiquemos. ¿Cuánto espacio necesitamos? ¿Qué software cumple con nuestros deseos? Todo esto debería ser fácil de articular- estamos emprendiendo este viaje porque ninguna de las soluciones que hemos investigado cumple nuestros requisitos: ¿cuáles son?
Los requisitos no están aislados, forman una cadena de dependencias. Si quiero usar WordPress, necesitaré un servidor web capaz de ejecutar PHP de una determinada versión, una base de datos MySQL de otra versión, etc. Tomemos un momento para intentar enumerar en la medida de lo posible todos nuestros requisitos.
Típicamente, necesitaremos un sistema con el que podamos satisfacer los requisitos. Hay básicamente dos alternativas, escoger un sistema gestionado o no gestionado.
Un sistema gestionado es lo que comunmente se conoce por estos lares como “hosting compartido”. El proveedor nos da un sistema con PHP, MySQL en unas determinadas versiones al cual no tenemos acceso completo. En cambio, un sistema no gestionado en general nos da un sistema operativo al que tenemos acceso prácticamente completo- esto es lo que en general se denomina VPS o servidor dedicado (dependiendo de si el sistema es una máquina virtual o física).
En general, cuanto más gestionado el sistema, menos trabajo para nosotros pero también menos control. Si el hosting compartido cumple nuestros requisitos, seguramente será más barato y nos requerirá menos tiempo hacer funcionar lo que queremos. Muchas veces estos hostings compartidos ofrecen software conocido (i.e. WordPress, etc.) con sencillos instaladores que lo ponen en marcha sin esfuerzo. Es poco probable, sin embargo, que quien lea estas líneas se vea satisfecho por estas opciones, pero cabe valorarlas y (una vez más), poder señalar qué requisito no cumplen.
Los sistemas no gestionados son un poco más complicados. Nuestro primer paso probablemente sea escoger uno. El precio y fama son factores importantes, pero también debemos considerar otros.
El sistema operativo es probablemente la decisión clave. Muchas veces nuestros propios requisitos nos forzarán a escoger uno- un software puede funcionar sólo sobre Windows o sobre alguna versión específica de Linux. Si no, la cosa es un poco más complicada.
Por temas de coste, los sistemas Linux suelen ser una elección natural- Windows en general es más caro y representa una parte sustancial del coste de un alojamiento, y además muchas aplicaciones populares no están tan probadas y rodadas sobre Windows. Existen otros sistemas operativos fuera de estos dos, por supuesto, pero para las situaciones en las que nos encontramos no suelen ser muy populares ni adecuados.
Dentro de las distribuciones Linux hay un vasto elenco de opciones, y resulta poco viable evaluarlas todas. Mi sugerencia se reduce a escoger sólo entre dos: CentOS/RHEL y Debian.
RHEL (Redhat Enterprise Linux) es la distribución comercial de Linux más popular. Su interés se centra en dos puntos principales:
Si deseamos ejecutar algo que requiere RHEL, raramente hay otra opción viable, así que nuestra elección está realizada. Sin embargo, esto cada día es menos habitual, así que el motivo principal para usar RHEL es su prolongado ciclo de vida. Redhat se compromete a dar actualizaciones exclusivamente de corrección de bugs y de seguridad durante mucho tiempo- concretamente de hasta 10 años.
¿Por qué es importante esto? Pues porque los servicios que expongamos a Internet deben ser seguros. Nuestro servicio no funcionará si un ente hostil lo ataca con éxito y lo deja inoperativo. Existe una poderosa motivación económica que hace que sea rentable atacar sistemas, lo que se traduce en un riesgo más que significativo. Así pues, deberemos ser proactivos en la corrección de defectos de seguridad, y eso prácticamente siempre implica la instalación de nuevas versiones del software que usamos.
La ventaja de RHEL es que nos proporcionan estas actualizaciones sin ningún otro tipo de cambio. Es decir, sin mejoras de funcionalidad. Esto que parece contraproducente es en cambio a menudo una gran ventaja. Una nueva funcionalidad puede introducir bugs o cambios en el funcionamiento del software que nos fuercen a trabajar; actualizar configuraciones, instalar otro software, etc. Si nuestro sistema cumple nuestros requisitos, es probable que esto no nos dé ningún beneficio y sí nos haga perder el tiempo.
Una instalación con RHEL puede ser mantenida al día con correcciones de seguridad casi sin esfuerzo, lo cual es un gran beneficio.
Eso sí, hay tres inconvenientes.
El primero es que RHEL es un producto comercial (y bastante costoso, de hecho). Pero existe una solución sencilla- RHEL es prácticamente completamente open source, con lo que Redhat distribuye libremente el código fuente de RHEL (excepto unas partes específicas que no son open source, pero que en general no nos interesarán), con lo que existen ciertas entidades que cogen este código fuente y construyen clones de RHEL libremente distribuibles. El más popular actualmente es CentOS. La gran diferencia, más allá de las partes no open source, es que estos proyectos no suelen tener las actualizaciones listas a la misma velocidad que la propia Redhat.
El segundo es que esta garantía sólo es aplicable al software incluido dentro de RHEL- cada software que necesitemos que entre dentro de nuestos requisitos que no esté en RHEL nos irá restando de la facilidad de mantenimiento. Con un poco de suerte, el software que querremos estará en repositorios de calidad como EPEL, repositorio mantenido por gente de Fedora que funciona bien y está bien actualizado- existen algunos repositorios de este tipo. Alternativamente, hay software que dispone de repositorios propios de RHEL que funcionan bastante bien. Pero añadir estos repositorios de terceros siempre añade algo de entropía al sistema e incluso podemos encontrarnos que el software que queramos no esté empaquetado para RHEL y lo tengamos que instalar desde el código fuente… haciendo de los procesos de actualización un proceso manual.
El tercero es que el proceso de actualización de una versión de RHEL a otra no está soportado. Un sistema instalado con RHEL 6 (la versión más reciente), no podrá ser actualizado fácilmente a RHEL 7 cuando este salga a la luz (salen cada dos-tres años). Podremos usarlo sin problemas hasta que acabe su (largo) ciclo de vida de 10 años, pero cuando acabe o necesitemos actualizar a RHEL 7, lo mejor será construir un nuevo sistema con RHEL 7.
Si el motivo para escoger RHEL es la facilidad de mantenimiento y actualización, todo requisito que se salga de los paquetes de RHEL es un motivo más para no usar RHEL.
Y si el software que queremos no está en RHEL, ¿qué hacemos? Pues la otra alternativa es Debian. Debian es la distribución completamente open source más relevante del mercado. Sus objetivos incluyen el de ser “el sistema operativo open source universal”, algo que incluye la voluntad de empaquetar todo software libre existente (y de hecho, también parte del no libre), algo que se refleja en el descomunal número de paquetes; si es open source, lo más probable es que esté en Debian.
Sin embargo, esta gran cantidad de paquetes hace más complicado ofrecer un ciclo de vida largo como el de RHEL. Debian tiene una versión estable que sale cada más o menos un par de años (las últimas versiones estables son de 2011, 2009, 2007, 2005, 2002) y tiene actualizaciones de seguridad hasta la siguiente versión estable, así que si con RHEL podíamos estar hasta 10 años actualizando con mínimo esfuerzo, en Debian sólo podremos estarnos 2. Eso sí, Debian sí soporta actualizar entre versiones y al cabo de dos años podremos (con un poco de esfuerzo) pasarnos a la siguiente versión estable.
Debian también nos ofrece testing, una versión constantemente actualizada donde van entrando paquetes nuevos a medida que van saliendo. Testing puede tener más esfuerzo de actualización (pueden entrar paquetes que introducen cambios significativos que nos obliguen a trabajar), pero dispone de software relativamente actualizado y moderno.
En general, la vida con Debian es algo menos cómoda que un RHEL donde nos mantengamos dentro de los paquetes estándares, pero no mucho peor. Y si nuestros requisitos no están cubiertos por los paquetes estándar de RHEL, seguramente viviremos mucho mejor con un servidor Debian. Para ayudaros a tomar esta decisión, podéis usar los índices de paquetes de ambas distribuciones. Podéis consultar en el FTP de Redhat la lista de paquetes disponibles para RHEL 6 y Debian ofrece packages.debian.org donde podéis ver qué software hay en stable y testing.
Más allá de esto, hay otras diferencias entre ambas; documentación, herramientas administrativas, etc. son diferentes y cada cuál preferirá una u otra (a mi en general me gusta más Debian, pero la documentación de RHEL es muy interesante, por ejemplo). Antes de tomar una decisión también es conveniente que las probemos- con la facilidad hoy en día de usar virtualización es muy muy sencillo instalar ambas distribuciones en máquinas virtuales y hacer pruebas.
actualizado: correcciones del sospechoso habitual
Hasta ahora había estado usando el excelente rdiff-backup para hacer backups de mis datos (unos 700gb) a una unidad externa USB. Realmente funciona muy bien; el último backup está directamente disponible en el disco- sin necesitar usar rdiff-backup para leerlo y se guardan incrementos, con lo que es relativamente sencillo recuperar ficheros borrados (usando sus herramientas). Podemos eliminar incrementales fácilmente y en definitiva, es una solución sencilla y harto recomendable.
Sin embargo, tiene en mi opinión un par de defectos. No es sencillo comprimir los backups convenientemente (se puede hacer usando un sistema de archivos que soporte compresión, pero no hay muchos) y si renombras o mueves archivos grandes, pagas su espacio doble (una vez en su estado anterior, otra vez en el nuevo). A parte, la gestión de incrementales es lenta y los backups también tienden a alargarse.
Por ello se me ocurrió usar ZFS. ZFS es el sistema de archivos “futurista” de Sun Microsystems (ahora Oracle). Incluye snapshots baratos, deduplicación y compresión transparente. Así pense que si sincronizaba los datos que quería preservar a un volumen ZFS y tomaba un snapshots, tendría backups (podría usar los snapshots para recuperar archivos antiguos). Gracias a la deduplicación, un mismo archivo que en varios snapshots tuviese nombres diferentes sólo sería almacenado una vez. Y de bonus, compresión.
El problema es que el futuro de ZFS es incierto. Lógicamente Oracle seguirá soportándolo sobre Solaris, pero lógicamente no estoy dispuesto a pagar por ello habiendo sistemas operativos gratuitos perfectamente usables. Actualmente ZFS (y Solaris) son open source, y por ello ZFS funciona en otros sistemas operativos, pero no está claro lo que pueda suceder a partir de ahora.
En todo caso, me lancé a la piscina. En Linux existen dos implementaciones, ZFS on Linux, de reciente aparición- pero no es del todo agua clara (probablemente no se pueda distribuir dentro de Debian y se debe compilar contra el kernel- nada irresoluble pero desde luego inconveniente), así que me decidí por ZFS-Fuse, que está en Debian y parece más “estable”.
Una vez instalado mediante apt-get o similares, simplemente tenemos que hacer algo así como:
zpool create zfs /dev/sdx zfs create zfs/backup zfs set dedup=verify zfs/backup zfs set compression=on zfs/backup
, donde /dev/sdx es un dispositivo externo. Dedup y compression tienen varias opciones que vale la pena investigar. Una vez esto, uso un script como este para el backup:
#!/bin/sh
/etc/init.d/zfs-fuse start zpool import -a rsync -ax --delete --exclude ... --exclude ... / /zfs/backup/julius/root/ zfs snapshot zfs/backup@$(date +%Y%m%d%H%M) zfs list -t snapshot zpool export zfs /etc/init.d/zfs-fuse stop
; la mayor parte del follón es que exporto e importo el sistema ZFS para poder desconectar el dispositivo USB.
El rendimiento de ZFS bajo Fuse y mi disco USB es horripilante (3Mb/s), probablemente una confabulación de FUSE, lentitud de USB, mal disco duro externo, compresión y deduplicación, pero una vez pasa el interminable primer backup, el incremental me parece hasta más rápido que el de rdiff-backup. La deduplicación y compresión no dan muchos réditos de momento, pero es un sistema interesante.
Si habéis estado siguiendo esta serie de artículos, habréis podido percibir un notable patrón- los sujetos de los que hablo no suelen ser muy recientes. Internet se conoce como tal desde el 82, el modelo relacional se formuló en el 69, las funciones hash aparecen mencionadas en una publicación en el 53, el sistema RSA data del 78 y las máquina de Turing y von Neumann son de allá por los años 40.
Es decir, la hazaña informática más jovencita es más vieja que yo con sus 33 años de edad. Pero ninguna de ellas está obsoleta- es más, todas ellas siguen vigentes y es posible que algunas sobrevivan más de un siglo (sólo es posible que el criptosistema RSA quede obsoleto si algún día la computación cuántica resulta práctica- aunque con toda probabilidad sea reemplazado por un criptosistema de clave pública similar).
El que hoy nos ocupa es otro jovenzuelo- el sistema operativo UNIX nació en 1970 en un laboratorio de Bell Labs, como sistema operativo para un videojuego implementado por un equipo de programadores aburridos en el proyecto Multics. Con el pretexto de adaptarlo para el procesado de textos, Thompson, Ritchie, Kernighan, McIlroy y Ossanna asentaron una de las dos familias de sistemas operativos que aún hoy pervive con cierta popularidad (la otra sería la familia de los 360 de IBM, que es más antigua aún).
UNIX se basa en conceptos sencillos- se implementa usando el lenguaje C (hijo del recientemente fallecido Ritchie) portable, simple y eficiente en un momento en que los sistemas operativos se implementaban directamente sobre el procesador, ligándolos al hardware para el cuál estaban diseñados y dificultando su desarrollo; un sistema de archivos jerárquico, cualidades de multiusuario y multitarea… todos ellos conceptos imprescindibles hoy en día. Además, introduce la filosofía Unix de programas pequeños comunicándose entre ellos- haciéndolo extremadamente versátil pero simple, una cualidad vital para ser extremadamente apropiado para gente como los programadores.
Pero más allá de ello, UNIX fue “pionero” en el hecho de que su código (junto con el de los compiladores del lenguaje C) fueran distribuidos libremente- la condena de las prácticas monopolísticas de AT&T impedían su comercialización y por contra forzaban a distribuirlo a quien lo pidiera. Si hoy en día es increíblemente costoso desarrollar un sistema operativo, en esa época primitiva, lo era aún más; y los sistemas operativos de la época eran por tanto costosos y, al ser no portables, sólo funcionaban en un determinado tipo de hardware. La distribución de Unix, por tanto, permitía a cualquiera aprovechar su código, adaptarlo al hardware que tenían y disponer de un sistema operativo potente por un coste relativamente bajo.
Lógicamente, mucha gente se sumó al carro- compañías comerciales que lo usaron o incluso lo extendieron y comercializaron (HP, Solaris, IBM, etc.; hasta Microsoft comercializaba su propio Unix hasta el 89). Pero el desarrollo quizás más importante se dio en universidades, particularmente en la de Berkeley en California. En el 83 AT&T quedó liberada de los corsés antimonopolistas y pudo comercializar Unix, movimiento con el cual los Unix no comerciales, y en especial el de Berkeley comenzaron a cobrar importancia, ya que eran los únicos que quedaban como libremente distribuibles.
Los sistemas comerciales siguieron su camino y perduran hasta nuestros días; HPUX, AIX y especialmente Solaris aún son moderadamente populares, sobre todo en grandes entornos comerciales de computación.
Por otra parte, los sistemas académicos también siguieron su evolución paralela. Del código de Berkeley surgieron sistemas operativos como NetBSD, FreeBSD y OpenBSD- el BSD es de Berkeley Software Distribution- y el nucleo de Darwin que está en las entrañas de Mac OS X (y según dice Apple, el iOS del iPhone, iPod Touch e iPad) es también un “BSD”.
En los 90, un estudiante de informática finlandés, frustrado por no disponer de un sistema operativo Unix viable para ordenadores personales (que en aquel entonces eran básicamente Ataris, Amigas, Macs y PCs con MS/DOS y Windows), desarrolló un sistema operativo estilo Unix, aprovechando las herramientas GNU; algo que acabo dando luz a Linux (o GNU/Linux).
Llegando hasta hoy, los Unix comerciales siguen teniendo su importancia en entornos empresariales- Linux y los BSD libres han ganado una gran importancia, OS X es el segundo sistema operativo para ordenadores personales más popular; en el ámbito móvil, Android se basa en Linux y según dice Apple, el iOS del iPhone también, con lo que en realidad, gran parte de los ordenadores de hoy en día son “Unix”- las excepciones más notables son Windows, los sistemas operativos de los mainframes (básicamente los de IBM descendientes de la serie 360) y los sistemas operativos de móviles que no son Android ni iOS (Blackberry está transicionando de su sistema operativo a QNX [un Unix], Nokia aún conserva su Series 40 para móviles de bajo coste y está matando Symbian…).
El mérito de Unix radica en simplemente eso- su sencillez y claridad de conceptos inicial han perdurado hasta nuestros días- siendo difícil la valoración de su repercusión frente a la serie 360, pero claramente siendo uno de los desarrollos informáticos más significativos de la historia de la computación.
Hace mucho mucho tiempo, en una galaxia muy muy lejana, existía una web de noticias informáticas llamada Slashdot. Por motivos oscuros, Slashdot creció brutalmente en popularidad y por tanto, cada vez que aparecía una noticia en portada de Slashdot enlazando a una web, una cantidad elevada de personas hacía click en la noticia, dirigiendo a ésta ingentes cantidades de tráfico. En los inicios de Internet, no muchas webs estaban suficientemente bien preparadas para soportar carga como Slashdot, y por tanto este tráfico tendía a colapsar los sistemas que recibían enlaces de Slashdot- este efecto fue denominado “Slashdot Effect“.
Avanzando un poco hacia el presente, el tráfico de internet se ha multiplicado. De los 70 millones de usuarios de Internet en el 97 (nacimiento de Slashdot), hemos pasado a los 2110 millones de usuarios actuales (fuente); es decir, se ha multiplicado por 30 el número de usuarios, y muy probablemente, el uso de cada usuario de Internet también se ha intensificado- cada vez dedicamos más tiempo y hacemos más cosas en Internet.
Hoy en día, sitios como Facebook presumen de tener 400 millones de usuarios entrando cada día en sus servicios (¡5 veces el número de usuarios de toda Internet en el 97!) y se suben unos 250 millones de fotos diarias. En Twitter, coincidiendo con hechos como la muerte de Osama Bin Laden, llegan a escribirse más de 12 millones de tuits en una hora.
Así pues, si en el 97 el volumen de uso podía ya suponer un problema para los servicios de Internet, con el enorme crecimiento de la red, ¿se acrecentan estos problemas?
Sin duda alguna. A pesar de que la potencia de los ordenadores se ha acrecentado, esta no ha parecido contrarrestar el hecho de que cada vez queremos más datos, más rápidos y más inmediatos de la red. El mencionado Twitter ha sufrido a lo largo de su carrera para poder soportar el uso que se le da; su Fail Whale ha sido enormemente popular y aún hoy se deja ver de cuando en cuando.
¿Por qué es “difícil” tratar este problema?
Comencemos por lo más básico. Un servidor normalito que podemos adquirir, si sabemos buscar, por 50€/mes, puede servir sin muchos problemas y sin grandes esfuerzos, unas 50 peticiones por segundo de una página dinámica sencilla que muestra información almacenada en una base de datos. Esto equivale a servir 4.320.000 peticiones en un día. Supongamos que cada usuario se pasa unos 10 minutos diarios en la página, y hace una petición nueva cada 10 segundos; eso son unas 60 peticiones. El servidor anterior podría atender a unos 72.000 usuarios/diarios, pudiendo llegar a atender a 3000 usuarios/hora.
Estas cifras parecen respetables, y la buena noticia es que adquiriendo servidores más caros, obtenemos una mejor relación precio/peticiones/s, con lo que podemos fácilmente soportar más carga de este tipo simplemente echando un poco de dinero al problema.
Lógicamente, nunca podríamos llegar a soportar una carga brutal- del orden de magnitud de Facebook, o incluso mucho menos buscando servidores más caros- no existen servidores de tal potencia. Pero seguimos teniendo opciones sencillas. Si en vez de coger un servidor, cogemos más de uno y copiamos toda la base de datos y todo el sistema en estos servidores, las carga se puede repartir en ellos prácticamente a la perfección; si compramos 7 servidores, multiplicaremos las peticiones que podemos atender casi por 7.
Jugando con servidores más o menos costosos y en mayor o menor cantidad de ellos, podemos atender “tantas peticiones como queramos”, a un coste usualmente bastante razonable.
Adicionalmente, la mayor parte de “mostrar información almacenada” en la red hoy en día tiene una característica- es enormemente repetitiva; la página principal de un diario puede necesitar mostrarse a millones de usuarios, pero es esencialmente la misma para todos- así que por muy costoso que sea recuperar y formatear la información, es un trabajo que sólo tenemos que hacer la primera vez- luego podemos guardarnos el trabajo realizado y simplemente copiarlo para el resto de peticiones subsiguientes.
Pero el problema es que no todo es mostrar información almacenada. El problema realmente duro es almacenar información.
El primer problema es que nos surge es la persistencia. Normalmente querremos que la información que se guarde en nuestra web sea persistente; es decir, que no desaparezca. Eso nos obliga para cada escritura a realizar el trabajo duro, registrar esta información en un disco duro o un SSD. Esto es algo que no nos podemos ahorrar de ninguna manera y que de hecho, como veremos ahora, constituye un verdadero límite doloroso al rendimiento que podemos ofrecer.
Un sistema básico puede perfectamente realizar 1500 transacciones de escritura por segundo. Como en el caso de las lecturas, simplemente gastándonos dinero podemos ampliar este número muy fácilmente.
El problema, es que una vez alcanzado el límite del sistema, aplicar el mismo truco que antes (poner dos servidores en vez de uno)… no funciona excesivamente bien.
En el caso de las lecturas, asumíamos que podíamos replicarlo todo a todos los servidores para que cualquiera de ellos pueda atender cualquier petición. Esto nos lleva a que cada escritura que realicemos se tendrá que replicar a todos los servidores, con lo que… ¡no ganamos nada! Como cada escritura tiene que “pagarse” en todos los servidores, nuestra velocidad de escritura haciendo esto nunca aumentará.
Así pues, un replicado simple y obvio nos permite escalar la velocidad de lectura, pero no la de escritura. Si nos topamos con nuestro límite de velocidad de escritura… ¿cómo lo superaremos?
Hay varias alternativas.
Una bastante obvia es no replicar las escrituras a todos los servidores. Eso hará que cada servidor pueda escribir independientemente, con lo que combinaremos la velocidad de escritura de todos los servidores y aumentaremos nuestro rendimiento. Pero obviamente, no todos los datos estarán escritos en todos los servidores, y por tanto no podremos usar la estrategia para acelerar lecturas que comentábamos antes.
Lo que podemos hacer entonces es, en vez de repartir todas las peticiones entre todos los servidores, las repartiremos de otra manera, “particionando” la información. Por ejemplo, pondremos a los usuarios de cada país en un servidor diferente. Esto obviamente nos incrementará el rendimiento, siempre y cuando podamos hallar una partición adecuada.
El problema es que muchas veces, esto no es posible. Todos los usuarios de Twitter quieren acceder a los tuits de cualquier usuario, los usuarios están conectados entre sí de maneras arbitrarias, de manera que es imposible particionarlos de ninguna manera.
Cuando nos hallamos en esta situación, tenemos un problema, obviamente. La solución menos costosa es sacrificar la calidad de nuestros datos. Escribamos los datos a no todos los servidores, y repliquémoslo al resto “cuando podamos”. Aceptemos que algún servidor tendrá información desactualizada (pero que al menos podremos dar un servicio más o menos potable, pero rápido)… hagamos aproximaciones y aceptemos no dar datos 100% correctos e incluso aceptemos que algún dato puede perderse.
Lógicamente, esto no es factible de aplicar para cosas que requieran exactitud, como compras y pagos y cosas de este tipo… ¿pero para tuits y mensajes en Facebook? Pues probablemente sí.
En esto se fundamentan los sistemas NoSQL que prometen escalabilidad barata- una de las cosas en las que se fundamentan es en no proteger los datos con la paranoia habitual- hecho que debemos aceptar como sacrificio cuando los usamos como atajo a la escalabilidad.
En conclusión- escalar un sistema tiene un coste razonable para las cargas de consultas y visualización de información… los sistemas cuyo punto crítico sea este se pueden escalar mucho de una manera relativamente económica. En cambio, los sistemas cuyo cuello de botella sea la escritura son mucho más complicados de escalar adecuadamente- y uno de los costes que podemos pagar es el de la integridad de esos datos.
actualizado con los comentarios de mi editor habitual
Me he levantado con la triste noticia del fallecimiento de Dennis Ritchie. Es impactante como en un mundo tan cambiante y de evolución vertiginosa como el de la informática, dos de las creaciones de este hombre han cumplido ya más de 40 años y son fundamentales en la informática moderna.
Me refiero al sistema operativo UNIX (padre directo de los actuales Linux [y Android], Mac OS X [y si hemos de creer a Apple, iOS] y Solaris), de Thompson, Ritchie, Kernighan, McIlroy y Ossanna y la verdadera criatura de Ritchie, el lenguaje de programación C, con el que se han implementado gran parte de los sistemas informáticos actuales y que está en los cimientos y raices de la mayor parte del resto.
Pero para mi, Ritchie siempre será la R del K&R, *el* libro sobre C, cuya significancia va más allá de la monumental importancia del C, sino que además es uno de los textos sobre informática de referencia- es sin duda alguna un perfecto ejemplo de cómo debe ser la comunicación en ámbitos ingenieriles, cuyo estilo simple, directo y comprensible y su explicación de conceptos completa y precisa transciende su propósito y llega a inspirar pasión y vocación- al menos a un servidor así le sucedió.
Gracias por todo, Dennis. Te echaremos de menos, pues tus creaciones e influencia nos sobrevivirán a todos.
