mirror of https://github.com/tLDP/LDP
338 lines
15 KiB
XML
338 lines
15 KiB
XML
<chapter id="intro"><title>What is EVMS?</title>
|
|
|
|
<para>EVMS brings a new model of volume management to Linux®.
|
|
EVMS integrates all aspects of volume management,
|
|
such as disk partitioning, Linux logical volume manager (LVM) and
|
|
multi-disk (MD) management, OS2 and AIX volume managers, and
|
|
file system operations into a single
|
|
cohesive package.
|
|
With EVMS, various volume management technologies are accessible through
|
|
one interface, and new technologies can be added as plug-ins as they are developed.</para>
|
|
|
|
<sect1 id="cando"><title>Why choose EVMS?</title>
|
|
<para>EVMS lets you manage storage space in a way that is more
|
|
intuitive and flexible than many other Linux volume management systems.
|
|
Practical tasks, such as migrating disks or adding new disks to your
|
|
Linux system, become more manageable with EVMS because EVMS can
|
|
recognize and read from different volume types and file systems.
|
|
EVMS provides additional safety controls by not allowing commands that are
|
|
unsafe.
|
|
These controls help maintain the integrity of the data stored on the system.</para>
|
|
|
|
<para>You can use EVMS to create and manage data storage.
|
|
With EVMS, you can use multiple volume management technologies under one
|
|
framework while ensuring your system still interacts correctly with
|
|
stored data.
|
|
With EVMS, you are can use bad block relocation, shrink and expand volumes,
|
|
create snapshots of your volumes, and set up RAID
|
|
(redundant array of independent devices) features for your system.
|
|
You can also use many types of file systems and manipulate these storage pieces
|
|
in ways that best meet the needs of your particular work environment.</para>
|
|
|
|
<para>EVMS also provides the capability to manage data on storage that is
|
|
physically shared by nodes in a cluster. This shared storage allows data to
|
|
be highly available from different nodes in the cluster.</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="uis"><title>The EVMS user interfaces</title>
|
|
|
|
<para>There are currently three user interfaces available for EVMS: graphical (GUI), text mode (Ncurses), and the Command Line Interpreter (CLI).
|
|
Additionally, you can use the EVMS Application Programming Interface to implement your own customized user interface. </para>
|
|
<para><xref linkend="userinterf"></xref> tells more about each of the EVMS user interfaces.
|
|
|
|
</para>
|
|
<table id="userinterf" frame="all"><title>EVMS user interfaces</title>
|
|
<tgroup cols="4"><colspec colnum="1" colwidth="1in"></colspec><colspec colnum="2" colwidth="1.5in"></colspec><colspec colnum="3" colwidth="1in"></colspec><colspec colnum="4" colwidth="2.5in"></colspec>
|
|
<thead><row><entry>User interface</entry>
|
|
<entry>Typical user</entry>
|
|
<entry>Types of use</entry>
|
|
<entry>Function</entry></row></thead>
|
|
<tbody><row><entry>GUI</entry>
|
|
<entry>All</entry>
|
|
<entry>All uses except automation</entry>
|
|
<entry>Allows you to choose from available options only, instead of having to sort through all the options, including ones that are not available at that point in the process. </entry></row>
|
|
<row><entry>Ncurses</entry>
|
|
<entry>Users who don't have GTK libraries or X Window Systems on their machines</entry>
|
|
<entry>All uses except automation</entry>
|
|
<entry>Allows you to choose from available options only, instead of having to sort through all the options, including ones that are not available at that point in the process. </entry></row>
|
|
<row><entry>Command Line</entry>
|
|
<entry>Expert</entry>
|
|
<entry>All uses</entry>
|
|
<entry>Allows easy automation of tasks</entry></row>
|
|
</tbody></tgroup>
|
|
</table>
|
|
</sect1>
|
|
|
|
<sect1 id="terminology">
|
|
<title>EVMS terminology</title>
|
|
<para>To avoid confusion with other terms that describe volume
|
|
management in general, EVMS uses a specific set of terms.
|
|
These terms are listed, from most fundamental to most comprehensive,
|
|
as follows:
|
|
</para>
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry><term>Logical disk</term>
|
|
<listitem><para>Representation of anything EVMS can access as a physical disk.
|
|
In EVMS, physical disks are logical disks.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term>Sector</term>
|
|
<listitem><para>The lowest level of addressability on a block
|
|
device. This definition is in keeping with the standard
|
|
meaning found in other management systems.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term>Disk segment</term>
|
|
<listitem><para>An ordered set of physically contiguous
|
|
sectors residing on the same storage object.
|
|
The general analogy for a segment is to a traditional disk
|
|
partition, such as DOS or OS/2 ®</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term>Storage region</term>
|
|
<listitem><para>An ordered set of logically contiguous sectors
|
|
that are not necessarily physically contiguous. </para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term>Storage object</term>
|
|
<listitem><para>Any persistent memory structure in EVMS that can be used to
|
|
build objects or create a volume. Storage object is a generic term for disks, segments, regions, and feature objects.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term>Storage container</term>
|
|
<listitem><para>A collection of storage objects. A storage
|
|
container consumes one set of storage objects and produces new
|
|
storage objects. One common subset of storage containers is volume groups,
|
|
such as AIX® or LVM.</para>
|
|
<para>Storage containers can be either of type private or cluster.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term>Cluster storage container</term>
|
|
<listitem><para>Specialized storage containers that consume only disk objects
|
|
that are physically accessible from all nodes of a cluster.</para>
|
|
|
|
<variablelist>
|
|
<varlistentry><term>Private storage container</term>
|
|
<listitem><para>A collection of disks that are physically accessible from all
|
|
nodes of a cluster, managed as a single pool of storage, and owned and accessed
|
|
by a single node of the cluster at any given time.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry><term>Shared storage container</term>
|
|
<listitem><para>A collection of disks that are physically accessible from all
|
|
nodes of a cluster, managed as a single pool of storage, and owned and accessed
|
|
by all nodes of the cluster simultaneously.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term>Deported storage container</term>
|
|
<listitem><para>A shared cluster container that is not owned by any node of the cluster.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
</listitem></varlistentry>
|
|
|
|
<varlistentry><term>Feature object</term>
|
|
<listitem><para>A storage object that contains an EVMS native feature, such as
|
|
bad block relocation. </para>
|
|
<para>An <glossterm>EVMS Native Feature</glossterm> is a function of volume management designed
|
|
and implemented by
|
|
EVMS. These features are not intended to be backward compatible with other
|
|
volume management technologies. </para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term>Logical volume</term>
|
|
<listitem><para>A volume that consumes a storage object and exports
|
|
something mountable. There are two varieties of logical volumes: <glossterm>EVMS Volumes</glossterm>
|
|
and <glossterm>Compatibility volumes</glossterm>.</para>
|
|
<para> <glossterm>EVMS Volumes</glossterm> contain EVMS native metadata and can support all
|
|
EVMS features. <filename>/dev/evms/my_volume</filename> would be an example
|
|
of an EVMS Volume.</para>
|
|
<para><glossterm>Compatibility volumes</glossterm> do not contain any EVMS native metadata.
|
|
Compatibility volumes are backward compatible to their particular scheme, but
|
|
they cannot support EVMS features. <filename>/dev/evms/md/md0</filename> would
|
|
be an example of a compatibility volume. </para></listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</sect1>
|
|
<sect1><title>What makes EVMS so flexible?</title>
|
|
|
|
<para>There are numerous drivers in the Linux kernel, such as Device
|
|
Mapper and MD (software RAID), that implement volume management schemes. EVMS is built
|
|
on top of these drivers to provide one framework for combining and
|
|
accessing the capabilities.</para>
|
|
|
|
<para>The EVMS Engine handles the creation,
|
|
configuration, and management of volumes, segments, and disks.
|
|
The EVMS Engine is a programmatic interface to the EVMS system.
|
|
User interfaces and programs that use EVMS must go through the Engine.</para>
|
|
|
|
<para>EVMS provides the capacity for plug-in modules to the Engine that
|
|
allow EVMS to perform specialized tasks without altering the core code.
|
|
These plug-in modules allow EVMS to be more extensible and customizable than
|
|
other volume management systems.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="LAYERDEF">
|
|
<title>Plug-in layer definitions</title>
|
|
<para>EVMS defines a layered architecture where plug-ins in each layer
|
|
create abstractions of the layer or layers below. EVMS also allows most plug-ins
|
|
to create abstractions of objects within the same layer. The following
|
|
list defines these layers from the bottom up.</para>
|
|
|
|
<variablelist termlength="15">
|
|
<varlistentry><term>Device managers</term>
|
|
<listitem><para>The first (bottom) layer consists
|
|
of device managers.
|
|
These plug-ins communicate with hardware device drivers to
|
|
create the first EVMS objects. Currently, all devices are handled by a single plug-in.
|
|
Future releases of EVMS might need additional device managers
|
|
for network device management (for example, to manage
|
|
disks on a storage area network (SAN)).</para></listitem>
|
|
</varlistentry>
|
|
<varlistentry><term>Segment managers</term>
|
|
<listitem><para>The second layer consists of segment
|
|
managers. These plug-ins
|
|
handle the segmenting, or partitioning,
|
|
of disk drives. The Engine components can replace partitioning
|
|
programs, such as <command>fdisk</command> and
|
|
<application>Disk Druid</application>, and EVMS
|
|
uses Device Mapper to replace the in-kernel disk
|
|
partitioning code.
|
|
Segment managers can also be "stacked," meaning that
|
|
one segment manager
|
|
can take as input the output from another segment
|
|
manager.</para>
|
|
|
|
<para> EVMS provides the following segment managers:
|
|
DOS, GPT, System/390® (S/390), Cluster, and BSD. Other segment manager
|
|
plug-ins can be added to support other
|
|
partitioning schemes.</para></listitem>
|
|
</varlistentry>
|
|
<varlistentry><term>Region managers</term>
|
|
<listitem><para>The third layer consists of region
|
|
managers.
|
|
This layer provides a place for plug-ins that ensure
|
|
compatibility with existing volume management schemes
|
|
in Linux and other operating systems.
|
|
Region managers are intended to model systems that
|
|
provide a logical abstraction above disks
|
|
or partitions.</para>
|
|
|
|
<para>Like segment managers, region managers can
|
|
also be stacked.
|
|
Therefore, the input object(s) to a region manager can
|
|
be disks, segments, or other regions.</para>
|
|
|
|
<para>There are currently four region manager plug-ins in EVMS:
|
|
Linux LVM, AIX, OS/2, and Multi-Disk (MD).
|
|
<variablelist><varlistentry><term>Linux LVM</term>
|
|
<listitem><para>The Linux LVM plug-in provides compatibility with
|
|
the Linux LVM and allows the creation of volume groups
|
|
(known in EVMS as containers) and logical volumes
|
|
(known in EVMS as regions). </para></listitem></varlistentry>
|
|
|
|
<varlistentry><term>AIX LVM</term>
|
|
<listitem><para>The AIX LVM provides compatibility with AIX and is similar in functionality
|
|
to the Linux LVM by also using volume groups and logical
|
|
volumes. </para></listitem></varlistentry>
|
|
|
|
<varlistentry><term>OS/2 LVM</term>
|
|
<listitem><para>The OS/2 plug-in provides compatibility with
|
|
volumes created under
|
|
OS/2. Unlike the Linux and AIX LVMs, the OS/2 LVM
|
|
is based on linear linking of disk partitions, as well as
|
|
bad-block relocation. The OS/2 LVM does not allow for modifications.</para></listitem></varlistentry>
|
|
|
|
<varlistentry><term>MD</term>
|
|
<listitem><para>The Multi-Disk (MD) plug-in for RAID provides
|
|
RAID levels linear, 0, 1, 4, and 5 in
|
|
software. MD is one plug-in that displays as four region
|
|
managers that you can choose from.</para></listitem></varlistentry>
|
|
</variablelist></para></listitem>
|
|
</varlistentry>
|
|
<varlistentry><term>EVMS features</term>
|
|
<listitem><para>The next layer consists of EVMS
|
|
features. This layer is
|
|
where new EVMS-native functionality is implemented. EVMS
|
|
features can be built on any object in the system, including
|
|
disks, segments, regions, or other feature objects.
|
|
All EVMS features share a common type of metadata,
|
|
which makes discovery of feature objects much more
|
|
efficient, and recovery
|
|
of broken features objects much more reliable. There are three
|
|
features currently available in EVMS: drive linking, Bad
|
|
Block Relocation, and snapshotting. </para>
|
|
|
|
<variablelist>
|
|
<varlistentry><term>Drive Linking</term>
|
|
<listitem><para>Drive linking allows any
|
|
number of objects to be linearly concatenated together into a
|
|
single object. A drive linked volume can be expanded by
|
|
adding another storage object to the end or shrunk by removing the last object.</para></listitem></varlistentry>
|
|
|
|
<varlistentry><term>Bad Block Relocation</term>
|
|
<listitem><para>Bad Block Relocation (BBR)
|
|
monitors its I/O path and detects write failures (which can be
|
|
caused by a damaged disk). In the event of such a failure, the
|
|
data from that request is stored in a new location. BBR keeps
|
|
track of this remapping. Additional I/Os to that
|
|
location are redirected to the new location.</para></listitem></varlistentry>
|
|
|
|
<varlistentry><term>Snapshotting</term>
|
|
<listitem><para>The Snapshotting feature provides
|
|
a mechanism for creating a "frozen" copy of a volume at a single
|
|
instant in time, without having to take that volume off-line.
|
|
This is useful for performing backups on a live system.
|
|
Snapshots work with any volume (EVMS or compatibility), and can
|
|
use any other available object as a backing store. After a
|
|
snapshot is created and made into an EVMS volume, writes to the "original" volume cause the
|
|
original contents of that location to be copied to the snapshot's
|
|
storage object. Reads to the snapshot volume look like they
|
|
come from the original at the time the snapshot was created.
|
|
</para></listitem></varlistentry></variablelist>
|
|
|
|
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry><term>File System Interface Modules</term>
|
|
<listitem><para>File System Interface Modules (FSIMs)
|
|
provide coordination with the
|
|
file systems during certain volume management
|
|
operations. For
|
|
instance, when expanding or shrinking a volume,
|
|
the file system
|
|
must also be expanded or shrunk to the appropriate size.
|
|
Ordering in this example is also important;
|
|
a file system cannot
|
|
be expanded before the volume, and a volume cannot
|
|
be shrunk before the file system.
|
|
The FSIMs allow EVMS to ensure this
|
|
coordination and ordering.</para>
|
|
|
|
<para>FSIMs also perform file system
|
|
operations from one of the EVMS user interfaces. For instance,
|
|
a user can make new file systems and check existing file systems
|
|
by interacting with the FSIM.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term>Cluster Manager Interface Modules</term>
|
|
<listitem><para>Cluster Manager Interface Modules, also
|
|
known as the EVMS Clustered Engine (ECE), interface
|
|
with the local cluster manager installed on the system.
|
|
The ECE provides a standardized ECE API to the Engine
|
|
while hiding cluster manager details from the Engine.</para></listitem></varlistentry>
|
|
</variablelist>
|
|
</sect1>
|
|
|
|
</chapter>
|
|
|