cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6425
Views
20
Helpful
3
Replies

ESA High Availability configuration

Kanat Nurzhanov
Level 1
Level 1

Hello!

 

I have one ESA 300v virtual appliance, AsyncOS version 11.0.

Customer needs fault-tolerant configuration before testing it in production environment. I am a little confused about HA concept of ESA operation.

1) What is clustering from ESA perspective? 

How do I set fault-tolerant configuration of two ESAs? If main appliance falls down, would the second inherit it's operation? Or I should set two independant ESA instanses and use MX records for it? What is clustering then?  What is your advice to rapidly recover email handling when ESA falls?

2) What about licensing? If I deploy second VM ESA 300v, should I use the same license pack that I used for first appliance? Or should I request separate pack?

Thanks in advance!

2 Accepted Solutions

Accepted Solutions

High availability for the ESA is about how you get mail to the
two or more appliances: dns/mx records, load balancer, etc.

Externally we have 2 A records and 2 mx records that point at them. Internally the outbound connector in Exchange has the IP for both ESAs.

Clustering would be better named Configuration Replication. It allows you to change the configuration from any ESA and it will replicate it to the others as appropriate.

You can spin up as many VMs as you need. Deploy the ova, use the same license file, configure.


View solution in original post

Hello,

 

If you have the ESA/s within the same cluster, then most of the configuration will be at the cluster level, meaning both ESA/s use the same settings. Some settings remain machine-independent, like routing, interface(s), quarantine(s), ETC. You are also correct whereas you do not need an SMA for reporting/tracking/quarantines, as all of these can stay local to the ESA. 

 

As for the scenario you mentioned, that can certainly be one way of setting them up. 

 

Thanks!

-Dennis M.

View solution in original post

3 Replies 3

High availability for the ESA is about how you get mail to the
two or more appliances: dns/mx records, load balancer, etc.

Externally we have 2 A records and 2 mx records that point at them. Internally the outbound connector in Exchange has the IP for both ESAs.

Clustering would be better named Configuration Replication. It allows you to change the configuration from any ESA and it will replicate it to the others as appropriate.

You can spin up as many VMs as you need. Deploy the ova, use the same license file, configure.


 Thank you, Ken.

So two appliances has two independent configurations, correct? Or do they have the same config? 

What happens when one of them falls?

 

From the other topic: For the Outbound mail traffic , in case the ESA at the main site fails down , the Exchange will be configured to point to the ESA at the DR Site which was in Standby State. And for the Inbound traffic, we will rely on the MX-records to route the Inbound traffic to the ESA at the DR Site in case the ESA at the HQ fails.

 

Does the above scenario work? So second ESA in a cluster should be configured as a standby right?

 

And the last: I need SMA only when centralized quarantine, tracking required? When there is no SMA I manage two inpependent quarantines, right?

 

Thank you!

Hello,

 

If you have the ESA/s within the same cluster, then most of the configuration will be at the cluster level, meaning both ESA/s use the same settings. Some settings remain machine-independent, like routing, interface(s), quarantine(s), ETC. You are also correct whereas you do not need an SMA for reporting/tracking/quarantines, as all of these can stay local to the ESA. 

 

As for the scenario you mentioned, that can certainly be one way of setting them up. 

 

Thanks!

-Dennis M.