Re: Expanding LUNS/NSS Pools in OES2 SP2 without rebooting
Massimo Rosen
jblomendahl wrote:
>
> So even though I think I already know the answer to this question, is
> there anyway for a OES2 server (or any SUSE server) to unobtrusively
> detect space added to a LUN?
Make that any Linux, and the answer is no. And quite seriously,
magically "growing" a hard disk (that's what expanding a LUN is), is not
something that hard disks have ever been designed for (neither while
online, but also not offline), and wenever possible I avoid this like
the plague on *any* OS. Doing this is one of the most dangerous
activities possible on a disk.
> I know that I could add new LUNs and
> expand the pools across them, but since the SAN has a finite number of
> LUNs available and that we seem to be expanding pools on a monthly basis
> (a pool could be spanning a dozen or more LUNs within a year) this isn't
> a practical solution.
First, that sounds like bad planning. Second, it's a bad idea either
way. Only expand a pool if *really* necessary, not as a commodity. A
pool split into dozens of (small) segments isn't exactly a good idea.
Amongst others it'll lead to a performance hit. And quite seriously,
with todays HD sizes and the pool size limit of 8TB, I can't fathom
producing any pool consisting of more than a max of 4 segments (and have
never ever had to do this). 4 segments is the absolute maximum number of
segments *I* would ever allow a pool to span.
CU,
--
Massimo Rosen
Novell Product Support Forum Sysop
No emails please!
http://www.cfc-it.de
Massimo Rosen
jblomendahl wrote:
>
> So, how are things in 1995? :)
Fine. Hard Disks have been invented *way* before that though, and pretty
much nothing has changed how they're handled. "Growing" them was never,
and still isn't in any way part of their design, and that it works most
of the time is more coincidence than part of well though out design.
> I would have to disagree with your
> logic on this. We have been expanding LUNs in this manner for almost 10
> years on NetWare and Windows and I can think of only one instance where
> we had a problem that could possibly be related to growing a LUN.
You had LUNs 10 years ago, and even once you could resize? Wow.
> Today's SAN's have virtualized storage, and the fact that you can easily
> grow LUNs is a big selling point and a big advantage to using a SAN.
True. That doesn't change the technical facts behind it. *Nobody* and
nothing guarantuees you that it works. Even a virtualized hard disk is
still a hard disk, and still handled mostly by well over 20 year old
logic and standards.
> The most dangerous thing that you can do? Apparently some one forgot to
> tell the developers of NSS this since they included that handy "F3" key
> that lets you expand the pool.
Expanding a pool is completely unrelated to expanding a LUN. Expanding a
pool is designed to expand it to either previously free space, or a
different logical or physical disk.
> One of the big reasons that we are big
> fans of NetWare, is how well and reliably it does this.
Netware (even 6.5 in it's early days) for a very long time systmatically
had and even today often still has serious problems with "growing"
devices, and yes, people *do* have lost all their data doing so.
> Over allocating very expensive
> diskspace is a really poor planning.
"Very expensive"? Diskspace has never been cheaper. What do you plan to
use as fragments? 100GB or what?
> Disk space isn't a commodity?
Of course it is. Growing a LUN regularly as a matter of managing your
disk space isn't.
> Please, there is nothing more commoditized and dynamic than diskspace.
> What happens if you have to go beyond 4 segments?
With *every* segment it gets slower and data integrity weaker.
> Build a new larger LUN
> and migrate all the data to it? How long does it take you to migrate a
> couple of terabytes of data?
Depends. Still you don't want to do that often either. Hence you plan
your disk space allocations by *future* and not todays needs.
> I do appreciate the honest answer about this though, clearly OES (and
> SLES) are misnamed. There is nothing enterprise about them if they
> cannot keep up with the dynamic data centers of this century.
Again, this is a Linux and even mostly UNIX "limitation" (although I
wouldn't call that a real limitation at all). There's nothing
"unenterprise" about an OS that doesn't want to deal with a hard disk
growing (while the OS is up).
Alex Warmerdam
<jblom...@no-mx.forums.novell.com> wrote:
Hi,
> kjhurni, you can expand non-dynamic Windows volumes using Diskpart from
> the command line. However since you have a XIOtech SAN you can also use
> the server view in ICON manager to do the same thing (including the boot
> volumes if you feel lucky).
I thought you clearly stated that resizing a lun could be done on
Windows without any problem.
If you feel lucky....
That does not sound very promissing....;)
As for virtual disk expanding and the cost of disks.
If think you would love to review your opinion on this.
Novell has some nifty options build in in OES2 Linux which could move
your large amount of unused files onto cheaper storage, it's called
Dynamic Storage Technology. This you can not do with NetWare.
http://www.novell.com/documentation/oes2/stor_dst_lx/?page=/documentation/oes2/stor_dst_lx/data/bookinfo.html
That way you will save mucho $$$ now and in the future.
And if you play around with the policy, you could even use it to
migrate data between old and new on the fly without ever taken down a
server or bother a user. From the manual:
1.3.2 Empty Volume as Primary with an Existing Volume as Secondary
You have an existing volume on older storage and want to move the data
to new storage arrays. You create a new volume on a storage device in
a Fibre Channel SAN solution. You define a shadow volume that uses the
empty device as the primary area, and the existing volume as the
secondary area.
Configure a policy wherein the data moves to the primary volume based
upon usage. Data gradually flows to the primary volume as it is used.
In this way, there is a natural background migration of data from the
existing volume to the new volume. The new volume gradually grows, and
the relationship between the primary and shadow volume is as if the
primary had been populated first.
For example, suppose you have an existing pool that spans multiple
LUNs, and contains multiple volumes. The current best practice is to
use a separate LUN for each pool, and a single volume per pool. You
create a new pool on a new larger LUN (or fewer larger LUNs), then
create a single NSS volume in the pool. You might need to rename the
old and new NSS volumes if users need to access the data via known
paths, because after the shadow volume is created, users access data
via the new volume. Repeat this process so that you have one new empty
volume for each of the old volumes on the pool. As the new and old
volumes are ready, you create a DST shadow volume with the new volume
as the primary storage area and an existing volume from the old pool
as the secondary storage area.
To begin de-migrating the data, configure the global policies to shift
data from the secondary storage area to the primary storage area
whenever they are accessed or modified. You can also configure
individual shadow volume policies or use inventory reports to shift
data on schedule or on-demand based on age, filenames, file types, or
file size. De-migration occurs with the storage online and accessible
to end users; they are not aware of where the data is actually
stored.When you have moved all the data from the old NSS volume to the
new one, you can remove the shadow volume, then delete the empty old
NSS volume from the old pool. When the old pool has had all its
volumes deleted, you can delete the old pool, which frees that storage
for use in other volumes. Users are not aware that the volumes are on
a new pool. They see only the volume by its name.
Alex Warmerdam
<kjh...@no-mx.forums.novell.com> wrote:
>
> EVen with DST you still need to reboot the server if you need to expand
> either the primary or the shadow volume, and since they're on the SAME
> server, both will be unavailable during the reboot.
Why, if you have transfert all your data towards the primary, trash
the shadow. Trash the lun, create a new bigger lun. Mount the lun,
create the shadow again. Let the policy move all your data towards the
shadow volume. Trash your primary, delete the lun, create a new bigger
lun. And so on ...
Where is the reboot in this?
Or am i missing something?