NetApp SnapManager for SharePoint
*phew*
Finally got everything working with our SnapManager for SharePoint install. Here's a few gotchas for those brave souls about to embark on a similar voyage of the damned :)
Whilst the install is relatively straight forward, almost next, next finish infact the configuration is the opposite.
There are quite a number of requests for credentials during the install. I think we used just two accounts in the end, one for accessing the DFM and one to access SharePoint DBs.
Be aware that there is a "hidden" service running as a user account. We found that the password was not transferred correctly from the installation wizard to the registry for this account. Luckily there is a commandline tool to change the password.
sdcli dfm_config set -host <hostname> -user <username> -pwd <password>
As with all NetApp documentation. Read it. Read it and read it again. Then ignore the majority of it and look elsewhere. Forums offer much better examples and assistance than the offical documentation which has a confusing and counter intuitive layout.
SMSPS is nothing NOTHING like any of the other Snap Manager products (NOTE: See comment from Mark Arnold as to why!). SMSPS is a web based application with little or no progress indicators. Often you will "just have to wait" with out any signs of life.
Be patient.
Let storage requirements drive your design. It is recommended to have less than 30 DBs per LUN. I have taken that suggestion lower to 15DBs per LUN. More DBs per LUN could cause SQL timeout issues (I've not seen any in my experience). The entire LUN must be restored and mounted for each restore, so the smaller the LUN the quicker you can get back to "real" work :) (NOTE: Please see a much better explaination of this in the comment from Mark Arnold)
Get SMSQL working in your environment first. Don't even worry about SMSPS until you have SMSQL working flawlessly. This was our biggy.
Our main issues came as we didn't follow the cardinal rules.
Finally got everything working with our SnapManager for SharePoint install. Here's a few gotchas for those brave souls about to embark on a similar voyage of the damned :)
Whilst the install is relatively straight forward, almost next, next finish infact the configuration is the opposite.
There are quite a number of requests for credentials during the install. I think we used just two accounts in the end, one for accessing the DFM and one to access SharePoint DBs.
Be aware that there is a "hidden" service running as a user account. We found that the password was not transferred correctly from the installation wizard to the registry for this account. Luckily there is a commandline tool to change the password.
sdcli dfm_config set -host <hostname> -user <username> -pwd <password>
As with all NetApp documentation. Read it. Read it and read it again. Then ignore the majority of it and look elsewhere. Forums offer much better examples and assistance than the offical documentation which has a confusing and counter intuitive layout.
SMSPS is nothing NOTHING like any of the other Snap Manager products (NOTE: See comment from Mark Arnold as to why!). SMSPS is a web based application with little or no progress indicators. Often you will "just have to wait" with out any signs of life.
Be patient.
Let storage requirements drive your design. It is recommended to have less than 30 DBs per LUN. I have taken that suggestion lower to 15DBs per LUN. More DBs per LUN could cause SQL timeout issues (I've not seen any in my experience). The entire LUN must be restored and mounted for each restore, so the smaller the LUN the quicker you can get back to "real" work :) (NOTE: Please see a much better explaination of this in the comment from Mark Arnold)
Get SMSQL working in your environment first. Don't even worry about SMSPS until you have SMSQL working flawlessly. This was our biggy.
Our main issues came as we didn't follow the cardinal rules.
- Do not put any files other than DB and logs on the SnapDrive LUNs.
- Do not mix user and system DBs
- Split DBs and logs or don't. Do not mix strategies.
Nice article. I just have to correct (well, more elaborate on it really) something lest your readers be confused. When SMSQL needs to restore a database it does not restore the LUN. Instead it does a LUN Clone and then copies the database file from that clone over to the running LUN. So, the LUN can be as large as you want but IF you are in the business of doing frequent entire database restores you are going to want to run smaller databases. If you want a large database that's fine too because you can do a Volume SnapRestore. In that case you only put one, big (2 to 4TB big) database on one LUN in one FlexVol and do the VSR outside of SMSQL. It's all an architectural decision and of course, you can mix and match. You don't have to make one decision for the entire server and go with it,
ReplyDeleteIf you are just doing single item restores then SMSP interacts with SMSQL to do that without any significant data flying around.
If you want to put a site collection into the lab for whatever purposes you have FlexClone and it just doesn't matter how big the volume(s) is or are; the FlexClone is very quick and, again, moves no actual data.
And in case you readers were wondering what on earth we were smoking when we built SMSP compares to SMSQL and SME, we OEM SMSP from AvePoint where it's DocAve. A couple of other people OEM the product which is what you'd expect since it's the leader in the field of data protection and RBS provider in one.
Thanks again.
ReplyDeleteMy cousin recommended this blog and she was totally right keep up the fantastic work!
Sharepoint Remote Blob Storage
ReplyDeleteMy cousin recommended this blog and she was totally right keep up the fantastic work!
Sharepoint Remote Blob Storage
Hey Mitra, thanks.
ReplyDeleteHopefully some of my rants will help someone!