|
--- Roberto Nibali <ratz@xxxxxxxxxxxx> wrote:
> Hi,
>
> > I checked the mailing list and did not find
> something
> > such as roadmap or function list of next release.
> So I
> > wish I could add some of my ideas if one day we
> will
> > have the roadmap.
>
> Like Joe mentioned: it's rather unlikely that this
> will happen. I took 3
> years to update the TODO list ;).
>
> > 1. user defined scheduler: user can write their
> own
> > scheduler to guide the load dispatching
>
> Check out feedbackd and see if you miss something
> there. I know that
> this is not what you wanted to hear but to provide a
> generic API for
> user space deamons to interact directly with a
> generic scheduler is
> definitely out of scope. One problem is that the
> process of balancing
> incoming network load is not an atomic operation. It
> can take minutes,
> hours, days, weeks until you get an equalised load
> on your servers.
> Having a user space doing premature scheduler
> updates in a short time
> interval only asks for trouble regarding peak load
> bouncing.
You are right, a new algorism needs time to test and
verify. Sometimes I just need more control over the
dispatching, such as I need to use my hashing algorism
to control which client goes to where.
>
> > 2. session persistent extend: I noticed that 3
> methods
> > to extend a session in the mail
> >
>
http://marc.theaimsgroup.com/?l=linux-virtual-server&m=104467069124909&w=2
> > And I prefer the first one to extend it again
> with
> > the persistent time. So maybe all these
> implemented
> > and have control variable to choose one.
>
> I'd have to agree with you here.
>
> > 3. DOS attack: add functions such as BIG-IP syn
> check.
> > http://www.f5.com/solutions/tech/security/
>
> For the RS or the director or both?
>
> I think you are referring to those two marketing
> features:
>
> SYN Check? - One type of DoS attack is known as a
> SYN flood in which an
> attack is made for the purpose of exhausting a
> system?s resources
> leaving it unable to establish legitimate
> connections. The BIG-IP
> system's SYN Check feature works to alleviate SYN
> flooding by sending
> cookies to the requesting client on the server's
> behalf and by not
> recording state information for connections that
> have not completed the
> initial TCP handshake. This unique feature ensures
> that servers only
> process legitmate connections and the BIG-IP SYN
> queue is not exhausted,
> and normal TCP communication can continue. The SYN
> Check feature
> complements the BIG-IP Dynamic Reaping feature, in
> that while the
> Dynamic Reaping handles established connection
> flooding, SYN Check
> addresses embryonic connection flooding to prevent
> the SYN queue from
> becoming exhausted.
>
> Dynamic Reaping - The BIG-IP software contains two
> global settings that
> provide the ability to reap connections adaptively.
> Used to prevent
> denial-of-service (DOS) attacks, enterprises can
> specify a low-watermark
> threshold and a high-watermark threshold. The
> low-watermark threshold
> determines at what point adaptive reaping becomes
> more aggressive. The
> high-watermark threshold determines when
> non-established connections
> through the BIG-IP product will no longer be
> allowed. The value of this
> variable represents a percentage of memory
> utilization. Once memory
> utilization has reached this mark, connections are
> disallowed until the
> available memory has been reduced to the
> low-watermark threshold.
>
> 1. SYN Check can be enabled on the RS for all major
> Unices. For the rest
> we have to give in the fact that LVS is a
> software load balancer and
> does not have the possibilites a hardware load
> balancer has with
> regard to doing SYN cookies for other servers.
> Also limiting the
> backlog queue on a per socket basis definitely
> helps.
>
> 2. Dynamic Reaping could very well be brought into
> conjuction with our
> TCP DoS defense mechanism. Read about it at:
>
> http://www.linux-vs.org/docs/defense.html
>
> I have tested F5 BigIP load balancers and I was able
> to flood the RS
> just as well as using LVS. SYN flooding cannot be
> prevented, it can only
> be rate limited. It's a flaw in the TCP protocol
> which we'll have to
> live with. There are a couple of defense mechanisms
> but non of them can
> really distinguish between malicious TCP/SYN and
> friendly TCP/SYN.
>
Well, maybe you are right, they are just marketing
feature. I first though the syn check of BIGIP will
take less overhead then just pass it to real servers.
Thus, the whole cluster may survive longer. I totally
agree with you that syn flood is a defect of the TCPIP
protocol and there's no way to prevent it. I just want
the lvs can stand a little bit longer if we can
features such as syn check. Besides, the secure_tcp
defense strategy you mentioned in the defense page is
partialy disabled, because in the new kernel, the
timeout variables are not exists anymore. And I think
secure_tcp is less useful than syn check(if it is not
marketing feature), because it only pass the burden to
real servers, and real server will spend much more
overhead if it is dealed in lvs.
Yunfeng Hou
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
|
