Conditions requises pour l'installation

Edge pour Private Cloud version 4.17.09

Matériel requis

Pour bénéficier d'une disponibilité élevée, vous devez disposer de la configuration matérielle minimale requise ci-dessous. Google Cloud dans un environnement de production. Pour tous les scénarios d'installation décrits dans Installation Topologies (Topologies d'installation), les tables suivantes répertorient configuration matérielle minimale requise pour les composants d'installation.

<ph type="x-smartling-placeholder">

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

Composant d'installation

RAM

Processeur

Disque dur minimal

Cassandra

16 Go

8 cœurs

250 Go d'espace de stockage local avec SSD ou HDD rapide compatible avec 2 000 IOPS

Processeur de messages/routeur sur la même machine

16 Go

8 cœurs

100 Go

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

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, compatible avec 1 000 IOPS ou plus*.

Analytics – Version autonome de Postgres

16 Go*

8 cœurs*

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

Analytics – Qpid autonome

8 Go

4 cœurs

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

Pour les installations supérieures à 250 tâches par seconde, un disque dur avec stockage local prenant en charge 1 000 IOPS est recommandé.

La taille par défaut de la file d'attente Qpid est de 20 Go. Pour augmenter la capacité, ajoutez des Nœuds Qpid.

Autre (OpenLDAP, UI, serveur de gestion)

4GB

2 cœurs

60 Go

*Ajustez la configuration système Postgres en fonction du débit:

  • Moins de 250 tâches par seconde: 8 Go, 4 cœurs peuvent être envisagés avec un stockage réseau géré*** compatible avec 1 000 IOPS ou plus
  • Plus de 250 tâches par seconde: stockage réseau géré à 8 cœurs, 16 Go***, compatible avec 1 000 IOPS ou plus
  • Plus de 1 000 tâches par seconde: stockage réseau géré à 8 cœurs, 16 Go***, compatible avec 2 000 IOPS ou plus
  • Plus de 2 000 tâches par seconde: stockage réseau géré à 16 cœurs, 32 Go***, compatible avec 2 000 IOPS ou plus
  • Plus de 4 000 tâches par seconde: stockage réseau géré à 32 cœurs, 64 Go***, 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 Périphérie. Si vous ajoutez des valeurs personnalisées aux données d'analyse, alors ces valeurs doivent être a augmenté en conséquence. Utilisez la formule suivante pour estimer l'espace de stockage nécessaire:

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

Exemple:

(2 000 octets de données d'analyse par requête) x 100 requêtes/s x 3 600 s/h x 18 heures de pointe utilisation quotidienne x 30 jours/mois x conservation sur 3 mois = 1 194 393 600 000 octets ou 1 194,4 Go.

*** Stockage réseau recommandé pour la base de données Postgresql pour les raisons suivantes:

  • Il permet d'augmenter la taille de stockage de manière dynamique si et quand obligatoire.
  • Dans la plupart des cas, les IOPS réseau peuvent être ajustées à la volée environnement/stockage/réseau.
  • Les instantanés de niveau de stockage peuvent être activés pour la sauvegarde et la récupération de Google Cloud.

En outre, vous trouverez ci-dessous la configuration matérielle requise pour installer le 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

Analytics : Postgres/Qpid sur le même serveur

16 Go

8 cœurs

de 500 Go à 1 To d'espace de stockage réseau, de préférence avec un backend SSD, pouvant accepter 1 000 IOPS ou ou utilisez la règle du tableau ci-dessus.

Analytics – Version autonome de Postgres

16 Go

8 cœurs

de 500 Go à 1 To d'espace de stockage réseau, de préférence avec un backend SSD, pouvant accepter 1 000 IOPS ou ou utilisez la règle du 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 supérieures à 250 tâches par seconde, un disque dur avec stockage local prenant en charge 1 000 IOPS est recommandé.

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

Composant API BaaS

RAM

Processeur

Disque dur

ElasticSearch*

8 Go

4 cœurs

60 - 80 Go

Pile BaaS d'API *

8 Go

4 cœurs

60 - 80 Go

Portail API BaaS

1 Go

2 cœurs

20 Go

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

16 Go

8 cœurs

250 Go d'espace de stockage local avec SSD ou HDD rapide compatible avec 2 000 IOPS

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

Remarque :

  • Si le système de fichiers racine n'est pas assez volumineux pour l'installation, nous vous recommandons de de placer les données sur un disque plus grand.
  • Si une version plus ancienne d'Apigee Edge pour Private Cloud a été installée sur la machine, assurez-vous de supprimer le dossier /tmp/java avant une nouvelle installation.
  • Le dossier temporaire /tmp du système a besoin 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 appartient à "apigee:apigee".

Système d'exploitation et tiers configuration logicielle requise

Ces instructions d'installation et les fichiers d'installation fournis ont été testés sur le 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 périphériques les fichiers appartiennent à « apigee », tout comme les processus Edge. Cela signifie que les composants Edge s'exécutent "apigee" utilisateur. si nécessaire, vous pouvez exécuter les composants avec un autre nom d'utilisateur. Voir la section "Lier le routeur sur un port protégé dans la section Installer les composants Edge nœud pour obtenir un exemple.

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 le modifier l'emplacement du répertoire. Bien que vous ne puissiez pas modifier ce répertoire, vous pouvez créer un lien symbolique pour mapper /opt/apigee afin de un autre emplacement, comme décrit ci-dessous.

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

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é "apigee". C'est le même groupe et le même utilisateur créé 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éer l'environnement "apigee" utilisateur et groupe:
    &gt; groupadd -r Apigee
    &gt; useradd -r -g apigee -d /opt/apigee -s /sbin/nologin -c "Utilisateur de la plate-forme Apigee" Apigee
  2. Créez un lien symbolique de /opt/apigee vers l'installation souhaitée. racine:
    &gt; ln -Ts /srv/myInstallDir /opt/apigee
    /srv/myInstallDir est l'emplacement souhaité de Edge .
  3. Modifier la propriété de la racine d’installation et du lien symbolique sur « apigee » utilisateur:
    &gt; 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 compatibles sont listés ici:

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

Assurez-vous que JAVA_HOME pointe à la racine du JDK pour l'utilisateur effectuant l'installation.

SELinux

Selon vos paramètres pour SELinux, Edge peut rencontrer des problèmes lors de l'installation et du démarrage Composants Edge. Si nécessaire, vous pouvez désactiver SELinux ou le définir en mode permissif pendant l'installation, puis la réactiver après l'installation. Pour en savoir plus, consultez Installer l'utilitaire Edge de configuration Apigee.

Paramètre réseau

Nous vous recommandons de vérifier le paramètre réseau avant l'installation. Programme d'installation s'attend à ce que toutes les machines aient des adresses IP fixes. Utilisez les commandes suivantes pour valider :

  • hostname renvoie le nom de la machine
  • hostname -i renvoie l'adresse IP. pour le nom d'hôte qui peut ê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 est correctement définie. Pour en savoir plus, consultez la documentation de votre système d'exploitation spécifique.

Si un serveur possède plusieurs cartes d'interface, le "nom d'hôte -i" renvoie des valeurs séparées par un espace liste d'adresses IP. Par défaut, le programme d’installation Edge utilise la première adresse IP renvoyée, qui peuvent ne pas être correctes dans toutes les situations. Vous pouvez également définir la propriété suivante dans le fichier de configuration d'installation:

ENABLE_DYNAMIC_HOSTIP=y

Avec cette propriété définie sur "y", le programme d'installation vous invite à sélectionner l'adresse IP à utiliser comme de l'installation. La valeur par défaut est "n". Consultez la documentation de référence sur le fichier de configuration Edge pour plus d'informations.

Wrappers TCP

Les wrappers TCP peuvent bloquer la communication de certains ports et peuvent affecter OpenLDAP, Postgres et Installation de Cassandra. Sur ces nœuds, cochez /etc/hosts.allow et /etc/hosts.deny pour s'assurer qu'il n'existe aucune restriction de port sur les fichiers OpenLDAP, Postgres et Cassandra requis .

iptables

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

> sudo/etc/init.d/iptables stop

Sur CentOS 7.x:

> systemctl stop firewalld

S'assurer que Edge Router peut accéder à /etc/rc.d/init.d/functions

Les nœuds Edge Router et BaaS Portal 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, si vous ne les réglez pas sur 700, sinon le routeur ne démarre pas. Les autorisations peuvent être définies sur 744 pour permettre 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 pour garantir la fiabilité et la tolérance aux pannes. La stratégie de réplication pour chaque L'espace de clés périphérique détermine les nœuds Cassandra où sont placées les instances répliquées. Pour en savoir plus,consultez À propos de Cassandra Facteur de réplication et niveau de cohérence.

Cassandra ajuste automatiquement la taille de son tas de mémoire Java en fonction de la mémoire disponible. Pour en savoir plus, voir Réglage de Java ressources. En cas de dégradation des performances ou d'utilisation élevée de la mémoire.

Après avoir installé Edge pour Private Cloud, vous pouvez vérifier que Cassandra est configuré en examinant le fichier /&lt;inst_root&gt;/apigee/apigee-cassandra/conf/cassandra.yaml . Par exemple, assurez-vous que le script d'installation Edge pour Private Cloud définit les éléments suivants propriétés:

  • cluster_name
  • initial_token
  • partitionneur
  • graines
  • listen_address
  • rpc_address
  • chat

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 du 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:
    &gt; vi /&lt;inst_root&gt;/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 vos modifications.
  4. Redémarrez la base de données PostgreSQL:
    &gt; /<racine_inst_root>/apigee/apigee-service/bin/apigee-service apigee-postgresql redémarrer

Limites du système

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

  • Sur les nœuds Cassandra, définissez les limites de memlock souple et strict, de fichier nofile et d'espace d'adressage (AS) pour l'utilisateur de l'installation (par défaut est "apigee") dans /etc/security/limits.d/90-apigee-edge-limits.conf en tant que comme indiqué ci-dessous:
    apigee soft memlock illimité
    Apigee hard memlock illimité
    apigee soft nofile 32768
    apigee hard nofile 65536
    apigee soft comme illimité
    Apigee dur comme illimité

  • Sur les nœuds du processeur de messages, définissez le nombre maximal de descripteurs de fichier ouverts sur 64 000. dans /etc/security/limits.d/90-apigee-edge-limits.conf comme comme indiqué ci-dessous:
    fichier nofile doux Apigee 32768
    apigee hard nofile 65536


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

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, Network Security Services) sont un ensemble de bibliothèques des applications clientes et serveurs pour lesquels la sécurité est activée. Assurez-vous d'avoir installé NSS v3.19 ou ultérieure.

Pour vérifier votre version actuelle:

> yum info nss

Pour mettre à jour NSS:

> yum update nss

Consultez cet article de RedHat pour en savoir plus.

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 effectue deux résolutions DNS: une pour IPv4 et une pour IPv6. Vous devez désactiver la résolution DNS sur IPv6 lors de l'utilisation de NSCD.

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

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

Désactiver IPv6 sur Google Cloud Plate-forme pour RedHat/CentOS 7

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

Consultez la documentation RedHat ou CentOS pour votre version de système d'exploitation spécifique pour obtenir des instructions sur désactiver IPv6. Par exemple, vous pouvez :

  1. Ouvrez /etc/hosts dans une éditeur.
  2. Insérez un "#" dans la colonne 1 de la ligne suivante pour le mettre en commentaire:
    #::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

nom de base

grep

ls

rpm2cpio

ajouter un 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

sasl-cyrus
libdb-cxx
ps tr miam

date

libibverbes

pwd

uuid

chkconfig

nom de répertoire
librdmacm
python Uname
echo
libxslt

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, généralement, vous appelez "sudo <command>" ou “sudo PATH=$PATH:/usr/sbin:/sbin <command>".
  • Assurez-vous d'avoir installé l'outil "patch" avant d'utiliser un service pack (correctif). l'installation.

ntpdate : il est recommandé de synchroniser l'heure des serveurs. Si n'est pas encore configurée, l'utilitaire "ntpdate" pourrait servir cet objectif, qui vérifie si les serveurs sont synchronisés ou non. Vous pouvez utiliser yum install ntp pour installer la utilitaire. Ceci est particulièrement utile pour répliquer les configurations OpenLDAP. Notez que vous avez configuré des serveurs fuseau horaire UTC.

openldap 2.4 : l'installation sur site nécessite OpenLDAP 2.4. Si 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&quot; pour installer OpenLDAP.

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

Pare-feu et hôtes virtuels

Le terme « virtuel » est souvent surchargé dans le domaine informatique, et c'est donc avec une Apigee Edge pour le déploiement de cloud privé et les hôtes virtuels Pour clarifier, il existe deux principaux Utilisations du terme "virtuel" :

  • Machines virtuelles (VM): non obligatoire, mais certains déploiements utilisent une technologie de VM de créer des serveurs isolés pour leurs composants Apigee. Les hôtes de VM, comme les hôtes physiques, peuvent avoir des interfaces réseau et des 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 les uns des autres dans leur alias hôte ou dans leur port d'interface).

À titre d'exemple, un seul serveur physique "A" peut exécuter deux VM, nommée "VM1" et "VM2". Supposons que VM1 expose un réseau Ethernet virtuel interface, nommée eth0 interne à la VM, et à laquelle la virtualisation attribue l'adresse IP 111.111.111.111 des machines ou un serveur DHCP réseau ; et supposons que VM2 expose une interface Ethernet virtuelle nommée eth0 et se voit attribuer l'adresse IP 111.111.111.222.

Nous pouvons avoir un routeur Apigee en cours d'exécution dans chacune des deux VM. Les routeurs exposent l'hôte virtuel comme dans cet exemple:

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

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

Le système d'exploitation de l'hôte physique peut avoir un pare-feu de réseau ; si c'est le cas, le pare-feu doit être configuré pour transmettre le trafic TCP lié aux ports exposés sur le interfaces (111.111.111.111:{80, 443} et 111.111.111.222:80). De plus, chaque Le système d'exploitation d'une VM peut fournir son propre pare-feu sur son interface eth0, permettent au trafic 80 et 443 de 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 déployés. Les groupes de proxys d'API peuvent partager un point de terminaison s'ils ont des les chemins de base. Par exemple, un chemin de base peut être défini comme http://api.mycompany.com:80/ et un autre défini comme http://api.mycompany.com:80/salesdemo.

Dans ce cas, vous avez besoin d'un équilibreur de charge ou d'un directeur du trafic répartissant http://api.mycompany.com:80/ trafic 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 particulière et est configurée par votre groupe de réseau local.

Le chemin de base est défini lorsque vous déployez une API. Dans l'exemple ci-dessus, vous pouvez déployer deux API : monentreprise et testmonentreprise, pour l'organisation monentreprise-org par le hôte dont l'alias d'hôte est api.mycompany.com et dont le port est 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 auxquelles vous souhaitez vous connecter.

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

Configuration requise pour le port périphérique

La nécessité de gérer le pare-feu ne se limite pas aux hôtes virtuels ; à la fois une VM et un hôte physique les pare-feu doivent autoriser le trafic pour les ports requis par les composants pour communiquer avec chaque autre.

L'image suivante montre les ports requis pour chaque composant Edge:

Remarques sur ce schéma:

  • *Le port 8082 du processeur de messages doit être ouvert pour que le routeur puisse y accéder uniquement lorsque vous configurer 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, la configuration par défaut, le port 8082, doit toujours être ouvert sur le processeur de messages pour gérer le composant, mais le routeur ne nécessite pas y accéder.
  • Ports précédés de la lettre "M" sont les ports utilisés pour gérer le composant et doivent être ouverts sur le et doit être ouvert sur le composant 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: Router, le processeur de messages, l'UI, Postgres et Qpid.
  • Un processeur de messages doit ouvrir le port 4528 en tant que port de gestion. Si vous avez plusieurs Processeurs de messages : ils doivent tous pouvoir accéder les uns aux autres via le port 4528 (indiqué par le flèche en boucle du schéma ci-dessus pour le port 4528 sur le processeur de messages). Si vous avez plusieurs Centres de données, le port doit être accessible depuis tous les processeurs de messages de tous les centres de données.
  • Bien que cela ne soit pas obligatoire, vous pouvez ouvrir le port 4527 sur le routeur pour y accéder via n'importe quel message Processeur. Sinon, des messages d'erreur peuvent s'afficher 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 pouvoir accéder l'un à l'autre via le port 4527 (indiqué par la flèche en boucle dans la schéma ci-dessus pour le port 4527 sur le routeur).
  • L'interface utilisateur Edge nécessite un accès au routeur, sur les ports exposés par les mandataires d'API, pour prendre en charge à l'aide du bouton Send (Envoyer) de l'outil de traçage.
  • Le serveur de gestion a besoin d'accéder au port JMX sur le serveur Cassandra. nœuds.
  • L’accès aux ports JMX peut être configuré pour exiger un nom d’utilisateur/mot de passe. Pour en savoir plus, consultez la page Surveiller.
  • Vous pouvez éventuellement configurer l'accès TLS/SSL pour certaines connexions, qui peuvent utiliser différents ports. Consultez la section TLS/SSL pour plus encore.
  • Si vous configurez deux nœuds Postgres pour une utilisation de la réplication maître en mode veille, 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 un accès via SSH.
  • Vous pouvez configurer le serveur de gestion et l'interface utilisateur Edge pour envoyer des e-mails via un serveur SMTP externe Google Cloud. Dans ce cas, vous devez vous assurer que le serveur de gestion et l'interface utilisateur peuvent accéder aux sur le serveur SMTP. Pour le protocole SMTP non TLS, le numéro de port est généralement 25. Pour TLS SMTP, il s'agit souvent de 465, mais vérifiez auprès de votre fournisseur SMTP.

Le tableau ci-dessous indique les ports qui doivent être ouverts dans les pare-feu, par composant Edge:

Composant

Port

Description

Ports HTTP standards

80, 443

HTTP et tous les autres ports que vous utilisez pour les hôtes virtuels

Serveur de gestion

8080

Port pour les appels d'API de gestion Edge. Ces composants ont besoin d'accéder au port 8080 sur le serveur de gestion: routeur, processeur de messages, UI, Postgres et Qpid.

1099

Port JMX

4526

Pour le cache distribué et les appels 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 en provenance du routeur

8082

Port de gestion par défaut du processeur de messages et doit être ouvert sur le composant pour l'accès par le serveur de gestion.

Si vous configurez TLS/SSL entre le routeur et le processeur de messages, utilisé par le routeur pour effectuer des vérifications de l'état du processeur de messages.

1101

Port JMX

4528

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

Routeur

8081

Port de gestion par défaut du routeur ; doit être ouvert sur le composant pour que l'accès soit possible par le serveur de gestion.

4527

Pour le cache distribué et les appels de gestion

15999

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

Pour obtenir l'état d'un routeur, l'équilibreur de charge envoie une requête au port 15999 sur la 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 d'Edge par l'utilitaire apigee-validate. Cet utilitaire nécessite un accès au port 59001 sur le 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. sur

2888, 3888

Utilisé en interne par ZooKeeper pour le cluster ZooKeeper (appelé ensemble ZooKeeper). de communication

Cassandra

7000, 9042, 9160

Ports Apache Cassandra pour la communication entre les nœuds Cassandra et pour l'accès par d'autres composants Edge.

7199

Port JMX. Le serveur de gestion doit pouvoir y accéder.

Qpid

5672

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

8083

Port de gestion par défaut sur le serveur Qpid et doit être ouvert sur le composant pour l'accès par le serveur de gestion.

1102

Port JMX

4529

Pour le cache distribué et les appels de gestion

Postgres

5432

Utilisé pour la communication de Qpid/Management Server vers Postgres

8084

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

1103

Port JMX

4530

Pour le cache distribué et les appels de gestion

22

Si vous configurez deux nœuds Postgres pour une utilisation de la réplication maître en mode veille, 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 montre les mêmes ports, classés numériquement, avec la source et la destination composants:

Numéro de port

Objectif

Composant source

Composant de destination

<port de l'hôte virtuel#>

HTTP et tous les autres ports que vous utilisez pour le trafic des appels d'API de l'hôte virtuel. Ports 80 et 443 sont les plus couramment utilisées. 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)

Qpid Server (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 depuis le routeur

Serveur de gestion

Routeur

Processeur de messages

Processeur de messages

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

5432

Client Postgres

Serveur Qpid

Postgres

5672

Utilisé pour envoyer des analyses du routeur et du processeur de messages à 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 à l'accès sur le nœud Cassandra par l'équipe de gestion Google Cloud.

Client JMX

Cassandra

8080

Port de l'API de gestion

Clients de l'API Management

Serveur de gestion

8081 à 8084

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

Clients de l'API Management

Routeur (8081)

Processeur de messages (8082)

Qpid Server (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 Edge par défaut

Navigateur

Serveur d'interface utilisateur de gestion

9042

Transport natif CQL

Routeur

Processeur de messages

Serveur de gestion

Cassandra

9160

Client d'occasion 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 disponibles.

É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 demandes de page SmartDocs sont envoyées

SmartDocs

Routeur

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

Pour éviter cette situation, Apigee recommande que le serveur Cassandra, le processeur de messages et doivent se trouver dans le même sous-réseau afin qu'aucun pare-feu n'intervienne dans le déploiement de 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, nos recommandations sont les suivantes:

  1. Définissez net.ipv4.tcp_keepalive_time = 1 800 dans les paramètres sysctl sur l'OS Linux, où 1 800 doit être inférieur au nombre d'inactivité du pare-feu Délai avant expiration du tcp. Ce paramètre doit maintenir la connexion à un état établi afin que le pare-feu ne déconnecte pas la connexion.
  2. Sur tous les processeurs de messages, modifiez /&lt;inst_root&gt;/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:
    &gt; /opt/apigee/apigee-service/bin/apigee-service Edge-message-processor redémarrage
  4. Sur tous les routeurs, modifiez /&lt;inst_root&gt;/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:
    &gt; /opt/apigee/apigee-service/bin/apigee-service redémarrage du routeur périphérique

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

Exigences relatives aux ports BaaS pour l'API

Si vous choisissez d'installer l'API BaaS, vous ajoutez la pile d'API BaaS et les composants du portail API BaaS. 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 est téléchargée dans le navigateur. L'application Portal 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 d'API BaaS et de la pile d'API BaaS. Lorsque vous configurez le portail et que vous effectuez des appels d'API BaaS, vous Spécifiez l'adresse IP ou le nom DNS de l'équilibreur de charge, et non celui des nœuds de la pile.
  • Tous les nœuds de pile doivent ouvrir le port 2551 pour que tous les autres nœuds de pile puissent y accéder (indiqué par le flèche circulaire du schéma ci-dessus pour le port 2551 sur les nœuds de la pile). Si vous disposez de plusieurs Centres, 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 SMTP non TLS, le numéro de port est généralement 25. Pour le serveur SMTP TLS, il s'agit souvent de 465, mais vérifiez avec votre fournisseur SMTP.
  • Les nœuds Cassandra peuvent être dédiés à l'API BaaS ou partagés avec Edge.

Le tableau ci-dessous indique les ports par défaut qui doivent être ouverts dans les pare-feu, par composant:

Composant

Port

Description

Portail API BaaS

9000

Port de l'interface utilisateur BaaS de l'API

Pile d'API BaaS

8080

Port de réception des requêtes API

2551

Port pour la communication entre tous les nœuds de la pile. Doit être accessible par toutes les autres piles nœuds dans le modèle de canter de données.

Si vous avez plusieurs centres de données, le port doit être accessible à partir de tous les nœuds de pile dans tous les centres de données.

ElasticSearch

9 200 à 9 400

Pour la communication avec la pile d'API BaaS et entre ElasticSearch nœuds

Licences

Chaque installation d'Edge nécessite un fichier de licence unique obtenu auprès d'Apigee. Vous : 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 /&lt;inst_root&gt;/apigee/customer/conf/license.txt.

Si le fichier de licence est valide, le serveur de gestion valide la date d'expiration et autorise le message Nombre de processeurs (Mpx). Si l'un des paramètres de licence a expiré, vous trouverez les journaux dans le l'emplacement suivant: /&lt;inst_root&gt;/apigee/var/log/edge-management-server/logs. Dans ce cas, vous pouvez contacter l'assistance Apigee pour obtenir détails de la migration.

Si vous ne possédez pas encore de licence, cliquez ici pour contacter le service commercial.