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

Hoy en dia, el funcionamiento de un servidor web corporativo es esencial para muchas empresas, y que el mismo este operativo durante las 24 horas del dia los 365 dias del año es, si no imprescindible, si muy recomendable.

Si algo es seguro en el mundo de las nuevas tecnologias es que antes o despues éstas fallan, y debemos contar con un plan de contingencia para estas situaciones. Pero antes de ello, es conveniente plantear posibles escenarios de fallos y planificar una infraestructura que sea capaz, de forma autonoma y automatica de solventar posibles fallos tanto de los equipos como de la red.

El punto de fallo mas habitual del sistema suele ser el equipo que actua como servidor web (que habitualmente incluye servidor de base de datos asociado al servidor web), en este punto la instalacion de un sistema de replicacion de datos (idealmente drdb que permite la duplicacion de los datos de las bases de datos, pues trabaja a nivel de bloque y no de fichero), junto con heartbeat nos va a permitir que de forma automatica si un equipo falla, el equipo (o los equipos) configurados como esclavos pasen a maestros (dando continuidad al funcionamiento del sistema).

Otra alternativa de trabajo si no queremos trabajar con sistemas de HA como hearbeat, seria la instalacion de un sistema de clustering web en conjuncion con un reverse proxy (como HAproxy o Pound).

El problema asociado a este sistema viene derivado del funcionamiento síncrono de drdb y de cualquier  sistema de clustering (es decir, las modificaciones se realizan simultaneamente en todos los equipos que conforman el sistema), ello implica la disponibilidad de una red exclusiva para este uso asi como una alta velocidad de interconexion entre equipos (alta velocidad que habitualmente no vamos a disponer entre equipos ubicados en distintos datacenters salvo que se contraten conexiones dedicadas y de un coste muy elevado).

La anterior infraestructura nos garantiza el funcionamiento de nuestro sistema a nivel interno (es decir, en el datacenter donde esten ubicados los equipos), pero… ¿que ocurre si hay un fallo en la red que comunica nuestros equipos con el resto de redes? (por ejemplo, un fallo en un swich del datacenter, o de un router del mismo, o un corte de linea de acceso a internet del datacenter)… en este punto es donde debemos replantear toda la infraestructura y utilizar un sistema conocido como DNS failover, la idea basica es ubicar en 2 (o mas) lugares diferentes nuestros servidores web y utilizar otro equipo como gestor de las peticiones DNS.

¿Como funciona un sistema de dns failover?: basicamente consiste en un servidor dns (configurado con un ttl lo mas bajo posible en cada dominio que gestiona)  y un sistema de monitorizacion, de este modo, si el sistema de monitorizacion detecta que el servidor primario no esta disponible, modifica los parametros del servidor dns para que el dominio ahora sea redireccionado al servidor secundario (o terciario si lo hubiera).

En nuestro caso los equipos estan ubicados en 2 datacenters (ambos en paises de la Union Europea, lo cual evita problemas referentes a la transmision internacional de datos de tipo personal regulados por la LOPD) utilizamos un sistema de replicacion asincrona de datos (a traves de rsync, si bien hay otras opciones como unison, etc) y de las bases de datos (a traves de la replicacion nativa de mysql en este punto se puede optar por un esquema multimaster, o el esquema tradicional maestro-esclavo, este último requerirá intervencion tanto para su conversion en maestro como para la posterior reconversion en esclavo del equipo).

La gestion del DNS failover: si bien existen herramientas para su gestion directa, es preferible la utilizacion de los servicios de empresas especializadas (que garantizan con sistemas de clustering y multiple redundancia el servicio de DNS, el cual es esencial para el funcionamiento del resto de componentes) las cuales ademas de gestionar dinamicamente las dns nos remitirán un aviso en el momento en que se detecte cualquier anomalia en el funcionamiento de nuestros sistemas.

Compártelo