How to setup multiple servers efficiently (via subdomain-ing each server)

[benneth]

How do you architect adding multiple DEDI or VPS servers for your WHMCS installation?

 

CURRENTLY: 

1. WHMCS is currently installed on a VPS with all of my client websites. The domain is "example.com" for this VPS.

2. Since my WHMCS shuts itself off when provisioning accounts via WHM on the same VPS, I am moving the client websites to their own DEDI server (which would require either A) a new domain, or B) a subdomin)

3. I understand you can use a subdomain on the "example.com" VPS in its DNS Zone, with the goal of configuring the VPS to point client website DNS to resolve on the DEDI... so the DEDI's domain would look like "dedi1.example.com", and DEDI2 would look like "dedi2.example.com"

 

Does anyone else use this approach to scale their hosting biz?

 

Thanks.

 

 

[steven99]

Using sub domains is a pretty standard method for naming servers and scales fine.  You could use multiple domains as the service domain if you wanted to do separation of different services.  You'll still need to use server.example.com as server addresses should follow that naming convention. 

For the domain part, I would recommend using a "service" domain and not like your business domain. 

[benneth]

Hey Steven,

Thanks for the speedy reply. 

What do you mean by "service" domain? Can you give me an example?

Is there an advantage to using a service domain?

[steven99]

A service domain, as I term it at least, is a domain that is specific for providing services -- not selling them.  Using a service domain instead of your business's domain isolates clients services from your own a bit further.  If your domain has issues, client services are not affected.  If you want to change something on the domain, like the nameservers, client services are not affected.   It also helps if you want to offer white label type hosting but that only comes in to play with reseller accounts.   Another usage could be if you want to sell the hosting part of business and keep the rest, you just sell the service domain and clients do not have to change nameservers -- until they are moved at least. 

 

[benneth]

Right, so something like "hosting.example.com", or "anotherService.example.com" is a service domain? Any other examples?

Also, what do you mean by "if your domain has issues, client services are not affected"? Do you mean I can take my server elsewhere and after a migration, client services should be unaffected (except for those with A records w/ the old server IP)?

For context, the only service I sell is web hosting for WordPress sites. I don't allow customers to order services, but I do allow them to login to their WHMCS account to update their preferred payment method. A bit strange, but my customers are 100%  tech luddites who want someone to "just do it" for them -- so that means no cpanel access, and I'm OK with that.

As for selling the "service domain", what do you mean by this?

EDIT: Keeping in mind, the goal is to figure out the best approach to add VPS' or DEDI's in the future to offer a single service (web hosting).

Edited April 17, 2021 by benneth

[steven99]

Example.com is the service domain, did not mean to confuse.   So, you would have examplebusiness.com and exampleservice.com   (or .net if you want to be technical on using the "right" tld for that).  .  Examplebusiness.com is where you sell the services, your site and billing, etc.  Exampleservice is where you would put all the server addresses  -- server.exampleservice.com.

[benneth]

Ok, got it.

So if I understand correctly, there's two approaches to ensure I grow the server farm properly, and also so client DNS records follow me (regardless of which hosting provider I am working with):

1. Buy your own IPV4 address (difficult, expensive). Create an A record for the client, set the IP for the  DEDI1.exampleservice.com... same for DEDI2, DEDI3, etc...

2. Create your own nameservers  (easy, cheap) - means you don't have to login to a client's registrar more than once (eg. set ns1.examplebusiness.com, ns2.examplebusiness.com)

 

I'm looking at option 2 more seriously, due to the complexity and cost of option 1. 

[steven99]

Having your own ipv4 range can help with migrations, but only helps with migrations when moving from one data center to another within the same city as otherwise downtime will terrible and clients will complain.    For your own range, you need your own network setup, colocation, etc etc.   Having clients use your nameservers is the best option for dealing with migrations.   Beyond that, using a CNAME record that say www.example.com points to is another option but example.com still needs to point to an A record.    Though I have rarely done migrations as have picked / been lucky with good hosts. 

[benneth]

Nameservers are the path forward for sure. But why is the CNAME important when it comes to migrations? I thought it was for vanity/appearance.

[steven99]

Well, the CNAMEs really only help sites  and not dedicated but could be used I guess.  So, for a site lets say you have a site www.example.com that is a CNAME and it points to  bob.example.service.   You as the provider, you control example.service and can update bob.example.service at any time without any actions by the client.  After migrating bob.example.service to its new server, you update the A record for bob.example.service and www.example.com is updated.    On an old system I used, this was used for testing URLs but where like site-id.server-id.example.service.  Typically, I'll see this in site-id.sites.example.service type format.   Though using CNAMEs can be a little performance hit as multiple look ups are needed but should not that much.    For the A record part for example.com, you only need to run a simple web server that redirects to www.example.com. 

Of course the above isn't really default behavior for cpanel, WHMCS, etc but could be done via sub domains options within at least whmcs.