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.