arrow-down
    1. Overview
    2. Core concepts
    3. Using docs
    4. Intro Videos
    5. Tutorials
    1. Intro
    2. GraphQL API
    3. Media API
    4. Extending the API
    5. Component API
    1. Content Studio
      1. Branches
    2. Layers
      1. Lifecycle
      2. Media
      3. Attachments
      4. X-data
        1. Page templates
        2. Fragments
      5. Variants
      6. Permissions
      7. Versions
    3. Sites
      1. Visual editor
    4. Publishing
    1. Introduction
      1. Controllers
      2. Globals
      3. Events
      4. HTTP Request
      5. HTTP Response
      6. Error handler
      7. Filters
      8. Templating
      9. Localization
      10. Websocket
      11. Tasks
      12. Main controller
      13. Java bridge
      1. Admin Lib
      2. Application Lib
      3. Auditlog Lib
      4. Authentication Lib
      5. Cluster Lib
      6. Common Lib
      7. Content Lib
      8. Context Lib
      9. Event Lib
      10. Export Lib
      11. Grid Lib
      12. I18N Lib
      13. IO Lib
      14. Mail Lib
      15. Node Lib
      16. Portal Lib
      17. Project Lib
      18. Repo Lib
      19. Scheduler Lib
      20. Schema Lib
      21. Tasks Lib
      22. Value Lib
      23. VHost Lib
      24. Websocket Lib
    2. Other Libraries
      1. CLI
      2. Sandboxes
      3. Code
      4. Building
      5. Configuration
      6. TypeScript
    3. Building APIs
      1. Mappings
      2. Components
      3. Processors
      4. Contributions
    4. Building Webapps
      1. ID providers
      2. Admin Apps
      3. Admin Widgets
    1. Architecture
      1. TODO
      1. Navigating
      2. Users
      3. Applications
      4. Data management
      5. System info
      6. Audit Logs
      7. Task management
      1. Portal
      2. IDprovider
      3. Management
      4. Statistics
      1. Nodes and repos
      2. Properties
      3. Indexing
      4. Branches
      5. Editors
      1. DSL Queries
      2. NoQL Queries
      3. Filters
      4. Aggregations
      5. Highlighting
      1. ID providers
      2. System ID provider
      3. Users and groups
      4. Roles
      1. Strategies
      2. Distributions
      3. Docker
      4. Kubernetes
      5. Systemd
      6. Vhosts
      7. Configuration
      8. Backup & restore
      9. Clustering
      10. Observability
      1. Notes
      2. Upgrade
      3. Upgrading Apps
        1. Asset service
        2. HTTP service
        3. Image service
    1. Best practice
        1. AttachmentUploader
        2. Checkbox
        3. Combobox
        4. ContentSelector
        5. ContentTypeFilter
        6. CustomSelector
        7. Date
        8. DateTime
        9. Double
        10. GeoPoint
        11. HtmlArea
        12. ImageSelector
        13. Long
        14. MediaSelector
        15. Radiobutton
        16. Tag
        17. TextArea
        18. TextLine
        19. Time
        1. Field set
        2. Item set
        3. Option set
      1. Mixins
      2. Localization
      3. Styles
    2. Content Types
    3. X-data
    4. Macros
      1. Pages
      2. Regions
      3. Part component
      4. Layout component
      5. Text component
      6. Component Filtering
      7. Component Indexing
    1. Marketplace
    2. Market guidelines

Deployment strategies

Contents

Depending on your requirements for scalability, performance and isolation, there are a number of different deployment strategies to consider.

Single node

The minimal deployment of Enonic XP is limited to a single XP node. Similar to the XP SDK, this node will act as both front-end and back-end, running applications as well as handling storage.

In this case, you will simply need a local file system to store your indexes, blobs (raw data) and backups.

Single node deployment

Basic cluster

A basic XP cluster will provide redundancy, scalability and increased uptime for your services.

Enonic XP uses a distributed storage model without a dedicated master. It is crucial that the cluster always has one, and only one master. If your cluster at some point has more than one master, we have a so-called "Split brain" situation. Split brain means that you are essentialy running multiple clusters, where each cluster thinks it is the only one. As writing may occur in two different locations, this may result in loss of data or inconsistency.

To mitigate this, any cluster must at least have three nodes. At any time, only one of the nodes will act as master. Masters are elected based a quorum. With only two nodes, the cluster will not be able to form a quorum if one of the nodes fall out.

Under strain, a master node may start to perform slowly and behave unpredictably. A failing master may cause problems for your entire cluster. To avoid this scenario, one should always deploy three dedicated master nodes, and move processing to dedicated worker nodes. This should guarantee a stable set of master nodes to control your cluster, including where and how data is distributed.

This means that a minimal cluster requires at least five nodes, three master nodes, and two worker nodes. In theory, you could just start one worker node, but then again, that would not be a proper cluster.

In addition to running multiple nodes, clusters also have additional infrastructure requirements when compared to a single node:

  • A shared or distributed file system for storing blobs and for snapshotting, dump and export purposes

  • A load balancer is required to distribute incoming traffic to the various nodes in the cluster.

Cluster with dedicated master nodes
Due to the limited stress on the master nodes, they can normally be of smaller size than worker nodes.

Autoscaling cluster

If you want to quickly scale the number of instances of your cluster up or down based on sudden changes in traffic/load, you shold consider this option.

This scenario builds on the dedicated master nodes strategy, but now also differenciates between front-end and back-end nodes.

The front-end nodes will act as runtimes for the apps/site/admin and handle the incoming traffic. The back-end nodes will handle state, indexing and data persistence. The back-end nodes are typically able to serve multiple front-end nodes, as the request processing if often heavier on the front-end nodes.

Even if data nodes may also be scaled up an down, resizing front-end nodes is faster and easier than when it comes to data nodes. The downside of splitting into front-end and back-end nodes is a slightly higher latency when accessing your data.

Cluster suited for autoscaling
You may consider if you need different type of CPU/Memory assigned to the different node types. Typically, front-end nodes may require less memory than back-end nodes.

Micro service cluster

For enterprise class deployments, we recommend the micro service cluster strategy. It builds on the autoscaling cluster approach, but further aims to isolate the various services better. For instance, you might have dedicated nodes for the admin console, a specific site or app - all depending on needs.

You may even consider running selected services using combined nodes (handling both data and apps), for instance for admin nodes. In such a scenario, editors working in Content Studio minimally affect the performance of the other services.

The benefits of this strategy is a higher degree of control over each service and how it can be scaled, similar to how most cloud native micro service platforms work.

Full scale cluster deployment
In this scenario, each individual front-end service may be configured with different CPU/Memory and scaling options as required.

Contents

Contents

AI-powered search

Juke AI