Introduction to Logical Datacenter Designer, Part 2

Mickey Williams
Neudesic LLC

March 2005

Summary: See the Logical Datacenter Designer in action with this look at creating a simple datacenter model. (10 printed pages)

Contents

Introduction
Creating an Initial Model
   Adding Elements to the Model
   Connecting Servers
   Modeling Policy with Constraints
   Defining Constraints and Settings for a Model
   Zones
   Using Zones in a Model
   Importing Settings from IIS
Conclusion

Introduction

Logical Datacenter Designer is used to create models that describe the policies and logical structure of a datacenter, including servers, firewalls, communication paths, security constraints, and other configuration requirements that affect the deployment of application systems into a datacenter. Here, we'll look at how to build a simple model using the Designer.

Creating an Initial Model

The first model we'll create represents a simple datacenter with the following configuration:

• An IIS Web server that hosts presentation-tier applications.
• An IIS Web server that hosts service-tier Web services used by the presentation tier.
• A database server that hosts the database used by applications in the datacenter.

Although the physical configuration of the datacenter may consist of multiple computers in the presentation and service-tier, we'll only model a single logical server to represent these machines. The logical model is a scale invariant view of the physical datacenter. It doesn't attempt to model each server in the datacenter. Instead, it models each type of logical server so that datacenter policy can be shared with teams developing software that runs in the datacenter. There's no direct mapping between logical servers and physical machines. One logical server may be represented by many physical machines, and multiple logical servers may be used to represent a single physical server.

Adding Elements to the Model

Create an empty logical datacenter diagram using the steps outlined earlier, expanding the toolbox if necessary, and dragging three elements onto the design canvas:

• Two IISWebServer logical servers
• One DatabaseServer logical server

Your design canvas should look something like Figure 1.

Figure 1. Design canvas

As with other Visual Studio designers, the names for elements are defined in the Properties window. To make it easier to use the model, change the names and properties for the servers as shown in the list below.

Connecting Servers

Servers and similar elements in a logical datacenter diagram have communication endpoints that represent the connection points for communication paths within a datacenter. Communication can only occur between connected endpoints; during a deployment evaluation using the logical datacenter model, applications will be restricted to the communication paths in the model. Any applications that require additional communication paths will fail the deployment evaluation.

As discussed earlier, there are six standard endpoints in the toolbox, and they can be divided into two categories: server-side endpoints and client-side endpoints. Elements dropped on the design canvas will expose zero, one, or more endpoints by default. For example, the DatabaseServer element exposes a single DatabaseServerEndpoint, while the IISWebServer elements automatically exposes the following two endpoints:

• A WebSiteEndpoint that defines the incoming server side for communication with the Web server.
• An HTTPClientEndpoint that represents outgoing connections from the Web server.

To define a communication path between two endpoints, hold down the ALT key while dragging one endpoint to a compatible endpoint. Drag a connection between the HTTPClientEndpoint on the PresentationTier over to the WebSiteEndpoint on the ServiceTier element. The designer automatically creates a communication path, reflected by a line between endpoints.

Communication endpoints are strongly typed, and connection paths must be made between compatible endpoints. For example, an HTTPClientEndpoint can't be connected directly to a DatabaseServerEndpoint—a client endpoint must always be matched with its corresponding server endpoint. For example, if you attempt to connect the ServiceTier Web server to the SQLServer element, you'll see the no-drop mouse cursor and you won't be able to connect the two elements.

To connect the ServiceTier and SqlServer elements, you must first create a compatible client endpoint on the PresentationTier element. Drag a DatabaseClientEndpoint from the toolbox onto the PresentationTier Web server. Next, drag a connection from the new DatabaseClientEndpoint to the endpoint on the SqlServer database server.

The current state of the model is shown in Figure 2.

Figure 2. Current state of the model

Endpoints are automatically given names by the designer that are based on their type. To provide a more descriptive name, select the label on the design surface and change the Text property in the Properties window.

Modeling Policy with Constraints

Simple models, such as the one built in the previous section, can be used to test basic design assumptions. Using Deployment Designer, you can evaluate deployment on the model and verify that system components target appropriate servers and communication rules are enforced. For example, you would not be able to successfully deploy an application that required the PresentationTier logical server to communicate directly to the database.

A much finer set of policy enforcement is possible using the Settings and Constraints Editor. Individual elements in the model can be provided with constraints that further restrict the behavior and capabilities of applications deployed into the datacenter.

Constraints placed on logical servers affect the applications hosted on the server, as well as their behavior. A server can be constrained so that certain types of applications are never permitted to deploy, or a constraint may specify that a specific aspect of the application is required, such as specifying that only the AspNetSqlProvider be used for Role and Membership in ASP.NET applications.

Constraints placed on a logical server can also advertise the capabilities of the server. Pre-defined constraints can be used to specify the operating system and the versions of the .NET Framework available on a server. These constraints will be evaluated with the corresponding application constraints during deployment validation.

Constraints placed on endpoints restrict the flavor of communication that can be carried through the endpoint. For example, an HTTPClientEndpoint can be constrained to permit only Web service HTTP communication. Establishing such a constraint immediately changes the behavior of the Distributed System Designers in two ways:

1. Logical Datacenter Designer will not allow connections that violate policy. An HTTP client endpoint constrained to permit only Web service traffic cannot be bound to a Web server endpoint constrained to host only Web content traffic.
2. Deployment Designer will enforce constraints during a deployment evaluation. If the only communication path between two servers travels over endpoints that bar Web service traffic, any deployed system that attempts to pass Web service traffic across the endpoints will fail during deployment validation.

Defining Constraints and Settings for a Model

We'll use the Settings and Constraints Editor to enforce policy for the model that we've created in earlier sections. First, we need to establish some basic policy requirements for systems that are deployed into the datacenter. Here's a list of some common policy constraints:

• The PresentationTier and ServiceTier logical servers should only support ASP.NET applications, and should not host external Web services, BizTalk Web services, or generic applications.
• As a general policy, all Web applications must use external session state (either StateServer or SqlServer).

To configure the constraints for the PresentationTier logical server, begin by selecting the logical server element on the logical datacenter diagram. The Settings and Constraints editor is usually visible in the area just below the designer canvas, but if it isn't, right-click on the server and select Settings and Constraints from the context menu. The Settings and Constraints editor is shown in Figure 3.

Figure 3. Settings and Constraints editor

The editor displays a tree control with two top-level nodes: Constraints and Settings. The Constraints node is used to apply pre-defined or user-defined constraints on the selected model element. Selecting a pre-defined constraint displays the settings that compose the constraint. Constraints that are not enabled have their settings displayed as read-only. When a selected constraint is enabled by checking the associated check box, the controls that affect the composed settings can be edited. Figure 4 shows the Settings and Constraints editor being used to edit pre-defined constraints for ASP.NET Security.

Figure 4. Settings and Constraints editor being used to edit pre-defined constraints for ASP.NET Security

The Settings node is used to configure logical server settings. Although the Settings and Constraints Editor provides you with a finer degree of control over specific settings, it can be difficult to properly manage the large number of settings available to you. Figure 5 shows the SCE to edit the DomainController settings on a logical server. Alternatively, you can use the Import IIS Settings Wizard to extract your current settings directly from a machine in the datacenter. The wizard is launched by right-clicking on any node under settings and selecting Import Settings.

Figure 5. Settings and Constraints Editor being used to input DomainController settings

To enforce the policies discussed above, select the PresentationTier logical server, and follow these steps using the Settings and Constraints editor:

• Expand the Constraints node and clear the ExternalBizTalkWebService and ExternalWebService check boxes. This will restrict the logical server to only support ASP.NET and static HTTP content.

• Under Constraints, expand the ASP.NETWebApplication node and select the ASP.NET Session State check box. In the right pane, check the StateServer and SqlServer options for the Session State Mode, as shown in Figure 6.

  

  Figure 6. Session State Mode selections

Repeat the steps listed above for the ServiceTier logical server.

Zones

In a real datacenter or general network (as opposed to an MSDN article), there are more artifacts than simple connections between servers. Firewalls, routers, switches, and other network elements enforce security and communication policy that serve to restrict communication in a network. To some extent, this behavior could be modeled by applying constraints to communication endpoints, but this approach is tedious and error-prone. A better option is to use a Zone. Zones act as a container for logical servers and other network elements, and restrict both their behavior and communication settings.

Constraints are often added to a zone to restrict the elements that it can contain. For example, a zone that only allows Web content applications can be created. Any communication between an element inside a zone and an external element must be done through an endpoint at the Zone boundary, which is typically constrained to permit a limited subset of communication options.

To add a zone to a logical datacenter diagram, drag the zone toolbox element onto the designer. Logical servers and other elements can then be added to the zone by dragging them onto the zone, which will act as their container. Although communication paths can be easily established within a zone, direct communication with elements outside the zone is not possible. If you attempt to drag and endpoint across a zone boundary, you'll receive the no-drop mouse cursor over all target endpoints. Connections through zones must be made through zone endpoints.

Using Zones in a Model

To make the model a bit more realistic, let's add two zones to the datacenter we've modeled in the previous sections. The first zone will surround the presentation tier, and will be used to isolate that part of the network from all communication protocols except HTTP. The second zone will hold the service layer and database computers and restrict all outside communication, except for traffic from the first zone. Follow these steps:

1. Begin by dragging a Zone element from the toolbox and dropping in onto the design surface. Elements in a diagram have a Z-order, so the new Zone element may hide elements underneath it.
2. Drag the PresentationTier logical server onto the Zone element, or right-click the logical server and choose Move to Zone from the context menu. Zone elements isolate communication for contained elements, so all communication paths are removed when a logical server is moved into a zone.
3. Drag new communication paths between the zone boundary and the PresentationTier logical server. Alternatively, the context menu for endpoints enables you to configure connection paths.
4. Use the Settings and Constraints editor to restrict the zone's communication endpoints to the HTTP protocol only. For the inbound zone endpoint, clear all of the constraints except for WebSiteEndpoint. For the outbound zone endpoint, clear all of the constraints except for HttpClientEndpoint.
5. Change the zone's Name property to PerimeterFirewall.

A similar zone can be created to represent the datacenter's intranet:

1. Drag a new Zone element onto the design surface, and change the Name property to DatacenterIntranet.
2. Drag the remaining logical servers onto the zone, and recreate the communication paths between the two logical servers in the zone.
3. Drag a new incoming connection from the zone boundary to the ServiceTier logical server.
4. Use the Settings and Constraints editor to restrict the zone's incoming communication endpoint to the HTTP protocol.
5. Finally connect the outbound zone endpoint from the PerimeterFirewall zone to the inbound zone endpoint for the DatacenterIntranet zone.

The current state of the model is shown in Figure 7.

Figure 7. Current state of the model

Importing Settings from IIS

Although a basic logical model, such as the one shown in Figure 7, can be created manually using Visual Studio Team Architect, there are several issues with creating descriptions by hand. The task of creating models by hand can be difficult, especially in a large datacenter. The more complex your datacenter, the more difficult the modeling task. For complex datacenters, the task may simply be impractical to attempt with manual modeling. The other issue is one of accuracy. The more information added to a model by hand, the easier it is to create an inaccurate data model.

Fortunately, you can import the logical model directly from IIS (future releases will add to the number of elements that can be directly imported). Importing directly into the model simplifies the task by reducing the amount of manual labor required, and also results in a more accurate model.

For example, if I have a Windows 2003 Server installation running IIS with a hardened configuration at the perimeter of my network, the current settings for a particular server can be imported by selecting Import Settings from the logical server's context menu.

After the import process is complete, you can use it immediately, and implicit constraints will fire based on the imported settings. You can also rename the element and save it into the Toolbox for reuse in a new model.

Conclusion

A key component of Visual Studio Team Architect, Logical Datacenter Designer is used to create logical models of the datacenter. These models can be shared by system and infrastructure architects, enabling them to use a common set of tools when exchanging requirements and expectations.

Mickey Williams is a Principal Consultant with Neudesic, one of Microsoft's leading .NET professional services partners in Southern California. Mickey has extensive experience building mission-critical applications on a wide variety of platforms, and has authored or co-authored nine books on Windows programming. His work with .NET extends back to the earliest public release, and today he specializes in architecting and developing mission-critical applications that leverage the .NET Framework, particularly in the areas of ASP.NET, XML Web Services, and Smart Clients.

© Microsoft Corporation. All rights reserved.