Hola :) On Friday 23 April 2010 12:09 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 :-)
Ya, pero hace streaming de video, lo cual tiene unas exigencias mayores en cuanto a disponibilidad del material por lo que si con un vídeo lo puedes hacer ... con un correo no te quiero contar lo qu epuedes hacer ;)
A ver, que tú pones como ejemplo un tipo de industria/usuario que no es el habitual,
¿No es habitual? ¿No es habitual ver vídeo en Inet? Podría haber usado Youtube si quieres.
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.
Eso te lo he puesto más abajo. Entonces también tienes que reconocer que el ejemplo que has puesto tu (Google) tampoco "se ajustan a una empresa media.", como bien dices ;) Me he limitado a seguir tu ejemplo en cuanto a tamaño de empresa, complejidad de su negocio, volumen de datos, ... Si no te gusta la NBA como ejemplo qu ehe puesto ... tampoco te puede gustar Google como ejemplo que has puesto tu ;)
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.
¿Por qué? Ya te he explicado que es basado en políticas y que Google lo tiene todo muy estudiado. ¿Sabemos cómo monitorizan los correos y usuarios? Nopes. ¿Podrían estar monitorizando por usuario? Sí. ¿Podrían establecer reglas por usuario y volumen de datos? ¿Por qué no? Me puedes decir que eso es muy complicado, pero tambiés muy complicado su negocio de buscador y anuncios dirigidos ;) Obviamente, todo eso son suposiciones, así que te remito a lo que he dicho en correos anteriores y que aparece justo debajo: puede que usen discos SAS y como segundo nivel SATA. No sabemos cómo lo tienen montado por lo que tanto tu como yo lo único que podemos hacer es especular: - yo a favor de que sí tienen archivado - tu en contra de que tienen archivado Pero es eso, meras especulaciones ;) Así que mejor dejamos Google que no lo conocemos ni tu ni yo y es como discutir sobre el sexo de los ángeles ;) Yo te he puesto ejemplos reales que sí conozco, puedes ponerme ejemplos reales que tu sí conoces.
"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).
De ahí que hable tanto en los correos anteriores como ahora mismo de las reglas o políticas que cada empresa pone en función de sus flujos de trabajo (y órdenes/decisiones dle jefe). Me estás dando la razón, es lo que he dicho en correos anteriores: depende de la empresa, es la propia empresa la uqe tiene que decidir/definir sus políticas.
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 ;-)
Volvemos a lo de antes: desde un punto de vista lógico, no físico y, te guste o no, tu almacenamiento y el de todo ser vivo, es físico. Luego si tienes: /dev/sdc1 -> /var /dev/sdd1 -> /var/log /dev/sde1 -> /var/BBDD /dev/sdf1 -> /var/correo_electronico_del_jefe ... Y crece /var/correo_electronico_del_jefe y /var/log ... /var/ crece de forma lógica, pero NO crece de forma física. Lo mismo ocurre si sólo tienes los siguientes 3 sistemas de ficheros: / /home /var y /var y /home crecen 100 TB ... / NO crece, seguirá teniendo el mismo tamaño que tuvo ayer a las 16:30 cuando lo instalaste. Crecimiento desde un punto de vista lógico NO implica crecimiento desde un punto de vista físico y a ti lo que te interesa es el crecimiento físico, el lógico te da igual.
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.
Doy por hecho que has medido el tiempo de respuesta d etodos los correos de todos los usuarios de GMail ;) El que a ti te vaya deprisa NO significa que a mi me vaya deprisa. Otra cosa, te remito a lo que he dicho de los niveles de almacenamiento y a los ejemplos que te he puesto del video: puedes tener partes de dato on line y parte off-line así das la impresión que es on-line.
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)
Eso no es nada nuevo, le pasa a todo el mundo ;)
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
¿Y? Eso no significa que no lo vayas a necesitar. Pero ... volvemos a lo que he dicho en todos mis correos de este thread: - la empresa es la que decide así que si te funciona así, por mi bien, sigue así :D - yo no estoy intentando convencer a nadie de que use una determinada tecnología, me limito a contar la tecnología que existe Por cierto, ya sé que tu no haces distinción entre archivo y fichero, pero en el mundo del almacenamiento sí se hac distinción porque NO son lo mismo. Ya hubo un thread y no pienso entrar a resucitar dicho thread ni dicho tema. Se diferencia precisamente porque en tu frase puedes dar a entender que SÍ estas usando SW de archivado y que tienes archivados datos: "Con 1.2 TiB para espacio compartido de archivos y backup [...]" Esa frase la lee cualquier empresa de almacenamiento (EMC, Hitachi, SGI, HP, IBM, Oracle, ATEMPO, ...) y da por hecho que tienes un sw que te archiva y crea copias de seguridad. Es simplemente un consejo, ten cuidado porque puedes causar confusión, especialmente en un mercado que ya tiene unas palabras determinadas para determinadas situaciones. Es como si un usuario te dice que "este ordenador no funciona" y para él ordenador es sinónimo de teclado+ratón+monitor+CPU+tele+lavadora+video+TDT+SW ... te lo digo porque me ha pasado y no sabes de lo que están hablando y lo único que se consigue es alargar y liar una cosa que podía durar 2 minutos. Como ejemplo: la gente que confunde MS-Windows con MS-Office y meten en el saco el MSN. Hasta que sabes de lo qu ete están hablando ...
/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.
Eso no es cierto. No me creo que TODOS y me refiero a ABSOLUTAMENTE TODOS los ficheros que hay en tus sistemas informáticos se usen SIEMPRE. No me lo creo. Necesitar != querer.
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.
Necesitar != querer. Copio y pego: volvemos a lo que he dicho en todos mis correos de este thread: - la empresa es la que decide así que si te funciona así, por mi bien, sigue así :D - yo no estoy intentando convencer a nadie de que use una determinada tecnología, me limito a contar la tecnología que existe
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)
Ya lo sé y no he dado por hecho eso. Me he limitado a dar una solución técnica a un problema técnico.
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)
Para la solución que yo he dado (montar un disco nuevo bajo /var/disco_nuevo) NO hace falta tener LVM.
y hay quien sencillamente no quiere usar ese tipo de soluciones porque no les compensa.
O a lo mejor no lo necesita porque montando el nuevo disco como he dicho en el ejemplo les vale. Te repito que NO estoy obligando a nadie a usar ninguna tecnología: - en el caso de LVM he dado unos consejos a un colistero - en el caso de archivado, HSM, DAM, dedupe, ... lo he comentado porque a lo mejor a alguien le parece útil y porque está relacionado con el tema de crecimiento de datos
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.
Y dale, NO he dicho que sea obligatorio usarlo. Ya sé que es inviable en muchas empresas. En el párrafo mío anterior lo que hago es explicar por qué aparecieron esas herramientas, no te líes. Me he limitado a decir por qué se han diseñado y desarrollado esas tecnologías, no que sean obligatorias o necesarias. Ya sé que son inviables en muchas o algunas empresas, igual que es inviable que nos compremos todos (muchos o algunos) un Rolls Royce, pero eso no quita que alguin nos cuente por qué el Sr. Royce decidió diseñar y construir ese coche.
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.
Sí puedes y de hecho debes hacerlo, si no pones límites en el correo, el uso de Inet, ... Se va todo al carajo.
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.
Ya sé que recibís planos de AutoCAD, alguna vez has comentado el tipo de empresa en la que trabajas y coincide con el tipo de empresa de algunos de nuestros clientes. Pero eso no quita que esté mal y no me vale el que digas: "Es que los usuarios se quejan o no quieren aprender a usar FTP". Mira, nosotros hemos llegado a recibir correos de 60 MByte de gente de marketing y no te quiero contar la cantidad de quejas que hubo, se les explicó: tenemos un FTP interno, pónlo allí. Posteriormente se decidió que presentaciones, manuales, vídeos, ... estuvieran en una web (wiki o web "normal") y que a la gente no técnica se les formara y que las webs se diseñasen para facilitarles la labor. Con esto qué hemos conseguido: - mayor fluidez en el correo - evitar enviarle el "documentazo" a gente a la que no le interesa - ahorrar en almacenamiento en el servidor de correo - ahorrar dinero - ahorrar molestias - ... Si tu se lo explicas bien al que maneja "los dineros" ... creeme que puedes poner las reglas que te dé la gana. Si montas una buena demo y lo pones fácil ... todos felices :) Como siempre: otro consejo. Hago esta aclaración porque vas a volver a interpretar que te quiero obligar o convencer a usar una tecnología. Ya que estamos con este tema de AutoCAD (y lo que conlleva: múltiples ficheros, desde docs, PDFs, fotos de terrenos, planos, ...) os vendría de perlas un DAM porque evitarías que la gente enviase tanto plano por correo ;) Claro está, que hay que elegir bien cuál, el flujo de datos, ... Tu decides ;)
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.
A eso me refiero, copio y pego un trozo de tu frase: "[...] hasta que al año siguiente se archivan." Vuelves a darme la razón. Llevo todo este tiempo diciendo que se establecen políticas basadas en tiempo y el que establece ese tiempo es el cliente porque es el que sabe cómo funciona su empresa. En tu caso los archiváis anualmente, en otros sitios todoas las noches, en otros una vez a la semana. Que sí, que hasta que los archivas están en disco, vale, ¿y qué? Lo malo es que tuvieras en disco los de TODOS los años y que jamas archivaras.
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.
Yo no he dicho que haya un caos único. No te estás leyendo mis correos, estoy diciendo que cada empresa pondrá sus reglas o políticas. En mi párrafo anterior, de hecho, he escrito: " o se hace todas las noches o la política que creas conveniente" Ese "tu" puedes ser tu (Camaleón) o puede ser Carlos o Fernandito o Pepi o El director de Repsol o de Nike, me da igual quién sea. Cada uno pondrá sus reglas de acuerdo a su funcionamiento y 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 >:-)
Por eso he comentado algunas tecnologías de almacenamiento. Yo no obligo a que se usen, las doy a ocnocer. A lo mejor ahora mismo no puedes/necesitas hacer uso de ellas. Pero a lo mejor dentro de XXXXX años te surge un problema y piensas: "Un carajo de la lista me comentó una vez algo llamado dedupe/LVM/archivado/HSM/lava_vajillas/escobilla/buzón/tenedor que me vendría bien": También puede ocurrir que tu (Camaleón) jamás lo puedas implementar pero otros sí. O, a lo mejor nadie ne esta lista lo necesite jamás. Eso ya no es "mi problema", yo lo cuento y ya está, luego que cada uno decida.
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
Buena práctica :D
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:-)
No señor, tenemos empresas medianas que usan estas tecnologías. Y otros fabricantes también tienen empresas medianas que usan esas tecnologías. Yo he puesto los casos extremos para que veáis casos en los que es PRIMORDIAL, es decir, que a Pepito el streaming no le vaya del todo fino no es importante para la Humanidad, ahora que no le vaya fino a NBA es un desastre mundial (bueno, para todos a los que les guste el baloncesto ... a mi personalmente me importa un bledo*, a mi lo que me gusta es el skate y el snow ;) * lo cual no significa que me importa un bledo a nivel corporativo como fabricante ;) 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