* [linux-lvm] Best Practices deploying LVM @ 2009-10-29 23:45 Abraham Pérez 2009-10-29 23:58 ` Chris Cox 2009-10-30 0:00 ` Ray Morris 0 siblings, 2 replies; 7+ messages in thread From: Abraham Pérez @ 2009-10-29 23:45 UTC (permalink / raw) To: LVM general discussion and development [-- Attachment #1: Type: text/plain, Size: 584 bytes --] Hi everyone, I'm looking for some whitepapper or similar document to find any kind of best practices using LVM. For example, usually i make only one volume group in each server and inside it I create different logical volumes for different purposes, but talking with one colleague, we discover that he makes one volume group for each logical volume (more or less)... so my final question is: in performance terms, what configuration is more efficient and why? Please excuse my writen english, but I don't use it very often. Thanks for your attention, Abraham Pérez [-- Attachment #2: Type: text/html, Size: 611 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [linux-lvm] Best Practices deploying LVM 2009-10-29 23:45 [linux-lvm] Best Practices deploying LVM Abraham Pérez @ 2009-10-29 23:58 ` Chris Cox 2009-10-30 0:00 ` Ray Morris 1 sibling, 0 replies; 7+ messages in thread From: Chris Cox @ 2009-10-29 23:58 UTC (permalink / raw) To: LVM general discussion and development On Fri, 2009-10-30 at 00:45 +0100, Abraham Pérez wrote: > Hi everyone, > > I'm looking for some whitepapper or similar document to find any kind > of best practices using LVM. > > For example, usually i make only one volume group in each server and > inside it I create different logical volumes for different purposes, > but talking with one colleague, we discover that he makes one volume > group for each logical volume (more or less)... so my final question > is: in performance terms, what configuration is more efficient and > why? Define "efficient"... anyhow, the idea of a volume group is to present a pool of storage. So making a volume group per logical volume sort of defeats the intended purpose. So... a volume group has more to do with defining a class of storage pool. Ideally physical volumes inside of a single volume group have some kind of relationship (e.g. maybe they are all of the same speed or type or raid, etc). It's common for low end systems to have just one volume group. However, you COULD segment storage pool types by function. Thus you could have a System volume group for the OS volumes and a Data volume group for user data (just an example). There is a lot of ways to look at it. Personally, just because of pvmove, I see physical volumes as whole disks and not a myriad of piece meal partitions. That way you get the potential ability to move data off of a physical volume in a volume group to free areas on different drives in that same group and remove a drive from the volume group and from the system (e.g. think of upgrading the size of drives you use inside of a volume group... you could use this to upgrade the drives without having to necessarily take anything down). So my best practices... 1. Use multiple volume groups to define classes of storage. 2. Use full disk physical volumes over partitions. 3. I like unique naming of volume groups just so that if a drive lands else where, and it presents itself to the system, it will not collide with existing volume group names. (but there is good reason for not doing this... and really only a factor if you have a tendency to throw drives into different computers all of the time) > > Please excuse my writen english, but I don't use it very often. I use english all of the time.... it doesn't seem to help. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [linux-lvm] Best Practices deploying LVM 2009-10-29 23:45 [linux-lvm] Best Practices deploying LVM Abraham Pérez 2009-10-29 23:58 ` Chris Cox @ 2009-10-30 0:00 ` Ray Morris 2009-10-30 0:42 ` malahal 1 sibling, 1 reply; 7+ messages in thread From: Ray Morris @ 2009-10-30 0:00 UTC (permalink / raw) To: LVM general discussion and development I don't know about a whitepaper, but I can address your example. > he makes one volume group for each logical volume (more or less) If each one has one volume, that's not exactly a volume GROUP, is it? If groups and volumes are basically synomous, he gives up all the benfits of groups. In fact, he gives up most of the benefits of logical volumes, since each PV has to be in one group, and each VG is one LV, you're left with one LV per PV - might as well just use partitions directly. -- Ray Morris support@bettercgi.com On 10/29/2009 06:45:39 PM, Abraham P�rez wrote: > Hi everyone, > > I'm looking for some whitepapper or similar document to find any kind > of > best practices using LVM. > > For example, usually i make only one volume group in each server and > inside > it I create different logical volumes for different purposes, but > talking > with one colleague, we discover that he makes one volume group for > each > logical volume (more or less)... so my final question is: in > performance > terms, what configuration is more efficient and why? > > Please excuse my writen english, but I don't use it very often. > > Thanks for your attention, > Abraham P�rez > ------quoted attachment------ > _______________________________________________ > linux-lvm mailing list > linux-lvm@redhat.com > https://www.redhat.com/mailman/listinfo/linux-lvm > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [linux-lvm] Best Practices deploying LVM 2009-10-30 0:00 ` Ray Morris @ 2009-10-30 0:42 ` malahal 2009-10-30 8:52 ` Abraham Pérez 0 siblings, 1 reply; 7+ messages in thread From: malahal @ 2009-10-30 0:42 UTC (permalink / raw) To: linux-lvm Ray Morris [support@bettercgi.com] wrote: > I don't know about a whitepaper, but I can address > your example. > > > he makes one volume group for each logical volume (more or less) > > If each one has one volume, that's not exactly a volume > GROUP, is it? If groups and volumes are basically synomous, > he gives up all the benfits of groups. In fact, he gives > up most of the benefits of logical volumes, since each PV > has to be in one group, and each VG is one LV, you're left > with one LV per PV - might as well just use partitions > directly. I agree, you lose some flexibility but it has some advantage compared to plain partitions without LVM. E.g. he can make a file system larger than any disk with multiple disks in the above LVM (one LV per VG) configuration. There are other advantages. I am not sure the reason for making only one LV per VG though! Thanks, Malahal. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [linux-lvm] Best Practices deploying LVM 2009-10-30 0:42 ` malahal @ 2009-10-30 8:52 ` Abraham Pérez 2009-10-30 19:46 ` Ray Morris 0 siblings, 1 reply; 7+ messages in thread From: Abraham Pérez @ 2009-10-30 8:52 UTC (permalink / raw) To: LVM general discussion and development [-- Attachment #1: Type: text/plain, Size: 2440 bytes --] Thanks for the instant answers! Well... I'll try to explain myself better. I'm working in a client who have a lot of servers running under VMware. This client have a lot of problems with the storage, because they never have enough space so when they have to allocate disk in servers, they add small virtual hard disks with, for example, 5 or 10GB. Then for the OS installation, we follow the basic schema based on disk partitions (/dev/sda1 pointing to / with ext3, /dev/sda2 pointing to /home and so on) and for the applications data, we use VG and LV pointing to /opt The client have some applications who need a lot of mountpoints, so my colleague adds 1-3 LV per VG (aproximated) and I only create only one VG and inside it, different LVs. With this infrastructure, we have to discard different kinds of hard disk because they're exactly the same... and we have that doubt: what schema is better and why, discarding concept things like a volume group was designed to be a group, because we're looking for good reasons based in performance of future actions, it's not important... or am I mistaken??? I don't know if I explained myself very well, so thanks all anyway! Regards, Abraham Pérez 2009/10/30 <malahal@us.ibm.com> > Ray Morris [support@bettercgi.com] wrote: > > I don't know about a whitepaper, but I can address > > your example. > > > > > he makes one volume group for each logical volume (more or less) > > > > If each one has one volume, that's not exactly a volume > > GROUP, is it? If groups and volumes are basically synomous, > > he gives up all the benfits of groups. In fact, he gives > > up most of the benefits of logical volumes, since each PV > > has to be in one group, and each VG is one LV, you're left > > with one LV per PV - might as well just use partitions > > directly. > > I agree, you lose some flexibility but it has some advantage compared to > plain partitions without LVM. E.g. he can make a file system larger than > any disk with multiple disks in the above LVM (one LV per VG) > configuration. There are other advantages. I am not sure the reason for > making only one LV per VG though! > > Thanks, Malahal. > > _______________________________________________ > linux-lvm mailing list > linux-lvm@redhat.com > https://www.redhat.com/mailman/listinfo/linux-lvm > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ > [-- Attachment #2: Type: text/html, Size: 3135 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [linux-lvm] Best Practices deploying LVM 2009-10-30 8:52 ` Abraham Pérez @ 2009-10-30 19:46 ` Ray Morris 2009-10-30 21:03 ` Abraham Pérez 0 siblings, 1 reply; 7+ messages in thread From: Ray Morris @ 2009-10-30 19:46 UTC (permalink / raw) To: LVM general discussion and development With your way, you can add a new 2GB disk and use half of it for /home, half for /opt, if you wish. You can also leave some of it unused and expand any LV in the future as needed. That's one important reason why most people use voluem groups as groups - contianing several volumes. Does your colleague know of ANY advantage to creating a bunch of different groups? If not, your way wins - it has advantages over his way, and his way has no advantage. > we have to discard different kinds of hard disk > because they're exactly the same I have no idea what this is supposed to mean. Different kinds of hard disk are exactly the same? If this is supposed to mean "we are not able to use different types of drives for different partitions", I can understand that. However, for what purpose would you use different types of disks? Perhaps he wants a fast disk for one partition, and a large, cheap disk for another partition? If you use two cheap disks in a striped LV it's going to be faster AND cheaper than the "fast drive" option. MAYBE if you were going to use a super fast RAID array of SSD drives for some small amount of data, but not if we're talking standard magnetic hard drives. > a lot of servers running under VMware. This client > have a lot of problems with the storage, because they > never have enough space so when they have to allocate > disk in servers, they add small virtual hard disks > with, for example, 5 or 10GB. lvextend. Ours resize automatically on the fly, using a cron job that checks to see if any virtual servers need more space. > discarding concept things like a volume group was designed > to be a group, because we're looking for good reasons "Concept reasons", like using the tool designed for the job, may be the very best reasons because that one reason actually covers the hundred reasons that don't come to mind immediately. You don't know what issues you'll run into next week or next month, but you can bet you won't be the first one - other people will have had the same issues, and will use the standard tools for the standard purposes to solve that problem. Better for you if you can use the same solutions. Also, there are certain features and optimizations you don't know about, but you'll gain from those grouping features if you use groups as groups. No one knows about the features and optimizations that will be added next year, but if you use the tools the way they were designed you'll benefit from future enhancements that allow you to better use them for their purposes. -- Ray Morris support@bettercgi.com Strongbox - The next generation in site security: http://www.bettercgi.com/strongbox/ Throttlebox - Intelligent Bandwidth Control http://www.bettercgi.com/throttlebox/ Strongbox / Throttlebox affiliate program: http://www.bettercgi.com/affiliates/user/register.php On 10/30/2009 03:52:43 AM, Abraham P�rez wrote: > Thanks for the instant answers! > > Well... I'll try to explain myself better. I'm working in a client > who have > a lot of servers running under VMware. This client have a lot of > problems > with the storage, because they never have enough space so when they > have to > allocate disk in servers, they add small virtual hard disks with, for > example, 5 or 10GB. > > Then for the OS installation, we follow the basic schema based on disk > partitions (/dev/sda1 pointing to / with ext3, /dev/sda2 pointing to > /home > and so on) and for the applications data, we use VG and LV pointing > to /opt > > The client have some applications who need a lot of mountpoints, so my > colleague adds 1-3 LV per VG (aproximated) and I only create only one > VG and > inside it, different LVs. With this infrastructure, we have to > discard > different kinds of hard disk because they're exactly the same... and > we have > that doubt: what schema is better and why, discarding concept things > like a > volume group was designed to be a group, because we're looking for > good > reasons based in performance of future actions, it's not important... > or am > I mistaken??? > > I don't know if I explained myself very well, so thanks all anyway! > > Regards, > Abraham P�rez > > 2009/10/30 <malahal@us.ibm.com> > > > Ray Morris [support@bettercgi.com] wrote: > > > I don't know about a whitepaper, but I can address > > > your example. > > > > > > > he makes one volume group for each logical volume (more or less) > > > > > > If each one has one volume, that's not exactly a volume > > > GROUP, is it? If groups and volumes are basically synomous, > > > he gives up all the benfits of groups. In fact, he gives > > > up most of the benefits of logical volumes, since each PV > > > has to be in one group, and each VG is one LV, you're left > > > with one LV per PV - might as well just use partitions > > > directly. > > > > I agree, you lose some flexibility but it has some advantage > compared to > > plain partitions without LVM. E.g. he can make a file system larger > than > > any disk with multiple disks in the above LVM (one LV per VG) > > configuration. There are other advantages. I am not sure the > reason for > > making only one LV per VG though! > > > > Thanks, Malahal. > > > > _______________________________________________ > > linux-lvm mailing list > > linux-lvm@redhat.com > > https://www.redhat.com/mailman/listinfo/linux-lvm > > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ > > > ------quoted attachment------ > _______________________________________________ > linux-lvm mailing list > linux-lvm@redhat.com > https://www.redhat.com/mailman/listinfo/linux-lvm > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [linux-lvm] Best Practices deploying LVM 2009-10-30 19:46 ` Ray Morris @ 2009-10-30 21:03 ` Abraham Pérez 0 siblings, 0 replies; 7+ messages in thread From: Abraham Pérez @ 2009-10-30 21:03 UTC (permalink / raw) To: LVM general discussion and development [-- Attachment #1: Type: text/plain, Size: 6465 bytes --] Well, finally my english results a barrier for explain myself (lol). Anyway, now I have another point of view, so thank you all very much for your assistance!!! 2009/10/30 Ray Morris <support@bettercgi.com> > With your way, you can add a new 2GB disk and use > half of it for /home, half for /opt, if you wish. > You can also leave some of it unused and expand > any LV in the future as needed. That's one important > reason why most people use voluem groups as groups - > contianing several volumes. Does your colleague know > of ANY advantage to creating a bunch of different > groups? If not, your way wins - it has advantages > over his way, and his way has no advantage. > > > we have to discard different kinds of hard disk >> because they're exactly the same >> > > I have no idea what this is supposed to mean. > Different kinds of hard disk are exactly the same? > If this is supposed to mean "we are not able to > use different types of drives for different > partitions", I can understand that. However, > for what purpose would you use different types > of disks? Perhaps he wants a fast disk for one > partition, and a large, cheap disk for another > partition? If you use two cheap disks in a > striped LV it's going to be faster AND cheaper > than the "fast drive" option. MAYBE if you were > going to use a super fast RAID array of SSD drives > for some small amount of data, but not if we're > talking standard magnetic hard drives. > > > > a lot of servers running under VMware. This client >> have a lot of problems with the storage, because they >> never have enough space so when they have to allocate >> disk in servers, they add small virtual hard disks >> with, for example, 5 or 10GB. >> > > lvextend. Ours resize automatically on the fly, using > a cron job that checks to see if any virtual servers > need more space. > > > discarding concept things like a volume group was designed >> to be a group, because we're looking for good reasons >> > > "Concept reasons", like using the tool designed for the > job, may be the very best reasons because that one reason > actually covers the hundred reasons that don't come to mind > immediately. You don't know what issues you'll run into > next week or next month, but you can bet you won't be the > first one - other people will have had the same issues, > and will use the standard tools for the standard purposes > to solve that problem. Better for you if you can use > the same solutions. Also, there are certain features > and optimizations you don't know about, but you'll gain > from those grouping features if you use groups as groups. > No one knows about the features and optimizations that > will be added next year, but if you use the tools the > way they were designed you'll benefit from future > enhancements that allow you to better use them for their > purposes. > -- > > Ray Morris > support@bettercgi.com > > Strongbox - The next generation in site security: > http://www.bettercgi.com/strongbox/ > > Throttlebox - Intelligent Bandwidth Control > http://www.bettercgi.com/throttlebox/ > > Strongbox / Throttlebox affiliate program: > http://www.bettercgi.com/affiliates/user/register.php > > > > On 10/30/2009 03:52:43 AM, Abraham Pérez wrote: > >> Thanks for the instant answers! >> >> Well... I'll try to explain myself better. I'm working in a client who >> have >> a lot of servers running under VMware. This client have a lot of problems >> with the storage, because they never have enough space so when they have >> to >> allocate disk in servers, they add small virtual hard disks with, for >> example, 5 or 10GB. >> >> Then for the OS installation, we follow the basic schema based on disk >> partitions (/dev/sda1 pointing to / with ext3, /dev/sda2 pointing to /home >> and so on) and for the applications data, we use VG and LV pointing to >> /opt >> >> The client have some applications who need a lot of mountpoints, so my >> colleague adds 1-3 LV per VG (aproximated) and I only create only one VG >> and >> inside it, different LVs. With this infrastructure, we have to discard >> different kinds of hard disk because they're exactly the same... and we >> have >> that doubt: what schema is better and why, discarding concept things like >> a >> volume group was designed to be a group, because we're looking for good >> reasons based in performance of future actions, it's not important... or >> am >> I mistaken??? >> >> I don't know if I explained myself very well, so thanks all anyway! >> >> Regards, >> Abraham Pérez >> >> 2009/10/30 <malahal@us.ibm.com> >> >> > Ray Morris [support@bettercgi.com] wrote: >> > > I don't know about a whitepaper, but I can address >> > > your example. >> > > >> > > > he makes one volume group for each logical volume (more or less) >> > > >> > > If each one has one volume, that's not exactly a volume >> > > GROUP, is it? If groups and volumes are basically synomous, >> > > he gives up all the benfits of groups. In fact, he gives >> > > up most of the benefits of logical volumes, since each PV >> > > has to be in one group, and each VG is one LV, you're left >> > > with one LV per PV - might as well just use partitions >> > > directly. >> > >> > I agree, you lose some flexibility but it has some advantage compared to >> > plain partitions without LVM. E.g. he can make a file system larger than >> > any disk with multiple disks in the above LVM (one LV per VG) >> > configuration. There are other advantages. I am not sure the reason for >> > making only one LV per VG though! >> > >> > Thanks, Malahal. >> > >> > _______________________________________________ >> > linux-lvm mailing list >> > linux-lvm@redhat.com >> > https://www.redhat.com/mailman/listinfo/linux-lvm >> > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ >> > >> >> > ------quoted attachment------ > > _______________________________________________ >> linux-lvm mailing list >> linux-lvm@redhat.com >> https://www.redhat.com/mailman/listinfo/linux-lvm >> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ >> > > > _______________________________________________ > linux-lvm mailing list > linux-lvm@redhat.com > https://www.redhat.com/mailman/listinfo/linux-lvm > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ > [-- Attachment #2: Type: text/html, Size: 9043 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2009-10-30 21:04 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-10-29 23:45 [linux-lvm] Best Practices deploying LVM Abraham Pérez 2009-10-29 23:58 ` Chris Cox 2009-10-30 0:00 ` Ray Morris 2009-10-30 0:42 ` malahal 2009-10-30 8:52 ` Abraham Pérez 2009-10-30 19:46 ` Ray Morris 2009-10-30 21:03 ` Abraham Pérez
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.