Planification de la capacité et Access Gateway.

La planification des capacités est une série de tâches que vous effectuez pour évaluer les besoins actuels et futurs en matière de consommation de ressources. Elle vous aide à déterminer les ressources système dont vous avez besoin pour répondre à la demande des utilisateurs, faire face aux pics de demande et vous développer à mesure que la demande augmente. La planification des capacités vous aide également à éviter les excédents de capacité inutilisés, qui font grimper vos coûts de stockage et de maintenance.

Les deux principaux facteurs de la planification des capacités sont le dimensionnement et la mise à l'échelle. Le dimensionnement correspond au calcul de la mémoire, de l'espace disque, de la puissance de traitement du processeur et de la capacité de débit nécessaires pour appuyer votre déploiement d'Access Gateway. La mise à l'échelle consiste à augmenter ou à réduire la taille d'un cluster Access Gateway pour optimiser la consommation des ressources système.

Pour planifier les capacités, déterminez votre taux d'accès actuel et utilisez les données de consommation d'Access Gateway pour extrapoler des scénarios de consommation futurs.

Cette rubrique fournit les données de consommation et la configuration requise pour Access Gateway afin de vous aider à effectuer des calculs pour la planification des capacités de votre environnement.

Estimer le taux d'accès actuel

Avant de pouvoir prévoir les besoins futurs en matière de consommation de ressources, vous devez établir une base de référence. Cette référence correspond au niveau de votre consommation actuelle. Calculez le nombre d'accès et d'authentifications que Access Gateway doit prendre en charge. Recueillez des données sur une période plus longue afin d'obtenir une plus grande précision dans vos prévisions futures.

Collectez les données suivantes de votre système de journalisation et d'autres sources :
- Le nombre maximal, minimal et moyen d'accès et d'authentifications pour la période considérée.
- Les heures de la journée et les jours du mois où la demande est la plus forte.
- Les heures de la journée et les jours du mois où la demande est la plus faible.
- le nombre total d'utilisateurs susceptibles d'accéder à Access Gateway ;
- Le nombre d'utilisateurs susceptibles d'utiliser une application quotidiennement.
- Le nombre de fois où les utilisateurs accèdent à une application chaque jour.
- Le nombre de consultations d'une page effectuées par chaque utilisateur au cours d'une même session.
- Le nombre d'applications qu'Access Gateway protège.

Utilisez les données que vous recueillez dans ces formulaires de calcul pour calculer les chiffres actuels du nombre d'utilisateurs et d'accès :

Nombre moyen d'accès	Nombre total d'accès
Utilisateurs moyens = nombre total d'utilisateurs ÷ nombre estimé d'utilisateurs quotidiens	Nombre total d'accès = nombre moyen d'accès x accès aux pages
Nombre moyen d'accès = nombre moyen d'utilisateurs ÷ nombre estimé d'accès quotidiens	Nombre moyen global d'accès = nombre moyen d'utilisateurs x accès par jour

Classez les utilisateurs en fonction de leur fréquence d'accès :
- Utilisateurs fréquents : accèdent au système cinq fois par jour ou plus.
- Utilisateurs occasionnels : accèdent au système une ou deux fois par jour.
- Utilisateurs exceptionnels : accèdent au système une à trois fois par semaine.
Calculez le taux d'accès type pour chaque groupe d'utilisateurs. Par exemple, si vous avez 5 000 utilisateurs fréquents et qu'ils accèdent au système cinq fois par jour, vous avez 25 000 accès par jour pour ce groupe.

Estimer les exigences matérielles

Le matériel fait référence à la quantité de mémoire et d'espace disque, au nombre de processeurs et de cœurs, ainsi qu'au niveau de débit dont vous avez besoin pour garantir des performances optimales pour votre déploiement d'Access Gateway.

Exigences de mémoire

Élément	Exigences minimales pour les environnements de production
Système d'exploitation, Access Gateway Engine et micro-services	1,5 Go
Sessions mises en cache	128 Mo
Taille moyenne des sessions	1 024 octets
Tickets Kerberos. Ces tickets peuvent être plus volumineux, en fonction du nombre d'applications IIS consultées.	1 024 octets

Calculer les caches des application Web et des sessions Kerberos

Pour calculer l'espace requis pour le cache de la session, multipliez le nombre total de sessions par la taille moyenne des sessions, puis doublez le chiffre.

Chaque session est calculée à partir du nombre d'utilisateurs, du pourcentage d'événements de connexion des utilisateurs par jour et du nombre d'applications auxquelles les utilisateurs accèdent.

Pour calculer l'espace requis pour le cache de la session, utilisez cette formule : Nombre total de sessions x (taille moyenne des sessions x 2)

Voici quelques scénarios qui montrent comment utiliser cette formule :

Utilisateurs	Pourcentage de connexions par jour	Applications consultées	Nombre total de sessions	Taille de la session	Cache de session
5 000	50 %	5	Pourcentage de connexions de l'utilisateur par jour × accès aux applications 12 500	1 024 octets x 2	env. 25 Mo
10 000	75 %	10	75 000	1 024 octets x 2	env. 150 Mo
25 000	50 %	100	125 000	1 024 octets x 2	env. 500 Mo

Les applications Kerberos ajoutent des exigences supplémentaires en matière de mise en cache.

Utilisateurs	Pourcentage d'événements de connexion par jour	Applications IIS consultées	Nombre total de sessions	Taille de la session	Cache de session
10 000	50 %	5	Pourcentage de connexions de l'utilisateur par jour × accès aux applications 25 000	1 024 octets	env. 50 Mo

Remarque :

Considérations relatives aux sessions :

Les sessions sont effacées à l'aide d'un algorithme Least Recently Used (LRU). Lorsque le cache est complet et que de nouvelles sessions sont créées, la session inactive la plus ancienne est supprimée.
L'enregistreur Surveillance de session génère des alertes pour les conditions où le cache est plein ou presque plein. Vous trouverez des statistiques dans l'Console de gestion Access Gateway. Pensez à augmenter la mémoire de l'appliance pour réduire l'impact des caches complets.
Tenez toujours compte des moments où les charges augmentent généralement : - Période de l'année où les employés sont inscrits - Matinées - Événements de connexion après le déjeuner

Espace disque requis

Access Gateway nécessite de l'espace disque dur pour les éléments suivants. Déterminez le nombre et la taille de ces éléments sur une période donnée :

Logiciels : le logiciel Access Gateway et le système d'exploitation. La taille du fichier logiciel est généralement petite.
Sauvegardes : effectuées la nuit et conservées pendant 30 jours. La taille des fichiers de sauvegarde est généralement petite.
System Log : les fichiers journaux sont mis en attente sur le disque local et comprennent les fichiers Authentification, Autorisation, Audit, Accès, Session et Tous les journaux. En général, il y a une entrée pour chaque requête HTTP/HTTPS. Tenez compte du nombre d'utilisateurs, du nombre de fois où les utilisateurs accèdent à des applications, ainsi que du nombre de pages qu'ils consultent pour cette application.
Archives de journaux : elles sont conservées pendant 30 jours et sont supprimées et compressées.

Calculer la taille et l'augmentation des entrées de journal

Utilisez ces calculs pour estimer l'augmentation potentielle de vos besoins en matière d'espace disque. Remplacez les chiffres de l'exemple par vos propres chiffres. Une règle raisonnable consiste à allouer le double de la consommation estimée, en ajoutant un peu d'espace supplémentaire pour les mises à jour logicielles, la configuration et les sauvegardes. Dans cet exemple, l'espace disque requis est d'environ 14 gigaoctets, auxquels s'ajoute une marge de 10 % à 20 %, soit une augmentation mensuelle d'environ 17 à 20 gigaoctets.

Nom unique de base de l'utilisateur	10 000
Taux d'accès	75 %
Applications par utilisateur	10
Accès par jour	Nombre d'utilisateurs × taux d'accès × nombre d'applications par utilisateur 10 000 x 0,75 x 10 = 75 000
Taille classique des entrées de journal (sessions authentification et autorisation Access Gateway)	1024 octets x 3 = 3072 octets
Augmentation de la taille du disque par jour	Accès par jour x taille typique des entrées de journal 75 000 x 3 072 octets = 76 800 000 octets, soit environ 230,4 mégaoctets par jour
Augmentation de la taille du disque par mois (30 jours)	Augmentation de la taille du disque par jour x 30 230,4 x 30 = 6,912 Go
Augmentation de la taille du disque par an (365 jours)	Augmentation de la taille du disque par jour x 365 = 84,096 Go

Remarque :

Considérations relatives au disque dur :

Surveiller les alertes de l'enregistreur en cas de faible niveau de disque pour éviter un avertissement concernant une taille de disque insuffisante en cas de pics ou de nombre maximum de requêtes. Le contrôle est exécuté toutes les heures et émet des avertissements à 70 % d'utilisation et des alertes à 90 % d'utilisation.
Chaque requête HTTP donne lieu à des journaux d'audit et d'accès.
Un débit plus rapide du disque améliore le débit.
La taille des sessions a une incidence sur la journalisation d'audit avec autorisation et les journaux d'audit contiennent le contenu des sessions.
Ne faites pas preuve de prudence lorsque vous calculez le dimensionnement du disque dur. Allouez le double de l'espace disque requis estimé pour éviter que les pics et les requêtes de pages volumineuses n'entraînent des avertissements relatifs à un espace disque insuffisant.

Processeurs et cœurs

Le moteur Access Gateway s'adapte automatiquement à tous les processeurs, ce qui se traduit par un travailleur par processeur. Chaque cœur supplémentaire génère un thread supplémentaire, ce qui permet d'augmenter la puissance de traitement.

Remarque :

Un nombre plus important de processeurs ou de cœurs améliore les capacités.
Le débit réseau est généralement le goulot d'étranglement du traitement, et non le traitement du processeur.

Débit

Le débit correspond au rythme de transmission des données via le réseau. Dans Access Gateway, les données transmises par le réseau comprennent les données d'authentification, d'autorisation et de contenu renvoyé :

Authentifications : nombre d'assertions SAML traitées (depuis Okta vers chaque application)
Autorisations : nombre de politiques vérifiées par requête HTTP (toutes les requêtes HTTP)

Chaque requête d'authentification et d'autorisation utilise environ 1 024 octets, ce qui donne 2 048 octets de données renvoyées. Vous pouvez calculer le débit du réseau à l'aide de cette formule :

Sign-in attempts per second x (authentications + authorizations per second + returned data size)

Pour calculer la bande passante moyenne du réseau, utilisez cette formule :

Average response size x average request arrival rate

Si la réponse moyenne a une taille d'environ 20 Ko, le résultat pour 500 requêtes est de 20 Ko x 500, ce qui correspond à 10 Mo par seconde.

Remarque :

Vous pourrez trouver les données exactes, notamment le temps nécessaire à l'exécution d'une requête et la taille des données renvoyées, dans les journaux AuthN et Tous.

Estimer la taille des instances

Le nombre d'utilisateurs et d'authentifications que chaque taille d'instance peut prendre en charge dépend de plusieurs facteurs complexes. Les facteurs qui affectent les capacités sont notamment la relation entre la taille totale du disque et de la mémoire disponible sur le serveur, la vitesse de connexion du réseau et celle du processeur, etc.

Access Gateway vous permet de sélectionner une configuration qui convient à votre environnement. Vous pouvez déployer une ou deux instances de Access Gateway sur du matériel avec plusieurs cœurs et des modules de mémoire volumineux. Vous pouvez aussi déployer Access Gateway sur de plusieurs instances plus petites réparties sur plusieurs serveurs dans un cluster.

Pour déterminer le nombre d'utilisateurs que vos instances Access Gateway peuvent prendre en charge, utilisez les calculs figurant sur cette page ou contactez Support Okta pour obtenir de l'aide concernant votre environnement.

Ce tableau décrit les configurations matérielles minimales requises pour prendre en charge les différentes tailles d'instance Access Gateway. Le nombre d'utilisateurs et d'apps indiqués dans le tableau est fourni à titre indicatif uniquement. Les performances réelles dépendent de facteurs propres à votre environnement.

Utilisez	Matériel physique/virtuel	Équivalent AWS
Preuve de concept	Une instance avec le matériel suivant : 2 cœurs de 2 Go de mémoire Disque dur de 220 Go (par défaut) Carte réseau unique 1 Gbit/s	t2.medium
Petite 1 000 à 5 000 utilisateurs 1 à 10 applications	Deux instances, chacune avec le matériel suivant : 2 cœurs de 4 Go de mémoire Disque dur de 220 Go (par défaut) Carte réseau unique 1 Gbit/s	t2.medium
Moyen 5 000 à 20 000 utilisateurs 10 à 100 applications	Trois instances, chacune avec le matériel suivant : Deux cœurs de 8 Go de mémoire Disque dur de 220 Go Carte réseau unique 1 Gbit/s	m4.large
Grande 20 000 utilisateurs ou plus 100 applications ou plus	Trois instances, chacune avec le matériel suivant : 4 cœurs de 16 Go de mémoire Disque dur de 220 Go Carte réseau unique 1 Gbit/s	m4.xlarge. Consultez Types d'instances AWS.

Estimer les besoins en matière de mise à l'échelle

La mise à l'échelle est la tâche qui consiste à augmenter ou à réduire la taille d'un cluster Access Gateway.

Mise à l'échelle verticale : ajoutez ou supprimez d'une instance donnée de la mémoire, de l'espace disque ou des processeurs. En cas de journalisation excessive, utilisez une solution de transfert de journaux et réglez le niveau du journal dans Access Gateway au niveau minimal (avertissement ou erreur). Si vous avez besoin d'augmenter l'espace disque sur l'appliance, contactez les services Okta Professional
Mise à l'échelle horizontale : ajoutez ou supprimez des instances Access Gateway d'un cluster.

Okta recommande de déployer tous les membres du cluster à haute disponibilité Access Gateway avec la même configuration en matière de processeur, de mémoire et de disque.

Remarque :

Conseils relatifs aux performances des clusters

Les meilleures augmentations de performance sont obtenues en ajoutant des processeurs ou en utilisant de disques SSD.
Pour améliorer le débit global du cluster, Okta recommande une mise à l'échelle horizontale ou l'ajout d'instances Access Gateway supplémentaires. Par exemple, vous pouvez doubler la capacité d'un cluster à deux nœuds qui gère 1 500 requêtes en ajoutant deux nœuds supplémentaires avec la même configuration en matière de processeur, de mémoire et de disque.
En général, la mise à l'échelle horizontale est linéaire en raison de l'utilisation par Access Gateway des sessions persistantes (affinité de session). Access Gateway ne partage pas de sessions entre les nœuds.

Remarque :

La capacité peut être limitée par d'autres facteurs sans rapport avec Access Gateway, comme le débit réseau ou les performances des application en back-end. Consultez la section Interfaces réseau pour obtenir plus d'informations sur la mise en réseau d'Access Gateway et l'augmentation du débit du réseau.

Dimensionnement du nœud du serveur d'autorisations

Si vous déployez Access Gateway hors ligne, approvisionnez un serveur distinct pour le service d'authentification en plus de vos nœuds Access Gateway. Il n'est pas recommandé d'exécuter le service d'authentification sur un nœud Access Gateway existant dans le cadre de déploiements en production, en raison de ses besoins en matière de processeur et de RAM.

Le tableau suivant présente les spécifications recommandées pour le nœud du serveur d'autorisations selon chaque cas d'utilisation :

Utilisez	Cluster Access Gateway	Équivalent AWS pour chaque nœud Access Gateway	Nœud du serveur d'autorisations Access Gateway	Équivalent AWS pour le nœud du serveur d'autorisations
Preuve de concept (cluster Access Gateway sur un seul serveur)	Une instance avec le matériel suivant : 2 cœurs de processeur 2 Go de RAM 220 Go de disque dur Carte réseau unique 1 Gbit/s	t2.medium	Une instance avec 2 cœurs de processeur et 2 Go de RAM. Peut gérer les éléments suivants : 30 connexions/déconnexions d'utilisateur par seconde à l'aide d'un mot de passe, ou 240 requêtes de jetons d'actualisation par seconde, ou 240 autorisations d'identifiants client par seconde, ou 16 000 sessions mises en cache.	t2.medium
Petite 1 000 à 5 000 utilisateurs 1 à 10 applications	Deux instances, chacune avec le matériel suivant : 2 cœurs de processeur 4 Go de RAM 220 Go de disque dur Carte réseau unique 1 Gbit/s	t2.medium	Une instance avec 4 cœurs de processeur et 8 Go de RAM. Peut gérer les éléments suivants : 60 connexions/déconnexions d'utilisateur par seconde à l'aide d'un mot de passe, ou 480 requêtes de jetons d'actualisation par seconde, ou 480 autorisations d'identifiants client par seconde.	c5.xlarge
Moyen 5 000 à 20 000 utilisateurs 10 à 100 applications	Trois instances, chacune avec le matériel suivant : 2 cœurs de processeur 8 Go de RAM 220 Go de disque dur Carte réseau unique 1 Gbit/s	m4.large	Une instance avec 8 cœurs de processeur et 32 Go de RAM. Peut gérer les éléments suivants : 120 connexions/déconnexions d'utilisateur par seconde à l'aide d'un mot de passe, ou 960 requêtes de jetons d'actualisation par seconde, ou 960 autorisations d'identifiants client par seconde.	t2.2xlarge
Grande Plus de 20 000 utilisateurs Plus de 100 applications	Trois instances, chacune avec le matériel suivant : 4 cœurs de processeur 16 Go de RAM 220 Go de disque dur Carte réseau unique 1 Gbit/s	m4.large	Une instance avec 12 cœurs de processeur et 48 Go de RAM. Peut gérer les éléments suivants : 180 connexions/déconnexions d'utilisateur par seconde à l'aide d'un mot de passe, ou 1 440 requêtes de jetons d'actualisation par seconde, ou 1 440 autorisations d'identifiants client par seconde.	m5zn.3xlarge

Remarque : Ces valeurs sont des estimations. Les performances réelles dépendent de votre environnement, de la taille du répertoire LDAP et de la distribution de la charge de travail d'authentification.

Exigences en matière de vCPU pour le nœud du serveur d'autorisations

Évaluons les besoins en matière de vCPU pour les opérations sur un seul nœud de service d'authentification à l'aide des tests de performance suivants :

Opération	Débit par vCPU
Connexions des utilisateurs à l'aide d'un mot de passe	15 par seconde
Autorisations d'identifiants client	120 par seconde
Demandes de jetons d'actualisation	120 par seconde

Par exemple, pour un environnement présentant le volume suivant :

45 connexions/déconnexions par seconde
360 autorisations d'identifiants client par seconde
360 requêtes de jetons d'actualisation par seconde

Le vCPU requis est : 45 ÷ 15 + 360 ÷ 120 + 360 ÷ 120 = 3 + 3 + 3 = 9 vCPU.

Une fois que vous avez calculé le nombre total de vCPU, ajoutez une marge de 50 % pour faire face aux pics d'utilisation, ce qui porte le total à 9 x 1.5 = 14vCPU.

Exigences en matière de RAM pour le nœud du serveur d'autorisations

Un nœud de serveur d'autorisations nécessite environ 1 250 Mo de RAM pour prendre en charge les caches de données de domaine Realm et 10 000 sessions mises en cache. Si la mémoire est insuffisante, le nettoyage automatique s'exécute plus fréquemment, ce qui augmente l'utilisation du processeur et dégrade les performances.