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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to