Mailinglist Archive: opensuse-es (614 mails)

< Previous Next >
Re: [opensuse-es] Re: lvm o particiones extendidas
  • From: carlopmart <carlopmart@xxxxxxxxx>
  • Date: Fri, 23 Apr 2010 12:35:35 +0200
  • Message-id: <4BD177F7.4040304@xxxxxxxxx>
Camaleón wrote:
El Fri, 23 Apr 2010 11:10:23 +0200, Rafa Grimán escribió:

On Friday 23 April 2010 10:13 Camaleón wrote

Rafa, ¿de verdad crees que los correos que tienen los usuarios en Gmail
están archivados en cintas y almacenados allá en Mountain View? >:-)

Te sorprendería saber lo que hay en cinta y el usuario cree que está en
disco. Te pongo un ejemplo que es mucho más "delicado": NBA. Está
haciendo streaming en Internet de todos sus videos y creeme, la gran
mayoría están en cinta. Es cliente nuestro ;)

La NBA no usa un servicio como Gmail :-)

A ver, que tú pones como ejemplo un tipo de industria/usuario que no es el habitual, el volumen de datos que tiene que manejar la NBA no es el volumen de datos que tiene que manejar cualquier empresa ni las estrategias que tienen definidas, tampoco se ajustan a una empresa media.


Otra cosa, no confundas cosas. Yo no he dicho que tenga que estar TODO
en cinta, he dicho cosas como (copio y pego):

"2.- como admin, estableces reglas de migración que auto-
máticamente t emigran los correos más antiguos"


¿Lo hace Gmail? Ya te digo que no lo creo. El acceso desde el webmail a los correos que tengo desde de la lista el año 2.003 es instantáneo, dudo mucho que los tengan almacenados como archivo.


"Los ficheros más usados, se encuentran en los discos SAS, los
menos
usados en SATA y los que están llenos de polvo en cinta."

"Nada es eterno ;) Los datos/correos tarde o temprano se vuelven
antiguos
y se pueden archivar."

"Nada" es relativo. El "tiempo" es relativo, y lo que una empresa archiva en un día otra no lo llega a archivar en 5 años (debido a la diferencia entre la cantidad de datos que genera una y otra).

(...)

También es cierto que tus políticas no le valen a Google ni a la
gestoría de la esquina ni a la NBA, cada caso es un mundo. Por eso, lo
tienen que decidir el cliente final.

Pues eso... para el 85% de las "empresas/usuarios" "/var" crece y mucho ;-)
En cuanto a Google, creeme, lo tienen todo muy bien estudiado y no me
extrañaría que tuvieran en cinta mucha más info de la que creemos ;) No
sólo Google sino otros como FaceBook o NYSE o cualquier otro grande.

Demasiado rápido va como para que esté archivado, no me convence.

Sí, pero es que no hablamos de "archivar". Archivar implica dar un
tratamiento especial a los datos, sacarlos de su ubicación actual y
moverlos a otro espacio (físico o lógico) por lo que dejan de estar
accesibles en tiempo real para el servidor o el usuario.

Volvemos a lo de antes, se supone que has hecho un estudio sobre qué
datos y cuándo se pueden migrar porque no hace falta tiempo real. Este
es el caso de correo-e, documentos ofimáticos, imágenes, ...

Pero Rafa, a ver... cómo te lo diría. Mi "/vares" crecen y necesito tener espacio disponible para que puedan aumentar hasta lo que quieran (hasta lo que le permita el disco) porque no uso volúmenes "expandibles" ni cabinas de discos enganchadas. Con 1.2 TiB para espacio compartido de archivos y backup de momento nos sobra :-P


/var es para ficheros de tamao variable, de ahí el nombre.
Un "tamaño variable" requiere un "espacio variable" y esos datos pueden
e estar ahí meses o años antes de pasar a ser archivados >:-)

Efectivamente y esa variación de tamaño luego se refleja en la cantidad
"variable" de dinero que quieras pagar:
- disco -> más caro + más consumo + más calor - cinta -> más barato + menos consumo + menos calor

Pero es que necesito que estén en disco y accesibles, no en cinta y archivados.
Oye, por mi encantado que NO quieras archivar y ójala todos los clientes
pensaran así -> vendería más disco y me haría rico. Pero la realidad es
otra:

"¿por qué pagar más por mantener un dato on-line cuando NO
es necesario que esté on-ĺine?"

Y creeme, que si el jefe y el de contabilidad/compras/financiero oyen
"pagar más" o "pagar menos" ... la cosa cambia.

Porque cuesta (tiempo, dinero, mantenimiento) más llevarte ese dato offline que mantenerlo online. Y porque en el caso de los correos, necesitas tenerlos en línea, disponibles, frescos.

Si tienes un disco pequeño, "/var" ni se parte ni se divide. No
compensa, al contrario, te penaliza.

Si tienes un disco físico pequeño en *nix, hacerlo crecer es muy
sencillo: compras un disco nuevo y lo montas bajo /var/disco_nuevo ;)

Eso será si te puedes permitir el lujo de comprar un disco nuevo y de más capacidad (hay quien no puede ni eso) y para los afortunados que pueden comprarlo y ampliar el espacio, tienen además que tener una configuración que admita la gestión de volumen dinámicos (el LVM que estábamos comentando) y hay quien sencillamente no quiere usar ese tipo de soluciones porque no les compensa.
Es decir, si hay un directorio "caótico" ese es "/var" (puede aumentar
su tamaño o disminuirlo de forma aleatoria y sin un patrón concreto).

Por eso mismo existen:
- gestores de volúmenes
- sw de HSM
- sw de archivado
- dedupe

Inviable en muchas empresas.

Imagina un correo enorme que tenga que estar en la cola dirigido a
todos los usuarios del sistema enviado con malas intenciones,

Para eso se establecen límites en el tamaño del correo, entre otros
límites ;) Si no estableces límites: mal hecho.

No, no puedes. Eso no depende de ti, y nosotros podemos recibir planos completos en AutoCAD por correo electrónico (no preguntes...). Tengo que relajar esas normas o podemos perder mucho, no sólo tiempo sino dinero.

(...)

e imagina además
que por política de empresa todos los mensajes enviados/recibidos se
duplican en una cuenta de seguridad... aumentas el espacio requerido en
"/ var" de manera exponencial en apenas unos segundos.

Tu lo has dicho: es una COPIA, luego no es necesaria on-line porque
tienes el original on-line.

No se trata de que esté o no archivada, se trata de que te ocupa espacio en disco... hasta que llegue a su destino. Y su destino puede ser "/var/
mail", donde la persona que se encargue de consultar esos correos lo haga mediante IMAP y ahí se quedan los correos hasta que al año siguiente se archivan.

Es un ejemplo de lo que en un correo
anterior llamaba (o llaman algunos clientes/empresas) copia legal.

Esa copia puede estar perfectamente en una librería de cintas, bien sea
con o sin VTL por en medio para darle mayor agilidad/velocidad al
proceso o se hace todas las noches o la política que creas conveniente,
pero es lo que tu misma has dicho: una copia.

Pero es que no hay un "caso de uso" único. Cada empresa o cada usuario tiene establecido un método de trabajo distinto, acorde a sus necesidades.

¿Y cuándo se eliminan
los correos pesados? Pues dependerá de cada usuario. Algunos lo
descargaran vía pop, otros lo mantendrán accesible vía imap... y otros
no lo bajarán en ¿meses?.

Pero ahí ya interviene la política de empresa. si la empresa dice que se
hace así, así y así. Pues es como hay que hacerlo. Los recursos son de
la empresa, nos guste o no y es la empresa la que establece las normas.
Obviamente, si tu como Admin le consigues explicar bien las cosas al
jefe ... se harán "bien".

Si tu, como Admin, rechazas una tecnología porque sí ... a lo mejor te
estás perdiendo una cosa que te ahorraría mucha pasta y que podrías
invertir en cosas que necesitas: formación, renovación de equipos, ...

Rafa, hay muchas formas de hacer las cosas bien. Ya me gustaría a mí poder tener los servidores web (o los de correo) en HA, o al menos re-
duplicados. No puedo. O aumentar el almacenamiento de la red local. No puedo. Tengo que trabajar con lo que hay y rentabilizar no sólo en material sino en tiempo >:-)
O el mismo "zypper" te puede disparar las necesidades de espacio
actuales en "/var" al generar archivos de registro de actividad de
"no-sé-cuantos" gigas por un error.

Ahí hay otra tecnología que se llama thin provisioning u
oversubscription. También hay una cosa que se llama previsión, como
Admin tienes que preveer la cantidad de un recurso que vas a necesitar.
Obviamente es IMPOSIBLE acertar con las predicciones, pero tienes una
idea.

Por eso evito particionar pero me encargo de tener siempre los backups al día :-P
(...)

Te vuelvo a repetir: no te estoy inentando convencer de que uses o no
una tecnología (sea de gestión de almacenamiento, como es este caso) o
sea de monitorización de cámaras IP. Yo te comento lo que hay, lo que se
usa, en qué casos, ... que a ti te guste o no, que te convenzca, que te
parezca bueno o no, ... Oye, ya es cosa tuya: yo sólo intento ayudar
porque he visto que en casos similares ... sí ha funcionado ;)

Yo creo que tus "user-case", aunque totalmente válidos (repito, ya me gustaría poder mantener ese tipo de configuración), están un poco sobredimensionados en comparación con los requerimientos de las empresas medias O:-)

Saludos,


Pero es que una empresa media (y hasta pequeña) puede hacerse con una infraestructura de HA 99,999% operativa. No es tan alto el precio a pagar. Ejemplo:

- 2 servidores con 4/8GB de RAM y el máximo espacio de disco que te puedas
permitir.
- Entre 2 y 4 servidores más dando todos los servicios posibles: correo, web,
etc.

Metes todo el dinero que puedas en el hardware, más la electrónica. A partir de aquí puedes usar buen software libre para montar dos servidores de storage en HA y los demás servidores dando servicio y te olvidas de esos problemas que se comentan de espacio en /var.

Y por cierto, todo y cuando y digo todo es todo, lo que se almacena en /var es fácilmente movible a cualquier otro espacio de disco: bases de datos, spool del mta, etc. Todo. A mí no se me ocurre ningún caso en el que no se pueda hacer, aunque no digo que no lo haya pero no se me ocurre.

Saludos.

--
CL Martinez
carlopmart {at} gmail {d0t} com
--
Para dar de baja la suscripción, mande un mensaje a:
opensuse-es+unsubscribe@xxxxxxxxxxxx
Para obtener el resto de direcciones-comando, mande
un mensaje a:
opensuse-es+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups