Posts Tagged Cloud Computing
Amazon RDS – La nube de datos relacional*
Posted by Xavi in Bases de datos, Programación Web on 03/11/2009
Hace tiempo que trabajábamos buscando soluciones al problema de migrar aplicaciones que utilizan una base de datos relacional “clásica” a un entorno de cloud computing (más concretamente a Amazon EC2). Este problema nos llevó a interesantes estudios sobre el clúster y la replicación master-slave de MySQL hasta encontrar una solución bastante aceptable con esta última. Y después de todo este trabajo… va Amazon y lo resuelve con un nuevo servicio llamado Amazon RDS (Relational Database Service).
En pocas palabras, RDS viene a ser una puerta de acceso a una base de datos MySQL Server (de momento la versión 5.1 con InnoDB como motor principal) que corre encima de los servidores de Amazon Web Services. Amazon te proporciona una interfaz idéntica a la que utilizarías con un servidor dedicado a la base de datos pero no preguntes como funciona por debajo, no te preocupes por las actualizaciones de seguridad, no intentes acceder como si fuera un servidor normal y corriente… sólo utilízalo y disfrútalo!
Amazon RDS viene a completar la oferta de sistemas de bases de datos con SimpleDB (una base de datos muy simple para aplicaciones con una baja complejidad de datos) y Amazon EC2 Relational Database AMIs (una selección de AMIs con diferentes software de bases de datos preeinstalados).
Para interactuar con Amazon RDS, como con casi todos los servicios de AWS, tenemos la posibilidad de realizar llamadas a la API directamente o descargarnos las herramientas por linea de comandos (en mi opinión la mejor opción).
Para instalar las herramientas por linea de comandos podemos seguir los siguientes pasos:
- Descargamos las RDS Command Line Tools de la página oficial de Amazon
- Seteamos las variables JAVA_HOME y AWS_RDS_HOME necesarias en /etc/enviroment. Las linias que tendríamos que añadir son las siguientes
AWS_RDS_HOME="/path/a/la/carpeta/commandlinetools"
JAVA_HOME="/path/a/java"
En mi caso el “/path/a/java” es “/usr/lib/jvm/java-6-sun/” y si utilizas Ubuntu no creo que sea muy diferente
- El siguiente paso es añadir en el PATH del sistema el directorio /bin de las herramientas que hemos descargado. Para hacer esto, dentro del mismo archivo /etc/enviroment, añadiremos :$AWS_RDS_HOME/bin antes de las dobles comillas que cierran la expressión PATH=”blabla:/blabla:/blabla” para que quede de la forma PATH=”blabla:/blabla:/blabla:$AWS_RDS_HOME/bin”.
- Lo siguiente es abrir el archivo credential-file-path.template que encontraremos en la raíz del directorio de las herramientas y introducir nuestros datos de acceso a la cuenta de AWS.
- Una vez introducidas nuestras credenciales añadiremos la situación de este archivo en /etc/enviroment también:
AWS_CREDENTIAL_FILE="/path/a/credential-file-path.template"
Si queremos podemos modificar el nombre del fichero y moverlo a la localización que más nos guste, mientras mantengamos la informatcion de /etc/enviroment actualizada. - Una vez tengamos todo ésto solo queda reiniciar el ordenador para cargar todas estas variables y ya estaremos listos para empezar a jugar con Amazon RDS!
Me gustaría descubrir un método para recargar las variables de /etc/enviroment en caliente pero de momento los métodos que he encontrado no han acabado de funcionar correctamente, si tienes alguna sugerencia déjala en los comentarios 
Bueno ahora viene la mala noticia… Amazon RDS de momento solo está disponible para Estados Unidos… Pero prometen tenerlo disponible para Europa en los próximos meses, veremos que tardan.
Os dejo un post del blog de Amazon Web Services en el que se introduce Amazon RDS enlace.
*No me agredais física ni intelectualmente por el juego de palabras!!
Dropbox y la solución a la sincronización
Si hace unos días hablabamos de Ubuntu One en el post Probando Ubuntu One hoy hacemos una pequeña reseña de lo que nos ofrece el competidor más fuerte en cuanto a almacenamiento en la nube, Dropbox.
Adoptar una plataforma u otra de almacenamiento on-line depende, en gran medida, de las necesidades del usuario. En el momento en que estaba probando Ubuntu One, mi necesidad era un servicio conocido, poco intrusivo y del cual me pudiese fiar aunque de vez en cuando tuviera que hacer copia de según que documento. Después de un periodo de estrés mis necesidades han cambiado ligeramente y por eso decidí cambiar.
Por un lado, mi ordenador personal se trata de un Macbook de finales de 2007 con Mas OS X Leopard y Ubuntu funcionando en diferentes particiones. En la partición de Ubuntu no había problema pero para Mac (igual que para otros sistemas operativos) no hay ningún cliente y se tiene que recurrir a la aplicación web. Esto para usuarios básicos no tiene menor importancia, pero para alguien que está demasiado bien acostumbrado a que los archivos se sincronicen en segundo plano no es aceptable.
Por otro, el cliente de Ubuntu One dejó de funcionar en mi portátil del trabajo (tengo instalada la versión de 64 bits). Otro contratiempo que me hacía recurrir a la aplicación web en el emplazamiento dónde más uso este tipo de servicio… un coñazo hablando en plata!
Dropbox me llamó la atención cuando mi hermana, usuaria muy básica de informática, me dijo que para su trabajo (es ilustradora) le iba genial ya que podía compartir sus archivos con las editoriales y le resultaba mucho más fácil que por FTP.
Dropbox ofrece una aplicación web muy sencilla, clientes para un gran número de sistemas operativos y un sistema de compartición de archivos también muy sencillo, todo con un grado de fiabilidad satisfactorio (lo que he probado hasta el momento). Comentar que, en Leopard, Dropbox ofrece mostrar el icono habitual en la barra de menú con la caja de color azul o un icono alternativo en blanco y negro que se integra mucho mejor con el sistema. Quizás es sólo una curiosidad o quizás es una muestra del nivel de detalle que nos puede llegar a ofrecer este servicio… depende con los ojos con los que se mire.
Si quereis probarlo aquí teneis el enlace: http://www.getdropbox.com/
Amazon premia la planificación
Posted by Xavi in Programación Web on 16/03/2009
Nos lo avanzaba Santi el sábado por la mañana en su post (a mi a las ocho menos cuarto por mail, que afortunado me siento!). Amazon a abierto una fórmula de contratación para instancias de EC2 alternativa al pago por uso que existía hasta ahora (que sigue estando disponible).
La nueva fórmula premia los clientes que hagan una buena planificación del consumo de recursos que van a realizar. Así, siempre que tengamos activa una instancia más de 143 días al año (24 horas al dia) nos va a salir a cuenta esta nueva fórmula de pago por avanzado. El sistema se basa en una cuota fija por uno o tres años y un precio mucho más reducido por uso (horas de instancia activa).
Este ahorro, que puede parecer un poco escaso a primera vista, es muy significativo en máquinas de altas prestaciones que debamos tener activas 24/7 todos los días del año. Veamos un ejemplo:
- Las instancias del tipo High-CPU Extra Large Tienen un coste de 0.80 $/hora (para Unix/Linux) en la antigua fórmula de contratación. Con estos datos el coste anual de esta máquina si nunca la detuviéramos sería de:
0.80 $/h * 24 h/dia * 365 dias/año = 7,008 $/año - En el nuevo sistema de pago estas instancias tienen un coste de 0.24 $/hora y una cuota anual de 2,600 $. Con estos datos el coste de esta máquina sería el siguiente:
0.24 $/h * 24h/dia * 365 dias/año + 2,600 $/año = 4,702.4 $/año
Podemos discutir si esta nueva fórmula es adecuada o no para partes del sistema que requieran una flexibilidad mayor en cuanto a número de instancias activas, pero un 33% de ahorro para máquinas “estáticas” es una buena noticia, Sin duda.
Añadir un slave a un entorno de replicación MySQL
Posted by Xavi in Bases de datos, Linux on 16/03/2009
Siguiendo el hilo de los artículos de Laura Berdasco sobre levantar un entorno de replicación Master-Slave en MySQL, Vamos a explicar como añadir un esclavo más a un entorno de este tipo funcionando.
Estos pasos se han realizado en instancias de EC2 con acceso al puerto 3306 desde Internet (se pueden endurecer las políticas de seguridad en este punto pero para realizar las pruebas ya nos servirá esta configuración) y acceso por SSH en sistemas Ubuntu 8.10.
Para añadir un esclavo a un entorno debemos seguir los siguientes pasos:
- Paramos el servidor MySQL del esclavo en funcionamiento (de aquí en adelante slave-1). En la consola del slave-1 con el siguiente comando:
sudo /etc/init.d/mysql stopPara ejecutar este comando debemos acceder a la consola del slave-1 por SSH o localmente. - Paramos también le servidor MySQL del esclavo que queremos arrancar (de aquí en adelante slave-2). En la consola del slave-2 con el mismo comando que en paso anterior.
- Copiamos los archivos del direcotrio /var/lib/mysql del slave-1 al slave-2. Para esta operación necesitamos la clave (keypair) para acceder por SSH del slave-1 al slave-2, en nuestro caso se encuentra en /mnt/keypair.pem.
Si no tenemos este archivo en el slave-1 desde el ordenador en que la tengamos deberemos ejecutar este comando:
scp -i /path/to/keypair.pem /path/to/keypair.pem root@dns.slave-1.com:/mnt/keypair.pemEste comando nos sube por SSH el archivo keypair.pem situado en /path/to al directorio /mnt del servidor remoto (dns.slave-2.com) identificandose como root con el mismo archivo (opción -i). Para realizar esta acción debemos identificarnos como root (a veces puede fallar la ejecución con ‘sudo’).Una vez con el archivo keypair.pem en el slave-1 copiaremos tambien con el comando ‘scp’ el contenido del directorio /var/lib/mysql de slave-1 al slave-2. En la consola del slave-1:
scp -r -i /mnt/keypair.pem /var/lib/mysql/* root@dns.slave-2.com:/var/lib/mysql/Cuando se hayan copiado todos los archivos podemos poner en marcha el servidor MySQL del slave-1. - Una vez copiados estos archivos es importante cambiar el propietario. En la consola del slave-2 ejecutar los siguientes comandos:
cd /var/lib/mysqlSi no realizamos este cambio de propietario es posible que el servidor de MySQL del slave-2 no arranque correctamente.
sudo chown -R mysql:mysql * - Cambiar el server-id del slave-2. Editando el archivo con vim o nano tenemos que abrir el archivo /etc/mysql/my.conf y dónde encontremos una linia así (o con otro número):
...Cambiar el número que aparece por un server-id que no se esté utilizando en el entorno de replicación.
server-id=2 - Para poder arrancar el servidor MySQL del slave-2 sólo nos queda dar permisos de replicación en el master. En la consola del master entramos en el cliente mysql:
mysql -u root -pY ejecutamos la siguiente consulta:
mysql> GRANT REPLICATION SLAVE ON *.* TO 'usuario_replica'@'dns-slave-2.com' IDENTIFIED BY 'pwd_del_usuario_replica'; - Arrancamos el servidor MySQL del slave-2. En la consola del slave-2 ejecutamos el comando:
sudo /etc/init.d/mysql start
Para comprovar que todo ha ido correctamente debemos realizar alguna modificación en el master y asegurarnos que se distribuye a las dos replicas afectadas. Para más información podeis visitrar los compeltos artículos que Laura tiene en su blog sobre la replicación en MySQL: Replicación MySQL con Master-Slave sobre Ubuntu 8.10 (master) y Replicación MySQL con Master-Slave sobre Ubuntu 8.10 (slave).
Empaquetar una instancia de EC2 en funcionamiento (II)
Posted by Xavi in Programación Web on 04/03/2009
Este post es la continuación de Empaquetar una instancia de EC2 en funcionamiento (I), si no lo has leído mejor que le des un vistazo antes de continuar, si ya lo has leído adelante…
Empaquetar la instancia
Para empaquetar la instancia debemos encontrarnos en el directorio /tmp de la instancia y correr el siguiente comando (que pertenece a las AMI Tools que hemos instalado en el apunte anterior):
ec2-bundle-vol -k /mnt/pk-xxxx.pem -c /mnt/cert-xxxx.pem -u xxxx-xxxx-xxxx* El campo xxxx-xxxx-xxxx lo tenemos que sustituir por los numeros que aparecen en la parte superior derecha de nuestra página de Access Identifiers (justo debajo de Welcome Nombre Usuario | Sign Out).
Este comando va a tardar un poco y nos va a generar una serie de archivos que luego va a ser los que vamos a tener que subir y registrar.
Subir la AMI empaquetada a Amazon S3
Para poder disponer de la AMI debemos subirla a un bucket de Amazon S3. En el proceso de registro de una cuenta de EC2 se nos obliga a tener una de S3 porque las instancias quedan almacenadas allí, por lo tanto con una cuenta de EC2 seguro que tenemos acceso a una de S3.
El único requisito que debemos cumplir para subir una AMI a una cuenta de S3 es disponer de un bucket en la misma Availability Zone. Para gestionar les servicios de Amazon Simple Storage Service, S3, existe un programa multiplataforma en Java llamado Bucket Explorer; la licencia cuesta unos 40 dólares que para la simplicidad del programa considero justos (existe una licencia de prueba de 30 días).
Una vez creado el bucket debemos recordar su nombre y correr el comando siguiente dentro del directorio /tmp en la máquina virtual:
ec2-upload-bundle -b nombredelbucket -m image.manifest.xml -a accessKeyID -s secretAccessKey* Evidentemente sustituyendo nombredelbucket por el nombre del bucket creado, accessKeyID por la clave de acceso pública y secretAccessKey por la clave secreta. A parte de esto, el nombre del manifest puede variar según las opciones que hayamos descrito en la operación de “bundle”.
Registrar la AMI
Una vez subida la AMI al bucket de S3 sólo tenemos que registrarla para poder instanciarla desde el tablero de control de EC2. Una vez registrada nos aparecerá si seleccionamos Private Images en el desplegable de la sección AMIs y ya podremos arrancar tantas instancias como queramos desde la web.
Para registrar la AMI debemos correr el siguiente comando en la máquina local (dónde deberíamos tener instaladas las API Tools de Amazon, diferentes de las AMI que hemos instalado en la instancia de EC2, para más información lee mi post anterior sobre Amazon EC2):
sudo ec2-register nombredelbucket/image.manifest.xml
La instancia tarda unos segundos en estar disponible en el panel de control pero si todo ha ido bien deberíamos tener nuestra AMI personalizada y privada lista para lanzarse.
Cualquier duda dejadla en comentarios y miraremos de resolverla lo más pronto posible, así quizás ayudamos a otras personas que se encuentren con el mismo problema
Saludos!
Empaquetar una instancia de EC2 en funcionamiento (I)
Posted by Xavi in Programación Web on 04/03/2009
La documentación de Amazon sobre sus servicios es, en muchos casos, bastante confusa. Por este motivo, y enlazando con un apunte anterior en el que hablabamos de crear una página web sencilla con un servidor en Amazon EC2, vamos a revisar el proceso de empaquetado (bundle) de una instancia para crear una AMI de la que podamos correr tantas instancias como nos apetezca.
¿Por qué queremos crear una propia AMI?
Normalmente las AMI que tenemos a nuestra disposición tienen una selección de software bastante estándar, por consiguiente, si el software que queremos correr difiere mucho de la selección preestablecida, sería recomendable crear una AMI propia para no tener que instalar y configurar todo el software adicional cada vez que arrancamos una instancia.
Esta AMI podrá ser completamente privada, así que podremos dejar la configuración muy ajustada a nuestro sistema para ahorrar el máximo tiempo posible en el arranque de cada máquina virtual.
En resumen podríamos decir que crear una AMI propia nos permite dejar guardada una máquina configurada con todo el software necesario para arrancar una instancia y ponernos a trabajar con un tiempo mínimo de start-up.
Prerrequisitos
Para llevar a cabo este mini-tutorial para realizar el “bundling” de una instancia de EC2 necesitaremos lo siguiente:
- Una instancia de EC2 corriendo Ubuntu 8.10
- Conocer y tener acceso a la Private-key y certificado del protocolo de identificación X.509
- Tener acceso a la instancia de EC2 por SSH (esto implica tener acceso al archivo *.pem que nos sirve de identificación en la instancia)
- Conocer las Access Key ID y Private Access Key de la cuenta de Amazon WebServices
Subir la Private Key y el Certificate a la máquina virtual
Para poder identificarnos en las operaciones que realicemos en la máquina virtual nos hará falta tener a nuestra disposción los archivos de identificación (Private Key y Certificate del protocolo X.509). Aún así debemos tener en cuenta que tendremos que subirlos a un directorio que no quede guardado cuando hagamos el empaquetado de la AMI porque sino podríamos estar esparciendo nuestros archivos secretos de identificación por todas nuestras instancias en funcionamiento (¿y eso es algo que no queremos verdad?).
El directorio dónde vamos a subir estos archivos será /mnt y lo haremos con el siguiente comando:
scp -i /ruta/a/llaves/archivo-de-identificacion.pem /ruta/a/llaves/pk-xxxx.pem /ruta/a/llaves/cert-xxxx.pem root@dns.publica.de.amazon :/mntEste comando sube los dos archivos pk-xxxx.pem y cert-xxxx.pem al directorio /mnt de la máquina virtual como usuario root utilizando el mismo sistema de identificación que utilizariamos si quisiéramos acceder por ssh.
No debería hacer falta pero señalamos que tenemos que cambiar la ruta /ruta/a/llaves por la ruta absoluta de los archivos implicados y dns.publica.de.amazon por la DNS pública de la instancia que podemos encontrar en el panel de control de Amazon EC2.
Instalación de las herramientas en la máquina virtual
Para instalar las herramientas de Amazon para gestionar las AMIs vamos a seguir un proceso que nos ha funcionado pero no tiene porqué ser el único ni el mejor. Este proceso utiliza el paquete precompilado *.rpm de Amazon y la herramienta alien para pasarlo a *.deb. Vamos a verlo paso a paso:
- Accedemos a la máquina virtual por ssh (recuerda que todas las operaciones después de esta se realizarán en la linea de comandos de la instancia en Amazon EC2):
ssh -i /ruta/a/llaves/archivo-de-identificacion.pem root@dns.publica.de.amazon - Instalamos el software que necessitamos para instalar y utilizar las AMI Tools de Amazon:
apt-get install ruby alien* es posible que nos encontremos estos dos paquetes ya instalados en la AMI correspondiente pero mejor asegurarnos. - Descargamos las AMI Tools en un directorio que luego no vaya a ser almacenado en el “bundling” como por ejemplo /tmp:
cd /tmp
wget http://s3.amazonaws.com/ec2-downloads/ec2-ami-tools.noarch.rpm - Una vez descargado el archivo rpm vamos a crear el .deb con alien y instalarlo:
alien -d ec2-ami-tools.noarch.rpm* El nombre del paquete .deb generado puede variar según las versiones del software que estemos utilizando.
dpkg -i ec2-ami-tools_1.3-31781_all.deb
Si todo ha funcionado de forma correcta ya tenemos la instancia preparada para ser empaquetada y registrada pero esto lo veremos en un post posterior (aquí).
¿Me sigues? :-)
Comentarios recientes