> 1) ... Store all tickets and other dynamic > information where possible in an mysql database cluster ( replicated over > the WAN VPN link).
I can imagine the replication would be a bandwidth hog, while latency might be prohibitive. The workload on the CAS ticket registry is very read/write intensive, so you're going to generate a lot of data to replicate. If you wanted to have multiple nodes in the database serve as masters where they need to receive each updates from one another, I would think the latency would significantly reduce throughput. Also, I'm not up on MySQL clustering, but the only clustering setup I'm aware of is master-slave. Is mulit-master replication even an option? I wonder if another ticket storage mechanism like memcached or JBoss Cache would be more well-suited to this case. > 2) Load balance between the data centers using technology such as Big IP's > GTM . You'd still have to devise a solution to share ticket state between nodes in a cluster that spans data centers. M -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
