A user is an identity with associated privileges on a MinIO deployment. Each user consists of a unique access key (username) and corresponding secret key (password). The access key and secret key support authentication on the MinIO deployment, similar to a username and password.
Backups are a big business. Within that market, VM backups represent the lion’s share of the market. The world of VM backups has changed, however. What was once a small challenge for enterprises has become a massive one reaching PBs in size and spawning an entire sub-industry.
- Minio is an S3 compatible object storage system. It can be easily setup via docker or a static go binary and provides a nice web UI. The catch is that this system can only be used internally as public access to the storage bucket is required if you don’t want to configure anything else in SBT.
- Once the migration is complete, server will automatically unset the MINIOROOTUSEROLD and MINIOROOTPASSWORDOLD with in the process namespace. NOTE: Make sure to remove MINIOROOTUSEROLD and MINIOROOTPASSWORDOLD in scripts or service files before next service restarts of the server to avoid double encryption of your existing contents.
Veeam is the one of the major players in backup, recovery and replication software and, in the eyes of many enterprises, the major player. For Veeam customers, what makes MinIO so interesting is the fact that MinIO is software defined. Since software wants to talk to other software, MinIO and Veeam are a superb match when it comes to backing up VMs. Here is why:
- VM backups require scalable storage. There is little debate around this point in architecture circles these days. Object is the most scalable solution - whether in the public or private cloud.
- VM backups require performance. This is a two part requirement. First, backups and restores need to go quickly no matter the size. Traditional object storage architectures (think appliance vendors) are not up to the task here for a number of reasons. This is where modern object stores like MinIO are exceptionally well suited. There are a number of reasons but these four stand out:
- Speed. With the ability to read/write at speeds in excess of 160 GB/s in a single 32 node cluster, MinIO can backup and restore at speeds once considered impossible for object storage. Longer backup restore cycles would result in increased disruption to business. One way slower object stores try to make shortcuts is to move to an eventual consistency model. This can have devastating effects if the plug gets pulled in the middle of your job and your database gets corrupted.
- Object size. MinIO can handle any object size. Veeam’s default is 1MB objects but supports anywhere from 256K to 4MB. Because MinIO writes metadata atomically along with the object data, it does not require a database (Cassandra in most cases) to house the metadata. At smaller object sizes, deletes become highly problematic and effectively disqualify any object store that employs such an approach. At 4MB, dedupe becomes ineffective, so Veeam architects recommend against it.. Suffice to say - if the object storage implementation uses a metadata database, it is not well suited for handling backups.
- Inline and Strictly Consistent. Data in MinIO is always readable and consistent since all of the I/O is committed synchronously with inline erasure-code, bitrot hash and encryption. The S3 service provided by MinIO is resilient to any disruption or restarts in the middle of busy transactions. There is no caching or staging of data for asynchronous I/O. This guarantees all backup operations are guaranteed to succeed.
- Commercial off-the-shelf hardware. COTS hardware = huge savings, familiarity and flexibility. This becomes an important requirement as the data grows into to the Petabytes.
The result of these requirements is that Veeam is a natural pair for high-performance, software defined object storage. That is exactly what MinIO is and is why we fit so well with Veeam.
To demonstrate that point, we will pair Veeam together with MinIO as a capacity tier to allow Veeam’s software to offload virtual machines from VMware ESX to Veeam.
ENVIRONMENT
ESX Server
One ESX server running 10 virtual machines with 300GB thin disks with 100GB generated data in each. (specs)
- 28 Physical Cores @ 2.2 GHz
- 384 GB of DDR4 ECC RAM
- 3.8TB NVME
- 10Gbps network *
- 6.5.0 Update 1 (Build 7967591)
Veeam Server
- 28 Physical Cores @ 2.2 GHz
- 384 GB of DDR4 ECC RAM
- 3.2 TB NVMe drive
- 20Gbps switch bonded nic
- Windows Server 2016, Veeam Backup and Replication 10.0.0.4461
MinIO Cluster
We deployed a four node MinIO cluster with the following specs
- 24 Physical Cores @ 2.2 GHz
- 256 GB of DDR4 ECC RAM
- 2.8 TB of SSD per server, split into 4 drives per server
- 2 x 10 GigE bonded NICs
- Ubuntu 18.04
MinIO configuration
We created a four node MinIO cluster with TLS for over the wire encryption, and object encryption. We have noted in previous benchmarks that object encryption has a minimal impact on the CPU performance. As such, we recommend it always be turned on.
MINIO_VOLUMES='https://veeam-minio0{1...4}/mnt/disk{1...4}/veeam'
MINIO_ERASURE_SET_DRIVE_COUNT=4
MINIO_ACCESS_KEY=
MINIO_SECRET_KEY=
MinIO servers
18.7 Gbits/sec
Windows to MinIO servers:
18.9 Gbits/sec
From these numbers, we see that all servers are getting the expected network bandwidth.
Warp tests
Warp is a utility created by the MinIO development team for measuring performance of S3 compatible object stores. In these tests, we have deployed a number of client machines with sufficient network bandwidth to saturate the MinIO cluster.
GET numbers
First, we run a test for GET performance across the cluster.
$ warp get --access-key --secret-key
Operation: DELETE. Objects per operation: 100. Concurrency: 192. Hosts: 4.
* Average: 6738.25 obj/s (7.585s, starting 18:32:15 UTC)
Veeam Setup
Configuring MinIO as an s3 target
Minio Generate Random Access Key Code
1. Create Object Store for capacity tier
First, we create a new S3 compatible object store as a capacity tier. Choose an s3 compatible object store and configure to use your MinIO deployment as a custom endpoint
Minio Generate Random Access Key Codes
1e. Use the minio client command line utility (mc) to see that Veeam has created the prefix structure under the bucket:
Running a backup to the capacity tier
Next, we create a backup job to offload VM's from Veeam to MinIO. We will use ten test VM’s, each with 100GB of random test data, with each VM having a unique data set to avoid any deduplication.
On the Storage screen, we choose a Scale-out Backup Repository that was configured for this test. After backing up to the Veeam server, VM's will also be backed up to the capacity tier, i.e., MinIO.
Minio Generate Random Access Key Free
Summary
Performance matters when it comes to backups and restores. Veeam's software is very well architected, but when it points to an S3 compatible object store it needs that object store to deliver in turn - otherwise the utility of the overall solution is limited.
MinIO and Veeam are superb compliments to each other. Both deliver scalability, speed and simplicity in a software-defined solution.
We encourage Veeam users to try out this architecture as it will enable them to modernize their stack, improve performance, deliver greater scale and ultimately present vastly superior economics for this critical software workflow.
Minio Generate Random Access Key
To get started with MinIO, simply download the code. If you have questions we have outstanding documentation an integration document on Github and the industry's best community Slack channel. If you want a deeper relationship, check out our pricing page to see what options might fit your requirements.