Last week, we started uncovering the possibilities of a certified Data Storage Container that lets you improve your projects' filesystem structure, making them more reliable and configurable. Below, we consider in detail what types of storage are available at Jelastic Cloud and for what kind of data they're best-suited:
- Local filesystem.
- Master container.
- Compound container.
- Dedicated container.
- External server.
This kind of storage is used to persist the data, which needs to be kept during the container lifecycle but is not needed to be shared across other nodes. Basically, it's kind of a folder you create inside of a server. Creating a local volume in a container represents a highly efficient way to protect your data (e.g. during the redeploy operation).
Among the main advantages of local filesystem storage is the simplicity of data control and its full local availability (as no network issue can affect its accessibility).
Such storage can be used for saving log files, which you don't want to be erased, or for your load balancer's configuration files, in order to keep the existing nodes' linking structure.
The master container type of data storing becomes most efficient when you don't need to export files on different environments but face the necessity of sharing your data in the confines of a single node layer.
In such a case, you don't require a separate storage container and can use the initial (master) node of the layer as your storage server. For example, if your application uses some pool of images on compute nodes, you can just share a folder with them for the whole layer. This ensures availability of the same content for all containers and, simultaneously, eliminates the necessity to synchronize, and keep this data copy at each node.
So, this way, you get rid of data duplications, lowering disk space consumption, which also reduces overall environment cost. Moreover, as a separate storage node is not used here (because everything is kept within layer's master container), no additional environment elements (and thus funds) are required to implement this structure.
Jelastic provides a possibility to treat any node as a data storage server, i.e. assign it an additional storage role beside the main native one. Using such a compound container works best for handling simple projects.
This way, you can leverage the shared storage functionality without the redundant complication of your environment topology due to separate node inclusion. And complementary utilization of a server, whose presence is necessary due to its role but is not very loaded, generally helps to save money compared to dedicated storage container use case.
Also, keep in mind that local files can be retrieved by an application much faster than when they are accessed via network. So, for example, if you have two nodes with one of them distributing some static content and another one just pushing it out upon request, the best solution will be to set up a storage on the first container to ensure faster distribution and preventing the network from bottlenecking.
Dedicated Storage Container
For more complex and loaded applications, it's worth centralizing your shared data within a single container to get simpler and more flexible export management (including accessing permission control — e.g. read-only for one node type and read-write for another).
In Jelastic, a Dedicated Storage Container is recommended for sharing files across multiple layers or even environments of a single account. It is specially optimized for data storing (i.e. is focused on performance and provides an enlarged amount of disk space).
Apart from that, you get the following benefits:
- Because storage represents an independent container, its occasional high loading can be properly handled without influencing performance (as it might happen during load peaks in the case of a single node fulfills several "roles").
- Upon needing to, you can painlessly remove everything except the required data and start your project over from scratch. The majority of common environment settings (e.g. internal domain and sharing permissions) will be left unchanged, which highly simplifies project re-integration.
- Storing data separately makes it easier to handle several project clones (i.e. environments), dedicated for different app lifecycle stages (e.g. separate ones for development, testing, and production).
- Mount the folder with your DB's scheduled backups to your storage container. This automatically keeps backups on the remote server and improves overall data safety during software upgrades.
Additionally, such a structure can be also efficiently utilized in case you need to share some common configuration files to nodes on different layers and/or environments. Your Jelastic Dedicated Storage Container can be also used as external storage.
This way, you can share some content for the required third-party service or other developers (providing them with personal access permissions) or get quick access to your data from any point with the Jelastic-hosted NFS server.
By using this option, you can even build your own intercloud sharing solution and/or operate with the same data from different Jelastic installations. Find out the required NFS server configurations for such an implementation within the linked doc.
External server mounting is intended for establishing connections to a third-party NAS storage system, which shares data via NFS. With Jelastic Cloud, the integration process is fairly simple because you don't need to perform any additional configuration either on the platform or storage sides.
So, if you have your own storage server with the properly structured content being already set up, with this option, you don't need to copy or transfer it anywhere — just mount and share data across the layers, environments, or even multiple Jelastic installations.
Otherwise, if you are just planning to create your own high-performance, reliable storage, consider leveraging the Dedicated Jelastic Storage Container. It's delivered with all of the necessary software preinstalled, so you can utilize such storage just after creation with no extra configuration required.