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.

Examining your disk storage utilization

You can review your disk storage utilization from the command line by connecting to your Cloud Classic environment using SSH.

df -h

The 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/brick1144138

Filesystem

Cloud Classic Enterprise and Cloud Classic Professional use different filesystems, as described in the following table:

Local storage

From the previous disk storage usage example on this page, the following devices are of primary interest:

• /dev/xvda1
• /dev/xvdb

These 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).

Distributed file system

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.

Database

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/mysql

The 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.

Backups

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.

Storage space

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.

Disk Storage on Cloud Classic

df -h

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/brick1144138

lrwxrwxrwx 1 mysql mysql 15 May  9 23:09 mysql -> /vol/ebs1/mysql