ColdFusion 8 enterprise failover

Does cf8 enterprise failover work well? IOW, if an instance hangs does it spawn a new instance seamlessly? Thank in advance.

New instances are not spawned.  Traffic is simply redirected to other instances in the cluster. Depending on how you define "hang"-- yes, once an instance stops responding the Webserver connectors no longer send traffic to it until it comes back up. Please be aware that JRun clustering is not necessarily application aware. You can weigh an instance, but you cannot control the balancing based off server load, users, etc. ~Brad > Does cf8 enterprise failover work well? IOW, if an instance hangs does it > spawn a new instance seamlessly? > Thank in advance.

Ah, ok. So one defines a cluster for an application within the cf8 enterprise server and then if an instance within the cluster hangs, then traffic is redirected? Am I understanding that right? And that works well? Thanks. ----- Excess quoted text cut - see Original Post for more -----

Yes.  You add one or more instances to one or more servers.  Then you define a cluster, add the instances to it, and choose a load balancing algorithm. You then associate that cluster with your IIS site (or apache virtual server etc) In my experience, clusters can be a little cranky if you are making changes to them, but once they are up they work pretty well. The main gotcha's for clustering IMO are: * Features that require subsequent HTTP requests to target the same initial server (cfchart, cfimage) * Data that is specific to a users and stored in a persistent scope like session or Application does not automatically follow users from once instance to another. Session replication can solve the latter, but still has some problems I think, and not many people seem to use it. Sticky sessions eliminates both problems for the most part, and seems to be the most common way to handle clusters.  Of course, the failure of an instance won't be helped by sticky sessions since that only sticks a users to an instance as long as it is still up. ~Brad ----- Excess quoted text cut - see Original Post for more -----

Uh, what?  Session replication has been working for me starting with MX 6.1 and continues to work fine now that we've moved to CF8.  I've also not had an issue with cfchart since the information replicates within the cluster.  And, as an added bonus, the latest JRun updater for CF8 brings us partial session updates!  Now, only the data that actually changes gets pushed to the other clusters.  Before?  It sent the entire scope data.  This is in several environments, and one that has a load of about 75k hits daily shared across 4 servers and 4 instances.  Things that may go wrong though...  if your servers are on different subnets, it's a right pain in the ass to make it work correctly.  The only time I've seem to have issues with session replication is with sites that have exceedingly high memory writes/reads.  We've got a Mach II app that will not behave when pushed into a cluster.  Normal startup time for this app is 30 seconds, but that stretched beyond 3 minutes when it was trying to replicate data amongst peers.  Then again, this app had a startup XML file of around 120k.  It's ungodly massive, and something I did mention to the devs in the past ;). Matthew Williams Geodesic GraFX Brad Wood wrote: ----- Excess quoted text cut - see Original Post for more -----

> Uh, what?  Session replication has been working for me starting with MX > 6.1 and continues to work fine now that we've moved to CF8. How do you define "working"?  When you can't place CFCs or XML objects in your session scope without ugly erros, I don't call that working. Serialization of complex objects has plauged session replication for a while.  CF8 made CFCs serializable and that was very good, but to this day (and to my knowledge), ColdFusion is still incapable of serializing complex variables (Arrays, Dates, Query objects) within a CFC. (Adobe Bug #70580) I know there are people who use session replciation, but in general, my perception (from this list anyway) is that a lot of people have simply enabled sticky sessions and then clocked out. I've also > not had an issue with cfchart since the information replicates within > the cluster. I'm not sure what you speak of, but to my knowledge this is not operation out of the box since cfchart's cache location defaults to a local directory. (Which is why it qualifies in my gotcha catagory) Your options are to cache to a shared network location, or enable some sort of file replication beween your chart caching folders.  Keep in mind, I didn't say it was impossible. I simply said it was a gotcha. To my knowledge, cfimage does not allow customization of the caching folder.   And, as an added bonus, the latest JRun updater for CF8 > brings us partial session updates! Your are right.  This is a very good thing. ~Brad

Brad Wood wrote: ----- Excess quoted text cut - see Original Post for more ----- I define working in that we host about 130 applications, and none have had issues (beyond that MachII app) in 2 years with our setup.  At least, I've not had any complaints.  Now, we do use session stickiness in addition to the replication, so in theory we wouldn't have any issues unless the server goes down.  We've actually had 98+% uptime on the servers, so maybe we just don't come across it?  Mayhap we just have really boring devs that don't serialize objects.  I don't know. ----- Excess quoted text cut - see Original Post for more ----- Yes, sleep addled brain at work here.  I should say that since all of the sessions should stick, we don't typically have an issue with CFCHART.  Although, I should look at setting those folders as targets for our DFS shares. I guess the only real thing I have going here is that, in my experience, life has been 1000x better since we've moved to multi-server with session replication and stickiness.  Customers and the public no longer catch a 500 server error (which happened frequently before I came on board).  The only complaint I've had for our public facing servers in the last few months is an issue with our front end balancer.  If a CFHTTP request gets routed back to the same server making the request, the load balancer fails the request.  This only applies to non-CFM related requests, so calls to XML files and images would fail intermittently.  The workaround for that is to use things like CFFILE instead, but I have no control over the front end load balancer. Matthew Williams Geodesic GraFX

Matthew Williams wrote: > The only complaint I've had for our public facing servers in > the last few months is an issue with our front end balancer.  If a > CFHTTP request gets routed back to the same server making the request, > the load balancer fails the request.  This only applies to non-CFM > related requests, so calls to XML files and images would fail > intermittently.  The workaround for that is to use things like CFFILE > instead, but I have no control over the front end load balancer. The simple solution typically is to add all the hostnames you are using to the hosts file of your CF server with the 127.0.0.1 IP address. (You need to restart your CF instance after that because it caches DNS lookups.) Jochem

Great, thanks. How much memory is required or recommended for each instance? I'm on a Windows Server 2003 Standard Edition with 4 GB of memory (its max). How many instances would be recommended for that amount of memory? ----- Excess quoted text cut - see Original Post for more -----

By default CF uses 512 Megs + up to 128 Megs of memory per instance.   You can configure that to be higher, though I wouldn't go any lower.   I'd go with a maximum of two instances with that type of system in a production environment.  This way, you could allocate about 1.2 gigs per instance and be relatively safe.  At least, that's what I've found to be the most optimum on my end. Matthew Williams Geodesic GraFX Richard Steele wrote: > Great, thanks. How much memory is required or recommended for each instance? I'm on a Windows Server 2003 Standard Edition with 4 GB of memory (its max). How many instances would be recommended for that amount of memory?

This is one of those things no one can really answer but you.  I can make suggestions, but other people on this list can probably make better ones. Assuming you are 32 bit, your maximum heap size you can allocate to each JVM is 1.8 Gigs. Factors you need to take into consideration are:  What else is running that server?  The operating system will need some memory.  Is that server dedicated to CF or are there a mail server, and a SQL server on it as well? How much memory does your CF application use at peak load times? Also, you need to decide what you want to get out of clustering.  The topic of this thread says "failover", so I'll assume redundancy in on your docket. For the record, keep in mind that multiple instances on the same physical server will not help in the event of hardware failure, network failure, power failure, OS failure, Web server crashes (IIS, Apache), or Database Failure. This is totally my opinion based on some assumptions, and anyone else is very welcome to dissent, but if you have an average CF app on a dedicated CF box, I would probably start out with a simple cluster of two instances. Give them both 1 Gig min and max heap size and see how that treats you.  Set it up as regular (non-weighted) round robin, and enable sticky sessions. Then run some tests.  Start putting some load on your app and watch your memory usage to see what it is doing.  Then shut down an instance and see how well it is handled. There is an ideal set up for you, but I don't know of any magic formula to find it without testing and experimentation. Here's a recent article by Mike Brunt on the topic. http://www.adobe.com/devnet/coldfusion/articles/clustering_cf8.html ~Brad > Great, thanks. How much memory is required or recommended for each > instance? I'm on a Windows Server 2003 Standard Edition with 4 GB of > memory (its max). How many instances would be recommended for that amount > of memory?