Hola :) On Friday 23 April 2010 10:13 Camaleón wrote
El Fri, 23 Apr 2010 00:25:06 +0200, Rafa Grimán escribió:
On Thursday 22 April 2010 17:53 Carlos E. R. wrote
(...)
Siempre y cuando la política de la empresa te deje. Pueden exigirte tener en linea varios gigas de espacio para cada usuario en imap, en plan gmail.
El acrhivado puede está shelved cuando lo sacas de la librería o del jukebox de CD/DVD/BR. Sacar cintas de una librería para backup es bastante normal (hay que evitar que backup y datos estén físicamente próximos). El archivado (a cinta o a CD/DVD/BR) no significa necesarioamente que te lo llevas a otra oficina, a un banco, a un vault o similar, significa que no lo tienes en disco principal. Es decir, puede estar dentro de la librería de cintas.
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 ;) 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" "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." Es decir, lo que se archiva o lo que se migra (en el caso de HSM) son datos antiguos. Obviamente, los correos de ayer y de hoy no se migran. ¿Quién define lo que es antiguo? Como siempre, el jefe ;) Como Admin, debes opinar y presentar un estudio de uso del correo (o cualquier otro dato). Yo, como fabricante o integrador no te puedo decir cada cuánto tienes que migrar o archivar los datos, ATEMPO tampoco, IBM tampoco, EMC tampoco, ... Eso lo tienes que establecer tu como admin de tu empresa. Como integrador y fabricnate lo que sí es hecho es ayudar al cliente y asesorarle y formarle en el uso de la herramienta de forma que si quiere cambiar sus políticas, lo pueda hacer sin mi. De hecho, los 3 - 4 primeros meses la gente se queja y andas experimentando hasta que consigues afinar las reglas. Pero una vez que tienes las reglas "en su sitio", la cosa funciona. Claro está que puedes contratar a una empresa para que te haga ese estudio ... pero vas a tener que pagar la consultoría (y el SW que quieran instalar para monitorizar el comportamiento de los usuarios y el flujo de trabajo). 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. 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.
También hay que tener en cuenta un tipo de archivado "especial" que es lo que se llama copia legal y es básicamente lo que exige la ley en cuanto a determinados datos digitales: que tienes que tener una copia para revisiones legales durante no sé cuánto tiempo. Se tiene que guardar en un medio inalterable (WORM) y tienes que garantizar su lectura durante ese tiempo que exige la ley.
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, ... En el caso de audio y/o vídeo que sí puedes necesitar tiempo real (el streaming de YouTube, por ejemplo, no es tiempo real ni lo es ningún streaming basado en Flash), lo que se hace es lo que he comentado en un correo anterior (copio y pego): " - dejar los primeros segundos en el nivel 1 y el resto migrarlo - migrar ciertas partes, por ejemplo, del minuto 1 al 7, del 8 al 9 los mirga a nivel 2 dejando el resto de minutos en nivel 1. Así, cuando el usuario pida el fichero de vídeo, no tiene que esperar sino que lo vé inmediatamente y cree que está todo on-line."
El /var puede ser muy grande. Aunque lo gestiones bien, lo repartas, lo archives en tres capas, puede ser enorme. Es a donde van los datos que no son propiedad de un usuario sino de todos, es decir, los datos que se "sirven" desde el servidor.
/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 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.
Pero vuelvo a lo de antes, sí: jerárquicamente /var crece y, jerárquicamente / crece también, pero eso es desde un punto de vista lógico, NO físico ;) Si nos ponemos a mirarlo desde un punto de vista físico (que es el que interesa porque los discos son elementos físicos y no lógicos) lo que crece es el sistema de ficheros y /var /var/cache (por ejemplo) pueden ser dos sistemas de ficheros diferentes luego físicamente, el que crece es /var/cache, pero no /var ;) Lo mismo va para /var/log o /var/mail o /var/lo_que_quieras, si lo diseñas bien, lo diseñarás como sistemas de ficheros diferentes.
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 ;)
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
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. Ya, ya sé que el usuario se queja si le pones límites. Tuve un amigo trabajando en "Infobirria" y le llamo un lciente indignado porque "el correo no funciona". El cliente quería enviar una imagen iso por correo. Sí, quería envíar los 670 MBytes de un CD a un colega. Pues qué quieres que te diga ... que se queje todo lo que quiera, hay unos límites en el correo y en las autopistas y en la tarjeta de crédito y en lo que puedes comer/beber de una sentada y en todo en esta vida.
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. 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.
¿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, ...
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. En HPC (sea científico, media, financiero, ...) el volumen de datos que se maneja es algo inhumano y las previsiones a 3 años sabes a ciencia cierta que el 1er año te las vas a fundir, peor aún así ... se hacen estimaciones y previsiones para no quedarte de pronto sin espacio. ¿Qué ocurre cuando esta gente se queda de pronto sin espacio? Muy sencillo: 1.- monitorizan todo mucho para que esto casi no ocurra 2. -tienen SW de archivado 3.- tienen SW de HSM 4.- tienen SW de dedupe 5.- tienen políticas a medida en función de sus flujos de trabajo Siendo el 5 punto el más importante. Ya sé que me vas a decir que tu no manejas sus presupuestos, pero no tiene nada que ver porque su presupuesto es 500% mayor que el tuyo, pero sus necesidades son 5000% mayores que las tuyas por lo que salen ellos perdiendo ;) Además de eso, piensa que: - a lo mejor tu no necesitas HSM: ya te has quitado un gasto que ellos sí tienen - a lo mejor tu puedes funcionar perfectamente con un sw de backup* FLOSS: te has ahorrado las licencias que ellos tienen que pagar porque no hay soluciones FLOSS que les valga * o cualquier otro sw que tu no licencias y ellos sí: servidores de ficheros, servidor de correo, ... 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 ;) Rafa -- "We cannot treat computers as Humans. Computers need love." Happily using KDE 4.4.1 :) -- 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