SMMOSS Questions

[tanweer]

Hi All,

Sorry for the wide distribution.

IHAC who is interested to deploy SMMOSS to their SharePoint environment. Can somebody shed some light on the following questions:

·         Is there any best practice around splitting the content DB ( 1 year projection is around 16 TB)  that would allow them to have different snap and retention schedules.

·         Can I direct the SMMOSS Index to a CIFS repository? Pro/Con with this approach

·         What is the rate at which the SMMOSS Media server can ingest files while it is performing an index/catalog to facilitate item level restores. This would allow us to size the smmoss media server lun/volume.

• Is geo-cluster supported by NetApp, SMMOSS,      SMSQL?
• Any reference      sizing documents for large SMMOSS deployments

Any comments/thoughts will be appreciated.

Thanks

Tanweer Eqbal
Professional Services Engineer
PS - Australia

NetApp
+61 2 9779 5651 Direct
+61 410 712 224 Mobile

Tanweer.Eqbal@netapp.com
www.netapp.com

[sourav]

Hi Tanweer,

1. Could you clarify by what you mean by different Snap and Retention schedules. Note that even if you split the Content DB into multiple parts, SMMOSS will always be backed up together as a part of a single backup plan. This means that all the Content DB's will share the same retention policy. Microsoft typically suggests that Content DB should be no larger than 100GB (soft limit) but in your case we can create atleast 8-10 to ease the load. Do not split it any further unless there is an obvious performance gain since databases in a group are backed up sequentially by SMMOSS and SMSQL. In you case you may want to implement the best practices of deploying large databases on NetApp storage. I believe there is a TR for that. Please check.

2. Yes you can absolutely place SMMOSS indexes on CIFS repositories. Assuming that the CIFS share is based on an NetApp LUN, there are no particular Pros and Cons except that I believe that I/O is better for LUNs presented directly to the host (please confirm with CIFS expert). Follow the best practices mentioned in TR-3776.

3. Typically the Media Server can index data at the rate if 30-40GB per hour. Again, the thumb rule here is that unless you

4. The above point has not relation to sizinjg the SMMOSS Media Server LUN. Follow the sizing guidelines in TR-3776.

5. Contact Mike Klass or Mike Noble for customer references.

ReRegards,

S  Sourav

·     

[sourav]

Sorry, I have accidentally forgotten to complete point 3 in the previous reply. Here is the rest of the sentence: -

Typically the Media Server can index data at the rate if 30-40GB per hour. Again, the thumb rule here is as follows: -

1. Check the number of backups that need to be indexed. The time taken per backup (in hours) = (0.1 * Number of items * Number of versions * Avg. Size per item in MB) / (40 * 1024). I have assumed 10% metadata in the above formula and hence, the numerator has a factor of 0.1. The denominator is the MB equivalent of 40GB.

2. So consequently you'll have to decide the number of Media Servers by looking at the number of backup that need to be indexed by SMMOSS and at what granualrity level. This calculation should also take into account the backup window. If you give me this information then I can work out a number for you.

Regards,

Sourav.