Difference between revisions of "Pandora: Metaconsole: Documentation en: Arquitecture"

From Pandora FMS Wiki
Jump to: navigation, search
(User Synchronization)
Line 1: Line 1:
[[Pandora:Documentation_en|Go back to Pandora FMS documentation index]]
+
[[Pandora:Documentation_en#Part_6._Metaconsole|Go back to Pandora FMS documentation index]]
  
 
= Architecture =
 
= Architecture =
Line 164: Line 164:
 
</center><br><br>
 
</center><br><br>
  
[[Pandora:Documentation_en|Go back to Pandora FMS documentation index]]
+
[[Pandora:Documentation_en#Part_6._Metaconsole|Go back to Pandora FMS documentation index]]
  
 
[[Category:Pandora FMS Metaconsole]]
 
[[Category:Pandora FMS Metaconsole]]

Revision as of 15:23, 15 October 2013

Go back to Pandora FMS documentation index

1 Architecture

The Metaconsole architecture consist of one central node: The Metaconsole and of so many server nodes as you want: The Instances. The Instances are Pandora FMS normal installations. They consist on a web console in the front end and of one server in the back end that processes the data that it gets, it does remote checks,etc. The Metaconsole has not its own server. It is only a web console.

1.1 Where are stored the data?

Some data are in the Instances, others in the Metaconsole and others in both places. They need to be synchronized to work properly.

In Instances:

  • Agents
  • Modules
  • Alerts
  • Policies

In the Metaconsole:

  • The Metaconsole configuration:
  • Components
  • Reports* and the template reports
  • Network maps*
  • Visual maps*
  • Netflow filters

In both:

  • Users and profilesThe userLos usuarios y perfiles
  • Groups
  • Templates, actions and alert commands
  • Tags
  • Categories

* Though these items are stored in the metaconsole, they are configurations that are used to visualize the Instace data, so they don't have any utility by themselves.

1.2 How Information is got and modified?

The Metaconsole gets and modifies the Instances information in two different ways:


  • Active: Access to the Database or API of the Instances in a remote way from the Metaconsole (it's the case with agents,modules, alerts, etc).




Metaconsola Arquitecture Active.png



  • Passive: Data replication from the Instances to the Database of the Metaconsole (it is the case of events).


Metaconsola Arquitecture Passive.png



2 Synchronization

There are two different types in the Metaconsole synchronization tools:


  • Synchronization utilities:
  • Users
  • Groups
  • Alerts
  • Tags
  • Propagation Utilities:
  • Component Propagation (from the Metaconsole to the Instances)
  • Agent movements (From one instance to the other)

Info.png

If you want to synchronize the module categories, you should do it manually going into each Instance

 


2.1 Synchronization utilities

The synchronization tools match the content between the Metaconsole and Instances to make sure its correct working.


Template warning.png

After modifying these dat in the metaconsole will be necessary to synchronize them with the Instances to avoid unusual behaviors.

 


Info.png

Most of the synchronization is done by name. In order to not having any problems withe the exceptions we should follow the instructions from Index scaling in the Metaconsole configuration section.

 


2.1.1 User Synchronization

In order an user could operate in the Metaconsole, this user should exist both in the Metaconsole and in the Instance.

Info.png

But their passwords don't have necessarily to be the same one

 


Template warning.png

Users should have the same permissions(ACLs, Tags and Wizard access) in the Metaconsole and Instances for its correct working

 



We will see later the tool to synchronize users and their profiles in the section Synchronization administration.



Metaconsola Users Sync.png



2.1.2 Group Synchronization

Groups should be synchronized in order to warranty the access to the data they have.


Template warning.png

The ACLs that an user has in each group in the Metaconsole should correspond with the accesses of the user with the same name in the instance.

 


We will see later the tool to synchronize the groups in the section.



Metaconsola Groups Sync.png



2.1.3 Alert Synchronization

The alert synchronization refers to the synchronization between the Metaconsole and the Instances of the templates, actions and alert commands.

This synchronization is necessary because one alert is the association of a template, with a number of actions, to one module. Besides, each action has synchronized one command.

Alerts are configured and assigned from the Metaconsole with the templates, actions and commands of the Metaconsole itself. In order that this configuration would be possible and coherent, the instance where the module to which an alert will be assigned would be placed should has the same templates, actions and commands.

There is one tool to synchronize the alerts that we will see later in the section.


Template warning.png

The tool only synchronize the data structures.The commands are associated to one script. The synchronization of that script should be done in a manual way entering into the Instances..

 




Metaconsola Alerts Sync.png



2.1.4 Tag Synachronization

Tags are a complementary access control mechanism to the groups, so they also should be synchronized to warranty the access to the data that they have associated to.


Template warning.png

Tags that an user has in each group in the Metaconsole should match withe the tags of the user with same name in the instance.

 





Metaconsola Tags Sync.png



2.2 Propagation Utilities

These tools are useful to copy or move data from one Instance to other or from the Metaconsole to the Instances.

Unlike the synchronization utilities, propagation is not necessary for the best performance of the Metaconsole. It is only a tool to make easier the availability of data in the Instances.


2.2.1 Components Propagation

With the component propagation tool, its is possible to copy any component created in the Metaconsole to the Instances that you want.



Metaconsola Components Prop.png



2.2.2 Agent Movement

This tool allows to move agents between Instances.


Info.png

To avoid involuntary errors, what is actually done is to copy the agents to the destination Instances and deactivate them in the origin ones.

 





Metaconsola Agents Prop.png



Go back to Pandora FMS documentation index