Table of Contents
Hardware RAID controllers are complex devices: essentially, it’s a computer inside a computer. It has it’s own processor (or may be processors), it usually has it’s own RAM, and, most important, it runs its own software, which is usually a fairly complex operating system that manages physical discs, hides all the RAID magic behind the curtains and allows the host operating system to see only few logical discs.
Unfortunately, most of the RAID controllers are proprietary. It’s a well-known fact that physical discs used on controller A are incompatible with some other controller B (even worse, they can be incompatible between various revisions of firmware of controller A). RAID’s firmware hides all the intricate management of discs from the system administrator. Administrator can control RAID using either:
BIOS OPROM, which is available by pressing some magic key when the computer’s booting.
Some management utilities, running in OS. Such utilities are mostly proprietary, provided by vendors, available in binary-only form.
Einarc project tries to solve such problem: provide a unified, solid interface to manage all possible storage devices.
Einarc unifies various RAIDs and storage devices, providing a simple object interface for end-user. Inside, it works as a proxy, translating commands from that object interface to RAID-specific commands for it’s proprietary CLI, and back, it translates response from proprietary CLI into unified answer.
Support for various RAIDs is implemented as classes. Each class has to implement a couple of methods that would translate requests.
Currently, there are following modules available:
This is not a complete list. To check if your adapter is supported, just
run ./configure
or einarc-install
without options to select all
available modules. There’s a good chance that your adapter would be
supported too.
Currently, Einarc is a sub-project of Inquisitor hardware testing framework and can be downloaded either bundled with Inquisitor itself or from its own mini-homepage. Alternatively, your favourite distributed may provide you with pre-built package.
After downloading, extract the contents of tarball (this would yield a
directory with sources), then run ./configure
. You can use the
following options:
\--target=TARGET
\--bindir=DIR
\--rubysharedir=DIR
\--rubylibdir=DIR
\--einarclibdir=DIR
\--modules=LIST
a comma-separated list of storage support modules to build:
./configure
; requires lspci
to run.
If in doubt, just use "all" — it will download everything, all CLIs not
usable on current machine just won’t be used.
-h
, \--help
After running ./configure
with options, file Makefile.config
would
be created. You can check it out and edit by hand if necessary. Then run
make
to start a build process. In fact, Einarc is written in a script
language and does not need build, but we use the build stage to download
all the proprietary CLIs that would be required to support requested
controllers.
After downloading, unpacking and preparing all required tools, you can
run make install
(usually requires root privileges) to install Einarc
in your system.
Since version 1.4, it’s possible to package and install Einarc as
pre-built binary package (rpm, deb) from major distribution
repositories. Recommended name for a package is einarc
.
After installation of package, all Einarc modules that don’t require
proprietary CLIs are available (so far it’s only software
module to
control Linux software RAIDs), so in most case you’ll still have to
download necessary proprietary CLIs to make Einarc useful. It can be
done automatically on target machine by running einarc-install
. It can
be called with the same --modules
option as in ./configure
:
\--modules=LIST
a comma-separated list of storage support modules to build:
./configure
; requires lspci
to run.
If in doubt, just use "all" — it will download everything, all CLIs not
usable on current machine just won’t be used.
Simplest way to use Einarc is to use command-line interface. Einarc can be invoked using:
einarc [options] <object> <method> <parameters>
Options:
-l
, \--list
-V
, \--version
\--help
-h
, \--human
-t
, \--type=TYPE
-a
, \--adapter=NUM
Refer to object interface description for particular object.
Note that command-line interface is always ready to provide a hint. For example, one can forget almost everything and start with just calling "einarc". Consider this session:
$ einarc Adapter type not specified: use --list to list all adapters and choose one $ einarc --list areca 1 ARC-1160 PCI $ einarc -h -t areca Object not specified; available objects: logical, log, adapter, task, physical
Let’s start with showing all logical drives. We don’t know what method we should choose, but Einarc will give a hint:
$ einarc -h -t areca logical Command not specified; available commands: list, add, delete, clear, get, set $ einarc -h -t areca logical list # RAID level Physical drives Capacity Device State 1 5 0:1,0:2,0:4,0:5,0:8 762939.45 MB normal 2 1+0 0:6,0:7 190734.86 MB normal 3 5 0:9,0:10,0:11,0:12,0:13 1907348.63 MB normal 4 1+0 0:15,0:16 476837.16 MB normal
More complex example: let’s check if a physical drive is hotspare drive
or not. Such simple boolean flag is available as a property of
physical
object, and Einarc will give a hint on how to get it and when
to add a reference to particular physical disc ID:
$ einarc -h -t areca physical Command not specified; available commands: list, get, set $ einarc -h -t areca physical get Object identifier not specified $ einarc -h -t areca physical get 0:1 Property not specified; available properties: hotspare $ einarc -h -t areca physical get 0:1 hotspare 0
Getting a property of adapter is in fact even simpler: there shouldn’t be any IDs. Here we’ll get a list of all RAID levels a particular adapter supports:
$ einarc -h -t areca adapter Command not specified; available commands: info, restart, get, set $ einarc -h -t areca adapter get Property not specified; available properties: raidlevels $ einarc -h -t areca adapter get raidlevels 0 1 1E 10 3 5 6
Einarc’s libraries can be called directly with almost the same object terms as from the command-line interface.
Einarc is written in Ruby and thus can be used easily from this script language. Using Einarc API in your program takes a few simple steps:
Einarc modules should be loaded before use. Adding the following require statement would automatically load all available RAID support modules:
require 'raid/baseraid'
To find out which adapters are available, use:
RAID::BaseRaid.query_adapters
This would return you an array of hashes, one element of array for each adapter found, for example:
[{:driver=>"areca", :version=>"PCI", :num=>1, :model=>"ARC-1160"}]
After adapter object a is created, one can use all the methods described in object interface using a simple convention.
If method does not return anything, it’s just
a.object_method(all, other, arguments, ...)
for example:
a.logical_clear
If method should return its data as Ruby objects (a hash, an array, an array of hashes, etc), then it should be called as
a._object_method(all, other, arguments, ...)
Note the beginning underscore. An example:
a._adapter_info => {"PCI product ID"=>"1160", "System Memory"=>"256MB/333MHz", "Current IP Address"=>"192.168.0.1", "Controller Name"=>"ARC-1160", "BOOT ROM Version"=>"V1.39 2006-1-4 ", "CPU DCache Size"=>"32KB", "Main Processor"=>"500MHz", "Firmware version"=>"V1.39 2006-2-9 ", "PCI vendor ID"=>"17d3", "CPU ICache Size"=>"32KB", "Serial number"=>"XXXXXXXXXXXXXXXX"}
If method should print whatever strings Einarc CLI displays, it should be called as:
a.object_method(all, other, arguments, ...)
For example:
a.adapter_info PCI product ID 1160 System Memory 56MB/333MHz Current IP Address 192.168.10.111 ...
Einarc exposes a relatively simple and straight-forward object model for an end-user.
Every computer (host) may have one or more adapters (object adapter
).
Adapters provide RAID services as logical discs (object logical
) that
are usually seen in OS as individual devnodes. Logical discs may include
one or more physical discs (object physical
). Physical discs are
usually hidden from the OS and are accessible only through proprietary
CLI. Adapters also may keep some history of what events happened in the
past and what objects were involved (object log
). Finally, adapters
being little computers with their own operating system and multi-tasking
may perform separate background tasks, such as building/rebuilding or
checking of the array (object task
).
Each of these objects have a couple of methods described below. Some of
these objects have named properties that can be read using get
and
written using set
. Some of the properties are read-only (only get
would work), some are write-only (only set
would work).
A special function that lists available adapters of current
model. This function is not called directly through object model, but
called indirectly, iterating over all support drivers when performing
an -l
(--list
) command line command to list all available and
supported adapters.
Output is tab-separated strings in format:
Driver | Adapter ID | Adapter model | Adapter serial number / version |
---|---|---|---|
lsi_megarc | 00 | MegaRAID SCSI 320-1 | 40LD/8SPAN |
areca | 01 | ARC-1120 | PCI |
"adapter" is an object related to the controller card. It stores various settings with properties that can be read and wriiten with get and set and can be examined for general info with info command.
Properties:
Gets general information about adapter. Information is returned as key-value pairs. Some keys are fixed and are consistent across all adapters:
Serial number
Firmware version
PCI vendor ID
PCI product ID
PCI subvendor ID
PCI subproduct ID
Other keys are adapter- and implementation-specific and thus vary.
several tab-separated lines in format
Name | Value |
---|---|
Firmware Version | 1L37 |
BIOS Version | G119 |
DRAM | 64MB |
"log" is an object to access adapter’s event log in NVRAM.
Clears event log in NVRAM.
Display full event log in NVRAM.
log entries, one per line, in following tab-separated format:
Entry ID | YYYY-MM-DD | HH:MI:SE | Where it happened | What happened |
---|---|---|---|---|
0 | 2006-12-04 | 14:13:24 | ARC-1120-VOL#00 | Create Volume |
1 | 2006-12-04 | 14:13:24 | Raid Set # 00 | Create RaidSet |
Posts a test message in log. Can be later read back to see that logging works.
"physical" is an object to access physical disc drives attached to
adapter. It’s possible to get list with list
and read and write it’s
properties and settings with get
and set
.
Physical disc address is a:
b, where a is channel number and b is a device number on that channel. Usually, it’s best to assume that it’s a string to pass through.
Properties:
Shows a list of all physical disc drives attached to adapter.
info on one disc drive per line, tab-separated:
Physical disc address | Drive vendor and model | Drive version, revision, firmware, misc info | Drive serial | Drive size | Drive state |
---|---|---|---|---|---|
0:1 | WDC WD800JD-00J | 05.01C05 | WD-WMAM97310565 | 80000 | hotspare |
0:2 | WDC WD1600JB-00EVA0 | 15.05R15 | WD-WMAEK1016963 | 160000 | 0 |
1:7 | WDC WD3200JD-00KLB0 | 08.05J08 | WD-WMAMR1259708 | 320000 | free |
Logical drive is a virtual drive, set up on regions of one or several physical drives. It is referenced with a logical drive ID, a plain integer number.
Properties:
Displays a list of logical drives.
info on one logical drive per line, tab-separated:
Logical drive ID | RAID level | Physical discs included, comma-separated | Capacity (MB) | State |
---|---|---|---|---|
1 | 0 | 0:1 | 80000 | normal |
2 | 5 | 0:2,0:3,0:4 | 10000 | degraded |
3 | passthrough | 0:7 | 73400 | normal |
Creates one or more new logical drives.
5
0:2,0:3,0:4
. By default, use all available physical discs. Various RAID levels place limits on what arrays can be created with a given set of discs. Obviously, passthrough can be created only on one physical disc.
200,3500
. By default, create one logical disc with maximal size. Not applicable while creating passthrough disc.
name=value
, for example stripe=64,cache=readahead
.
Deletes a logical drive.
Deletes all logical drives. Leaves array of free physical discs, ready for creation of new array.
Tasks are processes that are executed in background on an adapter, such as building or checking the logical disc.
Displays a list of tasks.
info on one task per line, tab-separated:
Task ID | Where | What | Progress |
---|---|---|---|
112 | 0 | Bld/Vfy | 0.0% |
113 | 1:1 | Checking | 24.0% |
A special object that deals with adapter-related firmware reading/writing operations.
Extracts a firmware from the adapter into a file.
It’s possible to implement support for the following storage devices in Einarc: