| Description of Requirements (continued)
Manageability
Overview
If management policies can be
communicated to the device so that it can act independently to execute them, the result
will be not only less human intervention required but also tighter and more timely
control.
Consider the case of weekly backup.
Systems are usually backed up during an idle period on weekends, so that the system
availability is not interrupted during the business week. This also produces a backup that
is guaranteed to be consistent. This window has been gradually shrinking at the same time
system capacities have been exploding. It has become an almost impossible problem trying
to find time to interrupt a system long enough to backup possibly terabytes of data.
By taking action on an object based on
attributes assigned to it, the OOD could inform a backup function whenever an object has
reached the correct state for its backup to be taken. The backup of all files could be
spread over a longer period – during which others are still being updated –
without affecting data integrity.
Other attributes that could invoke
action by the OOD include encryption, compression, versioning, parity redundancy and HSM
style migration. In each of these, the device would only have to be informed of the policy
with respect to a specific object or set of objects. It could then perform the function
itself or inform an agent designated to provide that service.
Compression and encryption could be
done right on the drive, so that only the fact that one is required for an object need be
communicated to the device. For a management function that must go off the drive, such as
HSM, not only the policy is needed but also the identification of an agent to perform the
function.
To make this most efficient, it will
probably be necessary for there to be associations established among objects, so that
those with the same attributes or with dependencies can be identified. Consider a database
consisting of six files, none of which can be backed up until either all have been closed
or until one designated as the object on which all of the others are dependent has been
closed. A File Server may be needed to manage this kind of relationship between Objects.
In addition, it will be necessary to
establish inter-device dependencies, as in the case of a RAID parity set. By making it
possible to establish groups in which one device makes certain that the rest of the group
has the same essential properties, management of the group will be more efficient and
effective.
Manageability Operations
Export Object
The EXPORT function will be needed for
the device to support storage self-management and attributes-based management. It will
enable the device to take action based on rules expressed in attributes associated with a
given object. It could be used to initiate a backup or support versioning of objects to
other devices.
This function will copy an object to
another device by issuing an OPEN-CREATE, WRITEs and a CLOSE to that device, transferring
the object.
The needed information includes:
- Permission information
- Object identifier
- Options
- Target Device ID
- Target Partition ID
The information returned includes:
- Status of request
- New Object ID
Get Object Attributes
The function retrieves for the
specified objects the information on permissions, etc. It is also used to interrogate
device wide policies. It should be possible to retrieve attributes for multiple Objects
with a single GET OBJECT ATTRIBUTE operation. For instance, a single request could return
the Device Object and all Partition Object Attributes.
The needed information includes:
- Permission information
- Object ID or ID list
- Options
The information returned includes:
- Status of request
- Attributes of Object
Set Object Attributes
The function sets permissions, etc. for
a specified Object.
The needed information includes:
- Permission information
- Object ID
- Options
The information returned includes:
- Status of request
- Attributes of Object
Device Lock Operations
Object locks could be supported at the
block, object, partition and device levels. The LOCK mechanism provides for inter-server
access resolution. These can be used for scheduling concurrent updates as well as
prohibiting access during maintenance functions. Though these are really just instances of
the READ ATTRIBUTE and SET ATTRIBUTE operations, more detail is provided as they are
critical to the sharing of data among a cluster of Requesters.
Read Lock
Attribute
This function will inspect the Object
to see if a particular LOCK is set.
The needed information includes:
- Permission information
- Object, Partition or Device identifier
- Lock parameters
- Options
The information returned includes:
- Status of request
- ID of Requester owning lock
Set Lock Attribute
This function will attempt to
automatically inspect a lock and – if it is not set – set it with the
Requester's ID. This function can also be used to UNLOCK.
The needed information includes:
- Permission information
- Object, Partition or Device identifier
- Lock parameters
- Options
The information returned includes:
- Status of request
- ID of server owning lock
Reset Lock
Attribute
This function will be used to reset a
LOCK in the event a server owning a LOCK no longer is functioning.
The needed information includes:
- Permission information
- Object, Partition or Device identifier
- Lock parameters
- Options
The information returned includes:
- Status of request
- ID of server owning lock
Get, Set Device
Associations
These functions define or interrogate
relationships among devices. This is necessary for inter-device communications. (A
possible implementation would be one of the devices being identified as the
"master" or first of set, with the others being dependent members of the set.
The first of set would be responsible for disseminating to the other members changes in
set attributes. Other members would reject attribute settings if they were not from the
first of set.)
If storage is to be as much as possible
self-managed, it must be possible for the device to perform a self-inspection. This must
extend to its membership in a larger device group.
The needed information includes:
- Permission information
- Options
- List of members and attributes
Information returned includes:
|
