GroupWise 8 Virtualization Best Practices
This article focuses on virtualizing GroupWise on VMware ESX (or vSphere). Other hypervisors including Xen will work, but are not the focus of this article. Covered topics include LUNs, VMDKs and a little bit about implementation. Specifically best practices for virtualizing GroupWise on either Open Enterprise Server, or SuSE Linux Enterprise Server.
A GroupWise virtualization project may also a good time to redesign your GroupWise system to relocate or consolidate Post Offices and agents, and generally to re-architect the system. It is also an opportunity to centralize and consolidate servers. Virtualization allows the use of fewer hardware servers to run a GroupWise system.
Keep in mind upgrading software at the same time as moving users can become very difficult. It is advisable that you do it one step at a time. If you are planning to virtualize you may want to move the users first and stabilize the system before upgrading to a newer version of GroupWise don't trap yourself by trying to do too many things at one time.
This article is geared toward GroupWise administrators with advanced knowledge of Novell GroupWise. Other knowledge needed includes: VMware, SLES, OES (if used), and general knowledge of networking and email flow.
This article is adapted from a Brainshare 2011 presentation sponsored by Messaging Architects, and presented by Gregg Hinchmann.
===Planning and Design=== Hi Dena
Virtual Infrastructure Design
Virtual infrastructure should be designed in light of the reasons you choose to virtualize GroupWise. Some business reasons to virtualize are:
- Decreased overhead.
- Reducing the number of physical servers reduces the physical space required. This can save money by postponing expansion, or by decreasing used rack space, and reducing fees in a leased space datacenter situation.
- Centralization of services to datacenters. Many companies are able to bring remote POs and domains into central datacenters, given increase in internet connection speeds.
- Fault Tolerance
- VMware has several services that increase fault tolerance. These include: vMotion, Storage vMotion, VMware Site Recovery Manager, and so on. These require storage to be in the form of VMDKs on a VMFS filesystem. Use of Raw Device Mapping (RDM) will mean you lose these capabilities. VMare will also allow you to mirror your entire VMware server to another datacenter (at a significant cost). <--Is this an advantage?
- Business continuity. Backup and disaster recovery are easier. Centralizing VMs on a SAN allows snapshotting and backup on the SAN level rather than on a per server basis. Backup windows in this case are almost non-existant.
- Cost savings
- Cost savings can be realized in hardware (both procurement and maintenance costs), as well as HVAC and power costs.
During the design phase you should consider whether it is time to redesign the GroupWise system. This is especially true if your GroupWise system has grown a lot over time. Some signs that a redesign is in order are:
- If you still have the old Domain/PO combination, where every server has a domain, a PO and a webaccess agent running. You may be able to consolidate domains and/or post offices.
- Do you have too few post offices, or too many users per post office?
- Would it be best to build a new post office and move users?
- Are gateways and post offices running under one domain? It's better to have a domain and associated gateways running together, with the post office on a separate server.
- Are you running more than one post office per server?
- We have observed that you actually get better performance with two smaller post offices on one physical machine than you do with one larger post office on the same machine.
If you are consolidating post offices keep the following in mind regarding user moves:
There are things that are not moved when you do a move user
- Such as the event records used by the mobile device servers
- This can be traumatic for mobile users
- Move user has a tendency to break shared folders and address books
- Sometime you have to re-share them to get them to work
- Moving every user on a post office can dramatically increase the size of the post office data
- This is because the users end up with individual copies of attachments and distribution lists that were originally shared by all recipients.
- Moving a user breaks all status track for existing sent items
- Moving a user can cause a one time large re-download to their cache if they run in caching mode.
- Move user can encounter problem messages that it will re-try on for up to 7 days unless you force a complete
- Moving a user will change their Domain/Post office settings inheritance which can impact the way the user works.
Storage System Design
LUNS, VMDK vs. RDM, etc.
The first thing to decide when designing a virtualized GroupWise system is the type of disk storage to use. You shouldn't use local disks on the VMware server. Doing so will mean the loss of most of the advantages of virtualized storage. Data should be stored on a SAN.
The typical virtualization SAN setup is one or more LUNs on the SAN formatted with vmfs, and used to store all OS and date drives (as VMDKs). This scenario works well for a typical server that is not I/O intensive. GroupWise post offices are very I/O intensive. Putting a post office on the same LUN as other servers, and especially other post offices will reduce performance as read and write requests are delayed due to the activity of other systems sharing the LUN. The magnitude of the delay will vary based on many factors. These include:
- The type of SAN (iSCSI, Fiber Channel, etc.)
- The RAID level of the disks containing the LUN
- The speed of the disks in the SAN
- The activity level of other servers on the LUN
- The size of the post office, and
- The volume of email entering and leaving the system.
A better design for performance and disaster recovery mimics the traditional design of a clustered Novell Netware system:
- One LUN =
- One vmfs datastore =
- One VMDK containing
- One post office
- One VMDK containing
- One vmfs datastore =
You may consider using many smaller LUNs rather than a few larger LUNs. Size and number of post offices will be the major factors to consider.
VMDKs are generally better than using Raw Device Mapping. In many cases disk throughput will actually be better using VMDK files for storage. In addition VMDKs give you the advantages of all the disaster recovery and vMotion capabilities in VMware. The exceptional case you may need to use RDM is for clustering (Novell or Microsoft).
You should design and document your storage infrastructure carefully as part of the virtualization project. Using whatever planning, design, and documentation methodology works best for you.
Best practices are to virtualize on the same OS you would use to run GroupWise on a physical server. This section contains tips and tuning information focused on virtualizing GroupWise on SuSE Linux Enterprise Server or OES server.
SLES 11 on VMWare
- SLES11 sp3 + post patches <--SP3 isn't released yet?
- EXT3 File System
- Tuning Options
- Full on Linux -SAMBA may be needed for GroupWise Administration
SLES 11(or SLES 10) on VMWare Tuning Options
- A Base set of Software for SLES should be installed, this includes:
- Server Base Systematic
- Common Code Base
- GNOME Desktop Environment
- X Window Systematic
- GCC -which is under the C/C++ Complier Tools
- Kernel Source
- Optional: SAMBA which is Open Source
- Ncpfs from SLES11 SDK -for moving GroupWise® from NetWare®
- Firewall Disabled
- VNC Enabled -if you need remote access
- Postfix Disabled or port changed if GWIA running on server -SMTP 25 -Listen on Localhost
- NoATime on EXT3 set -improved file system performance
- VMXNET3 NIC Driver for SLES11/10/OES2
- VMWare Paravirtualized Driver for SLES11
- Not available for SLES10
OES2 Linux on VMWare
- OES2 sp3 + post patches
- NSS or EXT3 File System
- Tuning Options
- Great for transition to Linux and Windows Administration of GroupWise
OES2 on VMWare Tuning Options
- A base set of software for OES should be installed, this includes:
- Novell Backup/Storage Management
- Novell eDirectory
- Novell iManager
- Novell Linux User Management
- Novell NCP Server
- Novell Remote Manager
- Novell Storage Services (NSS)
- Optional: CIFS which is Novell's implementation of SMB (Do not do both SAMBA and CIFS)
Here are some NSS tuning tips that may improve the performance of your GroupWise system in cases where your post office is stored on an NSS volume
- In a Terminal, type 'nsscon'
- Then type the following as shown and for those references where VOL is listed specify the name of the NSS volume where GroupWise will exist. Remember
- Setting Cross Protocol Locks: See TID 7004594
- Edit /etc/opt/novell/ncpserv.conf file
- At the very end, type "CROSS_PROTOCOL_LOCKS 1" without quotes
- At the very end, type "OPLOCK_SUPPORT_LEVEL 0" without quotes
- Save the file
- Type "rcndsd restart" and press Enter
- Shut down the MTA by typing "rcgrpwise stop DomainName" and press Enter
- Start the MTA by typing "rcgrpwise start DomainName" and press Enter
Build Virtual Machines
Ways to build VMs:
- Clones - Use VMWare's "clone" function to duplicate an existing SLES virtual machine.
- Standard install - Create a new virtual machine and install the OS just as you would on a physical server.
Again, the virtual disks for GroupWise POs should be on the fastest storage available, and the VMs should run on hosts that are not overburdened with other VMs. Refer to your VMware documentation for details on the process of creating a virtual machine, and balancing resource allocation between VMs.
Install VMware Tools
VMware Tools should be installed on all VMs running GroupWise. They provide faster display, network and disk I/O performance and additional monitoring and management capabilities.
Build GroupWise System
Virtualization does not change the process of installing GroupWise. Novell has many resources to guide you through the process. This is a brief overview of the installation process:
- Download the installer.
- Install ConsoleOne and Snapins, DBCopy, GWCheck.
- Install Agents, but do not configure.
- Create the new Primary Domain.
- Create the New Post Office Domain(s).
- Link the New Domain(s) to the New Primary. Do NOT link to the old Domains, until its time to move users.
- Create the New Post Offices.
- Create the Gateway Domains.
- Create the Gateways.
- Install/Configure GWMonitor/GWHA.
- Create Test Users.
- Test the System.
- Move Mailboxes.
Virtualization does not change the process of migrating GroupWise data. Novell has many resources to guide you through the process. This is a brief overview of the data migration process:
- Move Primary Domain
- This can wait if there are gateways under the domain (Or consider building new Primary free of gateways/post offices)
- Move Post Office Domain(s)
- This can wait if there are gateways under the domain
- Move Post Offices
- Estimate 4 to 10GB per hour move speed
- Raw Device Mapping/Unhook NSS Volume/Hook NSS Volume to new server
- Move Gateway Domains and Gateways
- OR just create new Gateway Domains and gateways, then do a cut over of gateways
- I would strongly suggest that customers go through virtualization with their existing user/post/domain infrastructure.
- Focus on consolidating hardware
- Reducing GWIAs, Webaccesses, etc. is OK
- If there are two small post offices then place them together on one large virtual machine.
- The only motivation for moving users would be to reduce the number of POAs or just to simplify monitoring them. That is independent of virtualization.