[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Socket activation

On Sep 4, 2013, at 2:34 PM, David Strauss <david davidstrauss net> wrote:

> My other responses are in-line, but I wanted to offer yet another
> option: out-of-band container activation. We currently use this for
> MariaDB, but they way I'll suggest here is slightly different and more
> general-purpose than the Drupal integration we use.
> It's pretty safe to assume that for the main application comes online,
> its dependent resources need to come online. Socket activation handles
> this lazily, which is nice, but it's probably a minimal optimization
> over another option: activating all containers publishing to the
> application when the initial HTTP request comes in.

>From a paas provider perspective there is more advantage to the provider for individual activation because it allows for different classes of container code to be idled at different rates.  For instance a tool like phpmyadmin or Jenkins, running in a container, would ideally be idled at an extremely aggressive rate, whereas the whole unit   may still be taking web requests.

OpenShift's current idling mechanism at the http level only works cleanly as long as the primary application front is also http - as more categories of application become relevant, listening to external ports beyond 80/443 we have to adopt a more generic tcp queueing/unifying mechanism anyway, and so socket activation is ideal in concept.

> It wouldn't require any socket magic, nor would it only support HTTP.
> It's just that the entry point would have to be HTTP.
> This approach has a major downside, though. If someone wants to
> directly connect to MariaDB, they'd either have to invoke the
> out-of-band mechanism first or send an HTTP request to their
> application to activate dependencies. We've seen a bit of user
> confusion over this, despite our best attempts at documentation.
> It might be possible to turn the out-of-band activation into a plus,
> though. We're looking to move to a security approach where direct
> MariaDB access requires making an API or dashboard request to unlock
> the access, which would be a prime time to activate the necessary
> container(s), too.
> On Wed, Sep 4, 2013 at 11:18 AM, Krishna Raman <kraman gmail com> wrote:
>> It would only be the first SYN that would be ignored and would be picked up upon the next retry once the container is started.
>> If the container takes longer to start than the SYN timeout, then even the socat approach would result in timeout at your router level.
>> Would the router's failure-detection trip based on a single SYN failure?
> It would only be a single SYN failure for each container. If lots of
> containers get activated on a box, say, after a reboot, there's be a
> spike in failed SYN receipts.
>>> Have you looked into environment-based socket passing with a shim like
>>> socat? socat already supports specifying a socket using a file
>>> descriptor, and it can forward to and from sockets in the container's
>>> network namespace. It seems like it would be equivalent in
>>> functionality and compatibility with SYN timeout and iptables but
>>> without breaking the TCP spec or requiring global firewall changes at
>>> container start-up time.
>> A socat based approach has a few issues:
>> 1) I am trying to avoid having to route packets through a user level program. Would rather keep it in kernel space and use IPTables.
>> 2) Even tough it is small, socat and other programs will add overhead to each gear
>> 2) Based on some tested a we did a while ago socat becomes unresponsive is there is heavy load. Rob can elaborate on this.
> I haven't load-tested socat for anything, and I completely understand
> the other reasons here.
> -- 
> David Strauss
>   | david davidstrauss net
>   | +1 512 577 5827 [mobile]
> _______________________________________________
> dev mailing list
> dev lists openshift redhat com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]