Data Center Edition, Clustering, High Availability, and Scale: Configuration, Design Patterns, and Trade-Offs

1. Single-node Server versus Data Center Edition

Data Center Edition is not the “large server” switch. It is a licensed distributed architecture intended for resilience and scale. A well-sized Enterprise single-node installation can still be operationally simpler and may be the right answer when node-level HA is not required. DCE becomes compelling when the service objective explicitly requires application/search node fault tolerance or when measured compute scale justifies horizontal application-node capacity.

2. Application scaling versus search scaling

Current DCE scaling documentation explicitly supports adding application nodes—up to ten total—to increase computing capabilities. That does not mean ten app nodes are always useful. Horizontal application growth helps when Web or Compute Engine is the proven bottleneck and the database/search tiers can sustain the added concurrency.

Search scaling is constrained by Elasticsearch cluster design, storage latency, heap/GC, index size, and quorum/availability semantics. Search nodes are generally sized with more CPU/RAM than application nodes, and Sonar recommends SSDs. Do not add search nodes merely because scanner throughput increased; first observe es.log, search health, disk, JVM metrics, and indexing/query latency.

3. Load-balancer design: health and forwarded traffic, not session tricks

The load balancer must distribute HTTP requests across application nodes, terminate HTTPS correctly if that is its role, and remove unhealthy backends from routing. Current SonarSource DCE requirements explicitly state that sticky sessions are not required because the built-in JWT mechanism handles session behavior.

Required LB contract
- backends: every healthy application node only
- health: application status endpoint that identifies routable nodes
- HTTPS: preserve correct reverse-proxy headers/base URL semantics
- capacity: backend connection/request limits sized from evidence
- no public route to 9001/9002/9003 cluster ports
- no assumption that LB health proves CE/search/database health

4. Physical/VM/Docker versus Kubernetes DCE

Orchestration does not eliminate the shared database requirement or transform a single failure domain into true HA. If every pod, database, ingress, and persistent dependency sits on one physical host or one failure zone, the YAML may look distributed while the service is not resilient.

5. Current Kubernetes considerations

The current DCE Helm chart exposes separate image tags for applicationNodes and searchNodes, with topology-spread examples for availability zones. Current chart guidance also emphasizes memory requests/limits that reflect JVM heap requirements. Treat these as starting points; Chapter 31 will turn workload evidence into sizing decisions.

# Illustrative fragment — not a full install manifest.
applicationNodes:
  replicaCount: 2
  image:
    tag: 2026.4.1-datacenter-app
searchNodes:
  replicaCount: 3
  image:
    tag: 2026.4.1-datacenter-search
# external database and real secret references omitted intentionally

Pin chart/image versions and verify the exact current chart schema before use. Do not copy this fragment into production as a complete values file.

6. Availability versus disaster recovery

DCE reduces outage from certain node failures. It does not solve database corruption, destructive configuration changes, lost credentials, region loss, or a bad schema migration. Those are DR/backup/change-management problems. A production design therefore needs both:

• HA objective: what node/AZ failures must the live cluster absorb?
• DR objective: what RPO/RTO applies when the durable database or whole cluster must be restored?
• Rollback boundary: what can be reversed in place and what requires database restore?

7. DCE upgrades are coordinated cluster changes

Do not infer that a distributed deployment supports unconstrained rolling upgrades. Current guidance requires coordinated upgrade behavior, including database migration through /setup when required. For Helm DCE upgrades, search pods become ready first and only one application replica is brought up while the database migration is pending. Plugin installation/update also requires cluster downtime across application nodes. Chapter 29’s supported-path and backup discipline remains the governing model.

8. Worked decision table

Knowledge check

Official references and version notes

• DCE topology — current role model and minimum/default 2 application + 3 search topology.
• DCE installation requirements — node identity, search-node placement, hardware guidance, Docker/network/load-balancer requirements.
• DCE-specific system properties — current cluster roles, host lists and default application-cluster port.
• DCE network rules — default 9000/9001/9002/9003 trust paths.
• DCE scaling — application-node scaling, currently up to ten application nodes.
• Installing the database — current supported database engines/versions including PostgreSQL 14–18.
• Official SonarQube DCE Helm chart — current DCE chart/image structure and application/search node configuration.
• Performing an update — coordinated DCE Helm/database migration behavior and post-update reanalysis.