August 29, 2013

The Distributed Perforce Service

Healthcare

Image: nicknazrin w/Flickr

At the end of September, we will be releasing the new Perforce Distributed Service (currently in Beta). It's an advanced configuration of the Perforce Server that enables you to operate a set of coordinated servers across multiple machines, potentially spread across multiple data centers, in a clean and integrated fashion.

We've been working on this technology for years and I'm personally quite excited to see it becoming available.

Is Distributed for Me?

A Distributed Perforce installation offers a number of significant benefits. If you're trying to decide whether to deploy or not, ask yourself the following questions:

  1. Are the users of your Perforce Server located in multiple locations?
  2. Are your remote users suffering from reduced performance?
  3. Have you deployed proxies and read-only replicas successfully, but are still in need of better performance?
  4. Is your main Perforce server experiencing high load and reduced performance?
  5. Are Continuous Integration, build automation, and DevOps teams driving high automation loads across your main Perforce Server?
  6. Is it easier for your organization to add capacity by deploying additional servers than by increasing the power of your existing server hardware?

Answering "yes" to any of these questions means you would realize benefits from a Distributed Perforce installation. And if you answered "yes" to multiple questions, the benefits could be substantial!

Am I Ready for Distributed?

The immortal Peter Parker observed that, "with great power comes great responsibility." While it may actually have been Voltaire who said that, it's still worth considering.

Operating a Distributed Perforce Server is considerably more complex than operating a standard Perforce server. Although you can provide your users with dramatically improved performance, you don't want to find yourself in a situation in which your installation is more complex than you can manage.

So if you're considering deploying the Distributed Perforce, it's time for you and me to sit down and have a heart-to-heart talk.

Don't be nervous, I'm not trying to scare you. I just want you to spend a few minutes being honest with yourself.

Look through the following questions and answer them honestly. Consider your current knowledge of the Perforce Server with regards to these topics.

  1. Backup/Recovery
    1. Do you make regular backups of your Perforce server?
    2. Do you test those backups?
    3. Do you have a data retention policy for long-term backup storage?
    4. Do you regularly verify the archive contents of your server?
    5. Do you regularly verify the integrity of your server's database?
    6. Do you know how to detect damage to the server's database or archives, and do you know how to repair such damage should it occur?
    7. Do you have an offsite backup mechanism?
    8. Do you have a disaster recovery plan, and have you practiced it?
  2. Security
    1. Do you have security procedures and policies in place?
    2. Have you reviewed the security-related configuration of your server?
    3. Do you conduct regular security audits of your server? Could you tell if somebody was trying to break in to your server?
    4. Do you have network security measures in place? Are you comfortable with your ability to secure your corporate network?
  3. Personnel
    1. Do you have trained Perforce administrators in your remote offices?
    2. Do you have written documentation of your Perforce administration policies, and are your remote administrators aware of the processes?
    3. Do you have communication mechanisms for multiple administrators to alert each other of anomalies and discuss their resolution? For example, is there an internal "Perforce administrators" mailing list at your organization?
  4. Networking
    1. Have you assessed your internal network configuration, and are you aware of the capacity and performance of the network links to your remote sites?
    2. Do you have network monitoring systems in place? Can you track the utilization of your network links, and can you quickly detect and respond to network issues if they arise?
  5. Monitoring
    1. Are you comfortable monitoring the performance of your primary Perforce server?
    2. Do you understand what your typical workload is, and what your typical performance looks like?
    3. Do you keep historical records of performance observations, so that you can detect trends and patterns?
    4. Are all your monitoring tools available from a common portal? Is this infrastructure adequate to allow you to extend your monitoring to observe multiple Perforce servers from a single monitoring client?
    5. Do you have performance monitoring tools in place to alert you to unusual performance issues before they become serious problems?
    6. Do you actively monitor for resource issues such as running out of disk space?
  6. Automation
    1. Have you written automated tools for all your routine administrative tasks?
    2. Do you have a test environment where you can deploy test servers, run regression tests of your custom Perforce tools and processes, and shake out site-specific issues with upgrades?
    3. Are all your automated tools checked into the Perforce Server, so that your administrators can collaborate on them?
    4. Does this include things like your trigger scripts, your protections and group definitions, your server startup/shutdown scripts, and your server configuration settings?
    5. Do your tools thoroughly check the results of commands for errors? Are you confident that a failure in a regular automated task would be detected?
    6. Do you have remote automation facilities set up? Can a script on one Perforce Server machine securely and reliably perform administrative tasks on another machine?

I'm Ready! Bring It On!

If you flew through the questions above and would raise me a few questions back, then great! As I mentioned at the start of this article, the Perforce Distributed service is in Beta now, and it's not too soon to start getting involved.

  1. Download the beta Perforce Server and install it in your test environment. Run your internal regression tests.
  2. Read the Perforce Server beta release notes and make sure you understand them.
  3. Read the Distributed Perforce Server documentation in the System Administrator's Guide.
  4. Contact us with any questions that you have.
  5. Deploy a test version of the Distributed Perforce service across multiple test machines in your environment, and experiment with its functionality.
  6. Start preparing your upgrade and deployment plan.

I'm Not Ready. What Can I Do?

If you have thought about the above questions, and you realize that you're not yet prepared to take the step toward a Distributed Perforce installation, don't despair! You can still benefit from all the powerful capabilities that come with this release.

Talk to us!

Our Technical Support team can answer your questions and give you details about deploying a Distributed Perforce server.

Our documentation and Knowledge Base are full of useful information for you to read and absorb.

We'd be glad to help you set up test installations of a Distributed Perforce Server so you can experiment with the features and understand their behavior.

Our e-Learning team has lots of great instructional materials to help you cement your knowledge.

And if you have special needs, custom requirements, or particular circumstances, our expert consultants can customize your installation to them.

So, yes, the Distributed Perforce Server is more complex. It requires more from you, but the realized benefits can be dramatic. And just as you've come to expect from us, we'll be right there with you, ready to help make your installation successful.