TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Come on Amazon, give ELB some love

50 点作者 dhendo将近 12 年前

7 条评论

hoov将近 12 年前
I agree that ELBs need much more functionality.<p>In order to get around the lack of features, I only use the ELBs for SSL termination (well, and DNS, and autoscaling). For anything fancier, I&#x27;ve developed a coprocess that manages HAProxy behind the scenes. It leverages Auto Scaling notifications to keep the backend instances in sync. It has a REST API so that you can drive configuration, and it works in a master-master configuration.<p>It&#x27;s been running in production for about 9 months now, and has proven invaluable. Having hooks at this layer is incredible. I&#x27;m able to get amazing debugging information, I can &quot;bumper&quot; the site at the frontend, I can do 100% zero downtime deployments with quick rollback, I can tarpit and rate limit, etc.<p>Once I added enough &quot;sugar&quot;, I started to realize that maybe AWS is doing it right -- it&#x27;d be impossible to add all the features that every customer would want to the ELB. However, WebSocket support and request draining are low-hanging fruit. Same goes for the support for generic HTTP methods, which was implemented some time ago.
de_dave将近 12 年前
ELB already does weighting, directing requests depending instance type and instance load. Can&#x27;t find where in the docs this is clarified unfortunately. Have witnessed this with my own eyes though!<p>Draining is a huge issue for us. Investigating ways to add a secondary layer of balancing behind ELB to help mitigate it, which is completely silly. We shouldn&#x27;t need to do this. ELB should have supported gracefully terminating connections from Day 1, IMO. Last I heard it was being &#x27;considered&#x27;.
评论 #5995147 未加载
felixge将近 12 年前
I&#x27;d also love to see support for draining - and it seems like we might be in luck in the near future:<p><a href="https://forums.aws.amazon.com/thread.jspa?threadID=61278&amp;start=75&amp;tstart=0" rel="nofollow">https:&#x2F;&#x2F;forums.aws.amazon.com&#x2F;thread.jspa?threadID=61278&amp;sta...</a><p>^-- BenF@AWS commented on June 10th saying that amazon is now actively working on it!
评论 #5996283 未加载
verelo将近 12 年前
I would love to be able to not just attached EC2 instances to ELB&#x27;s, but also RDS instances.
评论 #5995582 未加载
progolferyo将近 12 年前
How about more control over the software &amp; configuration side of ELB as well? If you could control more things that nginx or haproxy let you control, I think there would be a lot less need for another routing mechanism behind ELB.<p>In addition to weighting, we need an nginx layer for different app pools, custom routing options, max connections limits, request queueing, url rewriting, static content serving for specific requests. The list goes on but these things could easily be brought up into the ELB layer.
forthewyn将近 12 年前
I also wish ELB would get security groups like EC2 and RDS already have.<p>I think a LOT of people revert to HAPRoxy on an EC2 instance because of this.
madaxe将近 12 年前
They have been - and they successfully nerfed half a dozen of ours (public facing) when they did the migration about three weeks back. Most recent upgrade added the ability for R53 to do latency based and healthcheck based DNS (with ELBs, that is), which is pretty shiny. As others have noted, it already auto-weights.