Backup Hub
Backup Hub
Hi everyone. I was asking about this in the #unreal-support channel last night, and they directed me to the forums, so here is my question.
I run a network with 8 leaves and 2 hubs (total of 10 servers). The USA servers are linked to the USA hub, and the Europe servers are linked to a Europe hub in the UK.
Sometimes unexpected problems occur at odd times of the day. Either when I'm sleeping here in the USA, or when the European opers/admins are at work or not around, or vice versa. A few days ago, the UK hub (which holds 5/8 leaves) went completely down. A CPU overload or something. I wasn't around, and neither was the UK admin. The network was split for several hours until one of us made it back.
I'm trying to have the Europe servers autoconnect to the UK hub. If it goes down, I'd like it to try once or twice to reconnect to it (in case it was just a small hiccup that caused a lost link), and then if it's still not up, connect to the USA hub. Same would go with the USA leaves connecting to the UK hub if the US one went down.
I realize I may be asking too much, or this feature may not be in Unreal. So if there is a feature just to automatically connect to the backup if one goes down (without trying one or two times on the down one first), that would be a major improvement over what it is now.
Thanks in advance for any help.
-Mark
I run a network with 8 leaves and 2 hubs (total of 10 servers). The USA servers are linked to the USA hub, and the Europe servers are linked to a Europe hub in the UK.
Sometimes unexpected problems occur at odd times of the day. Either when I'm sleeping here in the USA, or when the European opers/admins are at work or not around, or vice versa. A few days ago, the UK hub (which holds 5/8 leaves) went completely down. A CPU overload or something. I wasn't around, and neither was the UK admin. The network was split for several hours until one of us made it back.
I'm trying to have the Europe servers autoconnect to the UK hub. If it goes down, I'd like it to try once or twice to reconnect to it (in case it was just a small hiccup that caused a lost link), and then if it's still not up, connect to the USA hub. Same would go with the USA leaves connecting to the UK hub if the US one went down.
I realize I may be asking too much, or this feature may not be in Unreal. So if there is a feature just to automatically connect to the backup if one goes down (without trying one or two times on the down one first), that would be a major improvement over what it is now.
Thanks in advance for any help.
-Mark
-
- Posts: 44
- Joined: Mon Jan 24, 2005 6:10 pm
If I read that right, you're asking for a "autoconnect to this server, if it fails autoconnect to a different server" feature?
Unreal doesn't have something like this (and I don't know how you would be able to do it, but that's another story), so I would recommend continuing this over at the bugtracker (bugs.unrealircd.org).
Unreal doesn't have something like this (and I don't know how you would be able to do it, but that's another story), so I would recommend continuing this over at the bugtracker (bugs.unrealircd.org).
I'm not even sure I'm right about this part.
But I think if servers are connected to each other like a chain.
For an example:
USA servers are connected in this order -> 1, 2, 3, 4, 5.
And EU servers connected the same way.
If server 2 crashes then I think server 3 to 5 will have a split.
I think it would work better if, (Still an example):
Server 3, is conneced to server 1. And server 4, and 5 to server 2. Or something simular.
What I mean is, all server behind the crashing one will have a large netsplit.
But if you build it up as an spider web then it could be more stable. Then probably if:
Server 4 crashes then server 5 wont die becouse it's conneced directly to server 1.
Correct me if I'm wrong. I bet no one actually understood what I ment. hehe.
But I think if servers are connected to each other like a chain.
For an example:
USA servers are connected in this order -> 1, 2, 3, 4, 5.
And EU servers connected the same way.
If server 2 crashes then I think server 3 to 5 will have a split.
I think it would work better if, (Still an example):
Server 3, is conneced to server 1. And server 4, and 5 to server 2. Or something simular.
What I mean is, all server behind the crashing one will have a large netsplit.
But if you build it up as an spider web then it could be more stable. Then probably if:
Server 4 crashes then server 5 wont die becouse it's conneced directly to server 1.
Correct me if I'm wrong. I bet no one actually understood what I ment. hehe.
BOOM!
Hi guys, and thanks for the responses.
1) My servers aren't in a "chain". I'm not very good at text art, but here is sort of an example:
New York -> US Hub
Chicago -> US Hub
Tampa -> US Hub
Australia -> US Hub
London Leaf -> UK Hub
Netherlands -> UK Hub
Germany -> UK Hub
Norway -> UK Hub
They don't connect through each other, they all connect directly up to their hub.
I am trying to make it so if say, the UK hub went down, the London leaf, Netherlands, Germany, and Norway would connect up the USA hub. It wouldn't be as fast, but at least it wouldn't be down.
kucha: I looked at "denylink" block in docs, but I'm not sure exactly how to implement it (there isnt an example for that particular block). But if you could explain how, it may just do it.
Ron2K: That's exactly what I'm looking for. You said to go to the bugtracker. Are you sure that's a good place to post feature requests, or how would I file it?
Thanks again for all your replies so far.
-Mark
1) My servers aren't in a "chain". I'm not very good at text art, but here is sort of an example:
New York -> US Hub
Chicago -> US Hub
Tampa -> US Hub
Australia -> US Hub
London Leaf -> UK Hub
Netherlands -> UK Hub
Germany -> UK Hub
Norway -> UK Hub
They don't connect through each other, they all connect directly up to their hub.
I am trying to make it so if say, the UK hub went down, the London leaf, Netherlands, Germany, and Norway would connect up the USA hub. It wouldn't be as fast, but at least it wouldn't be down.
kucha: I looked at "denylink" block in docs, but I'm not sure exactly how to implement it (there isnt an example for that particular block). But if you could explain how, it may just do it.
Ron2K: That's exactly what I'm looking for. You said to go to the bugtracker. Are you sure that's a good place to post feature requests, or how would I file it?
Thanks again for all your replies so far.
-Mark
Trust me, all UnrealIRCd feature requests are handled theremixx941 wrote:Ron2K: That's exactly what I'm looking for. You said to go to the bugtracker. Are you sure that's a good place to post feature requests, or how would I file it?
No. That just outright stops a server from linking at all.kucha wrote:hm.. tell me if I'm wrong but isn't it possible to do something similar with denylink block?
Actually, looking at the docs, it seems like you can have a deny link block deny only autoconnects while still allowing /connects - however, in this context, that won't help at all, as mixx941 is trying to autoconnect to one server; if it fails autoconnect to the next.
Well, I opened up a bug report, and it got closed!
Says it's a duplicate of: http://bugs.unrealircd.org/view.php?id=0001836
Which looks pretty much what I need. It says "acknowledged" for the status. I hope it gets taken into consideration
-Mark
Says it's a duplicate of: http://bugs.unrealircd.org/view.php?id=0001836
Which looks pretty much what I need. It says "acknowledged" for the status. I hope it gets taken into consideration
-Mark
While I don't dislike it, I must admit that it's not high on my TODO atm, so it probably will not be in 3.2.3.
Also, there's of course a(n imperfect) workaround.. just 2 server classes.. 1 with fast connfreq (eg: 60), 1 with slow connfreq (eg: 900).. and then put your prefered server in the fast one, and your backup @ slow one. And of course your server blocks w/autoconnect.
This doesn't guarantee that the first one will be tried like 14 times before the 2nd one (due to "bad timing" the secondary might even be tried first :P), but it does give the primary one a lot more chance :).
You could even make the slow one as high as 1800 or more, as it's just as a means to prevent your "my net got broken for X hours when I was asleep"-problem.
Other alternatives include installing an alarm in your bedroom that goes off (or your computer), but this is usually not good for your night's rest ;)
A pager / sms... ehh.. ah well ;)
Also, there's of course a(n imperfect) workaround.. just 2 server classes.. 1 with fast connfreq (eg: 60), 1 with slow connfreq (eg: 900).. and then put your prefered server in the fast one, and your backup @ slow one. And of course your server blocks w/autoconnect.
This doesn't guarantee that the first one will be tried like 14 times before the 2nd one (due to "bad timing" the secondary might even be tried first :P), but it does give the primary one a lot more chance :).
You could even make the slow one as high as 1800 or more, as it's just as a means to prevent your "my net got broken for X hours when I was asleep"-problem.
Other alternatives include installing an alarm in your bedroom that goes off (or your computer), but this is usually not good for your night's rest ;)
A pager / sms... ehh.. ah well ;)
Don't forget deny link{}! Though, it doesn't help you when two autoconnects trigger simultaneously (usually why you put your connfreqs such that one isn't a multiple of the other, like 90 and 91, then it'll probably be a billion years before they coincide, or at least a day or two). Though, would it hurt to have a connecting() operator for crules?Syzop wrote:Also, there's of course a(n imperfect) workaround.. just 2 server classes.. 1 with fast connfreq (eg: 60), 1 with slow connfreq (eg: 900).. and then put your prefered server in the fast one, and your backup @ slow one. And of course your server blocks w/autoconnect.
This doesn't guarantee that the first one will be tried like 14 times before the 2nd one (due to "bad timing" the secondary might even be tried first ), but it does give the primary one a lot more chance .
You could even make the slow one as high as 1800 or more, as it's just as a means to prevent your "my net got broken for X hours when I was asleep"-problem.
*edit* basically something like this:
Code: Select all
deny link {
mask *;
rule "connecting(*)";
type auto;
};
*/edit*
I still wonder, what kind of affect does class::maxclients have on servers and autoconnect? Most ircds use it as the concurrent autoconnects limit (eg maxclients = 1 means only autoconnect 1 server at a time, but you could still have X00 servers in that class linked), but...
Er, I think it would take a properly scripted client to deal with that though... .Syzop wrote:Other alternatives include installing an alarm in your bedroom that goes off (or your computer), but this is usually not good for your night's rest
A pager / sms... ehh.. ah well
Thanks for the reply. By that reply, I'm assuming that you are considering possibly doing it in the future? Would it be a very hard thing to implement? To me, it seems like a real useful feature .Syzop wrote:While I don't dislike it, I must admit that it's not high on my TODO atm, so it probably will not be in 3.2.3.
The only problem that I have with your suggestion about the longer connect frequencies is that it would take that time for it to regain, and if it was pretty high, then it could be quite a long time. Better than all night or all day at work, yes, but still not optimal.
That's a great idea. I am having a pager/email mobile phone set up so in case it's MY hub on the network that went down, that my opers can page me and I can come and take care of it. I know some software that can do that for whole servers going down, but I'm not sure of anything for just netplits. Eh, I suppose I could just have it monitor the IRCD ports or the whole hub server itself .Syzop wrote:Other alternatives include installing an alarm in your bedroom that goes off (or your computer), but this is usually not good for your night's rest
A pager / sms... ehh.. ah well
Thanks again for the suggestions, and I hope to see this in future versions (if it's not terribly hard to implement).
Also, special thanks for developing open source and free software. I love the open source community. Knowing that people donate their time to a great cause is a very nice and refreshing break to the corporate world of Microsoft and other poorly coded software. Thanks again.
-Mark
Another part of this that would be useful is that...
When connected to the backup hub, STOP trying to automatically connect to the main primary one. If it keeps trying to autoconnect, the main one could come up, and with 3-4 leaves trying to autoconnect, one would hit the hub first, and then all the others would be denied (server already exists), and then all traffic to the hub would be going through that leaf.
Example:
Leaf1 -> Connected to Backup Hub
Leaf1 -> Autoconnect to down hub
Leaf2 -> Autoconnect to down hub
Down Hub -> Back Up
Leaf2 -> Autoconnected Successfully to hub back up
Leaf1 -> Autoconnect to hub denied
All traffic from the backup hub to the hub that was down and is now back up would be going through Leaf2, which may not always be the best thing.
Sorry if that's confusing.
-Mark
When connected to the backup hub, STOP trying to automatically connect to the main primary one. If it keeps trying to autoconnect, the main one could come up, and with 3-4 leaves trying to autoconnect, one would hit the hub first, and then all the others would be denied (server already exists), and then all traffic to the hub would be going through that leaf.
Example:
Leaf1 -> Connected to Backup Hub
Leaf1 -> Autoconnect to down hub
Leaf2 -> Autoconnect to down hub
Down Hub -> Back Up
Leaf2 -> Autoconnected Successfully to hub back up
Leaf1 -> Autoconnect to hub denied
All traffic from the backup hub to the hub that was down and is now back up would be going through Leaf2, which may not always be the best thing.
Sorry if that's confusing.
-Mark