An important, and often overlooked, step in any software project is ensuring what the development team plans to build will deploy in the production infrastructure. This includes hardware, software versions, configuration of that software, and communication between the various servers involved. The sooner you can get a comfort level (or identify the risks), the more likely your project will succeed.
It is the job of the application architect and the infrastructure architect to make sure they get on the same page, while the design is simply that, a page. When that design moves from paper to code, the wrong infrastructure assumptions can cause costly delays (or worse) in deployment. The new logical datacenter diagram in Team Architect can help.
Logical Datacenter Diagram
The logical datacenter diagram (.ldd) allows you to represent an infrastructure environment in a model. In fact, for most projects you may want to represent more than one infrastructure model. Perhaps a development, staging, and production infrastructure will exist. Knowing the anomalies between these infrastructures can be very helpful. Having this logical representation allows you to test whether your application, as modeled, will deploy.
The current version of the Logical Datacenter Designer is not a networking diagram or even a similar tool. Those tools are still important for the infrastructure team. This diagram is less for the infrastructure team and more for the application architect's benefit. The infrastructure team may be concerned about switches, routers, firewalls, trusts, virus protection, VLANs, and so on (as well they should be). The logical datacenter diagram does not represent this information. It is meant solely to logically represent servers and their related software configuration and their allowed connection points. This gives the application architect and the infrastructure team confidence that a new application project will be deployable in the environment.
The logical nature of this designer is evident from the first use. For example, a logical server in the datacenter diagram would be an IIS web server, a database server, a generic server, and so on. These logical servers do not have physical mappings. Instead, one IIS server might represent an entire farm of web servers, or a database and web server may be deployed on the same box. This information is important to the infrastructure team but is not as relevant to the application architect's need to ensure the new project will deploy correctly.
Instead, the focus is on software, configuration of that software, and communication channels between servers. For example, as an application architect, you may need to ensure that your production environment supports the 2.0 version of the .NET Framework, or that the IIS server that hosts your web services is capable of communicating to your database. These are the types of details that can be embedded in a logical datacenter diagram.
Logical Datacenter Diagram Toolbox
The Logical Datacenter Designer Toolbox provides the access to the items that can be added to the logical datacenter diagram. These items are grouped into three sections: General Designer, Endpoints, and Logical Servers. The General Designer section contains elements that are common to many of the architect designers. The Endpoints section groups the endpoint connections that define the communication between servers in the datacenter. Finally, the Logical Servers section groups the various logical servers and zones that can be defined on the diagram. Figure 21.15 shows a visual representation of this Toolbox.
Figure 21.15. The Logical Datacenter Designer Toolbox.
A zone in a logical datacenter is used to group servers and provide an abstraction of the same. Zones do not, by default, represent any one thing or group of things. You are free to define zones to group servers as you see fit. You can even nest zones within other zones to represent complex relationships.
The principal benefit of using a zone is to indicate what type of communication (traffic) is allowed in and out of the zone. The servers within the zone may talk to one another, but connecting to the zone can be a different story. As an example, a zone can be used to represent any number of things, including an intranet, an extranet, the Internet, a firewall, and a VPN.
As an example, say you want to define zones that will host servers to support the application and systems you have defined previously. You will want a client zone to represent the Windows client application for the sales analysis tool. You will also create an Internet or public access zone for the CRM user interface, as well as to expose a set of proxies for the service layer. Next, you will define a zone for the intranet; you will call this zone ServiceLayer. Finally, you will create a zone for the database. Figure 21.16 shows an example of these zones.
Figure 21.16. Logical datacenter zones.
The next step is to add servers to these zones. After you do this, you'll define the connections between the zones and servers within the zones. You will then work to set the constraints on both servers and zones.
Servers do not have to be added to a zone. They can be added directly to the diagram. However, it helps to think of servers inside communication zones or boundaries. Therefore, the example will use the zones you defined earlier when adding servers.
The Logical Datacenter Designer allows you to use a few different server types on your diagram. These server types and their descriptions are as follows:
For the example, you will end up with one logical server per zone. Many times you will have more than one server in a zone. For example, if you have both an application server and a front-end web server in your intranet, you might define them in the same zone. The servers would talk to one another, but the zone boundary would dictate the incoming and outgoing traffic. Figure 21.17 focuses back on the example.
Figure 21.17. Logical datacenter zones and servers.
This diagram shows the five added servers. The Client zone contains two servers: one to represent each type of client that will connect to the solution. These are not really servers. Rather, they represent an application host that also has configuration implications. Next, the logical database server was added to the SecureDatabase zone. Then two web servers were added. The web server in the PublicAccessProxy zone is meant to host the CrmUserInterface application. In addition, this server has proxy web services that call into the server in the ServiceLayer zone. These are used for the SalesClient application. The next step is to connect the communication channels between these servers and zones.
Connecting Servers and Zones
Servers and zones are connected via endpoints. Endpoints define the type of traffic (and related constraints) that is allowed for a zone or server. If a zone endpoint, for instance, allows only inbound web traffic, there is no other open communication method allowed into that zone. The servers in the zone may have their own endpoints and communicate with one another using different traffic patterns.
The Logical Datacenter Designer allows you to define a few different endpoints. These endpoints and their descriptions are as follows:
For the example, your goal is to wire up the zones and servers within the zones. When there is traffic coming into a zone, typically that traffic is destined for a server (and not simply routed through the zone). The same is true on the outbound side. The outbound traffic from a zone typically originates from a server.
Figure 21.18 shows the endpoints added to the diagram and connected accordingly.
Figure 21.18. Logical datacenter connected zones and servers.
The following provides a step-by-step walkthrough illustrating how to connect the items in the diagram:
Defining Settings and Constraints
Configuring the zones and the servers is the final step. The logical datacenter diagram will then represent your infrastructureat least for the purpose of the application architect. This architect can then use this zone to determine whether the proposed architecture will fit with the real infrastructure environment. Of course, the logical datacenter diagram works only if it truly matches your physical system configurations.
Configuring a Zone
There are a number of settings you can control with respects to zones. These settings include the capability to constrain the types of logical servers that can be added to the zone, the communication allowed in and out of the zone, whether zones can be nested within the zone, and the capability to define custom settings. The Datacenter Designer respects these constraints. It will not allow you, for instance, to add a web server to a zone that is configured for database servers only.
As an example, each zone defined previously should be constrained as to what servers are allowed in the zone. The client zone should allow only clients, the two zones that participate in web traffic should allow only web servers, and the database zone should be constrained to database servers. You set these types of constraints in the Settings and Constraints window (just like the application diagram). Figure 21.19 shows an example.
Figure 21.19. Zone settings and constraints.
In the example, the ServiceLayer zone has been selected. Notice on the left side of the Settings and Constraints window that servers other than an IISWebServer have been disabled (and thus disallowed) to be in this zone. Next, for this type of server, another constraint has been added: Web servers in this zone must be running version 2.0 of the .NET Framework.
For each constraint you set, you can craft a custom error message that is displayed when this constraint is broken. To do so, you click the ellipsis button in the Error Message field for the constraint. This brings up the dialog box shown in Figure 21.20. Here, you can set the error message. Notice you can use the macro text to show special fields for the given message.
Figure 21.20. A custom constraint error message.
Configuring a Server
You configure servers in the same manner. You select each and then control their settings through the Settings and Constraints window. From here, you can indicate the types of applications that are allowed to run on the server, the constraints for each, and the various server settings.
Figure 21.21 shows an example. The CrmServer has been selected. To restrict this server to running ASP.NET and web service applications, you can use the check boxes on the left side of the window.
Figure 21.21. Setting a server constraint.
Next, you can define various settings for the server. Notice that the ASP.NET Session State parameter has been selected (left side, settings tree). You can now use the configuration area on the right side of the dialog box to control these constraints. Figure 21.21 indicates that session state is managed via SQL Server.
Again, your settings should closely match the servers in your environment. These settings will be used to restrict what the application architect can deploy.
Importing Server Settings
The datacenter diagram is a logical representation of your servers. However, you can use an import feature to point a server at a real, physical machine and import its settings. This capability can be helpful if you have access to servers that already represent the correct environment.
You access this feature from the Diagram menu with the Import Settings item. Selecting this menu item launches the Import IIS Settings Wizard. The imported settings apply to the server you have selected in the diagram. The wizard will walk you through the import.
Figure 21.22 shows the key step in the wizard. Here, you provide login credentials to the server. You also indicate what settings you want to import. If you import website settings, the diagram tool can add a new endpoint for each website on your server. You can also pick and choose which sites to import on another screen in the wizard.
Figure 21.22. The IIS Settings Wizard.