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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>>>> [email protected] >>>>>> >>>>>> 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 ([email protected]) >>>>>> Help/Unsubscribe/Update your Subscription: >>>>>> http://lists.apple.com/mailman/options/webobjects-dev/ramsey%40xeotech.com >>>>>> >>>>>> This email sent to [email protected] >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Do not post admin requests to the list. They will be ignored. >>>>>> Webobjects-dev mailing list ([email protected]) >>>>>> Help/Unsubscribe/Update your Subscription: >>>>>> http://lists.apple.com/mailman/options/webobjects-dev/simon%40potwells.co.uk >>>>>> >>>>>> This email sent to [email protected] >>>>>> >>>>>> _______________________________________________ >>>>>> Do not post admin requests to the list. They will be ignored. >>>>>> Webobjects-dev mailing list ([email protected]) >>>>>> Help/Unsubscribe/Update your Subscription: >>>>>> http://lists.apple.com/mailman/options/webobjects-dev/james%40jimijon.com >>>>>> >>>>>> This email sent to [email protected] >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Do not post admin requests to the list. They will be ignored. >>>> Webobjects-dev mailing list ([email protected]) >>>> Help/Unsubscribe/Update your Subscription: >>>> http://lists.apple.com/mailman/options/webobjects-dev/kieran_lists%40mac.com >>>> >>>> This email sent to [email protected] >>> >>> >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/m.soutier%40starhealthcare.info >> >> This email sent to [email protected] > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/simon%40potwells.co.uk > > This email sent to [email protected] > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/kieran_lists%40mac.com > > This email sent to [email protected]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
