[prev in list] [next in list] [prev in thread] [next in thread] 

List:       novell
Subject:    Re: Re: NSS/Volume configs
From:       "Joe Pampel" <Joe () ardsley ! com>
Date:       2005-06-23 0:38:12
Message-ID: s2b9cc59.001 () gw ! ardsley ! com
[Download RAW message or body]

jm2c
 
I find hardware has a lot to do with backup speed and (IMHO) the
ultimate force in how fast things can run is the OS on the host + the
host hardware. The backup app can request anything it wants.. but the OS
and hardware are what stream it in the first place. 
IMHO it's a good idea to run TSATEST to see just how fast the OS/host
can stream data, and then see where your backup app is in relation to
that number. YMMV and some apps will handle multiple streams etc etc..
but leaving that for a sec - TSATEST will always be faster (by at least
20%-30% I'm guessing) and is a 'theoretical' speed which cannot be
reached in practicality due to protocol overhead etc.. If tsatest shows
12MB/sec and your app is running at 4MB/sec, then your app or perhaps
tape device is where the trouble lies.. and so on. I think it's a pretty
helpful tool. 

 
- Joe P
 

>>> cam@myrealbox.com 6/22/2005 3:59:07 PM >>>

At one of my last jobs, I had a 1.2TB NSS volume running under NW51. 
It seemed to operate fine, though we eventually migrated it to several
smaller 150-200GB volumes in order to increase legato backup speed. 
Granted NSS on NW51 is different from NSS running under NW65, but I
wouldn't expect any problems going to the newer OS.

As far as your backup goes, I'm not sure its dependent on the hardware.
 I'm pretty sure its the software that determines how the backup will
stream to the device.  Most direct attached backup solutions don't
encounter time restriction issues due to the relatively fast speed of a
dedicated scsi bus, assuming you've setup the hardware correctly.

Also, moving from different NSS configurations, while time consuming,
can easily be accomplished with VCU.NLM and extra disk space.  I've used
VCU to move volumes (including SYS), and it worked like a charm.  For
those servers that don't have room, an external storage cabinet full of
drives can be attached in a pinch to an external connector and used as
scatch place to hold the data while you reconfigure your internal drive
space.

-----Original Message-----
From: Gerry VanLoh <vanloh@ole.augie.edu>
To: Novell LAN Interest Group <novell@netlab1.usu.edu>
Date: Wed, 22 Jun 2005 12:45:10 -0500
Subject: Re: NSS/Volume configs

Christopher - I pretty well agree and understand everything you say
(and 
your opinions are highly welcomed!!)  Due to some respected feedback I

had received over a couple of other servers recently set up this way
but 
with 146 gig drives producing, among others in the pool, a 600 gig 
volume, I was curious to see if anyone else had experiences with large

NSS drives on Raid-5 this way or even the 1.5 Tb sizes.  I know the NSS

pools/volumes can handle larger space and usually this is in some form

of SANS configuration, I have no experience with SANS and this will not

be used in that type of system - just a good ol' Netware 6.5.3 box.  I

just don't want to introduce problems I might be able to avoid before
we 
add this chunk of storage.  Backups will be another area that will have

to be addressed later but is currently a changer using AIT type 
cartridges - Brightstor right now.

After reading this thread, I do feel we could redo a few servers for 
better NSS configurations but they aren't too bad.

Gerry

Christopher Mangiarelli wrote:
> As was mentioned in previous postings, there are advantages and
disadvantages 
to either config.  If you put all your volumes in a single pool, then 
you can
"share" disk space between volumes and maximize your utilization 
percentile.
However, you incur the "cost" of having to take all your volumes
offline in
order to repair the pool.  If you do a 1:1 ratio of volumes to pools,
then
you gain the ability to perform targetted repairs and in a clustered 
environment,
you can move the volumes independently around he ring, but you lose the

ability
to "share" disk space.
> 
> Usually when asked to design a volume setup for an environment, my
first 
question is; "Do you plan on implementing a cluster?".  If so, then I
stick
to the 1:1 rule so that resources can float.  In the case of a student
population, I might create USR1_Pool, USR2_Pool (Volumes: USR1, USR2.
etc),
etc.  and then either control mappings with a login script or use DFS 
pointers
on another volume (let's say everybody maps to \Cluster_Data_Vol, on 
that volume
would be a directory called \Users which consists of DFS mount points
to 
\USR1,
\USR2, etc).
> 
> If the answer is No, and a single server solution is going to be the
solution, 
then my next question is; "What type of backup solution are you 
implementing".
Some backup solutions (ie. Legato) can only do one backup thread per 
volume.
So backing up a 1.5TB volume across ethernet on a single thread will 
take awhile.
However, backing up six 250GB volumes in six backup threads might be 
faster.
If I chose this solution, then I perform the same naming convention 
(USR1, USR2, etc).
> 
> Finally, if the setup is a single server solution with either local
or dedicated 
backup, then the answer may be to just create a single pool/volume for

user data
and take the easy way out.
> 
> So, those are my opinions, take them for what they are worth (which
probably 
isn't much).
> 
> P.S.  While NSS does have limitations on the size and numbers of
files, it is 
usually assumed that most organizations will never reach that limit. 
As 
usual,
only you know your environment best and it may be worthwhile to 
determine if
these limits need to be factored into your solution.
> 
> -----Original Message-----
> From: Gerry VanLoh <vanloh@ole.augie.edu>
> To: Novell LAN Interest Group <novell@netlab1.usu.edu>
> Date: Wed, 22 Jun 2005 08:26:24 -0500
> Subject: Re: NSS/Volume configs
> 
> I've been following this NSS/volume configuration thread with
interest 
> since we are in the midst of the same thing.  I'm wondering about 
> another point in the NSS setups of volumes.  We are adding a server
(HP 
> DL-380) with Raid-5 for drive fault tolerance.  They want to add as
much 
> storage space as possible for students here and short of SANS (later

> maybe) I'm curious about sticking as much drive space on a server 
> possible.  In this case, 6 - 300 gig drives in a Raid array would
give 
> this volume nearly 1500 Gb.  Are there some good practices / gotchas

> concerning that much drive space on one big volume in one pool that
way 
> or should this be handled differently?  Access speed isn't a big 
> consequence, it's mostly small student files and home web page type 
> things.  Since the accounts are relatively dynamic, it's easier to 
> manage them if in one area.
> 
> Thanks for any comments!
> Gerry VanLoh
> Augustana College
> vanloh@ole.augie.edu

> --
> Christopher Mangiarelli
> cam@myrealbox.com

_______________________________________________
Novell mailing list
Novell@netlab1.usu.edu
http://netlab1.usu.edu/mailman/listinfo/novell


--
Christopher Mangiarelli
cam@myrealbox.com

_______________________________________________
Novell mailing list
Novell@netlab1.usu.edu
http://netlab1.usu.edu/mailman/listinfo/novell

_______________________________________________
Novell mailing list
Novell@netlab1.usu.edu
http://netlab1.usu.edu/mailman/listinfo/novell
[prev in list] [next in list] [prev in thread] [next in thread]