Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 2 subscribers
  • Views 2598 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Astaro HA act as one best practice

mckarto
Hi everybody

We need to rethink our Firewall concept and are looking for the best configuration.

Situation:
At the moment we have two ESXi Host (esxi55-a, esxi55-b), each has an own Astaro v8 Firewall (asl8-a, asl8-b) with 4x1GBit on WAN site (lag0) and 4 interfaces for different internal networks (internal, develop, productiv, sandbox). 
Both ESXi Hosts share the same storage, so if we move a vm from host esxi55-a to the other host esxi55-b we have to take down it's external IP address from firewall als8-a and configure it on the other asl8-b and have all rulesets on both firewalls.
at the moment 55 virtual machines run on the hosts.
not very elegant, historically grown, shame on me.

New situation and my wishes:
4-8 ESXi Hosts with up to 100 vm's in different internal networks (develop, productive, internal, direct)

HA-act as one?
Connecting all NICS from the ESXi Servers to two switches (one for failover).
Both switches are connected to asl9-a and asl9-b which are in a somewhat HA active/active/act-as-one state. [:S]
The administration of external additional IPs for the vms, the NAT and rulesets are only configured once on asl9-a.
The traffic gets load-balanced over both, asl9-a and asl9-b.
If one of the firewalls fails, the other one takes over the traffic.

correct? i didn't find a lot more specific information in the docs.
What about the licenses, do I need active/active upgrade?

software:
Astaro Security Gateway v8, 50 IP each
hardware:
fujitsu rx300 s5 with 6GB RAM, XEON quadcore, 8 intel nics, momentary mostly not very busy (RAM 25%, CPU 8%, Disk 2%, NW Usage extern lag0 max 55Mbps (7MB/sec), average 704kbps)

thanks for anyone reading, hopefully understanding and more hopefully for any hints.

mckarto


This thread was automatically locked due to age.
Parents
  • 0
    Hi mckarto,

    To answer your question about running an Active/Passive(HA) cluster in VMware ESX(i), yes you can quite easily. I don't use it in production (we HA an UTM220 pair in production) but have experimented with HA in my lab using vm's spread over several hosts.

    HA in virtual machines works as well as if the nodes were physical machines, you only need to make one tweak for a quirk of VMware ESX(i)'s vSwitches.

    The tweak is you have to disable virtual MAC's in the UTM cluster config (a command line change) because ESX(i) vSwitches will see the slave node's virtual MAC and forward the traffic to the slave's interface instead of out onto the rest of the LAN. Disabling the virtual MAC will cause the slave & master to have separate MAC's which the vSwitch will be able to correctly handle.

    The other option, depending on down time tolerances, and vmware licensing, is to run the UTM virtual machine on an ESXi cluster that supports either High Availability(HA) or Fault Tolerance(FT). If you can support a few minutes of downtime during a host crash, then vSphere HA can migrate the UTM vm to a new host. If you can't and are licensed for Fault Tolerance, then FT can minimize that downtime to miliseconds (quite literally dropped pings and it's switched over)
Reply
  • 0
    Hi mckarto,

    To answer your question about running an Active/Passive(HA) cluster in VMware ESX(i), yes you can quite easily. I don't use it in production (we HA an UTM220 pair in production) but have experimented with HA in my lab using vm's spread over several hosts.

    HA in virtual machines works as well as if the nodes were physical machines, you only need to make one tweak for a quirk of VMware ESX(i)'s vSwitches.

    The tweak is you have to disable virtual MAC's in the UTM cluster config (a command line change) because ESX(i) vSwitches will see the slave node's virtual MAC and forward the traffic to the slave's interface instead of out onto the rest of the LAN. Disabling the virtual MAC will cause the slave & master to have separate MAC's which the vSwitch will be able to correctly handle.

    The other option, depending on down time tolerances, and vmware licensing, is to run the UTM virtual machine on an ESXi cluster that supports either High Availability(HA) or Fault Tolerance(FT). If you can support a few minutes of downtime during a host crash, then vSphere HA can migrate the UTM vm to a new host. If you can't and are licensed for Fault Tolerance, then FT can minimize that downtime to miliseconds (quite literally dropped pings and it's switched over)
Children
No Data