Deployment options and sizing guidelines for HipChat Data Center
AWS deployment options for HipChat Data Center
HipChat Data Center can be deployed on AWS. We provide an AWS CloudFormation template which you can use as provided, or use as a reference implementation to build your own template. You can also deploy either of the architectures described here, substituting AWS components for the different required services.
|Postgres database||AWS Relational Database Service (RDS)
|Redis server||AWS ElastiCache, size:
|NFSv4 file system||AWS Elastic File System (EFS)|
|Load balancer||AWS Elastic Load Balancer (ELB)|
Enterprise-scale HipChat Data Center deployment
An enterprise deployment of HipChat Data Center consists of a total of seven components: a load balancer, three HipChat application nodes, and three external data stores (Postgres, Redis, and an NFS4 volume).
Use an enterprise-scale deployment when:
- You have more than 2000 users.
- Your organization requires High Availability (HA).
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:
- You're deploying a temporary evaluation, test, or development instance.
- Your deployment serves 2000 users or fewer
An Enterprise-scale deployment of HipChat Data Center
A small-scale deployment of HipChat Data Center
Load balancer or Reverse proxy?
In both deployment scale options, clients access the HipChat node(s) through a service which terminates SSL. This is required regardless of which deployment type you choose.
In an Enterprise-scale deployment this service is a load balancer which distributes client connections among the HipChat nodes. In a small-scale deployment all connections go to a single HipChat node, so this service can be just a reverse proxy.
Several services (such as NGINX or Apache) can function as both a load balancer and a reverse proxy. If you use one of these, you can quickly scale up your deployment later by adding more HipChat nodes.
- The load balancer host can be small: 2 cores, with 2GB of RAM.
- The three HipChat nodes must have 8 cores 2.8GHz 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.
We recommend that you start with at least 40GB of file storage for a new deployment, however if you're migrating from a HipChat Server deployment, you might need more storage.
- If your deployment requires high availability (HA) then you must configure both Postgres and Redis to be highly-available. This may require additional infrastructure.
- The reverse proxy (load balancer) 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.
If you are migrating from a HipChat Server deployment, you might need to increase the data store node's available storage based on the number and size of messages in your exported server data.
Single points of failure
A small-scale deployment can save you administrative and maintenance time and reduce infrastructure costs, however it can be hazardous. If the node that hosts your data stores fails, there are no failover mechanisms, all three data stores are affected, and the deployment will immediately stop.
Be extra sure that the data stores node has a good backup and recovery mechanism.