About storage

Are there restrictions for IOPS (number of I/O per second) to the disk, data transfer bandwidth, etc?

IOPS and data transfer bandwidth are restricted using the following reference values.

Ishikari Zone No. 1 (old plan) Ishikari Zone No. 2 (when "iscsi4" is included in the storage name)

Disk plan Reading IOPS
(disk → VM)
Writing data transfer bandwidth
(VM → disk)
Reading data transfer bandwidth
(disk → VM)
Writing data transfer bandwidth
(VM → disk)
20GB-4TB standard plan 2,000 500 64MByte/s 64MByte/s
20GB SSD plan 6,000 1,500 150MByte/s 150MByte/s
40GB SSD plan 6,000 1,500 150MByte/s 150MByte/s
100GB-500GB SSD plan 10,000 2,000 200MByte/s 200MByte/s

Tokyo Zone No. 1 Ishikari Zone No. 1 (new plan) Ishikari Zone No. 2 (when "iscsi5" is included in the storage name)

Disk plan Reading IOPS
(disk → VM)
Writing data transfer bandwidth
(VM → disk)
Reading data transfer bandwidth
(disk → VM)
Writing data transfer bandwidth
(VM → disk)
20GB-4TB standard plan 2,000 500 64MByte/s 64MByte/s
20GB SSD plan 4,000 1,500 100MBytes/s 100MBytes/s
40GB SSD plan 4,000 1,500 100MBytes/s 100MBytes/s
100GB SSD plan 7,000 3,000 150MByte/s 150MByte/s
250GB SSD plan 7,000 3,000 150MByte/s 150MByte/s
500GB SSD plan 10,000 6,000 200MByte/s 200MByte/s
1TB SSD plan 10,000 6,000 200MByte/s 200MByte/s
2TB SSD plan 10,000 6,000 200MByte/s 200MByte/s
4TB SSD plan 10,000 6,000 200MByte/s 200MByte/s

*The numbers listed in each table are limit value. There is no guarantee that performance will always be maintained up until these upper limits.

Is it possible to add multiple disks to the server and use RAID configuration?

It is possible to use the software RAID. However, for the following reasons, it is not recommended for SAKURA Cloud.

  • A maximum of three disks can be connected to one server. Therefore, the possible RAID configuration patterns are limited.
  • Data backup in storage differs for each storage server. Also, during recovery from the backup data, the backup acquisition time of each additional disk differs. This makes restoring impossible in some cases

Are measures taken to prevent data leakage from disks which were deleted (contracts cancelled)?

After deletion, “0” data writing and formatting is performed for the entire disk space assigned to the customer. Data prior to deletion cannot be read, so there is no need to worry about data leakage.

When multiple disks are connected to the server, problems occur such as an unintended disks becoming the startup disk or being mounted on a separate partition. What is the cause of these problems?

A mechanism exists in which a disk possesses a unique UUID in the partition information and it is possible to identify each disk by boot loader. However, if disks copied using the disk copy or archive operation are connected, the UUID becomes redundant, and it is not possible to identify which disk should be mounted to which lable (partition). As a result, there are cases in which startup is not performed from the intended disk or a disk is mounted to a separate partition.

One solution is to change the disk UUID after copying in order to avoid duplication. As shown below, in the case of Linux, you can change the disk UUID by using the tune2fs command which changes the settings information for the file system and the uuidgen command which generates a unique UUID.

# tune2fs -U `uuidgen` /dev/sda1

*The final command line argument is the applicable disk device name.

The UUID for each connected disk can also be checked using the blkid command.

# blkid

Also, to enable changes to UUID at the time of restarting, execute the grub2-mkconfig or update-grub command to update the GRUB settings file. (Please refer to the appropriate GRUM document for the OS which you use.) Also, please correct this setting when specifying /etc/fstab for UUID.