Windows Server Architecture
Windows Server Architecture
This topic has not yet been rated Rate this topic Curtis Cummings Microsoft Corporation May 2005 Applies to: .NET Infrastructure Architecture Visit the Windows Server System Reference Architecture (WSSRA) Web site to learn more about WSSRA. Summary: The Microsoft Windows Server System Reference Architecture (WSSRA) guidance addresses the fundamental aspects of design, particularly at the architectural level, which are described in this article. (6 printed pages) Contents Introduction Availability Security Scalability Manageability Reliability Supportability Repeatability Standardization Integration .NET Ready
Introduction
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 to 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 nines 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 among 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 loadbalanced. 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 industryrecognized 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 demandbased 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 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: Purposing. Monitoring and alerting. Remote administration. 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.
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 that are 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 highperformance 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. The Microsoft internal IT organization has significant input into the solution design, which takes into consideration real-world operations and support issues. With the delivery of more highly supportable solutions, 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.