dimarts, 26 d’octubre del 2010
Migració del blog
He migrat el meu blog personal a wordpress i ara s'allotja a un servidor d'Ingent Grup. La nova adreça és http://davidmataro.com i http://davidmataro.com/es per l'edició en catellà.
dimecres, 13 d’octubre del 2010
Initr
Initr és un projecte liderat des d'Ingent Grup per a la administració automatitzada de sistemes distribuïts.Initr neix com a una interface de gestió de mòduls de puppet desenvolupada i utilitzada per Ingent Grup com a eina principal de gestió de sistemes per oferir el servei Ingent Network.
Initr és caractaritza per ser una eina flexible, escalable i distribuïda.
· Felxible: permet la gestió de la configuració de qualsevol software.
· Escalable: permet gestionar de manera unificada i automatitzada entorns amb pocs servidors i entorns amb milers de servidors.
· Distribuït: permet gestionar de manera centralitzada servidors distribuïts en diferents Data Centers.
Amb Initr i de manera senzilla es pot reproduir qualsevol configuració d'un sistema en un altre servidor. Permet reproduir la configuració d'un sistema de manera automàtica en cas de pèrdua del mateix, o desplegar nous servidors dins d'una granja de servidors de manera ràpida i automatitzada.
Initr permet als administradors de sistemes perdre menys temps en feines repetitives i redueix la possibilitat d'errors humans en la configuració dels sistemes. Fets que permeten reduïr el cost operatiu d'administració dels sistemes.
Initr disposa d'un conjunt de mòduls o classes ja desenvolupats per a la administració de sistemes amb puppet i permet desenvolupar nous mòduls personalitzats. Entre els mòduls ja desenvolupats i d'àmbit generalista destaquen:
· Mòdul de monitoratge amb nagios.
· Mòdul d'estadístiques d'ús amb munin.
· Mòdul per gestionar processos automàtics amb monit.
· Mòdul per a la gestió de actualització de paquets.
· Mòdul per a la administració d'un servidor DNS amb bind i per a la administració d'un DNS dinàmic.
· Mòdul per a la administració del servidor web apache, amb capacitat d'adminitració de virtualhost, bbdd mysql i awstats.
· Mòdul per a la gestió de samba
· Mòdul per a la gestió d'un servidor ftp.
· Mòdul per a la gestií d'un servidor de correu electrònic.
· Mòdul per a la gestió de squid.
· Mòdul per a la gestió de claus ssh i accés remot ssh transparent als firewalls.
Un exemple pràctic de com Initr ajuda a reduïr els costos operatius de la administració de sistemes és desplegament i administració d'un sistema de monitoratge.
Si mai heu instal·lat nagios, sabreu el que comporta afegir un nou node o servidor a monitoritzar: configura el node i checks en el servidor nagios, instal·la el client de nagios en el node, en cas de disposar de nodes distribuïts en diferents Data Centers, configura les regles de firewall i checks passius. I no diguem si aquesta tasca la fan diferents tècnics, la estructura de fitxers de configuració de nagios pot degenerar molt sinó hi ha molta disciplina per part dels tècnics, provocant errors en el sistema que es tradueixen en hores d'aquest mateixos tècnics per fer tunning de la configuració.
Amb Initr tot això es simplifica. Un cop afegit el node a Initr - que es tant senzill com crear el nou node a Initr i executar una comanda en el node -, per monitoritzar el node amb nagios, sols cal des de la interficie web de Initr afegir la classe nagios al node i definir els checks dessitjats. De manera automàtica tot es configura (servidor, node, ..) i el node passa a estar monitoritzat des de nagios.
Initr és caractaritza per ser una eina flexible, escalable i distribuïda.
· Felxible: permet la gestió de la configuració de qualsevol software.
· Escalable: permet gestionar de manera unificada i automatitzada entorns amb pocs servidors i entorns amb milers de servidors.
· Distribuït: permet gestionar de manera centralitzada servidors distribuïts en diferents Data Centers.
Amb Initr i de manera senzilla es pot reproduir qualsevol configuració d'un sistema en un altre servidor. Permet reproduir la configuració d'un sistema de manera automàtica en cas de pèrdua del mateix, o desplegar nous servidors dins d'una granja de servidors de manera ràpida i automatitzada.
Initr permet als administradors de sistemes perdre menys temps en feines repetitives i redueix la possibilitat d'errors humans en la configuració dels sistemes. Fets que permeten reduïr el cost operatiu d'administració dels sistemes.
Initr disposa d'un conjunt de mòduls o classes ja desenvolupats per a la administració de sistemes amb puppet i permet desenvolupar nous mòduls personalitzats. Entre els mòduls ja desenvolupats i d'àmbit generalista destaquen:
· Mòdul de monitoratge amb nagios.
· Mòdul d'estadístiques d'ús amb munin.
· Mòdul per gestionar processos automàtics amb monit.
· Mòdul per a la gestió de actualització de paquets.
· Mòdul per a la administració d'un servidor DNS amb bind i per a la administració d'un DNS dinàmic.
· Mòdul per a la administració del servidor web apache, amb capacitat d'adminitració de virtualhost, bbdd mysql i awstats.
· Mòdul per a la gestió de samba
· Mòdul per a la gestió d'un servidor ftp.
· Mòdul per a la gestií d'un servidor de correu electrònic.
· Mòdul per a la gestió de squid.
· Mòdul per a la gestió de claus ssh i accés remot ssh transparent als firewalls.
Un exemple pràctic de com Initr ajuda a reduïr els costos operatius de la administració de sistemes és desplegament i administració d'un sistema de monitoratge.
Si mai heu instal·lat nagios, sabreu el que comporta afegir un nou node o servidor a monitoritzar: configura el node i checks en el servidor nagios, instal·la el client de nagios en el node, en cas de disposar de nodes distribuïts en diferents Data Centers, configura les regles de firewall i checks passius. I no diguem si aquesta tasca la fan diferents tècnics, la estructura de fitxers de configuració de nagios pot degenerar molt sinó hi ha molta disciplina per part dels tècnics, provocant errors en el sistema que es tradueixen en hores d'aquest mateixos tècnics per fer tunning de la configuració.
Amb Initr tot això es simplifica. Un cop afegit el node a Initr - que es tant senzill com crear el nou node a Initr i executar una comanda en el node -, per monitoritzar el node amb nagios, sols cal des de la interficie web de Initr afegir la classe nagios al node i definir els checks dessitjats. De manera automàtica tot es configura (servidor, node, ..) i el node passa a estar monitoritzat des de nagios.
dilluns, 9 d’agost del 2010
Provant ElasticHosts
Avui he llegit que ServerBeach ha llençat un servei de cloud utilitzant la plataforma de ElasticHosts i m'he decidit a provar-la. En el procés de registre m'he endut la primera sorpresa. Es obligat posar un telèfon i que sigui correcte ja que envien la meitat de la password per mail i l'altre meitat via un sms.
Un cop creada la compte, s'accedeix al panell de control via https://lon-p.elastichosts.com/accounts/ amb el mail com a nom d'usuari i la password que ens han anviat per mail i sms. Per defecte la demo té creada una màquina virtual amb les característiques següents:
CPU: 2000 core MHz
RAM: 1024 MB
Drives: RedHat Fedora Linux 13 Live CD
El sistema asigna una ip dinàmica a la màquina virtual i permet l'accés per vnc i a les estadístiques de tràfic des del pròpi panell de control.
Per crear un nou servidor, des de la part dreta del panell de control, hi ha la opció "Add server or drive", aquí seleccionem server, introduïnt un nom - en el meu cas test1 - i seleccionem el tipus d'instal·lació:
· Imatge pre-instal·lada: disposa de imatges de debian, ubuntu i windows.
· Instal·lació des d'un cd: disposa de cd de centos, debian, freebsd, knoppix, opensolaris, RedHat Fedora, Ubunto i Windows. aquesta opció permet per tota la instal·lació del sistema operatiu de manera personalitzada.
· Arrancar des d'un live cd: també ofereix opcions en linux i windows.
· Arrancar des de una imatge de disc existent: cal seleccionar la imatge previament creada.
Per la prova, he seleccionat crear el servidor des d'una imatge pre-instal·lada i he seleccionat la imatge d'un Debian Linux 4.0: System Base without X. Finalment seleccionem la capacitat del disc (1 GB).
Al premer Add, en el panel de control es mostra el nou servidor amb nom test1 i el nou disc també anomenat test1. Podem visualitzar que en la vista del servidor s'indica que el disc del servidor és test1. El servidor permet les opcions de arrancar, editar i d'esborrar.
Al seleccionar la opció de editar, es pot modificar el nom del servidor, la cpu, la memoria, els discos la configuració de xarxa i el password d'accés vnc. També hi ha unes opcions avançades on es pot modificar el número de cores, el model de la targeta de xarxa, configurar una lan privada i encriptar la sessió vnc.
Un cop arrancada la màquina virtual test1 ja podem entrar per vnc amb el password que s'indica en el panel de control. Un cop a dins, amb el login root entrem directament a la consola del sistema sense password. De manera que cal posar una password. Un cop posada la password la pròxima vegada que fem login ja ens demana la password per entrar.
Per defecte, l'únic accés al servidor virtual és via vnc, de manera que si volem accés ssh, cal que arranquem el servei.
Ara ja podem començar a treballar amb el nou servidor virtual.
A descatar la posibilitat de crear vlan privades per conectar les màqunes virtuals. Així permet desplegar arquitectures de més d'una capa amb recursos de xarxa dedicats.
ElasticHosts proporciona una API REST per a la gestió remota de les màquines virtuals via crides HTTP. Per provar-la podem descarregar el shell script elastichost.sh. Les dades d'accés des de la API estan a My Account > Profile, son el UUID i la Secret API Key. Al web hi ha tota la documentació per utilitzar la API.
ElasticHosts presenta dos modelitat de facturació, una per càrrega de credit i una altre per pagament d'una quota mensual.
My account > Billing: des d'aquí podem gestionar el consum de recursos utilitzants en la modelitat de pregamament. Aquest recursos es consumeixen per trams horaris.
My account > Subscriptions: permet gestionar les subscripcions, on es paga una quota mensual per uns recursos. És a dir, permet pagar un tant mensual per una quantitat de recursos de MHz de CPU, de RAM, de Disc i de Tràfic.
Per finalitzar, ElasticHosts presenta una interface de gestió simple i util per a la administració de servidors en cloud, la qual és mereix els premis que li estan donant ultimament. Sens dubte aquesta és una molt bona opció per desplegar un servei de lloguer de servidor en la modelitat de pagament per us.
Un cop creada la compte, s'accedeix al panell de control via https://lon-p.elastichosts.com/accounts/ amb el mail com a nom d'usuari i la password que ens han anviat per mail i sms. Per defecte la demo té creada una màquina virtual amb les característiques següents:
CPU: 2000 core MHz
RAM: 1024 MB
Drives: RedHat Fedora Linux 13 Live CD
El sistema asigna una ip dinàmica a la màquina virtual i permet l'accés per vnc i a les estadístiques de tràfic des del pròpi panell de control.
Per crear un nou servidor, des de la part dreta del panell de control, hi ha la opció "Add server or drive", aquí seleccionem server, introduïnt un nom - en el meu cas test1 - i seleccionem el tipus d'instal·lació:
· Imatge pre-instal·lada: disposa de imatges de debian, ubuntu i windows.
· Instal·lació des d'un cd: disposa de cd de centos, debian, freebsd, knoppix, opensolaris, RedHat Fedora, Ubunto i Windows. aquesta opció permet per tota la instal·lació del sistema operatiu de manera personalitzada.
· Arrancar des d'un live cd: també ofereix opcions en linux i windows.
· Arrancar des de una imatge de disc existent: cal seleccionar la imatge previament creada.
Per la prova, he seleccionat crear el servidor des d'una imatge pre-instal·lada i he seleccionat la imatge d'un Debian Linux 4.0: System Base without X. Finalment seleccionem la capacitat del disc (1 GB).
Al premer Add, en el panel de control es mostra el nou servidor amb nom test1 i el nou disc també anomenat test1. Podem visualitzar que en la vista del servidor s'indica que el disc del servidor és test1. El servidor permet les opcions de arrancar, editar i d'esborrar.
Al seleccionar la opció de editar, es pot modificar el nom del servidor, la cpu, la memoria, els discos la configuració de xarxa i el password d'accés vnc. També hi ha unes opcions avançades on es pot modificar el número de cores, el model de la targeta de xarxa, configurar una lan privada i encriptar la sessió vnc.
Un cop arrancada la màquina virtual test1 ja podem entrar per vnc amb el password que s'indica en el panel de control. Un cop a dins, amb el login root entrem directament a la consola del sistema sense password. De manera que cal posar una password. Un cop posada la password la pròxima vegada que fem login ja ens demana la password per entrar.
Per defecte, l'únic accés al servidor virtual és via vnc, de manera que si volem accés ssh, cal que arranquem el servei.
Ara ja podem començar a treballar amb el nou servidor virtual.
A descatar la posibilitat de crear vlan privades per conectar les màqunes virtuals. Així permet desplegar arquitectures de més d'una capa amb recursos de xarxa dedicats.
ElasticHosts proporciona una API REST per a la gestió remota de les màquines virtuals via crides HTTP. Per provar-la podem descarregar el shell script elastichost.sh. Les dades d'accés des de la API estan a My Account > Profile, son el UUID i la Secret API Key. Al web hi ha tota la documentació per utilitzar la API.
ElasticHosts presenta dos modelitat de facturació, una per càrrega de credit i una altre per pagament d'una quota mensual.
My account > Billing: des d'aquí podem gestionar el consum de recursos utilitzants en la modelitat de pregamament. Aquest recursos es consumeixen per trams horaris.
My account > Subscriptions: permet gestionar les subscripcions, on es paga una quota mensual per uns recursos. És a dir, permet pagar un tant mensual per una quantitat de recursos de MHz de CPU, de RAM, de Disc i de Tràfic.
Per finalitzar, ElasticHosts presenta una interface de gestió simple i util per a la administració de servidors en cloud, la qual és mereix els premis que li estan donant ultimament. Sens dubte aquesta és una molt bona opció per desplegar un servei de lloguer de servidor en la modelitat de pagament per us.
divendres, 9 de juliol del 2010
Del Datacenter al servidor, noves tendències de refrigeració.
Fa dies vaig llegir un post sobre servidors de IBM refrigerats per aigua. Avui he llegit a Data Center Knowledge que Google ha patentat el Liquid-Cooled ' Server Sandwith'. Aquesta no és la única patent de Google en quant a sistemes de refrigeració en entorns d'alta densitat. Fa uns dies ja vaig publicar un post on feia referencia al disseny de Datacenters basats en contenidors de Google.
Que dos gegants com IBM i Google estiguin treballant per refrigerar directament els servidors en comptes del Datacenter porta a certes reflexión sobre les noves tendències en els sistemes de refrigeració del Datacenter o millor dit dels servidors.
Si recordem quin és l'objectiu d'un sistema de refrigeració en un Datacenter, aquest és disipar la calor que generen els servidors al cost més baix possible. Per això hem anat evolucionant, varem passar de sistemes de climatització basats en aire-aire a sistemes de climatització basats en aigua-aire, sistema més eficients energèticament. També hem anat evolucionats en quant a la gestió de l'aire. És a dir, fa uns anys es refrigeraven les sales on s'allotjaven els servidors sense més. Després varem implementar passadíssos fred i calents i a dia d'avui estem contenint l'aire fred o contenint l'aire calent o desplegant Datacenters en contenidors. Cada cop estem portant l'aire fred més aprop del servidors reduint els m3 a climatitzar. I això ho fem perquè els servidors que hem de refrigerar estan dissenyats per a ser refrigerats amb aire.
Ara, el canvi de tendència que estan marcant IBM i Google entre d'altres, canviant la refrigeració dels servidors d'aire a aigua, provoca un canvi de la infraestructura de refrigeració del Datacenter. Si ara porten l'aigua de les refrigeradores als equips de sala, ara s'haurà de portar fins al rack de la mateixa manera que ho fan els sistemes inRow tipus APC. Però a més, l'aigua haurà d'arribar als servidors i per això s'hauran d'adaptar els racks, com ja han fet alguns fabricant adaptant portes del darrera refrigerades per aigua per a entorn d'alta densitat.
Un altre element que canvia es la gestió, això pot suposar la definitiva integració dels sistemes de control de les infraestructures amb els dels servidors i elements de xarxa. Controlant des d'un únic punt la temperatura dels processadors, de l'aigua dels circuits interns dels servidors, de la velocitat d'impulsió, consum elèctric,... conjuntament amb la ocupació de memòria, de disc, tràfic de xarxa, ...
Sens dubte aquest canvi en la arquitectura de refrigració del servidors forçarà a canviar forces elements del Datacenter.
Que dos gegants com IBM i Google estiguin treballant per refrigerar directament els servidors en comptes del Datacenter porta a certes reflexión sobre les noves tendències en els sistemes de refrigeració del Datacenter o millor dit dels servidors.
Si recordem quin és l'objectiu d'un sistema de refrigeració en un Datacenter, aquest és disipar la calor que generen els servidors al cost més baix possible. Per això hem anat evolucionant, varem passar de sistemes de climatització basats en aire-aire a sistemes de climatització basats en aigua-aire, sistema més eficients energèticament. També hem anat evolucionats en quant a la gestió de l'aire. És a dir, fa uns anys es refrigeraven les sales on s'allotjaven els servidors sense més. Després varem implementar passadíssos fred i calents i a dia d'avui estem contenint l'aire fred o contenint l'aire calent o desplegant Datacenters en contenidors. Cada cop estem portant l'aire fred més aprop del servidors reduint els m3 a climatitzar. I això ho fem perquè els servidors que hem de refrigerar estan dissenyats per a ser refrigerats amb aire.
Ara, el canvi de tendència que estan marcant IBM i Google entre d'altres, canviant la refrigeració dels servidors d'aire a aigua, provoca un canvi de la infraestructura de refrigeració del Datacenter. Si ara porten l'aigua de les refrigeradores als equips de sala, ara s'haurà de portar fins al rack de la mateixa manera que ho fan els sistemes inRow tipus APC. Però a més, l'aigua haurà d'arribar als servidors i per això s'hauran d'adaptar els racks, com ja han fet alguns fabricant adaptant portes del darrera refrigerades per aigua per a entorn d'alta densitat.
Un altre element que canvia es la gestió, això pot suposar la definitiva integració dels sistemes de control de les infraestructures amb els dels servidors i elements de xarxa. Controlant des d'un únic punt la temperatura dels processadors, de l'aigua dels circuits interns dels servidors, de la velocitat d'impulsió, consum elèctric,... conjuntament amb la ocupació de memòria, de disc, tràfic de xarxa, ...
Sens dubte aquest canvi en la arquitectura de refrigració del servidors forçarà a canviar forces elements del Datacenter.
dilluns, 5 de juliol del 2010
Instal·lació automàtica de sistemes amb Cobbler
En tot Datacenter la automatitizació de sistemes és una tasca imprescindible per tal de minimitzar els costos operatius de desplegar un nou sistema, mantenir la homogenietat dels sistemes i evitar els erros humans. La virtualització i la possibilitat de clonar màquines virtuals ràpidament, automatitzar la instal·lació de nous de sistemes s'ha simplificat. Tot i això, no tots els sistemes són virtuals, de manera que cal també automatitzar la instal·lació dels sistemes físics a banda dels virtuals.
Una eina per automatitzar la instal·lació de sistemes físics i virtuals és Cobbler. Cobbler permet als administradors de sistemes centralitzar i automatitzar la instal·lació de sistemes, ja siguin físics o virtuals. Cobbler és un projecte OpenSource de RedHat que s'inclou dintre de FedoraHoted. Cobbler s'estructura en els elements següent:
- Distribucions: una distribució conté tota la informació realcionada amb el kernel, scripts, ... d'una instal·lació. És a dir, és una
distribució de Linux a partir de la qual es realitza una instal·lació.
- Perfil: un perfil és una particularització de la instal·lació d'una distribució. Aquesta particularituzació es fa mitjançant la definició d'un fitxer d'instal·lació kickstart. Un perfil per exemple pot representar la instal·lació d'un servidor web, d'un servidor de bbdd o d'una estació de treball.
- Sistema: un sistema no és més que la instal·lació d'un perfil sobre un servidor físic o virtual concret.
- Repositori: un repositori és un mirror de les actualitzacions d'uan distribució concreta. D'aquesta manera, els sistemes instal·lats des de Cobbler actualitzen els paquets des del mateix servidor de Cobbler i no des d'Internet. Així, s'accelera la actualització de paquets i és redueix el tràfic de xarxa Internet.
- Imatges: són instal·lacions que és fan sobre un fitxer ISO. De manera que aquesta imatge ISO es pot instal·lar tant sobre un servidor físic com virtual.
Cobbler disposa de dos interface de treball, una via linia de comandes i una segona via web. Des de ambdues interface es poden gestionar les distribucions, perfils, sistemes i repositoris.
Des del punt de vista d'un Datacenter, Cobbler permet automatitzar la instal·lació de nous servidor de hosting dedicat o virtual, re-instal·lar de manera ràpida un servidor que ha fallat i fins hi tot, disposar de plantilles de servidors (perfils) que s'instal·lin automàticament en funció de la necessitat de càrrega. Per exemple, en cas d'un portal web amb un frontal format per N servidors Apache, si augmenta la demanda es poden instal·lar nous servidors Apache de manera ràpida i fins hi tot de manera automàtica. I aquest servidors Apache s'instal·len basats en una plantilla (perfil) determinada.
Més informació a Cobbler.
Una eina per automatitzar la instal·lació de sistemes físics i virtuals és Cobbler. Cobbler permet als administradors de sistemes centralitzar i automatitzar la instal·lació de sistemes, ja siguin físics o virtuals. Cobbler és un projecte OpenSource de RedHat que s'inclou dintre de FedoraHoted. Cobbler s'estructura en els elements següent:
- Distribucions: una distribució conté tota la informació realcionada amb el kernel, scripts, ... d'una instal·lació. És a dir, és una
distribució de Linux a partir de la qual es realitza una instal·lació.
- Perfil: un perfil és una particularització de la instal·lació d'una distribució. Aquesta particularituzació es fa mitjançant la definició d'un fitxer d'instal·lació kickstart. Un perfil per exemple pot representar la instal·lació d'un servidor web, d'un servidor de bbdd o d'una estació de treball.
- Sistema: un sistema no és més que la instal·lació d'un perfil sobre un servidor físic o virtual concret.
- Repositori: un repositori és un mirror de les actualitzacions d'uan distribució concreta. D'aquesta manera, els sistemes instal·lats des de Cobbler actualitzen els paquets des del mateix servidor de Cobbler i no des d'Internet. Així, s'accelera la actualització de paquets i és redueix el tràfic de xarxa Internet.
- Imatges: són instal·lacions que és fan sobre un fitxer ISO. De manera que aquesta imatge ISO es pot instal·lar tant sobre un servidor físic com virtual.
Cobbler disposa de dos interface de treball, una via linia de comandes i una segona via web. Des de ambdues interface es poden gestionar les distribucions, perfils, sistemes i repositoris.
Des del punt de vista d'un Datacenter, Cobbler permet automatitzar la instal·lació de nous servidor de hosting dedicat o virtual, re-instal·lar de manera ràpida un servidor que ha fallat i fins hi tot, disposar de plantilles de servidors (perfils) que s'instal·lin automàticament en funció de la necessitat de càrrega. Per exemple, en cas d'un portal web amb un frontal format per N servidors Apache, si augmenta la demanda es poden instal·lar nous servidors Apache de manera ràpida i fins hi tot de manera automàtica. I aquest servidors Apache s'instal·len basats en una plantilla (perfil) determinada.
Més informació a Cobbler.
dimecres, 23 de juny del 2010
Modular Natural Free Cooling
El passat 2 de juny vaig assistir a las jornada que anualment organitza AST-GLOBAL anomenada Nueva Generación de Datacenters. Per qui no conegui AST-GLOBAL, és una empresa lider en solucions de Datacenters modulars, segurs i eficients energèticament.
En aquesta jornada AST presentava el Modular Natural Free Cooling. Modular Natural Free Cooling és una tecnologia innovadora patentada per AST que permet fer free cooling a 24 ºC i per sota. Aquesta solució ja està implanta a Thor - un ampresa d'islandia - on s'ha aconseguit un PUE de 1.07. Sens dubte un PUE extramadament baix. Però el més significant de la solució és que permet fer free cooling un 80% del temps aproximadament a llocs com Barcelona o Madrid.
El en link hi ha una taula amb les temperatures de les pricipals ciutats de nord amèrica i europa on es veu el % del temps que es pot operar en free cooling utilitzant aquesta tecnologia.
En aquesta jornada AST presentava el Modular Natural Free Cooling. Modular Natural Free Cooling és una tecnologia innovadora patentada per AST que permet fer free cooling a 24 ºC i per sota. Aquesta solució ja està implanta a Thor - un ampresa d'islandia - on s'ha aconseguit un PUE de 1.07. Sens dubte un PUE extramadament baix. Però el més significant de la solució és que permet fer free cooling un 80% del temps aproximadament a llocs com Barcelona o Madrid.
El en link hi ha una taula amb les temperatures de les pricipals ciutats de nord amèrica i europa on es veu el % del temps que es pot operar en free cooling utilitzant aquesta tecnologia.
dissabte, 19 de juny del 2010
Provant Googlecl
Google a publicat Googlecl, un shell que utilitza les APIs de Google i que permet gestionar els serveis de Google des de la linia de comandes. Ara mateix permet gestionar els serveis següents:
· Blogger
· Calendar
· Contacts
· Docs
· Picasa
· Youtube
Primer de tot hem d'instal·lar-lo. En el meu cas l'instal·lo sobre Mac OS X:
Per utilitzar googlecl cal escriure google, seguit del servei i de la tasca a executar. Per exemple, si volem llistar tota la llista de contactes cal escriure:
$ google contacts list
La primera vegada que s'accediex a un servei demana que autoritzin l'accés. Per això, quant executes per primera vegada una comanda, primera demana l'usuari i després mostra una url amb un token. Posant aquesta url en un navegador podem autoritzar o denar l'accés. Sempre podem tornar a denegar l'accés connectant a Google i seleccionat My Account -> Change authorized websites.
Per obtenir ajuda cal:
$ google --help
$ google help
A partir d'aquí, sols cal utilitzar la imaginació per treure suc a googlecl. Un petit exemple, si volem fer una còpia de seguretat dels contactes que tenim a google contacts podem executar cada dia la comanda següent:
$ google contacts list > contacs.csv
· Blogger
· Calendar
· Contacts
· Docs
· Picasa
· Youtube
Primer de tot hem d'instal·lar-lo. En el meu cas l'instal·lo sobre Mac OS X:
1. Instal·lar Xcode
En el meu cas l'instal·lo directament del DVD de Snow Leopard. També es por descarregar de Developer Tools.
2. En cas de no tenir instal·lades les X, cal instal·lar-les. En el meu cas ja les tinc instal·lades.
3. Instal·lar macports
Descarregar el MacPorts-1.9.1.pkg de la web de macports per a Snow Leopard i instal·lar-lo.
Obrir un terminal i executar 'sudo port -v selfupdate' per tal d'assegurar que disposem de la últime relaease.
4. Instal·lar googlecl
sudo port install googlecl
Per utilitzar googlecl cal escriure google, seguit del servei i de la tasca a executar. Per exemple, si volem llistar tota la llista de contactes cal escriure:
$ google contacts list
La primera vegada que s'accediex a un servei demana que autoritzin l'accés. Per això, quant executes per primera vegada una comanda, primera demana l'usuari i després mostra una url amb un token. Posant aquesta url en un navegador podem autoritzar o denar l'accés. Sempre podem tornar a denegar l'accés connectant a Google i seleccionat My Account -> Change authorized websites.
Per obtenir ajuda cal:
$ google --help
$ google help
A partir d'aquí, sols cal utilitzar la imaginació per treure suc a googlecl. Un petit exemple, si volem fer una còpia de seguretat dels contactes que tenim a google contacts podem executar cada dia la comanda següent:
$ google contacts list > contacs.csv
divendres, 18 de juny del 2010
Dissenys de Datacenter de Google basats en contenidors
Llegeixo a Data Center Knowledge que google a patentat una torra de contenidors com a Datacenter. La foto és molt ilustrativa, una torra de 4 parells de contenidors apilats que fan un total de 8 contenidors.
Aquesta no és l'únic disseny de Datacenter de Google amb containers. Les imatges següents mostren un altre model de Datacenter basat en contenidors, així com el disseny del sistema de refrigeració del contenidor.
Aquesta no és l'únic disseny de Datacenter de Google amb containers. Les imatges següents mostren un altre model de Datacenter basat en contenidors, així com el disseny del sistema de refrigeració del contenidor.
dimarts, 8 de juny del 2010
Factors a tenir en compte alhora de contractar un servei de colocation
Ja des de fa uns anys, els sistemes d'informació cada cop prenen més importancia en els processos de negoci de les empreses. Fet que fa que la disponibilitat d'aquests sistemes d'informació sigui critica. Tant per empreses grans com per empreses petites. Els costos per tal de disposar d'uns nivells de disponibilitat dels sistemes d'informació acord amb el negoci son elevats, de manera que cada cop son més les empreses que cerquen un colocation on allotjar els seus sistemes d'informació.
Alhora d'escollir un Datacenter on contractar el colocation, hi ha varis factors a tenir en compte. Aquest factors permeten entendre el preu del servei i veure si s'ajusten a les necessitats que cal satisfer.
Cal tenir clar la potència elèctrica que necessitem i la que ofereix el proveïdor. Fins ara s'estaven oferin potencies de 2.2 kw i 4.4 kw amb línies de 16 i 32 A, però hi ha proveïdor que ofereixen potencies més elevades. És important entendre el mètode de facturació de la potencia que aplicarà el proveïdor, ja que és un dels costos més significatius del colotaion. Hi ha proveïdors que no mesuren la potencia consumida, sino que dins de la quota del servei contractat incorpora el cost del màxim de corrent que es pot arribar a consumir, esdavenint aquest un cost fixe independentment del consum realitzat. En canvi d'altres proveïdors mesuren el consum realizat i facturan aquest concepte a banda del servei contractat, de manera que el consum és tracta de forma variable. En aquest últim cas, és important veure i entedra la formula que el proveídor utilitza per calcular el preu del kwh.
Altrament, també és important identificar com el proveïdor ens entrega l'energia, si amb una sola línia, una línia activa i una segona passiva o dues línies actives. Això ens determinarà el nivell de redundància de corrent que ens proporciona el proveïdor i que influeix en el preu del servei també. Per tal de tenir clar la relació qualitat preu - entenent qualitat com a nivell disponibilitat que ens ofereix el proveïdor - cal coneixer el nivell de reduncacia del Dataceter del proveïdor.
Els nivells de redundancia dels Datacenters estan regulats pel l'estandard TIA 968 o per la institució americana Uptime Institute. Ambdos defineixen 4 nivells de redundancia, Tier I, Tier II, Tier III i Tier 4, essent el Tier IV el de major disponibilitat i el Tier I el de menys. Sens dubte, com més alt és el Tier més costos de desplegament i manteniment hi ha. I aquest afecten directament en el preu del servei. Per tant es fa necessari identificar els nivells de disponibilitat que requerim per tal d'escollir el proveïdor que disposi dels nivells de redundancia que s'adaptin als requeriments.
Un altre factor que influeix directament en el cost és la eficiència del Datacenter. És a dir, quina és la relació entre el consum dels servidors i el consum en aire acondicionat per disipar la calor generada pels servidors, així com les pèrdues en la distribució de la energia fins als servidors. D'aquesta relació s'obté una valor anomenat PUE (Power Usage Effectiveness) - veure mètriques pel control energètic en un Centre de Dades -. Com més baix és el PUE més eficient és el Datacenter i per tant menys costos d'energia hi ha. Per tant un proveïdor amb un PUE baix, té menys costos energètics, de manera que pot oferir un preu més competitiu.
La connectivitat del Datacenter també és un factor determinant alhora d'ecollir proveïdor. Aquí poden trobar dos tipus. Datacenter d'una operadora de telecomunicacions i Datacenters neutres. Els Datacenters d'una operadora per norma sols disposen de comunicacions de la mateixa operadora, tot i que aquestes estiguin redundades. En canvi, els Datacenters neutres disposen de més un operador o carrier. De cara a entendre els costos dels Datacenters neutres, cal veure si aquest disposen de connexió directa a un NAP (Network Access Point), punt d'accés a la xarxa on es realiza l'intercanvi de tràfic entre operadors o carrier. Això reduix els costos d'accés als operadors o carriers, de manea que permet als operadors oferir preus més competitius i disposar de grans capacitats de connexió. En ambdos casos és important identificar la redundancia es fa a través de camins físicament separats o no.
Per últim, si hem d'allotjar els serveis en un Datacenter també és important coneixer quines són els nivells de qualitat de la gestió del servei. Aquí, en els últims anys s'ha imposat la metodologia de gestió del servei basada en les millor pràctiques ITIL. En aquest sentit la ISO20000 permet als proveïdors certificar la aplicació d'ITIL en la gestió del servei. D'altre banda, la ISO27001 permet certificar la apliacació de bones pràctiques en la gestió de la seguretat.
Alhora d'escollir un Datacenter on contractar el colocation, hi ha varis factors a tenir en compte. Aquest factors permeten entendre el preu del servei i veure si s'ajusten a les necessitats que cal satisfer.
Cal tenir clar la potència elèctrica que necessitem i la que ofereix el proveïdor. Fins ara s'estaven oferin potencies de 2.2 kw i 4.4 kw amb línies de 16 i 32 A, però hi ha proveïdor que ofereixen potencies més elevades. És important entendre el mètode de facturació de la potencia que aplicarà el proveïdor, ja que és un dels costos més significatius del colotaion. Hi ha proveïdors que no mesuren la potencia consumida, sino que dins de la quota del servei contractat incorpora el cost del màxim de corrent que es pot arribar a consumir, esdavenint aquest un cost fixe independentment del consum realitzat. En canvi d'altres proveïdors mesuren el consum realizat i facturan aquest concepte a banda del servei contractat, de manera que el consum és tracta de forma variable. En aquest últim cas, és important veure i entedra la formula que el proveídor utilitza per calcular el preu del kwh.
Altrament, també és important identificar com el proveïdor ens entrega l'energia, si amb una sola línia, una línia activa i una segona passiva o dues línies actives. Això ens determinarà el nivell de redundància de corrent que ens proporciona el proveïdor i que influeix en el preu del servei també. Per tal de tenir clar la relació qualitat preu - entenent qualitat com a nivell disponibilitat que ens ofereix el proveïdor - cal coneixer el nivell de reduncacia del Dataceter del proveïdor.
Els nivells de redundancia dels Datacenters estan regulats pel l'estandard TIA 968 o per la institució americana Uptime Institute. Ambdos defineixen 4 nivells de redundancia, Tier I, Tier II, Tier III i Tier 4, essent el Tier IV el de major disponibilitat i el Tier I el de menys. Sens dubte, com més alt és el Tier més costos de desplegament i manteniment hi ha. I aquest afecten directament en el preu del servei. Per tant es fa necessari identificar els nivells de disponibilitat que requerim per tal d'escollir el proveïdor que disposi dels nivells de redundancia que s'adaptin als requeriments.
Un altre factor que influeix directament en el cost és la eficiència del Datacenter. És a dir, quina és la relació entre el consum dels servidors i el consum en aire acondicionat per disipar la calor generada pels servidors, així com les pèrdues en la distribució de la energia fins als servidors. D'aquesta relació s'obté una valor anomenat PUE (Power Usage Effectiveness) - veure mètriques pel control energètic en un Centre de Dades -. Com més baix és el PUE més eficient és el Datacenter i per tant menys costos d'energia hi ha. Per tant un proveïdor amb un PUE baix, té menys costos energètics, de manera que pot oferir un preu més competitiu.
La connectivitat del Datacenter també és un factor determinant alhora d'ecollir proveïdor. Aquí poden trobar dos tipus. Datacenter d'una operadora de telecomunicacions i Datacenters neutres. Els Datacenters d'una operadora per norma sols disposen de comunicacions de la mateixa operadora, tot i que aquestes estiguin redundades. En canvi, els Datacenters neutres disposen de més un operador o carrier. De cara a entendre els costos dels Datacenters neutres, cal veure si aquest disposen de connexió directa a un NAP (Network Access Point), punt d'accés a la xarxa on es realiza l'intercanvi de tràfic entre operadors o carrier. Això reduix els costos d'accés als operadors o carriers, de manea que permet als operadors oferir preus més competitius i disposar de grans capacitats de connexió. En ambdos casos és important identificar la redundancia es fa a través de camins físicament separats o no.
Per últim, si hem d'allotjar els serveis en un Datacenter també és important coneixer quines són els nivells de qualitat de la gestió del servei. Aquí, en els últims anys s'ha imposat la metodologia de gestió del servei basada en les millor pràctiques ITIL. En aquest sentit la ISO20000 permet als proveïdors certificar la aplicació d'ITIL en la gestió del servei. D'altre banda, la ISO27001 permet certificar la apliacació de bones pràctiques en la gestió de la seguretat.
dissabte, 24 d’abril del 2010
Integració entre Zenoss i Puppet
Zenoss i Puppet colaboran per tal de proporcionar al mercat una solució de monitoratge i automatització de Datacenter integrada.
Zenoss es lider en la comercialització d'una solució opensource de monitoratge i gestió. Zenoss core es la base de zenoss enterprise i és una dels projectes opensource amb més actius. D'altre banda, Puppet és un dels sistemes d'automatització de nova generació que permet gestionar gestionar gran quantitat de sistemes de manera molt ràpida.
La integració de Puppet amb Zenoss permet disposar d'un sistema de monitoratge i de gestió automàtica unificat que millora les capacitats de gestió del Datacenter.
El modul que integra zenoss amb puppet es pot baixa de http://community.zenoss.org/docs/DOC-5818
Zenoss es lider en la comercialització d'una solució opensource de monitoratge i gestió. Zenoss core es la base de zenoss enterprise i és una dels projectes opensource amb més actius. D'altre banda, Puppet és un dels sistemes d'automatització de nova generació que permet gestionar gestionar gran quantitat de sistemes de manera molt ràpida.
La integració de Puppet amb Zenoss permet disposar d'un sistema de monitoratge i de gestió automàtica unificat que millora les capacitats de gestió del Datacenter.
El modul que integra zenoss amb puppet es pot baixa de http://community.zenoss.org/docs/DOC-5818
dilluns, 29 de març del 2010
Datacenter commissioning
Quant s'afronta un projecte de contrucció d'un Datacenter, en la fase de disseny s'especifíquen tot un conjunt de subsistemes (sistema elèctric, sistema de refrigeració, sistema de detecció i extenció d'incèndis, sistemes de seguretat física i sistemes de monitoratge i gestió), la relació entre cadascun dels elements i s'estima el comportament del conjunt amb càrrega. Després en la fase de desplegament, cada sistema es desplegat pel proveïdor corresponents - normalment un proveïdor per subsistema - i probat de manera individual. Cada proveïdor realitza la posta en marxa i les proves funcionals del subsistema que ha instal·lat per tal de disposar de la acceptació del client i facturar. En aquest procés, en cap moment es fa una comprovació de tot el conjunt. I és aquí on el "Commissioning" pren importància.
L'objectiu del "Commissioning" és provar el comportament de tots els subsistemes treballant conjuntament, amb la finalitat de comprovar si el desplegament de cada subsistema assoleix els objectius marcats en la fase de disseny i compleix amb els requisits inicials. És a dir, és un procés de validació de la instal·lació. També permet identificar les mancances de la instal·lació i els límits de la mateixa, informació que serà de molta utilitat en la fase d'explotació. És per això que la pràctica del "Commissioning" es cada cop més utilitzada en la fase de desplegament d'un Datacenter.
Com tot procés aquest està format per una entrada, un conjunt d'activitats i una sortida.
Entrades:
Sortides:
Les principals activitats del procés de provisioning són realitzar l'script (scripting), executar les proves i documentar.
Per executar les proves del sistema amb càrrega, s'utilitza el que es coneix com a "load banks". Són un conjunt d'elements per generar calor a la sala i així provar tant el sistema elèctric com el sistema de refrigeració.
El procés de commissioning no tant sols és utils per comprovar el grau de compliment d'una instal·lació nova i identificar les mancances i limits del mateix. Sinó que també permet auditar un Datacenter construïts ja fa anys o en producció.
Bibliografia d'interés:
L'objectiu del "Commissioning" és provar el comportament de tots els subsistemes treballant conjuntament, amb la finalitat de comprovar si el desplegament de cada subsistema assoleix els objectius marcats en la fase de disseny i compleix amb els requisits inicials. És a dir, és un procés de validació de la instal·lació. També permet identificar les mancances de la instal·lació i els límits de la mateixa, informació que serà de molta utilitat en la fase d'explotació. És per això que la pràctica del "Commissioning" es cada cop més utilitzada en la fase de desplegament d'un Datacenter.
Com tot procés aquest està format per una entrada, un conjunt d'activitats i una sortida.
Entrades:
- LLista de requisits de disseny i contrucció del datacenter.
- El disseny del Datacenter.
- Resultat de les proves realitzades en la posta en marxa de cadascun dels components del Datacenter.
Sortides:
- Script: conté la llista de components provats i el tipus de test realitzat i el resultat obtingut.
- Registre d'error: és una anàlisi FMEA (Failure Mode Effects Analysis) d'un components específica que ha fallat durant el test. Aquest identifica l'impacte de l'error i recomana les possibles solucions.
- Resum executiu: descriu les accions les proves realitzades i un pla d'acció.
Les principals activitats del procés de provisioning són realitzar l'script (scripting), executar les proves i documentar.
- Scripting: defineix la seqüència, el temps i l'ordre per fer les proves de tots els elements del Datacenter. També permet defineix els registres a obtenir en cada prova.
- Executa les proves: consisteix en executar una sèrie d'errors en els elements del sistema segons una seqüència establerta i tornar a restablir-los. Amb aquestes proves cal provar tant el sistema d'alimentació elèctrica, de fred, de detecció d'incèndis, ...
- Documentació: cal registrar totes les proves realitzades i documentar-ho per tal deixar registrar l'estat i comportament de tot el sistema. La documentació serveix tant per veure el grau de compliment del sistema respecte els requisits inicials i el disseny, com per a la posterior explotació del mateix.
Per executar les proves del sistema amb càrrega, s'utilitza el que es coneix com a "load banks". Són un conjunt d'elements per generar calor a la sala i així provar tant el sistema elèctric com el sistema de refrigeració.
El procés de commissioning no tant sols és utils per comprovar el grau de compliment d'una instal·lació nova i identificar les mancances i limits del mateix. Sinó que també permet auditar un Datacenter construïts ja fa anys o en producció.
Bibliografia d'interés:
- ASHARE Guideline 0 - the Commissioning Process: Guia on descriuen totes les fases del procés de Commissioning.
- APC White Paper #148 Data Center Projects: Commissioning.
- APC White Paper #149 Ten Errors to Avoid When Commissioning a Data Center.
Més sobre contenidors
PowerHouse de l'empresa ActivePower és un contenidor standard ISO que conté un sistema d'alimentació segura, amb generador autònom i dipòit de gasoil, UPS i un centre de commutació. Aquest es comercialitza amb diferents potències de sortida i amb dues modelitats, una amb sols sortida segura (UPS) i un altre amb dues sortides, una segura (SAI) i una no segura (sols generador).
Sens dubte que l'entrada en joc dels contenidors com a repositoris de racks, sistemes de fred i ara sistemes d'alimentació segura, està canviat la fisonomia dels Datacenters.
diumenge, 21 de març del 2010
Datacenter en un contenidor
Aquesta setmana he tingut la oportunitat de visitar les instal·lacions que AST Globlal té a Cornella de Llobregat i veure la solució de Datacenter dins d'un contenidor Smart Shelter Container.
És impressionant veure com els enginyers de AST Globlal posen dins d'un contenidor standard, que es pot portar a qualsevol lloc del moment amb camió o vaixell, tot un Datacenter, amb el racks, clima, SAI's, sistema de detecció i extinció d'incèndis, videovigilància, i tot el necessàri. A més, el sistema es totalment flexible i moular i s'adapta a les necessitats del client.
D'altre banda, també hem van ensenyar noves solucions de free-cooling amb les que estan treballant i que son revolucionaries i que de ben segur que en breu veurem arreu del món.
Sens dubte, ens trobem davant d'una empresa innovadora dins del sector dels Datacenter i que de ben segur en sentirem a parlar molt.
Us deixo l'enllaça al canal de youtube de AST, on es pot veure el Smart Shelter Container.
dissabte, 30 de gener del 2010
Instal·lant Snow Leopard
Ja feia temps que tinc al cap substituir el Tiger per Snow Leopard. Sens dubte, la desició m'ha costat, ja que tal i com com es diu sovint, quant una cosa va be no la toquis. Tot i això, avui m'he decit a fer net i instal·lar de zero Snow Leopard.
La instal·lació ha estat força senzilla, posar el dvd, seleccionar la opció instal·lar, formatar el disc i esperar una mica més de mitja hora. Al cap de mitja horeta, el sistema ha reiniciat i ja tinc Snow Leopard.
Com era d'esperar els senyors de mac cuiden els detalla fins a l'últim extrem, i el sistema ens dona la benvinguda de forma espactacular amb un video que ens dona la benvinguda en diferents idiomes.
Un cop cop arrancat, hem sorpren la rapidesa amb que obre el Finder i el Safari. Sens dubte, la primera impresió en quant a la velocitat del sistema és que va més ràpid que amb Tiger sobre el dual core a 2GHz i 1 GB de RAM del meu MacBook.
Ara toca recuperar tota la informació i instal·lar totes les aplicacions. Per fer això, abans d'instal·lar he clonat el disc amb Tiger sobre un disc extern USB mitjançant Carbon Copy. Aquest disc USB és la base a partir del qual començar a recuperar tota la informació sobre el nou Snow Leopard.
Un cop recuperada la informació i instal·lades les aplicacions, he configurat Time Machine perquè facis còpies de seguretat sobre el disc USB.
I fins aquí la instal·lació de Snow Leopard. Ara toca gaudir-ne.
Subscriure's a:
Missatges (Atom)
