Real World Case Study - Citrix MetaFrame XP

The Lilydink Toy Company has decided to create a unified MetaFrame XP strategy for their entire enterprise. They currently have multiple pockets of users that use applications in multiple locations.

Lilydink Toy Company

The Lilydink Toy Company has decided to create a unified MetaFrame XP strategy for their entire enterprise. They currently have multiple pockets of users that use applications in multiple locations. Figure 3.13 shows their current business environment.

Figure 3.13: The Lilydink Toy Company's business environment

All users in the remote sites need to access the corporate database application at the headquarters. Additionally, remote users will need to access applications at their respective remote sites.

After studying their environment, there were some technical design decisions that the project team could easily make. Lilydink decided that they would place MetaFrame XP application servers throughout their environment instead of placing them all at the headquarters. They figured that by doing this the users' sessions would always execute in close proximity to their data. Also, they didn't like the idea of application data from the remote sites traveling across the network to central MetaFrame XP servers, just to be sent right back to the remote user via an ICA session.

They next decided that they would have a local IMA data store at each physical site. If each site was its own server farm, then this would be a given. However, if they have a single, large server farm, they will place local data store replicas at each remote site that has MetaFrame XP servers.

Even with these preliminary questions answered, The Lilydink Toy Company still wasn't sure what their server farm architecture should look like. After some lengthy discussions, they boiled it down to two questions:

  • Should they create one large server farm or a separate server farm for each location?
  • If they create a large server farm, should they partition it into separate zones or just have one large zone?

Lilydink decided to map out all possible solutions based on answers to these two questions. They came up with three different architectures worth considering:

  • One company-wide server farm with one zone.
  • One company-wide server farm with multiple zones.
  • Multiple server farms.

The sections on the following pages compare three MetaFrame XP network architectures. While no architecture represents the "perfect" solution, each has very specific advantages and disadvantages. Most likely, a combination of architectures will work best for the Lilydink Toy Company.

Option 1. One Company-Wide Farm with One Zone

The first company-wide MetaFrame XP architecture that Lilydink considered was the creation of one large server farm not split into separate server zones. In this scenario, there would only be one zone data collector for the entire company. All session update information would traverse the WAN to the single zone data collector.

Lilydink's IT staff created architectural diagrams to represent where the different MetaFrame XP components would be and to get a visual feel for the amount of network traffic between sites. Their first diagram is shown in Figure 3.14 on the next page.

Figure 3.14: One large server farm with a single large zone

The first thing that you may notice when looking at this layout is that there is quite a bit of network traffic between remote sites. In addition to users' ICA traffic from their application sessions, every remote MetaFrame XP server creates a connection back to the zone data collector at the headquarters.

The design team was also concerned that having a zone data collector on the opposite side of a busy WAN link could frustrate remote users if they try to logon during busy periods.

The Lilydink project team created the follow list of advantages and disadvantages for this architecture:

Advantages of One Large Farm

  • Licenses are pooled across all sites. Each remote user will only need one license, even though they will access applications on local and remote MetaFrame XP servers.
  • Simple maintenance and administration, because all servers will be in the same server farm.
  • All session update information is sent across the WAN once, to the zone data collector at the headquarters.

Disadvantages of One Large Farm

  • Even though it happens only once, all session update information must be sent across the WAN to the zone data collector at the headquarters.
  • Logons, queries, and enumerations could be slow for remote users, because the zone data collector is across the WAN.
  • Firewall ports 2512 and 2513 must be opened to allow intra-farm communication if the WAN links connect through firewalls. (See Chapter 15 for more information on MetaFrame XP port usage.)
  • Centralized administration only. Because all servers belong to the same server farm, remote sites cannot have their own administrators.
  • Session information updates from each MetaFrame XP server to the zone data collector cannot be configured, timed, parsed, queued, or limited (unlike ICA Gateway traffic in MetaFrame 1.8).

Option 2. One Company-Wide Farm with Multiple Zones

Instead of having one zone, the Lilydink project team decided that another architecture option was to create one company-wide server farm with separate zones for each geographic location. This would allow them to have a zone data collector at each local site.

Even after a brief look at the architecture diagram (see Figure 3.15), it's easy to see that WAN network traffic could be less than the first design. The main difference here is that any and all session change information is passed from the first zone data collector to all of the others. For example, whenever a user logs on to a MetaFrame XP server, that server informs the zone data collector. If there is only one zone, no other communication takes place. Even if the zone data collector is on the other side of a WAN link, the update only crossed the link once. However, if there were many zones, the zone data collector that received the information from the MetaFrame XP server would immediately notify each and every one of the other zone data collectors. In a WAN environment, such as the illustrated environment of the Lilydink Toy Company, those immediate zone updates would travel across the WAN repeatedly-once for each zone data collector.

Figure 3.15: One farm, multiple zones

Advantages of One Farm with Multiple Zones

  • Licenses are pooled across all sites. Each remote user will only need one license even though they will access applications on local and remote MetaFrame XP servers.
  • Simple maintenance and administration, because all servers will be in the same server farm.
  • Local zone data collectors at each site allow for fast logons, queries, and application enumerations.

Disadvantages of One Farm with Multiple Zones

  • All background information is replicated to all zone data collectors. (Remember, this additional network load is the price you pay for having local, up-to-date information at each site.)
  • Firewall ports 2512 and 2513 must be opened to allow intra-farm communication if the WAN links connect through firewalls.
  • Centralized administration only. Because all servers belong to the same server farm, remote sites cannot have their own administrators.
  • All zone data collectors need direct network access to all other zone data collectors.

Option 3. Multiple Server Farms

Not sure if the WAN bandwidth could handle the traffic generated by a MetaFrame XP server farm, Lilydink decided to consider the option of creating multiple server farms, one for each geographically separate location. With this design, each farm is essentially its own entity. While this design has virtually zero impact to the WAN, it also is the most difficult to work with on a daily basis.

As you can see in the diagram (Figure 3.16), the only traffic that traverses the WAN in this situation is the actual ICA session traffic from the remote users accessing applications from the headquarters. Of course, this architecture is not without its problems, most notably the inability to share MetaFrame XP connection licenses between locations.

Figure 3.16: Multiple farms

Advantages of Multiple Server Farms

  • No MetaFrame XP background IMA data replication.
  • Departmental-based licensing.
  • Each farm could have separate, local administrators.
  • No IMA data store replication, since each farm has its own IMA data store.

Disadvantages of Multiple Server Farms

  • Licenses are not pooled across different geographic regions, causing each remote user that accesses corporate and local applications to consume two connection licenses.
  • All security must be configured independently at each farm.
  • All farms must be administered separately. While there are ways to configure the Citrix Management Console to simultaneously show both server farms (see Chapter 16), farm administrators must manually make changes to the configuration of each farm separately.

Analysis of the Proposed Worldwide Architectures

After looking at the advantages and disadvantages of the three solutions outlined, the Lilydink IT staff decided that their MetaFrame XP company-wide architecture would be a combination of the three. In some places it would be logical to conserve bandwidth while in others it would be important to share licenses and management via common server farms.

The main advantage to having one giant worldwide farm is that one user will only need one license, regardless of the location or the number of servers that he accesses. With the abilities to replicate the IMA data store locally among sites and to segment the server farm into multiple zones, it is technically possible to build one large farm that spans multiple WAN locations.

However, if localized administration is important, having one giant farm can be a problem. Users are granted server farm administrative rights via the Citrix Management Console. These rights allow a user to access and change the IMA Data Store (which contains all configuration information about all farm servers). Server farm administration rights are "all or nothing." There is no way to segment a server farm into multiple administrative groups (unless you split the farm into multiple farms). Even if native Microsoft security was used to "lock-down" a server (with NTFS rights, policies, etc.), all server farm administrators would still be able to change that server's information in the IMA data store. This would be like revoking someone's local administrative rights from a server but then giving them full control of the registry (the IMA data store in this case). This lack of administrative delegation ability within one server farm is a disadvantage to the many advantages of having one unified, global farm. (Note that not even Feature Release 2's delegated administration helps in this case, since it delegates administration by role, not by server.)

In addition to the major farm design, another decision must be made as to the numbers and locations of server zones. Most likely, organizations will want to split any farm that traverses geographic locations into multiple zones. This is primarily due to the fact that all servers in one zone need constant access to the zone data collector. Additionally, having local zones will always ensure that a zone data collector resides on the same subnet as a MetaFrame XP server that a user would like to use.

Ultimately, the Lilydink Toy Company will create multiple zones, some spanning physical sites, others not. For example, several remote sites may have MetaFrame XP servers that all connect into Europe. It is possible that all of those remote sites would be one zone, while the US sites would be in another zone.

 

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchVirtualDesktop

SearchEnterpriseDesktop

SearchServerVirtualization

SearchVMware

Close