At $lastjob we had a small buildout (under 20 physical servers, under 20 vm's) using the Rackspace "RackConnect" product which connects their public cloud to your dedicated infrastructure. We had similar issues as you did with the backend networking (eg: ServiceNet, which in a RackConnect setup all vm traffic transits in order to get to your firewall for egress as well as to get to dedicated services). Every issue we reported was taken very seriously by support as well as our account team but the process of fixing the problem required a lot of coordination to ensure that things were communicated clearly, and the the right people were consistently being engaged to address the issue.
As a corollary to Tom's point that outsourcing turns your job into quality control, managing the relationship with your outsourcing vendor becomes a base tool in the quality control process and is more important than managing the relationship with the person you buy servers from. This is doubly so if you tickle edge-cases with your vendor and need to diver deeper than "it's bustificated, reboot it." -n On Sat, Jan 11, 2014 at 7:29 AM, Edward Ned Harvey (lopser) <lop...@nedharvey.com> wrote: >> From: tech-boun...@lists.lopsa.org [mailto:tech-boun...@lists.lopsa.org] >> On Behalf Of Andrew Hume >> >> we've tried this on SIlverLining (an AT&T cloud) and RackSpace, with > > I can't comment on silverlining, but I can say about rackspace: They are > both clueless, ignorant, and stubbornly idiotic about their network > architecture. > > I have a long story, which I'll shorten as such: A client that I provide IT > service to is a web hosting company. They were hosted at rackspace, and they > were having intermittent reliability problems. I installed a bunch of > monitoring software, and spent a bunch of time digging into it, and concluded > that the storage network is lossy. I opened several support tickets with > rackspace, and after a whole lot of chest thumping, (as well as referring to > the phrase "fanatical support" for the purpose of undermining the credibility > of my complaint, the irony of which does not escape me) ... And after me > showing and proving... They still deny any such problem. The main > justification is that "You're the only one complaining," which is another way > of saying "You're the only one with the combination of knowledge and > willingness to dig in and find it." So we stopped using rackspace. > > Side note. One of the systems is a legacy system in place for a legacy > nonpaying customer, where mgmt decides, we leave the server turned on, but > use bare minimum effort to support it. Once in a while, something goes wrong > in drupal, so another admin decides, the way to handle it is to reboot the > server via cron. It works for a few days, and then we get the cron failure > email alert "/sbin/shutdown: command not found." ;-) Which *really* > demonstrates the fault of the storage system. But RS didn't want to hear any > of that. Can't reproduce it when we look at it together, it's a non-issue. > Happens only when a person isn't looking. Only detectable by a machine > monitoring. pfffft. heheheheh... Anyway, I hate rackspace, as you might > have noticed. > _______________________________________________ > Tech mailing list > Tech@lists.lopsa.org > https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech > This list provided by the League of Professional System Administrators > http://lopsa.org/ -- ------------------------------------------- nathan hruby <nhr...@gmail.com> metaphysically wrinkle-free ------------------------------------------- _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
