Postgres שלישי מס' 5: "PostgreSQL ו-Kubernetes. CI/CD. בדיקת אוטומציה"

בסוף השנה שעברה התקיים שידור חי נוסף של קהילת PostgreSQL הרוסית #RuPostgres, שבמהלכו שוחח המייסד המשותף שלה, ניקולאי סמוקוואלוב, עם המנהל הטכני של פלנט דמיטרי סטוליארוב על DBMS זה בהקשר של Kubernetes.

אנו מפרסמים תמליל של עיקר הדיון הזה, ובשעה ערוץ יוטיוב קהילתי הסרטון המלא פורסם:

מסדי נתונים ו-Kubernetes

НС: לא נדבר היום על ואקום ונקודות ביקורת. אנחנו רוצים לדבר על Kubernetes. אני יודע שיש לך ניסיון רב שנים. צפיתי בסרטונים שלך ואפילו צפיתי מחדש בכמה מהם... בואו נגיע ישר לעניין: למה Postgres או MySQL ב-K8s בכלל?

DS: אין ולא יכולה להיות תשובה חד משמעית לשאלה זו. אבל באופן כללי, מדובר בפשטות ונוחות... פוטנציאל. כולם רוצים שירותים מנוהלים.

НС: לאיך RDS, רק בבית?

DS: כן: כמו RDS, בכל מקום.

НС: "בכל מקום" זו נקודה טובה. בחברות גדולות הכל נמצא במקומות שונים. מדוע אם כן, אם מדובר בחברה גדולה, לא לקחת פתרון מוכן? לדוגמה, ל-Nutanix יש פיתוחים משלה, לחברות אחרות (VMware...) יש את אותו "RDS, רק בבית".

DS: אבל אנחנו מדברים על יישום נפרד שיעבוד רק בתנאים מסוימים. ואם אנחנו מדברים על Kubernetes, אז יש מגוון עצום של תשתית (שיכולה להיות ב-K8s). בעיקרו של דבר זהו תקן עבור ממשקי API לענן...

НС: זה גם בחינם!

DS: זה לא כל כך חשוב. החופש חשוב לפלח לא גדול במיוחד של השוק. עוד משהו חשוב... אתם בטח זוכרים את הדוח "מסדי נתונים ו-Kubernetes"?

НС: כן.

DS: הבנתי שזה התקבל בצורה מאוד לא ברורה. היו אנשים שחשבו שאני אומר: "חבר'ה, בואו נכניס את כל מסדי הנתונים ל-Kubernetes!", בעוד שאחרים החליטו שכל אלה הם אופניים איומים. אבל רציתי להגיד משהו אחר לגמרי: “תראה מה קורה, איזה בעיות יש ואיך אפשר לפתור אותן. האם עלינו להשתמש במסדי נתונים של Kubernetes כעת? הפקה? ובכן, רק אם אתה אוהב...לעשות דברים מסוימים. אבל עבור מפתח, אני יכול לומר שאני ממליץ עליו. עבור מפתח, הדינמיות של יצירה/מחיקה של סביבות חשובה מאוד."

NS: ב-dev, האם אתה מתכוון לכל הסביבות שאינן פרוד? בימוי, QA…

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

НС: אף אחד. אבל איפה אנחנו רואים סביבות סטטיות? סביבה סטטית תתיישן מחר.

DS: בימוי יכול להיות סטטי. יש לנו לקוחות...

НС: כן, גם לי יש כזה. זו בעיה גדולה אם יש לך מסד נתונים של 10 TB ו-200 GB סטaging...

DS: יש לי מקרה מאוד מגניב! ב-Staging ישנו מסד נתונים של מוצרים בו מתבצעים שינויים. ויש כפתור: "להתגלגל לייצור". השינויים האלה - deltas - מתווספים (נראה שהם פשוט מסונכרנים דרך ה-API) בייצור. זוהי אפשרות אקזוטית מאוד.

НС: ראיתי סטארטאפים בעמק שיושבים ב-RDS או אפילו בהרוקו - אלו סיפורים מלפני 2-3 שנים - והם מורידים את ה-dump למחשב הנייד שלהם. כי מסד הנתונים הוא עדיין רק 80 GB, ויש מקום על המחשב הנייד. אחר כך הם קונים דיסקים נוספים לכולם כך שיהיו להם 3 מסדי נתונים לביצוע פיתוחים שונים. גם ככה זה קורה. ראיתי גם שהם לא מפחדים להעתיק פרוד לבימוי - זה מאוד תלוי בחברה. אבל ראיתי גם שהם מאוד מפחדים, ושהרבה פעמים אין להם מספיק זמן וידיים. אבל לפני שנעבור לנושא הזה, אני רוצה לשמוע על Kubernetes. האם אני מבין נכון שאף אחד עדיין לא מתלהב?

DS: יש לנו מאגרי מידע קטנים בייצור. אנחנו מדברים על נפחים של עשרות גיגה-בייט ושירותים לא קריטיים שהתעצלנו בשבילם לעשות העתקים (ואין צורך כזה). ובתנאי שיש אחסון רגיל תחת Kubernetes. מסד הנתונים הזה עבד במכונה וירטואלית - מותנה ב-VMware, על גבי מערכת האחסון. שמנו את זה PV ועכשיו אנחנו יכולים להעביר אותו ממכונה למכונה.

НС: מסדי נתונים בגודל כזה, עד 100 ג'יגה-בייט, יכולים להתגלגל תוך דקות ספורות על דיסקים טובים ורשת טובה, נכון? מהירות של 1 GB לשנייה כבר לא אקזוטית.

DS: כן, עבור פעולה ליניארית זו לא בעיה.

НС: אוקיי, אנחנו רק צריכים לחשוב על פרוד. ואם אנחנו שוקלים Kubernetes עבור סביבות שאינן מתוצרת, מה עלינו לעשות? אני רואה את זה בזלנדו לעשות מפעיל, בקראנצ'י נְסִירָה, יש כמה אפשרויות אחרות. ויש OnGres - זה חברנו הטוב אלווארו מספרד: מה שהם עושים הוא בעצם לא רק מפעיל, וכל ההפצה (StackGres), שלתוכו, בנוסף ל-Postgres עצמה, הם גם החליטו להכניס גיבוי, ה-Proxy של Envoy...

DS: שליח על מה? איזון תעבורת Postgres במיוחד?

НС: כן. כלומר, הם רואים את זה כך: אם אתה לוקח הפצת לינוקס וקרנל, אז PostgreSQL רגיל הוא הקרנל, והם רוצים לעשות הפצה שתהיה ידידותית לענן ותפעל על Kubernetes. הם מרכיבים רכיבים (גיבויים וכו') ומפותרים אותם כך שיעבדו היטב.

DS: מגניב מאוד! בעיקרון זוהי תוכנה ליצירת Postgres מנוהל משלך.

НС: להפצות לינוקס יש בעיות נצחיות: כיצד ליצור מנהלי התקנים כך שכל החומרה תהיה נתמכת. ויש להם את הרעיון שהם יעבדו ב- Kubernetes. אני יודע שבמפעיל Zalando ראינו לאחרונה חיבור ל-AWS וזה כבר לא ממש טוב. לא צריך להיות קשר לתשתית ספציפית - מה הטעם אם כך?

DS: אני לא יודע בדיוק לאיזה מצב נקלע זלאנדו, אבל ב-Kubernetes האחסון נעשה כעת בצורה כזו שאי אפשר לקחת גיבוי דיסק בשיטה גנרית. לאחרונה בסטנדרטי - בגרסה האחרונה מפרטי CSI - אפשרנו צילומי מצב, אבל איפה זה מיושם? בכנות, הכל עדיין כל כך גולמי... אנחנו מנסים CSI על גבי AWS, GCE, Azure, vSphere, אבל ברגע שמתחילים להשתמש בו, אתה יכול לראות שהוא עדיין לא מוכן.

НС: לכן אנחנו צריכים לפעמים להסתמך על תשתית. אני חושב שזה עדיין שלב מוקדם - כאבי גדילה. שאלה: איזו עצה היית נותן למתחילים שרוצים לנסות PgSQL ב-K8s? איזה מפעיל אולי?

DS: הבעיה היא ש-Postgres הוא 3% עבורנו. יש לנו גם רשימה גדולה מאוד של תוכנות שונות ב-Kubernetes, אני אפילו לא אפרט הכל. לדוגמה, Elasticsearch. יש הרבה מפעילים: חלקם מפתחים באופן פעיל, אחרים לא. הכנו לעצמנו דרישות לגבי מה צריך להיות למפעיל כדי שניקח את זה ברצינות. במפעיל ספציפי עבור Kubernetes - לא ב"מפעיל לעשות משהו בתנאים של אמזון"... למעשה, אנחנו די נרחב (=כמעט כל הלקוחות) משתמשים במפעיל יחיד - עבור Redis (בקרוב נפרסם כתבה עליו).

НС: וגם לא עבור MySQL? אני יודע ש-Percona... מכיוון שהם עובדים כעת על MySQL, MongoDB ו-Postgres, הם יצטרכו ליצור איזשהו פתרון אוניברסלי: לכל מסדי הנתונים, לכל ספקי הענן.

DS: לא היה לנו זמן להסתכל על האופרטורים של MySQL. זה לא הפוקוס העיקרי שלנו כרגע. MySQL עובד מצוין במצב עצמאי. למה להשתמש באופרטור אם אתה יכול פשוט להפעיל מסד נתונים... אתה יכול להפעיל קונטיינר Docker עם Postrges, או שאתה יכול להפעיל אותו בצורה פשוטה.

НС: גם על זה הייתה שאלה. אין מפעיל בכלל?

DS: כן, ל-100% מאיתנו יש PostgreSQL שפועל ללא מפעיל. עד כאן. אנו משתמשים באופן פעיל באופרטור עבור Prometheus ו- Redis. יש לנו תוכניות למצוא מפעיל עבור Elasticsearch - הוא זה שהכי "דולק", כי אנחנו רוצים להתקין אותו ב-Kubernetes ב-100% מהמקרים. בדיוק כפי שאנו רוצים להבטיח שגם MongoDB מותקן תמיד ב-Kubernetes. כאן מופיעות משאלות מסוימות – יש תחושה שבמקרים אלו ניתן לעשות משהו. ואפילו לא הסתכלנו על פוסטגרס. כמובן, אנחנו יודעים שיש אפשרויות שונות, אבל למעשה יש לנו אופציה עצמאית.

DB לבדיקה ב- Kubernetes

НС: בואו נעבור לנושא הבדיקות. כיצד להפעיל שינויים במסד הנתונים - מנקודת מבט של DevOps. יש מיקרו-שירותים, מסדי נתונים רבים, משהו משתנה איפשהו כל הזמן. כיצד להבטיח CI/CD תקין כך שהכל יהיה מסודר מנקודת המבט של DBMS. מה הגישה שלך?

DS: לא יכולה להיות תשובה אחת. ישנן מספר אפשרויות. הראשון הוא גודל הבסיס שאנו רוצים לגלגל החוצה. אתה בעצמך ציינת שלחברות יש גישות שונות לגבי קבלת עותק של מסד הנתונים של פרוד ב-dev ובמה.

НС: ובתנאי ה-GDPR, אני חושב שהם נזהרים יותר ויותר... אני יכול לומר שבאירופה כבר התחילו להטיל קנסות.

DS: אבל לעתים קרובות אתה יכול לכתוב תוכנה שלוקחת dump מהייצור ומערפלת אותה. נתוני פרוד מתקבלים (תצלום, dump, עותק בינארי...), אך הם אנונימיים. במקום זאת, יכולים להיות סקריפטים לדור: אלה יכולים להיות מתקנים או סתם סקריפט שיוצר מסד נתונים גדול. הבעיה היא: כמה זמן לוקח ליצור תמונת בסיס? וכמה זמן לוקח לפרוס אותו בסביבה הרצויה?

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

НС: על ידי העתקה פשוטה?

DS: הנתונים מאוחסנים ישירות בתמונת Docker. הָהֵן. יש לנו תמונה מוכנה, אם כי 100 GB. הודות לשכבות ב-Docker, אנו יכולים לפרוס את התמונה הזו במהירות כמה פעמים שאנחנו צריכים. השיטה טיפשית, אבל היא עובדת טוב.

НС: ואז, כשאתה בודק, זה משתנה ממש בתוך Docker, נכון? העתק על כתיבה בתוך Docker - לזרוק אותו ולך שוב, הכל בסדר. מעמד! והאם אתה כבר משתמש בו עד הסוף?

DS: במשך זמן רב.

НС: אנחנו עושים דברים מאוד דומים. רק שאנחנו לא משתמשים בהעתקה-על-כתיבה של Docker, אלא באחד אחר.

DS: זה לא גנרי. ודוקר עובד בכל מקום.

НС: בתיאוריה, כן. אבל יש לנו שם גם מודולים, אתה יכול ליצור מודולים שונים ולעבוד עם מערכות קבצים שונות. איזה רגע כאן. מהצד של Postgres, אנחנו מסתכלים על כל זה אחרת. עכשיו הסתכלתי מהצד של הדוקר וראיתי שהכל עובד בשבילך. אבל אם מסד הנתונים הוא עצום, למשל, 1 TB, אז כל זה לוקח הרבה זמן: פעולות בלילה, ודחיסה של הכל ל-Docker... ואם 5 TB נדחסים ל-Docker... או שהכל בסדר?

DS: מה ההבדל: אלה בלובים, רק ביטים ובייטים.

НС: ההבדל הוא זה: האם אתה עושה את זה דרך dump ושחזור?

DS: בכלל לא הכרחי. השיטות ליצירת תמונה זו יכולות להיות שונות.

НС: עבור חלק מהלקוחות, הפכנו את זה כך שבמקום ליצור תמונת בסיס באופן קבוע, אנחנו כל הזמן מעודכנים אותה. זה בעצם העתק, אבל הוא מקבל נתונים לא מהמאסטר ישירות, אלא דרך ארכיון. ארכיון בינארי שבו מורידים WALs כל יום, שבו נלקחים גיבויים... WALs אלה מגיעים לאחר מכן לתמונת הבסיס בהשהייה קלה (ממש 1-2 שניות). אנחנו משכפלים ממנו בכל דרך - עכשיו יש לנו ZFS כברירת מחדל.

DS: אבל עם ZFS אתה מוגבל לצומת אחד.

НС: כן. אבל ל-ZFS יש גם קסם לשלוח: בעזרתו אפשר לשלוח תמונת מצב ואפילו (עוד לא ממש בדקתי את זה, אבל...) אפשר לשלוח דלתא בין שניים PGDATA. למעשה, יש לנו עוד כלי שלא ממש שקלנו אותו עבור משימות כאלה. ל-PostgreSQL יש pg_rewind, שעובד כמו rsync "חכם", מדלג על הרבה ממה שאתה לא צריך לצפות, כי שום דבר לא השתנה שם. אנחנו יכולים לעשות סנכרון מהיר בין שני השרתים ולהריץ לאחור באותו אופן.

אז מהצד הזה, יותר של DBA, אנחנו מנסים ליצור כלי שיאפשר לנו לעשות את אותו הדבר שאמרת: יש לנו מסד נתונים אחד, אבל אנחנו רוצים לבדוק משהו 50 פעמים, כמעט בו זמנית.

DS: פי 50 אומר שאתה צריך להזמין 50 מופעי Spot.

НС: לא, אנחנו עושים הכל במכונה אחת.

DS: אבל איך תרחיב פי 50 אם מסד הנתונים הזה הוא, נגיד, טרה-בייט. סביר להניח שהיא צריכה זיכרון RAM מותנה של 256 GB?

НС: כן, לפעמים צריך הרבה זיכרון - זה נורמלי. אבל זו דוגמה מהחיים. למכונת הייצור 96 ליבות ו-600 GB. במקביל, 32 ליבות (אפילו 16 ליבות עכשיו לפעמים) ו-100-120 GB של זיכרון משמשים למסד הנתונים.

DS: ו-50 עותקים נכנסים לשם?

НС: אז יש רק עותק אחד, ואז העתק-על-כתיבה (ZFS) עובד... אני אספר לכם ביתר פירוט.

לדוגמה, יש לנו מסד נתונים של 10 TB. הם יצרו עבורו דיסק, ZFS גם דחס את הגודל שלו ב-30-40 אחוז. מכיוון שאנחנו לא מבצעים בדיקות עומס, זמן התגובה המדויק לא חשוב לנו: שיהיה איטי עד פי 2 - זה בסדר.

אנו נותנים את ההזדמנות למתכנתים, QA, DBA וכו'. לבצע בדיקות ב-1-2 שרשורים. לדוגמה, הם עשויים להפעיל סוג של הגירה. זה לא דורש 10 ליבות בבת אחת - זה צריך 1 Postgres backend, 1 ליבה. ההגירה תתחיל - אולי ואקום אוטומטי עדיין יתחיל, ואז תשמש הליבה השנייה. יש לנו 16-32 ליבות שהוקצו, כך ש-10 אנשים יכולים לעבוד בו זמנית, אין בעיה.

כי פיזית PGDATA אותו דבר, מסתבר שאנחנו בעצם שוללים את פוסטגרס. הטריק הוא זה: לדוגמה, 10 Postgres מושקים בו זמנית. מה הבעיה בדרך כלל? הם שמו shared_buffers, נניח 25%. בהתאם, מדובר ב-200 GB. לא תוכל להפעיל יותר משלושה כאלה, כי הזיכרון יגמר.

אבל בשלב מסוים הבנו שזה לא הכרחי: הגדרנו shared_buffers ל-2 GB. ל-PostgreSQL יש גודל_מטמון יעיל, ובמציאות הוא היחיד שמשפיע תוכניות. הגדרנו אותו ל-0,5 TB. וזה אפילו לא משנה שהם לא קיימים: הוא מתכנן תוכניות כאילו הן קיימות.

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

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

НС: ראשית, אני מסכים, זה סיפור פוסטגרס בלבד. אני חושב שאם יהיה לנו איזשהו IO ישיר ומאגר חיץ כמעט לכל הזיכרון, הגישה הזו לא תעבוד - התוכניות יהיו שונות. אבל בינתיים אנחנו עובדים רק עם Postgres, אנחנו לא חושבים על אחרים.

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

DS: מנקודת המבט שלי, אנחנו יוצרים פודים ב-Kubernetes. K8s - אלסטי: מזמינים קשרים לפי הצורך. המשימה היא פשוט ליצור פוד ולהגיד שהוא צריך X כמות משאבים, ואז K8s יבינו את זה לבד. אבל תמיכת האחסון ב-Kubernetes עדיין לא יציבה: 1.16בתוך 1.17 (מהדורה זו שוחררה недели לפני) תכונות אלו הופכות לבטא בלבד.

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

НС: יש צורך גם שכל המנועים (אמזון, גוגל...) יתחילו לתמוך בגרסה זו - גם זה לוקח קצת זמן.

DS: אנחנו עדיין לא משתמשים בהם. אנחנו משתמשים בשלנו.

פיתוח מקומי עבור Kubernetes

НС: האם נתקלתם במשאלה כזו כשאתם צריכים להתקין את כל הפודים במכונה אחת ולעשות בדיקה קטנה כזו. כדי לקבל במהירות הוכחה לקונספט, ראה שהאפליקציה פועלת ב- Kubernetes, מבלי להקדיש לה חבורה של מכונות. יש מיניקוב, נכון?

DS: נראה לי שהמקרה הזה - פרוס על צומת אחד - עוסק אך ורק בפיתוח מקומי. או כמה ביטויים של דפוס כזה. לאכול מיניקובשם k3, סוג. אנו מתקדמים לקראת שימוש ב- Kubernetes IN Docker. עכשיו התחלנו לעבוד איתו לבדיקות.

НС: פעם חשבתי שזה ניסיון לעטוף את כל התרמילים בתמונת Docker אחת. אבל התברר שמדובר במשהו אחר לגמרי. בכל מקרה, יש מיכלים נפרדים, פודים נפרדים - רק ב-Docker.

DS: כן. ויש חיקוי מצחיק למדי, אבל המשמעות היא זו... יש לנו כלי עזר לפריסה - werf. אנחנו רוצים להפוך את זה למצב מותנה werf up: "תביא לי Kubernetes מקומי." ואז להפעיל את התנאי שם werf follow. לאחר מכן המפתח יוכל לערוך את ה-IDE, ויושק תהליך במערכת שיראה את השינויים ובונה מחדש את התמונות, תוך פריסה מחדש ל-K8s מקומיים. כך אנחנו רוצים לנסות לפתור את בעיית הפיתוח המקומי.

צילומי מצב ושיבוט מסדי נתונים במציאות K8s

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

אבל לבדיקות, נראה לי שצילומי מצב, עליהם אתה מדבר ב-Docker או שאני מדבר עליהם ב-ZFS, btrfs ואפילו LVM... - הם מאפשרים לך לא ליצור נתונים ממש חדשים על מכונה אחת. בענן, עדיין תשלמו עבורם בכל פעם ותמתינו לא שניות, אלא דקות (ובמקרה עומס עצלן, אולי שעון).

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

DS: אני לא מסכים. המשימה של הענן היא לגרום לשיבוט נפח לעבוד כמו שצריך. לא בדקתי את היישום שלהם, אבל אני יודע איך אנחנו עושים את זה בחומרה. יש לנו Ceph, זה מאפשר כל נפח פיזי (RBD) אמר לשבט ולקבל כרך שני עם אותם מאפיינים בעשרות אלפיות שניות, IOPS'אמי וכו'. אתה צריך להבין שיש בפנים עותק-על-כתיבה מסובך. למה שהענן לא יעשה את אותו הדבר? אני בטוח שהם מנסים לעשות את זה בדרך זו או אחרת.

НС: אבל זה עדיין ייקח להם שניות, עשרות שניות להעלות מופע, להביא את דוקר לשם וכו'.

DS: מדוע יש צורך להעלות מופע שלם? יש לנו מופע עם 32 ליבות, 16... והוא יכול להשתלב בו - למשל, ארבע. כאשר נזמין את החמישי, המופע כבר יועלה, ואז הוא יימחק.

НС: כן, מעניין, Kubernetes מתברר כסיפור אחר. מסד הנתונים שלנו אינו ב-K8s, ויש לנו מופע אחד. אבל שיבוט מסד נתונים מרובה טרה-בתים לא לוקח יותר משתי שניות.

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

НС: זה מתאים לא רק ל-Postgres: התוכניות האלה, כפי שתיארתי, יעבדו רק בה. אבל אם אנחנו לא מתעסקים בתוכניות, ואנחנו רק צריכים את כל הנתונים לבדיקות פונקציונליות, אז זה מתאים לכל DBMS.

DS: לפני שנים רבות עשינו משהו דומה בצילומי מצב של LVM. זו קלאסיקה. גישה זו הייתה בשימוש פעיל מאוד. צמתים מצביים הם רק כאב. כי אתה לא צריך להפיל אותם, אתה צריך תמיד לזכור אותם...

НС: האם אתה רואה כאן אפשרות של הכלאה? נניח שהמדינה היא סוג של תרמיל, הוא עובד עבור מספר אנשים (בודקים רבים). יש לנו כרך אחד, אבל הודות למערכת הקבצים, השיבוטים הם מקומיים. אם התרמיל נופל, אבל הדיסק נשאר, התרמיל יעלה, יספור מידע על כל השיבוטים, יאסוף הכל שוב ויגיד: "הנה השיבוטים שלך רצים על היציאות האלה, המשך לעבוד איתם."

DS: מבחינה טכנית זה אומר שבתוך Kubernetes זה פוד אחד שבתוכו אנחנו מפעילים הרבה Postgres.

НС: כן. יש לו גבול: נניח שלא יותר מ-10 אנשים עובדים איתו בו זמנית. אם אתה צריך 20, נשיק פוד שני כזה. נשכפל אותו במלואו, לאחר שקיבלנו את הנפח השני המלא, יהיו לו אותם 10 שיבוטים "דקים". אתה לא רואה את ההזדמנות הזו?

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

НС: אני לא מאמין בשנייה וחצי להרבה טרה-בייט. ב-Ceph אתה עושה את זה בעצמך, אבל אתה מדבר על העננים. עבור לענן, צור שיבוט של נפח EBS מרובה טרה-בייט ב-EC2 וראה מה יהיו הביצועים. זה לא ייקח כמה שניות. אני מאוד מעוניין מתי הם יגיעו לרמה הזו. אני מבין מה אתה אומר, אבל אני מבקש להבדיל.

DS: בסדר, אבל אמרתי בטווח הבינוני, לא לטווח הקצר. למספר שנים.

על המפעיל של PostgreSQL מ- Zalando

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

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

"עבור לשירותים מנוהלים והשתמש בהם, אל תפעיל את מסד הנתונים ב-Kubernetes. אחרת, ה-K8s שלך יחליטו, למשל, לבצע שדרוג, לכבות את כל הצמתים, והנתונים שלך יעופו רחוק, רחוק."

החלטנו ליצור מפעיל שבניגוד לעצה זו ישיק מאגר נתונים Postgres ב-Kubernetes. והייתה לנו סיבה טובה - פטרוני. זהו כשל אוטומטי עבור PostgreSQL, שנעשה בצורה נכונה, כלומר. שימוש ב-etcd, consul או ZooKeeper כאחסון מידע על האשכול. מאגר כזה שייתן לכל מי ששואל, למשל, מה המנהיג הנוכחי, את אותו מידע - למרות שהכל מופץ אצלנו - כדי שלא יהיה מוח מפוצל. בנוסף היה לנו תמונת דוקר בשבילו.

באופן כללי, הצורך של החברה ב-failover אוטומטי הופיע לאחר הגירה ממרכז נתונים פנימי של חומרה לענן. הענן התבסס על פתרון PaaS (Platform-as-a-Service) קנייני. זה קוד פתוח, אבל נדרשה הרבה עבודה כדי להפעיל אותו. זה נקרא STUPS.

בתחילה, לא היה Kubernetes. ליתר דיוק, כאשר הפתרון שלנו נפרס, K8s כבר היו קיימים, אבל הוא היה כל כך גולמי שהוא לא מתאים לייצור. זה היה, לדעתי, 2015 או 2016. עד 2017, Kubernetes התבגרה פחות או יותר - היה צורך להגר לשם.

וכבר הייתה לנו מכולה של דוקר. היה PaaS שהשתמש ב-Docker. למה לא לנסות K8s? למה לא לכתוב מפעיל משלך? מוראט קבילוב, שהגיע אלינו מאביטו, התחיל את זה כפרויקט ביוזמתו - "לשחק" - והפרויקט "המריא".

אבל באופן כללי, רציתי לדבר על AWS. מדוע היה קוד היסטורי הקשור ל-AWS...

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

אז, כשעשינו את ההצהרה, פעלנו ב-Postgres על אמצעי אחסון חיצוני (EBS במקרה זה, מכיוון שעבדנו על AWS). בסיס הנתונים גדל, בשלב מסוים היה צורך לשנות את גודלו: למשל, הגודל הראשוני של EBS היה 100 TB, בסיס הנתונים גדל אליו, עכשיו אנחנו רוצים להפוך את EBS ל-200 TB. אֵיך? נניח שאתה יכול לבצע dump/שחזור במופע חדש, אבל זה ייקח הרבה זמן וכרוך בזמן השבתה.

לכן, רציתי שינוי גודל שיגדיל את מחיצת EBS ואז יגיד למערכת הקבצים להשתמש במרחב החדש. ועשינו את זה, אבל באותו זמן לא היה ל-Kubernetes שום API עבור פעולת שינוי הגודל. מאז שעבדנו על AWS, כתבנו קוד עבור ה-API שלו.

אף אחד לא מונע ממך לעשות את אותו הדבר עבור פלטפורמות אחרות. אין שום רמז בהצהרה שאפשר להריץ אותו רק ב-AWS, וזה לא יעבוד על כל השאר. באופן כללי, מדובר בפרויקט קוד פתוח: אם מישהו רוצה לזרז את הופעת השימוש ב-API החדש, אתה מוזמן. לאכול GitHub, בקשות למשוך - צוות Zalando מנסה להיענות להן די מהר ולקדם את המפעיל. למיטב ידיעתי, הפרויקט השתתפו ב-Google Summer of Code ועוד כמה יוזמות דומות. זלנדו עובד מאוד פעיל על זה.

בונוס נ.ב.!

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

PPS

קרא גם בבלוג שלנו:

• «מסדי נתונים ו-Kubernetes (סקירה ודוח וידאו)";
• «הגירה של קסנדרה ל-Kubernetes: תכונות ופתרונות";
• «העברה חלקה של MongoDB ל-Kubernetes";
• «העברה חלקה של RabbitMQ ל-Kubernetes".

מקור: www.habr.com