Conditions requises pour l'installation

Edge pour Private Cloud version 4.17.09

Matériel requis

Vous devez disposer de la configuration matérielle minimale requise suivante pour bénéficier d'une infrastructure à disponibilité élevée dans un environnement de production. Pour tous les scénarios d'installation décrits dans la section Topologies d'installation, les tableaux suivants indiquent la configuration matérielle minimale requise pour les composants d'installation.

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

Composant d'installation

RAM

Processeur

Quantité minimale sur le disque dur

Cassandra

16 Go

8 cœurs

250 Go de stockage local avec SSD ou HDD rapide pouvant atteindre 2 000 IOPS

Processeur de messages/Routeur sur la même machine

16 Go

8 cœurs

100 Go

Analyse - Postgres/Qpid sur le même serveur (non recommandé pour la production)

16 Go*

8 cœurs*

500 Go à 1 To** d'espace de stockage réseau***, de préférence avec un backend SSD, acceptant au moins 1 000 IOPS*

Analyse – Postgres autonome

16 Go*

8 cœurs*

500 Go à 1 To** d'espace de stockage réseau***, de préférence avec un backend SSD, acceptant au moins 1 000 IOPS*.

Analytics - Qpid autonome

8 Go

4 cœurs

Entre 30 Go et 50 Go de stockage local avec SSD ou HDD rapide

Pour les installations de plus de 250 tâches par seconde, il est recommandé d'utiliser un stockage HDD avec un stockage local compatible avec 1 000 IOPS.

La taille de la file d'attente Qpid par défaut est de 20 Go. Si vous devez augmenter la capacité, ajoutez des nœuds Qpid supplémentaires.

Autre (OpenLDAP, UI, serveur de gestion)

4GB

2 cœurs

60 Go

*Ajustement de la configuration système requise pour Postgres en fonction du débit:

  • Moins de 250 TPS: le stockage réseau à quatre cœurs de 8 Go peut être envisagé avec un espace de stockage réseau géré*** permettant d'atteindre au moins 1 000 IOPS.
  • Plus de 250 TPS: stockage réseau géré de 16 Go à 8 cœurs*** compatible avec 1 000 IOPS ou plus
  • Plus de 1 000 TPS: stockage réseau géré de 16 Go à 8 cœurs*** compatible avec 2 000 IOPS ou plus
  • Plus de 2 000 TPS: stockage réseau géré de 32 Go à 16 cœurs*** compatible avec 2 000 IOPS ou plus
  • Plus de 4 000 TPS: stockage réseau géré de 64 Go à 32 cœurs*** compatible avec 4 000 IOPS ou plus

**La valeur du disque dur Postgres est basée sur les analyses prêtes à l'emploi capturées par Edge. Si vous ajoutez des valeurs personnalisées aux données d'analyse, ces valeurs doivent être augmentées en conséquence. Utilisez la formule suivante pour estimer l'espace de stockage nécessaire:

(nombre d'octets/requête) x (requêtes par seconde) * (secondes par heure) * (heures d'utilisation maximale par jour) * (jours par mois) * (mois de conservation des données) = octets de stockage nécessaires

Exemple:

(2 000 octets de données d'analyse par requête * 0,0 s/s x 100 octets de données d'analyse * 0,0 heure de conservation * 0,0 s/s, 100 octets/s * 0,0 heure de conservation x 100 octets/s

*** Le stockage réseau est recommandé pour la base de données Postgresql, car:

  • Il permet d'augmenter la taille de l'espace de stockage de manière dynamique si et quand cela est nécessaire.
  • Les IOPS réseau peuvent être ajustées à la volée dans la plupart des environnements/sous-systèmes de stockage/réseau actuels.
  • Les instantanés au niveau du stockage peuvent être activés dans le cadre de solutions de sauvegarde et de récupération.

De plus, vous trouverez ci-dessous la configuration matérielle requise si vous souhaitez installer les Services de monétisation:

Composant avec monétisation

RAM

Processeur

Disque dur

Serveur de gestion (avec services de monétisation)

8 Go

4 cœurs

60 Go

Analyse - Postgres/Qpid sur le même serveur

16 Go

8 cœurs

Entre 500 Go et 1 To d'espace de stockage réseau, de préférence avec un backend SSD, acceptant au moins 1 000 IOPS, ou utilisez la règle indiquée dans le tableau ci-dessus.

Analyse – Postgres autonome

16 Go

8 cœurs

Entre 500 Go et 1 To d'espace de stockage réseau, de préférence avec un backend SSD, acceptant au moins 1 000 IOPS, ou utilisez la règle indiquée dans le tableau ci-dessus.

Analytics - Qpid autonome

8 Go

4 cœurs

Entre 40 et 500 Go de stockage local avec SSD ou HDD rapide

Pour les installations de plus de 250 tâches par seconde, il est recommandé d'utiliser un stockage HDD avec un stockage local compatible avec 1 000 IOPS.

Voici la configuration matérielle requise si vous souhaitez installer l'API BaaS:

Composant d'API BaaS

RAM

Processeur

Disque dur

ElasticSearch*

8 Go

4 cœurs

60-80 Go

Pile BaaS API *

8 Go

4 cœurs

60-80 Go

Portail BaaS de l'API

1 Go

2 cœurs

20 Go

Cassandra (facultatif : vous utilisez généralement le même cluster Cassandra pour les services BaaS de périphérie et d'API)

16 Go

8 cœurs

250 Go de stockage local avec SSD ou HDD rapide pouvant atteindre 2 000 IOPS

* Vous pouvez installer ElasticSearch et la pile BaaS de l'API sur le même nœud. Dans ce cas, configurez ElasticSearch pour qu'il utilise 4 Go de mémoire (par défaut). Si ElasticSearch est installé sur son propre nœud, configurez-le pour utiliser 6 Go de mémoire.

Remarques :

  • Si le système de fichiers racine n'est pas assez volumineux pour l'installation, nous vous recommandons de placer les données sur un disque de plus grande taille.
  • Si une ancienne version d'Apigee Edge pour Private Cloud a été installée sur la machine, veillez à supprimer le dossier /tmp/java avant une nouvelle installation.
  • Le dossier temporaire /tmp à l'échelle du système doit disposer d'autorisations d'exécution pour démarrer Cassandra.
  • Si l'utilisateur "apigee" a été créé avant l'installation, assurez-vous que "/home/apigee" existe comme répertoire d'accueil et qu'il appartient à "apigee:apigee".

Configuration requise concernant 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 répertoriés ici: https://apigee.com/docs/api-services/reference/supported-software.

Créer l'utilisateur Apigee

La procédure d'installation crée un utilisateur du système Unix nommé "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 les composants en tant qu'utilisateur différent. Pour obtenir un exemple, consultez la section "Lier le routeur à un port protégé" dans Installer des composants Edge sur un nœud.

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 vers un autre emplacement, comme décrit ci-dessous.

Dans les instructions de ce guide, le répertoire d'installation est indiqué sous la forme /<inst_root>/apigee, où /<inst_root> est /opt par défaut.

Créer un lien symbolique depuis /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 créés par le programme d'installation Edge.

Pour créer le lien symbolique, procédez comme suit avant de télécharger le fichier bootstrap_4.17.01.sh. Vous devez effectuer toutes ces étapes en mode root:

  1. Créez l'utilisateur et le groupe "apigee" :
    > groupadd -r apigee
    > useradd -r -g apigee -d /opt/apigee -s /sbin/nologin -c "utilisateur de la plate-forme Apigee" apigee
  2. Créez un lien symbolique depuis /opt/apigee vers la racine d'installation souhaitée:
    > ln -Ts /srv/myInstallDir /opt/apigee
    /srv/myInstallDir correspond à l'emplacement souhaité des fichiers Edge.
  3. Modifiez la propriété de la racine d'installation et du lien symbolique par l'utilisateur "apigee" :
    > chown -h apigee:apigee /srv/myInstallDir /opt/apigee

Java

Une version compatible de Java1.8 doit être installée sur chaque machine avant l'installation. Les JDK pris en charge sont répertoriés ici:

https://apigee.com/docs/api-services/reference/supported-software

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

SELinux

En fonction des paramètres que vous avez définis pour 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 en mode permissif lors de l'installation, puis le réactiver après l'installation. Pour plus d'informations, reportez-vous à la section Installer l'utilitaire de configuration d'Apigee Edge.

Paramètre réseau

Il est recommandé de vérifier le paramètre réseau avant l'installation. Le programme d'installation s'attend à ce que toutes les machines aient une adresse IP fixe. Utilisez les commandes suivantes pour valider le paramètre:

  • nom d'hôte renvoie le nom de la machine
  • nom d'hôte -i renvoie l'adresse IP du nom d'hôte pouvant être adressé à partir 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 défini correctement. Pour plus d'informations, consultez la documentation de votre système d'exploitation.

Si un serveur comporte 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, ce qui peut ne pas être correct dans tous les cas. Vous pouvez également définir la propriété suivante dans le fichier de configuration d'installation:

ENABLE_DYNAMIC_HOSTIP=y

Lorsque 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 les fichiers de configuration Edge.

Wrappers TCP

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

iptables

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

> sudo/etc/init.d/iptables stop

Sur CentOS 7.x:

> systemctl stop firewalld

Assurez-vous qu'Edge Router peut accéder à /etc/rc.d/init.d/functions

Les nœuds Edge Router et les nœuds de portail BaaS utilisent le routeur Nginx et nécessitent un accès en lecture à /etc/rc.d/init.d/functions.

Si votre processus de sécurité nécessite que vous définissiez des autorisations sur /etc/rc.d/init.d/functions, ne les définissez pas sur 700, sinon le routeur ne démarrera pas. Les autorisations peuvent être définies sur 744 pour permettre l'accès en lecture à /etc/rc.d/init.d/functions.

Cassandra

Tous les nœuds Cassandra doivent être connectés à un anneau. Cassandra stocke les instances répliquées de données sur plusieurs nœuds pour garantir 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 où sont placées les instances répliqué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 du tas de mémoire Java en fonction de la mémoire disponible. Pour en savoir plus, consultez la section Régler les ressources Java. En cas de dégradation des performances ou de consommation de mémoire élevée.

Après avoir installé Edge for Private Cloud, vous pouvez vérifier que Cassandra est correctement configuré en examinant le fichier /<inst_root>/apigee/apigee-cassandra/conf/cassandra.yaml. Par exemple, assurez-vous que le script d'installation Edge for Private Cloud définit les propriétés suivantes:

  • cluster_name
  • initial_token
  • partitionneur
  • graines
  • listen_address
  • rpc_address
  • snitch

Avertissement: Ne modifiez pas ce fichier.

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 postgresql.properties:
    > vi /<inst_root>/apigee/customer/application/postgresql.properties

    Si le fichier n'existe pas, créez-le.
  2. Définissez les propriétés indiquées ci-dessus.
  3. Enregistrez les modifications.
  4. Redémarrez la base de données PostgreSQL:
    > /<inst_root>/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

Limites du système

Assurez-vous d'avoir défini les limites système suivantes sur les nœuds Cassandra et ceux du processeur de messages:

  • Sur les nœuds Cassandra, définissez les limites "soft and hard memlock", "nofile" et "address space" (en tant que) pour l'utilisateur d'installation d'installation (par défaut "apigee") dans /etc/security/limits.d/90-apigee-edge-limits.conf comme indiqué ci-dessous:
    apigee soft memlock illimité
    apigee hard memlock Unlimited




  • Sur les nœuds du processeur de messages, définissez le nombre maximal de descripteurs de fichiers ouverts sur 64 K 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 un grand nombre de fichiers temporaires sont ouverts simultanément).

jsvc

"jsvc" est une condition préalable à l'utilisation de l'API BaaS. La version 1.0.15-dev est installée lorsque vous installez l'API BaaS.

Services de sécurité réseau (NSS)

Les services de sécurité réseau (NSS) sont un ensemble de bibliothèques qui permettent de développer des applications clientes et serveur sécurisées. Vous devez vous assurer que vous avez installé NSS v3.19 ou version ultérieure.

Pour vérifier la version dont vous disposez:

> 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 lors de l'utilisation de NSCD (Name Service Cache Daemon)

Si vous avez installé et activé NSCD (Name Service Cache Daemon), les processeurs de messages effectuent deux résolutions 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 Google Cloud Platform pour RedHat/CentOS 7

Si vous installez Edge sur RedHat 7 ou CentOS 7 sur Google Cloud Platform, vous devez désactiver IPv6 sur tous les nœuds Qpid.

Pour savoir comment désactiver IPv6, consultez la documentation RedHat ou CentOS correspondant à la version de votre système d'exploitation. Par exemple, vous pouvez :

  1. Ouvrez /etc/hosts dans un éditeur.
  2. Insérez un caractère "#" dans la première colonne des lignes suivantes pour le commenter:
    #::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
  3. Enregistrez le fichier.

AMI AWS

Si vous installez Edge sur une AMI (Amazon Machine Image) AWS pour Red Hat Enterprise Linux 7.x, vous devez d'abord exécuter la commande suivante:

> yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

Outils

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

awk

expr

Lua-socket

tr/min

unzip

basename

grep

ls

rpm2cpio

ajouter_utilisateur

bash

nom d'hôte

net-tools

sed

wc

bc

id

perl (à partir de procps)

sudo

wget

curl

Liibaio

pgrep (à partir de procps)

tar

Xerces-C

Cyrus-Salal
libdb-cxx
ps tr miam

date

libibverbes

pwd

uuid

Chkconfig

dirname
librdmacm
python Uname
echo
libxlsx

Remarque :

  • L'exécutable de l'outil "useradd" se trouve dans /usr/sbin et pour chkconfig dans /sbin.
  • Avec l'accès sudo, vous pouvez accéder à l'environnement de l'utilisateur appelant. Par exemple, vous pouvez généralement appeler "sudo <command>" ou "sudo PATH=$PATH:/usr/sbin:/sbin <command>".
  • Assurez-vous d'avoir installé un outil de correctif avant d'installer un Service Pack (correctif).

ntpdate : il est recommandé de synchroniser l'heure des serveurs. S'il n'est pas déjà configuré, l'utilitaire "ntpdate" peut remplir cet objectif, qui permet de vérifier si les serveurs sont synchronisés avec l'heure. Vous pouvez exécuter yum install ntp pour installer l'utilitaire. Ceci est particulièrement utile pour répliquer les configurations OpenLDAP. Notez que vous avez configuré le fuseau horaire du serveur au format UTC.

openldap 2.4 : l'installation sur site nécessite OpenLDAP 2.4. Si votre serveur dispose d'une connexion Internet, le script d'installation Edge télécharge et installe OpenLDAP. Si votre serveur ne dispose pas d'une connexion Internet, vous devez vous assurer qu'OpenLDAP est déjà installé avant d'exécuter le script d'installation Edge. Sur RHEL/CentOS, vous pouvez exécuter yum install openldap-clients openldap-servers pour installer OpenLDAP.

Pour les installations à 13 hôtes et à 12 hôtes avec deux centres de données, vous avez besoin de la réplication OpenLDAP, car plusieurs nœuds hébergent OpenLDAP.

Pare-feu et hôtes virtuels

Le terme "virtuel" est généralement surchargé dans le domaine informatique, et il est donc utilisé dans Apigee Edge pour le déploiement de cloud privé et les hôtes virtuels. Pour clarifier les choses, on distingue deux utilisations principales du terme "virtuel" :

  • Machines virtuelles (VM): option facultative, 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, tels que les hôtes physiques, peuvent disposer d'interfaces réseau et de pare-feu.
  • Hôtes virtuels: points de terminaison Web, semblables à un hôte virtuel Apache.

Un routeur d'une VM peut exposer plusieurs hôtes virtuels (à condition qu'ils diffèrent l'un de l'autre par leur alias d'hôte ou leur port d'interface).

Comme un exemple de dénomination, un seul serveur physique "A" peut exécuter deux VM, nommées "VM1" et "VM2". Supposons que VM1 expose une interface Ethernet virtuelle, nommée eth0 à l'intérieur de la VM, à laquelle l'adresse IP 111.111.111.111 est attribuée par la machine de virtualisation et qu'une adresse IPv1.2 est également utilisée par la VM1.2.

Un routeur Apigee peut être exécuté sur chacune des deux VM. Les routeurs exposent les points de terminaison de l'hôte virtuel comme dans cet exemple hypothétique:

Le routeur Apigee dans 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 port que ceux exposés par la VM1).

Le système d'exploitation de l'hôte physique peut disposer d'un pare-feu réseau. Si tel est le cas, celui-ci doit être configuré pour transmettre le trafic TCP lié 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, qui doit également autoriser le trafic des ports 80 et 443 à se connecter.

Le chemin d'accès de base est le troisième composant impliqué dans le routage des appels d'API vers différents proxys d'API que vous avez pu déployer. Les groupes de proxys 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 l'autre comme http://api.mycompany.com:80/salesdemo.

Dans ce cas, vous avez besoin d'un équilibreur de charge ou d'un directeur du trafic 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.

Il est défini lorsque vous déployez une API. Dans 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 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 via 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/.

Configuration requise pour le port périphérique

La gestion du pare-feu va au-delà des hôtes virtuels uniquement. Les pare-feu des VM et des hôtes physiques doivent autoriser le trafic permettant aux ports requis par les composants de communiquer entre eux.

L'image suivante montre les exigences en termes de ports pour chaque composant Edge:

Remarques sur ce schéma:

  • *Le port 8082 du processeur de messages ne doit être ouvert au routeur que lorsque vous configurez TLS/SSL entre le routeur et le processeur de messages. Si vous ne configurez pas TLS/SSL entre le routeur et le processeur de messages, le port 8082 par défaut doit toujours être ouvert sur le processeur de messages pour gérer le composant, mais le routeur n'a pas besoin d'y accéder.
  • Les ports précédés de la lettre "M" sont des ports utilisés pour gérer le composant. Ils doivent être ouverts sur le composant et l'être pour que le serveur de gestion puisse y accéder.
  • Les composants suivants nécessitent un accès au port 8080 sur le serveur de gestion: routeur, processeur de messages, UI, Postgres et Qpid.
  • Un processeur de messages doit ouvrir le port 4528 en tant que port de gestion. Si vous disposez de plusieurs processeurs de messages, ils doivent tous être en mesure d'accéder les uns aux autres sur le port 4528 (indiqué par la flèche en boucle dans le schéma ci-dessus pour le port 4528 du processeur de messages). Si vous disposez de plusieurs centres de données, le port doit être accessible depuis tous les processeurs de messages de tous les centres de données.
  • Bien qu'il ne soit pas requis, vous pouvez ouvrir le port 4527 sur le routeur pour y accéder par n'importe quel processeur de messages. Sinon, vous risquez de voir des messages d'erreur dans les fichiers journaux du processeur de messages.
  • Un routeur doit ouvrir le port 4527 en tant que port de gestion. Si vous avez plusieurs routeurs, ils doivent tous être en mesure d'accéder les uns aux autres sur le port 4527 (indiqué par la flèche en forme de boucle dans le schéma ci-dessus pour le port 4527 du routeur).
  • L'interface utilisateur Edge nécessite l'accès au routeur, sur les ports exposés par les proxys d'API, pour prendre en charge le bouton Envoyer dans l'outil de traçage.
  • Le serveur de gestion a besoin d'accéder au port JMX sur les nœuds Cassandra.
  • L'accès aux ports JMX peut être configuré pour exiger un nom d'utilisateur/mot de passe. Pour en savoir plus, consultez la section Contrôler.
  • Vous pouvez éventuellement configurer l'accès TLS/SSL pour certaines connexions, qui peuvent utiliser des ports différents. Pour en savoir plus, consultez la section TLS/SSL.
  • Si vous configurez deux nœuds Postgres pour utiliser la réplication en attente maître, vous devez ouvrir le port 22 sur chaque nœud pour l'accès SSH. Vous pouvez éventuellement ouvrir des ports sur des nœuds individuels pour autoriser l'accès SSH.
  • Vous pouvez configurer le serveur de gestion et l'interface utilisateur Edge pour envoyer des e-mails via un serveur SMTP externe. Dans ce cas, vous devez vous assurer que le serveur de gestion et l'interface utilisateur peuvent accéder au port nécessaire sur le serveur SMTP. Pour le protocole SMTP non TLS, le numéro de port est généralement 25. Pour le protocole SMTP sur lequel TLS est activé, il s'agit souvent de 465. Veuillez vérifier auprès de votre fournisseur SMTP.

Le tableau ci-dessous indique les ports à ouvrir dans les pare-feu, par composant Edge:

Composant

Port

Description

Ports HTTP standards

80, 443

HTTP, plus tous les autres ports utilisés pour les hôtes virtuels

Management Server

8080

Port pour les appels d'API de gestion en périphérie. Ces composants nécessitent un accès au port 8080 du serveur de gestion: routeur, processeur de messages, UI, Postgres et Qpid.

1099

Port JMX

4526

Pour les appels de cache distribué et de gestion

UI de gestion

9000

Port permettant au navigateur d'accéder à l'interface utilisateur de gestion

Processeur de messages

8998

Port du processeur de messages pour les communications du routeur

8082

Port de gestion par défaut pour le processeur de messages et doit être ouvert sur le composant pour que le serveur de gestion puisse y accéder.

Si vous configurez TLS/SSL entre le routeur et le processeur de messages, il permet au routeur d'effectuer des vérifications de l'état sur le processeur de messages.

1101

Port JMX

4528

Pour les appels de cache distribué et de gestion entre les processeurs de messages, ainsi que pour la communication depuis le routeur et le serveur de gestion

Routeur

8081

Port de gestion par défaut pour le routeur. Il doit être ouvert sur le composant pour que le serveur de gestion puisse y accéder.

4527

Pour les appels de cache distribué et de gestion

15999

Port de vérification de l'état. Un équilibreur de charge utilise ce port pour déterminer si le routeur est disponible.

Pour obtenir l'état d'un routeur, l'équilibreur de charge envoie une requête au port 15999 du routeur:

> curl -v http://<routerIP>:15999/v1/servers/self/reachable

Si le routeur est accessible, la requête renvoie le code HTTP 200.

59001

Port utilisé pour tester l'installation Edge par l'utilitaire apigee-validate. Cet utilitaire a besoin d'accéder au port 59001 du routeur. Pour en savoir plus sur le port 59001, consultez la section Tester l'installation.

ZooKeeper

2181

Utilisé par d'autres composants tels que le serveur de gestion, le routeur, le processeur de messages, etc.

2888, 3888

Utilisé en interne par ZooKeeper pour la communication du cluster ZooKeeper (appelé ensemble ZooKeeper)

Cassandra

7000, 9042, 9160

Ports Apache Cassandra pour la communication entre les nœuds Cassandra et l'accès aux autres composants de périphérie.

7199

Port JMX. Doit être ouvert au serveur de gestion pour y accéder.

QPID

5672

Utilisé pour les communications du routeur et du processeur de messages vers le serveur Qpid

8083

Port de gestion par défaut sur le serveur Qpid et doit être ouvert sur le composant pour que le serveur de gestion puisse y accéder.

1102

Port JMX

4529

Pour les appels de cache distribué et de gestion

Postgres

5432

Utilisé pour la communication de Qpid (serveur de gestion) vers Postgres

8084

Port de gestion par défaut sur le serveur Postgres qui doit être ouvert sur le composant pour que le serveur de gestion puisse y accéder.

1103

Port JMX

4530

Pour les appels de cache distribué et de gestion

22

Si vous configurez deux nœuds Postgres pour utiliser la réplication en attente maître, vous devez ouvrir le port 22 sur chaque nœud pour l'accès SSH.

LDAP

10389

OpenLDAP

SmartDocs

59002

Port du routeur Edge où les demandes de page SmartDocs sont envoyées.

Le tableau suivant présente les mêmes ports (classés par ordre numérique) avec les composants source et de destination:

Numéro de port

Objectif

Composant source

Composant de destination

<port de l'hôte virtuel>

HTTP plus tous les autres ports que vous utilisez pour le trafic des appels d'API de l'hôte virtuel. Les ports 80 et 443 sont les plus couramment utilisés. Le routeur de messages peut interrompre les connexions TLS/SSL.

Client externe (ou équilibreur de charge)

Écouteur sur le routeur de messages

1099 à 1103

Gestion JMX

Client JMX

Serveur de gestion (1099)

Processeur de messages (1101)

Serveur Qpid (1102)

Serveur Postgres (1103)

2181

Communication avec le client ZooKeeper

Serveur de gestion

Routeur

Processeur de messages

Serveur Qpid

Serveur Postgres

ZooKeeper

2888 et 3888

Gestion des internœuds ZooKeeper

ZooKeeper

ZooKeeper

4526

Port de gestion RPC

Serveur de gestion

Serveur de gestion

4527 Port de gestion RPC pour le cache distribué et les appels de gestion, ainsi que pour les communications entre les routeurs

Serveur de gestion

Routeur

Routeur

4528

Pour les appels de cache distribués entre les processeurs de messages et pour la communication à partir du routeur

Serveur de gestion

Routeur

Processeur de messages

Processeur de messages

4529 Port de gestion RPC pour les appels de cache distribué et de gestion Serveur de gestion Serveur Qpid
4530 Port de gestion RPC pour les appels de cache distribué et de gestion Serveur de gestion Serveur Postgres

5432

Client Postgres

Serveur Qpid

Postgres

5672

Utilisé pour envoyer des analyses depuis le routeur et le processeur de messages vers Qpid

Routeur

Processeur de messages

Serveur Qpid

7000

Communications entre les nœuds Cassandra

Cassandra

Autre nœud Cassandra

7199

Gestion JMX Doit être ouvert pour que le serveur de gestion puisse accéder au nœud Cassandra.

Client JMX

Cassandra

8080

Port pour l'API de gestion

Clients de l'API de gestion

Serveur de gestion

8081 à 8084

Ports d'API des composants, utilisés pour émettre des requêtes API directement vers des composants individuels. Chaque composant ouvre un port différent. Le port exact utilisé dépend de la configuration, mais doit être ouvert au niveau du composant pour que le serveur de gestion puisse y accéder.

Clients de l'API de gestion

Routeur (8081)

Processeur de messages (8082)

Serveur Qpid (8083)

Serveur Postgres (8084)

8998

Communication entre le routeur et le processeur de messages

Routeur

Processeur de messages

9000

Port d'interface utilisateur de gestion de périphérie par défaut

Visiteur

Serveur d'interface utilisateur de gestion

9042

Transport natif CQL

Routeur

Processeur de messages

Serveur de gestion

Cassandra

9160

Client de récupération Cassandra

Routeur

Processeur de messages

Serveur de gestion

Cassandra

10389

Port LDAP

Serveur de gestion

OpenLDAP

15999

Port de vérification de l'état. Un équilibreur de charge utilise ce port pour déterminer si le routeur est disponible.

Équilibreur de charge Routeur
59001 Port utilisé par l'utilitaire apigee-validate pour tester l'installation Edge apigee-validate Routeur

59002

Port du routeur sur lequel les requêtes de page SmartDocs sont envoyées

SmartDocs

Routeur

Un processeur de messages maintient un pool de connexions dédiées ouvert à Cassandra, configuré pour ne jamais expirer. Lorsqu'un pare-feu est placé entre un processeur de messages et le serveur Cassandra, la connexion peut expirer. Toutefois, le processeur de messages n'est pas conçu pour rétablir les connexions à Cassandra.

Pour éviter cette situation, Apigee recommande que le serveur Cassandra, le processeur de messages et les routeurs se trouvent dans le même sous-réseau, afin qu'aucun pare-feu ne soit impliqué dans le déploiement de ces composants.

Si un pare-feu se trouve entre le routeur et les processeurs de messages, et qu'un délai d'inactivité tcp est défini, nous vous recommandons de procéder comme suit:

  1. Définissez net.ipv4.tcp_keepalive_time = 1800 dans les paramètres sysctl de l'OS Linux, où 1 800 doit être inférieur au délai d'inactivité tcp du pare-feu. Ce paramètre doit maintenir la connexion à un état établi afin que le pare-feu ne la déconnecte pas.
  2. Sur tous les processeurs de messages, modifiez /<inst_root>/apigee/customer/application/message-processor.properties pour ajouter la propriété suivante. Si le fichier n'existe pas, créez-le.
    conf_system_cassandra.maxconnecttimeinmillis=-1
  3. Redémarrez le processeur de messages:
    > /opt/apigee/apigee-service/bin/apigee-serviceedge-message-processor restart
  4. Sur tous les routeurs, modifiez /<inst_root>/apigee/customer/application/router.properties pour ajouter la propriété suivante. Si le fichier n'existe pas, créez-le.
    conf_system_cassandra.maxconnecttimeinmillis=-1
  5. Redémarrez le routeur:
    > /opt/apigee/apigee-service/bin/apigee-service Edge-router restart

Si vous installez les 12 configurations en cluster hôtes avec deux centres de données, assurez-vous que les nœuds des deux centres de données peuvent communiquer via les ports indiqués ci-dessous:

Exigences concernant les ports BaaS de l'API

Si vous choisissez d'installer l'API BaaS, vous ajoutez les composants de la pile BaaS de l'API et du portail BaaS d'API. Ces composants utilisent les ports indiqués dans la figure ci-dessous:

Remarques sur ce schéma:

  • Le portail BaaS de l'API n'envoie jamais de requêtes directement à un nœud de pile BaaS. Lorsqu'un développeur se connecte au portail, l'application Portal est téléchargée dans le navigateur. L'application de portail exécutée dans le navigateur envoie ensuite des requêtes aux nœuds de la pile BaaS.
  • Une installation de production d'API BaaS utilise un équilibreur de charge entre le nœud du portail BaaS de l'API et les nœuds de la pile BaaS de l'API. Lors de la configuration du portail et lorsque vous effectuez des appels d'API BaaS, vous devez spécifier l'adresse IP ou le nom DNS de l'équilibreur de charge, et non des nœuds de pile.
  • Tous les nœuds de pile doivent ouvrir le port 2551 pour y accéder depuis tous les autres nœuds de pile (indiqué par la flèche en forme de boucle dans le schéma ci-dessus pour le port 2551 sur les nœuds de pile). Si vous disposez de plusieurs centres de données, le port doit être accessible depuis tous les nœuds de pile de tous les centres de données.
  • Vous devez configurer tous les nœuds de la pile Baas pour envoyer des e-mails via un serveur SMTP externe. Pour le protocole SMTP non TLS, le numéro de port est généralement 25. Pour le protocole SMTP sur lequel TLS est activé, il s'agit souvent de 465. Veuillez vérifier auprès de votre fournisseur SMTP.
  • Les nœuds Cassandra peuvent être dédiés aux API BaaS ou partagés avec Edge.

Le tableau ci-dessous présente les ports par défaut à ouvrir dans les pare-feu, par composant:

Composant

Port

Description

Portail BaaS de l'API

9000

Port pour l'interface utilisateur BaaS de l'API

Pile BaaS d'API

8080

Port sur lequel les requêtes API sont reçues

2551

Port pour la communication entre tous les nœuds de pile. Doit être accessible par tous les autres nœuds de pile dans le répertoire de données.

Si vous disposez de plusieurs centres de données, le port doit être accessible depuis les nœuds de pile de tous les centres de données.

ElasticSearch

9 200 à 9 400

Pour la communication avec la pile BaaS de l'API et entre les nœuds ElasticSearch

Licences

Chaque installation d'Edge nécessite un fichier de licence unique que vous obtenez auprès d'Apigee. Vous devrez fournir 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 /<inst_root>/apigee/customer/conf/license.txt.

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

Si vous ne possédez pas encore de licence, contactez le service commercial en cliquant ici.