מרכזי נתונים

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

הפלטפורמה כבר לא שוכרת לוח בקרה של מישהו אחר. proxmox.farm_enabled הוא true בקונפיגורציה שנשלחת, 12 סוגי אפליקציות כשירים ל-farm, ו-'datacenter' ראשון ברשימה הזו. פריסה של אחד כזה היא מתודה מוצהרת אחת, deploy_datacenter, וההצהרה שלה קובעת מי רשאי לקרוא לה: clearance 'admin', min_plan 'pro', private: true. השילוב הזה אומר סשן בלוח הבקרה במסלול Pro ומעלה, ואומר ששום מפתח API, בכל מצב שהוא, לא מגיע אליה, כי private הוא החומה. זו אחת מתוך 19 מתודות בלבד, מתוך 1010 שבקונפיגורציה שבמאגר, שנושאות רף מסלול כלשהו. הבחירה היא מתוך 14 קודי מטרופולין ו-16 גדלי שרת, מ-shared_hosting_1 ועד large_hosting_32, ומה שחוזר הוא מסמך אפליקציה עם app_type 'datacenter' וסיסמת אדמין ל-CouchDB בת 20 תווים שנוצרת מחדש ונשמרת על המסמך כ-couchdb_admin_password. ב-farm המכונה הווירטואלית הזו היא שכפול מלא של תבנית הזהב שלה ב-Proxmox, vmid 9101; כל סוג אחר שכשיר ל-farm ואינו VPS משכפל במקום זאת את אימג' הפריסה המשותף. עוד נקודה שראוי לומר בפירוש לפני המשך העמוד: תיאור הקטלוג של deploy_datacenter עדיין אומר שהוא יוצר droplet ב-DigitalOcean, והפונקציה שהוא קורא לה עדיין נקראת create_digitalocean_droplet, אף שהפונקציה הזו מעבירה את היצירה ל-Proxmox עוד לפני ש-DO נשקל בכלל. השם ישן יותר מהחומרה.

clearance admin, min_plan pro, private
14 מטרופולינים, 16 גדלי שרת
תבנית זהב vmid 9101
מרכז נתונים הוא אפליקציה שבבעלותך, על חומרה ש-Xuda מפעילה.
מסוף ההפצה

מה פרסום מדפיס בפועל.

פרסום הוא הפצה, לא העתקת קבצים. הוא בוחר את מסמכי xuda_servers שבהם docType 'regional_server', application_server true ו-stat 1, ואז עובר עליהם אחד אחרי השני וכותב stat 2 publishing, 3 done או 4 failed עם stat_ts על כל אחד. כל אזור מנוקז מהרוטציה לפני שנוגעים בו, והניקוז נדחה אם זהו האזור התקין האחרון. החלק ההרסני רץ מנותק תחת setsid מתוך /tmp על מכונת היעד, ולכן הוא מסתיים גם אם המתזמר, ה-broker או חיבור ה-SSH מתים באמצע, וההפצה אז מתשאלת סמן סטטוס במשך עד 25 דקות תוך קריאת יומן ההתקנה המרוחק לפי היסט בייטים. אלה השורות שלו.

[publish master] mode=soft
soft מחלץ מעל ההתקנה הקיימת כך ש-node_modules שורד. publish_mode hard מוחק קודם את /var/xuda
[publish master] drained from rotation; waiting 40s for CF to shift traffic
הניקוז הוא touch אחד של /run/xuda-draining. לאחר מכן /health עונה 503 והקצה משמיט את האזור ברענון שלו, בערך כל 30 שניות
[publish master] copying server.zip... <sent>/<total> MB
פעימה כל 15 שניות, שנקראת עם stat -c %s על מכונת היעד בזמן שההעתקה רצה
[publish master] server.zip copied (<total> MB)
[publish master] <every line of the remote install log, tailed by byte offset, no repeats>
[publish master] undrained; rejoins rotation within ~30s
אחר כך stat 3 ו-stat_ts על המסמך, והאזור הבא מתחיל. אף פעם לא שניים בבת אחת
[publish eu] left DRAINED (out of rotation); fix + redeploy, auto-rejoins in ~15m
מסלול הכישלון: stat 4, publish_error שנחתך ל-500 תווים, וההפצה ממשיכה במכוון
שתי שורות נושאות את כל מודל הבטיחות. שורת הניקוז היא הסיבה שהתקנה מחדש אינה נראית למשתמשים. שורת left-DRAINED היא הסיבה שגם אזור שבור נשאר בלתי נראה, וכדאי לשים לב מה מחזיר אותו: לא פסיקה שהוא תוקן, אלא דגל הניקוז שפג אחרי 15 דקות על טיימר.
47

תהליכי pm2 שאזור מרים מקובץ אחד

4

מצבי פרסום שמסמך אזור עובר דרכם

20%

קיבולת פנויה שצומת צריך מעבר לבקשה שלך

25 דק'

תקרה לכל מכונה לפני שההפצה מכריזה על פקיעת זמן

אותה חומרה, שני דיירים

Xuda רצה על ה-farm הזה באותו אופן שבו רץ מרכז הנתונים שלך.

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

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

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

configure_datacenter_replication מקבל ארבעה דברים: replicate_type, חד־פעמי או רציף; replicate_from, master או datacenter; replicate_direction, one_way או two_way; ו-apply, שכאשר הוא false שומר את ההגדרה בלי להריץ אותה, כך שפתיחה מחדש של זריעה שהסתיימה לא מעתיקה את הנתונים פעמיים. כל מה שמעבר לזה הוא CouchDB רגיל. הפלטפורמה מוסיפה צנרת: היא יוצרת את מסד הנתונים _replicator אם אין כזה בנקודת הקצה, כותבת מסמך אחד לכל כיוון, מפרקת קודם את הזוג הקודם, ומצמצמת את מה שעובר באמצעות selector. הנקודות שלהלן אומרות איזה מצב קיים אחרי לחיצה על שמירה, כי באחד משני המצבים התשובה היא שאין.

  • בחירה ברציף הופכת למסמך. replicate_datacenter בונה את replicate_opt עם create_target: false, מוסיף continuous: true, ושומר אותו במסד הנתונים _replicator של נקודת הקצה שנבחרה, ויוצר את מסד הנתונים הזה קודם אם הוא חסר. בחירה בחד־פעמי אינה מסמך כלל: היא קוראת ל-replicate_couch_start פעם אחת, ההעתקה רצה, ולא נשאר באשכול דבר שמתאר אותה. אותו דיאלוג, שתי כמויות שונות מאוד של מצב מתמשך, בקובץ cpi/deploy_module/index.mjs שורה 7302.
  • דו־כיווני הוא שתי משימות חד־כיווניות שמכוונות זו אל זו. המסמך הראשון נקרא על שם מזהה האפליקציה עם _1 בסופו, כאשר source ו-target הם שתי כתובות ה-URL ומסדי הנתונים שלהן. הדגל two_way כותב מסמך שני, _2, זהה פרט לכך ש-source ו-target מוחלפים. הפירוק מניח את המבנה הזה: delete_prev_replications מסיר את _1 ואת _2 משתי נקודות הקצה ומנקה את replication_stat לפני שנכתב משהו חדש.
  • ה-selector קובע מה עובר, והוא גס במכוון. רפליקציה מ-master מגדירה את replicate_opt.selector כ-$or על docType workspace_drive ועל docType database, כך שמטא-נתונים של הדרייב ושורות טבלה עוברים ושאר הפרויקט לא. scope setup ו-scope custom מצמצמים רק את ענף ה-database, ומוסיפים udfData.udffileid $in לרשימת מזהי טבלאות שנקראת ממסמכי הטבלאות של Studio.
  • מה שהיא לא עושה. שום דבר לא מקדם עותק לתפקיד ראשי, שום דבר לא מסיט תעבורה, ושום דבר לא מיישב split brain מעבר לכך ש-CouchDB בוחר גרסה מנצחת דטרמיניסטית ומשאיר את המפסידה כקונפליקט. ו-CouchDB משכפל את מסמכי הדרייב, לא את הקבצים: תיקיית workspace_drive שעל הדיסק מסונכרנת בנפרד ב-rsync, דרך /tmp כך ששתי המכונות הווירטואליות אף פעם לא מתחברות זו לזו ב-SSH, כזריעה חד־פעמית. הטיימר שהיה הופך את סנכרון התיקייה לרציף עדיין מסומן TODO בקוד המקור.
מה שמירה אחת מריצה בפועל
  1. שמירת ארבעת השדות
    clearance admin, private, בבעלות app_module. apply: false עוצר כאן ולא כותב דבר ל-CouchDB.
  2. מחיקת הזוג הקודם
    _1 ו-_2 מוסרים משתי נקודות הקצה, replication_stat מתנקה. שמירה חוזרת מחליפה, לעולם לא ממזגת.
  3. בניית replicate_opt
    create_target: false תמיד, continuous: true רק עבור רציף, ו-selector עם $or רק מ-master.
  4. כתיבה, או הרצה חד־פעמית
    רציף כותב מסמך אחד לכל כיוון. חד־פעמי שולח רפליקציה אחת, ואז מוסיף אישור.
היכן זה יכול לנחות

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

שדה האזור נושא 14 קודי מטרופולין, והבורר מקבץ אותם לחמישה אזורי-על שמוגדרים ב-MACRO_REGIONS בקובץ cpi/deploy_module/index.mjs שורה 9515. כל רשומה מחזיקה שתי רשימות: farm_locations, אתרי ה-xuda Farm שהאזור מחזיק, ו-do_slugs, קידומות ה-slug של DigitalOcean שהוא מחזיק. בחירת אזור אינה בוחרת ספק ואינה בוחרת מכונה. היא מצמצמת את קבוצת המועמדים לשתי הרשימות האלה, וכל השאר הוא שיבוץ.

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

אזורי, גלובלי, או כזה שכבר מופעל אצלך.

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

אזורי (DigitalOcean)
גלובלי (xuda Farm)
כזה שכבר מופעל אצלך
מקור האימג'אימג' מוכן מראש של DigitalOcean: create_digitalocean_droplet נקרא כאשר image_id מוגדר ל-digitalocean.datacenter_image_id, שהוא 198689047 בקונפיגורציה שבמאגר.שכפול מלא של תבנית זהב של Proxmox, vmid 9101, שמוצהרת כ-proxmox.templates.datacenter_vmid. כל סוג אחר שכשיר ל-farm ואינו VPS משכפל את תבנית הפריסה המשותפת. המארחים הם מכונות עצמאיות בלי אחסון משותף, ולכן מארח שחסר לו 9101 מקבל אותה בהעברה עם vzdump אל PBS ואז qmrestore, דרך ה-REST API.אין. שום דבר לא עולה. הפריסה מקבלת config.json שנושא datacenter_id ו-DSN של מרכז הנתונים, וזה כל החיבור.
מסלול הגיבויתמונת מצב של droplet. המזהה שנשמר על מסמך האפליקציה הוא snapshot_image_id, ושחזור מעביר את מזהה האימג' הזה ל-droplet חדש.ברמת ההיפרוויזור. vzdump כותב אל מאגר הנתונים של PBS והמשימה מתורגמת ל-PBS volume id, המזהה גם לשחזור וגם למחיקה. שחזור מחליף את אותו vmid במקומו, או בונה מכונה וירטואלית חדשה מהארכיון.מה שכבר מכסה את המכונה הזו. הפריסה המחוברת שומרת את הנתונים שלה ב-db_<datacenter_id> על מרכז הנתונים, ולכן היא מוגנת בדיוק כשמרכז הנתונים מוגן ולא מעבר לכך.
מקור המחירה-slug. כל אחד מ-16 סוגי השרתים הוא רשומה ב-PRICE_OBJ.server_slugs עם cpu, ram ו-disk קבועים ומחיר חודשי קבוע, החל מ-shared_hosting_1 עם 1 vCPU, 2 GB ו-50 GB.compute_farm_price: ליבות כפול תעריף ה-cpu של הדרגה, ועוד RAM כפול תעריף ה-ram, ועוד דיסק כפול תעריף ה-disk. כל קלט נחתך למקסימום של הדרגה, הסכום מקבל רצפה במינימום של הדרגה, והתוצאה מעוגלת ל-10 הסנט הקרובים.שום דבר חדש לא מחושב. החיבור לא יוצר שרת, ולכן הוא לא מייצר לא מחיר slug ולא תעריף farm.
סירוב על רקע קיבולתלא גלוי מהצד שלך. שום חישוב מרווח לא רץ כאן, ויצירה שהספק לא יספק חוזרת כשגיאה של הספק ולא כקוד של ה-farm.get_farm_server מכפיל את הליבות, ה-RAM והדיסק שביקשת ב-1 ועוד proxmox.headroom_pct חלקי 100, כרגע 20 אחוז, לפני שהוא משווה אותם לקיבולת הפנויה של כל צומת. אם אף צומת לא עומד בזה ו-proxmox.do_failover הוא false, היצירה נדחית עם -462 ואינה נכנסת לתור. אזור עם רשימות ריקות דוחה מוקדם יותר, עם -463.אין בדיקה בכלל. שיבוץ אף פעם לא רץ בחיבור, ולכן שום דבר לא מוודא שיש למכונה מקום למסד נתונים נוסף לפני שה-DSN נכתב.
איך משיגים אחד

שלושה מהלכים מכלום ועד מרכז נתונים עם פריסות עליו.

זו אינה פעולת API בשירות עצמי. deploy_datacenter מוצהר עם clearance admin, min_plan pro ו-private: true, ולכן מדובר בסשן של לוח הבקרה במסלול Pro ומעלה ושום מפתח API בשום מצב לא מגיע אליו. זו אחת מ-19 מתודות בלבד בקונפיגורציה שבמאגר שנושאות רף pro, מתוך 1010 מוצהרות.

  1. 01

    הצהרה עליו

    שם, אזור מתוך 14 קודי המטרופולין, וסוג שרת מתוך 16 הגדלים שנעים מ-shared_hosting_1 עד large_hosting_32. זה כותב מסמך אפליקציה עם app_type datacenter, ועל אותו מסמך, סיסמת אדמין ל-CouchDB בת 20 תווים שנוצרת מחדש תחת couchdb_admin_password. פרטי גישה אחד נוצרים כאן וכל מה שבא אחר כך חולק אותם. רשומת הקטלוג עדיין מתארת את זה כיצירת droplet ב-DigitalOcean, והפונקציה עדיין נקראת create_digitalocean_droplet, אף שהיא מעבירה את היצירה ל-Proxmox קודם. השם מיושן, ההתנהגות לא.

  2. 02

    המכונה עולה ומתקשרת בחזרה

    שום דבר לא מתשאל את המכונה. השירות xuda-firstboot.service שעל המכונה הווירטואלית קורא ב-curl למתודה digitalocean_webhook עם המזהה שלו כעשר שניות אחרי שהרשת עולה, וה-webhook מריץ את ההתקנה: 10 שלבים בעלי שם, מהתחברות לשרת, דרך התעודה בחתימה עצמית וקובצי ה-ini, ועד יצירת מסד הנתונים. לפני שהוא יוצר משהו הוא מתשאל את נקודת הקצה _users של CouchDB על המכונה 10 פעמים, בהפרש של 5 שניות, ומוותר אם היא לא עונה כלל. אחר כך הוא יוצר את db_<app_id>, מריץ את הרפליקציה שהוגדרה, כותב את מסמכי העיצוב והאינדקסים, ורק אז מסמן את השרת כפעיל.

  3. 03

    חיבור פריסות לפי מזהה

    פריסה שמשובצת על מרכז נתונים מקבלת config.json שנושא datacenter_id ו-DSN של מרכז הנתונים שמצביע אל db_<datacenter_id> בכתובת הפרטית של מרכז הנתונים, עם אותם פרטי אדמין שנוצרו בשלב הראשון. זה כל הקישור: בלי סוכן, בלי לחיצת יד של רישום. השניים חולקים סיסמה אחת, ומרכז נתונים על ה-farm יושב מאחורי חומת אש שחוסמת כברירת מחדל עם ipfilter פעיל: 443 מוגבל לטווחי Cloudflare כשהאפליקציה עומדת מאחוריו, CouchDB 5984 רק מה-IPSet של הפרויקט עצמו, ו-SSH רק מהסט xuda_control.

מגבלות בכנות

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

  • שום דבר כאן לא מתרחב מעצמו. צומת שחוצה את proxmox.capacity_alert_pct, שהוא 80, מעלה התראה שהפעולה המומלצת בה היא שאדם יזמין מכונה נוספת, והוא מוצא משיבוץ רק ב-95 אחוז. כאשר proxmox.do_failover הוא false, פריסה שלא מוצאת צומת מתאים נדחית עם קוד -462. היא לא נכנסת לתור, ושום דבר לא גדל כדי להכיל אותה.
  • שניים מתוך חמשת אזורי-העל הם תוויות שאין מאחוריהן דבר. MACRO_REGIONS נותן ל-africa ול-latam רשימת farm_locations ריקה ורשימת do_slugs ריקה, ולכן שיבוץ לא מחזיר שם צומת ומסלול היצירה עונה -463, האזור הזה אינו זמין לפריסה, יש לבחור אחר.
  • אין failover בין אזורים לפרויקט שלך. פרויקט מוצמד לאזור בית, וכשהאזור הזה לא נגיש, קריאה תלוית מיקום חוזרת עם הודעה פשוטה שהעבודה לא התחילה. היא לא רצה בשקט במקום אחר.
  • רפליקציה אינה failover. בוחרים חד־פעמי או רציף, master או datacenter, חד־כיווני או דו־כיווני, וזו כל היכולת. שום דבר לא מקדם עותק לתפקיד ראשי, לא מסיט תעבורה ולא מיישב split brain בשבילך.
  • ההפצה סדרתית לחלוטין, אזור אחד בכל פעם, עם תקרה של 25 דקות למכונה, ומכונה שנכשלת נשארת במכוון מחוץ לרוטציה. היא חוזרת כשדגל הניקוז פג אחרי 15 דקות, על טיימר, ולא בעקבות פסיקה כלשהי על כך שתוקנה.
  • שומר הפרסום הוא בדיקת shell בתוך סקריפטי הבנייה, לא נעילה ברמת הפלטפורמה. הוא מחפש רק stat 1 או 2 על מסמך regional_server, ו-XUDA_SKIP_PUBLISH_GUARD=1 מכבה אותו, וכך בדיוק הפצה שלא הסתיימה נעקפת.
  • התאמת הקיבולת ותשאול בריאות הצמתים רצים על מכונת בקרה אחת בדיוק, וזה במכוון, כי שני סורקים היו מתחרים זה בזה. זה תהליך אחד שמחליט, כל חמש דקות, על אילו צמתים כל ה-farm רשאי לשבץ.
  • מסלול הריפוי העצמי של דיסק אזורי, ניקוי tmp ואז הגדלת הנפח ואז הכרזה שהאזור מלא, נשלח וכבוי: server_capacity_monitor.enabled הוא false בקונפיגורציה שבמאגר, ושלב ההגדלה שלו הוא בכל מקרה קריאת volume של DigitalOcean.
  • כל מספר בעמוד הזה נקרא מהעותק של config.json שבמאגר ומקוד המקור של cpi. ידוע שהקונפיגורציה החיה של master סוטה מהעותק הזה והיא לא נקראה, ולכן כדאי לראות במספרים האלה את צורת הדברים ולא את הסכומים המדויקים של היום.
לפני לחיצה על פריסה

שש השאלות שהעמוד הזה קיים כדי לענות עליהן

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

צפייה

לוח הבקרה שממנו הפריסה מתחילה.

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

בחירת האזור עם כללי הקיבולת מול העיניים.

מרכז נתונים הוא פריסה במסלול Pro עם שתי הכרעות אמיתיות: האזור, 14 קודי מטרופולין, וסוג השרת, 16 גדלים מ-shared_hosting_1 עד large_hosting_32. כדאי להכריע קודם על האזור, כי שיבוץ אף פעם לא חוצה אזור ושום דבר לא גדל כדי להתאים לך. ל-africa ול-latam אין צמתים כלל והם עונים -463, ואזור שהצמתים שלו נמצאים בתוך מרווח 20 האחוזים של הבקשה שלך עונה -462 במקום להכניס אותך לתור. ברגע שזה נוחת, ההתקנה מריצה את 10 השלבים שלה ומסיימת ביצירת db_&lt;app_id&gt; על המכונה, וכל פריסה שתשובץ שם חולקת את אותם פרטי גישה.