Collabora Online high availability

Co-editing a document in Collabora Online only works when everyone editing that file lands on the same coolwsd process or pod. The mechanism that makes this possible is the WOPISrc parameter. The WOPI host includes WOPISrc in the URL it uses to open a document in the editor, and that value identifies the file. The load balancer in front of the coolwsd servers must hash or route on that parameter, so every user who opens the same document reaches the same backend. If the routing rule is wrong, two people can open the same file on two servers and edit separate copies that cannot be merged cleanly. The components involved are the WOPI host (for example Nextcloud), the reverse proxy or ingress, the coolwsd servers or Kubernetes pods, and the shared storage or document locations the host uses for files. The Helm chart README lists Nginx, HAProxy and OpenShift Router as supported ingress options. Each has its own way of expressing a hash or header-based rule, so the routing configuration is specific to the ingress you choose. Confirm the exact rule against the Collabora Online version you run, because the request paths and parameter handling are part of the product and can change between branches. Ask the vendor or check the release notes before you copy a configuration from an older guide. Routing by client IP address or by a cookie is a weaker choice. Users behind a shared corporate NAT or a proxy can share one IP, so a whole office may be pinned to a single server while other servers sit idle. Clients also change IP addresses on mobile networks, and a cookie can be dropped, expired or never set for a request that arrives through a different path. Either failure can split the users on one document across two servers. Routing on WOPISrc ties the decision to the document itself, which is the unit that needs to stay together. When a session is split, the effects show up quickly. Collaborative edits from one user may not reach the other, so each person sees a different state of the document until they reload. Copy and paste between sessions can fail or behave inconsistently, because the clipboard handling depends on the same server holding the editing session. Those symptoms are easy to mistake for browser or network problems, so test them deliberately during rollout. Before go-live, run a two-browser test on a shared document while you monitor which backend serves each request, and repeat it after any ingress change, scaling event or Collabora upgrade. Plan for a failover case too: when a pod is removed, documents on it must reopen cleanly on another backend, and the team should know who is responsible for that check.

Start capacity planning by measuring peak load. No per-editor sizing figure is available for this topic, so the number has to come from your own environment. Count peak concurrent sessions per document group over a representative period, such as a full business cycle that includes month-end. Total user counts overstate the load, because most licensed users never have a document open at the same moment. Pull the counts from the WOPI host logs, where file open and close events show which document each session used and when it started and ended. Ask the host's administrators which log entries record these events in your configuration, and confirm that the logs keep enough history to cover the peak you are sizing for.

Once you have peak sessions per document group, convert them into a node count. The Collabora Online Helm chart README lists production resource limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB. Use these as a starting reference for pod sizing and confirm them with a load test. Run the test against a single pod to find how many concurrent sessions it sustains with your document mix, divide your measured peak by that number, and round up. Then add headroom so that losing one node still leaves enough pods at peak. Because horizontal pod autoscaling is disabled in the chart, that headroom is a standing replica count you set and pay for continuously.

Document format and file size change the load, so the test corpus must match your real files. The product supports OpenDocument formats and Microsoft formats such as docx, xlsx and pptx, plus PDF, RTF, CSV and Visio files. Each type places different demands on CPU and memory while it loads, edits and renders. A spreadsheet with heavy formulas or a presentation with large embedded media can use far more memory than a short text document. Large files also hold memory for as long as their sessions stay open, so peak memory per pod depends on how many large files are open together. Sample documents from your file store by type and size, note which formats dominate the largest files, and build the test mix from that sample.

Spreading users across nodes does not help when a single hot document concentrates sessions on one node. The load balancer routes by the WOPISrc parameter, so every editor of one document reaches the same pod. A shared board pack with 40 simultaneous editors (illustrative) lands on one pod even when the cluster has spare capacity elsewhere. Sizing must therefore check the largest document group at peak as well as the total. Identify the hottest documents from the logs, load test a single pod with that document and its editor count, and decide whether the pod's limits and the node it runs on can carry the load. If they cannot, plan to split the document into sections or reduce concurrent editing on it, and confirm that a node failure still leaves that document a pod with enough capacity.

Finish with a load test that reflects the peak you measured, and repeat it when conditions change. Define pass criteria before the test, such as response times for typing and saving at the target concurrency. During the failover test, record which node or pod was removed and how long affected sessions took to recover. Re-run the test after each point release of your chosen branch, after changes to the ingress or chart resource settings, and after material growth in editors or file sizes. Ask Collabora or your implementation partner for any sizing guidance tied to your branch and edition, and confirm it against your own results. Keep the test scripts and log queries in version control so the next capacity review starts from the same method.

Before go-live, run five acceptance tests against a staging copy of the cluster that matches production in node count, ingress, TLS and WOPI host configuration. The tests cover routing, failure and the features users depend on most. Two users opening the same document must land on the same node, a node stopped during an active session must produce a predictable outcome, the load balancer must take an unhealthy node out of rotation, copy and paste must work within a session, and WOPI requests from addresses not on the allow list must be refused. Give each test an owner, a written expected result and a place to record what actually happened. A demo that looks fine is not evidence that the design holds under failure.

The routing tests check the most important design decision in this topic: load balancers must route by the WOPISrc parameter so every user editing one document reaches the same coolwsd server or pod. Open the same document from two separate user accounts through the production hostname and ingress, then confirm from server logs or pod identifiers that both sessions reached the same node. Repeat with several documents so a single lucky match does not pass the test. Ask your ingress administrator to show the exact routing rule in use. A rule based on cookies or source address can pass a two-user test and still split documents once real traffic arrives.

The node-loss test is where teams and business owners most often disagree, so define the expected outcome before stopping anything. Open a document, make edits, then stop the node or pod while the session is active. An acceptable result is that the client reconnects and recovers the session, or that users are clearly told to reload, with no silent loss of edits. Record what each user saw, then reopen the document and check its contents against what was typed. Confirm the exact node-loss behavior with Collabora for the release you run, since session recovery can differ between release branches. Do not treat results from one branch as proof for another.

Three smaller tests catch configuration errors that otherwise surface in the first support ticket. First, fail the readiness check on one node and confirm the load balancer stops sending new sessions to it, while existing sessions are handled as in the node-loss test. Second, within a single session, copy text from the editor, paste it into another part of the document, then paste formatted content back in, since copy and paste depends on the session staying on one node. Third, send WOPI requests from an address that is not on your allow list, such as a workstation on another subnet, and confirm they are refused. Nextcloud's administration guide recommends restricting WOPI requests to the addresses of the Collabora servers, so check that the list matches your real ingress and egress addresses.

Run the tests in a staging copy built from the same images or packages, ingress and TLS settings as production, and record any difference in the test log. Keep a simple record for each test with an identifier, date, release version, tester, steps, observed result, pass or fail, and evidence such as log excerpts or screenshots. Agree pass criteria with the business owner before the first run, not after. Decide which node-loss outcomes are acceptable, whether a forced reload is tolerable for each user group, and who signs off on exceptions. Re-run any failed test after a fix, and repeat the full set after any change to the release, load balancer or WOPI allow list. File the signed record with the go-live approval.