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.
lunes, 9 de agosto de 2010
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.
Suscribirse a:
Entradas (Atom)
