Exigences concernant l'installation

Matériel requis

Vous devez respecter les configurations matérielles minimales requises suivantes pour une infrastructure hautement disponible 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 la section Topologies d'installation, les tableaux suivants répertorient les configuration matérielle minimale requise pour les composants d'installation.

Dans ces tableaux, les exigences concernant le 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é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 prenant en charge 2 000 IOPS
Processeur/routeur de messages sur la même machine 16 Go 8 cœurs 100 Go
Processeur de messages (autonome) 16 Go 8 cœurs 100 Go
Routeur (autonome) 16 Go 8 cœurs 100 Go
Analytics : Postgres/Qpid sur le même serveur 16 Go* 8 cœurs* Entre 500 Go et 1 To** de stockage réseau***, de préférence avec un backend SSD, compatible avec 1 000 IOPS ou plus*
Analytics : maître ou standby Postgres (autonome) 16 Go* 8 cœurs* 500 Go à 1 To** de stockage réseau***, de préférence avec un backend SSD, compatible avec 1 000 IOPS ou plus*
Analytics - Qpid autonome 8 Go 4 cœurs Entre 30 Go et 50 Go de stockage local avec SSD

La taille par défaut de la file d'attente Qpid est de 1 Go, mais elle peut être augmentée jusqu'à 2 Go. Si vous avez besoin plus de capacité, ajoutez des nœuds Qpid.

OpenLDAP/UI/Serveur de gestion 8 Go 4 cœurs 60 Go
Serveur d'interface utilisateur/de gestion 4GB 2 cœurs 60 Go
OpenLDAP (autonome) 4GB 2 cœurs 60 Go

* Ajustez les exigences système de Postgres en fonction du débit :

  • Moins de 250 tâches par seconde: 8 Go, 4 cœurs peuvent être envisagés avec un réseau géré. stockage*** compatible avec 1 000 IOPS ou plus
  • 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 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 TPS : stockage réseau géré de 64 Go et 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, alors ces valeurs doivent être augmentées en conséquence. Utilisez la formule suivante pour estimer l'espace de stockage nécessaire:

bytes of storage needed =

  (# bytes of analytics data/request) *

  (requests/second) *

  (seconds/hour) *

  (hours of peak usage/day) *

  (days/month) *

  (months of data retention)

Exemple :

(2K bytes) * (100 req/sec) * (3600 secs/hr) * (18 peak hours/day) * (30 days/month) * (3 months retention)

= 1,194,393,600,000 bytes or 1194.4 GB of storage needed

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

  • 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, la liste suivante indique les exigences matérielles si vous souhaitez installer les services de monétisation (non compatibles avec l'installation tout-en-un) :

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 : maître ou standby Postgres autonome 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 40 Go à 500 Go de stockage local avec SSD ou disque dur rapide

Pour les installations supérieures à 250 TPS, un disque dur avec un stockage local compatible avec 1 000 IOPS est recommandé.

Système d'exploitation et tiers configuration logicielle requise

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 dans la section Logiciels pris en charge et versions prises en charge.

Java

Une version compatible de Java 1.8 doit être installée sur chaque machine avant l'installation. Les JDK pris en charge sont répertoriés dans Logiciels et versions compatibles

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

SELinux

En fonction de vos paramètres pour SELinux, Edge peut rencontrer des problèmes d'installation et de 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 de configuration Apigee.

Créer le fichier "apigee" utilisateur

La procédure d'installation crée un utilisateur 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 des composants en tant qu'utilisateur différent.

Répertoire d'installation

Par défaut, l'installateur écrit tous les fichiers dans le répertoire /opt/apigee. Vous ne pouvez pas modifier cet emplacement de 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 la section Créer un lien symbolique à partir de /opt/apigee.

Dans les instructions de ce guide, le répertoire d'installation est désigné par /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 de l'utilisateur créés par l'installateur Edge.

Pour créer le lien symbolique, procédez comme suit avant de télécharger le fichier bootstrap_4.52.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 "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

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

  3. Modifiez la propriété de la 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 le paramètre réseau avant l'installation. L'installateur 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 qui peut être adressé à partir de 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 l'hôte n'est pas défini correctement. Pour en savoir plus, consultez la documentation de votre système d'exploitation spécifique.

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, l'installateur d'Edge utilise la première adresse IP renvoyée, ce qui peut ne pas être correct 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". Pour en savoir plus, consultez la documentation de référence sur le fichier de configuration Edge.

Wrappers TCP

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

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 lors de l'installation à l'aide de la commande suivante :

sudo/etc/init.d/iptables stop

Sur CentOS 7.x:

systemctl stop firewalld

Accès à l'annuaire

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

Service Annuaire Description
Routeur /etc/rc.d/init.d/functions

Le routeur Edge utilise le routeur Nginx et nécessite un accès en lecture à /etc/rc.d/init.d/functions

Si votre processus de sécurité vous oblige à définir des autorisations sur /etc/rc.d/init.d/functions, ne les définissez pas sur 700, sinon le routeur ne démarrera pas.

Vous pouvez définir les autorisations sur 744 pour autoriser l'accès en lecture à /etc/rc.d/init.d/functions.

ZooKeeper /dev/random La bibliothèque cliente Zookeeper nécessite un accès en lecture au générateur de nombres aléatoires /dev/random. Si /dev/random est bloqué en lecture, le Le service ZooKeeper risque de ne pas démarrer.

Cassandra

Tous les nœuds Cassandra doivent être connectés à un anneau. Cassandra stocke des répliques de données sur plusieurs nœuds 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 la section À propos du facteur de réplication Cassandra et du 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, consultez Réglage des ressources Java 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 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é définit 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 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 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

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 les limites de memlock souple et strict, de fichier nofile et d'espace d'adressage (AS) pour Utilisateur de l'installation (par défaut : "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 de processeur de messages, définissez le nombre maximal de descripteurs de fichiers ouverts sur 64 Ko 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 system.log de routeur ou de processeur de messages, il est possible que les limites de votre descripteur de fichier soient définies trop bas :

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

    Vous pouvez vérifier le nombre maximal 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.

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é la version 3.19 ou ultérieure de NSS.

Pour vérifier votre version actuelle :

yum info nss

Pour mettre à jour NSS :

yum update nss

Consultez cet article. chez 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 effectuent deux recherches DNS : une pour IPv4 et une pour IPv6. Vous devez désactiver la résolution DNS sur IPv6 lorsque à l'aide 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 no

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.

Pour savoir comment désactiver IPv6, consultez la documentation RedHat ou CentOS de votre version d'OS spécifique. Par exemple, vous pouvez :

  1. Ouvrez /etc/hosts dans un é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

libxslt

tr/min

unzip

nom de base

grep

lua-socket

rpm2cpio

useradd

bash

nom d'hôte

ls

sed

wc

bc

id

net-tools

sudo

wget

curl

Liibaio

perl (à partir de procps)

tar

xerces-c

sasl-cyrus libdb4 pgrep (à partir de procps) tr miam

date

libdb-cxx

ps

uuid

chkconfig

nom de répertoire libibverbes pwd uname  
echo librdmacm python    

ntpdate

Apigee vous recommande de vous assurer que les heures de vos serveurs sont synchronisées. Si ce n'est pas déjà configuré, l'utilitaire ntpdate peut servir cette fonction, qui vérifie si les serveurs sont synchronisés ou non. Vous pouvez utiliser yum install ntp pour installer utilitaire. Cela est particulièrement utile pour répliquer des 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 votre serveur dispose d'une connexion Internet, puis 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 les installations à 12 hôtes avec deux centres de données, la réplication OpenLDAP est requise, car plusieurs nœuds hébergent OpenLDAP.

Pare-feu et hôtes virtuels

Le terme virtual est souvent surchargé dans le domaine informatique, ce qui en fait une Apigee Edge pour le déploiement de cloud privé et les hôtes virtuels Pour clarifier, le terme virtual est utilisé de deux manières principales :

  • 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, analogues à 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 une interface Ethernet virtuelle, qui est nommée "eth0" interne à la VM, à laquelle l'adresse IP 111.111.111.111 est attribuée les machines de virtualisation ou un serveur DHCP réseau ; et que la VM2 expose une instance Interface Ethernet également nommée "eth0" qui se voit attribuer une adresse IP 111.111.111.222

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 a 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 VM1).

Le système d'exploitation de l'hôte physique peut disposer d'un pare-feu réseau. Si tel est le cas, ce pare-feu doit être configuré pour transmettre 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. Celui-ci doit également autoriser la connexion du trafic sur les ports 80 et 443.

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 d'accès 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 directeur de trafic qui répartit le trafic http://api.mycompany.com:80/ entre les deux adresses IP (111.111.111.111 sur VM1 et 111.111.111.222 sur 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 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 auxquelles vous souhaitez vous connecter.

Toutefois, si vous déployez l'API testmycompany avec l'URL de base de /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 : 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 /opt/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 (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 en savoir plus sur la migration.

Si vous ne possédez pas encore de licence, contactez le service commercial d'Apigee.