Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 10 replies
  • Subscribers 4 subscribers
  • Views 3586 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

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

Brian Seklecki

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.
  • 0

    Hello Brian,

    High Availability is of course nice to have, is it necessary? SEC and SESC don't depend on 100% uptime. Things like An SSL-Aware Layer4 load balancer switch seems like an overkill. Do you have a particular motive for this enquiry?

    Christian

  • 0

    I work in CyberSecurity and come from an Enterprise/Telecom background.

     

    The inability to push mission critical updates to a managed client would be considered a Severity 0 service disruption

     

    Therefore, I am uncomfortable propose any solution to any client that doesn't have integrated BCDR/HA-DR contingency planning, no matter how Janky.

     

    Merci,

    ~BAS

  • +1 in reply to Brian Seklecki

    Hello BAS,

    understood, maybe I should add some details to my previous remark.
    SEC/SUM pulls the updates from a CDN checking in five minute intervals (minimum). The updates are written to the update location. Endpoints in turn check this location and pull the updates if there are. An additional SUM can do the same and write to a location that's on the endpoints configured as secondary. The operation of these to SUM - even though managed by the same SEC - is independent. IMuO* no need for HA as far as updating is concerned.

    Management is independent of updating. It's management where you it's more likely that a disruption can be critical, e.g. when you have to amend a policy to deal with a false positive or similar, i.e. you have to configure an exception/exclusion. YMMV but I had such a thing twice in fifteen years, one wasn't even pervasive. Mind you, both required manual intervention so there must be some knowledgeable person on duty. And around this time SEC must go or have gone belly up. Do these chances really call for HA?
    Thinking about it - I can imagine it's possible to have an appropriately configured SEC on standby that can take over within minutes. Hm, would be fun to put this notion to test.

    Christian
    * undiscerning 

  • 0 in reply to Brian Seklecki

    If thats the Case, switch to Central.

    Central has a Uptime, you most likely never can archive (based of Cloud services). 

    https://centralstatus.sophos.com/#!/

    Because of the cloud based approach, the uptime and update cycle is always enabled. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

      I forgot to mention, I require a solution with HA for use in air gap environment with asymmetric manual updates

  • +1 in reply to Brian Seklecki

    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 Videos | Knowledge Base  |  @SophosSupport | Sign up for SMS Alerts |
    If a post solves your question use the 'This helped me' link

  • 0 in reply to Jasmin

    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

  • +1 in reply to Brian Seklecki

    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

  • 0 in reply to QC

    Thank you!

       You guys have been stellar on Thursday!

        Have a great weekend!

    ~Brian

  • 0 in reply to Brian Seklecki

    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   

Unfiltered HTML