Uncategorized

Windows Server 2008, SQL Server 2008 Disaster Recovery Notes with SharePoint Products and Technolgies

In recent months there has been a great deal of discussion and debate on disaster recovery and high availability with Microsoft SharePoint Products and Technologies and with the recent releases of both Microsoft SQL Server 2008 and Windows Server 2008 there are open opportunities to leverage components available natively to these technologies and compliment a SharePoint Products and Technologies disaster recovery design.

One of the most significant challenges has been overcoming latency penalties applied through distance between the active and passive datacenters, particularly with Microsoft SQL Server Log Shipping since we’re dealing with SMB and a synchronous process.  This is where both SQL Server 2008 and Windows Server 2008 come in…

SQL Server 2008 introduces backup compression which can be further integrated in the Microsoft SQL Server Log Shipping configuration (see also http://msdn.microsoft.com/en-us/library/ms188168.aspx).  By compression the Transaction Log backups and scheduling an aggressive backup schedule in the configuration and administrator can apply a general level of predictability surrounding the size and number of Transaction Log backups and make more efficient use of bandwidth where working with limited throughput and maintaining synchronicity is a concern.

To compliment a Microsoft SQL Server Log Shipping configuration, an administrator can leverage the improvements made to Distributed File System in Windows Server 2008 to optimize WAN performance when copying Transaction Log backups to a remote Secondary server instance.  Windows Server 2008 DFSR improvements include:

  • RPC Asynchronous Pipe vs. Multiple RPC Calls in Windows Server 2003 R2
  • Asynchronous I/Os vs. Synchronous I/Os in Windows Server 2003 R2
  • Unbuffered I/Os vs. Buffered I/Os in Windows Server 2003 R2
  • Low Priority I/Os vs. Normal Priority I/Os in Windows Serve 2003 R2
  • 16 Concurrent File Downloads vs. 4 Concurrent File Downloads in Windows Server 2003 R2

In this scenario, Windows Server 2008 DFSR would be configured with the Microsoft SQL Server 2008 backup and load shares as members of a replication group actively replicating Transaction Log backups generated in through the Microsoft SQL Server 2008 Log Shipping configuration.  The Microsoft SQL Server Log Shipping Copy job would be disabled permitting DFSR to perform replication between the shares.

So what about my Domain Controllers?

Windows Server 2008 introduces support for Read-Only Domain Controllers and additionally Windows Server 2008 DFSR improvements can be realized providing AD DS schema version 31.

Standard
Uncategorized

Database Mirroring, Notes and Considerations

The question of Microsoft SQL Server 2005 Database Mirroring (DBM) continues to be a topic of discussion in implementation with Microsoft SharePoint Products and Technologies, attached is a set of key notes and considerations to take into account when implementing DBM.

Before implementing DBM with Microsoft SharePoint Products and Technologies, you must first understand that many applications are not natively aware of a Microsoft SQL Server 2005 Database Mirroring architecture in most cases.  With most applications, to include Microsoft SharePoint Products and Technologies, the application expectation is to consume storage from a single, specific source – generally a single instance (named or default) or cluster resource.

High Availability and Connectivity

DBM provides high availability (HA) at the database level, wherein a failure of a database is recoverable through its failover partner.  In addition, DBM also provides HA at the server level in which hardware failure is recoverable through the individual databases’ failover partners.  In either scenario, the addressable database is that which is Principal, the Mirror database is in Recovery and cannot be addressed by the client application.  When database role reversal occurs, the addressable database resides on a separate physical instance, to which SharePoint is not configured to consume from.  By implementing Connection Aliases on the Web front-end computers using the SQL Server Client Network Utility, client connections can be redirected to the new instance hosting the Principal databases as a potential solution to these limitations.

In either scenario with DBM and Microsoft SharePoint Products and Technologies, due to the limitations as mentioned previously, a need to maintain database -> node majority is required – that being all databases as Principal should reside on the same SQL Server instance (think of it as a cluster group).  A bidirectional mirrored session, where one or more, but not all, databases reside on a separate physical instance as Principal will result in that content hosted in those databases to be unavailable to SharePoint (see the following illustrations).  In the event this occurs, the Web front-end computers Application Event Log will commonly provide two application events, not specific to the condition, but more over to overall database health.  The Event Id’s in this scenario are 3760 and 5586.  By monitoring for the occurrence of these events in DBM, you can diagnose when a condition exists where database -> node majority is lost and reactively restore majority on either node and where necessary updating the Connection Alias on the Web front-end computers. 

An additional configuration that can be implemented as had been commonly implemented with Windows Server 2000 Domain Controllers is leveraging WLBS to provide a single cluster resource that the client application will use to establish its connections; however, in this scenario you need to be mindful of the NLB state to ensure that connections are not distributed, but are specific to only one node in the load balancing rotation which hosts the databases as Principal.  The server instance hosting the databases as Mirror should be suspended in WLBS to ensure client connections are not passed to it which will result in client errors, generally, presented as "An unexpected error has occurred." in the user interface.

The following illustrations examine several possible database level configurations and notes regarding each.

Illustrations

image

In the illustration above, connections are established to the server instance where all databases are Principal.  In this scenario, connections will be successful and there are no issues in your topology.  Failover to the partner will require either updating the Connection Alias or resuming the node in the load balancing rotation depending on the configuration used to establish the connection.

image

In the illustration above, connections are established to the server instance where the majority of databases are Principal.  In this scenario, connections are successful; however, content in Database B will not be served since the database is in Recovery.  Failover to the partner will require either updating the Connection Alias or resuming the node in the load balancing rotation depending on the configuration used to establish the connection and establishing database -> node majority.

image

In the illustration above, connections are established to the server instance where all databases are Mirror.  In this scenario, connections will be unsuccessful.  Failover to the partner will require either updating the Connection Alias or resuming the node in the load balancing rotation depending on the configuration used to establish the connection.

Operating Modes

When running in high safety mode with automatic failure, implying a Witness server instance is configured in the DBM architecture, you should consider configuring the failover partner timeout value to a value that provides a level of assurance that the Principal database can sustain protracted issues, to include blocking, secure channel float, etc.  that may cause a bidirectional mirrored state inadvertently.  The default failover partner timeout value is 20 seconds, and generally 120 seconds offers increased level of protection with Microsoft SharePoint Products and Technologies.  To ensure database -> node majority and enforce failover only when a catastrophic issue occurs at the instance or server level, you should consider using the high safety without automatic failover DBM operating mode.  The high safety without automatic failover mode provides synchronous mirroring and requires manual intervention in the event one or more databases needs to be failover over to the failover partner.

Recovery Models

Another consideration when implementing DBM is that the databases participating in the DBM session must use the Full Recovery Model.  While Simple is the most commonly implemented Recovery model, you should keep aware that this may introduce operational complexity into your design and also ensure your operations staff and DBA’s are familiar with the Full Recovery Model.

In conclusion, before implementing DBM, you should consider the impact on your topology and understand the support boundaries as documented in White paper- Using database mirroring (Office SharePoint Server) or Using database mirroring with Windows SharePoint Services (white paper).

Standard
Uncategorized

Planning a 100,000+ My Site personal site deployment? Notes…

This topic has frequented my Inbox over the past months, planning a My Site personal site deployment for 100,000+ users.  In this post we’ll examine the issues and potential solutions.


First it is important to understand that while a My Site personal site is a site collection in basic form, it’s instantiation via a browser request or managed code results in significantly greater overhead than a traditional collaboration-type site collection.  The majority of overhead is presented through the numerous data building operations that occur both on the private and public pages associated with the template, private.aspx and person.aspx respectively.


The My Site private page (private.aspx) is considered to be a private view that hosts information specific to you (or the site collection owner).  This information is presented in part based on your membership in a specific audience in many configurations.  The private page also serves as a host to your documents, alerts and subsequent alert results.  Private.aspx also provides the capability to view your Inbox, calendar, and other Exchange views.


The My Site personal site public page is intended to present information to be shared with other users and contains information such as personal and professional interests, shared links and documents.  The public page also provides out of the box functionality that can be used to determine organizational similarities between the user requesting your profile and themselves (also known as the Organization Hierarchy Web Part).  Other comparative Web Parts include In Common with You and Memberships.


The result of these two unique views presented in a My Site personal site is approximately a 50% more costly public view when compared to the private view as a result of resource intensive operations required to build and present the profile information for a specific user requesting the My Site personal site public page.


The majority of the information that is presented on the public page is derived from the profile database, since that content is isolated to a single database there are no options to spread the load across multiple database servers.  The database is the smallest unit of file system representation for SharePoint and cannot be logically partitioned (clustered indexing strategy comes in play here); however, you can physically partition the database and stripe the data files across dedicated physical disks to gain parallelism which will help with data access I/O.


Topology


A distributed topology provides the most efficient mechanism to support a large number of My Site personal sites and is commonly comprised of two or more independent server farms supporting the associated Web applications from unique geographic regions.  For example, server farm A in Seattle hosts the My Site host Foo, and an audience defined in the Shared Services Provider for domain users in the North America region is configured to use the My Site host Foo as their trusted My Site host (Figure 1) whereas server farm B in Dublin hosts the My Site host Bar, and an audience (Figure 2) defined in the Shared Services Provider for domain users in the EMEA region is configured to use the My Site host Bar as their trusted My Site host.  This topology generally requires a parent Shared Services Provider to which server farms A and B are consumers, a local Shared Services Provider can be configured; however, certain profile replication mechanisms should be in place to keep the SSP’s synchronized.  In either scenario when user B who is a member of an EMEA based domain users group, e.g. EuropeDomain Users requests Foo, the audience membership is read and subsequently the user is redirected to Bar, this process conversely applies to user C who is a member of a North America based domain users group, e.g. AmericaDomains Users.


clip_image002


Figure 1 Trusted My Site host locations (Shared Services Provider administration)


clip_image002[5]


Figure 2 Configure Trusted My Site host location and audience


*An important consideration is the requirement to have two or more unique URI’s to supported the distributed topology, for example http://mysite in North America and http://mysiteemea in EMEA.


Planning


Consider RAID 0+1 or 1+0 sets to supported the Shared Services Provider database and define a subsequent scale-up strategy.


Consider running profile synchronization operations during non-core business hours.


Consider removing costly Web Parts and determine their overall business value, this may include Organizational Hierarchy, In Common with You, and Memberships.


Consider a distributed topology where possible.


Remember the sizeable fraction of visits to a My Site personal site are from that of the site collection owner themselves.


RPS – Throughput can decline as the number of site collections in a given content database increase.


Consider Kerberos where possible to improve authentication performance and reduce overhead.


Plan for capacity and ensure a proper governance plan is endorsed and implemented.


Resources


About My Site
http://office.microsoft.com/en-us/sharepointserver/HA011605561033.aspx


About Audiences
http://office.microsoft.com/en-us/sharepointserver/HA011603031033.aspx


Plan for software boundaries (Office SharePoint Server)
http://technet.microsoft.com/en-us/library/cc262787.aspx


Planning and Monitoring SQL Server Storage for SharePoint: Performance Recommendations and Best Practices
http://go.microsoft.com/fwlink/?LinkID=105623&clcid=0x409

Standard
Uncategorized

High-Availability and Disaster Recovery with Microsoft SQL Server 2005 Database Mirroring and Microsoft SQL Server 2005 Log Shipping for Microsoft SharePoint Products and Technologies

I’ve discussed on several occasions Microsoft SQL Server 2005 Database Mirroring with Microsoft SharePoint Products and Technologies as a method by which database mirroring can provide intra-datacenter high-availability; however, am frequently asked how Microsoft SQL Server 2005 Database Mirroring can provide protection from datacenter failure.  While possible, you generally do not want to geographically distribute your principal and mirror instances due to potential problems with maintaining synchronicity and bandwidth/latency constraints instead maintaining and intra-datacenter session to provide local fault tolerance; however, you can implement Microsoft SQL Server 2005 Log Shipping in conjunction with Microsoft SQL Server 2005 Database Mirroring to provide a standby copy of your databases in the remote datacenter.

General Assumptions

Microsoft SQL Server 2005 Database Mirroring is installed and configured in high-safety mode with a witness server (synchronous).

Mirroring w Witness

The illustration above depicts Microsoft SQL Server 2005 Database Mirroring in high-safety mode with a witness server.  SQL01p is the principal server, SQL02m is the mirror server, and SQL01w is the witness server in the Microsoft SQL Server 2005 Database Mirroring session.

Configure the Principal/Primary Server

Configure Microsoft SQL Server 2005 Log Shipping on the principal Microsoft SQL Server 2005 server using either the Microsoft SQL Server Management Studio or Transact-SQL for each database to be mirrored using either a backup share on a separate host server or local folder.

See notes on Log Shipping with Microsoft SharePoint Products and Technologies.

When the Microsoft SQL Server 2005 Log Shipping configuration has been applied on the Microsoft SQL Server 2005 Database Mirroring principal server, failover the databases to the Microsoft SQL Server 2005 Database Mirroring mirror server.

Configure the Mirror/Primary Server

Configure Microsoft SQL Server 2005 Log Shipping on the mirror Microsoft SQL Server 2005 server using Transact-SQL, Microsoft SQL Server Management Studio cannot be used to configure the mirror server where participating in a shared Microsoft SQL Server 2005 Log Shipping session.

When the Microsoft SQL Server 2005 Log Shipping configuration has been applied on the Microsoft SQL Server 2005 Database Mirroring mirror server, failover the databases to the Microsoft SQL Server 2005 Database Mirroring principal server.

NOTE When configuring Microsoft SQL Server 2005 Log Shipping on the mirror/primary server you will receive an error indicating a transactional log backup could not be generated because the database is in either NORECOVERY mode or STANDBY mode.  The error is expected due to the state of the databases and can be ignored.

Log Shipping

The illustration above depicts both the principal and mirror configured as log shipping primary; however, in this scenario only the principal generates log backups.  In the event failover occurs within the Microsoft SQL Server 2005 Database Mirroring session, the new principal (previously mirror) will begin generating log backups at the log backup destination used by the original principal.

When the configuration of Microsoft SQL Server 2005 Log Shipping has been completed on the Microsoft SQL Server 2005 Database Mirroring pair, the log backup job will on the principal server will generate log backups on the backup share that will be applied by the primary server, the log backup job on the mirror server will continue to execute though will not generate logs until failover occurs within the Microsoft SQL Server 2005 Database Mirroring session.

Resources

Microsoft SQL Server 2005 Database Mirroring

Microsoft SQL Server 2000/2005 Log Shipping

Standard
Uncategorized

Announcing the Beta Release of the SharePoint Capacity Planning Tool

After several months of work and very little sleep in between we are pleased to announce general availability of the SharePoint Capacity Planning Tool (Beta).


The SharePoint Capacity Planning Tool (Beta) provides a wealth of helpful information when planning a SharePoint Products and Technologies deployment; helping administrators, consultants, and IT Pros determine the potential required hardware investment(s) and topologies to support and meet requirements for availability and performance or even the affect of introducing additonal offices with their own unique bandwidth and latency constraints. 


Using the SharePoint Capacity Planning Tool (Beta) you can build topology models, run simulations, and generate reports that will help you evaluate and identify alternative solutions considering profile-based usage variations, content size and scope, networking technology, and availability requirements.


The SharePoint Capacity Planning Tool (Beta) provides both Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007 models allowing you to explore the unique characteristics of each platform and more effectively and efficiently plan topologies based on their respective infrastructure requirements.


To being using the SharePoint Capacity Planning Tool (Beta) or to learn more visit: https://connect.microsoft.com/programdetails.aspx?ProgramDetailsID=1602


I look forward to hearing your feedback and hope you find this tool invaluable in planning your SharePoint Products and Technologies deployment(s).

Standard
Uncategorized

Planning for *Additional* Storage with Microsoft SharePoint Products and Technologies – Recycle Bin

This will be the first of a series focusing on those areas of storage that are commonly overlooked when planning storage for Microsoft SharePoint Products and Technologies. In this post we’ll look at the native Recycle Bin in Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0 to understand its fundamental aspects and impacts on storage.

The Recycle Bin enables end-users to easily recover content deleted within a site collection and is configured in two separate and unique stages referred to as the 1st and 2nd stage each with its own configuration properties.

image

The 1st stage Recycle Bin is configured using a numeric representation that defines the duration an item can exist in the Recycle Bin (SPWebApplication.RecycleBinRetentionPeriod Property), the default value of this property is 30 days; while the assumption is often made that this number is unique to the 1st stage Recycle Bin, conversely it applies to both the 1st and 2nd stage Recycle Bins and is based on the initial delete date of the content.

The 2nd stage Recycle Bin is configured on a percentage of quota value or more specifically a quota allocation (SPWebApplication.RecycleBinRetentionPeriod Property) as opposed to a duration as with the 1st stage Recycle Bin. This quota is configured to 50% of the live site quota by default, for example, a Web application with a default quota template of 1 gigabyte applied to a site collection can potentially result in a site collection consuming up to 1.5 gigabytes in a content database or more so, a Web application can be 50% larger than planned.  Though the 2nd stage Recycle Bin can be disabled entirely, you should carefully consider the recovery costs that can arise when content is requested for recovery – many organizations choose to increase the duration an item can exist in the 1st stage as a mitigation strategy.

Windows SharePoint Services 3.0 uses an automated cleanup service based on the initial delete date of a specific item and applies to both the 1st and 2nd stage Recycle Bins enabled as a Timer Job (see illustration).

image

Controlling the size of the 2nd stage Recycle Bin is an essential practice to managing storage for a site collection. The automated cleanup service will purge both the 1st and 2nd stage Recycle Bins when the initial delete date for a specific item or collection of items has reached its configured duration. Reducing the storage allocation for the 2nd stage Recycle Bin to purge items as the configured quota is reached on a more frequent basis can provide for the better management of storage; however, again may increase recovery costs where content becomes necessary to be restored from a conventional backup resource.

Standard