The first major thing you need to consider when designing your MetaFrame XP network architecture is the physical placement of MetaFrame XP servers on the network.
The key here is to determine where MetaFrame XP servers should be located in relation to the data and the users. In simple cases, this determination is not very difficult. Consider the environment in Figure 3.2 consisting of two office locations. Let's assume that users from both offices need to access a database-driven application housed in the main office.
Figure 3.2: Users in two offices need access to the same database application
This company's IT department has decided to use MetaFrame XP to ease application deployment and to get the best possible performance for remote users. The company is faced with two choices when it comes to the location of the MetaFrame XP server for the remote users: they can put the MetaFrame XP server at the remote office with the users, or at the main office with the database.
While both choices would allow the company to manage the users' applications, putting the server near the database will yield the best performance. (See Figure 3.3.) This is because the network traffic between the database and the client application running on the MetaFrame XP server is much heavier than the ICA user session traffic between the MetaFrame XP server and the end user. By placing the MetaFrame XP server at the main office, the database client software that is installed on the MetaFrame XP server is located near the database itself. Application performance is excellent due to this close proximity, and only MetaFrame XP ICA session traffic has to cross the expensive, slow WAN link.
Figure 3.3: A MetaFrame XP server at the main office
Now consider the other possible server placement option for this company. If the MetaFrame XP server were located at the remote office (as in Figure 3.4 on the next page), the heavy database traffic would still have to cross the WAN while the light, efficient ICA session traffic would be confined the remote office's local LAN, where bandwidth is plentiful. The server located at the remote office would not help application performance from an end user's point of view because the level of database traffic on the WAN is no different than if they weren't using MetaFrame XP.
Figure 3.4: MetaFrame server placement at the remote office
As this simple example shows, it's desirable to place the MetaFrame XP server close to the data source instead of close to the users. MetaFrame XP's ICA protocol is designed to work over great distances and slow WAN links. This allows heavy application data traffic, flowing between the MetaFrame XP server and the data server, to remain on a local LAN.
Why should you care about server placement?
As shown in the previous example, the placement of your MetaFrame XP servers will directly impact several areas, including:
- Users' session performance.
- Network bandwidth usage.
- Server management.
Users' Session Performance
The performance of the users' sessions depends not only on the network speed between the user and the MetaFrame server, but also between the MetaFrame server and the data the user needs to access. It does no good to put a MetaFrame server on the same LAN link as a user if that server must access files that are located across a 56K connection.
However, this must be balanced with the network latency between the user and the MetaFrame XP server. Users won't want to use MetaFrame applications if there's a two second delay from the time they hit a key until the time the character appears on their screen.
Network Bandwidth Usage
Network bandwidth usage is directly affected by the location of the MetaFrame XP servers. Average MetaFrame XP ICA user sessions only require about 20KB per second. Many n-tier business applications (such as Baan, SAP, and PeopleSoft) require much more than that. If your MetaFrame XP server is on the wrong side of the network then you won't save any bandwidth by using MetaFrame.
Ultimately someone is going to need to maintain and manage the MetaFrame XP servers. It's usually much easier for administrators to maintain them if the application servers and the MetaFrame XP servers are both at the same physical location.
What are the server placement options?
Even after looking at the complexities that arise when deciding where to put your MetaFrame XP servers, there are still really only two possible solutions.
- Distribute the servers throughout your environment, balancing some near each data source.
- Put all MetaFrame XP servers in the same place, in one big datacenter.
As with all decisions, each point has distinct advantages and disadvantages that must be considered when designing the final solution.
Option 1. MetaFrame XP Servers Placed in many Locations
When users need to access data that is in multiple geographic areas, multiple MetaFrame servers can be used, with some servers in each location, physically close to each data source.
By placing MetaFrame XP servers in multiple locations throughout your environment (see Figure 3.5), a user can concurrently connect to multiple MetaFrame XP servers. This allows each server to have quick, local access to the data. An added benefit of this is that there is not one single point of failure. Losing access to one data center only affects some applications.
Figure 3.5: Multiple MetaFrame XP servers provide fast access to data
MetaFrame XP can even be configured to automatically route users to secondary servers in the event that a user's primary servers are inaccessible. (See Chapter 4 for details on how to do this.)
The downside to having MetaFrame servers in multiple locations is that your overall environment becomes more complex. Servers must be managed in several physical locations. User access must be designed so that they can seamlessly connect to multiple MetaFrame XP servers. On top of all this, it is inevitable that some data will only exist in one place, and that users will need to access it from every MetaFrame XP server, regardless of location. (Windows roaming profiles are a good example of this.) Lastly, a multi-server MetaFrame XP environment requires that each MetaFrame XP server communicates with other MetaFrame XP servers to transfer background information. When all MetaFrame XP servers are located on the same LAN, managing this communication is not an issue due to the high availability of bandwidth. However, when MetaFrame XP servers span multiple physical locations connected by WAN links, this communication must be managed. (Managing this communication is certainly possible; it just becomes another thing that must be planned for.)
As you can see in Figure 3.5, there are several advantages and disadvantages to placing MetaFrame XP servers in multiple locations throughout your environment.
Advantages of Placing Servers in Multiple Locations
- Users' MetaFrame XP sessions are always close to their data.
- Efficient use of WAN bandwidth.
- Local departments can own, control, and manage their own servers.
- Increased redundancy.
Disadvantages of Placing Servers in Multiple Locations
- More complex environment.
- Users may need to connect to multiple MetaFrame XP servers in order to use all their applications.
- Your servers might require additional local (onsite) administrators because they are not all in the same building.
Option 2. All MetaFrame XP Servers in one Central Location
Instead of sprinkling MetaFrame XP servers throughout your environment, you can put all of your servers in one datacenter (see Figure 3.6 on the next page). After all, providing remote access to Windows applications is what MetaFrame XP is really designed to do.
Figure 3.6: All MetaFrame XP servers in one datacenter
Having one central datacenter that contains all of your MetaFrame XP servers is easy to administer, but it causes other issues to arise.
For example, any users that need to access data outside of the data center where the MetaFrame XP servers are located must do it via a WAN link. While the performance of the ICA session between a user and MetaFrame XP server won't be a problem, significant performance problems could exist within the application sessions themselves due to potential great WAN distance between the MetaFrame XP server and the user's data.
Different applications handle data latency in different ways, but your users will become frustrated if they have to wait a long time to open or save files. Additionally, WAN bandwidth might be wasted because users would be forced to connect to all MetaFrame XP applications via the WAN.
Advantages of Placing all MetaFrame XP Servers in one Location
- Simple environment to administer.
- Users can connect to one MetaFrame XP server to run all of their applications.
- MetaFrame XP servers are all in the same physical location.
Disadvantages of Placing all MetaFrame XP Servers in one Location
- Access to data may be slow if the data is located across a WAN.
- WAN bandwidth may be wasted because users would be forced to connect to a remote server for any MetaFrame XP application.
- No option for local MetaFrame XP servers (local control, local speed, etc.)
- Single point of failure.
As you can see, the location and placement of your MetaFrame XP servers will directly impact many aspects of your MetaFrame XP environment. While part of the design will be easy, other aspects will take some time and thorough planning.
Considerations when Choosing Server Locations
The previous example showed that the data location directly affects the placement of the MetaFrame XP server. However, in the real world, there are many more factors than were outlined in this simple example. The subsequent list includes all necessary considerations and is followed by descriptions of why each item is important.
- Where are the users?
- Where is the data?
- How much (and what type) of data is each user going to need?
- How many different applications are the users running?
- Where is the IT support for the applications?
- What does the WAN look like?
The location of the users is a major factor to consider when deciding where to put the MetaFrame XP servers. Are all of the users in one central location, or are there multiple pockets of users? Is there a datacenter at every location where the users are, or are the users at remote offices?
The data that users need to access from within their MetaFrame XP sessions is probably the most important consideration when deciding where to put your servers. When you look at the sources of data, it is important to consider all types of data that a user may need to access from a MetaFrame XP session. This includes back-end application data and databases, as well as files and file shares, home drives, and Microsoft Windows roaming profiles. (See Figure 3.7)
Figure 3.7: Users often need to access multiple types of data from one session
Are the users at the same physical location as all of their data sources? Is all application data at the same location on the network as users' home drives and Windows roaming profiles, or will users need to pull data from multiple network locations for a single session?
When considering the data that users need to access, consider how each data source will be used throughout their sessions. Will they need to access the data only during session startup or shutdown, or will they need constant access throughout the entire session? For each data source, will users only need to read the data, or will they need to write as well?
Lastly, consider the impact of each data source on the users' sessions. What happens if the path to each data source is congested? Will users be merely inconvenienced, or will they not be able to do their job?
To help understand the importance of these questions, refer to Figure 3.8 (facing page). This diagram details a situation that is becoming more and more common as organizations grow.
Figure 3.8: A user in Europe needs to access data throughout the world
In this example, a user works for a company with a worldwide presence. Apparently this company followed the advice of consultants from the nineties, because all of their crucial business data has been consolidated into one single database in the US. Obviously, one of the main reasons that this company chose to use MetaFrame XP is so that their European users can have fast access to the database application. This company put a MetaFrame XP server in the US, right next to the database server, allowing the European user to access the database through a bandwidth-efficient ICA session. Sounds great! Very simple. Unfortunately, in the real world it is not always as simple.
In reality, the European user must access applications other than that one US database. Since the user is already running applications via ICA sessions to a MetaFrame XP server in the US, they might access other applications via that same MetaFrame XP server, right?
Let's think about this before we jump to an easy answer. Should a European user really be accessing all applications via servers in the US? Sure. If the user is already crossing the WAN to connect to the database, there is no real impact to adding more applications. But will the user always be utilizing the database? What if the user just wants to use other applications? Should the company pay for the transatlantic bandwidth so that the user can create a PowerPoint presentation? What about the user's home drive? Most likely, the user will want to save files and work with others. Should he use PowerPoint running on a US server while saving files to a file server in Europe? What about PowerPoint's auto-save feature? Will this user have the patience to wait while his file is auto-saved across the ocean WAN every ten minutes while he's trying to work?
The point here is that users need to connect to multiple data sources, and they frequently need to access data that resides in many different geographic regions. While this European example is a geographic extreme, the same ideas apply anywhere. A slow WAN is a slow WAN. The previous example also applies to users in Washington DC accessing databases 30 miles away in Baltimore over a 56k frame relay.
This example illustrates a situation in which a user only needed access to a database and a home drive. Other users may need to access files and data from many different groups in many different locations. Also, don't forget about Windows roaming user profiles. If one single roaming profile is to be used for all MetaFrame XP sessions on servers throughout the world, then that profile needs to be accessible to the user wherever they log on. (More on roaming profiles in Chapter 5.)
If a user only needed to access data from one geographic region, the design would be simple. You would just put a MetaFrame server next to the data and have the user connect via an ICA session. However, multiple geographic regions that all have important data for the user increase the complexity of the design.
The number and types of applications that you want to make available via MetaFrame XP also affect the decision as to where the servers should be located. The application mix needed by one user may dictate that the user must connect to multiple MetaFrame XP servers. Some users may only need to access applications on single MetaFrame XP servers while others may need to access applications across departments via many MetaFrame XP servers.
The mix of local applications and remote MetaFrame XP applications is also a factor. Will any applications be loaded locally on the users' computers or will everything be done via MetaFrame XP? If everything is done via MetaFrame, and the MetaFrame servers are located across the WAN from the users and the WAN link goes down, all productivity stops. Is that an acceptable risk to the organization or should some servers and data be local-even though all data may not be local?
IT Support of Applications
How does your organization's IT department support applications? If all application support is from one site then it makes sense for all MetaFrame XP servers to be located at that site. However, large organizations usually have many applications that are supported by different people from different locations, as shown in Figure 3.9 on the next page. In these cases you may have to place MetaFrame XP servers in multiple locations, with each server placed near the people that support its applications.
Figure 3.9: Application support from multiple people in multiple locations
The wide area network can also affect where MetaFrame XP servers should be located. If bandwidth is congested, MetaFrame XP servers should be located across WAN links because they are generally more efficient than the native applications over WAN links.