העברה חלקה של RabbitMQ ל-Kubernetes

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

היינו צריכים את הפעולה הזו לפחות בשני מקרים:

1. העברת נתונים מאשכול RabbitMQ שאינו ממוקם ב-Kubernetes לאשכול חדש - שכבר "קוברנטיז" (כלומר פועל ב-K8s pods).
2. הגירה של RabbitMQ בתוך Kubernetes ממרחב שמות אחד לאחר (לדוגמה, אם מעגלים מופרדים על ידי מרחבי שמות, אז כדי להעביר תשתית ממעגל אחד למשנהו).

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

... ואנו עומדים בפני המשימה להעביר אותו לייצור החדש ב-Kubernetes.

ראשית, תתואר הגישה הכללית להגירה עצמה, ולאחריה יתוארו הפרטים הטכניים של יישומה.

אלגוריתם הגירה

השלב הראשון, המקדים, לפני כל פעולה הוא לבדוק שמצב זמינות גבוהה מופעל בהתקנה הישנה של RabbitMQ (HA). הסיבה ברורה - אנחנו לא רוצים לאבד שום מידע. כדי לבצע בדיקה זו, אתה יכול ללכת לפאנל הניהול של RabbitMQ ובכרטיסייה Admin → Policies לוודא שהערך מוגדר ha-mode: all:

השלב הבא הוא להעלות אשכול RabbitMQ חדש בתרמילים של Kubernetes (במקרה שלנו, למשל, מורכב מ-3 צמתים, אבל מספרם עשוי להיות שונה).

לאחר מכן, אנו ממזגים את אשכולות RabbitMQ הישנים והחדשים, ומשיגים אשכול יחיד (של 6 צמתים):

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

לאחר פעולות אלה, מספיק להסיר את הצמתים הישנים מאשכול RabbitMQ, והמהלך יכול להיחשב כמושלם:

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

בואו ננסה את זה בפועל

דרישות

הפרטים מאוד פשוטים:

1. אשכול Kubernetes (מיניקוב יעבוד גם);
2. אשכול RabbitMQ (ניתן לפרוס על מתכת חשופה, וליצור כמו אשכול רגיל ב-Kubernetes מתרשים Helm הרשמי).

עבור הדוגמה למטה, פרסתי את RMQ ל-Kubernetes וקראתי לזה rmq-old.

הכנת דוכן

1. הורד את תרשים ההגה וערוך אותו מעט:

helm fetch --untar stable/rabbitmq-ha

מטעמי נוחות, הגדרנו סיסמה, ErlangCookie ולעשות פוליטיקה ha-allכך שבברירת מחדל התורים מסונכרנים בין כל הצמתים של אשכול RMQ:

rabbitmqPassword: guest
rabbitmqErlangCookie: mae9joopaol7aiVu3eechei2waiGa2we
definitions:
policies: |-
  {
    "name": "ha-all",
    "pattern": ".*",
    "vhost": "/",
    "definition": {
      "ha-mode": "all",
      "ha-sync-mode": "automatic",
      "ha-sync-batch-size": 81920
    }
  }

2. התקן את התרשים:

helm install . --name rmq-old --namespace rmq-old

3. עבור לפאנל הניהול של RabbitMQ, צור תור חדש והוסף מספר הודעות. הם יהיו נחוצים כדי שאחרי ההגירה נוכל לוודא שכל הנתונים נשמרים ושלא איבדנו דבר:

ספסל הבדיקה מוכן: יש לנו את RabbitMQ "הישן" עם נתונים שצריך להעביר.

העברת אשכול RabbitMQ

1. ראשית, בואו נפרוס את RabbitMQ החדש ב другом מרחב שמות עם אותו ErlangCookie וסיסמא למשתמש. לשם כך, נבצע את הפעולות המתוארות לעיל, ונשנה את הפקודה הסופית להתקנת RMQ לפקודה הבאה:

helm install . --name rmq-new --namespace rmq-new

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

export OLD_RMQ=rabbit@rmq-old-rabbitmq-ha-0.rmq-old-rabbitmq-ha-discovery.rmq-old.svc.cluster.local && 
  rabbitmqctl stop_app && 
  rabbitmqctl join_cluster $OLD_RMQ && 
  rabbitmqctl start_app

במשתנה OLD_RMQ נמצאה הכתובת של אחד הצמתים זקן אשכול RMQ.

פקודות אלה יעצרו את הצומת הנוכחי חדש אשכול RMQ, חבר אותו לאשכול הישן והפעל אותו שוב.

3. אשכול RMQ של 6 צמתים מוכן:

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

אז, מצב הסנכרון:

כאן +5 פירוש הדבר שההודעות כבר נמצאות יותר על 5 צמתים (למעט מה שמצוין בשדה Node). לפיכך, הסנכרון הצליח.

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

לניתוח האחרון (כלומר כבר לאחר העברת האפליקציה לאשכול חדש) עבור לכל צומת זקן אשכול ובצע את הפקודות:

rabbitmqctl stop_app
rabbitmqctl reset

האשכול "שכח" מהצמתים הישנים: אתה יכול למחוק את ה-RMQ הישן, ואז המעבר יושלם.

שים לב: אם אתה משתמש ב-RMQ עם אישורים, אז שום דבר לא משתנה מהותית - תהליך המעבר יתבצע בדיוק אותו הדבר.

ממצאים

הסכימה המתוארת מתאימה כמעט לכל המקרים שבהם אנחנו צריכים להעביר את RabbitMQ או פשוט לעבור לאשכול חדש.

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

השתמשנו באותה אסטרטגיה כשעדכנו את RabbitMQ לגרסה חדשה עם תצורה שונה - הכל עבד כמו שעון.

נ.ב.

כהמשך הגיוני לחומר זה, אנו מכינים מאמרים על MongoDB (הגירה משרת חומרה ל-Kubernetes) ו-MySQL (איך אנחנו מכינים את ה-DBMS הזה בתוך Kubernetes). הם יפורסמו בחודשים הקרובים.

PPS

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

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

מקור: www.habr.com