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

Enterprise Console / Update Manager - High Availability Options (2020)

All:

 

 I just want to confirm, as of February 2020, that there are no "native" High Availability or Clustering features in S.E.C. - Enterprise Console? 

  Nothing endorsed explicitly by SOPHOS?

 

To summarize, external High-Available options are:

*) A High availability VMWare container (vMotion + vSAN with full N+1)

*) Underlying SQL Server HA/Replication/AlwaysOn replication, and a "warm-standby" host 

*) Some exotic HA software clustering option (MSCS, Veritas VCS, etc.)

*) An SSL-Aware Layer4 load balancer switch (F5, A10, Radware, etc.)

*) Some combination All-of-the-above

 

merci && cordialement !

 

~Brian



This thread was automatically locked due to age.
Parents Reply Children
  • Thank you  

    And a question to  regarding HA:

      I see now that the communications between a managed client and a SEC is handled by IIOP/COBRA protocol over HTTPs/SSL Ports 8192,8193 and 8194.

      If I need to develop a low-cost HA solution other than vMotion-enabled VM, this can be done by having multiple or warm-standby SECs, and using the Migration script (https://community.sophos.com/kb/en-us/116737) as need to re-home clients.

        I see the RMS uses a CAC.pem file, so there is a trusted X.509 key, and thus a pairing process.

      Since there is no native Clustering features, the CAC.PEM will be different between SEC instances, so even if the IP/DNS/FQDN listed in mrinit.conf was a HA Layer3/4 VIP that could migrate between active standby hosts, and even if the CAC.pem cn= or subAltName= could reference the floating VIP instead of the participating individual hosts with different SEC installation instances, one would still need to re-home with the VBS migration script to establish the trust with the new unique per-host/per-installation certificate (cac.pem).

    Also, if the SQL instances consumed by the different SEC instances are not replicated, then probably also:  the pairing / re-home'ing / registration process also needs to "register" some client data in the underlying SQL database on the SEC.

    Thanks,

      ~BAS

  • Hello BAS,

    I'm not an expert [:)], and it's time to leave so just a short answer for now.

    You can "clone" a server's identity -  please see Re-using the same Remote Management System (RMS) certificates ....

    As for the database: I'd have assumed that a remote SQL server/cluster is used when HA is desired.  

    Christian

  • Thank you!

       You guys have been stellar on Thursday!

        Have a great weekend!

    ~Brian

  • Hello Brian,

    thanks, not yet weekend.

    There are some intricacies w.r.t. a common database and a different (but with the same "identity") Management Server taking over. A change of the IP address poses no problem. According to Sophos Enterprise Console: Changing domain name, computer name, network type or upgrading of OS are not supported once SEC is installed a name change does.
    BUT: A server to server migration is essentially a server rename (unless you use the same name that is not assumedin the migration guide). Server-B uses the restored (or unchanged remote) database that Server-A used and puts itself into Server-A's position. This does not work all the time. On one of the latest migrations I had to use ResetUserMappings.sql. Thus assuring another server takes over automatically (without manual intervention) might require some "research and scripting".

    Christian