[SOLVED] How do I add multiple storage pools?

[nordviks]

I'm using If you are using Network edition v5.11. I need to increase the mail storage capacity. How do I add multiple storage pools, and will this give me a dynamic expanding mail storage? When I have 64GB of mail storage, when I add a 320GB storage pool will the system see this as one volume of 384GB?

Do I need a second installation, or can I just add disk space?


Knut

[mmorse]

Are you saying LVM to size volume groups/pools by absorbing new physical disks/volumes to present to the system as one instance?

As far as Zimbra is concerned:
-Using LVM to expand /opt/zimbra, /opt/zimbra/store, or /opt/zimbra/index you don't have to do anything else.

-Haven't implemented LVM etc? Don't worry, you can still create 'expanding mail storage' even if not presented to the system as one big unit. If your creating an /opt/zimbra/store2, /mnt/device/zimbra/store2, or /mnt/device/zimbra/index2 that's separate - in order to get Zimbra to start putting blobs there you need to point the current message/index or volume there.

Just realize blobs are NOT moved in this process, you're only pointing at the location to store any NEW data. (See below explanation.)

Thus you shouldn't remove the old store, but alternatively if you want new store2 to hold the contents of the old store as well - just move the blobs first: Volumes : Ajcody-Notes - Zimbra :: Wiki

Promised Explanation:
Each Zimbra mailbox server is configured with one current index & message (NE can add secondary HSM volumes).

When a new message is delivered or created, the message is saved in the current message volume. Additional message volumes can be created, but only one is configured as the current volume where new messages are stored. When the volume is full, you can configure a new current message volume. The current message volume receives all new messages. New messages are never stored in the previous volume. A current volume cannot be deleted. If there are accounts with messages referencing a volume it should not be deleted until you point the volume path to wherever you've now moved the items.

Each mailbox is assigned to a permanent index directory on the current index volume. When an account is created, the current index volume is automatically defined for the account. You cannot change which index volume the account is assigned. As volumes become full, you can create a new current index volume for new accounts. When a new index volume is added as current, the older index volume is no longer assigned new accounts. Index volumes not marked current are still actively in use as the index volumes for accounts assigned to them. Any index volume that is referenced by a mailbox as it's index volume cannot be deleted.

The Network Edition has HSM (Hierarchical Storage Management) which involves moving data to other storage locations automatically after x amount of time. Messages and attachments are moved from a primary volume to the current secondary volume based on the age of the message; completely transparent to the user.

For instance: After 30 days messages move from your fast (and usually more expensive) SCSI disks, to a SATA array so that you can keep storage costs down. But you could also use it to move between your 64GB & 320GB volumes if they're separate.

(Also a handy tidbit of info: http://www.zimbra.com/forums/adminis...e-volumes.html - first tip is good for HSM > back to store, Klug's also points out that you can essentially use the same concept of Adam's above wiki link; making it a subdirectory of the new filesystem location keeps it simple.)

The admin console > server > volumes tab is straight forward, make sure you have permission to write to the target location - see also: CLI zmvolume - Zimbra :: Wiki
(-l and -dc arguments display your volumes)

If you're curious how to view that in the DB:
su - zimbra
mysql
select * from zimbra.volume;

[nordviks]

Originally Posted by mmorse

Are you saying LVM to size volume groups/pools by absorbing new physical disks/volumes to present to the system as one instance?

As far as Zimbra is concerned:
-Using LVM to expand /opt/zimbra, /opt/zimbra/store, or /opt/zimbra/index you don't have to do anything else.

-Haven't implemented LVM etc? Don't worry, you can still create 'expanding mail storage' even if not presented to the system as one big unit. If your creating an /opt/zimbra/store2, /mnt/device/zimbra/store2, or /mnt/device/zimbra/index2 that's separate - in order to get Zimbra to start putting blobs there you need to point the current message/index or volume there.

Just realize blobs are NOT moved in this process, you're only pointing at the location to store any NEW data. (See below explanation.)

Thus you shouldn't remove the old store, but alternatively if you want new store2 to hold the contents of the old store as well - just move the blobs first: Volumes : Ajcody-Notes - Zimbra :: Wiki

Promised Explanation:
Each Zimbra mailbox server is configured with one current index & message (NE can add secondary HSM volumes).

When a new message is delivered or created, the message is saved in the current message volume. Additional message volumes can be created, but only one is configured as the current volume where new messages are stored. When the volume is full, you can configure a new current message volume. The current message volume receives all new messages. New messages are never stored in the previous volume. A current volume cannot be deleted. If there are accounts with messages referencing a volume it should not be deleted until you point the volume path to wherever you've now moved the items.

Each mailbox is assigned to a permanent index directory on the current index volume. When an account is created, the current index volume is automatically defined for the account. You cannot change which index volume the account is assigned. As volumes become full, you can create a new current index volume for new accounts. When a new index volume is added as current, the older index volume is no longer assigned new accounts. Index volumes not marked current are still actively in use as the index volumes for accounts assigned to them. Any index volume that is referenced by a mailbox as it's index volume cannot be deleted.

The Network Edition has HSM (Hierarchical Storage Management) which involves moving data to other storage locations automatically after x amount of time. Messages and attachments are moved from a primary volume to the current secondary volume based on the age of the message; completely transparent to the user.

For instance: After 30 days messages move from your fast (and usually more expensive) SCSI disks, to a SATA array so that you can keep storage costs down. But you could also use it to move between your 64GB & 320GB volumes if they're separate.

(Also a handy tidbit of info: http://www.zimbra.com/forums/adminis...e-volumes.html - first tip is good for HSM > back to store, Klug's also points out that you can essentially use the same concept of Adam's above wiki link; making it a subdirectory of the new filesystem location keeps it simple.)

The admin console > server > volumes tab is straight forward, make sure you have permission to write to the target location - see also: CLI zmvolume - Zimbra :: Wiki
(-l and -dc arguments display your volumes)

If you're curious how to view that in the DB:
su - zimbra
mysql
select * from zimbra.volume;

Thank you so much for this great reply!

[ajcody]

Mike,

Here's my updated url for the zmvolume stuff. I added your excellent write up on it as well.

Adam