We're building a multitenant SAAS app. Each customer gets its own subdomain, http://customername.mycompany.com. Each customer will have many gigabytes of data, which means that they have to be assigned to a particular server and stay there.
If I have a server farm, and a request comes in for a particular customer, how do I direct the request to the right server?
My thought is that I'll have to create some kind of custom, programmable load balancer that will know where each customer lives and proxy the request through.
Is there an easier way?
If not, where do I find such a load balancer? The ones I've found online act more like appliances than applications which could go query a database to find the right destination server.
I think the answer is in the question; you mention that the user will connect to username.mycompany.com. So use a DNS A record to point them to a particular IP.
In the future, if you wanted to load balance the user across (say 2) servers, you could create a virtual IP on a load balancer appliance (running LVS for example), and then point the A record to the Virtual IP created by the LB, and distribute the user across a group of servers that you have configured.
This is why using subdomains is simpler than having URL based access such as company.com/username, in which case you would have to inspect the content of the packet to see the requested URL. By using subdomains, everything can be done at the IP layer.
Related
two different websites and i want one URL,
example: when user visit example.com from India he get website-1 but on same domain and same URL and he visit example.com from US than he get website-2 with same URL on same domain, so any one can help me ?
There are multiple ways to archieve this (including but not limited to):
DNS based approach
IP based approach
DNS based approach
You have two servers, one for website-1 and one for website-2. Now you configure your DNS server to serve the IP for website-1 if the client is from India and website-2 if the user is from the rest of the world. This feature is referenced as GeoDNS or "Geolocation Load Balancing".
I said "rest of the world" because you can never be sure, that there will be only requests coming only from India and the US.
IP based approach
Your server needs to decide after doing a GeoIP lookup of the client, which website to serve. Basically the same logic as above, but this time implemented on only one server. This can be done using most server side scripting languages and maybe even within your webserver itself.
Wondering if we can share session data between two servers (running different code) behind an Nginx reverse proxy.
To be precise, we have a legacy app in PHP running on an apache server. We are updating some functionality and hosting only that functionality on a separate server (nginx). Both apps update the same DB.
nginX uses load balancing/ reverse proxy URL rewritting techniques to decide which server to send the client to based on the URL path they use.
So, a person can add items to his virtual basket (held in session) on
the new server application.
He then decides to edit his personal information which is on the other server (Legacy).
Nginx uses it's reverse proxy/load balancing magic to decide which server to send the person to based on where an app is available.
The question is, how can a session created on one app server be available to another app server aswell? is it possible to setup the reverse proxy to store all session data and how. Please point me to the right direction of you can help with google links aswell.
your question has several possible answers. It all depends on the way the application is designed.
A possible scenario would be to keep session information on a database shared among different web heads. In this way the client, once authenticated will retrieve its "session status" regardless which server he is accessing in the final servers cluster backend.
Again, this depends very much on the way the application is/has been designed.
I think there is very little magic you can do on an old legacy application just by configuring the reverse proxy engine.
In the end, sessions are handled by the application server and not the proxy frontend.
I am developing an app (RoR + Heroku) which allows users create their own websites either using my subdomain (pagename.myapp.com) or using their own domain (pagename.com).
An important point of this is that this option is the key of my business: subdomains are the free plans and custom domains are the paid ones. So I have a table where I store the custom domains of each user and check if this page is active (exists and has paid the quota).
For that I need to give users the capability of point their domain to my servers. All we know that Heroku don't recommend the use of DNS A-Records.
Also I would like to abstract as much as possible this feature to being able to switch my infrastructure (Heroku to AWS) in the future without having to ask all my users to change their DNS Zone. Taking this into account, I think that the best option would be run something like an EC2 proxy (using AWS Elastic IP) which give me the ownership of this IP. This proxy I think that should redirect to proxy.myapp.com, and I would resolve the request in the app level.
Due to I didn't find clear information about that, I am not sure if this hypotesis is the best solution and how to setup the proxy (which type of proxy use? Nginx maybe?).
Said that, I would like to ask recommendations/best practices to solve this "common" feature.
Thanks
What you are wanting to do is fairly straight forward to implement. Your assumptions are correct about setting up the proxy. Nginx or haproxy will both work great for this (I personally would use haproxy). Here are some of the gotchas that you will run into though:
Changing the host header at a proxy server can cause the end web application to generate incorrect links. You can use relative paths to fix this, but it requires that the web application developer to be aware of the environment that they are running in.
user connects to www.example.com (proxy server)
proxy server connects to www.realdomain.com (web app)
the web app has a link for a shopping cart. www.realdomain.com/shoppingcart
the end user clicks on the link but the link is www.realdomain.com/shoppingcart instead of www.example.com/shoppingcart
The cost of the host acting as the proxy server. This can spiral out of control really quickly. For example, do you want redundancy, if so how are you planning on implementing that? Do you plan on having ssl termination? If so you will have to increase the CPU count to accommodate the additional load. Do you want to have a secure connection to heroku from your proxy? If you do then you will need to increase the CPU count for that as well. You may have to add additional ram as well depending on the number of concurrent connections.
Heroku also changes their load balancers regularly. This is important because your proxy service will need to reload the config / update the ip addresses of the heroku instances every 60 seconds. In my experience they may change once or twice a day, but the DNS entry that they use has a 60 second TTL. That means that you should make sure that you are capable of updating your config up to every 60 seconds.
My company has been doing something very similar to this for almost a year now. We use haproxy and simply have it reload the config regularly. We have never had an outage or an interruption to our end users. Nginx is also a very good product. It has built in DNS caching so if you go that route you will need to make sure that you configure it correctly so that the DNS cache TTL is 60 seconds.
Will many of your clients want to use your app on their domain apex? E.g. example.com rather than theapp.example.cpm? If not, I would recommend having them CNAME to proxy.myapp.com which CNAMEs to myapp.herokuapp.com. Then, you can update proxy.myapp.com without customer interruption.
If you do need apex or A record support, you would want to set up Nginx as a reverse proxy for your Heroku app. Keep in mind that if you need HTTPS support for client domains, you will need to do some sort of certificate management on your proxy.
I like the answer dtorgo gave and that he mentioned the TLS termination, which many online tutorials on custom domains don't touch at all.
I'll go into more detail on how to implement the custom domains feature for your SaaS while also handling the TLS/HTTPS.
If your customers just CNAME to your domain or create the A record to your IP and you don't handle TLS termination for these custom domains, your app will not support HTTPS, and without it, your app won't work in modern browsers on these custom domains.
You need to set up a TLS termination reverse proxy in front of your webserver. This proxy can be run on a separate machine but you can run it on the same machine as the webserver.
CNAME vs A record
If your customers want to have your app on their subdomain, e.g. app.customer.com they can create a CNAME app.customer.com pointing to your proxy.
If they want to have your app on their root domain, e.g. customer.com then they'll have to create an A record on customer.com pointing to your proxy's IP. Make sure this IP doesn't change, ever!
How to handle TLS termination?
To make TLS termination work, you'll have to issue TLS certificates for these custom domains. You can use Let's Encrypt for that. Your proxy will see the Host header of the incoming request, e.g. app.customer1.com or customer2.com etc., and then it will decide which TLS certificate to use by checking the SNI.
The proxy can be set up to automatically issue and renew certificates for these custom domains. On the first request from a new custom domain, the proxy will see it doesn't have the appropriate certificate. It will ask Let's Encrypt for a new certificate. Let's Encrypt will first issue a challenge to see if you manage the domain, and since the customer already created a CNAME or A record pointing to your proxy, that tells Let's Encrypt you indeed manage the domain, and it will let you issue a certificate for it.
To issue and renew certificates automatically, I'd recommend using Caddyserver, greenlock.js, OpenResty (Nginx).
tl;dr on what happens here;
Caddyserver listens on 443 and 80, it receives requests, issues, and renews certificates automatically, proxies traffic to your backend.
How to handle it on my backend
Your proxy is terminating TLS and proxying requests to your backend. However, your backend doesn't know who is the original customer behind the request. This is why you need to tell your proxy to include additional headers in proxied requests to identify the customer. Just add X-Serve-For: app.customer.com or X-Serve-For: customer2.com or whatever the Host header is of the original request.
Now when you receive the proxied request on the backend, you can read this custom header and you know who is the customer behind the request. You can implement your logic based on that, show data belonging to this customer, etc.
More
Put a load balancer in front of your fleet of proxies for higher availability. You'll also have to use distributed storage for certificates and Let's Encrypt challenges. Use AWS ECS or EBS for automated recovery if something fails, otherwise, you may be waking up in the middle of the night restarting machines, or your proxy manually.
If you need more detail you can DM me on Twitter #dragocrnjac
I am wondering how distributed web site traffic is balanced. For example, I have a web site which has the single domain name (www.foo.com) and supposing physically it is setup as three web servers in US, EU and Asia separately. When the end user is located in the US, I want the user to access US physical web server when he requests www.foo.com in his browser. When the end user is located in the EU, I want the user to access EU physical web server. And similar for Asia. The benefit is the end user could access the nearest server, which will give the best performance.
I believe most big and distributed web sites are implemented in this way, e.g Google. I am wondering how it is implemented internally? In more details, how the magic of finding the nearest server is implemented?
Here you go. A perfect article for you and me to understand how this works. Like #omar it's something to do with DNS.
Global DNS Load Balancing, direct the users based on their geography.
Quick Info:
A special DNS server, or a module attached with DNS server, return different answer to different request based on the request (generally another DNS server, which is your DNS server of your ISP) IP geo-location :
www.yourdomain.com ---[CNMAE Record] ---> geo.yourdomain.com --- [ GSLB handdling, CNAME ]--> us.geo.yourdomain.com -- [A record] --> 68.178.110.21
Please don't hesitate to have a look at this:
http://dev.robertmao.com/2007/06/30/global-dns-load-balancing-for-free/
Some of the players who give service:
Amazon Route 53, Cloudlevarage, f5, zeus, etc
Some of the ways you can build your own Geo-DNS:
Bind & MaxMind
Bind & MaxMind
This is done by using professional DNS services. They have world wide DNS servers who support DNS resolution from countries and return specific IP.
our hosting account is set up with the domain www.nashman.ca, and our application is at www.nashman.ca/hub. We have another domain that forwards to www.nashman.ca/hub and that's hub.mhn.co. The problem i'm having with this is that the forwarded domain adds on the /hub whenever you navigate to another page from hub.mhn.co, so the domain shows as hub.mhn.co/hub/admin when you're in the admin area, for example. I need the domain to stay consistent, and never show that folder name, because its breaking some of the javascript I use. What is the best way to set this up?
edit
I've been doing some reading about URL Rewriting, and looking into it - my hosting provider supports the IIS7 URL Rewrite module. All the tutorials I've found so far detail how to set up rules using the IIS config tools, but I don't have access to them. Is there a way to do it by editing my web.config in my apps root directory? And will this solve my issue?
Is the default page for hub.mhn.co using a redirect to www.nashman.ca? If so, what is happening is that the forwarding software basically returns a new URI that the browser requests, and the new URI will replace the old one in the browser window and thus in all future requests. You're probably redirecting to ~/hub/ (the hub subdirectory of the site root) which will result in the browser requesting a new URI that keeps the domain name but tacks on the subdirectory.
If you have direct control over the DNS and your webservers, you can use the DNS configuration to direct a request for the hub.mhn.co domain directly to the /hub subdirectory of your webserver. That way, the browser never knows that hub.mhn.co is actually www.nashman.ca/hub/. You might have to direct to an alternate port on the webserver and map that port to the subdirectory, depending on your DNS software (IIRC, most can deal with ipaddress/subdir routes, but some can only handle routing to ipaddress:port).
If your IT department does not have direct control/ownership over your DNS routing, or your exact hosting environment, you are more or less at the mercy of your hosting provider. They may be able to set up their environment to do the same thing, or not; all you can do is ask.
EDIT: Basically you have two options left if you're hosting remotely and can't use their DNS to reroute silently.
First option: clone (copy all files from) the web layer of nashman.ca/hub as hub.mhn.co under a different root space in your hosting environment (try to keep any hooks to service-layer code over at nashman so you don't have to copy the whole vertical slice). If you must also keep the UI under the /hub/ subdirectory, you're repeating code, but you may be able to mitigate this with deploy scripts that will allow you to deploy one local copy of your codebase to various locations. This may also cost more as your hosting environment is now hosting two non-trivial sites.
Second option: host the site and/or resolve the calls on your own hardware. As long as you have a public, static IP address through your ISP, you can provide a DNS server that will be the "authoritative" server for nashman.ca and hub.mhn.co domains. Your ISP or a third party domain name registry can provide a "pass-down" route to get requests from the TLD servers down to you. Then, you can route requests to whatever IP address, port and/or subfolder you like; that can be a remote webhosting provider (as long as they don't mind JUST hosting your site) or your own webservers. This will require the hardware, and a static IP from your ISP. If you lose power to this server, your site will be unreachable until power's restored. If the IP address of your DNS server changes, your site will be unaccessible by DNS until the server that routes requests to you updates its routing table with the new IP (which can be up to 24 hours).