On Mar 2, 2012, at 10:12 AM, William Herrin wrote:
> On Fri, Mar 2, 2012 at 1:03 AM, Owen DeLong wrote:
>> On Mar 1, 2012, at 9:34 PM, William Herrin wrote:
>>> You know, when I wrote 'socket=connect("www.google.com",80,TCP);' I
>>> stopped and thought to myself, "I wonder if I should change tha
On Mar 1, 2012, at 10:01 AM, Michael Thomas wrote:
> The real issue is that gethostbyxxx has been inadequate for a very
> long time. Moving it across the kernel boundary solves nothing and
> most likely causes even more trouble: what if I want, say, asynchronous
> name resolution? What if I want
On Fri, Mar 2, 2012 at 1:03 AM, Owen DeLong wrote:
> On Mar 1, 2012, at 9:34 PM, William Herrin wrote:
>> You know, when I wrote 'socket=connect("www.google.com",80,TCP);' I
>> stopped and thought to myself, "I wonder if I should change that to
>> 'connectbyname' instead just to make it clear that
In a message written on Thu, Mar 01, 2012 at 05:02:30PM -0800, Owen DeLong
wrote:
> Then push for better written abstraction libraries. There's no need to
> break the current functionality of the underlying system calls and
> libc functions which would be needed by any such library anyway.
Agree
On Mar 1, 2012, at 9:34 PM, William Herrin wrote:
> On Thu, Mar 1, 2012 at 8:47 PM, Owen DeLong wrote:
>> On Mar 1, 2012, at 5:15 PM, William Herrin wrote:
>>> On Thu, Mar 1, 2012 at 8:02 PM, Owen DeLong wrote:
There's no need to
break the current functionality of the underlying syste
On Thu, Mar 1, 2012 at 8:47 PM, Owen DeLong wrote:
> On Mar 1, 2012, at 5:15 PM, William Herrin wrote:
>> On Thu, Mar 1, 2012 at 8:02 PM, Owen DeLong wrote:
>>> There's no need to
>>> break the current functionality of the underlying system calls and
>>> libc functions which would be needed by an
In message <596196444196086313@unknownmsgid>, Matt Addison writes:
> On Mar 1, 2012, at 17:10, William Herrin wrote:
> > If took you 50 lines of code to do
> > 'socket=connect("www.google.com",80,TCP);' and you still managed to
> > produce a version which, due to the timeout on dead addresses, is
On Mar 1, 2012, at 17:10, William Herrin wrote:
> If took you 50 lines of code to do
> 'socket=connect("www.google.com",80,TCP);' and you still managed to
> produce a version which, due to the timeout on dead addresses, is
> worthless for any kind of interactive program like a web browser. And
> b
On Mar 1, 2012, at 5:15 PM, William Herrin wrote:
> On Thu, Mar 1, 2012 at 8:02 PM, Owen DeLong wrote:
>> There's no need to
>> break the current functionality of the underlying system calls and
>> libc functions which would be needed by any such library anyway.
>
> Owen,
>
> Point to one sent
On Thu, Mar 1, 2012 at 8:02 PM, Owen DeLong wrote:
> There's no need to
> break the current functionality of the underlying system calls and
> libc functions which would be needed by any such library anyway.
Owen,
Point to one sentence written by anybody in this entire thread in
which breaking c
On Mar 1, 2012, at 2:57 PM, William Herrin wrote:
> On Thu, Mar 1, 2012 at 5:37 PM, Owen DeLong wrote:
>> You don't have to reinvent what I've done. Neither does every
>> or any other application programmer.
>> You are welcome to use any of the many connection
>> abstraction libraries that are a
Randy Carpenter wrote:
Does anyone have any recommendation for a reliable cloud host?
Basic requirements:
1. Full redundancy with instant failover to other hypervisor hosts upon
hardware failure (I thought this was a given!)
Assuming a simple set up as you suggest. If what you want to do
On Thu, Mar 01, 2012 at 05:57:11PM -0500, William Herrin wrote:
> Which is what everybody basically does. And when it works during the
> decidedly non-rigorous testing, they move on to the next problem...
> with code that doesn't perform well in the corner cases. Such as when
> a host has just been
On Thu, Mar 1, 2012 at 5:37 PM, Owen DeLong wrote:
> You don't have to reinvent what I've done. Neither does every
> or any other application programmer.
> You are welcome to use any of the many connection
> abstraction libraries that are available in open source.
> I suggest you make a trip throu
On Mon, 27 Feb 2012, William Herrin wrote:
Why would you imagine that a $30/month virtual private server is built
on an enterprise-grade virtualization cluster?
A lot of the time "the cloud" is billed as just that.
The reality is that its more often a federated cluster of machines with
some d
William,
I could have done it in a lot less lines of code, but, it would have been much
less readable.
Not blocking on the connect() call is a little more complex, but, not terribly
so. It does, however, again, make the code quite a bit less readable.
There are libraries available that abstrac
In message
, William Herrin writes:
> On Thu, Mar 1, 2012 at 4:07 PM, Owen DeLong wrote:
> > I think that the modern set of getaddrinfo and connect is actually not th=
> at complicated:
>
> Owen,
>
> If took you 50 lines of code to do
> 'socket=connect("www.google.com",80,TCP);' and you still
On Thu, Mar 1, 2012 at 4:07 PM, Owen DeLong wrote:
> I think that the modern set of getaddrinfo and connect is actually not that
> complicated:
Owen,
If took you 50 lines of code to do
'socket=connect("www.google.com",80,TCP);' and you still managed to
produce a version which, due to the timeou
In message , Owen DeLong write
s:
> >=20
> > It's deeper than just that, though. The whole paradigm is messy, from
> > the point of view of someone who just wants to get stuff done. The
> > examples are (almost?) all fatally flawed. The code that actually =
> gets
> > at least some of it right
>
> It's deeper than just that, though. The whole paradigm is messy, from
> the point of view of someone who just wants to get stuff done. The
> examples are (almost?) all fatally flawed. The code that actually gets
> at least some of it right ends up being too complex and too hard for
> people
On Mar 1, 2012, at 6:26 AM, William Herrin wrote:
> On Thu, Mar 1, 2012 at 7:20 AM, Owen DeLong wrote:
>> The simpler approach and perfectly viable without mucking
>> up what is already implemented and working:
>>
>> Don't keep returns from GAI/GNI around longer than it takes
>> to cycle throug
than EC2, but their high touch features seems worthwhile. Live
support is included.
Rob
-Original Message-
From: Bobby Mac [mailto:bobby...@gmail.com]
Sent: Wednesday, February 29, 2012 1:24 PM
To: Tei
Cc: Nanog
Subject: Re: Reliable Cloud host ?
HP has built an Openstack based cloud. I
Jeroen,
On Mar 1, 2012, at 9:25 AM, Jeroen Massar wrote:
>> I always thought the right way to deal with IPv6 would have been to
>> use a 32-bit number from the class E space as a 'network handle'
>> where the actual address (be it IPv4 or IPv6) was handled by the
>> kernel.
>
> This is the case w
Michael,
On Mar 1, 2012, at 10:00 AM, Michael Thomas wrote:
> My rule of thumb is for this sort of thing "does it *require* kernel level
> access?"
> In this case, the answer is manifestly "no".
This is tilting at windmills since it's wildly unlikely anything will change,
but...
The idea is to
On Thu, Mar 1, 2012 at 1:32 PM, Michael Thomas wrote:
> On 03/01/2012 08:58 AM, William Herrin wrote:
>> libc != kernel. I want to move the action into the standard libraries
>> where [resolve and connect] can be done once and done well.
>> A little kernel action on top
>> to parallelize connectio
On 03/01/2012 08:58 AM, William Herrin wrote:
On Thu, Mar 1, 2012 at 10:01 AM, Michael Thomas wrote:
On 03/01/2012 06:26 AM, William Herrin wrote:
The even simpler approach: create an AF_NAME with a sockaddr struct
that contains a hostname instead of an IPvX address. Then let
connect() figure
On 03/01/2012 08:57 AM, David Conrad wrote:
Moving it across the kernel boundary solves nothing
Actually, it does. Right now, applications effectively cache the address in
their data space, requiring the application developer to go to quite a bit of
work to deal with the address changing (o
On 2012-03-01 17:57 , David Conrad wrote:
> Hi,
>
> On Mar 1, 2012, at 7:22 AM, Joe Greco wrote:
>> On Mar 1, 2012, at 7:01 AM, Michael Thomas wrote:
>>> The effect of what you're recommending is to move all of this
>>> into the kernel, and in the process greatly expand its scope.
>>> Also: even
Hi,
On Mar 1, 2012, at 7:22 AM, Joe Greco wrote:
> On Mar 1, 2012, at 7:01 AM, Michael Thomas wrote:
>> The effect of what you're recommending is to move all of this
>> into the kernel, and in the process greatly expand its scope. Also:
>> even if you did this, you'd be saddled with the same probl
On Thu, Mar 1, 2012 at 10:01 AM, Michael Thomas wrote:
> On 03/01/2012 06:26 AM, William Herrin wrote:
>> The even simpler approach: create an AF_NAME with a sockaddr struct
>> that contains a hostname instead of an IPvX address. Then let
>> connect() figure out the details of caching, TTLs, proto
On 03/01/2012 07:22 AM, Joe Greco wrote:
It's deeper than just that, though. The whole paradigm is messy, from
the point of view of someone who just wants to get stuff done. The
examples are (almost?) all fatally flawed. The code that actually gets
at least some of it right ends up being too c
> On 03/01/2012 06:26 AM, William Herrin wrote:
> > On Thu, Mar 1, 2012 at 7:20 AM, Owen DeLong wrote:
> >> The simpler approach and perfectly viable without mucking
> >> up what is already implemented and working:
> >>
> >> Don't keep returns from GAI/GNI around longer than it takes
> >> to cycle
On 03/01/2012 06:26 AM, William Herrin wrote:
On Thu, Mar 1, 2012 at 7:20 AM, Owen DeLong wrote:
The simpler approach and perfectly viable without mucking
up what is already implemented and working:
Don't keep returns from GAI/GNI around longer than it takes
to cycle through your connect() loo
> On Thu, Mar 1, 2012 at 8:25 AM, Joe Greco wrote:
> > "If three people died and the building burned down then the sprinkler
> > system didn't work. It may have sprayed water, but it didn't *work*."
> >
> > That's not true. =A0If it sprayed water in the manner it was designed to,
> > then it worke
On Thu, Mar 1, 2012 at 8:25 AM, Joe Greco wrote:
> "If three people died and the building burned down then the sprinkler
> system didn't work. It may have sprayed water, but it didn't *work*."
>
> That's not true. If it sprayed water in the manner it was designed to,
> then it worked.
That's lik
On Thu, Mar 1, 2012 at 7:20 AM, Owen DeLong wrote:
> The simpler approach and perfectly viable without mucking
> up what is already implemented and working:
>
> Don't keep returns from GAI/GNI around longer than it takes
> to cycle through your connect() loop immediately after the GAI/GNI call.
T
>
> On Wed, Feb 29, 2012 at 4:02 PM, Joe Greco wrote:
> > In the specific case of TTL, the problem is made much worse due to the
> > way most client code has hidden this data from developers, so that many
> > developers don't even have any idea that such a thing exists.
> >
> > I'm not sure how t
On Feb 29, 2012, at 10:15 PM, Jimmy Hess wrote:
> On Mon, Feb 27, 2012 at 10:57 PM, Matt Addison
> wrote:
>> gai/gni do not return TTL values on any platforms I'm aware of, the
>> only way to get TTL currently is to use a non standard resolver (e.g.
>> lwres). The issue is application developers
> GAI/GNI do not return TTL values, but this should not be a problem.
> If they were to return anything, it should not be a TTL, but a time()
> value, after which the result may no longer be used.
>
> One way to achieve that would be for GAI to return an opaque structure
> that contained the IP an
On Mon, Feb 27, 2012 at 7:03 PM, George Herbert
wrote:
> On Mon, Feb 27, 2012 at 3:45 PM, William Herrin wrote:
>> universe does $30/mo per customer recover that cost during the useful
>> life of the equipment?
> As I stated, one can either do it with SANs or with alternate storage.
Should not a
On Mon, Feb 27, 2012 at 10:57 PM, Matt Addison
wrote:
> gai/gni do not return TTL values on any platforms I'm aware of, the
> only way to get TTL currently is to use a non standard resolver (e.g.
> lwres). The issue is application developers not calling gai every time
GAI/GNI do not return TTL va
HP has built an Openstack based cloud. I got a beta account and things are
surprisingly stable.
hpcloud dot com
On Wed, Feb 29, 2012 at 1:12 PM, Tei wrote:
> related to the topic:
>
> http://slashdot.org/story/12/02/29/153226/microsofts-azure-cloud-suffers-major-downtime
>
> --
> --
> ℱin del ℳ
On Wed, Feb 29, 2012 at 4:02 PM, Joe Greco wrote:
> In the specific case of TTL, the problem is made much worse due to the
> way most client code has hidden this data from developers, so that many
> developers don't even have any idea that such a thing exists.
>
> I'm not sure how to see that a de
> On Wed, Feb 29, 2012 at 7:57 AM, Joe Greco wrote:
> >> In message
> >> ,
> >> ?William Herrin writes:
> >> > On Tue, Feb 28, 2012 at 4:06 PM, Mark Andrews wrote:
> >> > > DNS TTL works. =A0Applications that don't honour it arn't a indication
> >> > > th=
> >> > at
> >> > > it doesn't work.
>
On 2/29/2012 1:38 PM, Robert Hajime Lanning wrote:
> On 02/29/12 10:01, Owen DeLong wrote:
>> Further, DNS performance issues in the past have led developers of
>> such applications to "take matters into their own hands" to try and
>> improve the performance/behavior of their application in spite o
related to the topic:
http://slashdot.org/story/12/02/29/153226/microsofts-azure-cloud-suffers-major-downtime
--
--
ℱin del ℳensaje.
On 02/29/12 10:01, Owen DeLong wrote:
Further, DNS performance issues in the past have led developers of
such applications to "take matters into their own hands" to try and
improve the performance/behavior of their application in spite of
DNS. This is one of the things that led to many of the TTL
On Feb 29, 2012, at 6:18 AM, William Herrin wrote:
> On Wed, Feb 29, 2012 at 7:57 AM, Joe Greco wrote:
>>> In message
>>> ,
>>> William Herrin writes:
On Tue, Feb 28, 2012 at 4:06 PM, Mark Andrews wrote:
> DNS TTL works. =A0Applications that don't honour it arn't a indication th=
>>>
On Wed, Feb 29, 2012 at 7:57 AM, Joe Greco wrote:
>> In message
>> ,
>> William Herrin writes:
>> > On Tue, Feb 28, 2012 at 4:06 PM, Mark Andrews wrote:
>> > > DNS TTL works. =A0Applications that don't honour it arn't a indication
>> > > th=
>> > at
>> > > it doesn't work.
>> >
>> > Mark,
>> >
> In message
> ,
> William Herrin writes:
> > On Tue, Feb 28, 2012 at 4:06 PM, Mark Andrews wrote:
> > > DNS TTL works. =A0Applications that don't honour it arn't a indication th=
> > at
> > > it doesn't work.
> >
> > Mark,
> >
> > If three people died and the building burned down then the spr
In message ,
William Herrin writes:
> On Tue, Feb 28, 2012 at 4:06 PM, Mark Andrews wrote:
> > DNS TTL works. =A0Applications that don't honour it arn't a indication th=
> at
> > it doesn't work.
>
> Mark,
>
> If three people died and the building burned down then the sprinkler
> system didn't
On Tue, Feb 28, 2012 at 4:06 PM, Mark Andrews wrote:
> DNS TTL works. Applications that don't honour it arn't a indication that
> it doesn't work.
Mark,
If three people died and the building burned down then the sprinkler
system didn't work. It may have sprayed water, but it didn't *work*.
Reg
In message ,
William Herrin writes:
> On Tue, Feb 28, 2012 at 12:45 AM, Mark Andrews wrote:
> >getaddrinfo was designed to be extensible as was struct
> >addrinfo. Part of the problem with TTL is not [all] dat=
> a sources
> >used by getaddrinfo have TTL information.
>
On Tue, 28 Feb 2012, Owen DeLong wrote:
But they don't have to... They can simply use getaddrinfo()/getnameinfo()
and let the OS libraries do it. The fact that some applications choose to
use their own resolvers instead of system libraries is what is broken.
Not always true - firewall software
On Feb 28, 2012, at 10:22 AM, William Herrin wrote:
> On Tue, Feb 28, 2012 at 9:02 AM, Jared Mauch wrote:
>> On Feb 27, 2012, at 2:53 PM, valdis.kletni...@vt.edu wrote:
>>> On Mon, 27 Feb 2012 14:02:04 EST, William Herrin said:
>>>
The net result is that when you switch the IP address of y
On Tue, 28 Feb 2012 09:02:00 EST, Jared Mauch said:
> Sometimes you have to break the service worse for people to repair it.
I broke it a decade ago, I think I can pretty much give up on expecting people
to
repair it. :)
pgpBAyxDj9y8X.pgp
Description: PGP signature
On Tue, Feb 28, 2012 at 9:02 AM, Jared Mauch wrote:
> On Feb 27, 2012, at 2:53 PM, valdis.kletni...@vt.edu wrote:
>> On Mon, 27 Feb 2012 14:02:04 EST, William Herrin said:
>>
>>> The net result is that when you switch the IP address of your server,
>>> a percentage of your users (declining over ti
On Feb 27, 2012, at 2:53 PM, valdis.kletni...@vt.edu wrote:
> On Mon, 27 Feb 2012 14:02:04 EST, William Herrin said:
>
>> The net result is that when you switch the IP address of your server,
>> a percentage of your users (declining over time) will be unable to
>> access it for hours, days, week
On Tue, Feb 28, 2012 at 12:45 AM, Mark Andrews wrote:
> getaddrinfo was designed to be extensible as was struct
> addrinfo. Part of the problem with TTL is not [all] data sources
> used by getaddrinfo have TTL information.
Hi Mark,
By the time getaddrinfo replaced gethostby
On Feb 27, 2012, at 9:45 PM, Mark Andrews wrote:
>
> getaddrinfo was designed to be extensible as was struct
> addrinfo. Part of the problem with TTL is not data sources
> used by getaddrinfo have TTL information. Additionally for
> many uses you want to reconnect to th
getaddrinfo was designed to be extensible as was struct
addrinfo. Part of the problem with TTL is not data sources
used by getaddrinfo have TTL information. Additionally for
many uses you want to reconnect to the same server rather
than the same name. Not
On Feb 27, 2012, at 19:10, Owen DeLong wrote:
>
> On Feb 27, 2012, at 3:50 PM, William Herrin wrote:
>
>> On Mon, Feb 27, 2012 at 3:43 PM, david raistrick
>> wrote:
>>> On Mon, 27 Feb 2012, William Herrin wrote:
In some cases this is because of carelessness: The application does a
get
On Sun, Feb 26, 2012 at 4:56 PM, Randy Carpenter wrote:
> We have been using Rackspace Cloud Servers. We just realized that
> they have absolutely no redundancy or failover after experiencing a
> outage that lasted more than 6 hours yesterday. I am appalled that
> they would offer something calle
In message ,
William Herrin writes:
> On Mon, Feb 27, 2012 at 3:43 PM, david raistrick wro=
> te:
> > On Mon, 27 Feb 2012, William Herrin wrote:
> >> In some cases this is because of carelessness: The application does a
> >> gethostbyname once when it starts, grabs the first IP address in the
>
On Mon, Feb 27, 2012 at 4:59 PM, William Herrin wrote:
>
> Yes, well, that's why we're still using a layer 4 protocol (TCP) that
> can't dynamically rebind to the protocol level below (IP).
This is somewhat irritating, but on the scale of 0 (all is well) to 10
(you want me to do WHAT with DH
On Mon, Feb 27, 2012 at 3:45 PM, William Herrin wrote:
> On Mon, Feb 27, 2012 at 2:19 PM, George Herbert
> wrote:
>> Failing to have central shared storage (iSCSI, NAS, SAN, whatever you
>> prefer) fails the smell test on a local enterprise-grade
>> virtualization cluster, much less a shared clou
On Mon, Feb 27, 2012 at 7:07 PM, Owen DeLong wrote:
> On Feb 27, 2012, at 3:50 PM, William Herrin wrote:
>> Meh. What should be fixed is that connect() should receive a name
>> instead of an IP address. Having an application deal directly with the
>> IP address should be the exception rather than
On Feb 27, 2012, at 3:50 PM, William Herrin wrote:
> On Mon, Feb 27, 2012 at 3:43 PM, david raistrick wrote:
>> On Mon, 27 Feb 2012, William Herrin wrote:
>>> In some cases this is because of carelessness: The application does a
>>> gethostbyname once when it starts, grabs the first IP address i
On Mon, Feb 27, 2012 at 3:43 PM, david raistrick wrote:
> On Mon, 27 Feb 2012, William Herrin wrote:
>> In some cases this is because of carelessness: The application does a
>> gethostbyname once when it starts, grabs the first IP address in the
>> list and retains it indefinitely. The gethostbyna
On Mon, Feb 27, 2012 at 2:19 PM, George Herbert
wrote:
> Failing to have central shared storage (iSCSI, NAS, SAN, whatever you
> prefer) fails the smell test on a local enterprise-grade
> virtualization cluster, much less a shared cloud service.
Hi George,
Why would you imagine that a $30/month
On Mon, Feb 27, 2012 at 11:19:27AM -0800, George Herbert wrote:
> On Mon, Feb 27, 2012 at 7:28 AM, William Herrin wrote:
> > On Sun, Feb 26, 2012 at 7:02 PM, Randy Carpenter
> > wrote:
> >>> On Feb 26, 2012, at 4:56 PM, Randy Carpenter wrote:
> >>> > 1. Full redundancy with instant failover to o
On Mon, 27 Feb 2012, William Herrin wrote:
In some cases this is because of carelessness: The application does a
gethostbyname once when it starts, grabs the first IP address in the
list and retains it indefinitely. The gethostbyname function doesn't
even pass the TTL to the application. Ntpd is
On Mon, 27 Feb 2012, William Herrin wrote:
In some cases this is because of carelessness: The application does a
gethostbyname once when it starts, grabs the first IP address in the
list and retains it indefinitely. The gethostbyname function doesn't
even pass the TTL to the application. Ntpd is
On Mon, 27 Feb 2012 14:02:04 EST, William Herrin said:
> The net result is that when you switch the IP address of your server,
> a percentage of your users (declining over time) will be unable to
> access it for hours, days, weeks or even years regardless of the DNS
> TTL setting.
Amen brother.
On Mon, Feb 27, 2012 at 7:28 AM, William Herrin wrote:
> On Sun, Feb 26, 2012 at 7:02 PM, Randy Carpenter wrote:
>>> On Feb 26, 2012, at 4:56 PM, Randy Carpenter wrote:
>>> > 1. Full redundancy with instant failover to other hypervisor hosts
>>> > upon hardware failure (I thought this was a given
On Mon, Feb 27, 2012 at 12:09 PM, Jared Mauch wrote:
> On Feb 27, 2012, at 10:28 AM, William Herrin wrote:
>> How DNS is designed to work and how it actually works is not the same.
>> Look up "DNS Pinning" for example. For most kinds of DR you need IP
>> level failover where the IP address is rero
> Pardon the weird question:
>
> Is the DNS service authoritative or recursive? If auth, you can
> solve this a few ways, either by giving the DNS name people point to
> multiple (and A) records pointing at a diverse set of
> instances.
Authoritative. But, also not the only thing that we a
On Feb 27, 2012, at 10:28 AM, William Herrin wrote:
> On Mon, Feb 27, 2012 at 9:39 AM, Jared Mauch wrote:
>> Is the DNS service authoritative or recursive? If auth, you can
>> solve this a few ways, either by giving the DNS name people
>> point to multiple (and A) records pointing at a div
On 2/27/2012 10:25 AM, Jason Gurtz wrote:
>> [...] For DNS,
>> EasyDNS (https://web.easydns.com/DNS_hosting.php) are rather good and
>> not too expensive, and you can get a 100% up-time guarantee if you
>> want. A review of them regarding availability is at
>> http://www.theregister.co.uk/2012/01
On Sun, Feb 26, 2012 at 7:02 PM, Randy Carpenter wrote:
>> On Feb 26, 2012, at 4:56 PM, Randy Carpenter wrote:
>> > 1. Full redundancy with instant failover to other hypervisor hosts
>> > upon hardware failure (I thought this was a given!)
>>
>> This is actually a much harder problem to solve than
> [...] For DNS,
> EasyDNS (https://web.easydns.com/DNS_hosting.php) are rather good and
> not too expensive, and you can get a 100% up-time guarantee if you
> want. A review of them regarding availability is at
> http://www.theregister.co.uk/2012/01/31/why_i_use_easydns/
I have been a very sati
On Feb 26, 2012, at 5:56 PM, Randy Carpenter wrote:
> We require 1 or 2 very small virtual hosts to host some remote services to
> serve as backup to our main datacenter. One of these services is a DNS
> server, so it is important that it is up all the time.
>
> We have been using Rackspace Cl
instances as well.
Max
On 2/26/12, Randy Carpenter wrote:
>
>
> Does anyone have any recommendation for a reliable cloud host?
>
> We require 1 or 2 very small virtual hosts to host some remote services to
> serve as backup to our main datacenter. One of these services is a DNS
Hello,
On Sun, Feb 26, 2012 at 10:56 PM, Randy Carpenter wrote:
>
>
>
> Does anyone have any recommendation for a reliable cloud host?
>
> We require 1 or 2 very small virtual hosts to host some remote services to
> serve as backup to our main datacenter. One of th
> -Original Message-
> From: Tony Patti [mailto:t...@swalter.com]
> Sent: 27 February 2012 02:42
> To: 'david raistrick'; 'Randy Carpenter'
> Cc: 'Nanog'
> Subject: RE: Reliable Cloud host ?
>
> > -Original Message-
> &g
> -Original Message-
> From: david raistrick [mailto:dr...@icantclick.org]
> Sent: Sunday, February 26, 2012 7:19 PM
> To: Randy Carpenter
> Cc: Nanog
> Subject: Re: Reliable Cloud host ?
>
> On Sun, 26 Feb 2012, Randy Carpenter wrote:
>
> > I don'
On Sun, 26 Feb 2012, Randy Carpenter wrote:
This does not have to be true at all. Even having a fully
fault-tolerant SAN in addition to spare servers should not cost much
more than having separate RAID arrays inside each of the server, when
you are talking about 1,000s of server (which Racksp
On Sun, 26 Feb 2012, Randy Carpenter wrote:
I don't need that kind of HA, and understand that it is not going to be
available. 15 minutes of downtime is fine. 6 hours is completely
unacceptable, and it false advertising to say you have a "Cloud"
service, and then have the realization that you
- Original Message -
>
> On Feb 26, 2012, at 4:56 PM, Randy Carpenter wrote:
> > We have been using Rackspace Cloud Servers. We just realized that
> > they have absolutely no redundancy or failover after experiencing
> > a outage that lasted more than 6 hours yesterday. I am appalled
> >
.
- Mike
On Feb 26, 2012, at 2:56 PM, Randy Carpenter wrote:
>
>
> Does anyone have any recommendation for a reliable cloud host?
>
> We require 1 or 2 very small virtual hosts to host some remote services to
> serve as backup to our main datacenter. One of these services is a DN
On 2/26/2012 6:04 PM, Mike Lyon wrote:
> Godaddy? Servint.com? Amazon EC2?
>
> -mike
>
> Sent from my iPhone
>
> On Feb 26, 2012, at 12:57, Randy Carpenter wrote:
>
>>
>> Does anyone have any recommendation for a reliable cloud host?
>>
>> We requ
On Feb 26, 2012, at 4:56 PM, Randy Carpenter wrote:
> We have been using Rackspace Cloud Servers. We just realized that they have
> absolutely no redundancy or failover after experiencing a outage that lasted
> more than 6 hours yesterday. I am appalled that they would offer something
> called
Godaddy? Servint.com? Amazon EC2?
-mike
Sent from my iPhone
On Feb 26, 2012, at 12:57, Randy Carpenter wrote:
>
>
> Does anyone have any recommendation for a reliable cloud host?
>
> We require 1 or 2 very small virtual hosts to host some remote services to
> serve as
Does anyone have any recommendation for a reliable cloud host?
We require 1 or 2 very small virtual hosts to host some remote services to
serve as backup to our main datacenter. One of these services is a DNS server,
so it is important that it is up all the time.
We have been using Rackspace
94 matches
Mail list logo
