To make planning easier IBM has categorized three different sizes of deployment of IBM Connections. Additional guidance can be found here
. The scenarios are as follows:
- Small deployment
- Medium deployment
- Large deployment
This option installs all applications in a single cluster on a single node and so is the simplest deployment. However, it has limited flexibility and does not allow you to scale up individual applications. For each node within the cluster, all applications run within a single JVM. The following figure shows a one node small deployment architecture.
The following figure shows one of the simplest deployments of IBM Connections, where each component is running on its own machine. This option does not provide any workload or disaster recovery, but it does provide simplicity to small organizations looking to run IBM Connections.
This option installs a subset of applications in separate clusters. IBM Connections 4 provides three predefined cluster names shared among all applications. This option is used to distribute applications according to usage expectations and allows you to maximize the use of available hardware and system resources to suit specific needs. The following figure illustrates a medium IBM Connections deployment architecture.
The following figure shows a typical medium deployment of IBM Connections. A two-node cluster is used for IBM Connections, with two HTTP servers in front handling all requests coming from the edge server. This approach also shows you how you can use IBM Tivoli® Directory Integrator (TDI) to merge data coming from multiple sources into the Lightweight Directory Access Protocol (LDAP) server and IBM DB2® database.
This option installs each application in its own cluster, and IBM Connections 4 provides a predefined cluster name for each application. This option provides the best performance in terms of scalability and availability options, but it also requires more system resources. The figure below illustrates a large architecture, with multiple nodes and clusters.
With a basic understanding of all the deployment options, you reach a decision point regarding all the additional servers and components that IBM Connections uses. The figure below shows a complex environment with multiple nodes, HTTP and proxy servers, and database clusters for each feature of IBM Connections (blogs, home pages, and more). Large organizations with strict service level agreements should consider deployments that include high availability and disaster recovery as well as sufficient resources to support the workload.
For large IBM Connections deployment, high availability considerations include:
- Clustering for Connections applications
Deploying IBM Connections applications in dedicated cluster provides better performance, scalability, and availability. This deployment requires more system resources and additional maintenance.
Lightweight Directory Access Protocol (LDAP) server is used to store user repository information for WebSphere application server. When the LDAP server fails, WebSphere cannot access directory data, such as security data, and hence fails to service client requests. Therefore, consider building a highly available LDAP as a part of the highly available WebSphere system. The LDAP high availability configuration and setup varies from vendor to vendor. As a general rule, place WebSphere Edge Component load balancer in front of LDAP server and access the LDAP server through cluster IP address. If any one of the LDAP server fails, request will route to another LDAP servers.
- Load balancing
A load balancer distributes load across a number of systems. If you have more than one HTTP server, you must use a load balancer. For moderately sized deployments, use a software-based load balancer, such as WebSphere Edge Component. For larger deployments, which support a large number of concurrent users, use a hardware-based load balancer such as F5 or Cisco ACE.
- Clustering for WebSphere - horizontal and vertical clusters
Horizontal clustering, sometimes referred to as scaling out, is adding physical machines to increase the performance or capacity of a cluster pool. Vertical clustering, sometimes referred to as scaling up, is adding WebSphere Application Server instances to the same machine. WebSphere clustering is a logical group of application servers that hosts the IBM Connections server applications either vertically or horizontally and provides the load balancing and high availability capabilities. Vertical clustering is not supported on IBM Connections 4.
- WebSphere Edge caching proxy
WebSphere Edge Caching Proxy Server is a proxy Server which can be used to cache content from backend so that the servers are relieved from high load. This in turn helps faster response from the server and improves user experience. You can configure WebSphere Edge Server for high availability by using additional WebSphere Edge Server as a backup server. When the primary WebSphere Edge Server fails, the user requests are sent to the backup server.
- Relational database management systems
IBM Connections applications supports IBM DB2, Oracle, and SQL server for storing application related data. Each database systems provides high availability features and can be used for IBM Connections data.
- IBM DB2
DB2 supports a number of software and hardware offerings from IBM and other vendors that you can use with DB2 to strengthen high availability in your environment.
IBM offers the following high availability configurations. The options for implementing high availability and disaster recovery solutions with DB2 include:
- High availability disaster recovery
DB2 high availability disaster recovery (HADR) feature provides a high availability solution for both partial and complete site failures. HADR protects against data loss by replicating data changes from a source database, called the primary database, to one or more target databases, called the standby databases.
- Tivoli System Automation
Tivoli System Automation (TSA) clustering software is installed on TSA server, primary, and standby DB2 servers. Both the DB2 servers are monitored through heartbeat node installed on TSA server. In the event of primary database failure, TSA automatically fail back to standby node.
- Clustering with IBM PowerHA SystemMirror for AIX (formerly known as High Availability Cluster Multi-Processing for AIX or IBM HACMP™) or Microsoft Cluster Server for Windows.
- SQL Server
SQL Server provides the following options for creating high availability solutions:
- AlwaysOn Failover Cluster Instances
AlwaysOn Failover Cluster Instances leverages Windows Server Failover Clustering (WSFC) functionality to provide local high availability through redundancy at the server-instance level—a failover cluster instance (FCI).
- AlwaysOn Availability Groups :AlwaysOn Availability Groups is an enterprise-level high-availability and disaster recovery solution introduced in SQL Server 2012 to enable you to maximize availability for one or more user databases. AlwaysOn Availability Groups requires that the SQL Server instances reside on Windows Server Failover Clustering (WSFC) nodes
- Database mirroring : Database mirroring is a solution to increase database availability by supporting almost instantaneous failover. Database mirroring can be used to maintain a single standby database, or mirror database, for a corresponding production database that is referred to as the principal database. This feature is deprecated and not recommended for high availability solutions
- Log Shipping: Like AlwaysOn Availability Groups and database mirroring, log shipping operates at the database level. You can use log shipping to maintain one or more warm standby databases (referred to as secondary databases) for a single production database that is referred to as the primary database
Oracle database built-in high availability capabilities are as follows:
- Real Application Clusters (RAC)
- Data Guard
- Automatic Storage Management (ASM)
- Flashback, Recovery Manager (RMAN)
- Online Reorganization
- Edition-based Redefinition