Re: Sincronizar /var/www de tres servidores script en debian
El Wed, 1 Oct 2014 12:11:19 +0200
Maykel Franco <maykeldebian@gmail.com> escribió:
> El día 1 de octubre de 2014, 11:58, Juan José López
> <juanjolistascorreo@gmail.com> escribió:
> > El Wed, 1 Oct 2014 10:09:24 +0200
> > Maykel Franco <maykeldebian@gmail.com> escribió:
> >> El día 1 de octubre de 2014, 9:08, C. L. Martinez
> >> <carlopmart@gmail.com> escribió:
> >> > 2014-09-30 19:42 GMT+00:00 Maykel Franco
> >> > <maykeldebian@gmail.com>:
> >> >>
> >> >>
> >> >> Gracias por contestar. No me gustan los sistemas distribuidos o
> >> >> compartidos para este fin. Pierden peefoemance. Y
> >> >> concretamente /var/www necesito que se sirva rápido. Aparte de
> >> >> usar sistema de cache opcode como xcache y similares. Además
> >> >> necesitaría otra máquina en el caso de iscsi. Ocfs2 o gfs lo he
> >> >> usado para drbd activo/activo y sinceramente no me fio.
> >> >>
> >> >> Me gusta esta opción, lsyncd. No lo he probado nunca pero se
> >> >> ejecuta a nivel de demonio y se sincronizan solo los cambios.
> >> >>
> >> >> En /var/www se sincroniza todo menos los los, que con uníson los
> >> >> tenia excluidos. Solo sincronizaba el contenido estático, que no
> >> >> cambia.
> >> >>
> >> >> Voy a mirar el enlace que me has pasado.
> >> >>
> >> >> Gracias.
> >> >
> >> >
> >> > Uhmm .. No me imagino porque no te fias de DRBD o OCFS2 o GFS2.
> >> > Yo los llevo utilizando durante años en clusters de producción
> >> > (web, correo, BBDD, etc..) y van finos finos ... Y siempre es
> >> > mejor utilizar algo así que tirar de scripts, porque siempre
> >> > pueden fallar muchas cosas y no tienes la info actualizada en
> >> > tiempo real (otra cosa es que necesites que esté replicada en
> >> > tiempo real).
> >> >
> >> > De hecho aparte de esas opciones tienes otra más: GlusterFS.
> >> >
> >> > Yo me las miraría antes de implementar nada basado en
> >> > scripts ... Y si no terminan de convencerte tienes otra más:
> >> > DragonflyBSD+HAST o FreeBSD+HAST, otras pequeña maravillas :))
> >> >
> >> > Saludos.
> >> >
> >> >
> >> > --
> >> > To UNSUBSCRIBE, email to
> >> > debian-user-spanish-REQUEST@lists.debian.org with a subject of
> >> > "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> >> > Archive:
> >> > [🔎] CAEjQA5KwjMd-AFtvR9534ae3_dU0TXL2OvWA+YxBqaYhhVgKyQ@mail.gmail.com">https://lists.debian.org/[🔎] CAEjQA5KwjMd-AFtvR9534ae3_dU0TXL2OvWA+YxBqaYhhVgKyQ@mail.gmail.com
> >> >
> >>
> >> Porque no necesito que los ficheros estén sincronizados en tiempo
> >> real, es un contenido estático, que se cambia de higos a ramos, y
> >> sólo necesito que se sincronice cuando se realiza un cambio en un
> >> fichero o una subida de producción... No veo necesario montar
> >> sistemas de archivos distribuidos.
> >>
> >> Si quisiera un samba activo/activo pues todavía. Que lo he montado
> >> en otra empresa, con drbd y cuando reiniciabas las máquinas eso
> >> era una lotería con el famoso split-brain. Además sino recuerdo
> >> mal, drbd sólo permite 2 servidores de replica, es un raid1 TCP/IP
> >> y un tercer servidor de backup.
> >>
> >> En el caso de ocfs de oracle, gfs2 de red hat, no lo sé imagion que
> >> soportarán ḿas de 2, al igual que glusterfs.
> >>
> >> Gracias por la respuesta.
> >>
> >> Saludos.
> >>
> >>
> >
> > Prueba con incron. Es el que yo utilizo para sincronizar archivos
> > entre varios chroots.
> >
> > Cada vez que un archivo MODIFICADO se cierra, te permite ejecutar un
> > comando. Dependiendo de como lo tengas montado, puedes hacer rsync,
> > scp, un simple cp, ... puedes montarte un mini-script que lo copie
> > y te avise por correo ...
> >
> > No es en tiempo real, pero casi. Ejecuta DESPUÉS DE CERRAR EL
> > ARCHIVO MODIFICADO, así que no usa ancho de banda durante las
> > modificaciones en sí. Y no depende de programaciones temporales,
> > por lo que la sincronización es casi perfecta.
> >
> >
> > --
> > To UNSUBSCRIBE, email to
> > debian-user-spanish-REQUEST@lists.debian.org with a subject of
> > "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> > Archive:
> > [🔎] 20141001115824.54aaf5d6@danika.localdomain">https://lists.debian.org/[🔎] 20141001115824.54aaf5d6@danika.localdomain
> >
>
> Que bueno... Muchas gracias, a probar se a dicho!!
>
> Gracias nuevamente a todos, un placer esta lista lo que se aprende.
>
> Saludos.
>
>
Nota aclaratoria:
Su propia funcionalidad es su mayor inconveniente. Se limita a ejecutar
órdenes al realizar ciertas acciones con los archivos; no 'sincroniza'
nada.
En otras palabras; si los archivos no son ya idénticos, incrond no
ejecutará la orden correspondiente hasta que no ocurra algún evento de
los indicados. Si la orden falla por cualquier motivo, incrond no
volverá a hacer nada hasta que vuelva a ocurrir el evento lanzador.
Yo los sincronizo al iniciar el equipo, desde rc.local. Como son
chroots en el mismo equipo, un rsync me va de perlas. Si ya están
sincronizados, no molesta. Y, si no lo están, me aseguro de que
comiencen en un 'estado conocido', que dicen los que saben.
Manejo pocos archivos, y los tengo incluidos directamente. Si manejas
muchos, te recomendaria un script que lea directamente
desde /etc/incron.d/ y ejecute la orden.
Reply to: