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

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

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

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

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

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

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

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

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

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

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

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

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

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

ज़रूरी शर्त: EPEL रेपो चालू करें

इंस्टॉल करने से पहले, पक्का करें कि ईपीईएल (एंटरप्राइज़ Linux के लिए अतिरिक्त पैकेज) रिपॉज़िटरी चालू हो. इस्तेमाल किए जाने वाले निर्देश, Red Hat Enterprise Linux (RHEL), Rocky Linux या Oracle Linux के वर्शन पर निर्भर करते हैं:

• RHEL 8.x, Rocky Linux 8.x या Oracle Linux 8.x के लिए:

  wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm

  sudo rpm -ivh epel-release-latest-8.noarch.rpm

• RHEL 9.x, Rocky Linux 9.x या Oracle Linux 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 17 और Java 21 के काम करने वाले वर्शन इंस्टॉल करने होंगे. इस्तेमाल किए जा सकने वाले 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 के तौर पर नोट किया गया है.

/opt/apigee से सिमलिंक बनाना

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

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

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

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

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

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 नोड पर, सॉफ़्ट और हार्ड मेमलॉक, नोफ़ाइल, और ऐड्रेस स्पेस (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

• मैसेज प्रोसेसर नोड पर, /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

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

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

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

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

   enable-cache hosts no

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

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

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

Amazon Linux के लिए ज़रूरी शर्तें

Amazon Linux 2023.9/2023.10/2023.11 पर नया इंस्टॉल करने या 4.53.01 से 4.54.00 पर अपग्रेड करने से पहले, /etc/yum.repos.d/amazonlinux.repo फ़ाइल में बदलाव करें. [amazonlinux] वाले सेक्शन में ये चीज़ें शामिल होनी चाहिए, ताकि यह पक्का किया जा सके कि पैकेज apigee-thirdparty से डाउनलोड किए गए हैं, न कि Amazon से:exclude=postgresql18,luajit*.

टूल

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

समय सिंक करना

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

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

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 की सेल्स टीम से संपर्क करें.