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