Cloud Platform FAQ

What is the exact formula for Cloud Capacity Unit calculations?

The current formula utilized for these calculations is:

  • 4GB Memory = 1 CCU
  • 2 CPU Cores = 1 CCU

Additional formulas will be added over time as new technologies are added to the Acquia Cloud Platform.

Do Cloud Capacity Units impact how I will be billed?

For subscribers with server-based subscriptions, Cloud Capacity Units are informational only, unless your environments have been upgraded to Acquia Cloud Next, which is powered by serverless technologies. Subscriptions which exceed the total Cloud Capacity Unit equivalent of contracted infrastructure capacity may be subject to additional fees if the elevated utilization recurs or persists.

For subscribers with subscriptions that leverage Acquia’s Views and Visits model, Cloud Capacity Units are a component of Resource Limits. Subscriptions that exceed the Resource Limits guidelines associated with your contracted Views and Visits capacity may be subject to additional fees if the elevated utilization recurs or persists.

What benefits do I get from Cloud Capacity Units?

Once Cloud Capacity Units become the primary resource tracking metric for a subscription, they will provide a number of benefits to Cloud Platform subscribers.

  • CCUs eliminate the need for subscribers with server-based pricing to choose CPU-optimized or memory-optimized infrastructure, as the platform will allocate either CPU or Memory to applications as needed and track utilization as a single metric.
  • CCUs on Acquia Cloud Next environments are tracked per-environment, providing more granular utilization data than current per-server metrics. For Cloud Platform environments that have not yet been upgraded to Acquia Cloud Next, however, they will continue to be tracked per-server.
  • CCUs provide more granular data per-service than server-based metrics. As new technologies are released on Acquia Cloud, subscribers will gain insights into utilization from the following isolated services: load balancing, PHP, SSH, cron, Cloud hooks, file system, and database.

Do Cloud Capacity Units include Storage Utilization?

At this time, CCUs do not include storage utilization, which is tracked separately on the Acquia Cloud Platform.

How do Cloud Capacity Units impact Acquia’s Views/Visits (Acquia Cloud) or Dynamic Request (Site Factory) models?

At this time, CCUs will only be used for diagnostic purposes for subscribers on these pricing models.

What should I do if my CCUs spike or drop unexpectedly?

Since CCUs can serve as an indicator of an application’s health or performance, you should attempt to correlate unexpected spikes or drops in Cloud Capacity Units with development activities such as code changes, site configuration changes, and environment configuration changes, or with changes in traffic. While modest spikes in CCUs should be expected during mid-day traffic peaks or whenever cron runs, unexpected spikes that jump too high and occur too often could be indicative of a caching or configuration problem that could lead to a temporary resource limit being imposed on your environment by Acquia. In the unlikely event that this happens, contact Acquia Support for assistance.

Platform Email is enabled for my account. However, emails are sent through the legacy email service. Why is that so?

To ensure that emails are sent through Platform Email, you must update your settings.php file. For more information, see Acquia require line.

What are the flags supported by Platform Email for the Sendmail command?

Platform Email supports the following flags for the Sendmail command:

f, i, r, s, t, F

Note that Platform Email does not support bs.

Acquia Cloud Next FAQs

On Wednesday, 24 March 2021, Acquia will begin upgrading customer applications to Acquia Cloud Next. Acquia Cloud Next technologies provide better performance, scalability, and resiliency during high load. Powered by advanced serverless architecture, Acquia Cloud Next ensures applications can scale faster to satisfy the demands of high traffic events and resource intensive processes.

For more information on Acquia Cloud Next and to learn how it differs from Acquia Cloud Classic, see Acquia Cloud Next.

How does infrastructure upsizing and downsizing work in Acquia Cloud Next?

Acquia Cloud Next is powered by Kubernetes-managed clusters and advanced file system and database management technologies that leverage pooled resources across hundreds of containerized and virtually isolated environments. This architecture allows non-production environments to run in a high-availability configuration by default. Also, it allows production environments to leverage the full capacity of an entire regional cluster, if necessary, to respond to spikes in traffic or other forms of high resource utilization.

On Acquia Cloud Next, non-production environments are permitted to scale up to a predefined point before additional resources stop getting allocated. Acquia Support can raise this limit on a case-by-case basis for customers who haven’t exceeded their Resource Limits or contractual Cloud Capacity Unit thresholds.

Production environments are also permitted to scale up to a predefined point above the expected amount of cloud capacity, required to satisfy the level of traffic, associated with a given subscription. However, in the unlikely event that any Production environment nears that threshold, Acquia Support will step in to audit the activity on your account and determine if additional auto-scaling can be permitted or if some form of intervention is required to reduce utilization back to normal levels. For example, if your site is under attack or inadvertently consumes more resources than expected.

Once a spike in resource utilization subsides, all environments on Acquia Cloud Next automatically reduce the amount of dedicated capacity to make it available to the regional pool once more.

Could the dynamic auto-scaling on Acquia Cloud Next result in overage fees?

The dynamic auto-scaling functionality in Acquia Cloud Next provides flexibility and almost limitless growth when extra cloud capacity is required.

For customers on Acquia’s Views/Visits pricing model, Acquia reaches out only if:

  • the aggregate resource utilization across all applications and environments exceeds the Resource Limits guidelines published in Acquia’s Products & Services Guide for a period lasting longer than eight hours.
  • recurring spikes above thresholds are observed on a routine basis over the course of two or more weeks.

In either case, overage fees will be assessed starting from the date of initial notification by Acquia.

For customers on Acquia’s legacy infrastructure-based pricing model, Acquia doesn’t notify you about transient Cloud Capacity Unit spikes that exceed your contractual capacity limits. Such spikes must be rare and shouldn’t exceed three hours in duration. However, recurring or excessive spikes in resource utilization above your contractual capacity limits may result in:

  • overage fees
  • requirement that you upgrade your subscription to an appropriate package using Acquia’s Views/Visits pricing model.

In either case, overage fees will be assessed starting from the date of initial notification by Acquia. However, fees may be waived in the event of a subscription upgrade.

Can I limit or manually trigger scaling on my Acquia Cloud Next environments?

Environments running on Acquia Cloud Next dynamically scale to meet active demand. Hence, they can’t be scaled manually, even upon request. Acquia will provide the ability to limit scaling per-environment in a later release.

Can I run my applications on a dedicated (non-pooled) version of Acquia Cloud Next?

Acquia Cloud Next leverages pooled capacity to ensure every production environment can utilize as much capacity as it needs and when it needs it. It was also designed with security and compliance in mind, and leverages an architecture that virtually eliminates the need for permanently dedicated capacity to properly protect an environment.

Hence, Acquia Cloud Next is currently only available in a pooled configuration. More information about dedicated capacity configurations will be available later this year.

Should I still notify Acquia in advance of high traffic events on my site? Should my sites still get upsized proactively?

As an Acquia Cloud Platform customer, you are always advised to contact Acquia Support before any high traffic event occurs. This information ensures that Acquia’s on-call teams know about the possibility of a spike in legitimate traffic on an environment. This also gives Acquia the context needed to provide assistance, if required.

Environments running on the Acquia Cloud Next technologies don’t require proactive capacity increases as such environments dynamically scale as needed. However, Acquia teams may adjust some settings in anticipation of increased traffic to ensure optimal performance throughout the event.

If Acquia Cloud Next leverages Kubernetes and containers, can I download and run a local image or provide my own custom builds for Acquia to run?

At this time, Acquia can neither provide build scripts and images for the Acquia Cloud Next containers nor run container images and build scripts provided by customers. To get this functionality added to the Acquia Cloud Platform roadmap, contact your Acquia account team.

How are Atomic code updates different from traditional code deployments?

On the Acquia Cloud Classic infrastructure, code deployments involves a multi-step process:

  1. Once you trigger code deployment, the Cloud Classic web infrastructure performs a [git pull] operation to pull the new code to a hidden repository folder.
  2. Once that process is complete, the Cloud Classic web infrastructure syncs the changes to the active directory for your docroot.

This process, while typically fast, can result in inconsistent code deployments across multiple web nodes.

In contrast, modern deployment methodologies advocate for atomic updates, a concept Acquia has implemented Acquia Cloud Next with the following sequence:

  1. Once you trigger code deployment, the Acquia Cloud Next application layer automatically provisions new pods and containers, and deploys your code and environment settings.
  2. Once the pod is healthy, traffic is diverted from your old Drupal pods to your new Drupal pods and post-code-deploy Cloud Hooks are triggered.
  3. Once traffic stops routing to your old pods, they will shut down.

This process not only allows for clean and consistent updates to your environment but also ensures that your environments constantly run on fresh and healthy pods.

How is Memcached architected differently on Acquia Cloud Next?

On the Acquia Cloud Classic infrastructure, Memcached was typically configured to run across all available web nodes with 64 MB of memory allocated to each infrastructure. This isolated a relatively small amount of system memory, pulling it away from PHP, cron, and other application-layer services for the exclusive use of Memcached.

Some customers on the Acquia Cloud Classic infrastructure also invested in dedicated Memcache capacity, where some infrastructure was set aside for the exclusive use of Memcached so that two or more nodes could allocate nearly all of their available memory to Memcache. This configuration was typically only available to top-tier accounts and for production environments.

On Acquia Cloud Next, Memcached is rearchitected to run in a high-availability configuration on both production and non-production environments. This not only results in improved performance on non-production environments but also expands access to a more performant Memcached configuration to all customers by default.

For environments running on Acquia Cloud Next, Drupal pods connect to Memcached pods through a relay point running mcrouter for improved performance and resiliency. Owing to this optimization, the [mcstat] command won’t function during SSH sessions and the Memcache module. After using SSH to access an environment, use acquia-memcache stats to access Memcached data.

The Acquia Cloud Platform team is actively researching potential mid-term solutions to both limitations to improve customer visibility into the health and performance of Memcached on your environments.

How does logging behave differently on Acquia Cloud Next?

On Acquia’s Cloud Classic infrastructure, you have access to the /var/log/sites directory to view environment log data and store custom logs. On average, these logs remain available for weeks or months at a time, but would be lost whenever infrastructure was relaunched during maintenance events, sometimes limiting the historical data available.

Since Acquia Cloud Next leverages ephemeral containers and pods, the same methodology is not available for upgraded environments. Hence, you must configure your custom logs to be stored in an alternative location: /shared/logs. Hence, you must access historical logs for your environments using an alternative method such as Acquia CLI.

For this reason, Acquia has updated the Download Logs functionality in the Acquia Cloud Platform user interface and Cloud API v2. Prior to this update, you could only download logs for the current day. However, with this update, you can select a day or time period over the past 30 days. You can download logs up to 24 hours. This enhancement not only makes log access easier but also ensures that your logs persist even after maintenance events.

How do Cron, SSH, and Cloud Hooks behave differently on Acquia Cloud Next?

On the Acquia Cloud Classic infrastructure, cron jobs, SSH, and Cloud Hooks run on the same infrastructure. Hence, they might compete with other processes, such as PHP or MySQL for system resources. You can also ssh directly to a specific web node and purchase dedicated cron capacity to ensure that a single node was always available and isolated for the sole use of frequent or resource-intensive cron processes.

On Acquia Cloud Next, the existing Acquia Cloud Classic functionality is enhanced. By default, all production and non-production environments have access to isolated cron, SSH, and Cloud Hooks pods that run only when needed and shut down whenever they are not. Thus, your environments are more efficient by default and utilize fewer Cloud Capacity Units when idle because excess pods aren’t left running. Additionally, cron, SSH, and Cloud Hook activity can’t interfere with Drupal, Memcached, or MySQL activity by competing for resources.

On Acquia Cloud Next, long running or stuck processes, such as processes running cron or Cloud Hooks, can’t be terminated manually. Contact Acquia Support for assistance if this happens in one of your environments.

Environments upgraded to Acquia Cloud Next may require adjustments to scripts, cron jobs, and other automations due to the updated location of several file directories. For more information, see Working with files.