Notes de version d'Edge for Private Cloud

Dans un premier temps, Mint n'évalue pas les transactions

Edge for the Private Cloud n'évalue pas initialement les transactions lorsque vous activez la monétisation pour une organisation pour la première fois. Cela s'applique aux organisations nouvelles et existantes.

L'API d'activation de la monétisation répond avec l'ID de la tâche et, une fois celle-ci terminée, l'état de celle-ci indique la réussite de celle-ci. Toutefois, les appels d'API monétisés effectués initialement ne seront pas traités par la monétisation et ne seront pas évalués. Ces transactions n'apparaîtront que dans les données analytiques standards.

Solution :

apigee-service edge-message-processor restart

Une fois la monétisation activée, le redémarrage des MP entraîne le chargement par Edge de la configuration de ZooKeeper au démarrage. Cela se produit à chaque redémarrage, ce qui signifie que le problème ne s'applique qu'au départ.

Fuite de mémoire des serveurs d'évaluation Mint

Lorsqu'une nouvelle instance Qpid est enregistrée dans un mxgroup, les files d'attente se créent sans les utilisateurs. La profondeur de la file d'attente augmente donc jusqu'à ce qu'elle utilise toutes les ressources disponibles.

Solution :

Format du fichier de métadonnées pour l'installation de apigee-sso

Lors de l'installation de apigee-sso et de l'utilisation d'un fichiermetadata.xml au lieu d'une URL, si celui-ci ne comporte pas de nouvelle ligne (CRLF) à la fin, il n'est pas lu entièrement.

Solution :

Pour contourner ce problème, vous pouvez effectuer l'une des opérations suivantes:

• Ajoutez un CRLF à la fin du fichiermetadata.xml

  OU

• Indiquez un emplacement basé sur une URL pour les métadonnées

apigee-monit n'est pas compatible avec Amazon Linux 1

Solution :

La sauvegarde du processeur de messages ne sauvegarde pas le bon ensemble de fichiers

Solution :

Exécutez la sauvegarde une deuxième fois. Elle devrait sauvegarder le bon ensemble de fichiers.

DataAccessException dans plusieurs configurations de centres de données

Dans plusieurs configurations de centres de données, si un datastore devient indisponible, l'erreur suivante peut s'afficher:

DataAccessException: Error while accessing datastore;
Please retry later

Il se peut donc que Management Server ne démarre pas, car il tente de se connecter aux nœuds Cassandra à la fois dans dc-1 et dc-2. Le DataAccessExceptions se produit si un nœud Cassandra est en panne. Cela peut également entraîner une interruption du trafic de l'API, où les processeurs de messages signalent DataAccessExceptions lors de la tentative de récupération des KVM.

Notez que l'état attendu est que le serveur de gestion ne se connecte pas aux composants du datastore entre les régions.

Solution

La solution consiste à annuler l'enregistrement des types de nœuds Cassandra suivants dans le centre de données indisponible, puis à les réenregistrer une fois que les nœuds Cassandra sont à nouveau disponibles:

• kms-datastore
• dc-datastore
• keyvaluemap-datastore

Pour annuler l'enregistrement de ces types de nœuds Cassandra et les réenregistrer:

1. Obtenez les UUID des nœuds Cassandra à l'aide de la commande curl suivante :

   curl -u ADMIN_EMAIL:ADMIN_PW \
     "http://MS_IP:MS_PORT/v1/servers?region=REGION&pod=GATEWAY_POD \
     &type=CASSANDRA_NODE_TYPE"

   Où :

   • ADMIN_EMAIL et ADMIN_PW sont les identifiants de votre compte Apigee.
   • MS_IP et MS_PORT sont l'adresse IP et le numéro de port du serveur de gestion.
   • REGION est le nom du centre de données dans lequel se trouve le serveur de gestion.
   • GATEWAY_POD est le nom du pod, qui correspond par défaut à "passerelle". Il se peut toutefois que vous l'ayez renommé autrement. Vérifiez votre implémentation.
   • CASSANDRA_NODE_TYPE est l'une des valeurs suivantes : kms-datastore, dc-datastore ou keyvaluemap-datastore.

   Exemple :

   curl -u nickdanger@google.com:myP@$$w0rD
     "http://192.168.0.1:8080/v1/servers?region=dc-1&pod=gateway&type=dc-datastore"

   La réponse utilise le format suivant :

   {
     "internalIP" : "POD_IP_ADDRESS",
     "isUp" : [true|false],
     "pod" : "GATEWAY_POD",
     "reachable" : [true|false],
     "region" : "dc-1",
     "tags" : {
       "property" : [ ]
     },
     "type" : [ "kms-datastore", "dc-datastore", "keyvaluemap-datastore" ],
       "uUID" : "POD_UUID"
   }

   Exemple :

   {
     "internalIP" : "192.168.1.11",
     "isUp" : false,
     "pod" : "gateway",
     "reachable" : false,
     "region" : "dc-1",
     "tags" : {
       "property" : [ ]
     },
     "type" : "dc-datastore",
     "uUID" : "13cee956-d3a7-4577-8f0f-1694564179e4"
   }

   Notez les valeurs du champ uUID dans la réponse. Vous les utiliserez pour annuler l'enregistrement des nœuds.

2. Répétez l'étape 1 pour chaque type de nœud Cassandra: kms-datastore, dc-datastore et keyvaluemap-datastore. Prenez note des UUID renvoyés.
3. Annulez l'enregistrement des nœuds à l'aide de la commande suivante :

   curl -u ADMIN_EMAIL:ADMIN_PW "http://MS_IP:MS_PORT/v1/servers/UUID" -X DELETE

   Où UUID correspond à l'UUID renvoyé dans la réponse de la commande précédente.

4. Répétez l'étape 3 pour chaque UUID que vous avez collecté aux étapes 1 et 2.
5. Réenregistrez les nœuds à l'aide de la commande suivante :

   curl -u ADMIN_EMAIL:ADMIN_PW "http://MS_IP:MS_PORT/v1/servers -d \
     "Type=kms-datastore&Type=dc-datastore&Type=keyvaluemap-datastore& \
     Type=counter-datastore&Type=cache-datastore&InternalIP=POD_IP_ADDRESS& \
     region=REGION&pod=GATEWAY_POD" -H \
     'content-type: application/x-www-form-urlencoded' -X POST

Notez que ces opérations enregistrent et annulent l'enregistrement des nœuds auprès de Zookeeper et n'ont aucune incidence sur le cluster Cassandra. Pour en savoir plus sur ces commandes, consultez la page Mettre à jour les enregistrements dans le datastore.

Règle MessageLogging incluant des informations supplémentaires dans le message de journal

L'élément FormatMessage de la règle MessageLogging contrôle le format du message enregistré. Lorsque la valeur est FormatMessage=false, le message journal n'est pas censé inclure des informations générées par Apigee. Toutefois, même si vous définissez FormatMessage=false, le message de journal inclut toujours les informations suivantes:

• Le niveau de priorité
• Le code temporel

Solution :