Storage Configuration

A well designed storage system is an essential part of a dependable eBox. It must be suitable for your present needs but also be capable of adapting to future changes. It must be reliable, but also be easily repaired if it breaks. You might want it to defend the system against damage caused by broken upgrades. You might require it to provide a high degree of system availability in order to protect your users against hardware failures.

Choosing the most suitable method of managing your disk storage space is a fundamental stage of building your eBox. It may differ depending upon the principal purpose of your server. For example, a machine which is used predominately for serving user and group shares, such as a PDC, might have different storage needs to one which is mainly used as an email server.

The following examples cover some typical scenarios that might be commonly used. They are provided to assist you in configuring your own eBox to meet your particular requirements.

The Examples

The examples illustrate the architecture of the storage. The creation of each component is covered in the Installation Guide?.

Starting with the simplest, each succeeding example builds upon the previous one as additional features are added. Each starts with a block diagram which shows how the general structure of the storage is built up of layers, in a similar manner to a child stacking building blocks on top of each other.

The uppermost layer shows individual storage spaces where all files are ultimately located. It is recommended that you do not allocate all the space available in this layer. This allows the free space to be used to hold a snapshot of your system state prior to applying an upgrade. The snapshot is used to quickly return your system to the pre-upgrade condition if the upgrade is unsuccessful. See the Safe Upgrade Guide?.

A further reason for having the unallocated space is the ability to grow any or all of the individual storage spaces into the free space while your system is live and the users active. See the Storage Live Volume Resize Guide?.

The second diagram in each example shows a different view of the same storage system. Imagine you are viewing it from directly above. It provides additional details of how it will appear once fully configured. The individual logical volumes, together with their file systems illustrate choices that might be used in a specimen eBox. Your choices may be different to meet the design requirements of your server.

It is usual that the logical volumes root, swap, and var are created with a recommendation that free space is also made available. Other logical volumes are at your discretion.

Example 1

This is the most basic configuration and uses a single hard disk to store both system and data files.

General Structure

Hard Disk Layer:
The machine has one disk installed.

Partitions Layer:
The hard disk is split into two partitions. /boot is located on sda1 and thereby not part of the volume group.

Volume Group Layer:
sda2 hosts ebox which is a 'container' for the individual storage spaces.

Logical Volumes Layer:
ebox hosts a series of Logical Volumes. A file system is placed on each one and files are then written to them in the normal way.

Representative Configuration

A system based on this single disk model is usable in situations where downtime to conduct repairs is acceptable. If the hard disk fails the entire systems is lost. A backup kept on an external device is essential when this configuration is used. It is not recommended in situations where a high degree of availability is needed or where backups are stored locally on the same disk.

Example 2

A second hard disk is added which enables the construction of RAID1 Arrays. Now the files can be mirrored on each disk.

General Structure

Hard Disk Layer:
The machine has two disks installed.

Partitions Layer:
Each hard disk is split into two partitions. /boot is located on sda1 and a copy on sdb1.

RAID1 Layer:
sda1 and sdb1 form the components of md0, a 'boot' array which is not part of the volume group. sda2 and sdb2 form md1, a 'system+data' array.

Volume Group Layer:
md1 hosts ebox which is a 'container' for the individual storage spaces.

Logical Volumes Layer:
ebox hosts a series of Logical Volumes. A file system is placed on each one and files are then written to them in the normal way.

Representative Configuration

A system based on this configuration is robust. If either of the hard disks fail the system is not lost; it continues to function normally using the remaining disk. The downtime needed to replace the failed disk can be scheduled to occur at a time of your choice. This enhanced resilience provides a higher degree of availability and makes the system suitable for the storage of a local backup.

Example 3

A third hard disk is added and used as a 'hot-swap' spare for the RAID1 Arrays.

General Structure

Hard Disk Layer:
The machine has three disks installed. sdc is the spare.

Partitions Layer:
Each hard disk is split into two partitions. /boot is located on sda1 and a copy on sdb1. sdc1 and sdc2 are prepared for use and fulfill a 'standby' role.

RAID1 Layer:
sda1 and sdb1 form the active components of md0, a 'boot' array. sda2 and sdb2 are the active components of md1, a 'system+data' array. sdc1 and sdc2 are the 'standby' components of md0 and md1 respectively.

Volume Group Layer:
md1 hosts ebox which is a 'container' for the individual storage spaces.

Logical Volumes Layer:
ebox hosts a series of Logical Volumes. A file system is placed on each one and files are then written to them in the normal way.

Representative Configuration

A system built using this configuration is not only robust, it also reduces the risk of operating with only a single disk. In the event of a disk failure, the spare is used as a 'hot-swap' replacement for the failed disk and synchronized with the functioning disk. The change is made on a live system without stopping the service to your users.