हार्डवेयर की ज़रूरी शर्तें
प्रोडक्शन ग्रेड एनवायरमेंट में, ज़्यादा उपलब्धता वाले इंफ़्रास्ट्रक्चर के लिए, आपको हार्डवेयर से जुड़ी ये ज़रूरी शर्तें पूरी करनी होंगी.
इस वीडियो में, इंस्टॉलेशन के लिए साइज़ के बारे में अहम जानकारी दी गई है:
इंस्टॉलेशन टोपोलॉजी में बताए गए सभी इंस्टॉलेशन के लिए, यहां दी गई टेबल में इंस्टॉलेशन कॉम्पोनेंट के लिए हार्डवेयर की ज़रूरी शर्तों की सूची दी गई है.
इन टेबल में, हार्ड डिस्क की ज़रूरी जगह के बारे में बताया गया है. यह जगह, ऑपरेटिंग सिस्टम के लिए ज़रूरी जगह के अलावा है. आपके ऐप्लिकेशन और नेटवर्क ट्रैफ़िक के आधार पर, इंस्टॉलेशन के लिए यहां दिए गए संसाधनों से ज़्यादा या कम संसाधनों की ज़रूरत पड़ सकती है.
इंस्टॉलेशन कॉम्पोनेंट | RAM | सीपीयू | कम से कम हार्ड डिस्क |
---|---|---|---|
Cassandra (स्टैंडअलोन) | 16GB | 8-कोर | 250 जीबी लोकल स्टोरेज, जिसमें एसएसडी 2000 IOPS के साथ काम करता हो |
एक ही मशीन पर Cassandra/Zookeeper | 16GB | 8-कोर | 250 जीबी लोकल स्टोरेज, जिसमें एसएसडी 2000 IOPS के साथ काम करता हो |
एक ही मशीन पर मैसेज प्रोसेसर/राउटर | 16GB | 8-कोर | 100 जीबी |
मैसेज प्रोसेसर (स्टैंडअलोन) | 16GB | 8-कोर | 100 जीबी |
राऊटर (स्टैंडअलोन) | 8 जीबी | 8-कोर | 100 जीबी |
Analytics - Postgres/Qpid on same server | 16GB* | 8‑कोर* | 500 जीबी से 1 टीबी** नेटवर्क स्टोरेज***. बेहतर होगा कि इसमें एसएसडी बैकएंड हो और यह 1,000 आईओपीएस या इससे ज़्यादा* को सपोर्ट करता हो |
Analytics - Postgres मास्टर या स्टैंडबाय स्टैंडअलोन | 16GB* | 8-कोर* | 500 जीबी से 1 टीबी** नेटवर्क स्टोरेज***. बेहतर होगा कि इसमें एसएसडी बैकएंड हो और यह 1,000 आईओपीएस या इससे ज़्यादा* को सपोर्ट करता हो |
Analytics - Qpid (स्टैंडअलोन) | 8 जीबी | 4-कोर | एसएसडी के साथ 30 जीबी से 50 जीबी लोकल स्टोरेज
Qpid की डिफ़ॉल्ट कतार का साइज़ 1 जीबी होता है. इसे 2 जीबी तक बढ़ाया जा सकता है. अगर आपको ज़्यादा क्षमता चाहिए, तो Qpid के और नोड जोड़ें. |
SymasLDAP/UI/Management Server | 8 जीबी | 4-कोर | 60 जीबी |
यूज़र इंटरफ़ेस (यूआई)/मैनेजमेंट सर्वर | 4 जीबी | दो कोर | 60 जीबी |
SymasLDAP (स्टैंडअलोन) | 4 जीबी | दो कोर | 60 जीबी |
* थ्रूपुट के आधार पर, Postgres के लिए सिस्टम की ज़रूरी शर्तों में बदलाव करें:
** Postgres हार्ड डिस्क की वैल्यू, Edge से कैप्चर किए गए आउट ऑफ़ द बॉक्स ऐनलिटिक्स पर आधारित होती है. अगर आपने Analytics के डेटा में कस्टम वैल्यू जोड़ी हैं, तो इन वैल्यू को उसी हिसाब से बढ़ाना चाहिए. ज़रूरी स्टोरेज का अनुमान लगाने के लिए, इस फ़ॉर्मूले का इस्तेमाल करें:
उदाहरण के लिए:
*** Postgresql डेटाबेस के लिए नेटवर्क स्टोरेज का सुझाव दिया जाता है, क्योंकि:
|
इसके अलावा, अगर आपको कमाई करने से जुड़ी सेवाएं इंस्टॉल करनी हैं, तो यहां हार्डवेयर से जुड़ी ज़रूरी शर्तों की सूची दी गई है. ये सेवाएं, ऑल-इन-वन इंस्टॉलेशन पर काम नहीं करती हैं:
कमाई करने की सुविधा वाला कॉम्पोनेंट | RAM | सीपीयू | हार्ड डिस्क |
---|---|---|---|
मैनेजमेंट सर्वर (कमाई करने से जुड़ी सेवाओं के साथ) | 8 जीबी | 4‑कोर | 60 जीबी |
Analytics - Postgres/Qpid on same server | 16GB | 8-कोर | 500 जीबी से 1 टीबी का नेटवर्क स्टोरेज. बेहतर होगा कि इसमें एसएसडी बैकएंड हो. साथ ही, यह 1, 000 आईओपीएस या इससे ज़्यादा को सपोर्ट करता हो. इसके अलावा, ऊपर दी गई टेबल में मौजूद नियम का इस्तेमाल करें. |
Analytics - Postgres मास्टर या स्टैंडबाय स्टैंडअलोन | 16GB | 8-कोर | 500 जीबी से 1 टीबी का नेटवर्क स्टोरेज. बेहतर होगा कि इसमें एसएसडी बैकएंड हो. साथ ही, यह 1, 000 आईओपीएस या इससे ज़्यादा को सपोर्ट करता हो. इसके अलावा, ऊपर दी गई टेबल में मौजूद नियम का इस्तेमाल करें. |
Analytics - Qpid (स्टैंडअलोन) | 8 जीबी | 4-कोर | एसएसडी या फ़ास्ट एचडीडी के साथ 40 जीबी से 500 जीबी का लोकल स्टोरेज
अगर 250 टीपीएस से ज़्यादा इंस्टॉलेशन करने हैं, तो हमारा सुझाव है कि 1,000 आईओपीएस के साथ काम करने वाले लोकल स्टोरेज वाले एचडीडी का इस्तेमाल करें. |
Cassandra नेटवर्क के लिए बैंडविड्थ की ज़रूरी शर्तें
Cassandra, नेटवर्क टोपोलॉजी के बारे में अन्य नोड के साथ जानकारी शेयर करने के लिए, गॉसिप प्रोटोकॉल का इस्तेमाल करता है. Cassandra में डेटा को कई नोड में बांटा जाता है. साथ ही, इसमें Gossip प्रोटोकॉल का इस्तेमाल किया जाता है. इस वजह से, नेटवर्क पर डेटा ट्रांसफ़र की प्रोसेस काफ़ी बढ़ जाती है. Gossip प्रोटोकॉल के तहत, रीड और राइट ऑपरेशन के लिए कई नोड से कम्यूनिकेट करना पड़ता है.
Cassandra के लिए, नेटवर्क बैंडविड्थ कम से कम 1 Gbps प्रति नोड होनी चाहिए. प्रोडक्शन इंस्टॉलेशन के लिए, ज़्यादा बैंडविथ का सुझाव दिया जाता है.
Cassandra के लिए, ज़्यादा से ज़्यादा या 99वें पर्सेंटाइल की लेटेन्सी 100 मिलीसेकंड से कम होनी चाहिए.
ऑपरेटिंग सिस्टम और तीसरे पक्ष के सॉफ़्टवेयर से जुड़ी ज़रूरी शर्तें
इंस्टॉल करने के इन निर्देशों और इंस्टॉल करने के लिए उपलब्ध कराई गई फ़ाइलों को, सपोर्ट किए गए सॉफ़्टवेयर और उनके वर्शन में दिए गए ऑपरेटिंग सिस्टम और तीसरे पक्ष के सॉफ़्टवेयर पर टेस्ट किया गया है.
ज़रूरी शर्तें: EPEL repo चालू करें
इंस्टॉल करने से पहले, पक्का करें कि 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' नाम का Unix सिस्टम उपयोगकर्ता बनाती है. Edge डायरेक्ट्री और फ़ाइलों के साथ-साथ Edge प्रोसेस का मालिकाना हक भी 'apigee' के पास होता है. इसका मतलब है कि Edge कॉम्पोनेंट, 'apigee' उपयोगकर्ता के तौर पर चलते हैं. ज़रूरत पड़ने पर, कॉम्पोनेंट को किसी दूसरे उपयोगकर्ता के तौर पर चलाया जा सकता है.
इंस्टॉलेशन डायरेक्ट्री
डिफ़ॉल्ट रूप से, इंस्टॉलर सभी फ़ाइलों को /opt/apigee
डायरेक्ट्री में लिखता है. इस डायरेक्ट्री की जगह की जानकारी को बदला नहीं जा सकता. इस डायरेक्ट्री को बदला नहीं जा सकता. हालांकि, /opt/apigee
को किसी दूसरी जगह पर मैप करने के लिए, सिंबॉलिक लिंक बनाया जा सकता है. इसके बारे में /opt/apigee से सिंबॉलिक लिंक बनाना लेख में बताया गया है.
इस गाइड में दिए गए निर्देशों में, इंस्टॉलेशन डायरेक्ट्री को /opt/apigee
के तौर पर दिखाया गया है.
/opt/apigee से सिंबॉलिक लिंक बनाया जा रहा है
सिमलिंक बनाने से पहले, आपको "apigee" नाम का उपयोगकर्ता और ग्रुप बनाना होगा. यह वही ग्रुप और उपयोगकर्ता है जिसे Edge इंस्टॉलर ने बनाया है.
सिमलिंक बनाने के लिए, bootstrap_4.53.01.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" है. ज़्यादा जानकारी के लिए, Edge कॉन्फ़िगरेशन फ़ाइल का रेफ़रंस देखें.
टीसीपी रैपर
टीसीपी रैपर, कुछ पोर्ट के कम्यूनिकेशन को ब्लॉक कर सकते हैं. साथ ही, इससे SymasLDAP, Postgres, और Cassandra के इंस्टॉलेशन पर असर पड़ सकता है. उन नोड पर, /etc/hosts.allow
और /etc/hosts.deny
की जांच करें. इससे यह पक्का किया जा सकेगा कि ज़रूरी SymasLDAP, Postgres, और Cassandra पोर्ट पर कोई पाबंदी न हो.
iptables
पुष्टि करें कि iptables की कोई भी नीति, ज़रूरी Edge पोर्ट पर नोड के बीच कनेक्टिविटी को नहीं रोक रही है. अगर ज़रूरी हो, तो iptables को इंस्टॉल करने के दौरान, इस कमांड का इस्तेमाल करके बंद किया जा सकता है:
sudo/etc/init.d/iptables stop
निर्देशिका का ऐक्सेस
यहां दी गई टेबल में, Edge नोड पर मौजूद उन डायरेक्ट्री की सूची दी गई है जिनके लिए Edge प्रोसेस की खास ज़रूरतें होती हैं:
सेवा | डायरेक्ट्री | ब्यौरा |
---|---|---|
राऊटर | /etc/rc.d/init.d/functions |
Edge Router, Nginx Router का इस्तेमाल करता है. साथ ही, इसे अगर सुरक्षा से जुड़ी प्रोसेस के लिए, आपको
|
चिड़ियाघर में जानवरों की देखभाल करने वाला | /dev/random |
Zookeeper क्लाइंट लाइब्रेरी को रैंडम नंबर जनरेटर /dev/random को पढ़ने का ऐक्सेस चाहिए. अगर /dev/random को पढ़ने से ब्लॉक किया जाता है, तो हो सकता है कि Zookeeper सेवा शुरू न हो पाए. |
Cassandra
सभी Cassandra नोड, रिंग से कनेक्ट होने चाहिए. Cassandra, डेटा की रेप्लिका को कई नोड पर सेव करता है, ताकि यह पक्का किया जा सके कि डेटा भरोसेमंद है और इसमें गड़बड़ी होने की संभावना कम है. हर Edge keyspace के लिए रेप्लिकेशन की रणनीति यह तय करती है कि रेप्लिका को किन Cassandra नोड पर रखा जाएगा. ज़्यादा जानकारी के लिए, Cassandra के रेप्लिकेशन फ़ैक्टर और कंसिस्टेंसी लेवल के बारे में जानकारी लेख पढ़ें.
Cassandra, उपलब्ध मेमोरी के हिसाब से Java हीप के साइज़ को अपने-आप अडजस्ट करता है. ज़्यादा जानकारी के लिए, परफ़ॉर्मेंस में गिरावट या ज़्यादा मेमोरी इस्तेमाल होने की स्थिति में, Java संसाधनों को ट्यून करना लेख पढ़ें.
Edge for Private Cloud इंस्टॉल करने के बाद, यह देखा जा सकता है कि Cassandra को सही तरीके से कॉन्फ़िगर किया गया है या नहीं. इसके लिए, /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
इन वैल्यू को सेट करने के लिए:
- postgresql.properties फ़ाइल में बदलाव करें:
vi /opt/apigee/customer/application/postgresql.properties
अगर फ़ाइल मौजूद नहीं है, तो उसे बनाएं.
- ऊपर दी गई प्रॉपर्टी सेट करें.
- बदलावों को सेव करें.
- 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 और Message Processor नोड पर, सिस्टम की ये सीमाएं सेट की हों:
- 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
- मैसेज प्रोसेसर नोड पर, खुले फ़ाइल डिस्क्रिप्टर की ज़्यादा से ज़्यादा संख्या को 64 हज़ार पर सेट करें. इसके लिए,
/etc/security/limits.d/90-apigee-edge-limits.conf
में जाकर नीचे दिया गया तरीका अपनाएं: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 पर डीएनएस लुकअप की सुविधा बंद करने के लिए:
- हर मैसेज प्रोसेसर नोड पर,
/etc/nscd.conf
में बदलाव करें - यह प्रॉपर्टी सेट करें:
enable-cache hosts no
RHEL 8 और इसके बाद के वर्शन पर IPv6 बंद करना
अगर आपको Google Cloud Platform पर RHEL 8 या इसके बाद के वर्शन पर Edge इंस्टॉल करना है, तो आपको सभी Qpid नोड पर IPv6 बंद करना होगा.
IPv6 को बंद करने के निर्देशों के लिए, कृपया अपने ओएस वेंडर के दिए गए दस्तावेज़ देखें. उदाहरण के लिए, Red Hat Enterprise Linux के दस्तावेज़ में काम की जानकारी देखी जा सकती है.
टूल
इंस्टॉलर, स्टैंडर्ड वर्शन में EL5 या EL6 के ज़रिए उपलब्ध कराए गए इन UNIX टूल का इस्तेमाल करता है.
awk |
expr |
libxslt |
आरपीएम |
unzip |
basename |
grep |
lua-socket |
rpm2cpio |
useradd |
बैश |
hostname |
ls |
sed |
wc |
bc |
आईडी |
net-tools |
sudo |
wget |
curl |
libaio |
perl (from procps) |
tar |
xerces-c |
cyrus-sasl | libdb4 | pgrep (from procps) | tr | लज़ीज़ |
तारीख |
libdb-cxx |
ps |
uuid |
chkconfig |
dirname | libibverbs | pwd | uname | |
ईको | librdmacm | python |
समय सिंक करना
Apigee का सुझाव है कि आपके सर्वर का समय सिंक किया गया हो. अगर यह पहले से कॉन्फ़िगर नहीं है, तो ntpdate
यूटिलिटी या इसके जैसा कोई टूल, यह काम कर सकता है. इसके लिए, वह यह पुष्टि करता है कि सर्वर का समय सिंक किया गया है या नहीं. उदाहरण के लिए, यूटिलिटी इंस्टॉल करने के लिए, yum install ntp
या इसके जैसी किसी अन्य कमांड का इस्तेमाल किया जा सकता है. यह खास तौर पर, LDAP सेटअप को दोहराने के लिए मददगार है. कृपया ध्यान दें कि आपको सर्वर के टाइम ज़ोन को यूटीसी पर सेट करना होगा.
फ़ायरवॉल और वर्चुअल होस्ट
आईटी के क्षेत्र में, virtual
शब्द का इस्तेमाल अक्सर कई तरह के कामों के लिए किया जाता है. Apigee Edge for Private Cloud डिप्लॉयमेंट और वर्चुअल होस्ट के लिए भी ऐसा ही होता है. हम आपको बता दें कि virtual
शब्द का इस्तेमाल दो मुख्य तरीकों से किया जाता है:
- वर्चुअल मशीनें (वीएम): इनकी ज़रूरत नहीं होती. हालांकि, कुछ डिप्लॉयमेंट, Apigee कॉम्पोनेंट के लिए अलग-अलग सर्वर बनाने के लिए वीएम टेक्नोलॉजी का इस्तेमाल करते हैं. फ़िजिकल होस्ट की तरह ही, वीएम होस्ट में भी नेटवर्क इंटरफ़ेस और फ़ायरवॉल हो सकते हैं.
- वर्चुअल होस्ट: वेब एंडपॉइंट, Apache वर्चुअल होस्ट के जैसे होते हैं.
किसी वीएम में मौजूद एक राउटर, कई वर्चुअल होस्ट को ऐक्सेस करने की अनुमति दे सकता है. हालांकि, इसके लिए ज़रूरी है कि उनके होस्ट एलियास या इंटरफ़ेस पोर्ट एक-दूसरे से अलग हों.
नामकरण के उदाहरण के तौर पर, एक फ़िज़िकल सर्वर A
दो वीएम चला रहा है. इनके नाम "VM1" और "VM2" हैं. मान लें कि "VM1" एक वर्चुअल इथरनेट इंटरफ़ेस दिखाता है. इसे VM के अंदर "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 की सेल्स टीम से संपर्क करें.