בדף הזה מתואר המושג 'זמינות גבוהה' והכלים שאנחנו ממליצים להשתמש בהם. הכלים האלה תומכים גם בהגדרת זמינות גבוהה (HA) עבור אשכולות שמופעלת בהם הצפנת נתונים שקופה (TDE).
מידע על חוסן הנתונים
אפשר לחשוב על עמידות הנתונים במונחים של זמינות, זמן לשחזור השירות ואובדן נתונים. הזמינות נמדדת בדרך כלל במונחים של זמן פעולה רציף (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, וגם בארכיון של קובצי Write Ahead Log (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 שומרת על מצב התקינות של שרתי הבק-אנד שאליהם היא מתחברת על ידי ביצוע בדיקות תקינות. אם שרת לא עובר בדיקת תקינות, HAProxy מפסיקה לשלוח אליו תנועה עד שהוא עובר שוב את בדיקות התקינות.
שיקולים לגבי שכפול סינכרוני ואסינכרוני
באשכול PostgreSQL שמנוהל על ידי Patroni, אפשר להגדיר שכפול במצב סינכרוני ובמצב אסינכרוני. כברירת מחדל, Patroni משתמש בשכפול אסינכרוני של נתונים בזמן אמת. כדי לעמוד בדרישות מחמירות של RPO, מומלץ להשתמש בשכפול סינכרוני.
שכפול סינכרוני ב-PostgreSQL מבטיח עקביות של הנתונים על ידי המתנה עד שהטרנזקציות ייכתבו גם בשרת הראשי וגם לפחות בשרת המתנה הסינכרוני לפני ביצוע הפעולה. רפליקציה סינכרונית מבטיחה שהנתונים לא יאבדו במקרה של כשל בשרת הראשי, ומספקת עמידות ועקביות גבוהות של הנתונים. השרת הראשי מחכה לאישורים מהשרת המשני הסינכרוני, מה שעלול להוביל לזמן אחזור ארוך יותר ולתפוקה נמוכה יותר בגלל זמן הלוך ושוב נוסף. הפעולה הזו עלולה להפחית את התפוקה הכוללת של המערכת, במיוחד בעומס גבוה.
שכפול אסינכרוני מאפשר לבצע עסקאות באשכול הראשי בלי לחכות לאישורים מאשכולות ההמתנה. השרת הראשי שולח רשומות WAL לשרתי גיבוי, שמחילים אותן באופן אסינכרוני. הגישה האסינכרונית הזו מקטינה את זמן האחזור של הכתיבה ומשפרת את הביצועים, אבל יש בה סיכון לאובדן נתונים אם השרת הראשי נכשל לפני שהשרת המשני מספיק להתעדכן. יכול להיות שהשרתים המשניים יהיו מאחורי השרת הראשי, מה שעלול לגרום לחוסר עקביות במהלך מעבר לשירות גיבוי.
הבחירה בין שכפול סינכרוני לשכפול אסינכרוני באשכול Patroni תלויה בדרישות הספציפיות של עמידות הנתונים, העקביות והביצועים. שכפול סינכרוני עדיף בתרחישים שבהם שלמות הנתונים ואובדן נתונים מינימלי הם קריטיים, בעוד ששכפול אסינכרוני מתאים לסביבות שבהן יש עדיפות לביצועים ולזמן אחזור נמוך יותר. אתם יכולים להגדיר פתרון משולב שכולל אשכול עם שלושה צמתים עם גיבוי סינכרוני באותו אזור אבל בתחום אחר או במרכז נתונים אחר בקרבת מקום, וגיבוי אסינכרוני שני באזור אחר או במרכז נתונים מרוחק יותר, כדי להגן על עצמכם מפני הפסקות חשמל אזוריות פוטנציאליות.