Is it possible to store (HTTP) requests from cliens for some period

is it HTTP::retry?

HTTP::retry

Since you're using an inband (passive) monitor, I'm assuming you're looking for a TCP layer failure (vs some HTTP response code). Take a look at the wiki link for the LB::reselect command:

https://devcentral.f5.com/wiki/iRules.LB__reselect.ashx

when CLIENT_ACCEPTED {
    set def_pool [LB::server pool]
    set lb_fails 0
}
when LB_FAILED {
    log local0. "lb failed"
    if { $lb_fails < [active_members $def_pool] } {
        LB::mode rr
        LB::reselect pool $def_pool
    } 
    incr lb_fails
}

The LB::reselect command, when invoked inside the LB_FAILED event, will reselect a pool member and retry the client's request.

Thank you for quick response! This is really a very helpful! I'll configure it and will be ready to test it .......thank you very much.

Is it possible to use 2 iRules for 1 Virtual server: 1 - for passive monitoring; 2 - for HTTP::retry functionality? or better to implement it in single rule?

i understand passive monitor and HTTP::retry do similar thing i.e. take an action based on response content.

sol7440: Overview of passive health monitoring

inband monitor is one type of health check. it has no error handling but LB::reselect or reselect tries can be used to provide appropriate action as Kevin suggested.

Inband

Improving the default behavior using the Inband monitor feature (10.x or later)

Beginning in BIG-IP 10.x, the Inband monitor type was introduced. The Inband monitor determines the availability of a pool member based on a specified number of failed connection attempts or data request attempts within a specified time interval. This monitor works in parallel with regular monitors, and can be used instead of the LB::down iRule command.

Note: For more information about the Inband monitor, refer to the Configuration Guide for BIG-IP Local Traffic Management.

The Inband monitor provides no error handling for in-progress connections. Therefore, it does not replace the LB::reselect functionality. However, beginning in BIG-IP version 10.x it is possible to cause a reselection by using the Reselect Tries advanced pool feature. This feature is equivalent to the LB::reselect iRule command. Once a connection attempt to a pool member is considered failed (equivalent to the LB_FAILED iRule event), the BIG-IP system selects a new pool member. Should that pool member also fail, the system repeats the reselection until it reaches the limit configured for this option. Only at this point is the client connection reset.

Note:  Do not confuse this feature with the Reselect option under the Action on Service Down advanced pool feature, which manages established client connections by moving them to an alternative pool member when monitors mark the original pool member down.

As a result, in BIG-IP 10.x and later, you can avoid many failure situations without the need for an iRule since the combination of Inband monitors and the Reselect Tries feature can be used instead of the LB::down iRule command and the LB::reselect iRule command. iRules continue to offer greater flexibility and you can still use them in combination with these features where a particular behavior is required.

sol10640: Pool member reselection options

Is it possible to use 2 iRules for 1 Virtual server: 1 - for passive monitoring; 2 - for HTTP::retry functionality? or better to implement it in single rule?

you can create one irule or multiple ones and stacking them. :)

Stacking iRules: A Modular Approach by Deb Allen