Layer 7 switching. - Redhat

This is a discussion on Layer 7 switching. - Redhat ; Hey, Just wondering if anyone can recommend any 'production ready' layer 7 switching product on Linux. I am looking at IPVS w/KTCPVs for both L4/L7 switching, but the L7 stuff does not give me the warm fuzzies. Just wondering what ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Layer 7 switching.

  1. Layer 7 switching.

    Hey,

    Just wondering if anyone can recommend any 'production ready' layer 7
    switching product on Linux. I am looking at IPVS w/KTCPVs for both
    L4/L7 switching, but the L7 stuff does not give me the warm fuzzies.
    Just wondering what anyone else is using (other than Apache or squid).
    Would like stateful fail-over as well....

    JR.


    --

    Bill will have to take Linux from my cold, dead flippers.

    -Tux.

  2. Re: Layer 7 switching.

    On 31 Aug, 00:05, Johnny Rebel wrote:
    > Hey,
    >
    > Just wondering if anyone can recommend any 'production ready' layer 7
    > switching product on Linux. I am looking at IPVS w/KTCPVs for both
    > L4/L7 switching, but the L7 stuff does not give me the warm fuzzies.
    > Just wondering what anyone else is using (other than Apache or squid).


    You don't say what kind of traffic you're trying to switch. If it's
    HTTP, HTTPS or SMTP then that makes life a lot simpler, but it still
    kind of depends what you're trying to achieve. While a Cisco CSS
    provides a lot of additional functionality over squid, its stuff I
    don't need - so I've used squid where needed, but really I'd prefer to
    push the failover out to the browser just using round-robin (there's a
    lot of nonsense talked about round-robin DNS - it really is a v. good
    way of providing fault-tolerant, volume based balanced connectivity).
    Similarly for SMTP - just a backup MX.

    For long running sessions, e.g. thick client database access, X apps
    etc then LVS is probably the way to go.

    > Would like stateful fail-over as well....
    >
    > JR.



    Are we still talking about HTTP[S]? Do you mean at the request level
    or session level? If so, don't expect the former any time soon. The
    latter is pretty much the domain of the application and how it
    implements sessions (which are not an intrinsic part of the protocol).
    For J2EE you'd need to set up session replication, for PHP, just a
    common session storage layer.

    C.

  3. Re: Layer 7 switching.

    C. (http://symcbean.blogspot.com/) wrote:
    > On 31 Aug, 00:05, Johnny Rebel wrote:
    >> Hey,
    >>
    >> Just wondering if anyone can recommend any 'production ready' layer 7
    >> switching product on Linux. I am looking at IPVS w/KTCPVs for both
    >> L4/L7 switching, but the L7 stuff does not give me the warm fuzzies.
    >> Just wondering what anyone else is using (other than Apache or squid).

    >
    > You don't say what kind of traffic you're trying to switch. If it's
    > HTTP, HTTPS or SMTP then that makes life a lot simpler, but it still
    > kind of depends what you're trying to achieve. While a Cisco CSS
    > provides a lot of additional functionality over squid, its stuff I
    > don't need - so I've used squid where needed, but really I'd prefer to
    > push the failover out to the browser just using round-robin (there's a
    > lot of nonsense talked about round-robin DNS - it really is a v. good
    > way of providing fault-tolerant, volume based balanced connectivity).
    > Similarly for SMTP - just a backup MX.



    Yes - just http/https... it is an enterprise web infrastructure. We
    have Cisco's in our current setup, but they are expensive, propriatary
    (read: procurement issues) and IMHO, crap. Lots of whiz-bang acronyms,
    and flashy glossy.... but we are stuck with them for now. LVS seems to
    fit the bill, but the development doesn't quite seem to be behind it in
    releases. round-robin DNS is not what I am looking for - we can not
    afford any misses which that will give us. We tested that a long while
    back, and while it does have some advantages, it isn't what we need.
    (enclaved environment all the way).

    >
    > For long running sessions, e.g. thick client database access, X apps
    > etc then LVS is probably the way to go.


    Yeah, think Peoplesoft.... but this is just a front end to get to the
    website. Other applications such as this will be plugging into the
    front end architecture this posting was in reference to.

    >
    >> Would like stateful fail-over as well....
    >>
    >> JR.

    >
    >
    > Are we still talking about HTTP[S]? Do you mean at the request level
    > or session level? If so, don't expect the former any time soon. The
    > latter is pretty much the domain of the application and how it
    > implements sessions (which are not an intrinsic part of the protocol).
    > For J2EE you'd need to set up session replication, for PHP, just a
    > common session storage layer.


    Yes - front end is three load-balancers, then two SSL reverse proxies
    going to a set of 5 load-balancers. From here, down to multiple
    Peoplesoft type applications (web based) on a flat backbone. LVS from
    what I have been read does provide stateful failover for L3 switching.
    Making L7 have stateful failover shouldn't be that far a stretch. This
    is all above the application layer (not the OSI application layer) so
    shoudl be doable. I have heard that Weblogic has this already in their
    web servers...


    z

    >
    > C.



    --

    Bill will have to take Linux from my cold, dead flippers.

    -Tux.

  4. Re: Layer 7 switching.

    On 3 Sep, 00:46, Johnny Rebel wrote:
    > C. (http://symcbean.blogspot.com/) wrote:
    > > On 31 Aug, 00:05, Johnny Rebel wrote:
    > >> Hey,

    >
    > >> Just wondering if anyone can recommend any 'production ready' layer 7
    > >> switching product on Linux. I am looking at IPVS w/KTCPVs for both
    > >> L4/L7 switching, but the L7 stuff does not give me the warm fuzzies.
    > >> Just wondering what anyone else is using (other than Apache or squid).

    >
    > > You don't say what kind of traffic you're trying to switch. If it's
    > > HTTP, HTTPS or SMTP then that makes life a lot simpler, but it still
    > > kind of depends what you're trying to achieve. While a Cisco CSS
    > > provides a lot of additional functionality over squid, its stuff I
    > > don't need - so I've used squid where needed, but really I'd prefer to
    > > push the failover out to the browser just using round-robin (there's a
    > > lot of nonsense talked about round-robin DNS - it really is a v. good
    > > way of providing fault-tolerant, volume based balanced connectivity).
    > > Similarly for SMTP - just a backup MX.

    >
    > Yes - just http/https... it is an enterprise web infrastructure. We
    > have Cisco's in our current setup, but they are expensive, propriatary
    > (read: procurement issues) and IMHO, crap. Lots of whiz-bang acronyms,
    > and flashy glossy.... but we are stuck with them for now. LVS seems to
    > fit the bill, but the development doesn't quite seem to be behind it in
    > releases. round-robin DNS is not what I am looking for - we can not
    > afford any misses which that will give us. We tested that a long while
    > back, and while it does have some advantages, it isn't what we need.
    > (enclaved environment all the way).
    >


    I've never seen a discarded request in my round-robin testing -
    certainly, if a server goes down after the request has been sent from
    the client, round-robin is not going to help, but then I've never
    heard of a web architecture which can. What did you see that makes you
    think different?

    >
    > Yes - front end is three load-balancers, then two SSL reverse proxies
    > going to a set of 5 load-balancers. From here, down to multiple
    > Peoplesoft type applications (web based) on a flat backbone. LVS from
    > what I have been read does provide stateful failover for L3 switching.


    You've probably read more than me - but I'd recommend reading it again
    very carefully, particulary how quickly failover can be detected.

    > Making L7 have stateful failover shouldn't be that far a stretch. This
    > is all above the application layer (not the OSI application layer) so
    > shoudl be doable. I have heard that Weblogic has this already in their
    > web servers...
    >


    As far as I know this is just session data replication - so the
    session is resumable on a different node - but not the request.

    I'd be interested to hear about your round-robin testing / any
    progress on request resumption.

    C.

  5. Re: Layer 7 switching.

    C. (http://symcbean.blogspot.com/) wrote:
    > On 3 Sep, 00:46, Johnny Rebel wrote:
    >> C. (http://symcbean.blogspot.com/) wrote:
    >>> On 31 Aug, 00:05, Johnny Rebel wrote:
    >>>> Hey,
    >>>> Just wondering if anyone can recommend any 'production ready' layer 7
    >>>> switching product on Linux. I am looking at IPVS w/KTCPVs for both
    >>>> L4/L7 switching, but the L7 stuff does not give me the warm fuzzies.
    >>>> Just wondering what anyone else is using (other than Apache or squid).
    >>> You don't say what kind of traffic you're trying to switch. If it's
    >>> HTTP, HTTPS or SMTP then that makes life a lot simpler, but it still
    >>> kind of depends what you're trying to achieve. While a Cisco CSS
    >>> provides a lot of additional functionality over squid, its stuff I
    >>> don't need - so I've used squid where needed, but really I'd prefer to
    >>> push the failover out to the browser just using round-robin (there's a
    >>> lot of nonsense talked about round-robin DNS - it really is a v. good
    >>> way of providing fault-tolerant, volume based balanced connectivity).
    >>> Similarly for SMTP - just a backup MX.

    >> Yes - just http/https... it is an enterprise web infrastructure. We
    >> have Cisco's in our current setup, but they are expensive, propriatary
    >> (read: procurement issues) and IMHO, crap. Lots of whiz-bang acronyms,
    >> and flashy glossy.... but we are stuck with them for now. LVS seems to
    >> fit the bill, but the development doesn't quite seem to be behind it in
    >> releases. round-robin DNS is not what I am looking for - we can not
    >> afford any misses which that will give us. We tested that a long while
    >> back, and while it does have some advantages, it isn't what we need.
    >> (enclaved environment all the way).
    >>

    >
    > I've never seen a discarded request in my round-robin testing -
    > certainly, if a server goes down after the request has been sent from
    > the client, round-robin is not going to help, but then I've never
    > heard of a web architecture which can. What did you see that makes you
    > think different?


    Exactly - if a server goes down, round robin falls. I need a 24x7
    infrastructure. That level up to the SSL reverse proxies is A-OK. LVS
    will do stateful failover(L3)via the heartbeat VLAN - not really
    failover - every other node has every other session table. "failover"
    is instant since the client is hitting a virtual IP.

    >
    >> Yes - front end is three load-balancers, then two SSL reverse proxies
    >> going to a set of 5 load-balancers. From here, down to multiple
    >> Peoplesoft type applications (web based) on a flat backbone. LVS from
    >> what I have been read does provide stateful failover for L3 switching.

    >
    > You've probably read more than me - but I'd recommend reading it again
    > very carefully, particulary how quickly failover can be detected.


    Yep - it is instant from what I am reading, testing may prove otherwise
    (still waiting for my servers). The layer 7 stuff is where things get a
    little trickier.

    >
    >> Making L7 have stateful failover shouldn't be that far a stretch. This
    >> is all above the application layer (not the OSI application layer) so
    >> shoudl be doable. I have heard that Weblogic has this already in their
    >> web servers...
    >>

    >
    > As far as I know this is just session data replication - so the
    > session is resumable on a different node - but not the request.


    You are correct - the session is resumable - so is the request since the
    web server doesn't actually do it do the DB - the application (BEA
    Tuxedo does that, and does it well) server does that. If an app server
    goes down - the request is toast.

    >
    > I'd be interested to hear about your round-robin testing / any
    > progress on request resumption.


    We are not even considering round robin for this infrastructure since it
    doesn't meet our requirements. We will only have one virtual IP to
    access just about every web application in the enclaved environment.
    Round robin would assume multiple front end servers/IP's. While we will
    have a large infrastructure (120k users approx) throughput is not our
    largest concern (each node /should/ do about 700mbps balanced)
    availability is. Front infrastructure must always be available
    including during maintenance on individual nodes, system down etc...

    JR.


    >
    > C.



    --

    Bill will have to take Linux from my cold, dead flippers.

    -Tux.

+ Reply to Thread