Cloister → ניהול קלסטר OTP פשוט

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

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

העברת הודעות בין תהליכים בצמתים שונים, כמו גם בין קישורים לצגים, היא שקופה […]

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

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

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

דרישות

מה שהייתי צריך באופן אישי זה ספרייה שתשתלט על הניהול של האשכול ותהיה לה את המאפיינים הבאים:

• עבודה שקופה עם רשימה מקודדת של צמתים וגילוי דינמי באמצעות שירותים erlang;
• התקשרות חוזרת פונקציונלית מלאה עבור כל שינוי בטופולוגיה (צומת שם, צומת כאן, חוסר יציבות ברשת, פיצולים);
• ממשק שקוף להפעלת אשכול עם שמות ארוכים וקצרים, כמו עם :nonode@nohost;
• תמיכת Docker מחוץ לקופסה, ללא צורך בכתיבת קוד תשתית.

זה האחרון אומר שלאחר שבדקתי את האפליקציה באופן מקומי ב :nonode@nohost, או בסביבה המופצת באופן מלאכותי באמצעות test_cluster_task, אני רק רוצה לרוץ docker-compose up --scale my_app=3 וראה כיצד הוא מבצע שלושה מופעים ב-docker ללא שינויי קוד. אני גם רוצה אפליקציות תלויות כמו mnesia - כאשר הטופולוגיה משתנה, מאחורי הקלעים הם בונים מחדש את האשכול בשידור חי ללא בעיטה נוספת מהאפליקציה.

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

גישה נבחרת

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

כאשר מפעילים אותו כיישום, הספרייה מסתמכת על config, שממנו הוא קורא את הערכים הבסיסיים הבאים:

config :cloister,
  otp_app: :my_app,
  sentry: :"cloister.local", # or ~w|n1@foo n2@bar|a
  consensus: 3,              # number of nodes to consider
                             #    the cluster is up
  listener: MyApp.Listener   # listener to be called when
                             #    the ring has changed

הפרמטרים שלמעלה אומרים, פשוטו כמשמעו, את הדברים הבאים: קלוסטר משמש עבור יישום OTP :my_appשימושים גילוי שירות erlang כדי לחבר צמתים, לפחות שלושה, ו MyApp.Listener מודול (יישום @behaviour Cloister.Listener) מוגדר לקבל הודעות על שינויים בטופולוגיה. ניתן למצוא תיאור מפורט של התצורה המלאה ב תיעוד.

עם תצורה זו, האפליקציה קלוסטר רצון השקה בשלבים, עיכוב תהליך התחלת היישום הראשי עד להשגת הסכמה (שלושה צמתים מחוברים ומחוברים, כמו בדוגמה למעלה.) זה נותן ליישום הראשי את ההזדמנות להניח שכאשר הוא מתחיל, האשכול כבר זמין. בכל פעם שהטופולוגיה משתנה (יהיו רבים מהם, מכיוון שהצמתים לא מתחילים באופן סינכרוני לחלוטין), המטפל ייקרא MyApp.Listener.on_state_change/2. לרוב אנו מבצעים פעולה כאשר אנו מקבלים הודעת סטטוס %Cloister.Monitor{status: :up}, שפירושו: "שלום, האשכול מורכב."

ברוב המקרים, התקנה consensus: 3 הוא אופטימלי כי גם אם אנו מצפים שיותר צמתים יתחברו, ההתקשרות חזרה תעבור status: :rehashing → status: :up על כל צומת שנוסף או הוסר לאחרונה.

כשאתה מתחיל במצב פיתוח, אתה רק צריך להגדיר consensus: 1 и קלוסטר ידלג בשמחה על ההמתנה להרכבת האשכול כשהוא יראה :nonode@nohostאו :node@hostאו :[email protected] - תלוי איך הצומת הוגדר (:none | :shortnames | :longnames).

ניהול אפליקציות מבוזרות

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

היתרון העיקרי בשימוש קלוסטר הוא שהוא מבצע את כל הפעולות הדרושות כדי לבנות מחדש את האשכול לאחר שינוי טופולוגיה מתחת למכסת המנוע. האפליקציה פשוט פועלת בסביבה מבוזרת מוכנה כבר, כאשר כל הצמתים מחוברים, ללא קשר אם אנו יודעים את כתובות ה-IP ולכן את שמות הצמתים מראש, או שהם הוקצו/שונו באופן דינמי. זה לא מצריך הגדרות מיוחדות של תצורת Docker ומנקודת מבטו של מפתח יישומים, אין הבדל בין ריצה בסביבה מבוזרת או ריצה בסביבה מקומית. :nonode@nohost. אתה יכול לקרוא עוד על זה ב תיעוד.

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

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

מקור: www.habr.com