Moving Email Accounts From Old SAN to New
Hello,
Our current SAN is being taken off maintenance, so we've been directed to move all email accounts (57K of them) to our new SAN. Our version is (Solaris 9)
iPlanet Messaging Server 5.2 HotFix 2.09 (built Nov 18 2005)
libimta.so 5.2 HotFix 2.09 (built 10:35:58, Nov 18 2005)
SunOS luminis-email 5.9 Generic_118558-36 sun4u sparc SUNW,Sun-Fire-480R
I understand 5.2 is no longer supported, and we will be going 6.2 within the next few months. This version comes with the portal application we use, so we can't go newer.
Sun Java(tm) System Messaging Server 6.2-3.04 (built Jul 15 2005)
libimta.so 6.2-3.04 (built 01:43:03, Jul 15 2005)
Here are some questions I would appreciate some help on.
1) We currently have about 1.9T of space allocated between 5 partitions.
The primary partition, created when we first installed iPlanet, is 720G. When I added more partitions, went with 300G. I believe smaller partitions are better for backup purposes and performance, plus if you lose one, you don't lose as much.
As for partition sizes on the new SAN, one colleague wanted 4 500G partitions. I favor going with 7 300G partitions. Feel free to comment on this.
2) To move accounts, we're thinking of the following:
a) Take system down and copy partition data from old to new. If the new partition
has a different name, it would seem a reconstruct on that partition would be needed.
Otherwise, rename new partition to existing name - no reconstruct needed? If we use
this method, would use cpio to copy accounts over.
b) Use mboxutil to move accounts. We could do this live and ongoing, correct? If we
use this method, we don't have to take the system down. It would take longer, but I
kind of favor this as I've done it before and we don't have downtime.
If anyone can suggest a better method, I would like to hear it.
Thank you,
Keith
[1983 byte] By [
kmrnm10a] at [2007-11-27 9:16:23]
# 1
If you can tolerate down time, you can simply copy the parttions over. Keep the same directory names/paths, and you don't need to reconstruct.You might want to look at the "relinker", though, unless your copy will preserve hard links.
If you can't handle down time, then mount your new SAN, create new partitions with configutil, restart Messaging, and use mboxutil to move your users over.
Either will work fine.
# 2
Found reference to "relinker" in the Sun Java doc, but not the 5.2. Does it go by
some other name?
Another question I didn't ask regards to changing the 'default' partition. Can that
be done in the same restart when adding new partitions (like one of the new ones will be the default)?
Thank you, Keith
# 3
Rather than move the files, I'd use Disksuite aka LVM to attach the new array as a mirror and then let it sync up. I had to move some partitions around (and move off of failing arrays) over the past year) and it's by far the fastest way around.
A brief outline would look like this:
1) If you're not using LVM now, stop JES and umount the store filesystems and create a one-way mirror device for your existing SAN. Remount the store filesystems using the one-way mirror and restart JES. From this point on, there's no more downtime until the last step
2) Create a 2nd sub-mirror for each store partition on the new SAN. Make them as large as you want them to be when you are done (i.e this is where you'll prep to grow the filesystems).
3) Add the new submirror to each metamirror and wait for them to sync up.
4) When they're sync'd, detach the old SAN submirror
5) Grow the metamirror to the size of the new SAN submirror
6) Stop JES and umount the store filesystems and use growfs to grow the filesystem to new larger size of the LUN
7) remount the now larger filesystems and restart JES.
total downtime will be under 10 minutes. 5 minutes if you're quick.
If you need pointers to the infodocs on these steps, let me know. It's all really easy and much faster than trying to do file copies since there's a huge overhead for file creations that you skip when you do the block copies instead.
If you can spare a reboot, adding
set md_mirror:md_resync_bufsz=2048
to /etc/system will greatly increase your resync speeds.
# 4
Hi,
> 1) We currently have about 1.9T of space allocated between 5 partitions.
> The primary partition, created when we first installed iPlanet, is 720G. When I added
> more partitions, went with 300G. I believe smaller partitions are better for backup
> purposes and performance, plus if you lose one, you don't lose as much.
> As for partition sizes on the new SAN, one colleague wanted 4 500G partitions. I favor
> going with 7 300G partitions. Feel free to comment on this.
I would go with the 7x300GB. From a risk mitigation, backup/restore and fsck perspective this is the better option. When we had file-system corruptions/multi-disk SAN failures which required fsck/restore from tape having the smaller partitions was great.
> Found reference to "relinker" in the Sun Java doc,
> but not the 5.2. Does it go by
> some other name?
Nope. Didn't exist in 5.2.
If you plan on running 6.2, make sure you patch to -63. There were a few relinker fixes from memory.
> Another question I didn't ask regards to changing the
> 'default' partition. Can that
> be done in the same restart when adding new
> partitions (like one of the new ones will be the
> default)?
I assume you mean changing store.partition.primary.path to point at a different location. In which case yes it can be done in one operation.
Please note that there was another forum user who tried changing partitions and ended up in a bit of a mess, I highly recommend you test these scenarios first in a test environment.
Regards,
Shane.
# 5
Thank you Jeff. This is really good, but I don't think I'll be able to use it in this case since I'll have different number of partitions, plus I have one large existing partition that I will be breaking up. I've used mirroring for our root volumes, but I've not played around with the mail partitions (or other filesystems). It seems there's a lot there that would be worth exploring. If you can provide the pointers to the infodocs, that would be great as I can see using this in the future. My profile in the messages posts has my email if you need it.
Keith
# 6
Thank you for the comments, Shane.
Regarding the default partition. I was thinking of changing the "store.defaultpartition"
directive. Here's what we currently have below:
store.defaultpartition = primary
store.partition.primary.path = /opt/mailstore/partition/primary
store.partition.secondary.path = /opt/mailstore/partition/secondary
store.partition.third.path = /opt/mailstore/partition/third
store.partition.fourth.path = /opt/mailstore/partition/fourth
store.partition.fifth.path = /opt/mailstore/partition/fifth
Over the past year, when I added a new partition, I would make the *new* partition the default (using the store.defaultpartition ). That worked well until April (fourth partition) - it is probably me you're referring to on the mess - and what a mess it was. Learned a lot in that exercise. Looking back, there were several little things that happened which had like a 'domino' effect resulting in the final mess :)
Anyway, using the store.defaultpartition is correct, right?
Keith
