Sun Solaris 10

Introducción

ZFS es un filesystem desarrollado por Sun Microsystems (por un equipo coordinado por Jeff Bonwick), implementado en Solaris y OpenSolaris desde 2005. Un filesystem (o sistema de archivos) es la parte del sistema operativo que se ocupa de administrar el almacenamiento de información en distintos tipos de unidades (generalmente discos rígidos). En primer lugar, todos los filesystems ofrecen métodos para crear, borrar, mover, copiar y renombrar archivos y directorios. A eso se agregan otras características muy importantes como la gestión de permisos, enlaces (hard links y symbolic links), mecanismos para evitar la fragmentación, mecanismos para asegurar la integridad de los datos (como el journaling, utilizado por ext3, ext4, NTFS, ReiserFS, entre otros), y métodos de gestión de RAIDs entre otras cosas.

Como indica la gente de Sun, ZFS es una nueva aproximación a la organización de la información, orientada a evitar conceptos obsoletos y reducir la complejidad de código, produciendo un sistema de archivos sencillo de administrar, con énfasis en la integridad de los datos y la escalabilidad.

Storage pools

Una de las características novedosas de ZFS es que, a diferencia de los filesystems tradicionales, que se ubican en un único dispositivo y, por lo tanto, requieren de un administrador de volúmenes cuando se quiere trabajar con más de un dispositivo, éste sistema se apoya en virtual storage pools (espacios de almacenamiento virtual) llamados “zpools”. Éstos están formados por virtual devices (dispositivos virtuales), “vdevs”, que a su vez se componen de block devices (dispositivos de bloques): archivos, particiones o discos enteros. De esta forma, se pueden configurar RAIDs de distinto tipo. Además de los tradicionales RAID-0 (dividido o data stripping) y RAID-1 (espejo o data mirroring), ZFS ofrece una variante del RAID-5 (dividido con paridad distribuida) llamada RAID-Z que evita un problema conocido llamado “agujero de escritura” (corrupción de las divisiones por perdida de energía entre la actualización de la información y las partes).

Capacidad y escalabilidad

En cuanto a la capacidad de almacenamiento y su escalabilidad, ZFS fue diseñado para tener límites que nunca fueran alcanzados (el tipo de proposición que sabemos que a la ciencia le encanta hacer para poder romper algunos años más tarde). Algunos límites teóricos de ZFS (tomados de Wikipedia) son:

• 2⁴⁸ — Número de snapshots en cualquier sistema de ficheros (2 × 10¹⁴)
• 2⁴⁸ — Número de ficheros en un sistema de ficheros (2 × 10¹⁴)
• 16 exabytes — Tamaño máximo de un sistema de ficheros
• 16 exabytes — Tamaño máximo de un fichero
• 16 exabytes — Tamaño máximo de cualquier atributo
• 3 × 10²³ petabytes — Tamaño máximo de un zpool
• 2⁵⁶ — Número de atributos de un fichero (realmente limitado a 2⁴⁸ que es el número de ficheros que puede contener un sistema de ficheros ZFS)
• 2⁵⁶ — Número de ficheros en un directorio (realmente limitado a 2⁴⁸ que es el número de ficheros que puede contener un sistema de ficheros ZFS)
• 2⁶⁴ — Número de dispositivos en cualquier zpool
• 2⁶⁴ — Número de zpools en un sistema
• 2⁶⁴ — Número de sistemas de ficheros en un zpool

Copy-on-write

OpenSolaris

Otra característica muy interesante que agrega ZFS es un modelo transaccional llamado copy-on-write (algo así como “copia al escribir”). Este modelo, que se aplica a todas las transacciones, implica que todos los punteros de bloque tienen un checksum de 256 bits que se verifica cada vez que se accede a él. Además, cada los bloques que contienen información activa no son nunca sobreescritos, sino que la información modificada se ubica en otros bloques nuevos, y estos últimos son agrupados en grupos transaccionales para reducir el overhead que esto podría producir. Esto permite una preservación casi perfecta de la información, que hace que no sea necesario ejecutar fsck sobre filesystems ZFS. Además, en configuraciones de discos donde la información es replicada (mirroring), la información es self-healing (es decir que los bloques corruptos se reparan automáticamente en función de la información previamente almacenada).

Snapshots

Al utilizar el modelo de copy-on-write, se preservan los bloques con información antigua, con lo cual es posible crear snapshots (imágenes o “instantáneas”) de la información, las cuales se crean rápidamente y en una forma que es eficiente desde el punto de vista del espacio. Éstas permiten restaurar el sistema con los datos existentes en determinada fecha (lo que hace Time Slider). También se pueden crear snapshots escribibles llamadas clones, lo cual resulta en un par de sistemas de archivos independientes que comparten algunos bloques.

Administración de cache

ZFS utiliza ARC (Adaptive Replacement Cache), un algoritmo que resulta más eficiente que el tradicional sistema de memoria virtual page cache que implementaba Solaris.

Gestión de I/O

ZFS implementa un motor de I/O (Input/Output o Entrada/Salida) segmentado (en inglés es un pipelined I/O engine, basado en el concepto de las CPU pipelines). Esto le brinda una serie de características (scoreboarding, priorities, deadline scheduling, out-of-order issue y I/O aggregation), que hacen que ZFS soporte tranquilamente cargas de entrada y salida que otros filesystems no pueden manejar.

Limitaciones

Existen una serie de limitaciones que están mejor explicadas en la entrada en inglés de la wikipedia. Reproduzco algunas aquí.

• ZFS no soporta la definición de quotas por grupo o por usuario. En cambio, como los filesystems ZFS son muy livianos, uno crea filesystems para cada usuario con sus propias limitaciones de espacio. Sin embargo, no hay una solución para cuando un mismo filesystem debe ser compartido por varios usuarios con quotas distintas.
• Por el momento, no es posible reducir la cantidad de vdevs en un zpool, ni reducir la capacidad de un zpool.
• No se puede agregar un disco a un vdev de un RAID-Z o de un RAID-Z2, pero sí se puede agregar otro vdev al mismo zpool.
• No se pueden mezclar vdevs de distintos tipos en un mismo pool.
• ZFS no es un sistema nativo de cluster, distribuido, ni un sistema paralelo de archivos y no puede proveer acceso concurrente para múltiples hosts porque ZFS es un filesystem local.

Palabras finales

Sin dudas, ZFS es un filesystem muy interesante, con características muy innovadoras. Personalmente tengo cierta reticencia a aceptar las contribuciones de software de las grandes empresas. Lejos de mí está casarme con Sun, que pone sus manos en muchos proyectos muy distintos y no en todos con buenos resultados. Sin embargo, hay algunas cosas que debo reconocerle. Así como me pareció muy interesante la implementación de SMF, este aporte de ZFS, al partir de una reconsideración integral de la estructura de un sistema de archivos (from the scratch), creo que es un avance muy interesante. No como el fin de un camino, sino justamente como un camino alternativo que pueda contribuir al desarrollo general de los sistemas operativos (unix).

¿Ustedes qué opinan?

Fuentes:

• What is ZFS? @ OpenSolaris
• ZFS @ Wikipedia
• Sistema de archivos @ Wikipedia

Nexenta es un experimento interesante, que Ubuntu Hardy Heron y le reemplaza el kernel por el de Solaris y utiliza el filesystem zfs. Como dice el artículo de FOSS Boss, Solaris tiene un muy buen desempeño a nivel servidor, pero tiene un montón de herramientas que están desactualizadas. Aunque yo diferiría, por ejemplo, en el caso del ya mencionado SMF.

Nexenta OS

Es muy interesante la integración del apt-get de Debian con el filesystem zfs, porque según indica el artículo, uno puede hacer un completo dist-upgrade y si algo anda mal, bootear a una imagen de tu sistema anterior al upgrade. Eso da una solidez muy interesante que no se obtiene con Ubuntu. Quienes usamos Ubuntu para Desktop sabemos que es casi un vicio estar actualizando paquetes varias veces por día, pero también sabemos que ello conlleva un aumento de la entropía (muy fatalista?) que hace a nuestro sistema inestable.

Además es interesante tener en un entorno Solaris herramientas de GNU. Recuerdo haberme peleado más de una vez porque alguna de las herramientas que uno tiene en GNU/Linux, en Solaris existen pero no funcionan 100% igual. Por ejemplo, si no recuerdo mal, el grep de Solaris no tiene el parámetro -r que sí existe en Linux, entonces para buscar un string en una serie de archivos hay que usar find, xargs, algunos pipes y grep.

Como dice el autor, se trata de una distribución muy joven y está orientada fundamentalmente a servidores. Pero de por sí es una idea interesante que habrá que ver cómo se desarrolla.

Pueden ver los releases de Nexenta aquí: http://www.nexenta.org/releases/

Sitio oficial: http://www.nexenta.org/os

Sun Solaris 10

Solaris 10 incorpora SMF: Service Management Facility, que básicamente es un daemon que controla los servicios que corren en el sistema operativo. Su idea es reemplazar los scripts de /etc/init.d y /etc/rc.*.d, con una utilidad bastante más robusta y simple de configurar.

A partir de Solaris 10, entonces, vemos que muchos servicios que antes estaban en /etc/init.d ahora desaparecieron de allí y si revisamos el /etc/inittab vemos que una de las primeras cosas que hace es levantar el svc.startd que es el daemon que maneja los servicios de SMF. De hecho, dicen que ahora el boot es bastante más limpito, porque todos los mensajes de los servicios que se inician se van logueando en distintos lugares, y uno termina viendo algo así:

SunOS Release 5.10 Version Generic 64-bit
Copyright 1983-2004 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.
Hostname: demobox
NIS domain name is testlab.example.com
checking ufs filesystems

demobox console login:

En este link hay una Quickstart Guide muy interesante, donde muestra cómo se hacían las cosas en las versiones anteriores de Solaris y cómo deberían hacerse ahora con SMF: http://www.sun.com/bigadmin/content/selfheal/smf-quickstart.jsp

Subir y bajar el apache es tan sencillo como ejecutar los siguientes comandos:

Levantar:     svcadm enable network/http:apache2
Bajar:           svcadm disable network/http:apache2
Reiniciar:     svcadm restart network/http:apache2

Como podrán observar, los servicios se agrupan en unidades más “user-friendly” (o admin-friendly), en vez de ser archivos tirados en directorios (de hecho en Solaris siempre era más molesto que en Linux, porque el archivo debía estar indefectiblemente en /etc/init.d y con hard links en /etc/rc3.d – para el caso de servicios que levantaran en runlevel 3). Además se pueden configurar facilmente variables de entorno y otras cosas locas que se deben inicializar con el servicio.

Por otro lado, al haber un daemon constantemente corriendo, si el servicio no es deshabilitado por un “restarter” habilitado, el servicio se levanta automáticamente:

[root@BOCUNOCDWB04:~]# svcadm enable network/http:apache2
[root@BOCUNOCDWB04:~]# ps -ef |grep httpd
root 23319     1   3 13:38:59 ?           0:01 /usr/local/apache2/bin/httpd -k start -DSSL
nobody 23328 23319   0 13:39:02 ?           0:00 /usr/local/apache2/bin/httpd -k start -DSSL
root 23330 22786   0 13:39:04 pts/2       0:00 grep httpd
nobody 23327 23319   0 13:39:02 ?           0:00 /usr/local/apache2/bin/httpd -k start -DSSL
root 23322     1   0 13:39:01 ?           0:00 /usr/local/apache2/bin/httpd -k start -DSSL
nobody 23326 23319   0 13:39:02 ?           0:00 /usr/local/apache2/bin/httpd -k start -DSSL
nobody 23325 23319   0 13:39:02 ?           0:00 /usr/local/apache2/bin/httpd -k start -DSSL
nobody 23324 23319   0 13:39:02 ?           0:00 /usr/local/apache2/bin/httpd -k start -DSSL
[root@BOCUNOCDWB04:~]# pkill httpd
[root@BOCUNOCDWB04:~]# ps -ef |grep httpd
root 23357     1   0 13:39:22 ?           0:00 /usr/local/apache2/bin/httpd -k start -DSSL
nobody 23360 23351   0 13:39:22 ?           0:00 /usr/local/apache2/bin/httpd -k start -DSSL
root 23365 22786   0 13:39:22 pts/2       0:00 grep httpd
root 23351     1   2 13:39:20 ?           0:01 /usr/local/apache2/bin/httpd -k start -DSSL
nobody 23359 23351   0 13:39:22 ?           0:00 /usr/local/apache2/bin/httpd -k start -DSSL
nobody 23361 23351   0 13:39:22 ?           0:00 /usr/local/apache2/bin/httpd -k start -DSSL
nobody 23362 23351   0 13:39:22 ?           0:00 /usr/local/apache2/bin/httpd -k start -DSSL
nobody 23363 23351   0 13:39:22 ?           0:00 /usr/local/apache2/bin/httpd -k start -DSSL
[root@BOCUNOCDWB04:~]#

De la misma forma, si hay algún error al levantar el programa o el mismo se muere dejando algún error, el servicio es puesto en estado “maintenance”, para poder consultar posteriormente por qué no está corriendo.

[root@BOCUNOCDWB04:~]# svcs -xv network/http:apache2
svc:/network/http:apache2 (Apache 2 HTTP server)
State: maintenance since Mon 14 Jul 2008 01:37:39 PM COT
Reason: Start method failed repeatedly, last exited with status 1.
See: http://sun.com/msg/SMF-8000-KS
See: man -M /usr/apache2/man -s 8 httpd
See: /var/svc/log/network-http:apache2.log
Impact: This service is not running.
[root@BOCUNOCDWB04:~]#

Para configurar los servicios hay una consola a la que podemos acceder con svccfg.

[root@BOCUNOCDWB04:~]# svccfg
svc:> select network/http
svc:/network/http> select apache2
svc:/network/http:apache2> listprop
httpd                              application
httpd/stability                    astring  Evolving
httpd/ssl                          boolean  true
network                            dependency
network/entities                   fmri     svc:/milestone/network:default
network/grouping                   astring  require_all
network/restart_on                 astring  error
network/type                       astring  service
filesystem-local                   dependency
filesystem-local/entities          fmri     svc:/system/filesystem/local:default
filesystem-local/grouping          astring  require_all
filesystem-local/restart_on        astring  none
filesystem-local/type              astring  service
autofs                             dependency
autofs/entities                    fmri     svc:/system/filesystem/autofs:default
autofs/grouping                    astring  optional_all
autofs/restart_on                  astring  error
autofs/type                        astring  service
startd                             framework
startd/ignore_error                astring  core,signal
general                            framework
general/enabled                    boolean  true
start                              method
start/exec                         astring  “/lib/svc/method/http-apache2 start”
start/timeout_seconds              count    60
start/type                         astring  method
stop                               method
stop/exec                          astring  “/lib/svc/method/http-apache2 stop”
stop/timeout_seconds               count    60
stop/type                          astring  method
refresh                            method
refresh/exec                       astring  “/lib/svc/method/http-apache2 refresh”
refresh/timeout_seconds            count    60
refresh/type                       astring  method
restarter                          framework    NONPERSISTENT
restarter/transient_contract       count  restarter/logfile                  astring  /var/svc/log/network-http:apache2.log
restarter/contract                 count    299148
restarter/start_pid                count    23339
restarter/start_method_timestamp   time     1216060760.150109000
restarter/start_method_waitstatus  integer  0
restarter/auxiliary_state          astring  none
restarter/next_state               astring  none
restarter/state                    astring  online
restarter/state_timestamp          time     1216060760.155996000
restarter_actions                  framework    NONPERSISTENT
restarter_actions/restart          integer
restarter_actions/maint_off        integer
svc:/network/http:apache2>

La forma en que el daemon manejará los servicios se define en un script que tiene “métodos”, que serán invocados por el daemon. Estos scripts están en /lib/svc/methods, y el daemon los llama por ejemplo de esta forma:

/lib/svc/methods/http-apache2 start 

Adentro el método consulta algunas variables del servicio y lo levanta. El script es muy similar a los de /etc/init.d.

Con svcs se listan los servicios.
Con svcs -l se puede ver el estado actual de un determinado servicio. Además podes se puede ver el proceso principal y sus hijos:

 % svcs -p network/smtp:sendmail
    STATE          STIME    FMRI
    online         18:20:30 svc:/network/smtp:sendmail
     18:20:30      655 sendmail
     18:20:30      657 sendmail

Y con svcs -x se puede ver por qué un determinado servicio falló.

Tiene muchas más cosas locas. Yo creo que debe tener alguna forma de controlar servicios remotos, porque cada servicio tiene una URI que llaman FMRI (Fault Managed Resource Identifier), que puede ser algo así:

• svc://localhost/system/system-log:default
• svc:/system/system-log:default
• system/system-log:default

Y en la primera opción justamente se define una location que en ese caso es localhost, pero supongo que uno podría poner una IP.

También hay otras cosas locas para el manejo de los runlevels del SO. Podés definir milestones que, si no entendí mal, serían como runlevels custom para los cuales vos podés definir qué servicios corren.

Más información sobre SMF en el System Administration Guide de Solaris: http://docs.sun.com/app/docs/doc/817-1985

Particularmente en estos dos capítulos:
http://docs.sun.com/app/docs/doc/817-1985/hbrunlevels-25516?a=view
http://docs.sun.com/app/docs/doc/817-1985/faauf?a=view

Cheat-sheet de  SMF: http://www2.petervg.nl/quick_reference/SolarisSMF.pdf