SMGR with Geo 8.1- defining SAN 2

[bankingguy]

Hi,

I have 2 SMGR. 1 will be main and the other one will be Geo. I'm trying to create a csr file for this SMGRs. My confusion is:

1. When we first power up the OVA, it will ask us to define the FQDN and VFQDN
2. I'm confused if i need to define the VFQDN of the 2 SMGR or just one?
3. Do i need to define the Geo redundant FQDN + VQDN on the csr file I'm doing in the main or
4. Do i need to create 2 csr file for 2 SMGR - where i only define the FQDN of the SMGR + VQDN.

 

[kyle555]

the vfqdn is shared.

Are you using your own certs across the board or letting SMGR sign them?

I'd say just spin up 2 in a lab and look at their respective certs and figure that's what you'd want them to look like if you wanted to do them yourself.

Read this

https://downloads.avaya.com/css/P8/documents/100144833

 

[bankingguy]

Hi Kyle555,

when you say shared VFQDN, do you mean the VFQDN i configured in the 1st SMGR is the same VFQDN im going to configure in the Geo SMGR?

 

[kyle555]

Yes.

Say we got smgr1.bank.com adn smgr2.bank.com

When you install smgr1 and it asks for the VFQDN, you might put vsmgr.bank.com.

When you install SMGR2, there's nothing different about the initial deployment - you deploy the OVA with NTP/DNS/ smgr2.bank.com as FQDN and vsmgr.bank.com as the VFQDN. It comes up, you patch it to the same level as the primary, and you finally get to the web interface and go to Geo-Redundancy and that's when you point him to smgr1.bank.com

Bear in mind that GeoRedundant System Manager is only as good as the network elements you have that support georedundancy. Suppose we got data center 1 and 2. CM Duplex at DC1, ESS at DC2.

Suppose DC1 goes dark. So, right off the bat, it'll be fine to show you the state of the SMs at DC2. Still, you can't save translations on a ESS, so it's not like you're going to keep adding users with it. Aura Messaging has a single MSS where you build users, so while DC2 might take calls and voice messages during the failure, there's no real interface to add mailboxes either. Unless you're running some Mutare message mirror for a standby MSS, but if you were, you'd have to repoint the application servers at DC2 to use the standby MAS at DC2 and that takes time.

Speaking of taking time, GRSMGR needs to activate and restart. On a basic failover test for a customer between a DC1 and DC2 where we just turned off SMGR1 with GRSMGR/SMGR2 at DC2 talking to CM at DC1, it took us just under an hour to activate and bring him live and add a phone. Another hour to flip back to the primary.

Under the hood, what happens is the database replication nodes are made to the virtual FQDN. So, before GRSMGR, you'd install smgr1.bank.com with no VFQDN and the replication software - symmetric DS - would have a node in its table as smgr1.bank.com. SMGR1 would also generate a certificate from the internal authority for CN and SAN smgr1.bank.com. Because all management and replication traffic is encrypted and secured by certificates, your SMs or anything else would need to point to the IP of SMGR1 with bank1.smgr.com either through the hosts file or DNS.

Enter GRSMGR - it's just another SMGR, and it's cert is for CN smgr2.bank.com with SANs smgr2.bank.com and vsmgr.bank.com, just like how bank1 has SANs smgr1.bank.com and vsmgr.bank.com. Within the elements like SM that are geo-aware and geo-capable, they ultimately always point to vsmgr.bank.com with a sort of internal DNS priority mechanism that goes to smgr1.bank.com first and smgr2.bank.com next but under the pretense of either one representing vsmgr.bank.com - that's why the vfqdn's have to be the same on both machines.

As far as activating/deactivating georedundancy, it's a type of master/slave replication that's outside the normal DRS/symmetric DS replication the other apps use. That's why it takes an hour to turn up SMGR2 - you're telling it that it's not running a copy of the master anymore, but that it should reconfigure its stuff to be in charge of the database and come back up.

When the failure is corrected, you put smgr1 back live and I'd have to look at the docs, but I believe the choice is either to grab the delta of what happened in SMGR2 and call that the authoritative data set or to turn down SMGR2 and carry on with the data it had before failure.

You'd only be looking at turning up a GRSMGR during a rather long failure.

In any case, if you're comfortable letting SMGR be the CA, don't think about it too much. If you want to issue all your certs from your CA, go ahead, but read the doc meticulously. Bear in mind that I think you always start from scratch to patch/upgrade - like break geo and remove the 3rd party cert and upgrade it as if it were a standalone SMGR using its own CA and then build the second all over again.

Are you hellbent on not using the SMGR CA?

 

[bankingguy]

Hi Kyle,

I'm going use 3rd Party CA. Thank you for your help.

 

[kyle555]

You can use SMGR internal certs for the management traffic and just use 3rd party on the SIP interfaces on SM and client facing things if that's any easier. Otherwise, it's not a pleasant experience. You've been warned!

 

[bankingguy]

Haha, i know... But i don't have a choice. Its mandatory.
Thank you again.

 

[HUGWideBoy]

bankingguy,

Did you get this to work ? we've been trying to do the same for the last couple of months with no joy at all (read the manual Kyle555 suggested)

also "Certificate Management for Avaya Aura® System Manager 8.1.x June 2019" (don't get me started on the typos, incorrect information or completely wrong commands in this manual)

We've come to the conclusion the SMGR just won't work with 3rd party certificates or the process is so far removed from the documentation that it's beyond us.

I'm now looking to make SMGR a subCA of our corporate CA (this has also not gone down well, as it was "mandatory" for us to just use the 3rd party certs)

 

[bankingguy]

Yes, the Virtual FQDN needs to be the same when you initially configure / upload the OVA on both SMGR Main site and DR site. Now when you generate the 2 csr file (one for Main one for DR), you have to define the same VFQDN on the SAN field.