Results 1 to 7 of 7

Thread: RAID Re-configuration, Easiest Way To Move Zimbra?

Hybrid View

  1. #1
    Join Date
    Dec 2007
    Location
    Stockton, CA
    Posts
    164
    Rep Power
    7

    Default RAID Re-configuration, Easiest Way To Move Zimbra?

    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.

  2. #2
    Join Date
    Sep 2006
    Location
    477 Congress Street | Portland, ME 04101
    Posts
    1,374
    Rep Power
    11

    Default

    Quote Originally Posted by thunder04 View Post
    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

  3. #3
    Join Date
    Dec 2007
    Location
    Stockton, CA
    Posts
    164
    Rep Power
    7

    Default

    Quote Originally Posted by LMStone View Post
    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.

  4. #4
    Join Date
    Jun 2007
    Location
    BC, Canada
    Posts
    281
    Rep Power
    8

    Default

    Quote Originally Posted by thunder04 View Post
    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.
    Freddie

  5. #5
    Join Date
    Dec 2007
    Location
    Stockton, CA
    Posts
    164
    Rep Power
    7

    Default

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

    Though, would a hardware RAID 0+1 perform better?
    Last edited by thunder04; 11-23-2009 at 09:26 AM.

  6. #6
    Join Date
    Jun 2007
    Location
    BC, Canada
    Posts
    281
    Rep Power
    8

    Default

    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.
    Freddie

Similar Threads

  1. ldap id2entry.bdb has bad LSN
    By pixelplumber in forum Administrators
    Replies: 5
    Last Post: 02-03-2010, 10:44 PM
  2. Replies: 15
    Last Post: 11-24-2009, 08:46 AM
  3. Zimbra shutdowns every n hours.
    By Andrewb in forum Administrators
    Replies: 13
    Last Post: 08-14-2007, 09:55 AM
  4. huge log size
    By rmvg in forum Administrators
    Replies: 5
    Last Post: 01-02-2007, 10:39 AM
  5. Fedora Core 3, Clean Install - Not working!
    By pcjackson in forum Installation
    Replies: 17
    Last Post: 03-05-2006, 07:38 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •