Posts Tagged RDS
Amazon AWS anuncia la afinidad de servidores en Elastic Load Balancing
Posted by Xavi in Programación Web on 08/04/2010
Uno de los problemas más importantes que existían para desarrollar aplicaciones web en las infraestructuras de Amazon era la falta de un balanceador de carga que presentara afinidad de servidores. Ésto representaba un problema muy grave para la creación de aplicaciones ya que, hoy en dia, se almacenan datos en variables de sesión para facilitar la navegación de los usuarios. Con un servidor único para la aplicación no existe tal problema porqué las variables de sesión siempre están disponibles, pero con diferentes servidores y un balanceador de carga se corre el riesgo de que diferentes peticiones de páginas web se sirvan desde diferentes servidores y las preferencias de los usuarios se pierdan.
Antes, Amazon tenía un balanceador de carga que derivaba las peticiones a diferentes servidores pero no servía para aplicaciones complejas, ya que no se podía configurar para que enviara todas las peticiones de un mismo cliente (navegador web) a un mismo servidor.
A través del blog de Amazon AWS se acaba de anunciar la disponiblidad de la afinidad de servidores en su balanceador de carga Elastic Load Balancer. Esta funcionalidad puede solucionar el problema que comentábamos al principio y facilitar la puesta en marcha de muchas aplicaciones en un entorno de altas prestaciones. Sin duda se trata de una gran notícia para muchos desarrolladores!!
Se puede consultar el post original de Amazon AWS aquí y la documentación aquí.
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!!
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).
¿Me sigues? :-)
Comentarios recientes