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, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org