RAID Re-configuration, Easiest Way To Move Zimbra?

[thunder04]

Hey Guys,

It looks like I'm going to be re-configuring the RAID setup on our Zimbra server. Currently, we have two 147GB SAS drives that are mirrored. I was a little worried about it in the beginning...and my fears have come true. We're out of disk space!

So, I'm going to have two more 147GB SAS drives ordered and do a RAID 0+1. This way we gain more disk space through striping (double disk space from ~147GB to ~296GB, keep redundancy with mirroring, and as a side benefit get a slight performance boost.

From my limited experience, I think that this change will require me to pretty much re-do the server. Which, isn't all bad.

If I copy /opt/zimbra to another storage device, re-do the Zimbra server, copy /opt/zimbra back over, and do a re-install, will I more or less be OK?

We're currently running Zimbra 5.0.18 open-source edition. The server's OS is Debian Etch

I'd love to do two things. 1) Upgrade the server's OS to Debian Lenny, and 2) upgrade to the latest version of Zimbra 6.

Can I re-do the server with Debian Lenny, copy /opt/zimbra back over, and install Zimbra 6? Or, should I install Debian Etch, copy /opt/zimbra back over, re-install Zimbra 5.0.18, run apt-get dist-upgrade, then upgrade to Zimbra 6?

I'm nervous about this! Am I on the right track?

A P.S. question - Is it possible to run the 32 bit version of Zimbra on 64 bit Debian? I only ask because our server has 4 GB RAM and it bugs me that we're only able to utilize 3.5GB of it, lol. I'd go 64bit all-round, but our backup Zimbra server (for a disaster-like scenario) is only 32 bit.

[LMStone]

Originally Posted by thunder04

Hey Guys,

It looks like I'm going to be re-configuring the RAID setup on our Zimbra server. Currently, we have two 147GB SAS drives that are mirrored. I was a little worried about it in the beginning...and my fears have come true. We're out of disk space!

So, I'm going to have two more 147GB SAS drives ordered and do a RAID 0+1. This way we gain more disk space through striping (double disk space from ~147GB to ~296GB, keep redundancy with mirroring, and as a side benefit get a slight performance boost.

From my limited experience, I think that this change will require me to pretty much re-do the server. Which, isn't all bad.

If I copy /opt/zimbra to another storage device, re-do the Zimbra server, copy /opt/zimbra back over, and do a re-install, will I more or less be OK?

We're currently running Zimbra 5.0.18 open-source edition. The server's OS is Debian Etch

I'd love to do two things. 1) Upgrade the server's OS to Debian Lenny, and 2) upgrade to the latest version of Zimbra 6.

Can I re-do the server with Debian Lenny, copy /opt/zimbra back over, and install Zimbra 6? Or, should I install Debian Etch, copy /opt/zimbra back over, re-install Zimbra 5.0.18, run apt-get dist-upgrade, then upgrade to Zimbra 6?

I'm nervous about this! Am I on the right track?

A P.S. question - Is it possible to run the 32 bit version of Zimbra on 64 bit Debian? I only ask because our server has 4 GB RAM and it bugs me that we're only able to utilize 3.5GB of it, lol. I'd go 64bit all-round, but our backup Zimbra server (for a disaster-like scenario) is only 32 bit.

Rebuilding your whole server to add disk space is a lot of work, and IMHO not at all necessary. I would also segregate the OS and ZCS upgrades from the adding disk space task. So let's deal with adding disk space first...

The two biggest disk space hogs will be /opt/zimbra/store and /opt/zimbra/backup.

So, if it were me, the two new disks I'd add as a separate RAID1 array, and after a quick reboot so the system sees the new disks, I'd mount the new array as, say, /opt/zimbra/backup-new.

Next, I'd rsync all of /opt/zimbra/backup to /opt/zimbra/backup-new; delete everything in /opt/zimbra/backup and then remount /opt/zimbra/backup-new as /opt/zimbra/backup (modifying /etc/fstab accordingly). You are done.

Aside from a quick reboot to get the system to see the new RAID array, this procedure gives you zero downtime; no Zimbra reconfiguration whatsoever.

As far as OS and version updates go, our policy is always to have a rollback option at all times. Consequently, we never do in-place OS updates. Instead, we build a new server and migrate Zimbra. Plus, the Zimbra installer when doing an upgrade presumes that your existing Zimbra installation works, so if you upgrade the OS underneath Zimbra you have to jump through a lot of hoops, and in our experience it's just easier to move Zimbra to a new server to do the OS upgrade--and less downtime too.

If you have a "warm standy" Zimbra box to which you expect to be able to do a restore, both the primary and standby boxes IMHO should have the same OS, not only level but architecture. Since your backup box is 32-bit, and you also don't have a lot of RAM on your primary box, I'd stick with 32-bit for the moment.

What's the rationale for updating the OS? Etch is still supported; I'd personally avoid an OS upgrade until Etch gets close to end-of-life (or until Zimbra stops making RPMs for it).

Hope that helps.

Mark

[thunder04]

Originally Posted by LMStone

Rebuilding your whole server to add disk space is a lot of work, and IMHO not at all necessary. I would also segregate the OS and ZCS upgrades from the adding disk space task. So let's deal with adding disk space first...

The two biggest disk space hogs will be /opt/zimbra/store and /opt/zimbra/backup.

So, if it were me, the two new disks I'd add as a separate RAID1 array, and after a quick reboot so the system sees the new disks, I'd mount the new array as, say, /opt/zimbra/backup-new.

Next, I'd rsync all of /opt/zimbra/backup to /opt/zimbra/backup-new; delete everything in /opt/zimbra/backup and then remount /opt/zimbra/backup-new as /opt/zimbra/backup (modifying /etc/fstab accordingly). You are done.

Aside from a quick reboot to get the system to see the new RAID array, this procedure gives you zero downtime; no Zimbra reconfiguration whatsoever.

As far as OS and version updates go, our policy is always to have a rollback option at all times. Consequently, we never do in-place OS updates. Instead, we build a new server and migrate Zimbra. Plus, the Zimbra installer when doing an upgrade presumes that your existing Zimbra installation works, so if you upgrade the OS underneath Zimbra you have to jump through a lot of hoops, and in our experience it's just easier to move Zimbra to a new server to do the OS upgrade--and less downtime too.

If you have a "warm standy" Zimbra box to which you expect to be able to do a restore, both the primary and standby boxes IMHO should have the same OS, not only level but architecture. Since your backup box is 32-bit, and you also don't have a lot of RAM on your primary box, I'd stick with 32-bit for the moment.

What's the rationale for updating the OS? Etch is still supported; I'd personally avoid an OS upgrade until Etch gets close to end-of-life (or until Zimbra stops making RPMs for it).

Hope that helps.

Mark

Thank you for your reply!

/opt/zimbra/backup is nonexistant (as in, empty, lol) because we're running the open source edition. So, all of our space is consumed by stuff that is in use. I work for a school district, so we're forced to do things on the cheap. For backups, I'm currently rsyncing /opt/zimbra on our mail server to our backup mail server (which after some tweaking and testing, does work).

Right now I have Zimbra installed on its own partition which consumes a majority of the container. The OS is on a 14 GB partition...which, for Debian, is probably a bit much as it's currently only using 3.2 GB. I can't think of a way to better utilize disk space and not degrade performance other than doing a RAID 0+1. I mean, I guess I could have one mirrored set store everything, and the second mirrored set could be solely for the message store...but I have a feeling that there would be a bit of wasted space with the first mirrored set.

If the RAID controller in our mail server will allow me to turn a RAID 1 container into a RAID 0 container without destroying any data, then I can avoid all of this...but I doubt it can do that. But, if it could, that would be sweet as all I would need to do is expand the partition Zimbra is installed on.

As for the OS upgrade, I only thought about it because now would be an opportunity to do it. I know it's not necessary, but if it's possible it wouldn't be too much more work than I'm already in for, lol.

[fcash]

Originally Posted by thunder04

I can't think of a way to better utilize disk space and not degrade performance other than doing a RAID 0+1. I mean, I guess I could have one mirrored set store everything, and the second mirrored set could be solely for the message store...but I have a feeling that there would be a bit of wasted space with the first mirrored set.

Enter LVM.

Create a second RAID1 array. Use that as the Physical Volume for LVM. Create a Volume Group. Then create a new Logical Volume. Move your existing /opt/zimbra over to the new LV. Be sure to use a filesystem that supports resizing (XFS is best, but ext3/4 work).

Then use the old partition from the original RAID1 to create a second Physical Volume. Add that to the existing Volume Group. Then use lvresize to expand the LV to use all that new free space. And, finally, resize the filesystem to use the extra space.

[thunder04]

Hmm. That's definitely an option! I totally forgot about LVM.

Though, would a hardware RAID 0+1 perform better?

[fcash]

I couldn't tell you, I don't know how LVM works in this situation (is it a RAID0 across all PVs, or does it just concat across the PVs?).

There's probably some options in LVM to specify how to use the PVs, but I've never dug into it that deep.

[svendsen]

I would also go for LVM. I always use LVM because it makes storage more flexible.
I would also check the RAID controller documentation. Some middleend/highend controllers can migrate RAID levels quite easy.