Design Microsoft Infrastructure Using a Prescriptive Architectural Approach
The Infrastructure Planning and Design guides complement Microsoft’s step-by-step product documentation, with an architectural design approach. The guides lead you to an infrastructure design that is optimized for your performance and fault tolerance requirements and is right for your business.
Microsoft provides extensive documentation for its infrastructure products, including the newly-released Windows Server 2008 R2. The documentation walks you through how to install and configure the server in all the detail that you could possibly want, including screen shots of the click-by-click process.
But how do you decide how many servers you need? Will just one do the job? If you need more than one, how big should each one be? Where should you put them? And what would happen if one of them failed?
The Infrastructure Planning and Design (IPD) guides lead you to the answers to these questions. Notice the wording here…the guides lead you to answers. Rather than providing the answers directly, the guides aim to walk the reader through a process to arrive at an infrastructure design that is right for their business and IT environment.
To date, the IPD team in Microsoft has delivered guides for many of the Microsoft server products, as well as a number of technology selection guides. An IPD technology guide leads the reader through an architectural approach to the infrastructure design by covering the following:
What is the scope of the project?
The key to beginning an effective infrastructure design is understanding what the technology must deliver to its users. An IPD technology guide leads the reader through determining what functionality is required, so that a design can be created to meet, but not exceed, that requirement. This is particularly important where a single product is able to provide a lot of functionality, such as Microsoft System Center Configuration Manager 2007 R2 (SCCM). The IPD guide for SCCM includes a table that enables the reader to map the function they require to just the parts of the product that they’ll need to design. That ensures the lowest cost design that does not over-deliver.
The technical requirements are used to determine the scope. These are then reality-checked against the business requirements and the business climate, since a significant business event such as a recently-completed acquisition can significantly alter the scope of the infrastructure design project.
What are the components that make up the technology?
The moving parts of the infrastructure and their relationships to each other are presented in pictorial form at the beginning of the guide. For example, the figure below shows the infrastructure for Microsoft Enterprise Desktop Virtualization (MED-V).
Figure 1. The Infrastructure components of MED-V
Understanding the components and their relationships and dependencies is critical to the architectural design that follows.
The IPD guides provide a short description of each component, to explain its role, importance, and dependencies. But the guides assume knowledge of the technology, and do not replicate the product documentation, rather they complement it. Links are provided to additional reading in case you need to study up on some part of the product.
When do you need each component and when do you need more than one of them?
The guides walk you through determining whether you need each of the components. This usually involves a definition of what constitutes an “instance” of the product. The scale limitations of the instance are listed, so that you can map them to your scale requirements, to decide whether one instance will be enough. Sometimes the scale limits of the infrastructure components are not readily available from the relevant product group. In these cases, the IPD guide provides pragmatic guidance based on the role that the component must perform. This same process is repeated for each of the components in the instance, for example the SQL database on which all Microsoft infrastructure products depend. If the demand on one of the components in the instances is greater than that component can support, design of additional instances will need to be added to the design..
Where should each component be, and why?
Should the SQL server be on the same machine as the primary server? Should they be on the same LAN segment, or can the SQL server be remote and even on a machine that is shared with other servers? The IPD guides use product group recommendations, where those are available. If they’re not, the approach is to quantify the load on the SQL server and other components, to determine their location and network connectivity. If that is not possible, pragmatic guidance is provided on what makes sense, given an understanding of the role that the component plays in the infrastructure.
What are the performance requirements of each component?
Here again, SQL server provides a great example. There are always two design inputs for sizing the SQL server infrastructure: how big should the database be, in GB, and what should its throughput be, in IOs per second (IOPS). Throughput is extremely important but sometimes neglected. In general, IO throughput is increased by using a large number of small disks, rather than a few large disks. That’s because most IO activity is short bursts of data transfer from different files; the actuator must be moved to a different place on the disk for each transfer. Fewer disks means fewer actuators and therefore fewer transfers in parallel. There will be competition for the actuator and a queue will build up.
Can it all be run on a single server?
The IPD guides adhere to an important architectural principle: keep things simple. A technology guide states whether it is possible to run all of the infrastructure components on a single server. Even if the components cannot be run together on a single server, it may be possible to run them on a single physical machine, by running them virtualized, in different virtual machines. The IPD guide states, when it’s known, whether each of the components is supported in a VM.
Should it all be run on a single server?
Just because all the components can be run together on a single server doesn’t mean that it makes sense to do so. Additional servers may need to be added to the design for both technical and business reasons. An IPD technology guide helps the reader map the capabilities and limitations of the technology against their requirements to arrive at a design for the smallest number of servers required to do the job.
Additional infrastructure may be required because of the size of the project. It may also be required to provide fault tolerance. The fault tolerance requirements of the business are collected in the first step of a guide and as the design is created the reader maps those requirements against the fault tolerance capabilities of each component in the infrastructure.
Business requirements may also necessitate the design of additional server infrastructure for regulatory, political, geographic, and sometimes language localization reasons. IPD technology guides lead the reader through incrementing the design to account for these.
The Design Flow in IPD technology guides
An IPD guide leads the reader through completing the infrastructure design in a series of sequential steps that are presented in a design flow. The order of the steps is important; work that is done in one step may be used as input to a succeeding step, and the very first step is spent understanding the motivation for the project and the requirements and scope which result from that. This sequential order is also used to progressively narrow the focus of the design; in any step the reader may be presented with a decision to make. Each of the available options is presented, along with its implications, to assist the reader in coming to a decision that’s appropriate for their IT environment and for their business. The decision may cause a branch in the decision flow which narrows the scope of the remaining work. Following this process results in the most cost-effective design that will meet the requirements of the business.
Figure 2. The Infrastructure design flow for System Center Configuration Manager 2007 R2
Technology IPD guides and other IPD guides
The IPD guides released to-date are mostly individual technology design guides. In cases where the technology being designed interacts with another technology, the other technology guide may be referenced. In some circumstances, more than one Microsoft technology may appear to meet the businesses’ needs. For this situation IPD selection guides are available. For example, the IPD guide for Selecting the Right Virtualization Technology leads the reader through a series of three to five decisions to determine which Microsoft virtualization technology is the right fit for each virtualization project. The architect can then pick up the right IPD technology guide to work through the infrastructure design.
Selection IPD guides are also available to guide IT and business decision makers through the process of selecting between on-premises services and Microsoft hosted services to deliver Exchange and SharePoint functionality.
How IPD guides are created
These guides are produced by a group working in the Solution Accelerators team at Microsoft in Redmond, Washington, USA. The group has broad infrastructure experience in many different areas and for each guide work together with a current expert practitioner. In addition, the IPD group always needs and appreciates input from infrastructure practitioners and architects. If you have feedback on the IPD guides, or on any other Solution Accelerator, please contact the team at satfdbk@microsoft.com. The IPD team is currently refreshing the Windows Server 2008 guides to reflect the changes and new functionality in Release 2.
The IPD guides are available for free download at www.microsoft.com/IPD.
About the author
Fergus Stewart is a Program Manager in Microsoft’s Solution Accelerators team. Prior to joining the team he worked on infrastructure and systems management projects in enterprise IT environments around the world.