דרישות התקנה

Edge for Private Cloud גרסה 4.16.05

דרישות חומרה

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

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

בנוסף, אלה דרישות החומרה להתקנת שירותי המונטיזציה:

אם אתם רוצים להתקין את API BaaS, אלה דרישות החומרה:

הערה:

• אם מערכת הקבצים הבסיסית לא גדולה מספיק להתקנה, מומלץ להעביר את הנתונים לדיסק גדול יותר.
• אם במכונה הותקנה גרסה ישנה יותר של Apigee Edge for Private Cloud, צריך למחוק את התיקייה ‎/tmp/java לפני התקנה חדשה.
• כדי להפעיל את Cassandra, צריך לתת הרשאות הפעלה לתיקייה הזמנית ‎/tmp ברמת המערכת.
• אם המשתמש apigee נוצר לפני ההתקנה, צריך לוודא ש-‎/home/apigee קיים כספריית הבית והוא בבעלות apigee:apigee.

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

הוראות ההתקנה האלה וקובצי ההתקנה שסופקו נבדקו במערכות ההפעלה ובתוכנות הצד השלישי שמפורטות כאן: https://apigee.com/docs/api-services/reference/supported-software.

יצירת משתמש Apigee

תהליך ההתקנה יוצר משתמש במערכת Unix בשם apigee. הספריות והקבצים של Edge נמצאים בבעלות של apigee, וכך גם התהליכים של Edge. כלומר, רכיבי Edge פועלים כמשתמש apigee. אם צריך, אפשר להפעיל רכיבים כמשתמש אחר. דוגמה לכך מופיעה בקטע "Binding the Router to a protected port" במאמר Install Edge components on a node.

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

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

בהוראות שבמדריך הזה, ספריית ההתקנה מצוינת בתור ‎/<inst_root>/apigee, כאשר ‎/<inst_root> הוא ‎/opt כברירת מחדל.

Java

לפני ההתקנה, צריך להתקין גרסה נתמכת של Java1.8 בכל מכונה. רשימת ערכות ה-JDK הנתמכות:

https://apigee.com/docs/api-services/reference/supported-software

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

הגדרת רשת

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

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

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

Cassandra

כל הצמתים של Cassandra צריכים להיות מחוברים לטבעת.

‫Cassandra מתאימה באופן אוטומטי את גודל ה-Java heap בהתאם לזיכרון הזמין. מידע נוסף זמין במאמר כוונון משאבי Java. במקרה של פגיעה בביצועים או צריכת זיכרון גבוהה.

אחרי שמתקינים את Edge for Private Cloud, אפשר לבדוק אם Cassandra מוגדרת כמו שצריך. לשם כך, בודקים את הקובץ /<inst_root>/apigee/apigee-cassandra/conf/cassandra.yaml. לדוגמה, מוודאים שסקריפט ההתקנה של Edge for Private Cloud הגדיר את המאפיינים הבאים:

• cluster_name
• initial_token
• partitioner
• זרעים
• 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 /<inst_root>/apigee/customer/application/postgresql.properties
   
   אם הקובץ לא קיים, יוצרים אותו.
2. מגדירים את המאפיינים שמפורטים למעלה.
3. שומרים את השינויים.
4. מפעילים מחדש את מסד הנתונים של PostgreSQL:
   > ‎/<inst_root>/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

jsvc

"jsvc" הוא תנאי מוקדם לשימוש ב-API BaaS. גרסה 1.0.15-dev מותקנת כשמתקינים את API BaaS.

שירותי אבטחת רשת (NSS)

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

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

> yum info nss

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

> yum update nss

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

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.

הערה:

• קובץ ההפעלה של הכלי useradd נמצא ב-‎/usr/sbin ושל chkconfig ב-‎/sbin.
• עם גישת sudo, אתם יכולים לקבל גישה לסביבה של המשתמש שמבצע את הקריאה החוזרת. לדוגמה, בדרך כלל תבצעו קריאה חוזרת ל-"sudo <command>" או ל-"sudo PATH=$PATH:/usr/sbin:/sbin <command>".
• לפני שמתקינים חבילת שירות (תיקון), צריך לוודא שהכלי "תיקון" מותקן.

‫ntpdate – מומלץ לסנכרן את השעה בשרתים. אם הוא עדיין לא מוגדר, אפשר להשתמש בכלי 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.

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

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

• מכונות וירטואליות (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 יכולות לשתף נקודת קצה (endpoint) אם יש להן נתיבי בסיס שונים. לדוגמה, אפשר להגדיר נתיב בסיס אחד בתור 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)

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

בתמונה הבאה מוצגות דרישות היציאות לכל רכיב של Edge:

הערות לגבי התרשים:

• ‫*יציאה 8082 במעבד הבקשות צריכה להיות פתוחה לגישה על ידי הנתב רק כשמגדירים TLS/SSL בין הנתב לבין מעבד הבקשות. אם לא מגדירים TLS/SSL בין הנתב למעבד הבקשות, עדיין צריך לפתוח את יציאה 8082 (הגדרת ברירת המחדל) במעבד הבקשות כדי לנהל את הרכיב, אבל הנתב לא צריך גישה אליה.
• היציאות עם הקידומת "M" הן יציאות שמשמשות לניהול הרכיב, והן צריכות להיות פתוחות ברכיב כדי ששרת הניהול יוכל לגשת אליהן.
• הרכיבים הבאים דורשים גישה ליציאה 8080 בשרת הניהול: נתב, מעבד בקשות, ממשק משתמש, Postgres ו-Qpid.
• מעבד הבקשות צריך לפתוח את יציאה 4528 כיציאת הניהול שלו. אם יש לכם כמה מעבדי בקשות, כולם צריכים להיות מסוגלים לגשת זה לזה דרך יציאה 4528 (מסומנת בחץ הלולאה בתרשים שלמעלה ליציאה 4528 במעבד הבקשות). אם יש לכם כמה מרכזי נתונים, היציאה צריכה להיות נגישה מכל מעבדי הבקשות בכל מרכזי הנתונים.
• לא חובה, אבל אפשר לפתוח את יציאה 4527 בנתב כדי לאפשר גישה לכל מעבד בקשות. אחרת, יכול להיות שיופיעו הודעות שגיאה בקובצי היומן של מעבד הבקשות.
• הנתב צריך לפתוח את יציאה 4527 כיציאת הניהול שלו. אם יש לכם כמה נתבים, כולם צריכים להיות מסוגלים לגשת זה לזה דרך יציאה 4527 (מסומנת בחץ הלולאה בתרשים שלמעלה ליציאה 4527 בנתב).
• כדי לתמוך בלחצן Send בכלי המעקב, ממשק המשתמש של Edge צריך גישה לנתב ביציאות שנחשפות על ידי שרתי proxy ל-API.
• שרת הניהול צריך גישה ליציאת JMX בצומתי Cassandra.
• אפשר להגדיר את הגישה ליציאות JMX כך שתידרש הזנה של שם משתמש וסיסמה. מידע נוסף זמין במאמר איך עוקבים אחרי השימוש.
• אפשר גם להגדיר גישת TLS/SSL לחיבורים מסוימים, שיכולים להשתמש ביציאות שונות. מידע נוסף זמין במאמר TLS/SSL.
• אם מגדירים שני צומתי Postgres לשימוש בשכפול של מאסטר-המתנה, צריך לפתוח את יציאה 22 בכל צומת לגישת SSH. אפשר לפתוח יציאות בצמתים ספציפיים כדי לאפשר גישת SSH.
• אפשר להגדיר את שרת הניהול ואת ממשק המשתמש של Edge כך שישלחו אימיילים דרך שרת SMTP חיצוני. אם כן, צריך לוודא שלשרת הניהול ולממשק המשתמש יש גישה ליציאה הנדרשת בשרת ה-SMTP. ב-SMTP ללא TLS, מספר היציאה הוא בדרך כלל 25. ב-SMTP עם TLS, בדרך כלל מדובר ב-465, אבל כדאי לבדוק עם ספק ה-SMTP.

בטבלה הבאה מוצגות היציאות שצריך לפתוח בחומות האש, לפי רכיב Edge:

> curl -v http://<routerIP>:15999/v1/servers/self/reachable

בטבלה הבאה מוצגות אותן יציאות, לפי סדר מספרי, עם רכיבי המקור והיעד:

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

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

אם יש חומת אש בין הנתב למעבדי הבקשות, ומוגדר בה זמן קצוב לתפוגה של TCP במצב חוסר פעילות, מומלץ:

1. מגדירים את net.ipv4.tcp_keepalive_time = 1800 בהגדרות sysctl במערכת ההפעלה Linux, כאשר הערך 1800 צריך להיות נמוך יותר מזמן הקצוב לתפוגה של TCP במצב חוסר פעילות בחומת האש. ההגדרה הזו אמורה לשמור על החיבור במצב פעיל כדי שחומת האש לא תנתק אותו.
2. בכל מעבדי הבקשות, עורכים את /<inst_root>/apigee/customer/application/message-processor.properties כדי להוסיף את המאפיין הבא. אם הקובץ לא קיים, יוצרים אותו.
   conf_system_casssandra.maxconnecttimeinmillis=-1
3. מפעילים מחדש את מעבד הבקשות:
   > ‎/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
4. בכל הנתבים, עורכים את /<inst_root>/apigee/customer/application/router.properties כדי להוסיף את המאפיין הבא. אם הקובץ לא קיים, יוצרים אותו.
   conf_system_casssandra.maxconnecttimeinmillis=-1
5. מפעילים מחדש את הנתב:
   > ‎/opt/apigee/apigee-service/bin/apigee-service edge-router restart

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

דרישות היציאות של API BaaS

אם בוחרים להתקין את API BaaS, מוסיפים את הרכיבים API BaaS Stack ו-API BaaS Portal. הרכיבים האלה משתמשים ביציאות שמוצגות באיור הבא:

הערות לגבי התרשים:

• אפשר להקצות את צומתי Cassandra ל-API BaaS או לשתף אותם עם Edge.
• בהתקנה של API BaaS בסביבת ייצור, משתמשים במאזן עומסים בין הצומת של API BaaS Portal לבין הצמתים של API BaaS Stack. כשמגדירים את הפורטל וכשמבצעים קריאות ל-BaaS API, מציינים את כתובת ה-IP או את שם ה-DNS של מאזן העומסים, ולא של צומתי ה-Stack.
• צריך להגדיר את כל הצמתים של Baas Stack כך שישלחו אימיילים דרך שרת SMTP חיצוני. ב-SMTP ללא TLS, מספר היציאה הוא בדרך כלל 25. ב-SMTP עם TLS, בדרך כלל מדובר ביציאה 465, אבל כדאי לבדוק את זה עם ספק ה-SMTP.

בטבלה הבאה מוצגות היציאות שצריך לפתוח בחומות האש כברירת מחדל, לפי רכיב:

רישוי

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

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

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