Deployment options and sizing guidelines for Hipchat Data Center
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.
Looking for more deployment tiers?
Only the listed hardware configurations are currently supported. If you are comfortable with hardware performance analysis and know your cluster needs, you can substitute different hardware in your deployment. However we cannot guarantee good performance if you do so, and it is your responsibility to test and validate your configuration.
Small-scale Hipchat Data Center deployment
Enterprise-scale Hipchat Data Center deployment
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.
AWS deployment options for Hipchat Data Center
Hipchat Data Center can also 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. If you're familiar with CloudFormation, you can also deploy either of the architectures described here, substituting AWS components listed here for the different required services.
Service | AWS equivalent |
---|---|
Hipchat nodes | c4.2xlarge servers |
Postgres database | AWS Relational Database Service (RDS)
|
Redis server | AWS ElastiCache, size: cache.m4.large |
NFSv4 file system | AWS Elastic File System (EFS) |
Load balancer | AWS Elastic Load Balancer (ELB) |
Atlassian currently publishes the Hipchat Data Center AMIs to the following regions:
eu-west-1 (Ireland)
eu-central-1 (Frankfurt)
us-east-1 (N. Virginia)
us-west-2 (Oregon)
ap-southeast-2 (Sydney)