हार्डवेयर की ज़रूरी शर्तें
प्रोडक्शन ग्रेड वाले एनवायरमेंट में, हमेशा उपलब्ध रहने वाले इन्फ़्रास्ट्रक्चर के लिए, आपको हार्डवेयर से जुड़ी ये ज़रूरी शर्तें पूरी करनी होंगी.
इस वीडियो में, इंस्टॉलेशन के लिए साइज़ तय करने के बारे में खास जानकारी दी गई है:
इंस्टॉलेशन टॉपोलॉजी में बताए गए इंस्टॉलेशन के सभी मामलों के लिए, यहां दी गई टेबल में इंस्टॉलेशन कॉम्पोनेंट के लिए हार्डवेयर की ज़रूरी शर्तों की सूची दी गई है.
इन टेबल में, ऑपरेटिंग सिस्टम के लिए हार्ड डिस्क में ज़रूरी जगह के अलावा, हार्ड डिस्क से जुड़ी ज़रूरी शर्तें भी शामिल हैं. आपके ऐप्लिकेशन और नेटवर्क ट्रैफ़िक के आधार पर, हो सकता है कि आपके इंस्टॉलेशन के लिए, यहां बताए गए संसाधनों से ज़्यादा या कम संसाधनों की ज़रूरत पड़े.
इंस्टॉलेशन कॉम्पोनेंट | 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 सिस्टम की ज़रूरी शर्तों में बदलाव करना:
** Postgres हार्ड डिस्क की वैल्यू, Edge से कैप्चर किए गए आउट ऑफ़ द बॉक्स आंकड़ों पर आधारित होती है. अगर Analytics डेटा में कस्टम वैल्यू जोड़ी जाती हैं, तो इन वैल्यू को तदनुसार बढ़ाया जाना चाहिए. ज़रूरी स्टोरेज का अनुमान लगाने के लिए, नीचे दिए गए फ़ॉर्मूले का इस्तेमाल करें:
उदाहरण के लिए:
*** 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 मिलीसेकंड से कम होना चाहिए.
ऑपरेटिंग सिस्टम और तीसरे पक्ष के सॉफ़्टवेयर से जुड़ी ज़रूरी शर्तें
इंस्टॉल करने के इन निर्देशों और इंस्टॉल करने के लिए दी गई फ़ाइलों को, इस्तेमाल किए जा सकने वाले सॉफ़्टवेयर और उनके वर्शन में दिए गए ऑपरेटिंग सिस्टम और तीसरे पक्ष के सॉफ़्टवेयर पर टेस्ट किया गया है.
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
के तौर पर दिखाया गया है.
/opt/apigee से सिमलिंक बनाना
सिंबल लिंक बनाने से पहले, आपको "apigee" नाम का एक उपयोगकर्ता और ग्रुप बनाना होगा. यह वही ग्रुप और उपयोगकर्ता है जिसे Edge इंस्टॉलर ने बनाया है.
सिंबल लिंक बनाने के लिए, bootstrap_4.52.02.sh फ़ाइल डाउनलोड करने से पहले, यह तरीका अपनाएं. आपको ये सभी चरण रूट के तौर पर पूरे करने होंगे:
- "apigee" उपयोगकर्ता और ग्रुप बनाएं:
groupadd -r apigee > useradd -r -g apigee -d /opt/apigee -s /sbin/nologin -c "Apigee platform user" apigee
/opt/apigee
से अपने पसंदीदा इंस्टॉल रूट पर सिमलिंक बनाएं:ln -Ts /srv/myInstallDir /opt/apigee
यहां /srv/myInstallDir, Edge फ़ाइलों की पसंदीदा जगह है.
- इंस्टॉल रूट और सिमलिनक का मालिकाना हक, "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
CentOS 7.x पर:
systemctl stop firewalld
निर्देशिका का ऐक्सेस
यहां दी गई टेबल में, Edge नोड पर मौजूद उन डायरेक्ट्री की सूची दी गई है जिनके लिए, Edge प्रोसेस की खास ज़रूरतें होती हैं:
सेवा | डायरेक्ट्री | ब्यौरा |
---|---|---|
राऊटर | /etc/rc.d/init.d/functions |
Edge Router, Nginx राउटर का इस्तेमाल करता है. साथ ही, उसे अगर आपकी सुरक्षा प्रोसेस के लिए, आपको
|
चिड़ियाघर का रखरखाव करने वाला व्यक्ति | /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
ये वैल्यू सेट करने के लिए:
- postgresql.properties फ़ाइल में बदलाव करें:
vi /opt/apigee/customer/application/postgresql.properties
अगर फ़ाइल मौजूद नहीं है, तो उसे बनाएं.
- ऊपर दी गई प्रॉपर्टी सेट करें.
- किए गए बदलाव सेव करें.
- PostgreSQL डेटाबेस को रीस्टार्ट करें:
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart
सिस्टम की सीमाएं
पक्का करें कि आपने 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 पर डीएनएस लुकअप की सुविधा बंद करने के लिए:
- हर मैसेज प्रोसेसर नोड पर,
/etc/nscd.conf
में बदलाव करें - यह प्रॉपर्टी सेट करें:
enable-cache hosts no
RedHat/CentOS 7 के लिए, Google Cloud Platform पर IPv6 की सुविधा बंद करना
अगर Google Cloud Platform पर RedHat 7 या CentOS 7 पर Edge इंस्टॉल किया जा रहा है, तो आपको सभी Qpid नोड पर IPv6 बंद करना होगा.
IPv6 को बंद करने के निर्देशों के लिए, अपने ओएस वर्शन के RedHat या CentOS दस्तावेज़ देखें. उदाहरण के लिए:
/etc/hosts
को किसी एडिटर में खोलें.- नीचे दी गई लाइन के कॉलम 1 में "#" वर्ण डालें, ताकि उस पर टिप्पणी की जा सके:
#::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
- फ़ाइल सेव करें.
AWS AMI
अगर आपको Red Hat Enterprise Linux 7.x के लिए, AWS Amazon मशीन इमेज (AMI) पर Edge इंस्टॉल करना है, तो आपको सबसे पहले यह कमांड चलाना होगा:
yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional
टूल
इंस्टॉलर, 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 |
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 के साथ भी होता है. साफ़ तौर पर बताएं, 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 की सेल्स टीम से संपर्क करें.