• State Not Answered
  • Replies 3 replies
  • Subscribers 28 subscribers
  • Views 192 views
  • Users 0 members are here
Options
Related

Central Search with 2 Nodes

andrew myers
1 month ago

Quick question on a setup with 2 SPS nodes.

Is there any way to have some sort of centralized search as with the Search Master / Search Minion setup? A client has 2 nodes and they don't have the budget for a 3rd, so they're trying to figure out a solution with just the 2.

If we turn one into a Search Master, we'll only have a single node for sessions which makes a single point of failure. But keeping them both with just Search Local makes it hard to find sessions.

Is there a way to either;

1. Set one up as Search Master and the other as Search Minion / Managed Node, and then on a failover have the search master become a standard Managed Node to reduce downtime?

2. Use some sort of HA setup to switch between the two while keeping centralized session logging?

3. Have some sort of external archive server where session info from both end up, for external centralized logging?

Thanks,

Parents
  • 0 1 month ago

    Hi Andrew,

    Its not a common practice to change the roles of SPS nodes from one role to another on a regular basis after the initial cluster setup was determined.

    Another way, if a customer is only using SPP initiated is to keep both SPS nodes as Search Local and then manage the traffic from SPP Managed Networks to go to a particular SPS node then if you need to failover you would modify the Managed network to assign the other SPS node instead (This way traffic will go to only a specific assigned SPS node).

    For Search Master role, you do need at least 3 SPS nodes to have better redundancy and central search at the same time.

    Thanks!

Reply
  • 0 1 month ago

    Hi Andrew,

    Its not a common practice to change the roles of SPS nodes from one role to another on a regular basis after the initial cluster setup was determined.

    Another way, if a customer is only using SPP initiated is to keep both SPS nodes as Search Local and then manage the traffic from SPP Managed Networks to go to a particular SPS node then if you need to failover you would modify the Managed network to assign the other SPS node instead (This way traffic will go to only a specific assigned SPS node).

    For Search Master role, you do need at least 3 SPS nodes to have better redundancy and central search at the same time.

    Thanks!

Children
  • 0 29 days ago in reply to Tawfiq.Ahmad

    Thank you for the quick reply!

    Probably will look into using Managed Networks, but I was also wondering about Archiving the data.

    Is it possible to send Session data to an archive server such that the archived data is viewable from either node? Either that, or setting up something like Safeguard Player on the archive server to be able to parse through archives from both SPS nodes after they're sent over?

  • 0 29 days ago in reply to andrew myers

    You can archive session audit trails from both SPS nodes using an Archive Policy then assign the Archive Policy to the Connection policy you wish to be archived but with Search Local role you would only be able to search for these audit trails from the SPS node Web UI where that session was recorded locally.

    You can replay archived .ZAT audit trail files using Desktop Player but the user and connection details will only show up after opening the .ZAT file in the player, one way is to configure the archive policy with a path template based on Connection date (refers to the time the connection started) so you can easily identify the session start date to locate the audit trail in the archive server and you should also select to Include the Cluster Node ID in the path in that archive policy.

    As per Admin guide, select to Include the Cluster Node ID in the path (    This ensures that the node ID is included in the path of the relevant directory, which is required to prevent cluster nodes from archiving data to the same location. Archiving data to the same location would result in data loss. In addition, including the node ID in the directory name also enables easy identification.)

    Thanks!