With a physical server environment, is it advisable to live in the same major city as the data center, even if there are better data center options halfway across the country?

Hosting and bandwidth costs, incident response time and ongoing travel costs are primary concerns. Uptime is important, but we could endure a half-day data-center outage once a year or so.

I am planning a data center application deployment with roughly a dozen physical Linux hosts (with more to come) each with defined roles of database server using local storage, or standby database server, or application server. The machines will share a VLAN and utilize some DAS second-line storage for archival. There is no virtualization planned except possibly for a few standby roles which would greatly under-utilize a physical machine.

The nearby and far-remote data center both offer paid engineering support. I can't determine at this time how well the engineers would know our specific architecture in a problem situation. Assuming a long mean time between emergencies, I'm guessing they would not be that familiar, or even the same persons.

I have managed remote servers with isolated roles, always hosted outside of data centers for many years, and would be comfortable never seeing the machines after install. My question comes from listening to a StackExchange podcast, where physical network hardware became intermittently slow under load from rapidly communicating servers, requiring extensive debugging over an extended period. High-end network hardware is outside my current experience, is this type of troubleshooting practical from a remote connection, or is it common to need to go onsite when that happens?

To sum up, how much benefit is obtained from living near a good data center in a major city when starting up a deployment like this? Does it outweigh the benefits of a better/best data center in an even larger city?

Thank you for sharing your experiences in this area.



Ultimately you know your business and priorities much better than we do; thus only you can evaluate the tradeoffs. If it was me, I would certainly not have one of my servers any farther than 3 hours from me, but that's because I can't justify paying $80/hr for onsite hands. Then again, if you knew that you'd save enough (call it 20% in hosting costs), and you are confident that you wouldn't burn as much in remote-hands, then you have your answer.

I will say that a serial term server connected to each server's serial console solves many ills, and it is well worth having if you do something to a box and it goes tango-uniform on you...

Serial access, a couple of strategically-placed webcams, and hyper-detailed installation docs and cable/device labeling could make a remote-hosting situation attractive to the right company.

All this assumes that your basic facilities concerns (reliability, power, HVAC, backup, earthquake, flood, etc...) are equal or better in the remote facility.

|improve this answer|||||

I think you'll have to look at it from a commercial point of view. If bandwidth costs are so much lower elsewhere, and they will form the majority of your COGS, then why not?

Remote hands costs aren't really normally so high that you want to send engineers out, particularly with such a small infrastructure that you're proposing (If you need to install or upgrade 50 boxes, it might be cost effective to send an engineer)

You could of course, actually think about the customer instead. Who is the customer? Are they going to be affected by latency?

If you have a regionally biased web site, it seems like a good idea to host it close to the region to get best latency - but on the other hand, latency might be fairly acceptable if it's on the same continent as the majority of your users (hint: Do not use APAC hosts if your users are in N America or Europe!)

|improve this answer|||||

First off - a couple assumptions I'm making here about your needs. I'm assuming that an EC2 type public cloud is not a viable approach, and that your application would not perform well split across two datacenters. There are some significant advantages to not being tied to a single datacenter, and also some significant costs. Without knowing more about your application, I can't say which would be more relevant, but something to keep in mind - if you have the option of failing over to another datacenter, weird problems that take time to troubleshoot are less of a showstopper.

It heavily depends on the providers involved and the level of support they provide. I deal with three datacenters at work: an onside datacenter in our building and two managed hosting sites, each from different providers. Both managed hosting providers are "big names".

The difference between the support we get at each place is night and day. The remote site that's nearby is more of a pain to deal with than the site on the other side of the US, and it's ALL in the providers and levels of support. I realize you asked about colo, not managed hosting, but I still think it's relevant. Basic remote hands are not something you want to try to troubleshoot anything more complicated than "reboot the server" with. Good datacenter engineers, on the other hand, are going to handle complex issues much better. And with similar levels of support on paper, these two providers are VERY different in practice.

Regardless of who you host with, if you choose an architecture the staff is familiar with you will get better support. Period. That's why most managed colo providers have specific distros, etc, they support. Of course, no one is going to support, or know, your application itself. That's not their department, it's yours. The datacenter's job is to provide a platform and keep that platform working. If there are weird network problems under load they are the ones who need to fix it regardless of where you are.

Much of this is written from the perspective of managed hosting. If you truly need managed colocation - and I'd be surprised if you do - the lines of who supports what might be different and you need to pay careful attention to those terms. For what you are describing, managed hosting, with dedicated servers, sounds like a better fit. That gives you much more ability to scale and much less to worry about or have to troubleshoot yourself. You're not a high end networking hardware expert. Why should you be, with this sort of deployment? Let the datacenter take care of that part so you can focus on the application you're deploying.

And, finally, the most important thing is the specific providers involved. Talk to other customers of theirs. If you can, start slow and feel out how they actually perform.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.