ShowTable of Contents
Table of Contents
At some point, you will most likely be in the position to expand your Domino Domain. Whether this is to add a Sametime or Traveler server into your domain or add an additional mail server; when you make your first transition from a single server to a multiple server environment, there are some things you need to keep your environment running smoothly. This article walks you through the process of expanding your Domain.
Registering and Securing a New Server
The first step when adding a new server to your Domino domain is to
register the new server. Similar to registering a user, the registration process will create a server document and server ID file for the new server. The registration process will also automatically add the server name to the
LocalDomainServers group if it exists. At this point, you can modify the server document to set the proper authorities for the new server. In the example shown in figure 1, you can see that the server administrators have been defined, the administrators have also been allowed the programmability restriction of
Sign or run unrestricted methods and operations. In the server access section, database and replica creation has been restricted to administrators only and the Terminations group has been denied access. You are now ready to configure the new server using the
configuration wizard appropriate for the platform you are using for this new server.
Replicating Critical Databases
In a multiple server environment, there are 2 databases that must be replicated among your servers – names.nsf and admin4.nsf. This is critical in order for the administration process to function correctly. In small companies with 10 Domino servers or less, replication is typically a push/pull replication from the administration server as shown in figure 2. Replication is scheduled using a
connection document. In the example you can see that connection is from Server1/Company A to Server2/Company A. On the
Replication/Routing tab, the replication type is
Pull Push which means changes made in those databases will flow to and from each server. The
Files/Directory paths to replicate has been defined as
names.nsf and
admin4.nsf so only those databases will replicate. Finally, on the
Schedule tab, the replication is configured to run every 20 minutes every day.
For more information the administration process including example replication topologies for larger Domino deployments and adminp basics, refer to the
Notes/Domino Best Practices: Administration Process article. Be aware that to prevent replication conflicts and to ensure proper operation of the adminp task, the domino directory (names.nsf) must have the same server specified as the administration server for ALL domino servers in the domain. This can actually be expanded to any application. You will not have one server in your domain that is the administration for every database in your domain; however, each application replica should use the same administration server.
While only names.nsf and admin4.nsf must be replicated, you can choose to replicate all databases in common between the servers. In this case, be aware that nearly all templates will replicate between the servers. For more information, refer to the
Domino Template Replication and Design article on the Domino wiki. In most cases, this is desired; however if you need to co-exist in a multiple release environment and do not want the design to be updated to the latest release, see
7.5_Design_replication_and_mixed_releases__avoiding_design_ping-pong
for more information.
In figure 2 above, you saw an example of probably the most common and simple replication configuration. There are a number ways you can improve on that schedule when working in enterprise size deployments of Domino:
- Set specific times in the schedule rather than an interval.
- Set a replication time limit.
- Avoid replicating databases during scheduled maintenance times.
- Consider time zones.
- Avoid pushing massive updates to the Domino Directory during prime business hours, especially important for large enterprises or large directories containing a hundred thousand users or more.
What is the difference between using the times and setting a time range and repeat interval? The difference is that with the repeat interval the replication will not always occur at the same time. That is because the repeat interval starts when the replication completes. So if the first replication starts 12:00 and takes 15 minutes, the next replication will occur at 12:35, not 12:20. When setting a specific start time, it can be easier to troubleshoot replication if you know exactly what time it will occur. Set a replication time limit to avoid one replication event from starting before the previous replication is completed. Keep in mind that if you want very frequent replication on some databases, it will be much simpler to use a repeat interval.
To consider these keys points, imagine that Company A has recently expanded their enterprise globally and added a group of servers in Rio de Janeiro. The company now has two groups of servers
Server Group US and
Server Group Brazil. They have decided they want to replicate names.nsf, admin4.nsf and their mail files every 60 minutes. They run their backups at 12:00 a.m., the design task at 1 a.m. and updall task at 2 a.m. They run weekly compacts on all databases on Saturday from 4 a.m to 7 a.m. How can you create a replication topology that satisfies the business requirements and avoids the maintenance windows assuming these servers are located in the EST and BRST time zones?
| EST Time |
|
|
| 12:00 a.m. – 3:00 a.m. Daily |
3:00 a.m. – 6:00 a.m. Daily
|
Nightly maintenance window for US servers
|
| 4:00 a.m. – 7:00 a.m. Saturday |
7:00 a.m. – 10:00 a.m. Saturday
|
|
| 9:00 p.m. – 12:00 a.m. Daily |
12:00 a.m. – 3:00 a.m. Daily
|
Nightly maintenance window for Brazil servers
|
| 1:00 a.m. – 4:00 a.m. Saturday |
4:00 a.m. – 7:00 am. Saturday
|
Compact for Brazil servers
|
You can now easily see what times you should avoid scheduling large replication events depending on which server you initiate the replication. Assuming Server 1 is located in the EST time zone, you can create a connection document as shown in the folloing figure.
By creating the connection document in this way, you can accommodate for the maintenance windows and time zones for both servers for every day but Saturday. You can then create another document for Saturday. The following figure shows the example for Saturday from the server 2 located in Brazil to Server Group US.
Mail Routing
Typically you want all of the servers in your Domino domain to be able to exchange mail as needed. If all of your Domino servers are in the same Notes Named Network (NNN), then Domino automatically know how to route mail between your servers. If they are not in the same NNN, then you need to have
two connection documents: server1 to server2 and server2 to server1.
What is the Notes Named Network? The NNN is a way to logically group your servers based on your physical network. It is defined in the server document in the
Notes Network parameter which is found on the
Ports →
Notes Network Ports tab in the server document as shown in figure 6. By default, the first server in a Domino domain is created into a network called
Network1 and additional servers default to
TCPIP Network. Thus you should choose a value for your servers or set the network name to match if appropriate based on your network topology.
In order to send mail between two Domino servers, the server must know where to send the mail and must be able to make a connection to the remote location. If you have properly configured your NNN or connection documents. you have satisfied the first requirement. The second requirement requires a close working relationship with your network administrator. The Domino servers uses the Notes remote procedure call (NRPC) protocol over the port 1352 when sending mail or replicating. If you have a firewall between your Domino servers, you must ensure that port 1352 is open in both directions in order for mail to be successfully exchanged.
Monitoring and Managing Multiple Servers
Monitoring the log or Domino console manually is a rather straight forward task in a single server environment. As you add more servers to your environment, this task becomes increasingly more difficult. Domino provides multiple tools to simply this task so it is important to remember to use these tools and add your new server to this environment. Information on configuring monitoring and alerts can be found in
3.1 Monitoring.
Here is a simple checklist for you:
- Add the new server to DDM Hierarchy.
- Configure Diagnostic Collection for the new server if you do not use a global configuration document for this.
- Configure statistics collection document for new the server.
Clustering
Another common reason for expanding the Domino domain is to be able to provide high availability to your users. To date, there is no hardware or software that will or can guarantee the system will be up from now until the end of time. Therefore your Domino server will be down at some point. Whether the server is down for routine maintenance, upgrades or a natural disaster; Domino application clustering is simple to configure and use to provide high availability for your users.
Key clustering concepts for the new Domino Administrators are:
For detailed information on clustering refer to the article
Understanding IBM Lotus Domino server clustering and
3.5 Server Clustering Options.