Forum Discussion
What will happen if no members in a high speed logging pool are available ?
I have an irule that sends tcp event data, client_accepted, client_closed, server_connected and server_closed to splunk using hsl high speed logging. My question is what will happen to ongoing connections and new connection requests if all of the members of the high speed logging pool are down? So to clarify, the application is still running fine and all pool members for the application are up, it is just that the splunk servers that the logging data is being sent to are down. Will it just discard sending the logging data ? Will it queue up somewhere and when memory or disk is filled up will things break ? Does it matter whether I use UDP or TCP when sending the logging data ? I have taken the members of the hsl pool down for testing and when I use TCP as the protocol when I open the HSL pool, it seems to queue the log data somewhere and when I bring the hsl pool members back up it then sends a big batch of log data. Here are the lines of code from my irule for the logging piece.
set hsl_pool hsl-splunk-f5-pool
set hsl [HSL::open -proto TCP -pool $hsl_pool]
HSL::send $hsl "${current_date}T${timestamp}$current_date_offset event=CLIENT_ACCEPTED protocol=TCP client_ip=$client client_port=$client_port vip_ip=$vip vip_port=$vip_local_port vip_name=$vip_name \n "
- Hamish
Cirrocumulus
Yes. There are differences between UDP and TCP.
With UDP logging it's fire & forget. Send a message == send a UDP packet. The messages arrive out of order and aren't guaranteed to arrive.
TCP logging on the other hand uses a stream. Messages WITHIN a TCP dream arrive in order. but when you have >1 tcp stream (Which you do as soon as HSL doesn't have a free connection) HSL will open a new tcp connection. Then messages arrive out of order ACROSS the connections.
Neither is always useful under stress.
I ran into issues many years ago with HSL. It's been a while since I destructively tested HSL, but the way it worked with TCP, is that IF there is an open and idle connection to a pool member, it'll be used. if not, a new one will be opened. There was pretty much no control over what happened. I even got to the point where we ran out of ports during stress testing...
As I was more interested in numbers (i.e. numbers of connections & messages I ended up doing the counting in an iRule and then sending the contents of the stats table from the BigIP to the backend servers on a timer. YMMV.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com