By using AWS re:Post, you agree to the Terms of Use

Questions tagged with Amazon Elastic Block Store

Sort by most recent

Browse through the questions and answers listed below or filter and sort to narrow down your results.

Understanding RDS throughput limits

I have trouble understanding what throughput limit(s) my RDS instance is supposed to have. Based on this [blog post](https://aws.amazon.com/blogs/database/making-better-decisions-about-amazon-rds-with-amazon-cloudwatch-metrics/): > An Amazon RDS instance has two types of throughput limits: Instance level and EBS volume level limits. > You can monitor instance level throughput with the metrics WriteThroughput and ReadThroughput. WriteThroughput is the average number of bytes written to disk per second. ReadThroughput is the average number of bytes read from disk per second. For example, a db.m4.16xlarge instance class supports 1,250-MB/s maximum throughput. The EBS volume throughput limit is 250 MiB/S for GP2 storage based on 16 KiB I/O size, and 1,000 MiB/s for Provisioned IOPS storage type. If you experience degraded performance due to a throughput bottleneck, you should validate both of these limits and modify the instance as needed. My RDS instance is of db.r6g.8xlarge type, which according to https://aws.amazon.com/rds/instance-types/ has 9000 Mbps (= 1125 MB/s) EBS dedicated bandwidth. On the other hand, according to https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html the underlying gp2 volume (5TB size) has a 250 MB/s throughput limit. So how are these two limits applied? Should I be able to reach close to 1125 MB/s or am I restricted to 250 MiB/s because of gp2 volume limit? In CloudWatch, during bulk write operations I have observed Total (Read + Write) Throughput momentarily reach ~ 1000 MB/s but mostly it was steady around 420 MB/s, i.e. somewhere in between the two limits.
2
answers
0
votes
582
views
asked 7 months ago

Is there a way to identify an EBS Volume inside a Linux EC2 instance using its volume ID ?

We are working on a use case where we need to map the disk label within the instance to the corresponding Volume ID in EBS. While performing some validations on some AMIs, we found that there is a difference between the behavior for Windows and Linux We have observed that the requirement we need is present in case of Windows (AMI Used: Windows_Server-2016-English-Full-Containers-2022.01.19) The following query yields the required result. Here the serial number of the disk is mapping to the EBS volume id The device driver for this instance was the AWS PV Storage Host Adapter ``` PS C:\Users\Administrator> Get-WmiObject Win32_DiskDrive | select-object -property serialnumber,index serialnumber index ------------ ----- vol0b44250cf530aa7f3 0 vol0f38be626e3137975 1 vol0bdc570ca980fb5fb 2 ``` However in case of Linux instances (AMI Used: amzn2-ami-kernel-5.10-hvm-2.0.20220121.0-x86_64-gp2) we are seeing that the EBS volume ID is not present within the disk metadata. We checked the following points inside the Linux: 1. Directories within /dev/disk: For the above AMI, the disk serial number is not being exposed in the /dev/disk/by-id directory. In the /dev/disk/by-path directory, there are entries present in the following format xen-vbd-51712 -> ../../xvda . Is it possible to map the string xen-vbd-51712 to the EBS volume ? 2. udevadm info <disk_label>: This is yielding the following information attached below, however the volume id is not present in the below. ``` P: /devices/vbd-51712/block/xvda N: xvda S: disk/by-path/xen-vbd-51712 S: sda E: DEVLINKS=/dev/disk/by-path/xen-vbd-51712 /dev/sda E: DEVNAME=/dev/xvda E: DEVPATH=/devices/vbd-51712/block/xvda E: DEVTYPE=disk E: ID_PART_TABLE_TYPE=gpt E: ID_PART_TABLE_UUID=08cf25fb-6b18-47c3-b4cb-fea548b3a3a2 E: ID_PATH=xen-vbd-51712 E: ID_PATH_TAG=xen-vbd-51712 E: MAJOR=202 E: MINOR=0 E: SUBSYSTEM=block E: TAGS=:systemd: E: USEC_INITIALIZED=34430 ``` As per https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/device_naming.html, the device name which is provided when the EBS volume is attached to the instance is not guaranteed to be the same which is visible inside the instance. ``` "When you attach a volume to your instance, you include a device name for the volume. This device name is used by Amazon EC2. The block device driver for the instance assigns the actual volume name when mounting the volume, and the name assigned can be different from the name that Amazon EC2 uses" ``` Since our use case can involve frequent addition/removal of EBS volumes on an instance, we wanted to find a deterministic method to identify a volume inside a Linux instance. Could you please let us know that if there is a route by which we can relate the disk within EC2 instance with the corresponding EBS volume id ?
1
answers
0
votes
855
views
asked 7 months ago