2. COST ACCOUNTING CONCEPTS FOR IS ORGANIZATIONS › 2.7 DASD/DFHSM/SMS Storage Accounting › 2.7.6 System Managed Storage (SMS) Accounting
2.7.6 System Managed Storage (SMS) Accounting
One of the major enhancements incorporated in IBM's z/OS
operating system is the logical implementation of System
Managed Storage (SMS). By design, SMS isolates the end user
from the physical implementation of the storage hierarchy.
Because storage chargeback rates have typically been based
on device type (DASD or tape) and quantity, often expressed
in device-dependent terms (for example, 3380 track-days),
SMS necessitates a major redesign of storage rate structures.
Even more revolutionary, SMS changes the orientation of
auxiliary storage management from the physical volume to
explicit performance and availability criteria. This further
changes the design of storage-cost recovery algorithms and
the underlying methods by which the unit cost of storage is
calculated.
For IS accounting, you must develop an effective method of
directly charging for system-managed storage that does not
depend on physical device-related characteristics.
Furthermore, this method must be adaptable to auxiliary
storage installations consisting of mixtures of diverse
technologies (for example, conventional magnetic DASD and
optical DASD) and implementations (for example, conventional
DASD strings and DASD arrays). Your charging method must
reflect the differences in the actual cost of these
technologies while remaining independent of both the device
and the technology. Otherwise, IS end users would have no
reason to support the capital investments necessary to
modernize.
Storage Hierarchies
-------------------
Modern computer systems implement storage in the form of a
hierarchy in which each tier has a different ratio of
performance to cost. At the top of the hierarchy is the high
speed buffer; it offers the lowest access time but is so
expensive that it cannot be very large given practical
economic constraints. The next level of the hierarchy is
main storage, followed by expanded storage, controller cache,
DASD, and tape. Each of these levels trades off access speed
for reduced cost.
The objective of this hierarchical structure is to provide a
total performance level for the entire hierarchy nearly equal
to that of the highest performance level at a cost close to
that of the lowest performance level.
The lower tiers of the hierarchy, DASD and tape, are managed
on a data set-by-data set basis, in an SMS environment, by
DFSMS.
Data Set Placement
------------------
The primary consideration when placing a data set is usually
the amount of space it requires. Because of the economic
relationship between the layers of the storage hierarchy,
the larger a data set is, the greater the incentive to place
it at a lower hierarchical level to minimize storage costs.
The second consideration is frequency of access. If a data
set is accessed frequently, the time required to mount a tape
volume upon which it resides may become a significant portion
of the total processing time associated with the data set.
This is especially true if the data set is relatively small,
because the processing time for a small amount of data will
typically be correspondingly short.
Considered together, data set size and frequency of access
determine the optimum media for a great many data sets.
Large, infrequently used data sets belong on tape while
small, frequently used data sets belong on DASD. In between
these two boundaries lies a "grey area" in which additional
considerations determine where the data set should be placed.
The third consideration for data set placement is the type of
access. Tape, being a sequential medium, is poorly suited to
data with random access patterns. Also, it provides little
or no capability for inserting records into existing
databases. Therefore, it is seldom a choice for IMS or DB2
data databases, regardless of how large they are or how
infrequently they are accessed.
SMS Concepts and Constructs
---------------------------
In a pre-SMS environment, data sets are allocated by storage
users (application programs, TSO users, storage managers,
etc.) on specific physical devices and possessing specific
physical characteristics defined by the storage user (space
required, method of allocation, logical record length, block
size, retention, expiration action, etc.). In an SMS
environment, data sets to be allocated are defined as having
certain characteristics. These classes of characteristics
are then mapped by the SMS components to logical pools of
storage that is in turn mapped onto the physical storage
hierarchy.
Data sets are assigned to storage groups based on the data's
characteristics and storage requirements (performance,
availability, etc.). These characteristics and requirements
are divided into three classifications:
o Data Class - specifies many of the characteristics of the
data such as record format, logical record length, etc.
o Management Class - specifies data management requirements
such as length of retention, backup requirements, and
disposition of the data set upon expiration
o Storage Class - specifies performance and availability
criteria
By assigning a new data set to a specific management and
storage class, the user defines the storage support
requirements for the data. SMS can then map the request into
the storage group that is best suited to meet those
requirements. Subsequently, the physical placement of the
data set can be further optimized as storage demands change
or as different physical devices are added to the storage
pool.
Life Cycle Management With SMS
------------------------------
In manual storage management schemes, data is generally
either active or archived. More often than not, archival
of data (both onsite or offsite backup) is treated as an
overhead of active data storage. Therefore, the unit cost
of storage is simply computed as the fully-burdened cost of
the physical storage (per unit of time) divided by the
amount of available storage.
In an SMS environment, a data set may migrate from primary
storage to secondary storage to archival storage during its
life cycle. Therefore, the average amount of time a data set
of a given management and storage class resides on each type
of storage must be determined and the cost of the primary,
secondary, and inactive storage must be computed individually
and summarized together to arrive at the actual unit-cost of
system managed storage.
Strategies for System Managed Storage Accounting
------------------------------------------------
SMS technology requires a change from a device-dependent
(for example, 3380 track-day) accounting algorithm to one
based on space-time (for example, Megabyte-Hrs). Since SMS
utilizes a class structure based on performance,
availability, and data management requirements that were
largely implicit in device selection, it seems logical to use
these classifications as the basis for storage charging.
They provide a basis for implementing a class-of-service
algorithm that is equitable, easily managed by IS, and easily
understood by the end user.
(Class-of-service charging schemes are widely utilized
throughout service industries. For instance, the U.S.
Postal Service offers a range of service classes, from
overnight delivery to third class bulk rate. The major
distinction between these classes is the speed with which the
item arrives at its destination. These postage classes are
analogous to SMS storage classes that determine how rapidly
data may be accessed.)
In particular, SMS Storage Class defines service-level
thresholds for performance and availability. These
considerations largely determine the device type, cached
versus non-cached, channel and control unit utilizations,
etc., required by the data. These factors determine the
direct cost of the storage.
SMS Management Class defines the retention, backup and
disposition requirements. These factors determine the
indirect cost of the data storage.
Taken together, storage and management class imply both the
performance cost and the support cost of a unit of data
stored. This forms the basis for a class-of-service based
charging algorithm as follows:
Data set charge = megabyte hours * Storage Class rate
+
megabyte hours * Management Class rate
Refer to the next section and Chapter 3 of the CA MICS
Accounting and Chargeback User Guide for information on how
to implement this algorithm at your installation.
