Conditions requises pour l'installation

Edge for Private Cloud v. 4.16.09

Matériel requis

Vous devez respecter la configuration matérielle minimale requise suivante pour une infrastructure à haute disponibilité dans un environnement de production. 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 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.

En outre, la liste suivante répertorie la configuration matérielle requise si vous souhaitez installer les services de monétisation :

La liste suivante répertorie la configuration matérielle requise si vous souhaitez installer API BaaS :

Remarque :

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

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 listés sur la page https://apigee.com/docs/api-services/reference/supported-software.

Créer l'utilisateur apigee

La procédure d'installation crée un utilisateur du système Unix nommé "apigee". Les répertoires et fichiers Edge appartiennent à "apigee", tout comme les processus Edge. Cela signifie que les composants Edge s'exécutent en tant qu'utilisateur "apigee". Si nécessaire, vous pouvez exécuter les composants en tant qu'utilisateur différent. Pour obtenir un exemple, consultez la section "Associer le routeur à un port protégé" dans Installer des composants Edge sur un nœud.

Répertoire d'installation

Par défaut, le programme d'installation écrit tous les fichiers dans le répertoire /opt/apigee. Vous ne pouvez pas modifier l'emplacement de ce répertoire.

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

Java

Une version compatible de Java 1.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 vers la racine du JDK pour l'utilisateur qui effectue l'installation.

Paramètre des réseaux

Nous vous recommandons de vérifier les paramètres réseau avant l'installation. Le programme d'installation 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 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.

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 assurer la fiabilité et la tolérance aux pannes. La stratégie de réplication de chaque espace de clés Edge détermine les nœuds Cassandra où sont placées les instances répliquées. Pour en savoir plus,consultez À propos du facteur de réplication et du niveau de cohérence de Cassandra.

Cassandra ajuste automatiquement la taille de son tas de mémoire Java en fonction de la mémoire disponible. Pour en savoir plus, consultez Régler les ressources Java. En cas de dégradation des performances ou de consommation élevée de mémoire.

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

• cluster_name
• initial_token
• partitioner
• graines
• listen_address
• rpc_address
• vif d'or

Avertissement : Ne modifiez pas ce fichier.

Base de données PostgreSQL

Après avoir installé Edge, vous pouvez ajuster les paramètres de base de données PostgreSQL suivants en fonction de la quantité de RAM disponible sur votre système :

conf_postgresql_shared_buffers = 35% of RAM      # min 128kB
conf_postgresql_effective_cache_size = 45% of RAM
conf_postgresql_work_mem = 512MB       # min 64kB

Pour définir ces valeurs :

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

jsvc

"jsvc" est un prérequis pour utiliser l'API BaaS. La version 1.0.15-dev est installée lorsque vous installez l'API BaaS.

Network Security Services (NSS)

Network Security Services (NSS) est un ensemble de bibliothèques qui permet de développer des applications clientes et serveur sécurisées. Assurez-vous d'avoir installé NSS v3.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 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.

AWS AMI

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.

Remarque :

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

ntpdate : il est recommandé de synchroniser l'heure des serveurs. Si ce n'est pas déjà fait, l'utilitaire "ntpdate" peut servir à vérifier si les serveurs sont synchronisés. Vous pouvez utiliser "yum install ntp" pour installer l'utilitaire. Cela est particulièrement utile pour répliquer des configurations OpenLDAP. Notez que vous avez configuré le fuseau horaire du serveur sur 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 d'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, vous avez besoin de la réplication OpenLDAP, car plusieurs nœuds hébergent OpenLDAP.

Pare-feu et hôtes virtuels

Le terme "virtuel" est souvent surchargé dans le domaine informatique, et il en va de même pour un déploiement Apigee Edge pour Private Cloud et des hôtes virtuels. Pour clarifier, il existe deux utilisations principales du terme "virtuel" :

• Machines virtuelles (VM) : non requises, 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 disposer d'interfaces réseau et de pare-feu. Ces instructions d'installation ne sont pas spécifiquement compatibles avec les installations de VM.
• 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 par leur alias d'hôte ou leur port d'interface).

À titre d'exemple, 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 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 nommée eth0 et qu'elle se voit attribuer l'adresse IP 111.111.111.222.

Nous pourrions avoir un routeur Apigee s'exécutant dans chacune des deux VM. Les routeurs exposent les points de terminaison d'hôte virtuel, comme dans cet exemple hypothétique :

Le routeur Apigee de 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êmes nom et port que ceux exposés par la VM1).

Le système d'exploitation de l'hôte physique peut disposer d'un pare-feu réseau. Si tel est le cas, 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, et ceux-ci doivent également 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 différents proxys d'API que vous avez peut-être déployés. Les bundles de proxys d'API peuvent partager un point de terminaison s'ils ont des chemins de base différents. Par exemple, un chemin de base peut être défini comme http://api.mycompany.com:80/ et un autre comme http://api.mycompany.com:80/salesdemo.

Dans ce cas, vous avez besoin d'un équilibreur de charge ou d'un gestionnaire 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 qui possède l'alias d'hôte 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 l'URL 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/.

Exigences concernant les ports Edge

La gestion du pare-feu ne se limite pas aux hôtes virtuels. Les pare-feu des VM et des hôtes physiques doivent autoriser le trafic pour les ports requis par les composants pour communiquer entre eux.

L'image suivante montre les exigences de port pour chaque composant Edge :

Remarques concernant ce schéma :

• *Le port 8082 du processeur de messages ne doit être ouvert que pour l'accès par le routeur lorsque vous configurez TLS/SSL entre le routeur et le processeur de messages. Si vous ne configurez pas TLS/SSL entre le routeur et le processeur de messages, 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 n'a pas besoin d'y accéder.
• Les ports précédés de la lettre "M" sont utilisés pour gérer le composant. Ils doivent être ouverts 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 : routeur, processeur de messages, UI, Postgres et Qpid.
• Un processeur de messages doit ouvrir le port 4528 en tant que port de gestion. Si vous disposez de plusieurs processeurs de messages, ils doivent tous pouvoir accéder les uns aux autres via le port 4528 (indiqué par la flèche en boucle dans le schéma ci-dessus pour le port 4528 sur le processeur de messages). Si vous disposez de plusieurs centres de données, le port doit être accessible depuis tous les processeurs de messages de tous les centres de données.
• Bien que cela ne soit pas obligatoire, vous pouvez ouvrir le port 4527 sur le routeur pour qu'il soit accessible par n'importe quel processeur de messages. 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 disposez de plusieurs routeurs, ils doivent tous pouvoir accéder les uns aux autres via le port 4527 (indiqué par la flèche en boucle dans le schéma ci-dessus pour le port 4527 du routeur).
• L'interface utilisateur Edge nécessite l'accès au routeur, sur les ports exposés par les proxys d'API, pour prendre en charge le bouton Envoyer dans l'outil de trace.
• Le serveur de gestion nécessite un accès au port JMX sur les nœuds Cassandra.
• L'accès aux ports JMX peut être configuré pour exiger un nom d'utilisateur et un mot de passe. Pour en savoir plus, consultez Surveiller.
• Vous pouvez éventuellement configurer l'accès TLS/SSL pour certaines connexions, qui peuvent utiliser des ports différents. Pour en savoir plus, consultez TLS/SSL.
• Si vous configurez deux nœuds Postgres pour utiliser la réplication maître-secours, vous devez ouvrir le port 22 sur chaque nœud pour l'accès SSH. Vous pouvez éventuellement ouvrir des ports sur des nœuds individuels pour autoriser l'accès SSH.
• Vous pouvez configurer le serveur de gestion et l'interface utilisateur Edge pour envoyer des e-mails via un serveur SMTP externe. Si vous le faites, vous devez vous assurer que le serveur de gestion et l'interface utilisateur peuvent accéder au port nécessaire sur le serveur SMTP. Pour le protocole SMTP non TLS, le numéro de port est généralement 25. Pour le protocole SMTP compatible TLS, il s'agit souvent du port 465, mais vérifiez auprès de votre fournisseur SMTP.

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

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

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

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, il peut entraîner l'expiration de la connexion. Cependant, le processeur de messages n'est pas conçu pour rétablir les connexions à Cassandra.

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

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

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

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

Configuration requise au niveau des ports pour API BaaS

Si vous choisissez d'installer API BaaS, vous ajoutez les composants API BaaS Stack et API BaaS Portal. Ces composants utilisent les ports indiqués dans la figure ci-dessous :

Remarques concernant ce schéma :

• Le portail API BaaS n'envoie jamais de requêtes directement à un nœud de la pile BaaS. Lorsqu'un développeur se connecte au portail, l'application du portail 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 API BaaS et les nœuds de la pile 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 des nœuds de la pile.
• Vous devez configurer tous les nœuds de la pile Baas pour qu'ils envoient des e-mails via un serveur SMTP externe. Pour le protocole SMTP non TLS, le numéro de port est généralement 25. Pour le protocole SMTP compatible avec TLS, il s'agit souvent du port 465, mais vérifiez auprès de votre fournisseur SMTP.
• Les nœuds Cassandra peuvent être dédiés à 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 :

Licences

Chaque installation d'Edge nécessite un fichier de licence unique que vous obtenez auprès d'Apigee. Vous devrez fournir le chemin d'accès au fichier de licence lors de l'installation du serveur de gestion, par exemple /tmp/license.txt.

Le programme d'installation copie le fichier de licence dans /<inst_root>/apigee/customer/conf/license.txt.

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