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.
Suscribirse a:
Entradas (Atom)
