בקטע הזה מפורטות השיטות המומלצות וההמלצות שלנו לשימוש ב-OPDK עם AWS Cloud.
Cassandra משמשת כ-backend וכמאגר נתונים כמעט לכל כללי המדיניות, והיא חלק קריטי מסביבת זמן הריצה של Apigee Edge. המסמך הזה מתמקד באופטימיזציה של Cassandra לסביבת AWS.
דרישות אחסון וקלט/פלט
רוב פעולות הקלט/פלט של Cassandra הן סדרתיות, אבל יש מקרים שבהם נדרש קלט/פלט אקראי. לדוגמה, כשקוראים טבלאות של מחרוזות ממוינות במהלך פעולות קריאה. מומלץ להשתמש ב-SSD כמנגנון האחסון של Cassandra, כי הוא מספק זמני תגובה עם זמן אחזור קצר מאוד לפעולות קריאה אקראיות, וביצועי כתיבה רציפים מספיקים לפעולות דחיסה. גם כאן, הרפליקציה נלקחת בחשבון.
הרבה מכונות ב-AWS EC2 מגיעות עם אחסון מקומי שבו הכונן הקשיח מחובר פיזית לחומרה שבה המכונה של EC2 מתארחת. ב-Apigee מומלץ להשתמש גם ב-SSD וגם במאגרי מכונות כשמריצים את Cassandra בסביבת הייצור. כשמשתמשים בסוג מכונה עם יותר מ-SSD אחד, אפשר להשתמש ב-RAID0 כדי לקבל יותר קיבולת אחסון וקצב העברת נתונים.
דרישות רשת
Cassandra משתמשת בפרוטוקול Gossip כדי להחליף מידע עם צמתים אחרים לגבי הטופולוגיה של הרשת. השימוש ב-Gossip והאופי המבוזר של Cassandra, שכולל תקשורת עם כמה צמתים לפעולות קריאה וכתיבה, גורמים להעברת נתונים רבים ברשת. מומלץ להשתמש בסוג מכונה עם רוחב פס של 1Gbps לפחות, ויותר מ-1Gbps למערכות ייצור.
משתמשים ב-VPC עם CIDR של /16. מכיוון שרשתות משנה ב-AWS לא יכולות להתפרס על יותר מאזור זמינות אחד, Apigee ממליצה על הפעולות הבאות:
- יוצרים רשת משנה אחת לכל אזור זמינות (AZ)
- משתמשים ב-3 רשתות משנה פרטיות להתקנה של Apigee, עם צומת Cassandra אחד בכל אזור זמינות. ב-3 תת-הרשתות צריכים להיות מספיק בלוקי CIDR כדי לאפשר הרחבה אופקית של אשכול Cassandra.
- מגדירים 3 תת-רשתות ציבוריות עם NAT ייעודי ל-Cassandra כדי לאפשר תקשורת עם האינטרנט להורדת תוכנות ועדכוני אבטחה.
בניגוד לארכיטקטורות מדור קודם של מאסטר-סלייב, לקסנדרה יש ארכיטקטורה ללא מאסטר שבה לכל הצמתים יש תפקיד זהה, כך שאין נקודת כשל בודדת. כדי לאפשר זמינות גבוהה, כדאי לפזר את צומתי Cassandra על פני כמה אזורי זמינות. אם תפזרו את הצמתים בין אזורי זמינות, תוכלו לשמור על הזמינות ועל זמן הפעולה התקינה במקרה של אסון.
בחירת משפחת מכונות
כשבוחנים את דרישות המעבד (CPU) של Cassandra, כדאי לשים לב שעומסי עבודה שכוללים הרבה הוספות מוגבלים על ידי המעבד ב-Cassandra לפני שהם מוגבלים על ידי קלט/פלט. במילים אחרות, כל פעולות הכתיבה עוברות ליומן ה-commit, אבל Cassandra כל כך יעילה בכתיבה, שהמעבד הופך לגורם המגביל. Cassandra היא מערכת עם רמת בו-זמניות גבוהה, והיא משתמשת בכמה שיותר ליבות מעבד (CPU) זמינות.
Apigee ממליצה להשתמש במשפחת מכונות שכוללת איזון בין מעבד (CPU) לזיכרון. באופן ספציפי, מומלץ להשתמש במכונות ממשפחת C5 אם הן זמינות באזור AWS שלכם, וב-C3 כאפשרות חלופית. במקרים מסוימים, 4xlarge הוא המכונה האופטימלית בשתי המשפחות שמספקת את המחיר/הביצועים הטובים ביותר.
ב-Apigee מומלץ גם להשתמש בדיירות שמוגדרת כברירת מחדל למכונות של Cassandra. כשמגדילים את מספר המכונות ליותר ממכונה אחת לכל אזור זמינות, סביר להניח שכל מכונות Cassandra ימוקמו באותה חומרה בסיסית אם מגדירים את הדיירות כייעודית. לכן, אם החומרה תיכשל, סביר להניח שתאבדו את כל המכונות באותו אזור זמינות.
סיכום ההמלצות
בטבלה הבאה מופיע סיכום של ההמלצות של Apigee לשימוש ב-AWS עם Apigee Edge for Private Cloud:
| משפחת המכונות | C5d (מועדף) או C3 |
| סוג המכונה | C(x).4xlarge |
| Instance Store | SSD (אחסון מקומי) עם RAID0 |
| סוג השכירות | ברירת מחדל |
| מיקום הצומת | צומת Cassandra אחד לכל אזור זמינות |
| VPC ורשת משנה | תת-רשת אחת לכל אזור זמינות ו-VPC לכל אזור |
מידע נוסף זמין במאמר סוגי מכונות של אמזון.