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
  • Hi  

    High Availability for the Sophos Enterprise console can be facilitated by having the VM server where vMotion is enabled, so in case the host is down, the VM server will migrate to another VM host and in this way, your Sophos Enterprise console should be available as well.

    Coming to SQL, if you have clustered SQL environment, you can achieve the HA with SQL as well. Please refer to this article for the Upgradation to Clustered SQL.

    Regards,

    Jasmin
    Community Support Engineer | Sophos Support

    Sophos Support VideosKnowledge Base  |  @SophosSupport | Sign up for SMS Alerts |
    If a post solves your question use the 'This helped me' link

  • 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