I'll be there!! I've built an image at Rackspace - using FathomDB as the mysql service. Working good so far, but this is just preliminary right now.
Ken On Aug 4, 2010, at 4:43 PM, Kieran Kelleher wrote: > So the AWS calculator indicates about $2200 a month for one "Large Multi-AZ > 100%" RDS and 3 "Extra Large 100%" EC2 instances. Does that sound about right > or would you expect it to be much less than that? > > Or, if you prefer you can enlighten me more over a beer at WOWODC - are you > going to the upcoming WOWODC? > > Regards, Kieran > > On Aug 4, 2010, at 7:18 AM, Simon wrote: > >> yes, we run our production servers 24/7. at the moment we run our staging >> and build servers 24/7 as well, but we are going to stop that shortly by >> writing a quartz job based on the ec2 api to boot and shutdown >> non-production instances automatically so they run 8am-8pm instead of 24/7 >> >> simon >> >> On 4 August 2010 10:12, Marius Soutier <m.sout...@starhealthcare.info> wrote: >> So are you using your EC2 instances 24/7? Do you use on-demand instances or >> reserved ones? EC2 seems ridiculously cheap as long as you start instances >> only when you need them, but for permanent usage I'm not sure yet. >> >> - Marius >> >> On 03.08.2010, at 14:28, Simon wrote: >> >>> we run a db.m1.large instance and our db is around 20GB. previously it ran >>> on an intel xserve with 8GB of Ram. performance wise db.m1.large is around >>> where we were before, but we've not been scientific about this because we >>> didn't have any performance issues before, and we don't have any now. we >>> didn't move to RDS for performance. >>> >>> however, when staging the move we initially ran a db.m1.small instance and >>> that was nowhere near powerful enough. when we boot copies of production >>> for testing purposes we use db.m1.small, but we wouldn't use that in >>> production. >>> >>> the real beauty of RDS with regard to performance is that is its literally >>> a couple of clicks to upgrade. how long do you think it will take you to >>> transition your DB to that a linux raid server ? we could double our >>> compute power and ram in literally 3 clicks and a couple of minutes - and >>> because we run with multi-avail zone it would automatically fail over to >>> the slave whilst the upgrade took place. >>> >>> we don't use ssl. traffic is limited to our ec instances, and yes sensitive >>> data is encrypted in the db anyway. we've just flown through PCIDSS >>> compliance without a glitch. >>> >>> regarding multi-avail: my understanding is that they have made limited >>> modifications to the 5.1 code base to support running mysql on a big scale >>> in the cloud. i don't know if that includes fundamental changes to the >>> master/slave mechanics, but the way multi-avail works "feels" like it's >>> just plain old replication, but wrapped in some fancy automation. >>> >>> yeah, the docs do mention latency, but we've not noticed anything at all. >>> >>> the biggest mistake we made was attempting to run apps outside ec2 pointing >>> at RDS. the latency in that set-up killed our apps. ymmv. >>> >>> simon >>> >>> >>> >>> On 2 August 2010 21:02, Kieran Kelleher <kieran_li...@mac.com> wrote: >>> Sounds great Simon. >>> >>> I have a database of about 35GB of data running on an 8GB PowerPC G5 today >>> in one of my active projects and we have preliminary plans under way to >>> upgrade our DB server to a 32GB Linux RAID unit. What is the biggest RDS >>> memory size instance that you have used, and what is the perception of >>> performance gains, if any, over traditional self or colo hosting? >>> >>> I notice they support SSL connections also to MySQL. Do you use SSL between >>> the EC2 app instance and the RDS instance - or is that overkill considering >>> that I have sensitive data (credit card numbers, etc) encrypted in the >>> database fields anyway? If you do use SSL connections between app and db, >>> have you noticed much latency? >>> >>> You said you have availed of the different zone replication/failover >>> feature - from reading the FAQs, it appears that this is different to >>> traditional master-slave replication - are they executing the SQL in >>> parallel on both the master and failover RDS instances to give true >>> mirroring, or am I reading this wrong? Have you noticed latency impact due >>> to this configuration (the online info suggests that there is some latency)? >>> >>> Regards, Kieran >>> >>> On Aug 2, 2010, at 1:38 PM, Simon wrote: >>> >>>> How does session management work with the elastic load balancer? For >>>> example if you have 3 independent EC2 instances all running the same app? >>>> >>>> if you are not using https then amazon provide a couple of cookie-based >>>> mechanisms for session stickiness. if you are using https then you can use >>>> the elb to send initial requests to one of your instances, then the user >>>> communicates with that specific instance directly. there is no >>>> ssl-termination available with elb, but the amazon lists suggest this is >>>> coming. once they have this ssl load balancing will be a lot more elegant. >>>> >>>> Also, do you completely trust RDS to make sure your data is never lost? Is >>>> there any need for you to have a physical server replicating from RDS? Is >>>> there any risk that one day, amazon loses your database and says "Sorry, >>>> but we assume you have your own backup"? >>>> >>>> in short, yes, i completely trust it. we've been running it in production >>>> for 9 months now without a single glitch. we use their multi-avail support >>>> and we've done test failovers which happen flawlessly in minutes. how long >>>> would it take you to (a) make a decision to fail over your master to a >>>> slave and (b) physically carry out the failover and (c) physically restore >>>> the master once things are sorted out ? the automation here alone makes it >>>> a much more powerful solution than running it ourselves. >>>> >>>> and how often do you test restoring from your backups ? officially we used >>>> to do it once a month, but it was always a real drag... now we routinely >>>> restore databases - sometimes several times a day - and use them to test >>>> code against because it's 2 clicks, make a cup of tea, and you've got a >>>> fully functioning snapshot of production from 5 minutes ago. >>>> >>>> do we ever take "normal" backups ? yes, but very very rarely, and not for >>>> date protection - we do them purely to get a fresher copy on our laptops >>>> for offline use. >>>> >>>> Simon >>>> >>>> >>>> >>>> -Kieran >>>> >>>> On Jul 27, 2010, at 1:16 PM, Simon wrote: >>>> >>>>> doing what you've done means you're managing mysql, looking after it, >>>>> making sure it doesn't fall over, doing backups, managing replication >>>>> etc. rds does all of that for you. it also makes changing the config of >>>>> your database server a breeze: need more disk space ? couple of clicks. >>>>> need more ram ? couple of clicks. need more compute power behind it ? >>>>> couple of clicks. need automatic fail-over to a different availability >>>>> zone ? couple of clicks. >>>>> >>>>> re web server resources, remember it's just a normal wo deployment >>>>> running in the cloud, so you can do whatever you do now. >>>>> >>>>> we don't separate the web and app tier - all our ec2 instances run >>>>> monitor, wotaskd and apache, and are effectively independent of each >>>>> other, and we use an elastic load balancer up front. >>>>> >>>>> simon >>>>> >>>>> >>>>> On 27 July 2010 17:40, James Cicenia <ja...@jimijon.com> wrote: >>>>> So the base image is the actual OS? So you are managing it as the admin? >>>>> >>>>> I decided to try WOlastic. I configured the instances, setup up mysql >>>>> with my users and sync'd the database from existing production to amazon. >>>>> So you are suggesting RDS vs. what I just did? What are the benefits of >>>>> RDS? Amazon backs up the mysql I created. >>>>> >>>>> Now I am a bit stumped on WebServerResources. How are you handling that? >>>>> >>>>> Well, if this works well, I can my webobject apps over and then just sell >>>>> my server and drop the colo. >>>>> >>>>> - James >>>>> >>>>> On Jul 27, 2010, at 11:28 AM, Simon wrote: >>>>> >>>>>> rolling your own is surprisingly easy if you start with a base image. we >>>>>> started out with a vanilla centos image from rightscale, and have built >>>>>> it up into what we needed from there. you can then create an ebs-backed >>>>>> ami in a couple of clicks. >>>>>> >>>>>> re pricing, it all depends on what you need. our financial models tell >>>>>> us for our deployment is excellent value for money, and we can scale >>>>>> well beyond our current needs and it remains as such. use the cost aws >>>>>> calculator to figure out your own costs, and remember to factor in staff >>>>>> costs in your decision making process. those DBA's are darn expensive >>>>>> compared to RDS :-) >>>>>> >>>>>> http://calculator.s3.amazonaws.com/calc5.html >>>>>> >>>>>> the only performance issue we found is that it is basically impossible >>>>>> to host your DB outside of amazon due to latency. but you don't have to >>>>>> use RDS - if you like sticking needles in your eyes you can just run and >>>>>> look after your own mysql / postgre / mssql / whatever on an ec2 >>>>>> instance. >>>>>> >>>>>> the general performance of our apps has also vastly improved. a mixture >>>>>> of using more computing power and amazon having much faster internet >>>>>> transit than we were paying for in our previous co-lo. >>>>>> >>>>>> alongside production we also run our staging servers and our hudson >>>>>> build server on ec2. in productivity terms running hudson there was a >>>>>> huge leap forward: previously a new build would take around 30 minutes >>>>>> to upload to staging / production. now it takes 19 seconds flat :-) >>>>>> >>>>>> we're shortly going to move our subversion repository to ec2 as well. >>>>>> >>>>>> Simon >>>>>> >>>>>> On 27 July 2010 15:13, James Cicenia <ja...@jimijon.com> wrote: >>>>>> This is very cool. >>>>>> >>>>>> I need to move one of my servers, or, use the cloud approach for its >>>>>> WOApps. I see you rolled your own but wolastic seems like it is for a >>>>>> mere mortal. >>>>>> >>>>>> Anyone use wolastic? What is the pricing your are seeing? Issues? >>>>>> Performances? Etc. >>>>>> >>>>>> Thanks. >>>>>> James Cicenia >>>>>> >>>>>> >>>>>> >>>>>> On Jul 26, 2010, at 3:55 PM, Simon wrote: >>>>>> >>>>>>> we don't use the wolastic images (we have our own) but we do deploy >>>>>>> entirely on the amazon ec2 cloud now. ec2 instances running standard >>>>>>> javamonitor / wotaskd, amazon RDS for database server, s3 for file >>>>>>> storage etc. scalability on demand, load balancing, redundancy across >>>>>>> multiple availability zones. it's the best thing since sliced bread... >>>>>>> >>>>>>> our staging servers (also on ec2) run wonders javamonitor / wotasd and >>>>>>> hence we'll probably upgrade our production servers to those soon. >>>>>>> >>>>>>> simon >>>>>>> >>>>>>> On 26 July 2010 21:36, Ramsey Gurley <ram...@xeotech.com> wrote: >>>>>>> I haven't tried it yet, but WOlastic looks like a *really* cool >>>>>>> deployment solution for WO. >>>>>>> >>>>>>> http://wolastic.com/ >>>>>>> >>>>>>> Ramsey >>>>>>> >>>>>>> >>>>>>> On Jul 26, 2010, at 4:27 PM, Ken Anderson wrote: >>>>>>> >>>>>>> Thanks for the thoughts guys! >>>>>>> >>>>>>> Ken >>>>>>> >>>>>>> On Jul 26, 2010, at 1:42 PM, Pascal Robert wrote: >>>>>>> >>>>>>> >>>>>>> Le 2010-07-26 à 12:55, Chuck Hill a écrit : >>>>>>> >>>>>>> On Jul 26, 2010, at 9:44 AM, Ken Anderson wrote: >>>>>>> >>>>>>> I've been asked to comment on the best way to deploy WebObjects today >>>>>>> without any "imposed" restrictions. I haven't done any new deployments >>>>>>> in a long while, so I'm likely not up to date on the last. What are >>>>>>> people using today, and why do they think it's the best? >>>>>>> >>>>>>> Thanks much! >>>>>>> Ken >>>>>>> >>>>>>> Lacking imposed restrictions (e.g. must run in J2EE container), >>>>>>> traditional WO deployment through Apache with mod_webobjects is >>>>>>> probably the way to go. Anjo was working on mod_proxy deployment, but >>>>>>> I don't recall how far he got or if he has this in production. It >>>>>>> looked promising. There is also a Fast CGI adaptor and Ravi is working >>>>>>> on something for WOWODC. >>>>>>> >>>>>>> I'm adding some mods in JavaMonitor too (for WOWODC) and Andrew >>>>>>> Lindesay also have stuff in LEWOStuff to use mod_proxy_ajp. >>>>>>> >>>>>>> >>>>>>> >>>>>>> ---- >>>>>>> Pascal Robert >>>>>>> prob...@macti.ca >>>>>>> >>>>>>> AIM: MacTICanada >>>>>>> Twitter : MacTICanada >>>>>>> LinkedIn : http://www.linkedin.com/in/macti >>>>>>> WO Community profile : http://wocommunity.org/page/member?name=probert >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Do not post admin requests to the list. They will be ignored. >>>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/ramsey%40xeotech.com >>>>>>> >>>>>>> This email sent to ram...@xeotech.com >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Do not post admin requests to the list. They will be ignored. >>>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/simon%40potwells.co.uk >>>>>>> >>>>>>> This email sent to si...@potwells.co.uk >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Do not post admin requests to the list. They will be ignored. >>>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/james%40jimijon.com >>>>>>> >>>>>>> This email sent to ja...@jimijon.com >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Do not post admin requests to the list. They will be ignored. >>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>>>> Help/Unsubscribe/Update your Subscription: >>>>> http://lists.apple.com/mailman/options/webobjects-dev/kieran_lists%40mac.com >>>>> >>>>> This email sent to kieran_li...@mac.com >>>> >>>> >>> >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/webobjects-dev/m.soutier%40starhealthcare.info >>> >>> This email sent to m.sout...@starhealthcare.info >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/simon%40potwells.co.uk >> >> This email sent to si...@potwells.co.uk >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/kieran_lists%40mac.com >> >> This email sent to kieran_li...@mac.com > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/kenlists%40anderhome.com > > This email sent to kenli...@anderhome.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
