Vultr, Block Storage CentOS

AdamF

@travisdh1 said in Vultr, Block Storage CentOS:

@fuznutz04 said in Vultr, Block Storage CentOS:

@travisdh1 This system has high usage. I fully expect it to fill up rapidly.

Ah, ok. Yeah, block is probably your most efficient use of resources for this then.
vgcreate /dev/sdb #I'm assuming the new block storage will show up as an sd device
vgextend /dev/sdb vg_data
lvextend lv_root -l +95%FREE
resize2fs /dev/vg_data/lv_root
Shouldn't take much time at all. As always, we'd want to have a backup available before touching storage things.

I'm going to give this a test on a test system just because I have never dealt with Vultr block storage. Then if all is well, I'll give this a go.

I'm assuming if there is an issue with block storage (like there was earlier this week with the NJ data center) that it would cause the VPS to crash. Hopefully this isn't the case.

AdamF

@travisdh1 Thank you for this BTW. I'll probably do this this weekend, but wanted to get prepared and wrap my head around this first.

travisdh1

@fuznutz04 said in Vultr, Block Storage CentOS:

@travisdh1 Thank you for this BTW. I'll probably do this this weekend, but wanted to get prepared and wrap my head around this first.

Glad to help. LVM is one of my big knowledge wheelhouses if you can't tell.

AdamF

@travisdh1 said in Vultr, Block Storage CentOS:

@fuznutz04 said in Vultr, Block Storage CentOS:

@travisdh1 Thank you for this BTW. I'll probably do this this weekend, but wanted to get prepared and wrap my head around this first.

Glad to help. LVM is one of my big knowledge wheelhouses if you can't tell.

I noticed. Before I met you this year, I watched your LVM presentation from Mangocon 2016.

stacksofplates

@travisdh1 said in Vultr, Block Storage CentOS:

Because you're using LVM, options 2 and 3 are both doable. To me 2 is quicker and easier, but I've used LVM long enough that I know how to do most of that off the top of my head. The only thing I normally have to lookup is how to expand the file system, because the process tends to be a little different depending on the file system. Real quick here.
pvcreate /dev/device
vgextend volume_group_name /dev/device
lvextend logical_volume_name -l +95%FREE
xfs_growfs /dev/volume_group_name/logical_volume_name
done. Shouldn't take but 5 minutes, if that.

Edit: I normally go with either 90% or 95% of the available space in the volume group to keep space available for a local snapshot.

If you pass -r to lvextend it will auto resize the filesystem. That way you don't need to remember the differences between them.

AdamF

@stacksofplates said in Vultr, Block Storage CentOS:

@travisdh1 said in Vultr, Block Storage CentOS:
Because you're using LVM, options 2 and 3 are both doable. To me 2 is quicker and easier, but I've used LVM long enough that I know how to do most of that off the top of my head. The only thing I normally have to lookup is how to expand the file system, because the process tends to be a little different depending on the file system. Real quick here.
pvcreate /dev/device
vgextend volume_group_name /dev/device
lvextend logical_volume_name -l +95%FREE
xfs_growfs /dev/volume_group_name/logical_volume_name
done. Shouldn't take but 5 minutes, if that.

Edit: I normally go with either 90% or 95% of the available space in the volume group to keep space available for a local snapshot.
If you pass -r to lvextend it will auto resize the filesystem. That way you don't need to remember the differences between them.

So you are saying instead of this:

 lvextend logical_volume_name -l +95%FREE

Use this:?

lvextend logical_volume_name -r

travisdh1

@fuznutz04 said in Vultr, Block Storage CentOS:

@stacksofplates said in Vultr, Block Storage CentOS:
@travisdh1 said in Vultr, Block Storage CentOS:
Because you're using LVM, options 2 and 3 are both doable. To me 2 is quicker and easier, but I've used LVM long enough that I know how to do most of that off the top of my head. The only thing I normally have to lookup is how to expand the file system, because the process tends to be a little different depending on the file system. Real quick here.
pvcreate /dev/device
vgextend volume_group_name /dev/device
lvextend logical_volume_name -l +95%FREE
xfs_growfs /dev/volume_group_name/logical_volume_name
done. Shouldn't take but 5 minutes, if that.

Edit: I normally go with either 90% or 95% of the available space in the volume group to keep space available for a local snapshot.
If you pass -r to lvextend it will auto resize the filesystem. That way you don't need to remember the differences between them.
So you are saying instead of this:
 lvextend logical_volume_name -l +95%FREE
Use this:?
lvextend logical_volume_name -r

More like

lvextend logical_volume_name -l +95%FREE -r

AdamF

@travisdh1 Thanks

travisdh1

@fuznutz04 said in Vultr, Block Storage CentOS:

@travisdh1 Thanks

If you want to just look at how powerful LVM has become through the years, you should run lvm and look at the help screens sometime. That's how I dived into it initially at least.

AdamF

@travisdh1 Run LVM? You mean just look at the man pages? Or are you referring to something else?

travisdh1

@fuznutz04 said in Vultr, Block Storage CentOS:

@travisdh1 Run LVM? You mean just look at the man pages? Or are you referring to something else?

It's got a whole environment just for its self. Literally just lvm on a command line.

AdamF

@travisdh1 Ah nice. Will do. I want to learn a lot more about it, so I'll take your advice.

travisdh1

@fuznutz04 said in Vultr, Block Storage CentOS:

@travisdh1 Ah nice. Will do. I want to learn a lot more about it, so I'll take your advice.

The amount of options is almost staggering. Even more, ZFS, brtfs and a number of other filesystems have just as many options and choices to make.

AdamF

@travisdh1 said in Vultr, Block Storage CentOS:

@fuznutz04 said in Vultr, Block Storage CentOS:

@travisdh1 Ah nice. Will do. I want to learn a lot more about it, so I'll take your advice.

The amount of options is almost staggering. Even more, ZFS, brtfs and a number of other filesystems have just as many options and choices to make.

Yeah, one at a time. I've worked with ZFS in the past, but it was when I was using FreeNAS back in the day.

travisdh1

@fuznutz04 said in Vultr, Block Storage CentOS:

@travisdh1 said in Vultr, Block Storage CentOS:

@fuznutz04 said in Vultr, Block Storage CentOS:

@travisdh1 Ah nice. Will do. I want to learn a lot more about it, so I'll take your advice.

The amount of options is almost staggering. Even more, ZFS, brtfs and a number of other filesystems have just as many options and choices to make.

Yeah, one at a time. I've worked with ZFS in the past, but it was when I was using FreeNAS back in the day.

At least it's all the same stuff, just called something different for the most part.

AdamF

@travisdh1 Right. Seeing as how the world is built on storage systems, I need to dig in a little.

That's all for now. Good night NotJengaMaster.

travisdh1

@fuznutz04 said in Vultr, Block Storage CentOS:

@travisdh1 Right. Seeing as how the world is built on storage systems, I need to dig in a little.

That's all for now. Good night NotJengaMaster.

whispers it's the glasses

AdamF

@travisdh1 So on second thought, I'm thinking it might be a better approach to redirect the call recordings to the block device directly, without extending the LVM volume to the block device. So it would be like this:

Attach block device and create partition and file system.
Mount the new device to a new directory (/callrecordings)
In FreePBX, point the call recordings to this new directory.

This way, the VPS disk, is still completely separate from the block device disk. In my head, this just seems cleaner, and has less potential for errors if the block device is ever unavailable.

Thoughts?

scottalanmiller

@fuznutz04 said in Vultr, Block Storage CentOS:

@travisdh1 So on second thought, I'm thinking it might be a better approach to redirect the call recordings to the block device directly, without extending the LVM volume to the block device. So it would be like this:

Attach block device and create partition and file system.
Mount the new device to a new directory (/callrecordings)
In FreePBX, point the call recordings to this new directory.

This way, the VPS disk, is still completely separate from the block device disk. In my head, this just seems cleaner, and has less potential for errors if the block device is ever unavailable.

Thoughts?

Yes, that makes way more sense.

AdamF

@scottalanmiller said in Vultr, Block Storage CentOS:

@fuznutz04 said in Vultr, Block Storage CentOS:

@travisdh1 So on second thought, I'm thinking it might be a better approach to redirect the call recordings to the block device directly, without extending the LVM volume to the block device. So it would be like this:

Attach block device and create partition and file system.
Mount the new device to a new directory (/callrecordings)
In FreePBX, point the call recordings to this new directory.

This way, the VPS disk, is still completely separate from the block device disk. In my head, this just seems cleaner, and has less potential for errors if the block device is ever unavailable.

Thoughts?

Yes, that makes way more sense.

The only thing that made me think of that was because about 2 weeks ago Vultr NJ had some issues with block storage. If they have an issue again, at least I could still boot the VM. (although I would have to remove the block device from the fstab. But then, It should boot fine I suppose. (crosses fingers)