diff --git a/sites/platform/.yaml b/sites/platform/.yaml index 1ffefcac53..f9cb4d7357 100644 --- a/sites/platform/.yaml +++ b/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' diff --git a/sites/platform/src/administration/pricing/_index.md b/sites/platform/src/administration/pricing/_index.md index e3ba8858ab..7228e1dcae 100644 --- a/sites/platform/src/administration/pricing/_index.md +++ b/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/). diff --git a/sites/platform/src/dedicated-environments/_index.md b/sites/platform/src/dedicated-environments/_index.md new file mode 100644 index 0000000000..5710b4d516 --- /dev/null +++ b/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." +--- diff --git a/sites/platform/src/dedicated-environments/backups-restores.md b/sites/platform/src/dedicated-environments/backups-restores.md new file mode 100644 index 0000000000..ceaaa50b68 --- /dev/null +++ b/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). \ No newline at end of file diff --git a/sites/platform/src/dedicated-gen-2/_index.md b/sites/platform/src/dedicated-environments/dedicated-gen-2/_index.md similarity index 94% rename from sites/platform/src/dedicated-gen-2/_index.md rename to sites/platform/src/dedicated-environments/dedicated-gen-2/_index.md index 8b4de50a4a..5350841bb6 100644 --- a/sites/platform/src/dedicated-gen-2/_index.md +++ b/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." --- diff --git a/sites/platform/src/dedicated-environments/dedicated-gen-2/development.md b/sites/platform/src/dedicated-environments/dedicated-gen-2/development.md new file mode 100644 index 0000000000..c028e6d12a --- /dev/null +++ b/sites/platform/src/dedicated-environments/dedicated-gen-2/development.md @@ -0,0 +1,78 @@ +--- +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.  + +##### Build process + +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](#storage) and how your app can [connect to services](dedicated-environments/dedicated-gen-3/overview.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. \ No newline at end of file diff --git a/sites/platform/src/dedicated-gen-2/overview/grid.md b/sites/platform/src/dedicated-environments/dedicated-gen-2/environment-differences.md similarity index 62% rename from sites/platform/src/dedicated-gen-2/overview/grid.md rename to sites/platform/src/dedicated-environments/dedicated-gen-2/environment-differences.md index 26d952fa4d..d08ad66bd3 100644 --- a/sites/platform/src/dedicated-gen-2/overview/grid.md +++ b/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. +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 or 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,13 +29,14 @@ 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 {{< note >}} -Most {{% names/dedicated-gen-2 %}} projects allow you to use custom `php.ini` files on your Production/Staging environments.
-However, **for a small set of projects**, this isn't supported yet. + +Most {{% names/dedicated-gen-2 %}} projects allow you to use custom `php.ini` files on your production or staging environments. However, **for a small set of projects**, this isn't supported yet. + {{< /note >}} @@ -60,21 +56,26 @@ For other PHP options, such as the following, [open a support ticket](/learn/ove ### Xdebug -All {{% names/dedicated-gen-2 %}} clusters that have [Xdebug](../../languages/php/xdebug.md) enabled have a second PHP-FPM process. -This second process is used only when requests include the correct Xdebug key in a header. +All {{% names/dedicated-gen-2 %}} clusters that have [Xdebug](../../languages/php/xdebug.md) enabled have a second PHP-FPM process. This second process is used only when requests include the correct Xdebug key in a header. + So you can keep Xdebug always on and not worry about performance issues as it's ignored on most requests. -To obtain the key, open a [support ticket](/learn/overview/get-support). +**To obtain the Xdebug key:** + +1. Open a [support ticket](/learn/overview/get-support). + +{{< note >}} + Staging and Production environments have separate keys. -Set that key in the Xdebug helper for your browser. -Then whenever you have Xdebug enabled, the request uses the alternate development PHP-FPM process with Xdebug. + +{{< /note >}} + +2. Set that key in the Xdebug helper for your browser. Whenever you have Xdebug enabled, the request uses the alternate development PHP-FPM process with Xdebug. ## 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 @@ -91,9 +92,9 @@ So it's best to ensure your cron tasks can receive a `SIGTERM` message and termi ## Configuration & change management -You can't manage some configuration settings via YAML configuration files on {{% names/dedicated-gen-2 %}} environments. +You can't manage some configuration settings via YAML configuration files on {{% names/dedicated-gen-2 %}} Environments. In these cases, you need to open a [support ticket](/learn/overview/get-support). -You can have some settings different between Staging and Production environments. +You can have some settings different between staging and production environments. It's assumed you want the settings the same, unless you state otherwise in the ticket. The following settings require a [support ticket](/learn/overview/get-support): @@ -109,5 +110,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. diff --git a/sites/platform/src/dedicated-environments/dedicated-gen-2/overview.md b/sites/platform/src/dedicated-environments/dedicated-gen-2/overview.md new file mode 100644 index 0000000000..e987047fe9 --- /dev/null +++ b/sites/platform/src/dedicated-environments/dedicated-gen-2/overview.md @@ -0,0 +1,136 @@ +--- +title: Dedicated Gen 2 Overview +weight: -10 +sidebarTitle: "DG2 overview" +description: "Dedicated Generation 2 is a robust, redundant layer. It’s well-suited for those who like the Platform.sh development experience but need more resources and redundancy for their production environment." + +--- + +{{% description %}} + +Dedicated Generation 2 consists of two parts: a development environment and a Dedicated Gen 2 cluster. + +### Key features + +- **High Availability:** 99.99% SLA (service-level agreement) with [Enterprise or Elite](https://platform.sh/pricing/) +- **Dedicated hosts:** Each DG2 cluster is provisioned with 3 dedicated hosts as the typical configuration +- **Headless architecture:** Seamless headless architecture with multi-app support +- **Isolation:** On DG2, services run as processes on the base operating system (OS) +- **Storage:** Storage allocation between mounts, DB and services is done through Platform.sh once a ticket is raised. Storage management is not self-service + +## Dedicated Generation 2 vs Grid + +Much of the tooling used on Grid is used for DG2, but there are still some differences. Please find a list of the similarities and differences between these two environments below:  + +| Feature | Dedicated Generation 2 | Grid | +| --- | --- | --- | +| **Source Operations** | Yes | Yes | +| **PHP version upgrade** | Self-service via yaml config files | Self-service via yaml config files | +| **Node.js version upgrade** | Self-service via yaml config files | Self-service via yaml config files | +| **Cron management** | Self-service via yaml config files | Self-service via yaml config files | +|**Web server internal config : locations** | Self-service via yaml config files | Self-service via yaml config files | +| **CDN** | Fastly | A managed Fastly CDN service can be purchased through Platform.sh | +| **Dedicated IP** | Yes | No | +| **Configuration management** | Split responsibility between Platform.sh and customer | only yaml files | +| **Usable regions** | Any region needed | Only the publicly available | +| **Autonomous upsize** | Managed through Platform.sh| Yes | +| **Autoscaling** | Yes | No | +| **Upsize or Downsize methods** | No downtime - each instance is altered in a rolling fashion | Redeploy - possible downtime depending on the hooks | +| **Production branch** | Managed by Platform.sh | Self-service | +| **Multi availability zones ** | Yes | No | +| **New Relic** | APM + New Relic infrastructure | APM Supported only | +| **Multi-app support** | Supported through docroots | Supported natively. | +| **Routes management** | Managed by Platform.sh | Self-service | +| **Environment clone** | Only on development environments | Yes on all branches | +| **Services : Add, remove, upgrade** | Managed by Platform.sh | Self-service | +| **Relationships : Add, remove, update** | Managed by Platform.sh | Self-service | +| **Workers management** | Managed by Platform.sh | Self-service | +| **Web server internal config : domains** | Managed by Platform.sh | Self-service | +| **Storage allocation between mounts, DB and services** | Managed by Platform.sh | Self-service | +| **Cron tasks interrupted by deploys** | Yes: a deploy will terminate a running Cron task | No: a running Cron task will block a deployment until it is complete | +| **Log exports** | Managed by Platform.sh with Rsyslog exports and Fastly log exports | Log forwarding feature and Fastly log export also available| +| **Sync and merge functionalities** | Only on development environments | Yes on all branches | +| **SLA** | 99.99% with [Enterprise or Elite](https://platform.sh/pricing/)| 99.9% with [Enterprise or Elite](https://platform.sh/pricing/)| +| **Infrastructure** | Dedicated 3 node cluster | Containers with dedicated resources on top of a shared redundant infrastructure | +| **Functioning** | 3 nodes are running all applications and services and are replicated | A single container is deployed per runtimes and per services | +| **Resources allocation** | Resources deployed on 3 nodes | Resources are spread through the container with fixed sizes after deployment | +| **MySQL Replication** | Yes: 3 services nodes cluster | None: standalone service container | +| **Redis Replication** | Yes: 3 services nodes cluster | None: standalone service container | +| **High Availabilty (HA)** | Yes | No | +| **Split Architecture** | Yes | No | +| **Storage** | Local disks are accessed either locally or via glusterfs | 100 GB self service max (can be extended upon request) | +| **Automated backup** | Yes | Yes | +| **Custom domains name** | On all branches for [Enterprise or Elite](https://platform.sh/pricing/) customers | On all branches for [Enterprise or Elite](https://platform.sh/pricing/) customers | +| **MongoDB** | Not supported | Standalone service container | + +### Dedicated Gen 2 vs Dedicated Gen 3 + +Just like Dedicated Gen 3, [Dedicated Gen 2](/dedicated-environments/dedicated-gen-2/overview.html) ensures increased uptime and availability for your apps and services. But as a Dedicated Gen 2 user, you have to go through the Platform.sh Customer Success team to make configuration or application topology changes. + +To understand the differences and similarities between Dedicated Generation 2 and Dedicated Generation 3, please head to [Dedicated Gen 3 vs Dedicated Gen 2](/dedicated-environments/dedicated-gen-3/overview.md#dedicated-gen-3-vs-dedicated-gen-2). + +### Optional features + +You can enable the following features on your Dedicated Gen 2 projects, as well as [multiple availability zones](/dedicated-environments/dedicated-gen-3/overview.md#multiple-availability-zones). To enable an optional feature or get more information on potential fees, [contact Sales](https://platform.sh/contact/). + +#### Multiple applications + +You can create multiple apps within a single project so they can share data. This can be useful if you have several apps that are closely related, such as a backend-only CMS and a frontend system for content delivery and display. + +For more information, see how to [configure multiple apps in a single project](/create-apps/multi-app/_index.md). + +#### Staging environments  + +A dedicated single-node staging machine is provisioned for your application with an identical software configuration to your production hardware, but reduced hardware specs. This gives the advantages of isolating the staging load from the production hardware as well as having an identical software configuration to perform UAT, but this option doesn’t provide a bed for performance testing as the physical hardware configuration isn’t the same as production. + +#### Additional application servers  + +For especially high-traffic sites we can also add additional application-only servers. These servers contain just the application code; data storage services (such as SQL, Solr, Redis) are limited to the standard three. The cluster begins to look more like a standard N-Tier architecture at this point, with a horizontal line of web application servers in front of a 3 node (N+1) cluster of Galera database servers. + +Speak to your sales representative about the costs associated with adding additional application servers. This configuration requires a separate setup from the default so advanced planning is required. + +#### SFTP  + +In addition to SSH accounts, you can create sftp accounts with a custom user/password that are restricted to certain directories. These directories must be one of the writeable mounts. + +There is no cost for this configuration, and you can request it at any time via a [support ticket](/learn/overview/get-support.md). SSH public key based authentication is also supported on the sftp account. + +See how to [transfer files through sftp](/development/file-transfer.md). + +#### Error handling  + +On Grid projects, incoming requests are held at the edge router temporarily during a deploy. That allows a site to “respond slowly” rather than be offline during a deploy, provided the deploy time is short (a few seconds). + +On Dedicated Gen 2 projects, incoming requests aren’t held during deploy and receive a 503 error. As the Dedicated Gen 2 cluster is almost always fronted by a CDN, the CDN continues to serve cached pages during the few seconds of deploy, so for the vast majority of users there is no downtime or even slow down. If a request does pass the CDN during a deploy, it isn’t counted as downtime covered by our Service Level Agreement. + +By default, Platform.sh serves generic Platform.sh-branded error pages for errors generated before a request reaches the application. (500 errors, some 400 errors, etc.) Alternatively you may provide a static error page for each desired error code via a ticket for us to configure with the CDN. This file may be any static HTML file but is limited to 64 KB in size. + +#### Remote logging  + +Dedicated Gen 2 supports sending logs to a remote logging service such as Loggly, Papertrail, or Logz.io using the rsyslog service. This is an optional feature and you can request that it be enabled via a [support ticket](/learn/overview/get-support.md). Once enabled and configured your application can direct log output to the system syslog facility and is replicated to the remote service you have configured. + +When contacting support to enable rsyslog, you need: + +- The name of the remote logging service to use. +- The message template format used by your logging service. +- The specific log files you want forwarded to your logging service. + +There is no cost for this functionality. + +#### IP restrictions  + +Platform.sh supports [project-level IP restrictions (allow/deny) and HTTP Basic authentication](/environments/http-access-control.md). These may be configured through the development environment and are automatically replicated from the production and staging branches to the production and staging environments, respectively. + +Changing access control triggers a new deployment of the current environment. However, the changes aren’t propagated to child environments until they’re manually redeployed. + +### Updates + +Platform.sh updates the core software of the Dedicated Gen 2 cluster (operating system, web server, PHP, MySQL, etc.) periodically, and after any significant security vulnerability is disclosed. + +These updates are deployed automatically with no additional work required by you. We attempt to maintain parity with your development environment, but we don’t guarantee absolute parity of point versions of your Dedicated Gen 2 Environments with their corresponding development environments. For example, your development environment may have a PHP container running 8.1.30, but your production environment may lag behind at 8.1.26. + +We can upgrade point releases on request and always upgrade the underlying software in the event of security release. + +Updates to application software (PHP code, JavaScript, etc.) are the responsibility of the customer. + + diff --git a/sites/platform/src/dedicated-environments/dedicated-gen-3/_index.md b/sites/platform/src/dedicated-environments/dedicated-gen-3/_index.md new file mode 100644 index 0000000000..abcdb5a66a --- /dev/null +++ b/sites/platform/src/dedicated-environments/dedicated-gen-3/_index.md @@ -0,0 +1,5 @@ +--- +title: "{{% names/dedicated-gen-3 %}}" +weight: -19 +description: Learn more about the Dedicated Gen 3 offering, which provides a redundant configuration with at least 3 virtual machine instances for your production environment. +--- diff --git a/sites/platform/src/dedicated-environments/dedicated-gen-3/development.md b/sites/platform/src/dedicated-environments/dedicated-gen-3/development.md new file mode 100644 index 0000000000..03e96bb4b4 --- /dev/null +++ b/sites/platform/src/dedicated-environments/dedicated-gen-3/development.md @@ -0,0 +1,58 @@ +--- +title: "Dedicated Gen 3 Development" +weight: 1 +sidebarTitle: "DG3 development" +layout: single +description: "Learn about the cluster infrastructure of Dedicated Generation 3, and discover key details about deployment, which regions are supported and storage limits." +--- + +Learn about the [cluster infrastructure](#cluster-infrastructure) of Dedicated Generation 3, and discover key details about [deployment](#deployment), which [regions](#regions) are supported and [storage limits](#storage). + +## Cluster infrastructure  + +Clusters in a DG3 environment can be imagined as a mini-Grid region that has no [Ceph](/glossary.md#ceph) dependency, so it can run anywhere. The cluster nodes function as entrypoint, coordinator, storage and host all in one. These clusters usually only contain a single branch while the remainder of the project remains on a Grid host.  + +For more information about the Dedicated clusters, visit [Dedicated Gen 2 Development](/dedicated-environments/dedicated-gen-2/development.md#cluster-infrastructure). + +![Dedicated cluster architecture](/images/dedicated/cluster-infrastructure.svg "0.50") + +On a DG3 cluster, the services (mariadb, php, redis) run in Highly Available (HA) mode instead of as single, isolated applications. These clusters can be in either of your production or staging environments. + +### HTTP clusters + +With a HTTP connection, a cloud load balancer sits in front of the hosts and, if Fastly is enabled, Fastly sits in front of the cloud load balancer. Therefore, the web request flow looks like this: + +![HTTP cluster architecture](/images/dedicated/http-cluster.svg "0.50") + +### SSH clusters + +On DG3, customers have direct access to the application containers. This connection is proxied through the Grid region and then to the DG3 cluster like in the diagram below: + +![SSH cluster architecture](/images/dedicated/ssh-cluster.svg "0.50") + +In the diagram, there are only 3 hosts. Host 1 has both the entry point and app container, and the same goes for hosts 2 and 3. Each service is run on 3 High availability containers spread across each of the 3 dedicated hosts. + +## Deployment + +On Grid, all project branches are deployed into that same Grid region. On DG3, this behaves the same but the projects deployed are Highly Available (HA), and branches set as default and (optionally) labelled staging are deployed into their own dedicated clusters instead. + +{{< note title="Note" theme="info" >}} + +Existing non-HA projects cannot be converted to HA projects and vice-versa. HA projects must be created as HA. + +{{< /note >}} + +## Providers and regions + +Unlike Grid, you can deploy into [any region](https://docs.platform.sh/development/regions.html#regions) of supported IaaS providers with a Dedicated Generation 3 environment. Currently, these providers are listed below: + +- Amazon Web Services (AWS) +- Microsoft Azure (Azure) +- Google Cloud Platform (GCP) +- OVHcloud (OVH)  + +For more details on specific regions, consult the region [documentation](/development/regions.md#regions). + +## Storage + +Each Dedicated Gen 3 cluster comes with 50GB of storage per environment by default. This storage is intended for your data (databases, search indexes, user uploaded files, etc.) and you can subdivide it as you want. You can request more storage at any time. \ No newline at end of file diff --git a/sites/platform/src/dedicated-environments/dedicated-gen-3/overview.md b/sites/platform/src/dedicated-environments/dedicated-gen-3/overview.md new file mode 100644 index 0000000000..f387550609 --- /dev/null +++ b/sites/platform/src/dedicated-environments/dedicated-gen-3/overview.md @@ -0,0 +1,165 @@ +--- +title: "Dedicated Gen 3 Overview" +weight: -10 +sidebarTitle: "DG3 overview" +description: "Designed to cater to the needs of organizations that build demanding apps, Dedicated Generation 3 (DG3) offers increased resources and High Availability (HA) for all your services, along with stricter isolation requirements and additional compliance frameworks." +--- + +{{% description %}} + +### Key features + +- **High Availability:** 99.99% SLA (service-level agreement) with [Enterprise or Elite](https://platform.sh/pricing/) +- **Dedicated hosts:** Each DG3 cluster is provisioned with 3 dedicated hosts as the typical configuration +- **Headless architecture:** Seamless headless architecture with multi-app support +- **Self-service:** Customers may edit their application and service YAML files and push changes Customers can also take advantage of MariaDB Galera multi-leader, disk resizing and adding, upgrading or removing services on their own +- **Data sync from Dedicated to Grid:** Customers can initiate data syncs themselves via Console (restore a Grid HA backup on DG3 and restore a DG3 backup on a Grid HA environment) +- **Better containerization:** DG3 is containerized and decouples the base operating system (OS) version and [control plane](/glossary.md#control-plane) from the service versions, so the OS and services can be upgraded independently +- **Better staging:** Dedicated Gen 3 comes with HA staging as default. This allows the data sync between Dedicated and Grid to be simpler, consistent and seamless + +{{< note title="Note" theme="info" >}} + +Existing Grid and Dedicated Gen 2 projects cannot be migrated to Dedicated Gen 3. + +{{< /note >}}  + +### Dedicated Gen 3 vs Grid + +Much of the tooling used on Grid is used for DG3, but there are still some differences. Please find a list of the similarities and differences below:  + +| Feature | DG3 | Grid | +| --- | --- | --- | +| **Source Operations** | Yes | Yes | +| **PHP version upgrade** | Self-service via yaml config files | Self-service via yaml config files | +| **NodeJS version upgrade** | Self-service via yaml config files | Self-service via yaml config files | +| **Cron management** | Self-service via yaml config files | Self-service via yaml config files | +| **Web server internal config : locations** | Self-service via yaml config files | Self-service via yaml config files | +| **CDN** | Fastly | A managed Fastly CDN service can be purchased through Platform.sh | +| **Dedicated IP** | Yes | No | +| **Configuration management** | Split responsibility between Platform.sh and customer | only through yaml files | +| **Usable regions** | Any region needed | Only the publicly available | +| **Autonomous upsize** | Managed through Platform.sh | Yes | +| **Upsize or downsize methods** | No downtime - each instance is upsize in a rolling fashion | Redeploy - possible downtime depending on the hooks | +| **Production branch** | Managed by Platform.sh| Self-service | +| **Autoscaling** | Yes | No | +| **Multi availability zones** | Yes | No | +| **New Relic** | Not supported | APM Supported only | +| **Multi-app support** | Supported natively | Supported natively | +| **Routes management** | Self-service via yaml config files | Self-service via yaml config files | +| **Environment clone** | Yes on all branches | Yes on all branches | +| **Services : Add, remove, upgrade** | Self-service via yaml config files | Self-service via yaml config files | +| **Relationships : Add, remove, update** | Self-service via yaml config files | Self-service via yaml config files | +| **Mounts management** | Self-service via yaml config files | Self-service via yaml config files | +| **Workers management**| Self-service via yaml config files | Self-service via yaml config files | +| **Web server internal config : domains** | Self-service via yaml config files | Self-service via yaml config files | +| **Storage allocation between mounts, DB and services** | Self-service via yaml config files | Self-service via yaml config files | +| **Storage increase responsibility** | Shared responsibility with Platform.sh | Self-service | +| **Cron tasks interrupted by deploys** | No: a running Cron task will block a deployment until it is complete | No: a running Cron task will block a deployment until it is complete | +| **Sync and merge functionalities** | Yes on all branches | Yes on all branches | +| **SLA** | 99.99% with [Enterprise or Elite](https://platform.sh/pricing/) | 99.9% with [Enterprise or Elite](https://platform.sh/pricing/)| +| **Infrastructure** | Dedicated 3 node cluster | Containers with dedicated resources on top of a shared redundant infrastructure | +| **Functioning** | 3 nodes are running all applications and services are replicated across all 3| A single container is deployed per runtimes and per services | +| **Resources allocation** | Resources are deployed on all 3 nodes | Resources are spread through one container with fixed sizes after deployment | +| **MySQL Replication** | Yes: 3 services nodes cluster | None: standalone service container | +| **Redis Replication** | Yes: 3 services nodes cluster | None: standalone service container | +| **High availability (HA)** | Yes | No | +| **Split Architecture** | No | No | +| **Automated backup** | Yes | Yes | +| **Elasticsearch premium** | Yes | Yes | +| **SFTP password access** | Yes | No | +| **Custom domains name** | On all branches for [Enterprise or Elite](https://platform.sh/pricing/) customers | On all branches for [Enterprise or Elite](https://platform.sh/pricing/) customers | + +#### Available services + +Your app can connect to each service by referencing the exact same [environment variables](/development/variables.md) as for Grid environments.  + +| Service | Supported versions | +| --- | --- | +| **Headless Chrome** | 95 | +| **MariaDB/MySQL** | 10.11 Galera, 10.6 Galera, 10.5 Galera, 10.4 Galera, 10.3 Galera | +| **Network Storage** | 2 | +| **OpenSearch** | 2 | +| **PostgreSQL** | 16, 15, 14, 13, 12 | +| **RabbitMQ** | 3.13, 3.12 | +| **Redis** | 7.2, 7.0, 6.2 | +| **Ruby** | 3.3, 3.2, 3.1, 3.0 | +| **Solr** | 9.6, 9.4, 9.2, 9.1, 8.11 | +| **Vault KMS** | 1.12 | + +See the [services documentation](/add-services/_index.md) for service-specific details. + +#### Local mounts  + +Dedicated Gen 3 provides a redundant infrastructure and local mounts aren’t shared between the three hosts. If you need a folder to be shared between your hosts, set up a [network storage mount](/add-services/network-storage.md). + +### Dedicated Gen 3 vs Dedicated Gen 2 + +Just like Dedicated Gen 3, [Dedicated Gen 2](/dedicated-environments/dedicated-gen-2/_index.md) ensures increased uptime and availability for your apps and services. But as a Dedicated Gen 2 user, you have to go through the Platform.sh Customer Success team to make configuration or application topology changes. + +Dedicated Gen 3 gives you both the high availability of Dedicated Gen 2 and the self-service flexibility and features of Grid projects. As a Dedicated Gen 3 user, you can edit your configuration yourself and see those changes reflected in your environments on every push without opening a ticket. See the table below for more differences and similarities between Dedicated Den 3 and Dedicated Gen 2: + +| Feature | Dedicated Gen 2 | Dedicated Gen 3 | +| --- | --- | --- | +| **Source Operations** | Yes | Yes | +| **PHP version upgrade** | Self-service via yaml config files | Self-service via yaml config files | +| **NodeJS version upgrade** | Self-service via yaml config files | Self-service via yaml config files | +| **Cron management** | Self-service via yaml config files | Self-service via yaml config files | +| **Web server internal config : locations** | Self-service via yaml config files | Self-service via yaml config files | +| **CDN** | Fastly | Fastly | +| **Dedicated IP** | Yes | Yes | +| **Usable regions** | Any region needed | Any region needed | +| **Autonomous upsize** | Managed through Platform.sh | Managed through Platform.sh| +| **Multiple availability zones** | Yes | Yes | +| **New Relic** | APM + New Relic infrastructure | APM + New Relic infrastructure | +| **Multi-app support (PWA)** | Supported through docroots | Supported natively | +| **Routes management** | Managed by Platform.sh | Self-service via yaml config files | +| **Environment clone** | Only on development environments | Yes on all branches | +| **Services : Add, remove, upgrade** | Managed by Platform.sh | Self-service via yaml config files | +| **Relationships : Add, remove, update** | Managed by Platform.sh| Self-service via yaml config files | +| **Mounts management** | Self-service or managed by Platform.sh | Self-service via yaml config files | +| **Workers management** | Managed by Platform.sh | Self-service via yaml config files | +| **Web server internal config: domains** | Managed by Platform.sh | Self-service via yaml config files | +| **Storage allocation between mounts, DB and services** | Managed by Platform.sh | Self-service via yaml config files | +| **Storage increase responsibility** | Managed by Platform.sh | Self-service | +| **Cron tasks interrupted by deploys** | Yes: a deploy will terminate a running Cron task | No: a running Cron task will block a deployment until it is complete | +| **Sync and Merge functionalities** | Only on development environments | Yes on all branches | +| **Functioning** | 3 nodes are running all applications and services are replicated | 3 nodes are running all applications and service are replicated | +| **Resources allocation** | Resources deployed on the 3 nodes | Resources deployed on the 3 nodes | +| **MySQL Replication** | Yes: 3 services nodes cluster | Yes: 3 services nodes cluster | +| **Redis Replication** | Yes: 3 services nodes cluster | Yes: 3 services nodes cluster | +| **Split Architecture** | Yes | No | +| **VPN** | AWS PrivateLink | AWS PrivateLink | +| **Automated backup** | Yes | Yes | +| **Elasticsearch premium** | Yes | Yes | +| **SFTP password access** | Yes | Yes | +| **Custom domains name** | On all branches for [Enterprise or Elite](https://platform.sh/pricing/) customers | On all branches for [Enterprise or Elite](https://platform.sh/pricing/) customers | +| **On-demand backup** | Not supported | Same as grid | + +#### Optional features + +You can enable the following features on your Dedicated Gen 3 projects. To enable an optional feature or get more information on potential fees, [contact Sales](https://platform.sh/contact/). + +##### Multiple availability zones  + +The default configuration for Dedicated clusters is to launch them into a single availability zone (AZ) for the following reasons: + +- The members of your cluster communicate with each other via TCP to perform DB replication, cache lookup, and other associated tasks. Therefore, the latency between data centers or AZs can become a significant performance liability. When your entire cluster is deployed within a single AZ, the latency between cluster members is minimal. This has a direct effect on perceived end-user performance. +- Network traffic between AZs is billed, whereas intra-AZ traffic isn’t. Launching Dedicated clusters across multiple AZs leads to higher costs and decreased performance. +If you prefer the peace of mind of hosting across multiple AZs, you can request a different configuration. + +{{< note title="Note" theme="info" >}} + +Platform.sh is responsible for meeting the 99.99% uptime SLA, so multiple-AZ deployments should only be considered in cases where they’re truly appropriate. Multi-AZ deployments are available only on select AWS regions. + +{{< /note >}}  + +##### SFTP  + +In addition to SSH accounts, you can create SFTP accounts with a custom user/password to [transfer files](/development/file-transfer.md).  + +{{< note title="Note" theme="info" >}} + +On Dedicated Gen 3 projects, SFTP access cannot be limited to a specific directory. Instead, access is given to the whole application directory and its mounts. SSH public key based authentication is also supported on the SFTP account. + +{{< /note >}} + diff --git a/sites/platform/src/dedicated-environments/overview.md b/sites/platform/src/dedicated-environments/overview.md new file mode 100644 index 0000000000..41f4d0398c --- /dev/null +++ b/sites/platform/src/dedicated-environments/overview.md @@ -0,0 +1,69 @@ +--- +title: "Overview" +weight: -20 +sidebarTitle: "Overview" +layout: single +description: "Our Dedicated Environments are well-suited for those who need more resources and redundancy, along with stricter isolation requirements." +--- + +{{% description %}} + +When you create a project on Platform.sh, you can choose to deploy it using one of three types of architecture offerings: Professional (known as Grid), [Dedicated Generation 2](/dedicated-environments/dedicated-gen-2/_index.md) (DG2) or [Dedicated Generation 3](/dedicated-environments/dedicated-gen-3/_index.md) (DG3).  + +## What is Dedicated? + +DG2 and DG3 are classified as Dedicated Environments (Dedicated). This is because your production environment is replicated across at least three virtual servers that are dedicated solely to your project. + +In the diagram below, we can see that the Dedicated architecture provides three virtual servers that act as isolated hosts for a site in a failover configuration. Within each server, all the data of your site is synced. + +![The dedicated architecture](/images/dedicated/dedicated-architecture.svg "0.50") + +Having three isolated hosts means that when one becomes unavailable, the others take over, so your site will always remain up and running. This differs from the Grid architecture, where a single host runs multiple projects from various customers simultaneously.  + +From the Grid architecture diagram below, we can see that projects hosted in Grid share resources. The CPU, memory, and networking with other projects are all running on the same host. There is only one host that can be relied on in a failover configuration, and this host also holds the resources of various other sites. There is also a [Ceph](/glossary.md#ceph) storage dependency. + +![The grid architecture](/images/dedicated/grid-architecture.svg "0.50") + +## Deployment + +With a Dedicated Environment, you are given the freedom to deploy into **any public region of supported IaaS providers** (currently **AWS, Azure, GCP, OVH**). This differs from the Grid architecture, which is solely available in [public regions](https://platform.sh/regions/). + +For a full list of public regions and IP addresses, visit the [Regions page](/development/regions.md#regions). + +In a Grid region, incoming and outgoing traffic is handled via central region gateways, and [publicly available IP addresses](/development/regions.md#public-ip-addresses) can be used for external firewalls. The public IP addresses for these public regions are stable but not guaranteed never to change. + +## Grid vs Dedicated + +Whether you choose a Grid or Dedicated Environment depends on the needs you have. In the table below, you can see the different ways in which either might work for you:  + +| FEATURE | GRID | DEDICATED | +| --- | --- | --- | +| **Availability** | All support tiers | Just with [Enterprise or Elite](https://platform.sh/pricing/) | +| **Uptime SLA** | 99.9% with [Enterprise or Elite](https://platform.sh/pricing/)| 99.99% with [Enterprise or Elite](https://platform.sh/pricing/) | +| **Infrastructure** | Containers with dedicated resources on top of a shared redundant infrastructure| Dedicated 3 node clusters| +| **Functioning** | A single container is deployed per runtime and per service| at least 3 nodes are running all applications and services are replicated across all of them | +| **Resource Allocation** | Resources are spread through one container with fixed sizes after deployment| Resources are deployed across a least 3 nodes +| **Usable regions** | Any public region can be used to deploy | Any public region of supported IaaS providers can be used to deploy | +| **Autonomous upsize** | Yes | Managed through Platform.sh | +| **Upsize and downsize methods** | Redeploy - possible downtime depending on the hooks | No downtime - each instance is altered in a rolling fashion | +| **Multi-app support** | Supported natively | Supported through docroots on Dedicated Gen 2 and supported natively on Dedicated Gen 3 | +| **Custom domains name** | On all branches for Enterprise and Elite customers | On all branches for Enterprise and Elite customers | +| **Sync and merge functionalities** | Yes on all branches | Only on development environments | +| **Environment clone** | Yes on all branches | Only on development environments | +| **MySQL Replication** | None: standalone service container | Yes: at least 3 services nodes cluster that follow the leader-follower principle| +| **Redis Replication** | None: standalone service container | Yes: at least 3 services nodes cluster | +| **MongoDB** | Standalone service container | No | +| **CDN** | A managed Fastly CDN service can be purchased through Platform.sh | Fastly | +| **PHP version upgrade** | Self-service | Self-service | +| **NodeJS version upgrade**| Self-service | Self-service | +| **Routes management** | Self-service | Self-service | +| **Cron management** | Self-service | Self-service | +| **Cron tasks interrupted by deploys** | No: a running Cron task will block a deployment until it is complete | Yes: a deploy will terminate a running Cron task | +| **Mounts management** | Self-service | Managed by Platform.sh (Dedicated Gen 2 only) | +| **Workers management** | Self-service | Managed by Platform.sh | +| **Storage increase** | Self-service | Managed by Platform.sh | +| **Storage allocation between mounts, DB and services** | Self-service | Managed by Platform.sh | + + + +For more information about our Dedicated offerings, explore our [Dedicated Gen 2](/dedicated-environments/dedicated-gen-2/_index.md) and [Dedicated Gen 3](/dedicated-environments/dedicated-gen-3/_index.md) pages. \ No newline at end of file diff --git a/sites/platform/src/dedicated-environments/security-monitoring.md b/sites/platform/src/dedicated-environments/security-monitoring.md new file mode 100644 index 0000000000..36a20954c4 --- /dev/null +++ b/sites/platform/src/dedicated-environments/security-monitoring.md @@ -0,0 +1,53 @@ +--- +title: "Security and monitoring" +weight: -17 +sidebarTitle: "Security and monitoring" +layout: single +description: "Security is handled in a similar way for both Dedicated Gen 2 and Dedicated Gen 3 projects, with strict procedures that are followed to handle incidents." +--- + +We use a combination of three trusted methods to ensure your site is secure and running at all times:  + +- [Project isolation](#project-isolation) +- [Encryption](#encryption) +- [Performance monitoring](#performance-monitoring) + +{{% description %}} + +### Project isolation  + +All Dedicated clusters are single-tenant. The [three hosts](/dedicated-environments/dedicated-gen-2/overview.md) are exclusively used by a single customer and each cluster is launched into its own isolated network (VPC on AWS, equivalent on other providers). The network is behind a firewall for incoming connections. Only ports 22 (SSH), 80 (HTTP), and 443 (HTTPS), and 2221 (SFTP) are opened to incoming traffic. + +There are no exceptions for this rule, so any incoming web service requests, ETL jobs, or otherwise need to transact over one of these protocols. Outgoing TCP traffic isn’t behind a firewall. Outgoing UDP traffic is disallowed. For containers to be allowed to connect to each other, the following requirement must be met: + +- The containers must live in the same environment +- You need to define an explicit relationship between the containers in your [app configuration](/create-apps/app-reference/single-runtime-image.md#relationships) + +All Dedicated projects are isolated and their data is fully encrypted. Should a security breach occur, Platform.sh follows a strict security incident handling procedure to deal with the issue as promptly and efficiently as possible. + +### Encryption  + +All sites and tools supported and maintained by Platform.sh are fully encrypted by default. + +For more information about Encryption at Platform.sh, visit the [Platform.sh Trust Center](https://platform.sh/trust-center/security/encryption/). + +### Performance monitoring + +All of our Dedicated clusters are monitored 24/7 to ensure uptime and to measure server metrics such as available disk space, memory and disk usage, and several dozen other metrics that give us a complete picture of the health of your application’s infrastructure. + +As soon as a metric goes out of bounds (i.e., an outage is detected), Support and Operations teams are alerted, a Point in Time report is generated, and the Platform.sh teams can triage the cause of the outage. + +#### Automated monitoring + +On top of internal Platform.sh tools, a third-party availability monitoring system is configured for every Dedicated project. This further guarantees that issues are spotted and addressed as quickly as possible. If you’re using a CDN, [make sure it’s configured](/domains/cdn/_index.md#configure-your-cdn-to-support-high-sla) to support automated monitoring and guarantee high SLA. + +Automated monitoring is used to keep an eye on your production environment at all times. If automated monitoring triggers an alert, or if a customer files an urgent priority ticket, an on-call engineer is immediately paged so they can respond and begin to triage the issue. +Cloud infrastructure issues are handled by the Platform.sh Customer Success team. Note that application problems are returned to the user and may be downgraded. + +#### Observability services + +As the official, in-house Platform.sh observability tool, [Blackfire](/increase-observability/integrate-observability/blackfire.md) provides unparalleled monitoring, profiling, and performance testing technologies. Using Blackfire on Platform.sh enhances your experience and allows you to enjoy greater support as well as unique upcoming features. + +As an Enterprise or Elite customer, you can use the Platform.sh [Observability Suite](https://platform.sh/features/observability-suite/), which offers application performance monitoring by Blackfire packaged with infrastructure monitoring. The Observability Suite includes all Blackfire features, support, and usage that scales with your needs. + +Platform.sh also supports third-party observability services such as [New Relic](/increase-observability/integrate-observability/new-relic/_index.md) and [Tideways](/increase-observability/integrate-observability/tideways.md). You need to get your own license for them. These third-party services have their own associated cost, are language-specific, and may not be available for all languages. \ No newline at end of file diff --git a/sites/platform/src/dedicated-gen-2/architecture/_index.md b/sites/platform/src/dedicated-gen-2/architecture/_index.md deleted file mode 100644 index f9d8a02906..0000000000 --- a/sites/platform/src/dedicated-gen-2/architecture/_index.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: "{{% names/dedicated-gen-2 %}} cluster specifications" -weight: 2 -layout: single -sidebarTitle: "Features" -description: "{{% names/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." ---- - -{{% description %}} - -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. - -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). \ No newline at end of file diff --git a/sites/platform/src/dedicated-gen-2/architecture/deploying.md b/sites/platform/src/dedicated-gen-2/architecture/deploying.md deleted file mode 100644 index 9bda170cb7..0000000000 --- a/sites/platform/src/dedicated-gen-2/architecture/deploying.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: "Deployment" -weight: 1 -sidebarTitle: "Deploying" ---- - -## Deploying to Production and Staging - -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 {{% names/dedicated-gen-2 %}} cluster. -Any defined users or environment variables are also propagated to the {{% names/dedicated-gen-2 %}} cluster. - -Note that there is no automatic cloning of data from the {{% names/dedicated-gen-2 %}} cluster to the Development Environment -the way there is between branches in the Development Environment. -Production data may still be replicated to the Development Environment manually. - -Deploys of other branches don't trigger rebuilds of the {{% names/dedicated-gen-2 %}} cluster environments. - -## Deployment process - -When deploying to the {{% names/dedicated-gen-2 %}} cluster the process is slightly different than when working with {{% vendor/name %}} on the Grid. - -* The new application image is built in the exact same fashion as for {{% vendor/name %}} 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 highly dependent on how long the deploy hook takes to run. - -During the deploy process the cluster is unavailable. -Nearly all {{% names/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. - -## Deployment philosophy - -{{% vendor/name %}} values consistency over availability, -which means that deployments can cause your app to be unavailable for a short amount of time. -For more information, see the [overview of the build and deploy phases](/learn/overview/build-deploy.md). diff --git a/sites/platform/src/dedicated-gen-2/architecture/development.md b/sites/platform/src/dedicated-gen-2/architecture/development.md deleted file mode 100644 index 936030cc15..0000000000 --- a/sites/platform/src/dedicated-gen-2/architecture/development.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "{{% vendor/name %}} development environments" -weight: 2 -sidebarTitle: "Dev environments" -description: "{{% names/dedicated-gen-2 %}} customers have a development environment for their project that consists of a {{% vendor/name %}} Grid project, typically provisioned by the {{% vendor/name %}} team to reflect the amount of storage in your contract. This environment provides you with all the DevOps, Continuous Integration, Continuous Deployment, and other workflow tooling of the professional product, but segregates the performance impacts from your production hardware." ---- - -## Architecture (Development Environments) - -![{{% vendor/name %}} Professional architecture](/images/dedicated/PS-Arch-NoHA.svg "0.6") - -## Default limits - -The Development Environment for a {{% names/dedicated-gen-2 %}} project provides `production` and `staging` branches linked to the {{% names/dedicated-gen-2 %}} cluster -and 3 additional active environments for development. -This number can be increased if needed for an additional fee. - -The default storage for {{% names/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. - -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 {{% names/dedicated-gen-2 %}} cluster. - -## Larger developments environments - -By default, all containers in development environments are {{< partial "plans/default-dev-env-size" >}} sized, as they have limited traffic needs. -For more resource-intensive applications this size can be increased for an additional fee. diff --git a/sites/platform/src/dedicated-gen-2/architecture/options.md b/sites/platform/src/dedicated-gen-2/architecture/options.md deleted file mode 100644 index 9274061db1..0000000000 --- a/sites/platform/src/dedicated-gen-2/architecture/options.md +++ /dev/null @@ -1,81 +0,0 @@ ---- -title: "Optional features" -weight: 4 -description: Add optional features to your {{% names/dedicated-gen-2 %}} project. -keywords: - - SFTP - - sftp ---- - -You can enable the following features on your {{% names/dedicated-gen-2 %}} projects, -as well as [multiple availability zones](../../dedicated-gen-3/options.md#multiple-availability-zones). - -To enable an optional feature or get more information on potential fees, -[contact Sales](https://platform.sh/contact/). - -## Multiple applications - -{{% multi-app-intro %}} - -For more information, see how to [configure multiple apps in a single project](../../create-apps/multi-app/_index.md). - -## Staging environments - -A dedicated single-node staging machine is provisioned for your application with an identical software configuration to your production hardware, but reduced hardware specs. -This gives the advantages of isolating the staging load from the production hardware as well as having an identical software configuration to perform UAT, but this option doesn't provide a bed for performance testing as the physical hardware configuration isn't the same as production. - -## Additional application servers - -For especially high-traffic sites we can also add additional application-only servers. -These servers contain just the application code; data storage services (such as SQL, Solr, Redis) are limited to the standard three. -The cluster begins to look more like a standard N-Tier architecture at this point, with a horizontal line of web application servers in front of a 3 node (N+1) cluster of Galera database servers. - -Speak to your sales representative about the costs associated with adding additional application servers. -This configuration requires a separate setup from the default so advanced planning is required. - -## SFTP - -In addition to SSH accounts, you can create `sftp` accounts with a custom user/password that are restricted to certain directories. -These directories must be one of the writeable mounts (or rather, there’s no point assigning them to the read-only code directory). - -There is no cost for this configuration, and you can request it at any time via a [support ticket](/learn/overview/get-support.md). -SSH public key based authentication is also supported on the `sftp` account. - -See how to [transfer files through `sftp`](/development/file-transfer.md). - -## Error handling - -On Grid projects, incoming requests are held at the edge router temporarily during a deploy. -That allows a site to "respond slowly" rather than be offline during a deploy, provided the deploy time is short (a few seconds). - -On {{% names/dedicated-gen-2 %}} projects, incoming requests aren't held during deploy and receive a 503 error. -As the {{% names/dedicated-gen-2 %}} cluster is almost always fronted by a CDN, -the CDN continues to serve cached pages during the few seconds of deploy, -so for the vast majority of users there is no downtime or even slow down. -If a request does pass the CDN during a deploy, it isn't counted as downtime covered by our Service Level Agreement. - -By default, {{% vendor/name %}} serves generic {{% vendor/name %}}-branded error pages for errors generated before a request reaches the application. -(500 errors, some 400 errors, etc.) Alternatively you may provide a static error page for each desired error code via a ticket for us to configure with the CDN. -This file may be any static HTML file but is limited to 64 KB in size. - -## Remote logging - -{{% names/dedicated-gen-2 %}} supports sending logs to a remote logging service such as Loggly, Papertrail, or Logz.io using the `rsyslog` service. -This is an optional feature and you can request that it be enabled via a [support ticket](/learn/overview/get-support). -Once enabled and configured your application can direct log output to the system `syslog` facility -and is replicated to the remote service you have configured. - -When contacting support to enable `rsyslog`, you need: - -- The name of the remote logging service to use. -- The message template format used by your logging service. -- The specific log files you want forwarded to your logging service. - -There is no cost for this functionality. - -## IP restrictions - -{{% vendor/name %}} supports [project-level IP restrictions (allow/deny) and HTTP Basic authentication](../../environments/http-access-control.md). These may be configured through the Development Environment and are automatically replicated from the production and staging branches to the production and staging environments, respectively. - -Changing access control triggers a new deploy of the current environment. -However, the changes aren’t propagated to child environments until they’re manually redeployed. \ No newline at end of file diff --git a/sites/platform/src/dedicated-gen-2/overview/_index.md b/sites/platform/src/dedicated-gen-2/overview/_index.md deleted file mode 100644 index 1d0bd461a9..0000000000 --- a/sites/platform/src/dedicated-gen-2/overview/_index.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "{{% names/dedicated-gen-2 %}}" -weight: 1 -sidebarTitle: "Overview" -layout: single -description: "{{% names/dedicated-gen-2 %}} is a robust, redundant layer. It's well-suited for those who like the {{% vendor/name %}} development experience but need more resources and redundancy for their production environment. It's available only with an Enterprise contract." ---- - -{{% description %}} - -{{% names/dedicated-gen-2 %}} consists of two parts: a Development Environment and a {{% names/dedicated-gen-2 %}} cluster. - -## The Development Environment - -The Development Environment is a normal Grid environment with all Grid capabilities and workflows. -The default branches are slightly different, as noted in the [default limits](../architecture/development.md#default-limits). - -## The {{% names/dedicated-gen-2 %}} cluster - -The {{% names/dedicated-gen-2 %}} cluster is a three-host redundant configuration provisioned by {{% vendor/name %}} for each customer. -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. - -The build process for your application is identical for both the Development Environment and the {{% names/dedicated-gen-2 %}} cluster. -However, because the hosts are provisioned by {{% vendor/name %}}, not as a container, -service configuration must be done by {{% vendor/name %}}'s Customer Success team. -By and large the same flexibility is available but only via opening a [support ticket](/learn/overview/get-support). diff --git a/sites/platform/src/dedicated-gen-2/overview/backups.md b/sites/platform/src/dedicated-gen-2/overview/backups.md deleted file mode 100644 index 8a929d0824..0000000000 --- a/sites/platform/src/dedicated-gen-2/overview/backups.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Backups" -weight: 4 -toc: false -description: See when backups of {{% names/dedicated-gen-2 %}} environments are taken. ---- - -{{% vendor/name %}} takes a byte-for-byte snapshot of {{% names/dedicated-gen-2 %}} production environments every 6 hours. -Backups are retained for different durations depending on when they're taken. -For details, see the [retention policy for backups](../../security/data-retention.md#dedicated-gen-2-backups). - -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 {{% vendor/name %}}. -To request a restoration, open a [support ticket](/learn/overview/get-support). - -The restoration process 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 {{% names/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. -(We don't 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.) - -You are free to make your own backups using standard tools (`mysqldump`, rsync, etc.) at your own leisure. diff --git a/sites/platform/src/dedicated-gen-2/overview/monitoring.md b/sites/platform/src/dedicated-gen-2/overview/monitoring.md deleted file mode 100644 index 43a4cc6e1d..0000000000 --- a/sites/platform/src/dedicated-gen-2/overview/monitoring.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -title: "Resource and incident monitoring" -weight: 2 -sidebarTitle: "Incident Monitoring" -description: | - All of our Dedicated clusters are monitored 24/7 to ensure uptime and to measure server metrics such as available disk space, memory and disk usage, and several dozen other metrics that give us a complete picture of the health of your application’s infrastructure. ---- - -{{% description %}} - -For more information, see which [monitoring systems](../../dedicated-gen-3/monitoring.md) {{% vendor/name %}} uses to [monitor application performance](../../dedicated-gen-3/monitoring.md#application-performance-monitoring) -and detect [availability incidents](../../dedicated-gen-3/monitoring.md#availability-incident-handling-procedure) -on both {{% names/dedicated-gen-2 %}} and {{% names/dedicated-gen-3 %}} projects. \ No newline at end of file diff --git a/sites/platform/src/dedicated-gen-2/overview/security.md b/sites/platform/src/dedicated-gen-2/overview/security.md deleted file mode 100644 index 9fa055624a..0000000000 --- a/sites/platform/src/dedicated-gen-2/overview/security.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: "Security & data privacy" -weight: 2 -sidebarTitle: "Security and privacy" ---- - -Security and data privacy are handled in a similar way for all Dedicated projects. -See [how {{% vendor/name %}} manages incidents](../../dedicated-gen-3/security.md#security-incident-handling-procedure), -and [how data is encrypted](../../dedicated-gen-3/security.md#encryption) -on both {{% names/dedicated-gen-2 %}} and {{% names/dedicated-gen-3 %}} projects. - -{{% project-isolation %}} \ No newline at end of file diff --git a/sites/platform/src/dedicated-gen-2/overview/updates-upgrades.md b/sites/platform/src/dedicated-gen-2/overview/updates-upgrades.md deleted file mode 100644 index 3cd8ec293b..0000000000 --- a/sites/platform/src/dedicated-gen-2/overview/updates-upgrades.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: "Updates and upgrades" -weight: 3 ---- - -{{% vendor/name %}} updates the core software of the {{% names/dedicated-gen-2 %}} cluster (operating system, web server, PHP, MySQL, etc.) periodically, and after any significant security vulnerability is disclosed. -These updates are deployed automatically with no additional work required by you. -We attempt to maintain parity with your development environment, but we don't guarantee absolute parity of point versions of your {{% names/dedicated-gen-2 %}} environments with their corresponding development environments. -I.e, your development environment may have a PHP container running 5.6.30, but your production environment may lag behind at 5.6.22. -We can upgrade point releases on request and always upgrade the underlying software in the event of security release. - -Updates to application software (PHP code, JavaScript, etc.) are the responsibility of the customer. \ No newline at end of file diff --git a/sites/platform/src/dedicated-gen-3/_index.md b/sites/platform/src/dedicated-gen-3/_index.md deleted file mode 100644 index 276f01e743..0000000000 --- a/sites/platform/src/dedicated-gen-3/_index.md +++ /dev/null @@ -1,65 +0,0 @@ ---- -title: "{{% names/dedicated-gen-3 %}}" -weight: -19 -layout: single -description: Learn more about the Dedicated Gen 3 offering, which provides a redundant configuration with at least 3 virtual machine instances for your production environment. ---- - -{{% names/dedicated-gen-3 %}} runs the same software as on the Grid, but on isolated hosts. -Each service is replicated across three hosts in a failover configuration. -If a host becomes unavailable, the other two take over so your site remains up. - -{{% names/dedicated-gen-3 %}} was designed to cater to the needs of organizations that build demanding apps. -Compared to the Grid, {{% names/dedicated-gen-3 %}} offers increased resources, -high availability for all your services and apps, -stricter isolation requirements, -as well as additional compliance frameworks. - -To set up a {{% names/dedicated-gen-3 %}} project on [any supported cloud provider](../development/regions.md#regions), -[contact {{% vendor/name %}}](https://platform.sh/contact). -Note that existing Grid and {{% names/dedicated-gen-2 %}} projects can't be migrated to {{% names/dedicated-gen-3 %}} at this time. - -## Storage - -Each {{% names/dedicated-gen-3 %}} cluster comes with 50GB of storage per environment by default. -This storage is intended for your data (databases, search indexes, user uploaded files, etc.) -and you can subdivide it as you want. - -You can request more storage at any time. - -## Differences with the Grid - -If you upgrade from the Grid to {{% names/dedicated-gen-3 %}}, -there are a few differences you need to be aware of. - -### Available services - -Not every service or version available on the Grid is available on {{% names/dedicated-gen-3 %}}. -The following table shows the currently available services and their versions for {{% names/dedicated-gen-3 %}}. - -{{< gen-3-services >}} - -Your app can connect to each service by referencing -the exact same [environment variables](../development/variables/_index.md) as for Grid environments. -See the [services documentation](../../add-services/_index.md) for service-specific details. - -### Local mounts - -{{% names/dedicated-gen-3 %}} provides a redundant infrastructure -and local mounts aren't shared between the three hosts. - -If you need a folder to be shared between your hosts, -set up a [network storage mount](../add-services/network-storage.md). - -## Differences with {{% names/dedicated-gen-2 %}} - -Just like {{% names/dedicated-gen-3 %}}, -[{{% names/dedicated-gen-2 %}}](../../dedicated-gen-2/overview/_index.md) ensures increased uptime -and availability for your apps and services. -But as a {{% names/dedicated-gen-2 %}} user, -you have to go through the {{% vendor/name %}} Customer Success team to make configuration or application topology changes. - -{{% names/dedicated-gen-3 %}} gives you both the high availability of {{% names/dedicated-gen-2 %}} -and the self-service flexibility and features of Grid projects. -As a {{% names/dedicated-gen-3 %}} user, you can edit your configuration yourself -and see those changes reflected in your environments on every push without opening a ticket. \ No newline at end of file diff --git a/sites/platform/src/dedicated-gen-3/monitoring.md b/sites/platform/src/dedicated-gen-3/monitoring.md deleted file mode 100644 index 344979c1e2..0000000000 --- a/sites/platform/src/dedicated-gen-3/monitoring.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: "Resource and incident monitoring" -weight: 2 -sidebarTitle: "Incident monitoring" -description: Learn how {{% vendor/name %}} monitors your clusters and handles availability incidents. ---- - -{{% vendor/name %}} monitors Dedicated clusters 24/7 to maintain uptime and performance. - -A wide range of server metrics, including disk space, memory, and disk usage are continuously measured using in-house tools. -These metrics provide a complete picture of the health of your application infrastructure. - -As soon as a metric goes out of bounds, {{% vendor/name %}} Support and Operations teams are alerted. -When an outage is detected, a Point in Time report is generated -so {{% vendor/name %}} Support can triage the cause of the outage. - -On top of internal {{% vendor/name %}} tools, -a third-party availability monitoring system is configured for every Dedicated project. -This further guarantees that issues are spotted and addressed as quickly as possible. - -If you're using a CDN, [make sure it's configured](../domains/cdn/_index.md#configure-your-cdn-to-support-high-sla) -to support automated monitoring and guarantee high SLA. - -## Application performance monitoring - -As the official, in-house {{% vendor/name %}} observability tool, [Blackfire](../../increase-observability/integrate-observability/blackfire.md) provides unparalleled monitoring, profiling, and performance testing technologies. -Using Blackfire on {{% vendor/name %}} enhances your experience -and allows you to enjoy greater support as well as unique upcoming features. - -You can subscribe to Blackfire in two different ways: - -- As an Enterprise or Elite customer, - you can sign up for the {{% vendor/name %}} [Observability Suite](https://platform.sh/features/observability-suite/), - which offers application performance monitoring by Blackfire packaged with infrastructure monitoring. - The Observability suite includes all Blackfire features, support, and usage that scales with your needs. - To subscribe to the Observability Suite, [contact Sales](https://platform.sh/contact/). - -- All customers can also [subscribe to Blackfire](https://www.blackfire.io/pricing) separately. - To get a quote based on the size of your cluster, [contact Sales](https://platform.sh/contact/). - Note that if you subscribe to Blackfire separately, - features and usage may cost more than the equivalent bundled in the Observability Suite. - -{{% vendor/name %}} also supports third-party observability services -such as [New Relic](../increase-observability/integrate-observability/new-relic/_index.md) -and [Tideways](../increase-observability/integrate-observability/tideways.md). -You need to get your own license for them. -These third-party services have their own associated cost, -are language-specific, and may not be available for all languages. - -## Availability incident handling procedure - -Automated monitoring is used to keep an eye on your production environment at all times. -If automated monitoring triggers an alert, or if a customer files an urgent priority ticket, -an on-call engineer is immediately paged so they can respond and begin to triage the issue. - -Cloud infrastructure issues are handled by the {{% vendor/name %}} Customer Success team. -Note that application problems are returned to the user and may be downgraded. - -![Diagram of the {{% vendor/name %}} availability incident handling procedure](/images/dedicated/incident-monitoring.svg "0.4") \ No newline at end of file diff --git a/sites/platform/src/dedicated-gen-3/options.md b/sites/platform/src/dedicated-gen-3/options.md deleted file mode 100644 index 0f1b87c660..0000000000 --- a/sites/platform/src/dedicated-gen-3/options.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: Optional features -weight: 4 -description: You can add optional features to your {{% names/dedicated-gen-3 %}} project. -keywords: - - SFTP - - sftp ---- - -You can enable the following features on your {{% names/dedicated-gen-3 %}} projects. - -To enable an optional feature or get more information on potential fees, -[contact Sales](https://platform.sh/contact/). - -## Multiple availability zones - -The default configuration for Dedicated clusters is to launch them into a single availability zone (AZ) -for the following reasons: - -- The members of your cluster communicate with each other via TCP to perform DB replication, - cache lookup, and other associated tasks. - Therefore, the latency between data centers or AZs can become a significant performance liability. - When your entire cluster is deployed within a single AZ, the latency between cluster members is minimal. - This has a direct effect on perceived end-user performance. - -- Network traffic between AZs is billed, whereas intra-AZ traffic isn't. - So launching Dedicated clusters across multiple AZs leads to higher costs for decreased performance. - -If you prefer the peace of mind of hosting across multiple AZs, -you can request a different configuration. -But note that multiple-AZ configurations don't improve the contractual 99.99% uptime SLA -(nor does the standard, single-AZ configuration decrease the 99.99% uptime SLA). -{{% vendor/name %}} is responsible for meeting the 99.99% uptime SLA no matter what, -so multiple-AZ deployments should only be considered in cases where they're truly appropriate. - -Multi-AZ deployments are available only on select AWS regions. - -## SFTP - -In addition to SSH accounts, you can create `sftp` accounts with a custom user/password to [transfer files](/development/file-transfer.md). - -{{< note >}} - -On {{% names/dedicated-gen-3 %}} projects, `sftp` access cannot be limited to a specific directory. -Instead, access is given to **the whole application directory** and its mounts. - -{{< /note >}} - -SSH public key based authentication is also supported on the `sftp` account. \ No newline at end of file diff --git a/sites/platform/src/dedicated-gen-3/security.md b/sites/platform/src/dedicated-gen-3/security.md deleted file mode 100644 index 03adc21de8..0000000000 --- a/sites/platform/src/dedicated-gen-3/security.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: "Security and data privacy" -weight: 3 -description: Learn how security and data privacy are handled on {{% names/dedicated-gen-3 %}} projects. ---- - -{{% vendor/name %}} is committed to protecting your data and keeping your site safe, secure, and available at all times. -All Dedicated projects are isolated and their data is fully encrypted. - -Should a security breach occur, {{% vendor/name %}} follows a strict [security incident handling procedure](#security-incident-handling-procedure) -to deal with the issue as promptly and efficiently as possible. - -{{% project-isolation plan="true" %}} - -## Security incident handling procedure - -Should {{% vendor/name %}} become aware of a security incident — such as an active or past hacking attempt, virus or worm, or data breach — -senior personnel, including the CTO, are promptly notified. - -The security incident procedure includes the following steps: - -1. Isolating the affected systems. -2. Collecting forensic evidence for later analysis, including a byte-for-byte copy of the affected systems. -3. Restoring normal operations. - -Once normal service is restored, a root cause analysis is performed to determine exactly what happened. -Upon request, {{% vendor/name %}} can provide you with a Reason for Outage report that summarizes the incident, cause, and steps taken. - -{{% vendor/name %}} cooperates with relevant law enforcement, -and informs law enforcement in the event of an attempted malicious intrusion. -Depending on the type of incident, the root cause analysis may be conducted by law enforcement rather than {{% vendor/name %}} personnel. - -{{% vendor/name %}} endeavors to notify affected customers within 24 hours in case of a personal data breach -and 72 hours in case of a project data breach. - - - -Under the European General Data Protection Regulation (GPDR), -{{% vendor/name %}} is required to notify its supervising authority within 72 hours of a discovered breach -that may result in risk to the rights and freedoms of individuals. -The supervising authority for {{% vendor/name %}} is the French [Commission Nationale de l'Informatique et des Libertés](https://www.cnil.fr/). - - -### Audit trail - -As part of the security incident process, {{% vendor/name %}} records a log of all steps taken to identify, -isolate, and respond to the incident. -This log may include: - -- A byte-for-byte copy of the affected systems -- How the intrusion was detected -- The steps taken to contain the intrusion -- Any contact with third parties, including law enforcement -- Any conclusions reached regarding the root cause - -## Encryption - -### AWS - -AWS EBS Volumes are encrypted on {{% vendor/name %}}, -which means {{% names/dedicated-gen-3 %}} and {{% names/dedicated-gen-2 %}} sites are fully encrypted. -Keys are managed by the AWS Key Management Service. -AWS automatically rotates these keys every three years. -In some cases, temporary storage (such as swap) is stored on unencrypted local storage volumes. - -### Azure - -By default, data is encrypted using [Microsoft-Managed Keys](https://learn.microsoft.com/en-us/compliance/assurance/assurance-encryption) -for Azure Blobs, Tables, Files, and Queues. - -### GCP - -Data is encrypted using [default encryption at rest](https://cloud.google.com/docs/security/encryption/default-encryption?hl=en). \ No newline at end of file diff --git a/sites/platform/src/development/variables/use-variables.md b/sites/platform/src/development/variables/use-variables.md index 9bae44bc6a..c430eaf869 100644 --- a/sites/platform/src/development/variables/use-variables.md +++ b/sites/platform/src/development/variables/use-variables.md @@ -354,7 +354,7 @@ and at runtime. ### Variables on {{% names/dedicated-gen-2 %}} environments -[{{% names/dedicated-gen-2 %}} instances](../../dedicated-gen-2/overview/_index.md) also have the following variables available: +[{{% names/dedicated-gen-2 %}} instances](/dedicated-environments/dedicated-gen-2/overview/_index.md) also have the following variables available: | Variable name | Build | Runtime | Description | | ---------------- | ----- | ------- | ----------- | @@ -363,7 +363,7 @@ and at runtime. {{< note >}} -The `PLATFORM_CLUSTER` environment variable isn't yet available on [{{% names/dedicated-gen-3 %}}](../../dedicated-gen-3/_index.md). +The `PLATFORM_CLUSTER` environment variable isn't yet available on [{{% names/dedicated-gen-3 %}}](/dedicated-environments/dedicated-gen-3/_index.md). If your application depends on whether it's running on a {{% names/dedicated-gen-3 %}} host, use `PLATFORM_MODE`. {{< /note >}} diff --git a/sites/platform/src/environments/backup.md b/sites/platform/src/environments/backup.md index 79519ad9b3..cf4984b0ce 100644 --- a/sites/platform/src/environments/backup.md +++ b/sites/platform/src/environments/backup.md @@ -62,7 +62,7 @@ For information on how long backups are retained, see the [data retention policy ## Backup schedule -Backups for Dedicated environments have a [specific frequency](../dedicated-gen-2/overview/backups.md). +Backups for Dedicated environments have a [specific frequency](/dedicated-environments/dedicated-gen-2/environment-differences.md#backups). On Grid environments, preview environments can have up to 2 [manual backups](#create-a-manual-backup). The number of available backups for Production environments depends on your schedule. @@ -101,7 +101,7 @@ To downgrade to the lower schedule, [contact support](/learn/overview/get-suppor ## Use automated backups -For Dedicated environments, see more about [backups of Dedicated environments](../dedicated-gen-2/overview/backups.md). +For Dedicated environments, see more about [backups of Dedicated environments](/dedicated-environments/dedicated-gen-2/environment-differences.md#backups). For Grid environments, automated backups are taken for production environments at least once every day. The exact number of backups depends on your [backup schedule](#backup-schedule). @@ -132,8 +132,8 @@ They may make restorations less reliable. To avoid such issues, schedule [manual backups](#create-a-manual-backup) during non-peak hours, when the short amount of downtime is least noticed. -Automated backups are always live, including those taken on [{{% names/dedicated-gen-3 %}}](../dedicated-gen-3/_index.md) -and [{{% names/dedicated-gen-2 %}}](../dedicated-gen-2/overview/_index.md) environments. +Automated backups are always live, including those taken on [{{% names/dedicated-gen-3 %}}](/dedicated-environments/dedicated-gen-3/_index.md) +and [{{% names/dedicated-gen-2 %}}](/dedicated-environments/dedicated-gen-2/overview/_index.md) environments. You can create a manual live backup on a Grid project: diff --git a/sites/platform/src/glossary/_index.md b/sites/platform/src/glossary/_index.md index dfeeb38742..40c6dc9b66 100644 --- a/sites/platform/src/glossary/_index.md +++ b/sites/platform/src/glossary/_index.md @@ -79,6 +79,10 @@ all branching and merging must be managed through the upstream repository to avo {{< /codetabs >}} +## Ceph + +Ceph is a storage platform that provides distributed object, block and file storage built on a cluster foundation. Ceph can be used to provide reliable, redundant distributed storage for your data. + ## Cluster Every active environment is deployed as a cluster, @@ -88,13 +92,18 @@ That may include a database container, an Elasticsearch container, a container for your application, and more. They're always deployed together as a single unit. +## Control plane + +The control plane is Platform.sh’s orchestration, control, and management environment. It helps us to establish and operate regions, provision services and networks. + + ## {{% names/dedicated-gen-2 %}} -[{{% names/dedicated-gen-2 %}} environments](../dedicated-gen-2/overview/_index.md) are managed host clusters with triple redundancy. +[{{% names/dedicated-gen-2 %}} environments](/dedicated-environments/dedicated-gen-2/overview.md) are managed host clusters with triple redundancy. Their dedicated architecture makes them differ from [Grid environments](#grid). -See a [list of differences](../dedicated-gen-2/overview/grid.md). +See a [list of differences](/dedicated-environments/dedicated-gen-2/environment-differences.md). -These differences aren't present with [{{% names/dedicated-gen-3 %}} projects](../dedicated-gen-3/_index.md). +These differences aren't present with [{{% names/dedicated-gen-3 %}} projects](/dedicated-environments/dedicated-gen-3/_index.md). ## Deprecated versions diff --git a/sites/platform/src/increase-observability/metrics/_index.md b/sites/platform/src/increase-observability/metrics/_index.md index 51c651a224..d8f72405aa 100644 --- a/sites/platform/src/increase-observability/metrics/_index.md +++ b/sites/platform/src/increase-observability/metrics/_index.md @@ -12,15 +12,15 @@ Within the Console, metrics can be found for an environment under **Metrics**. The information under **Metrics** shows usage metrics for: -[{{% names/dedicated-gen-2 %}} environments](../../dedicated-gen-2/overview/_index.md): -each of the three hosts in your [N+1 configuration](../../dedicated-gen-2/architecture/_index.md) +[{{% names/dedicated-gen-2 %}} environments](/dedicated-environments/dedicated-gen-2/overview/_index.md): +each of the three hosts in your [N+1 configuration](/dedicated-environments/dedicated-gen-2/overview.md) and their average for the Production environment. Metrics aren't available for other {{% names/dedicated-gen-2 %}} environments (such as a staging environment), but are available for Grid environments (such as your preview environments). ![A screenshot of what the metrics dashboard displays for {{% names/dedicated-gen-2 %}} environments](/images/metrics/all-dedicated.png "0.45") -[{{% names/dedicated-gen-3 %}} environments](../../dedicated-gen-3/_index.md): each of the three hosts and their average. +[{{% names/dedicated-gen-3 %}} environments](/dedicated-environments/dedicated-gen-3/_index.md): each of the three hosts and their average. These metrics are available for all of your {{% names/dedicated-gen-3 %}} environments. ![A screenshot of what the metrics dashboard displays for {{% names/dedicated-gen-3 %}} environments](/images/metrics/all-dedicated-gen3.png "0.45") diff --git a/sites/platform/src/increase-observability/metrics/dedicated.md b/sites/platform/src/increase-observability/metrics/dedicated.md index c2fc9218c5..10e89f8d48 100644 --- a/sites/platform/src/increase-observability/metrics/dedicated.md +++ b/sites/platform/src/increase-observability/metrics/dedicated.md @@ -88,7 +88,7 @@ The upper limit in the graph is 3.62 GB because 0.38 GB of memory are ### Disk Disk represents the plan space for all services and mounts, -which for {{% names/dedicated-gen-2 %}} production environments is [50 GB](../../dedicated-gen-2/architecture/_index.md). +which for {{% names/dedicated-gen-2 %}} production environments is [50 GB](/dedicated-environments/dedicated-gen-2/overview.md). This example has the following persistent disk space configured: diff --git a/sites/platform/src/languages/php/_index.md b/sites/platform/src/languages/php/_index.md index d1fbfdb70b..6a03917b99 100644 --- a/sites/platform/src/languages/php/_index.md +++ b/sites/platform/src/languages/php/_index.md @@ -360,7 +360,7 @@ To see the settings used on your environment: ### Customize PHP settings -For {{% names/dedicated-gen-2 %}}, see the [configuration options](../../dedicated-gen-2/overview/grid.md#configuration-options). +For {{% names/dedicated-gen-2 %}}, see the [configuration options](/dedicated-environments/dedicated-gen-2/development). You can customize PHP values for your app in two ways. The recommended method is to use variables. diff --git a/sites/platform/src/languages/php/extensions.md b/sites/platform/src/languages/php/extensions.md index 739d527e63..6036de3748 100644 --- a/sites/platform/src/languages/php/extensions.md +++ b/sites/platform/src/languages/php/extensions.md @@ -11,8 +11,9 @@ Some of them are available for {{% vendor/name %}} containers. {{< note version="1" theme="warning" title="Warning" >}} + The information on this page applies to Grid and {{% names/dedicated-gen-3 %}} plans. -See also [PHP extensions on {{% names/dedicated-gen-2 %}} plans](../../dedicated-gen-2/overview/grid.md#extensions). +See also [PHP extensions on {{% names/dedicated-gen-2 %}} plans](/dedicated-environments/dedicated-gen-2/development.md). {{< /note >}} diff --git a/sites/platform/src/learn/overview/structure.md b/sites/platform/src/learn/overview/structure.md index fbec81f56a..f4e8cb86dc 100644 --- a/sites/platform/src/learn/overview/structure.md +++ b/sites/platform/src/learn/overview/structure.md @@ -7,10 +7,10 @@ description: "Learn about how your {{% vendor/name %}} environments are structur {{< note >}} This page describes how things work on Grid projects. -[{{% names/dedicated-gen-3 %}}](/dedicated-gen-3/_index.md) projects are similar, +[{{% names/dedicated-gen-3 %}}](/dedicated-environments/dedicated-gen-3/_index.md) projects are similar, but they run on dedicated hosts and each container is replicated three times. -For {{% names/dedicated-gen-2 %}} projects, read about how [{{% names/dedicated-gen-2 %}} projects are structured](/dedicated-gen-2/overview/_index.md). +For {{% names/dedicated-gen-2 %}} projects, read about how [{{% names/dedicated-gen-2 %}} projects are structured](/dedicated-environments/dedicated-gen-2/overview.md). {{< /note >}} diff --git a/sites/platform/src/security/data-retention.md b/sites/platform/src/security/data-retention.md index 9058189a5a..cc5cd58537 100644 --- a/sites/platform/src/security/data-retention.md +++ b/sites/platform/src/security/data-retention.md @@ -94,7 +94,7 @@ Backups for {{% names/dedicated-gen-2 %}} environments are retained based on whe | Weeks 8--12 | One bi-weekly backup | | Weeks 12--22 | One backup per month | -See more about [backups of {{% names/dedicated-gen-2 %}} environments](../dedicated-gen-2/overview/backups.md). +See more about [backups of {{% names/dedicated-gen-2 %}} environments](/dedicated-environments/dedicated-gen-2/environment-differences.md#backups). ## Tombstone backups diff --git a/sites/platform/static/images/dedicated/cluster-infrastructure.svg b/sites/platform/static/images/dedicated/cluster-infrastructure.svg new file mode 100644 index 0000000000..56efab5058 --- /dev/null +++ b/sites/platform/static/images/dedicated/cluster-infrastructure.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/sites/platform/static/images/dedicated/dedicated-architecture.svg b/sites/platform/static/images/dedicated/dedicated-architecture.svg new file mode 100644 index 0000000000..8168fc2fb7 --- /dev/null +++ b/sites/platform/static/images/dedicated/dedicated-architecture.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/sites/platform/static/images/dedicated/grid-architecture.svg b/sites/platform/static/images/dedicated/grid-architecture.svg new file mode 100644 index 0000000000..887f2564a4 --- /dev/null +++ b/sites/platform/static/images/dedicated/grid-architecture.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/sites/platform/static/images/dedicated/http-cluster.svg b/sites/platform/static/images/dedicated/http-cluster.svg new file mode 100644 index 0000000000..3ed5831e3d --- /dev/null +++ b/sites/platform/static/images/dedicated/http-cluster.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/sites/platform/static/images/dedicated/split-architecture.svg b/sites/platform/static/images/dedicated/split-architecture.svg new file mode 100644 index 0000000000..7ec6089de1 --- /dev/null +++ b/sites/platform/static/images/dedicated/split-architecture.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/sites/platform/static/images/dedicated/ssh-cluster.svg b/sites/platform/static/images/dedicated/ssh-cluster.svg new file mode 100644 index 0000000000..342f6d9d53 --- /dev/null +++ b/sites/platform/static/images/dedicated/ssh-cluster.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/themes/psh-docs/layouts/partials/editpagebutton.html b/themes/psh-docs/layouts/partials/editpagebutton.html index 46d348a02a..4c3d8987b7 100644 --- a/themes/psh-docs/layouts/partials/editpagebutton.html +++ b/themes/psh-docs/layouts/partials/editpagebutton.html @@ -1,6 +1,6 @@
- {{ $editLocation := printf "%sedit/main/%s/src/%s" site.Params.repo site.Params.folder .File.Path}} + {{ $editLocation := printf "%sedit/main/%s/src/%s" site.Params.repo site.Params.folder .File.Path }} Edit page diff --git a/themes/psh-docs/layouts/shortcodes/names/dedicated-environments.html b/themes/psh-docs/layouts/shortcodes/names/dedicated-environments.html new file mode 100644 index 0000000000..a68a6246eb --- /dev/null +++ b/themes/psh-docs/layouts/shortcodes/names/dedicated-environments.html @@ -0,0 +1 @@ +Dedicated Environments \ No newline at end of file