2016-10-27 2 views
2

J'ai récemment déployé WSO2 API Manager (2.0.0) en tant que cluster tout-en-un 2 instances (utilisant le système Hazelcast AWS) avec la source de données mysql comme spécifié dans ce link Depuis, impossible de trouver un guide complet d'installation étape par étape pour cette configuration. Je voudrais clarifier quelques domaines dont je ne suis pas sûr.WSO2 API Manager comme 2 installation tout-en-un instance

  1. Depsync via SVN - puisque ce sera manger à manger nœuds (au lieu de gestionnaire aux nœuds des travailleurs) tous deux ont <AutoCommit>true</AutoCommit>. Devrions-nous avoir des inquiétudes à ce sujet?
  2. DAS - DAS étant un nœud distinct, WSO2AM et WSO2DAS doivent-ils tous deux partager la même base de données WSO2AM_STATS_DB?
  3. Éditeur - Pouvons-nous utiliser les deux éditeurs (c'est-à-dire un à la fois)? Une fois que nous avons publié remarqué une API, il faut du temps pour autre éditeur pour synchroniser l'état de published (même si la nouvelle API apparaît presque immédiatement sur un autre éditeur comme created)

Merci.

Répondre

1

1) Si vous activez <AutoCommit>true</AutoCommit> dans les deux nœuds, cela peut provoquer des conflits svn s'il existe une publication parallèle depuis 2 nœuds. Au lieu de cela, vous pouvez publier sur plusieurs passerelles à partir de l'éditeur. Pour cela, vous pouvez configurer plusieurs environnements dans la section <Environments> dans api-manager.xml

2) Oui, DAS écrit des données récapitulatives dans ce DB, et les tableaux de bord APIM lisent les données du même DB.

3) Tous les nœuds éditeur/magasin doivent appartenir au même cluster. Alors seulement ils peuvent communiquer sur les changements d'état de l'API etc. Pour être sur le même cluster, tous ces nœuds doivent avoir le même domaine de clustering. Vous pouvez configurer cela dans la section clustering de axis2.xml.

+0

Merci Bhathiya. –

+0

Questions de suivi de couple 1) Je suis sur AWS et les nœuds peuvent être déployés automatiquement. Maintenir IP sera difficile. Par conséquent, je préfère éviter la configuration de l'environnement multi-passerelle de l'éditeur. Lorsque vous avez mentionné peut provoquer des conflits en raison de la publication parallèle, je suppose que lorsque l'administrateur a décidé d'ajouter ou de modifier l'API dans l'éditeur? Avec un contrôle approprié sur l'accès aux éditeurs - nous sommes en mesure d'atténuer ce problème? 3) Chaque nœud s'exécute en tant que JVM unique (sans profil) - Éditeur/Magasin/Gestionnaire de clés/Gestionnaire de trafic/GW dans une JVM et en cluster. Ai-je raison de dire que Publisher/Store dans ce cas sont groupés? –

+0

"La maintenance d'IP sera difficile." Vous pouvez utiliser des noms d'hôte. 1) Si vous pouvez garantir qu'une telle création/modification simultanée d'api n'aura pas lieu, le modèle svn devrait fonctionner. ou vous pouvez utiliser rsync. 3) oui, si les deux pub et store sont dans le même jvm, ils peuvent être considérés groupés. Mais ce que je voulais dire, c'est que vous devez regrouper deux nœuds de sorte que lorsqu'un éditeur modifie le statut d'un API, le deuxième éditeur peut le savoir. – Bee