7 Replies Latest reply on Apr 21, 2015 1:32 AM by rhinomike

    MEG 7.5 Clustering

    rodvin

      Hi,

       

      I'm having some doubts in configuring three VirtualAppliances in cluster mode.

      The documentation provided by McAfee is very poor onthis matter, so I decided to create this thread for anyone share theirexperiences.

       

      I'm deploying three Virtual Appliances, 1 Master, 1failover and 1 Scanner.

      For the Master and the Failover, I've configured thesame VIP in both appliances and they successfully shift from one to anotherwhen I do a shutdown.

       

      Now, regarding to the Scanner Appliance what specificconfiguration do i need to make?

      Can I have visibility over the scanner in the masterweb-interface, under the Clustering box in the Dashboard- Specific load in eachappliance, etc..

       

      Feel free to give some tips and/or comments about this!

       

      Best regards.

        • 1. Re: MEG 7.5 Clustering
          feeeds

          Have you learned anything new on the clustering ability? I agree with you about the lack of documentation. I have had a ticket open for almost 2 weeks now requesting assistance. What does the scanner box do? I did not ready anything about that in the docs.  thanks,

          • 2. Re: MEG 7.5 Clustering
            rodvin

            Hi,

             

            I was waiting for someone to come forward and share some ideas, but I think that will not happen in a near future..

            I didn't learn anything new since I've open this thread, I've tried to search in forums but still nothing.

             

            I'll probably do the deployment in production later on today, but I haven’t decided yet with which scenario I'll go, Standalones or with the cluster option.

             

            I’ll give you feedback and some notes on how it went.

            • 3. Re: MEG 7.5 Clustering
              eplossl

              So the idea behind clustering is that there is a primary appliance which has all the configuration and keeps all the other devices maintained (in terms of policy, at least), a secondary appliance in case the primary goes down, and zero or more dedicated scanner appliances.  The master and failover take all incoming connections and hand them off to one of the configured scanners. 

               

              To get a little deeper into it, the VIP for the cluster is held by the master appliance.  All mail coming into or going out of the cluster goes through that appliance.  In the event that something happens to the master and it stops responding to VRRP communications from the cluster, the Failover appliance takes over the VIP and all the mailflow traffic.  The Failover would then respond to arp requets for the vip and handle the communications for it. 

               

              It is my belief that when Virtual Hosts get involved, it gets a lot more complicated, but can still be done.  In those cases, the master and failover still manage the VH IPs, and simply hand off the scanning to the scanner devices in the cluster.  For all intents and purposes, the traffic still comes from the cluster master anyway.

               

              I hope this helps.  If you would like some additional information, please feel free to let us know.

              • 4. Re: MEG 7.5 Clustering
                feeeds

                What have you done with firewall NATing? When we send mail outbound, it comes from the actual IP of the VM, vs the VIP. Inbound is fine, mail is being sent to the VIP just fine, it's outbound that is the issue.

                So we are trying to figure out how to NAT the cluster on the firewall since it does not appear to be coming from the VIP.

                • 5. Re: MEG 7.5 Clustering

                  Hello,

                   

                  If you need all nodes in the cluster to use the same IP address when connecting outbound, you will need to set up an outbound address pool under Virtual Hosting for the clustered appliances to use.

                   

                  The default behavior of a clustered MEG environment is to have each node using its own assigned IP address when connecting out.

                   

                  Hope this helps.

                  • 6. Re: MEG 7.5 Clustering
                    VriendP

                    Clustering with virtualhosts, here's how I did it.

                     

                    Create a normal cluster in the way that is described in the manual, eg:

                     

                    On both appliances:

                    1. On the primary interface, add an extra virtual IP that is used as the cluster IP.

                    2. On the primary interface, add an extra virtual IP that is used for each of the virtual hosts

                    3. Set the appliance to cluster mode, being Cluster Master or Cluster Failover. Include the scanner role and make sure both appliances use the same cluster (VRRP?) group ID.

                     

                    Individual Appliances:

                    Log on to either appliance or preferably the IP used in step 1, which will take you to the Cluster Master

                    Go to System, VirtualHosts and create each virtualhost using one of the IP's that you used in step 2

                    Configure Anti-Relay as well as policies as needed per virtualhost.

                     

                    The Virtualhost bit:

                    I created 2 additional virtualhosts as this is required for two different sources in the network that are required to send their mail from a different public IP. The private IP that was assigned to each virtualhost is used to both receive and deliver outbound email, where NAT on the firewall takes care of mapping the private IP to the desired public IP.

                     

                    Both the Cluster Master and the Cluster Failover appliances have a scanning role enabled by default. I would recommend to stick with two appliances unless a third -and perhaps more than a third- scanning node is required for handling the load. I didn't test that because it's out of scope for me but I would strongly recommend testing this thoroughly before implementing such setup in production.

                     

                    I've included screenshots of the applicable parts of the configuration. Hope this helps someone.

                    meg1_1.JPG

                    10.0.0.201 is the node IP

                    10.0.0.200 is the cluster IP

                    10.0.0.11 is the first vhost IP

                    10.0.0.12 is the second vhost IP

                    meg1_2.JPG

                    meg1_3.JPG

                    vhosts are replicated inside the cluster so they have to be created only once. Below are the settings of each tab of each vhost.

                    meg1_4.JPG

                    meg1_5.JPG

                    meg1_6.JPG

                    meg1_7.JPG

                    meg1_8.JPG

                    meg1_9.JPG

                    • 7. Re: MEG 7.5 Clustering
                      rhinomike
                      VriendP,

                       

                      Thanks for the guide. Awesome stuff you have put together.

                       

                      Just a small comment. You don't think you need to setup some of the Virtual IPs you created on step 2.

                       

                      In particular the following IPs

                       

                      10.0.0.11 is the first vhost IP

                      10.0.0.12 is the second vhost IP

                       

                      Instead, I think you can proceed with creating the Virtual Hosts directly, without bothering creating the virtual IP address associated with the "Inbound / Intercept Address Pool"

                       

                      The hint that led me into this conclusion is the following comment within the online help.

                       

                      You cannot ping the IP address externally, or see the address by running the ip addr show commands. To test that the virtual host is listening on the expected address, telnet to the configured SMTP port.

                       

                      I did create an appliance with just two IPs ( 10.0.0.201 - a "physical" IP and 10.0.0.200 the cluster Virtual Address) and yet was able to telnet to port 25 of 10.0.0.11 and 10.0.0.12 without issues.