Hola :) On Wednesday 21 April 2010 15:37 Camaleón wrote
El Wed, 21 Apr 2010 14:32:01 +0200, Rafa Grimán escribió:
On Wednesday 21 April 2010 13:16 Camaleón wrote
Por eso digo que hay que archivar. El uso de archivado es muy bueno y muy utilizado en servidores de correo porque quita mucha morralla (aka correos antiguos que el usuario ni se acuerda que existe ;)
No puedes archivar los datos de un servidor web :-P
Imagina, te vas a YouTube para ver un vídeo en streaming y en lugar de ver un lindo gatito haciendo momerías te salta un pedazo de archivo en tar.bz2 (gatito_lindo.tar.bz2).
Ahí entraría la parte de HSM (aka almacenamiento jerárquico). Tienes 3
niveles de almacenamiento típicamente: 1.- elevada velocidad (FC/SAS): de esto tienes "poco"
y tienes los datos usados más recientemente
2.- disco de baja velocidad pero elevada densidad (SATA): aquí tienes datos que no se usan mucho, pero que alguna vez alguien lo ha pedido
3.- cinta: aquí tienes los datos que casi no se usan
Pasado el punto 3, se archiva todo ... o se borra ;)
No sé... yo no veo ese sistema para un servidor web.
Pues es lo que están usando todas las TVs del mundo ;) Incluyendo NBA. Además de las empresas de postproducción y de efectos especiales ... y eso es tiempo real ;)
Por ejemplo, en las típicas empresas de hospedaje compartido, no hay apenas archivado de datos (sólo se almacenan los registros de acceso y durante poco tiempo) pero dudo mucho que sigan un sistema jerarquizado como el que planteas... salvo que lo pagues, claro está, porque eso cuesta pasta y como no contrates un servidor dedicado o virtual, dudo mucho que lo ofrezcan >:-)
Si pagas, lo hacen ;)
Tampoco puedes archivar los buzones actuales de los usuarios ni los faxes. Bueno, los faxes sí, pero de hecho el directorio de archivado está en la misma ruta (/hylafax/archive), aunque supongo que con un poco de maña esto es modificable.
Por eso tienes dos opciones: 1.- el usuairo tiene derecho a gestionar el archivado por lo que un usuario "correcto" pasará al archivo todos los correos de más de 6 meses o un año y los recuperará si los necesita
Je, je... "usuario correcto" no existe en mi vocabulario >:-)
Por eso lo puse entre comillas ;)
2.- como admin, estableces reglas de migración que auto- máticamente t emigran los correos más antiguos
Eso lo puedes hacer pero dejando al usuario al margen y no tocando para nada sus mensajes locales actuales. Yo puedo hacer una copia de seguridad de sus correos o de la configuración del cliente de correo (agenda contactos, etc...), pero no puedo decidir qué le archivo y qué no, no me parece correcto porque los datos archivados son datos que le quito de su alcance y los puede necesitar :-/
Para eso hay una interfaz/GUI para el usuario, para que recupere lo que necesita cuando lo necesita. Obviamente, no vas a migrar los correos de ayer. Migras los de hace un año, por ejemplo.
Una tercera opción es juntar ambas de forma que automáticamente se migran los correos pasado un tiempo y si el usuario quiere recuperarlo, lo recupera.
Ufff. Ya te digo yo que no podría hacerlo, me cortan la cabeza. Yo les hago la copia de seguridad y poco más. Ellos son los que tienen que decidir qué quieren eliminar o mantener siempre accesible.
Pero es que no se eliminan, se mueven de un sitio a otro. Otra cosa, si al jefe le exolicas que migrando los correos a una cinta va a ahorrar en espacio, consumo eléctrico (tanto porque la cinta no consume a menos que se use como el que no produce calor), ... Lo impone. Te lo digo porque lo he visto. Y cuando las órdenes vienen de arriba ...
Aún así, los usuarios necesitan tener acceso a los faxes en bruto, no pueden verlos comprimidos ni archivados porque ese formato no es accesible ni se integra con los visores de fax que usamos y la gente tiene que poder consultar faxes que se han enviado, por ejemplo, en el año 2.008 y necesitan ver los datos del número de fax que se ha marcado o la fecha programada del envío y esos datos en un archivo comprimido no se pueden consultar a simple vista.
Para eso el ADA(M) tiene una interfaz gráfica (muy similar al explorador de disco) que te permite recuperar los ficheros.
En el caso de los fax u otros ficheros (ofimática, vídeos, ...) el uso de HSM es batsante cómodo porque imaginémonos que tienes el servidor con
lo siguiente: nivel 1: 5 TB en SAS nivel 2: 20 TB en SATA nivel 3: 100 TB en cinta
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.
Suponemos que el sistema de ficheros que exportas es /mnt/exportado/ y el usuario lo mapea a su PC con MS-Windows como F:
Bien, pues el usuario verá que su F: tiene un tamaño de 100 + 50 + 5 TB = 155 TB. El usuario no sabe (ni tiene por qué sabr) que realmente hay 3 niveles de almacenamiento. Así que el usuario pincha en el fichero, lo borra, lo copia, lo mueve, ... como si realmente fuera un único disco.
Dependiendo del HSM y del tipo de fichero, se pueden hacer unsa cosas u otras, por ejemplo, en vídeo (TV, cine, ...) el HSM puede hacer una de
dos: - 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.
A su vez, el HSM se puede integrar con archivado y backup de forma que mezclas todo ;)
Si la teoría está muy bien, Rafa, pero esa solución no sirve para los faxes (no sólo se trata de almacenar y clasificar los documentos de fax sino de "interpretarlos" para que el usuario sepa si es el archivo que busca o no) >:-). Como sistema de archivado general, vale.
Sí vale porque se migran los fax (u otros tipos de ficheros) que tienen una edad determinada, por ejemplo, todos los fax más antiguos de 1 año. Te lo digo porque lo hemos montado y funciona. No sólo nosotros, IBM también lo monta y EMC y muchos más. Lo hacemos/hacen para todo tipo de ficheros y el cliente no se da cuenta. Nosotros lo hemos instalado en clientes para vídeo, audio, imágenes, documentos ofimáticos (incluyendo fax), datos HPC, ... y los usuarios no se enteran, te lo garantizo.
Vale, pero en este caso hablamos de datos que no son antiguos, son actuales y los usuarios hacen uso a diario de ellos (lectura y escritura).
Para archivo definitivo esas soluciones son perfectas.
Nada es eterno ;) Los datos/correos tarde o temprano se vuelven antiguos y se pueden archivar.
Bueeenooo, no sé yo... el propio cliente de correo hace las funciones de archivador. O debería, si hicieran clientes de correo profesionales en lugar de tanta integración con las redes sociales :-P.
x"D QUé manía les tengo a las redes sociales >:-|
Al fin y al cabo, los datos archivados están en algún lado (disco duro local, disco en red, cinta, Internet...) el cliente de correo sólo tendría que "enlazar" con el archivador y mostrarlo / administrarlo como tal (por ejemplo, no incluir esas carpetas en la rutina de copia de seguridad, mantener los datos comprimidos y descomprimirlos al vuelo si el usuario ejecuta alguna acción sobre esos corroes, mantener el estado de los mensajes, permitir indexar igualmente su contenido, etc...).
No te sé decir exactamente cómo lo hace cada sw de archivado, cada uno lo hae a su manera. Con el MS-Exchange, creo que se hace eso, pero no te lo sé decir a ciencia cierta 0:)
PD Se me olvidaba. A todo esto, usar DAM (Digital Asset Management) también es útil, pero como siempre ... supone cambiar cosas, migraciones, cambio de cómo se trabaja, ... Los DAM son similares a lso CMS, pero para cualquier tipo de dato digital, no sólo ficheros ofimáticos.
Buf, vaya "monstruo", eso hace de todo (de la wikipedia):
"(...) The term "digital asset management" (DAM) also refers to the protocol for downloading, renaming, backing up, rating, grouping, archiving, optimizing, maintaining, thinning, and exporting files."
Creo que con un DMS sencillito ya sería suficiente O:-). Bueno, vale, para algunos sectores de la industria no, necesitan una mejor administración de los contenidos y un mayor control del espacio y la ubicación exacta de las copias, es cierto.
Con sistemas como estos que hacen todo y de forma automática nos quedamos sin curro en unos años :-)
No te creas. Los CMS/DAM/MAM/ECMS/PLM se tienen que configurar y administrar y eso no es fácil ;) Hay mucha integración por detrás, BBDD, servidores de ficheros, correo, web, ... Además, como el DAM te permite trabajar con difrerentes tipos de ficheros (a diferencia de los CMS), tienes que saber dimensionarlo bien, separar los servicios, ... Casi se me olvida. Un DAM es muy valorado en países "organizados", en países como España en los que todos hacemos lo que nos da la gan cuando nos da la gana ... el DAM es más un dolor de cabeza que una solución :( Estos inventos son muy buenos cunado toda la organización sigue unas normas. Como aquí las normas están para saltártelas ... pues si dice el jefe que hay que almacenar los documentos en el servidor ... que los almacene su abuela es la respuesta más educada que va a recibir. Por ejemplo, ¿cuántos habéis sufrido al SharePoint de MS? Pues eso es un CMS, imagínate si además añades vídeo y audio ... No te quiero contar la que se lía. Yo lo he sufrido y no es poruqe sea de MS es porque la gente no seguí las normas y al final había documentos repetidos, no sabías cuál era la versión última, qué revisiones se habían hecho, quién las había hecho, de qué iba el documento, ... Rafa -- Rafa Grimán Systems Engineer Silicon Graphics, S.A. Sociedad Unipersonal Plaza del Descubridor Diego de Ordás 3 Tel: +34 91 398 42 00 Edificio Santa Engracia 120 Fax: +34 91 398 42 01 28003 Madrid Mobile: +34 628 11 79 40 Spain E-mail: rgriman@sgi.com http://www.sgi.com Skype: rgriman NIF - A79415873. Inscrita en el Registro Mercantil de Madrid Tomo 207, Folio 104, Hoja M-4186 el 5-7-90 __________________________________________________________________________ NB: INFORMATION IN THIS MESSAGE IS SGI CONFIDENTIAL. IT IS INTENDED SOLELY FOR THE PERSON(S) TO WHOM IT IS ADDRESSED AND MAY NOT BE COPIED, USED, DISCLOSED OR DISTRIBUTED TO OTHERS WITHOUT SGI CONSENT. IF YOU ARE NOT THE INTENDED RECIPIENT PLEASE WILL YOU NOTIFY ME BY EMAIL OR TELEPHONE, DELETE THE MESSAGE FROM YOUR SYSTEM IMMEDIATELY AND DESTROY ANY PRINTED COPIES. NB: LA INFORMACION CONTENIDA EN ESTE MENSAJE ES CONFIDENCIAL DE SGI. ESTA DIRIGIDA UNICAMENTE A LA PERSONA(S) A LA CUAL SE ENVIA Y NO PUEDE SER COPIADA, UTILIZADA, DIVULGADA O DISTRIBUIDA A OTROS SIN EL CONSENTIMIENTO PREVIO DE SGI. SI USTED NO ES EL DESTINATARIO INDICADO HAGA EL FAVOR DE NOTIFICARMELO POR MAIL O POR TELEFONO, BORRE EL MENSAJE DE SU SISTEMA INMEDIATAMENTE Y DESTRUYA CUALQUIER COPIA IMPRESA "We cannot treat computers as Humans. Computers need love." Happily using KDE 4.4.1 :) -- "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