דרישות התקנה

דרישות חומרה

כדי ליצור תשתית עם זמינות גבוהה בסביבת ייצור, צריך לעמוד בדרישות החומרה המינימליות הבאות.

בסרטון הבא מפורטות הנחיות ברמה גבוהה לגבי הגודל של ההתקנה:

לכל תרחישי ההתקנה שמתוארים בטופולוגיות ההתקנה, בטבלאות הבאות מפורטות דרישות החומרה המינימליות לרכיבי ההתקנה.

בטבלאות האלה דרישות הדיסק הקשיח הן בנוסף לשטח הדיסק הקשיח שנדרש על ידי מערכת ההפעלה. בהתאם לאפליקציות ולתנועה ברשת, יכול להיות שההתקנה תדרוש יותר או פחות משאבים מאלה שמפורטים בהמשך.

רכיב ההתקנה RAM CPU נפח דיסק קשיח מינימלי
Cassandra 16GB 8 ליבות אחסון מקומי בנפח 250GB עם כונן SSD שתומך ב-2,000 IOPS
מעבד מעבד/נתב באות מכונה 16GB 8 ליבות 100GB
מעבד הודעות (עצמאי) 16GB 8 ליבות 100GB
נתב (עצמאי) 16GB 8 ליבות 100GB
Analytics – Postgres/Qpid באותו שרת 16GB‏* 8 ליבות* אחסון ברשת בנפח 500GB - 1TB*****, עדיף עם קצה עורפי SSD, עם תמיכה ב-1000 IOPS ומעלה*
Analytics – שרת ראשי או שרת זמין (standalone) של Postgres 16GB‏* 8 ליבות* אחסון ברשת בנפח 500GB - 1TB*****, עדיף עם קצה עורפי SSD, עם תמיכה ב-1000 IOPS ומעלה*
Analytics – Qpid עצמאי 8GB 4 ליבות אחסון מקומי בנפח 30GB עד 50GB עם SSD

גודל התור שמוגדר כברירת מחדל ב-Qpid הוא 1GB, ואפשר להגדיל אותו ל-2GB. אם צריך יותר קיבולת, מוסיפים צמתים נוספים של Qpid.

OpenLDAP/ממשק משתמש/שרת ניהול 8GB 4 ליבות 60GB
שרת UI/ניהול 4GB 2 ליבות 60GB
OpenLDAP (עצמאי) 4GB 2 ליבות 60GB

* התאמת דרישות המערכת של Postgres בהתאם לתפוקה:

  • פחות מ-250 TPS: 8GB, 4 ליבות עם אחסון מנוהל ברשת*** שתומך ב-1000 IOPS ומעלה
  • יותר מ-250 TPS: אחסון מנוהל ברשת בנפח 16GB עם 8 ליבות*** שתומך ב-1,000 IOPS ומעלה
  • יותר מ-1,000 TPS: 16GB, 8 ליבות, אחסון ברשת מנוהלת*** עם תמיכה ב-2000 IOPS ומעלה
  • יותר מ-2, 000 TPS: אחסון מנוהל ברשת בנפח 32GB עם 16 ליבות*** שתומך ב-2, 000 IOPS או יותר
  • יותר מ-4, 000 TPS: אחסון מנוהל ברשת בנפח 64GB עם 32 ליבות*** שתומך ב-4, 000 IOPS או יותר

** הערך של דיסק הקש של 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 of storage needed

*** מומלץ להשתמש ב-Network Storage למסד הנתונים של Postgresql כי:

  • היא מאפשרת להגדיל באופן דינמי את נפח האחסון לפי הצורך.
  • אפשר לשנות את מספר ה-IOPS ברשת בזמן אמת ברוב המערכות המשניות של הסביבה, האחסון והרשתות של היום.
  • אפשר להפעיל קובצי snapshot ברמת האחסון כחלק מפתרון לגיבוי ולשחזור.

בנוסף, בהמשך מפורטות דרישות החומרה אם ברצונך להתקין את שירותי המונטיזציה (לא נתמכים בהתקנה של All-in-One):

רכיב עם מונטיזציה RAM CPU דיסק קשיח
שרת ניהול (עם שירותי מונטיזציה) 8GB 4 ליבות 60GB
Analytics –‏ Postgres/Qpid באותו שרת 16GB 8 ליבות אחסון ברשת בנפח 500GB - 1TB, עדיף עם קצה עורפי של SSD, עם תמיכה ב-1000 IOPS ומעלה, או להשתמש בכלל שמופיע בטבלה שלמעלה.
Analytics – העברות ראשיות או זמניות במצב המתנה בנפרד 16GB 8 ליבות אחסון ברשת בנפח 500GB - 1TB, עדיף עם קצה עורפי של SSD, עם תמיכה ב-1000 IOPS ומעלה, או להשתמש בכלל שמופיע בטבלה שלמעלה.
Analytics – Qpid עצמאי 8GB 4 ליבות אחסון מקומי בנפח 40GB עד 500GB עם כונן SSD או HDD מהיר

להתקנות של יותר מ-250 בקשות לשנייה, מומלץ להשתמש בדיסק קשיח עם אחסון מקומי שתומך ב-1,000 פעולות קלט/פלט לשנייה (IOPS).

דרישות מערכת הפעלה ותוכנות צד שלישי

הוראות ההתקנה האלה וקבצי ההתקנה שסופקו נבדקו במערכות ההפעלה ובתוכנות של צד שלישי שמפורטות בקטע תוכנות נתמכות וגרסאות נתמכות.

Java

לפני ההתקנה, צריך להתקין בכל מכונה גרסה נתמכת של Java 1.8. מפתחות ה-JDK הנתמכים מפורטים במאמר תוכנות נתמכות וגרסאות נתמכות.

מוודאים שמשתנה הסביבה JAVA_HOME מפנה לשורש של ה-JDK של המשתמש שמבצע את ההתקנה.

SELinux

בהתאם להגדרות של SELinux, ייתכן ש-Edge ייתקל בבעיות בהתקנה ובהפעלה של רכיבי Edge. במקרה הצורך, אפשר להשבית את SELinux או להגדיר אותו למצב הרשאה במהלך ההתקנה, ואז להפעיל אותו מחדש אחרי ההתקנה. מידע נוסף זמין במאמר התקנה של הכלי apigee-setup ב-Edge.

יצירת המשתמש ב-apigee

תהליך ההתקנה יוצר משתמש מערכת ב-Unix בשם 'apigee'. הספריות והקבצים של Edge הם בבעלות apigee, וכך גם התהליכים של Edge. כלומר, רכיבי Edge יפעלו בתור משתמש 'apigee'. אם יש צורך, אפשר להריץ רכיבים בתור משתמש אחר.

ספריית ההתקנה

כברירת מחדל, מנהל ההתקנה כותב את כל הקבצים בספרייה /opt/apigee. אי אפשר לשנות את המיקום של הספרייה הזו. אי אפשר לשנות את הספרייה הזו, אבל אפשר ליצור קישור לספרייה אחרת כדי למפות את /opt/apigee למיקום אחר, כפי שמתואר בקטע יצירת קישור לספרייה אחרת מ-/opt/apigee.

בהוראות במדריך הזה, ספריית ההתקנה מסומנת בתור /opt/apigee.

לפני שיוצרים את הקישור הלא ישיר, צריך ליצור משתמש וקבוצה בשם apigee. זוהי אותה קבוצה והאותו משתמש שנוצרו על ידי מנהל ההתקנה של Edge.

כדי ליצור את הקישור הסימבולי, צריך לבצע את השלבים הבאים לפני שמורידים את הקובץ shoestrap_4.52.00.sh. צריך לבצע את כל השלבים האלה כמשתמשים עם הרשאת root:

  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. משנים את הבעלות על ה-root של ההתקנה ועל הקישור הלא ישיר למשתמש 'apigee':
    chown -h apigee:apigee /srv/myInstallDir /opt/apigee

הגדרת רשת

מומלץ לבדוק את הגדרות הרשת לפני ההתקנה. תוכנת ההתקנה מצפה שלכל המכונות יהיו כתובות IP קבועות. משתמשים בפקודות הבאות כדי לאמת את ההגדרה:

  • hostname מחזיר את שם המכונה
  • הפונקציה hostname -i מחזירה את כתובת ה-IP של שם המארח שאפשר לשלוח אליו הודעות ממכונות אחרות.

בהתאם לסוג ולגרסה של מערכת ההפעלה, יכול להיות שתצטרכו לערוך את /etc/hosts ו-/etc/sysconfig/network אם שם המארח לא מוגדר בצורה נכונה. לקבלת מידע נוסף, אפשר לעיין בתיעוד של מערכת ההפעלה הספציפית.

אם לשרת יש כמה כרטיסי ממשק, הפקודה hostname -i מחזירה רשימה של כתובות IP מופרדות בפסיקים. כברירת מחדל, מנהל ההתקנה של Edge משתמש בכתובת ה-IP הראשונה שמוחזרת, שאולי לא תהיה נכונה בכל המצבים. לחלופין, אפשר להגדיר את המאפיין הבא בקובץ התצורה של ההתקנה:

ENABLE_DYNAMIC_HOSTIP=y

כשהמאפיין מוגדר ל-'y', במהלך ההתקנה תופיע בקשה לבחור את כתובת ה-IP שבה רוצים להשתמש. ערך ברירת המחדל הוא 'n'. מידע נוסף זמין בחומר העזר בנושא קובץ תצורת קצה.

חבילות TCP

חבילות TCP Wrappers יכולות לחסום תקשורת של יציאות מסוימות, ויכולות להשפיע על התקנת OpenLDAP, ‏ Postgres ו-Cassandra. בצמתים האלה, בודקים את /etc/hosts.allow ו-/etc/hosts.deny כדי לוודא שאין הגבלות על יציאות OpenLDAP,‏ Postgres ו-Cassandra הנדרשות.

iptables

מוודאים שאין כללי מדיניות של iptables שמונעים קישוריות בין צמתים ביציאות Edge הנדרשות. במקרה הצורך, אפשר לעצור את טבלאות ה-IP במהלך ההתקנה באמצעות הפקודה:

sudo/etc/init.d/iptables stop

ב-CentOS 7.x:

systemctl stop firewalld

גישה לספרייה

בטבלה הבאה מפורטים ספריות בצמתים של Edge שיש להן דרישות מיוחדות מתהליכי Edge:

שירות ספרייה תיאור
נתב /etc/rc.d/init.d/functions

Edge Router משתמש בנתב Nginx ודורש הרשאת קריאה ל-/etc/rc.d/init.d/functions.

אם תהליך האבטחה שלכם מחייב להגדיר הרשאות ב-/etc/rc.d/init.d/functions, אל תגדירו אותן לערך 700, אחרת הנתב לא יופעל.

אפשר להגדיר את ההרשאות ל-744 כדי לאפשר גישה לקריאה ל-/etc/rc.d/init.d/functions.

שומר גן חיות /dev/random ספריית הלקוח שלzokeeper דורשת גישת קריאה למחולל המספרים האקראיים /dev/random. אם האפליקציה /dev/random חסומה בזמן הקריאה, יכול להיות שלא תהיה אפשרות להפעיל את שירות גן החיות.

קסנדרה

כל הצמתים של Cassandra חייבים להיות מחוברים לטבעת. Cassandra שומרת רפליקות של נתונים במספר צמתים כדי להבטיח אמינות ועמידות בכשלים. אסטרטגיית הרפליקציה לכל מרחב מפתחות של Edge קובעת את צומתי 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 בהתאם לכמות ה-RAM שזמינה במערכת:

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 ושל Message Processor:

  • בצמתים של Cassandra, מגדירים את המגבלות הרכות והקשות של memlock, ‏ nofile ו-address space (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
  • בצמתים של Message Processor, מגדירים את המספר המקסימלי של מתארי קבצים פתוחים ל-64K ב-/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 Support כדי לפתור את הבעיה.

Network Security Services‏ (NSS)

Network Security Services‏ (NSS) היא קבוצה של ספריות שתומכות בפיתוח של אפליקציות לקוח ושרת עם אבטחה מובנית. עליכם לוודא שהתקנתם את NSS גרסה 3.19 ואילך.

כדי לבדוק את הגרסה הנוכחית:

yum info nss

כדי לעדכן את NSS:

yum update nss

מידע נוסף זמין במאמר הזה של RedHat.

השבתת חיפוש DNS ב-IPv6 כשמשתמשים ב-NSCD (Name Service Cache Daemon)

אם התקנתם והפעלתם את NSCD‏ (Name Service Cache Daemon), מעבדי ההודעות מבצעים שתי בדיקות DNS: אחת ל-IPv4 ואחת ל-IPv6. כשמשתמשים ב-NSCD, צריך להשבית את בדיקת ה-DNS ב-IPv6.

כדי להשבית את חיפוש ה-DNS ב-IPv6:

  1. בכל צומת של Message Processor, עורכים את /etc/nscd.conf
  2. מגדירים את המאפיין הבא:
    enable-cache hosts no

השבתת IPv6 ב-Google Cloud Platform עבור RedHat/CentOS 7

אם מתקינים את Edge ב-RedHat 7 או ב-CentOS 7 ב-Google Cloud Platform, צריך להשבית את IPv6 בכל צמתים של Qpid.

להוראות להשבתת IPv6, אפשר לעיין במסמכי התיעוד של RedHat או CentOS לגרסה הספציפית של מערכת ההפעלה. לדוגמה, אפשר:

  1. פתיחת /etc/hosts בעורך.
  2. כדי להוסיף הערה לשורה הבאה, מוסיפים את התו # בעמודה הראשונה:
    #::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
  3. שומרים את הקובץ.

AWS AMI

אם מתקינים את Edge ב-AWS Amazon Machine Image‏ (AMI) עבור Red Hat Enterprise Linux 7.x, קודם צריך להריץ את הפקודה הבאה:

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

כלים

תוכנת ההתקנה משתמשת בכלי ה-UNIX הבאים בגרסה הרגילה שסופקו על ידי EL5 או EL6.

awk

expr

libxslt

RPM

לחלץ את הקובץ

basename

grep

lua-socket

rpm2cpio

useradd

bash

hostname

ls

sed

wc

bc

id [מזהה]

net-tools

sudo

wget

curl

ליביו

perl (מ-procps)

זפת

xerces-c

cyrus-sasl libdb4 pgrep (מ-procps) tr טעים

תאריך

libdb-cxx

ps

Uuid

chkconfig

dirname libibverbs pwd uname  
echo librdmacm python    

ntpdate

מומלץ ב-Apigee שהשעון של השרתים יהיה מסונכרן. אם עדיין לא הגדרתם את האפשרות הזו, תוכלו להשתמש בכלי ntpdate כדי לוודא שהשעון של השרתים מסונכרן. אפשר להשתמש ב-yum install ntp כדי להתקין את השירות. האפשרות הזו שימושית במיוחד ליצירת רפליקה של הגדרות OpenLDAP. שימו לב שהגדרתם את אזור הזמן של השרת לפי שעון UTC.

Openldap 2.4

כדי להתקין את השירות בארגון נדרש OpenLDAP 2.4. אם לשרת יש חיבור לאינטרנט, סקריפט ההתקנה של Edge מוריד ומתקין את OpenLDAP. אם אין לשרת חיבור לאינטרנט, צריך לוודא ש-OpenLDAP כבר מותקן לפני שמריצים את סקריפט ההתקנה של Edge. ב-RHEL/CentOS, אפשר להריץ את הפקודה yum install openldap-clients openldap-servers כדי להתקין את OpenLDAP.

בהתקנות עם 13 מארחים ובהתקנות עם 12 מארחים ושני מרכזי נתונים, יש צורך ברפליקציה של OpenLDAP כי יש כמה צמתים שמארחים את OpenLDAP.

חומות אש ומארחים וירטואליים

המונח virtual נתון לעומס יתר בתחום ה-IT, וכך גם לגבי פריסה של Apigee Edge לענן פרטי ומארחים וירטואליים. לשם הבהרה, יש שני שימושים עיקריים למונח virtual:

  • מכונות וירטואליות (VM): לא חובה, אבל בחלק מהפריסות נעשה שימוש בטכנולוגיית VM כדי ליצור שרתים מבודדים לרכיבי Apigee. למארחי מכונות וירטואליות, כמו מארחים פיזיים, יכולים להיות ממשקי רשת וחומות אש.
  • מארחים וירטואליים: נקודות קצה באינטרנט, בדומה למארח וירטואלי של Apache.

נתב במכונה וירטואלית יכול לחשוף כמה מארחים וירטואליים (כל עוד הם שונים זה מזה בשם החלופי של המארח או ביציאת הממשק שלהם).

דוגמה למתן שמות, יכול להיות שבשרת פיזי אחד A מריצים שתי מכונות וירטואליות, שנקראות VM1 ו-VM2. נניח ש-"VM1" חושף ממשק אתרנט וירטואלי בשם 'eth0' בתוך המכונה הווירטואלית, וכתובת ה-IP שלו מוקצית 111.111.111.111 על ידי מכונות הווירטואליות או שרת DHCP של הרשת. לאחר מכן נצא מנקודת הנחה ש-VM2 חושפת ממשק אתרנט וירטואלי שנקרא גם 'eth0' ושמוקצית לו כתובת ה-IP 111.111.111.222.

יכול להיות שנפעיל נתב Apigee בכל אחת משתי המכונות הווירטואליות. הנתב חושף נקודות קצה של המארח הווירטואלי, כמו בדוגמה הזו:

הנתב של Apigee ב-VM1 חושף שלושה מארחים וירטואליים בממשק eth0 שלו (שיש לו כתובת IP ספציפית כלשהי), api.mycompany.com:80,‏ api.mycompany.com:443 ו-test.mycompany.com:80.

הנתב ב-VM2 חושף את api.mycompany.com:80 (אותו שם ואותה יציאה כמו שמוחשפים ב-VM1).

יכול להיות שמערכת ההפעלה של המארח הפיזי כוללת חומת אש ברשת. במקרה כזה, צריך להגדיר את חומת האש כך שתאפשר מעבר של תעבורת TCP שמקושרת ליציאות שנחשפות בממשקים הווירטואליים (111.111.111.111:{80, 443} ו-111.111.111.222:80). בנוסף, יכול להיות שמערכת ההפעלה של כל מכונה וירטואלית תספק חומת אש משלה בממשק eth0, וגם חומות האש האלה צריכות לאפשר חיבור של תעבורת נתונים ביציאות 80 ו-443.

נתיב הבסיס הוא הרכיב השלישי שמעורב בחיבור קריאות ל-API לשרתים שונים של proxy ל-API, שאולי פרסתם. חבילות שרת proxy ל-API יכולות לשתף נקודת קצה אם יש להן נתיבי בסיס שונים. לדוגמה, אפשר להגדיר נתיב בסיס אחד בתור http://api.mycompany.com:80/ נתיב בסיס אחר בתור http://api.mycompany.com:80/salesdemo.

במקרה כזה, תצטרכו מאזן עומסים או מנהל תעבורת נתונים, שיפוצלו את תעבורת הנתונים http://api.mycompany.com:80/ בין שתי כתובות ה-IP (111.111.111.111 ב-VM1 ו-111.111.111.222 ב-VM2). הפונקציה הזו ספציפית להתקנה הספציפית שלכם, והיא מוגדרת על ידי קבוצת הרשתות המקומית.

הנתיב הבסיסי מוגדר כשפורסים API. לפי הדוגמה שלמעלה, אפשר לפרוס שני ממשקי API,‏ mycompany ו-testmycompany, לארגון mycompany-org באמצעות המארח הווירטואלי עם הכינוי api.mycompany.com והיציאה 80. אם לא מגדירים נתיב בסיס בפריסה, הנתב לא יודע לאיזה API לשלוח את הבקשות הנכנסות.

עם זאת, אם פורסים את ה-API testmycompany עם כתובת ה-URL הבסיסית /salesdemo, המשתמשים ניגשים ל-API הזה באמצעות http://api.mycompany.com:80/salesdemo. אם פורסים את ה-API mycompany עם כתובת ה-URL הבסיסית /, המשתמשים יגיעו ל-API דרך כתובת ה-URL http://api.mycompany.com:80/.

רישוי

לכל התקנה של Edge נדרש קובץ רישיון ייחודי שמקבלים מ-Apigee. תצטרכו לציין את הנתיב לקובץ הרישיון בזמן התקנת שרת הניהול, לדוגמה ‎/tmp/license.txt.

מנהל ההתקנה מעתיק את קובץ הרישיון אל /opt/apigee/customer/conf/license.txt.

אם קובץ הרישיון תקין, שרת הניהול מאמת את התוקף ואת מספר מעבדי ההודעות (MP) המותרים. אם תוקף ההגדרות של הרישיון פג, היומנים נמצאים במיקום הבא: /opt/apigee/var/log/edge-management-server/logs. במקרה כזה, אפשר לפנות אל התמיכה של Apigee Edge לקבלת פרטי ההעברה.

אם עדיין אין לכם רישיון, פנו אל מחלקת המכירות של Apigee.