Hi Nils, Hi Saravanan, > saravanan paramasivan wrote:
> > Thanks Nil. I am in EE only and this answers my question. > > > > @Nils - I am going to have one author instance and two public instances in > > production. is there any standard fail over settings/ best practice? I don't know about best-practice, but here are some ideas: If you're using a hot-failover, you should be able to achieve this using linux-heartbeat and virtual IPs... Note that a hot failover node requires half a magnolia licence, so I don't find this cost-effective. Pay for the whole licence and get a real second node, which will then help you handle load as well as high-availability. An alternative is cold-standby, which doesn't require a license, but will result in some down-time before the standby node is manually brought online. Personally, I would use a load-balancing hardware - your load-balancer typically becomes your SPOF (single point of failure), so I find it better to use a rock-solid hardware device here, rather than mess around with Linux and Apache, but you can do that too. I'd also terminate SSL at the load-balancer if possible - hardware will be able to handle more SSL connections than tomcat. In theory the load-balancer can distribute the requests directly to tomcat. I wouldn't do it that way. I'd put an Apache in front of tomcat, installed on the public nodes itself. Configure the Apache to listen on port 80 and forward requests to tomcat via mod_jk. The big advantage of mod_jk is that it can enable completely transparent fail-over. If mod_jk doesn't get an answer from Public-A within a set time, or Public-A is unreachable, it will forward the SAME request to Public-B for handling. In this way you get failover without dropping ANY requests at all. Most Load-Balancers can't offer this functionality, relying on polling their target systems for availability, meaning a failover time of a few seconds, during which hundreds of requests might be dropped. The other big advantage of using Apache in front of tomcat is that you can use mod_rewrite to easily and quickly filter out requests you don't want. We filter out all requests to "/.magnolia*" to prevent any access to the backend from the outside world. From inside our corporate network we allow direct access to tomcat on port 8080, so we can still perform maintainance. From outside there is no risk of getting at the backend. If you need to detect SSL in magnolia, configure 2 separate paths to magnolia: HTTP: Load-balancer port 80 --> apache port 80 --> mod_jk config 1 --> tomcat AJP Connector Port 8009 secure=false scheme=http HTTPS: Load-balancer port 443 --> apache port 81 --> mod_jk config 2 --> tomcat AJP Connector Port 8010 secure=true scheme=https And finally, we use the Apache to filter "cross-site-content-access" in magnolia EE. Basically if you're using EE and have 2 sites set up, /site1 and /site2, with domains www.site1.com and www.site2.com then by default magnolia will allow requests like: www.site2.com/site1/some/page.html Then some content from site 1 will be found in site 2, most likely displayed wrong because the templates and content don't match the site-definition. Personally I don't consider this a big problem per se, but the trouble starts when google starts to index the wrong content in the wrong site, and then users begin to find "bad search results" in google. Not so nice. So we avoid this trouble by filtering "/site1*" in our apache setup if the domain is site2, and vice-versa. Finally you should consider backup. If you set up load-balancing as described above, then you can shut down tomcat anytime on one of the public nodes to make a backup. If you keep your public nodes symmetrical, there is no need to back up both nodes, they should be the same. An alternative might be to install a 3rd public node, not attached to the load balancer (ie without any public requests coming in), which receives all the content, but is only used for backup purposes...) as I understand it that would be a kind of cold standby machine, and so would not need its own magnolia license. I hope that helps. > I don't really understand what you're looking for. If you have two public > instances behind a loadbalancer then all websites should just keep working > when one > of the public instances goes down (unless that one instance can't handle the > load of course). Activation from the author instance to the public instances > won't > work when not all public instances are available, but will be possible again > the moment they are both online again. > You could decide to remove either of the public instances as a subscriber on > the author instance if you need to activate content while one of your public > instances is down, but then you'll need to synchronize the instance that was > down when you bring it back online. I guess you could use the Synchronization > module [0] for this, but I've never used it. The Sync module currently only works correctly for the website workspace, so it isn't a finished solution for syncing your new public nodes. To add new nodes, I would start them with a copy of the repository of an existing node. Regards from Vienna, Richard ---------------------------------------------------------------- For list details, see http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
