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

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

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

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

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

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

इंस्टॉलेशन कॉम्पोनेंट RAM सीपीयू हार्ड डिस्क में कम से कम स्टोरेज
Cassandra 16 जीबी 8-कोर 2,000 IOPS के साथ एसएसडी वाला 250 जीबी लोकल स्टोरेज
एक ही मशीन पर मैसेज प्रोसेसर/राउटर 16 जीबी 8-कोर 100 जीबी
मैसेज प्रोसेसर (स्टैंडअलोन) 16 जीबी 8-कोर 100 जीबी
राऊटर (स्टैंडअलोन) 16 जीबी 8-कोर 100 जीबी
Analytics - Postgres/Qpid on same server 16 जीबी* 8‑कोर* 500 जीबी - 1 टीबी** नेटवर्क स्टोरेज***, एसएसडी बैकएंड के साथ, 1,000 आईओपीएस या इससे ज़्यादा के साथ काम करता हो*
Analytics - Postgres मास्टर या स्टैंडबाय (स्टैंडअलोन) 16 जीबी* 8-कोर* 500 जीबी - 1 टीबी** नेटवर्क स्टोरेज***, एसएसडी बैकएंड के साथ, 1,000 आईओपीएस या इससे ज़्यादा के साथ काम करता हो*
Analytics - Qpid standalone 8 जीबी 4-कोर एसएसडी के साथ 30 जीबी - 50 जीबी लोकल स्टोरेज

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

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

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

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

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 सीपीयू हार्ड डिस्क
मैनेजमेंट सर्वर (कमाई करने की सेवाओं के साथ) 8 जीबी 4‑कोर 60 जीबी
Analytics - Postgres/Qpid on same server 16 जीबी 8-कोर 500 जीबी - 1 टीबी नेटवर्क स्टोरेज, जो एसएसडी बैकएंड के साथ हो और 1, 000 आईओपीएस या इससे ज़्यादा को सपोर्ट करता हो. इसके अलावा, ऊपर दी गई टेबल में मौजूद नियम का इस्तेमाल करें.
Analytics - Postgres मास्टर या स्टैंडबाय स्टैंडअलोन 16 जीबी 8-कोर 500 जीबी - 1 टीबी नेटवर्क स्टोरेज, जो एसएसडी बैकएंड के साथ हो और 1, 000 आईओपीएस या इससे ज़्यादा को सपोर्ट करता हो. इसके अलावा, ऊपर दी गई टेबल में मौजूद नियम का इस्तेमाल करें.
Analytics - Qpid standalone 16 जीबी 8-कोर एसएसडी या तेज़ एचडीडी के साथ 40 जीबी - 500 जीबी लोकल स्टोरेज

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

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

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

Java

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

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

SELinux

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

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

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

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

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

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

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

सिमलिंक बनाने के लिए, bootstrap_4.51.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" है. ज़्यादा जानकारी के लिए, Edge कॉन्फ़िगरेशन फ़ाइल का रेफ़रंस देखें.

टीसीपी रैपर

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

iptables

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

sudo/etc/init.d/iptables stop

CentOS 7.x पर:

systemctl stop firewalld

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

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

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

Edge राऊटर, 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 सेवा शुरू न हो पाए.

Cassandra

सभी Cassandra नोड, एक रिंग से कनेक्ट होने चाहिए. Cassandra, डेटा की कॉपी को कई नोड पर सेव करता है, ताकि डेटा को सुरक्षित रखा जा सके और गड़बड़ियों को ठीक किया जा सके. हर Edge कीस्पेस के लिए, रेप्लिकेशन की रणनीति से यह तय होता है कि 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

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

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

  • Cassandra नोड पर, सॉफ़्ट और हार्ड मेमलॉक, नोफ़ाइल, और ऐड्रेस स्पेस (as) की सीमाएं सेट करें. ये सीमाएं, इंस्टॉल करने वाले उपयोगकर्ता (डिफ़ॉल्ट रूप से "apigee") के लिए /etc/security/limits.d/90-apigee-edge-limits.conf में सेट करें. इसके लिए, यहां दिया गया तरीका अपनाएं: 
    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

    ज़्यादा जानकारी के लिए, Apache Cassandra के दस्तावेज़ में प्रॉडक्शन के लिए सुझाई गई सेटिंग देखें.

  • मैसेज प्रोसेसर नोड पर, /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 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. फ़ाइल सेव करें.

AWS AMI

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

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

टूल

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

awk

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

uuid

chkconfig
dirname libibverbs pwd uname  
ईको librdmacm python    

ntpdate

Apigee का सुझाव है कि आपके सर्वर का समय सिंक किया गया हो. अगर पहले से कॉन्फ़िगर नहीं किया गया है, तो 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 को होस्ट करने वाले कई नोड होते हैं.

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

virtual शब्द का इस्तेमाल, आईटी सेक्टर में आम तौर पर कई चीज़ों के लिए किया जाता है. Apigee Edge for Private Cloud डिप्लॉयमेंट और वर्चुअल होस्ट के लिए भी ऐसा ही है. 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 ट्रैफ़िक को कनेक्ट करने की अनुमति देनी होगी.

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

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

एपीआई को डिप्लॉय करने पर, बेसपाथ सेट हो जाता है. ऊपर दिए गए उदाहरण के मुताबिक, 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 की सेल्स टीम से संपर्क करें.