I have created one EC2 instance (as part of the provision of a Tomcat Beanstalk instance). Now I need to configure HTTPS connection to the EC2 instance. As per the Beanstalk documentation, the easiest way is to configure a load balancer that interacts with browsers using HTTPS and that routes traffic to the EC2 instance using HTTP.
So I configured a load balancer under the EC2 management console. After the configuration, I tried to ping the public DNS name of the load balancer or the resolved IP address. The target is reachable but does not produce any response, as shown below:
ping 13.54.72.179
PING 13.54.72.179 (13.54.72.179) 56(84) bytes of data.
^C
13.54.72.179 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6139ms
I carefully checked all the configurations, as per the load balancer configuration and trouble-shooting documentation. All seem to have been configured properly.
Target group: the target group has the healthy state in monitoring tab.
VPC: the load balancer availability zone and the EC2 instance are in
the same VPC zone. Also in the route table, there is an internet
gateway associated to 0.0.0.0/0 destination.
load balancer listeners: both HTTP and HTTPS listeners are
configured. Load balancer is also configured for internet-facing
connection.
Security group for load balancer: for inbound traffic, both
HTTP/HTTPS and TCP protocol are configured, accepting all sources;
for outbound traffic: all protocols to all destinations are allowed.
Security group for EC2: for the purpose of testing, we enable all
traffic for all sources in inbound traffic.
I researched a few forum threads about the "load balancer not responding" topic and checked the configurations they mentioned. However, none of them worked for me.
So I am at loss now. Can someone enlighten me where I might have missed in configuring the load balancer? Or what I need to do for trouble-shooting?
Related
As I understand, the max number of TCP connections to a server from a single client IP Address is ~64k connections.
However, what I am not clear about is max number of connections that a server can handle, behind a single load balancer considering that the connections terminate on the Load balancer. Is it ~64k only because there is only one IP from which the server can receive requests?
Indeed, upstream server can handle only 64k connections from the same client due to limitation of ephemeral port range at client side.
But you can assign several IP addresses to the same private interface of your load balancer and force server to use them in a round-robin fashion.
You can define several networks on the same interface of load balancer, for example:
192.168.1.1,
192.168.2.1,
192.168.3.1
And define corresponding extra IP addresses at upstream server:
192.168.1.2,
192.168.2.2,
192.168.3.2 .
With following upstream configuration load balancer will pass requests to the same upstream server while using different IP addresses:
upstream ipproxy {
server 192.168.1.2:some-port;
server 192.168.2.2:some-port;
server 192.168.3.2:some-port;
}
Load balancer will be forced to use different IP addresses thus allowing you to bypass 64k connection limitation and achieve 192k connections.
For networking I'm using new Standard SKU (Load balancer, Public IP addresses, etc.). By default everything is disabled for Public IP Address Standard SKU.
I added the following and got TCP outbound connectivity:
1. NSG - enabled all outbound traffic
2. Load balancer rule - rule for Tcp & disabled SNAT
3. Outbound rule - for Tcp
Now when I remote to VMSS VM instance, I can open "google.com". But "ping google.com" keeps timing out.
I wonder what I should configure to enable ping/tracert to work (they are essential for my service offering)?
(First I created VMSS with default Basic Load Balancer - there everything works, including ping).
Turned out this is a limitation of Load Balancer. According to documentation it should apply for both Basic and Standard Load Balancers. For me Basic does allow ICMP traffic and Standard does not.
This article suggests a few workarounds (using psping instead of ping): https://blogs.msdn.microsoft.com/mast/2014/06/22/use-port-pings-instead-of-icmp-to-test-azure-vm-connectivity/
We have kafka and zookeeper installed on a single AWS EC2 instance. We have kafka producers and consumers running on separate ec2 instances which are on the same VPC and have the same security group as that of kafka instance. In the producer or consumer config we are using the internal IP address of the kafka server to connect to it.
But we have noticed that we need to mention the public IP address of the EC2 server as advertised.listeners for letting the producers and consumers connect to the Kafka server:
advertised.listeners=PLAINTEXT://PUBLIC_IP:9092
Also we have to whitelist the public ip addresses and open traffic on 9092 port of each of our ec2 servers running producers and consumers.
We want the traffic to flow using internal IP addresses. Is there a way we need not whitelist the public ip addresses and open traffic on 9092 port for each one of our servers running producer or consumer?
If you don't want to open access to all for either one of your servers, I would recommend adding a proper high performance web server like nginx or Apache HTTPD in front of your applications' servers acting as a reverse proxy. This way you could also add SSL encryption and your server stays on a private network while only the web server would be exposed. It’s very easy and you can find many tutorials on how to set it up. Like this one: http://webapp.org.ua/sysadmin/setting-up-nginx-ssl-reverse-proxy-for-tomcat/
Because of the variable nature of the ecosystem that kafka may need to work in, it only makes sense that you are explicit in declaring the locations which kafka can use. The only way to guarantee that external parts of any system can be reached via an ip address is to ensure that you are using external ip addresses.
We did a network traffic capture while using the Discovery Node API and found that there was port access attempted on 621XX ports (62111, 62112, etc) and we were wondering if there was a specific set of ports the Discovery service typically uses.
This information would help immensely when firewall and corporate proxy settings come in to play.
The Watson Discovery API is an HTTPS service so only needs TCP port 443 to work. I would suggest that the activity on ports 621** are dynamic or private ports that your app is using to make the connections. They are not ports that need to be punched through firewalls, they are merely the port at which HTTPS connections to the remote server on port 443 are terminated.
We have a web instance (nginx) behind a ELB which we manually power on when required.
The web app starts up quickly and returns a successful 200 response when we run wget locally.
However the website will not load as the ELB isn't sending healthcheck requests to the instance. I can confirm this by viewing the nginx access logs.
The workaround I've been using is to remove the web instance from the ELB and add it back in.
This seem to activate the healthchecks again and they are visible from our access logs.
I've edited our Healthcheck settings to allow a longer timeout and raise the Unhealthy Threshold to 3 but this has made no difference.
Currently our Health Check Config is:
Ping Target: HTTPS:443/login
Timeout: 10 sec
Interval: 12 sec
Unhealthy: 2
Healthy: 2
Listener:
HTTPS 443 to HTTPS 443 SSL Cert
The ELB and web instance are both on the same public VPC Security Group which has http/https opened to 0.0.0.0/0
Can anyone help me figure out why the ELB Health checks aren't kicking in as soon as the web instance has started? Is this by design or is there a way of automatically initiating the checks? Thank you.
Niall
Does your instance come up with a different IP address each time you start it?
Elastic Load Balancing registers your load balancer with your EC2 instances using the IP addresses that are associated with your instances. When an instance is stopped and then restarted, the IP address associated with your instance changes. Your load balancer cannot recognize the new IP address, which prevents it from routing traffic to your instances.
— http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/TerminologyandKeyConcepts.html#registerinstance
It would seem like the appropriate approach to getting the instance re-associated would be for code running on the web server instance to programmatically register itself with the load balancer via the API when the startup process determines that the instance is ready for web traffic.
Update:
Luke#AWS: "You should be de-registering from your ELB during a stop/start."
— https://forums.aws.amazon.com/thread.jspa?messageID=463835
I'm curious what the console shows as the reason why the instance isn't active in the ELB. There does appear to be some kind of interaction between ELB and EC2 where ELB has some kind of awareness of an instance's EC2 state (e.g. "stopped") that goes beyond just the health checks. This isn't well-documented, but I would speculate that ELB, based on that awareness, decides that it isn't worth bothering with the health checks, and the console may provide something useful to at least confirm this.
It's possible that, given sufficient time, ELB might become aware that the instance is running again and start sending health checks, but it's also possible that instances have a hidden global meta-identifier separate from i-xxxxxx and that a stopped and restarted instance is, from the perspective of this identifier, a different instance.
...but the answer seems to be that stopping an instance and restarting it requires re-registration with the ELB.