IAM Deployment Guide

Table of Contents

• Introduction
• IAM Cluster
• Production System Requirements
• High Availability
• Scaling IAM
• IAM Performance
• Network & Firewall
  • Ports
  • Firewall
  • Network

Introduction

• IAM can run on instances of any size with any resources. While the system requirements vary significantly depending on the use-case, generally speaking, we recommend to start big and then gradually reduce the instances to the appropriate number and size.
• When allocating resources to an IAM cluster, slightly over-provision the cluster to make room for request spikes.

IAM Cluster

• Regardless of the datastore being adopted with IAM, the IAM nodes themselves need to join in a cluster. The IAM nodes will talk to each other via their connections to the database. Please refer to the clustering reference for more details.

Production System Requirements

• For IAM, prefer CPU optimized instances. We recommend at least 4 CPU cores, 16GB of RAM and 24GB of disk space. IAM performs better on a system with multiple cores. In an AWS environment, we recommend running c4.2xlarge instances in production that guarantee enough cores (8) and memory (16GB).
• For the database, prefer memory optimized instances. Assume more intensive workload on the datastore if you are using the rate-limiting or response rate-limiting plugins with a “cluster” policy. Use this only if Redis is not an option. High ulimit value, possibly >=65535. A higher limit value will allow IAM and the datastores to process more incoming requests.

High Availability

• Instances with multiple cores are required. IAM, by leveraging the underlying Nginx runtime, will start a worker process for each core. On systems with multiple cores a worker crash will not badly affect the system since the other workers can process the ongoing HTTP requests until the crashed worker is being automatically replaced with a new one.
• At least 2 nodes/instances of IAM, behind a load balancer (Nginx, HAProxy, AWS ELB or similar). This prevents downtime if an IAM node crashes, since the other nodes can process the incoming HTTP requests. The number of instances behind the load balancer should increase with the number of incoming requests, to avoid the scenario when after a node crashes the sudden increase of load to the remaining nodes will effectively DDoS them and make the other nodes crash too.

Scaling IAM

• IAM is stateless and more nodes can be added behind the load balancer to scale the system. Incoming HTTP/s requests can be processed by any server, and that also includes the IAM's Admin API.
• Every new IAM node should target the same datastore, and join the existing IAM nodes in a cluster. Failure to join the IAM nodes in an IAM cluster will result in data inconsistencies and errors when processing requests. IAM automates joining a node in the cluster as long as the right configuration settings have been provided. For more information, we recommend reading the clustering reference.

IAM Performance

The performance of IAM varies depending on multiple factors, including:

• Network latency from the client to IAM, and from IAM to the final upstream servers, greatly affects the performance. The faster the network, the better IAM will perform in pretty much every aspect, including system resources.
• Number of incoming HTTP requests and the size of requests and responses that have to be processed.
• Response time from the upstream server. The fastest the upstream servers can process a request, the faster IAM can process the response back to the client and free up resources to handle more incoming requests.
• The number of plugins that are being executed. The more plugins, the more processing time IAM will require when proxying requests.

Network & Firewall

In this section, you will find a summary about the recommended network and firewall settings for IAM.

Ports

These are the port settings in order for IAM to work:

• Allow HTTP traffic to proxy_listen. By default, 8000.
• Allow HTTPS traffic to proxy_listen. By default, 8443.
• Allow HTTP traffic to admin_listen. By default, 8001.
• Allow HTTPS traffic to admin_listen. By default, 8444.

For IAM Manager:

• Allow HTTP traffic to admin_gui_listen. By default, 8002.
• Allow HTTPS traffic to admin_gui_listen. By default, 8445.

For the Dev Portal:

• Allow HTTP traffic to portal_gui_listen. By default, 8003.
• Allow HTTPS traffic to portal_gui_listen. By default, 8446.

Note: since IAM CE 0.13.0—and EE 0.32—listen directives have a new format, described here, where instead of specifying SSL and non-SSL ports in different configuration directives—e.g., admin_listen and admin_listen_ssl—only one is required: for example, the listen directive for the Admin API for SSL and non-SSL ports now looks like:

0.0.0.0:8001, 0.0.0.0:8444 ssl

Other listen directives comply to the new format.

Firewall

Below are the recommended firewall settings:

• The upstream APIs behind IAM will be available on proxy_listen. Configure listeners accordingly to the access level you wish to grant to the upstream APIs.
• Protect admin_listen, and only allow trusted sources that can access the Admin API.

Network

• IAM assumes a flat network topology in Multi-DC setups. If you have a Multi-DC setup, IAM nodes between the datacenters should communicate over a VPN connection.
• IAM will try to auto-detect the node's first, non-loopback, IPv4 address and advertise this address to other IAM nodes. Sometimes this is not enough and the IP address needs to be manually set, you can do that by changing the advertise property in the cluster configuration.