Posts Tagged Amazon

Google Storage for developers planta cara a Amazon S3

Corrían rumores de que Google podía presentar una alternativa al servicio de almaceniamiento de Amazon, pero eran muy pocos los que creían que esto realmente podía pasar (me incluyo en el grupo de los incrédulos). Y Google anunció ayer en el Google I/O la disponibilidad de Google Storage for developers, un servicio de almacenamiento on-line con unas características muy parecidas a Amazon S3. Vamos a ver algunas de sus características:

  • Almacenamiento por buckets/objetos: Exactamente igual que su vecino de Amazon.
  • Nombre único del bucket en todo el servicio: Igual.
  • Ausencia de carpetas o jerarquía pero capacidad de introducir el caracter “/” en el nombre del archivo para simular un árbol de directorios: Igual.
  • Privacidad de los objetos 100% y inmutabilidad de los objetos: No recuerdo que Amazon detallara el punto de la privacidad (no estoy seguro), pero en cuanto a la inmutabilidad siguen siendo servicios equivalentes (hace falta reescribir el objeto para modificarlo).

A estas características básicas vamos a añadir un listado de las operaciones básicas. Veremos que siguen cortadas por el mismo patron que S3:

  • Crear y eliminar buckets
  • Listar buckets y objetos
  • Subir y descargar objetos
  • Eliminar objetos
  • Definir listas de control de acceso (ACL) para los objetos
  • Definir metadatos de los objetos

Y una serie de características adicionales, algunas de las cuales sí que marcan alguna diferencia con Amazon:

  • Autenticación basada en cookies (no recuerdo que esto este disponible en S3 pero no estoy seguro de ello).
  • Soporte a las cuentas de Google para establecer el nivel de seguridad de los objetos.
  • Es necesaria una Developer Key (un par de clave de acceso y clave secreta).
  • API REST (no existe una API SOAP y no parece que entre en los planes de Google).
  • Soporte para SSL.
  • Herramientas por linea de comandos y librería basadas en Python (Boto).
  • Aplicación web para gestionar buckets y objetos (!!!).

La lista de precios también sigue el mismo patrón que Amazon pero se ofrece una cuota inicial gratuita (“solo” 100 GB de almacenamiento y 300 GB de transferencia al mes). Los precios son los siguientes:

  • Almacenamiento: 0’17 US$/GB al mes
  • Transferencia (subida): 0’10 US$/GB
  • Transferencia (descarga): 0’15 US$/GB en América y EMEA y 0’30 US$/GB en APAC
  • Peticiones (PUT,POST,LIST): 0’10 US$/1.000 peticiones
  • Peticiones (GET,HEAD): 0’10 US$/10.000 peticiones

¿La mala noticia? Disponible para desarrolladores en los U.S. y con cola de admisión… espero que no tarden lo mismo que Amazon en traer los servicios a Europa!!

Enlace: http://code.google.com/intl/es-ES/apis/storage/

, , , , ,

No Comments

Amazon S3 amplia su abanico de posibilidades (RRS)

Amazon S3 es un servicio de almacenamiento de objetos que fue definido por Amazon como “highly durable” pero nunca habían aportado datos ni estadísticas relacionadas con la durabilidad de los objetos que se almacenaban. Hoy, para anunciar una ampliación del abanico de posibilidades que ofrece el servicio han dado los primeros datos.

Amazon Web Services publica en su blog que la durabilidad de un archivo en su servicio de almacenamiento es del 99’9999999% (7 nueves) o, como exponen en el auncio, que de cada 10.000 objetos que almacenemos puede perderse uno (de media) cada 10 millones de años. Esta persistencia de ficheros en S3 la podemos considerar como muy alta… mucho más de lo que un gran número de aplicaciones necesitan realmente.

En ocasiones, todos los datos volcados en Amazon tienen su respaldo en máquinas que están más cerca del equipo responsable y simplemente se alojan en Amazon para su difusión por Internet (y su posible reposición está más que asegurada). En estos casos, esforzarse para mantener un porcentaje tan alto de durabilidad es un derroche de recursos que el cliente final no tiene porqué pagar.

¡Dicho y hecho!

A partir de hoy mismo, Amazon pone a disposición de los clientes la opción de reducir la durabilidad de sus archivos a 99’9999% (4 nueves) a cambio de una reducción en el precio del almacenamiento. Esta reducción va asociada a un parámetro que debe definirse de forma explícita (por defecto la durabilidad seguirá como antes) y es de un 33% del precio original. En el intervalo más caro (hasta 50 TB al mes), el almacenamiento “normal” cuesta 0’15€/mes por GB y el nuevo almacenamiento 0’10€/mes por GB.

Lo encontrareis en la página de S3 así como en el artículo del que he leído esta información, pero el nuevo sistema de almacenamiento se llama Reduced Redundancy Storage o RRS para los amigos.

, , , ,

No Comments

Amazon AWS anuncia la afinidad de servidores en Elastic Load Balancing

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í.

, , ,

No Comments

Instalar PostgreSQL 8.3 en CentOS desde Yum

Trabajar con servidores Linux, muchas veces comporta trabajar con CentOS. CentOS es una distribución de Linux muy orientada a servidores corporativos y ofrece un rendimiento muy alto en una amplia gama de entornos.

Para trabajar con este sistema es mejor estar habituado al trabajo con el gestor de paquetes de Red Hat (RPM) y Yum, sino tendremos que buscar información sobre como manipular los repositorios y encontrar el software necesario para nuestras aplicaciones. En el siguiente artículo intentaré detallar como instalar un servidor de bases de datos PostgreSQL 8.3 en un CentOS 5.2 (mis pruebas se han realizado en una instancia de Amazon EC2 con una imagen de CentOS 5.2 proporcionada por RightScale).

Desactivar los repositorios por defecto de CentOS

Para poder instalar la versión 8.3 de PostgreSQL tenemos que deshabilitar los repositorios de PostgreSQL que vienen con nuestro sistema operativo. Si no hicieramos este paso es posible que sólo consiguiéramos instalar la vesión que proporcionan los paquetes de la distribución en cuestión.

Para desactivar dichos repositorios debemos editar el fichero /etc/yum.repos.d/CentOS-Base.repo. Yo lo hago con Nano porque me parece un editor más ligero que otros pero el editor cada uno prefiere el suyo:
$> nano /etc/yum.repos.d/CentOS-Base.repo
Y en las secciones base y updates tenemos que excluir PostgreSQL, Para ello añadiremos exclude=postgresql* al final de cada sección. Dichas secciones deben acabar pareciendose a lo siguiente:
[base]
name=CentOS-$releasever - Base
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep$
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5
exclude=postgresql*

[updates]
name=CentOS-$releasever - Updates
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep$
#baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/
gpgcheck=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5
exclude=postgresql*

Añadir los repositorios de PostgreSQL 8.3

Una vez desactivados los repositorios por defecto debemos definir los nuevos repositorios. Para ello utilizaremos los RPM de la página de repositorios de PostgreSQL. En la página copiaremos en enlace de la última versión de la rama 8.3 y iremos a la línea de comandos:
$> cd /tmp
$> wget http://yum.pgsqlrpms.org/reporpms/8.3/pgdg-centos-8.3-6.noarch.rpm
$> rpm -ivh pgdg-centos-8.3-6.noarch.rpm

NOTA: Recuerda que debes cambiar la URL de descarga del paquete RPM por la que corresponda en el momento que realices la operación.

Instalar el servidor de base de datos

Una vez activados los repositorios tenemos que instalar el servidor de base de datos:
$> yum install postgresql postgresql-server
Es posible que en este paso nos de un problema de librerías por culpa de un paquete llamado apr-util. En este caso deberemos instalar primero este paquete (por separado) y luego volver a lanzar la instalación del servidor:
$> yum install apr-util
$> yum install postgresql postgresql-server

La solución al problema de dependencias no debería reproducirse si instalamos el servidor de bases de datos en estos dos pasos.

Arrancar el servidor y habilitar conexiones remotas

Para arrancar el servidor seguiremos los pasos siguientes:
$> service postgresql initdb
$> service postgresql start

Con esto ya tendremos el servidor de base de datos arrancado y aceptando conexiones en local, pero no podremos acceder al servidor desde conexiones remotas. Para habilitar las conexiones remotas debemos asegurarnos que no hay ningún tipo de bloqueo que no sea el del servidor Postgre, modificar dos ficheros y reiniciar el servicio. El primer fichero que vamos a modificar es /var/lib/pgsql/data/pg_hba.conf.

En pg_hba.conf se tiene que dar acceso a la red desde la que vamos a acceder (dirección IP), en el ejemplo vamos a usar 0.0.0.0/0 pero se debería cambiar por nuestra dirección para tener un control más estricto. Para dar acceso a una red añadiremos los siguiente al fichero:
host all all 0.0.0.0/0 trust

El segundo fichero que debemos modificar es /var/lib/pgsql/data/postgresql.conf. En este debemos buscar la línea que pone:
listen_addresses='localhost'
Y poner:
listen_addresses='*'

Una vez realizados estos cambios se tiene que reiniciar el servicio:
$> /etc/init.d/postgresql restart

En teoria, cuando el servicio arranque de nuevo debería ser posible establecer conexiones remotas al servidor con el usuario postgres y el password que le corresponda. En caso de que no se haya definido password para dicho usuario, éste se puede setear de forma manual. Como usuario ROOT ejecutamos el siguiente comando:
passwd postgres
El sistema nos pedirá que introduzcamos dos veces el password y listo! Espero que les sirva de ayuda.

, , , , , ,

No Comments

Amazon RDS – La nube de datos relacional*

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:

  1. Descargamos las RDS Command Line Tools de la página oficial de Amazon
  2. 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 ;-)
  3. 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”.
  4. 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.
  5. 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.
  6. 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.

logo_aws

*No me agredais física ni intelectualmente por el juego de palabras!!

, , , , ,

1 Comment

Subir vídeos a YouTube con Zend Gdata – Subir el vídeo

Para finalizar la serie de artículos dedicados a la subida de un vídeo a YouTube desde nuestra aplicación web en PHP (con el módulo Zend_Gdata) vamos a describir el proceso que se debe seguir desde el punto en que lo dejamos en el post anterior.

Una vez recibido el token de YouTube (ver post anterior) deberemos seguir estos pasos:

Upgrade del token recibido a un token de sesión

Para realizar más de una operación con la cuenta del usuario que se ha identificado en la página de YouTube debemos hacer un “upgrade” del token recibido. Para realizar una sola operación no sería necesario hacer este paso pero aquí recomendamos hacerlo para que no surjan problemas a posteriori con la identificación del usuario.

El upgrade del token requiere haber recogido el valor original de token enviado por YouTube a través de la petición. En el siguiente fragmento de código vamos a explicar cómo hacer la actualización del token recibido por un token de sesión presuponiendo que recuperamos el valor del token por GET.
$originalToken = $_GET['token'];
$ytClient = new Zend_Gdata_HttpClient();
$ytClient->setHeaders("X-GData-Key: key=VALOR_DE_TU_CLAVE_DE_DESARROLLADOR");
$ytClient->setAuthSubPrivateKeyFile('/path/a/clave.pem',null, true);
$sessionToken = Zend_Gdata_AuthSub::getAuthSubSessionToken(trim($originalToken),$ytClient);

$ytClient->setAuthSubToken($sessionToken);
En este fragmento de código podemos observar como recuperamos el valor del token por GET y cómo construimos el Zend_Gdata_HttpClient para que la petición de actualizar el token pueda ser satisfecha. En la última instrucción de este fragmento se setea el nuevo token de sesión en el cliente http para que las peticiones posteriores sean ejecutadas con los permisos que se han conseguido con la identificación de este usuario.

La clave de desarrollador y la clave.pem que se utilizan en este trozo de código corresponden a los requisitos previos que comentábamos en el primer post sobre la subida a vídeos a YouTube. Estas claves se incluyen en el cliente http que realizará las consultas a modo de signatura (para la seguridad de las peticiones que se realizarán a YouTube).

Subir el vídeo

Llegados a este punto, la subida del vídeo es la parte más sencilla de todo el proceso. Sólo hace falta seguir al pie de la letra las indicaciones existentes tanto en la documentación del Zend Framework como en la página de la API de YouTube destinada a este propósito para que la operación llegue a buen puerto.

A continuación se detalla el código necesario para la inserción del video a YouTube:
$yt = new Zend_Gdata_YouTube($ytClient);
$myVideoEntry = new Zend_Gdata_YouTube_VideoEntry();
$filesource = new Zend_Gdata_App_MediaFileSource('Sample.mov');
$filesource->setContentType('video/quicktime');
$filesource->setSlug('Sample.mov');

$myVideoEntry->setMediaSource($filesource);
$myVideoEntry->setVideoTitle('Prueba de subida a YT');
$myVideoEntry->setVideoDescription('Una descripción');
$myVideoEntry->setVideoCategory('Music'); //La categoría debe ser una categoría válida en YouTube
$myVideoEntry->SetVideoTags('mytest, sample'); //Tags
$myVideoEntry->setVideoDeveloperTags(array('solutions', 'iceberg')); //Tags como desarrollador

//URI estática para realizar las subidas
$uploadUrl = 'http://uploads.gdata.youtube.com/feeds/api/users/default/uploads';

//Bloque try-catch para subir el vídeo
try {
$newEntry = $yt->insertEntry($myVideoEntry, $uploadUrl, 'Zend_Gdata_YouTube_VideoEntry');
} catch (Zend_Gdata_App_HttpException $httpException) {
echo $httpException->getRawResponseBody();
} catch (Zend_Gdata_App_Exception $e) {
echo $e->getMessage();
}

De forma opcional se puede geolocalizar el vídeo que se está subiendo pero esto se puede encontrar de forma sencilla en la documentación de la API de YouTube.

A modo de epílogo sólo comentar que el archivo de vídeo que se utiliza ‘Sample.mov’ debe estar alojado de forma obligatoria en el servidor desde el que se está ejecutando esta operación. YouTube no acepta URLs como input para la subida de vídeos (lo hemos probado con unos enlaces públicos a archivos alojados en Amazon S3 y no ha habido manera).

Espero que toda la información vertida en estos tres artículos haya sido de utilidad, en breve se publicará un meta-post con los enlaces a los tres apuntes relacionados.

, , , , , ,

5 Comments

S3 Firefox Organizer, un cliente gráfico gratuito para Amazon S3

Amazon S3 es un sistema de almacenamiento de datos on-line muy completo en cuanto a funcionalidades. Las diferentes possibilidades que tenemos para acceder a estas funcionalidades desde los lenguajes de programación mayoritarios hacen de él un gran producto para albergar los datos multimedia de una aplicación web. No obstante, mientras realizamos pruebas, es possible que nos haga falta un cliente gráfico para confirmar que las operaciones que han realizado nuestras aplicaciones son las que pretendiamos.

Cuando empecé a trabajar con S3, recurrí a BucketExplorer. Este programa ofrece casi todas las funcionalidades que podríamos pedir de un cliente gráfico pero el hecho de estar programado en Java ofrece una ejecución multiplataforma pero también una ejecución bastante lenta. Su funcionamiento es muy correcto y cumple los requisitos demandados para mis tareas, pero encontrarme un par de “buckets” en mi cuenta de Amazon S3 (que yo no había creado) con su nombre me hizo desconfiar y lo eliminé de mi directorio de programas.

Hasta hace unas horas no tenía ningún cliente gráfico de S3 en mi sistema hasta que me he tropezado con S3 Firefox Organizer, un add-on para Firefox que nos brinda todas las funcionalidades necesarias para gestionar diversas cuentas de S3. Este plugin recuerda sin ninguna duda a FireFTP, un cliente FTP accesible desde las pestañas de Firefox.

Logo FireFTP

Logo FireFTP

Si quereis probar S3 Firefox Organizer sólo teneis que ir al directorio oficial de plugins del navegador y buscarlo, la verdad es que a mi me ha sorprendido agradablemente y creo que me quedaré con el durante un buen tiempo.

Espero que os guste y me conteis que tal vuestra experiencia con él.

Technorati Profile

, , , ,

No Comments

Amazon premia la planificación

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.

, , , ,

3 Comments

Añadir un slave a un entorno de replicación MySQL

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/mysql
    sudo chown -R mysql:mysql *
    Si no realizamos este cambio de propietario es posible que el servidor de MySQL del slave-2 no arranque correctamente.
  • 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):
    ...
    server-id=2
    Cambiar el número que aparece por un server-id que no se esté utilizando en el entorno de replicación.
  • 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).

, , , , ,

No Comments

Elasticfox, un buen plugin para gestionar Amazon EC2 desde Firefox

La gestión de servicios de Amazon EC2 nos obliga a tratar con las API y AMI Tools de Amazon a través de la línea de comandos (hay una expicación de como instalar API y AMI Tools en este mismo blog, aquí y aquí). El tablero de control vía web que nos ofrecen muchas veces resulta insuficiente porque sólo podemos ejecutar un pequeño número de las operaciones disponibles y la gestión de según qué es muy pesada hacerla comando a comando.

Suponogo que conocedores de estos inconvenientes, Amazon pone a servicio de los usuarios un plugin para Firefox llamado Elasticfox. Por cierto, no lo busques en el buscador oficial del navegador porque no està disponible, aquí tienes el enlace.

Elasticfox ofrece una interficie bastante simplificada para gestionar la mayoría de los servicios de Amazon EC2. Para operaciones complicadas se tiene que recurrir igualmente a la línea de comandos pero para conocer el estado de nuestras instancias y bloques de almacenamiento con un vistazo rápido tenemos suficiente.

Y un apunte final… Si estamos mirando en una “availability zone” determinada no vemos los datos de las otras zonas. ¿Esto es una ventaja realmente? Si alguien está gestionando sus instancias de Estados Unidos, ¿No quiere ver las que están corriendo en Europa? Quizás tendría que haber una opción que permetiera esconder la información de otras zonas, pero que no se puedan ver todas de golpe me parece incómodo.

, , , ,

No Comments