PAT.Raw Storage

From OIAr Archive 2013
(Redirected from PAT.Centralized Storage)
Jump to navigation Jump to search
Informational
Informational
Page maturity
This page has maturity level 4 (mature)

This is a Pattern document

Document icon PAT Raw Storage Version: 0.94 OIAr logo
Document type: Pattern Type Owner:

J.A.H. Schoonderbeek


Informational
Informational
Commentary

Description

This Pattern Type belongs to "Infrastructure Sector Core". This facility offers data preservation and data retrieval functionality with the following characteristics:

  • operates on data at the lowest abstraction level, i.e. "raw bits" level (e.g. bits and bytes),
  • located at one logical location,
  • access by general or dedicated storage network facilities (indicated by Data Transport),
  • the ability to perform storage related "intelligent" tasks, such as replication, migration, encryption, compression and data deduplication. This intelligence is characterized as "back-end facing" intelligence; generally speaking the facility's users don't get (direct) access to it, only the administrators and back-end systems.

As examples: realizations of Raw Storage can include:

  • SAN solutions,
  • (the back-end of) NAS appliances,
  • hard disk solutions.

Note: it's possible that the solution is to make use of Scheduling (e.g. for scheduling backups or snapshots) and/or Business Rules (e.g. for data deduplication or automatic migration of data to nearline/offline storage). If this is the case, then this pattern must be paired with facilities that deliver these functions.

Graphical Overview

This is the graphical representation of the infrastructure functions in this Pattern Type, plus their main relations:

Pattern Type Raw Storage
Pattern Type Raw Storage


(The source file of this picture can be downloaded here).

Pattern Type Composition

This pattern has the following mandatory and optional subfunctions, expressed in Building Block Types:

Icon Function WA Inclusion Rationale
BT.Raw Retention icon Raw Retention ST mandatory This facility handles the actual low-level storing/retrieving of data. Physically this can be realized with devices containing (re)writeable media, such as Solid State Disks, hard disks, tape, optical media et cetera.
BT.Retention Engine icon Retention Engine ST mandatory This facility provides "intelligence" to the storage solution with respect to its handling of the stored data, with the aim of meeting the quality requirements, improving infrastructure management, and/or providing sufficient performance. It may handle migration/replication to other instances of itself, encryption, compression, and other "standard" storage-related processing. Note that for some types of functionality an implementation/realization of Retention Engine may need to invoke another implementation/realization (e.g. for replication/migration over longer distances, there likely is a separate realization in each physical location).
BT.Caching icon Caching MW optional An intelligent storage facility may use caching to increase its capacity to receive and/or return data on request.
BT.Control Interface icon Control Interface SE optional If implemented, this function can be used for several Management Tasks, among others:
  • Restoring back-ups (note that end users may be enabled to do this themselves);
  • Initiating or scheduling back-ups (again note that end users may be allowed to do this themselves);
  • Capacity & Performance Management;
  • Provisioning;
  • Rules Management, in order to guide data migration between Tiers.

Care must be taken to limit access to these management tasks to authorized systems and users.

BT.Restore icon Restore ST optional Implementing a facility of this type may serve different goals:
  • It can serve a business need for data protection,
  • It can support a technical need related to business continuity, technical exploitation or maintenance.

To support these goals, Restore can support the following activities:

  • restoring backups for pools of data (such as "volumes");
  • storage migration, where pools of raw data that have been migrated off-line to backup media can be restored to active storage upon demand and/or rules.

Note that the Restore function may or may not be under control of end users.
In realization, Restore can be a sub-function of a versatile Retention Engine, e.g. the realized facility may be able to restore data from Raw Retention under control of that Retention Engine (as is the case with snapshotting/cloning), or it can be paired with a separate Pattern Variant of Raw Storage or File Storage/Raw Storage explicitly meant for backup & restore.

BT.Backup icon Backup ST optional Implementing a facility of this type always serves to support the Restore function, and thus virtually always appears together with one or more Variants of the Restore function. Furthermore, the criteria that govern the Backup functionality must always be derived from the goals and needs of all of the Restore Variants that it supports.

Note that the Backup function usually is under control of IT Operations, but may occasionally be offered to end users directly.
In realization, just as with Restore, Backup can be a sub-function of a versatile Retention Engine, or it can be implemented as a separate system/device.

BT.Scheduling icon Scheduling MW optional If the Pattern is to have automated backup functionality, then this function will govern the backup schedule and initiate separate backup jobs.


Pattern Type Neighbors

This pattern has the following mandatory and optional relations with adjacent (sub)functions, expressed in Pattern Types (PAT). Note: if the table below is empty, then there are no architecturally prescribed relations with adjacent subfunctions:

Function Adjacency Description
Data Transport mandatory Data must be able to travel from the storage consumers to storage and back. This often requires some sort of network, be it a SAN, a LAN or something alike. However, storage requirements usually pose stringent demands on the Data Transport capacity and reliability.
Authentication & Authorization optional A&A will be required for one or more of the following uses:
  • Authentication may be required for users accessing the control interface, be they system administrators or storage consumers (either systems or individual end users);
  • Authorization may be required for
    • read/write/modification/deletion actions (usually at the level of consuming systems);
    • actions requested by users of the Control Interface, such as provisioning of storage space;
    • back-end facing actions such as replication, backup and restore actions;
  • Authorization may be required for the Backup and for the Restore functions, so that privileged data doesn't wind up on underprivileged media, or privileged data is restored to an underprivileged location.
File Storage optional One of the facilities that require use of raw storage is the File Storage facility, as it itself is required to store data on a higher abstraction level (loosely structured data). File Storage stores the loosely structured data as groups of bits/bytes, and also the meta-data it has on this data.
This facility may make use of the Retention Engine's "storage intelligence" to offer its own users more functionality.


Pattern Variants based on this type

Pattern VariantBrief descriptionOwnermaturity
PAV.File Storage.LocalFile Storage.LocalJ.A.H. Schoonderbeek1