Note
This article covers self-hosted TeamCity On-Premises and is not related to the hosted TeamCity Cloud offering.
Question
How should a self-hosted TeamCity High Availability (multinode) setup be deployed on AWS, and which AWS services correspond to each TeamCity component?
Answer
TeamCity HA components
A high-availability multinode setup requires, at minimum: a main server node, one or more secondary nodes, a shared Data Directory on network storage, an external database, and a reverse HTTP proxy in front of the nodes. The server nodes should have comparable resources, and the shared Data Directory should be hosted on separate, well-performing storage that stays reachable if a node goes down. See Multinode Setup for High Availability.
Mapping to AWS services
Deploy the nodes and storage across at least two Availability Zones.
| TeamCity component | AWS service | Notes |
|---|---|---|
| Server nodes (main + secondary) | Amazon EC2 in two or more AZs | Use local Amazon EBS volumes for the installation and the node-specific data directory which contains the caches |
| Shared Data Directory | Amazon EFS (multi-AZ NFS) | Amazon FSx for OpenZFS or NetApp ONTAP are lower-latency alternatives; Amazon FSx for Windows File Server suits SMB or Windows environments |
| External database | Amazon RDS Multi-AZ, or Amazon Aurora (MySQL- or PostgreSQL-compatible) | Aurora provides faster failover; see the failover note below |
| Reverse proxy / load balancer | Application Load Balancer, or NGINX on Amazon EC2 | Routes traffic to the main node with health-check-based failover |
| Build artifacts | Amazon S3 via the artifact storage feature | S3 is more cost-efficient and scales better for artifact storage than local. See Amazon S3 and S3-compatible Storages |
| Build agents | Amazon EC2 (cloud profile) | See Setting Up TeamCity for Amazon EC2 |
| Backups | AWS Backup covering EFS and RDS | Capture the file system and database together while the server is stopped, so they restore as a consistent pair |
Data Directory latency
TeamCity is sensitive to Data Directory I/O. Keep the node-local caches (<Data Directory>/system/caches) on local storage per node rather than on the network share, per System Requirements and HA setup guide. If Amazon EFS latency affects performance, consider a lower-latency Amazon FSx file system.
Database failover connections
After a database failover, the TeamCity connection pool can retain connections to a former or read-only instance. Configure a connection validation query and pool health checks so TeamCity reconnects to the current writer, and point TeamCity at the cluster writer endpoint. See Using AWS Aurora Database Cluster.
Failover model
A secondary node provides a read-only interface by default. Switching data processing to it after the main node goes down is a promotion of the secondary to main, not an automatic write failover. See Multinode Setup for High Availability.
Consistent backups
The Data Directory and the database must be backed up and restored as a matched, same-moment pair. Stop the TeamCity services first, then trigger the EFS and RDS backups together, so a restore returns both to the same state. See TeamCity Data Backup.
Comments
0 comments
Please sign in to leave a comment.