מערכת ניהול תצורת רשת לסינון Qrator

TL; DR: תיאור של ארכיטקטורת שרת-לקוח של מערכת ניהול תצורת הרשת הפנימית שלנו, QControl. הוא מבוסס על פרוטוקול תעבורה דו-שכבתי שעובד עם הודעות עמוסות ב-gzip ללא ביטול דחיסה בין נקודות קצה. נתבים ונקודות קצה מבוזרים מקבלים עדכוני תצורה, והפרוטוקול עצמו מאפשר התקנה של ממסרי ביניים מקומיים. המערכת בנויה על העיקרון גיבוי דיפרנציאלי ("יציב לאחרונה", מוסבר להלן) ומשתמש בשפת השאילתה JMESpath יחד עם מנוע התבניות Jinja לעיבוד קובצי תצורה.

Qrator Labs מפעילה רשת הפצה גלובלית לצמצום התקפות. הרשת שלנו פועלת על פי עיקרון anycast, ורשתות משנה מתפרסמות באמצעות BGP. בהיותנו רשת BGP anycast הממוקמת פיזית במספר אזורים של כדור הארץ, אנו יכולים לעבד ולסנן תעבורה לא לגיטימית קרוב יותר לליבה של האינטרנט - מפעילי Tier-1.

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

בהתחלה הייתה המילה. זה הפך מהר מאוד לפרוטוקול תקשורת הזקוק לעדכון.

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

כתוצאה מכך, הגענו לתכנית הבאה:

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

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

MTR מפראג לסינגפור

אותו דבר לגבי הונג קונג

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

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

עיצוב יציב לאחרונה

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

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

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

ארכיטקטורה של תחבורה דו-מפלסית

מדוע בנינו את התחבורה שלנו בשני מפלסים? התשובה היא די פשוטה - רצינו לנתק ניתוב מהיגיון ברמה גבוהה, תוך קבלת השראה ממודל ה-OSI עם שכבות התחבורה והיישום שלו. השתמשנו ב-Thrift לתפקיד פרוטוקול התחבורה, ובפורמט הסדרת msgpack לפורמט ברמה גבוהה של הודעות בקרה. זו הסיבה שהנתב (מבצע שידור/שידור/ממסר) לא מסתכל בתוך msgpack, לא פורק או אורז את התוכן אחורה, ורק מעביר נתונים.

Thrift (מאנגלית - "thrift", מבוטא [θrift]) היא שפת תיאור ממשק המשמשת להגדרה ויצירת שירותים עבור שפות תכנות שונות. זוהי מסגרת לשיחות פרוצדורות מרחוק (RPC). משלב צינור תוכנה עם מנוע יצירת קוד לפיתוח שירותים שעובדים בצורה פחות או יותר יעילה וקלה בין שפות.

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

ישנן אפשרויות אחרות, כגון protobuf / gRPC, אולם כאשר התחלנו את הפרויקט שלנו, gRPC היה די חדש ולא העזנו לקחת אותו לסיפון.

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

Msgpack דומה ל-JSON, אך מהיר וקטן יותר. זהו פורמט של סידור נתונים בינארי המאפשר החלפת נתונים בין מספר שפות.

ברמה הראשונה יש לנו Thrift עם המידע המינימלי הדרוש לנתב כדי להעביר את ההודעה. ברמה השנייה יש מבני msgpack ארוזים.

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

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

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

כדי ליצור קובץ תצורה, אנו זקוקים לבקשת JMESPath, תבנית עבור מיקום הקובץ ב-FS ותבנית עבור התצורה עצמה. כמו כן, מומלץ בשלב זה להבהיר את הרשאות הקובץ. כל זה שולב בהצלחה בקובץ אחד - לפני תחילת תבנית התצורה, שמנו כותרת בפורמט YAML שמתארת ​​את השאר.

לדוגמה:

---
selector: "[@][[email protected]._meta.version == `42`] | items([0].fft_config || `{}`)"
destination_filename: "fft/{{ match[0] }}.json"
file_mode: 0644
reload_daemons: [fft] ...
{{ dict(match[1]) | json(indent=2, sort_keys=True) }}


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

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

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

תודה על עזרתך בכתיבת החומר. VolanDamrod, סרנהייט, לֹא.

גרסה אנגלית הודעה.

מקור: www.habr.com