Storage in Yandex Managed Service for Valkey™

Yandex Managed Service for Valkey™ allows you to use network and local storage drives for database clusters. Network drives are based on network blocks, i.e., virtual drives in the Yandex Cloud infrastructure. Local drives are physically located on the database host servers.

When creating a cluster, you can select the following disk types for data storage:

• Network SSDs (network-ssd): Compromise solution: slower than local SSDs, network SSDs ensure data integrity in the event of Yandex Cloud hardware failure.

• Non-replicated SSDs (network-ssd-nonreplicated): Network SSDs with higher performance achieved by eliminating redundancy.

  For a list of host classes and corresponding platforms, see Valkey™ host classes.

  You can only expand this type of storage in 93 GB increments.

• Ultra high-speed network SSDs with three replicas (network-ssd-io-m3): Network disks that deliver performance equivalent to non-replicated SSDs while ensuring redundancy.

  You can only increase the size of these disks in 93 GB increments.

• Local SSDs (local-ssd): Highest-performing disks.

  You can expand such a storage as follows:

  • For Intel Cascade Lake: Only in 100 GB increments.
  • For Intel Ice Lake and AMD Zen 4: Only in 368 GB increments.

  For a list of host classes and corresponding platforms, see Valkey™ host classes.

  For clusters with hosts residing in the ru-central1-d availability zone, local SSD storage is not available if using Intel Cascade Lake.

Block size for all disk types is 4 KB.

Selecting disk type when creating a clusterSelecting disk type when creating a cluster

The number of hosts you can create together with a Valkey™ cluster depends on the disk type you select and whether you enabled sharding:

Disk type	Non-sharded cluster	Sharded cluster
Network SSDs (network-ssd), ultra high-speed network SSDs with three replicas (network-ssd-io-m3)	1 host or more	1 host or more (1 shard × 1 host)
Local SSDs (local-ssd)	3 hosts or more	2 hosts or more (1 shard × 2 hosts)
Non-replicated SSDs (network-ssd-nonreplicated)	3 hosts or more	3 hosts or more (1 shard × 3 hosts)

Learn about the limits on the number of hosts per cluster or shard in Quotas and limits.

Managing disk spaceManaging disk space

When the storage is 100% full, cluster hosts automatically switch to read-only mode. In this mode, data write requests fail. To release the cluster from read-only mode, increase the storage size or contact support.

Monitoring the transition to read-only modeMonitoring the transition to read-only mode

To monitor the cluster storage utilization percentage, set up alerts in Yandex Monitoring:

1. In the management console, select the folder.

2. Navigate to Monitoring.

3. Create a notification channel.

4. Create an alert with the following properties:

   • Metric expression: disk.used_bytes / disk.total_bytes * 100.

   • Alert condition: Set alert trigger conditions:

     • Aggregation function: Maximum (maximum metric value over the period).
     • Comparison function: Greater than or equals.
     • Warning: 90 (90 % of storage size).
     • Alarm: 95 (95 % of storage size).
     • Evaluation window: Metric value calculation period.
     • Evaluation delay: Preferred time shift backward, in seconds. Allows to exclude incorrectly triggered alerts with several metrics collected at different time intervals. To learn more about the calculation delay, see this Yandex Monitoring guide.

   • Notifications: Add the notification channel you created earlier.

Automatic storage expansionAutomatic storage expansion

Automatic increase of storage size prevents situations where free disk space has been used up and hosts have switched to read-only mode. The storage size increases upon reaching the specified threshold percentage of the total capacity. There are two thresholds:

• Scheduled expansion threshold: When reached, the storage expands during the next maintenance window. If this threshold is set, configure the maintenance schedule.
• Immediate expansion threshold: When reached, the storage size increases immediately.

You can use either one or both thresholds. If you set both, make sure the immediate increase threshold is higher than the scheduled one.

Upon reaching the specified threshold, the storage expands differently depending on the disk type:

• For network SSDs, by the higher of the two values: 20 GB or 20% of the current disk size.

• For non-replicated SSDs and ultra high-speed network SSDs with three replicas, by 93 GB.

• For local SSDs:

  • Intel Cascade Lake, by 100 GB.
  • Intel Ice Lake and AMD Zen 4, by 368 GB.

If the threshold is reached again, the storage will be automatically expanded until it reaches the specified maximum. After that, you can set a new maximum storage size manually.

You can configure automatic storage expansion when creating or updating a cluster.

Disk encryptionDisk encryption

When creating or restoring a cluster from a backup, you can encrypt the storage disk with a custom KMS key. To encrypt a disk of an already created cluster, disable encryption, or encrypt a disk with a different key, create a backup of the cluster and restore it with the new settings.

To create an encrypted disk, you need the kms.keys.user role or higher.

If you deactivate the key used to encrypt a disk, access to the data will be suspended until you reactivate the key.

Data tieringData tiering

Valkey™ stores all data in RAM. This ensures high performance but requires a large amount of RAM, which is much more expensive than disk storage.

With data tiering, unused data can be moved from memory to disk. This way you have your data both in RAM and on disk.

Data is managed using the key eviction policy configured in the Maxmemory policy setting. In Valkey™, when this policy is enabled, evicted data is deleted. With data tiering, evicted data is moved to disk instead of being deleted, which is known as cooling.

When processing a request, Valkey™ first looks for data in RAM. If there is no data there, it checks the disk storage.

If the disk runs out of free space, the keys get deleted the same way as with regular eviction.

Data tiering saves RAM by moving rarely used data to disk. This can be useful when the total amount of data is much larger than the amount of frequently used data.

For example, a database may contain 300 GB of data, while only 20% of it is actively used, i.e., 60 GB. Without data tiering, all data must be reside in RAM. With data tearing, 240 GB of rarely used data can be moved to disk with only frequently used data remaining in RAM. This allows using about 60–70 GB of RAM instead of more than 300 GB, with minimal impact on response time.

Unlike hybrid storage, this approach does not use S3 object storage: data is moved directly from memory to disk.

Learn more about configuring data tiering.

Use casesUse cases

• Using a Yandex Managed Service for Valkey™ cluster as a PHP session storage
• Migrating a database from a third-party Valkey™ cluster