Edge for Private Cloud v4.18.05
हार्डवेयर से जुड़ी ज़रूरी शर्तें
प्रोडक्शन ग्रेड एनवायरमेंट में, बहुत ज़्यादा उपलब्ध इन्फ़्रास्ट्रक्चर के लिए, आपको हार्डवेयर से जुड़ी ये ज़रूरी शर्तें पूरी करनी होंगी.
इस वीडियो में, इंस्टॉल करने के लिए साइज़ से जुड़े बड़े दिशा-निर्देश दिए गए हैं:
इंस्टॉलेशन टोपोलॉजी में बताए गए सभी इंस्टॉल के लिए, नीचे दी गई टेबल में इंस्टॉल किए जाने वाले कॉम्पोनेंट के लिए ज़रूरी हार्डवेयर की कम से कम ज़रूरतों के बारे में बताया गया है.
इन टेबल में, हार्ड डिस्क के स्टोरेज की शर्त, ऑपरेटिंग सिस्टम के लिए हार्ड डिस्क के स्टोरेज की सीमा से अलग है. आपके ऐप्लिकेशन और नेटवर्क ट्रैफ़िक के आधार पर, आपको इंस्टॉल करने के लिए नीचे दिए गए संसाधनों से ज़्यादा या कम संसाधनों की ज़रूरत पड़ सकती है.
इंस्टॉलेशन कॉम्पोनेंट | RAM | CPU | कम से कम हार्ड डिस्क |
---|---|---|---|
कसांद्रा | 16 जीबी | 8-कोर | 2000 IOPS के साथ काम करने वाले एसएसडी या तेज़ एचडीडी के साथ 250 जीबी का लोकल स्टोरेज |
एक ही मशीन पर मैसेज प्रोसेसर/राउटर | 16 जीबी | 8-कोर | 100 जीबी |
Analytics - एक ही सर्वर पर Postgres/Qpid | 16 जीबी* | 8-कोर* | 500 जीबी - 1 टीबी** नेटवर्क स्टोरेज***, एसएसडी बैकएंड के साथ 1,000 या इससे ज़्यादा आईओपीएस के साथ काम करता हो* |
Analytics - Postgres स्टैंडअलोन | 16 जीबी* | 8-कोर* | 500 जीबी - 1 टीबी** नेटवर्क स्टोरेज***, एसएसडी बैकएंड के साथ 1,000 या इससे ज़्यादा आईओपीएस के साथ काम करता हो* |
Analytics - Qpid स्टैंडअलोन | 8 जीबी | 4-कोर | 30GB - एसएसडी या तेज़ एचडीडी के साथ 50 जीबी का लोकल स्टोरेज
250 टीपीएस से ज़्यादा साइज़ के इवेंट के लिए, लोकल स्टोरेज वाले एचडीडी का इस्तेमाल करने का सुझाव दिया जाता है. इसमें, 1,000 आईओपीएस की सुविधा होनी चाहिए. Qpid सूची का डिफ़ॉल्ट साइज़ 20 जीबी है. अगर आपको ज़्यादा क्षमता जोड़नी है, तो अतिरिक्त Qpid नोड जोड़ें. |
अन्य (OpenLDAP, यूज़र इंटरफ़ेस (यूआई), मैनेजमेंट सर्वर) | 4 जीबी | 2-कोर | 60 जीबी |
* थ्रूपुट के आधार पर Postgres सिस्टम की ज़रूरी शर्तों में बदलाव करें:
- 250 से कम TPS: 8 जीबी, 4-कोर वाले डिवाइस को मैनेज किए जा रहे नेटवर्क स्टोरेज के साथ इस्तेमाल किया जा सकता है*** 1,000 या इससे ज़्यादा आईओपीएस के साथ काम करने वाला
- 250 TPS से ज़्यादा: 16 जीबी, 8 कोर, मैनेज किया जा रहा नेटवर्क स्टोरेज*** 1000 या इससे ज़्यादा आईओपीएस के साथ काम करता है
- 1000 से ज़्यादा TPS: 16 जीबी, 8 कोर, मैनेज किया जा रहा नेटवर्क स्टोरेज*** 2000 या इससे ज़्यादा आईओपीएस के साथ काम करता है
- 2000 से ज़्यादा TPS: 32 जीबी, 16-कोर, मैनेज किया जा रहा नेटवर्क स्टोरेज*** 2,000 या इससे ज़्यादा आईओपीएस के साथ काम करता है
- 4,000 TPS से ज़्यादा: 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
*** Postgresql डेटाबेस के लिए नेटवर्क स्टोरेज का सुझाव दिया जाता है, क्योंकि:
- इससे, ज़रूरत पड़ने पर स्टोरेज के साइज़ को डाइनैमिक तरीके से बढ़ाया जा सकता है.
- नेटवर्क IOPS को आज के ज़्यादातर एनवायरमेंट/स्टोरेज/नेटवर्क सबसिस्टम में तुरंत अडजस्ट किया जा सकता है.
- बैकअप और खाता वापस पाने के तरीके के तौर पर, स्टोरेज के स्नैपशॉट चालू किए जा सकते हैं.
इसके अलावा, कमाई करने से जुड़ी सेवाएं इंस्टॉल करने के लिए, यहां दी गई हार्डवेयर से जुड़ी ज़रूरी शर्तें यहां दी गई हैं:
कमाई करने की सुविधा वाला कॉम्पोनेंट | RAM | CPU | हार्ड डिस्क |
---|---|---|---|
मैनेजमेंट सर्वर (कमाई करने वाली सेवाओं के साथ) | 8 जीबी | 4-कोर | 60 जीबी |
Analytics - एक ही सर्वर पर Postgres/Qpid | 16 जीबी | 8-कोर | 500 जीबी - 1 टीबी नेटवर्क स्टोरेज. आम तौर पर, यह एसएसडी बैकएंड के साथ होता है और 1, 000 आईओपीएस या इससे ज़्यादा के वर्शन के साथ काम करता है. इसके अलावा, ऊपर दी गई टेबल में दिए गए नियम का भी इस्तेमाल किया जा सकता है. |
Analytics - Postgres स्टैंडअलोन | 16 जीबी | 8-कोर | 500 जीबी - 1 टीबी नेटवर्क स्टोरेज. आम तौर पर, यह एसएसडी बैकएंड के साथ होता है और 1, 000 आईओपीएस या इससे ज़्यादा के वर्शन के साथ काम करता है. इसके अलावा, ऊपर दी गई टेबल में दिए गए नियम का भी इस्तेमाल किया जा सकता है. |
Analytics - Qpid स्टैंडअलोन | 8 जीबी | 4-कोर | 40GB - एसएसडी या तेज़ एचडीडी के साथ 500 जीबी का लोकल स्टोरेज
250 टीपीएस से ज़्यादा साइज़ के इवेंट के लिए, लोकल स्टोरेज वाले एचडीडी का इस्तेमाल करने का सुझाव दिया जाता है. इसमें, 1,000 आईओपीएस की सुविधा होनी चाहिए. |
ऑपरेटिंग सिस्टम और तीसरे पक्ष के सॉफ़्टवेयर से जुड़ी ज़रूरी शर्तें
इंस्टॉल करने के इन निर्देशों और इंस्टॉल करने के लिए दी गई फ़ाइलों की जांच, ऑपरेटिंग सिस्टम और तीसरे पक्ष के सॉफ़्टवेयर पर की गई है. इन सॉफ़्टवेयर की सूची काम करने वाले सॉफ़्टवेयर और इसके साथ काम करने वाले वर्शन में दी गई है.
'apigee' उपयोगकर्ता बनाया जा रहा है
इंस्टॉल करने की प्रोसेस के दौरान, 'apigee' नाम का एक यूनिक्स सिस्टम उपयोगकर्ता बनाया जाता है. Edge की प्रोसेस की तरह, Edge की डायरेक्ट्री और फ़ाइलों का मालिकाना हक 'apigee' के पास होता है. इसका मतलब है कि Edge कॉम्पोनेंट, 'apigee' उपयोगकर्ता के तौर पर चलते हैं. अगर ज़रूरी हो, तो कॉम्पोनेंट को किसी दूसरे उपयोगकर्ता के तौर पर चलाया जा सकता है.
इंस्टॉलेशन डायरेक्ट्री
डिफ़ॉल्ट रूप से, इंस्टॉलर सभी फ़ाइलों को /opt/apigee
डायरेक्ट्री में लिखता है. आपके पास
इस डायरेक्ट्री की जगह को बदलने का विकल्प नहीं है. इस डायरेक्ट्री में बदलाव नहीं किया जा सकता. हालांकि, /opt/apigee
को किसी दूसरी जगह पर मैप करने के लिए एक सिमलिंक बनाया जा सकता है, जैसा कि /opt/apigee से सिमलिंक बनाना में बताया गया है.
इस गाइड में दिए गए निर्देशों में, इंस्टॉलेशन डायरेक्ट्री को /opt/apigee
के तौर पर बताया गया है.
/opt/apigee से सिमलिंक बनाना
सिमलिंक बनाने से पहले, आपको "apigee" नाम का एक उपयोगकर्ता और ग्रुप बनाना होगा. यह वही ग्रुप और उपयोगकर्ता है जिसे Edge इंस्टॉलर के ज़रिए बनाया गया है.
सिमलिंक बनाने के लिए, बूटstrap_4.18.05.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
जहां Edge फ़ाइलों में /srv/myInstallDir सही जगह पर हो.
- इंस्टॉल रूट और सिमलिंक का मालिकाना हक "apigee" उपयोगकर्ता को दे दें:
chown -h apigee:apigee /srv/myInstallDir /opt/apigee
Java
इंस्टॉलेशन से पहले हर मशीन पर, Java 1.8 का इस्तेमाल किया जा सकने वाला वर्शन होना ज़रूरी है. जिन JDKs का इस्तेमाल किया जा सकता है उनकी सूची साथ काम करने वाले सॉफ़्टवेयर और ऐसे वर्शन में दी गई है जिन पर यह सुविधा काम करती है.
पक्का करें कि JAVA_HOME
एनवायरमेंट वैरिएबल, उपयोगकर्ता के इंस्टॉल करने के लिए JDK के रूट की ओर पॉइंट करता हो.
SELinux
SELinux की आपकी सेटिंग के हिसाब से, Edge को Edge कॉम्पोनेंट को इंस्टॉल और चालू करने में समस्या आ सकती है. अगर ज़रूरी हो, तो SELinux को बंद किया जा सकता है या इंस्टॉल करने के दौरान इसे अनुमति वाले मोड पर सेट किया जा सकता है. इसके बाद, इंस्टॉल करने के बाद इसे फिर से चालू किया जा सकता है. ज़्यादा जानकारी के लिए, Edge apigee-setup उपयोगिता इंस्टॉल करें देखें.
नेटवर्क सेटिंग
Apigee का सुझाव है कि इंस्टॉल करने से पहले, आप नेटवर्क सेटिंग की जांच कर लें. इंस्टॉलर को यह उम्मीद करनी चाहिए कि सभी मशीनों के आईपी पते तय हों. सेटिंग की पुष्टि करने के लिए, इन निर्देशों का इस्तेमाल करें:
hostname
, मशीन का नाम दिखाता हैhostname -i
उस होस्टनेम के लिए आईपी पता दिखाता है जिसे दूसरी मशीनों से ठीक किया जा सकता है.
अगर होस्टनेम सही तरीके से सेट नहीं किया गया है, तो आपको
/etc/hosts
और /etc/sysconfig/network
में बदलाव करना पड़ सकता है. ये बदलाव आपके ऑपरेटिंग सिस्टम के टाइप और वर्शन पर
निर्भर करते हैं. ज़्यादा जानकारी के लिए, अपने खास ऑपरेटिंग सिस्टम से जुड़े दस्तावेज़ देखें.
अगर किसी सर्वर में एक से ज़्यादा इंटरफ़ेस कार्ड हैं, तो "hostname -i" कमांड, आईपी पतों की स्पेस से अलग की गई सूची दिखाता है. डिफ़ॉल्ट रूप से, Edge इंस्टॉलर, लौटाए गए पहले आईपी पते का इस्तेमाल करता है, जो सभी स्थितियों में सही नहीं भी हो सकता है. विकल्प के तौर पर, आपके पास इस प्रॉपर्टी को इंस्टॉलेशन कॉन्फ़िगरेशन फ़ाइल में सेट करने का विकल्प होता है:
ENABLE_DYNAMIC_HOSTIP=y
जब प्रॉपर्टी "y" पर सेट होती है, तो इंस्टॉलर आपको वह आईपी पता चुनने का निर्देश देता है जिसे इंस्टॉल के तौर पर इस्तेमाल करना है. डिफ़ॉल्ट वैल्यू "n" है. ज़्यादा जानकारी के लिए, Edge कॉन्फ़िगरेशन फ़ाइल का रेफ़रंस देखें.
टीसीपी रैपर
टीसीपी रैपर कुछ पोर्ट के कम्यूनिकेशन को ब्लॉक कर सकते हैं. साथ ही, OpenLDAP, Postgres, और कैसेंड्रा को
इंस्टॉल करने पर असर डाल सकते हैं. उन नोड पर, /etc/hosts.allow
और
/etc/hosts.deny
की जांच करके पक्का करें कि ज़रूरी OpenLDAP, Postgres, और कैसेंड्रा पोर्ट पर कोई पोर्ट प्रतिबंध नहीं है.
Iptable
पुष्टि करें कि ऐसी कोई iptables नीति नहीं है जो ज़रूरी Edge पोर्ट पर नोड के बीच कनेक्टिविटी को रोकती है. अगर ज़रूरी हो, तो इंस्टॉल करने के दौरान iptables को रोका जा सकता है. इसके लिए निर्देश दें:
sudo/etc/init.d/iptables stop
CentOS 7.x पर उपलब्ध:
systemctl stop firewalld
पक्का करें कि एज राऊटर /etc/rc.d/init.d/Functions को ऐक्सेस कर सकता हो
Edge राऊटर, Ngnx राऊटर का इस्तेमाल करता है और उसे /etc/rc.d/init.d/functions
पढ़ने का ऐक्सेस चाहिए.
अगर सुरक्षा से जुड़ी प्रोसेस के लिए आपको
/etc/rc.d/init.d/functions
पर अनुमतियां सेट करनी हैं, तो उन्हें 700 पर सेट न करें. ऐसा न करने पर, राऊटर काम नहीं करेगा. /etc/rc.d/init.d/functions
को पढ़ने का ऐक्सेस देने के लिए, अनुमतियां 744 पर सेट की जा सकती हैं.
कसांद्रा
सभी कैसेंड्रा नोड रिंग से जुड़े होने चाहिए. कैसेंड्रा, डेटा की नकल करके, उसे कई नोड पर सेव करती है, ताकि यह पक्का किया जा सके कि वह भरोसेमंद है और गड़बड़ी को सहन न कर सके. हर Edge कीस्पेस के लिए नकल करने की रणनीति से कैसंड्रा नोड के बारे में तय होता है जहां कॉपी बनाए जाते हैं. ज़्यादा जानने के लिए, Cassandra के रेप्लिकेशन फ़ैक्टर और कंसिस्टेंसी लेवल के बारे में जानकारी देखें.
Cassandra, उपलब्ध मेमोरी के हिसाब से अपने Java हीप साइज़ को अपने-आप अडजस्ट कर लेता है. ज़्यादा जानकारी के लिए, परफ़ॉर्मेंस में गिरावट आने या मेमोरी का ज़्यादा इस्तेमाल होने पर, Java रिसॉर्स को ट्यून करना देखें.
'Edge for Private Cloud' इंस्टॉल करने के बाद, /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
सिस्टम की सीमाएं
पक्का करें कि आपने 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
- मैसेज प्रोसेसर नोड पर,
/etc/security/limits.d/90-apigee-edge-limits.conf
में खुले फ़ाइल डिस्क्रिप्टर की ज़्यादा से ज़्यादा संख्या 64K पर सेट करें, जैसा कि नीचे दिखाया गया है:apigee soft nofile 32768 apigee hard nofile 65536
ज़रूरत पड़ने पर, यह सीमा बढ़ाई जा सकती है. उदाहरण के लिए, अगर आपके पास कुछ समय के लिए सेव की गई बहुत ज़्यादा फ़ाइलें एक ही समय पर खोली जाती हैं.
नेटवर्क सिक्योरिटी सर्विस (एनएसएस)
नेटवर्क सिक्योरिटी सर्विसेज़ (एनएसएस), लाइब्रेरी का एक ऐसा सेट है जो सुरक्षा की सुविधा वाले क्लाइंट और सर्वर ऐप्लिकेशन के डेवलपमेंट में मदद करता है. आपको यह पक्का करना चाहिए कि आपने 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
RedHat/CentOS 7 के लिए, Google Cloud Platform पर IPv6 बंद करें
अगर Google Cloud Platform पर RedHat 7 या CentOS 7 पर Edge इंस्टॉल किया जा रहा है, तो आपको सभी Qpid नोड पर IPv6 को बंद करना होगा.
IPv6 को बंद करने के निर्देशों के लिए, अपने खास ओएस वर्शन का RedHat या CentOS दस्तावेज़ देखें. उदाहरण के लिए, आपके पास ये काम करने की सुविधा होती है:
/etc/hosts
को किसी एडिटर में खोलें.- टिप्पणी करने के लिए, नीचे दी गई लाइन में से एक के कॉलम में "#" वर्ण डालें:
#::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
- फ़ाइल सेव करें.
एडब्ल्यूएस एएमआई
अगर आप 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 |
आरपीएम |
unzip |
basename |
grep |
लुआ-सॉकेट |
rpm2cpio |
उपयोगकर्ता जोड़ें |
बैश |
hostname |
ls |
sed |
wc |
bc |
id |
net-tools |
sudo |
Wget |
curl |
लिबायो |
पर्ल (procps से) |
टार |
ज़ेर्स-सी |
सायरस-ससल | libdb4 | pgrep (procps से) | tr | लज़ीज़ |
date |
libdb-cxx |
ps |
uuid |
chkconfig |
dirname | लिरिब्वर्ब | pwd | Uname | |
echo | लिबरमैक | python |
एनटीपीडी
Apigee का सुझाव है कि आपके सर्वर का समय सिंक हो. अगर इसे पहले से कॉन्फ़िगर नहीं किया गया है, तो ntpdate
यूटिलिटी इस काम को पूरा कर सकती है. इससे यह पुष्टि की जाती है कि सर्वर को टाइम सिंक किया गया है या नहीं. इस सुविधा को इंस्टॉल करने के लिए, yum install ntp
का इस्तेमाल
किया जा सकता है. यह खास तौर पर, OpenLDAP के सेटअप को दोहराने के लिए फ़ायदेमंद होता है. ध्यान दें कि आपने सर्वर
का टाइम ज़ोन यूटीसी में सेट अप किया हो.
Openldap 2.4
कंपनी की इमारत में इंस्टॉल करने के लिए, OpenLDAP 2.4 ज़रूरी है. अगर आपके सर्वर पर इंटरनेट कनेक्शन है,
तो Edge इंस्टॉल स्क्रिप्ट डाउनलोड करके OpenLDAP को इंस्टॉल करता है. अगर आपके सर्वर में इंटरनेट कनेक्शन नहीं है, तो Edge इंस्टॉल स्क्रिप्ट चलाने से पहले यह पक्का करें कि OpenLDAP पहले से इंस्टॉल है. RHEL/CentOS पर
yum install openldap-clients openldap-servers
चलाकर, OpenLDAP को इंस्टॉल किया जा सकता है.
13-होस्ट और दो डेटा सेंटर वाले 12 होस्ट के इंस्टॉलेशन के लिए, OpenLDAP को कॉपी करने की ज़रूरत होती है, क्योंकि OpenLDAP को होस्ट करने वाले कई नोड होते हैं.
फ़ायरवॉल और वर्चुअल होस्ट
आम तौर पर, आईटी एरिया में virtual
शब्द का इस्तेमाल बहुत ज़्यादा होता है. इसलिए, Apigee Edge का इस्तेमाल, प्राइवेट क्लाउड डिप्लॉयमेंट और वर्चुअल होस्ट के लिए किया जाता है. साफ़ तौर पर यह बताने के लिए, 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 ट्रैफ़िक को कनेक्ट करने की अनुमति भी ज़रूरी है.
Basepath तीसरा कॉम्पोनेंट है जो आपके इस्तेमाल किए गए अलग-अलग एपीआई प्रॉक्सी को
एपीआई कॉल को रूट करता है. अगर एपीआई प्रॉक्सी बंडल के अलग-अलग बेस पाथ हैं, तो वे एक एंडपॉइंट शेयर कर
सकते हैं. उदाहरण के लिए, एक बेस पाथ को http://api.mycompany.com:80/
और दूसरे को http://api.mycompany.com:80/salesdemo
के तौर पर बताया जा सकता है.
इस मामले में, आपको लोड बैलेंसर या ट्रैफ़िक डायरेक्टर की ज़रूरत होगी. यह डायरेक्टर दो आईपी पतों (VM1 पर 111.111.111.111
और VM2 पर 111.111.111.222
) के बीच http://api.mycompany.com:80/ ट्रैफ़िक को बांटता है. यह फ़ंक्शन खास तौर पर आपके इंस्टॉल करने के तरीके के हिसाब से होता है. साथ ही, इसे आपके लोकल नेटवर्किंग ग्रुप ने कॉन्फ़िगर किया होता है.
एपीआई डिप्लॉय करते समय, बेस पाथ सेट किया जाता है. ऊपर दिए गए उदाहरण में से, आपके पास 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/lice.txt.
इंस्टॉलर, लाइसेंस फ़ाइल को
/opt/apigee/customer/conf/license.txt
पर कॉपी करता है.
अगर लाइसेंस फ़ाइल मान्य है, तो मैनेजमेंट सर्वर समयसीमा खत्म होने और मैसेज
प्रोसेसर (MP) की अनुमति वाले मैसेज की संख्या की पुष्टि करता है. अगर किसी भी लाइसेंस सेटिंग की समयसीमा खत्म हो जाती है, तो लॉग इन जगहों पर देखे जा सकते हैं: /opt/apigee/var/log/edge-management-server/logs
.
ऐसे में, डेटा दूसरी जगह भेजने की जानकारी के लिए, Apigee Edge की सहायता टीम से संपर्क किया जा सकता है.
अगर आपके पास अब तक लाइसेंस नहीं है, तो Apigee Sales से संपर्क करें.