David Mataró

Migración del blog

2010-10-26T20:20:00.002+02:00

He migrado el blog a wordpress y ahora se aloja en un servidor de Ingent Grup. La nueva dirección és http://davidmataro.com/es y http://davidmataro.com para la edición en catalan.

Initr

2010-10-13T23:55:00.007+02:00

Initr es un proyecto liderado desde Ingent Grup para la administración automatizada de sistemas distribuidos. Initr nace como una interface de gestión de módulos de puppet desarrollada y utilizada por Ingent Grup como herramienta principal de gestión de sistemas para ofrecer el servicio Ingent Network .

Initr se caracteriza por ser una herramienta flexible, escalable y distribuida.

· Felxible: permite la gestión de la configuración de cualquier software.
· Escalable: permite gestionar de forma unificada y automatizada entornos con pocos servidores y entornos con miles de servidores.
· Distribuido: permite gestionar de forma centralizada servidores distribuidos en diferentes Data Centers.

Con Initr y de manera sencilla se puede reproducir cualquier configuración de un sistema en otro servidor. Permite reproducir la configuración de un sistema de manera automática en caso de pérdida del mismo, o instalar nuevos servidores dentro de una granja de servidores de manera rápida y automatizada.
Initr permite a los administradores de sistemas perder menos tiempo en tareas repetitivas y reduce la posibilidad de errores humanos en la configuración de los sistemas. Hechos que permiten reducir el coste operativo de administración de los sistemas.

Initr dispone de un conjunto de módulos o clases ya desarrollados para la administración de sistemas con puppet y permite desarrollar nuevos módulos personalizados. Entre los módulos ya desarrollados y de ámbito generalista destacan:

· Módulo de monitorización con nagios.
· Módulo de estadísticas de uso con Munin.
· Módulo para gestionar procesos automáticos con monit.
· Módulo para la gestión de actualización de paquetes.
· Módulo para la administración de un servidor DNS con bind y para la administración de un DNS dinámico.
· Módulo para la administración del servidor web apache, con capacidad de adminitración de VirtualHost, bbdd mysql y awstats.
· Módulo para la gestión de samba
· Módulo para la gestión de un servidor ftp.
· Módulo para la gestión de un servidor de correo electrónico.
· Módulo para la gestión de squid.
· Módulo para la gestión de claves ssh y acceso remoto ssh transparente a los firewalls.

Un ejemplo práctico de cómo Initr ayuda a reducir los costes operativos de administración de sistemas es la instalación y administración de un sistema de monitorización.

Si nunca ha instalado nagios, sabrá lo que conlleva añadir un nuevo nodo o servidor a monitorizar: configurar el nodo y checks en el servidor nagios, instalar el cliente de nagios en el nodo, en caso de disponer de nodos distribuidos en diferentes Data Centers, configurar las reglas de firewall y checks pasivos. Y no digamos si esta tarea la hacen diferentes técnicos, la estructura de archivos de configuración de nagios puede degenerar mucho sino hay mucha disciplina por parte de los técnicos, provocando fallos en el sistema que se traducen en horas de este mismos técnicos para hacer tunning de la configuración.

Con Initr todo esto se simplifica. Una vez añadido el nodo a Initr - que es tan sencillo como crear el nuevo nodo en Initr y ejecutar un comando en el nodo -, para monitorizar el nodo con nagios, sólo hay que añadir la clase nagios al nodo desde la interfaz web de Initr y definir los checks deseados. De manera automática todo se configura (servidor, nodo, ..) y el nodo pasa a estar monitorizado desde nagios.

Probando ElasticHosts

2010-08-09T14:01:00.002+02:00

Hoy he leído que ServerBeach ha lanzado un servicio de cloud utilizando la plataforma de ElasticHosts y me he decidido a probarla. En el proceso de registro me he llevado la primera sorpresa. Se obligado poner un teléfono y que sea correcto ya que envían la mitad de la clave por mail y la otra mitad a través de un sms.

Una vez creada la cuenta se accede al panel de control vía https://lon-p.elastichosts.com/accounts/ con el mail como nombre de usuario y password que nos han enviado por mail y sms. Por defecto la demo tiene creada una máquina virtual con las siguientes características:

CPU: 2000 core MHz
RAM: 1024 MB
Drives: RedHat Fedora Linux 13 Live CD

El sistema asigna una ip dinámica en la máquina virtual y permite el acceso por vnc y a las estadísticas de tráfico desde el propio panel de control.

Para crear un nuevo servidor, desde la parte derecha del panel de control está la opción "Add server oro drive", aquí seleccionamos server, introduciendo un nombre - en mi caso test1 - y seleccionamos el tipo de instalación :

· Imagen pre-instalada: dispone de imágenes de debian, ubuntu y windows.

· Instalación desde un CD: dispone de cd de sación, debian, freebsd, knoppix, OpenSolaris, RedHat Fedora, Ubunto y Windows. esta opción permite por toda la instalación del sistema operativo de forma personalizada.

· Arrancar desde un live cd: también ofrece opciones en linux y windows.

· Arrancar desde una imagen de disco existente: hay que seleccionar la imagen previamente creada.

Para la prueba, he seleccionado crear el servidor desde una imagen pre-instalada y he seleccionado la imagen de un Debian Linux 4.0: System Base without X. Finalmente seleccionamos la capacidad del disco (1 GB).

Al pulsar Add, en el panel de control se muestra el nuevo servidor con nombre test1 y el nuevo disco también llamado test1. Podemos visualizar que en la vista del servidor indica que el disco del servidor es test1. El servidor permite las opciones de arrancar, editar y borrar.

Al seleccionar la opción de editar, se puede modificar el nombre del servidor, la cpu, la memoria, los discos la configuración de red y el password de acceso vnc. También hay unas opciones avanzadas donde se puede modificar el número de cores, el modelo de la tarjeta de red, configurar una lan privada y encriptar la sesión vnc.

Una vez arranque la máquina virtual test1 ya podemos entrar por vnc con el password que se indica en el panel de control. Una vez dentro, con el login root entramos directamente en la consola del sistema sin password. De modo que hay que poner una password. Una vez puesta la password la próxima vez que hacemos login ya nos pide la contraseña para entrar.

Por defecto, el único acceso al servidor virtual es vía vnc, de manera que si queremos acceso ssh, es necesario arrancar el servicio.

Ahora ya podemos empezar a trabajar con el nuevo servidor virtual.

A que destacar la posibilidad de crear vlan privadas para conectar las máquinas virtuales. Así permite desplegar arquitecturas de más de una capa con recursos de red dedicados.

ElasticHosts proporciona una API REST para la gestión remota de las máquinas virtuales vía llamadas HTTP. Para probarla podemos descargar el shell script elastichost.sh. Los datos de acceso desde la API están a My Account> Profile, son el UUID y Secreto API Key. En la web está toda la documentación para utilizar la API.

ElasticHosts presenta dos modalidad de facturación, una por carga de crédito y otra por pago de una cuota mensual.

My account> Billing: desde aquí podemos gestionar el consumo de recursos utilizados en la modalidad de prepago. Estos recursos se consumen por tramos horarios.

My account> Subscription: permite gestionar las suscripciones, donde se paga una cuota mensual por unos recursos. Es decir, permite pagar un tanto mensual por una cantidad de recursos de MHz de CPU, de RAM, Disco y de Tráfico.

Para finalizar, ElasticHosts presenta una interface de gestión simple y útil para la administración de servidores en cloud, la que se merece los premios que le están dando ultimamente. Sin duda esta es una muy buena opción para desplegar un servicio de alquiler de servidor en la modalidad de pago por uso.

Del Datacenter al servidor, nuevas tendencias de refrigeración.

2010-07-09T20:30:00.003+02:00

Hace días leí un post sobre servidores de IBM refrigerados por agua. Hoy he leído en Data Center Knowledge que Google ha patentado el Liquid-Cooled 'Server Sandwith'. Esta no es la única patente de Google en cuanto a sistemas de refrigeración en entornos de alta densidad. Hace unos días ya publiqué un post donde hacía referencia al diseño de datacenters basados en contenedores de Google.

Que dos gigantes como IBM y Google estén trabajando para refrigerar directamente los servidores en lugar del Datacenter lleva a ciertas reflexión sobre las nuevas tendencias en los sistemas de refrigeración del Datacenter o mejor dicho de los servidores.

Si recordamos cuál es el objetivo de un sistema de refrigeración en un Datacenter, este es disipar el calor que generan los servidores al coste más bajo posible. Por eso hemos ido evolucionando, pasamos de sistemas de climatización basados en aire-aire en sistemas de climatización basados en agua-aire, sistema más eficientes energéticamente. También hemos ido evolucionados en cuanto a la gestión del aire. Es decir, hace unos años se refrigera las salas donde se alojaban los servidores sin más. Después implementemos pasillos frío y calientes y a día de hoy estamos conteniendo el aire frío o conteniendo el aire caliente o desplegando datacenters en contenedores. Cada vez estamos llevando el aire frío más cerca del servidores reduciendo los m3 a climatizar. Y esto lo hacemos porque los servidores que debemos refrigerar están diseñados para ser refrigerados con aire.

Ahora, el cambio de tendencia que están marcando IBM y Google entre otros, cambiando la refrigeración de los servidores de aire a agua, provoca un cambio de la infraestructura de refrigeración del Datacenter. Si ahora llevan el agua de las refrigeradoras a los equipos de sala, ahora deberá llevarse hasta el rack de la misma manera que lo hacen los sistemas inRow tipo APC . Pero además, el agua deberá llegar a los servidores y por eso tendrán que adaptarse los racks, como ya han hecho algunos fabricante adaptando puertas traseras refrigeradas por agua para entorno de alta densidad.

Otro elemento que cambia es la gestión, esto puede suponer la definitiva integración de los sistemas de control de las infraestructuras con los de los servidores y elementos de red. Controlando desde un único punto la temperatura de los procesadores, del agua de los circuitos internos de los servidores, de la velocidad de impulsión, consumo eléctrico, ... conjuntamente con la ocupación de memoria, de disco, tráfico de red, ...

Sin duda este cambio en la arquitectura de refrigració del servidores forzará a cambiar muchos elementos del Datacenter.

Instalación automática de sistemas con Cobbler

2010-07-05T16:29:00.006+02:00

En todo Datacenter, la automatitizació de sistemas es una tarea imprescindible para minimizar los costes operativos de desarrollar un nuevo sistema, mantener la homogeneidad de los sistemas y evitar los errores humanos. Con la virtualización y la posibilidad de clonar máquinas virtuales rápidamente, automatizar la instalación de nuevos sistemas se ha simplificado. Sin embargo, no todos los sistemas son virtuales, de modo que hay también en la instalación de los sistemas físicos además de los virtuales.

Una herramienta para automaitzar la instalación de sistemas físicos y virtuales es Cobbler . Cobbler permite a los administradores de sistemas centralizar y automatizar la instalación de sistemas, ya sean físicos o virtuales. Cobbler es un proyecto OpenSource de RedHat que se incluye dentro de FedoraHoted . Cobbler se estructura en los elementos siguiente:

- Distribuciones: una distribución contiene toda la información realcionadas con el kernel, scripts, ... de una instalación. Es decir, es una distribución de Linux a partir de la cual se realiza una instalación.

- Perfil: un perfil es una particularización de la instalación de una distribución. Esta particularituzació se hace mediante la definición de un archivo de instalación kickstart. Un perfil por ejemplo puede representar la instalación de un servidor web, de un servidor de bbdd o de una estación de trabajo.

- Sistema: un sistema no es más que la instalación de un perfil sobre un servidor físico o virtual concreto.

- Repositorio: un repositorio es un mirror de las actualizaciones de una distribución concreta. De esta manera, los sistemas instalados desde Cobbler actualizan los paquetes desde el mismo servidor de Cobbler y no desde Internet. Así, se acelera la actualización de paquetes y se reduce el tráfico de red Internet.

- Imágenes: son instalaciones que se hacen sobre un archivo ISO. De manera que esta imagen ISO se puede instalar tanto en un servidor físico como virtual.

Cobbler dispone de dos interface de trabajo, una vía línea de comandos y una segunda vía web. Desde ambas interface se pueden gestionar las distribuciones, perfiles, sistemas y repositorios.

Desde el punto de vista de un Datacenter, Cobbler permite automatizar la instalación de nuevos servidor de hosting dedicado o virtual, la re-instalación de forma rápida un servidor que ha fallado e incluso, disponer de plantillas de servidores (perfiles) que se instalen automáticamente en función de la necesidad de carga. Por ejemplo, en caso de un portal web con un frontal formado por N servidores Apache, si aumenta la demanda se pueden instalar nuevos servidores Apache de manera rápida e incluso de manera automática. Y este servidores Apache se instalan basados en una plantilla (perfil) determinada.

Más información en Cobbler .

Modular Natural Free Cooling

2010-06-27T16:56:00.004+02:00

El pasado 2 de junio asisti a la jornada que anualmente organiza AST-GLOBAL llamada Nueva Nueva Generación de Datacenters. Para quien no conozca AST-GLOBAL, esta es una empresa lider en soluciones de Datacenters modulares, seguros i eficientes energèticamente.

En esta jornada AST presentaba el Modular Natural Free Cooling. Modular Natural Free Cooling
es una tecnologia innovadora patentada por AST que permite hacer free cooling a 24ºC o por debajo. Esta solución ya esta implantada en Thor - una empresa de islándia - donde se ha conseguido un PUE de 1.07. Sin duda un PUE extremadamente bajo. Però lo más significativo de la solución es que permite hacer free cooling un 80% del tiempo aproximadamente en sitios como Barcelona o Madrid.

En el link hay una tabla con las temperaturas de las principales ciudades de américa del norte i europa donde se visualiza el % del tiempo en que se pude operar en free cooling utilizando esta tecnologia.

Probando Googlecl

2010-06-19T18:34:00.002+02:00

Google ha publicado Googlecl, un shell que utiliza las APIs de Google i que permite gestionar los servicios de Google desde línea de comandos. Permite gestionar los servicios siguientes:

· Blogger
· Calendar
· Contacts
· Docs
· Picasa
· Youtube

Primero hay que instalar googlecl. En mi caso lo instalo sobre Mac OS X:

1. Instalar Xcode

Lo instalo directamente desde el DVD de Snow Leopard. También se puede descargar de Developer Tools.

2. En caso de no tener instaladas las X, también hay que instalar las X.

3. Instalar macports

Descargar MacPorts-1.9.1.pkg de la web de macports para Snow Leopard e instalarlo.

Abrir un terminal y executar 'sudo port -v selfupdate' para asegurar que se tiene instalado la última release.

4. Instalar googlecl

sudo port install googlecl

Para utilizar googlecl hay que ejecutar google seguido del servicio y de la tarea a ejecutar. Por ejemplo, para listar la lista de contactos hay que escribir:

$ google contacts list

La primera vez que se accede a un servicio pide que se autorize el acceso. Para ello, cuando ejecutar el comando por primera vez, te pide el usuario, y una vez entrado el usuario muestra una url con un token. Al poner esta url en un explorador se puede permitir o denegar el acceso. Siempre se puede volver a denegar el acceso conectando a google y seleccionando My Account -> Change authorized websites.

Obtener ayuda:

$ google --help

$ google help

A partir de aqui solo hay qeu dejar correr la imaginación para sacarle partido a googlecl. Un pequeño ejemplo. Si queremos hacer un backup de los contactos de google contacts podemos ejecutar el siguiente comando:

$ google contacts list > contacs.csv

Diseños de Datacenter de Google basados en contenedores

2010-06-18T18:15:00.004+02:00

Leo en Data Center Knowledge que google a patentado una torre de contenedores com Datacenter. La foto és muy ilustrativa, una torre de 4 pares de contenedores apilados. un total de 8 contenedores.

Este no es el único dissenyo de Datacenter de Google con contenedores. Las imagenes siguientes muestran otro modelo de Datacenter basado en contenedores, así como el diseño del sistema de refrigeración.

Aspectos a tener en cuenta para contratar un colocations

2010-06-12T13:30:00.004+02:00

Ya desde hace unos años, los sistemas de información cada vez toman más importancia en los procesos de negocio de las empresas. Lo que hace que la disponibilidad de estos sistemas de información sea critica. Tanto para empresas grandes como para empresas pequeñas. Los costes para disponer de unos niveles de disponibilidad de los sistemas de información conforme con el negocio son elevados, de manera que cada vez son más las empresas que buscan un colocation donde alojar sus sistemas de información.

Para escoger un Datacenter donde contratar un colocation, hay varios factores a tener en cuenta. Estos factores permiten entender el precio del servicio y ver si se ajustan a las necesidades a satisfacer.

Hay que tener claro la potencia eléctrica que necesitamos y la que ofrece el proveedor. Hasta ahora se estaban ofreciendo potencias de 2.2 kw y 4.4 kw con líneas de 16 y 32 A, pero hay proveedor que ofrecen potencias más elevadas. Es importante entender el método de facturación de la potencia que aplicará el proveedor, ya que es uno de los costes más significativos del colotaion. Hay proveedores que no miden la potencia consumida, sino que dentro de la cuota del servicio contratado incorpora el coste del máximo de corriente que se puede llegar a consumir, siendo este un coste fijo independientemente del consumo realizado. En cambio otros proveedores miden el consumo realizado y facturan este concepto aparte del servicio contratado, de manera que el consumo se trata de forma variable. En este último caso, es importante ver y entedra la formula que el proveedor utiliza para calcular el precio del kwh.

Por otra parte, también es importante identificar como el proveedor nos entrega la energía, si con una sola línea, una línea activa y una segunda pasiva o dos líneas activas. Esto nos determinará el nivel de redundancia de corriente que nos proporciona el proveedor y que influye en el precio del servicio también. Para tener claro la relación calidad precio - entendiendo calidad como a nivel disponibilidad que nos ofrece el proveedor - hay que conocer el nivel de reduncacia del Dataceter del proveedor.

Los niveles de redundancia de los datacenters están regulados por el estándar TIA 968 o por la institución americana Uptime Institute . Ambos definen 4 niveles de redundancia, Tier I, Tier II, Tier III y Tier IV, siendo el Tier IV el de mayor disponibilidad y el Tier I lo de menos. Sin duda, cuanto más alto es el Tier más costes de desarrollo y mantenimiento hay. Y este influye directamente en el precio del servicio. Por lo tanto se hace necesario identificar los niveles de disponibilidad que requiere para escoger el proveedor que disponga de los niveles de redundancia que se adapten a los requerimientos.

Otro factor que influye directamente en el coste es la eficiencia del Datacenter. Es decir, cuál es la relación entre el consumo de los servidores y el consumo en aire acondicionado para disiparse el calor generado por los servidores, así como las pérdidas en la distribución de la energía hasta los servidores. De esta relación se obtiene un valor llamado PUE (Power Usage Effectiveness). Cuanto más bajo es el PUE más eficiente es el Datacenter y por tanto menos costos de energía hay. Por lo tanto un proveedor con un PUE bajo, tiene menos costes energéticos, de manera que puede ofrecer un precio más competitivo.

La conectividad del Datacenter también es un factor determinante a la hora de seleccionar un proveedor. Aquí se pueden encontrar dos tipos. Datacenter de una operadora de telecomunicaciones y datacenters neutros. Los datacenters de una operadora por norma sólo disponen de comunicaciones de la misma operadora, aunque estas estén redundada. En cambio, los datacenters neutros disponen de más un operador o carrier. De cara a entender los costes de los datacenters neutros, hay que ver si este dispone de conexión directa a un NAP (Network Access Point), punto de acceso a la red donde se realiza el intercambio de tráfico entre operadores o carrier. Esto reduce los costes de acceso a los operadores o carriers, de manera que permite a los operadores ofrecer precios más competitivos y disponer de grandes capacidades de conexión. En ambos casos es importante identificar la redundancia se hace a través de caminos físicamente separados o no.

Por último, si hemos de alojar los servicios en un Datacenter también es importante conocer cuáles son los niveles de calidad de la gestión del servicio. Aquí, en los últimos años se ha impuesto la metodología de gestión del servicio basada en las mejores prácticas ITIL. En este sentido la ISO20000 permite a los proveedores certificar la aplicación de ITIL en la gestión del servicio. Por otro lado, la ISO27001 permite certificar la aplicación de buenas prácticas en la gestión de la seguridad.

Integracion entre Zenoss y Puppet

2010-04-24T20:51:00.004+02:00

Zenoss y http://www.puppetlabs.com colaboran para proporcionar al mercado una solución de monitorización y automatización de Datacenter integrada.

Zenoss es líder en la comercialización de una solución opensource de monitorización y gestión. Zenoss core es la base de zenoss enterprise y es una de los proyectos opensource con más activos. Por otro lado, http://www.puppetlabs.com es uno de los sistemas de automatización de nueva generación que permite gestionar gestionar gran cantidad de sistemas de forma muy rápida.

La integración de http://www.puppetlabs.com con Zenoss permite disponer de un sistema de monitorización y de gestión automática unificado que mejora las capacidades de gestión del Datacenter.

El módulo que integra zenoss con Puppet se puede baja de http://community.zenoss.org/docs/DOC-5818

Datacenter commissioning

2010-03-29T20:21:00.002+02:00

En cuanto se afronta un proyecto de construcción de un Datacenter, en la fase de diseño se especifican un conjunto de subsistemas (sistema eléctrico, sistema de refrigeración, sistema de detección y extinción de incendios, sistemas de seguridad física y sistemas de monitorización y gestión), la relación entre cada uno de los elementos y se estima el comportamiento del conjunto con carga. Después en la fase de despliegue, cada sistema es desplegado por el proveedor correspondientes - normalmente un proveedor para subsistema - y probado de manera individual. Cada proveedor realiza la puesta en marcha y las pruebas funcionales del subsistema que ha instalado para disponer de la aceptación del cliente y facturar. En este proceso, en ningún momento se hace una comprobación de todo el conjunto.Y es aquí donde el "Commissioning" toma importancia.

El objetivo del "Commissioning" es probar el comportamiento de todos los subsistemas trabajando conjuntamente, con el fin de comprobar si el desarrollo de cada subsistema alcanza los objetivos marcados en la fase de diseño y cumple con los requisitos iniciales. Es decir, es un proceso de validación de la instalación. También permite identificar las carencias de la instalación y los límites de la misma, información que será de mucha utilidad en la fase de explotación. Es por ello que la práctica del "Commissioning" es cada vez más utilizada en la fase de despliegue de un Datacenter.

Como todo proceso este está formado por una entrada, un conjunto de actividades y una salida.

Entradas:

Lista de requisitos de diseño y construcción del datacenter.
El diseño del Datacenter.
Resultado de las pruebas realizadas en la puesta en marcha de cada uno de los componentes del Datacenter.

Salidas:

Script: contiene la lista de componentes probados y el tipo de test realizado y el resultado obtenido.
Registro de error: es un análisis FMEA (Failure Mode Effects Analysis) de un componentes específica que ha fallado durante el test. Este identifica el impacto del error y recomienda las posibles soluciones.
Resumen ejecutivo: describe las acciones las pruebas realizadas y un plan de acción.

Actividades:

Las principales actividades del proceso de commissioning son realizar el script (scripting), ejecutar las pruebas y documentar.

Scripting: define la secuencia, el tiempo y el orden para hacer las pruebas de todos los elementos del Datacenter. También permite define los registros a obtener en cada prueba.
Ejecuta las pruebas: consiste en ejecutar una serie de errores en los elementos del sistema según una secuencia establecida y volver a restablecer los mismos. Con estas pruebas hay que probar tanto el sistema de alimentación eléctrica, de frío, de detección de incendios, ...
Documentación: hay que registrar todas las pruebas realizadas y documentar esto para dejar registrar el estado y comportamiento de todo el sistema. La documentación sirve tanto para ver el grado de cumplimiento del sistema respecto a los requisitos iniciales y el diseño, como para la posterior explotación del mismo.

Para ejecutar las pruebas del sistema con carga, se utiliza lo que se conoce como "load banks". Son un conjunto de elementos para generar calor en la sala y así probar tanto el sistema eléctrico como el sistema de refrigeración.

El proceso de commissioning no sólo es útil para comprobar el grado de cumplimiento de una instalación nueva e identificar las carencias y límites del mismo. Sino que también permite auditar un Datacenter construidos ya hace años o en producción.

Bibliografía de interés:

Asha Guideline 0 - the Commissioning Process: Guía donde describen todas las fases del proceso de Commissioning.
APC White Paper # 148 Data Center Projects: Commissioning.
APC White Paper # 149 Ten Errores to Avoid When Commissioning en Data Center.

Más sobre contenedores

2010-03-29T09:51:00.001+02:00

PowerHouse de la empresa ActivePower es un contenedor estándar ISO que contiene un sistema de alimentación segura, con generador autónomo y depósitos de gasóleo, UPS y un centro de conmutación. Este se comercializa con diferentes potencias de salida y con dos modelitats, una con sólo salida segura (UPS) y otro con dos salidas, una segura (SAI) y una no segura (sólo generador).

Sin duda que la entrada en juego de los contenedores como repositorios de racks, sistemas de frío y ahora sistemas de alimentación segura, está cambiado la fisonomía de los datacenters.

Datacenter en un container

2010-03-21T20:53:00.004+01:00

Esta semana he tenido la oportunidad de visitar las instalaciones que AST global, tiene en Cornella de Llobregat y ver la solución de Datacenter dentro de un contenedor Smart Shelter Container.

Es impresionante ver cómo los ingenieros de AST global, ponen dentro de un contenedor standard, que se puede llevar en cualquier lugar del mundo en camión o barco, todo un Datacenter, con racks, clima, SAI's, sistema de detección y extinción de incendios, videovigilancia, y todo lo necesario. Además, el sistema es totalmente flexible y modular y se adapta a las necesidades del cliente.

Por otro lado, también me enseñaron nuevas soluciones de free-cooling con las que están trabajando y que son revolucionarias y que seguro que en breve veremos todo el mundo.
Sin duda, nos encontramos ante una empresa innovadora dentro del sector de los Datacenter y que a buen seguro oiremos hablar mucho.

Os dejo el enlace al canal de youtube de AST, donde se puede ver el Smart Shelter Container.

Instalando Snow Leopard

2010-01-30T19:12:00.004+01:00

Ya hace tiempo que tengo en la cabeza sustituir el Tiger para Snow Leopard. Sin duda, la decisión me ha costado, ya que tal y como como se dice a menudo, cuando algo va bien no la toques. Sin embargo, hoy me he decidido a limpiar e instalar de cero Snow Leopard.

La instalación ha sido bastante sencilla, poner el dvd, seleccionar la opción instalar, formatear el disco y esperar un poco más de media hora. Al cabo de media hora, el sistema ha reiniciado y ya tengo Snow Leopard.

Como era de esperar los señores de mac cuidan los detalla hasta el último extremo, y el sistema nos da la bienvenida de forma espactacular con un video que nos da la bienvenida en diferentes idiomas.

Una vez vez arrancado, sorprende la rapidez con que abre el Finder y el Safari. Sin duda, la primera impresión en cuanto a la velocidad del sistema es que va más rápido que con Tiger sobre el dual core a 2GHz y 1 GB de RAM de mi MacBook.

Ahora toca recuperar toda la información e instalar todas las aplicacines. Para ello, antes de instalar he clonado el disco con Tiger sobre un disco externo USB mediante Carbon Copy. Este disco USB es la base a partir del cual empezar a recuperar toda la información sobre el nuevo Snow Leopard.

Una vez recuperada la información e instaladas las aplicaciones, he configurado Time Machine para que hagas copias de seguridad sobre el disco USB.

Y hasta aquí la instalación de Snow Leopard. Ahora toca disfrutarlo

Análisis FMEA

2009-12-20T19:58:00.003+01:00

FMEA (Failure Modes and Effects Analysis) o también conocido como el análisis de modos y efectos de fallo es una metodología para el análisis de los potenciales modos de fallo de un sistema o elemento y clasificarlos en base a la severidad, la probabilidad de ocurrencia y la capacidad de detección.

A continuación se describen los conceptos básicos de la metodología y cómo aplicarla para hacer un análisis de riesgos de un sistema.

Conceptos básicos:

Modo de fallo (Failure mode): es la manera en que se produce un error o fallo. Es decir si se analiza un sistema de alimentación eléctrica por ejemplo, un posible modo de fallo es la caída del suministro de compañía.

Efectos (Failure effects): es el efecto que produce el error o fallo sobre el sistema. Siguiendo con el ejemplo anterior, en caso de disponer un sistema de suministro eléctrico compuesto por el suministro de compañía y un sistema dedundant compuesto por un generador autónomo, el efecto ante la caída de la corriente de compañía es la pérdida de redundancia en el suministro eléctrico.

Causa (Failure cause): es el elemento, el defecto o proceso que ha iniciado el proceso de fallo. En el ejemplo puede ser un error en la central eléctrica.

Severidad (Severity): es la consecuencia que produce el fallo, entendida como el grado de daño que éste provoca.

Ocurrencia (Ocurrence): es la probabilidad de que pase el fallo en concreto.

Detección (Detection): es la capacidad de detección del fallo o error. Entendiendo como capacidad de detección, cuáles son las acciones proventivas, de test, monitorización para detectar el error antes de que éste se manifieste y afecte al servicio.

RPN (Risk Priotity Number): es el valor que se obtiene de la multiplicación de los valores o grados determinados en la severidad, la ocurrencia y la detección: RPN = S x O x D. El RPN sirve para priorizar las acciones a realizar sobre los sistemas o elementos, de manera que los modos de fallo con un RPN más alto, son las que podemos considerar más prioritarias a la hora de emprender acciones corretives o preventivas.

El proceso o metodología para hacer un análisis FMEA consiste en:

1. Detectar el modelo de fallo o error

2. Analizar y calificar la severidad

3. Analizar y calificar la probabilidad de ocurrècnia

4. Analizar y calificar el grado de detección

5. Determinar el valor de RPN

6. Emprender las acciones correctivas y preventivas

Este proceso formado por los anteriores seis puntos, se puede ejecutar cada vez que se pone un nuevo sistema o proceso en funcionamiento, o cada vez que este sistema o proceso se actualiza o es modifica, o cada vez que se detecta un problema en el mismo. Es importante, realizar el proceso cada vez que se modifica de un modo u otro el sistema o proceso, a fin de detectar posibles debilidades del mismo y poder tomar las acciones preventivas y correctivas antes de que éstas afecten el servicio.

También es importante realizar este análisis en la fase de diseño de un nuevo sistema, ya que permite incorporar al sistema las medidas necesarias para minimizar el riesgo de error del sistema y poder tomar las medidas correctivas en caso de que se produzca el error.

Una manera de realizar un análisis FMEA es utilizando una hoja de cálculo tal y como se muestra en el ejemplo siguiente. Donde se evalúa el error en el sistema de arranque remoto del generador en un sistema de suministro eléctrico con redundancia.

11 prácticas para mejorar la eficiéncia del datacenter

2009-12-08T19:20:00.003+01:00

Hace tiempo que en mi Blog en versión Catalan, escribi una entrada sobre las mejores prácticas para mejorar la eficiéncia energética del Datacenter, entrada que reproduzco a continuación en castellano.

En Data Center Solution leo que un informe de Gartner dice que las empresas pueden ahorrar un millón de kw hora implementando un total de once buenas prácticas.

1. Cerrar el agujeros en el suelo técnico

Los agujeros que se realizan para que entre o salga el cableado del suelo técnico son una fuente de pérdida de caudal de aire. Esta pérdida repercute directamente en la eficiencia del sistema de aire acondicionado. Por lo tanto reducir el número de agujeros del suelo técnico o sellar de manera que no haya pérdidas mejora la eficiencia energética del sistema de aire acondicionado del datacenter.

2. Instalar paneles en los racks

La instalación de paneles en las posiciones de los racks que no se utilizan evita la recirculación del aire caliente dentro del rack. Esto no permite que el aire caliente se mezcle con el aire frío y se introduzca dentro de los servidores y evita la aparición de zonas calientes en el datacenter.

3. Sistemas unificados

Utilizar sistemas de aire acondicionado que coordinen la función de enfriar con la función de humidicifar, de modo que no es necesario disponer de dos equipos por separado, uno para enfriar y otro para refrigerar.

4. Mejorar el flujo de aire en el suelo técnico

Aunque el suelo técnico de los centros de datos es un espacio para la circulación del aire acondicionado, la mayoría de los centros de datos aprovechan el suelo técnico para hacer pasar cableado, ya sea de datos o eléctrico. En la mayoría de los casos este cableado actúa coma un obstáculo para que haya una buena circulación del aire a través de suelo técnico. Por lo tanto hay que tener muy en cuenta a la hora de poner cableado u otros elementos en el suelo técnico, ya que al dificultar la circulación del aire, hace que el sistema de aire acondicionado consuma más energía.

5. Implementar pasillos fríos y pasillos fríos

Organizar la disposición de los racks en pasillos fríos y pasillos calientes, evitando así pasillos con aire caliente y frío al mismo tiempo, lo que incrementa la temperatura del datacenter ya que dificulta la circulación correcta del aire a través del datacenter.

6. Instalar sensores

Instalar sensores en diferentes puntos del datacenter permite la captación de datos - ya sea manual o automática - para ser analizadas. Este análisis permite detectar problemas de temperatura en zonas del datacenter y tomar medidas para solucionarlos.

7. Implementar contenedores calientes o fríos

El siguiente paso después de organizar el datacenter en pasillos fríos y pasillos fríos, es contener el aire frío o el aire caliente, de modo que el aire que esta dentro del contenedor - por ejemplo el frio - no se mezcla con el aire que está fuera del contenedor, por ejemplo el caliente. Esta medida aumenta sustancialmente la eficiencia del datacenter y permite la obtimització del espacio al permitir llenar los racks al 100%.

8. Augementar la temperatura del datacenter

Mantener la temperatura del datacenter en la curba de eficiencia que recomienda "The American Society of Heating, Refrigerating, and Air-Conditioning Engineers [ASHRAE] que se sitúa entre 77 y 80 grados Fahrenheit (de 25 a 26,66 grados centígrados).

9. Instalar equipos de velocidad variable

Los sistemas de aire acondicionado tradicionales disponen de una velocidad de funcionamiento fija. En cambio, ahora ya hay equipos que adaptan la velocidad los ventiladores y bombas de aire automáticamente. De modo que cuando se reduce la velocidad de estos elementos se produce un ahorro de energía considerable.

10. "Free Cooling"

Generalmente se denomina "Free Cooling" toda técnica de refrigeración que no utiliza unidades de refrigeración. Son técnicas que utilizan el aire exterior - si éste es más frío que el del interior - para renovar el aire interior o que utilizan la evaporación de agua para enfriar los equipos.

11. Diseño de un sistema de climatización modular

Diseñar el datacenter de manera que se incremente la capacidad de refrigeración a medida que se requiere capacidad de refrigeración. De esta manera, no se consume energía para refrigerar espacios que no están ocupados.

Guia de Google Wave

2009-12-08T19:16:00.001+01:00

Google Wave, el nuevo servicio de Google que unifica las herramientas colaborativas de mensajería instantánea, el correo electrónico y de documentos compartidos.Google Wave no es sencillo de entender ni de utilizar.Sin embargo, las primeras sensaciones al utilizarlo es que este es una muy buena herramienta para trabajar en entornos colaborativos.

Otra fuente de recursos es youtube.En youtube, podemos encontrar múltiples videos que nos explican como utilizar Google Wave y entender un poco más sus posibilidades como herramienta de trabajo en grupo.

Para facilitar la entrada en Google Wave, aparte de la documentación que aporta Google sobre el nuevo servicio, hay guías alternativas que permitirá entendra un poco mejor cómo utilizar Wave con nuestro grupo de trabajo.Una que destaca es la que han escrito la Gina Trapani y el Adam Pash y que se puede encontrar en The Complete Guite to Google Wave. .Otra fuente de recursos es youtube.En youtube, podemos encontrar múltiples videos que nos explican como utilizar Google Wave y entender un poco más sus posibilidades como herramienta de trabajo en grupo.

El Colocation sigue creciendo

2009-12-01T22:37:00.001+01:00

Según TeleGeography el Colocation sigue creciendo. Un estudio presentado por esta empresa pone de manifiesto que a pesar de la situación de crisis actual los proveedores de Colocation siguen invirtiendo en ampliar las capacidades. Se ha creado 154.016 metros cuadrados de nuevo espacio desde el 2008. El aumento de espacio para Colocation se está produciendo en todos los mercados, no es un fenómeno de tan solo unos mercados determinados.

A pesar de este crecimiento del espacio disponible, el estudio nota que la ocupación del espacio se produce de forma lenta.

Cambio modelo relación proveedor - client

2009-10-26T23:26:00.000+01:00

Hoy he leído un estudio que analiza i clasifica los proveedores de hosting gestionado, desde los que hacen colocation puro y duro hasta los proveedores de cloud computing como Google, Amazon i Microsoft, pasando por los ISP clásicos e integradores. Entre los diferentes datos i reflexiones que aporta el estudio, me ha interesado especialmente el cambio de modelo que se está produciendo en las empresas que ofrecen servicios de hosting gestionado.

Si inicialmente la relación entre el proveedor de hosting y el cliente se basaba en el alquiler de espacio o hardware, compartiendo infraestructuras y la red, ahora se está evolucionando hacia la compatición del hardware. Nada nuevo hasta el momento, ya que hasta ahora se ha compartido hardware en servicios muy específicos como el alojamiento web y correo electrónico (Hosting Compartido). El cambio que se está produciendo va más allá de la compartición de hardware sin ningún tipo de garantía como en el caso del hosting compartido. Sino que ahora la compartición de recursos permite garantizar la disponibilidad i exclusividad de estos recursos compartidos. Por otro lado, la compartición de recursos se extinende a aplicaciones empresariales como CRMs, ERPs, etc. Todo este cambio se soporta sobre las tecnologías de visrutalización, las cuales permiten la compartición de recursos garantizando los niveles de servicio requeridos.

Por otro lado, este cambio también lleva a un cambio en el modelo de facturación entre proveedores y clientes. Si has ahora, el modelo de facturación se basaba en el cobro por parte del proveedor de una cuota mensual por el servicio prestado con independencia del uso que el cliente haga del servicio. Ahora el proveedor factura el servicio según el uso que el ciente hace de él. Hay proveedores que facturan por usuarios concurrentes conectados al sistema, otros según los recursos asignados como número de cpu's, memoria ram, espacio de disco o ancho d banda internet consumido. Y hasta hay proveedores que facturan por ciclo de cpu o por consumo de electricidad. Este cambio que ajusta el pago del servicio al uso que el cliente hace de él, esta llevando a nuevos modelos de relación entre los proveedores de hosting gestionado y sus proveedores de hardware y software para ajustar el gasto con el nuevo modelo de facturación a cliente. Tenemos ejemplos como la modalidad de licenciamiento SPLA ( Service Provider Servie Agreement) de Microsoft, la cual se ajusta al modelo de pago por uso, reduciendo el riesgo de los proveedores de hosting gestionado.

Ya para finalizar, en todos estos cambios que se están produciendo, cabe destacar que el gran beneficiado es el cliente, quién reduce los costes de explotación de los servicios IT y gana en disponibilidad y seguridad, en definitiva en calidad de servicio.

Lista de Data Centers certificados por UptimeInstitute

2009-10-06T23:39:00.002+02:00

Lista de Data Centers certificados por UptimeInstitute. Esta contiene los Data Centers ya certificados o en progreso de certificación, tanto de los Data Centers ya construidos como de los Data Centers en fase de diseño.

Resource Center – Tier Certified Facilities and Designs

Google sigue innovando en el Datacenter

2009-08-06T20:42:00.007+02:00

Leo en Data Center Knowledge que Google a empezado operar un Datacenter en Bélgica que no dispone de equipos de refrigeración para enfriar el Datacenter. De esta manera Google mejora considerablemente la eficiencia energética del Datacenter.

Las enfriadoras que se utilizan para enfriar agua y que se utilizan en la mayoría de Datacenters son una de las principales fuentes de coste de un Datacenter, ya que requieren de un consumo elevado de electricidad para funcionar.

Si hasta ahora muchos Datacenter optaban por soluciones combinadas, enfriadoras más sistemas de freecooling, ahora Google ha subido un nivel más, al eliminar por completo las enfriadoras. Sin duda, esto sólo se puede hacer en localidades donde la temperatura externa sea suficientemente baja durante todo el año para enfriar el Datacenter sólo con la impulsión de aire procedente del exterior dentro del Datacenter.

La pregunta que nos hacemos todos en este escenario, es la siguiente: que pasa si la temperatura externa sube y no permite enfriar el Datacenter? Pues Google lo soluciona parando servidores de este Datacenter y desviando la carga hacia otros Datacenters. Sin duda esto sólo está al alcance de empresas globales con un concepto de Datacenter distribuido, como Google, Amazon, Microsoft y Yahoo.

Presentación

2009-08-06T20:35:00.004+02:00

Hola,

hace unos meses empece a escribir un blog en catalan. Ahora me he decidido en iniciar el blog en castellano también. La intención es mantener los mismos contenidos en catalan y castellano.

Este blog, no es un blog temático, sino que es un blog donde escribo aquello que me pasa por la cabeza.

Nada, poco a poco iré incorporando contenidos.

Un saludo