[MUSIC] In this video you will learn about the shared attachment that you can do with block volumes as well as understand about the performance features available with block storage volumes. What do we mean by shared multi attach? When you have various block volumes created, you can attach them to compute instances by going to a compute instance page and attach volumes in the same AD as per the AD in which the compute instance is created. For example, this is an instance that is an AD one. If I go to the instance page and Look on attach block volumes and click attach, I get the option to attach any volume that is within the same ad. And you have two choices of instances and paravirtualized which we will discuss in performance which is coming up later in the same video. When you attach a volume to a instance, you have a choice to keep it read-write when you keep it as read-write, this is a single attach mode only you cannot attach the same volume to another instance. Whereas if you want the volume to be attached to multiple instances, you have a choice to use it in only read only mode or read-write mode. The idea about using read write more shareable is that when you want to have a cluster file system wherein multiple instances should be able to read and write to the volume, you can use this option. And remember, it is your responsibility to implement a cluster file system something like OCFS In the storage so that locking across multiple instances can be taken care with the net OCI doesn't give you anything out of the box to make it a read write locking mechanism within it. It is your responsibility to implement it. Whereas Read Only you don't need to bother because when it is read only locking is not applicable because It is not happening from multiple instances. When you are using this feature of multi attach, please remember, if you want to change the mode of attachment from read only multi attach or sharable to read write, you need to detach the volume from all instances And then attach it again in the new mode. That is how the set of this allows you to do it. And as I told you, you implement an OTFs or some cluster file system to avoid any corruption that might happen because multiple instances are writing to the same volume. The same volume can be attached. From the instance page by going to attached volumes, or you could go to a given block volume and from the block volume page also, you will be able to attach it to an instance just to show you that attaching block volumes to an instance can be done both from an instance page or from a Block volume page. Both options are there, and all the options are available here. The next section of this video is about performance. When we look at block storage or storage in general, we have IOPS in terms of the number of IO operations that can be done on a volume. The throughput which talks about how much of data will be sent and latency is the delay in accessing it. The block volume service provisions, the storage you need in terms of the size of storage volume, you want and, performance is dependent on the size, and it linearly scales up for every GB to a certain maximum. For example, if you create a volume from the block volume page, and I will show you quickly what is the performance specification that comes, let me give it some sample name. I will choose custom here and it is currently one terabyte in size. Now, we will come into the history options in a moment. Considering balanced it says it can get 25,000 I ops and 480 Mbps based on the rate of 60 I ops per GB and 480 kbps per GB But let's say I make it as 100 GB. The moment I make it 100 GB the rate of iops in Mbps remains the same, but depending on the size given it is increasing or decreasing for that purpose. But let's say I go and make it four terabytes. Look at the I ops here. It has not changed, from what it was for one terabyte because this is the maximum, your volume can get for the balanced specification. So the amount of IOPS and Throughput you get will depend on this volume size. And the total you can get from a volume depends on the performance specification you choose. And also remember, the total network bandwidth your compute instance gets depends on the shape. So if you're going to expect a lot of data transfer happening to block storage, your shapes should be able to accommodate so much of network bandwidth in the shape and I ops performance is dependent again on the instance type or shape as well as ice Cassie volumes. What do we mean by ice Cassie and paravirtualized? When you attach a volume to a compute instance, which you can do from the volume page from the block volume page or from the instance page, you have the choice of ice cozy or para virtualized, para virtualized is an option available only if you are attaching it to a VM instance, wherein the hypervisor runs the I scuzzy commands required to connect to the volume. Whereas, for both bare metal and virtual machines, you can use I scuzzy based option wherein. After attaching the volume to the instance, you need to get the I scuzzy commands and run them from an SSH connection in the compute to be able to connect to the volume from the instance. So that is a additional step required. So para virtualized gives you simpler management. Whereas Ice Cassie is where Oracle guarantees the SLA for Block Storage performance. So keep that in mind. In the next couple of slides we have some details about the performance metrics that you can achieve and automatic adjustment of performance is available if you enable auto tune performance. What is this auto tune performance? If you have a volume with you, and you click Edit, you have the ability to enable auto tune Auto Tune is dependent on the volume performance you choose. Fundamentally three choices you have for block volumes wherein if you choose balance then the per GB I ops and per GB kbps is given here. If you come into lower cost, the pricing is lesser because the kind of I ops and kbps or throughput you get is lesser higher performance costs a little more Were in the I ops and GBPs throughput is more. So, the amount of cost associated for the storage provision is one aspect plus the volume performance specification you give is an additional cost associated. If you choose lower cost, there is no additional cost, but if you go to balanced or higher performance based on the size of your volume, there would be an additional cost involved you need to keep in mind. And if you have attached multiple volumes to an instance keep in mind, the total amount of throughput you can achieve depends on the shape of the compute instance. The shape of the compute instance determines the total amount of network bandwidth it can handle with auto tune performance enabled in a volume. If you have chosen balanced or high performance on a volume, but the volume is currently not attached, then OCI will automatically set the volume performance to lower cost, till you attach it so that you don't pay for the, performance related costs associated. This is a feature which is built in and you have to enable it for using that functionality. Thus, you have the auto tune performance feature. And depending on the size of the volume that you provision, the maximum throughput maximum for one MB block size and eight KB block size is given Maximum I ops is given here and you can see up to around the 700 GB there is scaling of the speed and performance of the volume. But from 700 GB all the way to 32 GB, you get the same performance from a single volume. And what is given here is for the ICC based attachments. Remember I told you earlier itself, Oracle guarantees SLA for the block storage only for I scuzzy based attachments, not for para virtualized. They will be a little bit slower, some commands given here for you to test out read performance, write performance, or a mixed workload, you can run these tests on a compute instance that is having a block volume attached and check out how it is performing. But remember again, the total network bandwidth that the compute instance can use determine is determined by shape. So the if you have multiple volumes attached and you're doing a test or using it if the total network transfer that the compute instance needs is more than what is there in the shape. You might see a degradation in storage performance. Keep that in mind. So how do you determine the network bandwidth a compute instance gets is available as part of the shape specification you choose when you create a compute instance. So if I go to creating a compute instance and choose the change shape option. If I choose para vertinized, I see that the network bandwidth that it gives, is part of the shape itself, right? Similarly if I choose virtual machine, I see what is the network bandwidth that is given The network bandwidth includes the wieneke network for your application accessing any other resource plus the storage, from block storage. That's the aggregated bandwidth, the shape will support. That's about block storage performance. And with that, we come to the end of operations for Block Storage
