El día 17 de enero de 2012 17:23, Joan Puiggali - Kopernix
<[email protected]> escribió:
>
>> Per a DB crec que va una mica com el cul... no l'he provat però he
>> llegit en molts llocs que va de pena...
>
> El hardware que se utilice para red. tiene mucho que decir en todo esto. De
> todos modos el caso de unos es almacenamiento masivo. con escalabilidad alta,
> el de otros centralizar discos, para levantar maquinas virtuales desde mas de
> una ubicación y en caso de fallo de estas poderlo levantar con facilidad de
> otra, al mismo tiempo pedir rendimiento...
>
> Vamos que para necesidades colores, no se puede comparar con otras soluciones
> como si comparáramos dos smartphones...

No era mi intención compararlo como si fueran smartphones, hablo según
lo experimentado. Es por todos sabido que el talón de aquiles de
GlusterFS son los ficheros pequeños. Tanto que en todos los lados
desaconsejan que los ficheros de los servidores web se residan en un
glustefs.

Es muy difícil conseguir una velocidad óptima de transferencia en un
entorno con todo tipo de archivos. Se pueden configurar muchos
parámetros, y probar con los FS sobre los que los volumenes de gluster
residen, así como el protocolo de red para transferirlos, pero toma
mucho tiempo dar con el setting adecuado.

En casa de clientes, a menudo me encuentro montando volumenes con
bricks formateados en reiserfs para ficheros pequeños, o ext3 para
ficheros grandes. Últimamente he hecho pruebas con btrfs (con muy
gratos resultados, por cierto) para entornos mixtos.

En el caso de MySQL (no he probado con otras DB) éste maneja su propio
locking y caching con lo que suele dar problemas con el locking y
caching de glusterfs. Creo que por eso no recomiendan usar la
replicación a través de gluster.

>
> Merci Ramiro por el comentario de Zfs.
>
> --
> JPA
> --
> _______________________________________________
> Comandob mailing list
> [email protected]
> http://lists.badopi.org/mailman/listinfo/comandob



-- 
http://tuxjuegos.tuxfamily.org
--
_______________________________________________
Comandob mailing list
[email protected]
http://lists.badopi.org/mailman/listinfo/comandob

Responder a