Writing hooks for Perlbal

Raistlin Majere raistlin at e-raist.com
Wed Oct 11 18:12:50 UTC 2006


Elliot,
	Ideally, I'd like to first TRY To reproxy to the server, and if that  
fails then do execute whatever code is necessary (OS level scripts to  
bring up other servers, etc) and set the reproxy maps correctly, so  
that requests will be queued and sent to the new backend server.   
Essentially this means that when servers are up, traffic flows  
without the overhead of health monitoring, but when they are down, a  
user has to wait for the timeouts, and then the overhead of my OS  
level scripts to bring up new servers.

	I was looking through the doc/ directory and found the "admin  
commands".  Do you know where/how I can send commands to the perlbal  
daemon without rewriting the config file?  (i.e. I can send it  
additions, changes, deletions, through commands sent to the daemon  
instead of modifying the perlbal.conf file)

	Thanks again, for all your help.

-=Raistlin


On 11-Oct-06, at 9:10 AM, Elliot F wrote:

> Raistlin,
>
> I could swear that perlbal already has a health check in place, but  
> the other place you would do health checking would be during the  
> callback that you registered (that would fire every N seconds.)  Or  
> are you looking for something else?
>
> Elliot
>
> Raistlin Majere wrote:
>> Elliot,
>>         Well, I think I'm onto something.  I've been hacking on  
>> Service.pm and the code that spawns new servers.  Around line 1162  
>> I've added a subroutine which verifies that the server is  
>> available on the specified ip and port it receives from  $self-> 
>> {pool}->get_backend_endpoint.  If the server isn't there, then I  
>> execute a lot of code and return a new $ip and $port, and then let  
>> the subroutine continue.
>>     I'm a little concerned that this gets executed only when new  
>> backends are created, and that if an existing backend with a  
>> persistent connection goes down this code won't be executed.  I'd  
>> like to find a better place for it and write a 'hook' for it.   
>> Essentially a 'verify' server hook.  Any ideas or suggestions  
>> would be appreciated.
>> -=Raistlin
>> On 8-Oct-06, at 12:11 PM, Elliot F wrote:
>>> I would suggest taking a look at the code around the  
>>> backend_client_assigned hook.  If you haven't already, take a  
>>> look at the doc/hacking/hooks.txt file.
>>>
>>> I'm not sure, but your problem may quickly get much more  
>>> complex.  I would not be surprised if you have to make your own  
>>> hook somewhere, or modify perlbal.
>>>
>>> If the 'backend_client_assigned' hook isn't enough, I'm assuming  
>>> you would want to look at './lib/Perlbal/BackendHTTP.pm', and  
>>> specifically the 'assign_client' sub around line 159.  I'm not  
>>> saying this is the answer, but it would be where I would start  
>>> looking.
>>>
>>> Hope that helps,
>>>
>>> Elliot
>>>
>>> Raistlin Majere wrote:
>>>> Alright, I have the plugin/callback being called.  Looks like I  
>>>> just needed to add "plugins = MyPlugin" (where MyPlugin is the  
>>>> package in the Perlbal/Plugin directory).
>>>> The callback functionality looks useful for polling things and  
>>>> reacting accordingly, I've implemented this, however I am  
>>>> curious how to rewrite a request to a different backend server.
>>>> Ideally I'd like to be able to be able to:
>>>> Accept a request to a virtualhost
>>>> Verify that the backend server is up and running
>>>> if it's not then hold the request while I either:
>>>>     a) bring the backend server up
>>>>     b) rewrite the request to a different server
>>>> Any ideas how to redirect the request, POST data, etc to a  
>>>> different machine?
>>>>> Raistlin,
>>>>>
>>>>> Take a look at registering a callback that perlbal will trigger  
>>>>> every N seconds.  AtomStream.pm has it being used.  It's called  
>>>>> 'Perlbal::Socket::register_callback'.  You would be able to do  
>>>>> whatever check(s) you want, and react accordingly (mark it as  
>>>>> down somehow, reconfigure perlbal, etc.)  And it wouldn't be  
>>>>> doing it for every request.
>>>>>
>>>>> Just make sure you don't block.  :)
>>>>>
>>>>> Elliot
>>>>>
>>>>> Raistlin Majere wrote:
>>>>>> I've installed and configured perlbal and have run into some  
>>>>>> difficulties.  I've setup perlbal to be a reverse proxy so  
>>>>>> that it correctly proxies virtualhosts to the appropriate  
>>>>>> servers.  (i.e. vhost1.example.com, vhost2.example.com  
>>>>>> correctly reverse proxies for vhost1.com and vhost2.com  
>>>>>> respectively) This is working perfectly, and wasn't too  
>>>>>> difficult to configure.
>>>>>> However now I want to write some code that will:
>>>>>> First verify that the backend server is alive
>>>>>> Second that the backend server can answer requests on the port  
>>>>>> I'm trying to talk to
>>>>>> And if it's NOT alive and able to respond to requests that I  
>>>>>> can redirect requests to a different server, or execute some  
>>>>>> code to bring the downed server up, before retrying.
>>>>>> I've tried to use the Perlbal::ClientProxy  
>>>>>> "start_proxy_request" hook, however that seems to affect each  
>>>>>> and every request (i.e. each html page, graphic, etc.)
>>>>>> I need to be able to check to see if the backend server is  
>>>>>> alive, and if it's not, tell Perlbal: "Whoa hold your horeses"  
>>>>>> long enough for me to bring a server up (I can do this with  
>>>>>> some scripts I have), and then redirect the request to the new  
>>>>>> server.
>>>>>> Any help or advice would be greatly appreciated.



More information about the perlbal mailing list