[development] No suitable nodes available at RackspaceCloud (Mosso)

[Matt Chapman]

Anyone who buys hosting without shell access is gonna get what they pay for...

However, I do want to draw attention to the fact that the CloudSITES
services is being discussed here. I have been using the Rackspace
CloudSERVERS (similar to Amazon EC2, in concept) offering for a few
months now, and I love it. It has not been plagued by the recent
security issues, or any of the complaints I head about
CloudSites/Mosso.

My only problem has been a corrupted backup on one occasion, so as
always, never trust someone else's backup of your data. That applies
to any hosting service, so I highly recommend Rackspace CloudServers.

All the Best,

Matt Chapman
Ninjitsu Web Development

--
The contents of this message should be assumed to be Confidential, and
may not be disclosed without permission of the sender.



On Thu, Feb 18, 2010 at 8:38 AM, Tomáš Fülöpp (vacilando.org)
<tomi at vacilando.org> wrote:
> (Interesting, Brian; I also were promised shell pretty soon about a year
> ago. It's a shame - MediaTemple has shell and also a breakdown of compute
> cycles per script...)
>
> Anyway -- Victor's note about shortening PHP timeout brought me to thinking
> about measuring the time since the start of the execution and issuing
> flush() each time the process might time out.
>
> Two questions:
>
> what is the most suitable Drupal function for this -- it needs to be
> something that runs regularly and for all kind of pages
> for Drupal, is it enough to issue flush() or is ob_end_flush() also needed,
> or something else
>
> Thanks a million for any ideas;
>
> Tomáš / Vacilando
>
>
>
> On Thu, Feb 18, 2010 at 15:46, Brian Vuyk <brian at brianvuyk.com> wrote:
>>
>> I've run into this with a few of my client sites, but they haven't even
>> been high-traffic sites.
>>
>> Personally, I just don't think the RS Cloud is a good match for Drupal.
>> Combine that with the recent security issues they've had, occasional
>> inexplicable downtime, the 'no suitable nodes' and the lack of a shell, and
>> I am moving my sites away as quick as I can.
>>
>> The shell issue is really sensitive for me - about 14 months ago, my
>> previous host ran into... issues... and could no longer offer hosting. So, I
>> was in a pinch and Rackspace (then Mosso) looked very good apart from the
>> lack of a shell. I talked to their customer service reps, and was informed
>> that shell access for the cloud was in pre-release testing, and was
>> scheduled to go live the next week.
>>
>> In a burst of poor judgement, I decided that the package they offered was
>> good enough to do without shell access for a week, so I bought in, and
>> transferred my sites. 14 months later, shell access still hasn't been
>> released, and I've had to move all my more critical  / development-intensive
>> sites off of their service in the meantime.
>>
>> Brian
>>
>>
>>
>> Tomáš Fülöpp (vacilando.org) wrote:
>>
>> Hi,
>>
>> At RackspaceCloud (former Mosso) I've been plagued with a very unfortunate
>> problem that i crippling both my work and the work of my clients -- namely
>> the infamous error message "Unfortunately there were no suitable nodes
>> available to serve this request." Those of you at RS Cloud must have bumped
>> into it. It is cryptic and happens unpredictably. The cloud is very stable
>> and scalable, but for any a little bit heavier Drupal installation people do
>> start getting these errors.
>>
>> Basically, it is a generic error thrown by load balanced systems that
>> occurs as a result of a script exceeding a maximum timeout value (not the
>> PHP timeout value!) If a client connection does not receive a response from
>> the server after approximately 30 to 60 seconds the load balancer will close
>> the connection and the client will immediately receive the error message. In
>> most cases, the script will continue to execute until it reaches completion,
>> throws an error, or times out on the server, but the client will not see the
>> page load as expected and will instead receive this error.
>>
>> I've used Boost for anonymous pages, Parallel, Memcache, etc., all of
>> which helped and anonymous users usually don't get this error. The problem
>> is with admin or any other a bit heavier work of logged in users. Even for
>> basic Drupal websites with not too many modules! Pages like the list of
>> modules, or the status page, i.e. heavy database or file requests, or API
>> calls in PHP, are very likely to time out.
>>
>> Over the past year I've had a number of discussions with techs and admins
>> at that cloud, but the situation is unresolved. They recognize the problem
>> but maintain this is due to the special/unusual setup they use for their
>> cloud. It is not a problem for some other CMS / frameworks. E.g. a very
>> heavy MediaWiki installation runs just fine. Drupal seems to be less
>> compatible with their system, somehow, somewhere.
>>
>> Now, why do I mention all this in the development list? I've been
>> intrigued by one little ray of hope in their words: "if a client connection
>> does not receive a response from the server after approximately 30 to 60
>> seconds the load balancer will close the connection and the client will
>> immediately receive the error message". Their techs said if I were able to
>> emit any kind of intermediary response to the client during rendering of the
>> page, then this would be solved.
>> Indeed, a bit like the Batch API works in Drupal (with that I often run
>> night-long scripts without problems). I wonder, maybe this is a more generic
>> problem for any system that employs load balancers?
>>
>> So my questions to you, colleagues, is -- do you see any place in Drupal
>> processing chain that could be used, and approximately how, to make sure
>> that the load balancer keeps the connection opened. If you have any ideas,
>> wild or proven, I will be happy to test and develop them further and bring
>> them back to the community, of course. If this succeeds, I think many of us
>> will be relieved (and able to focus on development again!)
>>
>> Thank you for any ideas - on and off this list.
>>
>> Best regards,
>>
>> Tomáš / Vacilando
>>
>>
>
>