With Hipchat Data Center you can now deploy a multi-node cluster, which allows you to scale your deployment for large numbers of users, and to create a highly-available (HA) application. If your organization doesn't need scale or availability, you can deploy Hipchat Data Center using only one Hipchat node and combine other services on a second node. 

The configuration requirements (such as open ports, usernames and settings, etc) are very for the services, no matter which option you decide to deploy. 

---

Small-scale Hipchat Data Center deployment

For a small-scale deployment you'll need a reverse proxy, and two nodes. One node will host the Hipchat application, and the other will host the combined data stores (Postgres, Redis, and the file store) used by the application. That's three machines, down from seven. 

Use a small-scale deployment when:

• Your deployment serves 2000 users or fewer.
• You're deploying a temporary evaluation, test, or development instance.

Read the small-scale Hipchat Data Center set up guide.

Small-scale requirements

• The reverse proxy host can be small: 2 cores, with 2GB of RAM.

• The Hipchat application node must have 8 CPU cores (2.8GHz or faster), 16GB RAM, and a minimum of 40GB of (non-RAM) storage space.

• The data stores node must have 8 CPU cores (2.8GHz or faster), 16GB RAM, and at least 60GB of non-RAM storage. 

A small-scale deployment of Hipchat Data Center

---

Enterprise-scale Hipchat Data Center deployment

An enterprise deployment of Hipchat Data Center consists of a total of seven components: three Hipchat application nodes, and four component services including a load balancer, Postgres, Redis, and an NFS4 volume.

If you're deploying for high availability, you must also deploy highly-available versions of the component services, and that may require additional hosts and infrastructure.

Use an enterprise-scale deployment when:

• Your deployment serves more than 2000 users.
• Your organization requires High Availability (HA).

Read the Enterprise-scale Hipchat Data Center set up guide.

Enterprise-scale requirements

• The load balancer host can be small: 2 cores, with 2GB of RAM.
• The three Hipchat nodes must have 8 cores 2.8GHz CPU or faster, and a minimum of 16GB unallocated RAM. 
• The Postgres server must have at least an 8 core 2.25GHz CPU, with simultaneous threading (SMT) capability, 32 GB of memory, and at least 64GB of storage.
• The Redis server must have a 4 core 2.25Ghz CPU, and at least 8GB of memory.
• The NFS volume must be NFSv4, and accessible anonymously (with read and write permissions) by all three Hipchat Nodes.

An Enterprise-scale deployment of Hipchat Data Center

Additional infrastructure for High Availability

Highly-available deployments require:

• A backup load balancer for cluster access.
  This load balancer takes over if the primary load balancer fails. (The failover load balancer must support sticky sessions.)
  
  
• Additional Postgres hosts.
  These serve either as the replica(s) in a failover configuration, or as shards in for a multimaster configuration. 
  
  • A load balancer for Postgres, so that Hipchat can access the database cluster through a single endpoint.
    
    
• Additional Redis caches.
  Ideally a total of three Redis caches for a full HA Sentinel cluster. (Sentinel is the Redis feature that coordinates between replicas.
  
  • A load balancer for Redis, so that Hipchat can access the caches through a single endpoint, similar to this example using HAProxy.
    
    
• A highly-available solution for your NFS datastore.
  This might be a commercial solution such as a SAN (storage area network). What you choose here may vary based on your environment and the best practices in your organization. 

An Enterprise-scale deployment of Hipchat Data Center configured with highly-available component services

Scale and trade-offs

A small-scale deployment can save you administrative and maintenance time and reduce infrastructure costs. However, it can also introduce some single points of failure which you should be aware of as an administrator. Because there is only one of each component in the cluster there are no failover mechanisms, and a single node failure can make the entire Hipchat deployment unavailable. For example, if the node that hosts your data stores fails, all three data stores are affected and the deployment will immediately stop. Similarly, a problem on the reverse proxy will prevent users from accessing the service, and a failure on the Hipchat node itself will stop the service.

Load balancers vs reverse proxies

In both the small- and Enterprise-scale deployment options, clients access the Hipchat node(s) through a service which terminates SSL. This is required regardless of which deployment type you choose. 

In a small-scale deployment all client connections go to a single Hipchat node, so this service can be a reverse proxy. When you add nodes to create an Enterprise-scale deployment, the service must also function as a load-balancer which distributes client connections among the Hipchat nodes. If you think you might later increase your small-scale deployment to Enterprise-scale, you can choose one of several services (such as NGINX, HAProxy or Apache) that can function as both a load balancer and a reverse proxy.