Hace poco hablamos de la importancia de los proximos desarrollos de intel (Sandy Bridge) y las aportaciones a los sistemas de storage. En este mercado la practica totalidad de desarrollos estan basados en en chipsets y tecnologia Intel.

Pero, si nuestro objetivo es disponer de un sistema SAN / NAS avanzado en el que la prioridad sea: consumo electrico, coste de sistema y seguridad de datos… es decir, prescindiendo de aspectos como… altisimo rendimiento y muy elevada capacidad de almacenamiento… en este caso AMD tiene mucho que decir.

Para empezar debemos explicar que es AMD Fusion: es el nombre en clave de un proyecto de creacion de una nueva familia tanto de microprocesadores como de chipsets, llamados a sustituir a la familia K10 de amd (familia con mas de 8 años en su haber… su desarrollo comienza el año 2003, pues la gama k10 no es sino una evolucion natural de la gama k8, que comienza con el Athlon 64), este desarrollo rompe completamente los diseños anterioriores… por diversas razones:

a. Integra el procesador grafico dentro del propio die del procesador, intercanectando procesador y procesador grafico sin intervencion de conexiones externas.

b. Se centra en optimizar el consumo energetico, especialmente en la gama “Bobcat”.

De este modo AMD ha preparado 2 gamas… la denominada Bobcat… que integra un procesador de doble o simple nucleo y un chipset de bajo o ultrabajo consumo… como podemos ver en la siguiente imagen:

Y por otro lado dispondremos de una gama de microprocesadores para desktop y servidores cuyo nombre en clave es Bulldozer (disponibles a mediados de este año)

Para nuestro uso, vamos a prescindir de la gama movil, (pues la frecuencia de trabajo del procesador puede ser excesivamente reducida para nuestras necesidades). centrandonos en el modelo de doble nucleo con chipset Zacate… ¿cuales son las caracteristicas de este sistema?…

1º. Una controladora grafica con características mas que “aceptables” (considerablemente superior a la gama ION de Nvidia por poner un ejemplo, y que puede reproducir sin problemas contenido h264 fullHD (1080p) con una carga del sistema del 33%. (Para nuestro uso como sistema de almacenamiento no es importante… pero es un dato a tener en cuenta).

2º. Procesador doble nucleo a 1600 Mhz… con amplias posibilidades de incrementar esta velocidad (overclocking), con juego completo de instrucciones 64 bits… SSE, SSE2, SSE3… incluso instrucciones para virtualizacion de sistemas (AMD-V)

3º. Soporte hasta 8 Gigas memoria DDR3

4º. Hasta 6 puertos SATA 3.0 (6 Gbps)

5º. Soporte memoria ECC (controlador de memoria integrado en nucleo).

7º. Hasta 14 puertos usb 2.0

8º. Un puerto pci-e 4x

Unamos todos estos datos y que obtenemos…

Un sistema de doble nucleo con potencia (doble nucleo 1,6 Ghz)  y caracteristicas (64 bits) suficientes para soportar cualquier sistema operativo que admita sistemas de ficheros avanzados (zfs), con soporte memoria ECC (garantia de integridad punto a punto de datos), con soporte SATA 3.0 (eliminamos el cuello de botella de SATA 2.0 si utilizamos discos SSD como cache o cache L2ARC, imprescindible si queremos hacer uso de deduplicacion), que nos permite adicionar hasta 8 Gb de memoria… es decir, podemos hacer uso de caracteristicas simples de NAS (compartir ficheros, servidor ftp), hasta las características mas avanzadas (compresion y encriptacion, deduplicacion, replicacion remota, snapshots automatizados, comparticiones iSCSI, hybrid storage….).

Pero vayamos a un ejemplo concreto… imaginemos un entorno soho… en el que debemos suministrar los datos hasta a 7 equipos cliente.. perfectamente podriamos optar por una solucion compuesta por:

a. Caja CFI A7879…

b. Placa GA-E350N-USB3

c.  3 Discos duros WD15EARS (bajo consumo), 1,5 Tb

d.  Opcional como cache de lectura zfs: Intel X25-M G2 120 Gb

En una configuracion estandar… RAIDZ, obtendriamos un sistema con una capacidad de almacenamiento de 3 TB, con hasta 8 Gigas de RAM y 120 gb de Cache de lectura (que nos suministraria los datos de uso habitual para los usuarios a una velocidad de hasta 290 MB/s)… todo ello con un consumo estimado de aproximadamente 68 W en plena carga (38 W placa + 8W*3 discos duros + 6 W SSD)… y como muestra una imagen de usa placa con el procesador overclockeado a 2,6 Ghz a plena carga… 48 W de consumo en total… un sistema estandar (y no hablamos ya con discos de 15.000 rpm en sistemas basados en intel XEON), facilmente triplica esa cifra de consumo electrico…

Opcionalmente podemos añadir (aprovechando el conector pci-e 16 x disponible (el cual es realmente 4x), una controladora de red adicional para incrementar la capacidad de conectividad del sistema.

Deduplicacion, alto rendimiento, integridad punto a punto, encriptacion, snapshoting automatizado, servicios de servidor avanzado (NAS y SAN), opcionalmente DLNA, opcionalmente P2P, etc.. todo ello por menos de 850 € y un coste electrico anual inferior a los 80 € (suponiendo funcionamiento 24×7x365) ¿alguien da mas???.

Compártelo

Es de sobra conocido por todos la actual situacion de escasez de ip en un entorno de demanda creciente de un recurso tan limitado (y exageradamente mal repartido) como es el de los rangos de direcciones IP, por lo tanto la introduccion de un cambio en los protocolos era imperativo.

A modo introductorio, recordemos que IPV4 se compone de un total de 4 octetos de direcciones posibles, lo cual nos permite 2^32 direcciones…unos 4.200 millones de direcciones lo  cual es un numero suficiente para asignar una ip a casi cada habitante de la Tierra … pero claramente insuficiente a dia de hoy.

¿Como se ha llegado a esta situacion?… una mezcla de factores  lo ha hecho posible:

1º. IPV4 nace en el año 1981, en un contexto de claras limitaciones tecnologicas (imaginemos los anchos de banda existentes en aquel momento, y lo que podria suponer la utilizacion de cabeceras de mayor tamaño para el envio de informacion), asi como con un numero de potenciales usuarios tremendamente limitado (recordemos que a principios de los 80 arpanet estaba constituido por apenas 100 nodos, y no seria hasta comienzos de los 90 que internet alcanzo el millon de nodos).

2º. El reparto de rangos IPs ha sido muy desigual y poco “democratico” (de este modo se asignaronclases A (hasta 16 millones de direcciones) y B a empresas americanas, lo cual disminuyo conisderablemente la disponibilidad a posteriori de direcciones). En disculpa de la entidad de asignacion, cabe decir que cuando se creo IPV4 no se creyo que la evolucion fuera tan rapida como hemos podido comprobar (y el consumo de ip tan rapido…)

3º. El crecimiento exponencial de dispositivos conectados a internet: no solo PCs, en estos momentos hay dispositivos moviles, maquinas  con control y gestion remoto (ejm: autoexpendedoras), etc etc

De este modo, se creó la version 6 del protocolo IP, con ello se pretendia fundamentalmente solucionar una serie de problemas derivados de IPV4, como son: la necesidad del uso general de NAT, la posibilidad de implementar seguridad nativa punto y sobre todo las limitaciones en el numero de IP disponibles.

¿Y como han aumentado el numero de IP?… aumentando el rango, en este punto, podriamos haber pasado a un sistema de 5 octetos 2^40… pasando de 5 mil millones de IP disponibles, hasta 1280 mil millones (1,2 billones de ip), o, opcion mejor: pasando a 6 octetos  2^48… tendriamos disponibles 327 billones de IPs…cada persona en la tierra tendria a su disposicion mas de 50.000 direcciones Ip diferentes… o llevandolo mas al extremo… 7 octetos … 84.000 billones de IPs (unos 12 millones de Ips por persona) o al estilo Bilbao… 8 octetos…21,5 trillones (o 21,5 millones de billones)…unos 3072 millones de ips por persona.

En cualquiera de estos casos las ip nuevas hubieran sido del rango: 87.29.229.254.263.88 (suponiendo 6 octetos)… y que opcion han elegido???… 5 octetos…no, 6 octetos… no… mejor lo hacemos a lo grande… pero MUY GRANDE… vamos a democratizar internet hasta la eternidad: nos vamos a 16 OCTETOS…  2^128)…

Y esto cuanto es…imaginemos  que exploramos y conquistamos el sistema solar, terraformamos todos los planetas, alcanzando una poblacion total de 600.000 millones de personas (100 veces la actual) ahora imaginemos que deseamos asignar una direccion ip diferente a cada persona durante cada segundo de su vida (es decir, usamos 600.000 millones de IP por segundo…), bien, en ese remoto supuesto, necesitariamos 70.000 billones (españoles, no americanos) de años para agotar todas las direcciones… es decir, podemos asignar una direccion IP a diferente a cada persona, a su coche, su casa, su perro, a cada una de las celulas que lo componen, podemos incluso asignar direcciones ip diferentes a todos y cada uno de los organismos vivos que hay en el planeta tierra (incluyendo plantas, hongos, liquenes, placton, virus y bacterias diversos)… eso si, por el momento no podemos asignar una IP propia a cada uno de los atomos que hay en la tierra… imagino que eso lo dejaremos para IPV7.

Y en la practica…¿cuantas direcciones me corresponden?… o mas bien…¿cuantas direcciones ip va a asignarme mi ISP?… la respuesta es sencilla unas poquitas… apenas 8 octetos 2^64, es decir, nuestro router (que ya no va a gestionar una ip publica, sino un rango de IPs), va a gestionar  4 MIL MILLONES DE VECES EL NUMERO DE IPS DISPONIBLES EN LA ACTUALIDAD CON IPV4…

Como indico en el titulo, esto no es matar mosquitos a cañonazos… pasamos directamente a misiles termonucleares (un saludo a Yuri)

Compártelo

La introduccion por parte de Intel de su nueva microarquitectura para procesadores denominada Sandy bridge va a suponer una autentica revolucion en una serie de conceptos que tradicionalmente vienen existiendo en el mundo del almacenamiento empresarial.

Comenzamos con la inclusion en el propio procesador del soporte y gestion de la memoria ECC (siguiendo los pasos de AMD, que incluye ese soporte en la practica totalidad de micros, incluyendo las gamas desktop.), anteriormente esta gestion debia realizarla ser realizada a traves de un chip incluido en la placa base.

Por otro lado, si bien no destacable a efectos de servidores, destaca la inclusion en el propio chip de los procesadores graficos (si bien esta característica ya estaba disponible desde los modelos I5 basados en la microarquitectura Westmere.

Los cambios redicales comienzan en la introduccion de soporte RAID nativo en el procesador asi como soporte nativo SAS 2 y 3 en el chipset. Tradicionalmente la gestion de SAS e incluso RAID se reservaba a adaptadores independientes del chipset, y por tanto, normalmente no integradas en placa.

La inclusion de soporte RAID en procesador asi como SAS en placa va a permitir:

1. Incrementar considerablemente el rendimiento en el subsistema de storage.

2. Reducir los costes de infraestructura

3. Reducir el consumo electrico del conjunto.

Como avance de las novedades futuras, podemos ver el siguiente documento: Avance placas supermicro
que contiene informacion relevante al respecto, asi como las proximas novedades de este fabricante.

Compártelo

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