SnapManager for Sharepoint topology

[mdvillanueva]

Hello Experts,

I hope you can shed some light to these questions:

1. Do the front-end server need to have Snapdrive installed? If yes, do they necessarily need to have lun or just simply a session?

2. What if we don't plan to use the Sharepoing index server component and instead use Fast search server? will smsp still work?

3. Does SMSP Manager need Snapdrive (and sessions)?

4. Does Media server need snapdrive (and sessions) ?

5. Can SMSP Manager and media server be the same server?

5. Does the media server need to be connected via snapdrive to the same filer in which the database server has a session established? or it can be a filer in our DR site?

Thanks,

Maico

[beaupre · Accepted solution]

Maico,

Here are the answers to your questions:

1. SharePoint Web Front End servers do not need SnapDrive installed. The SMSP Agent creates a backup of the SharePoint components on the WFEs by streaming the data to the SMSP Backup Index LUN which is connected to the SMSP Management host.

A SharePoint Search Server will have SnapDrive installed on it to store the SharePoint Search index files. If the SharePoint Search Index files are not on a NetApp LUN, then you cannot backup the SharePoint search database. The search database and the search index are backed up as a set.

2. SMSP can backup FAST. SMSP will still work.

3. SMSP Manager should use a LUN to store Backup Index metadata and the streamed backups of the WFE data. Installing SnapDrive on this LUN helps facilitate the management of this LUN. The SMSP Manager communicates with the SMSP Agents (Control and Member). The SMSP Member agent communicates with SnapDrive and SMSQL to help create a backup depending on how the SMSP backup plan is configured.

4. The SMSP Media server should use a LUN for the RBS Index if you are using Archiver. If you use a LUN for the Archiver RBS Index, then you will need SnapDrive so that this LUN will be backed up via snapshot.

5. In some smaller configurations, you can have the SMSP Management server and the SMSP Media server be on the same host. You can also have multiple media servers.

6. The media server should be located near to the primary storage where the SharePoint databases are stored. The media server also plays the role in indexing the backup of the SharePoint content databases. If you are using SMSP Archiver, you will need the media server located near the databases because the data path for the Archiver involves the BLOBs going from the WFEs through the media server and then stored on the RBS Store CIFS share. Extender does not rely on the media service to externalize BLOBs to a CIFS share.

Thanks,
Mark

[mdvillanueva]

Hello Mark,

Thanks for the very detailed response! I do have some follow-up questions and I hope you wont get tired answering a newbie's questions.

1. you mentioned something about Sharepoint backup index lun. Is that a lun that is on the SMSP Manager to store the backups? I am under the impression that the media server is playing the role of keeping the metadata and streamed backups of the WFE. Does a media server have different role?

2. Our Sharepoint admin informed me that we won't be using Sharepoint Index server and instead use Fast Index server (we are establishing a MOSS 2010). So do you mean that is ok without the Sharepoint index server?

6. it looks like there is still alot of reading for me to do because I am still unclear with the role of the media server and archiver and BLOB.

Thanks again.

[beaupre]

Maico,

1. The SMSP Backup Index LUN is connected to the SMSP Manager server to store the metadata about the SMSP backups. The metadata is also called the backup index data. The backup index data can be created after the backup is created or during an SMSP maintenance job.

The SMSP media server service works with the SMSP member agent to index the clone of the content database (created by SMSQL) to create backup index metadata that is stored on the SMSP backup index LUN.

2. Since you won't be using the SharePoint Search, you can exclude the SharePoint Search database and SharePoint Search Index data from the SMSP backup plan. This also means that you don't need to put the SharePoint Search Index data on a LUN connected to the server that has the SharePoint Search role installed.

3. SMSP has an RBS provider that allows you to store SharePoint content outside of SQL server. The idea behind storing content outside of SQL is that you get better performance and scalability for SharePoint than storing and retrieving the data from SQL. RBS is an MS SQL API only available in SQL 2008R2 Enterprise Edition. The BLOBs can be stored in a LUN or on a CIFS share. Typically, the BLOBs are stored on a CIFS share on SATA disk. The CIFS share or LUN can only be on NetApp storage.

SMSP leverages RBS in two ways: Extender and Archiver. In the SMSP documentation, Extender and Archiver is considered storage optimization.

Extender has policies that can be applied to new or existing content that externalize SharePoint content via RBS based entirely on content size. The scope of an Extender policy is at the web application level. (A web application can have multiple databases, but usually just has one.) Uploaded content is converted into BLOB format by the SMSP provider on the WFE and stored directly into the CIFS share. Retrieved content is retrieved from the CIFS share and then converted back into the original file format.

Archiver is similar to Extender in that it can externalize content based on size, but also based on complex business rules. These rules can be where the content is located, last access time, last modified time, file name, etc. You can create custom Archiver rules as well as using built in rules. You use Archiver to age out content or to store content on NetApp SnapLock enabled volumes for compliance reasons. The value of Archiver is that you age out stale content based on business rules that are based on records retention policies within your company.

Uploaded content is converted into BLOB format by the SMSP provider on the WFE and sent to the SMSP media service for the Archiver rules to be applied. When data is Archived, the SharePoint administrator can set a property on the content denoting that the content has been archived and the document icon can be modifed to show that the content has been archived as well.

One Archived content has expired the BLOB and the stubs are deleted from the farm and are not restorable. It is recommended that you have careful planning and a robust records retention policy prior to implementing Archiver policies.

Thanks,
Mark

[mdvillanueva]

Mark,

Thanks again for another detailed explanation. Looks like extender and archiver are really useful. Which of the two do you prefer for an organization that is new to this, and base on the ease of setup? Or would you even recommend using it?

Maico

[mdvillanueva]

Mark

Another follow-up question: we have two WFE (load-balanced). Do I install the member agent on both nodes?

Thanks,

Maico

[beaupre]

Maico,

You will install the SMSP Agent on all WFEs. The WFE that has the Central Admin role installed will need to be configured as both a member agent and a control agent. All other WFEs will have the member agents installed. The Agents also install the SMSP RBS Provider on the WFEs.

With any feature in the product, you need to use it to satisfy a technical or business requirement. Extender is useful for when you want to keep the size of the SQL databases smaller so that you can use less FC or SAS disk while being able to store your content on SATA. Archiver is useful when you want to age out content based on record retention policies that you have set up.

Thanks,
Mark

[mdvillanueva]

Mark,

Thanks again for the expert opinion! We would probably go with the archiver since it can pretty much achieve what Extender can do, plus more.

Maico

[beaupre]

Maico,

I am glad to help.

Be careful in implementing archiver. If you are wanting to automatically age out sharepoint content, this is your tool.

Most customers end up using the Extender because they don't have the records retention policies in place.

Also, since the data path for BLOBs subject to Archiver policies goes through the media server, you will need to implement some kind of high availability for the media server. You can use Windows Clustering or virtualization HA.

Thanks,
Mark

[mdvillanueva]

Mark,

Thanks again. That advise about HA is a good one. Can you educate me some more on SMSP? What I don’t understand is, does it use snapshots the same way as SME and SMSQL does? I can’t find anything that says that says if it does.

Thanks,

Maico

[beaupre]

SMSP uses SMSQL to create the database backups of the SharePoint databases. SMSP leverages SnapDrive to create snapshots of FAST data and SharePoint Search Index data. SMSP makes API calls to the NetApp controller to create snapshots of the RBS data stored in a CIFS share or uses SnapDrive to create snapshots if the RBS Data is stored on a NetApp LUN.

The SMSP 6.1 Installation and Administration Guide provides a list of software required for the solution.

Thanks,
Mark

[mdvillanueva]

Hi again Mark,

Last time you mentioned that the SMSP media server service works with the SMSP member agaent to index the clone of the content database (created by SMSQL) to create backup index metadata that is stored on the smsp backup index LUN. I assume you are talking about the granurality indexing setting on this one, right?

I am currently using the SMSP Manager also as Media server. But right now i am using the Sharepoint SQL database server that has SMSQL as the granurality index server. It looks like it works but it seems like SMSQL treats the job as a restore? because I see notifications about a restore of the clone.

1. Can I continue to use the database  server to index the backup? does that mean the index gets save in the database server? base on what I read it gets saved in the backup index lun, is that correct?

2. If I use the media server as the granularity index server, does that mean I need to install SMSQL on the same server? is that ok even if SMSP Manager is also on the same server?

Thanks,

Maico

[beaupre]

Maico,

You can define an alternate SQL server for verification and cloning for indexes instead of using the SharePoint SQL server for verification and indexing.

The SMSP indexing behavior is controlled by the Restore Granularity setting in the SMSP backup plan.

To answer your questions:

1. You can use the SharePoint SQL server for verification and indexing, but it is a good practice to use a different SQL server for verification and indexing as this offloads the verifcation and indexing from the SharePoint SQL server. The verification process is SMSQL database verification based on DBCC. The indexing process involves the cloning of the content database from snapshot and the member agent with the media service indexes the content. The index data is stored in the SMSP Backup Index LUN.

2. If you want to use the SMSP management/media server as the verficiation and index server, you will need to install SQL, SnapDrive, SMSQL and the server will have to have iSCSI or FCP connectivity to the storage where the content databases are located.

If you decide to use the SMSP management/media server for verification and indexing, you will need to ensure that the verification and indexing activities do not affect Archiver performance. If you are not implementing Archiver policies, then you should be okay.

Please let me know if you have any questions.

Thanks,
Mark