SuperCharger High Availability?


SuperCharger High Availability?

quinton.currier

I haven't been able to find an article or previous question that identifies if SuperCharger handles high availability, but if there are any snippets I missed I would appreciate the links.

My question boils down to:
If I have a distributed subscription of 2 collectors and 40 forwarders evenly distributed and one of my collectors goes down, how long with it take for the forwarders to be reassigned to the collector that is still up?

I've seen that there is
a. The re-balance button
b. Supercharger will not automatically reallocate for a new collector added
c. Nightly distributes the new sources?
but still a little lost on what happens if a collector goes down

I am planning out the architecture for our environment and unfortunately unable to test this myself
Thank you
Tamas Lengyel

quinton.currier - 4/10/2019
I haven't been able to find an article or previous question that identifies if SuperCharger handles high availability, but if there are any snippets I missed I would appreciate the links.

My question boils down to:
If I have a distributed subscription of 2 collectors and 40 forwarders evenly distributed and one of my collectors goes down, how long with it take for the forwarders to be reassigned to the collector that is still up?

I've seen that there is
a. The re-balance button
b. Supercharger will not automatically reallocate for a new collector added
c. Nightly distributes the new sources?
but still a little lost on what happens if a collector goes down

I am planning out the architecture for our environment and unfortunately unable to test this myself
Thank you

Excellent question. Unfortunately, the answer is that Supercharger will not redistribute forwarders in distributed subscriptions if one of the collectors goes down. Why?

The problem is that redistribution takes long. It takes a relatively long time for a computer to see that it is in a new AD group. In the knowledge base article entitled 9. How To Purge Kerberos Ticket via Group Policy using Klist, we explain that when a computer is added to a group in AD it doesn't know that it's been added until one of two things happen:

1. The computer is rebooted
2. The Kerberos ticket cache is cleared which does not require a reboot.

So, let's say, Supercharger notices that a collector is down, but of course we don't know how long it will be down. If we would to redistribute the forwarders, the collector might come back long before the endpoints respond to the removal and added to the new collector. This is the reason currently we are not able to automatically redistribute forwarders in the case you outlined.



quinton.currier

Tamas Lengyel - 4/11/2019
quinton.currier - 4/10/2019
I haven't been able to find an article or previous question that identifies if SuperCharger handles high availability, but if there are any snippets I missed I would appreciate the links.

My question boils down to:
If I have a distributed subscription of 2 collectors and 40 forwarders evenly distributed and one of my collectors goes down, how long with it take for the forwarders to be reassigned to the collector that is still up?

I've seen that there is
a. The re-balance button
b. Supercharger will not automatically reallocate for a new collector added
c. Nightly distributes the new sources?
but still a little lost on what happens if a collector goes down

I am planning out the architecture for our environment and unfortunately unable to test this myself
Thank you

Excellent question. Unfortunately, the answer is that Supercharger will not redistribute forwarders in distributed subscriptions if one of the collectors goes down. Why?

The problem is that redistribution takes long. It takes a relatively long time for a computer to see that it is in a new AD group. In the knowledge base article entitled 9. How To Purge Kerberos Ticket via Group Policy using Klist, we explain that when a computer is added to a group in AD it doesn't know that it's been added until one of two things happen:

1. The computer is rebooted
2. The Kerberos ticket cache is cleared which does not require a reboot.

So, let's say, Supercharger notices that a collector is down, but of course we don't know how long it will be down. If we would to redistribute the forwarders, the collector might come back long before the endpoints respond to the removal and added to the new collector. This is the reason currently we are not able to automatically redistribute forwarders in the case you outlined.



Thank you Tamas, your explanation really helped in understanding.
As a followup question though - when using the rebalance (yellow reset) button in the subscription, does that require a Kerberos ticket purge as well? Or is that already handled by SuperCharger?

Please correct me if i'm wrong, but if a collector goes down for more than say 10 minutes - we could go in and force a re-balance through that reset button and removing the down collector from that distributed subscription.
Thanks
Tamas Lengyel

quinton.currier - 4/11/2019
Tamas Lengyel - 4/11/2019
quinton.currier - 4/10/2019
I haven't been able to find an article or previous question that identifies if SuperCharger handles high availability, but if there are any snippets I missed I would appreciate the links.

My question boils down to:
If I have a distributed subscription of 2 collectors and 40 forwarders evenly distributed and one of my collectors goes down, how long with it take for the forwarders to be reassigned to the collector that is still up?

I've seen that there is
a. The re-balance button
b. Supercharger will not automatically reallocate for a new collector added
c. Nightly distributes the new sources?
but still a little lost on what happens if a collector goes down

I am planning out the architecture for our environment and unfortunately unable to test this myself
Thank you

Excellent question. Unfortunately, the answer is that Supercharger will not redistribute forwarders in distributed subscriptions if one of the collectors goes down. Why?

The problem is that redistribution takes long. It takes a relatively long time for a computer to see that it is in a new AD group. In the knowledge base article entitled 9. How To Purge Kerberos Ticket via Group Policy using Klist, we explain that when a computer is added to a group in AD it doesn't know that it's been added until one of two things happen:

1. The computer is rebooted
2. The Kerberos ticket cache is cleared which does not require a reboot.

So, let's say, Supercharger notices that a collector is down, but of course we don't know how long it will be down. If we would to redistribute the forwarders, the collector might come back long before the endpoints respond to the removal and added to the new collector. This is the reason currently we are not able to automatically redistribute forwarders in the case you outlined.



Thank you Tamas, your explanation really helped in understanding.
As a followup question though - when using the rebalance (yellow reset) button in the subscription, does that require a Kerberos ticket purge as well? Or is that already handled by SuperCharger?

Please correct me if i'm wrong, but if a collector goes down for more than say 10 minutes - we could go in and force a re-balance through that reset button and removing the down collector from that distributed subscription.
Thanks

Supercharger does not handle the Kerberos purge, you'd have to do that manually.

Yes, you can remove the collector and force a re-balance manually, if you know the collector will be down for a while.

j

High Availability Feature Request

Example use case:

Collector 1
Security - Logon Events Subscription
System - Service Stop or Start Events Subscription

Collector 2
Security - Logon Events Subscription
System - Service Stop or Start Events Subscription

Active Directory Groups
Collector 1 - Security - Logon Events Subscription
Collector 2 - Security - Logon Events Subscription
Collector 1 - System - Service Stop or Start Events Subscription
Collector 2 - System - Service Stop or Start Events Subscription


Additional subscriptions for fail over on each collector:
FO - Security - Logon Events Subscription
FO - System - Service Stop or Start Events Subscription

Additional groups for fail over:
FO - Collector 1 - Security - Logon Events Subscription
FO - Collector 2 - Security - Logon Events Subscription
FO - Collector 1 - System - Service Stop or Start Events Subscription
FO - Collector 2 - System - Service Stop or Start Events Subscription

The sections under Collector 1, Collector 2, and Active Directory groups would work as they normally do.
The Active Directory security groups would be populated with the specific computer objects as set during balancing.
The Fail over security groups would be populated with the combination of Collector 1 and Collector 2 computer objects for each respective subscription.

During normal operations, the FO subscriptions would remain DISABLED.

SuperCharger would monitor the accessibility of the Collectors and/or Subscriptions.

When it detects that a collector/subscription is not accessible it disables the normal subscription(s) on the surviving collector and enables the FO subscription(s) on the surviving collector.

No new access token from updated group membership is required because the computers were members of all the groups all along.

SuperCharger continues to monitor for the normal subscriptions to become available and automatically enables the normal subcriptions and disables the FO subscriptions.

You would probably want a way to mark a subscription as either failover protected or a maintenance mode within SuperCharger to allow for intentional service stops.

Tamas Lengyel

jgianfrancesco - 11/26/2019
High Availability Feature Request

Example use case:

Collector 1
Security - Logon Events Subscription
System - Service Stop or Start Events Subscription

Collector 2
Security - Logon Events Subscription
System - Service Stop or Start Events Subscription

Active Directory Groups
Collector 1 - Security - Logon Events Subscription
Collector 2 - Security - Logon Events Subscription
Collector 1 - System - Service Stop or Start Events Subscription
Collector 2 - System - Service Stop or Start Events Subscription


Additional subscriptions for fail over on each collector:
FO - Security - Logon Events Subscription
FO - System - Service Stop or Start Events Subscription

Additional groups for fail over:
FO - Collector 1 - Security - Logon Events Subscription
FO - Collector 2 - Security - Logon Events Subscription
FO - Collector 1 - System - Service Stop or Start Events Subscription
FO - Collector 2 - System - Service Stop or Start Events Subscription

The sections under Collector 1, Collector 2, and Active Directory groups would work as they normally do.
The Active Directory security groups would be populated with the specific computer objects as set during balancing.
The Fail over security groups would be populated with the combination of Collector 1 and Collector 2 computer objects for each respective subscription.

During normal operations, the FO subscriptions would remain DISABLED.

SuperCharger would monitor the accessibility of the Collectors and/or Subscriptions.

When it detects that a collector/subscription is not accessible it disables the normal subscription(s) on the surviving collector and enables the FO subscription(s) on the surviving collector.

No new access token from updated group membership is required because the computers were members of all the groups all along.

SuperCharger continues to monitor for the normal subscriptions to become available and automatically enables the normal subcriptions and disables the FO subscriptions.

You would probably want a way to mark a subscription as either failover protected or a maintenance mode within SuperCharger to allow for intentional service stops.

Interesting proposal. We will definitely consider it. Thank you.

GO


Similar Topics


Reading This Topic


Login
Existing Account
Email Address:


Password:


Select a Forum....








LOGbinder Forum


Search