Cloud Platform
Disk Storage on Cloud Classic
This page explains how environments on the Cloud Classic infrastructure allocate and use the disk storage. This page also describes how to determine the amount of storage that is in use by your application.
You can review your disk storage utilization from the command line by connecting to your Cloud Classic environment using SSH.
Cloud Platformdf -hThe output will appear similar to the following:
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 9.9G 4.4G 5.4G 45% /
udev 3.7G 12K 3.7G 1% /dev
tmpfs 723M 328K 723M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 3.6G 0 3.6G 0% /run/shm
/dev/xvdb 30G 823M 28G 3% /mnt
/dev/xvdn 25G 2.6G 23G 11% /vol/backup-ebs
/dev/xvdm 25G 2.4G 23G 10% /vol/ebs1
/dev/xvdo 25G 2.6G 23G 11% /mnt/brick1144138Cloud Classic Enterprise and Cloud Classic Professional use different filesystems, as described in the following table:
| Partition | Mount | Cloud Classic Enterprise function | Cloud Classic Professional function |
|---|---|---|---|
/dev/xvdm | /vol/ebs1 | database | database and static files |
/dev/xvdn | /vol/backup-ebs | backups | backups |
/dev/xvdo | /mnt/gfs | Distributed file system (static files) | not used |
From the previous disk storage usage example on this page, the following devices are of primary interest:
/dev/xvda1/dev/xvdbThese storage devices are provided with your Cloud Classic infrastructure itself. They are both local to the infrastructure, and have the quickest access. These devices are essentially disposable (also known as ephemeral storage).
The root directory is mounted on /dev/xvda1, is 10 GB in size, and houses the operating system and basic functions. The entire content of this directory can be recreated from files in the Cloud Classic environment if the infrastructure needs to be discarded or relaunched.
The /mnt directory is mounted on /dev/xvdb, and is the infrastructure’s remaining ephemeral disk space. The content in this location is either something you can install using automation (for example, a copy of your Drupal code that actually runs under Apache) or is considered disposable (such as logs or other temporary files).
The distributed file system uses a physical disk where the files are stored. In the disk storage usage example, that partition is /dev/xvdo. These partitions are called bricks. The file system uses one or more bricks to ensure that any changes propagate to all defined bricks. This defines high availability by having a pair of EBS volumes that stay in sync.
For example, even though the example application has one brick on ded-12345 and another on ded-67890, all read and write operations use the file infrastructure based in /mnt/gfs.
The MySQL database has a separate volume in the disk storage usage example: /dev/xvdm. MySQL is normally run from /var/lib/mysql. In the example application, the following symlink exists to that volume:
lrwxrwxrwx 1 mysql mysql 15 May 9 23:09 mysql -> /vol/ebs1/mysqlThe infrastructure in the pair of ded-, fsdb-, and dbmaster-* for Production have this design. However, Drupal only knows about an infrastructure, which is the location for reading and writing to the database. MySQL replicates the data from active to passive (for example, from ded-12345 to ded-67890) using normal binlog processes, which keep the databases synchronized. When ded-12345 is unavailable, Cloud Classic environments will fail over (by changing a settings file) to the other infrastructure, and then inform Drupal to instead use ded-67890. This function provides high availability services for the database, ensuring website uptime while the secondary infrastructure is returned to service.
For more information about binlogs, see Binlogs.
Cloud Classic environments use synchronized copies with MySQL infrastructure, so your application is well-protected from adverse situations. However, catastrophic failures or other emergencies can occur, which is why taking a backup of your applications regularly is highly recommended.
Cloud Classic environments take snapshots every hour and save them to /dev/xvdn. These snapshots are generally needed only if both file system bricks fail. Database dumps are also stored here.
To learn about how often backups occur on Cloud Classic environments and how to create your own, see Taking backups.
The database in the disk storage usage example has 25 GB to store the data, binlogs, and any other files associated with the usual /var/lib/mysql directory. If necessary, during a maintenance window, that volume can be replaced with any size up to a maximum of 1 TB.
The file system volume is separate and is set to 25 GB. The maximum size the file system volume can be raised to 1 TB.
For more information about examining your file system, see Assessing disk space usage.
Acquia’s infrastructure monitoring warns when the database, file, or ephemeral disks reach 95% of the capacity. It also warns again at 100% of the capacity. When this event occurs, Acquia creates proactive critical priority tickets. Acquia will attempt to safely reduce disk space usage to prevent a system outage by moving the oldest database backups to the /mnt/tmp directory.
If this content did not answer your questions, try searching or contacting our support team for further assistance.
From the previous disk storage usage example on this page, the following devices are of primary interest:
/dev/xvda1/dev/xvdbThese storage devices are provided with your Cloud Classic infrastructure itself. They are both local to the infrastructure, and have the quickest access. These devices are essentially disposable (also known as ephemeral storage).
The root directory is mounted on /dev/xvda1, is 10 GB in size, and houses the operating system and basic functions. The entire content of this directory can be recreated from files in the Cloud Classic environment if the infrastructure needs to be discarded or relaunched.
The /mnt directory is mounted on /dev/xvdb, and is the infrastructure’s remaining ephemeral disk space. The content in this location is either something you can install using automation (for example, a copy of your Drupal code that actually runs under Apache) or is considered disposable (such as logs or other temporary files).
The distributed file system uses a physical disk where the files are stored. In the disk storage usage example, that partition is /dev/xvdo. These partitions are called bricks. The file system uses one or more bricks to ensure that any changes propagate to all defined bricks. This defines high availability by having a pair of EBS volumes that stay in sync.
For example, even though the example application has one brick on ded-12345 and another on ded-67890, all read and write operations use the file infrastructure based in /mnt/gfs.
The MySQL database has a separate volume in the disk storage usage example: /dev/xvdm. MySQL is normally run from /var/lib/mysql. In the example application, the following symlink exists to that volume:
lrwxrwxrwx 1 mysql mysql 15 May 9 23:09 mysql -> /vol/ebs1/mysqlThe infrastructure in the pair of ded-, fsdb-, and dbmaster-* for Production have this design. However, Drupal only knows about an infrastructure, which is the location for reading and writing to the database. MySQL replicates the data from active to passive (for example, from ded-12345 to ded-67890) using normal binlog processes, which keep the databases synchronized. When ded-12345 is unavailable, Cloud Classic environments will fail over (by changing a settings file) to the other infrastructure, and then inform Drupal to instead use ded-67890. This function provides high availability services for the database, ensuring website uptime while the secondary infrastructure is returned to service.
For more information about binlogs, see Binlogs.
Cloud Classic environments use synchronized copies with MySQL infrastructure, so your application is well-protected from adverse situations. However, catastrophic failures or other emergencies can occur, which is why taking a backup of your applications regularly is highly recommended.
Cloud Classic environments take snapshots every hour and save them to /dev/xvdn. These snapshots are generally needed only if both file system bricks fail. Database dumps are also stored here.
To learn about how often backups occur on Cloud Classic environments and how to create your own, see Taking backups.
The database in the disk storage usage example has 25 GB to store the data, binlogs, and any other files associated with the usual /var/lib/mysql directory. If necessary, during a maintenance window, that volume can be replaced with any size up to a maximum of 1 TB.
The file system volume is separate and is set to 25 GB. The maximum size the file system volume can be raised to 1 TB.
For more information about examining your file system, see Assessing disk space usage.
Acquia’s infrastructure monitoring warns when the database, file, or ephemeral disks reach 95% of the capacity. It also warns again at 100% of the capacity. When this event occurs, Acquia creates proactive critical priority tickets. Acquia will attempt to safely reduce disk space usage to prevent a system outage by moving the oldest database backups to the /mnt/tmp directory.
If this content did not answer your questions, try searching or contacting our support team for further assistance.