[SEO Subhead]
This Guidance demonstrates how to install and configure Perforce Helix Core, a popular version management tool for game developers, on AWS. It shows how to deploy Perforce with high availability across multiple AWS Regions and also covers secure connectivity from on-premises data centers and remote clients. By following this Guidance, game developers can implement a Perforce Helix Core installation on AWS, aligning to best practices and keeping costs low.
Please note: [Disclaimer]
Architecture Diagram
[Architecture diagram description]
Step 1
Choose a file system to store your depot. If your depot is less than 16 TB, we recommend running Helix Core on Amazon Elastic Block Store (Amazon EBS) GP3 volumes. For larger depots, we recommend Amazon FSx for NetApp ONTAP or Amazon FSx for OpenZFS. To optimize costs, FSx for ONTAP deduplication and compression are well suited for use with Helix Core depots.
Step 2
The Perforce Helix Edge Server Proxy in the studio data center connects to the primary AWS Region with AWS Direct Connect or AWS Site-to-Site VPN, depending on bandwidth and connection availability needs. On-site Perforce clients connect to the proxy to gain the benefits of local performance for commits.
Step 3
Remote users connect to the nearest edge server through AWS Client VPN, another virtual private network (VPN) solution, or with a virtual workstation.
Step 4
AWS Transit Gateway connects Amazon Virtual Private Clouds (Amazon VPCs) to on-premises networks and connects to VPN through a hub-and-spoke model that simplifies complex peering relationships and encrypt data in transit.
Step 5
These connections go through a NAT Gateway, which allows resources in a private subnet to connect to services outside of the Amazon VPC. External services cannot initiate a connection with the private resources.
Step 6
Users choose a Perforce commit-edge server to connect to based on the closest Region. This commit-edge architecture offers the best overall performance with most commands running locally.
Step 7
The primary and replica servers run in separate Availability Zones to increase availability. High availability and disaster recovery can be achieved through either a snapshot or replica strategy (with edge server replicas as an option). Restoring from an Amazon EBS snapshot or from AWS Backup is slower than replica failover, but more cost effective.
Step 8
AWS Backup is used for Amazon FSx backups. For Amazon EBS, snapshots are the standard backup mechanism. Though AWS Backup works with Amazon EBS, it’s not required for this solution.
Well-Architected Pillars
The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you make when building systems in the cloud. The six pillars of the Framework allow you to learn architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems. Using the AWS Well-Architected Tool, available at no charge in the AWS Management Console, you can review your workloads against these best practices by answering a set of questions for each pillar.
The architecture diagram above is an example of a Solution created with Well-Architected best practices in mind. To be fully Well-Architected, you should follow as many Well-Architected best practices as possible.
-
Operational Excellence
AWS CloudFormation allows consistent, repeatable deployments of the application and resources, removing sources of error during deployment that may impact security, reliability, and costs.
Amazon CloudWatch provides operational metrics and monitoring for the application and resources, logging to a single location, no matter how many resources you are using. Operational and health metrics are also captured at scale and are on by default for all services.
-
Security
Transit Gateway encrypts traffic any time it traverses network links, both inside and outside of AWS. Transit Gateway is a secure, centrally managed service to provide secure peering for both inter- and intra-Region networking.
Client VPN provides a secure connection to the hosted Perforce Helix Core applications from off-site clients. For virtual workstations, NICE DCV secures both pixels and end-user inputs using end-to-end encryption between the client and server. It also requires authentication from the client before allowing a connection.
-
Reliability
AWS Backup centrally manages and automates data protection for the various storage mechanisms used in this architecture diagram. AWS Backup simplifies the backup and recovery of Amazon FSx and, if desired, Amazon EBS stores your Perforce depot and builds a foundation for disaster recovery and business continuity. Additionally, Amazon Elastic Compute Cloud (Amazon EC2) allows you to deploy Helix Core standby replicas in different Availability Zones, allowing instant failover in case of an Availability Zone issue.
-
Performance Efficiency
Amazon EC2 provides global infrastructure to place Helix Core edge servers closer to your globally distributed users. Deploying Helix Core edge servers across multiple AWS Regions allows studios to give lower latency access to developers globally by placing edge instances closer to their location. Replication occurs on the AWS high-speed global network, rather than relying on public internet. This allows edge servers to keep in sync more rapidly and frequently.
Additionally, high performance storage is critical for allowing Helix Core to respond quickly and scale to multiple users. Both Amazon EBS and Amazon FSx provide high speed SSD based storage for responsive file retrieval and commits.
-
Cost Optimization
Amazon EC2 provides many different sizes of instances, allowing developers to choose the exact instance size they need. Instances can be scaled up and down as projects transition through various phases of the game development pipeline. Additionally, Amazon FSx provides a cost-effective solution for larger Helix Core depots. Amazon FSx is well suited to the use patterns of large Helix Core depots, and Amazon EBS is an even more cost-effective choice when depot sizes are below 16 TB.
-
Sustainability
Amazon EC2 allows studios to create instances on demand and provides efficient CPU options. Allowing studios to move from on-premises hardware to the cloud enables them to run compute power on an as-needed basis. This reduces waste from redundant or obsolete hardware and means that studios’ Perforce infrastructure will run from at least 90% renewable energy.
Implementation Resources
A detailed guide is provided to experiment and use within your AWS account. Each stage of building the Guidance, including deployment, usage, and cleanup, is examined to prepare it for deployment.
The sample code is a starting point. It is industry validated, prescriptive but not definitive, and a peek under the hood to help you begin.
Related Content
[Title]
Disclaimer
The sample code; software libraries; command line tools; proofs of concept; templates; or other related technology (including any of the foregoing that are provided by our personnel) is provided to you as AWS Content under the AWS Customer Agreement, or the relevant written agreement between you and AWS (whichever applies). You should not use this AWS Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the AWS Content, such as sample code, as appropriate for production grade use based on your specific quality control practices and standards. Deploying AWS Content may incur AWS charges for creating or using AWS chargeable resources, such as running Amazon EC2 instances or using Amazon S3 storage.
References to third-party services or organizations in this Guidance do not imply an endorsement, sponsorship, or affiliation between Amazon or AWS and the third party. Guidance from AWS is a technical starting point, and you can customize your integration with third-party services when you deploy the architecture.