PAT.Raw Storage.Commentary

From OIAr Archive 2013
Revision as of 00:22, 12 November 2012 by Jan Schoonderbeek (talk | contribs) (start)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
 
Document icon CM Raw Storage commentary Version: 0.2 OIAr logo
Document type: Commentary Owner:

J.A.H. Schoonderbeek



This is the commentary page for page Raw Storage.


This Pattern Type can be used to model storage at the lowest level (bits/bytes, or "raw bits"). It does not include the way for a storage consumer to get the data to and from the facility, because that can be described most adequately by the Data Transport pattern.

Core of the pattern

The foundation of the pattern is the Data Retention facility. This does the actual storing of the data, and does so at the lowest abstraction level. However, the storage functions that this facility provides to its users are very basic: read/write/modify/delete, or maybe even a subset of these (WORM drives or archiving solutions may not support modify and/or delete). Extra storage-related functionality must come from the next facility.

At the heart of the pattern sits the Retention Engine facility. This facility provides "backend-facing storage functions", meaning storage functions that the end user usually doesn't directly use himself. Likely these are the functions that the system administrators need to be able to deliver the Data Storage functionality as described in the Pattern Variant's characteristics: things like snapshotting, (automatic) data migration/replication, thin provisioning, et cetera.

And then there's the adjacent facility Data Transport. All data for this facility comes from/goes to the end user by means of some form of the Data Transport pattern. As an example: if the pattern is realized as an iSCSI device, the Data Transport pattern will likely be a realization like a standard network, or perhaps a dedicated storage network with standard ethernet equipment; however if the pattern is realized as a fiberchannel controller/disk cabinet combination, then the Data Transport pattern is a fiberchannel Storage Area Network.

"Dressing up" the pattern

The Pattern Type is fitted with some optional facilities:

  1. Control Interface
  2. Caching
  3. Backup & Restore
  4. Pattern Type Authentication & Authorization (A&A)

Functionality that is not included in this Pattern Type, but may be included in a Pattern Variant, includes:

  • BBT Scheduler; this can handle repeating automatic tasks like backups and creating snapshots;
  • PAT Orchestration; this can govern automatic handling of data based on business rules, although one should keep in mind that the Raw Storage facility has virtually no information about the data; this information is limited mostly to usage, usage patterns and metadata at the data volume level.