זמינות גבוהה וחוסן נתונים

בחירת גרסה של מאמר העזרה:

בדף הזה נסביר על זמינות גבוהה ועל הכלים שמומלץ להשתמש בהם.

מה עלול לקרות לנתונים

אפשר לחשוב על עמידות הנתונים במונחים של זמינות, זמן לשחזור השירות ואובדן נתונים. בדרך כלל מודדים את הזמינות לפי זמן הפעולה התקינה, והיא מבוטאת באחוזים מהזמן שבו מסד הנתונים זמין. לדוגמה, כדי להשיג זמינות של 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) הוא תוכנה בקוד פתוח שמשמשת לאיזון עומסים ולפרוקסי של אפליקציות מבוססות TCP ו-HTTP. היא משמשת לשיפור הביצועים והאמינות של אפליקציות אינטרנט על ידי חלוקת בקשות נכנסות בין כמה שרתים. ‫HAProxy מאזן עומסים על ידי פיזור התנועה ברשת בין כמה שרתים. ‫HAProxy גם מבצע בדיקות תקינות כדי לשמור על מצב התקינות של שרתי בק-אנד שהוא מתחבר אליהם. אם שרת נכשל בבדיקת תקינות, HAProxy מפסיק לשלוח אליו תנועה עד שהוא עובר שוב את בדיקות התקינות.

שיקולים לגבי שכפול סינכרוני ואסינכרוני

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

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

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

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

המאמרים הבאים