Cette page a été traduite par l'API Cloud Translation.

Exigences concernant l'installation

Matériel requis

Pour bénéficier d'une infrastructure à disponibilité élevée dans un environnement de production, vous devez disposer de la configuration matérielle minimale requise ci-dessous.

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 la configuration matérielle minimale requise pour les composants d'installation.

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écessiter plus ou moins de ressources que celles indiquées ci-dessous.

Composant d'installation	RAM	CPU	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^ d'espace de stockage réseau^, de préférence avec un backend SSD, acceptant 1 000 IOPS ou plus^
Analyses - Postgres maître ou de secours (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 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 de davantage de capacité, ajoutez des nœuds Qpid.
OpenLDAP/UI/Serveur de gestion	8 Go	4 cœurs	60 Go
UI/Serveur de gestion	4GB	2 cœurs	60 Go
OpenLDAP (autonome)	4GB	2 cœurs	60 Go
^{* Ajuster la configuration système Postgres en fonction du débit: Moins de 250 tâches par seconde: possibilité d'utiliser une capacité de 8 Go à quatre cœurs et un stockage réseau géré^* acceptant 1 000 IOPS ou plus Plus de 250 tâches par seconde: stockage réseau géré à 8 cœurs, 16 Go^, pouvant atteindre 1 000 IOPS ou plus Plus de 1 000 tâches par seconde: stockage réseau géré à 8 cœurs, 16 Go^, pouvant accepter 2 000 IOPS ou plus Plus de 2 000 tâches par seconde: stockage réseau géré à 16 cœurs, 32 Go^, pouvant accepter 2 000 IOPS ou plus Plus de 4 000 tâches par seconde: stockage réseau géré de 64 Go à 32 cœurs^, pouvant accepter 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: 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} ^{*** 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 vous en avez besoin. Les IOPS réseau peuvent être ajustées à la volée dans la plupart des sous-systèmes d'environnement, de stockage et de 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.}

En outre, vous trouverez ci-dessous la configuration matérielle requise si vous souhaitez installer les services de monétisation (non compatibles avec l'installation tout-en-un):

Composant avec monétisation	RAM	CPU	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	Espace de stockage réseau compris entre 500 Go et 1 To, de préférence avec un backend SSD, acceptant 1 000 IOPS ou plus, ou utilisez la règle du tableau ci-dessus.
Analyses – Serveur Postgres (autonome) ou de secours	16 Go	8 cœurs	Espace de stockage réseau compris entre 500 Go et 1 To, de préférence avec un backend SSD, acceptant 1 000 IOPS ou plus, 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, il est recommandé d'utiliser un disque dur avec stockage local pouvant accepter 1 000 IOPS.

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

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

Java

Une version compatible de Java 1.8 doit être installée sur chaque machine avant l'installation. Les JDK compatibles sont listés sur la page 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.

Remarque : Le programme d'installation Edge peut installer Java 1.8 et définir JAVA_HOME pour vous dans le cadre du processus d'installation de apigee-setup. Pour en savoir plus, consultez la section Installer l'utilitaire Edge de configuration Apigee.

SELinux

Selon vos paramètres 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 en savoir plus, consultez la section Installer l'utilitaire Edge de configuration Apigee.

Créer l'utilisateur "apigee"

La procédure d'installation crée un utilisateur du système Unix nommé "apigee". Les répertoires et les fichiers Edge sont la propriété de "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 avec un autre nom d'utilisateur.

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 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 depuis /opt/apigee.

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

Création d'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". 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.52.02.sh. Vous devez effectuer toutes ces étapes en mode root:

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

Créez un lien symbolique de /opt/apigee vers la racine d'installation de votre choix :
```
ln -Ts /srv/myInstallDir /opt/apigee
```
Où /srv/myInstallDir est l'emplacement souhaité pour les fichiers Edge.
Remplacez la propriété de la racine d'installation et du lien symbolique par 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. Le programme d'installation s'attend à ce que toutes les machines aient des 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ée à 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 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, le programme d'installation Edge utilise la première adresse IP renvoyée, qui peut être incorrecte dans toutes les situations. Vous pouvez également définir la propriété suivante dans le fichier de configuration de l'installation:

ENABLE_DYNAMIC_HOSTIP=y

Avec cette propriété définie sur "y", le programme d'installation vous invite à sélectionner l'adresse IP à utiliser pour 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.

Avertissement:Si vous définissez ENABLE_DYNAMIC_HOSTIP=y, assurez-vous que votre fichier de propriétés ne définit pas HOSTIP.

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

Accès à l'annuaire

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

Service Annuaire Description

Routeur

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é 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. 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 service ZooKeeper risque de ne pas démarrer.

/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é 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.

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 service ZooKeeper risque de ne pas démarrer.

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 la section À propos du facteur de réplication et du niveau de cohérence Cassandra.

Cassandra ajuste automatiquement la taille de son tas de mémoire Java en fonction de la mémoire disponible. Pour en savoir plus, consultez la section Régler les 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 Edge for Private Cloud 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 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:

Modifiez le fichier postgresql.properties :
```
vi /opt/apigee/customer/application/postgresql.properties
```
Si le fichier n'existe pas, créez-le.
Définissez les propriétés indiquées ci-dessus.
Enregistrez vos modifications.

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 de processeur de messages:

Sur les nœuds Cassandra, définissez les limites de memlock souple et strict, de nofile et d'espace d'adressage (AS) pour l'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 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. C'est le cas, par exemple, si vous avez un grand nombre de fichiers temporaires ouverts à la fois.
Si vous rencontrez l'erreur suivante dans un routeur ou un processeur de messages system.log, il est possible que les limites de votre descripteur de fichier soient trop basses:
```
"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 du descripteur de fichier sur 100000, envoyez une demande à l'assistance Apigee Edge pour un dépannage supplémentaire.

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 client et serveur sécurisées. Assurez-vous d'avoir installé NSS 3.19 ou une version ultérieure.

Pour vérifier votre version actuelle:

yum info nss

Pour mettre à jour NSS:

yum update nss

Pour en savoir plus, consultez cet article de RedHat.

Désactiver la résolution DNS sur IPv6 lors de l'utilisation de NSCD (Name Service Cache Daemon)

Si vous avez installé et activé le 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:

Sur chaque nœud du processeur de messages, modifiez /etc/nscd.conf
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.

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

Ouvrez /etc/hosts dans un éditeur.
Insérez le caractère "#" dans la colonne 1 de la ligne suivante pour le mettre en commentaire :
```
#::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
```
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	libxlsx	tr/min	unzip
basename	grep	Lua Socket	rpm2cpio	ajouter un utilisateur
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	yum
date	libdb-cxx	ps	uuid	Chkconfig
dirname	libibverbes	pwd	Uname
echo	Librdmacm	python

ntpdate

Apigee recommande de synchroniser les heures de vos serveurs. Si ce n'est pas déjà fait, l'utilitaire ntpdate peut remplir cette fonction et vérifier si l'heure des serveurs est synchronisée ou non. Vous pouvez utiliser 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 en 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, 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 l'arène informatique, et il l'est donc avec un déploiement Apigee Edge pour Private Cloud et des hôtes virtuels. Pour clarifier, il existe deux utilisations principales du terme virtual:

Machines virtuelles (VM): ce n'est pas obligatoire, mais certains déploiements utilisent une technologie de VM afin de créer des serveurs isolés pour leurs composants Apigee. Les hôtes de VM, tels que 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 soient différents dans leur alias d'hôte ou dans leur port d'interface).

À titre d'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 la machine de virtualisation ou un serveur DHCP réseau a attribué l'adresse IP 111.111.111.111. Supposons ensuite que la VM2 expose une interface Ethernet virtuelle également nommée "eth0" et qu'une adresse IP lui soit attribuée : 111.111.111.222.

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

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

Le système d'exploitation de l'hôte physique peut avoir un pare-feu de réseau. Si tel est le cas, ce pare-feu 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 permettre au trafic des ports 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 éventuellement déployés. 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 en tant que http://api.mycompany.com:80/ et un autre en tant que 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 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 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, mycompany et testmycompany, pour l'organisation mycompany-org avec l'hôte virtuel dont l'alias d'hôte est api.mycompany.com et le port défini sur 80. Si vous ne déclarez pas de chemin de base dans le déploiement, le routeur ne sait pas à quelle API envoyer les requêtes entrantes.

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

Attribution de licences

Chaque installation d'Edge nécessite un fichier de licence unique obtenu 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 /opt/apigee/customer/conf/license.txt.

Si le fichier de licence est valide, le serveur de gestion valide le délai d'expiration et le nombre de processeurs de messages autorisé. Si l'un des paramètres de licence a expiré, les journaux se trouvent à 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 disposez pas encore d'une licence, contactez le service commercial d'Apigee.