DAOS Part3 - Restores, Admin and Misc Info
July 31 2008
The questions and comments just keep pouring in, so here's some more on DAOS. In this post, we'll talk about how it works with replication, clustering and backups. I'll also mention a little bit about transaction logging.
So - as I mentioned before, DAOS is server-enabled. Therefore, in a cluster situation, each Domino server or partition would have to be DAOS enabled. Also, each server in the cluster set would have its own data store - sharing is not allowed. There is really no way to share DAOS stores across servers, as the current configuration of the feature has specific ways it stores things. If you used the same share across servers, DAOS would get confused, so to speak. So, please don't do it - bad things will happen!
Because of this, it's also not a good idea for you to restore a DAOS store from one server with the DAOS store on its cluster mate. While in theory, this should "work", as a rule it's not supported and again, "bad things can happen". To restore a DAOS store, do it from backup. There will be tools that will, in conjunction with backups from the transaction logs, restore and resync the DOAS store with its DAOS catalog and .nsf files. One such tool is the DAOS manager which will determine which attachments for a given .nsf will need restored. In essence, it will provide a list of missing attachments so you know what to pull from your backups and transaction logs.
Also, you might ask, why can't I just do an O/S level copy/paste of the .NSF files across clusters that are DAOS-enabled and not have to worry about restore procedures? Well, even though you can think of DAOS as just another storage device, you need to understand the "rules" of how it works. Because there are pointers to the .NLO files in more than one place, the best thing to do is to procedurally "repack" the attachments with the .nsf file. There is a compact command switch for this that will put the .nsf back into native form (putting the attachments back in). If you don't repack it and you move it to another DAOS server that is a replica or cluster mate, you can in fact run the resync tools to sync with the attachments on that cluster mate, but for 8.5 this will be a very long process. So if you need to restore an .NSF file, one way to do it is to repack it on the cluster mate and then create a new replica on the missing server.
I'm not sure if that explains the DAOS store very well, but we really don't have the "dirty details" to give right now about exactly how it works - "it just works"! As for your backup, well - the .NLO files will be treated like any other file on the file system, so as long as your backup program can backup transaction logs, you should be fine - no additional backup utilities needed. Please note that development is in process of writing a very good and thorough white paper on backups and restores that will describe best practices and procedures, more details on pruning, how you should do your backups, etc. As soon as I get the latest copy, I will provide more information. Again, suffice it to say, development will make sure that you can backup the files correctly and restore them without issue!
Also, I want to point out that DAOS should not interfere with all your 3rd party add-ins. At this point, DAOS works at a level below the add-ins, so they should not be impacted. So, all Domino applications on the server can use DAOS (including web apps) and not have an issue.
We've also had questions on if there is a CPU impact to running DAOS and the answer is yes - but a minimal one. For example, suppose you have an application that is used by a ton of users and has very large attachments. One of our readers pointed out that DAOS would have to compute a checksum against the attachment (thus reading it entirely). And, it's true that checksums are computed as the object is being written, so there will be a small CPU hit as that is done. However, it has not been shown to be significant at this time - and development has tested with some very large (and plentiful) attachments! Also, since it's all done in memory, there is no I/O hit to the server either. Oh - and the same goes for if you encrypt the DAOS store - memory and CPU hit, but no I/O hit. Let's face it - CPU and memory hits are usually not an issue to most of you out there!
That's it for today! Hope this has answered some of the other questions about DAOS! I think this also concludes my DAOS rant! Hopefully, next up in the lineup will be Configuration Tuner!!
So - as I mentioned before, DAOS is server-enabled. Therefore, in a cluster situation, each Domino server or partition would have to be DAOS enabled. Also, each server in the cluster set would have its own data store - sharing is not allowed. There is really no way to share DAOS stores across servers, as the current configuration of the feature has specific ways it stores things. If you used the same share across servers, DAOS would get confused, so to speak. So, please don't do it - bad things will happen!
Because of this, it's also not a good idea for you to restore a DAOS store from one server with the DAOS store on its cluster mate. While in theory, this should "work", as a rule it's not supported and again, "bad things can happen". To restore a DAOS store, do it from backup. There will be tools that will, in conjunction with backups from the transaction logs, restore and resync the DOAS store with its DAOS catalog and .nsf files. One such tool is the DAOS manager which will determine which attachments for a given .nsf will need restored. In essence, it will provide a list of missing attachments so you know what to pull from your backups and transaction logs.
Also, you might ask, why can't I just do an O/S level copy/paste of the .NSF files across clusters that are DAOS-enabled and not have to worry about restore procedures? Well, even though you can think of DAOS as just another storage device, you need to understand the "rules" of how it works. Because there are pointers to the .NLO files in more than one place, the best thing to do is to procedurally "repack" the attachments with the .nsf file. There is a compact command switch for this that will put the .nsf back into native form (putting the attachments back in). If you don't repack it and you move it to another DAOS server that is a replica or cluster mate, you can in fact run the resync tools to sync with the attachments on that cluster mate, but for 8.5 this will be a very long process. So if you need to restore an .NSF file, one way to do it is to repack it on the cluster mate and then create a new replica on the missing server.
I'm not sure if that explains the DAOS store very well, but we really don't have the "dirty details" to give right now about exactly how it works - "it just works"! As for your backup, well - the .NLO files will be treated like any other file on the file system, so as long as your backup program can backup transaction logs, you should be fine - no additional backup utilities needed. Please note that development is in process of writing a very good and thorough white paper on backups and restores that will describe best practices and procedures, more details on pruning, how you should do your backups, etc. As soon as I get the latest copy, I will provide more information. Again, suffice it to say, development will make sure that you can backup the files correctly and restore them without issue!
Also, I want to point out that DAOS should not interfere with all your 3rd party add-ins. At this point, DAOS works at a level below the add-ins, so they should not be impacted. So, all Domino applications on the server can use DAOS (including web apps) and not have an issue.
We've also had questions on if there is a CPU impact to running DAOS and the answer is yes - but a minimal one. For example, suppose you have an application that is used by a ton of users and has very large attachments. One of our readers pointed out that DAOS would have to compute a checksum against the attachment (thus reading it entirely). And, it's true that checksums are computed as the object is being written, so there will be a small CPU hit as that is done. However, it has not been shown to be significant at this time - and development has tested with some very large (and plentiful) attachments! Also, since it's all done in memory, there is no I/O hit to the server either. Oh - and the same goes for if you encrypt the DAOS store - memory and CPU hit, but no I/O hit. Let's face it - CPU and memory hits are usually not an issue to most of you out there!
That's it for today! Hope this has answered some of the other questions about DAOS! I think this also concludes my DAOS rant! Hopefully, next up in the lineup will be Configuration Tuner!!
