0

I'm setting up a site where users can set up their own site. The users enters a sitename (say site1) and the site is created with the subdomain site1.example.com. Currently I’ve set up a wildcard DNS to a single server where the site created. This works fine but is not scalable enough for future use.

I would like to be able to control on what server the site is created. For example site1 is created on server1 and site2 is created on server2. I’ve been looking at a couple of solutions.

  1. Set up my own DNS server and create the subdomain before the site is created.
  2. Using some kind of hosted DNS server that has an API to create the domain.
  3. Use IIS in some way so that I can redirect my wildcard DNS to a subdomain hosted on a server.

I prefer the IIS solution but have not found any example on setting this up or if this is even possible.

Perhaps there are some opensource or payed solutions available.

Peter Van de Langenberg
  • 1

3 Answers3

3

There are many ways to solve this, but the best solution depends on your limitations, environment, types of sites, etc. For example:

  • Is a single server not able to handle all sites due to the size of the content on each site, or because of the load/traffic generated?
  • Is the content stored as files, or in a database?
  • Are the sites running an application that requires shared state? Is the shared state kept in memory or on another server or cluster of servers?
  • Does each site require its own deployment of the application, or does the application support multi-tenancy (basically, can it look at what hostname was requested, and use that as its site -- this is how most multi-client hosted CMS/e-commerce applications work)
  • Can a single site grow so big that it can't be handled by a single server?

I will assume you have a "typical" web application, with the application hosted in a web server, session state stored locally in memory (the default for many platforms), and a database. I will assume that storage is in the database, and your application supports multi-tenant.

The "typical" way to set this up would be to have multiple tiers:

  • Database tier (Very beefy fail-over pair, master/slaves systems, or cluster, depending on your DB platform)
  • Session state tier (may be stored in the DB tier, a separate DB, IIS session state server, memcached, or something similar)
  • Application tier (your app server -- IIS)
  • Load balance tier (dedicated hardware, nginx, HAproxy, etc)

There are several key points to this:

  • Any application server is able to handle a request for any "site" (because it's all the same application, and they all connect to the same database)
  • Your session state must be shared and available to all app servers
  • Your database tier must be able to handle the load of simultaneous access from all app servers. Most people employ lots of caching at various different points in order to make this work.
  • If you are aiming for high-availability, you need to have N+1 capacity: eg, if your peak load requires 10 app servers, then you should have at least 11.
  • Many times in a big site, people will offload their static content (images, css, etc) to another server or even a CDN like Akami or Amazon CloudFront.

The setup is pretty flexible. You can add a LOT of app servers. You can independently change the setup of any teir. You have no single point of failure (eg, you can tolerate losing a server or two without anyone noticing).

Even if your app doesn't support multi-tenancy, you have a couple options:

  • Deploy every site to every server (note: this requires that you have a way of also keeping all files synchronized for installs/updates, and that you don't store any content locally)
  • Deploy every site to every server, but store the content on a centralized (and redundant) NAS or SAN
  • Deploy sites selectively, and then use your load balancer to direct traffic to the appropriate server based on the hostname.

Take a look at StackExchange's setup, which is actually quite close to what I just described:

enter image description here

gregmac
  • 1,579
  • 4
  • 18
  • 27
0

There are multiple solutions for this. What about deciding statically the server destination based on the domain? For example, after creating "site12", if the hash of "site12" is even then it goes to server1, otherwise it goes to server2.

uwe farinol
  • 11
  • 1
0

Your problem is creating the DNS records programmatically?

If so you can use NicTool. It has an extensive API for managing your DNS and can work with many nameservers.

Disclaimer: I use NicTool at work and I have set up automations that have saved us substantial cost.

MemCtrl
  • 118
  • 2
  • 10