A blob store is the storage for components and assets. Each blob store can be used by one or multiple repositories and repository groups. By default, a file blob store named default is automatically created in the directory during installation. New blob stores may be configured by selecting Blob Stores from the Repository sub menu of the Administration menu. Once a blob store is created, many of its attributes are immutable. This makes it important to carefully plan your blob store configuration.
Learn the basics of storage management in our technical guide.
- Blob - An object containing data within a blob store, e.g. component binaries and metadata files
- Blob Store - An internal storage mechanism for the binary parts of components and their assets
- Concrete Blob Store - Any blob store that is not a group
- Fill Policy - For a Group Blob Store, the fill policy determines which blob store a blob is written
- Group Blob Store - A blob store that delegates operations to one of the other blob stores on its list
- Hard Delete - When a soft deleted blob is permanently removed from the blob store, usually via the Admin - Compact blob store task
- Promote to Group - A process by which a concrete blob store becomes a group blob store that can access the blobs of the original concrete blob store
- Soft Delete - Blobs deleted in a repository are only marked for deletion. They still exist within the blob store. That is known as a soft delete.
- Soft Quota - A check of a blob store that compares a metric against a limit. If the check fails, then the blob store is considered unhealthy but writes still proceed and a warning is logged.
- Space Limit - A byte limit compared against specific blob store metrics by a soft quota
- Space Used Quota - This type of quota is violated when the total size of the blob store exceeds the space limit
- Space Remaining Quota - This type of quota is violated when the available space of a blob store falls below the space limit
Available Space - Remaining storage capacity of a blob store
Blob Count - The number of blobs currently stored in a blob store
Blob Store Type - The type of blob store implementation
File - Store blobs in file system-based storage
Group - Combines multiple blob stores into one
S3 - Store blobs in AWS S3 cloud storage
If you have a High Availability cluster, then you should refer to this guide as well, Configuring Blob Stores.
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 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 Manager supports several types of blob stores. File blob store is the default and is recommended for most installations.
File Blob Store
A file blob store lets Nexus Repository Manager store blobs as files in a directory. The location of the blob files is determined by the Path parameter supplied when creating the blob store. The Path can be on either a local disk or a NFSv4 compatible mount. Our guide, Configuring Blob Stores, has more in-depth information about configuring storage services for use with blob stores.
Nexus Repository Manager does not support the following file systems types:
- NFS versions 3 and older
- FUSE based user space file systems
S3 Blob Store
An S3 blob store saves blobs as objects within a bucket on AWS S3.
- The S3 blob store is only recommended for Nexus Repository Manager installations hosted in AWS.
- The S3 blob store should be in the same AWS region as the Nexus Repo installation. Using different regions will result in unacceptably slow performance.
- Nexus Repository Manager only supports AWS S3. Other implementations of the S3 protocol have not been tested and are not supported.
Nexus Repository Manager will automatically create an S3 bucket when a blob store is created if it does not already exist. However, you may also create the bucket yourself. Note that:
- Nexus Repository Manager will automatically apply a lifecycle rule to expire deleted content.
- The bucket can use server-side encryption with KMS key management transparently. Other methods of server-side encryption are not supported.
- If running on EC2 instances, Nexus Repository Manager can use the IAM role assigned to those instances when accessing S3 buckets.
Carefully consider whether S3 is the right storage solution for you. The performance is highly dependent on the speed of the network between NXRM and the AWS endpoint you connect to. NXRM will send multiple outbound HTTP requests to AWS to store blobs into S3, and large blobs are split into chunks over multiple requests. If your NXRM instance is not in AWS or connecting to another region, an S3 blob store may be significantly slower than a file based blob store.
For optimum performance:
- Run NXRM on AWS on EC2 instances
- Ensure that the S3 connection is using the region where NXRM is being run
The chunk size when uploading to S3 can be adjusted by setting the property
nexus.s3.multipartupload.chunksize in the
nexus.properties file. The unit is bytes and the default is 5242880 (5MB). This can be tuned for optimal performance on your network.
Azure Blob Store
An Azure blob store saves blobs as objects within a storage account container on Microsoft Azure.
- The Azure blob store is only recommended for Nexus Repository Manager installations hosted in Azure.
- The Azure blob store should be in the same Azure region as the Nexus Repo installation. Using different regions will result in unacceptably slow performance.
The Azure storage account must be created in Azure before using Nexus Repository Manager to create an Azure blob store. The following storage account settings are recommended:
- Location: the location hosting Nexus Repository Manager
- Performance: Standard or Premium
- Account kind: StorageV2
- Replication: Any
Nexus Repository Manager will automatically create an Azure container when a blob store is created if it does not already exist.
The Azure storage container name must be a valid DNS name, following the rules that Microsoft states in https://docs.microsoft.com/en-us/rest/api/storageservices/naming-and-referencing-containers--blobs--and-metadata
There are two methods of gaining access to the Azure storage account from NXRM. The first of which is using a secret access key supplied by the Azure storage account. Secondly, if running NXRM on an Azure VM you can utilize System Managed Identity access, which allows Azure to manage the access via roles assigned to the VM you are running NXRM in, see https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/qs-configure-portal-windows-vm for details. To properly utilize the System Managed Identity, the Azure VM will need the following roles assigned to the Azure storage container:
- Storage Account Contributor
- Storage Blob Data Contributor
NXRM does not currently validate the proper roles are assigned before storing the configuration. If the aforementioned roles are not properly granted to the VM, the blob store will need to be deleted and added again after the roles have been setup in the Azure storage instance
Carefully consider whether Azure is the right storage solution for you. The performance is highly dependent on the speed of the network between NXRM and Azure. NXRM will send multiple outbound HTTP requests to Azure to store blobs into the storage account, and large blobs are split into chunks over multiple requests. If your NXRM instance is not in Azure or connecting to another location, an Azure blob store may be significantly slower than a file based blob store.
For optimum performance:
- Run NXRM on Azure on virtual machines
- Ensure that the Azure connection is using the location where NXRM is being run
The chunk size when uploading to Azure can be adjusted by setting the property
nexus.azure.blocksize in the
nexus.properties file (e.g.
nexus.azure.blocksize=1000000). The unit is bytes and the default is 5242880 (5MB). This can be tuned for optimal performance on your network.
Group Blob Store
A group blob store combines concrete blob stores so that they act as a single blob store for repositories. A concrete blob store can either be used directly by a repository or as a member of a single group, but not both. Groups allow you to add members dynamically, but removing a blob store requires a task to ensure that repositories still have access to their blobs. More information about the task can be found in the Admin - Remove a member from a blob store group section of Types of Tasks and When to Use Them. The Fill Policy is the method that the blob store group uses to choose a member for writing blobs. The Fill Policy can be changed at any time.
Available choices for Fill Policy :
- Round Robin - Incoming writes alternate between all blob stores in the group. If writing to one blob store fails, then it attempts again with the next blob store in the group. This is useful when you have a number of blob stores available and you want each of them to receive a roughly equal number of writes. This does not balance based upon any other metric.
- Write to First - All incoming writes are given to the first blob store. If you need to direct all blobs to a specific blob store, e.g. you have a blob store for a new empty disk, then this fill policy will ensure that the new blob store gets all the writes.
Blob Store Layouts
Once a repository is allocated to a blob store, it is there permanently. Blob stores cannot be split but they can be moved from one storage device to another using a manual process. The instructions to do so are in this support article, Relocating 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:
- Your repositories are growing slowly enough that you will not exceed your available storage within a year.
- If you exceed available storage, you will be able to move blob stores to larger storage devices.
Multiple Blob Stores
You should separate repositories into two or more blob stores per storage device if both:
- You expect to exceed your currently available storage within a year.
- You cannot move blob stores to larger storage devices, so you must add capacity to Nexus Repository Manager by adding additional storage devices.
In extreme cases of unpredictable capacity, the best approach is to create a separate blob store for each repository. This configuration adds significant complexity so should be considered with caution.
Group Blob Stores
Groups blob stores allow you to combine multiple blob stores into one. Groups are a good choice if:
- You need to add more storage space via multiple devices.
- You need the ability to spread writes and reads across multiple blob stores.
You can start with a concrete blob store and later use the Promote to Group process to transform it into a group for more flexibility. Promotion creates a group containing the previous blob store to which you can add other blob stores.
Estimating Storage Requirements for Blob Stores
Blob stores contain two files for each binary component stored in Nexus Repository Manager:
- 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 (<1k)
The total storage size of a blob store 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.
Example: Moving a Blob Store
The following steps can be used to move a blob store to a new location. This can also be used to change a blob store's storage, for instance, a file based blob store can be moved to s3.
- Create a new blob store with the storage path set to the new location.
- Then promote the existing blob store to a group blob store.
- Set the new group's Fill policy to Write to First.
- Add the new blob store (created in step 1) into the group blob store underneath the original blob store.
Then schedule and run an Admin - Remove a member from blob store group task via Administration → System → Tasks to remove the original blob store from the group. The contents of the original blob store will be moved over to the new blob store, and then the original blob store will be removed.