ifstated(8) improvement
Hi tech, I've been using ifstated for years now for failover my links and I've developed quite some tools on top of it. But, I've recently reached a cornerstone. I've developed a series of scripts that are called with the run argument on the init of each state that perform a series of tasks. One of these tasks is to write to a database (currently sqlite) and based on the last state changes, perform different actions. But, since I can't talk directly to the ifstated daemon, I have a delay since I can affect any state change on it. So, I've been planning on improving ifstated itself, for it to be able to keep track of state changes and the time they happened, so it can be able to improve it's decision making capabilities in the sense that it can perform state changes based on previous states changes. Not just on external commands results or interface statuses. You could say something like this: set-state X if ! previous_state Y More to that, it could be also based on a more simplistic approach, using counters. With the possibility of zeroing the counters from ifstated.conf based on conditions. Or both, time and counters. So one could change to a different state if one of the links is flapping between states. I know this makes it not a pure machine state, but I believe that the improvements can be worth the change. What you guys think? Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: ifstated(8) improvement
On Mon, Jun 9, 2014 at 10:38 AM, Giancarlo Razzolini
grazzol...@gmail.com wrote:
Hi tech,
I've been using ifstated for years now for failover my links and
I've developed quite some tools on top of it. But, I've recently reached
a cornerstone. I've developed a series of scripts that are called with
the run argument on the init of each state that perform a series of
tasks. One of these tasks is to write to a database (currently sqlite)
and based on the last state changes, perform different actions. But,
since I can't talk directly to the ifstated daemon, I have a delay since
I can affect any state change on it.
So, I've been planning on improving ifstated itself, for it to be
able to keep track of state changes and the time they happened, so it
can be able to improve it's decision making capabilities in the sense
that it can perform state changes based on previous states changes. Not
just on external commands results or interface statuses. You could say
something like this:
set-state X
if ! previous_state Y
More to that, it could be also based on a more simplistic approach,
using counters. With the possibility of zeroing the counters from
ifstated.conf based on conditions. Or both, time and counters. So one
could change to a different state if one of the links is flapping
between states. I know this makes it not a pure machine state, but I
believe that the improvements can be worth the change. What you guys think?
Cheers,
--
Giancarlo Razzolini
GPG: 4096R/77B981BC
ifstated is a cool FSM emgine for handling the carp problems,
for more complex need , instead of hacking this not complete FSM engine,
i would just used another software.
The last time, i just use plain perl script, because it was convenient
and easy to read,
using a true FSM design was just making the logic more complex.
IMHO the way to improve ifstated is to fork it so it becomes a full FSM engine,
with transition and node definition, and each part using perl or ksh code.
node 1 {
entry : {perl code}
leaving: {ksh code}
eventX : node 2
}
The all work would be on the eventX , how to create one in a cron like
process, how to bind the superb kqueue, and
how to get notified from the network states change.
Now , if ifstated is not able to handle what it was design for (CARP)
i guess it should be fixed.
--
-
() ascii ribbon campaign - against html e-mail
/\
Re: ifstated(8) improvement
Em 09-06-2014 12:03, sven falempin escreveu:
ifstated is a cool FSM emgine for handling the carp problems,
for more complex need , instead of hacking this not complete FSM engine,
i would just used another software.
The last time, i just use plain perl script, because it was convenient
and easy to read,
using a true FSM design was just making the logic more complex.
IMHO the way to improve ifstated is to fork it so it becomes a full FSM
engine,
with transition and node definition, and each part using perl or ksh code.
node 1 {
entry : {perl code}
leaving: {ksh code}
eventX : node 2
}
The all work would be on the eventX , how to create one in a cron like
process, how to bind the superb kqueue, and
how to get notified from the network states change.
Now , if ifstated is not able to handle what it was design for (CARP)
i guess it should be fixed.
It definitively does what it was designed for. But I believe that these
improvements would also benefit carp only deployments. If a carp node is
failing more than N times in the last few minutes, it might be a good
idea to completely fail it over and enter on a different state. I use my
ifstated setup for both carp and isp link failure detection. I took a
look at ifstated code and I've been fiddling with it for a little time
now. I believe that the counter based approach is easy to implement with
less disruption. The time based one is more difficult. As I mentioned,
I've been using ifstated for years now (10+ IIRC). And more often than
not, isp links behave erratic. Carp can also have problems if the
network hardware underneath it does not behave correctly. I don't
believe that all of these situations can be solved even with a true FSM.
That's why I'm proposing these improvements. But, I wanted to discuss
with you guys here on tech@ first. Perhaps something entirely different
needs to be done.
Cheers,
--
Giancarlo Razzolini
GPG: 4096R/77B981BC
Re: ifstated(8) improvement
On Mon, Jun 9, 2014 at 11:17 AM, Giancarlo Razzolini
grazzol...@gmail.com wrote:
Em 09-06-2014 12:03, sven falempin escreveu:
ifstated is a cool FSM emgine for handling the carp problems,
for more complex need , instead of hacking this not complete FSM engine,
i would just used another software.
The last time, i just use plain perl script, because it was convenient
and easy to read,
using a true FSM design was just making the logic more complex.
IMHO the way to improve ifstated is to fork it so it becomes a full FSM
engine,
with transition and node definition, and each part using perl or ksh code.
node 1 {
entry : {perl code}
leaving: {ksh code}
eventX : node 2
}
The all work would be on the eventX , how to create one in a cron like
process, how to bind the superb kqueue, and
how to get notified from the network states change.
Now , if ifstated is not able to handle what it was design for (CARP)
i guess it should be fixed.
It definitively does what it was designed for. But I believe that these
improvements would also benefit carp only deployments. If a carp node is
failing more than N times in the last few minutes, it might be a good
idea to completely fail it over and enter on a different state. I use my
ifstated setup for both carp and isp link failure detection. I took a
look at ifstated code and I've been fiddling with it for a little time
now. I believe that the counter based approach is easy to implement with
less disruption. The time based one is more difficult. As I mentioned,
I've been using ifstated for years now (10+ IIRC). And more often than
not, isp links behave erratic. Carp can also have problems if the
network hardware underneath it does not behave correctly. I don't
believe that all of these situations can be solved even with a true FSM.
That's why I'm proposing these improvements. But, I wanted to discuss
with you guys here on tech@ first. Perhaps something entirely different
needs to be done.
Detecting bad network is problematic, i try to access external service for this,
dns and tcp, this can be done inside ifstated.
For the counter, you could use a file and modified it from ifstated,
and do a if grep 10 /my/file
echo my file reach 10| mail -s alert root; call real action; erase file,
but lets wait for people with more insight :-)
--
-
() ascii ribbon campaign - against html e-mail
/\
Re: ifstated(8) improvement
Em 09-06-2014 12:25, sven falempin escreveu: Detecting bad network is problematic, i try to access external service for this, dns and tcp, this can be done inside ifstated. Do this already, in the same and different ways. It all depends on what's available for network failure detection on the site. I always prefer snmp for this. But there are sites where it's not possible to do so. For the counter, you could use a file and modified it from ifstated, and do a if grep 10 /my/file echo my file reach 10| mail -s alert root; call real action; erase file, I use a database for this. Used files in the beginning but improved to a database. But I need to wait a state change and/or I need to have a run every statement that will make the decision. But, since It's only a boolean, I need to have several run every statements to be able to cover all cases. This makes the ifstated daemon a little slower, so the overall link failure detection takes more time. but lets wait for people with more insight :-) Yes. I'll probably hack it anyway. But if more people here on tech@ helps with suggestions/directions, I'll probably do a better job. Thanks in advance for your time. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
