Do you know where to look for information, regarding setting up for distributing containers and volumes into locations?
The following link, states that Kubernetes Engine is an available product for locations:
"Products available by location"
"Deploy resources in specific zones, regions and multi-regions."
https://cloud.google.com/about/locations
Just to add more details to what #Harsh Manvar mentioned and to answer your question. The global load balancing offerings will route traffic to the backend instances in the zone closest to the client. That said there are some scenarios where this may not occur 100% of the time.
In general users traffic is directed to a single IP address. Points of Presence (PoPs) terminate traffic as near as possible to your users and direct load-balanced traffic to the closest healthy backend that has capacity. More information here
‘nodeselector’ basically forces a Pod to run only on Nodes in that node pool. Depending on the resource availability, traffic will be sent from the Load balancer to the aforementioned nodes where you attached the label.
I hope this helps
Related
The title might be a little too much, but i am unable to find any statements regarding this. I am trying to set up computes in multiple AZ's (in a region) with auto-scaling. i am also trying to see if i can get away with only one ELB to do the load balancing act.
In this setup, the ELB is a single point of failure so, I would like to know, if anyone knows the recovery associated with ELB's. There are documentations about scaling in ELB but not the recovery/higher availability.
thanks
Make sure you select multiple AZs for the load balancer as well. You will have to in order for it to work with EC2 instances in multiple AZs anyway. When you do that, multiple ELB instances are created for you behind the scenes, one in each AZ. So the ELB isn't really a "single point of failure".
The most common issue you may see with an ELB is if you have a very quick, large burst of traffic, which will take the ELB a few minutes to scale up to meet the demand. If you know ahead of time you will be getting a large increase in traffic you can send a request to AWS support to pre-warm the ELB for you.
I recommend reading the section titled "Common Pitfalls When Testing Elastic Load Balancing" in this article.
An ELB is a logical entity that consists of multiple (at least 2 - one per AZ - and generally more) instances that route traffic to your back ends.
If an individual ELB instance were to fail, it would be replaced automatically, much in the way autoscaling replaces failed instances.
You can usually tell how many instances are in your ELB by doing a DNS lookup - you will see multiple IP addresses returned.
ELBs can become overloaded if you have a sudden burst of traffic, so they are not failure proof, but for most loads they do a very good job.
Right now our small-ish business has 3 clients who we have assigned to 3 elastic IPs in Amazon Web Services (AWS).
If we restart an instance no one loses access because the IPs are the same after restart.
Is there a way to handle expanding to 3 more clients without having things fall apart if there's a restart?
I'm trying to request more IPs, but they suggest it depends on our architecture, and I'm not sure what architecture they're looking for (or why some would warrant more elastic IPs than others or if this is an unchecked suggestion box).
I realize this is a very basic question, but googling around only gets me uninformative docs from the vendors mouth.
EDIT:
There is a lot of content on the interwebs (mostly old) about AWS supporting IPv6, but that functionality appears to be deprecated.
You can request more EIPs in the short run. Up to 5 EIP is free depending on your account. You should also considering using name based URLs and assign each of your clients to a subdomain, for example,
clientA.example.com
clientB.example.com
clientC.example.com
This way you will not be needing an additional IP for every client you add. Depending on your traffic, one EC2 instance can serve many clients, and as you scale, you can put multiple EC2 instances behind an AWS Elastic Load Balaner, and this will scale to serve exponentially more clients.
If the client wants to keep their servers separate and can pay for them, you can purchase EIP as many as you need. You should also consider separating database into one database instance for each client, which is probably what clients desire more than separation of IPs.
For IPv6, a quick workaround would be to use a front-end ELB that supports both IPv6 and IPv4.
If you use elastic IPs from VPC, you get 5 per region for an AWS account. See Amazon VPC Limits.
So, you can go to console and select VPC. Then click on elastic IPs, create it. Once created, assign it to a relevant instance.
So, atleast for now, you can solve the problem if you are not bothered about region.
I recently started reading about and playing around with AWS. I have particular interest in the different high availability architectures that can be acheived using the platform. Specifically, I am looking for a reliable poor man's solution that can be implemented using the least amount of servers.
So far, I am satisfied with solutions for the main HA concerns: load balancing, redundancy, auto recovery, scalability ...
The only sticking point I have is with failover solutions.
Using an ELB might seem great, however ELB actually uses DNS balancing under the hood. See Is AWS's Elastic Load Balancer a single point of failure?. Also from a Netflix blog post: Lessons Netflix Learned from the AWS Outage
This is because the ELB is a two tier load balancing scheme. The first tier consists of basic DNS based round robin load balancing. This gets a client to an ELB endpoint in the cloud that is in one of the zones that your ELB is configured to use.
Now, I have learned DNS failover is not an ideal solution, as others have pointed out, mainly because of unpredictable DNS caching. See for example: Why is DNS failover not recommended?.
Other than ELBs, it seems to me that most AWS HA architectures rely on DNS failover using route 53.
Finally, the floating IP/Elastic IP (EIP) strategy has popped up in a very small number of articles, such as Leveraging Multiple IP Addresses for Virtual IP Address Fail-over and I'm having a hard time figuring out if this is a viable solution for production systems. Also, all examples I came across implemented this using a set of active-passive instances. It seems like a waste to have a passive for every active to achieve this.
In light of this, I would like to ask you what is a faster and more reliable way to perform failover?
More specifically, please discuss how to perform failover without using DNS for the following 2 setups:
2 active-active EC2 instances in seperate AZs. Active-active, because this is a budget setup, were we can't afford to have an instance sitting around.
1 ELB with 2 EC2 instances in region A, 1 ELB with 2 EC2 instances in region B. Again, both regions are active and serving traffic. How do you handle the failover from 1 ELB to the other?
You'll understand ELB better by playing with it, if you are the inquisitive type, as I am.
"1" ELB provisioned in 2 availability zones is billed as 1 but deployed as 2. There are 2 IP addresses assigned, one to each balancer, and 2 A records auto-created, one for each, with very short TTLs.
Each of these 2 balancers will forward traffic to the instance in its same AZ, or you can enable cross-AZ load balancing (and you should, if you only have 1 server instance in each AZ).
These IP addresses do not change often and though it stands to reason that ELBs fail like anything else, I have maybe 30 of them and have never knowingly had a dead one on my hands, presumably because the ELB infrastructure will replace a dead instance and change the DNS without your intervention.
For 2 regions, you have little choice other than using DNS at some level. Latency-based routing from Route 53 can send people to the closest site in normal operations and route all traffic to the other site in the event of an outage of an entire region (as detected by Route 53 health checks), but with this is somewhat more likely to encounter issues with DNS caching when the entire region is unavailable.
Of course, part of the active/passive dilemma in a single region using Elastic IP is easily remedied with HAProxy on both app servers. It's an http request router and load balancer like ELB, but with a broader set of features. The code is so tight that you can likely run it on your app servers with negligible CPU consumption. The instance with the EIP would then balance traffic between its local app server and the peer. Across regions, HAProxy behind ELB could forward traffic to a mate in a remote region, if the local region is up but for whatever reason the application can't serve requests from the local region. (I have used such a setup to increase availability of external services, by bouncing the request to a remote AWS region when the direct Internet path from the local region is not working.)
We plan to do some performance test on a web site hosted on some Amazon EC2 instances. The question is, if all the HTTP traffic come from the same IP addresses (say, in the case of many different client hosts sharing the same public IP), will the EC2 loadbalancer forward all traffic to only one of the web servers (instances)?
This used to be a problem due to DNS caching by clients indeed (see my answer to Can Elastic Load Balancers correctly distribute traffic to different size instances for more on the previous state of affairs), but has mostly been remedied apparently with the recent introduction of Elastic Load Balancing [...] Cross-Zone Load Balancing:
We are pleased to announce support for cross-zone load balancing, which changes the way that Elastic Load Balancing (ELB) routes incoming requests, making it even easier for you to deploy applications across multiple Availability Zones. [emphasis mine]
The announcements provides a bit more information already, but links to Request Routing for details:
If you enable cross-zone load balancing, you no longer have to worry that clients caching DNS information will result in requests being distributed unevenly. And now, ELB ensures that requests are distributed equally to your back-end instances regardless of the Availability Zone in which they are located. [emphasis mine]
This still doesn't outline the exact algorithm used, but the main source of uneven distribution seems to be addressed like so (I have read a post by a large AWS customer recently, who reported their metrics becoming a more or less flat curve after flipping the switch on this, but don't recall the URL right now).
This has been the case in the past, I presume it still may be an issue. Its not so much that it will forward all traffic to a single instance, but it can send all traffic to a single zone.
The ELB does some load balancing with DNS round robin. A cached DNS lookup, could result in multiple requests being routed to the same zone.
I'm trying to get my EC2 instances to communicate better with APIs of a 3rd party service. Latency is extremely important as voice communication is heavily involved & lag is intolerable.
I know a few of the providers use EC2, but the thing is Amazon's IP system makes it difficult to find which region the instance is in. With non elastic-ip services I could do a whois and find if it was in Australia or somewhere in Europe so I could put a server close by.
With these elastic IP's how can I find which zone they're in. I can use ping times but its a bit of a guess and I have to make all these instances in different regions to find the shortest ping time.
Amazon EC2 regularly publishes its Amazon EC2 Public IP Ranges, which clusters them by Region.
It does not cluster them by Availability Zone (AZ) (if you actually meant that literally), but this shouldn't matter much, insofar cross AZ latency should regularly be within single digit milliseconds range only.
Other than that you might also be interested in my answer to How could I determine which AWS location is best for serving customers from a particular region?, which outlines two other options for handling this based on external data/algorithms or via the Multi-Region Latency Based Routing now Available for AWS (which would likely only be useful when fully embracing Amazon Route 53 as well).
Put your server behind a Route 53 DNS and let Latency Based Routing do the rest for you - it can decide automatically for you the least latent server.
http://aws.typepad.com/aws/2012/03/latency-based-multi-region-routing-now-available-for-aws.html