Edge for Private Cloud גרסה 4.18.05
דרישות חומרה
עליכם לעמוד בדרישות החומרה המינימליות הבאות לתשתית עם זמינות גבוהה בסביבה ברמת ייצור.
הסרטון הבא מציג הנחיות כלליות לשינוי הגודל של ההתקנה:
לכל תרחישי ההתקנה שמתוארים בקטע טופולוגיות התקנה, בטבלאות הבאות מפורטות דרישות החומרה המינימליות לרכיבי ההתקנה.
בטבלאות האלה, הדרישות לדיסק הקשיח הן בנוסף לשטח בכונן הקשיח שנדרש על ידי מערכת ההפעלה. בהתאם לאפליקציות ולתנועה ברשת, ייתכן שלהתקנה יידרשו יותר או פחות משאבים ממה שמפורט בהמשך.
רכיבי התקנה | RAM | CPU | מספר מינימלי של דיסקים קשיחים |
---|---|---|---|
קסנדרה | 16GB | 8 ליבות | אחסון מקומי בנפח 250GB עם SSD או HDD מהיר שתומך ב-2,000 IOPS |
מעבד/נתב הודעות באותו מחשב | 16GB | 8 ליבות | 100GB |
Analytics - Postgres/Qpid באותו שרת | 16GB* | 8 ליבות* | 500GB - 1TB** אחסון ברשת***, עדיף עם SSD עורפי, עם תמיכה ב- 1000 IOPS ומעלה* |
Analytics – פוסטים עצמאיים | 16GB* | 8 ליבות* | 500GB - 1TB** אחסון ברשת***, עדיף עם SSD עורפי, עם תמיכה ב- 1000 IOPS ומעלה* |
Analytics – Qpid עצמאי | 8GB | 4 ליבות | 30GB - 50GB לאחסון מקומי עם SSD או HDD מהיר
בהתקנות עם קיבולת גדולה מ-250 TPS, מומלץ להשתמש ב-HDD עם אחסון מקומי שתומך ב-1,000 IOPS. גודל ברירת המחדל של תור Qpid הוא 20GB. כדי להגדיל את הקיבולת, צריך להוסיף עוד צומתי Qpid. |
אחר (OpenLDAP, ממשק משתמש, שרת ניהול) | 4GB | 2 ליבות | 60GB |
* שנו את דרישות המערכת של Postgres בהתאם לתפוקה:
- פחות מ-250 TPS: 8GB, 4 ליבות, שאפשר להשתמש בהם עם אחסון רשת מנוהל*** שתומך ב-1000 IOPS ומעלה
- יותר מ-250 TPS: אחסון מנוהל ברשת של 16GB, 8 ליבות*** עם תמיכה ב-1000 IOPS ומעלה
- יותר מ-1,000 TPS: 16GB, אחסון מנוהל ברשת עם 8 ליבות*** עם תמיכה ב-2,000 IOPS ואילך
- יותר מ-2,000 TPS: 32GB, 16 ליבות, אחסון רשת מנוהל*** עם תמיכה ב-2,000 IOPS ומעלה
- יותר מ-4,000 TPS: 64GB, אחסון עם 32 ליבות, אחסון רשת מנוהל*** עם תמיכה ב-4,000 IOPS ומעלה
** הערך של Postgres בדיסק הקשיח מבוסס על ניתוח נתונים מהקופסה שהוקלט על ידי Edge. אם מוסיפים ערכים מותאמים אישית לנתוני הניתוח, צריך להגדיל את הערכים האלה בהתאם. משתמשים בנוסחה הבאה כדי להעריך את נפח האחסון הנדרש:
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
*** Network Storage מומלץ למסד נתונים Postgresql מהסיבות הבאות:
- היא מאפשרת להרחיב את נפח האחסון באופן דינמי, אם וכאשר יש צורך בכך.
- אפשר להתאים בזמן אמת את ה-IOPS של הרשת ברוב מערכות המשנה של הסביבה/האחסון/הרשת.
- ניתן להפעיל תמונות מצב של רמת האחסון כחלק מפתרונות הגיבוי והשחזור.
בנוסף, ברשימה הבאה מפורטות דרישות החומרה אם ברצונך להתקין את שירותי המונטיזציה:
רכיב עם מונטיזציה | RAM | CPU | דיסק קשיח |
---|---|---|---|
שרת ניהול (עם שירותי מונטיזציה) | 8GB | 4 ליבות | 60GB |
Analytics - Postgres/Qpid באותו שרת | 16GB | 8 ליבות | אחסון ברשת בנפח 500GB – 1TB, עדיף עם קצה עורפי SSD, שתומך ב-1,000 IOPS או יותר, או שאפשר להשתמש בכלל שמפורט בטבלה שלמעלה. |
Analytics – פוסטים עצמאיים | 16GB | 8 ליבות | אחסון ברשת בנפח 500GB – 1TB, עדיף עם קצה עורפי SSD, שתומך ב-1,000 IOPS או יותר, או שאפשר להשתמש בכלל שמפורט בטבלה שלמעלה. |
Analytics – Qpid עצמאי | 8GB | 4 ליבות | 40GB - 500GB לאחסון מקומי עם SSD או HDD מהיר
בהתקנות עם קיבולת גדולה מ-250 TPS, מומלץ להשתמש ב-HDD עם אחסון מקומי שתומך ב-1,000 IOPS. |
דרישות לגבי מערכת ההפעלה ותוכנה של צד שלישי
הוראות ההתקנה הזו וקובצי ההתקנה שסופקו נבדקו במערכות ההפעלה ובתוכנות הצד השלישי שמופיעות ברשימת התוכנות הנתמכות והגרסאות הנתמכות.
יצירת המשתמש 'apigee'
תהליך ההתקנה יוצר משתמש מערכת Unix בשם 'apigee'. ספריות וקבצים של Edge הם בבעלות 'apigee', וכך גם תהליכי Edge. כלומר, רכיבי Edge פועלים בתור המשתמש 'apigee'. אם צריך, אפשר להריץ רכיבים כמשתמש אחר.
ספריית התקנה
כברירת מחדל, מנהל ההתקנה כותב את כל הקבצים בספרייה /opt/apigee
. לא ניתן לשנות את המיקום הזה של הספרייה. אי אפשר לשנות את הספרייה הזו, אבל אפשר ליצור קישור סמלי כדי למפות את /opt/apigee
למיקום אחר, כפי שמתואר במאמר יצירת קישור סמלי מ- /opt/apigee.
בהוראות שבמדריך הזה, ספריית ההתקנה רשומה בתור /opt/apigee
.
יצירת קישור סימבולי מ- /opt/apigee
לפני שיוצרים את הקישור הסמלי, צריך ליצור משתמש וקבוצה בשם "apigee". זוהי אותה הקבוצה והמשתמש שנוצרו על ידי מנהל ההתקנה של Edge.
כדי ליצור את הקישור הסמלי, יש לבצע את השלבים הבאים לפני שמורידים את הקובץ shoestrap_4.18.05.sh. צריך לבצע את כל השלבים הבאים בתור הרמה הבסיסית (root):
- יוצרים את המשתמש והקבוצה "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.
- שינוי הבעלות על בסיס ההתקנה ועל קישור סמלי למשתמש ה-API:
chown -h apigee:apigee /srv/myInstallDir /opt/apigee
Java
לפני ההתקנה, צריכה להיות מותקנת גרסה נתמכת של Java 1.8 בכל מחשב. מפתחות ה-JDK הנתמכים מפורטים בתוכנות הנתמכות ובגרסאות הנתמכות.
צריך לוודא שמשתנה הסביבה JAVA_HOME
מפנה לשורש של ה-JDK
אצל המשתמש שמבצע את ההתקנה.
SELinux
בהתאם להגדרות שקבעתם ל-SELinux, ייתכן ש-Edge עלולה להיתקל בבעיות בהתקנה ובהפעלה של רכיבי Edge. במקרה הצורך, אפשר להשבית את SELinux או להגדיר אותו למצב מתירני במהלך ההתקנה, ואז להפעיל אותו מחדש לאחר ההתקנה. למידע נוסף, אפשר לקרוא את המאמר על התקנת כלי ההתקנה של Edge apigee-setup.
הגדרת רשת
Apigee ממליץ לך לבדוק את הגדרת הרשת לפני ההתקנה. המתקין מצפה שלכל המכונות יש כתובות IP קבועות. כדי לבדוק את ההגדרה, יש להשתמש בפקודות הבאות:
- הפונקציה
hostname
מחזירה את שם המכונה hostname -i
מחזירה את כתובת ה-IP של שם המארח שאפשר להפנות אליו ממכונות אחרות.
בהתאם לסוג ולגרסה של מערכת ההפעלה, יכול להיות שיהיה צורך לערוך את
/etc/hosts
ואת /etc/sysconfig/network
אם שם המארח לא
מוגדר בצורה נכונה. למידע נוסף, עיינו בתיעוד של מערכת ההפעלה הספציפית שלכם.
אם לשרת יש כמה כרטיסי ממשק, הפקודה 'שם מארח -i' מחזירה רשימה של כתובות IP שמופרדות ברווחים. כברירת מחדל, מנהל ההתקנה של Edge משתמש בכתובת ה-IP הראשונה שמוחזרת, וייתכן שהיא לא תהיה נכונה בכל המצבים. לחלופין, אפשר להגדיר את המאפיין הבא בקובץ תצורת ההתקנה:
ENABLE_DYNAMIC_HOSTIP=y
כשהמאפיין הזה מוגדר ל-y, מנהל ההתקנה יבקש מכם לבחור את כתובת ה-IP שתשמש במסגרת ההתקנה. ערך ברירת המחדל הוא 'n'. מידע נוסף זמין בחומר העזר בנושא קובצי תצורת קצה.
קובצי wrapper של TCP
רכיבי TCP wrappers יכולים לחסום את התקשורת של יציאות מסוימות, והם יכולים להשפיע על ההתקנה של OpenLDAP, Postgres ו-Cassandra. בצמתים האלה, צריך לבדוק את /etc/hosts.allow
ואת /etc/hosts.deny
כדי לוודא שאין הגבלות על היציאות הנדרשות ב-OpenLDAP, ב-Postgres וב-Cassandra.
iptables, אייפטבל
בדיקה שאין מדיניות ל-IPtables שמונעת קישוריות בין צמתים ביציאות Edge הנדרשות. אם צריך, אפשר לעצור את ההפעלה של מכשירי iptable במהלך ההתקנה באמצעות הפקודה:
sudo/etc/init.d/iptables stop
ב-CentOS 7.x:
systemctl stop firewalld
בדיקה של נתב Edge יכול לגשת אל /etc/rc.d/init.d/functions
נתב Edge משתמש בנתב Nginx ודורש גישת קריאה ל-/etc/rc.d/init.d/functions
.
אם תהליך האבטחה דורש הגדרה של הרשאות
ב-/etc/rc.d/init.d/functions
, אין להגדיר אותן ל-700, אחרת הנתב לא יוכל
לפעול. אפשר להגדיר את ההרשאות ל-744 כדי לתת גישת קריאה אל
/etc/rc.d/init.d/functions
.
קסנדרה
כל צומתי Cassandra חייבים להיות מחוברים לטבעת. Cassandra מאחסנת רפליקות של נתונים במספר צמתים כדי להבטיח אמינות ועמידות בכשלים. אסטרטגיית הרפליקציה לכל מרחב מפתחות של Edge קובעת את צומתי Cassandra שבהם ימוקמו רפליקות. למידע נוסף, ראו מידע על גורם השכפול ורמת העקביות של Cassandra.
Cassandra מתאימה באופן אוטומטי את גודל הערימה של Java לפי הזיכרון הזמין. למידע נוסף, תוכלו לקרוא את המאמר כוונון משאבי Java במקרים של ירידה בביצועים או צריכת זיכרון גבוהה.
אחרי שמתקינים את Edge for Private Cloud, אפשר לבדוק אם Cassandra מוגדרת נכון, על ידי בדיקת הקובץ /opt/apigee/apigee-cassandra/conf/cassandra.yaml
. לדוגמה, צריך לוודא שהסקריפט להתקנה של Edge לענן הפרטי מגדיר את המאפיינים הבאים:
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
כדי להגדיר את הערכים האלה:
- עורכים את הקובץ postgresql.properties:
vi /opt/apigee/customer/application/postgresql.properties
אם הקובץ לא קיים, יוצרים אותו.
- מגדירים את המאפיינים שמפורטים למעלה.
- שומרים את השינויים.
- מפעילים מחדש את מסד הנתונים של PostgreSQL:
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart
מגבלות מערכת
חשוב לוודא שהגדרתם את מגבלות המערכת הבאות בצמתים של Cassandra ומעבדי ההודעות:
- בצומתי Cassandra, צריך להגדיר מגבלות רך וקשה, nofile ומרחב כתובות (כפי) עבור
משתמש ההתקנה (ברירת המחדל היא "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
- בצמתים של מעבדי הודעות, צריך להגדיר את המספר המקסימלי של מתארי הקובץ הפתוחים ל-64K
ב-
/etc/security/limits.d/90-apigee-edge-limits.conf
כפי שמוצג כאן:apigee soft nofile 32768 apigee hard nofile 65536
במקרה הצורך, תוכלו להגדיל את המגבלה. לדוגמה, אם יש מספר גדול של קבצים זמניים שפתוחים בו-זמנית.
שירותי אבטחת רשת (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. יש להשבית חיפוש DNS ב-IPv6 כשמשתמשים ב-NSCD.
כדי להשבית את חיפוש ה-DNS ב-IPv6:
- בכל צומת של מעבד ההודעות, יש לערוך את
/etc/nscd.conf
- מגדירים את המאפיין הבא:
enable-cache hosts no
השבתה של IPv6 ב-Google Cloud Platform ל-RedHat/CentOS 7
אם אתם מתקינים את Edge ב-RedHat 7 או את CentOS 7 ב-Google Cloud Platform, צריך להשבית את IPv6 בכל צומתי Qpid.
לקבלת הוראות להשבתת IPv6, אפשר לעיין בתיעוד של RedHat או CentOS לגבי הגרסה הספציפית של מערכת ההפעלה. תוכלו, לדוגמה:
- פתיחת
/etc/hosts
בעורך. - כדי להגיב לו, מוסיפים תו "#" בעמודה אחת בשורה הבאה:
#::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
- שומרים את הקובץ.
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 |
libxmlt |
RPM |
unzip |
basename |
grep |
Lua-Socket |
rpm2cpio |
הוספת משתמש |
באש |
hostname |
ls |
sed |
wc |
bc |
id |
net-tools |
sudo |
Wget |
curl |
Libaio |
perl (מ-procps) |
זפת |
xerces-c |
Crus-Sasl | libdb4 | PgRep (מ-procps) | tr | טעים |
date |
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): לא חובה לעשות זאת, אבל בחלק מהפריסות נעשה שימוש בטכנולוגיית מכונות וירטואליות כדי ליצור שרתים מבודדים לרכיבי Apigee שלהם. למארחי מכונות וירטואליות, כמו מארחים פיזיים, יכולים להיות ממשקי רשת וחומות אש.
- מארחים וירטואליים: נקודות קצה באינטרנט, בדומה למארח וירטואלי של Apache.
נתב במכונה וירטואלית יכול לחשוף כמה מארחים וירטואליים (כל עוד הם שונים זה מזה בכינוי המארח או ביציאת הממשק שלו).
הנה דוגמה לשמות, יכול להיות שבשרת פיזי יחיד A
פועלות שתי מכונות וירטואליות –
שנקראות VM1 ו-VM2. נניח ש-'VM1' חושף ממשק Ethernet וירטואלי שנקרא '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 Sales.