martes, 26 de octubre de 2010
Migración del blog
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.
miércoles, 13 de octubre de 2010
Initr
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.
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.
lunes, 9 de agosto de 2010
Probando ElasticHosts
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.
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.
viernes, 9 de julio de 2010
Del Datacenter al servidor, nuevas tendencias de refrigeración.
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.
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.
lunes, 5 de julio de 2010
Instalación automática de sistemas con Cobbler
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 .
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 .
domingo, 27 de junio de 2010
Modular Natural Free Cooling
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.
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.
sábado, 19 de junio de 2010
Probando Googlecl
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:
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
· 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
viernes, 18 de junio de 2010
Diseños de Datacenter de Google basados en contenedores
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.
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.
sábado, 12 de junio de 2010
Aspectos a tener en cuenta para contratar un colocations
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.
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.
sábado, 24 de abril de 2010
Integracion entre Zenoss y Puppet
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
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
lunes, 29 de marzo de 2010
Datacenter commissioning
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:
Las principales actividades del proceso de commissioning son realizar el script (scripting), ejecutar las pruebas y documentar.
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:
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.
- 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.
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.
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
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.
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.
domingo, 21 de marzo de 2010
Datacenter en un container
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.
sábado, 30 de enero de 2010
Instalando Snow Leopard
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
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
Suscribirse a:
Entradas (Atom)
