Introduction to Logical Datacenter Designer, Part 1
Summary: See how this Team Architect Edition designer can help you model all operational aspects of your datacenter, making it easier to build and deploy. (6 printed pages)
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. Logical Datacenter Designer is integrated with other Distributed System Designers, included in Visual Studio Team System. All of the designers leverage a common XML-based metafile format known as the System Definition Model (SDM). Logical Datacenter Designer is an effective tool for communicating between IT professionals and system architects.
Logical Datacenter Designer is one of four Distributed System Designers included in Visual Studio Team Architect, and is used to build logical models of a datacenter. Models created with the Distributed Systems Designers are used to ensure that distributed systems are designed for efficient and secure deployment into the datacenter. These designers are the first development tools released as part of Microsoft's Dynamic Systems Initiative (DSI), a set of products that simplify the task of architecting, developing and deploying dynamic and distributed applications.
Logical Datacenter Designer is used to create a model that describes the operational aspects of a datacenter—such as servers, communication paths, and operational policies—in a way that is easily shared among system architects, infrastructure architects, developers, and IT operations staff. The resulting model describes the aspects of a datacenter that are of interest when architecting and deploying connected systems across multiple servers. The model doesn't necessarily describe an entire datacenter; it can often be more reasonable to model a portion of it. For example, separate models can be used to describe the eCommerce, B2B, and intranet hosting portions of a datacenter. Other designers included with Visual Studio Team Architect leverage the information in a logical datacenter diagram (LDD) to ensure that a distributed system adheres to the policies and constraints defined in the datacenter, a concept known as Design for Deployment.
Communication and integration are key features of the Distributed System Designers. All of the designers share a common document metamodel known as the System Definition Model (SDM) that is used to store model information. Sharing a common document format simplifies the task of integrating information from multiple designers when validating a design. Because an LDD can be included in a Visual Studio solution, it can be shared, versioned, and tracked just like any other document.
The System Definition Model
As discussed earlier, all architectural designers included in Visual Studio Team Architect leverage the System Definition Model (SDM). SDM documents store their information using XML, which makes it easy to integrate with third-party tools and processes. Inside the model, network elements and constraints are modeled as XML nodes. Because the SDM is an XML document, existing tools and class libraries can be used to consume information in models created with the Distributed System Designers.
Opening an SDM document in an XML editor reveals an XML document with a root node named SystemDefinitionModel, which contains a tree of SystemDefinition nodes:
<SystemDefinitionModel Name="MyDatacenter1"...> <SystemDefinition Name="MyDatacenter1" ...> <SystemDefinition Name="IISWebServer1" ...> ... </SystemDefinition> <SystemDefinition Name="Zone1" ...> ... <Subsystem Name="DatabaseServer1" ...> ... </Subsystem> <Containment Name="..." ChildMember="DatabaseServer1" /> ... </SystemDefinition> <SystemDefinition> </SystemDefinitionModel>
An actual SDM document includes versioning and namespace information making it more verbose, but the general idea is that the SystemDefinition nodes are used to model the logical servers and other shapes in the logical model. Each node includes information such as constraints, settings, and relationships with other nodes. Zone nodes can be nested, allowing zone shapes to contain logical servers (or even nested zones) as subsystems.
In a datacenter, application hosts and network topology are designed with multiple goals in mind:
- Organization, so that applications are deployed in a consistent and logical manner.
- Performance, meaning that applications should be deployed to application hosts and network segments that are optimized for their use.
- Security, such that applications are deployed in a way that maximizes security and minimizes threat surfaces.
Unfortunately, the tools typically used by infrastructure architects to design and document a datacenter are not integrated with the tools used by most system architects and developers. Often, some of the information conveyed in typical infrastructure diagrams are of no real use to the developer (ip address, vlan subnet masks, and so on). As a result, there is an impedance mismatch that hampers communication. It's difficult for an infrastructure architect to document every aspect of policies enforced in a datacenter, especially in organizations where the datacenter has servers, firewalls, and other network elements that have been acquired over a long period of time. It's also difficult for a systems architect to document every possible operational requirement for a distributed system made up of many separate applications that have been created over a period of time.
Logical Datacenter Designer is used to capture the operational goals of an enterprise into a model that focuses on the logical structure of the datacenter. By using the same document metamodel and tools that are used by system architects and developers, barriers to communication can be reduced, and information about the datacenter's requirements and capabilities can be more effectively communicated.
A logical description of a datacenter can be created and shared among multiple development projects, thus enabling multiple teams to leverage descriptions that are maintained by infrastructure architects responsible for the network topology for a datacenter or a portion of a network that is targeted for development.
At different phases during system design and construction, the logical system can be used to validate the current system design against the logical datacenter.
Logical Datacenter Designer is launched by selecting Add New Distributed System Diagram from the Visual Studio Project menu. Select Logical Datacenter Diagram from the list of available diagrams, and Visual Studio will add the new diagram to the Solution Items folder.
Typically, the logical datacenter diagram is created and maintained outside of your source projects, and owned by a group or individual that is responsible for the datacenter architecture. Although the model can be maintained by a development team, the real benefits come when the model is created by an infrastructure architect or other IT professionals.
The designer canvas acts as a design surface where logical datacenter elements are dropped and arranged to describe your model. Multiple canvases can exist within a solution. In addition to the design canvas and Properties window shared with all Visual Studio designers, there are two additional designer components that you'll be working with as you build a logical datacenter model:
- The Toolbox: The toolbox includes a number of predefined elements that are dropped on the design canvas, including zones, logical servers (application hosts), connection endpoints, and other elements.
- The Settings and Constraints Editor (SCE): The SCE is used to define requirements and responsibilities for elements in the logical datacenter, as well as specify values for configuration settings for those elements.
All Distributed System Designers include predefined toolbox items that can be used to create diagrams. The current version of the logical datacenter designer offers five built-in data center elements in the toolbox:
- DatabaseServer: A server that hosts a database in the datacenter.
- GenericServer: A server of unspecified type in the datacenter, typically extended to represent a custom server type.
- IISWebServer: A Web server that hosts ASP.NET Web Applications.
- WindowsClient: A desktop machine in the enterprise, used to model the constraints on end user's computers.
- Zone: A logical boundary, such as a firewall, that's separated from other portions of the datacenter. Zones can be nested within other zones.
The toolbox also includes endpoint elements that model communication points at the edges of other datacenter elements. Each endpoint type has a unique shape; server-side elements are solid, while client-side elements are hollow. The six endpoint elements are:
- DatabaseClientEndpoint: A consumer of a database connection.
- GenericClientEndpoint: The client side of a non-specific connection.
- GenericServerEndpoint: The server side of a non-specific connection.
- HTTPClientEndpoint: The consumer side of an HTTP connection.
- WebSiteEndpoint: The server side of an HTTP connection.
- ZoneEndpoint: A communication endpoint on the edge of a zone.
Although this list represents a default set of commonly used network elements, such as application hosts and protocols, there are many more types of each out in the wild. You have a great deal of flexibility with Logical Datacenter Designer and SDM to define additional protocols, logical servers, and other elements using the extensibility SDK.
The Settings and Constraints Editor
The Settings and Constraints Editor is used to define various aspects of elements included in the logical datacenter diagram, application diagram, and the system diagram. This is the same editor used by all of the distributed system designers in Visual Studio Team Architect. The settings can include configuration information, such as the versions of the operating system and the .NET runtime installed on the logical server. They can also include policy constraints, such as preventing ASP.NET Web applications from running on a group of logical servers.
One way to think of a constraint is as a requirement that must be maintained by all applications deployed onto a particular logical server. Individual elements in a logical datacenter diagram can be restricted in many ways to properly model the policies that exist in the datacenter. A constraint might require or restrict certain types of communication, might require specific security aspects, or may bar a certain application type altogether.
There are three types of constraints:
- Implicit constraints are included with the element shape dropped on the design surface, and don't require editing with the logical datacenter designer. An example of an implicit constraint occurs when an IIS Server shape is dropped on the design surface. A mapping of allowed file extensions for the logical server creates implicit constraints for applications deployed to the box. Implicit constraints can be authored with the Extensibility SDK.
- Pre-defined constraints are groups of constraints that are controlled together through the designer. For example, you can control whether or not an ASP.NET application can be hosted on a logical server with a pre-defined constraint.
- User-defined constraints are created by directly authoring one or more settings to form a constraint. Although user-defined constraints offer maximum flexibility, and can be used to author the same requirements as the pre-defined constraints, it is possible to create user-defined constraints that conflict with pre-defined constraints.
The Settings and Constraints Editor is normally docked below the bottom edge of the logical datacenter diagram. If it isn't visible, it can be displayed from any diagram element's context menu.
A key component of Visual Studio Team Architect, the 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.