El objeto de esta serie de posts va a ser la instalación y configuración de un sistema de home server basado en opensolaris 2010.3 (si bien la mayor parte de las entradas son de aplicación en opensolaris 2009.6).

Antes de nada, debemos aclarar qué entendemos por Home server, asi como las premisas que vamos a utilizar en esta serie: entendemos por Home server al sistema de uso habitualmente domestico (si bien puede ser también utilizado en entornos SOHO) cuya finalidad principal es:

• Almacenamiento y copia de seguridad de datos.
• Servicio de ficheros e impresoras (comparticion).
• Servicio de sistemas UPNP AV (servir los ficheros multimedia a los dispositivos indicados)
• Cliente de programas p2p
• Opcionálmente servidor web para pequeñas aplicaciones y servicios.

La selección del hardware y software la vamos a realizar en función a los siguientes parámetros:

1. Soporte por el sistema operativo
2. Consumo energético
3. Fiabilidad y seguridad en los datos
4. Precio (en el hardware… todo el software usado va a ser gratuito).

El objetivo final es reunir toda la información que actualmente o bien esta dispuesta en multitud de fuentes diferentes o bien esta concentrada en manuales genéricos de cientos de paginas, todo ello con la finalidad de que un usuario avanzado con conocimientos básicos del mundo opensolaris (o de los sistemas BSD o *nix en general) sea capaz de realizar sin problemas la instalación y configuración del sistema.

Intentaremos que los post sean lo mas descriptivos posible (incluyendo los resultados de las instalaciones, imagenes etc), e intentaremos abarcar un numero lo suficientemente amplio de opciones (partiendo de las opciones mas basicas, ampliando progresivamente con acciones opcionales).

Esperamos que el desarrollo de esta serie sea dinámico pudiendo ampliarlo con la participación  de los comentarios de los miembros de la comunidad de opensolaris que deseen participar.

Compártelo

ZFS:
1º. Deduplicacion a block level…. basicamente si hay 2 bloques iguales (identico hash) cambia el puntero de uno hacia los datos del otro, dejando el espacio disponible. En zfs la deduplicacion es sincrona (se realiza durante el proceso de escritura en el disco).
Imaginemos en entornos de virtualizacion (cada vez mas abundantes) donde se instalan un numero elevado de maquinas virtuales que comparten el 70% del sistema operativo…el ahorro en espacio es considerable… pero ¿y el rendimiento?… tambien, en tanto los datos que pasan a la memoria cache (ya sea en ARC o ARC2) va a ser utilizada por todas las maquinas virtuales (no es necesario escribir varias copias del mismo bloque en la cache, con lo que disponemos de mayor cantidad de cache para otros bloques).

2º. zpool recovery support… muy importante y practica, en sistemas en el que los discos no hacen lo que dicen haber hecho, puede ocurrir lo teoricamente imposible… una corrupcion del pool a nivel de uberblock (unico nivel que no es corregible los errores, pues al resto de niveles la correccion se realiza de forma casi automatica a traves del self healing)… lo que hace es eliminar la ultima entrada del uberblock de tal modo que recupera la entrada inmediatamente anterior, la correccion se realiza con el siguiente comando (como de costumbre en zfs comandos complejos y dificiles de recordar…:-))

zpool clear -F

Por cierto… para quien tenga este problema (con versiones anteriores de opensolaris)… la solucion: arranca opensolaris con un live-cd (128 o superior)  ejecuta  zpool clear -F … y a funcionar.

Otra cuestion respecto a ZFS: la no inclusion de ZFS en OSX snow leopard… mucho se ha hablado de este tema, que si no estaban convencidos de la fiabilidad, que si habria que realizar muchos cambios internos en osx… La respuesta es mas simple que esa… y la tenemos en un mensaje de un foro en el que Jeff Bonwick (creador de ZFS) indica  lo siguiente:

> Apple can currently just take the ZFS CDDL code and incorporate it
> (like they did with DTrace), but it may be that they wanted a “private
> license” from Sun (with appropriate technical support and
> indemnification), and the two entities couldn’t come to mutually
> agreeable terms.

I cannot disclose details, but that is the essence of it.

Jeff

Continuaremos con las novedades en networking (que son tambien muy importantes)…ILB

Imaginemos la situacion, tenemos 3 equipos que actuan como servidores de aplicaciones web y queremos un balanceador de carga entre los diferentes equipos (asi como un reverse-proxy para que puedan acceder
a los mismos desde fuera de nuestra red)… tenemos varias opciones…

apache (tienen un modulo de reverse proxy y balanceo de carga),
instalar un programa de balanceo de carga y reverse proxy ah-hoc… o
podemos usar ILB … (integrated L3/L4 Load Balancer) en opensolaris.

¿como funciona?… basicamente creamos un grupo …

ilbadm create-servergroup -s servers=webserv1,webserv2,

webserv3 webgroup

Al que podemos añadir nuevos elementos:

ilbadm add-server -s servers=webserv4 webgroup

Y finalmente creamos una regla que especifique que puerto debemos balancear, que rango de ips estan involucradas, el algoritmo de balanceo usado, el tipo de chequeo para comprobar que el servidor esta
“vivo” asi como otras opciones adicionales (filtrado de paquetes…)

ilbadm create-rule -i port=80,vip=15.192.0.0,ipversion=IPv4 \
-m lbalg=hash-IP-port,type=NAT \
-o servergroup=webgroup webrule

Inconvenientes: Tiene una cantidad menor de featurares que los programas ad-hoc.

Ventajas: Rendimiento (al estar insertado en la propia pila ip del
kenel (como modulo eso si).
Sencillez de concepto y manejo.
Podemos configurar que puertos deseamos balancear (y no
solamente los habituales como http, o https…)
Podemos balancear rangos completos de puertos (o la
totalidad de las conexiones)
Integracion con kstat
Integracion con crossbow.

En estos momentos disponemos de una herramienta que, en conjuncion con crossbow, nos permite personalizar hasta limites insospechados la creacion de redes virtuales (muy utiles en sistemas de
virtualizacion).

Compártelo