Mientras esperamos la publicacion de la ultima version de opensolaris (prevista para el mes de Marzo… pero hasta el momento no publicada), vamos a realizar la instalacion de un sistema de NAS basico de alto rendimiento instalable en equipos con poca capacidad de calculo que nos va a permitir el uso de las capacidades avanzadas de ZFS (snapshoting, clones, deduplicacion), de crossbow y de comstar (iscsi) todo ello con un footprint minimo (menos de 118 mb la instalacion completa ubicada en ramdisk).

Para ello vamos autilizar EON-NAS (Embedded Operating system/Networkin) en conjuncion con un GUI pensado para sistemas basados en zfs…(opensolaris, nexenta y EON), llamado napp-it. Con este conjunto podremos facilmente gestionar zfs, crear volumenes, asignar cuotas, crear comparticiones smb y nfs, crear usuarios, comprobar el estado de los servicios…

Ciertamente es una opcion muy interesante para sistemas de tipo legacy (32 bits), o la creacion de NAS de pequeño tamaño (con capacidades nunca soñadas para un NAS normal), con la ventaja de su pequeño footprint, la estabilidad de un sistema minimo (nucleo y servicios imprescindibles), si bien, claramante para instalaciones mayores es mas interesante la opcion de Nexentastor, como alternativa a Freenas es muy valida.

La ultima version de EON esta basada en el nucleo de la ultima version publicada de Solaris Express (proyecto denominado Nevada, y ya abandonado en favor del proyecto Indiana), existen 4 versiones diferentes: CIFS 64 y 32 bits y SAMBA 64 y 32 bits (en funcion al sistema de comparticion que utilicen, CIFS usa el integrado en el propio sistema de ZFS y samba permite mayor flexibilidad al incorporar el conocido programa de gestion de comparticion de ficheros).

Para utilizar el gui napp-it, es necesario utilizar la version basada en CIFS (32 o 64 bits).

Instalacion de EON: es sencillo, tras grabar el cd debemos arrancar el equipo desde esa unidad…tras su inicio nos pedira usuario y contraseña…

user: admin pass: eonstore
user: root pass: eonsolaris

Para simplificar primero haremos una instalacion en el disco duro (o disco usb o compact flash), para ello simplemente debemos ejecutar:

o

Nos realizara una serie de preguntas (seleccionar disco donde instalar, asi como diversas confirmaciones de borrado e instalacion).

Y modificaremos la linea

quedando

Tras esto… perderemos la conexion a ssh (al cambiar la direccion ip y reiniciar la red)… tendremos que volver a conectar, con la nueva ip

cd /var/apache2/2.2/cgi-bin
chown webservd:webservd napp-it
cd napp-it
chmod -R 755 ./*

Que quedará:
All:suser:cmd:::*:uid=0

Finalmente daremos permisos al usuario webservd

usermod -P’All’ webservd

Compártelo

Tras tener definidos discos duros, caja y memoria a usar, tenemos que definir lo mas importante del sistema: procesador y placa.

En este punto y en tanto hemos decidido que vamos a utilizar un sistema basado en memoria ECC, la eleccion se simplifica de forma considerable. Asi, aunque en nuestra empresa somos mas partidarios de utilizar soluciones integramente intel (Chipset + procesador + networking) para garantizar la estabilidad del sistema, cuando hablamos de un home server todo cambia…¿la razon?… los chipset intel con soporte de memoria ECC son o bien de gamas muy altas o bien son de tipo servidor (para equipos Xeon).

INTEL

De este modo… si disponemos de capital suficiente… y no nos importa tener un consumo electrico superior (salvo que consigamos un modelo de Xeon de bajo consumo de la serie Conroe, Wolfdale o Woodcrest), esta es la opcion mas interesante.

Respecto a modelos y marcas concretos, en Intel no vamos a definir pero recomendariamos comprar placas Intel (integran mejor las caracteristicas de los chipsets), o supermicro. En cualquier caso son una opcion mas cara que la alternativa en AMD.

Debemos tener en cuenta asimismo que la placa elegida va a ser determinada en gran medida por la caja seleccionada, asi por ejemplo, si seleccionamos cajas mini-itx, la gama de placas que podemos adquirir se reduce de forma muy considerable (sobre todo si queremos soporte ECC).

Una cuestion que nos va a surgir es ¿y una placa atom?…posiblemente no sea una opcion muy indicada porque:

1. . Algunos modelos de atom no tienen soporte 64 bits (algo muy importante para opensolaris, aunque no imprescindible).
2. No tendriamos soporte de memoria ECC
3. Tendriamos una escalabilidad del sistema limitada (en tanto la mayor parte de placas atom solamente tienen 2 conectores sata, siendo las opciones con 4 mas escasas).

No obstante y todo ello, si el objetivo primordial fuera reducir al maximo el consumo, esta claro que esta seria posiblemente la mejor opcion.

Como recomendacion de equipo intel, podemos dar la gama basica de servidores HP (gama proliant ml 110 G5), pues estan plenamente soportados en opensolaris, incluyen soporte de memoria ECC y estan dando un excelente rendimiento a un coste muy ajustado (si bien los consumos electricos son mayores de lo deseables).

AMD

Una vez definido que no podemos (o queremos) optar por la solucion intel … tenemos la alternativa AMD… personalmente la mayor parte de mis equipos (dejando aparte portatiles) han sido AMD, y debemos reconocer una relacion calidad precio muy interesante.

¿Porque la opcion de memoria ECC es mas barata en AMD que en Intel?.. muy sencillo, Intel hasta hace poco incorporaba el gestor de memoria en el Northbridge del chipset, con lo cual, para soportar memoria ECC debiamos buscar un chipset que incorporara ese soporte… AMD por el contrario desde hace tiempo utiliza el mismo diseño para sus procesadores de gama servidor y de gama “domestica”, simplemente varia la velocidad del reloj asi como el numero de nucleos , la cache y el numero de enlaces hypertransport que soporta… de este modo incorpora “de serie” un gestor de memoria integrado dentro del propio microprocesador (con ello el fabricante de la placa base se ahorra en el chipset la instalacion de gestores de memoria).. gracias a ello, podemos contar con una feature “enterprise” en nuestros equipos domesticos.

Por otro lado, el uso de la tecnologia hypertransport simplifica mucho el desarrollo de las placas (en tanto los chipset pueden tener menos elementos e incluso pueden funcionar a velocidades de reloj menores pues tienen un ancho de banda garantizado de comunicacion con la cpu)… en definitiva, durante mucho tiempo AMD ha estado tecnologicamente por delante de Intel (si bien esta situacion ha cambiado con el desarrollo de los procesadores Nehalem (I7, i5, i3) y el uso del QuickPath Interconnect.

Otro dato a tener en cuenta… los consumos del conjunto placa + micro son considerablemente inferiores en AMD que en Intel (excepcion hecha de modelos Atom), en primer lugar porque AMD tiene unos ratios TDP menores (habitualmente), y en segundo lugar porque la utilizacion de la tecnologia Hypertransport permite obtener rendimientos similares con menores frecuencias de trabajo (y menor consumo).

De este modo una vez definido que el equipo a a ser un AMD, debemos seleccionar microprocesador, en este punto tenemos la opcion de la gama BE de los antiguos Athlon X2 (con un TDP) de 45 W, un poco antiguos ya y dificiles de conseguir, o cualquier de la gama e (energy-efficient) de la antigua version K9… respecto a los nuevos micros de la familia K10 (Athlon II, phenom…) tenemos 2 opciones muy interesantes:

• M2N SLI DELUXE (o M32N SLI DELUXE)

• M2N68-CM

• Asus M3A78-CM.

Compártelo

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