The basics of a distributed Helix Versioning Engine installation are covered in the Multi-Site Deployment Guide
guide. This article provides a summary of those basics with references to more detailed documentation. A distributed Helix Versioning Engine installation builds upon Perforce Replication technology. Read and understand the chapter on Perforce Replication in the Multi-Site Deployment Guide
before deploying a distributed installation.
Commit and Edge Servers
A commit server stores the canonical archives and permanent metadata. In working terms, it is similar to a Perforce master server, but may not contain all workspace information.
An edge server contains a replicated copy of the commit server data and a unique, local copy of some workspace and work-in-progress information. In working terms, it is similar to a forwarding replica, but contains local workspace data and can handle more operations with no reliance on the commit server.
A distributed Helix service consists of a combination of a commit server and one or more edge servers.
Since an edge server can handle most routine operations locally, a distributed Helix service offloads a significant amount of processing work from the commit server and reduces data transmission between commit and edge servers. For more details on behaviors of edge servers, see the following
Knowledge Base article.
From a user's perspective, most typical operations until the point of submit are handled by an edge server. With a forwarding replica, read operations, such as obtaining a list of files or viewing file history, are local. With an edge server, syncing, checking out, merging, resolving, and reverting files are all local operations on the edge server.
Deploying commit and edge servers can be done incrementally. An existing master server may be configured to act as a commit server. The commit server continues to service existing users, workspaces, proxies, and replicas with no change in behavior. The only immediate difference is the commit server can now support edge servers.
Once a commit server is available, you can proceed to configure one or more edge servers. Deploying a single edge server for a pilot team is a good way to become familiar with edge server behavior and configuration. Additional edge servers can be deployed periodically, giving you time to adjust any affected processes and educate users about any change to their workflow.