hum, a solution... not memcache list opnion, but a user opnion use membase with replication at server side, or repcache replication at client side will have async write/reads and maybe problems (replication for mysql users) replication at server side will be sync (ndb cluster for mysql users)
i'm using repcache without problem, if one server die the other have the same information, when other server is up it's automatic sync with the 'master' it works well with php memcache session handler but a good session handler could be a nosql database (membase) since it's not a cache, it's a database... 2011/4/5 Geoffrey Hoffman <geoffrey.hoff...@gmail.com>: > It's not even a network problem, it's an application design problem. > > Even if all you wanted to do was load balance a user session (user ID > & some other text-based info) across data centers, it's not that > trivial, particularly if you didn't plan for that up front. At the > bare minimum all you need is a session ID, but the easiest way to do > that is with a session server specifically for this purpose. Even with > 1 LB, 2 Web Heads and 1 DB server in the same subnet in the cloud, > it's the same problem - user uploads something to X but their next > request is served by Y. > > The content belongs on a CDN. It sounds to me like you are describing > one of the most common use cases for one. You don't need to know the > user went to server X or Y since their session is on server S and the > content is on CDN and S & CDN are both accessible to X & Y. This > architecture is commonplace (now) but I wouldn't say it's `drop dead > easy`. > > Just my $0.02 - > > > On Mon, Apr 4, 2011 at 8:41 PM, Brian Moon <br...@moonspot.net> wrote: >> That is not a bad design. That is drop dead easy. >> >> You are asking to this list and memcached to magically solve a problem that >> is not realistically solvable with the current architecture of the Internet >> at a scale you are likely to be running on. >> >> Now, if you would like to invest in private OC3's that run from data center >> to data center to ensure sub millisecond latency from one to the other, be >> my guest that would solve your problem. But, this is not a memcached >> problem. It is a network problem. >> >> Brian. >> http://brian.moonspot.net >> >> On 4/4/11 7:13 PM, Mohit Anchlia wrote: >>> >>> Bad design. Besides not that easy :) If it was I wouldn't have posted >>> here. >>> >>> On Mon, Apr 4, 2011 at 5:04 PM, Brian Moon<br...@moonspot.net> wrote: >>>> >>>> You have full control over what resources your internal servers use. Just >>>> assign them a datacenter and go. >>>> >>>> Brian. >>>> http://brian.moonspot.net >>>> >>>> On 4/4/11 6:59 PM, Mohit Anchlia wrote: >>>>> >>>>> Problem here is that lot of traffic is generated internally by server >>>>> hosted by other projects within same co. now this need to be load >>>>> balanced. If we used geo then 70% of our traffic will be stuck on one >>>>> site. If all our clients were browser based then it would have been >>>>> easier. >>>>>> >>>>>> 2011/4/4 Brian Moon<br...@moonspot.net>: >>>>>>> >>>>>>> We are active/active as well. But, we use geo dns so that people only >>>>>>> get >>>>>>> DNS for one data center. Having someone be able to hit any datacenter >>>>>>> in >>>>>>> the >>>>>>> world at any time without any temporary loss of service is not >>>>>>> reasonable. I >>>>>>> don't care who you are. Even Google sticks you to a geo-regional based >>>>>>> datacenter. >>>>>>> >>>>>>> Brian. >>>>>>> http://brian.moonspot.net >>>>>>> >>>>>>> On 4/4/11 5:39 PM, Mohit Anchlia wrote: >>>>>>>> >>>>>>>> That is already in place but business requirement is to do >>>>>>>> active/active hence need for more complicated solution. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Apr 4, 2011 at 3:32 PM, Brian Moon<br...@moonspot.net> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Use geo dns instead to stick users to a single datacenter and only >>>>>>>>> fail >>>>>>>>> over >>>>>>>>> to the other data center when there is an issue. This will be much >>>>>>>>> less >>>>>>>>> of a >>>>>>>>> headache than trying to move cache data back and forth over the net. >>>>>>>>> >>>>>>>>> Brian. >>>>>>>>> http://brian.moonspot.net >>>>>>>>> >>>>>>>>> On 4/4/11 3:03 PM, Mo wrote: >>>>>>>>>> >>>>>>>>>> We have multiple data centers and are now planning to make this >>>>>>>>>> application active/active. Which means user can be load balanced. >>>>>>>>>> User >>>>>>>>>> generally uploads a file and it should be accessible on both sites. >>>>>>>>>> >>>>>>>>>> We expect it will take upto 1 hr to replicate files in worst case >>>>>>>>>> scenario and we are not able to come up with good solution since >>>>>>>>>> cookies wouldn't work for us. >>>>>>>>>> >>>>>>>>>> What we really need is someway of storing User and Site eg: User A >>>>>>>>>> visited site X. Based on that information we can then redirect user >>>>>>>>>> to >>>>>>>>>> correct site. After one hour this info will expire and generate new >>>>>>>>>> info. >>>>>>>>>> >>>>>>>>>> I am planning to use memcached on httpd apache server accross 2 >>>>>>>>>> data >>>>>>>>>> centers to keep cache in sync. >>>>>>>>>> >>>>>>>>>> I understand latency will be a factor but I am assuming we can also >>>>>>>>>> do >>>>>>>>>> async and it shouldn't be that slow since we are only talking about >>>>>>>>>> small set of data. >>>>>>>>>> >>>>>>>>>> Need help from experienced users if they have any good suggestions >>>>>>>>>> on >>>>>>>>>> how to do this. >>>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Roberto Spadim >>>>>> Spadim Technology / SPAEmpresarial >>>>>> >>>> >> > -- Roberto Spadim Spadim Technology / SPAEmpresarial
