cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
831
Views
5
Helpful
5
Replies

LMS3.0 Master/Slave Question

Mike Bailey
Level 1
Level 1

Working on our LMS3.0 deployment have configured two servers as Master/Slave - one in primary environment at one at our disaster recovery location.

As far as I can tell the only things that are replicated by this are devices, credentials and groups - is this correct?

As my implementation is fully ACS integrated (devices imported from ACS and ACS used for authentication) I'm wondering if it would be easier to set both up as Standalone and run them independently.

Is there anything else Master/Slave offers that I'm missing.

5 Replies 5

Joe Clarke
Cisco Employee
Cisco Employee

DCR high availability only replicates devices and credentials. Groups are not replicated, but can be shared across servers. DCR integration gives you one device list to work with, so you wouldn't have to worry about importing devices into both servers. If you are going to have both servers manage the same set of devices, DCR integration is probably the easier way to go.

Thanks - I guess my thinking is that we also have ACS at the DR site and we need to ensure that the DR server can perform all functions primary can in the event of a disaster.

ACS is already replicating all its device lists between ACS servers at primary/dr, so I was thinking:

1) Setup default credentials on both servers (ACS account)

2) Setup LMS to import devices from ACS locally at each site

3) Setup end devices to send SYSLOG to both LMS servers

4) Setup polling/collection jobs identical on both boxes

Both will theoretically then be identical and perform identical operations and will ensure change audit at both.

If I did the above do I need Master/Slave or leave each standalone?

Will I have issues with this configuration?

Thanks

Michael

If you did the above, you wouldn't need DCR integration since step 2 says you'll be importing the device from ACS locally at each site. If you enabled DCR integration, you would only need to import devices on the master.

When doing HA configs, we generally don't recommend you set the polling to be identical on both servers. This may add undue strain on devices. We typically recommend you poll for inventory and config changes less frequently. And while you can send syslog messages to both servers, disable the Automated Actions which fetch config and inventory updates on the DR server.

When the DR server needs to be come the main server, then just turn the polling back up to where it was on the failed server.

Thanks,

Basically the main purpose of LMS is to act a central repository of device configurations for all our routers/switches including those on customer sites in case we need to restore a configuration in the event of failure, as well as providing an audit trail of all changes to devices.

Thus we need the functionality of LMS to not only routinely poll/collect configs, but also to collect when changes are made locally through SYSLOG automated actions.

The other features are somewhat secondary (albeit useful).

Therefore if the primary server fails I need to be able to access the latest configurations and historical data to meet customer SLA's.

Hence I was thinking about more of an active/active configuration.

Obviously could spread polling schedule by a number of hours, but wouldn't limit the automated actions of SYSLOG (e.g. both servers trying to collect latest config at the same time).

Maybe need to think this through a little more, and weigh up the options/risks.

Thanks for the responses.

We use SyslogNG clusters to centrally manage our syslog from about 6500 mixed Cisco device types and use it to forward to our active/active pair of LMS 3.01 clusters.. its trivial to set up a timed delay for one recipient so that they indeed arrive at thier respective desitnations at different times. Just offset the arrival by a typical collection cycle's breath.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco