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

Edge for Private Cloud v4.18.01

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

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

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

इंस्टॉलेशन कॉम्पोनेंट RAM CPU कम से कम हार्ड डिस्क
कसांद्रा 16 जीबी 8-कोर 2000 IOPS के साथ काम करने वाले एसएसडी या तेज़ एचडीडी के साथ 250 जीबी का लोकल स्टोरेज
एक ही मशीन पर मैसेज प्रोसेसर/राउटर 16 जीबी 8-कोर 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 आईओपीएस की सुविधा होनी चाहिए.

Qpid सूची का डिफ़ॉल्ट साइज़ 20 जीबी है. अगर आपको ज़्यादा क्षमता जोड़नी है, तो अतिरिक्त Qpid नोड जोड़ें.

अन्य (OpenLDAP, यूज़र इंटरफ़ेस (यूआई), मैनेजमेंट सर्वर) 4 जीबी 2-कोर 60 जीबी

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

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

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

bytes of storage needed =

  (# bytes of analytics data/request) *

  (requests/second) *

  (seconds/hour) *

  (hours of peak usage/day) *

  (days/month) *

  (months of data retention)

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

(2K bytes) * (100 req/sec) * (3600 secs/hr) * (18 peak hours/day) * (30 days/month) * (3 months retention)

= 1,194,393,600,000 bytes or 1194.4 GB

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

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

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

कमाई करने की सुविधा वाला कॉम्पोनेंट RAM CPU हार्ड डिस्क
मैनेजमेंट सर्वर (कमाई करने वाली सेवाओं के साथ) 8 जीबी 4-कोर 60 जीबी
Analytics - एक ही सर्वर पर Postgres/Qpid 16 जीबी 8-कोर 500 जीबी - 1 टीबी नेटवर्क स्टोरेज. आम तौर पर, यह एसएसडी बैकएंड के साथ होता है और 1, 000 आईओपीएस या इससे ज़्यादा के वर्शन के साथ काम करता है. इसके अलावा, ऊपर दी गई टेबल में दिए गए नियम का भी इस्तेमाल किया जा सकता है.
Analytics - Postgres स्टैंडअलोन 16 जीबी 8-कोर 500 जीबी - 1 टीबी नेटवर्क स्टोरेज. आम तौर पर, यह एसएसडी बैकएंड के साथ होता है और 1, 000 आईओपीएस या इससे ज़्यादा के वर्शन के साथ काम करता है. इसके अलावा, ऊपर दी गई टेबल में दिए गए नियम का भी इस्तेमाल किया जा सकता है.
Analytics - Qpid स्टैंडअलोन 8 जीबी 4-कोर 40GB - एसएसडी या तेज़ एचडीडी के साथ 500 जीबी का लोकल स्टोरेज

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

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

एपीआई BaaS कॉम्पोनेंट रैम CPU हार्ड डिस्क
इलास्टिकसर्च* 8 जीबी 4-कोर 60-80 जीबी
API BaaS स्टैक* 8 जीबी 4-कोर 60-80 जीबी
API BaaS पोर्टल 1GB 2-कोर 20 जीबी
कैसेंड्रा** 16 जीबी 8-कोर 2000 IOPS के साथ काम करने वाले एसएसडी या तेज़ एचडीडी के साथ 250 जीबी का लोकल स्टोरेज

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

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

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

इंस्टॉल करने के इन निर्देशों और इंस्टॉल करने के लिए दी गई फ़ाइलों की जांच, ऑपरेटिंग सिस्टम और तीसरे पक्ष के सॉफ़्टवेयर पर की गई है. इन सॉफ़्टवेयर की सूची काम करने वाले सॉफ़्टवेयर और इसके साथ काम करने वाले वर्शन में दी गई है.

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

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

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

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

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

/opt/apigee से सिमलिंक बनाना

सिमलिंक बनाने से पहले, आपको "apigee" नाम का एक उपयोगकर्ता और ग्रुप बनाना होगा. यह वही ग्रुप और उपयोगकर्ता है जिसे Edge इंस्टॉलर के ज़रिए बनाया गया है.

सिमलिंक बनाने के लिए, बूटstrap_4.18.01.sh फ़ाइल को डाउनलोड करने से पहले इन चरणों को पूरा करें. आपको ये सभी चरण रूट के तौर पर पूरे करने होंगे:

  1. "apigee" उपयोगकर्ता और ग्रुप बनाएं:
    groupadd -r apigee > useradd -r -g apigee -d /opt/apigee -s /sbin/nologin -c "Apigee platform user" apigee
  2. /opt/apigee से अपने पसंदीदा इंस्टॉल रूट के लिए सिमलिंक बनाएं:
    ln -Ts /srv/myInstallDir /opt/apigee

    जहां /srv/myInstallDir, Edge फ़ाइलों की मनचाही जगह है.

  3. इंस्टॉल रूट और सिमलिंक का मालिकाना हक "apigee" उपयोगकर्ता को दे दें:
    chown -h apigee:apigee /srv/myInstallDir /opt/apigee

Java

इंस्टॉलेशन से पहले हर मशीन पर, Java 1.8 का इस्तेमाल किया जा सकने वाला वर्शन होना ज़रूरी है. जिन JDKs का इस्तेमाल किया जा सकता है उनकी सूची साथ काम करने वाले सॉफ़्टवेयर और ऐसे वर्शन में दी गई है जिन पर यह सुविधा काम करती है.

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

SELinux

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

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

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

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

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

अगर किसी सर्वर में एक से ज़्यादा इंटरफ़ेस कार्ड हैं, तो "hostname -i" कमांड, आईपी पतों के स्पेस से अलग की गई सूची दिखाता है. डिफ़ॉल्ट रूप से, Edge इंस्टॉलर, लौटाए गए पहले आईपी पते का इस्तेमाल करता है, जो सभी स्थितियों में सही नहीं भी हो सकता है. विकल्प के तौर पर, आपके पास इस प्रॉपर्टी को इंस्टॉलेशन कॉन्फ़िगरेशन फ़ाइल में सेट करने का विकल्प होता है:

ENABLE_DYNAMIC_HOSTIP=y

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

टीसीपी रैपर

टीसीपी रैपर कुछ पोर्ट के कम्यूनिकेशन को ब्लॉक कर सकते हैं. साथ ही, OpenLDAP, Postgres, और कैसेंड्रा को इंस्टॉल करने पर असर डाल सकते हैं. उन नोड पर, /etc/hosts.allow और /etc/hosts.deny की जांच करके पक्का करें कि ज़रूरी OpenLDAP, Postgres, और कैसेंड्रा पोर्ट पर कोई पोर्ट प्रतिबंध नहीं है.

Iptable

पुष्टि करें कि ऐसी कोई iptables नीति नहीं है जो ज़रूरी Edge पोर्ट पर नोड के बीच कनेक्टिविटी को रोकती है. अगर ज़रूरी हो, तो इंस्टॉल करने के दौरान iptables को रोका जा सकता है. इसके लिए निर्देश दें:

sudo/etc/init.d/iptables stop

CentOS 7.x पर उपलब्ध:

systemctl stop firewalld

पक्का करें कि एज राऊटर /etc/rc.d/init.d/Functions को ऐक्सेस कर सकता हो

Edge राऊटर और BaaS पोर्टल नोड, Ngnx राऊटर का इस्तेमाल करते हैं और उन्हें /etc/rc.d/init.d/functions के लिए पढ़ने का ऐक्सेस चाहिए.

अगर सुरक्षा से जुड़ी प्रोसेस के लिए आपको /etc/rc.d/init.d/functions पर अनुमतियां सेट करनी हैं, तो उन्हें 700 पर सेट न करें. ऐसा न करने पर, राऊटर काम नहीं करेगा. /etc/rc.d/init.d/functions को पढ़ने का ऐक्सेस देने के लिए, अनुमतियां 744 पर सेट की जा सकती हैं.

कसांद्रा

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

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

'Edge for Private Cloud' इंस्टॉल करने के बाद, /opt/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 /opt/apigee/customer/application/postgresql.properties

    अगर फ़ाइल मौजूद नहीं है, तो उसे बनाएं.

  2. ऊपर सूची में दी गई प्रॉपर्टी सेट करें.
  3. बदलावों को सेव करें.
  4. PostgreSQL डेटाबेस को रीस्टार्ट करें:
    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

सिस्टम की सीमाएं

पक्का करें कि आपने Cassandra और मैसेज प्रोसेसर नोड पर ये सिस्टम सीमाएं सेट की हैं:

  • कैसेंड्रा नोड पर, /etc/security/limits.d/90-apigee-edge-limits.conf में इंस्टॉलेशन उपयोगकर्ता (डिफ़ॉल्ट रूप से “apigee”) है, के लिए सॉफ़्ट और हार्ड मेमलॉक, नोफ़ाइल, और अड्रेस स्पेस (as) की सीमाएं सेट करें, जैसा कि यहां दिखाया गया है:
    apigee soft memlock unlimited
    apigee hard memlock unlimited
    apigee soft nofile 32768
    apigee hard nofile 65536
    apigee soft as unlimited
    apigee hard as unlimited
  • मैसेज प्रोसेसर नोड पर, /etc/security/limits.d/90-apigee-edge-limits.conf में खुले फ़ाइल डिस्क्रिप्टर की ज़्यादा से ज़्यादा संख्या 64K पर सेट करें, जैसा कि नीचे दिखाया गया है:
    apigee soft nofile 32768
    apigee hard nofile 65536

    ज़रूरत पड़ने पर, यह सीमा बढ़ाई जा सकती है. उदाहरण के लिए, अगर आपके पास कुछ समय के लिए सेव की गई फ़ाइलों को एक बार में बड़ी संख्या में खोला जा सकता है.

जेएसवीसी

API BaaS का इस्तेमाल करने के लिए "jsvc" एक ज़रूरी शर्त है. API BaaS इंस्टॉल करने पर, 1.0.15-dev वर्शन इंस्टॉल हो जाता है.

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

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

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

yum info nss

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

yum update nss

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

NSCD (नेम सर्विस कैश डीमन) का इस्तेमाल करते समय, IPv6 पर डीएनएस लुकअप को बंद करें

अगर आपने NSCD (नेम सर्विस कैश डीमन) को इंस्टॉल और चालू किया है, तो मैसेज प्रोसेसर दो डीएनएस लुकअप बनाते हैं: एक IPv4 के लिए और दूसरा IPv6 के लिए. NSCD का इस्तेमाल करते समय, आपको IPv6 पर डीएनएस लुकअप को बंद कर देना चाहिए.

IPv6 पर डीएनएस लुकअप को बंद करने के लिए:

  1. हर मैसेज प्रोसेसर नोड पर, /etc/nscd.conf में बदलाव करें
  2. यह प्रॉपर्टी सेट करें:
    enable-cache hosts no

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

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

IPv6 को बंद करने के निर्देशों के लिए, अपने खास ओएस वर्शन के लिए RedHat या CentOS का दस्तावेज़ देखें. उदाहरण के लिए, आपके पास ये काम करने की सुविधा होती है:

  1. /etc/hosts को किसी एडिटर में खोलें.
  2. टिप्पणी करने के लिए, नीचे दी गई लाइन में से एक के कॉलम में "#" वर्ण डालें:
    #::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
  3. फ़ाइल सेव करें.

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

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

expr

Libxslt

आरपीएम

unzip

basename

grep

लुआ-सॉकेट

rpm2cpio

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

बैश

hostname

ls

sed

wc

bc

id

net-tools

sudo

Wget

curl

लिबायो

पर्ल (procps से)

टार

ज़ेर्स-सी

सायरस-ससल libdb4 pgrep (procps से) tr लज़ीज़

date

libdb-cxx

ps

uuid

chkconfig

dirname लिरिब्वर्ब pwd Uname  
echo लिबरमैक python    

एनटीपीडी

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

Openldap 2.4

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

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

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

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

  • वर्चुअल मशीन (वीएम): इसकी ज़रूरत नहीं है. हालांकि, कुछ डिप्लॉयमेंट, 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 ट्रैफ़िक को कनेक्ट करने की अनुमति भी होनी चाहिए.

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 के दो एपीआई डिप्लॉय करने का विकल्प है. इसके लिए, वर्चुअल होस्ट का इस्तेमाल करें जिसका होस्ट उपनाम 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 दिखाता है.

59001 apigee-validate यूटिलिटी की मदद से Edge इंस्टॉलेशन की जांच करने के लिए इस्तेमाल किया गया पोर्ट. इस सुविधा को राऊटर पर पोर्ट 59001 का ऐक्सेस चाहिए. पोर्ट 59001 पर ज़्यादा जानकारी के लिए, इंस्टॉल की जांच करें देखें.
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 को खोलना होगा.
LDAP 10389 OpenLDAP
SmartDocs 59002 Edge राऊटर पर वह पोर्ट जहां SmartDocs की मदद से पेज ऐक्सेस करने के अनुरोध भेजे जाते हैं.

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

पोर्ट नंबर मकसद सोर्स कॉम्पोनेंट डेस्टिनेशन कॉम्पोनेंट
virtual_host_port एचटीटीपी और ऐसे अन्य पोर्ट जिनका इस्तेमाल वर्चुअल होस्ट एपीआई कॉल ट्रैफ़िक के लिए किया जाता है. आम तौर पर, पोर्ट 80 और 443 का इस्तेमाल किया जाता है. मैसेज राऊटर, TLS/एसएसएल कनेक्शन को खत्म कर सकता है. बाहरी क्लाइंट (या लोड बैलेंसर) मैसेज राऊटर पर लिसनर
1099 से 1103 तक जेएमएक्स मैनेजमेंट JMX क्लाइंट मैनेजमेंट सर्वर (1099)
मैसेज प्रोसेसर (1101)
Qpid सर्वर (1102)
Postgres Server (1103)
2181 ज़ूकीपर क्लाइंट से बातचीत मैनेजमेंट सर्वर
राऊटर
मैसेज प्रोसेसर
Qpid सर्वर
Postgres सर्वर
चिड़ियाघर का रखरखाव करने वाला जानवर
2888 और 3888 ज़ूकीपर इंटरनोड मैनेजमेंट चिड़ियाघर का रखरखाव करने वाला जानवर चिड़ियाघर का रखरखाव करने वाला जानवर
4526 RPC मैनेजमेंट पोर्ट मैनेजमेंट सर्वर मैनेजमेंट सर्वर
4527 डिस्ट्रिब्यूटेड कैश और मैनेजमेंट कॉल और राऊटर के बीच बातचीत के लिए RPC मैनेजमेंट पोर्ट मैनेजमेंट सर्वर
रूटीन
राऊटर
4528 Message प्रोसेसर के बीच डिस्ट्रिब्यूटेड कैश कॉल और राऊटर से संपर्क करने के लिए मैनेजमेंट सर्वर
राऊटर
मैसेज प्रोसेसर
मैसेज प्रोसेसर
4529 डिस्ट्रिब्यूटेड कैश और मैनेजमेंट कॉल के लिए RPC मैनेजमेंट पोर्ट मैनेजमेंट सर्वर Qpid सर्वर
4530 डिस्ट्रिब्यूटेड कैश और मैनेजमेंट कॉल के लिए RPC मैनेजमेंट पोर्ट मैनेजमेंट सर्वर Postgres सर्वर
5432 Postgres क्लाइंट Qpid सर्वर पोस्टग्रेस
5672

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

राऊटर
मैसेज प्रोसेसर
Qpid सर्वर
7000 कैसेंड्रा इंटर-नोड कम्यूनिकेशन कसांद्रा अन्य कैसंड्रा नोड
7199 JMX मैनेजमेंट. यह ज़रूरी है कि मैनेजमेंट सर्वर से Cassandra नोड पर ऐक्सेस किया जा सके. JMX क्लाइंट कसांद्रा
8080 मैनेजमेंट एपीआई पोर्ट मैनेजमेंट एपीआई क्लाइंट मैनेजमेंट सर्वर
8081 से 8084

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

मैनेजमेंट एपीआई क्लाइंट राऊटर (8081)
मैसेज प्रोसेसर (8082)
Qpid सर्वर (8083)
Postgres Server (8084)
8998 राऊटर और मैसेज प्रोसेसर के बीच कम्यूनिकेशन राऊटर मैसेज प्रोसेसर
9000 डिफ़ॉल्ट Edge मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) पोर्ट ब्राउज़र मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) सर्वर
9042 सीक्यूएल नेटिव ट्रांसपोर्ट राऊटर
मैसेज प्रोसेसर
मैनेजमेंट सर्वर
कसांद्रा
9160 Cassandra थ्रिफ़्ट क्लाइंट राऊटर
मैसेज प्रोसेसर
मैनेजमेंट सर्वर
कसांद्रा
10389 LDAP पोर्ट मैनेजमेंट सर्वर OpenLDAP
15999 स्वास्थ्य जांच पोर्ट. लोड बैलेंसर, इस पोर्ट का इस्तेमाल यह पता करने के लिए करता है कि राऊटर उपलब्ध है या नहीं. लोड बैलेंसर राऊटर
59001 Edge इंस्टॉलेशन की जांच करने के लिए, apigee-validate यूटिलिटी के ज़रिए इस्तेमाल किया गया पोर्ट apigee-validate राऊटर
59002 वह राऊटर पोर्ट जहां SmartDocs की मदद से पेज ऐक्सेस करने के अनुरोध भेजे जाते हैं SmartDocs राऊटर

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

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

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

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

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

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

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

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

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

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

कॉम्पोनेंट पोर्ट ब्यौरा
एपीआई BaaS पोर्टल 9000 API BaaS यूज़र इंटरफ़ेस (यूआई) के लिए पोर्ट
API BaaS स्टैक 8080 वह पोर्ट जहां एपीआई अनुरोध मिलता है
2551

सभी स्टैक नोड के बीच कम्यूनिकेशन के लिए पोर्ट. डेटा कैंटर में मौजूद दूसरे सभी स्टैक नोड से ऐक्सेस किया जा सकता है.

अगर आपके पास एक से ज़्यादा डेटा सेंटर हैं, तो यह ज़रूरी है कि पोर्ट को सभी डेटा सेंटर में सभी स्टैक नोड से ऐक्सेस किया जा सके.

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

लाइसेंस

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

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

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

अगर आपके पास अब तक लाइसेंस नहीं है, तो Apigee Sales से संपर्क करें.