Matériel requis
Vous devez respecter les configurations matérielles minimales 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écessiter 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 de stockage local avec SSD compatible avec 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* |
Analyses - Postgres maître ou de secours (autonome) | 16 Go* | 8 cœurs* | Stockage réseau de 500 Go à 1 To*****, de préférence avec un backend SSD, compatible avec 1 000 IOPS ou plus* |
Analytics – Qpid autonome | 16 Go | 8 cœurs | 30 Go à 50 Go de stockage local avec SSD
La taille de la file d'attente Qpid par défaut est de 1 Go, mais vous pouvez l'augmenter jusqu'à 2 Go. Si vous avez besoin de plus 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 |
* Ajustez les exigences système de Postgres en fonction du débit :
** La valeur du disque dur Postgres est basée sur les données analytiques prêtes à l'emploi collecté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 requis :
Exemple :
*** Le stockage réseau est recommandé pour la base de données PostgreSQL, car :
|
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 | 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é. |
Configuration système 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 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
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 apigee-setup Edge.
Créer l'utilisateur "apigee"
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 "apigee" utilisateur. 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 indiqué sous la forme /opt/apigee
.
Créer un lien symbolique à partir de /opt/apigee
Avant de créer le lien symbolique, vous devez d'abord créer un utilisateur et un groupe nommé "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.50.00.sh. Vous devez effectuer toutes ces étapes en mode root:
- Créer l'environnement "apigee" utilisateur et groupe:
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 souhaitée :ln -Ts /srv/myInstallDir /opt/apigee
Où /srv/myInstallDir est l'emplacement souhaité des fichiers Edge.
- 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 :
hostname
renvoie le nom de la machine.hostname -i
renvoie l'adresse IP du nom d'hôte qui peut être adressé à partir de ou 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.
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, vérifiez /etc/hosts.allow
et
/etc/hosts.deny
pour vous 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 périphériques qui ont des exigences particulières pour Processus en périphérie:
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 à
Si votre processus de sécurité vous oblige
à définir des autorisations sur
Vous pouvez définir les autorisations sur 744 pour
autoriser l’accès en lecture aux
|
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 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 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 :
- 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 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
Pour en savoir plus, consultez la section Paramètres de production recommandés dans la documentation Apache Cassandra.
- 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 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 des 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)
Network Security Services (NSS) est un ensemble de bibliothèques qui permet de développer des applications clientes et serveurs compatibles avec la sécurité. 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 recherche DNS sur IPv6 lorsque vous utilisez NSCD (Name Service Cache Daemon)
Si vous avez installé et activé NSCD (Name Service Cache Daemon), les processeurs de messages effectuer deux résolutions DNS: une pour IPv4 et une pour IPv6. Vous devez désactiver la recherche DNS sur IPv6 lorsque vous utilisez NSCD.
Pour désactiver la résolution DNS sur IPv6 :
- Sur chaque nœud de processeur de messages, modifiez
/etc/nscd.conf
- 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 devez 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 :
- Ouvrez
/etc/hosts
dans un éditeur. - Insérez un "#" 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
L'installateur utilise les outils UNIX suivants dans la version standard fournie par EL5 ou EL6.
awk |
expr |
libxslt |
tr/min |
unzip |
basename |
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 (de procps) | tr | miam |
date |
libdb-cxx |
ps |
uuid |
chkconfig |
nom de répertoire | libibverbes | pwd | Uname | |
echo | librdmacm | python |
ntpdate
Apigee recommande que les données les heures 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 l'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 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 d'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, OpenLDAP la réplication est nécessaire car plusieurs nœuds hébergent OpenLDAP.
Pare-feu et hôtes virtuels
Le terme virtual
est couramment surchargé dans le domaine de l'IT, et il en va de même pour un déploiement Apigee Edge pour Private Cloud 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 la technologie de VM pour créer des serveurs isolés pour leurs composants Apigee. Les hôtes de VM, comme les hôtes physiques, peuvent avoir des interfaces réseau et des pare-feu.
- Hôtes virtuels: points de terminaison Web, semblables à un hôte virtuel Apache.
Un routeur dans une VM peut exposer plusieurs hôtes virtuels (à condition qu'ils diffèrent les uns des autres dans leur alias d'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" dans la VM et à laquelle l'adresse IP 111.111.111.111
est attribuée par le mécanisme de virtualisation ou un serveur DHCP réseau. Supposons ensuite que VM2 expose une interface Ethernet virtuelle également appelée "eth0" et à laquelle une adresse IP 111.111.111.222
est attribuée.
Il est possible qu'un routeur Apigee s'exécute dans chacune des deux VM. Les routeurs exposent des points de terminaison d'hôte virtuel, comme dans cet exemple hypothétique :
Le routeur Apigee de la VM1 expose trois hôtes virtuels sur son interface eth0 (qui possède une adresse IP spécifique) : api.mycompany.com:80
, api.mycompany.com:443
et test.mycompany.com:80
.
Le routeur de la VM2 expose api.mycompany.com:80
(même nom et même port que ceux exposés par la VM1).
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
(111.111.111.111:{80, 443}
et 111.111.111.222:80
). Dans
De plus, le système d'exploitation de chaque VM peut
fournir son propre pare-feu sur son interface eth0,
doit autoriser le trafic des ports 80 et 443 à se connecter.
Le chemin de base est le troisième composant impliqué dans le routage des appels d'API vers les différents proxys d'API que vous avez peut-être déployés. Les bundles de proxy d'API peuvent partager un point de terminaison s'ils ont des chemins d'accès de base différents. 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. Dans l'exemple ci-dessus, vous pouvez déployer deux API :
mycompany
et testmycompany
, pour l'organisation
mycompany-org
par l'hôte virtuel qui possède l'alias d'hôte de
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 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 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
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.