I don t know for you. Maybe not. But this was our case and this was to tell you what we were doing.
Envoyé de mon iPhone Le 9 juil. 2009 à 18:09, kenvogt <[email protected]> a écrit : > > I don't want to appear ungrateful. Your comments have been very > helpful. What it comes down to here is that I will be required to use > SQS to make this work. > > On Jul 9, 8:50 am, Frédéric Sidler <[email protected]> wrot > e: >> Ken, I have to roles that do asynchronous jobs. They have no >> relation with >> the www role(s). They are based on the Base role and the main >> process they >> are doing is twisted. They check messages that the application sent >> to SQS >> to send notifications. These notification are eiter SMS, Jabber or >> email >> notifications based on user preferences. >> >> I think that with the ability to manage the load based on the size >> of the >> SQS queue it would be possible to manage it dynamically, but this >> has not >> been tested yet. >> >> Hope this helps. >> >> >> >> On Thu, Jul 9, 2009 at 5:08 PM, kenvogt <[email protected]> >> wrote: >> >>> I agree, doing it just because that's how we used to do it is not a >>> good idea. But that is not what I am talking about here. This >>> scenario >>> here is not just two servers that do the same thing. They are doing >>> very different things and they are doing more than one server can do >>> alone. Why even have a Base role if not for purposes other than www, >>> app, or mysql? Notice I said "purposes", not "purpose" as if there >>> could only be one possibility other than www, app, or mysql. >> >>> On Jul 9, 7:58 am, Donovan Bray <[email protected]> wrote: >>>> Just remember that every role you customize and change during a >>>> code >>>> push you will then have to synchronize. Synchronizing is painful >>>> in my >>>> experience particularly for your production environment. We find >>>> that >>>> syncronizing the www role leaves no load balancer at times, and >>>> for a >>>> period of up to two minutes both load balancers are in place >>>> causing >>>> undefined havoc. We find that app roles stick around after the new >>>> ones have started and the load balancers send traffic to both >>>> causing >>>> more havoc for a few minutes. So we've been working hard at writing >>>> scripts that run on init such that if we lose an instance and one >>>> is >>>> restarted it configures itself with the latest code, and obviates >>>> the >>>> need to synchronize each role when we do a code push. >> >>>> Our standard code pushes have been reduced from two hours to 30 >>>> minutes, and are much less error prone and less stressful. >> >>>> Our app role takes about 15 minutes to start and now have increased >>>> risk since a failure of the complex script could render that >>>> instance >>>> unuseable, but waiting for synchronizes to finish and their >>>> destabilizing effect was an untennable situation. >> >>>> On Jul 8, 2009, at 11:42 PM, Frédéric Sidler >> >>>> <[email protected]> wrote: >> >>>>> There is a 4th role you should consider for this purpose. This >>>>> is not >>>>> www, app or mysql role. >> >>>>> On Thursday, July 9, 2009, kenvogt <[email protected]> wrote: >> >>>>>> I need a farm with a database server, a web server, and two >>>>>> distinct >>>>>> application servers for backend processing. When I login to >>>>>> Scalr and >>>>>> go to build a new farm, select Shared Roles, then Application >>>>>> servers, >>>>>> it only allows me to check a box for a server type. I need two >>>>>> of the >>>>>> app64 however. This is not a scaling issue, the servers need to >>>>>> do >>>>>> different things. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "scalr-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/scalr-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
