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

Edge for Private Cloud v. 4.16.05

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

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

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

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

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

ध्यान दें:

• अगर रूट फ़ाइल सिस्टम में इंस्टॉलेशन के लिए ज़रूरत के मुताबिक जगह नहीं है, तो हमारा सुझाव है कि डेटा को किसी बड़ी डिस्क पर सेव करें.
• अगर मशीन पर 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, उपलब्ध मेमोरी के आधार पर अपने 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 का यह लेख पढ़ें.

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 टूल का इस्तेमाल करता है.

ध्यान दें:

• ‘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 कॉम्पोनेंट के हिसाब से फ़ायरवॉल में खोले जाने वाले पोर्ट की जानकारी दी गई है:

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

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

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

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

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

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

लाइसेंस देना

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

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

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