Storage

From DreamFactory
Jump to: navigation, search
m
m
Line 4: Line 4:
 
Mounts can be local or remote storage. As long as the storage space is accessible via the file system of the server, it can be utilized for storage.
 
Mounts can be local or remote storage. As long as the storage space is accessible via the file system of the server, it can be utilized for storage.
  
By default, DreamFactory Enterprise&trade; defines the mount point <pre>/data/storage</pre> for your initial cluster. This directory contains a subdirectory for each cluster. The initial installation defaults to '''local''' as the storage area. This exists on your system in <pre>/data/storage/local</pre>. When you create new clusters, you can configure their storage areas in a different subdirectory, or different mount point altogether. It is designed to be flexible and map to most storage scenarios.
+
By default, DreamFactory Enterprise&trade; defines the mount point <code>/data/storage</code> for your initial cluster. This directory contains a subdirectory for each cluster. The initial installation defaults to '''local''' as the storage area. This exists on your system in <code>/data/storage/local</code>. When you create new clusters, you can configure their storage areas in a different subdirectory, or different mount point altogether. It is designed to be flexible and map to most storage scenarios.
  
 
== Layout and Structure ==
 
== Layout and Structure ==
Line 11: Line 11:
 
[[File:storage-layout.png]]
 
[[File:storage-layout.png]]
  
The <pre>/data</pre> tree contains self-explanatory subdirectories. Under <pre>/data/storage</pre> is where it begins to get interesting.
+
The <code>/data</code> tree contains self-explanatory subdirectories. Under <code>/data/storage</code> is where it begins to get interesting.
  
=== Lightweight Striping ===
+
=== Data Splaying ===
To ''spread'' the storage load, as it were, of thousands of virtual instances, the instance storage tree implements a simplistic hashed directory tree. Each [[DFE/Dashboard|Dashboard]] user is assigned a unique storage ID in the form of a GUID (<pre>[[DFE/Architecture/Database/User|User.storage_id_text]]</pre>). This GUID is hashed, and with it and the first four bytes are used to create a three-level nested subdirectory. Example:
+
With thousands of virtual instances, you don't want their storage areas all homed in the same directory. Firstly, you'll run out of '''inodes''' eventually. Secondly, as the more and more entries are added to the file system, access slows down considerably. To combat this performance decay, DreamFactory Enterprise builds a multi-layered storage structure using user information. The instance storage tree then becomes a simplistic hashed directory tree. We call this ***Data Splaying***.  
  
User id #1 has a storage ID of <pre>00933DBC-C7A9-DE0E-5D38-FB23B574A580</pre>.  
+
Each [[DFE/Dashboard|Dashboard]] user is assigned a unique storage ID in the form of a GUID (<code>[[DFE/Architecture/Database/User|User.storage_id_text]]</code>). This GUID is hashed, and with it and the first four bytes are used to create a three-level nested subdirectory. Example with a fictitious user #1:
Applying a SHA1 hash gives us <pre>9414f5052eead73c262d5ad89922541426208763ce86c2b64cc6a6680914a915</pre>.
+
  
 +
User id #1 has a storage ID of <code>00933DBC-C7A9-DE0E-5D38-FB23B574A580</code>.
 +
Applying a SHA1 hash gives us <code>9414f5052eead73c262d5ad89922541426208763ce86c2b64cc6a6680914a915</code>.
 +
From the hash, the first two bytes become the first directory level <code>/94</code>
 +
The second two bytes make up the second directory level <code>/94/14/</code>
 +
And the hash itself is the final component <code>/94/14/9414f5052eead73c262d5ad89922541426208763ce86c2b64cc6a6680914a915</code>
  
 
+
This final path is the relative path under the root storage area (defaults to <code>/data/storage/local</code>). Therefore, the storage area of user id #1 is located in <code>/data/storage/local/94/14/9414f5052eead73c262d5ad89922541426208763ce86c2b64cc6a6680914a915</code>. This is termed a user's '''storage root path''' as all instances for this user will reside in this directory. Also in this directory is a private area that survives instance termination. Currently, nothing is stored in this directory.
== Preventative Maintenance ==
+
=== Automated ===
+
=== Manual ===
+

Revision as of 23:08, 14 December 2015

Instance Storage

When DreamFactory Enterprise™ provisions a new instance, a directory is created for it to use as local storage. The location of this directory depends on the mount assigned to the server on which the instance was provisioned.

Mounts can be local or remote storage. As long as the storage space is accessible via the file system of the server, it can be utilized for storage.

By default, DreamFactory Enterprise™ defines the mount point /data/storage for your initial cluster. This directory contains a subdirectory for each cluster. The initial installation defaults to local as the storage area. This exists on your system in /data/storage/local. When you create new clusters, you can configure their storage areas in a different subdirectory, or different mount point altogether. It is designed to be flexible and map to most storage scenarios.

Layout and Structure

Below is a diagram of the default layout for storage.

Storage-layout.png

The /data tree contains self-explanatory subdirectories. Under /data/storage is where it begins to get interesting.

Data Splaying

With thousands of virtual instances, you don't want their storage areas all homed in the same directory. Firstly, you'll run out of inodes eventually. Secondly, as the more and more entries are added to the file system, access slows down considerably. To combat this performance decay, DreamFactory Enterprise builds a multi-layered storage structure using user information. The instance storage tree then becomes a simplistic hashed directory tree. We call this ***Data Splaying***.

Each Dashboard user is assigned a unique storage ID in the form of a GUID (User.storage_id_text). This GUID is hashed, and with it and the first four bytes are used to create a three-level nested subdirectory. Example with a fictitious user #1:

User id #1 has a storage ID of 00933DBC-C7A9-DE0E-5D38-FB23B574A580. Applying a SHA1 hash gives us 9414f5052eead73c262d5ad89922541426208763ce86c2b64cc6a6680914a915. From the hash, the first two bytes become the first directory level /94 The second two bytes make up the second directory level /94/14/ And the hash itself is the final component /94/14/9414f5052eead73c262d5ad89922541426208763ce86c2b64cc6a6680914a915

This final path is the relative path under the root storage area (defaults to /data/storage/local). Therefore, the storage area of user id #1 is located in /data/storage/local/94/14/9414f5052eead73c262d5ad89922541426208763ce86c2b64cc6a6680914a915. This is termed a user's storage root path as all instances for this user will reside in this directory. Also in this directory is a private area that survives instance termination. Currently, nothing is stored in this directory.