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 <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.
+
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. This is termed the '''root storage path'''.
  
 
== Layout and Structure ==
 
== Layout and Structure ==
Line 16: Line 16:
 
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***.  
 
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 [[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:
+
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 two bytes are used to create a two-level nested subdirectory. Example with a fictitious user #1:
  
 
User id #1 has a storage ID of <code>00933DBC-C7A9-DE0E-5D38-FB23B574A580</code>.  
 
User id #1 has a storage ID of <code>00933DBC-C7A9-DE0E-5D38-FB23B574A580</code>.  
Applying a SHA1 hash gives us <code>9414f5052eead73c262d5ad89922541426208763ce86c2b64cc6a6680914a915</code>.
+
Hashing the storage ID gives us <code>9414f5052eead73c262d5ad89922541426208763ce86c2b64cc6a6680914a915</code>.
From the hash, the first two bytes become the first directory level <code>/94</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>
+
The hash itself is the final component <code>/94/9414f5052eead73c262d5ad89922541426208763ce86c2b64cc6a6680914a915</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.
+
This final result is the ''relative'' path under the '''root storage path''' (which, as stated above, defaults to <code>/data/storage/local</code>). Therefore, the full path to the storage area of user id #1 is <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.

Revision as of 23:12, 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. This is termed the root storage path.

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 two bytes are used to create a two-level nested subdirectory. Example with a fictitious user #1:

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

This final result is the relative path under the root storage path (which, as stated above, defaults to /data/storage/local). Therefore, the full path to the storage area of user id #1 is /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.