elgeorge2k

Introducción Si necesitas alojamiento para un sitio web, tienes ciertos conocimientos de administración de servidores y quiere empezar de la dirección correcta con las herramientas de última tecnología éste post es para ti. Hay varias maneras de iniciar con tu sitio web basado en LAMP sin empezar gastando mucho dinero por el servicio, una de ellas es conseguir un alojamiento web gratuito, otra es tener tu sitio web alojado en tu computadora y usar soluciones como No-IP para mantener tu dominio apuntado a tu dirección dinámica por medio de un cname a un host, pero esto tiene varias desventajas: Desventajas del alojamiento gratuito: 1. No es escalable. En cuanto tu sitio empiece a tener visitas, vas a requerir pagar un plan mas completo, y eventualmente ya no te sera posible continuar con un alojamiento compartido por lo que necesitaras terminar pagando por servidores dedicados o virtuales. 2. No es autoritativo. No puedes usar muchas funciones nativas de LAMP, usar cronjobs o trabajar con comandos especiales del sistema operativo, muchas veces tienes limitado el acceso a archivos remotos y a conexiones remotas a la base de datos. Si tienes un problema que no puedes reparar necesitas ayuda del soporte técnico el cual tarda su tiempo en responder, ademas de que el sistema te pone bloqueos cuando tus programas php usan mucho CPU. No puedes adecuar tus propias soluciones como respaldos incrementales usando scripts en bash, o instalar aceleradores o programas específicos PECL para aumentar la capacidad de PHP. 3. Contenido encerrado. No puedes optar por hacer copias de tu contenido en otros servidores u otros servicios y en muchos casos solo puedes acceder a los archivos de tu contenido por FTP o Web, no puedes hacer dumps de la base de datos ni respaldar la base de datos en un servidor remoto. Si tu cuenta es bloqueada o eliminada por alguna razón no podrás acceder a tu contenido. Desventajas del alojamiento local 1. No hay garantía de conexion, si tienes un problema con la conexion a internet o la luz electrica tus sitios se van abajo, eso sin mencionar que tienes que tener encendidos los equipos todo el tiempo. 2. Conexión limitada. Por lo regular la conexión de subida esta mucho mas limitada que la de bajada en ISPs locales, y esta conexión en algunos casos no puede atender el trafico que necesitas. No es una solucion escalable. 3. Depende de tu infraestructura fisica. Si se daña un disco o la maquina por una descarga electrica puedes perder toda la información que había en el, por eso necesitas estar haciendo respaldos continuos para garantizar que no se pierda un sitio web completo por un error físico. Es por esto que yo opto por una tercera solución mas confiable y escalable que las otras 2: Amazon AWS es una serie de servicios basados en la nube que ofrece 1 año gratuito de un servidor virtual llamado instancia en su capacidad mas baja. Esto permite que puedas instalar tus servicios y probar de manera segura, gastando a lo mucho unos cuantos centavos al mes. Las ventajas son: 1. Escalable: si tu sitio empieza a tener mucho flujo solo inicias otras instancias y tienes un servicio distribuido. 2. Autoritativo: Tu tienes toda la capacidad de decisión sobre tu instancia virtual por lo tanto puedes configurar todos los servicios como tu los necesites para el desarrollo de tu sitio y manejo óptimo de la instancia. Puedes tener un script que haga copia de todos tus archivos en S3, o en cualquier unidad de tu preferencia (Dropbox, etc.). Solo tienes que montarla y listo. 3. Ancho de banda. Si algo tiene Amazon AWS es que tiene un ancho de banda (taza de transferencia) superior a cualquier otro servicio de alojamiento compartido, ya que cuentan con conexiones de alto nivel y una infraestructura casi insuperable. Puedes estar tranquilo de que los servicios estarán funcionales y ya que tus datos estan fisicamente distribuidos no tienes que preocuparte porque Amazon pierda tu información o se dañe un disco. Empezando con Amazon AWS Requerimientos para subscribirse a Amazon AWS * Tarjeta de crédito * Teléfono fijo Requerimientos para instalar todo lo necesario * Conocimientos básicos de Linux y administración de servidores Suscripción Para subscribirse en amazon aws solo tiene que tener a disposición una tarjeta de crédito y un teléfono local (de casa o empresa). Siga los pasos en Amazon AWS donde dice Registrese ahora Selección de la imágen Puede escojer una imágen de Windows, Amazon, SuSE, o RedHat desde el Wizzard Clasico, pero estas distribuciones tienen algunos problemas de manejor de instalaciones. Yo recomiendo usar una imagen de Debian "squeeze" base de 64 bits. Solo necesita ir a buscar AMIs Comunitarias e instalar alguna. ¿Porqué Debian? Mi punto de vista: Debian es un sistema operativo con releases estables y probadas (mucho mas estables que las de Ubuntu). El manejo de paquetes en Debian (usando aptitude) resuelve automáticamente todas las dependencias y es mucho menos caótico que el de su contra parte de RedHat (yum). Además es mucho más compacto y ligero, usa mucho menos memoria lo que es optimo para la instancia gratuita t1.micro que dan gratis: Aqui un punto importante: El disco debe ser EBS (No instance-store) ya que solo puedes iniciar un t1.micro con EBS además de que el instance-store no es persistente (se reinicia cuando se apaga la instancia). El espacio para EBS gratuito es de 30Gb, así que es importante que a la hora de asignar el espacio se pongan los 30Gb para que se aprobechen al máximo todos los recursos gratuitos. http://aws.amazon.com/es/ec2/pricing/ Región: No importa que region utilices para el plazo gratuito, pero hay regiones mas baratas que otras cuando tu plazo de 1 año expire, o si necesitas mas que un t1.micro en un plazo menor. La región US Virginia es mucho mas barata que muchas otras y hay servicios que no estan disponibles en otras regiones, además de tener mucho más zonas de disponibilidad; asi que ésta es la que les recomiendo. Inslalación Una ves con la instancia corriendo podrás bajar (por única ocasión) el certificado PEM de conexión por SSH. Ten mucho cuidado ya que si pierdes este certificado no podrás acceder como root a la instancia y tendrás que crear otra. Una ves conectado checa que la instancia tenga swap. Si no tiene puedes hacer lo siguiente para agregar un archivo de swap: dd if=/dev/zero of=/var/swap bs=1024 count=524288 chown root:root /var/swap chmod 0600 /var/swap mkswap /var/swap echo "swap swap defaults 0 0" >> /etc/fstab Tambien hay que actualizar tus paquetes: aptitude update && aptitude upgrade Con esto ya tenemos una instancia funcional y podemos proceder con los servicios: Para instalar los paquetes de tu ambiente LAMP básico: aptitude install mysql-server mysql-client apache2 php5 php5-mysql libapache2-mod-php5 Hay que habilitar un módulo para poder trabajar con los .htaccess: a2enmod rewrite Yo te recomiendo instalar memcached para mejorar el rendimiento con sesiones y olvidarte del script que elimina las sesiones de php: apt-get install memcached php5-memcache Y cambiar las sesiones de archivo a memcached: echo ' ; Handler used to store/retrieve data. session.save_handler = memcached session.save_path = "localhost:11211" ' > /etc/php5/conf.d/sessions.ini No te olvides que hay que habilitar el puerto 80 (HTTP) para ver su sitio web. Esto se hace en la consola de AWS en la sección Security Groups, selecciona el default y haz click en Inbound. Despues solo agregas la regla de HTTP, le das click en Add Rule y luego Apply Rule Changes. Si tienes un dominio, en ves de asignar un registro A a una IP. Asigna un cname record * al Public DNS de tu instancia. Esto funciona igual que un record A y te permite prescindir de una Elastic IP. Listo! ya tienes tu dominio apuntando a tu instancia y por lo tanto puedes hacer esto: http://tudominio.com/ Debe aparecer "It Works!!", despues puedes agregar un phpinfo y ver si tu php funciona así: echo '<?php phpinfo(); ' > /var/www/info.php Y puedes verlo en http://tudominio.com/info.php Hasta aquí has instalado tu ambiente con éxito. A continuación de mostraré algunos trucos extra para sacarle el máximo provecho a tus servicios de Amazon. Aqui te recomiendo que uses una Maquina Virtual como VirtualBox e instales la misma versión con los mismos paquetes para que tengas una maquina de prueba local en la que puedas trabajar y probar nuevas cosas antes de hacer cambios en tu instancia. CDN CDN (Content Delivery Network) es una manera de colocar tus archivos en servidores distribuidos por el mundo de manera que tus usuarios los descarguen de manera más veloz y sin requerir servirlos desde tu instancia. ¿Como se logra eso? Amazon S3 es un servicio de almacenamiento de objetos que te permite colocar archivos y acceder a ellos públicamente. Amazon AWS ofrece 5Gb gratuitos de uso de éste servicio por 1 año, así que si tu sitio web tiene archivos estaticos que en total son más de 5Gb tendrás que calcular el costo del uso de lo restante que tendras como cargo a tu tarjeta cada mes. En la practica: Puedes subir directamente los archivos usando el CloudBerry Explorer a un bucket publico o usar una herramienta muy versatil llamada FUSE over Amazon para conectar tu bucket como si fuera una unidad remota que puedes montar sobre tu ruta de archivos, por ejemplo en /var/www/cdn. FuseOverAmazon Para instalar Fuse Over Amazon necesitas descargar el paquete de instalación y seguir las instrucciones. http://code.google.com/p/s3fs/wiki/InstallationNotes Te recomiendo que uses tu VM en VirtualBox para crear un .deb a partir del paquete (instrucciones aquí: http://blog.foaa.de/2009/09/building-fuse-s3fs-debian-package/) que despues puedes instalar usando: dpkg -d s3fs.deb Y evitarte instalar los paquetes de build essentials en tu instancia. Una cosa que te recomiendo es editar el launch data de tu instancia y agregar: #!/bin/bash mount -a Debido a que la librería de FUSE se inicia despues de montar el fstab, por esto se necesita ejecutar mount -a posteriormente para que al iniciar la instancia quede todo montado correctamente. Ya que tengas el s3fs puedes montar tu unidad guardando las credenciales para tu servicio en /etc/s3fs-passwd (recuerda proteger el archivo usando chmod 600 /etc/s3fs-passwd). Agrega una entrada a fstab para que tu bucket se monte automaticamente en caso de que reinicies la maquina: s3fs#<bucket> /var/www/cdn fuse default_acl=public-read,allow_other,nodev,noexec,nosuid 0 0 Cambiando <bucket> por el nombre de tu bucket. default_acl=public-read Permite decirle a S3 que los archivos van a poder ser leidos públicamente, pero no escritos. Ahora apunta tu subdominio al bucket. Esto es sencillo, solo tienes que ir a tu AWS Console en S3 haz clic en tu bucket y dirigete a donde dice Website. Escribe index.html y error.html y copia el hostname. Apunta cdn.tudominio.com con un CNAME a este nuevo hostname y listo! con esto ya tienes tu redirección lista para CDN. Una cosa que es importante para que esto funcione es que tu bucket se tiene que llamar como el subdominio desde el que apuntas. Por ej. si tu subdominio es cdn.tudominio.com, el buquet se debe llamar así tambien. Si ya tienes datos en tu bucket solo tienes que moverlos desde la consola usando Cut y Paste. Otra cosa que necesitas hacer es cambiar los urls a tus imágenes para que apunten a tu dominio cdn.tudominio.com en ves de tudominio.com o www.tudominio.com para que funcione. CloudFront Hasta ahora tu sitio web funciona como un CDN, y tus imágenes y contenido estático son mostrados usando el servicio de S3 lo que es muy bueno ya que te quita carga de tu servidor web, pero no es un verdadero CDN ya que esta regionalizado (ubicado en una región). Para convertirlo en un verdadero CDN necesitas usar CloudFront. Este te permite distribuir tu contenido redundántemente en diferentes ubicaciones en todo el mundo para poder cumplir con la demanda de tiempo de respuesta de tus aplicaciones pero este servicio NO tiene un plan gratuito. Precios: http://aws.amazon.com/en/cloudfront/pricing/. Para activarlo entra en la consola y en CloudFront haz click en Create Distribution, selecciona para Download y el bucket. A continuación escribe el cname que usaras (cdn.tudominio.com), escribe index.html como root object y haz click en Siguiente y Create Distribution. Despues tienes que cambiar el CNAME de cdn.tudominio.com a tu Domain Name que se especifica en la distribución. Esto permitirá aplicar el CDN sin tener que cambiar los URL en tu código fuente. Optimización Tu instancia t1.micro funcionará bien con 1 request de ves en cuando, pero no esta preparada para trafico real con más de 1 request por segundo. La optimización se basa en reducir el uso de los recursos en una serie de factores. Si usas HTML estático probablemente tu código no se pueda optimizar mucho, ya que no usa mucho proceso y por lo tanto es solo cuestion de optimizar los valores del servidor. Si por el contrario usas un CMS como Wordpress, es recomendable que instales un plugin que te ayude a optimizar al maximo tu sitio web: W3 Total Cache te puede ayudar mucho en Wordpress. Utiliza memcached para todo; pero si tu sitio web tiene muchas páginas web te recomiendo probar con disco para evitar llenar la memoria de memcached. Si tienes otro CMS busca optimizar correctamente. Entra a webpagetest.org para hacer un benchmark de tu sitio y saber que es lo que necesitas optimizar. Tambien es recomendable que desinstales servicios que ocupan mucha memoria en tu instancia y ajustes las variables de perfork de apache a un buen minimo para una instancia t1.micro. Aqui hay una muy buena guía en inglés: http://www.earnersblog.com/vps-optimization-guide/ Para darte una idea, una instancia t1.micro puede soportar entre 10-20 requests por segundo si esta bien optimizada. Por lo tanto hay que ajustarla para este desempeño. Una instancia m1.large puede soportar entre 30-60 requests por segundo bien optimizada, así que bien vale la pena su precio. Varnish Varnish es un Acelerador HTTP que se coloca entre tus usuarios y tu servidor web, y hace las veces de un proxy con cache para almacenar temporalmente copias del contenido de tu sitio y poder así generar respuestas casi instantáneas ya que no tiene la necesidad de generar todo el código cada ves que pide el contenido de una página web. Pero no solo esto. Tiene la habilidad de funcionar como balanceador web, y también para redirigir el trafico en caso de que una instancia no tuviera capacidad de respuesta. Para instalarlo: curl http://repo.varnish-cache.org/debian/GPG-key.txt | apt-key add - echo "deb http://repo.varnish-cache.org/debian/ squeeze varnish-3.0" >> /etc/apt/sources.list apt-get update && apt-get install varnish Para configurarlo: Recomiendo el uso del archivo de configuracion VCL. Para esto edita tu archivo /etc/default/varnish y quita el comentario donde dice Alternative 2, Configuration with VCL Los parametros son muy sencillos: DAEMON_OPTS="-a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -p connect_timeout=300 -s file,/var/lib/varnish/varnish_storage.bin,1G" Necesitas crear el directorio donde va a estar el archivo de cache: mkdir /var/lib/varnish Y despues necesitas agregar el archivo de configuración VCL donde vas a especificar todos los parámetros. Puedes usar mi configuración y después personalizarla conforme tus propias necesidades: http://snipt.org/uRn1 Explicación de cada segmento: * Las partes con #C son codigo en C, estan ahi para hacer debug en syslog. * probe healthcheck define un healcheck para todos los backend * backend default es el backend chando no se selecciona ninguno en especifico * include "backend.d/midominio.vcl"; sirve para agregar un backend especial por dominio. Recomiendo poner esto para determinar fallback director y así poder tener una maquina de "respaldo" en caso de que la instancia no responda. * acl purge es un ACL para realizar purges y bans. Estos son esenciales para poder descartar objetos del cache desde las aplicaciones. * set req.backend = midominio; es donde establecemos el backend que vamos a querer para ese dominio. Esto es opcional * ! req.backend.healthy le decimos que si no esta disponible el backend se le de mas tiempo de gracia a los objetos del cache. En este caso si el backend no esta disponible, varnish segira respondiendo objetos del cache por 10 minutos más. * req.http.X-Forwarded-For es para establecer la IP desde donde se mando el request. Esto es muy util ya que apache guarda en REMOTE_ADDR la IP del cliente, pero como en este caso su cliente técnicamente es varnish, asi que si necesitas el cliente original necesitas instalar el modulo rpaf de apache para poder indicarle que guarde el valor de X-FORWARDED-FOR en donde esta el REMOTE_ADDR. Para instalarlo: apt-get install libapache2-mod-rpaf * if (req.http.Accept-Encoding) { En esta seccion se establece el Encoding correctamente ya que varnish guarda copias del cache en cada uno de los formatos en que se manda al cliente. En este caso gzip es el formato preferido ya que tiene mejor "compress ratio" y lo realiza más rapida y con menos uso de cpu que el deflate. En este caso no comprime archivos que por su naturaleza ya se encuentran comprimidos como jpeg, gif, etc. * # Remove tracker cookies En las siguientes lineas Varnish remueve las cookies que no le sirven al backend (no hay que confundir las cookies que necesita el frontend, estas las mantiene el cliente) para poder utilizar varnish de manera eficiente hay que borrar todas las cookies que establecen los front-end y no son necesarias para el backend como los trackers. * Remove cookies from static files: Aqui se eliminan todas las cookies si el request termina con una extension de archivo estatico. Esto se hace debido a que los archivos estaticos no se procesas dinamicamente por el servidor por lo tanto no le sirven las cookies y se pueden almacenar en cache sin problemas. * req.http.Cookie ~ "NO_CACHE": Esto sirve para poder establecer una cookie especial llamada NO_CACHE que hace que Varnish pase todos los requests directamente al backend (apache). Aqui les presento un codigo en javascript muy util para poder establecer esta cookie para el sitio actual y poder hacer esto automaticamente: var hostname = window.location.hostname.split('.'); var domain = '.' + hostname[hostname.length - 2] + '.' + hostname[hostname.length - 1]; document.cookie = 'NO_CACHE=1; expires=-1; path=/; domain=' + domain; location.reload(); * req.http.host == "midominio.com" && req.url ~ "^/phpmyadmin/": Son reglas especificas para no hacer cache, por ejemplo le estamos diciendo que midominio.com/phpmyadmin/* no va a entrar en el cache de varnish. * Donde dice set beresp.http.X-Cache = "PASS"; y set beresp.http.X-Cache = "MISS"; le estamos especificando respuestas para los headers del front-end. Esto es muy util para saber si la página esta siendo almacenada por Varnish o no. PASS es cuando por alguna regla no se esta almacenando. MISS es cuando falto en el cache debido a ya sea que expiro o se elimino por un purge o ban. HIT es cuando lo recupero del cache. * set resp.http.X-Served-By = server.hostname; establece X-Served-By el host que sirvio de conexión de Varnish. Una ves que has instalado Varnish hay que mover tus sitios a otro puerto. En este caso escoji el 8080 por ser un reconocido puerto alternativo de HTTP. Edita /etc/apache2/ports.conf y agrega: NameVirtualHost *:8080 Listen 8080 Tambien hay que modificar tus Vhosts para cambiar el puerto de escucha :80 a :8080 sed -i 's/:80/:8080/g' /etc/apache2/sites-enabled/* ++Reinicia apache para aplicar los cambios. Auto Scaling Amazon EC2 ofrece esta funcionalidad -actualmente solo soportata por API y comandos- que permite que se ejecute automáticamente otra instancia cuando las instancias que tienes no soportan la carga de usuarios para tu sitio. No te voy a mentir: escalado=incremento en costo, pero te puedo dar tips para que sin tener que pagar nada tengas listas tus instancias cuando necesites escalar tus instancias. Para habilitarlo haz lo siguiente: Lo primero que necesitas es una AMI propia, puesto que si inicias con la AMI base, tendrias que instalar todos los paquetes al iniciarla lo cual no es muy practico. Esta AMI tendra todo lo necesario para funcionar: Apache, PHP, pero los servivios de Memcached y MySQL tienen que estar centralizados. Por esto te recomiendo que tengas una instancia centralizada, que solo va a tener los servicios de Memcached y MySQL, y alojara tus archivos. Necesitas tener una imágen que estarás lanzando con un cliente de NFS para compartir tus archivos entre las maquinas, y el servidor de Apache y Memcached y lo colocaras en un Load Balancer donde estarán tus instancias que vayas lanzando. Aquí lo que te recomiendo para tener listo tu autoscale con plan gratuito es que tu instancia principal (la que tiene servidor MySQL) tenga servicio apache2 y todo lo que necesita para servir requests; y esté dentro del Load Balancer. Cuando necesite escalar lo unico que tienes que hacer es activar la configuracion de escalabilidad y sacar la instancia principal del load balancer y así tu carga de apache en una instancia no afecta el desempeño de la base de datos mysql que va a estar en la otra. Creación de la AMI Esto es lo más fácil de hacer: Haz click en tu instancia principal y selecciona: "Create Image (EBS AMI)". Cuando termine este proceso tendrás una AMI o imagen de Amazon de tu instancia "principal" lista para iniciarse. Para modificarla puedes lanzarla (launch), conectarte y modificarla. Cuanto termines y tengas lista tu instancia vuelves a crear otra AMI de ésta nueva instancia y puedes borrar la anterior que es de la "principal" (tambien el snapshot que no vas a necesitar). En tu AMI necesitas desinstalar mysql y memcached. apt-get purge mysql-server memcached Necesitas borrar todo en /var/www en tu AMI para dejar una directorio vacio que se pueda montar para nfs. Despues necesitas las nfs-common para montar y agregar el mount point a /etc/fstab para que se monte automaticamente: apt-get install nfs-common echo '<host>:/var/www /var/www nfs defaults,noatime 0 0' >/etc/fstab Claro tienes que poner el host que vas a utilizar. Yo te recomiendo que uses un nombre descriptivo para apuntar tu host principal con un CNAME en tu dominio, usa el Public DNS para apuntar. Usualmente para un servidor de archivos se usa NAS (Network Attacked Storage). Entonces puedes apuntar: CNAME nas.midominio.com => <Public DNS> de tu instancia principal y entonces usas nas.midominio.com como tu <host>. Instancia Principal Para instalar el NFS Server en tu instancia principal solo necesitas instalar el paquete: apt-get install nfs-kernel-server Y actualizar tu archivo /etc/exportfs. Puedes compartir localmente todos tus archivos ya que estas IP solo las va a usar tu red local y no estaran disponibles publicamente: /var/www 10.0.0.0/8(rw,sync) Esto permitira que tu directorio /var/www este disponible para cualquier IP que comienze con 10. (red privada). Listo! ya tienes tu instancia optimizada y lista para servir de NAS, DB y Memcached al máximo. Configurar AutoScaling Instalar APIs Necesitas instalar las siguientes command line APIs. Yo te recomiendo que lo hagas en tu maquina virtual (VirtualBox) para que no tengas cosas que no necesitas en tus servidores de Amazon. * EC2 API Tools * Elastic Load Balancing API Tools * Auto Scaling CL Tools * Amazon CloudWatch CL Tools Para instalarlas solo descarga todos los paquetes y colócalos en una ubicación común, por ejemplo /usr/share/aws/ ec2, as, y mon respectivamente. Necesitas algunas credenciales: 2 archivos para las EC2 y 1 archivo para las demás. Baja un archivo de certificado desde AWS Credenciales de Seguridad y su llave. Guarda estas credenciales en una ubicación común. Por ejemplo /etc/aws/ cert.pem y pk.pem para la llave. Copia el archivo credential-file-path.template que viene con cualquiera de las command line tools a /etc/aws/credentials.conf y agrega tus credenciales de AWS (AWS Credenciales de Seguridad). Necesitas el JRE. Puedes instalar openjdk-6-jre (o default-jre) Tambien necesitas las siguientes variables de entorno: export JAVA_HOME="/usr/lib/jvm/java-6-openjdk/jre" export EC2_HOME="/usr/share/aws/ec2" export AWS_ELB_HOME="/usr/share/aws/elb" export AWS_AUTO_SCALING_HOME="/usr/share/aws/as" export AWS_CLOUDWATCH_HOME="/usr/share/aws/mon" export AWS_CREDENTIAL_FILE="/etc/aws/credential.conf" export EC2_REGION="us-east-1" export EC2_URL="https://ec2.us-east-1.amazonaws.com" export EC2_CERT="/etc/aws/cert.pem" export EC2_PRIVATE_KEY="/etc/aws/pk.pem" export PATH="$PATH:/usr/share/aws/ec2/bin:/usr/share/aws/elb/bin:/usr/share/aws/as/bin:/usr/share/aws/mon/bin:/usr/share/aws/iam/bin" Ajústalas de acuerdo a tu entorno. Agregar los grupos Una ves que instalaste todas las herramientas y tienes todo listo para iniciar, necesitas crear los siguientes elementos: 1. Crear una configuración de inicio. Esta configuracion va a iniciar tu instancia con un patron de comandos. Yo te recomiendo que la instruyas para ejecutar los comandos desde tu NAS compartido para que los comandos esten actualizados: as-create-launch-config lc1 --image-id <ami-########> --instance-type t1.micro --user-data '#!/bin/sh mount -a; source /var/www/scripts/instance-launch.sh' Tienes que reemplazar el <ami-########> por el id de tu ami. Claro que necesitas crear primero el archivo script de instance-launch.sh. Al principio puedes dejarlo vacio y conforme necesites comandos puedes ir agregándolos. 2. Agregas tu ELB (Elastic Load Balancer). Necesitas agregarle algunos datos por ejemplo el health-check yo te recomiendo que uses /health-check.php y coincida con el health-check.php que usara Varnish (si lo tienes instalado) para que no tengas el mismo chequeo 2 veces. Recuerda tener al menos un archivo health-check.php que regrese un 200 OK status en operación normal y un 500 en error. Yo te recomiendo que uses mi script php para checar el load average del sistema operativo y determinar si esta en un estado operacional: http://snipt.org/uRfg3 Para que este script funcione necesitas instalar gawk y bc: apt-get install gawk bc Una ves que agregues tu Load Balancer necesitas agregar tu instancia "Master" y usar el DNS Name para cambiar el CNAME de *.tudominio.com. Esto se hace para que tu CNAME apunte al ELB en ves de la instancia directamente y pueda soportar balanceo de carga. 3. Agregas un AutoScaling group. Esto te permitira determinar en que zonas se iniciaran las instancias, cuantas en load balancer donde se iniciaran. as-create-auto-scaling-group asg1 --availability-zones us-east-1a,us-east-1b,us-east-1c,us-east-1d,us-east-1e --launch-configuration lc1 --max-size 20 --min-size 1 --default-cooldown 5 --load-balancers lb1 4. Estableces un Scaling Policy. Esto te permite determinar el cambio en la capacidad de instancias que despues accionaras con CloudWatch: as-put-scaling-policy scale-up --auto-scaling-group asg1 --type ChangeInCapacity --adjustment=1 as-put-scaling-policy scale-down --auto-scaling-group asg1 --type ChangeInCapacity --adjustment=-1 Anota el resultado de estos 2 comandos para el siguiente comando. 5. Creas 2 alarmas de CloudWatch para determinar en que circunstancias vas aumentar o disminuir instancias dado tu grupo de escalado: mon-put-metric-alarm --alarm-name instances-high-load --alarm-description "Instances CPU go 90% for 5 minutes" --metric-name CPUUtilization --namespace AWS/EC2 --statistic Average --period 300 --threshold 90 --comparison-operator GreaterThanThreshold --dimensions AutoScalingGroupName=asg1 --evaluation-periods 1 --unit Percent --alarm-actions <resultado-del-comando-scale-up> mon-put-metric-alarm --alarm-name instances-high-load --alarm-description "Instances CPU go down 30% for 5 minutes" --metric-name CPUUtilization --namespace AWS/EC2 --statistic Average --period 300 --threshold 30 --comparison-operator LessThanThreshold --dimensions AutoScalingGroupName=asg1 --evaluation-periods 1 --unit Percent --alarm-actions <resultado-del-comando-scale-down> Y listo!!! Ya esta todo listo para aumentar o disminuir dependiendo del trafico que tengas. Claro que hay un asunto: Esto va a iniciar una instancia automáticamente ya que pusiste el mínimo de instancias en 1. Yo aqui te recomiendo que juegues con estos valores, ponlo en 0 para que no tenga una instancia cargada siempre, y agrega otra alarma a tu instancia para mandarte un correo en caso de que el CPUUtilization sea mayor a 90% y así puedes tener todo listo para auto scaling incluso sin pagar un centavo en el free tier. Si empiezas a tener carga considerable, puedes habilitar de nuevo el autoscaling, y sacar tu servidor principal del Load Balancer. Para esto solo necesitas ejecutar: as-update-auto-scaling-group asg1 --min-size 0 --desired-capacity=0 Para desactivarlo y as-update-auto-scaling-group asg1 --min-size 1 --desired-capacity=1 Para activarlo con un mínimo de 1 instancia. Escalar la Base de Datos Escalar la base de datos es posible usando Cluster DB, pero esto trae una serie de problemas que hacen inestable la solucion. Mi recomendación es iniciar una instancia de Amazon RDS, y una o 2 Read Replicas para poder distribuir las lecturas y escrituras si tu aplicacion te permite configurar de esta manera. Otra cosa que puedes hacer es instalar MySQL Proxy en tu instancia principal y con esto balancear el trafico usando RDS con Read Replicas, y así no necesitas cambiar tus aplicaciones PHP en caso de que sea muy complicado: http://forge.mysql.com/wiki/MySQL_Proxy DynamoDB (NoSQL) Otra cosa que puedes hacer es trabajar en tus modelos de datos para utilizar DynamoDB, que es una base de datos tipo NoSQL basada en SimpleDB que te permite escalar los recursos ya que usa un manejo mucho más eficiente de los datos. Esta solucion es costosa y necesitas conocimientos sobre NoSQL para poder actualizar el acceso a la base de datos. Actualmente no esta soportata por los CMS más populares como Wordpress. Escalar Memcached Por el momento no hay forma de distribuir Memcached. Puedes optar por tener memcached instalado en una instancia central con suficiente memoria, digamos una m1.large. No tiene caso instalar memcached en cada instancia ya que cada instancia con memcached almacenara aproximadamente la misma información que bien pudiera estar compartida. Otra opción por la que puedes optar es iniciar una instancia ElastiCache que es a fin de cuentas un servidor memcached optimizado. Aqui puedes centralizar el cache y así obtener la mejor utilización del cache. Respaldos Incrementales El respaldo incremental es un respaldo que se realiza completo una sola vez (llamado de nivel 0) y después solo se almacenan los incrementos desde el nivel 0 al nivel 1, luego del nivel 1 al 2, y así sucesivamente. El problema de los respaldos siempre es la latencia (tiempo de ejecucion) que tarda en realizarse; principalmente el de la base de datos. Es por esto que te daré un tip para que puedas hacer los respaldos usando mysqlhotcopy que hace copias de los archivos directamente. Respaldo de Archivos Lo primero que necesitas es respaldar los archivos de tu proyecto o sitio. Esto se hace de muchas maneras. Mi manera preferida es usando un "tarball". TAR es una aplicación que te permite hacer respaldos en incrementos y mantener los archivos en pequeños documentos .tar.gz incrementales. Para esto utilizamos un script que se debe ejecutar cada determinado tiempo. Una estrategia de almacenamiento que utilizo es utilizar un bucket de s3 privado. Este bucket te permitirá mantener los respaldos en en s3, por si tienes un problema con tu instancia o tu volumen, tus copias siguen seguras y redundantes dentro de la infraestructura de Amazon S3: Agrega un directorio vacio para tus backups: mkdir /var/backups/www Agrega la entrada del mount en tu fstab: echo "s3fs#<bucket> /var/backups/www fuse nodev,nosuid 0 0" >>/etc/fstab Donde <bucket> es el nombre de tu bucket de respaldo. Ahora solo necesitas crear una estructura de directorios. Aqui yo te recomiendo que uses un respaldo completo por mes, y un respaldo incremental al día. Ahí almacenarás el respaldo nivel 0 así como los incrementales. http://snipt.org/uRfh9 Este script hace respaldos incrementales continuos a partir del nivel 0. Preserva todos los permisos, y checa si solo son carpetas vacias para eliminar el respaldo cuando no hay cambios. Para cambiar la longevidad del respaldo nivel 0 solo necesitas modificar la ruta y agregar, por ej, la semana a la ruta, y los respaldos nivel 0 se haran por semana. Para hacer los incrementos diarios solo tienes que ejecutarlo 1 ves por dia. Este script casi no afecta el rendimiento, pero puedes ejecutarlo usando "nice" para evitar que aftecte los demás servicios: crontab -e 0 8 * * * echo "nice /var/www/scripts/backup" | batch 1>/dev/null Base de Datos Así mismo, necesitas respaldar la base de datos. Para esto puedes usar xdelta. Xdelta es una aplicacion gratuita que hace diferencias incrementales entre archivos binarios. Por lo tanto puede ser usado de manera segura para tomar diferencias entre dumps y/o archivos gzip y guardarlas como incrementos: http://snipt.org/uRfi2 Este tipo de respaldo use mysqldump. La ventaja de esto es que puedes ver claramente las sentencias que vas a importar, y es mas portable que los archivos MYD, pero tiene una latencia que en veces causa que las bases de datos se paralicen. El siguiente snippet es un script en bash que utiliza mysqlhotcopy el cual tiene mucho menos latencia que mysqldump y se realiza más rápidamente: http://snipt.org/uRga9 Ahora solo hay que ponerlo en el crontab y listo! respaldos incrementales. crontab -e 0 8 * * * echo "nice /var/www/scripts/db-backup <db>" | batch 1>/dev/null Remplazando <db> por el nombre de la base de datos. Con esto termina mi primer post. Si tienes dudas o sugerencias para mi tutorial favor de comentarlas. Acerca de Jorge Antonio Muñoz Valle. Desarrollador Web Ingeniero en Sistemas de Información

Hice esta guía espero les sirva: http://www.lecciones-web.com/2012/05/guia-tu-sitio-web-basado-en-cloud.html INTRODUCCIÓN Si necesitas alojamiento para un sitio web, tienes ciertos conocimientos de administración de servidores y quieres empezar de la dirección correcta con las herramientas de última tecnología éste post es para ti. Es un resumen de lecciones aprendidas utilizando los servicios en nube de Amazon AWS para iniciar con un servicio web. ... Leer más