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.

Nexus Repository does not support the following file systems types:

  • NFS versions 3 and older
  • GlusterFS
  • FUSE-based user space file systems

S3 Blob Store

Nexus Repository only supports AWS S3. Other implementations of the S3 protocol may or may not work, and are not officially supported.

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.
  • Nexus Repository only supports AWS S3. We neither test nor support other S3 protocol implementations.

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 into 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 

NEW IN 3.31.0 PRO

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 the tasks 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

If you need to implement multiple blob stores in your configuration, do so with caution. While Nexus Repository can handle many blob store configurations, performance issues can occur in some scenarios: 

  • Repositories that are grouped together or are a 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.

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.

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 Nexus Repository:

  • The binary component (stored as a .bytes file thats 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-Availiability Clustering (Legacy) Considerations

If you have a High Availability cluster, then you should also refer to Configuring Blob Stores.