Librado Pamintuan wrote:
Now on the linux side our disk (local SCSI at this point til we get something
figured out) can be all be laid out under / and boot.
Then the disk management is not really a concern until it gets full.
The server will be using a hardware RAID controller here also (likley RAID10)
and the amount of storage I am talking about here is 350GB or so per server.
I wouldn't recommend just setting up / and /boot. I get verbose below...
So, I'm just wondering if anybody has any feedback on what they have done as
far as linux server partitoning, LVM etc.
One thing I'm thinking about is if I have to run an 'fsck' on a filesystem one
large one will take much longer to complete.
I do like the idea of using LVM as it means I don't have to know how large to
make my partitions ahead of time but there may be a performance penalty
attached.
You're right about fsck. And on the one 3TB partition we have we've
actually talked about disabling automatic fsck and scheduling down time
to handle it. Different file systems will take different amounts of time
to complete the fsck. If you get stuck with a large fs then bench mark
it against fsck using real world file system data.
As for the partition setup, we create one hardware array (RAID5) with a
single logical partition that fills the entire array. Under Linux this
shows up a physical drive /dev/sda. Our partition scheme, which includes
LVM, looks something like this (swap not shown):
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vol00-root 7.9G 350M 7.2G 5% /
/dev/sda1 99M 19M 76M 20% /boot
/dev/mapper/vol00-home 4.0G 124M 3.7G 4% /home
/dev/mapper/vol00-opt 4.0G 126M 3.7G 4% /opt
/dev/mapper/vol00-tmp 4.0G 43M 3.7G 2% /tmp
/dev/mapper/vol00-usr 7.9G 1.5G 6.1G 19% /usr
/dev/mapper/vol00-usr_local 2.0G 603M 1.3G 32% /usr/local
/dev/mapper/vol00-var 93G 1.1G 87G 2% /var
/dev/mapper/vol00-var_log 7.9G 77M 7.4G 1% /var/log
Some people will disagree with the idea of keeping / on an LVM. The
logic is that if / is not on the LVM, then all the LVM tools in /sbin
are available even if they aren't available on a rescue CD you may be
using. Reality is that LVM2 (found in RHEL4 or LVM1 in RHEL3) is common
enough these days that we've never had a problem getting our LVM
partitions mounted from a rescue CD.
<tangent>
In fact, using the most recent knoppix CD you can do the following as a
bare metal recovery. This assumes you've used vgcfgbackup and sfdisk to
save key partition and lvm config info
1) boot knoppix live CD
2) apt-get lvm tools
3) use sfdisk to restore partition tables on /dev/sda (target system)
4) create the vg and use vgcfgrecover to restore lvm partitions on
/dev/sda (target system)
5) mount /dev/sda partitions under /targetsys or whatever you like
6) bring up knoppix networking and install Networker 7.x RPMs using
alien (apt-get it if needed)
7) run a recover of the failed system directing all files to /targetsys
8) install grub or lilo to the mbr on /dev/sda and then reboot
This is actually a bit nicer than having to install the target system OS
+ Networker first.
</tangent>
Concerns about partition sizes are easily handled by using LVM features
to grow and shrink partitions as needed. Just be sure that the file
system you pick can also handle both growing and shrinking. Not all
Linux FS can do this.
If you do end up with a large partition (we have one that is 3TB) then
use .nsr files with 'skip' directives along with client saveset
definitions to break the partition up into logical sizes. This will
result in significantly faster backups as you backup multiple streams
from one partition. Depending on your config the bottleneck here will be
disk read I/O, the network, or the tape drives.
Example: /var/ftp is a 3TB partition on Linux
/var/ftp/
/var/ftp/redhat
/var/ftp/suse
/var/ftp/other
/var/ftp/readme.txt
In /var/ftp/.nsr add skip directives for /var/ftp/suse and
/var/ftp/redhat. In the client save set definition replace 'All' with
definitions for /var/ftp, /var/ftp/redhat, and /var/ftp/suse. (Include
other partitions as well, of course.) The /var/ftp saveset will contain
everything but the redhat and suse directories which will be backed up
as separate savesets instead.
--
Scott Russell <lnxgeek AT us.ibm DOT com>
IBM Linux Technology Center, System Admin
To sign off this list, send email to listserv AT listserv.temple DOT edu and type
"signoff networker" in the
body of the email. Please write to networker-request AT listserv.temple DOT edu
if you have any problems
wit this list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
| 