Ed Hanley is one of Novell’s Strategic Services Architects. In other words, he is the guy to get things done within our customer base. He recently shared some examples of customers that he was able to migrate from older versions of GroupWise to GroupWise 8.0.2. Here are some of the details about the customers, their environments and what Ed did to move them to the latest version.
Customer 1: Fortune 500 Client Centralized GroupWise messaging system 20,000 mailboxes 20 1,000 user POs (1,000 mailboxes / PO) Novell NetWare 6.5.8 Novell Cluster Services - Three separate 15 node clusters Some stand alone servers for WebAccess and GWIA gateways Servers = HP Proliant BL20p G4 Blades, 2 Intel Xeon, 2 Cores @ 2.66 GHz, 8 GB RAM with NetWare 6.5.8
Customer upgraded all GroupWise services from v7.0.3 to v8.0.2 in place on same server hardware. OS running the services did not change. All stayed on NetWare. Upgraded to v8.0.2 code occurred on the NetWare clustered servers and on the stand alone NetWare servers.
Server hardware was powerful in the first place, so when the GroupWise v8.0.2 client started to be deployed via ZENworks, no slowdown occurred to the messaging system. Customer has a strict email policy in place that keeps the mailboxes lean and fast. User desktops are locked down where they do not have administrator rights.
Customer 2: University Environment Centralized GroupWise messaging system 48,000 mailboxes 32 POs (1,500 mailboxes / PO) Two POs per server (not a best practice) Novell NetWare 6.5.8 Old Environment = Novell Cluster Services - Three separate NetWare 6.5.8 clusters New environment = Novell Cluster Services - One SLES 10 SP3 cluster Some stand alone servers for WebAccess and GWIA gateways Old Servers = IBM eServer xSeries 345, 2 Intel Xeon, Dual Core @ 1.60 GHz, 4 GB RAM with NetWare 6.5.8 New Servers = IBM BladeCenter HS22 7870, 2 Intel Xeon, Quad Core @ 2.00 GHz, 36GB RAM with SLES 10 SP3 64-bit OS boots off local HDs in server. GroupWise data comes off SAN LUNs via HBAs in servers both old and new servers.
Customer upgraded all GroupWise services from v7.0.3 to v8.0.2 in place on same server hardware running NetWare 6.5.8. OS running the services did not change. All stayed on NetWare. Upgraded to v8.0.2 code occurred on the NetWare clustered servers and on the stand alone NetWare servers.
Server hardware was NOT powerful enough to handle the new GW 8 client load that was to follow. When the end users had the older client, the system was working fine. End user experience was OK. When the GroupWise v8.0.2 client started to be deployed, the GW 8 system started to slow down where end users were getting very long delays in using the GW client in on-line mode. Client deployment was executed where the end users were informed that they can download the GW 8 client from internal web pages. The end users did this gradually over many months.
Customer does NOT have a strict email policy in place so user mailboxes are very large (i.e. some have 50,000 items in the main Inbox folder). After user complaints started to come in on a regular basis. The IT team resolved the poor GW performance issue by building one bigger new SLES 10 SP3 OES2 Novell Cluster on new IBM Blade servers. GW PO migration was done over a two week period using the GW Linux dbcopy utility. The remaining GW gateway services were migrated on the 3rd week. Users are now happy with fast on-line client response times with their large mailboxes.
Customer 3: Government De-centralized GroupWise messaging system 7,000 mailboxes Novell NetWare 6.5.8 All stand-alone servers (varies from 300 to 1,500 mailboxes / PO) Old Servers = Dell PowerEdge 2600, Single Intel Xeon III @ 2.40 GHz, 4 GB RAM with NetWare 6.5.8 New Servers = HP Proliant BL460c blade, 2 Intel Xeon, Dual Core @ 2.27 GHz, 12 GB RAM with SLES 10 SP3 64-bit
Customer upgraded all GroupWise services from 6.5.6 to v8.0.1 HP1 in place on same server hardware running NetWare 6.5.8. OS running the services did not change. All stayed on NetWare. Upgraded to v8.0.1 HP1 code occurred on the NetWare stand alone servers.
Server hardware was NOT powerful enough to handle the new GW 8 client load that was to follow. When the end users had the older 6.5 client, the system was working fine. End user experience was OK. When the GroupWise v8.0.1 HP1 client was deployed to all the desktops, the GW 8 system slowed down drastically that day only for the larger POs that had around 900 or more mailboxes in them. End users were getting very long delays in using the GW client in on-line mode. Client deployment was executed via ZENworks to all the desktops all at once.
Customer does NOT have a strict email policy in place so user mailboxes are very large. User complaints came in within hours to days to their Help Desk right after getting the new GW 8.0.1 HP1 client. The IT team resolved the poor GW performance in one of two ways:
(1) For the end users that have very large mailboxes with thousands of items in single folders, their GW Windows client was downgraded back to the old client to get them functional again that day. Note: The old GW 6.5 client only displays the first 5,000 items in a folder.
(2) For the large POs, a new SLES 10 SP3 64-bit server was built and the PO file structure was copied over using the GW dbcopy utility. The smaller GroupWise POs on NetWare did not have such a slow down as compared to the larger POs.
Users on the large POs are now happy with fast on-line client response times with the new GW 8 client. The long term solution that this customer had always planned to do, was build a new SLES 10 SP3 OES2 cluster and centralize all of their remote POs into the main data center and use Novell BCC as their DR solution to their second data center.
I wanted to provide some insight into the upgrade methodology, hardware and tools used to get customers on GroupWise 8 and make sure they have a positive experience. Moving to SLES is generally part of that migration story and has been documented in the scenarios above.
This are really impressive examples. Good to know that whe have just the right OS for our Groupwise system. (SLES10SP2+OES2SP1, must be updated to SLES10SP3+OES2SP2 i know). Whe did update our Groupwise 8.01 mailsystem to 8.02HP1 a few weeks ago, and this went good. But whe still must upgrade our Groupwise Clients for Windows from 7.02 to the latest 8.02HP1. I was wandering, how did you do this update on all those endusers? Whe have zenworks with can help us. But it's my experience that you first must Cleanup your 7.02 client from the Windows system, before you can install the new Groupwise 8.02HP1 client. This looks to me as a very big challenge to do handle this on 20.000 users. Our did you have a good 'script or trick' for this?
Q1 - Can you verify if the amount of memory for the GW8 Client has increased and if the amount of memory on the server has increased ?
A1 - We are not aware of any 'additional' memory requirements over and above what is recommended by the OS. We have only updated our minimum requirements based on OS documented requirements.
Q2 - Can you verify whether BES 5 has more load on the POA as well, comparing to BES 4.* ? Considering SOAP use...
A2 - There is more/different load on the POA between versions of BES. However, there are also many optimizations and improved performance changes specifically for BES/SOAP. BES 4.x was based on our ObjectAPI and it is a client-side API, not server - even though we ran it on the server. This is a difficult question to answer because we are comparing two completely different architectures. The additional load is generally because of new functionality - not because of the underlying technology.
Q3 - Is it possible to turn some of these features of the GW8 Client off ? To make the load less as well. Perhaps not the most charming idea, to turn features off, but hey, if it makes the network and GroupWise work better.
A3 - Yes, we have found that the most significant impact on POA load comes from changing to caching mode over online mode. This, of course, is not new to GroupWise 8, but because there are more features in GroupWise 8 clients, this tends to have an even larger impact. Less chatty clients make agents run better...
More GW8 features increase traffic between client and server. This puts more load on the POA and the network. SOAP adds load to the POA.
Q1 - Can you verify if the amount of memory for the GW8 Client has increased and if the amount of memory on the server has increased ?
Q2 - Can you verify whether BES 5 has more load on the POA as well, comparing to BES 4.* ? Considering SOAP use...
Q3 - Is it possible to turn some of these features of the GW8 Client off ? To make the load less as well. Perhaps not the most charming idea, to turn features off, but hey, if it makes the network and GroupWise work better. Please keep in mind if turning off features is an option, does this have to be for all users (feature turned off in the Client settings), or one user (feature turned off within the Client), or perhaps a Post Office, a MTA, an Internet domain, a Novell group, a GroupWise group.
I will answer for Ed and then request he elaborate as needed.
The GroupWise 8 clients have more features that have increased the network traffic between client and server. This increased traffic increases the load on the POA and the network. We have also increased our use of SOAP and with more applications, like Mobility, hitting the POA with requests, the more it can be impacted.
In general, newer harder will mitigate the problem. Engineering is also looking at profiling some of these performance areas and making sure that all requests are necessary or finding ways to combine requests to reduce the network traffic.
What OS [1] combination was used with scenario #2 University ? SLES 10 sp3 64bit with OES2sp1 or OES2sp2 ? SLES 10 SP3 with OES2 SP2 And what file system [2]: reiser, ext3 ? ext3
Support
Documentation
Learning Services
Partner Programs