Perforce Public Knowledge Base - Migrating to a Distributed Helix Service
× PRODUCTS SOLUTIONS CUSTOMERS LEARN SUPPORT
Downloads Company Partners Careers Contact Free Trials
Menu Search
Perforce
Reset Search
 

 

Article

Migrating to a Distributed Helix Service

« Go Back

Information

 
Problem
I want to move to a Distributed Helix Service architecture but don't know the exact migration path to take?
 
Solution

Moving to a Distributed Helix Service architecture all at once is a big undertaking. Incremental migrations may be attractive to larger sites that only see performance problems at some remote sites.

Some sample migration strategies to consider based on your current deployment are detailed below.
 

Current deployment

Migration strategy

Notes

Advantages

Single server

 

 

 

One time, fewer edge servers

  • Stand up a new commit server on new, less powerful hardware.
  • Implement backup strategy for commit server similar to existing server.
  • Repurpose existing server as the new edge server, retaining existing backup strategy
  • Add another edge server if existing performance is poor
  • Most efficient use of existing hardware

One time, more edge servers

  • Retain existing server as new commit server
  • Analyze performance per site and per user type
  • Determine filtering for each edge server
  • Determine backup plan for each edge server
  • Stand up edge servers either in VM or low cost hardware
  • Little impact on existing main server

Incremental

  • Retain existing server as new commit server
  • Stand up new edge servers as necessary to accommodate new growth
  • Simplest option

Incremental with support for remote sites and automation

  • Retain existing server as new commit server 
  • Analyze needs for remote sites and/or automation
  • Filtering and backup planning for new edge servers
  • Deploy new edge servers for remote sites and/or automated processes, either in VM or low cost hardware
  • Minimal impact on 'main office' users
  • Better performance for remote sites
  • Offload automation burden

P4D and proxies

 

Proxy replacement, existing hardware

In this scenario, analyze the main server per the 'Single server' scenarios. Then analyze proxy use. If the proxy is providing acceptable performance for a remote site or automation, leave it be. Otherwise, must connect proxy to an edge server that has enough load capacity.. Otherwise:

  • Stand up an edge server on the existing proxy hardware
  • Implement a backup plan
  • Implement filtering
  • Most direct replacement path for proxies.
  • Superior performance at remote sites.

Proxy replacement, new hardware

Like the previous scenario except edge servers deployed on new hardware or VMs. Requires load analysis to determine how many edge servers are necessary per site.

  • More efficient remote site deployments
  • Chance to replace old hardware with VMs

P4D + Proxies + Replicas (Forwarding or Build)

 

Replica replacement, existing hardware

Analyze single server and proxy scenarios per earlier discussion.
Recommend to replace forwarding/build replicas with edge servers. They can be reconfigured easily and provide better performance.

If the existing replica hardware and performance are ok, then:

  • Reconfigure replica as edge server
  • Implement backup plan
  • Implement filtering
  • Superior performance with minimal planning impact

Replica replacement, new hardware/VM

Similar to previous discussion, but eliminate out-of-band replica hardware and replace with one or more edge servers.
Additional steps:

  • Performance analysis of each replica to determine number of replacement edge servers
  • Provision new hardware or VMs.
    A combination of existing replica hardware and new hardware/VMs can be used in an incremental approach.
  • Use virtual infrastructure rather than dedicated hardware

DR replica

Reconfigure

A DR replica is still useful. It can be pointed at the new 'main server', be it a hybrid commit server or just a new commit server. Reconfiguration may be necessary but is expected to be minor updates to the server spec and not have any functional impact.

  • n/a



 

Related Links

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255