כיצד להתאים את PostgreSQL "בחינם" לסביבה ארגונית קשה

אנשים רבים מכירים את PostgreSQL DBMS, והוא הוכיח את עצמו בהתקנות קטנות. עם זאת, המגמה לכיוון קוד פתוח התבררה יותר ויותר, גם כשמדובר בחברות גדולות ובדרישות ארגוניות. במאמר זה נספר לכם כיצד לשלב את Postgres בסביבה ארגונית ונחלוק את הניסיון שלנו ביצירת מערכת גיבוי (BSS) עבור מסד נתונים זה באמצעות מערכת הגיבוי Commvault כדוגמה.

PostgreSQL כבר הוכיח את ערכו - ה-DBMS עובד מצוין, הוא משמש עסקים דיגיטליים אופנתיים כמו Alibaba ו-TripAdvisor, והיעדר דמי רישוי הופך אותו לחלופה מפתה למפלצות כמו MS SQL או Oracle DB. אבל ברגע שאנחנו מתחילים לחשוב על PostgreSQL בנוף הארגוני, אנו נתקלים מיד בדרישות מחמירות: "מה לגבי סובלנות תקלות בתצורה? התנגדות לאסונות? איפה המעקב המקיף? מה לגבי גיבויים אוטומטיים? מה לגבי שימוש בספריות קלטות הן ישירות והן באחסון משני?"


מצד אחד, ל-PostgreSQL אין כלי גיבוי מובנים, כמו DBMS "למבוגרים" כגון RMAN ב-Oracle DB או SAP Database Backup. מצד שני, ספקים של מערכות גיבוי ארגוניות (Veeam, Veritas, Commvault) למרות שהם תומכים ב-PostgreSQL, למעשה הם עובדים רק עם תצורה מסוימת (בדרך כלל עצמאית) ועם סט של הגבלות שונות.

מערכות גיבוי שתוכננו במיוחד עבור PostgreSQL, כגון Barman, Wal-g, pg_probackup, פופולריות ביותר בהתקנות קטנות של PostgreSQL DBMS או בהן אין צורך בגיבויים כבדים של אלמנטים אחרים של נוף ה-IT. לדוגמה, בנוסף ל-PostgreSQL, התשתית עשויה לכלול שרתים פיזיים ווירטואליים, OpenShift, Oracle, MariaDB, Cassandra וכו'. רצוי לגבות את כל זה בכלי משותף. התקנת פתרון נפרד בלעדי עבור PostgreSQL היא רעיון רע: הנתונים יועתקו למקום כלשהו לדיסק, ואז יש להסיר אותם לקלטת. גיבוי כפול זה מגדיל את זמן הגיבוי, וגם, יותר קריטי, את זמן השחזור.

בפתרון ארגוני, גיבוי של ההתקנה מתרחש עם מספר מסוים של צמתים באשכול ייעודי. במקביל, למשל, Commvault יכולה לעבוד רק עם אשכול דו-צמתים, שבו ראשי ומשני מוקצים בקפדנות לצמתים מסוימים. וזה הגיוני רק לגבות מ-Primary, כי לגיבוי מ-Second יש את המגבלות שלו. בשל המוזרויות של ה-DBMS, dump לא נוצר ב-Seconary, ולכן נותרה רק האפשרות של גיבוי קבצים.

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

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

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

אין לאן לסגת! מפתחי מוסקבה מאחור!

עם זאת, לאחרונה הצוות שלנו התמודד עם אתגר לא פשוט: בפרויקט ליצירת AIS OSAGO 2.0, שבו יצרנו את תשתית ה-IT, המפתחים בחרו ב-PostgreSQL למערכת החדשה.

למפתחי תוכנה גדולים הרבה יותר קל להשתמש בפתרונות קוד פתוח "אופנתיים". לפייסבוק יש מספיק מומחים כדי לתמוך בתפעול של DBMS זה. ובמקרה של RSA, כל המשימות של "היום השני" נפלו על כתפינו. נדרשנו לדאוג לסבילות לתקלות, להרכיב אשכול וכמובן להגדיר גיבוי. היגיון הפעולה היה כדלקמן:

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

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

קצת קסם לארגונים

אז, היינו צריכים להבטיח גיבוי אמין עבור 10 אשכולות של 3 צמתים כל אחד, כאשר אותה תשתית משתקפת במרכז הנתונים של הגיבוי. מרכזי נתונים במונחים של PostgreSQL עובדים על העיקרון האקטיבי-פאסיבי. גודל מסד הנתונים הכולל היה 50 TB. כל מערכת בקרה ברמת החברה יכולה להתמודד עם זה בקלות. אבל האזהרה היא שבתחילה ל-Postgres אין מושג לגבי תאימות מלאה ועמוקה למערכות גיבוי. לכן, היינו צריכים לחפש פתרון שבהתחלה היה לו פונקציונליות מקסימלית בשילוב עם PostgreSQL, ולחדד את המערכת.

קיימנו 3 "האקתונים" פנימיים - בדקנו יותר מחמישים פיתוחים, בדקנו אותם, ביצענו שינויים בקשר להשערות שלנו ובדקנו אותם שוב. לאחר בחינת האפשרויות הזמינות, בחרנו ב-Commvault. מחוץ לקופסה, מוצר זה יכול לעבוד עם התקנת אשכולות PostgreSQL הפשוטה ביותר, והארכיטקטורה הפתוחה שלו עוררה תקוות (שהיו מוצדקות) לפיתוח ושילוב מוצלחים. Commvault יכולה גם לגבות יומני PostgreSQL. לדוגמה, Veritas NetBackup במונחים של PostgreSQL יכולה לבצע גיבויים מלאים בלבד.

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

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

Patroni מגדיר צומת ראשי עבור כל אשכול. זה יכול להיות כל צומת פנוי במרכז הנתונים - אבל רק לרוב. בגיבוי, כל הצמתים הם משניים.

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

באופן כללי, התהליך נראה כך:

פטרוני בוחר ב-Primary → Keepalived מרים את אשכול ה-IP ומריץ את הסקריפט → סוכן Commvault בצומת האשכול הנבחר מקבל הודעה שזהו ה-Primary → Commvault מגדיר מחדש את הגיבוי באופן אוטומטי בתוך הפסאודו-לקוח.

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

הפתרון אינו מתיימר להיות אידיאלי ויש לו ניואנסים משלו. Commvault יכולה לגבות רק את כל המופע, ולא מסדי נתונים בודדים. לכן, נוצר מופע נפרד עבור כל מסד נתונים. לקוחות אמיתיים משולבים לכדי פסאודו-לקוחות וירטואליים. כל פסאודו-לקוח של Commvault הוא אשכול UNIX. אותם צמתי אשכול שעליהם מותקן סוכן Commvault for Postgres מתווספים אליו. כתוצאה מכך, כל הצמתים הווירטואליים של הפסאודו-לקוח מגובים כמופע אחד.

בתוך כל פסאודו-לקוח מצוין הצומת הפעיל של האשכול. זה מה שמגדיר פתרון האינטגרציה שלנו עבור Commvault. עיקרון הפעולה שלו הוא די פשוט: אם אשכול IP מועלה על צומת, הסקריפט מגדיר את הפרמטר "צומת פעיל" בבינארי של סוכן Commvault - למעשה, הסקריפט מגדיר "1" בחלק הנדרש של הזיכרון . הסוכן מעביר את הנתונים הללו ל-CommServe, ו-Commvault מבצעת גיבוי מהצומת הרצוי. בנוסף, תקינות התצורה נבדקת ברמת הסקריפט, ועוזרת למנוע שגיאות בעת התחלת גיבוי.

במקביל, מסדי נתונים גדולים מגובים בבלוקים על פני שרשורים מרובים, ועומדים בדרישות RPO וחלונות גיבוי. העומס על המערכת אינו משמעותי: עותקים מלאים אינם מתרחשים לעתים קרובות כל כך, בימים אחרים נאספים רק יומנים, ובתקופות של עומס נמוך.

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

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

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

זה טוב? טוֹב!

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

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

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

ניסית לעבוד עם PostgreSQL בסביבה ארגונית?

מחברים:

אולג לבנוב, מהנדס עיצוב מערכות אחסון נתונים, Jet Infosystems

דמיטרי אריקין, מהנדס עיצוב מערכות מחשוב ב-Jet Infosystems

מקור: www.habr.com