ISE VMs - again....

[dazza_johnson]

Background - ISE v2.2 deployment for guest central web auth and 802.1X (EAP-TLS). Consists of dedicated PANs, MnTs and PSNs (2xPANs, 2xMnT and 12xPSNs) in a distributed deployment. Initially licensed for 20k users, to scale to at least 40k.

My customer is balking at the 64GB RAM for the SNS-3595 OVA file.... I've since turned my attention to the SNS-3495 which I believe supports 40 x PSNs and up to 250,000 active sessions (clients).

My question is, if I build the PAN and MnT VMs using the SNS-3495 spec (i.e. 32GB RAM), can the PSN VMs be deployed using the SNS-3515 spec (i.e. 16GB RAM)? The PSNs don't require as much resources as the PAN/MnTs (I think), so hopefully with the PSNs using a lower spec (half the RAM) this is still considered supported and indeed a good idea to save wasting resources?

Any comments are welcome. Note: I "have" read the Cisco Live "BRKSEC-3699" presentation slides.

Thanks

DJ

[Timothy Abbott]

Darren,

The resources are not wasted.  ISE deployments need those resources to be available when needed which is why it is a requisite to have reservations set.  The scale number you are using (250K) for the 3495 is under the assumption that all nodes in the deployment are of the same type (3495).  If you use a smaller platform (which is supported) you lose scale. I don't believe what you are proposing is an unsupported configuration so long as you have reservations set and understand you won't scale to 250K which is sounds like the customer doesn't need anyway.  Criag (chyps) might have some additional information.

Regards,

-Tim

[Craig Hyps]

In general, lowering the specs of your VMs to avoid the incremental cost of memory is not the best approach.  Do not risk success of deployment due to cost of memory which is likely the least expensive component in the equation.  If wish to size the PSNs down and per-PSN scaling is well within the session requirements, then that is more understandable, but recommend not skimp on PAN and MnT resources to save a few dollars. 

All that being said, you indicated 20k sessions and expanding to 40k.  You can start with lower specs when deployment smaller and less activity and then later scale mem up.  In other words, plan on higher mem allocation up front, assuming stay within the scale requirements and not experiencing any resource issues, but allow for increase later on.  It will likely not be necessary to allocate all up front.  I will say that there is definitely a noticeable difference in Admin UI responsiveness, Live displays, and Reports with higher CPU/MEM.

If followed my session, you will know that in the case of ISE resource allocation, over-subscription is not one of the reasons to deploy ISE on a virtual appliance.  There are certainly other virtual appliance benefits, but do not expect to get 5 servers with the resources of 1.

Hope that helps.

Craig

[dazza_johnson]

Thanks for the comments chyps and tiabbott, much appreciated.

One of the challenges I have is the customers existing deployment has 32GB memory and from the CLI 'show memory' output they can see that only half is used. What they say, is we are losing 16GB of memory (per ISE node) because it is assigned solely for each ISE node (thick provisioned as per Cisco guidelines). Its a reasonable question and difficult for me to say it simply needs to be there in case it needs it (sounds a bit vague and unconvincing to me...).

Can you answer the following queries please;

1. Can you add memory restopectively to ISE VMs? I know you can't add HDD to ISE VMs retrospectively, something to do with the way the HDD is partitioned - but not sure on memory (should be fine with worth asking). That way we can use 16GB on PSNs and if required increase the memory as the deployment grows/needs it.
2. OK, so 250,000 is the scale if all nodes are 3495s. The scale is reduced using different builds. So my question is, if I use 3495s as PAN/MnT (dedicated nodes) and 3515s (16GB) as PSNs, what is my max number of PSNs and endpoints become? I couldn't find an answer on any document. I want to explain to my customer that using all 3495s is 40 PSNs and 250,000 clients, but using 3495s as PAN/MnT (dedicated nodes) and 3515s (16GB) as PSNs reduces the scale to x PSNs and y clients.

Thanks

DJ

[Craig Hyps · Accepted solution]

I cover this topic in some depth in Cisco Live session BRKSEC-3699 (Reference version available on ciscolive.com).  In that session, I specifically call out "Customers with VMware expertise may choose to disable resource reservations and over-subscribe, but do so at own risk."

This is to specifically address customers who have teams which can properly and promptly address any resource constraints.  From experience, if customer does not have the necessary resources pre-allocated and hit a resource issue, it becomes a serious problem if they have already max'ed out their allocations.  It can then have a significant impact on all network access and often the focus returns to Cisco and why we did not properly call out the risk.

1. Yes.  This was just reviewed in another post this week. (Virtual ISE - VMware Resource Upgrade). 
   CPU and memory can be detected after stop VM, but disk cannot and any changes require reimage from fresh image install from iso file.  That is why we released new OVAs based on larger disk sizes starting in ISE 2.2. 
   
   Thick provisioning is primarily recommended for MnT since the space will continually expand until log data needs to be purged.  Thick provisioning will reduce performance issues during initial expansion.  In comparison, pxGrid and PSNs have minimal disk growth after install so disk provisioning settings will have much less impact.
   
   Also not caveat in prior post that some property settings are detected during persona changes and adjust allocations based on the detected appliance resources. 
   
   
2. This info is covered in ISE installation guide and Community page here. ISE Performance & Scale
   Any PSN can be deployed in a distributed configuration.  Only the PAN and MnT determine overall deployment scale, and of course the max capacity of individual PSNs.  Deployment capacity trumps all.  In other words, if have 3495s with (20) 3595s as PSNs, the max capacity of deployment is still 250k, not 20 * 40k.   And again, the PAN and MnT are the last nodes where you want to skimp on resources.  Max scale is always based on a somewhat "clean" environment and too often there are extreme conditions where you want every bit of performance on these critical nodes.

Craig