Introduction to Architecture Blueprints

This introduction provides an understanding of the Microsoft approach for developing a standardized technology architecture and the design goals of such an architecture. Conceptual and logical diagrams are provided to help the reader visualize the architecture and understand how the individual components fit together.

On This Page

	Executive Summary
	Windows Server System Reference Architecture
	Introductions to the Blueprints
	Style Conventions
	Summary

Executive Summary

Organizations rely on information technology (IT) services to provide the infrastructure required to support their business goals. In order to fulfill these goals, the IT services must be available and should have the capacity to grow smoothly as business requirements expand.

Windows Server System Reference Architecture (WSSRA) is a detailed reference architecture, tested and proven in labs, that yields valuable implementation guidance for meeting the requirements of an enterprise. Customers can use this guidance to build highly available, secure, scalable, manageable, and reliable enterprise infrastructure. By following the recommendations in the WSSRA documentation, an organization can quickly and efficiently plan, build, and operate an infrastructure to support its long-term business needs.

This guidance builds on and updates the work done previously for the MSA Internet Data Center (IDC) version 1.5 and the MSA Enterprise Data Center (EDC) version 1.5. The Architecture Blueprints are organized at an architecture level in order to provide IT professionals with a common understanding of overriding principles prior to leveraging guidance on specific IT services. The guides relevant to the IT services are provided in a modular fashion to make the overall documentation set more accessible and consumable. In addition, WSSRA comprises a number of scenarios that are designed to address the key business requirements in an enterprise. The focus of this release is on the Centralized and Satellite Branch Office (SBO) scenarios.

Who Should Read the Architecture Blueprints

The Architecture Blueprints is intended for those involved in planning, designing, and implementing an enterprise-class infrastructure project, including consultants, system architects, and IT professionals who are responsible for the planning stages of application or infrastructure development and deployment. The intended audience for this includes the following business roles:

Top of page

Windows Server System Reference Architecture

WSSRA is aimed at empowering systems integrators and IT professionals with validated architectural guidance that demonstrates the Microsoft platform as the most trustworthy platform for business computing. The architectural guidance is provided in the Reference Blueprints, and the process followed for validating it is captured in the Implementation Guides. This validation implies that the guidance goes well beyond traditional white papers; it is validated by building and running formalized test suites against a data center instantiation to ensure adherence to architectural principles and design goals.

Development Approach

A typical enterprise-level organization’s data center contains a complex mix of vendor hardware and software as well as technology professionals who provide services throughout the IT life cycle. These components need to be integrated to ensure that they work well together. The components range from networking devices to application servers to storage devices, and each includes the necessary software components. Each of these components has a large number of potentially valid configurations, but only a few of these configurations result in an integrated, functional system. Determining the right configurations and then implementing and maintaining them can be an expensive proposition.

However, across multiple infrastructure projects, many of the problems that are solved are identical. WSSRA provides a basis for standardization that incorporates best practices that have been tested in a lab environment, which will significantly jumpstart implementation projects. The efficiencies come from the fact that the same problems do not have to be solved again and again.

Design Goals

WSSRA guidance typically addresses functional areas such as Microsoft Active Directory directory service implementations or file and print services. However, more fundamental aspects of design, particularly at the architectural level, need to be addressed. The WSSRA guidance addresses these fundamentals, which are called non-functional requirements and are described in the following paragraphs.

Availability

Availability is largely dependent on careful design and operational discipline, including change controls, rigorous testing, and optimized upgrade and fallback mechanisms. The people and process aspects of availability are not addressed here; we will concentrate on the availability of technology infrastructure and the services it supports.

The key to availability lies in isolating service functionality from failures of individual components, which can be achieved by removing any dependencies the service might have on individual architectural components. The overall approach for availability is to plan with failures in mind. WSSRA is designed to isolate all single points of failure in the design and maximize uptime by providing redundancy or functional specialization to contain faults through the use of devices that provide backup for each other, multiple communication paths between devices or servers, and special technologies such as clustering to provide service-level failover. Rather than quote a string of 9s for percentage availability, the guidance aims at developing high availability infrastructure for meeting unique customer requirements. Therefore, WSSRA focuses on providing solution-wide technologies and techniques to combat downtime that can be adopted as requirements or constraints dictate.

Techniques will vary, depending on the aspect or component of the architecture. For instance, Web services typically use load balancing to spread load amongst many similar systems so that if one fails the others can take over. Database services, however, often operate on a read/write basis and cannot be load-balanced. In this case, failover clustering is used to manage the provision of services among multiple hosts within a cluster.

Security

Managing risk by providing adequate protection to networks and systems that must maintain confidentiality, privacy, and integrity of information is a key design point. The only way to do this in a coherent way is to follow an enterprise-wide strategy instead of using a “band-aid” approach to solving specific problems or operating in a reactive rather than proactive mode. WSSRA uses the industry-recognized strategy called defense-in-depth.

The defense-in-depth strategy defines multiple layers of bidirectional security that do not rely on any one technology or technique to completely secure the infrastructure. Physical security, intrusion detection, security policy guidelines, and recommendations are also made in an effort to provide as secure a solution as possible.

To implement the defense-in-depth strategy, an architecture is separated into security zones that can be further split into segments. This layered and segmented approach allows for the compartmentalization of systems, meaning that a partial compromise does not result in data loss or exposure to additional compromise.

Scalability

Scale-up and scale-out strategies are specific to the role a component plays in the architecture. For example, Microsoft SQL Server databases may need to scale up for performance and growth and scale out with multiple clusters for performance and availability. An Internet Information Services (IIS)-based Web farm, however, is more likely to scale out using load balancing to provide fast and simple demand-based change.

Scaling is the ability of a system to handle increasing demands at an acceptable performance level. The aim of the design is to provide appropriate strategies for scaling to meet ever-increasing demand. The major components of the architecture that scale are the network systems or topology, applications servers, infrastructure services, data systems, storage, and management systems.

Windows Clustering and the Network Load Balancing service are the specific Microsoft technologies implemented in the WSSRA instantiation. When the overall load exceeds the capabilities of a system in the cluster, additional systems may be added to the cluster.

At present, expansion of system capacity requires an up-front commitment to expensive high-end servers that provide space for additional CPUs, drives, and memory. Clustering and load balancing technologies provide a strategy for adding smaller, standard systems incrementally on an as-needed basis to meet overall processing requirements. This approach provides for the growth of services with increasing performance and capacity requirements.

Scaling Up

Scaling up is a strategy that increases the capacity of a component to handle load. For example, an SQL Server cluster built on a Microsoft Windows Server 2003 Datacenter Server solution can scale up by increasing the number of processors or the amount of memory without losing the service or rebooting the server.

Scaling Out

Scaling out is a strategy that increases the number of components, thereby increasing the aggregate capacity of these components. Cloning and partitioning, along with functionally specialized services, provide an exceptional degree of scalability by growing each service independently. For example, network bandwidth can be scaled out by partitioning different types of traffic to different virtual local area networks (VLANs).

Manageability

Management and operations broadly refer to the infrastructure, technologies, and processes required to implement, configure, manage, monitor, and maintain the health of all elements in the architecture. The overall management system goals include:

There is often synergy between management and the other design goals, because an effective management infrastructure provides the tools that are necessary to meet other design goals. For example, to ensure accurate and timely scaling, management guidance provides for the measurement of important metrics to produce predictive and reactive alerting and reporting. The goal of the relationship between scalability and manageability is to deliver a holistic solution that enables efficient, effective, and (wherever possible) automated scaling. It is impossible to meet these goals without an effective management infrastructure, which is why the reference architecture relies heavily on the areas of management discussed in the following sections.

Purposing

The key to reducing deployment time and costs during build-out and scale-out scenarios is the provision of mechanisms that automate the configuration and purposing of hardware and systems. Not only is time saved, but also infrastructure components will be deployed with much more reliability and consistent behavior.

Monitoring and Alerting

It is impossible to measure performance, predict issues, or maintain availability of an IT environment without a comprehensive monitoring and alerting mechanism. It is imperative that any failures be brought to the immediate attention of the systems administrators who can rectify them. If corrective measures are not applied, network infrastructure can slowly decay until network performance degrades and services become unavailable.

Monitoring and alerting is also vital to a successful security strategy. There is significant auditing in important areas of the system, and the monitoring and alerting process is designed to generate alerts whenever unusual audit events are discovered.

Scalability can also benefit from the monitoring and alerting infrastructure. Defining alerts based on system usage makes it possible to employ proactive scaling of the environment to prevent users from being adversely affected. For example, an error message may be triggered when processor utilization on the cluster server is consistently above a preset limit; this condition may be an indication that more cluster servers or more powerful cluster server hardware is warranted. Consequently, monitoring and alerting can be used to support capacity planning.

Remote Administration

Supportability of any large-scale solution is improved when necessary administrative tasks can be performed remotely while the enterprise network architecture remains secure. Remote administration capability also makes it unnecessary for network administrators to make costly visits to the location of the network resources to resolve service-related issues. In combination with the monitoring and alerting infrastructure, the remote access technologies used allow support personnel to deal with almost any situation that may arise without requiring physical access to the infrastructure.

Reliability

Reliable solutions come from the consistent behavior that arises from the ability to repeatedly deploy standardized architecture and systems.

Reliability can directly affect the availability of the overall design and indirectly affect the level of success that can be achieved in the areas of security, scalability, manageability, and performance. Reliability is addressed at several levels, and is especially critical with regard to the stability of the solution and the performance of the implemented applications.

WSSRA, by the very nature of its design, testing, and adherence to best practices, is a repeatable and reliable architecture. Molding architecture into a solution with software and services that are high-performance and stable is a significant challenge. Each solution is designed and tested in a way that maximizes performance and takes advantage of technologies used in the architecture. In addition, comprehensive monitoring of services and software is used wherever possible to predict and catch software and service failures. Once the infrastructure is effectively monitored, the management framework is used to deliver automated ways to effect failover or rapid recovery.

Supportability

Every aspect of the lab implementation is a released and supported product. There is nothing inherently “new” or beta about what WSSRA delivers. The individual components are put together and configured in a manner that is supported by the provider of that component and its support organization. The architectural components are integrated and configured with input from the relevant Microsoft and partner support organizations to ensure maximum supportability of the solution. Microsoft's internal IT organization has significant input into the solution design, which takes into consideration real-world operations and support issues. Once more highly supportable solutions are delivered, solution-aware support and service offerings are available from Microsoft and its partners.

Repeatability

Pre-tested solution deployment mechanisms allow for repeatable solutions that can be deployed rapidly. Most organizations are unable to ensure that similar systems (such as stateless Web servers) are actually alike. More importantly, they are also unable to add capacity with the assurance that they are adding similar systems.

Standardization

Implementation of standardized infrastructure components through well-known architectural specifications creates predictable and reliable solutions. It also forms a basis for organizations to manage change and growth. It is expected that WSSRA as a technology architecture can form a significant portion of an organization’s enterprise architecture or standard operating environment. It may help bring together business/application and technology/infrastructure communities within an organization. Once these communities are joined, they can combine business applications with effective deployment mechanisms, targeting standardized infrastructure to roll out business solutions quickly and with a low risk.

Integration

A primary goal of WSSRA is to create an architecture in which Microsoft products and partner hardware and software products form an integrated solution to meet customer needs. The value of this architectural guidance is underscored by the fact that it has been tested in extensive and integrated lab facilities.

.NET Ready

WSSRA aims to be the optimized infrastructure on which .NET applications will be built. It provides application infrastructure architecture guidance to help ensure that the Microsoft .NET Framework is deployed and used to provide the supporting services that applications require in a complex data center environment.

The Enterprise Model

To ensure applicability to a wide audience, an enterprise model needs to be an abstraction of the varied sizes, distributions, and technology-dependent aspects of typical organizations. To this end, WSSRA contains distinct scenarios that define how services within different areas of an enterprise are implemented and consumed.

WSSRA defines the following scenarios:

These scenarios are a mixture of physical and logical entities differentiated by geography, isolation or inter-dependence, and business needs in the context of typical organizational structures. The following figure depicts an organizational structure that is separated into corporate and regional facilities and a branch network based on the provision of services and their consumption. The Centralized Data Center provides services for employees within corporate and regional facilities, which are logically separated into departments; it also provides extranet or Internet-based services. A typical branch network is usually extensive, uses services of the organization, and focuses on being a customer touch-point.

Figure 1. Organizational Structure

Roadmap for Delivering the Enterprise

WSSRA is designed around the Microsoft Windows platform; therefore, the release strategy for WSSRA is aligned to major releases of the platform. MSA 1.x was based on Windows 2000, WSSRA is based on Windows Server 2003, and any further change to the architecture will be based on the next major platform update.

Addressing the enterprise model completely is a huge task; therefore, we logically break down the model into manageable chunks to allow core services to be delivered and then, via iteration, additional services and scenarios to be incorporated:

Scope of  WSSRA

The first release of WSSRA will concentrate on the CDC and SBO scenarios; a subset of architecture and IT service guidance will be initially delivered as part of WSSRA. Architecture guidance is defined as guiding principles upon which all IT and end-user services are based (security, networking, and management, for example). IT and end-user services are defined as technology implementations to either enable service provision (for example, IP services) or directly provide services to users (for example, file and print services).

The architectural components in the following table are addressed in WSSRA:

Table 1. WSSRA Architecture Components

The different services and devices in WSSRA have considerations throughout the IT life cycle; therefore, each service has separate guidance for planning, building, and operating customer solutions.

The services and devices in the following table are addressed in WSSRA:

Table 2. WSSRA Services List

Design Overview

The process of defining the architectural aspects of WSSRA leads to some high-level decisions in terms of preferred architecture and numerous design options that need to be addressed for implementation projects that are based on specific customer requirements. This process of making informed decisions based on design options will ultimately formulate the most optimal architecture.

The following diagram is a starting point for conceptualizing how architecture and service provision can meet the needs of the enterprise and its user communities.

Figure 2. WSSRA Conceptual Diagram
See full-sized image

Top of page

Introductions to the Blueprints

This section provides short summaries of the blueprints that make up the Architecture Blueprints.

Introduction to Architecture Blueprints

This document introduces WSSRA and describes how it was developed, how it will be delivered, and the architectural and services components it includes. The document also provides a summary of each blueprint in the Architecture Blueprints and describes the scope of the documentation, its intended audience, and document conventions.

Network Architecture

This blueprint discusses details of the network architecture design. The primary focus of this blueprint is to provide an example of the process that is used to design the network architecture for an enterprise-level network. This process requires a detailed understanding of the physical network devices and the roles that they perform in the architectural design, such as routing, switching, firewall services, load balancing, and remote access services.

Storage Architecture

Storage architecture is a major component of the design. This blueprint provides an overview of different storage technologies and highlights their advantages and disadvantages in the context of an enterprise-level infrastructure. The blueprint also provides examples of storage architecture design strategies to meet the business requirements of an enterprise-class organization.

Application Infrastructure Architecture

This blueprint discusses business and design considerations for building an application infrastructure that will support both internally and externally focused applications in the enterprise.

Management Architecture

This blueprint describes the components, processes, and tools that are required to design the enterprise management architecture. The management architecture outlines the business requirements and architectural considerations for the operation and management of all services in WSSRA.

Security Architecture

This blueprint outlines the business requirements, architectural constructs, and processes that need to be in place for the definition and deployment of a secure enterprise infrastructure to support all WSSRA services. This blueprint provides a number of examples that can be used as implementation job aids.

Top of page

Style Conventions

Architecture Blueprints use the following style conventions and terminology.

Monospace font

Table 3. Style Conventions Used Throughout the WSSRA Documentation

Top of page

Summary

The Introduction to Architecture Blueprints is intended to help readers start to identify and think through the issues inherent in designing enterprise-class solutions that are highly available, secure, scalable, manageable, and reliable. Although each real-world implementation is unique in many respects, the design principles presented in the Architecture Blueprints remain relatively constant, even as technologies evolve and new products emerge.

Top of page