4.7 Placement of other Domino databases

< Day Day Up >

This section focuses on the data files of your Domino server. The preceding sections described where to put the files and databases related to the Domino server system. The following sections describe what to keep in mind when dealing with the user or application databases.

4.7.1 Mail files

The mail databases should go into a separate filesystem below the notesdata directory of the Domino server. To determine how many mail directories you need in your environment, look at the number of mail users, the total size of the mail databases (including fulltext index), and the growth-rate of your mailfiles (define quota is always a good idea).

Another point is how long it takes for a full recovery of one directory; you can simply put all your mail databases into one directory by defining a huge filesystem, but what will your users say if you take 24 hours to recover the directory?

From a performance point of view, it is not important to spread the databases among multiple filesystems. Because of the virtual device concept in VM, Linux has no effect on which physical device the data is written to. If you run your Linux natively on a zSeries machine, you must take care of your device-to-filesystem allocation.

4.7.2 Application databases

What is true for the placement and filesystem considerations for mail databases is also true for your application databases; make sure you have a separate filesystem set up for your application data, and that it is large enough to hold all the data. For applications, that might not only be Notes databases and full-text indices, but also flat files that these applications import or export.

4.7.3 Estimating DASD space

The amount of DASD space that is needed for Domino depends on the amount of data that you will store. This is the same as for other Domino platforms. For mail databases, this is normally in the range of 50 to 150 megabytes per user, and will typically grow as the users become more advanced in their use of Domino. Installations with thousands of users will therefore require hundreds of gigabytes, if not terabytes, of DASD space.

Before installing Linux, you should also plan for the proper sizing of the root filesystem and the /opt filesystem. The binaries for products installed will typically be placed in a subdirectory under /opt. The Domino binaries need about 1.3 GB. For the installation, an additional 600 MB is needed for the tar file.

A good starting point might be to size the root (/) and /opt filesystems at about 5 GB or two 3390 mod-3 full pack minidisks combined in a LVM. root (/) and /opt should be defined as separate mount points and not combined into a single filesystem. Also plan for /swap space, although it is far better to use virtual disk rather than real DASD, at least in a z/VM environment. This provides significant performance enhancements.

Lesson learned:

During testing, we failed to take into account the size of the /domserva and notesdata directories, and placed them under root (/). We found that we had to move the notesdata into a separate filesystem. This caused a considerable amount of work, which could have been avoided had we planned better.

4.7.4 Naming convention

We recommend that you use a self-describing, self-documenting naming convention for filesystems and LVMs with in your DASD configuration.

At the Linux level, name your LVMs so that the purpose of the LVM is obvious. We used a volume group name of mail1 and a logical group name of mail1 for the LVM used for the .../notesdata/mail1 directory (and mount point). Another lesson learned was that there were problems that were not obvious at first glance when we created a volume group for all of Domino and the individual logical groups for the subdirectories. It is also a good idea to have a self-describing naming convention for your directories.

At the z/VM level, you cannot assign a name or label to a minidisk, because the minidisk definition just maps a logical device address to a physical device. When assigning DASD to z/VM, it is a good idea to have a sequence of addresses to belong to the same z/VM LPAR. The VOLSERs for these DASD packs should indicate their use on Linux systems. As an example, we used a convention of LNXxxxx, where xxxx was the device address for the VOLSERs of packs used under Linux.

For example, as you can see in Figure 4-4 on page 63, our notesdata directory is located under the domserva directory, which describes the Domino server it belongs to. We planned it this way so that, if we were to add an additional Domino partitioned server (DPAR) to the LinuxA virtual machine, we would already have a self-documented structure in place: domserva with its notesdata directory below it for DomServA/ITSO, and in the future, domservx with its notesdata directory for DomServX/ITSO.

4.7.5 Example of our filesystem

Under VM, we installed four Domino servers in three separate Linux VM guests. So we had two Domino servers on their own Linux and two partitioned Domino server in a third Linux system. In Figure 4-6 on page 69, the filesystem for a Linux hosting one Domino server is shown. Only the directories that begin with a /(in bold and italics) are mount points. For clarity we have omitted other (unimportant) directories inside /opt and notesdata.

click to expand
Figure 4-6: Our filesystem structure

The notesdata directory is a directory under domserva and within the domserva mount point. The directories mail_01, mail_02, mail_03, mail_nn are also separate mount points, as is translog.

Much thought went into deciding on the structure for the servers used in this redbook project. There is a greater view that must be looked at when planning the use of DASD than we show in the example. All of the servers that will run in the z/VM LPAR or the Linux LPAR as a whole should be considered and planned for. Look at the total view of all DASD used across all servers.

In our case, we debated for a long time about the best way to lay out our mail and other database directories. In doing so, we considered the total size of mail files, total number of databases, the channel path to the DASD, and the types of DASD available to use (ESS vs. RVA), and so on. All of these factors must be looked at before considering how to lay out the Domino directory structure.

Even before installing Linux, a decision had to be made as to which of the filesystem types to use, journaled or non-journaled. For the journaled filesystems, we had a choice of types. In at least one instance, we used ext2, a non-journaled filesystem. For Domino, we found this is a mistake. It can lead to very long startup times for the Linux guest in the event of a crash. ext2 also performs extensive checks on the filesystem after every twenty starts of the Linux image.

In retrospect, we should have used ext3 or another journaled filesystem to improve reliability of the filesystems on all Linux images. A journaled filesystem is highly recommended for use with Domino. ext3 has been part of the Domino product test in the Poughkeepsie lab, as well as during our redbook project.

In Chapter 2, "Planning" on page 13, we provide a worksheet to help you plan the use of the mount points and the filesystems. At the very least, plan for separate filesytems at mount points for the directories listed in Table 4-6.

Table 4-6: Domino filesystems
Directory	Use
/	root
/opt	product code - Depending on the number of products installed in the Linux image, it may be best to create separate mount points for specific installed products.
/lotus (under /opt)	Domino Server binaries and scripts. A separate filsystem at its own mount point can ease backing off of an upgrade, and so on.
/tmp	temporary - May be highly variable in size.
/notesdata	Domino server data directory. While the directory for the servername can be under root (that is, domserva) the notesdata should be under its own mount point.
/mailxx or /appsxx	The individual application and mail database directories should planned based on size of databases, recovery consideration, DASD type, and so on.
/translog	Definitely in its own filesystem
/swap	Linux swapping - Use virtual disk when possible.

< Day Day Up >