Héctor Jaskolowski
Sysadmin
Colegio San Esteban
Bariloche
Sysadmin
Colegio San Esteban
Bariloche
viernes, 20 de noviembre de 2009
jueves, 15 de octubre de 2009
Consideraciones para entender hosting + Ancho de banda + disponibilidad
Subiéndome a la nube, capítulo uno
Este mes mi proveedor de housing me aplicó un 150% de aumento al costo del servicio. Aparte me aplicarán topes al consumo del ancho de banda. Al tener mis equipos en ese data center desde hace 8 años esperaba que un reajuste de tarifas no sería tan dramático nunca, pero yo soy muy ingenuo. Además el servicio cambiará para peor, aplicándose desde ahora topes en los consumos que antes no existían. Punto.Concidentemente, comencé hace un mes y días a estudiar cómo funciona a la estructura computacional de Amazon, conocida como Amazon Web Services (AWS). Digámosle "la nube".
Mi primer ejercicio fue tomar el servicio más sencillo de implementar. Surgió que lo más sencillo era implementar S3 (Simple Storage Service) como sistema de almacenamiento de los archivos estáticos de Grippo.com - http://static.grippo.com. Me tomó simplemente una hora mover todos los archivos estáticos a la plataforma S3. Luego ví que Amazon tiene una CDN ó Content Delivery Network, que es un sistema como Akamai, que acerca esos archivos estáticos a los cachés de los proveedores de internet de los millones de usuarios de Internet a nivel global, tecnología que todos los sitios gigantes de Internet están obligados a utilizar. Ahora se me hizo disponible también a mí. Otra hora más y pude conectar el nombre del host en mi propio dominio http://static.grippo.com, con la CDN de Amazon, a la que llaman con el bonito nombre de CloudFront. El origen de los datos de CloudFront es el repositorio S3 que ya había creado anteriormente. Asique, en dos horas, tuve todos mis archivos estáticos (imágenes, style sheets, scripts JS, iconos), en la nube de Amazon y servidos a través de su CDN bajo mi propio nombre de dominio. Esto lo hice al finalizar mayo.
¿Cuánto cuesta utilizar S3 con CloudFront? Calcular por adelantado es un poco complejo a primera vista. Ahora que hace más de un mes, el sistema tarifario de Amazon produce mucha satisfacción como cliente, cosa que no siento con mi proveedor de housing local. Amazon cobra por varios items por separado: cantidad de storage utilizado, bando de ancha utilizado y cantidad de requests servidos. Mis cálculos preliminares fueron que gastaría unos 60 dólares por mes. Pero tenía dudas. Ahora que cerró el mes de junio, puedo mostrarles con gran satisfacción la primera liquidación de un mes completo de S3 más CloudFront de Grippo.com en Amazon:
De esta imagen sólo presten atención a los títulos Amazon Simple Storage Service que totaliza USD 0,16, o sea 16 centavos de dólar, y Amazon CloudFront por USD 48,80.
Tengan en cuenta que para los costos que yo estoy acostumbrado a pagar en Buenos Aires, esos precios son muy inferiores. Tengan también en cuenta, que la tecnología que me ofrece Amazon, con mis datos guardados en forma redundante, monitoreado por un ejército de ingenieros y distribuidos en su CDN, no está al alcance de muchos hoy en día en todo el mundo. Para los chicatos, les cuento: con 96GB de data transfer, y 33 millones de requests.
Conclusión: mejor subirse a la nube que quedarse en la tierra.
Próximo capítulo: cómo subo el application server a la nube y cómo se hace load balancing en la nube. Ah! Les adelanto el costo por server equivalente a Pentium 4 Dual Core, con 1,7GB RAM y 160GB disco fijo: USD 40 mensual. Hasta la próxima
A principios de este mes, publiqué el capítulo uno, donde mostraba lo sencillo que fue migrar todos los elementos estáticos a S3 + CloudFront, el competitivo costo mensual y el upgrade que significa en tecnología pasar a servir imégenes, css, js y demás, desde una content delivery network, archivando los elementos en una plataforma indestructible, quasi-eterna y 100% disponible.
Ahora bien, una cosa son elementos estáticos, y otra cosa son páginas dinámicas. Hoy les voy a mostrar cómo va la migración de la aplicación y el tipo de setup redundante que es posible / mandatorio hacer.
Esta es la consola AWS de Amazon:
Versión para chicatos. En este dashboard vemos que ya tengo 2 running instances. Cada instancia es un server completo, con 1.7GB RAM, procesador Opteron de 2007, 160GB en disco. Uno de esos servers es solo para MySQL. El otro es un worker con Apache 2 + mod_perl 2. El plan es agregar un segundo servidor MySQL que haga replicación. Y agregar un segundo apache para atender los requests HTTP, balanceados con un ELB, ó Elastic Load Balancer en la jerga de Amazon. Cada una de las instancias (recuerden, cada instancia es un server), tiene montado por nfs un volumen externo, donde los datos importantes de la aplicación, incluyendo las databases MySQL, existen en un dispositivo redundante y externo a las instancias, llamado Elastic Block Store o EBS. Esto es importante porque si la instancia se corrompe, nunca se recuperarían los datos almacenados en su propio hard disk, los datos sensibles deben almacenarse fuera de la instancia.
En resumen:
- frente a los usuarios solo está el load balancer, que es un servicio que pinguea cada 30 segundos cada apache para ver si está vivo y balancea la carga entre tantas instancias como le pongamos.
- detrás del load balancer hay n cantidad de instancias, cada una corriendo apache + mod_perl, en mi caso con dos instancias puedo servir mucho mas de mis 3 millones de uniques mensuales
- cada aplicación realiza inserts, updates y deletes en un servidor master MySQL (que corre en su propia instancia) y todos los selects van al slave (que por supuesto corre en una instancia separada), en total hasta aca tenemos 4 instancias corriendo
- todos los datos (templates, logs, bases de datos), existen en una unidad de storage externo (EBS)
- en mi repositorio S3 tengo imágenes del setup particular del OS de cada rol de servidor. En mi caso uso Debian. A cada imagen la llaman AMI (Amazon Image) y contiene una imagen binaria que aplicada a una instancia nueva, instala no solo el OS sino todas las decenas de paquetes y configuraciones específicas que se necesitan para asignarlo un rol al server. Asi tengo un AMI para servidor MySQL master, otro para servidor MySQL slave, y otro para servidor Apache + mod_perl. En caso de necesitar más apaches, simplemente lanzo una nueva instancia (launch instance), y le aplico el AMI correspondiente a apache con mod_perl. Todo el proceso implica dos clicks y esperar como 90 segundos en total. Al finalizar ese procedimiento, tengo un nuevo apache que puedo agregar al load balancer y en minutos puede estar sirviendo mas requests.
De la misma manera, si se corrompe la instancia que corre alguno de los servidores MySQL, puedo en minutos tener otro con identico setup. Como las tablas de las bases de datos se montan en el volumen externo "indestructible", lo que puede ser una verdadera catástrofe, puede pasar inadvertido si se usan otras herramientas de las que voy a hablar en el futuro, que combinan un monitor con el API de AWS, y que permite automatizar el lanzamiento de instancias nuevas en caso de necesidad.
Como yo vengo de hacer todo con el destornillador en la mano, esa mejora la dejo para más adelante, aunque es inevitable caer en automatizar todo al punto de por ejemplo, mantener dos apaches de lunes a viernes, pero sabados y domingos cuando la demanda baja, mantener solo un apache y pagar menos.
Bueno, ¿cuanto cuesta todo esto? Como dije en la nota anterior, mi interés en compartir esto es que aún habiendo conocido AWS hace años, siempre me pregunté efectivamente cuán viable era para un sitio como grippo.com. Pues bien, es mucho más viable que mantenerlo en un datacenter de clase mundial en Buenos Aires, eso se los puedo asegurar, porque mientras esté en el datacenter de clase mundial, sea en Buenos Aires, Los Angeles, Londres o donde sea, siempre llega el momento fatídico del downtime, como me pasó hoy mismo, o llega el momento que con destornillador en la mano tenemos que cambiar una fuente que dijo basta, o agregar mas pizzas al horno (sevidores en el gabinete).
Si bien falta un día o dos para cerrar el mes de julio, con aproximadamente USD 100, estoy cubriendo toda la operacion de storage S3 (22 centavos) + CloudFront (mi propia CDN para 30 y pico millones de requests por 38 dólares) + EC2 (Elastic Computing Cloud, 60 dolares más). EC2 incluye el uso de dos instancias por el momento. Estoy a punto de lanzar dos instancias nuevas, así para finales de agosto puedo mostrar el costo total de infraestructura de grippo.com. El desglose de EC2 es muy pormenorizado:
Para chicatos. El primer item que figura con USD500, es para reservar una instancia. Si la instancia no está reservada, pago USD 0,10 por hora. Eso es lo mejor para instancias lanzadas por demanda, digamos una aplicacion que tiene mucho trafico de 9 a 17 de lunes a viernes, en esos momentos usamos instancias sin reserva y pagamos 0,10 por hora. En mi caso, necesito una base de 4 instancias para mi setup, puedo reservar 4 instancias a USD500 cada una por tres años, y durante esos tres años, pago USD 0,03 por hora, el costo de cada server en este caso es de menos de USD 500 anual! Sí leíste bien, anual. Si no es reservado, pagás algo más de USD 700 anual, claro en el caso de que lo estes usando todo el tiempo, que no sería el caso jamás, porque en ese caso lo convertirías a reservado.
Luego tengo USD 32 por mil y tantas horas de instancias a 0,03. Esas son las dos instancias que ya tengo corriendo, una con MySQL, la otra con Apache.
Luego viene el costo por bandwidth. Debo aclarar que tengo migrados sitios pequeños, que en su conjunto pueden tener 5 mil usuarios por día, como por ejemplo da.com.ar, grippo.co.il, grippo.es, horoscopo.grippo.com. Asique el bandwidth me cuesta centavos. El bandwidth que va a consumir el mes que viene puede llegar a 50GB mas o menos, la espectativa de costo de este item no superaría los USD 10.
Luego viene EBS, que es el storage externo, attacheable a las instancias. Es decir donde se guardan todos mis datos sensibles, incluyendo las bases de datos y de la que puedo programar un backup instantáneo que se realice cada hora si quiero, y que se almacene en mi repositorio S3. Sólo por esto conviene pasarse a AWS. Sólo por EBS y Snapshots.
Luego vienen las EIPs, elastics IP, que si las uso, no me las cobran. Sólo me cobrarían USD 2 mensual si las reservo pero no las asigno a ninguna instancia.
Luego viene CloudWatch que es un monitor que permite automatizar las respuestas a la demanda, que hablaremos en un futuro cercano.
Luego viene el load balancer, que cuesta 18USD mensual. Como en mi setup los apaches pueden responder a todas las aplicaciones, uso solo un load balancer, y pongo detras tantos apaches como sean necesarios de acuerdo a la demanda.
Espero que no sea muy confuso esta vez, hay muchos conceptos aqui adentro, cada uno voy a tratar de explicarlos por separado, pero lo central aquí es que grippo.com siendo uno de los 10 sitios nacionales con mayor tráfico y difícilmente llegue a superar los USD 200 mensuales en agosto, migrando el 100% de los servicios a Amazon.
Dicho de otra manera: cualquier start up podría reservar USD 100 mensuales y tener un setup indestructible y escalable al nivel de google, yahoo o amazon. Quizás era un tema que podía incidir mucho más en el presupuesto mensual, pero ya no.
Dicho de otra manera: qué se puede hacer con USD200 en un datacenter en Argentina?
Dicho de otra manera: cuál es el presupuesto de servidores más conectividad de los otros 10 sitios nacionales de mayor tráfico? Creo que cada uno se podría optimizar.
En cualquier caso, aclaro que no soy socio comercial de Amazon, simplemente su AWS es genial, y yo tardé como 4 años en comprobarlo
COMENTARIOS EN EL BLOG DE ORIGEN
comentarios
lunes, 7 de septiembre de 2009
configurar UPS en Linux
El sistema de alimentacion ininterrumpida (UPS en ingles) permite que ante variaciones de energía o ante un corte total el linux box permanezca funcionando hasta que la energía regrese o se produzca un apagado programado antes que las baterias se agoten.
De por si, tener una UPS sin monitoreo es algo que no ayuda mucho si la interrupcion de energia se produce fuera de los horarios del administrador o no hay quien pueda hacer un apagado limpio del linux.
Con la salida al mercado de sistemas UPS con conexion USB (ahora la mayoría lo tiene) el control desde un linux es sumamente sencillo y depende de configurar adecuadamente el daemon apcups
Para eso tenemos que instalar el paquete apcupsd
En debian y derivados es tan sencillo como:
#apt-get install apcupsd
luego editamos
#vi /etc/apcupsd/apcupsd.conf
buscamos estas tres lineas y las modificamos para que queden asi:
UPSCABLE usb
UPSTYPE usb
DEVICE /dev/usb/hiddev[[0-15]]
iniciamos el demonio con
# /etc/init.d/apcupsd start
comprobamos que el monitoreo esta funcionando:
#apcaccess
APC : 001,044,1084
DATE : Mon Sep 07 11:25:57 ART 2009
HOSTNAME : fileserver
RELEASE : 3.14.4
VERSION : 3.14.4 (18 May 2008) debian
UPSNAME : fileserver
CABLE : USB Cable
MODEL : Back-UPS CS 500
UPSMODE : Stand Alone
STARTTIME: Mon Sep 07 11:25:55 ART 2009
STATUS : ONLINE
LINEV : 216.0 Volts
LOADPCT : 24.0 Percent Load Capacity
BCHARGE : 094.0 Percent
TIMELEFT : 36.0 Minutes
MBATTCHG : 5 Percent
MINTIMEL : 3 Minutes
MAXTIME : 0 Seconds
OUTPUTV : 230.0 Volts
SENSE : MediumSELFTEST : OK
si queremos realizar un autotest de la UPS, paramos el daemos
# /etc/init.d/apcupsd stop
y ejecutamos:
#apctest
2009-09-07 11:23:48 apctest 3.14.4 (18 May 2008) debian
Checking configuration ...
Attached to driver: usb
sharenet.type = DISABLE
cable.type = USB_CABLEYou are using a USB cable type, so I'm entering USB test mode
mode.type = USB_UPS
Setting up the port ...
Hello, this is the apcupsd Cable Test program.
This part of apctest is for testing USB UPSes.Getting UPS capabilities...SUCCESSPlease select the function you want to perform.1) Test kill UPS power
2) Perform self-test
3) Read last self-test result
4) Change battery date
5) View battery date
6) View manufacturing date
7) Set alarm behavior
8) Set sensitivity
9) Set low transfer voltage
10) Set high transfer voltage
11) Quit
El menu es bastante claro de cuales son las opciones de chequeo sobre la UPS.
Ahora, para probar la eficacia del monitoreo primero apagamos el servicio en el runlevel
#chkconfig apcupsd off
Antes de reiniciar el servicio editamos nuevamente apcupsd.conf
buscamos la linea
TIMEOUT 0
CAMBIAMOS 0 X 1
Y ahora si iniciamos de nuevo.
# /etc/init.d/apcupsd start
desconectamos la UPS de la linea 220V y esperamos que apcupsd nos informe que inicia el proceso de shutdown.
reiniciamos el servidor, volvemos a editar apcupsd.conf para dejar de nuevo la linea:
TIMEOUT 0
y activamos el inicio del servicio en el boot
#chkconfig apcupsd on
Una útima prueba para establecer el tiempo de las baterias es desconectar la UPS de la linea 220V y esperamos que apcupsd nos informe periodicamente cómo va disminuyendo el tiempo calculado de utilidad de las baterias hasta que cuando se agoten empiece el proceso de shutdown
jueves, 3 de septiembre de 2009
Backup Incremental con Rsync Simple y sencillo
En esta segunda parte voy a explicar cómo tengo espejado la información del servidor de archivos.
Los backup son dos, de los cuales uno (como expliqué en la primera parte) se comprime y divide en partes con DAR para volcarlos en dvds.
El primero esta archivado en una unidad NFS en un servidor remoto y el segundo esta en un disco local extra que se monta y desmonta al solo efecto de guardar el backup.
La base de los backups que realizo en distintos servidores es una simple linea en el crontab:
fileserver:~# crontab -l
# m h dom mon dow command
20 20 * * 1-5 rsync -aru --inplace /home/comercial/ /home/copia/comercial/
# m h dom mon dow command
20 20 * * 1-5 rsync -aru --inplace /home/comercial/ /home/copia/comercial/
10 20 * * 1-5 /root/rbackup.sh
la unica diferencia en el script del segundo es que tiene que montar y desmontar la unida de disco local.
En caso de perdida de información, restaurarla es tan sencillo como copiar del destino al origen en forma parcial o total.
Hice algo más avanzado con este backup en base al ejemplo de copias incrementales disponible en el sitio de samba team.
Y en definitiva terminó siendo un backup más además del que ya tenia, pero el beneficio que le encontré es que se puede restaurar la información en forma casi instantanea.
y este es el script con el que lo hago:
#!/bin/sh
# This script does personal backups to a rsync backup server. You will end up
# with a 7 day rotating incremental backup. The incrementals will go
# into subdirectories named after the day of the week, and the current
# full backup goes into a directory called "current"
# tridge@linuxcare.com
# with a 7 day rotating incremental backup. The incrementals will go
# into subdirectories named after the day of the week, and the current
# full backup goes into a directory called "current"
# tridge@linuxcare.com
# directory to backup
# BDIR=/home/academico
# directorio de copias incremental
BACKUPDIR=`date +%A`
BACKUPDIR=`date +%A`
export PATH=$PATH:/bin:/usr/bin:/usr/local/bin
# borrar la copia de 7 dias anterior
rmdir /academico/$BACKUPDIR
# now the actual transfer
rsync -aru --inplace --backup --backup-dir=/academico/`date +%A` /home/academico/ /academico/current
rsync -aru --inplace --backup --backup-dir=/academico/`date +%A` /home/academico/ /academico/current
restaurar Backup
en este caso depende a que estado anterior de la información queremos volver.
si la perdida es total, copiamos todo el contenido de /academico/current al lugar de origen
Si queremos regresar a algun dia anterior copiamos el contenido del día elegido (lunes, martes, etc)
en el directorio de origen
jueves, 2 de julio de 2009
¿Qué Significa SPAM?
el origen del término se remonta a 1937 y no esta relacionado a la informática, Internet o email.
El nombre fue sugerido por Kenneth Daigneau, un actor de hermano del vicepresidente de la Hormel. La versión oficial es que es una abreviación de "SPiced hAM". (El Spam es una variedad de carne en lata elaborada por la empresa Hormel Foods Corporation)
Muchos de los más graciosos retroacrónimos han sido imaginados sin justificación tal y como: "Squirrel, oPossum, And Mouse" ("Ardilla, Zarigüeya, y Ratón"), "Spare-Parts-Already-Minced" ("Partes Sobrantes Previamente Picadas"), "Something Posing As Meat" ("Algo Haciéndose Pasar Por Carne"), y "Specially Processed Artificial Meat." ("Carne Artificial Especialmente Elaborada")
En un famoso sketch de 1970 de la serie de televisión Monty Python's Flying Circus los comediantes británicos representaban a una pareja que se sentaba a la mesa en un restaurante y se les ofrecía "huevo y panceta; huevo, salchichas y panceta; huevo y spam; huevo, panceta, salchichas y spam; spam, panceta, salchichas y spam; spam, huevo, spam, spam, panceta y spam; salchichas, spam, spam, panceta, spam, tomate y spam, ..." y no conseguían ningún plato que no contenga spam. Mientras, un grupo de ruidosos vikingos cantaban a coro cada vez más fuerte "Spam, spam, spam, spam. ¡Rico spam! ¡Maravilloso spam! Spam, spa-a-a-a-a-am, spa-a-a-a-a-a-am, spam. ¡Rico spam! ¡Rico spam! ¡Rico spam! ¡Rico spam! ¡Rico spam! Spam, spam, spam, spam". Como la canción, el spam es una repetición sin fin de texto de muy poco valor o ninguno, que aplicado a los mensajes electrónicos, se refiere hoy en día a los mensajes enviados de forma masiva y dirigidos a personas que, en principio, no desean recibirlos.
referidos a la informática se encuentran otros acrónimos tales como:
Short Pointless Annoying Messages
Stupid Pointless Annoying Messages
Sending People Annoying Mail
Sending Persistently Annoying Mail
Self Promotional Advertising Messages
Silly Pointless Annoying Message
Senseless Pointless Annoying Message
unSolicited Pornography And Marketing
Someone's Poor Advertising Method
Some Pestilent Asshole's Message
Fuente:
lunes, 8 de junio de 2009
Sistema de Backup - Concepto y solucion
El backup es una copia de la informacion sensible de un sistema informatico disponible en otro medio para proteccion de la misma.
En un servidor en produccion normalmente es parte de la planificacion inicial del mismo, por lo que a la hora de tener datos generados los mismos ya estan protegidos. Esta planificacion tiene varios aspectos a considerar siendo algunos de ellos:
1- Programa o aplicacion con que se lleva adelante la tarea
2- Tratamiento que se le efectual a las copias
3- medios en los que se almacenan las copias
4- metodos de recuperacion de los datos
5- documentacion que explique el proceso
En un servidor GNU/Linux se encuentran disponibles varias herramientas para generar copias de seguridad, cada una con mayor o menor complejidad en su funcionamiento.
-Tar, empaqueta directorios y archivos
-rsync, sistema de copia y sincronizacion de samba team
-rdiff-backup, para backups diferenciales e incrementales
-otras soluciones completas como Amanda o Bacula
Debe considerarse si los datos se van a comprimir, encriptar, dividir en tamaño de acuerdo al soporte donde se almacenaran, comprobacion de integridad de datos, etc.
Las copias pueden ser guardadas en Cds, DVDs, en discos remotos, etc. Datos replicados sin compresion ni empaquetado en discos locales para su pronta restauracion.
De acuerdo al volumen del backup en ocaciones puede resultar engorroso encontrar el archivo/s a restaurar, a la vez que en una situacion de daño total en el servidor es muy importante tener en cuenta el metodo de restauracion que posee nuestro sistema de backup
finalmente cuanto mejor documentado este nuestro sistema de backup, menos problematico terminara siendo su administracion
En mi caso particular tengo un servidor de bases de datos y otro de archivos. Para hacer la copia de seguridad me arme un simple script que vuelca las bases de datos a un temporal y lo comprime.
Se rota durante siete dias y empieza a eliminar el mas antiguo
Este backup se copia a una unidad nfs remota, se divide en partes para guardarlo en DVDs regrabables y al a vez tambien queda guardado en otra unidad de disco rigido en el mismo servidor.
Como el dump de la base se realiza todos los dias, un backup incremental no estaria funcionando dado el cambio de fecha y tamaño (o no) de los archivos. Entonces estoy probando si la opcion de backup diferencial funciona bien y solo detecta los agregado de las bases y actualiza esos archivos.
Esto lo realizo con DAR con el que tambien genero controles de integridad de archivos y es posible que mas adelante implemente la encriptacion de las copias.
Para el caso del servidor de archivos, tengo una unidad de disco en el servidor que solo se monta al efecto de sincronizar los datos con rsync y en caso de caidas, solo tengo que montar esa unidad en lugar de la que esta en produccion. Si el daño es total se recupera de la unidad remota por nfs o se recurre a las copias en DVD. Lo demas funciona como el anterior, con el DAR hago copias diarias con eliminacion de las antiguas en un periodo de 7 dias. Para mas adelante voy a implementar copias completas cada 30 dias pero por el momento solo tengo una copia completa inicial.
Las copias estan automatizadas con el Cron y periodicamente hago chequeos manuales de integridad de datos. Esto podria hacerlo en forma automatica tambien, pero he preferido dedicarle un tiempo en persona ya que al mismo tiempo que monto la unidad de disco local para backup para copiarlo a DVD le paso el chequeo CRC.
Scrip de backup de bases:
#!/bin/bash
# Realiza el respaldo de la base de datos en localhost
FECHA=`date -I -d today`
USER="-u user"
CLAVE="-pclave"
MYSQL_DATABASES="OpenBiblio biblioteca geeklog libros webbiblio2 webbiblio3"
# Comprueba que existe el temporal
! test -d /tmp/bases && mkdir --parent /tmp/bases
# dump de bases al temporal
for base in $MYSQL_DATABASES
{
mysqldump --opt $USER $CLAVE $base > /tmp/bases/$base.sql
}
# genera el tarball en la unidad remota nfs
cd /tmp/bases
/bin/tar -zcvf /backup/databases.$FECHA.tgz *
# borra el temporal
rm -f /tmp/bases/*
# borra el backup 7 dias mas viejo
rm -f /backup/databases.`date -d "$FECHA 7 day ago" +%Y-%m-%d`.tgz
# monta la unidad de backup local
# Realiza el respaldo de la base de datos en localhost
FECHA=`date -I -d today`
USER="-u user"
CLAVE="-pclave"
MYSQL_DATABASES="OpenBiblio biblioteca geeklog libros webbiblio2 webbiblio3"
# Comprueba que existe el temporal
! test -d /tmp/bases && mkdir --parent /tmp/bases
# dump de bases al temporal
for base in $MYSQL_DATABASES
{
mysqldump --opt $USER $CLAVE $base > /tmp/bases/$base.sql
}
# genera el tarball en la unidad remota nfs
cd /tmp/bases
/bin/tar -zcvf /backup/databases.$FECHA.tgz *
# borra el temporal
rm -f /tmp/bases/*
# borra el backup 7 dias mas viejo
rm -f /backup/databases.`date -d "$FECHA 7 day ago" +%Y-%m-%d`.tgz
# monta la unidad de backup local
mount /dev/sda4 /mnt/backup
dar -c /mnt/backup/databases -R /backup -A /mnt/backup/databases1/completo.dar
umount /mnt/backup
Este script este editado a partir de otros varios que he visto dando vueltas en internet y he tomado lo que necesitaba para cumplir con mis necesidades. He colocado solo algunas variables y no le incorpore avisos, ni exit codes ni logs, etc. que son los adicionales que finalmente me hicieron decidir por armar algo que haga solamente lo que necesito.
Hay conceptos que corregir lo que ire descubriendo con el uso, como por ejemplo de que manera se maneja los diferenciales, no comprimir el tarbal sino enviar los archivos planos al DAR, etc.
En una segunda oportunidad les traere la guia de como restaurar archivos, directorios, restaurar parcial o totalmente.
Sysadmin
Colegio San Esteban
Bariloche
viernes, 22 de mayo de 2009
KNOPPIX - Entorno de programacion Visual y Animacion 3D
Hace un par de dias mi hijo de 14 años me pidio que le instale un entorno de
programacion y de animacion.
Consulte en la lista de linux en la que participo y de varias opciones las
que me parecieron mejor para que se inicie como autodidacta fue Gambas y
Blender
programacion y de animacion.
Consulte en la lista de linux en la que participo y de varias opciones las
que me parecieron mejor para que se inicie como autodidacta fue Gambas y
Blender
Para no complicar las cosas de instalacion, baje el nuevo Knoppix 6.0.1en
español que esta basado en Debian/Lenny:
http://www.knoppix-es.org/?q=node/2186
lo instale con la opcion "KNOPPIX HD install" que trae el motor "Own - .Zero
Work Needed"
Desinstale el openoffice que no va a ser usado e hice una limpieza de
librerias y dependencias:
# apt-get remove --purge openoffice*
# deborphan | xargs apt-get -y remove -P
# apt get autoremove
Instale primero el programa de animacion 3D
#apt-get install blender
Esta muy bueno porque los accesos en el menu de LXde se crean
automagicamente asi que no hay que estar haciendolo manualmente.
Instalar Gambas es bastante complejo si se lo quiere compilar desde los
sources ya que hay que instalar previamente las dependencias. Eso esta bien
explicado en este blog:
http://cafeinalibre.blogspot.com/2009/03/howto-como-instalar-gambas-2111-en.html
Pero mas sencillo aun es instalar los paquetes disponibles para debian,
explicado en la pagina de gambas:
http://gambasdoc.org/help/doc/package?view&en
agregar al /etc/apt/sources.list
deb http://apt.linex.org/linex/gambas/stable/ ./
bajar la llave publica GPG:
#gpg --keyserver wwwkeys.eu.pgp.net --recv-keys 9AA551D966A90DE2
Instalar la llave:
#gpg --armor --export 9AA551D966A90DE2 | apt-key add -
Actualizar:
# apt-get update
Instalar Gambas:
#apt-get install gambas2
Y ya queda listo nuestro linux para programar en el GUI visual de gambas y
diseñar animaciones 3D con Blender
Héctor Jaskolowski
Sysadmin
Colegio San Esteban
Bariloche
Suscribirse a:
Entradas (Atom)
Felicitaciones Jorge!!! Un post excelene, la verdad que no encontre mucha documentacion de AWS en español y sintetizado, me viene barbaro, vamos a empezar a probar. Un abrazo.
Que maravilla! Yo estoy usando Amazon para hospedar videos, y es excelente alternativa al server en el Datacenter!
Yo estoy usando S3 para servir los videos, cual es la diferencia entre usar eso o el CDN?
Saludos
Si pero el soporte ? por lo que veo te cobran y lindo si queres un soporte rapido ante eventuales emergencias. O no Jorge ?
Hola Dan, el CDN, que en Amazon se llama CloudFront, pone los contenidos que tenes en S3, más cerca de los usuarios, en cachés ubicados en los ISP de los usuarios. Un CDN muy conocido es Akamai. El setup de CloudFront en Amazon es muy sencillo:
1. Adherir al servicio
2. Especificar el bucket S3 de donde se van a servir archivos
3. Listo, si queres, por medio de un registro CNAME del archivo de zona de tu dominio, podes usar el CDN bajo tu propio dominio.
El costo es casi identico a usar solamente S3.
Hola Sebastián. muy buena pregunta. El soporte es de dos tipos: autoservicio, en cuyo caso vos sos tu propio soporte, o premium, cuyo costo está entre 100 y 400 dólares mensuales.
http://aws.amazon.com/premiumsupport/
Luego hay un nuevo tipo de proveedores de hosting, que te dan un servicio por sobre AWS, es decir subcontratando AWS y manejandolos ellos, unificando recursos, optimizando el soporte, donde hay cuentas desde USD 25 mensuales, con soporte incluido.
http://www.engineyard.com
La idea detras de empresas como esta es : "ocupate solo de tu negocio, nosotros nos ocupamos de lo que necesites de hosting, con soporte incluido"
Que tema este del Cloud Computing. Me sería mucho mas claro si tarifaran el bandwidth en mbps. Tengo unos proyectos personales que mueven mucho trafico (500.000 únicas diarias) y mi proveedor, que no es de Argentina, me factura con el método 95th percentile. (http://en.wikipedia.org/wiki/Burstable_billing). Estoy usando en los servidores de imágenes que son el 90% del consumo unos 70mbps. Me pregunto cuanto costará esto en números de AWS...
je, voy a tener que analizarlo para mis proyectos nuevos, hasta 5k visitas y 90Gb de trasnfer me bancan, ahora si llego a duplicar eso ya pinta para este tipo de servicios?
Hola Fabio. Con esta calculadora podés prever exactamente cuanto va a ser el costo de cualquier proyecto.
http://calculator.s3.amazonaws.com/calc5.html
Sin embargo, el costo no es la única variable.
Cristian, modestamente te digo, estas equivocado, la forma de facturarte de AWS es mejor. Con el "95th percentile billing method there is potential for paying for bandwidth that is not used". Con AWS, el modo de facturar es mucho más claro: pagas por lo que usás, no pagas por lo que no usás.
Deberías usar esta calculadora:
http://calculator.s3.amazonaws.com/calc5.html
Ingresar los datos que te pide: storage, data transfer in/out, y cantidad de requests, para saber con certeza cuanto deberías haber pagado en meses anteriores. Asi te das una idea de cuánto demás estás pagando ahora. Por favor, avisame como te fue en la comparación.
Qué opinión te merece el hosteo de los MySQL versus el uso de SimpleDB?
Qué tanto te complica el mantenimiento de estos máquinas para la BD, y qué tanto cuesta pasar todo a SimpleDB?
Hola Sebastián, no he tenido tiempo todavía de usar SimpleDB, nisiquiera de leer la documentación. Trabajé con BigTable en Google Application Server, y creo entender que esto es parecido. Es muy cómodo trabajar con SimpleDB porque no es SQL. No hay schemas que definir por anticipado. Cuando necesitas un tuple o columna nueva, la usas y alli estará. Todas las columnas se indexan, asique realizar queries contra SimpleDB siempre es eficiente. Por otra parte no hay problemas de escalabilidad, porque no hay límite practicamente en la cantidad de data que pueden almacenar. Pero como te dije no tengo experiencia directa con SimpleDB. El mantenimiento de la BD en Amazon se hace más flexible, en mi opinión. El hecho de poder montar un volumen externo, sobre el cual hacer snapshots (backup), mientras el volumen está montado y el SQL server está en servicio, es algo que en sí mismo es de un valor increíble. Decime si no es siempre complicado hacer backups de las tablas. Bueno en AWS es tan fácil como apretar un botón en el dashboard de EC2 o programar un cron job para que lo haga periódicamente utilizando el API. Todos los esquemas de redundancia documentados en MySQL, incluyendo por supuesto replicación en todas sus variantes, es muy sencillo, económicamente viable y tremendamente potente en AWS. La performance es algo que voy a experimentar en lo que queda de agosto, ya que como expliqué tengo sitios pequeños por el momento, y estoy por mover uno grande en estos días. Pero gente mucho más experimentada que yo lo viene usando desde hace años. Te recomiendo el blog de alestic.com para interiorizarte a fondo de MySQL sobre AWS. Son genios.
Muy buena la calculadora, la estuve utilizando y a simple vista no creo que sea conveniente para lo que hago. No dudo de los beneficios de la infraestructura pero económicamente no me es viable. Tomando como ejemplo 50mbps (siento el promedio 70 mas o menos) hice unos calculos y mi consumo mensual en el sistema de Amazon son 16200GB al mes. Usando la calculadora del link, solo de transferencia sin poner espacio en disco ni requests ya me da un total de $2500 dolares mensuales. Actualmente por un dual xeon con discos SAS estoy pagando u$s10 aprox cada 1mbps.
Cristian, el data transfer no es el resultado de explotar la tasa de tranferencia en el tiempo como vos lo calculaste. Es algo asi como la suma de los tamaños de todos los archivos transferidos en la línea. Pensalo asi, en tu casa está el agua corriente, las cañerías y la canilla. Contar con un caudal de agua X no hace que el consumo sea igual a mantener la canilla abierta todo el tiempo, no?
Te animaría a intentar nuevamente con la calculadora, con los datos correctos.
¿Podes decirnos cual es el costo mensual en dólares de tu server, sumando todos los conceptos?
Jorge, el calculo lo baje de 70mbps para hacerlo mas aproximado, por eso lo puse en 50mbps que es mas bajo que el promedio o 95th percentile consumido actualmente. Pensa que usando 10mbps sostenidos las 24 horas del día serian unos 3140gb al mes. En mi ejemplo multiplique esos 10mbps x 5 que es un numero del que no baja ni en la peor hora del día durante todo el mes.
Los request ni los puse por que me da panico, eso exactamente es cada acceso a un item alojado en el servidor? Por que cada html de las webs que te hablo tiene incrustadas unas 180 imagenes. Eso sumado a los css y demas objetos podrian ser unos 190 request por visita.
Actualmente pago unos u$150 al mes por el server de htmls/php/mysql en The Planet y en promedio u$500 por server de imagenes.
Jorge, el calculo lo baje de 70mbps para hacerlo mas aproximado, por eso lo puse en 50mbps que es mas bajo que el promedio o 95th percentile consumido actualmente. Pensa que usando 10mbps sostenidos las 24 horas del día serian unos 3140gb al mes. En mi ejemplo multiplique esos 10mbps x 5 que es un numero del que no baja ni en la peor hora del día durante todo el mes.
Los request ni los puse por que me da panico, eso exactamente es cada acceso a un item alojado en el servidor? Por que cada html de las webs que te hablo tiene incrustadas unas 180 imagenes. Eso sumado a los css y demas objetos podrian ser unos 190 request por visita.
Actualmente pago unos u$150 al mes por el server de htmls/php/mysql en The Planet y en promedio u$500 por server de imagenes.
Muchas gracias Cristian por tu valiosa participación.
Hola,
Muy bueno tu artículo, recién ahora entiendo en detalle el tema de "la nube". En general yo utilizo servidores dedicados en Argentina y USA, y en general administrados, ya que no somos especialistas en configuración de servidores, a este respecto una consulta:
Cuando haces referencia a las AMI (Amazon Image) ¿Amazon dispone de algunas configuraciones "listas para usar" o es necesario armar una propia?
Gracias desde ya!
Hola de nuevo,
Me contesto yo solo, veo que existen cientos de AMIs a disposición. Entonces la consulta sería:
¿Para alguien acostumbrado a usar servidores administrados, o con panel de control (cpanel, plesk o incluso webmin) es factible pasarse a Amazon si volverse loco?
Gracias!
No Nestor, definitivamente Amazon AWS es para alguien que tenga perfil de sysadmin, es decir que se sienta cómodo instalando base de datos, web servers, y demás. El valor de Amazon AWS no está por alli, aunque hay compañías como
http://www.engineyard.com
que ofrecen justamente lo que estás sugiriendo, operando sobre plataforma Amazon AWS. Ellos te dicen, despreocupate de la tecnología, ocupate de tus negocios, nosotros te cuidamos tus servers en Amazon.
Cristian, que yo sepa, en Theplanet podes obtener un server dedicado por unos 150 u$, con una interface de 100 mbps para tener picos de esa velocidad. Pero de ninguna manera se puede hacer la cuenta de que tener disponibles 100 mbps impliquen 30 teras de trafico en tus manos. Por eso tenes un limite de banda de 2 o 3 teras (o poquito mas por alguna promo). Sumado a que el consumo tipico de internet es mas bien una campana (que la marcan tus usuarios mas la estacionalidad de la conectividad de tu carrier) y no una recta, lo comun es que un web server (o una granja de ellos) con una interface de 10 mbps pueda servir como MAXIMO 1 (un) tera/mes. o si tenes 100 mbps, 10 teras.
Por ejemplo, uno de los 2 diarios mas grandes del pais tiene un trafico de 80 mbps en su pico, y te aseguro que no pagan 150 u$ por un server en theplanet.
Un terabyte en bruto transferido via amazon costaria si mal no hago las cuentas unos 170 u$. Nada mal. Corrijanme si me equivoco. Daniel.