Another successful DAOS weekend
This customer was concerned over space on the Domino servers and having to always be on users to delete stuff, "a big email to a lot of users is bad".
The servers were migrated to new hardware and LZ1, document and design compression enabled. So the results below, add on 10-25% of additional savings for that.
Pre DAOS, total mail size of 517GB of mail.
Post DAOS (64k DAOS minimum attachment size):
Mail file NSF total size : 151.2 GB
DAOS folder size : 157 GB
Total Post DAOS size : 308.2 GB
This gives a DAOS total savings percentage of around 40%. Now, it is worth pointing out that all other compression settings were already enabled, and as such added another 15-20%. Now that DAOS has been around for a while, we're starting to see some big seat number customers moving to it (>2,000 seats in my world). And boy, are they loving it!
If you need more convincing of the potential storage savings of DAOS, see the right side navigator for Real World DAOS Results and see what actual Lotus Notes and Domino customers are saving.
Discussion for this entry is now closed.
Comments (7)
@1, while I can't comment on your particular situation, I have seen occasions where the catalog needs resyncing often (far too often). In these situations we just ignore it and run a weekly (or monthly) command to resync it. There were some fixes in 8.5.1 FP1 IF1 that purported to address some of these issues, but I have yet to see proof and there should be an 8.5.1 FP2 IF1 pretty soon to migrate these fixes to FP2.
Some items I "think" may cause this issue are:
1) DAOS being on the same drive as Domino AND high mail volumes
2) TX Logs not being big enough (100MB default? Really IBM?)
3) TX Logs not being on a separate drive.
You must have a huge throughput of email (new email, large number of attachments, large amounts of deleted email) if a "needs syncroinizing" DAOS catalog causing an OVERALL increase of mail sizes. Now that I have not seen, but I've not seen a lot of things. Still, you live and learn.
The attachment sizes and volume thereof are fairly large AND the DAOS store was on the same drive as the Domino data. Combined with jornalling on the server you might have hit the nail on the head there. We also used 4K+ as the DAOS starting point which was probably too low...
If we try again we will use 64k+ and a different RAIDset for the DAOS data files.
The TX logs were on their own RAID 10 set with plenty of space
Thanks,
Charles
You may want to run the DAOS estimator on the server to see the best min-size to savings ratio. On huge attachments counts it could even be upped to 128KB. Also if you are on an i5, the min should be 1MB.
We've a huge archive server with over 1000 archives mailboxes with average size of around 10 gigs. The total server storage is over 3 TB and we are running out of storage fast. We could add more disk but looking for a solution that would cut the backup time as well as the storage. We can't delete old emails just yet.
We started to pilot with DAOS but one draw back we see if that if we were to restore a nsf file that has been deleted for sometime, the restoration of the nlo files would be extremely difficult unless we restore the entire DAOS directory. In one test, we enabled DAOS on a 25 gig nsf file. After the compact completed, the nsf went down to 3.5 gigs but we ended up with ~ 17 gigs of NLO files totaling just over 38,000. Setting the nlo size to 2 megs didn't result in much saving. Next I'll be testing with 1 meg nlo file size.
Any thoughts or recommendation on file restores?
@5, DAOS on a single mail file on a given server will not yeild much in the way of significant disk savings. This is obvious if you think about, how many of the exact same attachment do I have in a single mail file? Maybe 3 to 6 copies, most of the time 1 or 2. Where the real space savings in DAOS come from doing 100's or 1000's of mail files on the same server. That is where you will see 45-65% savings per server, but this is overall, not per NSF file.
For backup I don't see an issue. If you restore an NSF, you can have DAOS tell you what NLO files are missing, then pipe this into your choosen backup program. See this post on how to restore - http://blog.darrenduke.net/Darren/DDBZ.nsf/dx/daos-my-2-cents-and-a-possible-future-and-how-to-back-it-up.htm?opendocument&comments
@6, I read your post on the backup & restore... good information there.
Concern I've is, if I'm restoring a nsf file that has few thousand nlo files, it would be a very tedious process to locate and restore them from the backup tape. It would be nice to have a separate folder for each nsf where nlo files would be kept, unless those nlo's are shared among multiple nsf files. I guess they could then go under a shared folder.
We have been operating a DAOS 8.5.1, +FP1, +FP2 environment for 400+ users and the primary mail server DAOS catalogue needs resyncing every 2 hours or so and takes up to 1.5 hours to do it. On our DR server it only loses sync once every couple of days. We were left with 155GB of mail occupying 245GB of disk including the DAOS files!
We have nearly completed the de DAOSing and the server is running much better. We used the excellent built in archiving instead on the DR server to save the space and the users and finance dept. are now both happy!