Two Peas in a Pod
If you look at the first "stage" in my drawing (Figure 1), you'll notice that I didn't call the 10GB chunks "drives"; I called them physical volumes. That's because although it's certainly possible to use a physical drive as a physical volume in LVM, it's not a requirement. In fact, it's not even the most common scenario. In most production environments, LVM is used in combination with RAID. Whether that's hardware-based RAID or software-based RAID, having your underlying physical volumes exist as RAID devices is ideal.
As someone who has had problems with hardware-based RAID arrays, I tend to lean toward software-based RAID in my systems. That's certainly a matter of personal preference, but it's good to know that since software-based RAID and LVM both operate at the kernel level, both are extremely efficient. Software-based RAID admittedly uses some CPU, especially when rebuilding arrays, but LVM uses very little. If I/O performance is of utmost importance for your purposes, it's worth doing some research and possibly testing before committing to any solution.
Although it's certainly possible to transition to an LVM system after
Linux is already installed, it's far more preferable to do so during
the initial setup. Most distributions allow for LVM setup to take place
during the installation process, and in the case of CentOS and RHEL,
LVM is used by default. Even if you're installing only onto a single,
non-RAID hard drive, setting up LVM allows you flexibility and expansion
opportunity later. Heck, it's possible to add RAID to a server later on,
then simply migrate the data from your original physical volume to the
RAID physical volume. That's far easier than using
dd, especially when
you'd like to keep your server running!
Because this is an introduction, let me start with a simplistic setup. Let's say you have two hard drives, /dev/sdb and /dev/sdc. With LVM, any block device can be used as a physical volume (PV), which means you can use either partitions or entire drives. If you need to have a "traditional" partition (in some cases, the /boot partition might need to be on a regular, non-LVM device), be sure to partition the drive before adding the physical volumes to your volume group. In this example, let's use the raw disks themselves.
Step 1: Create Physical Volumes
Once you have the block devices you want to add to your volume group
(again, keep referring to my drawing if the terms get confusing), you
need to establish them as LVM physical volumes. To do that, use the
pvcreate /dev/sdb pvcreate /dev/sdc
These commands configure the drives as potential candidates to be added
to a volume group. If you want to make sure it worked correctly, you
pvscan to show the status of any existing LVM
$ sudo pvdisplay --- Physical volume --- PV Name /dev/sdb VG Name PV Size 10.4 GiB / not usable 3.00 MiB Allocatable yes PE Size 4.00 MiB Total PE 4994 Free PE 4994 Allocated PE 0 PV UUID SRKAXh-EpYr-r2td-g0gA-31RA-fnfz-3qqGrO --- Physical volume --- PV Name /dev/sdc VG Name PV Size 10.4 GiB / not usable 3.00 MiB Allocatable yes PE Size 4.00 MiB Total PE 4994 Free PE 4994 Allocated PE 0 PV UUID t2cKru-IwMy-I8re-ADp2-vzFF-Tvh5-O4zMhI
And, the simpler
$ sudo pvscan PV /dev/sdb lvm2 [10.4 GiB] PV /dev/sdc lvm2 [10.4 GiB] Total: 2 [20.8 GiB] / in use: 0 [0 ] / in no VG: 2 [20.8 GiB]
Once you create the volume group and logical volumes, go ahead and run these commands again to see how the information changes. The differences should be obvious and should make sense.
|Nativ Disc||Sep 23, 2016|
|Android Browser Security--What You Haven't Been Told||Sep 22, 2016|
|The Many Paths to a Solution||Sep 21, 2016|
|Synopsys' Coverity||Sep 20, 2016|
|Naztech's Roadstar 5 Car Charger||Sep 16, 2016|
|RPi-Powered pi-topCEED Makes the Case as a Low-Cost Modular Learning Desktop||Sep 15, 2016|
- Android Browser Security--What You Haven't Been Told
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Nativ Disc
- The Many Paths to a Solution
- Naztech's Roadstar 5 Car Charger
- Synopsys' Coverity
- RPi-Powered pi-topCEED Makes the Case as a Low-Cost Modular Learning Desktop
- Securing the Programmer
- Identity: Our Last Stand
- Jose Dieguez Castro's Introduction to Linux Distros (Apress)
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide