Hola :) On Friday 23 April 2010 14:12 Camaleón wrote
El Fri, 23 Apr 2010 13:32:35 +0200, Rafa Grimán escribió:
On Friday 23 April 2010 12:09 Camaleón wrote
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 ;)
El streaming de vídeo no es de acceso lectura/escritura, que yo sepa >:-)
Eso es que no conoces cómo funciona el mundo media. Toda slas televisiones y productoras tienen escritura y lectura simultáneamet y por varios usuarios: - unos editando contenidos - otros catalogando - otros creando - ... La NBA, como buena productora y TV que es ... funciona así así que sí, hay lectura y ecritura al mismo tiempo en tiempo real y por varias personas.
El correo, sí. Y por parte de varios usuarios al mismo tiempo.
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.
Hijo, pues no. La NBA no es una empresita del montón, la verdad.
Google tampoco ;)
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 ;)
Te he puesto como ejemplo cualquier empresa vulgaris pero tú dices que no, que eso de mantener los correos en línea no era la norma. Ahí es cuando te he puesto como ejemplo a Gmail. Podría haber dicho cualquier otra empresa que dé servicio IMAP (o en la nube).
¿Google vulgaris? Eso es nuevo: si mal no recuerdo, tienen más de 1 millón de servidores. Es más, eGoogle puede que tengas más razón en que no puedan archivar correo, pero en una empresa pequeña/mediana que los trabajadores se van a casa ... razón de más para poder archivar, mojer y hacer lo que te da la gana: no hay nadie usándolo (bueno, siempre hay alguien conectado), pero reclama el correo, fichero, dato y solucionado. De hecho, te he puesto ejemplos en los que el usuario no sabe ni que está trabajando contra cinta.
¿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.
(...)
Yo te he puesto ejemplos reales que sí conozco, puedes ponerme ejemplos reales que tu sí conoces.
Pero eso no es justo. Que yo no conozca ninguna empresa de primera mano que siga una política determina no significa que no las haya. No es mi campo (servicios a terceras empresas), no lo puedo saber.
Yo sí, y ya te he dicho que tenemos clientes grandes y pequeños que lo hacen. Lo cual no quiere decir que todo el mundo lo deba hacer. Sólo digo que sí pueden y de hecho lo hacen.
"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.
Vale, pues te doy la razón en lo del "factor tiempo" :-)
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.
A ver, a ver... 20 GiB son 20 GiB que necesitan espacio físico si tienes un disco duro de 60 GiB y si no tienes espacio, el sistema se queda colgado, no puedes iniciar sesión, los correos se rebotan, etc...
Correcto, de ahí que te haya hablado de: - tecnologías ue te permiten ampliar, archivar, ... - previsiones - montar un segundo disco y descargar datos "amanuense" Eso jamás te lo he negado. Lo que digo es que si crece /var/algo en su propio sistema de ficheros, /var (que está en SU sistema de ficheors) 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.
¡Claro que crecen! Hasta el límite físico que tengas definido (sea el tamaño del disco o de la partición), pero la cantidad de datos se incrementa con cada copia de seguridad que hago, o con cada correo o con cada fax que se envía o se recibe.
A ver, tú has escrito "Pues eso... para el 85% de las "empresas/usuarios" "/var" crece y mucho > ;-)" Y yo he dicho que no, que lo que crece es el sistema de ficheros (mejor dicho, el volumen de datos de un sistema de ficheros) y que si /var y /var/algo son dos sistemas de ficheros diferentes y el que crece es /var/algo ... /var no crece. Y eso mismo le he respondido a Carlos. En cuanto a que: "¡Claro que crecen! Hasta el límite físico que tengas definido (sea el tamaño del disco o de la partición)" tampoco es cierto ya que si usas LVM o una solución de HSM, el crecimiento es hatsa que te dé el bolsillo ;) No depende del disco físico que haya debajo. Tu disco puede ser de 1 TB, pero con LVM puedes ir añadiendo discos de 1 TB hasta que te quedes sin dinero.
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
La tecnología existe, por supuesto. Pero no siempre merece la pena implementarlas.
Yo no he dicho que merezca la pena, ni que sea obligatorio ni necesario. He dicho que es interesante tenerlas en cuenta y conocerlas, que es diferente. [...]
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.
Ya te dije que sí. Al menos yo necesito tener los faxes recibidos/ enviados de hace 3 años bajo /var/spool/hylafax... o eso o empiezo a montar el servidor desde cero integrando alguna de esas soluciones que comentabas -> inviable, al menos de momento.
Eso lo dices porque no has usado sistemas de HSM, si los hubieras usado verías que no NECESITAS que estén on-line. El usuario no sabe ni dónde están ni se da cuenta si tarda en venir o no de cinta a disco. Te he puesto ejemplos de vídeo que es TIEMPO REAL, si pierdes un frame ... al carajo todo. Y allí funciona. También te he dicho que nosotros y otros fabricantes lo implementan para todo tipo de ficheros: ofimática, imágenes, ... Estás haciendo suposiciones sobre algo que no has usado y no conoces. Yo lo he visto en clientes grandes y pequeños, con necesidades de tiempo real y no y el usuario no se da cuenta.
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.
Entonces te encontrarás con el mismo problema de limitación de espacio.
No digo que no te encuentres de nuevo con el problema, sólo he dicho que no es necesario tener LVM. Depende de cómo quieras solucionar el problema. También te podía haber puesto como solución el comprar una cabina de discos externa. (cabina de discos de SGI, claro está ;)
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: Ya sabemos que no obligas a nadie...
(¿qué hace esta argolla con pinchos alrededor de mi cuello?)
No es de pinchos, son explosivos ... Mira que les tengo dicho a los de marketing que los explosivos en forma de pincho crean confusión. Nada, que no hay manera ... x"D
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".
Exacto: no quiere usar el FTP.
A tus usuarios los puedes "domesticar" (quiero decir, intentar hacerles comprender cómo hacer bien las cosas) pero a los usuarios de empresas asociadas o con las que trabajas, ah, amigo... esos no son tuyos y entienden la vida de otra forma... si te gusta vale, y si no, adiós contrato. Es así.
No es cierto y lo he vivido con clientes nuestros. Han migrado a DAM y proveedores y usuarios internos trabajan tan contentos. ¿Saben realmente que es un FTP o un WebDAV o un CIFS? No. ¿Lo tienen que saber? No. Tu le das una interfaz web o si quieres les programas un cliente nativo para su sistema operativo o un cliente XUL para Firefox o como te de la gana o creas que es más sencillo para el usuario y ya está. Generalmente lo más sencilo para el uusario es una interfaz web.
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 ;)
¡¡¡Argghhh, más siglas...!!! X-)
Ya lo puse en un corre anterior ;)
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.
He dicho "un año" por decir... pueden ser 5, o 10... y el /var sigue creciendo a diario.
Me da igual. El cliente es el que establece las políticas y es el que las modifica. He comentado en otro correo que los 3 - 4 primeros meses, el cliente modifica las reglas para irlo tuneando o afinando para sus necesidades, pero a partir del 6 mes ... eso no lo vuelve a tocar nadie (a menos que los flujos de trabajo cambien). [...]
Por eso evito particionar pero me encargo de tener siempre los backups al día :-P
Buena práctica :D
Hasta que algún día tenga problemas con "la" partición, claro :-P
Hmmmm, para ese tipo de problemas se me ocurre: LVM Archivado HSM x"D Es una broma. Lo que sí recomiendo es que no tengas datos y backups en el mismo sitio: si pierdes uno ... pierdes el otro :( [...]
... a mi personalmente me importa un bledo*, a mi lo que me gusta es el skate y el snow ;)
Y los caracoles...
Que no falten !!! x"D 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