Storage Planning
Once you've created a blob store, many of its attributes are immutable. This makes it important to carefully plan your blob store configuration.
You will need to choose which types to use, how many blob stores to create, and how you allocate repositories to these blob stores. These decisions should be based on the following:
the size of your repositories
the rate at which you expect them to grow over time
the storage space available
the options you have available for adding storage space
Blob Store Types
Nexus Repository supports several types of blob stores. In general, file system blob stores have better performance, but object store blob stores offer unbounded storage and convenience. Cloud object stores perform better if you are also running Nexus Repository in the cloud with the same cloud provider. File blob store is the default and is recommended for most installations.
File Blob Store
A file blob store lets Nexus Repository store blobs as files in a directory. The Path parameter supplied during blob store creation determines the blob files' location. The Path can be on either a local disk or a NFSv4-compatible mount. If you are running Nexus Repository in AWS, it is also possible to use EFS, which acts as a limitless NFS version 4 server.
See Configuring Blob Stores for more in-depth information about configuring storage services for use with blob stores.
Warning
Nexus Repository does not support the following file system types:
NFS versions 3 and older
GlusterFS
FUSE-based user space file systems
S3 Blob Store
An S3 blob store saves blobs as objects within a bucket on AWS S3.
S3 blob stores have the following requirements:
The S3 blob store is only recommended for Nexus Repository installations hosted in AWS.
The S3 blob store should be in the same AWS region as the Nexus Repository installation. Using different regions will result in unacceptably slow performance.
Carefully consider whether S3 is the right storage solution for you. Performance is highly dependent on the speed of the network between Nexus Repository and the AWS endpoint to which you connect. Nexus Repository will send multiple outbound HTTP requests to AWS to store blobs in S3; large blobs are split into chunks over multiple requests. If your Nexus Repository instance is not in AWS or connecting to another region, an S3 blob store may be significantly slower than a file-based blob store.
Azure Blob Store
An Azure blob store saves blobs as objects within a storage account container on Microsoft Azure.
Azure blob stores have the following requirements:
The Azure blob store is only recommended for Nexus Repository installations hosted in Azure.
The Azure blob store should be in the same Azure region as the Nexus Repository installation. Using different regions will result in unacceptably slow performance.
Carefully consider whether Azure is the right storage solution for you. Performance is highly dependent on the network speed between Nexus Repository and Azure. Nexus Repository will send multiple outbound HTTP requests to Azure to store blobs in the storage account; large blobs are split into chunks over multiple requests. If your Nexus Repository instance is not in Azure or connecting to another location, an Azure blob store may be significantly slower than a file-based blob store.
Blob Store Layouts
Once a repository is associated with a blob store, it can take significant time to run thetasks necessary to change this, and tasks are also only available in Nexus Repository Pro. Blob stores cannot be split but they can be moved from one storage device to another using a process described in Configuring Blob Stores. For these reasons, your approach to using blob stores should be chosen carefully.
Single Blob Store
The simplest approach is to create a single blob store per storage device and divide your repositories among them. This is suitable in the following cases:
If you exceed available storage, you will be able to move blob stores to larger storage devices.
Your repositories are growing slowly enough that you will not exceed your available storage within a year.
Multiple Blob Stores
When creating blob stores, focus on the utility gained versus the cost associated with managing multiple blob stores. Here are some best practices and considerations:
Consider separating blob stores by format as they are often on different build pipelines or repository stages.
You might split out Docker repositories since they can grow very quickly.
Consider splitting out more critical components (hosted vs. proxy/replicated repositories).
Nexus Repository doesn't support partial backup restoration, so you may benefit from keeping more actively developed components on a separate blob store from archived components. You can also put priority components on faster disks while archived ones go on slower, cheaper storage.
Only split by teams or lines of business when the team will never overlap or share components and when there are a reasonably fixed number of teams.
Only use automation for initial blob store provisioning, not for mass blob store creation.
Don't partition blobs per repository. This will cause performance impacts at scale.
While Nexus Repository can handle many blob store configurations, performance issues can occur in some scenarios:
Repositories that are grouped together or are part of a shared build pipeline (e.g., staging) benefit from being on a single blob store. If you use multiple blob stores in this scenario, components must be copied across multiple blob stores instead of just updating a database.
Because cleanup tasks are configured and serialized against each blob store, having many of them can cause them to run slowly.
The remaining disk space calculations can be inaccurate when multiple blob stores are located on the same disk.
Having many blob stores may negatively impact database search efficiency.
Group Blob Store
A group blob store combines concrete blob stores so that they act as a single blob store for repositories. Repositories can only act singularly or as part of a group. A repository can either use a concrete blob store directly or as a member of a single group, but not both.
Group blob stores are a good choice if you meet the following criteria:
You need to add more storage space via multiple devices.
You need the ability to spread writes and reads across multiple blob stores.
You need to mix both disk and cloud storage.
Estimating Blob Store Storage Requirements
Blob stores contain two files for each binary component stored in the Nexus Repository:
The binary component (stored as a .bytes file whose size is the same as the component).
A properties file that stores a small amount of metadata for disaster recovery purposes (<1KB).
The total blob store storage size is therefore approximately the total size of all of your components plus an allowance for the properties files and the block size of your storage device.
On average, the allowance will be 1.5 * # of components * block size.
High-Availability Clustering (Legacy) Considerations
If you have a high-availability cluster, then you should also refer to Configuring Storage.