Words and Phrases
SA topologies
You must decide what SA topology fits your facility’s needs. This section provides some background on the SA topologies to help you make that decision.
Single Host Core
The simplest topology is a Single Host Core (formerly a Standalone Core) that manages servers in a single facility.
A Single Host Core is best for a small network of servers contained in a single facility. Although a Single Host Core does not communicate with other SA Cores, it has all the components required to do so and can be easily converted into a core that is part of a Multimaster Mesh.
Multimaster Mesh (Multiple Cores)
To manage servers in more than one facility, you install a Multimaster Mesh of SA Cores or a combination of SA Cores and Satellites.
A Multimaster Mesh is a set of two or more SA Cores that communicate with each other through Management Gateways and can perform synchronization of the data about the Managed Servers contained in their respective Model Repositories. Changes to the data in any Model Repository in a Multimaster Mesh are broadcast to all other Model repositories in the Mesh and synchronized.
The SA Core Component that propagates and synchronizes changes from each Model Repository to all other Model Repositories is called the Model Repository Multimaster Component and is part of the Infrastructure Component bundle. This replication capability allows you to store and maintain a “blueprint” of software and environment characteristics for each facility making it easy to rebuild your infrastructure. It also provides the ability to easily provision additional capacity, distribute updates, and share software builds, templates and dependencies across multiple facilities.
A Multimaster Mesh can also include Satellite installations.
Servers can be managed from any facility with an installed SA Core using the SA Client.
An Multimaster Mesh offers the following benefits:
- Centralized Administration —The Managed Servers in a Multimaster Mesh can be centrally administered from any facility that is managed by an SA Core that is part of the mesh. Administration is not locked into a single location or even restricted geographically.
- Redundancy —Synchronized (replicated) data management between facilities provides redundancy. For example, if an SA Core in one facility in a mesh is damaged, other cores in the Multimaster Mesh contain synchronized copies of the managed server data that can be used to restore the damaged core’s Model Repository to a last known good state. In addition, while a damaged core is unavailable, other cores in the mesh can continue functioning without interruption.
Replication also provides the ability to close down or add a facility while other facilities in the mesh continue operations without interruption.
- Performance Scalability—In a Multimaster Mesh, only multimaster database synchronizations are transmitted over the network reducing network bandwidth load.
- Geographic Independence—Cores can continue to manage servers during network interruptions regardless of location.
Facilities and realms
SA Gateways use two constructs that facilitate routing network traffic and eliminate the possibility of IP address conflicts:
A Facility is a construct that represents a collection of servers that a single SA core manages through the data about the managed environment stored in its Model Repository. A facility typically represents a specific geographical location, such as Sunnyvale, San Francisco, or New York, or, commonly, a specific data center.
A Facility is a permissions boundary within SA; that is, a user’s permissions in one Facility do not carry over to another. Every Managed Server is assigned to a single facility. When a device initially registers with the SA Core, it is assigned to the facility associated with the gateway through which it is registering.
For example, Admin A works in Sunnyvale and is in charge of maintaining server patches. In a Facility framework, Admin A is bound to the Sunnyvale Facility as a user. When Admin A views servers, only those servers that are also bound to the Sunnyvale Facility are displayed. He will not see servers for any other Facility.
There are two types of facilities:
- Core Facilities: There is one Core Facility for every Core installation.
- Satellite Facilities: A default Facility created when you install a Satellite.
Realms are an SA construct that allow SA to manage servers on different networks in the same Facility without IP address conflicts. A realm is a unique identifier, appended to the IP address of a device in a Facility's network, that allows SA Gateways to uniquely identify devices on different networks in a Multimaster Mesh that may have conflicting IP addresses.
A Realm is a logical entity that defines an IP namespace within which all Managed Server IP addresses must be unique. However, servers that are assigned to different Realms can have duplicate IP addresses and still be uniquely identified within SA by their Realm membership.
Realms are interconnected by gateways in a gateway mesh — a single interconnected network of SA Gateways.
When you create and name a new Facility during installation, a default Realm is also created with the same name as the Facility. For example, when you create the Facility, Datacenter, the installation also creates a Realm named Datacenter. Subsequent Realms in that facility could be named Datacenter001, Datacenter002, and so on. Managed servers in each realm are uniquely identified by the combination of the Realm name and the IP address.
A connection within the mesh has an ingress (or source) realm, where the connection enters the mesh, and an egress (or destination) realm, where the connection exits the mesh.
All SA managed devices are assigned to exactly one realm. Which realm they are assigned to can change dynamically (though it typically will not change). Whenever a device registers with the core, the core looks up the ingress realm for the registration using a gateway identity server, and then assigns the device to that realm.
If the registration occurs using a direct connection, the device is assigned to the transitional realm. The transitional realm may be considered a non-realm. It exists only to denote devices that register themselves with a core using a direct connection.
With the exception of the transitional realm, realms do not span facilities (that is, every realm has a relationship to exactly one facility except for the transitional realm).
Within the mesh, there are two categories of realms:
- Non-root realms
- Root realms: The mesh has one or more realms at the “center” of the mesh. These realms are root realms. When a gateway is asked to route a connection, if that connection does not specify a destination realm, the connection will be routed to the “closest” root realm, where “closest” is whichever root realm is reachable at the least network cost. Root realms also have a special relationship in SA to facilities. Whenever an SA Core is installed, a facility is created. At the same time, a root realm is created that has a one-to-one relationship with the new facility.
Multimaster Mesh topology examples
The following figure shows a Multimaster Mesh with cores installed in two separate facilities, San Francisco and Los Angeles. Each facility’s core has a Model Repository that contains data about the Managed Servers in both facilities. That data is constantly synchronized (replicated) between both Facilities’ Model Repositories. The cores communicate through their respective Management Gateways.
Communication from the Managed Servers in the Los Angeles facility to the San Francisco core travels through the Los Angeles Agent Gateway to the Core Gateway, then to the Los Angeles Management Gateway, which then communicates with the San Francisco core through the San Francisco Management Gateway and Core Gateway.
The following figure shows a Multimaster Mesh with four cores. This Mesh topology is called a Star Formation with the San Francisco core at the center of the Mesh. The SA Installer configures a Multimaster Mesh in a star topology with backup gateway routes by default.
