You may setup Pandora for use HA in several scenarios: Database Clustering for HA. You need to setup a MySQL5 Cluster. In support forums / wiki are information to make this, you only need to convert DB schema in a MySQL Cluster compatible tables. This scenario has been tested and works fine, but you need some advanced knowledge about MySQL Clustering administration. Multiple Pandora Console. It's easy, you only need to setup another one. No locking problems or incompatibility has been detected in several Pandora FMS deployments. Multiple Pandora Data Servers for HA . This is the more complex scenario, because you don't need to know anything special about Pandora Server setup, and you need to use of another tool to implement Network HA, like VRRP or Keepalive. For Pandora Data server you need to setup two identical machines, with the same public keys for all agents connecting to server (and duplicate server SSH host key). And setup Network HA to point one of them. If one fails, VRRP or Keepalive "promote" the other server up, and Pandora Agents, will connect it for the next data packets. There is no need to change anything in each of Pandora Data server, only need ensure that Pandora Server name is the same on both machines (in pandora server setup, not in the system hostname). Multiple Pandora Network Servers for HA . This is easier. You need to setup multiple network servers in several machines across your network (or all of them in the same segment), and assign modules to the same server. If this servers fails, and there are other Network Servers active, marked as "primary" server, automatically, the first network server available marked as "Primary" will launch the network module query. If you have many servers marked as "primary", any of them could launch query. Multiple Pandora Network Servers for load balancing. . You need to setup multiple network servers in several machines across your network (or all of them in the same segment), and assign agent/modules to different servers, balancing load between all servers available. An special case for implement more processing power in servers could be to implement "virtual" servers. Using virtual servers (another instance of the same server in the same machine) is used when Pandora Server cannot process all information without delay too much. Pandora 1.2 it's using a limited number of threads to process information (this will change in future versions), so you can install another instance of Pandora Network or Pandora Data server (with another data_in directory!), to be able to process more information with the same machine. First Pandora versions, from 0.83 until 1.1 was based on a simple idea: one data, one database insertion. This was very easy to develop and allowed to program easily searches, insertions and other operations. This had many advantages and a big problem: the scalability. This system has a limit defined in maximum number of modules that could support in a "easy" way, from that number of modules the management was too slow. Solutions based on MySQL cluster was difficult and cames with some problems and they did not offer either a solution in the long term. Data compression based on interpolation and data purge, makes a smaller database, but this was not enough. Production systems has a limit based on 100 agents, with about ten modules each one. This was not a high limit for large environments. This problem was very important for Pandora future, so we changed the way Pandora store its data. New data management system store only "new" data. If a duplicate value enter the system, it won't be stored in database. It's very useful to keep database small. This works for all pandora data modules: numerical, incremental, boolean and string. This solves part of scalability problem reducing considerably database usage, in about 40%-70%. We also have another solution for scalability problems: total segregation of components in Pandora and a built-in method to implement High Availability solutions on Pandora components. You may have many Pandora servers (network, data or SNMP), Pandora Consoles, and Pandora Database (in a MySQL5 Cluster setup). Changes come with some different ways to reading data. With new version, if an agent cannot communicate with Pandora, and Pandora Server doesn't receive data from agent, this "no data" cannot have a graphical representation, for module graph there will be no changes. You will have a graph with a perfect horizontal line. Pandora, if doesn't receive new values, thinks that there are no new values, and everything seems to be as in the last notification. This graph, for example, shows changes for each data, received every 180 seconds. This would be the equivalent graph for the same data, except a connection failure, from 05:55 to 15:29 aproximately. In Pandora 1.2 we introduce a new general agent graph for show connectivity. It reflects access from modules to this agent. This graph complements all other graphs showing when agent has activity and it's receiving data. This is an example of an agent connecting regulary to server: If you have low leaks in this graph, you may have some problems or slow connections in Pandora Agent connectivity with Pandora Server. This graph with previous example could have an aspect similar to this: