Cloud Gateway
Containerization
Introduction
Like any software, IdentityIQ installations require various computing resources for operation. While each installation may
have different functional requirements, we can make generalizations for physical or virtual hardware that work for most
situations. The aim of a sizing guide is to help an IdentityIQ customer answer the simple question: What computing
resources must we purchase or allocate to support IdentityIQ? While this question requires some analysis of site-specific
performance goals, the vast majority of installations do not need a complicated review to arrive at a hardware
recommendation for an IdentityIQ system.
For software sales or deployment professionals, the process of creating a hardware sizing recommendation is a process of
gathering functional requirements of how IdentityIQ will be used and then producing a diagram with specifications for
hardware that IdentityIQ will run on. Recommendations herein do the majority of that work for you and introduce a simple
process for doing hardware sizing via common "footprints". Guides for determining which footprint an IdentityIQ installation
should be using are provided below.
Virtualization questions may arise, and despite this document mentioning "hardware", realize that is a generalized term for
discussion about compute resources. Many customers of all shapes and sizes have virtualized all system components
(IdentityIQ hosts, database or DB servers, IQService, etc.). Furthermore, when cloud platforms are involved (e.g. Amazon
Web Services or Microsoft Azure), consider that we do have specific recommendations for some platforms on our IdentityIQ
Performance Resources landing page. When in doubt, know that the hardware sizing advice here can be leveraged as a
starting point, regardless of hosting platform.
Hardware resource allocation also requires architecture strategy. Be sure to review our Recommended IdentityIQ
Deployment Architectures document in tandem with this guide.
Performance tuning is an important part of any deployment. Consider our related resources here when planning: IdentityIQ
Performance Resources.
While this guide is targeted at currently-supported versions of IdentityIQ, many of the recommendations here apply to early
versions as well. See the IdentityIQ End of Life Policy for more details on what constitutes a current IdentityIQ version.
Hardware Footprints
IdentityIQ installations come in many shapes and sizes. Experience has shown that over 95% of IdentityIQ installations can
be easily grouped into one of five "footprints". A footprint is a hardware deployment topology that supports an IdentityIQ
installation of a certain scale. The five footprints in the table below represent the most common installation layouts used
with IdentityIQ. These specifications target a 2-3 year life cycle for reasonable growth of the system.
All but the smallest scale deployments separate the function of serving responses to user interface requests (UI) from the
function of performing long-running background tasks (task/batch). The most straightforward way to segment these roles
is to use multiple servers (VMs or physical), each assigned a function category. These two tiers are commonly called "UI
servers" and "batch/task servers". The terms "presentation layer" and "background layer" are also used, respectively.
Separating these two functions provide many performance and redundancy benefits, and this is highlighted in our footprint
sizes of medium and larger.
Consider that SailPoint no longer recommends the use of 32-bit Java or operating systems. 64-bit hardware and software
is recommended for all installations, regardless of footprint.
Storage space (i.e. block storage or disk) recommendations do not account for operating system minimums. Numbers
provided here are only for IdentityIQ or related software aspects. Please consider this when quoting storage and add
additional space as needed for your operating system platform.
Refer to our Performance Management Guide for IdentityIQ to clarify details regarding various CPU, memory, and storage
recommendations.
Footprint Description
Very small, non-production installations of up to 5,000 Identity objects. An "all in one" platform can be
Micro used to meet this requirement. This single host would include the relational database management
system (RDBMS or DBMS) and servlet container necessary to support IdentityIQ.
Installations of up to 10,000 Identity objects. This size may utilize a "matched pair" of hosts to provide a
Small
form of redundancy.
Installations from 10,000 to 50,000 Identity objects. These can be configured as a 2, 3, or 4 host
Medium configurations. In many cases, roles for UI and Task functions are broken apart onto separate IdentityIQ
hosts.
Installations of 50,000 to 500,000 Identity objects. These are most frequently configured as 2
Large UI/Presentation servers, 2 Batch/Task servers, and 1 DB server. In some cases, customers may also
create an active/passive architecture to create a disaster recovery environment.
Short for "Please call SailPoint!"; applies to installations over 500,000 Identity objects. These are the extra
large installations that usually start off with a large footprint and then expand based on site-specific
Call needs. Installations at this scale may involve 3 to 8 Task servers and/or 2 to 5 UI servers, depending on
use cases involved. Installations of this size require a solution architect's review of the use cases to help
specify additional servers based on the needs of the installation.
Micro Footprint Installations
These are the smallest installations of IdentityIQ, usually used for sandbox or development environments. All components,
including the RDBMS, servlet container, and IdentityIQ, are all running on one operating system image. The virtual machines
(VMs) used in SailPoint's training classes and on many developer's workstations are examples of micro footprint
installations. Installations of "micro" scale should not be used for production use because they lack redundancy and
scalability features.
1 x combined DBMS & IdentityIQ host, with:
1-2 CPU
2 GB of memory, 4 GB or more preferred
40 GB of block storage for IdentityIQ binaries, logs, and DB
Note: A micro footprint installation might not involve a firewall as shown in the diagram when it is installed as a virtual
machine on a developer's PC/Mac and accessed only by a single, local user.
Small Footprint Installations
These are installations of IdentityIQ designed for relatively small enterprises. These installations can chose to separate the
DB functionality to a separate host or run it alongside one of the IdentityIQ application server instances. These are usually
specified as a pair of virtual machine images or physical servers. Both hosts in the pair of servers accept UI traffic and run
task/batch operations. At this scale, the batch operations rarely put noticeable load on the hosts.
2 x IdentityIQ hosts (one combined with RDBMS), each with:
4 CPU
8 GB of memory
50 GB of storage for IdentityIQ binaries and logs
250 GB of RAID-protected DB storage
Medium Footprint Installations
These installations fit most medium-size enterprises and start to separate the UI and batch/task layers for performance
benefits, typically designating two UI hosts and two batch/task hosts. Installations at this scale often have a substantial
volume of data to process during account aggregation tasks. Thus, this scale requires the separation and dedication of a
relational database host. Load balancing systems are also strongly recommended with medium configurations to provide
for load distribution and redundancy at the UI layer.
2 x IdentityIQ batch/task hosts, each with:
4 CPU
8 GB of memory
50 GB of storage space for IdentityIQ binaries and logs
2 x IdentityIQ UI hosts, each with:
4 CPU
8 GB of memory
50 GB of storage space for IdentityIQ binaries and logs
1 x Dedicated DB server host, with:
8 CPU
64 GB of memory
500 GB of RAID-protected DB storage
Large Footprint Installations
Large installations of IdentityIQ include enterprises that manage up to half-a-million Identity cubes. These installations
usually have material requirements and service level agreements for aggregation times and responsiveness of the
application; performance tuning may be required to meet project goals. Load balancers for the UI layer should be
considered a requirement. In addition, many customers opt to have a database cluster, thus, our notation here about one
database host is simply the minimum for system design; the sample diagram shows a database cluster with asynchronous
replication, which is more robust. Implementers that decide additional capacity is required beyond our initial estimates
here are advised to first keep the compute resources of the database host constant while adding one or two batch/task
and/or one or two UI servers; this is equivalent to horizontal scaling.
2 x IdentityIQ batch/task hosts, each with:
4 CPU
16 GB of memory
50 GB of storage space for IdentityIQ binaries and logs
2 x IdentityIQ UI hosts, each with:
4 CPU
8 GB of memory
50 GB of storage space for IdentityIQ binaries and logs
1 x Dedicated DB server host, with:
16 CPU
128 GB of memory
1 TB of RAID-protected DB storage
Database clustering highly recommended
