Magnolia is distributed as two web-applications, one acting as the authoring instance and the other as the public environment. Keeping the author application inside your firewall ensures better security. In a typical deployment you have at least two public instances but can have many more. The multiple instance model also allows clustering configurations.

Author instance is where editors work. This instance typically resides in a secure location behind a corporate firewall, inaccessible from the Internet. The author instance publishes content to public instances. Public instance receives the content and serves it to visitors on the Web. The public instance resides in a publicly reachable location. You can have more than one public instance, serving the same or different content.

Each instance functions as an independent application but technically they are the same. An author instance can be configured to function as a public instance and vice versa. The differences are small adaptations in configuration and security. Security for the public instances is usually managed separately.

Public instances serving different content

You can manage multiple sites from the same author instance. Each public instance can serve content targeted for a specific geographical area. For example, one instance serves visitors from Europe and another visitors from the U.S.

Magnolia multisite feature provides granularity for content control on multi-language and multi-domain installations. Administrators have the option to direct editors to the author instance through a specific domain. Editors edit only the part of the content structure that resides at the specified domain. To ensure a consistent browsing experience, URLs are adapted to always reflect the domain. You can also configure multiple domains to access the same instance.

Intranet and extranet

Magnolia allows for flexibility in placing secure and sensitive application instances. The diagram below illustrates a possible placement strategy where an extranet public instance resides outside the firewall but an intranet instance is inside. More advanced configurations can be built to place intranet and extranet instances inside a firewall, for example.

Planned redundancy and high availability

A distributed instance setup allows you to respond to high availability requirements and sudden increases in traffic. Each of the following problem scenarios can be addressed by adding a new public instance to serve the same content, helping existing instances deal with the load.

  • Public instance failure. Imagine you have two public Magnolia instances and due to hardware failure one of them is out of operation for a few days. Start a new public instance to replace the broken one.
  • Sudden high load on your site, also known as Slashdot effect. Spin off new public instances until the traffic subsides.
  • Public instance blackout. All public instances are corrupted, broken or compromised. No instances exist to serve content.

Instance configuration examples

Magnolia configurations range from a minimal one-machine setup to a standard three-instance production setup and beyond.

  • Minimal. Author and Public instances exist on the same server. This is the default configuration when you install Magnolia on your computer to try it.
  • Reduced. Author and Public instances exist on separate servers. The two Public instances are on the same server or one of the Public instances resides on the same server as the Author instance.
  • Standard. Public instances exist on separate servers. This configuration enables load balancing. Incoming requests can be directed to one server or another depending on availability.

Related topics:

#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))

To comment, create an account and log in.

© Copyright 2023 Magnolia