Dedicated Gen 3
Dedicated Gen 3 provides a scalable solution as an additional option on top of your existing Grid applications. It provides redundant configuration with a minimum of three Virtual Machine instances. Every service is replicated across all three virtual machines in a failover configuration (as opposed to sharding, allowing a site to remain up even if one of the VMs is lost entirely.
Projects often require a dedicated production cluster when they require high availability or need more resources than normally offered by Grid plans. Another common reason is data location requirements, such as the need to deploy to a location without a current region or a requirement that production data can’t be kept on shared infrastructure.
Dedicated Gen 3 works nearly identically to Grid environments and doesn’t require additional configuration on your part. The only difference is that of service availability.
Dedicated Gen 2 infrastructure ensures increased uptime and availability for your applications and services, but configuration or application topology changes have to go through the Customer Success team as Platform.sh provisions the virtual machines. Dedicated Gen 3 gives you both the high availability of Dedicated Gen 2 and the self-service flexibility and features of Grid projects.
This means that you can edit your configuration yourself and then see those changes reflected in your Dedicated Gen 3 environments on every push without opening a ticket.
- A minimum of three virtual machine cluster is associated with your default (production) environment, and also optionally with a staging environment.
- Configuration changes on development environments (through your
.platform.app.yamlfiles) are reflected on these Dedicated Gen 3 clusters when you merge them. It isn’t necessary to open a support ticket to change production infrastructure like it is for Dedicated Gen 2.
- You can deploy your application in any supported cloud provider.
Although Dedicated Gen 3 adds plenty of features to your existing Grid applications, there are a few differences and limitations to be aware of when considering an upgrade.
The services documentation states that not every service or version available on the Grid is available on Dedicated Gen 3. The table below shows the currently available services and their versions for Dedicated Gen 3.
|MariaDB/MySQL||10.6 Galera, 10.5 Galera, 10.4 Galera, 10.3 Galera|
|MariaDB/MySQL||10.6, 10.5, 10.4, 10.3 (all using Galera, for replication)|
|PostgreSQL||14, 13, 12, 11, 10|
Because you get a redundant infrastructure, note that local mounts are local to each Virtual Machine. Since you can’t know which VM is going to handle a specific request, you also don’t have a guarantee regarding which local mount is going to be used. Whether you actually want to use a local mount or in fact need to set up a network storage mount depends on your specific use-case.
If you are interested in Platform.sh’s data cloning, environment control, and infrastructure-as-code philosophy across our supported runtimes and services, but you also need a large amount of resources and data isolation, contact us to start setting up a Dedicated Gen 3 project.
At this time, existing Grid projects can’t be migrated to Dedicated Gen 3, but they soon will be. Migrations will then require contacting our sales team, at which point your infrastructure is reviewed for compatibility and pricing. After that, your existing project settings are modified to set up a production environment using Dedicated Gen 3.
At the moment, Dedicated Gen 2 projects can’t be migrated to Dedicated Gen 3, but support for this type of migration will soon be available.