Vultr, Block Storage CentOS

AdamF

@travisdh1 2. is the way I was leaning as well, since it just seems cleaner.

I'll post my disk details in the next post.

AdamF

It's worth noting that I have already upgraded this server once, and expanded the disk once already. Just not with block storage.

Relevant disk stats:

[root@xxx ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_data-lv_root
                       55G   32G   20G  62% /
tmpfs                 1.9G     0  1.9G   0% /dev/shm
/dev/vda1             477M   32M  420M   8% /boot

[root@xxx ~]# vgs
  VG      #PV #LV #SN Attr   VSize  VFree
  vg_data   2   2   0 wz--n- 59.50g    0

[root@xxx ~]# lsblk
NAME                       MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda                        252:0    0   60G  0 disk
├─vda1                     252:1    0  500M  0 part /boot
├─vda2                     252:2    0 39.5G  0 part
│ ├─vg_data-lv_root (dm-0) 253:0    0 55.6G  0 lvm  /
│ └─vg_data-lv_swap (dm-1) 253:1    0    4G  0 lvm  [SWAP]
└─vda3                     252:3    0   20G  0 part
  └─vg_data-lv_root (dm-0) 253:0    0 55.6G  0 lvm  /
sr0                         11:0    1 1024M  0 rom


[root@xxx ~]# pvdisplay
  --- Physical volume ---
  PV Name               /dev/vda2
  VG Name               vg_data
  PV Size               39.51 GiB / not usable 3.00 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              10114
  Free PE               0
  Allocated PE          10114
  PV UUID               ZPKVBC-lzNg-UiHV-UaCL-V2Ep-1FIo-rxYHsC

  --- Physical volume ---
  PV Name               /dev/vda3
  VG Name               vg_data
  PV Size               20.00 GiB / not usable 3.77 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              5119
  Free PE               0
  Allocated PE          5119
  PV UUID               Inu87j-N6Vb-lQ6e-CsUj-3JZi-CQBD-RREPVT

  [root@xxx ~]# vgdisplay
  --- Volume group ---
  VG Name               vg_data
  System ID
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  5
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               2
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               59.50 GiB
  PE Size               4.00 MiB
  Total PE              15233
  Alloc PE / Size       15233 / 59.50 GiB
  Free  PE / Size       0 / 0
  VG UUID               WETe1B-n9cD-DwP9-T9k1-91fZ-wm8Z-5KTVuG


  [root@xxx ~]# lvdisplay
  --- Logical volume ---
  LV Path                /dev/vg_data/lv_root
  LV Name                lv_root
  VG Name                vg_data
  LV UUID                6aLAzL-8vbD-zjlF-yX10-b516-3gkv-6aP9A9
  LV Write Access        read/write
  LV Creation host, time xxx.xxx.xxx.xxx.vultr.com, 2017-05-08 18:05:33 -0400
  LV Status              available
  # open                 1
  LV Size                55.57 GiB
  Current LE             14225
  Segments               2
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0

  --- Logical volume ---
  LV Path                /dev/vg_data/lv_swap
  LV Name                lv_swap
  VG Name                vg_data
  LV UUID                IxfAkn-FtI3-0o7Y-TcM9-DTeF-7NV2-sNLfde
  LV Write Access        read/write
  LV Creation host, time xxx.xxx.xxx.xxx.vultr.com, 2017-05-08 18:05:35 -0400
  LV Status              available
  # open                 1
  LV Size                3.94 GiB
  Current LE             1008
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:1

travisdh1

@fuznutz04 How much recording to you expect to be doing in the next 2 weeks? 20G is a LOT of call recordings. I'd keep an eye on it, and add block storage if you need it. Like I said, shouldn't take more than 5 minutes.

Do you know what the file system is? I think the default for CentOS is xfs, but I'd rather be sure. cat /etc/fstab

AdamF

@travisdh1 said in Vultr, Block Storage CentOS:

cat /etc/fstab

[root@xxx ~]# cat /etc/fstab

#
# /etc/fstab
# Created by anaconda on Mon May  8 18:05:59 2017
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/vg_data-lv_root /                       ext4    defaults        1 1
UUID=2d9dfe5e-db4c-4936-b234-3dbdf62a90e1 /boot                   ext4    defaults        1 2
/dev/mapper/vg_data-lv_swap swap                    swap    defaults        0 0
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0

AdamF

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

travisdh1

@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.

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.