Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Like this? Share it with your network

Share

Best Practices for Content Lifecycle Management with MS SharePoint

  • 1,783 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,783
On Slideshare
1,783
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
23
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Now we come to Connecting…
  • Going back to the importance of Information architecture- some main considerations, among other things, include determining the businesss goals that you have for SharePoint, not just deploying SharePoint to deploy it, but whare are you going to accomplish with it that you weren’t getting before? And then deciding on that structure and taxonomy, and then you always want to make SharePoint your own, and a good way to do this, and to control the manageability, is to standardise branding with templates and master pages. Other considerations include making sure you have accountability of your published content using workflows and approvals.
  • MLM – This diagram maps out data growth over a period of time in a collaboration environment:Electronic data will continue to grow year over yearInactive data growth outpaces growth of active, operational dataHowever, most of the data is actually inactive or stale data, which is the area in between the two linesIn SharePointConsider your work on a design documentThrough drafts and edits, multiple versions are being created. Ex. Up to 32 versions of a document, if each document is 2.5 MB, full version history takes up 80MB.When document is approved, initial 30 versions no longer needed and can be archived awayConsider project sitesProject sites bring groups of people together to work on related documents, task lists, discussions, etc.Within each org, there could be hundreds of projects that get completed each year. But entire project sites still reside on SharePointAs inactive data continue to grow, resources required for current active data is saturated by inactive data. Users experience diminishing service levels (i.e. performance degradation)Additional hardware, servers, processing power may be needed, As databases continue to grow, this would also impact the current SLA’s for backup and recovery windows that are currently in place.
  • There are several things you need to take into consideration when planning for how much storage you will need to allocate to SharePoint content.
  • There are a few basic ways to manage storage growth in SharePoint. First things first, set site quotas and alerts, we always recommend a 10 GB limit and 8 GB alert. This is going to let you stay on top of which sites are growing more quickly so you can plan future structure accordingly. Next is to monitor growth trends. Pay attention to how quickly your sites are growing, and then don’t forget to monitor the overall Content DB size. Finally, depending on growth, there’s a very good chance you’ll need to split content DB’s if they get too big. Now, what is “too big”? We’ll get to that in a minute, as there are several recommendations based on your concerns… First though, we’ll look at a couple of ways to control growth of content DBs…
  • By realizing how a site “chooses” a content DB, you can actually assign a site a content DB as its created. The link here describes the content DB selection process, but essentially, a site, upon creation, will attach to the content DB that has the greatest availability. Other factors come into play as well, such as if a content DB is running or not, so an option here would be to shut down all content DBs except the one you’d like your newly created site to go in.
  • Now, to the question we had early- how big is “too big” for content DBs? As previously mentioned, this depends on your concerns. If you’re most concerned about backup and recovery operations and you’re using a database-based backup solution, you really shouldn’t go over 100 GBs, even then you’re pushing it, as you need to make sure that you can recover your database in time to meet various SLAs. However, there are other tools out there, like the one AvePoint offers, that can leverage snapshot technology to greatly enhance the speed of backups and restores. This might also depend on your hardware. If performance is your main concern, then you might can let the size get a decent amount larger. The thing with performance, though, is this is not just going to depend on the database size, but also the # and size of objects, how heavily nested your site structure is, and once again, hardware. Obviously the goal for storage cost is to keep it as small as possible while allowing for proper backup and recovery windows and optimal performance. These are really considerations, but still we have the question, ‘what is “too big”? Which will have to come from your own organization’s policies and plans. Next we’re going to take a look at what’s actually being stored in Content DBs and evaluate ways to further optimize storage besides the few native tools already mentioned… Which brings us to the subject of BLOBs.
  • Why are we concerned with BLOBs? If the size of content DBs affects critical aspects of SharePoint- backup and recovery windows, performance, cost, then lets evaluate what the content in the databases consists of and what’s necessary and what’s not.
  • Here’s a look at a very basic SharePoint architecture. Here we have the front end with the object model, and the SharePoint content (blobs and metadata) are stored in SQL.
  • Already we’ve talked about how the size of the Databases affect these key areas…
  • MLM – This diagram maps out data growth over a period of time in a collaboration environment:Electronic data will continue to grow year over yearInactive data growth outpaces growth of active, operational dataHowever, most of the data is actually inactive or stale data, which is the area in between the two linesIn SharePointConsider your work on a design documentThrough drafts and edits, multiple versions are being created. Ex. Up to 32 versions of a document, if each document is 2.5 MB, full version history takes up 80MB.When document is approved, initial 30 versions no longer needed and can be archived awayConsider project sitesProject sites bring groups of people together to work on related documents, task lists, discussions, etc.Within each org, there could be hundreds of projects that get completed each year. But entire project sites still reside on SharePointAs inactive data continue to grow, resources required for current active data is saturated by inactive data. Users experience diminishing service levels (i.e. performance degradation)Additional hardware, servers, processing power may be needed, As databases continue to grow, this would also impact the current SLA’s for backup and recovery windows that are currently in place.
  • Now we come to Connecting…
  • To optimize storage, we can essentially look at two major concepts. We already discussed earlier how BLOB’s don’t contribute to SQL queries, so essentially there’s no need to keep them in the database. So the first option is to move the BLOBs out of the database. The way to do this is to leverage Blob Services APIs. The second option is to Archive content, which currently there are no native tools for, so you’d have to look at a 3rd party.
  • JohnAside from EBS API, no way to move BLOB contents off of SQL – providers not offered by SharePoint, requires 3rd party tools
  • Along the lines of the first option… move BLOBs out of the database, we can extend content.
  • There are 2 available APIs for extending content out of SQL. 1 is SharePoint specific, it’s the EBS API. The second, is SQL specific, it’s the RBS API. So which one do we use?
  • Here’s a quick overview of the EBS and RBS APIs
  • So if we leverage EBS… this is how the SharePoint architecture would change. The provider sits with the SP object model, and gives SharePoint tokens or stubs so it knows how to retrieve the content and maintains the context of the content. The metadata is stored in SQL, BLOBs go to a storage location of your choosing. This is completely transparent to the end user.
  • However, there are some things to note about EBS. As it is implemented by SharePoint, there’s only 1 provider allowed per SharePoint farm. There’s a chance that you could run into orphaned BLOBs, and then there are also compliance concerns.
  • So now let’s take a look at RBS… As RBS is SQL specific, it can be used across applications that leverage SQL, not just SharePoint, so this gives you more of an enterprise-wide storage architecture versus EBS, and here’s how enabling an RBS provider would affect your SharePoint storage architecture. You can have an RBS provider per database. No context, no ability to manage the object
  • As with EBS, there are some things to note with RBS… one of the main benefits is the ability to mange RBS viaPowershell, which MSFT is highly encouraging the use of over STSADM, as I believe they’re eventually doing away with STSADM.
  • Natively with SharePoint 2010, MSFT offers a RBS provider, FILESTREAM. However, it does not recommend using this with very large databases in production. To leverage this feature, you’d have to 1, 2, 3, and then 4, so you would need admin privileges on SQL and Windows server. STORAGE LOCATION IS FILE SYSTEM ONLY!!
  • So again, looking that the two blob services available, which is better, with EBS we have tighter application integration, allowing for more rules and settings to determine which BLOBs are offloaded, and then you have RBS…
  • Which is simpler, and allows for a more unified storage architecture across applications, it’s not SharePoint specifid….
  • At this point, looks like RBS is the way to go… As EBS is SharePoint specific, there’s been no guarantee that in future releases they will continue to support such an API. With RBS, we know that MSFT has bought in to this API as it’s telling customers that it will provide a powershell solution to migrate from EBS to RBS, hence, any solution leveraging these APIs should account for this.
  • So once we leverage Blob Services APIs to offload BLOB out of SQL, these are the impacts that we’ll see relative to our previous concerns regarding Backup and Recovery, Performance, and Storage.
  • If you understand this, you understand EBS as you talk to customers and how it integrates with other systems:Examples – new search providers like Google, COVEO, FAST search- Workflow providers like Nintex, K2, ETC
  • We like the concept of incorporating cloud storage as a sort of ‘overdraft protection’. Typically, with Cloud storage, it’s cheap to setup but more expensive to use. Compare this with overdraft protection for a checking account… typically it’s free even to set up, but if you use it, if you overdraw and your bank covers your charges so it goes thru, they’ll slap you with a fee, that’s often times not tiny. So think of this scenario… I’ve got my content DB limit set at 100 GB. I get an alert at 80 GBs, so I start planning how to rearrange site structure, split the DB so I won’t hit the limit. But what if in the meantime, I hit my limit? Well nothing happens at 100 GB, but as I go over, if I still haven’t had time to split my DB, cloud storage will be leveraged, allowing all operations to continue, nothing will fail, and this allows you to continue to split up your DB as per usual. OK, so that’s a scenario of leveraging BLOB services APIs to extend content… lets look at some other options for storing BLOBs out of SQL.
  • Now we come to Connecting…
  • John
  • So how do we go about not creating the BLOB issue? And why would you want to connect something to SharePoint instead of migrating it in and extending it later? There are several considerations that come into play when deciding whether or not to migrate data into SharePoint. First, value add of legacy system- are you getting some functionality or capability with your legacy system that you CAN”T get with SharePoint? Then maintenance costs… Hardware that goes with legacy system, cost of not only licensing and support, but also personnel on staff to maintain the system. Then you have to look at migraton costs- thru the process, will you have major interuptions to business processes? What tools will you need to migrate? And then training your users on how to use the new system.
  • There are multiple architectures for geographically dispersed farms, but at a high level we can narrow down to the most used configurations;
  • Tlanni: Scratch the cubeDifferent user experiences
  • Centralized architecture but we allow local content and sites in addition to the Main Farm;It will increase infrastructure complexity and governance process;Mobile Users= PAIN
  • A fully distributed global architecture will provide quick access to local SharePoint content with good user experience;You want to replicate only the relevant/global content You also want to handle special remote location (like the Alaska oil ring in this slide) via local Infrastructure and replication; Requires 3rd party tool
  • Another flavor of a distributed architecture with Centralized Backup and Cloud Storage;We can backup locally or to an alternate site;We can back up to the Cloud ;All available options build high redundancy for our SharePoint frams;
  • Now for Option 2… Archiving… so option 1, of not storing blobs in database is the most basic, or “good” scenario out of good, better, best, for SharePoint storage optimization… but you still want to keep that content on tier 1 storage. To put complete lifecycle management onto content, you need to add archiving to offload content to lower tiered storage.
  • MLM – This diagram maps out data growth over a period of time in a collaboration environment:Electronic data will continue to grow year over yearInactive data growth outpaces growth of active, operational dataHowever, most of the data is actually inactive or stale data, which is the area in between the two linesIn SharePointConsider your work on a design documentThrough drafts and edits, multiple versions are being created. Ex. Up to 32 versions of a document, if each document is 2.5 MB, full version history takes up 80MB.When document is approved, initial 30 versions no longer needed and can be archived awayConsider project sitesProject sites bring groups of people together to work on related documents, task lists, discussions, etc.Within each org, there could be hundreds of projects that get completed each year. But entire project sites still reside on SharePointAs inactive data continue to grow, resources required for current active data is saturated by inactive data. Users experience diminishing service levels (i.e. performance degradation)Additional hardware, servers, processing power may be needed, As databases continue to grow, this would also impact the current SLA’s for backup and recovery windows that are currently in place.
  • Natively, SharePoint offers the records center. If you’re leveraging the Records center, be aware that it is essentially just another location, still in SQL, to store content. The best practice here would be to put the records center on its own database, and leverage RBS to offload content. Now, archiving… natively, I mentioned there were no tools, but in reality, you could essentially just create backup files of the content you’d want to “archive” and then delete them out of SharePoint. OR, you look at 3rd parties, like AvePoint’s DocAve Archiver to build business rules into your archival plans.
  • If I had to take away 4 main points from today…. These would be them.
  • I’d also like to briefly introduce some applicable AvePoint tools to help you better monitor and manage growth of your Content DBs.
  • Now we come to Connecting…
  • Thank you for participating to this and don’t forget to fill in the evaluation;Now we will open the floor for Q&A;
  • Here are additional resources… whitepapers on how to set up Filestream, a white paper on storage optimization sponsored by AvePoint, etc
  • Implement ISystemUtility, IConnectionManager, and ITypeReflector interfaces (only ISystemUtility is mandatory). Potentially, one can also override default connection manager and EntityInstance interfaces. In addition, implementing IAdministrableSystem provides Administration UI property management support and implementing ISystemPropertyValidator provides import time validation of LobSystem properties (not on the Microsoft Office client).Compile the code in step 1 into a DLL and place it in the global assembly cache on the server and clients.Author the model XML for the custom data source (SharePoint Designer 2010 does not support a model authoring experience for custom connectors).At run time when a user executes a BDC operation, this invokes the Execute method in the ISystemUtility class. Thus, the responsibility of executing the actual back-end method is given to the Execute method (as implemented by the custom connector).