DocumentationRBD Service
The Rados Block Device RBD is a block storage solution that can be connected to your infrastructure. The connection must be established through a Linux based machine(preferred) or Windows based Machine. Once connected, you can re-export the block device to other parts of your infrastructure (such as remounting it over a network using Samba). RBD is particularly well-suited for centralized backup systems. It is a specialized service that requires the user to have advanced experience in managing Linux devices. RBD is intended for handling larger volumes of data - hundreds of TB. Additionally, the block device can be encrypted on the client side using LUKS. Client-side encryption ensures that data is encrypted during transmission, making it inaccessible even if intercepted. Access to the service is managed through virtual organizations and coresponding user groups.
RBD connections are only permitted from dedicated IPv4 addresses that are whitelisted in the firewall of our data centers. An RBD image can only be mounted on a SINGLE machine at a time; it cannot be mounted simultaneously on multiple workstations. In other words, RBD is not intended for use as a clustered file system. If you wish to use a clustered file system over RBD, please consult with Data Care support first.
How to access the RBD service?
To connect to the RBD service, please contact support at: support@cesnet.cz
Basic Use Cases for RBD
The following section outlines basic use cases for the RBD service.
Centralized Shared Storage for Internal Redistribution
If you need to store live data and provide storage for individual users, the RBD service can be integrated into your infrastructure using a Linux or Windows machine. You can create a filesystem on the connected block device, enable encryption, and then re-export it within your infrastructure using protocols such as Samba, NFS, FTP, SSH, etc. (or via containers that manage protocol distribution within your internal network). Client-side encryption ensures that data transmitted over the network is encrypted, making it impossible to decrypt once transmission is complete. The advantage of this setup is that you can create user groups and manage access rights according to your preferences or integrate your local user and group database. Additionally, the RBD block device can be equipped with snapshots at the RBD level. This allows you to restore data from previous snapshots, such as from the previous day, in the event of accidental deletion.
Backing Up Large Datasets that Require a Local Filesystem
If you have a centralized backup system (such as a script suite, Bacula, BackupPC, etc.) that requires a local filesystem, we recommend using the RBD service. As shown in the figure below, the RBD image can be connected directly to the machine running the central backup system as a block device. Additionally, RBD can be configured with snapshots (refer to the service description) to protect against unwanted overwriting or ransomware attacks.
RBD Data Reliability (Data Redundancy) - Replicated vs Erasure Coding
The following section describes additional approaches for data redundancy applied to the object storage pool. The RBD service can be configured with either replicated or erasure code (EC) redundancy, as well as synchronous or asynchronous geographical replication. It provides a trade-off between storage reliability and resource consumption. By default, we use EC.
Replicated
With replicated redundancy, your data is stored in three copies within the data center. If one copy becomes corrupted, the original data remains intact and readable, while the damaged copy is repaired in the background. Using a service with replication flag also improves read speeds, as data can be read from all replicas simultaneously. However, write speeds may be slower, as write operations must wait for confirmation from all three replicas before proceeding.
Suitable for? Ideal for smaller volumes of live data where reading speed is a priority (not very suitable for large data volumes).
Erasure Coding (EC)
Erasure coding (EC) is a data protection technique similar to dynamic RAID used in disk arrays. In this method, data is divided into fragments, which are stored with redundancy across the storage system. If a disk or an entire storage server fails, the data remains accessible and will be restored in the background. This ensures that your data is not at risk of being lost if a single disk is damaged.
Suitable for? Ideal for storing large data volumes, for example.
RBD Snapshots
Snapshots can be created at the RBD (replicated/erasure code) level and are managed from the client side. RBD snapshotting supports rollback of data in case of unwanted rewrite or data corruption. Snapshots can be mirrored to another geographic location, as described below.
Synchronous Geographical Replication
Synchronous geographical replication provides protection against data center failure. It may reduce write speed, as the system waits for successful write confirmation at both geographical locations. If you believe you need this service, please contact us.
Asynchronous Geographical Replication
Asynchronous geographical replication offers partial protection against data center failure, as some data may be lost between synchronization intervals due to time lag. However, in the event of data corruption (e.g., ransomware), you can interrupt the replication process to preserve your data. If you believe you need this service, please contact us.
Last updated on
