इंस्टॉलेशन से जुड़ी ज़रूरतें

Edge for Private Cloud v. 4.16.09

हार्डवेयर की ज़रूरी शर्तें

प्रोडक्शन ग्रेड एनवायरमेंट में बहुत ज़्यादा अपटाइम वाले इन्फ़्रास्ट्रक्चर के लिए, आपको हार्डवेयर से जुड़ी ये ज़रूरी शर्तें पूरी करनी होंगी. इंस्टॉलेशन टोपोलॉजी में बताए गए सभी इंस्टॉलेशन के लिए, यहां दी गई टेबल में इंस्टॉलेशन कॉम्पोनेंट के लिए हार्डवेयर की ज़रूरी शर्तें बताई गई हैं.

इन टेबल में, हार्ड डिस्क के लिए ज़रूरी डिस्क में बचा स्टोरेज, ऑपरेटिंग सिस्टम के लिए ज़रूरी हार्ड डिस्क में बचे स्टोरेज के अलावा है. आपके ऐप्लिकेशन और नेटवर्क ट्रैफ़िक के आधार पर, आपके इंस्टॉलेशन के लिए यहां दिए गए संसाधनों से ज़्यादा या कम संसाधनों की ज़रूरत पड़ सकती है.

इंस्टॉलेशन कॉम्पोनेंट

रैम

सीपीयू

हार्ड डिस्क में कम से कम स्टोरेज

Cassandra

16 जीबी

8-कोर

एसएसडी या फ़ास्ट एचडीडी के साथ 250 जीबी का लोकल स्टोरेज, जो 2,000 आईओपीएस के साथ काम करता हो

एक ही मशीन पर मैसेज प्रोसेसर/राउटर

8/16 जीबी

4‑कोर†

100 जीबी

Analytics - Postgres/Qpid on same server (not recommended for production)

16 जीबी*

8-कोर*

500 जीबी - 1 टीबी** नेटवर्क स्टोरेज***, एसएसडी बैकएंड के साथ, जो 1,000 आईओपीएस या इससे ज़्यादा* को सपोर्ट करता हो.

Analytics - Postgres standalone

16 जीबी*

8-कोर*

500 जीबी - 1 टीबी** नेटवर्क स्टोरेज***, जो एसएसडी बैकएंड के साथ हो और 1,000 IOPS या इससे ज़्यादा* के साथ काम करता हो.

Analytics - Qpid standalone

8 जीबी

4-कोर

एसएसडी या तेज़ एचडीडी के साथ 30 जीबी - 50 जीबी लोकल स्टोरेज

अगर आपको 250 टीपीएस से ज़्यादा इंस्टॉल करने हैं, तो हमारा सुझाव है कि आप 1,000 आईओपीएस के साथ लोकल स्टोरेज वाली एचडीडी का इस्तेमाल करें.

अन्य (OpenLDAP, यूज़र इंटरफ़ेस (यूआई), मैनेजमेंट सर्वर)

4 जीबी

2-कोर

60 जीबी

† थ्रूपुट के आधार पर, मैसेज प्रोसेसर के सिस्टम की ज़रूरतों में बदलाव करें:

हमारा सुझाव है कि आपके पास कम से कम 4-कोर वाला सिस्टम होना चाहिए. वहीं, हाई थ्रूपुट सिस्टम के लिए 8-कोर वाला सिस्टम होना चाहिए. अपने एपीआई के लिए सही साइज़ तय करने के लिए, परफ़ॉर्मेंस टेस्ट चलाए जा सकते हैं.

*थ्रूपुट के आधार पर, Postgres सिस्टम की ज़रूरी शर्तों में बदलाव करें:

  • 250 टीपीएस से कम: 8 जीबी, 4-कोर को मैनेज किए गए नेटवर्क स्टोरेज*** के साथ इस्तेमाल किया जा सकता है. यह 1,000 आईओपीएस या इससे ज़्यादा के साथ काम करता है
  • 250 टीपीएस से ज़्यादा: 16 जीबी, 8-कोर, मैनेज किया गया नेटवर्क स्टोरेज***, जो 1,000 आईओपीएस या इससे ज़्यादा के साथ काम करता हो
  • 1,000 टीपीएस से ज़्यादा: 16 जीबी, 8-कोर, मैनेज किया गया नेटवर्क स्टोरेज***, जो 2,000 आईओपीएस या इससे ज़्यादा को सपोर्ट करता हो
  • 2,000 टीपीएस से ज़्यादा: 32 जीबी, 16-कोर, मैनेज किया गया नेटवर्क स्टोरेज***, जो 2,000 आईओपीएस या इससे ज़्यादा को सपोर्ट करता हो
  • 4,000 टीपीएस से ज़्यादा: 64 जीबी, 32-कोर, मैनेज किया गया नेटवर्क स्टोरेज***, जो 4,000 आईओपीएस या इससे ज़्यादा के साथ काम करता है

**Postgres हार्ड डिस्क की वैल्यू, Edge से कैप्चर किए गए आउट ऑफ़ द बॉक्स आंकड़ों पर आधारित होती है. अगर Analytics डेटा में कस्टम वैल्यू जोड़ी जाती हैं, तो इन वैल्यू को उसी हिसाब से बढ़ाया जाना चाहिए. ज़रूरी स्टोरेज का अनुमान लगाने के लिए, इस फ़ॉर्मूले का इस्तेमाल करें:

(# बाइट/अनुरोध) * (हर सेकंड अनुरोध) * (हर घंटे सेकंड) * (हर दिन सबसे ज़्यादा इस्तेमाल के घंटे) * (हर महीने दिन) * (डेटा के रखरखाव के महीने) = ज़रूरी स्टोरेज के बाइट

उदाहरण के लिए:

(हर अनुरोध के लिए 2K बाइट का Analytics डेटा) * 100 अनुरोध/सेकंड * 3600 सेकंड/घंटा * हर दिन सबसे ज़्यादा इस्तेमाल के 18 घंटे * 30 दिन/महीना * 3 महीने का रखरखाव = 1,194,393,600,000 बाइट या 1194.4 जीबी.

*** Postgresql डेटाबेस के लिए, नेटवर्क स्टोरेज का सुझाव दिया जाता है, क्योंकि:

  • इससे ज़रूरत पड़ने पर, स्टोरेज के साइज़ को डाइनैमिक तरीके से बढ़ाया जा सकता है.
  • आज के ज़्यादातर एनवायरमेंट/स्टोरेज/नेटवर्क सबसिस्टम में, नेटवर्क IOPS को ज़रूरत के हिसाब से अडजस्ट किया जा सकता है.
  • बैकअप और रिकवरी के समाधान के तौर पर, स्टोरेज लेवल के स्नैपशॉट चालू किए जा सकते हैं.

इसके अलावा, अगर आपको कमाई करने की सेवाएं इंस्टॉल करनी हैं, तो यहां हार्डवेयर से जुड़ी ज़रूरी शर्तें दी गई हैं:

कमाई करने की सुविधा वाला कॉम्पोनेंट

रैम

सीपीयू

हार्ड डिस्क

मैनेजमेंट सर्वर (कमाई करने की सेवाओं के साथ)

8 जीबी

4-कोर

60 जीबी

Analytics - Postgres/Qpid on same server

16 जीबी

8-कोर

500 जीबी - 1 टीबी नेटवर्क स्टोरेज, जो एसएसडी बैकएंड के साथ हो और 1, 000 आईओपीएस या इससे ज़्यादा को सपोर्ट करता हो. इसके अलावा, ऊपर दी गई टेबल में मौजूद नियम का इस्तेमाल करें.

Analytics - Postgres standalone

16 जीबी

8-कोर

500 जीबी - 1 टीबी नेटवर्क स्टोरेज, जो एसएसडी बैकएंड के साथ हो और 1, 000 आईओपीएस या इससे ज़्यादा को सपोर्ट करता हो. इसके अलावा, ऊपर दी गई टेबल में मौजूद नियम का इस्तेमाल करें.

Analytics - Qpid standalone

8 जीबी

4-कोर

40 जीबी

अगर आपको API BaaS इंस्टॉल करना है, तो यहां दी गई हार्डवेयर की ज़रूरी शर्तें पूरी करनी होंगी:

एपीआई BaaS कॉम्पोनेंट

रैम

सीपीयू

हार्ड डिस्क

ElasticSearch*

8 जीबी

4-कोर

60 - 80 जीबी

एपीआई BaaS स्टैक *

8 जीबी

4-कोर

60 - 80 जीबी

API BaaS Portal

1GB

2-कोर

20 जीबी

Cassandra (ज़रूरी नहीं — आम तौर पर, Edge और API BaaS, दोनों सेवाओं के लिए एक ही Cassandra क्लस्टर का इस्तेमाल किया जाता है)

16 जीबी

8-कोर

एसएसडी या फ़ास्ट एचडीडी के साथ 250 जीबी का लोकल स्टोरेज, जो 2,000 आईओपीएस के साथ काम करता हो

* ElasticSearch और API BaaS स्टैक को एक ही नोड पर इंस्टॉल किया जा सकता है. अगर ऐसा है, तो ElasticSearch को 4 जीबी मेमोरी (डिफ़ॉल्ट) का इस्तेमाल करने के लिए कॉन्फ़िगर करें. अगर ElasticSearch को उसके नोड पर इंस्टॉल किया गया है, तो उसे 6 जीबी मेमोरी का इस्तेमाल करने के लिए कॉन्फ़िगर करें.

ध्यान दें:

  • अगर रूट फ़ाइल सिस्टम में इंस्टॉलेशन के लिए ज़रूरत के मुताबिक जगह नहीं है, तो हमारा सुझाव है कि डेटा को किसी बड़ी डिस्क पर सेव करें.
  • अगर मशीन पर Apigee Edge for Private Cloud का कोई पुराना वर्शन इंस्टॉल किया गया था, तो पक्का करें कि नया वर्शन इंस्टॉल करने से पहले, /tmp/java फ़ोल्डर को मिटा दिया गया हो.
  • Cassandra को शुरू करने के लिए, सिस्टम के अस्थायी फ़ोल्डर /tmp को एक्ज़ीक्यूट करने की अनुमतियां चाहिए.
  • अगर इंस्टॉलेशन से पहले उपयोगकर्ता “apigee” बनाया गया था, तो पक्का करें कि “/home/apigee” होम डायरेक्ट्री के तौर पर मौजूद हो और उसका मालिकाना हक “apigee:apigee” के पास हो.

ऑपरेटिंग सिस्टम और तीसरे पक्ष के सॉफ़्टवेयर से जुड़ी ज़रूरी शर्तें

इंस्टॉल करने के इन निर्देशों और इंस्टॉल करने के लिए दी गई फ़ाइलों को, यहां दिए गए ऑपरेटिंग सिस्टम और तीसरे पक्ष के सॉफ़्टवेयर पर टेस्ट किया गया है: https://apigee.com/docs/api-services/reference/supported-software.

Apigee उपयोगकर्ता बनाना

इंस्टॉल करने की प्रोसेस के दौरान, 'apigee' नाम का एक यूनिक्स सिस्टम उपयोगकर्ता बनता है. Edge की डायरेक्ट्री और फ़ाइलों का मालिकाना हक 'apigee' के पास होता है. Edge की प्रोसेस का मालिकाना हक भी इसी के पास होता है. इसका मतलब है कि Edge कॉम्पोनेंट, 'apigee' उपयोगकर्ता के तौर पर चलते हैं. ज़रूरत पड़ने पर, कॉम्पोनेंट को किसी दूसरे उपयोगकर्ता के तौर पर चलाया जा सकता है. उदाहरण के लिए, नोड पर Edge कॉम्पोनेंट इंस्टॉल करना में "राऊटर को सुरक्षित पोर्ट से बाइंड करना" देखें.

इंस्टॉलेशन डायरेक्ट्री

डिफ़ॉल्ट रूप से, इंस्टॉलर सभी फ़ाइलों को /opt/apigee डायरेक्ट्री में सेव करता है. इस डायरेक्ट्री की जगह की जानकारी को नहीं बदला जा सकता.

इस गाइड में दिए गए निर्देशों में, इंस्टॉलेशन डायरेक्ट्री को /<inst_root>/apigee के तौर पर नोट किया गया है. इसमें /<inst_root> डिफ़ॉल्ट रूप से /opt है.

Java

इंस्टॉल करने से पहले, आपको हर मशीन पर Java1.8 का ऐसा वर्शन इंस्टॉल करना होगा जो काम करता हो. इस्तेमाल किए जा सकने वाले JDK की सूची यहां दी गई है:

https://apigee.com/docs/api-services/reference/supported-software

पक्का करें कि JAVA_HOME, इंस्टॉल करने वाले उपयोगकर्ता के लिए जेडीके के रूट पर ले जाता हो.

नेटवर्क सेटिंग

हमारा सुझाव है कि इंस्टॉल करने से पहले, नेटवर्क सेटिंग की जांच कर लें. इंस्टॉलर को उम्मीद होती है कि सभी मशीनों के आईपी पते तय हों. सेटिंग की पुष्टि करने के लिए, इन निर्देशों का इस्तेमाल करें:

  • hostname, मशीन का नाम दिखाता है
  • hostname -i, होस्टनेम का आईपी पता दिखाता है. इस आईपी पते को अन्य मशीनों से ऐक्सेस किया जा सकता है.

अगर होस्टनेम सही तरीके से सेट नहीं है, तो आपको अपने ऑपरेटिंग सिस्टम के टाइप और वर्शन के हिसाब से, /etc/hosts और /etc/sysconfig/network में बदलाव करना पड़ सकता है. ज़्यादा जानकारी के लिए, अपने ऑपरेटिंग सिस्टम का दस्तावेज़ देखें.

Cassandra

सभी Cassandra नोड को एक रिंग से कनेक्ट करना होगा. Cassandra, डेटा की कॉपी को कई नोड पर सेव करता है, ताकि डेटा को सुरक्षित रखा जा सके और गड़बड़ियों को ठीक किया जा सके. हर Edge कीस्पेस के लिए, रेप्लिकेशन की रणनीति से यह तय होता है कि Cassandra नोड में रेप्लिका कहां रखे जाएंगे. ज़्यादा जानने के लिए,Cassandra के रेप्लिकेशन फ़ैक्टर और कंसिस्टेंसी लेवल के बारे में जानकारी लेख पढ़ें.

Cassandra, उपलब्ध मेमोरी के आधार पर अपने Java हीप साइज़ को अपने-आप अडजस्ट करता है. ज़्यादा जानकारी के लिए, Java के संसाधनों को ट्यून करना लेख पढ़ें. परफ़ॉर्मेंस में गिरावट या मेमोरी का ज़्यादा इस्तेमाल होने पर.

Edge for Private Cloud को इंस्टॉल करने के बाद, यह जांचा जा सकता है कि Cassandra को सही तरीके से कॉन्फ़िगर किया गया है या नहीं. इसके लिए, /<inst_root>/apigee/apigee-cassandra/conf/cassandra.yaml फ़ाइल की जांच करें. उदाहरण के लिए, पक्का करें कि Edge for Private Cloud की इंस्टॉलेशन स्क्रिप्ट में ये प्रॉपर्टी सेट हों:

  • cluster_name
  • initial_token
  • partitioner
  • seeds
  • listen_address
  • rpc_address
  • snitch

चेतावनी: इस फ़ाइल में बदलाव न करें.

PostgreSQL डेटाबेस

Edge इंस्टॉल करने के बाद, अपने सिस्टम में उपलब्ध रैम के हिसाब से, PostgreSQL डेटाबेस की इन सेटिंग में बदलाव किया जा सकता है:

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

इन वैल्यू को सेट करने के लिए:

  1. postgresql.properties में बदलाव करें:
    > vi /<inst_root>/apigee/customer/application/postgresql.properties

    अगर फ़ाइल मौजूद नहीं है, तो उसे बनाएं.
  2. ऊपर दी गई प्रॉपर्टी सेट करें.
  3. किए गए बदलाव सेव करें.
  4. PostgreSQL डेटाबेस को रीस्टार्ट करें:
    > /<inst_root>/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

jsvc

"jsvc" is a prerequisite for using API BaaS. एपीआई BaaS इंस्टॉल करने पर, वर्शन 1.0.15-dev इंस्टॉल हो जाता है.

नेटवर्क सिक्योरिटी सर्विसेज़ (एनएसएस)

नेटवर्क सिक्योरिटी सर्विसेज़ (एनएसएस), लाइब्रेरी का एक सेट है. यह सुरक्षा की सुविधा वाले क्लाइंट और सर्वर ऐप्लिकेशन को डेवलप करने में मदद करता है. आपको यह पक्का करना चाहिए कि आपने NSS v3.19 या इसके बाद का वर्शन इंस्टॉल किया हो.

अपने मौजूदा वर्शन की जांच करने के लिए:

> yum info nss

एनएसएस को अपडेट करने के लिए:

> yum update nss

ज़्यादा जानकारी के लिए, RedHat का यह लेख पढ़ें.

RedHat/CentOS 7 के लिए, Google Cloud Platform पर IPv6 को बंद करना

अगर Google Cloud Platform पर RedHat 7 या CentOS 7 पर Edge इंस्टॉल किया जा रहा है, तो आपको सभी Qpid नोड पर IPv6 को बंद करना होगा.

IPv6 को बंद करने के निर्देशों के लिए, अपने ओएस वर्शन के हिसाब से RedHat या CentOS का दस्तावेज़ देखें.

AWS AMI

अगर Red Hat Enterprise Linux 7.x के लिए, AWS Amazon Machine Image (AMI) पर Edge इंस्टॉल किया जा रहा है, तो आपको पहले यह कमांड चलाना होगा:

> yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

टूल

इंस्टॉलर, EL5 या EL6 के स्टैंडर्ड वर्शन में दिए गए इन UNIX टूल का इस्तेमाल करता है.

awk

dirname

ls

आरपीएम

अनज़िप करना

basename

ईको

perl

rpm2cpio

useradd

bash

expr

pgrep (procps से)

sed

wc

bc

grep

ps

tar

लज़ीज़

curl

hostname

pwd

tr

chkconfig

तारीख

आईडी

python

uname

sudo

ध्यान दें:

  • ‘useradd’ टूल के लिए एक्ज़ीक्यूटेबल फ़ाइल /usr/sbin में और chkconfig के लिए /sbin में मौजूद होती है.
  • sudo ऐक्सेस की मदद से, कॉल करने वाले उपयोगकर्ता के एनवायरमेंट का ऐक्सेस पाया जा सकता है. उदाहरण के लिए, आम तौर पर “sudo <command>” या “sudo PATH=$PATH:/usr/sbin:/sbin <command>” को कॉल किया जाता है.
  • पक्का करें कि सर्विस पैक (पैच) इंस्टॉल करने से पहले, आपने “पैच” टूल इंस्टॉल किया हो.

ntpdate – हमारा सुझाव है कि सर्वर का समय सिंक किया जाए. अगर पहले से कॉन्फ़िगर नहीं किया गया है, तो ‘ntpdate’ यूटिलिटी का इस्तेमाल किया जा सकता है. इससे यह पुष्टि की जाती है कि सर्वर का समय सिंक किया गया है या नहीं. यूटिलिटी इंस्टॉल करने के लिए, “yum install ntp” का इस्तेमाल किया जा सकता है. यह OpenLDAP सेटअप को कॉपी करने के लिए खास तौर पर मददगार है. ध्यान दें कि आपने सर्वर का टाइम ज़ोन यूटीसी में सेट किया हो.

openldap 2.4 – कंपनी की इमारत में इंस्टॉलेशन के लिए, OpenLDAP 2.4 ज़रूरी है. अगर आपके सर्वर में इंटरनेट कनेक्शन है, तो Edge इंस्टॉल स्क्रिप्ट, OpenLDAP को डाउनलोड और इंस्टॉल करती है. अगर आपके सर्वर में इंटरनेट कनेक्शन नहीं है, तो आपको यह पक्का करना होगा कि Edge इंस्टॉल स्क्रिप्ट चलाने से पहले, OpenLDAP इंस्टॉल हो. RHEL/CentOS पर, OpenLDAP इंस्टॉल करने के लिए, "yum install openldap-clients openldap-servers" चलाया जा सकता है.

13-होस्ट इंस्टॉलेशन और दो डेटा सेंटर वाले 12-होस्ट इंस्टॉलेशन के लिए, आपको OpenLDAP रेप्लिकेशन की ज़रूरत होती है. ऐसा इसलिए, क्योंकि OpenLDAP को होस्ट करने वाले कई नोड होते हैं.

फ़ायरवॉल और वर्चुअल होस्ट

आईटी सेक्टर में, “वर्चुअल” शब्द का इस्तेमाल आम तौर पर कई चीज़ों के लिए किया जाता है. ऐसा ही, Apigee Edge for Private Cloud डिप्लॉयमेंट और वर्चुअल होस्ट के साथ भी होता है. “वर्चुअल” शब्द के दो मुख्य इस्तेमाल हैं:

  • वर्चुअल मशीन (वीएम): ज़रूरी नहीं है, लेकिन कुछ डिप्लॉयमेंट में वीएम टेक्नोलॉजी का इस्तेमाल किया जाता है, ताकि Apigee के कॉम्पोनेंट के लिए अलग सर्वर बनाए जा सकें. फ़िज़िकल होस्ट की तरह, वीएम होस्ट में भी नेटवर्क इंटरफ़ेस और फ़ायरवॉल हो सकते हैं. इंस्टॉल करने के ये निर्देश, खास तौर पर वीएम इंस्टॉलेशन के लिए नहीं हैं.
  • वर्चुअल होस्ट: वेब एंडपॉइंट, जो Apache वर्चुअल होस्ट की तरह होते हैं.

वीएम में मौजूद कोई राऊटर, कई वर्चुअल होस्ट दिखा सकता है. हालांकि, इसके लिए ज़रूरी है कि वे अपने होस्ट के उपनाम या इंटरफ़ेस पोर्ट में एक-दूसरे से अलग हों.

नाम रखने के उदाहरण के तौर पर, एक फ़िज़िकल सर्वर “A” पर दो वीएम चल रहे हों, जिनका नाम “VM1” और “VM2” हो. मान लें कि VM1 एक वर्चुअल ईथरनेट इंटरफ़ेस दिखाता है, जिसका नाम वीएम में eth0 रखा जाता है. साथ ही, जिसे वर्चुअलाइज़ेशन मशीनरी या नेटवर्क डीएचसीपी सर्वर से आईपी पता 111.111.111.111 असाइन किया जाता है. इसके बाद, मान लें कि VM2 एक वर्चुअल ईथरनेट इंटरफ़ेस दिखाता है, जिसका नाम eth0 है और उसे आईपी पता 111.111.111.222 असाइन किया जाता है.

ऐसा हो सकता है कि दोनों वीएम में Apigee राऊटर चल रहा हो. राऊटर, वर्चुअल होस्ट एंडपॉइंट को एक्सपोज़ करते हैं, जैसा कि इस उदाहरण में दिखाया गया है:

VM1 में मौजूद Apigee राऊटर, अपने eth0 इंटरफ़ेस पर तीन वर्चुअल होस्ट दिखाता है. इस इंटरफ़ेस का एक खास आईपी पता होता है. ये वर्चुअल होस्ट हैं: api.mycompany.com:80, api.mycompany.com:443, और test.mycompany.com:80.

VM2 में मौजूद राऊटर, api.mycompany.com:80 को एक्सपोज़ करता है. यह वही नाम और पोर्ट है जिसे VM1 ने एक्सपोज़ किया है.

ऐसा हो सकता है कि फ़िज़िकल होस्ट के ऑपरेटिंग सिस्टम में नेटवर्क फ़ायरवॉल हो. अगर ऐसा है, तो उस फ़ायरवॉल को इस तरह कॉन्फ़िगर किया जाना चाहिए कि वह वर्चुअल इंटरफ़ेस (111.111.111.111:{80, 443} और 111.111.111.222:80) पर एक्सपोज़ किए जा रहे पोर्ट के लिए टीसीपी ट्रैफ़िक को पास कर सके. इसके अलावा, हर वीएम का ऑपरेटिंग सिस्टम, अपने eth0 इंटरफ़ेस पर अपना फ़ायरवॉल उपलब्ध करा सकता है. साथ ही, इन्हें भी पोर्ट 80 और 443 ट्रैफ़िक को कनेक्ट करने की अनुमति देनी होगी.

बेसपाथ, एपीआई कॉल को अलग-अलग एपीआई प्रॉक्सी पर रूट करने में शामिल तीसरा कॉम्पोनेंट है. इन एपीआई प्रॉक्सी को आपने डिप्लॉय किया होगा. एपीआई प्रॉक्सी बंडल, एंडपॉइंट शेयर कर सकते हैं. हालांकि, इसके लिए ज़रूरी है कि उनके बेसपाथ अलग-अलग हों. उदाहरण के लिए, एक बेसपाथ को http://api.mycompany.com:80/ और दूसरे को http://api.mycompany.com:80/salesdemo के तौर पर तय किया जा सकता है.

इस मामले में, आपको किसी लोड बैलेंसर या ट्रैफ़िक डायरेक्टर की ज़रूरत होगी, जो http://api.mycompany.com:80/ ट्रैफ़िक को दो आईपी पतों (VM1 पर 111.111.111.111 और VM2 पर 111.111.111.222) के बीच बांट सके. यह फ़ंक्शन, आपके खास इंस्टॉलेशन के लिए है. इसे आपके लोकल नेटवर्किंग ग्रुप ने कॉन्फ़िगर किया है.

एपीआई को डिप्लॉय करने पर, बेसपाथ सेट हो जाता है. ऊपर दिए गए उदाहरण के मुताबिक, mycompany-org संगठन के लिए, दो एपीआई mycompany और testmycompany डिप्लॉय किए जा सकते हैं. इसके लिए, आपको उस वर्चुअल होस्ट का इस्तेमाल करना होगा जिसका होस्ट उपनाम api.mycompany.com और पोर्ट 80 पर सेट हो. अगर डिप्लॉयमेंट में बेसपाथ का एलान नहीं किया जाता है, तो राऊटर को यह नहीं पता चलता कि आने वाले अनुरोधों को किस एपीआई पर भेजना है.

हालांकि, अगर /salesdemo के बेस यूआरएल के साथ एपीआई testmycompany को डिप्लॉय किया जाता है, तो उपयोगकर्ता http://api.mycompany.com:80/salesdemo का इस्तेमाल करके उस एपीआई को ऐक्सेस करते हैं. अगर आपने / के बेस यूआरएल के साथ, mycompany एपीआई को डिप्लॉय किया है, तो आपके उपयोगकर्ता http://api.mycompany.com:80/ यूआरएल का इस्तेमाल करके एपीआई को ऐक्सेस कर सकते हैं.

एज पोर्ट के लिए ज़रूरी शर्तें

फ़ायरवॉल को मैनेज करने की ज़रूरत सिर्फ़ वर्चुअल होस्ट तक सीमित नहीं है. वीएम और फ़िज़िकल होस्ट, दोनों के फ़ायरवॉल को उन पोर्ट के लिए ट्रैफ़िक की अनुमति देनी चाहिए जिनकी ज़रूरत कॉम्पोनेंट को एक-दूसरे से कम्यूनिकेट करने के लिए होती है.

यहां दी गई इमेज में, Edge के हर कॉम्पोनेंट के लिए पोर्ट की ज़रूरी शर्तें दिखाई गई हैं:

इस डायग्राम के बारे में जानकारी:

  • *मैसेज प्रोसेसर पर पोर्ट 8082 को सिर्फ़ तब खुला रखना होता है, जब आपको राऊटर और मैसेज प्रोसेसर के बीच टीएलएस/एसएसएल को कॉन्फ़िगर करना हो. ऐसा करने पर, राऊटर को ऐक्सेस मिल जाता है. अगर आपने राऊटर और मैसेज प्रोसेसर के बीच टीएलएस/एसएसएल को कॉन्फ़िगर नहीं किया है, तो कॉम्पोनेंट को मैनेज करने के लिए, मैसेज प्रोसेसर पर डिफ़ॉल्ट कॉन्फ़िगरेशन, पोर्ट 8082 अब भी खुला होना चाहिए. हालांकि, राऊटर को इसका ऐक्सेस देने की ज़रूरत नहीं है.
  • "M" प्रीफ़िक्स वाले पोर्ट का इस्तेमाल, कॉम्पोनेंट को मैनेज करने के लिए किया जाता है. साथ ही, मैनेजमेंट सर्वर से ऐक्सेस करने के लिए, कॉम्पोनेंट पर ये पोर्ट खुले होने चाहिए.
  • इन कॉम्पोनेंट को मैनेजमेंट सर्वर पर पोर्ट 8080 के ऐक्सेस की ज़रूरत होती है: राऊटर, मैसेज प्रोसेसर, यूज़र इंटरफ़ेस (यूआई), Postgres, और Qpid.
  • मैसेज प्रोसेसर को पोर्ट 4528 को मैनेजमेंट पोर्ट के तौर पर खोलना होगा. अगर आपके पास एक से ज़्यादा मैसेज प्रोसेसर हैं, तो वे सभी पोर्ट 4528 पर एक-दूसरे को ऐक्सेस कर सकते हों. ऊपर दिए गए डायग्राम में, मैसेज प्रोसेसर पर पोर्ट 4528 के लिए लूप ऐरो से यह दिखाया गया है. अगर आपके पास कई डेटा सेंटर हैं, तो सभी डेटा सेंटर में मौजूद सभी मैसेज प्रोसेसर से पोर्ट को ऐक्सेस किया जा सकता हो.
  • हालांकि, यह ज़रूरी नहीं है, लेकिन किसी भी मैसेज प्रोसेसर से ऐक्सेस करने के लिए, राऊटर पर पोर्ट 4527 को खोला जा सकता है. ऐसा न करने पर, आपको मैसेज प्रोसेसर की लॉग फ़ाइलों में गड़बड़ी के मैसेज दिख सकते हैं.
  • राऊटर को अपने मैनेजमेंट पोर्ट के तौर पर, पोर्ट 4527 खोलना होगा. अगर आपके पास एक से ज़्यादा राऊटर हैं, तो वे सभी पोर्ट 4527 पर एक-दूसरे को ऐक्सेस कर सकते हों. ऊपर दिए गए डायग्राम में, राऊटर पर पोर्ट 4527 के लिए लूप ऐरो से यह दिखाया गया है.
  • Edge यूज़र इंटरफ़ेस (यूआई) को एपीआई प्रॉक्सी से एक्सपोज़ किए गए पोर्ट पर, राऊटर का ऐक्सेस चाहिए. इससे ट्रेस टूल में भेजें बटन काम कर पाएगा.
  • मैनेजमेंट सर्वर को Cassandra नोड पर मौजूद JMX पोर्ट का ऐक्सेस चाहिए.
  • जेएमएक्स पोर्ट के ऐक्सेस को इस तरह कॉन्फ़िगर किया जा सकता है कि उपयोगकर्ता नाम/पासवर्ड की ज़रूरत पड़े. ज़्यादा जानकारी के लिए, मॉनिटर करने का तरीका देखें.
  • आपके पास कुछ कनेक्शन के लिए, टीएलएस/एसएसएल ऐक्सेस को कॉन्फ़िगर करने का विकल्प होता है. ये कनेक्शन, अलग-अलग पोर्ट का इस्तेमाल कर सकते हैं. ज़्यादा जानकारी के लिए, टीएलएस/एसएसएल देखें.
  • अगर मास्टर-स्टैंडबाय रेप्लिकेशन का इस्तेमाल करने के लिए, दो Postgres नोड कॉन्फ़िगर किए जा रहे हैं, तो आपको एसएसएच ऐक्सेस के लिए हर नोड पर पोर्ट 22 खोलना होगा. आपके पास अलग-अलग नोड पर पोर्ट खोलने का विकल्प होता है, ताकि एसएसएच ऐक्सेस की अनुमति दी जा सके.
  • मैनेजमेंट सर्वर और Edge यूज़र इंटरफ़ेस (यूआई) को कॉन्फ़िगर करके, बाहरी एसएमटीपी सर्वर से ईमेल भेजे जा सकते हैं. अगर ऐसा किया जाता है, तो आपको यह पक्का करना होगा कि मैनेजमेंट सर्वर और यूज़र इंटरफ़ेस (यूआई), एसएमटीपी सर्वर पर ज़रूरी पोर्ट को ऐक्सेस कर सकें. नॉन-टीएलएस एसएमटीपी के लिए, पोर्ट नंबर आम तौर पर 25 होता है. टीएलएस की सुविधा वाले एसएमटीपी के लिए, यह अक्सर 465 होता है. हालांकि, एसएमटीपी की सेवा देने वाली कंपनी से इसकी पुष्टि कर लें.

नीचे दी गई टेबल में, Edge कॉम्पोनेंट के हिसाब से फ़ायरवॉल में खोले जाने वाले पोर्ट की जानकारी दी गई है:

कॉम्पोनेंट

पोर्ट

ब्यौरा

स्टैंडर्ड एचटीटीपी पोर्ट

80, 443

एचटीटीपी के साथ-साथ, वर्चुअल होस्ट के लिए इस्तेमाल किए जाने वाले अन्य पोर्ट

मैनेजमेंट सर्वर

8080

Edge मैनेजमेंट एपीआई कॉल के लिए पोर्ट. इन कॉम्पोनेंट को मैनेजमेंट सर्वर पर पोर्ट 8080 के ऐक्सेस की ज़रूरत होती है: राऊटर, मैसेज प्रोसेसर, यूज़र इंटरफ़ेस (यूआई), Postgres, और Qpid.

1099

जेएमएक्स पोर्ट

4526

डिस्ट्रिब्यूटेड कैश मेमोरी और मैनेजमेंट कॉल के लिए

मैनेजमेंट यूज़र इंटरफ़ेस (यूआई)

9000

मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) को ब्राउज़र से ऐक्सेस करने के लिए पोर्ट

मैसेज प्रोसेसर

8998

राऊटर से कम्यूनिकेशन के लिए मैसेज प्रोसेसर पोर्ट

8082

मैसेज प्रोसेसर के लिए डिफ़ॉल्ट मैनेजमेंट पोर्ट. मैनेजमेंट सर्वर से ऐक्सेस करने के लिए, इसे कॉम्पोनेंट पर खुला होना चाहिए.

अगर आपने राऊटर और मैसेज प्रोसेसर के बीच टीएलएस/एसएसएल को कॉन्फ़िगर किया है, तो राऊटर इसका इस्तेमाल मैसेज प्रोसेसर पर हेल्थ चेक करने के लिए करता है.

1101

जेएमएक्स पोर्ट

4528

मैसेज प्रोसेसर के बीच डिस्ट्रिब्यूटेड कैश मेमोरी और मैनेजमेंट कॉल के लिए और राऊटर से कम्यूनिकेशन के लिए

राऊटर

8081

राऊटर के लिए डिफ़ॉल्ट मैनेजमेंट पोर्ट. मैनेजमेंट सर्वर से ऐक्सेस करने के लिए, कॉम्पोनेंट पर इसे खुला रखना ज़रूरी है.

4527

डिस्ट्रिब्यूटेड कैश मेमोरी और मैनेजमेंट कॉल के लिए

15999

हेल्थ चेक पोर्ट. लोड बैलेंसर इस पोर्ट का इस्तेमाल करके यह पता लगाता है कि राऊटर उपलब्ध है या नहीं.

राऊटर की स्थिति जानने के लिए, लोड बैलेंसर, राऊटर पर पोर्ट 15999 को अनुरोध भेजता है:

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

अगर राऊटर को ऐक्सेस किया जा सकता है, तो अनुरोध एचटीटीपी 200 दिखाता है.

ZooKeeper

2181

इसका इस्तेमाल मैनेजमेंट सर्वर, राऊटर, मैसेज प्रोसेसर जैसे अन्य कॉम्पोनेंट करते हैं

2888, 3888

ZooKeeper क्लस्टर (इसे ZooKeeper एन्सेम्बल भी कहा जाता है) के बीच कम्यूनिकेशन के लिए, ZooKeeper इसका इस्तेमाल करता है

Cassandra

7000, 9042, 9160

Cassandra नोड के बीच कम्यूनिकेशन के लिए और Edge के अन्य कॉम्पोनेंट के ऐक्सेस के लिए, Apache Cassandra पोर्ट.

7199

जेएमएक्स पोर्ट. मैनेजमेंट सर्वर के लिए, ऐक्सेस खुला होना चाहिए.

Qpid

5672

इसका इस्तेमाल, राऊटर और मैसेज प्रोसेसर से Qpid सर्वर पर कम्यूनिकेशन के लिए किया जाता है

8083

Qpid सर्वर पर डिफ़ॉल्ट मैनेजमेंट पोर्ट. मैनेजमेंट सर्वर से ऐक्सेस करने के लिए, इसे कॉम्पोनेंट पर खुला होना चाहिए.

1102

जेएमएक्स पोर्ट

4529

डिस्ट्रिब्यूटेड कैश मेमोरी और मैनेजमेंट कॉल के लिए

Postgres

5432

इसका इस्तेमाल, Qpid/मैनेजमेंट सर्वर से Postgres के साथ कम्यूनिकेट करने के लिए किया जाता है

8084

Postgres सर्वर पर डिफ़ॉल्ट मैनेजमेंट पोर्ट. इसे कॉम्पोनेंट पर खुला होना चाहिए, ताकि मैनेजमेंट सर्वर इसे ऐक्सेस कर सके.

1103

जेएमएक्स पोर्ट

4530

डिस्ट्रिब्यूटेड कैश मेमोरी और मैनेजमेंट कॉल के लिए

22

अगर मास्टर-स्टैंडबाय रेप्लिकेशन का इस्तेमाल करने के लिए, दो Postgres नोड कॉन्फ़िगर किए जा रहे हैं, तो आपको एसएसएच ऐक्सेस के लिए हर नोड पर पोर्ट 22 खोलना होगा.

LDAP

10389

OpenLDAP

SmartDocs

59002

Edge राऊटर पर मौजूद वह पोर्ट जहां SmartDocs पेज के अनुरोध भेजे जाते हैं.

ध्यान दें: इसके अलावा, आपको टेस्टिंग के लिए फ़ायरवॉल में पोर्ट खोलने पड़ सकते हैं. उदाहरण के लिए, 59001 वगैरह.

इस टेबल में, सोर्स और डेस्टिनेशन कॉम्पोनेंट के साथ, संख्या के हिसाब से लिस्ट किए गए वही पोर्ट दिखाए गए हैं:

पोर्ट नंबर

मकसद

सोर्स कॉम्पोनेंट

डेस्टिनेशन कॉम्पोनेंट

<virtual host port#>

एचटीटीपी के साथ-साथ, वर्चुअल होस्ट एपीआई कॉल ट्रैफ़िक के लिए इस्तेमाल किए जाने वाले अन्य पोर्ट. आम तौर पर, पोर्ट 80 और 443 का इस्तेमाल किया जाता है. मैसेज राऊटर, टीएलएस/एसएसएल कनेक्शन को बंद कर सकता है.

बाहरी क्लाइंट (या लोड बैलेंसर)

मैसेज राऊटर पर लिसनर

1099 से 1103

जेएमएक्स मैनेजमेंट

जेएमएक्स क्लाइंट

मैनेजमेंट सर्वर (1099)

मैसेज प्रोसेसर (1101)

Qpid Server (1102)

Postgres Server (1103)

2181

Zookeeper क्लाइंट कम्यूनिकेशन

मैनेजमेंट सर्वर

राऊटर

मैसेज प्रोसेसर

Qpid Server

Postgres सर्वर

ज़ूकीपर

2888 और 3888

Zookeeper इंटरनोड मैनेजमेंट

ज़ूकीपर

ज़ूकीपर

4526 से 4530

RPC मैनेजमेंट पोर्ट, डिस्ट्रिब्यूटेड कैश मेमोरी और मैनेजमेंट सर्वर से अन्य कॉम्पोनेंट को किए जाने वाले कॉल के लिए इस्तेमाल किए जाते हैं

मैनेजमेंट सर्वर

मैनेजमेंट सर्वर (4526)

राऊटर (4527)

मैसेज प्रोसेसर (4528)

Qpid Server (4529)

Postgres Server (4530)

4528

मैसेज प्रोसेसर के बीच डिस्ट्रिब्यूटेड कैश मेमोरी कॉल के लिए और राऊटर से कम्यूनिकेशन के लिए

राऊटर

मैसेज प्रोसेसर

मैसेज प्रोसेसर

5432

Postgres क्लाइंट

Qpid Server

Postgres

5672

इसका इस्तेमाल, राऊटर और मैसेज प्रोसेसर से Qpid को आंकड़े भेजने के लिए किया जाता है

राऊटर

मैसेज प्रोसेसर

Qpid Server

7000

Cassandra इंटर-नोड कम्यूनिकेशन

Cassandra

अन्य Cassandra नोड

7199

जेएमएक्स मैनेजमेंट. मैनेजमेंट सर्वर को Cassandra नोड पर ऐक्सेस के लिए खुला होना चाहिए.

जेएमएक्स क्लाइंट

Cassandra

8080

Management API पोर्ट

Management API क्लाइंट

मैनेजमेंट सर्वर

8081 से 8084

कॉम्पोनेंट एपीआई पोर्ट, जिनका इस्तेमाल सीधे तौर पर अलग-अलग कॉम्पोनेंट को एपीआई अनुरोध भेजने के लिए किया जाता है. हर कॉम्पोनेंट एक अलग पोर्ट खोलता है. इस्तेमाल किया जाने वाला पोर्ट, कॉन्फ़िगरेशन पर निर्भर करता है. हालांकि, मैनेजमेंट सर्वर से ऐक्सेस करने के लिए, कॉम्पोनेंट पर पोर्ट खुला होना चाहिए

Management API क्लाइंट

राऊटर (8081)

मैसेज प्रोसेसर (8082)

Qpid Server (8083)

Postgres Server (8084)

8998

राऊटर और मैसेज प्रोसेसर के बीच कम्यूनिकेशन

राऊटर

मैसेज प्रोसेसर

9000

Edge मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) का डिफ़ॉल्ट पोर्ट

ब्राउज़र

मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) सर्वर

9042

सीक्यूएल नेटिव ट्रांसपोर्ट

राऊटर

मैसेज प्रोसेसर

मैनेजमेंट सर्वर

Cassandra

9160

Cassandra thrift client

राऊटर

मैसेज प्रोसेसर

मैनेजमेंट सर्वर

Cassandra

10389

LDAP पोर्ट

मैनेजमेंट सर्वर

OpenLDAP

15999

हेल्थ चेक पोर्ट. लोड बैलेंसर इस पोर्ट का इस्तेमाल करके यह पता लगाता है कि राऊटर उपलब्ध है या नहीं.

लोड बैलेंसर राऊटर

59002

वह राऊटर पोर्ट जहां SmartDocs पेज के अनुरोध भेजे जाते हैं

SmartDocs

राऊटर

मैसेज प्रोसेसर, Cassandra के लिए एक खास कनेक्शन पूल को खुला रखता है. इसे इस तरह से कॉन्फ़िगर किया जाता है कि यह कभी टाइम आउट न हो. जब मैसेज प्रोसेसर और Cassandra सर्वर के बीच फ़ायरवॉल होता है, तो फ़ायरवॉल कनेक्शन का टाइम आउट हो सकता है. हालांकि, मैसेज प्रोसेसर को Cassandra से कनेक्शन फिर से बनाने के लिए डिज़ाइन नहीं किया गया है.

इस समस्या से बचने के लिए, Apigee का सुझाव है कि Cassandra सर्वर, मैसेज प्रोसेसर, और राऊटर एक ही सबनेट में हों. इससे इन कॉम्पोनेंट को डिप्लॉय करने के लिए, फ़ायरवॉल की ज़रूरत नहीं पड़ती.

अगर राऊटर और मैसेज प्रोसेसर के बीच फ़ायरवॉल है और उसमें टीसीपी टाइम आउट सेट है, तो हमारा सुझाव है कि:

  1. Linux OS पर sysctl सेटिंग में, net.ipv4.tcp_keepalive_time = 1800 सेट करें. यहां 1800, फ़ायरवॉल के इस्तेमाल में न होने पर टीसीपी टाइम आउट से कम होना चाहिए. इस सेटिंग से कनेक्शन को चालू रखा जाना चाहिए, ताकि फ़ायरवॉल कनेक्शन को डिसकनेक्ट न करे.
  2. सभी मैसेज प्रोसेसर पर, /<inst_root>/apigee/customer/application/message-processor.properties में बदलाव करें, ताकि यह प्रॉपर्टी जोड़ी जा सके. अगर फ़ाइल मौजूद नहीं है, तो उसे बनाएं.
    conf_system_casssandra.maxconnecttimeinmillis=-1
  3. मैसेज प्रोसेसर को रीस्टार्ट करें:
    > /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  4. सभी राऊटर पर, /<inst_root>/apigee/customer/application/router.properties में बदलाव करें, ताकि यह प्रॉपर्टी जोड़ी जा सके. अगर फ़ाइल मौजूद नहीं है, तो उसे बनाएं.
    conf_system_casssandra.maxconnecttimeinmillis=-1
  5. राऊटर को रीस्टार्ट करें:
    > /opt/apigee/apigee-service/bin/apigee-service edge-router restart

अगर आपने दो डेटा सेंटर के साथ 12 होस्ट क्लस्टर कॉन्फ़िगरेशन इंस्टॉल किया है, तो पक्का करें कि दोनों डेटा सेंटर में मौजूद नोड, नीचे दिए गए पोर्ट पर कम्यूनिकेट कर सकें:

एपीआई BaaS पोर्ट से जुड़ी ज़रूरी शर्तें

अगर आपने एपीआई BaaS इंस्टॉल करने का विकल्प चुना है, तो एपीआई BaaS स्टैक और एपीआई BaaS पोर्टल कॉम्पोनेंट जोड़ें. ये कॉम्पोनेंट, नीचे दी गई इमेज में दिखाए गए पोर्ट का इस्तेमाल करते हैं:

इस डायग्राम के बारे में जानकारी:

  • एपीआई BaaS पोर्टल, BaaS स्टैक नोड को सीधे अनुरोध नहीं भेजता. जब कोई डेवलपर Portal में लॉग इन करता है, तो Portal ऐप्लिकेशन ब्राउज़र में डाउनलोड हो जाता है. इसके बाद, ब्राउज़र में चल रहा पोर्टल ऐप्लिकेशन, BaaS स्टैक नोड को अनुरोध भेजता है.
  • API BaaS के प्रोडक्शन इंस्टॉलेशन में, API BaaS पोर्टल नोड और API BaaS स्टैक नोड के बीच लोड बैलेंसर का इस्तेमाल किया जाता है. पोर्टल को कॉन्फ़िगर करते समय और BaaS एपीआई कॉल करते समय, आपको स्टैक नोड के बजाय, लोड बैलेंसर का आईपी पता या डीएनएस नाम बताना होगा.
  • आपको Baas Stack के सभी नोड कॉन्फ़िगर करने होंगे, ताकि बाहरी एसएमटीपी सर्वर से ईमेल भेजे जा सकें. नॉन-टीएलएस एसएमटीपी के लिए, पोर्ट नंबर आम तौर पर 25 होता है. टीएलएस की सुविधा वाले एसएमटीपी के लिए, यह अक्सर 465 होता है. हालांकि, एसएमटीपी की सेवा देने वाली कंपनी से इसकी पुष्टि कर लें.
  • Cassandra नोड को एपीआई BaaS के लिए इस्तेमाल किया जा सकता है या Edge के साथ शेयर किया जा सकता है.

नीचे दी गई टेबल में, कॉम्पोनेंट के हिसाब से डिफ़ॉल्ट पोर्ट दिखाए गए हैं. इन्हें फ़ायरवॉल में खोलना ज़रूरी है:

कॉम्पोनेंट

पोर्ट

ब्यौरा

एपीआई BaaS पोर्टल

9000

एपीआई BaaS यूज़र इंटरफ़ेस (यूआई) के लिए पोर्ट

एपीआई BaaS स्टैक

8080

वह पोर्ट जहां एपीआई अनुरोध मिलते हैं

ElasticSearch

9200 से 9400

API BaaS स्टैक के साथ कम्यूनिकेट करने और ElasticSearch नोड के बीच कम्यूनिकेट करने के लिए

लाइसेंस देना

Edge के हर इंस्टॉलेशन के लिए, एक यूनीक लाइसेंस फ़ाइल की ज़रूरत होती है. यह फ़ाइल आपको Apigee से मिलती है. मैनेजमेंट सर्वर इंस्टॉल करते समय, आपको लाइसेंस फ़ाइल का पाथ देना होगा. उदाहरण के लिए, /tmp/license.txt.

इंस्टॉलर, लाइसेंस फ़ाइल को /<inst_root>/apigee/customer/conf/license.txt में कॉपी करता है.

अगर लाइसेंस फ़ाइल मान्य है, तो मैनेजमेंट सर्वर, लाइसेंस की समयसीमा खत्म होने की तारीख और अनुमति वाले मैसेज प्रोसेसर (एमपी) की संख्या की पुष्टि करता है. अगर लाइसेंस की कोई सेटिंग खत्म हो गई है, तो आपको लॉग इस जगह पर मिलेंगे: /<inst_root>/apigee/var/log/edge-management-server/logs. इस मामले में, माइग्रेशन की जानकारी के लिए Apigee की सहायता टीम से संपर्क किया जा सकता है.