Network Management

Hi All,

i have a few questions regrading the HP iMC HA installation.

I want over the PDF installation for HA but its not very understanding

we decided to go with 'Centralized deployment with DBMan for data synchronization' Deployment

meaning that we have an iMC server's (Active/Standby) with local DB .

my questions are:

• why do I need the External IP Address and Internal IP Address?

For what purpose exactly?

• On the section " Installation considerations " P# 25

The hac.conf is empty?

The document file link is:

http://h20566.www2.hpe.com/hpsc/doc/public/display?sp4ts.oid=4176520&docLocale=en_US&docId=emr_na-c04958702

thanks in advance

I looked at the document - on page 24 it shows the network diagram. This is the setup I am using. A primary active server, and a standby backup server with the data backed up nightly on the primary and copied to the secondary.. Both my primary and standby have IMC installed with a local DB. I use VMware for both, so each server can be backup in vmware as well.

I'm not sure if this is the configuration you are trying to deploy, but I can share how mine is setup. Attached are 3 screen shots - the network diagram from pg 24, and the DBman config screens from the active and standby server.

I did not use iHAT to configure this - it was not needed to set up this basic configuartion.

This is covered on page 81 in "HPE IMC Centralized Deployment Guide with Local Database" document:

- Setup FTP server on primary and standby. User home directory is the backups folder on the each

- On the active server, point to the standby server using the iP address of the standby. Select the tables to backup. Set a time to backup

- On the standby server, select files to restore.

This will run once a day and copy and restore the DB onto the standby server. The log file will show success or failure.

This configuration has the following advantages:
Standby server is covered as a backup license - no additional license required.
It will recieve alarms and traps if devices are configured to send to the backup server IP as well as the primary
It will process UAM requests, so users can be authtenticated by 802.1x or MAC
It can be upgraded separately from the primary and tested before upgrading the primary
Using VMware, the primary or secondary can be restored from snapshot quickly.

These disadvantages:
You cannot edit the configuration on the standby - no new nodes or changes.
Only the admin user is active- EDIT actually I checked again - other operators are active
It is not a true hot standby, with data synchronized up to the minute
Using VMware, when the primary or secondary is restored from snapshot there will be some loss of alarm and performance data.

If you need true HA, then the setup is more complicated, requiring iHAT to manage. I can not help you there.

But if you just need a failover to handle alarms and authentication, this will be easy to deploy.

Hope this helps - sorry if I did not address your requirement exactly.

Neil, what do you mean by

"Standby server is covered as a backup license - no additional license required."

How is this license activated?

Never heard this from HPE. :)

I must have read it in one of the docs, but can't recall which - DOn't think it was mentioned in the doc I refer to earlier.

To create a standby server, create a new server and deploy an identical configuration as your primary.

 - Unfortunately you can't clone it because imc has too many places where the ip address needs to be changed properly to bother with.

When you boot it up it will be in demo mode. When you go to log in press the Activate link above the login button.

At the License Information screen, Press Activate Now button - see screen shot

At the Register screen, Select Backup from the dropdown, and then supply the same license key used for the primary - see screen shot.

After this is complete, the server is now a backup imc server. Log into each server, and use the imc deployment tool to configure the backup as I showed earlier. Once the db has been restored, the configuration will be avaialbe on the backup.

The backup as I mention above, will mostly display information copied over, and can't be modified. The UAM related configuration can be deployed to the switches, as secondary radius settings need to be added for the backup to authenitcate users - or you can add manually using CLI on the switch. Most other config operations are disabled

Alarms can be viewed, but only recoverd all on the browse alarms screen - individual alarms can't be recover.

SNMP traps will be sent to the backup if the devices are configured to send to both.

All your devices will now also get queried by the backup over snmp and ping, so if you are restricting this you will need to grant access - otherwise they will generate more traps about unauth access.

Also, create a script to manage the number of backups stored on the standby machine - the deployment tool has a #to keep on the primary, but not the standby, so your disk will fill up.

Hi Neil,

i've a qiestion regrding the backup server license.

if my Active server will go down is the backup server will be ACTIVE?

If you mean will your backup server become an Active one if the active one fails? No it will not.

It is just a separate server sitting there running the same code. You can log into at any time and see what's there

It will respond same as a active IMC/Radius/UAM server, depending on the order you list in your devices, and if the primary does not respond and itwill authenticate users and assign vlans etc.

It will recieve traps and alarms and track devices using ping and snmp, but it is alreadly doing that all the time, as configured on your devices..

You can use any of the IMC functions in read-only mode, so you can view NTA or other data collected, alarms etc. - just can't add new or change configurations.

Every night or whenever, the backup database gets restored using from the active server, so anything added or deleted on the primary is now on the backup. During the day any changes made will create differences between them. But mostly that doesn't matter much - unless you have a lot of changes

iHA (iMC HA) in my opinion is the best way to deploy iMC in HA. This type of deployment is not limited by the number of the iMC group of servers or by the number of iMC servers in each group. iHA also is very much flexible in term in investement since you need to treat its licencing the same way you will approach a single iMC node and add on the top of it the HA license for the number of servers you want to deploy. iHA has its own (propriatary) cluster and combined with a remote database SQL always-on deployement you reach a high level of redundancy for iMC and for SQL. There is not more any requirement for the iMC dbman tool to backup the iMC database since it is all done on the SQL deployement.

Hi,

sorry for the late response, but by a chance do you know if the iMC HA support L3 meaning that Maser / Slave server will be in a different subnet and in a different sites?

Hello NeilR,

I've got the issue after configuration HA with DBman. I can see the following two alarms: 1. DBman failed to compare the version. 2. Failed to trasmit the file dbman_back.conf to the server. 

Have you configured FTP server ? Is Master Server IP of Backup System enouth to use DBman (correct confuguration on the agent-->environment-->Configure) on both installitions? May I see any examples for your dbman_addons.conf file? 

I use the same Linux(CentOS),MySQL, iMC versions for both installitions 

Regards,Alexey

Hello,

Can you please clarify which feature you mean by HA with DBman? Neil was describing Active-Standby Deployment with DBman, while iHA is a separately licensed feature in iMC with significantly more configuration required.

If you are referring to Active-Standby Deployment, you really just need a few steps to set it up:

1. Apply the license file from the Active system to the Standby system with license type "Backup" (this makes the system into a read-only standby)
2. On the Active system, on DMA Environment tab, click Configure and select Auto Backup Mode.
3. Enter the IP address of the Standby system as the "Master Server IP of Backup System", make sure your Backup Path exists and has enough free space, and all DBs are selected for both Local Backup and Upload to Backup System. Click OK to save the config.
4. On the Standby system, on DMA Environment tab, click Configure and select Auto Restore Mode. Again make sure the Backup Files Location has enough space on that system too, and all DBs are selected, and click OK to save.

iMC is now in Active-Standby deployment. It will transfer the files using SMB as far as I know - separate FTP setup and configuration should not be needed.

You can check the iMC\dbman\log\dbman_debug.log file after one day to see if the backup/restore was successful or not. Make sure you have the exact same components deployed and versions on both systems, or it will fail. This means the "Deploy" tab of DMA on both systems should be identical.

Hi @jguse 

I know this is a bit old. Quick question regarding primary/backup (stateless failover) you just described. Do both IMC instances need to be on the same IP subnet? I'd like to deploy this but ideally having both servers at two separate locations/different IP subnets. 

Hello @pattap 

I've usually only deployed and supported systems in this deployment model that ended up being in the same subnet, however I'm not aware of any restriction regarding this. The SMB transfer of the active system's backup to the standby system is configured by entering the IP address of the standby system in the DBMAN config, so as long as the active system can reach the standby via IP connectivity, that should work fine regardless of different subnet.

Alexey,

As Justin says, SMB is used to transfer the files between the servers.. FTP on the standby is not required.

On the pimary in the DBman configuration enter the ip of the backup server and validate. If validation fails then it means the installed modules on the standby server do not match the primary. Install all the same modules and patch versions.

create a directory to hold the backups on the primary and the standby server. I beleive it must exist prior to configuring. Set that path drive:\folder on the primary and check both sets of dbs to back up and upload. Select auto-backup and set a time. Allow an hour or two to complete depending on amount of data.

On the standby select auto restore, set the path for the files, and the db's to restore. The dbman process will continuosuly scan the directory for the files and once they are transferred from the primary, it will restore them. During restore the imc processes will shutdown and restart when complete.

Hi Neil 

I've just started looking into setting our IMC in similar way to yours.

I'm just wondering since on standby unit files are read only what happens when your active IMC fails? If I understand correctly with HP's tool that would provide a mechanism to detect the failure standby would just take over.

What is the process in your scenario and how much of functionality on the standby unit while the active is offline you have? Is it just a case of changing the license type  from standby to active within gui to make this instance of IMC fully functional?

Hi PattaP,

Some of what your get depends on what modules you are using. But the database is replicated nightly so your backup unit knows you configurations as of the last time it ran the backup. So it will continue to poll the devices it knows about and report errors based on polling, gather statistics, etc.

So you can use features like real time performance, any other performance views, real time location same as on the primary - you just can't change the configuration.

So i set my network devices to send traps to both and allow both to be accessed

I use uam to provide 802.1x and MAC authentication for all my user ports so that is one critical operation. Again i set both as authenticators on my network devices. Here IMC provides failover for the UAM processes, as the devices will interogate one and then on failure, the second one. UAM will continue to query LDAP on the standby. Some UAM processes are configurable on the standby so user sync and use managment is possible.

Alarms can be viewed but only cleared as batch not individually.

Launch of telnet, ssl and web clients to network devices is also possible.

So I just let both run in parallel. The only process I critically need to failover is UAM, and as both are active, the network device configuration handles that. 

I have not attmepted to move the active license to the standby, so can't comment there. I run these as VMs so I would likely just restore the primary and live with the loss of data if a failure so corrupted the primary. So far not been an issue.

lastly its handy for upgrades, as the upgrade processes take a while. I can do some testing by deploying on the standby first, and then if it looks good proceed to primary. Meanwhile authentication and alarming is still going on.