cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
658
Views
6
Helpful
7
Replies

Transition from Two-Nodes design to Large-Distributed design

iurikura
Cisco Employee
Cisco Employee

Hi Team,


Could you please let me know there is any migration guide that explains how to transit from two-nodes design to large design?

Especially, I'd like to know the procedure and service impact.

I understand when an ISE changes its persona, application will restarts and it could take abt 15-30 min.


When adding PSN dedicated nodes to ISE Minimum HA deployment, ( => A,M and P nodes finally should change to A and M nodes)

- which node should I firstly change its role?

- is there any other user impact?


Customer is using RADIUS and Guest Service features.


Thank you,

Itaru

1 Accepted Solution

Accepted Solutions

That is fine whichever path you choose.  Note that the original nodes likely have more disk assigned to them (600GB+) since running MnT role.  The PSNs typically do not require more than 200GB, so if operational cost of changing NAD configs is significant, then you can live with the over allocation of disk to the PSNs.  The only way to free up that space on VM is to reinstall.

View solution in original post

7 Replies 7

paul
Level 10
Level 10

Well not knowing your certificate setup, I would tackle it this way:

  1. Plan on leaving the two current nodes as the PSNs when all is said and done.  That means you don't need to change the network devices.
  2. Build a new node that will be the primary admin and M&T in the expanded deployment.  Bring it up to the patch level of the current deployment
  3. Get all the certs setup correctly on that new node.
  4. Remove the Admin and M&T role from the 2nd node in the current deployment. This will cause a service restart but there should be no disruption to service because everything should be pointed at both ISE nodes.
  5. Add the new Admin and M&T node into the deployment making it primary for M&T and backup for Admin.
  6. Add the new node to Active Directory.  At this point you have one node that is running as dedicated PSN.
  7. Log into the GUI of the new node you added and promote it to the the primary admin node.  This will cause a service restart on the new node plus the original Admin node.  Again this shouldn't cause an outage because the PSN only node is there to authenticate.
  8. Build your 4th node.  Patch it to the level of the deployment.
  9. Get all the certs setup correctly on the 4th node.
  10. Remove the Admin and M&T role from the original primary Admin node.  This will cause a service restart but shouldn't cause disruption.  At this point the two original nodes are just PSNs.
  11. Add the 4th node to the deployment making it backup for Admin and primary for M&T.
  12. Add the 4th node to Active Directory.

Done and Done.  Now you can break out Admin and M&T onto nodes 5 and 6 whenever you want without restarting any of the PSNs.

Paul, In general, I would make same node active for PAN and MNT functions.  However, question was to build out a large deployment where all nodes are running dedicated personas.  By keeping the original PAN nodes the same, you reduce the number of service restarts and do not impact the cert trust store for root CA and trust.

Yes, new PSNs will need to be joined to AD.

/Craig

Craig,

If you are doing my cert steps right there is no issue moving the PAN functions to the new nodes. I agree on the service restarts. I guess it comes down to touching NADs or living with the service restarts. You could definitely go from 2 to 6 using the same methodology I laid out and leave the PSNs the same.

On your same not active for PAN and MNT, if the nodes are at the same site on the same subnet would you always recommend that? Don’t split the processing load between the nodes?

Thanks for the feedback.

Paul Haferman

Office- 920.996.3011

Cell- 920.284.9250

Both MnT nodes are always processing all logs, so load on primary and secondary MnT essentially the same.  Admin UI retrieves the log and reporting info from Primary MnT, so balance between local fetch load vs network latency/load.  The secondary PAN/MNT is often at a different location for HA reasons, so need to take into consideration the network factor for retrieval of remote server data.  If nodes in same DC, then it may have some benefit to splitting, but we don't have any QA testing that has measured the impact.

/Craig

Thank you so much, Paul.

I'd like to do the way Paul taught because the difficult point is to keep all the NADs's configuration as same after adding two dedicated PSN nodes.

They have 1,000+ NADs in real traffic and are not willingly to change their configuration.

Creig,

Thank you for your comment.

Sorry for my insufficient explanation.

Actually customer is planning to add add two dedicated PSN nodes to minimum design.

No Mnt dedicated nodes are required currently.

That's why I focused on "( => A,M and P nodes finally should change to A and M nodes)".

I understood in theory ISE can transit its design from minimum HA to distributed deployment.

Thank you,

Itaru

That is fine whichever path you choose.  Note that the original nodes likely have more disk assigned to them (600GB+) since running MnT role.  The PSNs typically do not require more than 200GB, so if operational cost of changing NAD configs is significant, then you can live with the over allocation of disk to the PSNs.  The only way to free up that space on VM is to reinstall.

Craig Hyps
Level 10
Level 10

If have a window where you can allow for the temporary service outage, I would recommend start with the registration of the dedicated MnT nodes, and then proceed with the registration of dedicated PSN nodes.  This would allow all changes to be applied in less than an hour, but you will need to configure NADs to point to new PSN(s).  If configure them beforehand, then the NADs can failover to new PSNs if original IPs no longer respond to RADIUS requests or health probes.

If unable to have a service maintenance window to make these changes, then shortest disruption would be to pick time during lowest activity, then register the new dedicated PSN(s).  You will then point the NADs to the new PSN IP addresses.  This will not impact existing sessions, but new sessions will be authenticated by new RADIUS targets. 

Once the existing NADs are pointing to new PSNs you can remove the PSN persona from the PAN/MNT nodes.  You can then proceed to registering the dedicated MnT nodes.  Then register the new Primary MNT node which will remove Primary MnT persona from existing Primary PAN. Finally, register the new Secondary MNT node which will remove the persona from existing Secondary PAN.  

Craig