El otro día (en enero), tuve que hacer una migración porque los del datacenter iban a mover cosas. Así que me puse muy nervioso porque las migraciones tienen varios puntos a tener en cuenta, sobretodo si los DNS de varios dominios están involucrados o afectados.

El tema radicaba que realmente iban a darme un servidor nuevo y está localizado en Dusseldorf, cuando el anterior estaba en Munich (mera información adicional que tanto da). Con el mismo precio mensual, me daban una máquina con 8 procesadores, 16 GB de RAM y 4 discos de 1 TB configurados en RAID 5 por hardware, dándome un total de 2’7 TB útiles.
El tema radicaba en cómo mover los datos y que fuera una réplica exacta. Haciendo un poco de búsqueda por google, me encontré con los de 619Cloud que tenían un pequeño script comentado en este artículo. Aunque el script pone que es para CentOS, yo lo probé con Debian tras revisarlo concienzudamente y funciona… pero tiene un par de peros.

Primero:
El script está preparado para migrar máquinas virtuales, esto es que la máquina virtual tiene un hardware común y es una imagen exacta tanto la máquina en producción a migrar como la base sobre la que va a ir destinada. Aquí el único problema son los binarios.
Mientras que la máquina que iba a migrar tenía base 386, la nueva iba a ser x64 (cosa que NO tuve en cuenta). Al final la máquina funciona perfectamente, pero no puedo cambiar la arquitectura y, pese a que la instalación fue una Debian x64, se copiaron los binarios de 386… suerte que no copié la config de arranque del kernel.

Segundo:
Como herramienta principal, se usa RSYNC. Esto tiene varios inconvenientes: el ancho de banda usado será casi todo el disponible mientras ambas máquinas estén más o menos libres de carga (cosa que casi nunca pasa en un server en producción). Por otro lado, generalmente la máquina encargada de hacer los hashes de los ficheros será la de producción. Entre esto y que las transferencias no están maximizadas, se viene a usar 1/3 del ancho de banda disponible. Esto no sería problema si no tuviera montada una partición con datos muy tochos que podría haber desmontado primero y transferido por FTP (más rápido) después. Conclusión: la máquina estuvo 2 días sincronizando. Solución: paciencia y unos cafés.

Tercero:
Otro pequeño problemilla del RSYNC es que para hacer la lista de ficheros a transferir usa el mismo algoritmo que un ‘ls -l’, dando como resultado la ordenación de directorios por orden alfabético. Al hacer eso, hay mil librerias que se copian antes o después de los binarios que las van a ejecutar. Mientras la máquina de destino no se caiga o se corte la transferencia por lo que sea, el procedimiento seguirá su cauce como toca… pero la máquina de destino se comportará de manera errática (no se puede hacer login durante X horas porque los binarios de bash no encuentran su libreria, algunas cuentas de usuarios no aparecen, etc). La solución es la misma que en el apartado 2: paciencia hasta que termine.

Cuarto:
Hay que ir con cuidado a la hora de copiar la config del lilo y del grub, que NO hay que copiarlos. Ya he puesto algunas modificaciones en el script que lo que hacen es saltarse el lilo, la config del lilo, el grub y la config del grub. Así, por mucho que los binarios no sean los mismos, al menos tendrás un punto de arranque.
Aparte de eso hay varios ficheros de configuración que no se deben copiar (casi todo el /etc es útil): el hostname (para no liarse) y la configuración de red son los principales a NO copiar. Ello implica que el resolv.conf tampoco es válido (en realidad sí que es válido, pero más vale dejar el nuevo); otros dos ficheros que no hacen falta son el /etc/mtab y el /etc/fstab.

Como nota, aquí teneis el fichero original y el fichero modificado para migrar con las configuraciones necesarias.

NOTA: me queda pendiente reprogramar el fichero para que en realidad haga una lista de paquetes instalados, la transfiera a la máquina de destino y se instalen los programas en dicha máquina nueva antes de copiar nada, saltándose los directorios binarios y demás. Si alguien tiene ideas, que ponga comentarios.

Este es un post técnico que complementa al de cómo implementé el tema de NginX + PHP en FastCGI.

Desde siempre, dados varios bugs conocidos de php en cgi que, según la versión, hacían que los sockets fueran más o menos estables tenía un proceso en el cron del sistema que me reiniciaba el php (los sockets realmente) cada día a las 6:15 de la mañana.

A veces, cada X semanas, el php se quedaba colgado y lo reiniciábamos manualmente. NOTA: no es que el php se quedaba colgado, el tema radica en que el socket de escucha se quedaba tonto sin responder, los procesos de php seguían ejecutándose esperando cargas y peticiones (en estado suspendido). La solución al reiniciar, era que matando los procesos y rearrancando esa parte, el socket se creaba de nuevo y volvía a la normalidad.

Esto no se trata en casi ninguna web, exceptuando una: En el blog de Taragana.

Tras varios meses así, decidí implementar una mejor solución. Encontré una versión mejorada para Ubuntu (aunque yo uso Debian) de un script de arranque usando demonios. Tras esto, mejoraba 2 cosas: era más consistente el arranque (al poderlo poner en el arranque del sistema sin problemas) y se cargaba la configuración de php con más megas de RAM asignados (de la otra manera lo que pasaba era que se arrancaba el php en fcgi con valores por defecto (aunque le pasara por parámetro el fichero php.ini).

Estos scripts básicamente son dos: /etc/default/php-fastcgi (fichero de configuración) y el script de arranque.

Este cambio lo realicé a principios de enero y durante 2 semanas no dió ningún problema, tuve que comentar la linea de reinicio del cron porque no era necesario.

Pero tras eso, por alguna actualización o algo, la cosa fallaba como una escopeta de feria. Volví a poner el reinicio cada 2 días, pero ni eso… lo volví a poner a un día. Pero no bastaba…

La solución por probar era compilar el php-fm, pero se me antojaba demasiado complicado para dejar el sistema tal como lo tengo ahora, así que decidí investigar.

Primero pensé en ver si había alguna otra implementación de sockets que recibiera peticiones y pudiera ejecutar lo recibido usando el cliente normal de php de bash. Miré si había alguna manera de crear sockets desde 0 con php para este fin, pero no había nada sin tener que sumirme en decenas de varios de documentos de programación en C sin tener mucho tiempo.

Tras buscar, llegué hasta un blog que hablaba del tema. El auto se había programado un script en python que, básicamente, escaneaba por errores en el log del NginX cada 2 segundos sin impacto en el sistema. El que aquí os pongo simplemente tiene comentadas las lineas para enviar correo, dado que pasaba mal algunos parámetros al sendmail y se colgaba.

Básicamente, lo que hace es:

• Se ejecuta y se ‘demoniza’, así que se queda en el sistema.
• Escanea el /var/log/nginx/error.log cada 2 segundos, usando algo como tail -f.
• Si se encuentra en el log las cadenas “104: Connection reset by peer” o “111: Connection refused”,
  • Ejecuta un killall -9 php5-cgi (el binario se puede configurar)
  • Ejecuta el script de arranque /etc/init.d/php-fastcgi start

Al usar el tail -f, se usa muy poca memoria y permite estar tranquilo… como mucho hay un downtime de varios segundos. Luego se arranca como si no hubiera pasado nada.

Para evitar que algo reviente el phpmonitor.py, he creado un script en bash ejecutado cada minuto via cron que simplemente mira si se está ejecutando el monitor. Si se ejecuta, sale; si no, lo ejecuta. La doble seguridad o doble chequeo es necesario.

Cosas a mejorar:

• En el script de python, podríamos usar el propio script de arranque para parar los procesos en lugar de hacer un kill directamente; o usar un simple restart…
• Aplicar una parte de la solución de Taragana: crear pools para cada aplicación, así no siempre se quedaría todo parado. Aunque eso implicaría modificar el script de python para discriminar entre dominios/aplicaciones y no reiniciar lo que no toca

Alguien tuvo acceso a muchos datos referentes al precio de transmitir datos en Internet en los últimos 10 años. Es increible observar la tendencia general del declive del precio, sobretodo en la última década. Y esas tarifas solo hacen referencia a lo que las empresas pagaban, pero no incluye la depreciación general.

En 1998, el precio medio pagado por los distribuidores de contenido para transmitir video a Internet era de 15 céntimos de dólar por megabyte transmitido. Repetimos, por transmisión; eso no incluye el precio del hosting donde tener el archivo etc. Para entonces, las cosas no se medían en GB o TB, dado que nadie transmitía tanto, y la media del video transmitido era a un ancho de banda de 37Kbps. Si avanzamos hasta el presente, tenemos que empresas como Netflix codifican y transmiten contenido a un bitrate 90 veces más grande que en 1998.

Para ponernos definitivamente en el tema, y para que todo el mundo lo entienda, a día de hoy Netflix paga 5 céntimos de dólar para transmitir TODA una peli por Internet. Si Netflix existiera en 1998, y a la misma calidad que hoy, le costaría la friolera de 270 dólares por peli. Por supuesto, en 1998 nadie tenía conexión de 3 Mbps, incluso si solo se codificara los videos a 37Kbps, ello le saldría entre 2’40 y 4’80 dólares por una sola peli. Todo esto os sirve para daros una idea de cuan lejos ha llegado la validad del video en internet, hábitos de consumo y tarifas a grandes rasgos de los últimos 10 años.
Pero incluso con esa bajada de precios tan sorprendente, las compañías siguen haciendo números para conseguir dinero con el tema del video de online.

Texto original aquí.

Hacía tiempo que veía una cosa extraña en la instalación del servidor: se actualizaba todo menos el paquete principal de las webs, el NginX (servidor de alto rendimiento).

Tras buscar un poco, me percaté de este hilo en los foros de Ubuntu que realmente, en ubuntu/debian no se actualizaba dicho paquete desde la versión 0.6.35 (y eso que nosotros usamos testing).

En la web, esa versión ya aparece como legacy (en plan funcionó pero está obsoleta), siendo la versión de desarrollo la 0.8.4 y la estable la 0.7.61

La verdad es que no sé por qué no se ha ido actualizando, pero veo que no es cosa nuestra, pues este programejo ya ha pasado a lighttpd en cuestión de sitios que lo tienen instalado.

Como está en inglés, ahí va la receta para actualizar desde debian/ubuntu con apt:

1. Verificar que no tengais nada referente al nginx en el /etc/apt/preferences
2. Para instalar desde 0, primero instalad la versión que os ofrece vuestra versión, desde los repositorios oficiales
3. Modificad vuestro /etc/apt/sources.list para añadir esto:
   deb http://apt.avuc.nl lenny stable
   deb-src http://apt.avuc.nl lenny stable
4. ‘Upgradeais’
5. Como el que nos provee estos paquetes es una persona diferente, compiló con otras opciones; pero solo hay que hacer:
   ln -s /usr/local/nginx/sbin/nginx /usr/sbin/nginx
6. Reiniciar el nginx con vuestro script de toda la vida ( /etc/init.d/nginx)

Tras esto, ya tenemos nuestro nginx listo en la última versión.

La persona del post del foro se ha ofrecido voluntario a ir compilando las versiones estables y ponerlas en el mismo repositorio.

Actualización: se me había olvidado mencionar que, buscando cosas del nginx, me topé con este convertidor de reglas htaccess a nginx.

]]> http://www.arlay.net/2009/07/03/actualizando-el-nginx/feed/ 2 http://www.arlay.net/2009/03/20/10-maneras-de-hacer-copia-de-tu-mysql-metodo-5/?utm_source=rss&utm_medium=rss&utm_campaign=10-maneras-de-hacer-copia-de-tu-mysql-metodo-5 http://www.arlay.net/2009/03/20/10-maneras-de-hacer-copia-de-tu-mysql-metodo-5/#comments Fri, 20 Mar 2009 07:42:32 +0000 Relay http://www.arlay.net/?p=648 5. Pasar tu base de datos a un fichero XML con PHP

Aunque eso simplemente es una manera burda de hacer la lectura más comprensible, la verdad es que si la base de datos es muy grande, la lectura posterior para integrarla de nuevo en un motor MySQL será más rápida por la estructura de árbol que adopta el fichero XML final.

Podeis leer el código en la web de David Walsh.

Anterior método -

4. Directamente con mysqldump a saco

En los anteriores métodos ya se ha usado mysqldump, una utilidad que viene con el mysql en cualquier sistema. Aparte de combinarlo, dicho mysqldump ofrece opciones variadas que, con varios ejemplos, repasaremos para ver como hacer los backups a tu manera.

De la manera más sencilla, el comando se ejecuta con el siguiente esquema:

mysqldump ---user [nombre de usuario] ---password=[contraseña] [base de datos a copiar] > [fichero de salida]

No creo que haya mucho que explicar al respecto.

Como opción extra, se puede usar el argumento -opt:

mysqldump --opt basededatos > sql.dump

Especificando el argumento --opt, en teoría, estamos haciendo un volcado preparado para ser luego introducido en otro MySQL. Aunque suene raro, la explicación es sencilla: con dicho argumento, el mysqldump crea un volcado má´s sofisticado, incluyendo sentencias como “DROP TABLE IF EXISTS” entre otras. Así, no habrá problema en recuperar una copia del día anterior si ha habido algún destrozo interno o alguna salvajada en el mismo servidor. Además, se meten sentencias de bloqueo, para evitar problemas de concurrencia a la hora de que los datos se vuelquen tanto fuera como dentro de otro MySQL.

Volcando de un servidor a otro ‘on-the-fly’:

mysqldump --host=host1 --opt basededatos | mysql --host=host2 --C nuevabase

Usando las tuberías en unix/linux (pipes), se puede hacer una pequeña virguería como la descrita. Podemos pasar el argumento host (que contendrá la IP o el nombre de la máquina) para, a la vez que volcamos con mysqldump, aceptarlo e integrarlo en otro servidor con el cliente de consola de mysql. Nótese el argumento –opt de la primera parte, y el –C de la segunda, donde se especifica que se compriman los datos que viajen.

El único inconveniente es que la nuevabase debe estar creada en el host2 antes de ejecutar el comando. Ambos servidores deben permitir conexiones desde fuera si se lanza este comando desde otra máquina remota que no sea ni el host1 ni el 2.

La típica:

mysqldump ---user admin --password=password basededatos |  gzip > backup.gz

Esta es la típica opción que se usa en el 90% de los casos que conozco… un volcado, y comprimido usando gzip (se puede usar cualquier compresor de consola).

Como últimos argumentos a comentar, estan el –no-data y el –databases:

mysqldump --no-data --databases mydatabase1 mydatabase2 mydatabase3 > sql.dump

El primero simplemente especifica que no se vuelquen los datos, sino solo la estructura. El segundo, argumenta que le pasaremos varios nombres de diferentes bases de datos para volcar. No hay mucho más que os pueda servir.

Como restaurar lo que se ha volcado:

Esa era la pregunta que os deberíais estar haciendo, si es que no habeis restaurado un mysql nunca.

La solución pasa por invocar el cliente mysql a pelo pasándole como parámetros el nombre de la base de datos y el fichero sql que tengamos:

mysql mybasededatos < sql.dump

Via | SitePoint

Anterior método. – Siguiente método

Básicamente se trata de crear una tarea en el cron para que automatice la creación del backup (solo viable si el servidor de BDD es un linux).

15 2 * * * root mysqldump -u root -pPASSWORD –all-databases | gzip > /mnt/disk2/database_`data ‘ %m-%d-%Y’`.sql.gz

Aquí básicamente definimos el usuario root y su password para realizar una copia completa de todas las bases de datos que esté manejando mysql. Esto se puede reducir si cambiamos el usuario/contraseña y le especificamos la base/tabla a copiar. Lo concatenamos con gzip para que se comprima el sql y se le añade la fecha (pillada del sistema)

En caso de que el servidor no sea un Linux, se podrá crear una tarea programada (si es Windows) para realizar un simple mysqldump:

mysqldump -u root -p wordpress wp_posts > D:\wordpress_posts.sql

Lo anterior sería un ejemplo de volcado de la tabla de posts de un blog.

Via | Backup HowTo

Anterior método - Siguiente método

El método 1: Copiar automáticamente la base de datos a Amazon S3

Mucho usuarios hoy en día usan las capacidades de Amazon S3 para realizar las copias de mysql. Aquí tenemos un pequeño script que, aparte de realizar la copia, se encarga de subirlo a Amazon S3 (en django).

Cosas a cambiar antes de usar dicho script:

1) Hay que poner la libreria de Amazon S3 propia para python en el path del sistema (para que sea visible). Podeis bajar dicha libreria en este link: http://developer.amazonwebservices.com/connect/entry.jspa?externalID=134

2) Hay que mantener el script mysql_to_amazons3.py  en el mismo directorio que settings.py.

3) Definir las siguientes variables en el fichero settings.py

• MYSQL_DUMP_PATH=  “/usr/bin/mysqldump”

mysqldump es el comando con el que se hace la copia (se hace un volcado realmente) de la base de datos.Hay que darle todo el path al ejecutable.

• AWS_ACCESS_KEY_ID = ”

Esto es la clave para acceder a los servicios de Amazon. Esto se da tras darse de alta.

• AWS_SECRET_ACCESS_KEY = ”

La secret key (o password) que también da Amazon para poder acceder.

• BUCKET_NAME = ‘tempstore’

El nombre del contenedor donde guardar el fichero final de copia. Bucket es básicamente un contenedor (al pagar a Amazon S3 por el espacio ocupado, crear contenedores vendría a ser como crear directorios/carpetas).

• ARCHIVE_NAME = ” “

Nombre del fichero final que se va a guardar.

• Hay que cambiar las variables DATABASE_NAME , DATABASE_USER y DATABASE_PASSWORD
  para que contengan los valores de la base de datos a copiar, y el usuario y contraseña para poder hacer dicha copia.

Ejecutando el script:

1. Basta con ejecutar ‘python mysql_to_amazons3.py’ (sin comillas) para que se haga la copia y se suba a la cuenta de Amazon, con el nombre de fichero definido en el ‘contenedor’ designado.
2. El script deja una copia de la base de datos que se ha enviado en el directorio donde se encuentra dicho script.
3. El archivo contiene dos ficheros: _data.sql que contiene los datos, _struct.sql que contiene la estructura básica de la abse de datos. Esto se ha hecho intencionadamente, es una buena práctica.
4. Si se quiere hacer una tarea programada, lo mejor es usar crontab –e con el usuario que quiera lanzarlo para hacer la definicion.

¿Cual es el flujo de trabajo del script?

1.Usa subprocesos. Básicamente, usa la función Popen (pipe open) para ejecutar varios comandos (mysqldump -  -  – ).

2. Se lee la salida de estas tuberias para crear el fichero .tar.gz

3. Usa la API de Amazon S3 para subir el fichero.

Via | Uswaretech

Siguiente método.

Tras no tener que reiniciarlo pese a las actualizaciones semanales que le íbamos haciendo, en estos últimos días se ha colgado el servidor 2 veces en 76 horas.

Tras más de 170 días de uptime, con velocidades decentes y soportando cargas a punta pala sin inmutarse o despeinarse, una actualización con bug del kernel de linux hizo que la máquina se quedara sin conexión.

Una lástima, pues en los últimos 6 meses llevábamos como 5TB transmitidos hacia afuera y 600 GB de tráfico entrante.

El problema parece ser un bug que afecta a las tarjetas de red, no sé si a todas, pero sí a las Realtek que hace que la tarjeta empieze a desconectarse y volver a conectarse… y luego directamente el driver se cuelga, dejando sin red a la maquina en cuestión.

La máquina parece que sigue viva, pero sin conexión. En este caso, solo puedes mandar un ticket al datacenter para que lo reinicien o reiniciarlo tu en remoto si te dan la opción (un panel que te suele dar el dc).

Tras esto, me puse a investigar, y ví esto en el log:

Jan  3 12:34:13 NaRRa kernel: [41979.812779] NETDEV WATCHDOG: eth0:
transmit timed out
Jan  3 12:34:13 NaRRa kernel: [41979.812821] ————[ cut here
]————
Jan  3 12:34:13 NaRRa kernel: [41979.812849] WARNING: at
net/sched/sch_generic.c:222 dev_watchdog+0xa6/0xfb()
Jan  3 12:34:13 NaRRa kernel: [41979.812881] Modules linked in: ipv6
fuse loop snd_pcsp snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm
psmouse snd_timer i2c_
i801 iTCO_wdt snd soundcore serio_raw snd_page_alloc i2c_core
intel_agp evdev ext3 jbd mbcache raid10 ata_generic sg ehci_hcd
ide_pci_generic ide_core uhci_hc
d sr_mod cdrom sd_mod thermal_sys e1000e e1000 raid456 async_xor
async_memcpy async_tx xor raid1 raid0 multipath linear faulty md_mod
dm_zero dm_snapshot dm_r
ound_robin dm_mirror dm_log dm_emc dm_multipath dm_crypt dm_mod
crypto_blkcipher aic7xxx aic79xx scsi_transport_spi aacraid sata_vsc
sata_via sata_uli sata_sx
4 sata_svw sata_sis pata_sis sata_sil24 sata_sil sata_qstor
sata_promise sata_nv sata_mv raid_class ata_piix ahci libata dock
3w_xxxx 3w_9xxx scsi_mod
Jan  3 12:34:13 NaRRa kernel: [41979.813260] Pid: 0, comm: swapper Not
tainted 2.6.26-1-amd64 #1
Jan  3 12:34:13 NaRRa kernel: [41979.813287]
Jan  3 12:34:13 NaRRa kernel: [41979.813287] Call Trace:
Jan  3 12:34:13 NaRRa kernel: [41979.813325]  <IRQ>
[<ffffffff802349b8>] warn_on_slowpath+0×51/0x7a
Jan  3 12:34:13 NaRRa kernel: [41979.813366]  [<ffffffff802461b2>]
autoremove_wake_function+0×9/

Ahora parece que aguanta sin problemas

Rudy afirma que Psystar existe, y que no es ningún engaño. La razón por su aparente desaparición fue la desbordante demanda de ordenadores que tuvieron, que causó que la compañía que administraba sus pagos con tarjeta de crédito cerrara la cuenta por tener que procesar demasiadas terjetas. Además, dicha compañía les forzó a moverse a un sitio más grande para que pudieran producir sus OpenComputer a gran escala.

El presidente de Psystar también ha afirmado que no están escondiéndose de Apple, sino que sencillamente se han visto desbordados por la demanda. De hecho, asegura que muy pronto podrán volver a aceptar pedidos. Desde mi punto de vista personal, de momento no haría ningún movimiento hasta tener confirmaciones más fiables. Recordemos que la legalidad del OpenComputer con Mac OS X Leopard instalado es bastante dudosa.

Como dicen en Applesfera, yo ya dudo de mi anterior post sobre la empresa que iba a dar ordenadores compatibles con Mac OS X Leopard.

El problema, aparte de todo lo que he copiado (que me perdonen los de Applesfera), es que hay una claúsula básica en este sistema operativo que reza: Solo usar en máquinas Apple.

Es decir, solo puedes usarlo en ordenadores fabricados por Apple, nada de montarte tu clónico e instalar.

Soy más partidario de que Apple ponga su software en todos los ordenadores, sacando versiones específicas.

Aunque algunos crean que no ganarían pasta, yo sé más de uno que directamente compraría el sistema operativo.

Los números no engañan: vale que ganas 1000 euros en cada equipo que vendes, que le incluyes el sistema operativo (-120 euros aprox del total). Como vendes mucho hardware, en plan millones de ordenadores (tanto sobremesa como portatiles) en todo el mundo… generas muchísima pasta.

Ahora cambia tu punto de vista: añade a esa gente el resto del mundo que tiene windows/linux con PC’s que casi seguro que se pasarían a Mac OS X y tendrás el 99% del mercado. Teniendo tus millones de dólares por hard y sumándole otros tantos de venta de software.