Services Provided: Co-Location vs Rented/Dedicated Servers vs Cloud

	Author:	“No Bugs” Hare  Follow:
	Job Title:	Sarcastic Architect
	Hobbies:	Thinking Aloud, Arguing with Managers, Annoying HRs, Calling a Spade a Spade, Keeping Tongue in Cheek

[rabbit_ddmog vol=”7″ chap=”Chapter 23(b) from “beta” Volume VII”]

To recap our discussion on whether-you-want-to-use-cloud or rented (“dedicated”) servers – most likely, your cost analysis will show that in the long run you should aim for a “hybrid” deployment, using monthly rented servers for persistent load (and your databases(!)), and cloud servers to handle load spikes. NB: we’re still considering games which are large enough to use more than a few dozens of CPU cores – so $5/month 1-core Linode will not cut it.

However, “hybrid” deployments are quite complicated, and in general (and assuming that you can spare a few hundred per month on your hosting) – I suggest to have your first few servers rented (as we’ll see below, at the bare minimum you will need to rent two of them: gaming one and database one), and think about scaling your load (including using cloud servers) while you’re running your playtesting/public beta/etc.

On the other hand, there is one exception to this rule of thumb – if you want to run co-location from the very beginning.

On Co-Location

“most likely to rent just the space in the datacenter is going to be more expensive that renting space plus servers-in-that-space. Don’t ask me why it is the case – but it usually isCo-location is basically renting some space in the datacenter – and placing your own hardware there. One thing to keep in mind about co-location, is that (unless you’re really really large and are running hundreds of servers) – most likely to rent just the space in the datacenter is going to be more expensive that renting space plus servers-in-that-space. Don’t ask me why it is the case¹ – but it usually is.

It means that with co-location you’ll be paying quite a lot – including paying for hardware, for hardware upgrades, for SLAs with hardware suppliers, and for that space in datacenter (which, as mentioned above, most likely will cost you more than space+hardware).

In turn, it means that you should have a really compelling reason to decide to run your servers from co-location. While such reasons do exist – there are only a few ones I know of:

• You really really need to run custom hardware (which is not available for rent). However, examples of such custom hardware are quite rare; I can think only of the following ones:
  • hardware RNG
  • GPGPU (though personally, I would try to find GPGPUs for rent)
  • You really want to run some specific server box (such as HP DL580 – which I like a lot, and which is pretty difficult to find for rent). Still, I’d rather rent-and-run Dell R930 (which I like less than HP DL580 – but which is much easier to find for rent) – rather than deal with co-location
• You are using Amazon Lumberyard engine – and don’t want to run from EC2 cloud
  • Make sure to double-check that Amazon is ok with co-location (unofficially, they indicated they probably are [Amazon] – but it is better to double-check officially)
  • More on it in Vol. II’s chapter on Client-Driven Development Workflow and 3^rd-party Game Engines
• You’re a stock exchange which really wants (or is legally required) to have your hardware owned/run from specific location/…

Services You Need

Now, let’s see which services you can expect from your service provider (hosting ISP or CSP).

All Providers

For all the providers, you will certainly need:

• 24/7 support – and with at-most-within-the-hour reasonable response times too. This is damn important – you certainly do not want your game to be offline from 6pm Friday until 9am Monday just because some Ethernet cable went crazy – and there was nobody available to identify and fix the problem. Note that response times are more important than having phone support (yes, ticket system which is answered by a knowledgeable person in 10 minutes, is much better than spending 10 minutes over the phone with somebody who has no clue about the hardware just to redirect you further if you’re lucky – and I didn’t see knowledgeable 1^st-line phone support, ever).
  • Note that from a support’s point of view, it is usually significantly better to rent your servers directly from a hosting provider which owns the place (and not from a reseller which only poses as an independent company). This is especially true for handling connectivity issues (which in turn often require entering peer agreements – which most of resellers cannot do themselves².
• SLA A service-level agreement (SLA) is defined as an official commitment that prevails between a service provider and the customer.— Wikipedia —An SLA. Keep in mind that while every half-decent provider should provide you an SLA – don’t be too serious about their commitments. While SLAs seem to provide a kinda-guarantee for certain aspects of provider’s services – such as downtime or hardware replacement time, but let’s keep in mind that in 99.99% of cases SLAs are written in the way which doesn’t really provide any remedies if provider doesn’t fit into specified SLA requirements; most of the time – provider will re-imburse a portion of your monthly payment for SLA violations.³ In other words – your ISP is not going to cover the cost of your downtime (by far). Still – it makes sense to take a look at the SLA. If provider is proudly saying that their SLA guarantees 99.9% uptime – it is a Pretty Bad Sign™; 99.9% it means that they consider having 40+ minutes of downtime per month as a perfectly valid occurrence – and this is a damn lot <sad-face />. On the other hand, those well-established providers who kinda-guarantee 99.99% uptime – are much better (that is, if they provide what-they-promise – but it is up to you to figure out). Still, you shouldn’t treat it as a real “guarantee” (as noted above – remedies for them violating their SLAs are usually negligible) – but rather as an indication of what-they-consider-normal-performance.

Rented Servers

In addition to the generic services above, for “dedicated” rented servers – you will also need your hosting provider to:

• Provide you with hardware (more on it below)
  • As for “root access” to your servers – if out-of-band management is available (and it should) – you don’t really need that root password. What you need instead – is out-of-band management (IPMI, iLO, DRAC, etc.) credentials – and then you’ll be able to install your own system in the manner your want – completely remotely (more on it below).
• “for anywhere-serious deployment it is important to have an ability to connect your server boxes (and switches) so that servers can talk to each other without the need to go over the InternetProvide a so-called “private” network. The name for this service varies, but for anywhere-serious deployment it is important to have an ability to connect your server boxes (and switches) so that servers can talk to each other without the need to go over the Internet; this is (a) more secure, and (b) your ISP should not charge you for the traffic which goes within “private” network. In addition, as a Big Fat Rule of Thumb™, your out-of-band server management (which we’ll discuss below) should go via VPN and then to a “private” VLAN which does nothing but handles out-of-band access to your servers.
• Provide you with some Ethernet ports to connect your cables to – and Internet connectivity for these ports too.
  • This includes IPv4 addresses; for decent providers – it is usually not too difficult to get 4-8 IPs per box (at a few dozens dollars/month)
• Connect cables; this includes connecting cables from your server(s) to your switch(es) in the manner you describe.
  • BTW, keep in mind that Ethernet cables are responsible for a big chunk of overall failures – so replacing them is a standard procedure in case of any issues.
• S.M.A.R.T. S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) is a monitoring system included in computer hard disk drives (HDDs) and solid-state drives (SSDs) that detects and reports on various indicators of drive reliability, with the intent of enabling the anticipation of hardware failures.— Wikipedia —Repair their hardware if it fails. Ideally – they should also replace HDDs/SSDs in case of “pre-failure” indicated by S.M.A.R.T.
• Nice-to-have:⁴ “remote hands” services. Most of the time, you won’t need “remote hands” – and should be able to administer your dedicated servers perfectly remotely (see on out-of-band server management below). However, if you’re really paranoid about losing access to your server (for example, if out-of-band-management hardware is down and your server is malfunctioning too) – there may be value in having “remote hands”. Very briefly – “remote hands” is just somewhat-knowledgeable admin who knows nothing about your specific system, but who can say what she can see on screen, and can follow simple instructions such as “go to /etc/network/interfaces and change address for eth0 (which I was stupid enough to change 5 minutes ago) back to A.B.C.D”.⁵
• One thing which you do not need⁶ – is so-called “managed services”. Definitions of “managed services” vary, but most commonly – you will give keys of your servers⁷ to your ISP – and they will do their best to keep them running. This normally includes basic upgrades, backups, etc. – and it might be useful in general,⁸ but while it could work for common website architectures (and more generally – for standard software configurations) – it doesn’t work at all for highly customized software such as games.

Co-Location

For co-location – in addition to generic services above, you need your hosting provider to:

• Provide you with space (usually – it will be “rack” space, so make sure to buy only rack-oriented hardware)
• Provide you with power connectors (usually power bars go on sides of the rack) – and better it should be two power bars coming from independent power sources.
• Provide you with some (usually Ethernet) ports to connect “to the Internet” (and a few IPv4 addresses too)
  • Optionally – they may also provide “private” network; however – as long as your servers fit in the same “chunk” of the space-you’re-renting (such as in one single half-rack) – you can organize “private” network yourself (just by asking them to connect cables between your servers and switches).
• Receive and install whatever-hardware-you-bought-and-sent-to-them
• “normally, co-location providers do not repair hardware themselves – so it is your responsibility to repair your hardware, and to do it – you usually need a separate contract with hardware vendor who will do the actual job of replacing partsLet hardware vendors in – to repair your hardware (normally, co-location providers do not repair hardware themselves – so it is your responsibility to repair your hardware, and to do it – you usually need a separate contract with hardware vendor who will do the actual job of replacing parts).
• Connect cables, and provide “remote hands” (same way as for rented “dedicated servers”)

Cloud

For cloud/virtual servers – you can expect your Cloud Server Provider to:

• Provide you with cloud instances
• Re-launch your instances in case of hardware failure (ideally – they should detect failures and re-launch your instances themselves).
• NB: snapshots, while nice for debugging, are rarely used in production. BTW, beware of cloud providers who are offering snapshots (especially for free) – if your neighbor is making a snapshot, it may affect performance of your VMs.

[[To Be Continued…

This concludes beta Chapter 23(b) from the upcoming book “Development and Deployment of Multiplayer Online Games (from social games to MMOFPS, with social games in between)”.

Stay tuned for beta Chapter 23(c), where we’ll discuss the hardware which you need to run your game]]

Don't like this post? Comment↯ below. You do?! Please share:

Acknowledgement

Cartoons by Sergey Gordeev from Gordeev Animation Graphics, Prague.