Logical Architecture

Introduction
In the previous blog in this series I introduced the new service architecture of SharePoint 2010. There are several changes and understanding these changes will drive both the logical and physical topologies of SharePoint 2010. When I refer to the logical topology, this means the logical organization of SharePoint services that will be used to satisfy the business needs. The physical topology is the installation and configuration of those services. The goal of both topologies it to provide a solution that is:
  1. Scalable
  2. Secure
  3. Maintainable
  4. Has high performance
  5. Fault tolerant
In this blog I will take these themes and apply them to various way in which SharePoint 2010 can be configured to support the logical topology. I will go into the physical topology in the next part.

The biggest change in SharePoint 2010 is the flexibility you now have with the configuration and re-use of services. In the initial blog about services, I identified several rules that you should know which will directly apply to how the logical architecture of SharePoint 2010 would be done. Here they are again:
  1. Multiple instances of the same Service Applications can be initiated within a farm.
  2. Service Applications are shared across Web Applications within a farm by Service Group.
  3. Some Service Applications can be shared across multiple farms while others cannot.
  4. Service Groups can logically contain Service Applications that reside in other farms.
  5. Web Applications have the flexibility to use multiple instances of the same type of Service Application (regardless of which farm hosts that service).
  6. Service Applications can have its data partitioned and only accessible to specific subscribers.
  7. Service Groups can be used to logically scale for performance, security and scalability.
In the following sections I have indentified some common scenarios for configuration of SharePoint 2010 logical topology based on these rules. It will not be possible in this blog to go over every permutation these rules.
As well best practices for the configuration of these services is still not very well known other than the information is being provided to us by Microsoft and our experiences with SharePoint 2007. However you should be able to take these examples and use them as a way to start doing some early planning for implementation SharePoint 2010.
Side Note – If you are familiar with some of the logical topology diagrams that are provided by Microsoft they usually include Application Pools in those diagrams. I have decided to exclude that from these diagrams to make understanding the logical topology simple. Albeit understanding how the Applications Pools are incorporated into the topology is extremely important (security and fault tolerance). Usually when architecting a SharePoint topology I start with understanding how I want to organize service to achieve the best possible performance, security and redundancy. Once I have that organized, I will then use Application Pools to help attain those tenants.

Single Farm Single Service Group
This first topology depicts a standard SharePoint farm that has a single service group that is shared across all types of sites. Any time new sites are added within this farm, they will have access to all of the services that are available in the Default Application Group.

Advantages:
  • Most simple architecture to implement.
  • All web applications added into the farm have immediate access to all the available services.
  • All services are grouped together and can be managed centrally.
Disadvantages:
  • Does not allow for isolation of data used within the services. This means that all websites have access to each other’s data.
  • Cannot create dedicate services for specific web applications.
  • Will not scale well because publishing and collaboration would be occurring in the same farm.
Recommendations:
  • This is an initial place to start as your configuration for SharePoint 2010. It can always be scaled or reconfigured to support more demand.
  • It would be recommended to make sure that each service that can be partitioned be made partitioned. Service partition is introduced in the first part of this series. This is important because it not possible to partition a service after has been created. If services are partitioned from the beginning you have the ability to create some isolation of data between site collections.
  • These sites could all be installed on a single web application but that is not recommended. It is better to created dedication Web Applications for each running within their own application pool. This provides long-term scalability.
Single Farm Multiple Service Groups
This second example is a reconfiguration of the previous farm; the difference is that multiple Application groups have been created. There is a Default Application Group which has some of the core Service Applications that can be used by all the sites. Some sites, however, will have dedicated services. You will want to have dedicated services for scalability, performance and security reasons and this will be covered later on from a physical perspective.


Observations:
  • First thing that is interesting about this configuration is you see the Managed Metadata Service is configured into each application group. One interesting thing we will see with SharePoint 2010 is better ability to manage the Information Architecture, a key ingredient for Governance. We now have the ability to create reusable Information Architectures across sites and farms as well as created dedicated ones.
  • Second you will notice that Search has been centralized as part of the default application group and has been made a resource to all the sites. This is because it is a resource intensive process and it is not likely you will be creating dedicated search farms for a specific site. Note that FAST search cannot be used in this manner. FAST can either be used behind the firewall or outside but the same servers cannot be used for both.
  • Third application services have been distributed and dedicated. For instance Excel Services, BCS, Access Service, etc. are broken out.
Advantages:
  • Supports the ability for multiple goals to be met in the same farm.
  • Provides the ability to have better isolation of services. This provides the ability to have a granular implementation that better support scalability, performance and security.
  • Allows for divisional, department, or program administration.
Disadvantages:
  • Complex configuration to manage.
  • Requires more Governance and administration.
  • Will require more hardware/virtual resources to host.
Recommendations:
  • This configuration is good for a small SharePoint implementation within a department, division or business unit.
Multi-Farm
In this farm configuration we have broken it out and created several independent SharePoint farms that still use central services farm.


Observations:
  • Sites have been separated into dedicated farms based on usage such as public internet, extranet, internet and intranet.
  • Each farm has dedicated application groups of services that specific to their use.
  • All the farms have access to shared services in central services farm.
Advantages:
  • There is a clear separation between the sites by placing them in dedicated farms. This is very important because publishing farms and collaboration farms have been separated.
  • Organizations can be segregated from each other and prevents the initiatives of one from interfering with the initiatives of another.
  • Farms can be configured with service groups that are specific to their needs.
  • Central services can still be shared across farms where it makes sense.
Disadvantages:
  • A more complex configuration that requires more considerable time to administer and govern.
Recommendations:
  • This is an enterprise farm configuration.
  • This configuration should be implemented when a company has the need to optimize administration and hosting at the enterprise level.
  • This configuration is needed when data and services need to be isolated but there is still opportunity for reuse.
Multi-Farm with Application Service Partitioning

This farm configuration introduces service partitioning into the pervious diagram. Service partition is introduced in the first part of this series. It is recommended that all services be partitioned when they are initially set up, even if one partitioned is only used. It is not possible to change a service to allow for partitioning after it has been started in an un-partitioned state.





Observations:
  • In this diagram you will see in Farm A both the Managed Metadata and Business Connectivity Services have been partitioned. Others could have but just selected these for discussion. Now Farms B through E and utilize partitions that are just for them and they will have isolation.
  • Notice in Farm D we were able to remove those services from the configuration. This makes the management of that farm less complex.
  • Notice in Farm E we kept the Managed Metadata service. There is nothing from stopping that and can still be considered completely legitimate. For instance the administrator in Farm C does not have access to Farm A, and all they are using from Farm A is a partition of Managed Metadata that all the farms are using. If that is the case, they may want to still have a Managed Metadata service in Farm C so that they can make tactical additions to the Information Architecture.
Advantages:
  • Provides even more granularity and isolation of data management within SharePoint 2010.
Disadvantages:
  • Again an even more complex scenario for managing services for an enterprise farm.
Recommendations:
  • Using service partitioning must be a strategy considered when setting up an enterprise SharePoint 2010 farm.
Hosted Partitioned Farm
The last farm configuration I will introduce to you is the concept of a completely hosted farm. This is a very interesting scenario because you were not empowered to do this very well with SharePoint 2007. Some SharePoint service companies provided SharePoint hosted solutions but given what was available in SharePoint 2007. Now with SharePoint 2010 and Microsoft Azure those limitations have been removed.





Observations:
  • This scenario should not just be considered for providing SharePoint 2010 hosted solutions by a services company. A company itself can consider creating a solution like this for creating on demand solutions for provisioning full farms in a rapid fashion.
  • This scenario would also make sense for a parent company that has many subsidiary companies that they want to service in an economical fashion.
  • As you will notice this approach heavily uses service partitioning. The goal is to make the farms as lightweight as possible.
Advantages:
  • Utilizes many of the enterprise best practices discussed so far.
  • Since partitioning is utilized, there is isolation of data between farms.
  • Governance and administration is centralized into a single location and is not spread across farms.
Disadvantages:
  • Because all services are centralized, it is not possible to create customizations at the farm level. This means that if a farm has a special functional, performance or security requirement it may be hard to support that requirement.
Recommendations:
  • If you are creating a hosted solution and the expectations can be set ahead of time this is a good approach. However this is very hard to do and more often than not there will be requirements that will require dedicated services within the farms. It is ok to set out with this in mind but you must remain flexible to support an architecture like the one in the previous section.
What’s Next
In the next part of this series we will continue this line of discussion but for the physical topology of SharePoint 2010. We will focus on what is a small, medium and large farms.
References
Subscribe to: Posts (Atom)