I'm working on behalf of a client who's experiencing the joys of trying to deploy MEG7, which they purchased to help implement NDLP 9.2, and unfortunately they're losing confidence quickly in MEG 7 being ready for prime time. This is a brand new deployment of MEG, Configuration is
Experience thus far: They've seen 3 times in 5 days that this pair of boxes (which aren't wheeling much traffic at all), suddenly becoming non-responsive on their virtual IP address. When they're working, all is well, and you can netcat or telnet to port 22, 25 or 10443 on the virtual IP and get a TCP connection and appropriate response, but ..for reasons we've yet to figure out and mcafee support has yet to be able to tell us... those ports on the virtual IP stop responding, giving "connection refused" immediately.
To recover, you can:
When the VIP is refusing connections, both of the appliances remain reachable on their own physical IP's on both port 25, 10443, 22. I'd love to figure out what's killing the vip.
Mcafee has analyzed the MER upload and thus far reports "everything looks okay." We'll be providing them network captures the include the client's observations today of the services being available in teh morning, unavailable on the VIP midday, and then...available again this afternoon on the VIP.
This all leads me to wonder... is there anyone actually running this in production? Starting to feel like a beta tester. TIA for any help or experience!
Good news: discovered a vestigial load balancer pool that was doing odd things to the virtual IP that's likely to explain why the VIP was doing this "now ya see it, not ya get refused" routine.
Naturally, we're still rather interested in whether anyone is willing to admit they're running MEG7 in production. :-)
The inability to run in Cluster mode simultaneously to doing secure web delivery is a bummer until they fix a bug there, but I believe that hotfix is coming soon.
Heh. Forgot about this thread. Once the mystery of "vegistial load balancer virtual IP" was cleared things seemed to be okay... right up to the time we had a hardware issue on one of the brand new MEG boxes. Since the RMA of that box sanity has come to our MEG7 installation. We haven't pulled this into production just yet, but it at least now looks stable enough to move forward. Barring of course the next bizarre problem around the corner. :-)
I'm running 2 virtual appliances of MEG 7 in production, but they're not clustered. I'm managing them through EPO in case they explode so I can just reinstall them and apply the polices from EPO.
I don't recommend using quarantine manager
Thanks for your response and experience sharing.
Would you be willing to share more (via private message if you prefer) on your MQM experiences? McAfee seems to suggest them for a 2-server setup for a couple of reasons which seemed reasonable. 1) to avoid the possibility of users getting 2 separate digest messages as the only means of managing their queue and 2) to provide additional warning/buffer from a disk filling proposition where in the absence of MQM, you might fill disk on the gateways themselves and they'd grind to halt and not route mail (whereas in a disk full MQM situation, mail will still flow and things somehow queue up on the hopefully not full disk MEG appliances).
I was at the cusp of spinning up an MQM this week in fact.. :-)
If your virtual appliances aren't clustered, what are you load balancing with, or is one a cold standby? I know there are lots of ways to skin the cat here!
Thanks for any info!