Centos server migrate to larger disk

centoscentos5disk-space-utilizationhard drivemigration

I have a centos server that runs a whm/cpanel with mysql, apache, bind and email daemons. The server now has 95% of the server disk full. It is a dell poweredge 1950 with 2 spaces for SAS disks. I have it setup now with mirrored raid with the two disks currently in the server ( SAS 146GB 10K drives ).

I need to get more space available on the server but I'm unsure about how to go about that. What would you guys suggest for getting more space? I have purchased two 600GB SAS 10k drives to replace the 146GB drives ( i want to run the new larger drives in mirrored configuration as well ).

I've thought about trying to pull one of the disks in the mirrored configuration and putting a larger disk in and letting the system try to rebuild the array. However I'm worried that this could cause problems and that the larger disk may not even be accepted into the array. If the raid array became corrupted or unusable, then I'd be stuck doing a bare metal restore from backups which I'd like to avoid like the plague.

I've also thought to just put these larger disks in another free poweredge 1950 I have laying around and then move the data from the existing server over to this server. I have been experimenting with this offline, however I'm not sure this is the best way to go about it? The method I was going to go about this was

boot both servers off a live cds
on the destination server with larger disks, i would format the new 600GB disk with partitions and a file system, then mount the root partition. I would setup rsync daemon to be able to push to the root partition
from the source server with smaller disks I would mount the root drive, then rsync -avh everything up to the destination server new root partition
from the destination server I would then need to modify fstab, grub boot configuration if necessary, rebuild the initrd if necessary then do a grub-install to push grub onto the new disks

If all went well with the above I'd have a duplicate server with larger drives, and if that didn't work I'd still have the old server with smaller disks to revert back to in emergency.

I've experimented with some computers laying around my house, I got as far as having the new destination boot up but because of different hardware the destination server kernel panics, appears to be a missing kernel module for the hard drive controller. I was going to look into resolving this and seeing if my little experiment works so I can replicate on the live server, however I was wondering if I am going about this the wrong way?

Any suggestions are appreciated?

Thanks

Best Answer

The safest way would be to back your server up, turn it off, replace the drives, and restore to them.

Related Solutions

Linux – Migrate raw disk image over LAN

This is messy, but doable.

I presume here that / is on /dev/sda3 and that /boot is on /dev/sda1.

Shrink the filesystem on the old server to its minimum possible size.
```
oldserver # resize2fs -M /dev/sda3
```
Partition the new server's disk with an identically sized /boot, swapspace, and new / partition (and anything else you need).
```
newserver # parted /dev/sda
```
Copy the / and /boot filesystems.
```
oldserver # dd if=/dev/sda1 | ssh root@newserver "dd of=/dev/sda1"
oldserver # dd if=/dev/sda3 | ssh root@newserver "dd of=/dev/sda3"
```
Because the partition on the new server will be slightly smaller than the one on the old server, you'll receive a spurious No space left on device message at the end of this. However, since you shrank the filesystem at step 1, this doesn't matter.
Resize the filesystem on the new server to the size of the partition.
```
newserver # resize2fs /dev/sda3
```

Install GRUB on the new disk.

newserver # mount /dev/sda3 /mnt
newserver # mount /dev/sda1 /mnt/boot
newserver # mount -o bind /dev /mnt/dev
newserver # mount -o proc proc /mnt/proc
newserver # chroot /mnt /bin/bash

newserver(chroot) # grub-install /dev/sda
newserver(chroot) # exit

Finish the rest of your fixups (IP address, etc.).

You can probably find a way to avoid copying the partition's free space, but it'll probably take you longer to research than to just copy it all...

Disk performance below expectations

You need to put less focus on the interface max speed and look more at the physical disk performance characteristics as this is typically the bottleneck. As described on this site for the Hitachi Hus153030vls300 300GB Server SAS disk you linked.

In terms of performance the important figures listed on the Hitachi pdf are

Data buffer (MB) 16
Rotational speed (RPM) 15,000
Latency average (ms) 2.0
Media transfer rate (Mbits/sec, max) 1441
Sustained transfer rate (MB/sec, typ.) 123-72 (zone 0-19)
Seek time (read, ms, typical) 3.6 / 3.4 / 3.4

As all of these figures mean the disk will not be able to saturate a 3 Gbps channel there is no point in it having a 6 Gbps channel.

I cannot imagine a raid controller that can utilise each disks' maximum performance in the same array at the same time. So assuming you have a RAID 1 with 2 disks, the first capable of 60MB/s sustained sequential read and write speed and the second only 50MB/s, then writing to the array will be limited to 50MB/s while a decent raid card will be able to have 2 simultaneous read streams, one at 60MB/s and the other at 50MB/s. The more complex the array the more complicated these figures become.

Some other notes

the maximum transfer rate of a disk is different in different areas of the disk, typically it is faster at the start of the disk.
sequential reads are the fastest sustained operations a disk can do and random read or writes are significantly slower.
typically a raid controller will disable a disks' onboard write cache and will only use its own cache for writes if it has a good battery, or you override its default.
I have read of some instances of some disk/raid firmware combo's that falsely detect a bad battery and disable all write cache. So update your firmware for both disk and raid controller

There are some disks advertised as 6 Gbps high performance disks that are in fact not that high performance, they just have the 6 Gbps interface, and couldn't even saturate a 3 Gbps link anyway (which would take 357 MiB/s).

The main benefit of 6Gbps sas/sata is for SSDs and port multipliers (ie attaching multiple disks to the 1 sas/sata port)

Best Answer

Related Solutions

Linux – Migrate raw disk image over LAN

Disk performance below expectations

Related Topic