Data Center Edition, Clustering, High Availability, and Scale: Core Concepts and Mental Model

1. The practical problem: one service now has several failure domains

Chapter 27 taught you to separate Web, Compute Engine, database, and Elasticsearch evidence. Chapters 28–29 add backup/restore and versioned migration discipline. Data Center Edition combines those same responsibilities into a distributed deployment. That increases resilience and compute capacity, but it also creates new invariants: every node belongs to one cluster, node roles are explicit, versions/plugins must match, private networks must be reachable, the application nodes must share trust material, and all nodes ultimately depend on one supported durable database.

The wrong mental model is “run five SonarQube servers behind a load balancer.” Five independent servers would have separate search state, separate configuration, potentially different plugins, and no supported cluster membership. The correct model is one licensed SonarQube Server cluster whose application nodes coordinate with each other and whose search nodes form one Elasticsearch cluster.

2. Mental model: load-balanced application tier + search tier + shared database

A scanner or browser reaches the public SonarQube URL through the reverse proxy/load balancer. The load balancer sends HTTP traffic to a healthy application node. Each application node hosts the Web process and Compute Engine capability; application nodes coordinate through the cluster transport. The application tier reads/writes the same supported external database and communicates with the search tier. The three search nodes host Elasticsearch and form one search cluster. Search indexes accelerate visibility and query behavior; they are not a second independent source of truth replacing the database.

flowchart TD
  S[Scanner / browser / CI] --> LB[Reverse proxy / load balancer]
  LB --> A1[Application node 1\nWeb + Compute Engine]
  LB --> A2[Application node 2\nWeb + Compute Engine]
  A1 <--> A2
  A1 --> DB[(Supported shared database)]
  A2 --> DB
  A1 --> Q1[Search node 1]
  A1 --> Q2[Search node 2]
  A1 --> Q3[Search node 3]
  A2 --> Q1
  A2 --> Q2
  A2 --> Q3
  Q1 <--> Q2
  Q2 <--> Q3
  Q1 <--> Q3

Current SonarSource guidance defines two application nodes and three search nodes as both the minimum and default topology. With that topology, loss of one application node and one search node can be tolerated without user impact, assuming the remaining infrastructure—including database and network—remains healthy.

3. Node roles: scale the bottleneck you actually have

Current DCE guidance allows application nodes to scale up to ten total. That is a capacity tool, not a universal performance fix. Search and database limits remain independent.

4. Network and trust boundaries: four default cluster paths

The defaults below are operational contracts, not ports to expose broadly. Firewall rules should permit only the documented source→destination relationships, with explicit alternatives recorded when you override defaults.

5. Cluster identity and shared state that must agree

Every node enables cluster mode and declares a node role. Application nodes need a consistent application-host list and search-host list; search nodes need the search-cluster host list. Application nodes also share the JWT signing secret used by the built-in session mechanism. That shared JWT design is why the load balancer has no sticky-session requirement.

# Illustrative only — fake hostnames, not a production manifest.
sonar.cluster.enabled=true
sonar.cluster.name=academy-dce
sonar.cluster.node.type=application
sonar.cluster.node.host=app-1.internal
sonar.cluster.node.port=9003
sonar.cluster.hosts=app-1.internal,app-2.internal
sonar.cluster.search.hosts=search-1.internal:9001,search-2.internal:9001,search-3.internal:9001
sonar.auth.jwtBase64Hs256Secret=${DCE_SHARED_JWT_SECRET}

The secret is shown as an environment reference on purpose. Never copy a real cluster secret into source, a lesson, or a support ticket. Versions, plugins, and application-node configuration must likewise be controlled as one deployment artifact.

6. High availability is not disaster recovery

A five-node DCE cluster cannot protect you from an unprotected database, a bad shared configuration pushed everywhere, or a region-wide failure when every dependency is in that region. Chapter 28’s database-backed recovery remains mandatory.

7. Read-only inspection before any cluster change

For a licensed cluster, capture the following before scaling, patching, restarting, or removing a node:

edition/license: Data Center Edition / current license status
server target: 2026 Release 4.1 (2026.4.1) or the exact installed release
node inventory: app-1, app-2; search-1, search-2, search-3
node versions: exact and identical by deployment set
plugin inventory: exact and identical across application nodes
app hosts/search hosts: effective cluster membership
load balancer: backend list + health-check path/status
shared database: engine/version/endpoint/latency/backup status
search: cluster health + disk/heap/GC/indexing evidence
CE: queue depth, workers, failed/pending task evidence
network: allowed source→destination ports
shared secrets: identifier/version only, never secret value
recovery: last tested backup/restore ID and rollback boundary

If you do not have a licensed DCE instance, the local simulator in Lesson 2 produces the same inventory fields and validates topology/network invariants without pretending to instantiate Sonar’s commercial cluster.

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.