Home
Welcome to the HCL Domino 11.0.1 documentation
Welcome to the HCL Domino® 11.0.1 documentation. Here administrators can find information about planning, installing, configuring, and administering Domino 11.0.1.
Planning
Use this topic as an overview of planning task.
Planning a cluster
When planning a cluster, it is important to consider the performance and ability of your hardware. The cluster must have enough CPU power, memory, and disk space to handle the cluster traffic and the number of databases and replicas required.
How Domino® clustering works
This section explains how HCL Domino® clustering works for Notes® clients and Domino servers. This section also describes operating system clusters and how Domino clusters work in conjunction with operating system clusters.
How failover works
An HCL Domino® server cluster's ability to redirect requests from one server to another is called failover. When a user tries to access a database on a server that is unavailable or in heavy use, Domino directs the user to a replica of the database on another server in the cluster.
How Domino® finds a replica during failover
When a user tries to open a database that is not available, the Cluster Manager looks in the Cluster Database Directory for a replica of that database. To find the replica, the Cluster Manager looks for a database that has the same replica ID as the original database. It also makes sure that the replica is not marked Out of service or Pending delete from the cluster.

Welcome to the HCL Domino 11.0.1 documentation
Welcome to the HCL Domino® 11.0.1 documentation. Here administrators can find information about planning, installing, configuring, and administering Domino 11.0.1.
- Translated documentation
  The HCL Domino 11.0.1 documentation is currently available in the following languages.
- What's new in Domino® 11?
  Learn about all of the new features for administrators in HCL Domino® 11.
- Overview
  Welcome to HCL Domino® Administrator Help.
- Domino trial
  A trial version of HCL Domino® 11.0.1 is available free of charge.
- Installing
  Use this documentation to install the HCL Domino® server and subsequently deploy the HCL Notes®client.
- Planning
  Use this topic as an overview of planning task.
  - Roadmap for deploying Domino® servers
    Use this as a tool when planning how to integrate HCL Domino® into your existing environment.
  - Planning server-to-server connections
    Servers must connect to each other to exchange data, for example to replicate databases and exchange mail. You can create connections between servers across a local area network (LAN) or wide area network (WAN), by using a pass-through server (a server that acts as an intermediary server between a client and its destination), or over the Internet. Create a Server Connection document whenever you need to establish any new or additional server connections. You can modify this document when necessary.
  - Planning directory services
    HCL Domino® provides a range of directory service features.
  - Planning a mail routing topology
    HCL Domino® offers you considerable flexibility in configuring your mail system infrastructure, allowing you to use HCL Notes® routing, SMTP routing, or both, for internal and external messages.
  - Planning a cluster
    When planning a cluster, it is important to consider the performance and ability of your hardware. The cluster must have enough CPU power, memory, and disk space to handle the cluster traffic and the number of databases and replicas required.
    - What is a Domino® cluster?
      An HCL Domino® cluster is a group of two or more servers that provides users with constant access to data, balances the workload between servers, improves server performance, and maintains performance when you increase the size of your enterprise. The servers in a cluster contain replicas of databases that you want to be readily available to users at all times. If a user tries to access a database on a cluster server that is not available, Domino opens a replica of that database on a different cluster server, if a replica is available. Domino continuously synchronizes databases so that whichever replica a user opens, the information is always the same.
    - Cluster benefits and requirements
      This section explains what an HCL Domino® cluster is, how a cluster can benefit you, and the hardware and software requirements for setting up and using a cluster.
    - How Domino® clustering works
      This section explains how HCL Domino® clustering works for Notes® clients and Domino servers. This section also describes operating system clusters and how Domino clusters work in conjunction with operating system clusters.
      - Clustering basics
        All the servers in an HCL Domino® cluster continually communicate with each other to keep updated on the status of each server and to keep database replicas synchronized.
      - How failover works
        An HCL Domino® server cluster's ability to redirect requests from one server to another is called failover. When a user tries to access a database on a server that is unavailable or in heavy use, Domino directs the user to a replica of the database on another server in the cluster.
        When failover occurs
        Failover occurs when users cannot access the server that contains the database they want or they cannot access the database itself.
        How Domino® finds a replica during failover
        When a user tries to open a database that is not available, the Cluster Manager looks in the Cluster Database Directory for a replica of that database. To find the replica, the Cluster Manager looks for a database that has the same replica ID as the original database. It also makes sure that the replica is not marked Out of service or Pending delete from the cluster.
      - How workload balancing works
        By distributing databases throughout theHCL Domino® server cluster, you balance the workload in the cluster so that no server is overloaded.
      - The cluster components
        Several components -- the Cluster Manager, Cluster Database Directory, Cluster Database Directory Manager, Cluster Administrator, and Cluster Replicator -- work together to make clustering function correctly. In addition, the Internet Cluster Manager clusters HCL Domino® servers that run Internet protocols.
      - How replication works in a cluster
        Cluster replication is event-driven, rather than schedule-driven. When the Cluster Replicator learns of a change to a database, it immediately pushes that change to other replicas in the cluster. If there is a backlog of replication events, the Cluster Replicator stores these in memory until it can push them to the other cluster servers. If a change to the same database occurs before a previous change has been sent, the Cluster Replicator pools these changes and sends them together to save processing time.
      - Mail failover in a Domino® server cluster
        Depending on how your HCL Domino® server cluster is configured, mail fails over in one of several ways.
      - How calendars work in a cluster
        HCL Domino® supports clustering of calendars and the Free Time database. When clustered, the scheduling system works a little differently behind the scenes than when it is not clustered. However, these differences are not noticeable to users.
      - How operating system clusters work
        The method of clustering that HCL Domino® uses is called application clustering. Domino, which is an application, monitors the cluster and determines when failover and workload balancing should occur, based on parameters that you set. Another form of clustering is operating system clustering. In this form of clustering, the operating system monitors the cluster and determines when failover should occur. When failover occurs, the server (called a node) to which you fail over takes over the resources of the failed node, accesses the storage space the failed node was accessing, and runs the applications the failed node was running.
    - Determining how many Domino® servers to include in a cluster
      Adding HCL Domino® servers to the cluster increases the cluster's ability to balance the workload so that no server becomes overloaded and performance stays high. However, if servers use too many server tasks, CPU-intensive applications, and replicas, adding servers can decrease performance because of the additional amount of cluster traffic required to keep databases synchronized on all servers.
    - Determining the number and placement of replicas in a cluster
      There are two major reasons to create a replica for a database in a cluster -- to provide constant availability of the data and to distribute the workload between multiple servers. Before you create replicas in a cluster, consider how frequently users access a database and their need for data redundancy. If a database is extremely busy or its availability is extremely important, create multiple replicas and locate them on your most reliable servers. For databases that are not very busy and whose constant availability is not important, you may not want to create any replicas at all. A server log file, for example, does not need to have a replica on another server.
    - Distributing databases in a cluster
      The way you distribute databases significantly affects workload balancing, as well as the performance of your equipment.
    - Determining whether to create a private LAN for your cluster
      To make a busy cluster more efficient, you can create a private network for your cluster. To do so, you install an additional network interface card in each cluster server and connect these network interface cards through a private hub or switch.
    - Clustering over a wide area network
      A cluster over a wide are network (WAN) works the same way as a cluster on a LAN. However, if you have a low-speed WAN, you should consider disabling cluster replication. Instead, use scheduled replication more frequently than usual, such as every hour. This reduces WAN traffic, bottlenecks, and the cost of continual transmission.
    - Fault recovery in a cluster
      Fault recovery is the ability of an HCL Domino® server to clean up and restart itself after a failure. Fault recovery works well in a Domino cluster. If there is no Domino server to fail over to, fault recovery still ensures that users will have constant access to their data. Even if users fail over to another cluster server, fault recovery increases availability because the failed server becomes available again. In addition, depending on the workload balancing parameters you've set, some users will fail back to the original server when they open new databases.
    - Planning to use the Internet Cluster Manager (ICM)
      Plan the cluster that the Internet Cluster Manager (ICM) will service. Then plan where to run the ICM itself and how many ICMs to run.
  - Planning the TCP/IP network
    The default TCP/IP configuration for an HCL Domino® server is one IP address that is globally bound, meaning that the server listens for connections at the IP addresses of all NICs on the computer. Global binding works as long as the computer does not have more than one IP address offering a service over the same assigned TCP port.
  - Planning the NetBIOS network
    The HCL Domino® network is compatible with NetBIOS, a set of IBM® session-layer LAN services that has evolved into a standard interface that applications use to access transport-layer network protocols.
  - Messaging overview
    The HCL Domino® mail system has three basic components: Domino mail servers, Domino mail files, and mail clients. The Domino mail server is the backbone of an organization's messaging infrastructure, acting both as an Internet mail server and an HCL Notes® mail server. Domino provides standards-based Internet messaging through its support of the Simple Mail Transfer Protocol (SMTP), Post Office Protocol version 3 (POP3), Internet Message Access Protocol (IMAP), and Multipurpose Internet Mail Extensions (MIME). At the same time, Domino supports Notes mail through the use of Notes routing protocols -- Notes remote procedure calls (NRPC) -- and the Notes rich text message format.
  - Planning your Notes® client deployment
    Use the references listed here to plan for, install, upgrade to, and configure the HCL Notes® client.
  - Planning security
    An important aspect of planning security for your Domino® environment is understanding the tasks and features involved with securing each type of resource.
- Configuring
  Use this information to configure your network, users, servers (including Web servers), directory services, security, messaging, widgets and live text, and server clusters.
- Securing
  This section describes security features, including execution control lists, IDs, and SSL.
- Administering
  This documentation provides information about the administration tools for managing and monitoring servers and databases.
- Tuning
  Use this information to improve HCL Domino® server, Domino Web server, and messaging performance through the use of resource balancing and activity trends, Server.Load commands, advanced database properties, cluster statistics, and the Server Health Monitor.
- Troubleshooting
  This section describes how to find and solve problems with HCL Domino® server and Administrator client.
- Notices

How Domino® finds a replica during failover

When a user tries to open a database that is not available, the Cluster Manager looks in the Cluster Database Directory for a replica of that database. To find the replica, the Cluster Manager looks for a database that has the same replica ID as the original database. It also makes sure that the replica is not marked Out of service or Pending delete from the cluster.

If there is more than one replica of a database on a server, the Cluster Manager assumes that selective replication is used to replicate these databases. To be sure it fails over to the correct replica, the Cluster Manager selects a replica that has the same path as the original database. Therefore, if you put multiple replicas on a server, be sure that all replicas in the cluster that use the same selective replication formulas have the same path. Otherwise, users may fail over to a different replica.

When failover occurs on a server, a failover or workload balance event is created in the log file.