בדף הזה נסביר על זמינות גבוהה ועל הכלים שמומלץ להשתמש בהם. הכלים האלה תומכים גם בהגדרה של זמינות גבוהה לאשכולות שמופעלת בהם הצפנת נתונים שקופה (TDE).
מידע על החוסן (resilience) של הנתונים
אפשר לחשוב על עמידות הנתונים במונחים של זמינות, זמן לשחזור השירות ואובדן נתונים. הזמינות נמדדת בדרך כלל במונחים של זמן פעולה (uptime) ומבוטאת כאחוז הזמן שבו מסד הנתונים זמין. לדוגמה, כדי להשיג זמינות של 99.99%, מסד הנתונים לא יכול להיות מושבת למשך יותר מ-52.6 דקות בשנה, או 4.38 דקות בחודש. הזמן שנדרש לשחזור השירות אחרי הפסקה נקרא "יעד זמן ההתאוששות" (RTO). כמות הנתונים שאפשר לאבד בגלל הפסקה נקראת "יעד להתאוששות מאסון" (RPO), והיא מבוטאת כמשך הזמן שבו הטרנזקציות אבדו. לדוגמה, אם ה-RPO הוא 10 דקות, במקרה של תקלה אתם עלולים לאבד נתונים של עד 10 דקות.
מקובל להגדיר יעד זמינות, או יעד למדידת רמת השירות (SLO), יחד עם יעדים ל-RTO ול-RPO. לדוגמה, לעומס עבודה מסוים אתם יכולים להגדיר SLO של 99.99%, וגם לדרוש RPO של 0, ללא אובדן נתונים בכל כשל, ו-RTO של 30 שניות. לעומס עבודה אחר, יכול להיות שתגדירו את ה-SLO ל-99.9%, את ה-RPO ל-5 דקות ואת ה-RTO ל-10 דקות.
אפשר להטמיע חוסן בסיסי של מסד נתונים באמצעות גיבויים של מסד הנתונים. ב-AlloyDB Omni אפשר לגבות באמצעות pgBackRest, וגם להעביר לארכיון את קובצי יומן הכתיבה מראש (WAL) של מסד הנתונים כדי לצמצם את אובדן הנתונים. בגישה הזו, אם מסד הנתונים הראשי מושבת, אפשר לשחזר אותו מגיבוי עם RPO של דקות ו-RTO של דקות עד שעות, בהתאם לגודל של מסד הנתונים.
אם יש לכם דרישות מחמירות יותר לגבי RPO ו-RTO, אתם יכולים להגדיר את AlloyDB Omni בזמינות גבוהה באמצעות Patroni. בארכיטקטורה הזו יש מסד נתונים ראשי ושני מסדי נתונים משניים, או רפליקות. אתם יכולים להגדיר את AlloyDB Omni כך שישתמש בשכפול סטרימינג רגיל של PostgreSQL כדי לוודא שכל עסקה שמתבצעת בשרת הראשי משוכפלת באופן סינכרוני לשני מסדי הנתונים של הגיבוי. כך מתקבל RPO של אפס ו-RTO של פחות מ-60 שניות ברוב תרחישי הכשל.
בהתאם להגדרות האשכול, יכול להיות שרפליקציה סינכרונית תשפיע על זמן התגובה של הטרנזקציות, ואתם יכולים לבחור להסתכן באובדן של כמות קטנה של נתונים. לדוגמה, אתם יכולים להגדיר RPO שאינו אפס בתמורה לזמן אחזור נמוך יותר של טרנזקציות, על ידי הטמעת זמינות גבוהה עם רפליקציה אסינכרונית במקום סינכרונית. בגלל ההשפעה הפוטנציאלית של שכפול סינכרוני על זמן האחזור של טרנזקציות, ארכיטקטורות של זמינות גבוהה מיושמות כמעט תמיד במרכז נתונים אחד, או בין מרכזי נתונים קרובים (במרחק של עשרות קילומטרים או זמן אחזור של פחות מ-10 אלפיות השנייה). עם זאת, חשוב לציין שבמסמך הזה אנחנו משתמשים בשכפול סינכרוני כברירת מחדל.
לצורך תוכנית התאוששות מאסון (DR), שהיא הגנה מפני אובדן של מרכז נתונים או של אזור שבו יש כמה מרכזי נתונים קרובים זה לזה, אפשר להגדיר את AlloyDB Omni עם רפליקציה אסינכרונית בסטרימינג מהאזור הראשי לאזור משני, בדרך כלל במרחק של מאות או אלפי קילומטרים, או במרחק של עשרות עד מאות אלפיות השנייה. בהגדרה הזו, האזור הראשי מוגדר עם שכפול סינכרוני של נתונים בזמן אמת בין מסדי הנתונים הראשיים ומסדי הנתונים במצב המתנה באזור, ושכפול אסינכרוני של נתונים בזמן אמת מוגדר מהאזור הראשי לאזור משני אחד או יותר. אפשר להגדיר את AlloyDB Omni באזור המשני עם כמה צומתי מסד נתונים, כדי לוודא שהוא מוגן מיד אחרי מעבר לגיבוי בעת כשל מהאזור הראשי.
איך פועלת זמינות גבוהה
הטכניקות והכלים הספציפיים שמשמשים להטמעת זמינות גבוהה במסדי נתונים יכולים להשתנות בהתאם למערכת ניהול מסדי הנתונים. אלה כמה מהשיטות והכלים שמשמשים בדרך כלל להטמעת זמינות גבוהה במסדי נתונים, בהתאם למערכת לניהול מסדי נתונים:
יתירות: שכפול מסד הנתונים בכמה שרתים או אזורים גיאוגרפיים מספק אפשרויות ליתירות כשל אם המכונה הראשית מושבתת.
מעבר אוטומטי במקרה של כשל: מנגנון לזיהוי כשלים ומעבר חלק לרפליקה תקינה, כדי לצמצם את זמן ההשבתה. השאילתות מנותבות כך שהבקשות של האפליקציה יגיעו לצומת הראשי החדש.
המשכיות הנתונים: אמצעי הגנה מוטמעים כדי להגן על תקינות הנתונים במקרה של כשלים. זה כולל טכניקות שכפול ובדיקות עקביות של הנתונים.
אשכולות: אשכולות כוללים קיבוץ של כמה שרתי מסד נתונים כדי שיפעלו יחד כמערכת אחת. צומת ראשי מעבד תנועת קריאה-כתיבה, וצמתים במצב המתנה משכפלים נתונים באופן רציף כדי לספק יתירות כשל ולתמוך במדרגיות קריאה.
חזרה למצב הקודם: שיטות לחזרה לארכיטקטורה המקורית באמצעות הצמתים הראשיים והרפליקות שלפני יתירות הכשל, בקיבולת המקורית שלהם.
איזון עומסים: חלוקת בקשות למסד נתונים בין כמה מופעים משפרת את הביצועים ומאפשרת לטפל בעלייה בנפח התנועה.
מעקב והתראות: כלי מעקב מזהים בעיות כמו כשל בשרת, זמן אחזור ארוך, ניצול יתר של משאבים ומפעילים התראות או הליכי מעבר אוטומטי לגיבוי.
גיבוי ושחזור: אפשר להשתמש בגיבויים כדי לשחזר מסדי נתונים למצב קודם במקרה של פגיעה בנתונים או כשל קטסטרופלי.
מאגר חיבורים (אופציונלי): משפר את הביצועים ואת יכולת ההתאמה לעומס של אפליקציות שמקיימות אינטראקציה עם מסדי הנתונים.
כלים לזמינות גבוהה
Patroni הוא כלי בקוד פתוח לניהול אשכולות של מסדי נתונים ב-PostgreSQL, שנועד לנהל ולהפוך לאוטומטית את הזמינות הגבוהה של אשכולות PostgreSQL. Patroni משתמש במערכות שונות של קונצנזוס מבוזר, כמו etcd, Consul או Zookeeper, כדי לתאם ולנהל את מצב האשכול. חלק מהתכונות והרכיבים העיקריים של Patroni כוללים זמינות גבוהה עם יתירות כשל אוטומטית, בחירת שרת ראשי, רפליקציה ושחזור. Patroni פועל לצד שירות PostgreSQL במופעים של שרת מסד הנתונים, ומנהל את תקינותם, את המעבר לגיבוי כשל ואת השכפול שלהם כדי להבטיח זמינות ואמינות גבוהות.
Patroni משתמש במערכת מבוזרת להשגת הסכמה כדי לאחסן מטא-נתונים ולנהל את האשכול. במדריך הזה נשתמש בחנות תצורה מבוזרת (DCS) בשם etcd. אחד מהשימושים של etcd הוא לאחסן ולאחזר מידע על מערכות מבוזרות, כמו הגדרות, תקינות וסטטוס נוכחי, כדי להבטיח הגדרות עקביות בכל הצמתים.
High Availability Proxy (HAProxy) הוא תוכנה בקוד פתוח שמשמשת לאיזון עומסים ולניהול proxy של אפליקציות מבוססות TCP ו-HTTP. הוא משפר את הביצועים והאמינות של אפליקציות אינטרנט על ידי חלוקת התנועה ברשת בין כמה שרתים. בנוסף, HAProxy מבצע בדיקות תקינות כדי לשמור על מצב התקינות של שרתי בק-אנד שאליהם הוא מתחבר. אם שרת נכשל בבדיקת תקינות, HAProxy מפסיק לשלוח אליו תנועה עד שהוא עובר שוב את בדיקות התקינות.
שיקולים לגבי שכפול סינכרוני ואסינכרוני
באשכול PostgreSQL שמנוהל על ידי Patroni, אפשר להגדיר את הרפליקציה גם במצב סינכרוני וגם במצב אסינכרוני. כברירת מחדל, Patroni משתמש בשכפול אסינכרוני של נתונים בזמן אמת. אם יש לכם דרישות מחמירות לגבי RPO, מומלץ להשתמש ברפליקציה סינכרונית.
רפליקציה סינכרונית ב-PostgreSQL מבטיחה עקביות בנתונים על ידי המתנה לכתיבת טרנזקציות גם בשרת הראשי וגם בשרת המתנה סינכרוני אחד לפחות לפני ביצוע הטרנזקציה. רפליקציה סינכרונית מבטיחה שהנתונים לא יאבדו במקרה של כשל בשרת הראשי, ומספקת עמידות ועקביות גבוהות של הנתונים. השרת הראשי ממתין לאישורים מהשרת המשני הסינכרוני, מה שעלול להוביל לזמן אחזור ארוך יותר ולקצב העברת נתונים נמוך יותר בגלל זמן הלוך ושוב (RTT) הנוסף. זה יכול להפחית את קצב העברת הנתונים הכולל של המערכת, במיוחד בעומס גבוה.
שכפול אסינכרוני מאפשר לבצע טרנזקציות בצומת הראשי בלי לחכות לאישורים מצמתים במצב המתנה. השרת הראשי שולח רשומות WAL לשרתי הגיבוי, שמחילים אותן באופן אסינכרוני. הגישה האסינכרונית הזו מפחיתה את זמן האחזור של הכתיבה ומשפרת את הביצועים, אבל יש סיכון לאובדן נתונים אם השרת הראשי נכשל לפני שהשרת המשני מתעדכן. יכול להיות שהמערכות המשניות יהיו מאחורי המערכת הראשית, מה שיוביל לחוסר עקביות פוטנציאלי במהלך מעבר לגיבוי.
הבחירה בין שכפול סינכרוני לאסינכרוני באשכול Patroni תלויה בדרישות הספציפיות לעמידות, עקביות וביצועים של הנתונים. רפליקציה סינכרונית עדיפה בתרחישים שבהם תקינות הנתונים ואובדן נתונים מינימלי הם קריטיים, ורפליקציה אסינכרונית מתאימה לסביבות שבהן הביצועים וזמן אחזור נמוך יותר נמצאים בעדיפות גבוהה. אתם יכולים להגדיר פתרון משולב שכולל אשכול עם שלושה צמתים עם גיבוי סינכרוני באותו אזור אבל בתחום אחר או במרכז נתונים אחר בקרבת מקום, וגיבוי אסינכרוני שני באזור אחר או במרכז נתונים מרוחק יותר, כדי להגן על עצמכם מפני הפסקות חשמל אזוריות פוטנציאליות.