Ya tenemos definido el sistema operativo a utilizar para nuestro particular home server…opensolaris, ahora debemos definir el hardware a utilizar. Los parametros de eleccion vienen determinados por la propia denominacion del equipo: HOME SERVER

1. Silencioso (dado que va a estar en un entorno domestico.
2. Que ocupe poco espacio
3. Barato (priorizar precio sobre rendimiento… no necesitamos una conexion dual gigabit)
4. Eficiente energeticamente (de bajo consumo)
5. Componentes fiables (al fin y al cabo es un servidor)
6. Estabilidad (soporte memoria ECC)
7. Bien soportado por el sistema operativo

Con estas premisas en mente vamos a ir desgranando las opciones disponibles (empezaremos por lo menos problematico).

FUENTE DE ALIMENTACION

Debe ser estable y con suficiente capacidad para suministrar de forma correcta a requerimiento de los componentes… esto que parece una obviedad no lo es cuando hablamos de las tradicionales fuentes de alimentacion de 20 €, las cuales, pueden ser perfectamente utilizables en equipos de uso esporadico, pero no sirven para sistemas en continuo funcionamiento. Respecto a la disyuntiva de active PFC vs pasive PFC (correcion de factor de potencia activo o pasivo), personalmente me decanto por la opcion pasiva (una fuente con pasive PFC bien construida puede tener un factor de eficiencia superior al 82%) por razones puramente economicas.

Respecto a modelos en concreto… no vamos a indicar, solamente que debe ser de marcas reconocidas: Enermax, Corsair, Nox, Antec, Seasonic, y que es preferible pecar por exceso que por defecto (si bien cualquier fuente de estas marcas y 450 W reales es capaz de mover sin problema alguno placa, procesador y 6 dispositivos de almacenamiento)… Tenemos que tener en cuenta que los consumos de placa+procesador van a estar en torno a los 100 W de pico y el consumo de los discos duros rondan los 10 W en idle y los 25 W en arrancada… por lo tanto los maximos consumos previstos serian unos 250 W de pico… pero en este punto hay que tener mucho cuidado… pues facilmente podemos hacer el siguiente calculo:

25 W x 10 = 250 W… podemos colocar 10 discos duros sin problema… y esto seria erroneo pues las fuentes indican las capacidades acumuladas de todos los railes y voltajes… asi por ejemplo una fuente de 400 W puede tener perfectamente soportado un maximo de 12 A en su rail de 12 V (o 6 en cada rail, si tuviera 2 separados)… si conectamos 10 discos estamos llegando a picos de consumo de 20 A… que sobrepasan con mucho las posiblidades de la fuente… y el resultado puede ser desastroso para nuestros discos (en el peor de los casos la fuente puede fallar, enviando una sobrecarga a nuestros discos y quedarnos sin datos). Asi que, en resumen:

1º. Fuente de garantia, fiable

2º. Ligeramente sobredimensionada (teniendo en cuenta los picos de consumo, no los consumos en regimen normal de funcionamiento).

3º. Revisando los consumos por voltajes (fundamentalmente centrarse en los amperajes de los railes de +12V)

En este punto debemos hacer un inciso, adelantando un factor que condicionara la seleccion de nuestra placa base: el subsistema grafico debe ser integrado… la razon: consumo electrico (cualquier tarjeta grafica externa tiene un consumo notablemente superior a las tarjetas graficas integradas).

Como dato anexo: indicamos los consumos de elementos habituales maximos en un equipo:

1. Conjunto procesador placa con grafica integrada: 100-130 W de pico
2. Discos duros: 8-10 W idle/20-28 W arranque
3. Unidades de cd: 15 W idle, 25W arranque
4. Ventiladores (12 cm no de tipo servidor):  3W

Cajas

La seleccion de la caja va a estar definida por una serie de parametros y limitaciones, asi podemos optar entre cajas mini-itx, micro-atx y atx. Ventajas e inconvenientes de cada una:

Mini-itx:

• De pequeño tamaño, ocupan poco espacio.
• Capacidad de almacenamiento limitada (maximo 4 o menos discos duros)
• Limitan las placas a formato mini-itx (muchas menos opciones a elegir)
• Fuentes de alimentacion mas pequeñas, de menor potencia y si queremos fiables… mas caras.
• Habitualmente de nivel sonor mayor (al ser fuentes con ventiladores de 8 cms y mayor rpms).

Personalmente no recomiendo esta opcion si bien, en caso de escogerla hay 2 cajas interesantes:

La Chenbro ES340698 (opcion de gama alta)

La b-move kassia 400W SFX (opcion de gama baja, pero que cubre el expediente)

Micro-ATX//Semitorre ATX

• Ocupan poco espacio
• Utiliza fuentes de tamaño estandar (mas posibilidades a la hora de elegir)
• Pueden alojar hasta 6 dispositivos (discos duros y unidades opticas)
• Mayores posibilidades de ventilacion
• Menor nivel sonoro (posibilidad de utilizar ventiladores de mayor tamaño)
• Permite usar placas mini-itx y micro-atx (atx tambien en el formato semitorre atx)
• Gran diversidad de modelos

Posiblemente esta sea la mejor opcion, en tanto la gama a nuestra disposicion es casi infinita, los precios son sensiblemente mas contenidos que las opciones mini-itx  y aunque los tamaños de placa que acepta son mas limitados (no podemos poner placas atx (en micro-atx) o full-atx), esta limitacion (como veremos mas adelante) es mas bien pequeña (en tanto con casi total probabilidad la opcion de placa sea micro-atx).

Importante a la hora de elegir la caja es que nos permita realizar una correcta refrigeracion de los componentes, en especial de los discos duros, idealmente deberia disponer de ventiladores de minimo 10 cms de entrada y salida (o cuando menos de entrada).

Un ejemplo de caja interesante por sus capacidades y tamaño: la Nox Max…(imagen adjunta) formato micro-atx, soporta 6 unidades de disco (4 ellas con ventilacion frontal) y 2 unidades opticas con ventilacion frontal y lateral de 120 mms y trasera de 80 mms.

Caja ATX

• Ocupan mas espacio
• Utiliza fuentes de tamaño estandar (mas posibilidades a la hora de elegir)
• Pueden alojar hasta 10 dispositivos (discos duros y unidades opticas)
• Mayores posibilidades de ventilacion
• Menor nivel sonoro (posibilidad de utilizar ventiladores de mayor tamaño)
• Permite usar todo tipo de placas
• Gran diversidad de modelos

Si se dispone de espacio suficiente, esta es junto con la anterior la mejor opcion, que incluso nos va a permitir incorporar racks internos de almacenamiento con extraccion en caliente … pero todo ello son opciones que en principio deberian sobrepasar nuestras necesidades (y como hemos indicado que el precio es un condicionante… prescindiremos de esas opciones).

Dado que la gama de cajas atx es tan amplia (y la mayoria van a cubrir las necesidades… no realizamos ninguna recomendacion… simplemente que esten bien ventiladas y permitan el acceso facil a los dispositivos.

Compártelo

La primera condición en la selección de un home server es el soporte nativo ZFS…¿porque zfs? No vamos a responder a esta pregunta (quien necesite la respuesta se ha equivocado de blog… necesita preparación previa que no dispone para el resto de la serie… que comience con la wikipedia y diversos blogs referentes a zfs).

De este modo tenemos las siguientes opciones:

Freebsd// Freenas

Opensolaris // EON // Nexentastor

Freebsd:

Su soporte de zfs es estable desde la versión 7.3 … si bien yo personalmente recomendaría utililizar la versión 8.0.

Tiene el gran inconveniente de no ser un appliance de storage, por lo que tendremos que configurar manualmente todo el sistema de almacenamiento, asi como de no disponer de las ultimas features de zfs (deduplicacion fundamentalmente), el no disponer de otras opciones avanzadas como crossbow o comstar hace que rechazaremos en principio esta opción.

FreeNas

Appliance de storage basado en freebsd 7.0, es un fork de otro proyecto de appliance (en este caso para su uso como router y firewall) llamado monowall, su principal objetivo era obtener un sistema con un footprint lo mas reducido posible (para posibilitar su uso en sistemas embebidos), esta premisa ha hecho que actualmente se encuentre en una situacion de continuidad de desarrollo dudosa (en tanto las limitaciones establecidas por monowall impiden su desarrollo a traves de plugins, asi como complican sobremanera una posible actualizacion a freebsd 8.0). En cualquier caso, y con independencia de su futuro desarrollo, es un proyecto consolidado y de funcionamiento mas que probado con caracteristicas interesantes como son el soporte nativo de zfs, el soporte de un sistema de UPNP AV integrado, asi como el ser un appliance de almacenamiento (lo cual nos facilita de forma notable la configuración y gestión de todos los aspectos relacionados con el storage). A nivel personal indicare que este es el sistema que vengo utilizando desde hace bastante tiempo en un equipo con una potencia mínima (via epia M9000, con un procesador de tipo i386… de potencia equivalente a un pentium 3 500 Mhz), sin ningún tipo de incidencia, con soporte de snapshots cada hora, cada día y cada semana… de sencillo uso y fácil instalación.

Como contrapartida debemos indicar las mismas que Freebsd (en tanto esta basado en este sistema operativo).

Sistemas basados en nucleos Opensolaris

Opensolaris

Utilizar Opensolaris como Home server tiene una serie de ventajas y de desventajas:

Como ventajas, disfrutar de un nucleo basado en los desarrollos de Solaris, contando con herramientas como Dtrace, Zfs,Crossbow, Containers etc, un nucleo muy bien desarrollado y tremendamente estable, como ventaja añadida tendremos el poder usar las ultimas incorporaciones en los desarrollos (por ejemplo deduplicacion de datos, switches virtuales, priorizacion de trafico…) asi como disponer de una herramienta que bien de forma nativa bien a través de herramientas de virtualizacion (virtualbox, xvm o wine(este ultimo en puridad no un sistema de virtualizacion)) permite el uso de todo tipo de programas que en otros casos no prodriamos utilizar (aplicaciones propietarias windows o desarrolladas exclusivamente para windows p.ejm)

Inconvenientes:

1. Tendremos que configurar manualmente todos los parametros para adaptarlo a nuestras necesidades (al no ser un appliance de almacenamiento).
2. Si bien el nucleo de opensolaris es tremendamente estable, no podemos decir lo mismo del userland, el cual adolece aun de inestabilidad y falta de madurez… sobre todo en el gestor de paquetes IPS que pese ha haber mejorado considerablemente todavia tiene un nivel excesivo de fallos (y de lentitud, y de consumo de recursos…), lo mismo puede decirse de los sistemas de actualizacion de versiones (con un indice de fallos todavia excesivos).

En cualquier caso, y pese a los inconvenientes, y dado que el sistema no va a ser usado en entornos criticos (y lo que es mas importante, los inconvenientes afectan a los programas en si, no a la seguridad e integridad de nuestros datos), podemos considerarlo como la opcion mas interesante de todas las disponibles.

Nexentastor

Nexentastor es un appliance de almacenamiento basado en Nexenta, que no es sino un desarrollo que utilizando un nucleo opensolaris, intenta incorporar el userland de debian (ubuntu en la actualidad), asi incorpora gran parte de las capacidades de Opensolaris (dtrace, zfs, crossbow…) con las utilidades propias de debian (gestor de paquetes apt-get por ejemplo). El principal problema de nexenta es que las aplicaciones disponibles en el userland todavia son limitadas, por lo que no nos da por el momento la flexibilidad de opensolaris.

En cuanto a Nexentastor, al appliance de storage, si lo que buscamos es exclusivamente un sistema de almacenamiento para su uso como servidor NAS o SAN tanto a nivel empresarial como a nivel domestico, esta es con diferencia la mejor opcion existente, tanto por la estabilidad, como por la sencillez de uso, escalabilidad seguridad etc, con nexentastor podemos realizar replicacion automatizada, snapshots automatizados, soporte Active Directory,  scrubbings periodicos, analisis de rendimiento y configurarlo para recibir notificaciones tanto de errores, como de estadisticas de uso etc, todo ello con un entorno web intuitivo.

Nexentastor tiene 2 versiones diferenciadas, la comunity edition (permite utilizar hasta 12 TB efectivos de datos (es decir, podemos incorporar 2 raidz de 4 discos de 2 TB cada uno y no alcanzariamos ese limite) y la versión empresarial (con soporte, posibilidad de utilizacion de plugins de HA y otras características avanzadas), en nuestro caso la community edition sería mas que suficiente.

En cualquier caso, y pose a no utilizar esta opción (pues no nos puede brindar la opción de incorporar aplicaciones para p2p p.ejm, o servidores web o servidor UPNP AV, repito que es la mejor opción disponible como appliance de almacenamiento (comparándolo con sistemas como Openfiler, o Freenas o incluso con sistemas propietarios de Netapp, EMC, HP …)

EON

Eon Embedded Operating system/Networkinges un proyecto personal de un desarrollador llamado Andre Lue cuya idea es crear un appliance con las características de freenas (ya alguna añadida) pero con el nucleo opensolaris, de este  modo incorpora soporte UPNP /AV, asi como un servidor web basico.

Ventajas… todas las de los nuevos núcleos opensolaris (crossbow, deduplicacion, etc), instalable en equipos con recursos limitados etc.

Inconvenientes: proyecto muy joven mantenido por un único desarrollador (por lo que las posibilidades de bugs son considerables). En cualquier caso, es un proyecto muy interesante a tener en cuenta, sobre todo si al mismo se incorpora un entorno gui como napp-it (otro proyecto muy interesante de gui para gestión de storage y otros servicios)

Dado que tenemos que escoger una opción, y una vez analizadas todas las posibilidades, optamos por el desarrollo mas genérico… opensolaris 2010.3 (todavia no publicado al escribir estas lineas…).

En las próximas entradas desarrollaremos un análisis de las opciones de hardware existentes (una vez seleccionado el sistema operativo).

Compártelo

Esta entrada va a resultar un poco tecnica y bastante farragosa para los no iniciados en el mundo de ZFS. Basicamente ZFS es un sistema construido (en teoria) a prueba de todo tipo de fallos, disponiendo de un conjunto de herramientas cuya finalidad es precisamente simular todo tipo de situaciones anomalas (perdidas de conexiones, discos dañados etc); el problema surge normalmente cuando alguna parte de los elementos involucrados no actua como debe actuar (sobre todo, cuando un disco duro que recibe una orden de sincronizar la cache en el disco (es decir, escribir efectivamente en el disco duro lo que tiene almacenado en su memoria cache) indica que lo ha hecho, cuando en realidad no lo ha hecho… esta actuacion (cuya finalidad es obtener mejores resultados en los benchmarks) puede producir ocasionalmente situaciones de corrupcion de datos (en el caso de que se produzca un fallo en la red electrica en ese momento p.ejm), o bien cuando por algun bug de programacion zfs no sea capaz de reconocer la estructura dañada del ubberblock.

Antes de nada debemos saber que es y que importancia tiene el uberblock en un pool zfs, asi como conocer basicamente la estructura interna de un disco en un pool zfs, para, una vez comprendidos estos conceptos proceder a la reparacion del sistema.

La gestion de la ubicacion de datos asi como es realizada por una de los componentes integrantes de ZFS en concrto por el SPA (Storage pool allocator), de forma basica diremos que cada pool esta dividido en vdevs internos o logicos y vdevs fisicos, de este modo si disponemos de 2 discos A y B en un mirror denominado M1, los vdevs fisicos serían A y B y M1 el vdev logico.

Cada vdev fisico (los discos) dispone de varios vdev labels, todos ellos identicos (los de cada disco), en concreto son 4, ubicados en zonas fijas del disco al comienzo y al final del mismo (para garantizar que si se produce un fallo fisico en una parte del disco, poder acceder a los datos…

1º label: 0-256 KB 2º label: 256-512 KB ………3º label: N-512 KB 4º label: N-256 KB (siendo N el tamaño total del dispositivo).

Bien, ya conocemos donde estan los labels… pero ¿que contienen?…datos esenciales para el funcionamiento del pool…

0-8 KB: Espacio vacio

8-16 KB: Cabecera del bloque de arranque

16-128 KB: descripcion del vdev logico… incluye la identificacion del disco, la descripcion de a que vdev logico pertenece asi como los datos del resto de vdevs fisicos que pertenecen a ese vdev logico (es decir, si en nuestro ejemplo hemos creado un mirror llamado M1 con los discos A y B… tanto en el label de A como en el de B apareceran los datos descriptivos de A y B asi como de M1, redundancia en prevision de posibles fallos), tambien incluye datos descriptivos del estado del pool, version de zfs…etc

128-256KB: Uberblock, o mas bien array de uberblocks, pues cada uberblock ocupa 1 KB, es decir, en cada label puede haber hasta un total de 128 uberblocks.

La pregunta es…¿que es el uberblock?… podemos definirlo como el puntero maestro, el que nos va a dar acceso a la totalidad de datos del pool, el que nos muestra las puertas a las que debemos llamar para poder acceder a los datos; dado que zfs tiene una estructura de arbol de datos y metadatos (entre ellos punteros), el uberblock constituye el punto de inicio de todas las busquedas y accesos a los datos (aparte el checksum del uberblock constituye la firma digital de la totalidad del pool… pero ese es otro tema aparte), es decir, sin uberblock (o acceso al mismo) NO HAY DATOS. Por esta razon el uberblock es tan esencial, y por ello disponemos de 4 copias en cada disco (es decir, si tenemos un pool con 5 discos, tendremos un total de 20 copias del uberblock).

Como podemos ver, zfs tiene una obsesion: la seguridad y la redundancia de los datos esenciales para el funcionamiento… pero como establece la ley de Murphy… todo falla (o puede fallar).

En la proxima entrada describiremos la estructura del uberblock, explicaremos el sistema de actualizacion transaccional y de Copy on write del mismo, y finalmente veremos como “reparar” un sistema con los uberblocks dañados.

Compártelo

Hoy vamos a hablar de un proyecto para solaris-opensolaris denominado simple panels.

Es un proyecto sin grandes pretensiones que no pretende sino ser un GUI para las acciones mas habituales realizadas en los sistemas basados en solaris sobre todo para la gestion de ZFS, SMF y SVM (si bien esta ultima parte va a tener una utilidad mas bien escasa en los nuevos sistemas basados en ZFS).

Tras una breve conversacion (he de reconocer que no costo mucho convencerle…) con uno de los desarrolladores del proyecto (Victor Fernandez), parece que va a incorporarse la opcion de replicacion remota y automatizada de pools (una opcion muy interesante).

Confio en que el proyecto llegue a buen puerto, pues si bien es por todos conocido que habitualmente los entornos graficos no ofrecen la potencia de la linea de comandos, no es menos cierto que ofrecen cierta facilidad de uso y flexibilidad que en ocasiones es necesaria.

El enlace al proyecto:

http://blogs.sun.com/upm/entry/proyecto_simple_panels_comunidad_opensolaris

Compártelo