What would be required for the NLB host to do port-rewriting to make things stable? Is the NLB host not present on the return-path? If that is not the issue, is this a performance issue? Could random allocation of ports work instead?
AWS NLBs and the mixed up TCP connections
11–20 of 67 posts
Re: AWS NLBs and the mixed up TCP connections
#12Re: AWS NLBs and the mixed up TCP connections
#13Re: AWS NLBs and the mixed up TCP connections
#14Earlier quoted context omitted.
Agree. From 6+ years of experience it seems that we got fouled by the multi-az promise of being able to survive datacenter outage. You can survive datacenter (AZ) outage IF you have separate stacks per AZ and don't mix traffic. If you have Kafka cluster spread out in 3 AZ don't get surprised if you just LOWERED your availability because any issue in one AZ makes your stack unstable. And issues in single AZ are quite…
That's a really interesting point. The startup I currently work for only uses a single AZ due to financial concerns (and some performance as well), but I assume we'll have to move to more AZs for reliability. Would you advise the same for clusters of RDS and Elasticache? I'm wondering how you would even go about having two separate data sources, how would this be manageable?
Re: AWS NLBs and the mixed up TCP connections
#15Re: AWS NLBs and the mixed up TCP connections
#16Re: AWS NLBs and the mixed up TCP connections
#17What would be required for the NLB host to do port-rewriting to make things stable? Is the NLB host not present on the return-path? If that is not the issue, is this a performance issue? Could random allocation of ports work instead?
Sometimes it's tempting to think AWS' services are just like traditional appliances you'd stick in the middle of a network path but in reality they're all virtual and run on top of their software defined network in something they call hyperplane.
That means traditional intuition about how packets flow, like needing to be in the path to preserve the IP, may not apply.
It seems like in this case they need to preserve the static public IP that was used on the NLB for the incoming request across the whole transaction but maybe aren't doing that.
Re: AWS NLBs and the mixed up TCP connections
#18Re: AWS NLBs and the mixed up TCP connections
#19It annoys me to no end when people don't explain their abbreviations... "AZ" means Availability Zone, which is to say: Data Center. So cross-AZ means going to multiple data centers.
Re: AWS NLBs and the mixed up TCP connections
#20It annoys me to no end when people don't explain their abbreviations... "AZ" means Availability Zone, which is to say: Data Center. So cross-AZ means going to multiple data centers.
AZ is a well-known abbreviation in AWS. For all intents and purposes, it can mean a data center, but I've heard that AZs can span multiple physical data centers (which sort of makes sense -- there's a physical limit to how many servers you can fit in to one physical data center)