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

Distributed deployment PSN scale

mitchp75
Level 1
Level 1

The performance and scale document shows that the max number of PSN's in a deployment is 40 for a 3495 as PAN and 50 for a 3595 as PAN.....In a VM environment of 2.3 with an OVA for 3495 on all does this mean that you can re image each admin node with a 3595 OVA to extend to 50 leaving the PSN's alone with 3495 images? We're at 39 Nodes that include 2x admin and 2x MnT, 35 PSN's so I'm trying to plan ahead what adding 5 more PSN's may look like.

 

Also do Node Groups lower or raise that number?   

3 Accepted Solutions

Accepted Solutions

Nadav
Level 7
Level 7
Pretty much. PSN scalability is a factor of PAN and MnT sizing, just make sure they are on dedicated nodes.

View solution in original post

For years we have been stating this method

You can change the CPU and the memory on a VM just not the disk (build a new node and add to the deployment to replace the node)


Node groups are used for performance and doesn’t change scale. Please see ise performance and scale Cisco live on this page

 

https://community.cisco.com/t5/security-documents/ise-training/ta-p/3619944

View solution in original post

I think your TAC case likely on some older ISE release. I am pretty sure ISE 2.4 will adjust the parameters after the CPU/RAM resized. Even an older ISE release will update the parameters if a change made to the persona(s) of the ISE node.

Besides the optimization done with the system parameters, ISE and the underlying Linux will still take some advantage of the enlarged RAM allocation.

View solution in original post

12 Replies 12

Nadav
Level 7
Level 7
Pretty much. PSN scalability is a factor of PAN and MnT sizing, just make sure they are on dedicated nodes.

Hi,

I guess instead of reimaging the VM, you can extend the VM sizing similar to 3595.

 

-Aravind 

-Aravind

I've heard that's ill advised.

Check out:
https://www.ise-support.com/2017/12/23/vmware-and-cisco-ise/

Oh great! thanks for correcting me Nadav!
-Aravind

I would like to know how the claim "ISE doesn't use the extra CPU/memory" was verified.  If I shut down a VM and change the memory/CPU, start it up again and look at the ISE counters it correctly recognizes it, i.e. it goes from UCS_Large to SNS_3595.

For years we have been stating this method

You can change the CPU and the memory on a VM just not the disk (build a new node and add to the deployment to replace the node)


Node groups are used for performance and doesn’t change scale. Please see ise performance and scale Cisco live on this page

 

https://community.cisco.com/t5/security-documents/ise-training/ta-p/3619944

The documentation states that it can be, but at least two different blogs have stated that it will likely cause adverse effects:

 

https://www.network-node.com/blog/2017/10/7/ise-design-going-above-the-configuration

https://www.ise-support.com/2017/12/23/vmware-and-cisco-ise/

 

Maybe they're wrong, maybe they aren't, but that's their experience even though the documentation clearly says otherwise. It would be interesting to know how they came to their conclussions. Any chance you can chime in @katmcnam (the first blog is hers)?

The only issue I know about is if you change the memory and CPU is you have to modify the reservations as well. I have had customers increase memory but the reservations was still at the old memory and worse yet it was limited to that size. So you go from 16 GB to 64 GB but the reservation is set and limited to 16 GB. All sorts of issues can happen when a VM is limited to less than the maximum memory.


From what I was shown by a TAC engineer during troubleshooting, and they had to get root access to the file system, the sizing is written to a config file during ISE install/setup. It reads the virtual hardware and sets all of the configuration limits (ie database performance/resources) based on those. The configuration file doesn't get re-written if you shut down the VM, add CPU/RAM, and start it back up. All of the old limits are in place even with the additional hardware. Hence, "ISE doesn't use the extra CPU/memory" as in it is not fully utilized.

I think your TAC case likely on some older ISE release. I am pretty sure ISE 2.4 will adjust the parameters after the CPU/RAM resized. Even an older ISE release will update the parameters if a change made to the persona(s) of the ISE node.

Besides the optimization done with the system parameters, ISE and the underlying Linux will still take some advantage of the enlarged RAM allocation.

I would need to see proof that it works before I could recommend my customers do it. Based on the previous experience (it was with 2.3), it doesn't work that way because ISE does not take advantage of the new hardware due to the configuration file that was written based on the previous hardware settings. Nothing was brought up in that TAC case about making it work by changing the persona and then changing it back. The TAC engineer was adamant that a reinstall would be needed in order for the configuration to be valid and ISE take advantage of the new hardware.

If you provide the TAC case SR number, I may review its case notes. Below is from my ISE 2.4 system ADE.log:

 

2019-01-10T18:01:07.531147+00:00 myISE24 root: info:[application:operation:platformproperties.sh] 2019-01-10 18:01:07 INFO PlatformProfileServiceImpl:599 - Gathering platform-specific properties
2019-01-10T18:01:07.532810+00:00 myISE24 root: info:[application:operation:platformproperties.sh] Old Memory Size : 16267592
2019-01-10T18:01:07.584407+00:00 myISE24 root: info:[application:operation:platformproperties.sh] 2019-01-10 18:01:07 INFO PlatformProperties:61 - PlatformProperties whoami: root
2019-01-10T18:01:07.585786+00:00 myISE24 root: info:[application:operation:platformproperties.sh]
2019-01-10T18:01:07.619669+00:00 myISE24 root: info:[application:operation:platformproperties.sh] 2019-01-10 18:01:07 INFO PlatformProperties:103 - PlatformProperties{udiPid='ISE-VM-K9', udiVid='V01', udiSn='***********', memorySizeKb=16267592, numberOfCpuCores=2}
------------------------ Power Off; Change CPU core number from 2 to 12; Power On ----------------------------------------
2019-01-10T18:17:38.533482+00:00 myISE24 logger: info:[application:operation:platformproperties.sh] 2019-01-10 18:17:38 INFO PlatformProfileServiceImpl:599 - Gathering platform-specific properties
2019-01-10T18:17:38.540387+00:00 myISE24 logger: info:[application:operation:platformproperties.sh] Old Memory Size : 16267592
2019-01-10T18:17:38.822093+00:00 myISE24 logger: info:[application:operation:platformproperties.sh] 2019-01-10 18:17:38 INFO PlatformProperties:61 - PlatformProperties whoami: root
2019-01-10T18:17:38.823872+00:00 myISE24 logger: info:[application:operation:platformproperties.sh]
2019-01-10T18:17:38.890699+00:00 myISE24 logger: info:[application:operation:platformproperties.sh] 2019-01-10 18:17:38 INFO PlatformProperties:103 - PlatformProperties{udiPid='ISE-VM-K9', udiVid='V01', udiSn='***********', memorySizeKb=16266128, numberOfCpuCores=12}
2019-01-10T18:17:53.756732+00:00 myISE24 logger: info:[application:operation:platformproperties.sh] Old Memory Size : 16267592
2019-01-10T18:17:53.865711+00:00 myISE24 logger: info:[application:operation:platformproperties.sh] node-config.rc has been modified - rebuilding active properties file
2019-01-10T18:17:53.869203+00:00 myISE24 logger: info:[application:operation:platformproperties.sh] Getting profile properties for profile 'sns3515' and persona 'standalone'