Ahorrando espacio de disco en nuestra infrestructura Domino con DAOS
18 July, 2008 01:48:23 PM mangelcalvo Domino 8.5 | Comentarios (2)
Ha aparecido un nuevo artículo en Developer Works, IBM Lotus Domino going green: The new Lotus Domino attachment and object service. En él se describe en profundidad la nueva opción disponible en Domino 8.5 Domino attachment and object service, conocida familiarmente como DAOS.
Mediante esta nueva opción podemos configurar nuestro servidor, y las bases de datos que queramos que estén afectadas por esta funcionalidad, para que cada vez que se cree un documento con un anexo y dicho anexo supere el tamaño XX determinado por el administrador, el servidor extraiga el anexo y deje en el documento un enlace al mismo.
Los anexos se guardan en una ruta especificada en el sistema de archivos, por supuesto encriptados con el ID del servidor. El servidor dispone de una base de datos .nsf en la que gestiona las referencias de las rutas a los archivos, para su recuperación. Los clientes acceden a los anexos de manera totalmente transparente.
El administrador determina que bases de datos se ven afectadas por DAOS. Cualquier base de datos es susceptible de ser configurada para ser usada con DAOS, aunque la utilidad real se obtiene en las bases de datos de correos para todos esos anexos que fluyen dentro del sistema de mensajería interno con múltiples destinatarios, o en hilos de mensajes que arrastran el anexo original.
Desde hace varias versiones Domino dispone de un mecanismo "similar" Shared mail o Single Copy Object Store (SCOS). Dicho mecanismo está asociado al subsistema de mensajería Domino. Se basa en la creación de una base de datos en la que se crea un copia del Body de aquellos mensajes enviados a más de un destinatario. Los destinatarios reciben el mensaje con la cabecera y en vez del Body un enlace a un objeto de esa base de datos compartida. El mecanismo es también transparente para los usuarios.
Personalmente Shared mail no lo he implantado en ningún cliente, y las referencias que tengo no son buenas, sino más bien malas. Los problemas son muchos, sobre todo cuando se corrompe la base de datos compartida. Dicha base de datos tiende a crecer mucho en tamaño ( aunque puede ser dividida en varias ). Implementarla es pasar a tener un entorno similar a Exchange, con una gran base de datos, que en caso de corrupción compromete seriamente la estabilidad del sistema de correo.
DAOS es diferente a Shared mail, pero deberemos esperar a ver las opiniones de la gente que lo implanta.... o podemos implantarlo y opinar personalmente :-) En cualquier caso, está en la versión 8.5 Beta y tardará unos meses en llegar al mercado. Aún así, lo que anuncian es la posibilidad de hacer copias incrementales del repositorio de DAOS, lo cúal puede simplificar significativamente nuestra infraestructura de backup y decidirnos por la implantación de esta funcionalidad.
Hola Damián,
Veo que tú eres de los que han evaluado "de verdad" el producto. No te puedo, de momento, replicar en el funcionamiento real de DAOS, ya que ciertamente no lo he implantado en un entorno de pruebas para poder añadir información a lo que nos indicas. En cualquier caso hay aspectos me gustaría comentar.
En relación al formato en disco de los archivos DAOS, coincido en que comprimirlos mediante HUFFMAN o LZ1 no es una opción de seguridad. En cualquier caso, la versión definitiva encriptará los archivos con el ID del servidor, haciendo ilegibles los mismos. Pero, aunque no encriptáramos nada, el mero hecho de que alguien pueda acceder a un directorio del sistema de archivos del servidor es una agujero de seguridad inmenso. En un principio, ni siquiera deberia ser necesario encriptar el repositorio de DAOS ya que NO es accesible por ningún usuario, sino que únicamente ha de acceder a él el servidor. Por otro lado, las copias de seguridad encriptadas si garantizan que las mismas sólo tengan valor para ser restauradas en el sistema original, lo cuál justifica la encriptación en origen.
Lo que comentas en el punto 4 me resulta interesante, para averiguar que es lo que ocurre, ya que DAOS trabaja a nivel de anexo exclusivamente ( así lo entiendo yo por la documentación ) y nada que no fuera un anexo debería ubicarse en su repositorio.
En relación a Transaction Logging, efectivamente te obliga a disponer de un disco adicional, y no solamente eso, sino también un canal exclusivo para ese disco, diferente del canal de datos de Domino. Pero, mediante transaction logging y un sistema de backup compatible puedes configurar un backup incremental en Domino y los tiempos de respuesta para los usuarios son hasta un 10% mejores. Si tu entorno se mueve por el reino de los Teras de almacenamiento, quizá es una opción a estudiar, sino coincido contigo en que no es necesario añadir complejidad a la infraestructura Domino.
En conclusión, interesantes opiniones las tuyas tras haber probado DAOS en máquina la opción. Y, si dispones de más información y quieres compartirla estás invitado a incluirla en este blog cuando quieras.
Un saludo,
Miguel Angel
Estuve evaluando DAOS y estas son las conclusiones a las que llegué:
1+ Si tengo que hacer un fixup contra la base, el mismo es mucho más rápido. Esta es una ventaja.
2+ Backupear al principio me pareció interesante puesto que podría hacerlo en forma incremental, pero al momento de evaluar cómo restaurar una base afectada por DAOS vino el problema: Yo utilizo un sistema de backup genérico, no uno de IBM... entonces si tengo que restaurar una base (o más de una) determinada ¿cómo sé yo cuales archivos adjuntos de DAOS pertenecen a dicha base? Conclusión: No puedo utilizar más un sistema de backup genérico (desventaja)
3+ En la mayoría de los casos los archivos dejados en el directorio DAOS eran ilegibles... mejor, así es más seguro. Pero adjunté otros archivos y los mismos se podían leer al abrirlos en el directorio de DAOS!!! Investigando, me dí cuenta que si al momento de adjuntarlos uno no pone la opción COMPRESS entonces no se utiliza HUFFMAN ni LZ1 y por ende los archivos se adjuntan no comprimidos y se pueden leer del repositorio de DAOS sin problema. Si en cambio uno pone COMPRESS entonces se utiliza LZ1 o HUFFMAN... estos algoritmos son públicos así que sería muy fácil desencriptarlos. Conclusión: DAOS no me parece seguro (desventaja)
4+ Cuando convertí a DAOS a una base que casi no tenía archivos adjuntos, descubrí que en el repositorio de DAOS había muchos archivos nuevos a pesar de que casi no había adjuntos en la misma!!! Pensé que era un problema de DAOS pero investigando, me di cuenta que los documentos a pensar de no tener archivos adjuntos, tienen adjuntos internos que son la codifición MIME del mail!!! O sea que si uno recibe muchos SPAMs entonces eso significa que DAOS se va a incrementar mucho ya que los SPAMS no tienen adjuntos pero generalmente son grandes (desventaja)
5+ Traté de hacer "daos prune" pero no hubo caso. Recomiendan un prunning (clean del repositorio DAOS) cada mes... me parece mucho tiempo. El probelma es que el prune lleva mucho tiempo. Todavía me falta investigar cada cuanto conviene.
6+ Tengo que habilitar transaction logging.... me da la impresion que lo que ahorro de DAOS lo pierdo con transaction logging!!! Aparte para implementar transaction logging tengo que comprar un disco más.... (desventaja)
Acá terminé de evaluar DAOS. Personalmente no creo que funcione ya que no escala bien. Puede funcionar con un par de usuarios.... pero con muchos usuarios se torna difícil de mantener (tengo que mantener DAOS, transaction logging, etc...) aparte tengo windows y no sé como escalaría millones de archivos en Windows.