Exigences concernant l'installation

Matériel requis

Vous devez répondre aux exigences matérielles minimales suivantes pour une infrastructure à haute disponibilité dans un environnement de production.

La vidéo suivante vous donne des conseils généraux sur le dimensionnement de votre installation :

Pour tous les scénarios d'installation décrits dans Topologies d'installation, les tableaux suivants listent la configuration matérielle minimale requise pour les composants d'installation.

Dans ces tableaux, les exigences relatives au disque dur s'ajoutent à l'espace disque requis par le système d'exploitation. En fonction de vos applications et du trafic réseau, votre installation peut nécessiter plus ou moins de ressources que celles listées ci-dessous.

Vous trouverez ci-dessous la liste des exigences matérielles si vous souhaitez installer les services de monétisation (non compatibles avec l'installation tout-en-un) :

Bande passante réseau requise pour Cassandra

Cassandra utilise le protocole Gossip pour échanger des informations avec d'autres nœuds sur la topologie du réseau. En plus de la nature distribuée de Cassandra qui implique de communiquer avec plusieurs nœuds pour les opérations de lecture et d'écriture, l'utilisation de Gossip entraîne le transfert d'un grand nombre de données sur le réseau.

Cassandra nécessite une bande passante réseau minimale de 1 Gbit/s par nœud. Pour les installations en production, il est recommandé d'utiliser une bande passante plus élevée.

La latence maximale ou au 99e centile pour Cassandra doit être inférieure à 100 millisecondes.

Configuration requise pour le système d'exploitation et les logiciels tiers

Ces instructions d'installation et les fichiers d'installation fournis ont été testés sur les systèmes d'exploitation et les logiciels tiers listés dans Logiciels et versions compatibles.

Prérequis : Activer le dépôt EPEL

Avant de procéder à l'installation, assurez-vous que le dépôt EPEL (Extra Packages for Enterprise Linux) est activé. Utilisez les commandes suivantes en fonction de la version de votre système d'exploitation :

• Pour Red Hat/CentOS/Oracle 8.X :

  wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm

  sudo rpm -ivh epel-release-latest-8.noarch.rpm

• Pour Red Hat/CentOS/Oracle 9.X :

  wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm

  sudo rpm -ivh epel-release-latest-9.noarch.rpm

Java

Vous devez installer une version compatible de Java 1.8 sur chaque machine avant l'installation. Les JDK compatibles sont listés dans Logiciels et versions compatibles.

Assurez-vous que la variable d'environnement JAVA_HOME pointe vers la racine du JDK pour l'utilisateur qui effectue l'installation.

SELinux

En fonction de vos paramètres SELinux, Edge peut rencontrer des problèmes lors de l'installation et du démarrage des composants Edge. Si nécessaire, vous pouvez désactiver SELinux ou le définir sur le mode permissif pendant l'installation, puis le réactiver après l'installation. Pour en savoir plus, consultez Installer l'utilitaire Edge apigee-setup.

Créer l'utilisateur "apigee"

La procédure d'installation crée un utilisateur du système Unix nommé &39;apigee'. Les répertoires et fichiers Edge appartiennent à "apigee", tout comme les processus Edge. Cela signifie que les composants Edge s'exécutent en tant qu'utilisateur "apigee". Si nécessaire, vous pouvez exécuter des composants en tant qu'utilisateur différent.

Répertoire d'installation

Par défaut, le programme d'installation écrit tous les fichiers dans le répertoire /opt/apigee. Vous ne pouvez pas modifier l'emplacement de ce répertoire. Bien que vous ne puissiez pas modifier ce répertoire, vous pouvez créer un lien symbolique pour mapper /opt/apigee à un autre emplacement, comme décrit dans Créer un lien symbolique à partir de /opt/apigee.

Dans les instructions de ce guide, le répertoire d'installation est indiqué comme /opt/apigee.

Créer un lien symbolique à partir de /opt/apigee

Avant de créer le lien symbolique, vous devez d'abord créer un utilisateur et un groupe nommés "apigee". Il s'agit du même groupe et du même utilisateur que ceux créés par le programme d'installation Edge.

Pour créer le lien symbolique, effectuez ces étapes avant de télécharger le fichier bootstrap_4.53.01.sh. Vous devez effectuer toutes ces étapes en tant qu'utilisateur racine :

1. Créez l'utilisateur et le groupe "apigee" :

   groupadd -r apigee > useradd -r -g apigee -d /opt/apigee -s /sbin/nologin -c "Apigee platform user" apigee

2. Créez un lien symbolique de /opt/apigee vers la racine d'installation souhaitée :

   ln -Ts /srv/myInstallDir /opt/apigee

   Où /srv/myInstallDir est l'emplacement souhaité des fichiers Edge.

3. Modifiez le propriétaire du répertoire racine d'installation et du lien symbolique pour l'utilisateur "apigee" :

   chown -h apigee:apigee /srv/myInstallDir /opt/apigee

Paramètres des réseaux

Apigee vous recommande de vérifier les paramètres réseau avant l'installation. Le programme d'installation s'attend à ce que toutes les machines disposent d'adresses IP fixes. Utilisez les commandes suivantes pour valider le paramètre :

• hostname renvoie le nom de la machine.
• hostname -i renvoie l'adresse IP du nom d'hôte accessible depuis d'autres machines.

Selon le type et la version de votre système d'exploitation, vous devrez peut-être modifier /etc/hosts et /etc/sysconfig/network si le nom d'hôte n'est pas correctement défini. Pour en savoir plus, consultez la documentation de votre système d'exploitation.

Si un serveur possède plusieurs cartes d'interface, la commande "hostname -i" renvoie une liste d'adresses IP séparées par des espaces. Par défaut, le programme d'installation Edge utilise la première adresse IP renvoyée, qui peut ne pas être correcte dans toutes les situations. Vous pouvez également définir la propriété suivante dans le fichier de configuration de l'installation :

ENABLE_DYNAMIC_HOSTIP=y

Si cette propriété est définie sur "y", le programme d'installation vous invite à sélectionner l'adresse IP à utiliser lors de l'installation. La valeur par défaut est "n". Pour en savoir plus, consultez la documentation de référence sur le fichier de configuration Edge.

TCP Wrappers

Les wrappers TCP peuvent bloquer la communication de certains ports et affecter l'installation de SymasLDAP, Postgres et Cassandra. Sur ces nœuds, vérifiez /etc/hosts.allow et /etc/hosts.deny pour vous assurer qu'il n'y a aucune restriction de port sur les ports SymasLDAP, Postgres et Cassandra requis.

iptables

Vérifiez qu'aucune règle iptables n'empêche la connectivité entre les nœuds sur les ports Edge requis. Si nécessaire, vous pouvez arrêter iptables pendant l'installation à l'aide de la commande suivante :

sudo/etc/init.d/iptables stop

Accès à l'annuaire

Le tableau suivant répertorie les répertoires des nœuds Edge qui présentent des exigences particulières pour les processus Edge :

Cassandra

Tous les nœuds Cassandra doivent être connectés à un anneau. Cassandra stocke les répliques de données sur plusieurs nœuds pour assurer la fiabilité et la tolérance aux pannes. La stratégie de réplication de chaque espace de clés Edge détermine les nœuds Cassandra sur lesquels les répliques sont placées. Pour en savoir plus, consultez À propos du facteur de réplication et du niveau de cohérence de Cassandra.

Cassandra ajuste automatiquement la taille de son tas de mémoire Java en fonction de la mémoire disponible. Pour en savoir plus, consultez Ajuster les ressources Java en cas de dégradation des performances ou de forte consommation de mémoire.

Après avoir installé Edge pour Private Cloud, vous pouvez vérifier que Cassandra est correctement configuré en examinant le fichier /opt/apigee/apigee-cassandra/conf/cassandra.yaml. Par exemple, assurez-vous que le script d'installation d'Edge pour le cloud privé a défini les propriétés suivantes :

• cluster_name
• initial_token
• partitioner
• seeds
• listen_address
• rpc_address
• snitch

Base de données PostgreSQL

Après avoir installé Edge, vous pouvez ajuster les paramètres de base de données PostgreSQL suivants en fonction de la quantité de RAM disponible sur votre système :

conf_postgresql_shared_buffers = 35% of RAM      # min 128kB
conf_postgresql_effective_cache_size = 45% of RAM
conf_postgresql_work_mem = 512MB       # min 64kB

Pour définir ces valeurs :

1. Modifiez le fichier postgresql.properties :

   vi /opt/apigee/customer/application/postgresql.properties

   Si le fichier n'existe pas, créez-le.

2. Définissez les propriétés listées ci-dessus.
3. Enregistrez vos modifications.
4. Redémarrez la base de données PostgreSQL :

   /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

Configuration des paramètres régionaux pour Rocky 9.X

Si vous utilisez Rocky 9.X, assurez-vous que votre système est configuré avec LANG=en_US.utf8 dans les paramètres régionaux à l'échelle du système. Pour configurer cela, exécutez les commandes suivantes :

dnf -y -q install langpacks-en
localectl set-locale LANG=en_US.utf8
reboot

Limites du système

Assurez-vous d'avoir défini les limites système suivantes sur les nœuds Cassandra et Message Processor :

• Sur les nœuds Cassandra, définissez des limites souples et strictes pour memlock, nofile et l'espace d'adressage (as) pour l'utilisateur de l'installation (la valeur par défaut est "apigee") dans /etc/security/limits.d/90-apigee-edge-limits.conf, comme indiqué ci-dessous :

  apigee soft memlock unlimited
  apigee hard memlock unlimited
  apigee soft nofile 32768
  apigee hard nofile 65536
  apigee soft as unlimited
  apigee hard as unlimited
  apigee soft nproc 32768
  apigee hard nproc 65536

• Sur les nœuds Message Processor, définissez le nombre maximal de descripteurs de fichiers ouverts sur 64 000 dans /etc/security/limits.d/90-apigee-edge-limits.conf, comme indiqué ci-dessous :

  apigee soft nofile 32768
  apigee hard nofile 65536

  Si nécessaire, vous pouvez augmenter cette limite. Par exemple, si vous avez un grand nombre de fichiers temporaires ouverts en même temps.

• Si l'erreur suivante s'affiche dans un routeur ou un processeur de messages system.log, cela signifie peut-être que les limites de votre descripteur de fichier sont trop basses :

  "java.io.IOException: Too many open files"

  Vous pouvez vérifier vos limites d'utilisateurs en exécutant la commande suivante :

  # su - apigee
  $ ulimit -n
  100000
  

  Si vous atteignez toujours les limites de fichiers ouverts après avoir défini les limites de descripteurs de fichiers sur 100000, ouvrez une demande auprès de l'assistance Apigee Edge pour obtenir de l'aide supplémentaire.

Network Security Services (NSS)

Network Security Services (NSS) est un ensemble de bibliothèques qui permet de développer des applications client et serveur sécurisées. Assurez-vous d'avoir installé NSS v3.19 ou version ultérieure.

Pour vérifier votre version actuelle :

yum info nss

Pour mettre à jour NSS :

yum update nss

Pour en savoir plus, consultez cet article de RedHat.

Désactiver la résolution DNS sur IPv6 lorsque vous utilisez NSCD (Name Service Cache Daemon)

Si vous avez installé et activé NSCD (Name Service Cache Daemon), les processeurs de messages effectuent deux recherches DNS : une pour IPv4 et une pour IPv6. Vous devez désactiver la résolution DNS sur IPv6 lorsque vous utilisez NSCD.

Pour désactiver la résolution DNS sur IPv6 :

1. Sur chaque nœud de processeur de messages, modifiez /etc/nscd.conf.
2. Définissez la propriété suivante :

   enable-cache hosts no

Désactiver IPv6 sur RHEL 8 et versions ultérieures

Si vous installez Edge sur RHEL 8 ou version ultérieure sur Google Cloud Platform, vous devez désactiver IPv6 sur tous les nœuds Qpid.

Pour savoir comment désactiver IPv6, veuillez consulter la documentation fournie par le fournisseur de votre système d'exploitation. Par exemple, vous trouverez des informations pertinentes dans la documentation Red Hat Enterprise Linux.

Outils

Le programme d'installation utilise les outils UNIX suivants dans la version standard fournie par EL5 ou EL6.

Synchronisation horaire

Apigee vous recommande de synchroniser les heures de vos serveurs. Si ce n'est pas déjà fait, l'utilitaire ntpdate ou un outil équivalent peut servir à vérifier si les serveurs sont synchronisés au niveau de l'heure. Par exemple, vous pouvez utiliser yum install ntp ou une commande équivalente pour installer l'utilitaire. Cela est particulièrement utile pour répliquer les configurations LDAP. Veuillez noter que vous devez définir le fuseau horaire du serveur sur UTC.

Pare-feu et hôtes virtuels

Le terme virtual est souvent surchargé dans le domaine de l'informatique. C'est également le cas avec un déploiement Apigee Edge pour un cloud privé et des hôtes virtuels. Pour clarifier les choses, le terme virtual a deux utilisations principales :

• Machines virtuelles (VM) : non requises, mais certains déploiements utilisent la technologie de VM pour créer des serveurs isolés pour leurs composants Apigee. Les hôtes de VM, comme les hôtes physiques, peuvent disposer d'interfaces réseau et de pare-feu.
• Hôtes virtuels : points de terminaison Web, analogues à un hôte virtuel Apache.

Un routeur dans une VM peut exposer plusieurs hôtes virtuels (à condition qu'ils diffèrent les uns des autres par leur alias d'hôte ou par leur port d'interface).

Par exemple, un même serveur physique A peut exécuter deux VM, appelées "VM1" et "VM2". Supposons que "VM1" expose une interface Ethernet virtuelle, nommée "eth0" dans la VM, à laquelle l'adresse IP 111.111.111.111 est attribuée par le mécanisme de virtualisation ou un serveur DHCP réseau. Supposons ensuite que VM2 expose une interface Ethernet virtuelle également nommée "eth0" et à laquelle l'adresse IP 111.111.111.222 est attribuée.

Il est possible qu'un routeur Apigee s'exécute dans chacune des deux VM. Les routeurs exposent des points de terminaison d'hôte virtuel, comme dans cet exemple hypothétique :

Le routeur Apigee de la VM1 expose trois hôtes virtuels sur son interface eth0 (qui possède une adresse IP spécifique), api.mycompany.com:80, api.mycompany.com:443 et test.mycompany.com:80.

Le routeur de la VM2 expose api.mycompany.com:80 (même nom et même port que ceux exposés par la VM1).

Il est possible que le système d'exploitation de l'hôte physique dispose d'un pare-feu réseau. Si tel est le cas, ce pare-feu doit être configuré pour laisser passer le trafic TCP destiné aux ports exposés sur les interfaces virtualisées (111.111.111.111:{80, 443} et 111.111.111.222:80). De plus, le système d'exploitation de chaque VM peut fournir son propre pare-feu sur son interface eth0. Ces pare-feu doivent également autoriser le trafic des ports 80 et 443 à se connecter.

Le chemin de base est le troisième composant impliqué dans le routage des appels d'API vers différents proxys d'API que vous avez peut-être déployés. Les bundles de proxy d'API peuvent partager un point de terminaison s'ils ont des chemins de base différents. Par exemple, un chemin de base peut être défini comme http://api.mycompany.com:80/ et un autre comme http://api.mycompany.com:80/salesdemo.

Dans ce cas, vous avez besoin d'un équilibreur de charge ou d'un Traffic Director pour répartir le trafic http://api.mycompany.com:80/ entre les deux adresses IP (111.111.111.111 sur la VM1 et 111.111.111.222 sur la VM2). Cette fonction est spécifique à votre installation et est configurée par votre groupe de mise en réseau local.

Le chemin de base est défini lorsque vous déployez une API. À partir de l'exemple ci-dessus, vous pouvez déployer deux API, mycompany et testmycompany, pour l'organisation mycompany-org avec l'hôte virtuel dont l'alias d'hôte est api.mycompany.com et le port défini sur 80. Si vous ne déclarez pas de chemin de base dans le déploiement, le routeur ne sait pas à quelle API envoyer les requêtes entrantes.

Toutefois, si vous déployez l'API testmycompany avec l'URL de base /salesdemo, les utilisateurs accèdent à cette API à l'aide de http://api.mycompany.com:80/salesdemo. Si vous déployez votre API mycompany avec l'URL de base /, vos utilisateurs accèdent à l'API via l'URL http://api.mycompany.com:80/.

Licences

Chaque installation d'Edge nécessite un fichier de licence unique que vous obtenez auprès d'Apigee. Vous devrez indiquer le chemin d'accès au fichier de licence lors de l'installation du serveur de gestion, par exemple /tmp/license.txt.

Le programme d'installation copie le fichier de licence dans /opt/apigee/customer/conf/license.txt.

Si le fichier de licence est valide, le serveur de gestion valide la date d'expiration et le nombre de processeurs de messages (MP) autorisés. Si l'un des paramètres de licence a expiré, vous trouverez les journaux à l'emplacement suivant : /opt/apigee/var/log/edge-management-server/logs. Dans ce cas, vous pouvez contacter l'assistance Apigee Edge pour obtenir des informations sur la migration.

Si vous ne disposez pas encore d'une licence, contactez le service commercial d'Apigee.