IBM DOMINO ATTACHMENT AND OBJECT SERVICE
IBM introduced Domino Attachment and Object Service (DAOS) with their Domino server 8.5 (and later) as a way of saving significant space at the file level by sharing data that is identical between databases on the same server. The Domino server, for DAOS enabled databases, saves document attachments on itself in NLO files (DAOS repository) and saves a reference to each attached file in an NLO file. Then it refers to the same NLO file from multiple documents in one or more databases on itself. Practically, if you broadcaseted an email with e.g. 5Mb attachment to 1000 users, instead of having this single attachment in 1000 mailboxes generating 5000Mb (5Gb), this attachment is stored in DAOS repository and NLO pointer is inserted in the messages for these 1000 mailboxes storing only this single 5Mb attachment onto the Domion server.
Same attachment saved once
Reduced data on server
Improved performance
Reduced Backup data
Best for Mail and Doc Libraries
Best of all - It is FREE
The Challenge
Mailmeter as journaling solution in house but never enabled for attachments – limitation, attachments not available to mobile users if archivde hance archiving feasible only for messages older than 1 yr. Users replying or forwarding same attachments over and over. Users believing that each message they receive is important and needs to be preserved for years of their professional work. Work mailboxes used for private messages, fun at work or even saving other attachments like Word or Excel documents, pictures and so on. Practically the mailboxes are doubling in size each year requiring to rely on SAN solution for disk expensions. Backup jobs are running longer and longer, running into business hours and drastically degrading the mail servers performance and end users’ experience in working environment. Each cluster mail server has to be backed up, doubling, tripling or multiplying the same backed up data.
The Solution
DAOS.
Implementing on 3 Domino mail servers. Analysing and balacing the best ratio between minimum size of attachments vs total environment saving – it does not make sense archiving each single attachment, e.g. under 32kb or less. Our optimum ratio was 64kb. Readjust backups cycle and restore procedure. Communicate to users – not needed as they wouldn’t see a single change, nothing changes, even the icon of the attachment is the same as in the original message. Replication issue with other Domino servers – not at all, the attachments are pulled before the data is replicated across network. Even better, if the receiving server has enabled DAOS and has the same attachment, the replica will send the document across to the destination without the attachment. That’s correct – saving network bandwidth even more.
The Results
Total data per single Domin mail server reduced from some 3TB down to roughly under 700GB including the DAOS repository with all collected attachments. Huge savings in data storage (remember, disk space from SAN systems), reduced backup run-time from over 28-30hr down to under 2 hrs – with the incremenatal backup, full only once a week, and still taking under 6-8 hrs. And best of all, users never noticed any difference nor were aware of such feature in their environment.
Simple calculation:
Without DAOS ==> 3 servers requring 3Tb per server + 20-30% required disk space for optimum run = > 10.8-12Tb from SAN
With DAOS ==> 3 servers 0.6Tb + 20-30% required disk space for optimum run => 2.5-2.8Tb from SAN
- Recovered space 100%
- Cost – Free 100%
- Best disk tool 100%