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

Edge for Private Cloud वर्शन 4.16.09

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

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

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

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

रैम

सीपीयू

कम से कम हार्ड डिस्क

कसांद्रा

16 जीबी

8-कोर

2000 IOPS के साथ काम करने वाले एसएसडी या तेज़ एचडीडी के साथ 250 जीबी का लोकल स्टोरेज

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

8/16 जीबी

4‐कोर

100 जीबी

Analytics - एक ही सर्वर पर Postgres/Qpid (प्रोडक्शन के लिए सुझाए गए नहीं)

16 जीबी*

8-कोर*

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

Analytics - Postgres स्टैंडअलोन

16 जीबी*

8-कोर*

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

Analytics - Qpid स्टैंडअलोन

8 जीबी

4-कोर

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

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

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

4 जीबी

2-कोर

60 जीबी

† मैसेज प्रोसेसर के लिए सिस्टम की ज़रूरी शर्तों में बदलाव करें:

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

*थ्रूपुट के आधार पर Postgres सिस्टम की ज़रूरतों को अडजस्ट करें:

  • 250 से कम TPS: 8 जीबी, मैनेज किए जा रहे नेटवर्क स्टोरेज के साथ 4-कोर वाला वर्शन
  • 250 से ज़्यादा TPS: 16 जीबी, 8 कोर, मैनेज किया जा रहा नेटवर्क स्टोरेज*** 1,000 IOPS के साथ या इससे ज़्यादा का स्टोरेज
  • 1,000 से ज़्यादा TPS: 16 जीबी, 8 कोर, मैनेज किया जा रहा नेटवर्क स्टोरेज*** साथ में 2000 IOPS या इससे ज़्यादा का TPS काम करता है
  • 2,000 से ज़्यादा TPS: 32 जीबी, 16-कोर, मैनेज किया जा रहा नेटवर्क स्टोरेज*** 2000 IOPS या इससे ज़्यादा के लिए
  • 4,000 से ज़्यादा TPS: 64 जीबी, 32-कोर, मैनेज किया जा रहा नेटवर्क स्टोरेज*** साथ में 4000 IOPS या इससे ज़्यादा होने पर

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

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

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

(हर महीने 6 हज़ार बाइट/0.0 सेकंड तक डेटा का सबसे ज़्यादा रखरखाव *3 घंटे/0 सेकंड 3 घंटे *30 बाइट/0 सेकंड * 100 ज़रूरत हर महीने

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

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

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

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

रैम

सीपीयू

हार्ड डिस्क

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

8 जीबी

4-कोर

60 जीबी

Analytics - एक ही सर्वर पर Postgres/Qpid

16 जीबी

8-कोर

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

Analytics - Postgres स्टैंडअलोन

16 जीबी

8-कोर

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

Analytics - Qpid स्टैंडअलोन

8 जीबी

4-कोर

40 जीबी

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

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

रैम

सीपीयू

हार्ड डिस्क

ElasticSearch*

8 जीबी

4-कोर

60 - 80 जीबी

API BaaS स्टैक *

8 जीबी

4-कोर

60 - 80 जीबी

API BaaS पोर्टल

1GB

2-कोर

20 जीबी

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

16 जीबी

8-कोर

2000 IOPS के साथ काम करने वाले एसएसडी या तेज़ एचडीडी के साथ 250 जीबी का लोकल स्टोरेज

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

ध्यान दें:

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

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

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

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

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

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

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

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

Java

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

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

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

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

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

  • hostname मशीन का नाम दिखाता है
  • hostname -i, उस होस्टनेम के लिए आईपी पता दिखाता है जिसे दूसरी मशीनों से पता किया जा सकता है.

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

कसांद्रा

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

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

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

  • cluster_name
  • initial_token
  • पार्टिशनर
  • सीड
  • listen_address
  • rpc_address
  • स्नीच

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

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 सामानों को रीस्टार्ट करें

जेएसवीसी

API BaaS का इस्तेमाल करने के लिए "jsvc" एक ज़रूरी शर्त है. API 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 पर Edge या CentOS 7 इंस्टॉल किया जा रहा है, तो आपको सभी Qpid नोड पर IPv6 को बंद करना होगा.

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

एडब्ल्यूएस एएमआई

अगर आप 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

आरपीएम

unzip

basename

echo

perl

rpm2cpio

उपयोगकर्ता जोड़ें

बैश

expr

pgrep (procps से)

sed

wc

bc

grep

ps

टार

लज़ीज़

curl

hostname

pwd

tr

chkconfig

date

id

python

Uname

sudo

ध्यान दें:

  • ‘useradd’ टूल /usr/sbin और /sbin में chkconfig के लिए एक्ज़ीक्यूटेबल है.
  • 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 installopenldap-clients Openldap-servers" चलाया जा सकता है.

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

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

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

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

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

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

ऐसा हो सकता है कि दोनों वीएम में से हर एक में 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 ट्रैफ़िक को कनेक्ट करने की अनुमति मिलना भी ज़रूरी है.

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

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

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

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

एज पोर्ट की आवश्यकताएं

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

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

इस डायग्राम पर दी गई जानकारी:

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

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

कॉम्पोनेंट

पोर्ट

जानकारी

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

80, 443

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

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

8080

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

1099

JMX पोर्ट

4526

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

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

9000

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

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

8998

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

8082

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

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

1101

JMX पोर्ट

4528

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

राउटर

8081

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

4527

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

15999

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

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

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

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

ZooKeeper

2181

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

2,888, 3888

ज़ूकीपर क्लस्टर (जिसे ज़ूकेपर ग्रुप के नाम से जाना जाता है) के लिए, ज़ूकीपर अंदरूनी तौर पर इसे इस्तेमाल करता है कम्यूनिकेशन

कैसांड्रा

7,000, 9042, 9,160

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

7199

JMX पोर्ट. यह ज़रूरी है कि मैनेजमेंट सर्वर ऐक्सेस कर सके.

क्यूपीआईडी

5672

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

8083

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

1102

JMX पोर्ट

4529

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

पोस्टग्रेस

5432

Qpid/Management Server से Postgres तक कम्यूनिकेशन के लिए इस्तेमाल किया जाता है

8084

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

1103

JMX पोर्ट

4530

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

22

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

एलडीएपी

10389

OpenLDAP

SmartDocs

59002

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

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

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

पोर्ट नंबर

मकसद

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

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

<वर्चुअल होस्ट पोर्ट#>

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

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

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

1099 से 1103 तक

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

JMX क्लाइंट

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

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

Qpid सर्वर (1102)

Postgres सर्वर (1103)

2,181

ज़ूकीपर क्लाइंट से बातचीत

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

राऊटर

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

Qpid सर्वर

Postgres सर्वर

चिड़ियाघर का रखरखाव करने वाला जानवर

2,888 और 3888

ज़ूकीपर इंटरनोड मैनेजमेंट

चिड़ियाघर का रखरखाव करने वाला जानवर

चिड़ियाघर का रखरखाव करने वाला जानवर

4,526 से 4,530

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

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

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

राऊटर (4527)

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

Qpid सर्वर (4529)

Postgres सर्वर (4530)

4,528

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

राऊटर

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

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

5,432

Postgres क्लाइंट

Qpid सर्वर

पोस्टग्रेस

5672

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

राऊटर

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

Qpid सर्वर

7000

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

कसांद्रा

अन्य कैसंड्रा नोड

7,199

JMX मैनेजमेंट. यह ज़रूरी है कि मैनेजमेंट सर्वर से Cassandra नोड पर ऐक्सेस किया जा सके.

JMX क्लाइंट

कसांद्रा

8080

मैनेजमेंट एपीआई पोर्ट

मैनेजमेंट एपीआई क्लाइंट

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

8081 से 8084

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

मैनेजमेंट एपीआई क्लाइंट

राऊटर (8081)

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

Qpid सर्वर (8083)

Postgres सर्वर (8084)

8,998

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

राऊटर

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

9,000

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

ब्राउज़र

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

9042

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

राऊटर

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

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

कसांद्रा

9,160

Cassandra थ्रिफ़्ट क्लाइंट

राऊटर

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

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

कसांद्रा

10,389

LDAP पोर्ट

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

OpenLDAP

15,999

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

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

59,002

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

SmartDocs

राऊटर

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

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

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

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

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

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

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

इस डायग्राम पर दी गई जानकारी:

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

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

कॉम्पोनेंट

पोर्ट

जानकारी

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

9000

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

एपीआई BaaS स्टैक

8080

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

ElasticSearch

9,200 से 9,400

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

लाइसेंस

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

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

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