Imaginemos que deseamos clonar el disco de sistema de opensolaris, o en su defecto, garantizar la integridad de datos instalando un sistema de mirroring. Por desgracia el actual sistema de instalacion grafico no permite la creacion de sistemas de mirror en opensolaris (no es asi en nexenta), si bien el proyecto caiman (todavia en desarrollo) va a permitir este tipo de configuraciones.

La solucion a este problema la encontramos en este interesante video (en este caso el objetivo es conseguir una copia del disco de sistema (para ello realiza un attach del disco al mirror, con posterior resilvering, seguido de una instalacion de grub en el nuevo disco, y finaliza con un detach del disco en el mirror).

Aqui podemos ver el video. en youtube

Compártelo

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

En este punto entramos ya en materia considerablemente mas densa… discos duros, procesadores, memoria y placas base.

Discos duros

Dado el uso no empresarial  y la prioridad por el ahorro energetico, podemos descartar los sistemas basados en SAS o SCSI … asi que nos decantaremos por soluciones sata (o incluso IDE para la instalacion del sistema). Asimismo descartamos los discos de 2,5 (portatil) estandar por tener una tasa de errores muy superior a los de 3,5 pulgadas, asi como una vida media muy inferior.

De este modo tenemos que definir si vamos a utilizar discos de 7200 o de 5400 rpm… las ventajas de una y otra opcion serian las siguientes:

7200 rpm:

• Mayor rendimiento
• Mayor consumo energetico (8 W en idle… , 10 W en funcionamiento (Seagate)
• Teoricamente menor duracion (esto habria que demostrarlo) al estar sometido a un estress mayor de rotacion que los de 5400.
• Ligeramente mas caros (solo ligeramente) que los discos de 5900.

5400 rpm

• Menor rendimiento.
• Menor consumo (Western digital, 4 W en idle… 7-10 W en funcionamiento).
• Teoricamente mayor duracion.

Tradicionalmente habria recomendado Seagate, pero una serie de problemas recientes (con un conjunto elevado de discos fallando) me hacen optar por discos Westen digital. De este modo tenemos las siguientes opciones:

Gama AV y AV GP: discos estandar con sonoridad reducida (perfectos si buscamos un nivel de ruido lo mas bajo posible), la gama GP tiene ademas un consumo energetico mas reducido. Los precios son ligeramente superiores al resto de gama caviar (green y blue)

Gama Caviar (Green, Blue y Black): La gama green se caracteriza por un consumo mas reducido de energia (menor rpm, y menor rendimiento), la gama blue podemos definirla como la estandar (7.200 rpm) mientras la gama black (mas cara).

Una opcion interesante es el WD Caviar Green WD15EARS… pues combina los bajos niveles de ruido y consumo de la gama green con unos interesantes 64 mb de cache y un precio muy interesante. (Una anotacion… este disco PUEDE (parece que hay diferentes series) tener tamaño de sector de 4K, por lo que no es utilizable por defecto en sistamas operativos como XP…y tampoco es recomendable utilizarlo como disco de sistema en opensolaris pues habria que hacer diversas adaptaciones… no hay problema para usarlo como disco de datos en opensolaris).

¿Que gama elegir?… depende de la configuracion que vayamos a realizar, si vamos a instalar los pools en discos independientes (cada disco un pool de datos), tendremos el cuello de botella en los propios discos, por lo que si queremos rendimiento tendremos que ir a gamas blue y black, ahora bien, si los datos los ponemos en raidz o mirror… el cuello de botella estará en la red por lo que instalar discos de mas velocidad no nos va a dar mayor rendimiento externo (debemos tener en cuenta que al sistema va a accederse desde otros equipos).

Para aquellos intersados en obtener el maximo rendimiento… una opcion interesante son los WD caviar black modificando ciertos parametros en su configuracion (para poder incorporarlos de forma masiva a sistemas RAID.. convirtiendo un WD caviar en un RAID EDITION )…. leer esta entrada y esta otra, tambien en este caso seria interesante (dado que buscamos el maximo rendimiento podemos permitirnos lujos presupuestarios…, incoporar un disco SSD de 64 Gb como cache de segundo nivel de ZFS (L2ARC). (mas detalles).

Como complemento, un poco de informacion sobre discos duros de tipo “enterprise” y de tipo desktop… ¿en que se diferencian? (aparte de en el precio claro esta)… en muchos casos la electronica es la misma o muy similar, al igual que los platos magneticos (no compensa fabricar de un tipo para una clase y de otro tipo para otros)… las diferencias vienen:

1. La velocidad de giro (7200 desktop… 10.000 y 15.000 enterprise)… lo cual redunda no tanto en un incremento de la velocidad sostenida sino sobre todo de los accesos aleatoriso y la cantidad de peticiones por segundo que puede atender… asi p.ejm un disco de 7200 tiene un rendimiento aproximado de 79 IOPS mientras que el rendimiento de un disco de 10.000rpm  es de 140 IOPS… (fuente)
2. El tamaño de la cache…
3. Unos componentes electronicos teoricamente mas fiables que redunden en un ratio de fallos por ciclo de operaciones menor.
4. Un mayor consumo electrico (importa mas el rendimiento que el consumo).
5. Una capacidad menor de discos en tanto se opta por discos con un menor numero de platos asi como una orientacion tradicional (se magnetizan los datos de forma horizontal en el plato, no vertical… esto se debe a que la lectura de los discos si el mismo esta magnetizado de forma vertical es mucho mas compleja si el disco gira a altas velocidades… y por otro lado el ratio de fallos y sectores defectuosos en discos magnetizados verticalmente es muy superior a los magnetizados horizontalmente)… todo ello con la finalidad de obtener mayor fiabilidad y velocidad a costa de un mayor precio por Gb de datos.
6. Y por ultimo, los discos estan preparados para soportad sistemas RAID…¿que quiere decir esto…?, los discos tienen un sistema de autocorreccion de errores, (a traves de CRC), pero la correccion de errores requiere tiempo… tiempo en el que todo el sistema esta esperando los datos de un disco; dado que el sistema raid presume redundancia, los datos podrian ser obtenidos de otra fuente, por ello hay un parametro en el firmware de los discos denominado TLER (time-limited error recovery), que indica al disco cual es el tiempo maximo que debe intentar recuperar los datos antes de indicar al raid que el disco esta dañado, permitiendo obtener al raid los datos de otra fuente e indicar al usuario el estado degradado del raid (en realidad puede que el disco no este fisicamente dañado, y pueda ser utilizado en otro entorno, pero no en un sistema en el que perjudicaria el rendimiento del sistema)… este parametro viene desactivado en los discos “desktop” y activado en los discos “enterprise”.

Por ultimo ¿de que capacidad y cuantos discos?… depende en primer lugar del presupuesto que tengamos, asi como de los datos a incorporar. Presupuestariamente a dia de hoy los mas rentables son las opciones de 1,5 TB, en cuanto al numero… 4 discos deberia ser mas que suficiente para alojar la totalidad de datos que vamos a utilizar o necesitar de forma continuada… y esto quiere decir, el home server debe tener exclusivamente los datos que puedan ser utilizados o bien de forma continuada o bien a corto plazo… en ningun caso lo debemos usar como sistema de almacenamiento de datos pues: 1º estamos gastando energia electrica de forma innecesaria y 2º corremos riesgos innecesarios al tener los datos en un sistema “funcional” (un disco nunca perdera los datos guardado en una caja… pero puede perderlos en un ordenador funcionando si la fuente de alimentacion revienta), asi pues, compremos los discos necesarios para disponer de suficiente “escalabilidad” a medio plazo, pero asumiendo que el uso que vamos a dar al sistema es el que debe ser… (y si tenemos mas datos en otros discos… siempre se podran conectar posteriormente a traves de puertos usb, firewire…).

Una nota adicional… asi como hemos recomendado el uso de discos de 5400 rpm para el almacenamiento de los datos… recomendariamos el uso de discos de 7200 para el sistema operativo (que va a a ir en un disco aparte) .

Memoria

La decision a tomar en este punto no es tanto la velocidad y el formato (DDR2 o DDR3) sino el uso o no de memoria ECC (correcion de errores).

Sin animo de extender mucho sobre la explicacion de que es la correccion de errores… basicamente diremos que nos proteje de posibles errores tanto inducidos como por defectos de los propios modulos, corrigiendo esos posibles errores a traves del uso de redundancias. Esto tiene como consecuencia un menor rendimiento respecto a las memorias ECC (son mas lentas) pero por contra nos garantiza que los datos que entran y salen son los que deben ser. Ciertamente, el indice de fallos en la memoria se ha ido reduciendo progresivamente, pero no es menos cierto que las memorias tienen cada vez un mayor tamaño (mayor capacidad) y que la progresiva reduccion de los voltajes de trabajo las convierte en mas vulnerables a incidencias eletromagneticas externas… todo ello hace que la tasa de fallos de memoria se incremente progresivamente.

Simplemente un dato: actualmente un servidor tiene una media de 4000 fallos de memoria al año (fuente), utilizando memoria ECC estos fallos se corrigen… no usandola pueden provocar  corrupcion de datos,  daños en ficheros de programas hasta, fallos en el equipo…

ZFS nos garantiza la integridad de los datos en el disco… pero si los datos enviados por la memoria son defectuosos o son modificados por la propia memoria no hemos avanzado nada, de este modo, y teniendo en cuenta que buscamos estabilidad el uso de memoria ECC es imprescindible…. maxime teniendo en cuenta que los precios actuales de la memoria ECC son asequibles.

¿Que cantidad?… minimo 2 GB (zfs es un gran comedor de memoria), optimo 4 Gb.

Otras opciones: dual channel si o no???… dado que es un servidor, y el uso de la tarjeta grafica interna va a ser muy reducido, realmente los beneficios obtenidos por el uso de dual channel van a ser mas bien escasos (y el sobrecoste que va a implicar no compensa esos beneficios).

Indicar que la eleccion de memoria ECC ya va a condicionarnos sobremanera la plataforma de trabajo (Intel o AMD).

Por ultimo un dato un poco anecdotico y curioso… el uso de memoria ECC debe ser directamente proporcional a la altitud a la que se encuentre el equipo, asi, un equipo a nivel del mar tiene menor necesidad (aunque sigue siendo importante) que otro  ubicado en el Teide (p.ejm), la razon es que una de las principales causas de fallos en la memoria es la radicacion cosmica (que afecta mas conforme aumenta la altitud), asi, ya en los años 90 ibm calculo que la radiacion cosmica causaba un error al mes cada 256 mb de memoria… teniendo en cuenta que la memoria es 20 veces mayor en estos momentos y ademas trabaja con voltajes mas bajos (mas susceptible a influencias por radiaciones)… esta claro que esta cifra lejos de reducirse va a ir en aumento. (fuente)

De hecho, uno de los efectos colaterales de el incremento de la velocidad de reloj de los microprocesadores (el cual se puede conseguir en gran parte reduciendo los voltajes de trabajo) es su mayor predisposicion a los fallos causados por las radiaciones cosmicas… para “solventar” este problema, intel plantea (a futuro) aparte de dotar de blindajes electromagneticos los chips, la instalacion de detectores de radiacion cosmica en el propio procesador que permita repetir la ultima operacion realizada al detectar el impacto. (fuente)

En el proximo post terminaremos la seccion de hardware analizando placas base y procesadores

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