I have an AWS EC2 server that hosts 3 domains with Apache 2. This server sits behind an AWS ELB load balancer which sends it requests. If I want to update this server, instead of taking the server down, I can create a new identical EC2 server and install all the software using the same scripts that built the first server and when it is ready I can add the new server to the ELB and then remove the old server. This gives me zero downtime which is great.
But before I remove the old server how do test the new server to prove everything is working and it is serving those 3 domains? DNS points to the ELB for these domains, the ELB sendsthe requests to the server, and the Apache install on the server routes the traffic to the appropriate site depending on what subdomain was requested. Is there a way make a request to the new server via IP address since that is the only way to address it before it is behind the ELB but tell it I want to make a request to a specific subdomain? If not how else can I prove all 3 sites are running and working properly without just adding it to the ELB, removing the old server, and crossing my fingers?
P.S. Sorry for the poor title. Please edit it if you can think of a better one that better represents what I am asking.
Use ELB healthcheck to perform the check. I recommend you to enable Apache server status mod. Use health check against /server-status and if it returns 200 for certain period of time, ELB will mark the instance as active and healthy.
Related
We have configured a new webfarm using IIS10 with 3 hosts operating with the web traffic with a loadbalancing IIS ARR3.0 server sitting infront to balance incoming requests between all the nodes. During initial testing (Basic HTML pages) the round robin setup (33.33%) distribution between each node was working well but we had to enable server / client affinity so that our applications kept a consistent connection between our client session and the application. Since then, we are finding that all traffic going to these applications originating from different machines on different networks are all being forwarded to the same application server. If you take the server offline the application seamlessly starts running on the next server in the list (Client obviously must sign in again). Whilst one server is fine at this time to run the two applications we have running when we ramp up our migration and have all our 140 applications running, I don’t think one server will be too happy with the load.
ADDITIONAL INFORMATION
LoadBalancers/Arr Servers: LB-01 (LB-02 DUPLICATED Server for redundancy). Default ARR URL ReWrite with Route to Server Farm Action. Image of LB/ARR URL ReWrite Rule Server Affinity Enabled Client Affinity enabled use hostname selected no Advanced Settings, no routing rules. ARR Default Proxy Settings Image of Proxy Settings
Web/Application Servers WEB-01, WEB-02, WEB-03 FileSystem Shared using DFS All running on Shared Config's
The Applications would be as follows
https://www.domainname.com/application-name1
https://www.domainname.com/application-name2
...
Were the application launch page changes but the domain name stays the same
Image of IIS Monitoring and Management Window showing distribution
If there is a setting you wish to verify please ask for them. I know people arent physchic but huge paragraphs of information never really help.
My hunch is it is something to do with the URL rewrite I have tried the settings in the below post to no avail.
IIS ARR & load balancing
Uncheck 'Host Name Affinity' to dispatch to all your hosts
I have a website, example.com, that has a subdomain called play.example.com which hosts a multiplayer game on it.
Separately, I have an Elastic Beanstalk environment that hosts the game server (NodeJs backend), separate from the client build itself.
play.example.com connects to the game server over https, but is met with the error: ERR_CERT_COMMON_NAME_INVALID.
Steps I have taken:
1) Created an SSL certificate for *.example.com using AWS Certificate Manager
2) Added a listener to my load balancer that listens on port 443
3) Created an alias, type A IPv4 with the name play.example.com to the EB url
I understand the the error means that there is a name mismatch between the URL and the certificate, but isn't that what the alias is supposed to fix?
Thanks for any suggestions.
Okay, I've spent about a week now trying to fix these issues myself, and unfortunately Stackoverflow is full of people asking this question and nobody's giving answers.
Here's how I solved it, some of this might work for you too. It ended up being primarily configuration issues.
Your SSL cert is appropriate - I ended up hardcoding my subdomain ops.example.com but your wildcard shouldn't be an issue.
I read somewhere that AWS requires any DNS records to be of type CNAME, so I set up a basic CNAME record to redirect ops to my-site.my-aws-region-1.elasticbeanstalk.com
Then, what ended up being the linchpin to the whole thing was that in order to make HTTPS work, your load balancer has to be Listening for HTTPS on 443 and route to the instance via HTTP on 80.
Amazon was trying to tell me this, but because I was a noob and because their tutorials are some of the worst tutorials I've read in my entire career, they actually don't expose any of your secure ports to the internet. Which is actually fine because your traffic is encrypted all the way up to the load balancer, and then after that, even though it's not HTTPS anymore, it's all already on amazon's servers anyway so it's not any less secure.
Hope something in here helps!
I got a mail from amazon s3 webservices stating below details
"We are writing to you today to let you know about changes which impact your use of the Amazon Simple Storage Service (S3). In efforts to best serve our customers, we have improved the systems powering the Amazon S3 API and are in the process of shutting down legacy application server capacity. We have detected access on the legacy capacity for Amazon S3 buckets that you own. The legacy capacity is no longer in service, as the DNS entry for the S3 endpoint no longer includes the IP addresses associated with it. We will be shutting down the legacy capacity and retiring the set of IP addresses fronting this capacity after April 1, 2020."
I want to find out which legacy system I am using, and how to prevent from affecting my services.
Imagine you had a web site, www.example.com.
In DNS, that name was pointed to your web server at 203.0.113.100.
You decide to buy a new web server, and you give it a new IP address, let's say 203.0.113.222.
You update the DNS for example.com to point to 203.0.113.222. Within seconds, traffic starts arriving at the new server. Over the coming minutes, more and more traffic arrives at the new server, and less and less arrives at the old server.
Yet, for some strange reason, a few of your site's prior visitors are still hitting that old server. You check the DNS and it's correct. Days go by, then weeks, and somehow a few visitors who used your old server before the cutover are still hitting it.
How is that possible?
That's the gist of the communication here from AWS. They see your traffic arriving on unexpected S3 server IP addresses, for no reason that they can explain.
You're trying to connect to the right endpoint -- that's not the issue -- the problem is that for some reason you have somehow "cached" (using the term in a very imprecise sense) an old DNS lookup and are accessing a bucket by hitting a wrong, old S3 IP address.
If you have a Java backend service accessing S3, those can notorious for holding on to DNS lookups forever. You might need to restart that service, and look into how to resolve that issue and enable correct behavior which is -- as I understand it -- not how Java behaves by default. (Not claiming to be a Java expert but I've encountered this sort of DNS behavior many times.)
If you have an HAProxy or Nginx server that's front-ending for an S3 bucket and has been up for a while, those might need a restart and you should look into how to correctly configure them not to resolve DNS only at startup. I ran into exactly this issue once, years ago, except my HAProxy was forwarding requests to Amazon CloudFront on only 1 of the several IP addresses it could have been using. They took that CloudFront edge server offline, or it failed, or whatever, and the DNS was updated... but my proxy was not able to re-query DNS so it just kept trying and failing until I restarted it. Then I fixed it so that it periodically repeated the DNS lookup so it always had a current address.
If you have your own DNS resolver servers, you might want to verify that they aren't somehow misbehaving, and you might want to ensure that you don't for some reason have any /etc/hosts (or equivalent) static host entried for anything related to S3.
There could be any number of causes but I'm confident at least in my interpretation of what they say is happening.
Suppose we have two servers serving requests through a load balancer. Is it necessary to have web server in both of our servers to process the requests. Can load balancer itself act as a web server. Suppose we are using apache web server and HAProxy. So does that mean that web server(Apache) should be installed in both the server and load balancer in any one of the server. Why can't we have load balancer in both of our server machine that will be receiving the request and talking to each other to process the requests.
At the very basic, you want to have Webservers fulfill requests for static contents, while Application servers handle business logics, i.e. handle requests for dynamic contents.
But Web servers can do many other things as well such as authenticate and validate requests, logging metrics. Also, the important part of Webserver is putting the Content it gets from Application servers with a View for client to represent.
You want to have LB sitting in front of both Web and App servers if you have more than one server. Also, there's nothing preventing you from putting both Web and App server in one.
The load balancer is in front of your webserver(s) to redirect requests according to number of sessions, a hash of source IP and destination IP, requested URL or other criteria. Additionally, it will check availability of the backend servers to ensure requests get answered even if one server fails.
It's not installed on every webserver - you only need one instance. It could be a hardware appliance, or a software (like HAproxy) which may or may not be installed on one of the webservers. Although this would not be prudent, as this webserver could fail and then the proxy would not be able to redirect traffic to the remaining server.
There are several different scenarios for this. One is load balancing requests to 2 webservers which serve the same HTML content, to provide redundancy.
Another would be to provide multiple websites using just one public address, i.e. applying destination NAT according to the requested URL. For this, the software has to determine the URL in the HTML request and redirect traffic to the backend webserver servicing this site. This sometimes is called 'reverse proxy' as it hides the internal server addresses from the outside.
First question, so if I get this wrong somehow be kind.
We are using Route 53 with Amazon and have our primary front end servers behind an ELB. Our app also routes all requests through HTTPS. We are utilizing an offsite status page via statuspage.io.
What I am trying to accomplish is if the primary site goes down I'd like to have R53 redirect both the SSL and non-SSL traffic to our status page.
I originally had tried setting up a static page in S3 but still had issues with HTTPS requests made on our site.
Has anyone done this successfully? I imagine it has to be possible, but its definitely outside my realm of expertise.
Thank you very much for your time and help.
You are right, S3 website doesn't support HTTPS. However, CloudFront does[1]. What you can do is failover to CloudFront and have your origin be your S3 website or your statuspage.io.
Steps:
Create a distribution and set the CNAMEs to match your DNS entries.
Upload and associate your SSL cert with your distribution
Update failover target to be your CloudFront distribution and set it as an alias.
[1] http://aws.amazon.com/about-aws/whats-new/2014/03/05/amazon-cloudront-announces-sni-custom-ssl/
Route53 is managing the DNS which is not what you want to do (even if you'd change the DNS it would take TTL to sync). What you should do is use a combination of auto-scaling policies and health-checks. These health-checks will be performed by the ELB every 30 seconds and if two consecutive checks will fail it'll mark the instance as out-of-service and will stop directing traffic to it (the ELB is directing traffic to your instances in a round-robin manner).
Having more than one instance and using auto-scaling rules is the key: it will enable AWS to terminate the unhealthy instance and spin up a new instance instead (in the same ASG with the same AMI etc).