4221 improvements to dedicated docs #4249
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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." | ||
| --- |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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’re 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. | ||
|
There was a problem hiding this comment. strangely, there's a There was a problem hiding this comment.
I'm going to assume what we're referring to here is the chosen provider for the region the customer selected? In the Dedicated Gen 2 Overview page we don't reference "infrastructure provider" anywhere, only that they can choose any region. For "infrastructure" we state "Dedicated 3 node cluster". We should clarify what we mean here and/or connect it back to other docs that clarify our meaning. |
||
|
|
||
| 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). | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,5 +1,5 @@ | ||
| --- | ||
| title: "{{% names/dedicated-gen-2 %}}" | ||
| weight: -19 | ||
| description: "{{% names/dedicated-gen-2 %}} is a robust, redundant layer. This section contains all resources concerning the {{% names/dedicated-gen-2 %}} product." | ||
| --- |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,79 @@ | ||
| --- | ||
| 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 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 Development 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. By and large the same flexibility is available 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, 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. | ||
|
|
||
|  | ||
|
|
||
| ### 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**: 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. | ||
|
There was a problem hiding this comment. we usually break out "Notes" into a separate with the note shortcode. Is there a specific reason we don't do that here? There was a problem hiding this comment. Agreed - @Kemi-Elizabeth it would be better to put in this format. |
||
|
|
||
| Production data may still be replicated to the Development Environment manually. Deployments of other branches don’t trigger rebuilds of the Dedicated Gen 2 cluster environments. | ||
|
There was a problem hiding this comment. can we link to the docs on how to do this manually? There was a problem hiding this comment. |
||
|
|
||
| #### Deployment process | ||
|
|
||
| When deploying to the Dedicated Gen 2 cluster the process is slightly different than when working with Platform.sh on the Grid. | ||
|
There was a problem hiding this comment. here we refer to it as "Grid" but then the next line we refer to to it as "Platform.sh Professional". There was a problem hiding this comment. We should refrain from using the term Grid. |
||
|
|
||
| - The new application image is built in the exact same fashion as for Platform.sh Professional. | ||
| - 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. Nearly all Dedicated Gen 2 instances are fronted by the Fastly Content Delivery Network (CDN). 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. | ||
|
There was a problem hiding this comment. we say "nearly all Dedicated Gen 2 instances" have fastly here but in the overview comparing Gen 2 to we state that all Gen 2 come with fastly. Is there a reason we state "nearly" in this section? There was a problem hiding this comment. @Kemi-Elizabeth this is a good question to follow-up on and maybe place a note to define nearly, as I don't know the answer here either. |
||
|
|
||
| For more information about deployment, see the [overview of the build and deploy phases](/learn/overview/build-deploy.md). | ||
|
|
||
| ### Storage | ||
|
There was a problem hiding this comment. if we're reading the docs in order, we haven't read the Environment Differences section to know that development environments are on the grid, which makes this section on storage particularly confusing. |
||
|
|
||
| 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. | ||
|
There was a problem hiding this comment. do we have a link to the fee structure for storage we can add here? There was a problem hiding this comment. here we have the "e" in environment capitalized but later we do not (only the "d" is capitalized). Is there a reason for the difference? There was a problem hiding this comment.
We can link to pricing, or otherwise suggest users reach out to their rep.
I think we should make a choice here, since there does appear to be a jumble of terms. AFAI understand we've used "The Development Environment" to refer to the collection of "Grid" development environments child to the Dedicated environment(s) of a Dedicated project... |
||
|
|
||
| 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. | ||
|
There was a problem hiding this comment. We say the default is 50GB, but then the last sentence states:
I'm confused by what information we're trying to convey here. There was a problem hiding this comment. That this is the default but can be increased contractually? |
||
|
|
||
| A project may have up to six (6) 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. | ||
|
There was a problem hiding this comment. earlier we had the "e" in Development environment capitalized, but here we do not. There was a problem hiding this comment. This should be capitalized based on my note above, I think. |
||
|
|
||
| {{< note title="Note" theme="info" >}} | ||
|
|
||
| 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. | ||
|
There was a problem hiding this comment. if we're reading the docs in order, we haven't read the Environment Differences section to know that development environments are on the grid, which means "standard sized" doesn't make sense in the context to the rest of the page. |
||
|
|
||
| {{< /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. Customers can upgrade their staging to a more powerful machine or add more than one dedicated staging system. Those will still be a single machine. | ||
|
There was a problem hiding this comment. This reads like it was possibly copied from internal documentation? Else where in this page we use "you" and "your" and here have switch to "their" and referring to them in the 3rd person. same in the next paragraph. |
||
|
|
||
| The memory ratio will follow their production system: | ||
|
There was a problem hiding this comment. do the SKU's need to be published? What do the headings "Memory D-" and "Memory M-" refer to? There was a problem hiding this comment. Yeah this is an odd one to make public. What does a user actually see/know about this instead of internal/billing manager? |
||
|
|
||
| | SKU | CPU | Memory D-*| Memory M-* | | ||
| | ------| ----| ----------| -----------| | ||
| | STG-2 | 2 | 4 | 8 | | ||
| | STG-4 | 4 | 8 | 16 | | ||
| | STG-8 | 8 | 16 | 32 | | ||
|
There was a problem hiding this comment. similar: since we've moved this doc location, should we add a redirect for it in routes.yaml? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this really "when taken" or how old the backup is?
ie if the back up is between 1-3 days old they are retained. If the back up is between 4-6 days old, then only 1 backup in a 24 hour time group is retained. etc