Now that we've seen how zone data collectors are responsible for tracking and maintaining server information that changes frequently, let's take a look at the components of a MetaFrame XP server farm that maintain information that does not change frequently. This information is stored in a database called the IMA data store.
The IMA data store is not the same as the zone or the Zone Data Collector. (In fact, the two aren't related at all.) The IMA data store is an ODBC-compliant database containing persistent configuration information, whereas the zone data collectors contain dynamic information that changes frequently. To view or change configurations stored in the IMA data store, you use the Citrix Management Console. Any information that it displays is pulled from the IMA data store, and when you click the "OK" button after making a change, that information is written to the IMA data store.
All server farm configuration information is saved in the IMA data store, as opposed to being saved on individual MetaFrame XP servers. Whenever a MetaFrame XP server starts up, it contacts the IMA data store and downloads its configuration information. (Actually, this contact occurs whenever the IMA Service is started, which usually coincides with the server starting up, but not always.)
MetaFrame XP servers always know where the data store is because they each have a local file-based DSN called mf20.dsn. This DSN contains the information for connecting to the IMA data store. (More on this file in Chapters 12 and 16.)
After a MetaFrame XP server initially contacts the IMA data store and downloads its configuration information, the server will check for changes every 10 minutes. This default interval can be changed via the following registry key:
Data: The interval in milliseconds, entered in hex notation. (The 600 second default would be 600,000 milliseconds, or 0x927C0 in hex.)
Local Host Cache
As previously stated, every MetaFrame XP server downloads its configuration information from the server farm's IMA data store. Each server is smart enough to only download information from the IMA data store that is relevant to it. Information about other servers is ignored and not downloaded. Once the information is downloaded, it is saved locally in a Microsoft Access-style database known as the "Local Host Cache." This local host cache is maintained on every MetaFrame XP server. It serves two purposes:
- Increased Redundancy. If communication with the IMA data store is lost, the MetaFrame XP server continues to function for up to 48 hours (96 hours with Feature Release 2) because the vital configuration information it needs is available in its local host cache.
- Increased Speed. The local host cache contains information that the MetaFrame XP server needs to refer to often. By maintaining the information locally, the MetaFrame XP server does not have to access the IMA data store across the network every time any bit of information is needed.
Even though all application publishing information, domain trust rights, and application user rights are retained locally at each MetaFrame XP server in its local host cache, the Zone Data Collector is still contacted whenever a user launches an application. This contact is made so that the ZDC can keep an accurate count of each server's user load.
You can manually refresh a MetaFrame XP server's local host cache with the command dsmaint refreshlc. Real world experience shows that this manual refresh is something you'll do more often than you care to; particularly if you are testing new applications and do not want to wait for the changes to be propagated down to every MetaFrame XP server.
IMA Data Store Database Type
The IMA data store can be in one of four database formats: Microsoft Access (MS Jet), Microsoft SQL Server, Oracle, or IBM DB2. (IBM DB2 requires Feature Release 2 for MetaFrame XP.) The IMA data store works like any standard database, which means that the best performance, reliability, and scalability will be found when SQL Server, Oracle, or DB2 is used. Of course in order to get these benefits you need to address the additional management, hardware, and licensing requirements of these databases.
IMA Data Store Access Mode
Every MetaFrame XP server must belong to a server farm and have access to that farm's IMA data store. MetaFrame XP is designed to be able to access the data store in either "direct" or "indirect" mode.
When direct mode is used, a MetaFrame XP server connects directly to the database server that is running the IMA data store. A MetaFrame XP server that accesses the IMA data store via indirect mode accesses the database by connecting to another MetaFrame XP server. That other server then forwards the requests directly to the database, and then sends the information back to the original server.
If the IMA data store is a Microsoft Access database, it must be accessed via indirect mode. IMA data stores running on SQL, Oracle, or DB2 platforms can be accessed via direct or indirect mode.
IMA Data Store Replication
MetaFrame XP servers need to have regular communication with the IMA data store to ensure that they always have the current configuration information for the server farm. (Even though we say "regular" communication to describe the communication between a MetaFrame XP server and the IMA data store, keep in mind that this communication is not nearly as frequent as the communication between a MetaFrame XP server and its zone data collector.)
Because of this regular communication, slow network links between MetaFrame XP servers and the IMA data store can cause problems, such as extremely long IMA service start times and timeouts during sequential reads from the data store.
Obviously, this is a situation that should be avoided. One way to avoid this is to split the server farm into multiple, smaller farms. While this would technically solve the problem of MetaFrame XP servers having a slow connection to the data store, it would introduce the complexities and additional management requirements associated with multiple server farms.
Alternately, the IMA data store can be replicated throughout your network environment, so that multiple database copies exist in different locations for various MetaFrame XP servers to access. This data store replication is not a feature of MetaFrame XP; rather, database replication is a native feature of Microsoft SQL Server or Oracle.
Microsoft Access-based data stores do not support replication, because Microsoft Access itself does not support replication. This should not be a problem for you, because if your environment is big enough that you need data store replication, then you shouldn't be using Microsoft Access to run your data store anyway.
Also, IBM DB2 databases cannot be used for IMA data stores if you plan to replicate the database. This is because MetaFrame XP uses the binary large object data type to store information in DB2 databases, and DB2 does not support the use of that data type for replication.
One of the downsides of database replication in general is that the multiple replicas of the database must stay synchronized with the master copy. This can get to be a problem if many changes occur to the database simultaneously. Fortunately, MetaFrame XP servers only read data from the IMA data store. The only time that information is written to the data store is when a configuration change is made through the Citrix Management Console. Because these changes are manually performed by administrators, there is no risk that too many will occur simultaneously. In fact, in many cases, only one change will be made at a time.
Advantages of Replicating the IMA Data Store
- Increased performance in large server farms.
Disadvantages of Replicating the IMA Data Store
- You need multiple database servers.
- Adding MetaFrame servers to the farm is more complex.
- Only SQL and Oracle data stores can be replicated.
How to Configure IMA Data Store Replication
Detailed step-by-step procedures for replicating an IMA data store can be found in the "MetaFrame XP Advanced Concepts Guide" available for free at www.citrix.com/support. Ultimately, you need to configure one database so that it is the "master" copy of the data store. Changes made to the master copy are replicated to read-only copies throughout your environment. All MetaFrame XP servers are then configured, via their local mf20.dsn files, to point to the nearest replica of the data store.
The only caveat to replicating the IMA data store is that in order to make any changes to the farm or publish new applications, you must use a CMC that is connected to the read/write master copy of the data store. The easiest way to do this is to configure the CMC as a published application on one of the servers that connects to the master copy.
More details about configuring the DSN that a MetaFrame XP server uses and publishing the CMC can be found in Chapter 16.
How to Add a New Server to a Replicated Environment
When you add a new MetaFrame XP server to an environment with a replicated data store, you will need to point it to the read/write master copy of the data store during the installation process. Once MetaFrame is completely installed, you can configure the server (as described in Chapter 16) to use a closer read-only copy of the data store.
IMA Data Store Size
Regardless of the mode of access or the database platform, the IMA data store will require approximately 200 KB for each MetaFrame XP server in the farm. This will vary slightly based on the number of applications published, how print drivers are used, and the exact configuration of the farm. The good news is that the database will always be relatively small. Even the largest environments only have data stores that are around 50 MB or so.
Why should you care about IMA data store design?
As you have seen, there are many technical components that you need to understand when designing the IMA data store for your server farm. Based on these components, it's easy to see that the design of the IMA data store has the potential to impact several areas of your MetaFrame XP environment, including:
- WAN bandwidth.
- IMA service startup times.
- Server farm reliability.
Because each MetaFrame XP server needs to read from the IMA data store, your WAN bandwidth can be adversely affected if you do not adequately plan for the location of the data store and its replicas. You want to make sure that you know how and when these database reads will occur.
Speed for the IMA Service to Start
Every time the IMA service is started on a MetaFrame XP server, the IMA data store is queried and the necessary information is downloaded to the MetaFrame XP server's local host cache. If the nearest copy of the IMA data store is across a slow network link, the IMA service could take a long time to start as it downloads its information. No users can log on until the IMA service is fully started, after the IMA data store read is complete.
If the IMA data store is not available, MetaFrame XP servers default to their local host cached copies. If this occurs, you will not be able to make any configuration changes to the farm or to any published applications. Also, after 48 hours (or 96 hours with MetaFrame XP Service Pack 2) without contact with the IMA data store, local MetaFrame XP servers' license service will fail and users will not be able to log on. This 48 or 96 hour limit is an artificial cut-off built into the product and cannot be changed.
All servers in a server farm need to contact the single IMA data store. If you want your farm to grow to several hundred servers, you'll need to scale your IMA data store to support the large number of data requests and consider the location of local data store replicas to service all of those requests.
What are the IMA data store options?
When it comes down to actually designing your data store, there are really two different areas to look at that can be matrixed into three options. For your IMA data store, you can have:
- A Microsoft Access database in indirect mode, accessed through one server.
- SQL, Oracle, or DB2 database in indirect mode, accessed through one server.
- SQL, Oracle, or DB2 database in direct mode, accessed directly via the database server.
If you have existing SQL, Oracle, or DB2 servers in your environment then you can put the IMA data store on them. SQL Servers must be at least SQL Server 7.0 with Service Pack 2, and Oracle servers must be version 7.3.4. In order to use IBM's DB2 database for your data store, your MetaFrame XP servers must use Feature Release 2, and you must use at least DB2 version 7.2 with FixPak 5.
If you use a database other than Microsoft Access, you should know that the MetaFrame XP installation process cannot automatically create the database for you. You will need to manually create the empty database using the native database tools and specify that database during the MetaFrame XP installation. The installation program will automatically create and configure the tables it needs.
Option 1. Access Database IMA Data Store
Using the Microsoft Access database platform for your IMA data store is cheap and can be run on one of your MetaFrame XP servers. Access-based data stores are designed for small or test environments. The database cannot scale too large, and even if it could, other MetaFrame XP servers must always access the data store through the server that hosts it (via "indirect" mode).
Realize that even though we call this solution a "Microsoft Access" solution, it doesn't actually mean that you have a copy of Access installed on your MetaFrame XP server. Technically, this solution uses a "Microsoft Jet" database. The drivers and support files needed to read and write Jet databases are included as part of the Windows operating system. Microsoft Access is an application that also just "happens" to use the Jet database format.
Advantages of MS Access-based Data Stores
- No dedicated database hardware. (It can be run on a MetaFrame XP server.)
Disadvantages of MS Access-based Data Stores
- Single point of failure.
- Limited to 50 servers (for performance reasons).
- Data store cannot be replicated.
- The IMA data store often gets corrupted when Access is used.
Option 2. SQL, Oracle, or DB2 via Indirect Mode
A data store hosted by a SQL, Oracle, or DB2 server will be fast and reliable. However, just because the data store is on one of these platforms doesn't automatically mean that all MetaFrame XP servers in the farm are accessing the database via "direct" mode.
For example, if you have five MetaFrame XP servers that all access a Microsoft Access-based IMA data store via indirect mode hosted on one server, at any time you could convert the database from Microsoft Access to SQL Server. The MetaFrame XP server that previously hosted the Access database would then connect directly to the SQL Server. However, the other four servers would continue to connect to the first server where the database was previously located. Technically, this configuration would work, but you would not realize the full benefits of the SQL Server and would still have a single point of failure.
In this case, you would still be accessing the IMA data store via "indirect mode," connecting through one MetaFrame XP server. You would lose most of your potential gains over keeping with an Access database. (In this scenario, it would be easy to configure the other MetaFrame XP servers to access the new data store directly. See Chapter 16 for details.)
Advantages of SQL, Oracle, or DB2 via Indirect Mode
- Stable database.
- Scalable database.
- For Oracle and DB2, you wouldn't have to install any custom database drivers on all your MetaFrame XP servers. (They would only be needed on the server that is accessing the database via direct mode.)
Disadvantages of SQL, Oracle, or DB2 via Indirect Mode
- Single point of failure.
- A database server is needed.
- Performance bottleneck.
Option 3. SQL, Oracle, or DB2 via Direct Mode
An IMA data store running on a Microsoft SQL, Oracle, or DB2 server connected directly to all the MetaFrame XP servers in the farm is really the way to go for an enterprise-wide environment. It will be fast, reliable, and scalable. Also keep in mind that you can configure native database replication for SQL or Oracle so that there is a local copy of the IMA data store near each group of MetaFrame XP servers. The only downside to using SQL, Oracle, or DB2 via direct mode is the potential cost associated with the database software and servers. However, if you're using this type of data store and you have MetaFrame XP servers through your enterprise, a few thousand dollars spent to ensure that the IMA data store is done right is money well spent.
Advantages of SQL or Oracle in Direct Mode
- Quick, reliable access.
- Stable database.
- Scalable database.
- No single point of failure.
- For SQL or Oracle, database replication keeps copies of the database near MetaFrame XP servers.
Disadvantages of SQL or Oracle in Direct Mode
- A database server is needed.
- One more server to purchase.
- One more server to manage.
Considerations when Designing your Data Store
Because there are very different designs and strategies for an IMA data store, it's important that you determine which is right for you. Answering the following questions about your environment will help to make your decision as to what IMA data store options you should use:
- What is the WAN distribution of your MetaFrame XP servers?
- How many MetaFrame XP servers will there be?
- How crucial are the applications running on the MetaFrame XP servers?
- What is the budget?
- Is there already a database server that you can use?
- What is your tolerance for pain?
WAN Distribution of Servers
If your MetaFrame XP servers in a single server farm are located on opposite sides of a WAN, then you should consider database replication. This means that you would have to use SQL or Oracle for your data store. With servers in one location, database replication becomes less important (and your choice of database platform becomes less important).
Number of MetaFrame XP Servers
A Microsoft Access-based data store can support up to about 50 servers before performance bottlenecks would dictate moving it to a real database (i.e. SQL, Oracle, or DB2). If your MetaFrame XP environment will just be a handful of servers, then you can get away with choosing Microsoft Access for your data store platform.
Importance of your MetaFrame XP Environment
If MetaFrame XP is not mission critical in your environment, then it's probably not worth spending the extra money to build a dedicated SQL, Oracle, or DB2 server to host the IMA data store. On the other hand, if your applications are mission critical, you probably don't want to risk the single point of failure nature of a Microsoft Access-based data store.
If you do not have the budget for an IMA data store then your design is simple: use MS Access. The Microsoft Access data store option is free. It requires no additional hardware or software. Then again, if you have the money, you should opt for the more reliable and efficient solution.
Existing Database Server
If you are lucky enough to work in a large environment there may already be a SQL, Oracle, or DB2 database server that you can use for your IMA data store. If you are really lucky, someone else might be responsible for administering that server, which would be one less thing for you to worry about.
There have been numerous problems with IMA data stores based on Microsoft Access. Many administrators spend time repairing and restoring their data stores that are Microsoft Access-based. This is most likely due in part to bugs in the MetaFrame XP software and part to the fact that Microsoft Access is a desktop database. It is much more suited to track kitchen recipes than it is enterprise data stores. If you want the "real" solution then you need to use SQL Server, Oracle, or DB2.