4221 improvements to dedicated docs

sites/platform/.yaml

@@ -562,6 +562,7 @@ nodejs:
       - '4.7'
       - '0.12'
     supported:
+      - '22'
       - '20'
       - '18'
       - '16'
@@ -963,6 +964,7 @@ solr:
       - '4.10'
       - '3.6'
     supported:
+      - '9.6'
       - '9.4'
       - '9.2'
       - '9.1'
@@ -979,6 +981,8 @@ solr:
       - '4.10'
   versions-dedicated-gen-3:
     supported:
+      - '9.6'
+      - '9.4'
       - '9.2'
       - '9.1'
       - '8.11'

sites/platform/src/administration/pricing/_index.md

@@ -115,7 +115,7 @@ don't hesitate to [contact support](https://console.platform.sh/-/users/~/ticket
 
 For more resources along with triple redundancy on every element of the stack, use a {{% names/dedicated-gen-3 %}} plan.
 
-Learn more about [{{% names/dedicated-gen-3 %}}](../../dedicated-gen-3/_index.md).
+Learn more about [{{% names/dedicated-gen-3 %}}](/dedicated-environments/dedicated-gen-3/_index.md).
 
 To discuss how {{% names/dedicated-gen-3 %}} could work for you, [contact Sales](https://platform.sh/contact/).
 

sites/platform/src/dedicated-environments/_index.md

@@ -0,0 +1,6 @@
+---
+title: "Dedicated environments"
+weight: -18
+# layout: single
+description: "Our Dedicated environments provide increased resources and high availability for organizations that require higher security, better compliance, robust storage and isolated hosting."
+---

sites/platform/src/dedicated-environments/backups-restores.md

@@ -0,0 +1,57 @@
+---
+title: "Dedicated backup and restores"
+weight: 1
+sidebarTitle: "Dedicated backups"
+layout: single
+description:  "Backups are retained for different periods depending on various factors and whether you’re using a Dedicated Gen 2 or Dedicated Gen 3 environment. These processes can be either manual or automated."
+---
+
+{{% description %}}
+
+
+## Dedicated Generation 2 Backups
+
+Platform.sh takes a byte-for-byte snapshot of Dedicated Gen 2 production environments every 6 hours. Backups are retained for different durations depending on when they were taken. 
+
+|When taken      |Retention            | 
+|----------------|---------------------|
+| Days 1–3       | Every backup        |  
+| Days 4–6       | One backup per day  |   
+| Weeks 2–6      | One backup per week |
+| Weeks 8–12     | One bi-weekly backup|   
+| Weeks 12–22    | One backup per month|  
+
+Backups are created using snapshots saved to encrypted elastic block storage (EBS) volumes. An EBS snapshot is immediate, but the time it takes to write to the storage service depends on the volume of changes.
+
+-   Recovery Point Objective (RPO) is 6 hours (maximum time to last backup).
+-   Recovery Time Objective (RTO) depends on the size of the storage. Large EBS volumes take more time to restore.
+
+These backups are only used in cases of catastrophic failure and can only be restored by Platform.sh. To request a restoration, open a [support ticket](/learn/overview/get-support.md).
+
+## Dedicated Generation 2 restoration
+
+The restoration process for Dedicated Generation 2 environments may take a few hours, depending on the infrastructure provider in use. In the ticket, specify if you want backups of files, MySQL, or both. Uploaded files are placed in an SSH-accessible directory on the Dedicated Gen 2 cluster. 
+
+MySQL is provided as a MySQL dump file on the server. You may restore these to your site at your leisure. You are also free to make your own backups using standard tools (mysqldump, rsync, etc.).
+
+{{< note title="Note" theme="info" >}}
+
+Platform.sh does not proactively overwrite your production site with a backup. You are responsible for determining a “safe” time to restore the backup, or for selectively restoring individual files if desired.
+
+{{< /note >}} 
+
+## Dedicated Generation 3 
+
+For Dedicated Generation 3 environments, [automated backups](environments/backup.md#use-automated-backups) are retained for a specific amount of time depending on their type and your [backup schedule](/environments/backup.md#backup-schedule). [Manual backups](/environments/backup.md#create-a-manual-backup) are retained until you delete them or replace them with another backup.
+
+|Type            |Basic                |Advanced         |Premium    |
+|----------------|---------------------|-----------------|-----------|
+| 6-hourly       | -                   | -               |1 day      |                
+| Daily          | 2 days              | 1 week          |1 month    |
+| Weekly         | -                   | 4 weeks         |-          |
+| Monthly        | -                   | 1 year          |1 year     | 
+
+
+## Dedication Generation 3 restores
+
+Dedicated Generation 3 environments allow for backups and restores the same way as Grid, so you can use them with the management console and the [Platform.sh CLI](/administration/cli/_index.md).

sites/platform/src/dedicated-gen-2/_index.md → sites/platform/src/dedicated-environments/dedicated-gen-2/_index.md

@@ -1,5 +1,5 @@
 ---
 title: "{{% names/dedicated-gen-2 %}}"
-weight: -18
+weight: -19
 description: "{{% names/dedicated-gen-2 %}} is a robust, redundant layer. This section contains all resources concerning the {{% names/dedicated-gen-2 %}} product."
 ---

sites/platform/src/dedicated-environments/dedicated-gen-2/development.md

@@ -0,0 +1,76 @@
+---
+title: "Dedicated Gen 2 Development"
+weight: 1
+sidebarTitle: "DG2 development"
+description: "Learn about the cluster infrastructure of Dedicated Generation 2, and discover key details about split architecture, deployment, storage limits and memory."
+
+---
+
+Learn about the [cluster infrastructure](#cluster-infrastructure) of Dedicated Generation 2, and discover key details about [split architecture](#split-architecture), [deployment](#deployment), [storage limits](#storage) and [memory](#memory).
+
+### Cluster infrastructure
+
+Dedicated Gen 2 and 3 clusters are launched into a Triple Redundant configuration consisting of 3 hosts. This is an N+1 configuration that’s sized to withstand the total loss of any one of the 3 members of the cluster without incurring any downtime. Every service is replicated across all three hosts in a failover configuration (as opposed to sharding), allowing a site to remain up even if one of the hosts is lost entirely.
+
+Each instance hosts the entire application stack, allowing this architecture superior fault tolerance to traditional N-Tier installations. Moreover, the Cores assigned to production are solely for production. 
+
+The build process for your application is identical for both the Grid Environment and the Dedicated Gen 2 cluster. However, because the hosts are provisioned by Platform.sh, not as a container, service configuration must be done by Platform.sh’s Customer Success team. The flexibility for DG2 and Grid can be made to be the same but only via opening a [support ticket](/learn/overview/get-support.md).
+
+For more information, learn about [default storage settings](/dedicated-gen-3/_index.md#storage) and how your app can [connect to services](/dedicated-gen-3/_index.md#available-services).
+
+### Split architecture
+
+Split architecture works under Dedicated Generation 2 and allows to give more resources globally to a project. Services (data services, caching service or search engines) are split from application runtimes. Services will be running on a cluster of core nodes, and the application will be running on a cluster of web nodes.
+
+This allows us to grant more room for the application or the services regarding resources. Both clusters can differ in size. Split-architecture clusters can horizontally scale the application by adding additional nodes. 
+
+![Split architecture](/images/dedicated/split-architecture.svg "0.50")
+
+### Deployment
+
+The production branch of your Git repository is designated for production and a staging branch is designated for staging. Any code merged to those branches automatically triggers a rebuild of the production or staging environment in the Dedicated Gen 2 cluster. 
+
+Any defined users or environment variables are also propagated to the Dedicated Gen 2 cluster.
+
+{{< note title="Note" theme="info" >}}
+
+There is no automatic cloning of data from the Dedicated Gen 2 cluster to the Development Environment the way there is between branches in the Development Environment. 
+
+{{< /note >}} 
+
+Production data may still be replicated to the Development Environment [manually](https://docs.platform.sh/administration/cli/reference.html#environmentsynchronize). Deployments of other branches don’t trigger rebuilds of the Dedicated Gen 2 cluster environments.
+
+#### Deployment process 
+
+When deploying to the Dedicated Gen 2 cluster the process is slightly different than when working with Platform.sh on the Grid.
+
+-   The new application image is built in the exact same fashion as for the Grid.
+-   Any active background tasks on the cluster, including cron tasks, are terminated.
+-   The cluster (production or staging) is closed, meaning it doesn’t accept new requests. Incoming requests receive an HTTP 500 error.
+-   The application image on all three servers is replaced with the new image.
+-   The deploy hook is run on one, and only one, of the three servers.
+-   The cluster is opened to allow new requests.
+
+The deploy usually takes approximately 30-90 seconds, although that is dependent on how your deploy hook has been configured.
+
+During the deploy process the cluster is unavailable. All Dedicated Gen 2 instances are fronted by the Fastly Content Delivery Network (CDN) unless you decide to bring your own CDN. You can also decide that you'd rather not use Fastly. Fastly can be configured to allow a “grace period”, meaning that requests to the origin that fail are served from the existing cache, even if that cache item is stale. We configure a default grace period that is longer than a typical deployment, and can extend that time upon request. That means anonymous users should see no interruption in service at all. Authenticated traffic that can’t be served by the CDN still sees a brief interruption.
+
+For more information about deployment, see the [overview of the build and deploy phases](/learn/overview/build-deploy.md).
+
+### Storage
+
+The Development Environment for a Dedicated Gen 2 project provides production and staging branches linked to the Dedicated Gen 2 cluster and 3 additional active environments for development. This number can be increased if needed for an [additional fee](https://platform.sh/pricing/). 
+
+The default storage for Dedicated Gen 2 contracts is 50GB per environment (production, staging, and each Development Environment). This comprises total storage for your project and is inclusive of any databases, uploaded files, writable application logging directories, search index cores, and so on. The storage amount for your Development Environment reflects the amount in your Enterprise contract and can be altered based on the terms you agree.
+
+A project may have up to six users associated with it at no additional charge. Additional users may be added for an additional fee. These users have access to both the Development Environment and the Dedicated Gen 2 cluster.
+
+{{< note title="Note" theme="info" >}}
+
+While your DG2 Production and Staging Environments are on dedicated virtual machines, your Development Environments run on the [Grid](/glossary.md#grid). This means that, by default, all containers in Development Environments are standard sized, as they have limited traffic needs. For more resource-intensive applications this size can be increased for an additional fee.
+
+{{< /note >}}
+
+### Memory
+
+Dedicated Generation 2 includes a single node dedicated staging with 2 CPUs. This runs the same software configuration as the production cluster but only on a single node. This is usually enough for functional testing before moving to production. You can choose to upgrade your staging to a more powerful machine or add more than one dedicated staging system. Those will still be a single machine.

sites/platform/src/dedicated-gen-2/overview/grid.md → sites/platform/src/dedicated-environments/dedicated-gen-2/environment-differences.md

@@ -1,29 +1,24 @@
 ---
-title: "Differences between Production and Development environments"
+title: "Environment differences"
 weight: 5
-sidebarTitle: "Differences in development"
-description: See the differences between your Production/Staging environments (which are {{% names/dedicated-gen-2 %}}) and your Development environments (which are Grid environments).
+sidebarTitle: "Environment differences"
+description: See the differences between your Production/Staging environments (which are Dedicated Gen 2) and your Development Environments (which are Grid environments).
 ---
 
-With {{% names/dedicated-gen-2 %}} plans, your Production and Staging environments are dedicated virtual machines,
-while your Development environments run on the Grid, meaning shared redundant infrastructure.
-This difference means a few configuration options and tools function differently in the different environments.
+With {{% names/dedicated-gen-2 %}} plans, your Production and Staging environments are on dedicated virtual machines, while your Development Environments run on the [Grid](/glossary.md#grid), meaning shared redundant infrastructure. This difference means a few configuration options and tools function differently in the different environments.
 
-These differences should be gone with [{{% names/dedicated-gen-3 %}}](../../dedicated-gen-3/_index.md).
+This is not the case with [{{% names/dedicated-gen-3 %}}](/dedicated-environments/dedicated-gen-3/_index.md) projects.
 
 ## Syncing data between environments
 
 Because of the differences between {{% names/dedicated-gen-2 %}} and Grid environments,
-basic [syncs](/glossary.md#sync) and [merges](/glossary.md#merge)
-aren't available between Development environments and Production/Staging environments.
-So you don't see working buttons with those options in the Console.
+basic [syncs](/glossary.md#sync) and [merges](/glossary.md#merge) aren't available between Development Environments and Production/Staging environments. So you don't see working buttons with those options in the Console.
 
-To transfer data between environments, backup your Production/Staging data and then synchronize Development data.
-See how to [back up and transfer data](../../development/transfer-dedicated.md#synchronize-files-from-development-to-stagingproduction).
+To transfer data between environments, backup your Production/Staging data and then synchronize Development data. See how to [back up and transfer data](../../development/transfer-dedicated.md#synchronize-files-from-development-to-stagingproduction).
 
 ## Backups
 
-Production environments are [backed up automatically](./backups.md).
+Production environments are [backed up automatically](/environments/backup.md#backup-schedule).
 For other environments, trigger a [manual backup](../../environments/backup.md).
 
 ## PHP
@@ -34,7 +29,7 @@ The following table shows all of the extensions that are enabled by default in e
 To add any other extension with a pre-existing package in the Debian Apt repository,
 open a [support ticket](/learn/overview/get-support).
 
-{{< php-extensions/dedicated >}}
+{{< php-extensions/dedicated>}}
 
 ### Configuration options
 
@@ -72,9 +67,7 @@ Then whenever you have Xdebug enabled, the request uses the alternate developmen
 ## Solr
 
 On Grid environments, [Solr](../../add-services/solr.md) runs as a standalone instance.
-On {{% names/dedicated-gen-2 %}} environments, it runs as [SolrCloud](https://solr.apache.org/guide/6_6/solrcloud.html):
-a cluster of Solr servers to ensure high availability.
-This shouldn't affect you most of the time, but may influence certain advanced use cases.
+On {{% names/dedicated-gen-2 %}} environments, it runs as [SolrCloud](https://solr.apache.org/guide/6_6/solrcloud.html): a cluster of Solr servers to ensure high availability. This shouldn't affect you most of the time, but may influence certain advanced use cases.
 
 ## Cron tasks interrupted by deploys
 
@@ -109,5 +102,4 @@ The following settings require a [support ticket](/learn/overview/get-support):
 
 ## Logs
 
-{{% names/dedicated-gen-2 %}} environments have a slightly different location for [container logs](../../increase-observability/logs/access-logs.md).
-The difference shouldn't be noticeable if you use the CLI.
+{{% names/dedicated-gen-2 %}} environments have a slightly different location for [container logs](../../increase-observability/logs/access-logs.md). The difference shouldn't be noticeable if you use the CLI.