From: Green, Simon (Simon.Green@EU.ALTRIA.COM)
Date: Wed Apr 16 2003 - 06:00:18 EDT
It's not just VGDA updates that are slow: any LVM command is slow. Doing
"lsvg big_vg" would probably take a couple of minutes. The same goes for
other lsXX commands. Actual changes are even worse.
You may feel that you can live with the delay when you're running commands.
It does become very irritating, but maybe you can live with that. If you
have any monitoring scripts, bear in mind that they will take much longer to
run as well. (Imagine something listing LV info which used to take 5
minutes suddenly running for over an hour. Not good if you have it
scheduled once per hour!) Unless the script uses the "-L" flag it'll lock
the VG for all that time, as well, stopping other stuff getting at it.
When I first used a BigVG, I scripted the creation of all of the LVs and
filesystems. This was a total of about 800GB of disk capacity. Just to
create the couple of dozen filesystems - no data involved - took about eight
hours.
At DR tests I found that my normal recovery procedures - restvg from an
"empty" backup - simply did not work with BigVGs and I had to make other
arrangements. Again: creating a BigVG during DR tests took many times as
long as creating a normal VG, or even several VGs if I split the BigVG up.
When I ran into problems on one occasion - the perverse nature of the BigVG
caused one of my scripts to fail half-way through - trying to fix the
problem lost even more time. For a normal VG it would have been _maybe_ an
hour's work; for the BigVG it took something like six hours.
A BigVG may be a reasonable short-term solution to a specific problem.
However, I would STRONGLY recommend that make definite plans to split the VG
amongst several smaller ones.
> -----Original Message-----
> From: pSeries AIX Geek [mailto:aixgeek@YAHOO.COM]
> Sent: 15 April 2003 20:36
> To: aix-l@Princeton.EDU
> Subject: Re: Big VGs
>
>
> I'm back again with the big VG issue. My client wants
> to pursue them.
>
> The "drawbacks" with big VGs, as I see them are:
>
> 1. Slow VGDA updates.
> 2. Past AIX defects
> 3. Can't go back to AIX 4.3.0 or before.
>
> I don't consider #3 a problem, frankly.
>
> Can anyone point to any specific examples of how slow
> VGDA updates will take? If it's just a slowness
> issue, I think I can live with that (we'd only need to
> do VGDA updates only when we increase a file system,
> and those are generally planned).
>
> If there's a potential corruption issue, then that's a
> different story. The box is currently at AIX 4.3.3 ML
> 08, but it will probably go to AIX 5.1 or AIX 5.2 by
> the end of the summer.
>
> Can anyone relate any practical information about #1
> or #2, and can anyone relate any new issues I haven't
> considered?
>
> Quite honestly, it would be easiest for the customer
> to use big VGs if at all possible, but if it's really
> not feasible, then a second VG would be the route we'd
> take. This customer's environment is probably the
> "textbook" case for why IBM introduced the option.
>
>
> - pAG
>
> --- "Green, Simon" <Simon.Green@EU.ALTRIA.COM> wrote:
> > I would advise against this, unless you have no
> > choice.
> >
> > I set up a BigVG a few years ago and it was a major
> > pita!
> >
> > The big problem was that all LVM commands seemed to
> > take forever.
> > It's bad enough when you've got time for a cigarette
> > between
> > issuing lsvg and getting any output; it's worse when
> > a VG recovery
> > takes two hours instead of 20 minutes. (Trying to
> > get it to work
> > correctly at our Disaster Recovery tests was a
> > nightmare.)
> >
> > If you have to do it, treat it as a temporary
> > solution: try to
> > convince management to split the VG later on; it'll
> > be much less
> > painful in the long run.
> >
> > Simon Green
> > Altria ITSC Europe s.a.r.l.
> >
> > AIX-L Archive at
> > http://marc.theaimsgroup.com/?l=aix-l&r=1&w=2
> > AIX FAQ at http://www.faqs.org/faqs/aix-faq/
> >
> > N.B. Unsolicited email from vendors will not be
> > appreciated.
> >
> > > -----Original Message-----
> > > From: pSeries AIX Geek [mailto:aixgeek@YAHOO.COM]
> > > Sent: 08 April 2003 16:30
> > > To: aix-l@Princeton.EDU
> > > Subject: Big VGs
> > >
> > >
> > > I inherited a system that has a volume group with
> > > thirty two 8GB Shark LUNs. Obviously, we're maxed
> > > out. The current plan is to move to a "big" VG.
> > > There's some 150 free PPS on one disk, so I do
> > have
> > > the option of using lmigratepp to move the first
> > {x}
> > > partitions from each disk to the free section in
> > the
> > > VG.
> > >
> > > [Rebuilding a new VG or using another VG is also
> > an
> > > option, but for various reasons, the DBAs are
> > leaning
> > > toward this one.]
> > >
> > > My questions:
> > >
> > > 1. AIX 4.3.3 ML 10. Any known problems with big
> > VGs?
> > > I couldn't see any APARs.
> > >
> > > 2. Exactly how many free PPs do I need at the
> > start
> > > of each disk?
> > >
> > > Other than that, I assume that there aren't any
> > issues
> > > with just shutting everything down and running
> > "chvg
> > > -B VGname" (after running a database backup, of
> > > course).
>
>
> __________________________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo
> http://search.yahoo.com
>
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 22:16:45 EDT