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

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

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

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

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

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

इंस्टॉलेशन कॉम्पोनेंट RAM CPU हार्ड डिस्क का कम से कम स्टोरेज
कassandra 16 जीबी 8 कोर 250 जीबी का लोकल स्टोरेज, जिसमें 2,000 आईओपीएस (इनपुट/आउटपुट ऑपरेशन प्रति सेकंड) की सुविधा वाली एसएसडी हो
एक ही मशीन पर मैसेज प्रोसेसर/राउटर 16 जीबी 8 कोर 100 जीबी
मैसेज प्रोसेसर (स्टैंडअलोन) 16 जीबी 8 कोर 100 जीबी
राऊटर (स्टैंडअलोन) 16 जीबी 8 कोर 100 जीबी
Analytics - एक ही सर्वर पर Postgres/Qpid 16 जीबी* 8‑कोर* 500 जीबी से 1 टीबी** नेटवर्क स्टोरेज***, बेहतर होगा कि एसएसडी बैकएंड के साथ हो, और 1,000 आईओपीएस या उससे ज़्यादा की स्पीड के साथ काम करता हो*
Analytics - Postgres का मास्टर या स्टैंडबाय (स्टैंडअलोन) 16 जीबी* आठ कोर* 500 जीबी से 1 टीबी** नेटवर्क स्टोरेज***, बेहतर होगा कि एसएसडी बैकएंड के साथ हो, और 1,000 आईओपीएस या उससे ज़्यादा की स्पीड के साथ काम करता हो*
Analytics - Qpid स्टैंडअलोन 8 जीबी चार कोर एसएसडी के साथ 30 जीबी से 50 जीबी का स्टोरेज

Qpid क्यू का डिफ़ॉल्ट साइज़ 1 जीबी होता है. इसे 2 जीबी तक बढ़ाया जा सकता है. अगर आपको ज़्यादा स्टोरेज की ज़रूरत है, तो और Qpid नोड जोड़ें.
OpenLDAP/यूज़र इंटरफ़ेस/मैनेजमेंट सर्वर 8 जीबी चार कोर 60 जीबी
यूज़र इंटरफ़ेस (यूआई)/मैनेजमेंट सर्वर 4 जीबी दो कोर 60 जीबी
OpenLDAP (स्टैंडअलोन) 4 जीबी दो कोर 60 जीबी

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

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 of storage needed

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

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

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

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

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

Cassandra के नेटवर्क बैंडविड्थ की ज़रूरी शर्तें

Cassandra, नेटवर्क टोपोलॉजी के बारे में अन्य नोड के साथ जानकारी शेयर करने के लिए, Gossip प्रोटोकॉल का इस्तेमाल करता है. गॉसिप प्रोटोकॉल का इस्तेमाल करने पर, Cassandra के डिस्ट्रिब्यूटेड नेटवर्क की वजह से, नेटवर्क पर ज़्यादा डेटा ट्रांसफ़र होता है. Cassandra में, डेटा को पढ़ने और उसमें बदलाव करने के लिए, कई नोड के साथ कम्यूनिकेट किया जाता है.

Cassandra के लिए, हर नोड के लिए कम से कम 1 जीबीपीएस नेटवर्क बैंडविड्थ की ज़रूरत होती है. प्रोडक्शन इंस्टॉलेशन के लिए, ज़्यादा बैंडविड्थ का सुझाव दिया जाता है.

Cassandra के लिए, ज़्यादा से ज़्यादा या 99वें पर्सेंटाइल वाला इंतज़ार का समय 100 मिलीसेकंड से कम होना चाहिए.

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

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

ज़रूरी शर्त: EPEL रिपॉज़िटरी चालू करना

इंस्टॉलेशन शुरू करने से पहले, पक्का करें कि EPEL (Extra Packages for Enterprise Linux) रिपॉज़िटरी चालू हो. अपने ऑपरेटिंग सिस्टम के वर्शन के आधार पर, इन निर्देशों का इस्तेमाल करें:

  • Red Hat/CentOS/Oracle 8.X के लिए: 
    wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
    sudo rpm -ivh epel-release-latest-8.noarch.rpm
  • Red Hat/CentOS/Oracle 9.X के लिए: 
    wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
    sudo rpm -ivh epel-release-latest-9.noarch.rpm

Java

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

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

SELinux

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

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

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

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

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

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

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

सिंबल लिंक बनाने के लिए, bootstrap_4.53.00.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

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

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

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

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

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

ENABLE_DYNAMIC_HOSTIP=y

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

टीसीपी रैपर

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

iptables

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

sudo/etc/init.d/iptables stop

निर्देशिका का ऐक्सेस

यहां दी गई टेबल में, Edge नोड पर मौजूद उन डायरेक्ट्री की सूची दी गई है जिनके लिए, Edge प्रोसेस की खास ज़रूरतें होती हैं:

सेवा डायरेक्ट्री ब्यौरा
राऊटर /etc/rc.d/init.d/functions

Edge Router, Nginx राउटर का इस्तेमाल करता है. साथ ही, उसे /etc/rc.d/init.d/functions को पढ़ने का ऐक्सेस चाहिए.

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

/etc/rc.d/init.d/functions को पढ़ने का ऐक्सेस देने के लिए, अनुमतियां 744 पर सेट की जा सकती हैं.
चिड़ियाघर का रखरखाव करने वाला व्यक्ति /dev/random Zookeeper क्लाइंट लाइब्रेरी को रैंडम नंबर जनरेटर /dev/random का रीड ऐक्सेस चाहिए. अगर /dev/random को पढ़ने पर ब्लॉक किया जाता है, तो हो सकता है कि Zookeeper सेवा शुरू न हो पाए.

कassandra

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

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

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

Rocky 9.X के लिए स्थानीय भाषा का कॉन्फ़िगरेशन

अगर Rocky 9.X का इस्तेमाल किया जा रहा है, तो पक्का करें कि आपका सिस्टम, सिस्टम-वाइड लोकल सेटिंग में LANG=en_US.utf8 के साथ कॉन्फ़िगर किया गया हो. इसे कॉन्फ़िगर करने के लिए, ये कमांड चलाएं:

dnf -y -q install langpacks-en
localectl set-locale LANG=en_US.utf8
reboot

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

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

  • 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
apigee soft nproc 32768
apigee hard nproc 65536
  • मैसेज प्रोसेसर नोड पर, /etc/security/limits.d/90-apigee-edge-limits.conf में ज़्यादा से ज़्यादा 64K फ़ाइल डिस्क्रिप्टर सेट करें, जैसा कि यहां दिखाया गया है: 
    apigee soft nofile 32768
apigee hard nofile 65536

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

  • अगर आपको कभी रूटर या मैसेज प्रोसेसर में यह गड़बड़ी दिखती है system.log, तो हो सकता है कि आपने फ़ाइल डिस्क्रिप्टर की सीमाएं बहुत कम सेट की हों:

    "java.io.IOException: Too many open files"

    उपयोगकर्ताओं की संख्या की सीमाएं देखने के लिए, यह तरीका अपनाएं:

    # su - apigee
$ ulimit -n
100000

    अगर फ़ाइल डिस्क्रिप्टर की सीमाएं 100000 पर सेट करने के बाद भी, खोली जा सकने वाली फ़ाइलों की सीमा पूरी हो रही है, तो समस्या हल करने के लिए Apigee Edge की सहायता टीम से संपर्क करें.

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

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

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

yum info nss

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

yum update nss

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

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

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

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

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

RHEL 8 और उसके बाद के वर्शन पर IPv6 को बंद करना

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

आईपीवी6 को बंद करने के निर्देशों के लिए, कृपया अपने ओएस वेंडर से मिले दस्तावेज़ देखें. उदाहरण के लिए, Red Hat Enterprise Linux के दस्तावेज़ में आपको काम की जानकारी मिल सकती है.

टूल

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

awk

expr

libxslt

आरपीएम

अनज़िप करना

basename

grep

lua-socket

rpm2cpio

useradd

bash

 hostname

ls

sed

wc

bc

आईडी

net-tools

sudo

wget

curl

libaio

perl (procps से)

tar

xerces-c
cyrus-sasl libdb4 pgrep (procps से) tr लज़ीज़

तारीख

 libdb-cxx

ps

यूयूआईडी

chkconfig
dirname libibverbs pwd uname  
ईको librdmacm python    

समय सिंक करना

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

openldap 2.4

ऑन-प्राइमिस इंस्टॉलेशन के लिए, OpenLDAP 2.4 की ज़रूरत होती है. यह apigee-thirdparty-opdk रिपॉज़िटरी में शामिल है. आसानी से इंस्टॉल करने के लिए, कृपया openldap-compat लाइब्रेरी हटाएं.

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

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

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

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

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

नाम रखने के उदाहरण के तौर पर, हो सकता है कि एक फ़िज़िकल सर्वर A पर दो VM, "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) पर एक्सपोज़ किए जा रहे पोर्ट के लिए, टीसीपी ट्रैफ़िक को पास करने की अनुमति देनी होगी. इसके अलावा, हर VM का ऑपरेटिंग सिस्टम अपने 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 पर सेट है. अगर डिप्लॉयमेंट में कोई आधार पाथ नहीं दिया जाता है, तो राऊटर को यह पता नहीं चलता कि आने वाले अनुरोधों को किस एपीआई पर भेजना है.

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

लाइसेंस देना

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

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

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

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