משפט CAP הוא אבן היסוד של תורת המערכות המבוזרות. כמובן, המחלוקת סביבו אינה שוככת: ההגדרות בו אינן קנוניות, ואין הוכחה קפדנית... עם זאת, בעמידה איתנה על עמדות השכל הישר היומיומי™, אנו מבינים אינטואיטיבית שהמשפט נכון.
הדבר היחיד שאינו מובן מאליו הוא המשמעות של האות "פ". כאשר האשכול מחולק, הוא מחליט אם לא להגיב עד הגעה למניין, או להחזיר את הנתונים הקיימים. בהתאם לתוצאות של בחירה זו, המערכת מסווגת כ-CP או כ-AP. קסנדרה, למשל, יכולה להתנהג בכל כיוון, תלוי אפילו לא בהגדרות האשכול, אלא בפרמטרים של כל בקשה ספציפית. אבל אם המערכת היא לא "P" והיא מתפצלת, אז מה?
התשובה לשאלה זו היא מעט בלתי צפויה: אשכול CA אינו יכול להתפצל.
איזה סוג של אשכול זה שלא יכול להתפצל?
תכונה הכרחית של אשכול כזה היא מערכת אחסון נתונים משותפת. ברוב המוחלט של המקרים, המשמעות היא חיבור דרך SAN, מה שמגביל את השימוש בפתרונות CA לארגונים גדולים המסוגלים לתחזק תשתית SAN. על מנת ששרתים מרובים יעבדו עם אותם נתונים, נדרשת מערכת קבצים מקובצת. מערכות קבצים כאלה זמינות בתיקי HPE (CFS), Veritas (VxCFS) ו-IBM (GPFS).
אורקל RAC
האפשרות Real Application Cluster הופיעה לראשונה בשנת 2001 עם שחרורו של Oracle 9i. באשכול כזה, מספר מופעי שרת עובדים עם אותו מסד נתונים.
אורקל יכולה לעבוד גם עם מערכת קבצים מקובצת וגם עם פתרון משלה - ASM, Automatic Storage Management.
כל עותק שומר יומן משלו. העסקה מבוצעת ומבוצעת על ידי מופע אחד. אם מופע נכשל, אחד מצמתי האשכולות (מופעים) ששרדו קורא את היומן שלו ומשחזר את הנתונים שאבדו - ובכך מבטיח זמינות.
כל המופעים שומרים על מטמון משלהם, ואותם עמודים (בלוקים) יכולים להיות במטמונים של מספר מופעים בו-זמנית. יתרה מכך, אם מופע אחד צריך עמוד והוא נמצא במטמון של מופע אחר, הוא יכול לקבל אותו מהשכן שלו באמצעות מנגנון היתוך המטמון במקום לקרוא מדיסק.
אבל מה קורה אם אחד המקרים צריך לשנות נתונים?
הייחודיות של אורקל היא שאין לה שירות נעילה ייעודי: אם השרת רוצה לנעול שורה, אז רשומת הנעילה ממוקמת ישירות בדף הזיכרון שבו נמצאת השורה הנעולה. הודות לגישה זו, אורקל היא אלופת הביצועים בין מסדי נתונים מונוליטיים: שירות הנעילה לעולם לא הופך לצוואר בקבוק. אבל בתצורת אשכול, ארכיטקטורה כזו יכולה להוביל לתעבורת רשת אינטנסיבית ולקיפאון.
ברגע שרשומה ננעלת, מופע מודיע לכל שאר המופעים שלדף המאחסן את הרשומה הזו יש החזקה בלעדית. אם מופע אחר צריך לשנות רשומה באותו עמוד, עליו להמתין עד לביצוע השינויים בעמוד, כלומר, מידע השינוי נכתב ליומן בדיסק (והעסקה יכולה להמשיך). יכול לקרות גם שעמוד ישתנה ברצף במספר עותקים, ואז בעת כתיבת הדף לדיסק תצטרך לברר מי מאחסן את הגרסה הנוכחית של דף זה.
עדכון אקראי של אותם דפים בצמתים שונים של RAC גורם לירידה דרמטית בביצועי מסד הנתונים, עד לנקודה שבה ביצועי האשכולות יכולים להיות נמוכים משל מופע בודד.
השימוש הנכון ב-Oracle RAC הוא חלוקה פיזית של הנתונים (לדוגמה, באמצעות מנגנון טבלה מחולקת) וגישה לכל סט של מחיצות דרך צומת ייעודי. המטרה העיקרית של RAC לא הייתה קנה מידה אופקי, אלא הבטחת סובלנות לתקלות.
אם צומת מפסיק להגיב לפעימות לב, אזי הצומת שזיהה אותו מתחיל הליך הצבעה בדיסק. אם הצומת החסר לא מצוין כאן, אז אחד הצמתים לוקח על עצמו את האחריות לשחזור נתונים:
- "מקפיא" את כל הדפים שהיו במטמון של הצומת החסר;
- קורא את היומנים (לעשות מחדש) של הצומת החסר ומחיל מחדש את השינויים שנרשמו ביומנים אלה, בו-זמנית בודק אם לצמתים אחרים יש גרסאות עדכניות יותר של הדפים המשתנים;
- מחזיר עסקאות ממתינות.
כדי לפשט את המעבר בין צמתים, לאורקל יש את הרעיון של שירות - מופע וירטואלי. מופע יכול לשרת שירותים מרובים, ושירות יכול לעבור בין צמתים. מופע אפליקציה המשרת חלק מסוים במסד הנתונים (לדוגמה, קבוצת לקוחות) עובד עם שירות אחד, והשירות האחראי על חלק זה של מסד הנתונים עובר לצומת אחר כאשר צומת נכשל.
IBM Pure Data Systems לעסקאות
פתרון אשכולות עבור DBMS הופיע בתיק ה- Blue Giant בשנת 2009. מבחינה אידיאולוגית, זהו יורשו של אשכול Sysplex המקביל, הבנוי על ציוד "רגיל". בשנת 2009, DB2 pureScale שוחרר כחבילת תוכנה, ובשנת 2012, IBM הציעה מכשיר בשם Pure Data Systems for Transactions. אין לבלבל את זה עם Pure Data Systems for Analytics, שהוא לא יותר מאשר Netezza ששמו שונה.
במבט ראשון, ארכיטקטורת pureScale דומה ל-Oracle RAC: באותו אופן, מספר צמתים מחוברים למערכת אחסון נתונים משותפת, וכל צומת מריץ מופע DBMS משלו עם אזורי זיכרון ויומני טרנזקציות משלו. אבל, בניגוד ל-Oracle, ל-DB2 יש שירות נעילה ייעודי המיוצג על ידי קבוצה של תהליכי db2LLM*. בתצורת אשכול, שירות זה ממוקם על צומת נפרד, הנקרא מתקן צימוד (CF) ב-Parallel Sysplex, ו-PowerHA ב-Pure Data.
PowerHA מספקת את השירותים הבאים:
- מנהל מנעול;
- מטמון מאגר גלובלי;
- תחום תקשורת בין-תהליכים.
כדי להעביר נתונים מ-PowerHA לצמתי מסד הנתונים ובחזרה, נעשה שימוש בגישה לזיכרון מרחוק, כך שהחיבור בין האשכולות חייב לתמוך בפרוטוקול RDMA. PureScale יכול להשתמש גם ב-Infiniband וגם ב-RDMA על Ethernet.
אם צומת צריך עמוד, והדף הזה לא נמצא במטמון, אז הצומת מבקש את הדף במטמון הגלובלי, ורק אם הוא לא שם, קורא אותו מהדיסק. שלא כמו אורקל, הבקשה עוברת רק ל-PowerHA, ולא לצמתים שכנים.
אם מופע עומד לשנות שורה, הוא נועל אותה במצב בלעדי, ואת הדף שבו השורה ממוקמת במצב משותף. כל המנעולים רשומים במנהל המנעולים העולמי. כאשר העסקה מסתיימת, הצומת שולח הודעה למנהל המנעולים, אשר מעתיק את הדף שהשתנה למטמון הגלובלי, משחרר את המנעולים ומבטל את תוקף העמוד ששונה במטמונים של צמתים אחרים.
אם העמוד שבו נמצאת השורה ששונתה כבר נעול, אזי מנהל המנעולים יקרא את העמוד שהשתנה מזיכרון הצומת שביצע את השינוי, ישחרר את המנעול, יבטל את תוקף העמוד ששונה במטמונים של צמתים אחרים, וכן תן את נעילת העמוד לצומת שביקש זאת.
"Dirty", כלומר, לשנות, דפים יכולים להיכתב לדיסק הן מצמת רגיל והן מ-PowerHA (castout).
אם אחד מצמתי pureScale נכשל, השחזור מוגבל רק לאותן טרנזקציות שעדיין לא הושלמו בזמן הכשל: הדפים ששונו על ידי אותו צומת בעסקאות שהושלמו נמצאים במטמון הגלובלי ב- PowerHA. הצומת מופעל מחדש בתצורה מופחתת באחד השרתים באשכול, מחזיר את העסקאות הממתינות ומשחרר מנעולים.
PowerHA פועל על שני שרתים והצומת הראשי משכפל את המצב שלו באופן סינכרוני. אם צומת PowerHA הראשי נכשל, האשכול ממשיך לפעול עם צומת הגיבוי.
כמובן, אם אתה ניגש למערך הנתונים דרך צומת בודד, הביצועים הכוללים של האשכול יהיו גבוהים יותר. PureScale יכול אפילו להבחין שאזור מסוים של נתונים מעובד על ידי צומת אחד, ואז כל המנעולים הקשורים לאזור זה יעובדו באופן מקומי על ידי הצומת מבלי לתקשר עם PowerHA. אבל ברגע שהאפליקציה תנסה לגשת לנתונים האלה דרך צומת אחר, עיבוד נעילה מרכזי יתחדש.
הבדיקות הפנימיות של IBM על עומס עבודה של 90% קריאה ו-10% כתיבה, שדומה מאוד לעומסי ייצור בעולם האמיתי, מציגות קנה מידה כמעט ליניארי עד ל-128 צמתים. תנאי הבדיקה, למרבה הצער, אינם נחשפים.
HPE NonStop SQL
לפורטפוליו של Hewlett-Packard Enterprise יש גם פלטפורמה זמינה משלו. זוהי פלטפורמת NonStop, שיצאה לשוק בשנת 1976 על ידי Tandem Computers. ב-1997 נרכשה החברה על ידי קומפאק, שבתורה התמזגה עם Hewlett-Packard ב-2002.
NonStop משמש לבניית אפליקציות קריטיות - למשל, HLR או עיבוד כרטיסי בנק. הפלטפורמה מועברת בצורה של קומפלקס תוכנה וחומרה (appliance), הכולל צמתי מחשוב, מערכת אחסון נתונים וציוד תקשורת. רשת ServerNet (במערכות מודרניות - Infiniband) משמשת הן להחלפה בין צמתים והן לגישה למערכת אחסון הנתונים.
גרסאות מוקדמות של המערכת השתמשו במעבדים קנייניים שהיו מסונכרנים זה עם זה: כל הפעולות בוצעו באופן סינכרוני על ידי מספר מעבדים, וברגע שאחד המעבדים ביצע שגיאה, הוא כבה, והשני המשיך לעבוד. מאוחר יותר, המערכת עברה למעבדים קונבנציונליים (תחילה MIPS, לאחר מכן Itanium ולבסוף x86), ומנגנונים נוספים החלו לשמש לסנכרון:
- הודעות: לכל תהליך מערכת יש תאום "צל", אליו התהליך הפעיל שולח מעת לעת הודעות על מצבו; אם התהליך הראשי נכשל, תהליך הצל מתחיל לעבוד מהרגע שנקבע על ידי ההודעה האחרונה;
- הצבעה: למערכת האחסון יש רכיב חומרה מיוחד המקבל מספר גישה זהה ומבצע אותן רק אם הגישה תואמת; במקום סנכרון פיזי, המעבדים פועלים באופן אסינכרוני, ותוצאות עבודתם מושוות רק ברגעי קלט/פלט.
מאז 1987, DBMS רלציוני פועל בפלטפורמת NonStop - תחילה SQL/MP, ולאחר מכן SQL/MX.
מסד הנתונים כולו מחולק לחלקים, וכל חלק אחראי על תהליך ה-Data Access Manager (DAM) משלו. הוא מספק מנגנוני רישום נתונים, מטמון ונעילה. עיבוד הנתונים מתבצע על ידי תהליכי שרת הביצוע הפועלים באותם צמתים כמו מנהלי הנתונים המתאימים. מתזמן ה-SQL/MX מחלק משימות בין המבצעים ומצבר את התוצאות. כאשר יש צורך לבצע שינויים מוסכמים, נעשה שימוש בפרוטוקול ההתחייבות הדו-שלבי המסופק על ידי ספריית TMF (Transaction Management Facility).
NonStop SQL יכול לתעדף תהליכים כך ששאילתות אנליטיות ארוכות לא יפריעו לביצוע העסקה. עם זאת, מטרתו היא בדיוק עיבוד עסקאות קצרות, ולא אנליטיקה. היזם מבטיח את זמינותו של אשכול ה-NonStop ברמה של חמש "תשע", כלומר, זמן השבתה הוא רק 5 דקות בשנה.
SAP-HANA
המהדורה היציבה הראשונה של HANA DBMS (1.0) התרחשה בנובמבר 2010, וחבילת SAP ERP עברה ל-HANA במאי 2013. הפלטפורמה מבוססת על טכנולוגיות שנרכשו: TREX Search Engine (חיפוש באחסון עמודים), P*TIME DBMS ו-MAX DB.
המילה "HANA" עצמה היא ראשי תיבות, High Performance Analytical Appliance. DBMS זה מסופק בצורה של קוד שיכול לפעול על כל שרתי x86, עם זאת, התקנות תעשייתיות מותרות רק על ציוד מוסמך. פתרונות זמינים מ-HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. חלק מתצורות לנובו אף מאפשרות פעולה ללא SAN - את התפקיד של מערכת אחסון נפוצה ממלא אשכול GPFS על דיסקים מקומיים.
שלא כמו הפלטפורמות המפורטות לעיל, HANA היא DBMS בזיכרון, כלומר תמונת הנתונים הראשית מאוחסנת ב-RAM, ורק יומנים ותמונות מצב תקופתיות נכתבות לדיסק לצורך התאוששות במקרה של אסון.
כל צומת אשכול HANA אחראי על החלק שלו בנתונים, ומפת הנתונים מאוחסנת ברכיב מיוחד - שרת שמות, הממוקם בצומת הרכז. נתונים אינם משוכפלים בין צמתים. מידע נעילה מאוחסן גם בכל צומת, אך למערכת יש גלאי נעילה גלובלית.
כאשר לקוח HANA מתחבר לאשכול, הוא מוריד את הטופולוגיה שלו ואז יכול לגשת ישירות לכל צומת, בהתאם לנתונים שהוא צריך. אם עסקה משפיעה על הנתונים של צומת בודד, אז היא יכולה להתבצע באופן מקומי על ידי אותו צומת, אבל אם הנתונים של מספר צמתים משתנים, הצומת היוזם יוצר קשר עם צומת המתאם, שפותח ומתאם את העסקה המבוזרת, ומבצע אותה באמצעות פרוטוקול התחייבות דו-פאזי אופטימלי.
צומת הרכז משוכפל, כך שאם הרכז נכשל, צומת הגיבוי משתלט מיד. אבל אם צומת עם נתונים נכשל, הדרך היחידה לגשת לנתונים שלו היא להפעיל מחדש את הצומת. ככלל, אשכולות HANA מתחזקים שרת רזרבי על מנת להפעיל מחדש צומת שאבד בו במהירות האפשרית.
מקור: www.habr.com