ליבת רב ־ דייר

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

1) מודל דייר וגבולות בידוד

הגדרות

Tenant/Org/Account - ארגון לוגי עם משתמשים, נתונים, מדיניות ומגבלות משלו.
בידוד: היכולת למנוע מדייר אחד להשפיע על הנתונים, הביצועים והביטחון של דייר אחר.

רמות בידוד

1. נתונים: מסדי נתונים/סכמות/טבלאות, הצפנה עם "מפתח הדייר", מסננים "דייר _ id'.
2. חישובים: CPU/RAM/IO מכסות, מאגר עובדים או תורים משוקללים.
3. רשת: מקטע, נקודות קצה פרטיות/VPN, רשימות של אישורים על ידי דייר.
4. פעולות: נדידה, גיבוי, ד "ר ותקריות עם גבולות השפעה" לכל דייר ".

תבניות רב-שכבתיות

סילו (בידוד קשה): אשכולות/מסדי נתונים בודדים לדייר. אבטחה מרבית, מחיר גבוה.
בריכה: תשתית משותפת עם בידוד הגיוני; יעילות טובה יותר, סיכון גבוה יותר של ”שכן רועש”.
Bridge/Hybrid: מטוס שליטה היברידי - נפוץ + סלקטיבי ”סילו” ללקוחות VIP/מוסדרים.

2) זיהוי וניתוב של בקשות הדייר

רזולוציית דייר

לפי התחום: https ://detenant. &fospos

לאורך הדרך: ”/t/דייר/”..

לפי הכותרת: "X-Tenant-Id'," X-Org "(אימות חתימה)

על ידי אסימון: בולים 'דייר _ id', 'org _ id',' תוכנית ',' scopes&ft

ניתוב

השער L7 (API gateway/Ingress) מחלץ את הדייר _ id, מעשיר את ההקשר ('תוכנית', גבולות, אזור), וכותב לשבילים/לוגים.
שירותי פונקציה מקבלים את ההקשר לקריאה בלבד; החלטות על המסלול והגבולות מתקבלות על ידי מנוע השער/מדיניות.

3) נתונים ותרשימים: אסטרטגיות

אפשרויות אחסון

סכימה משותפת, רמה שורה: קבוצה אחת של טבלאות, שדה RLS קפדני (Row-Level Security).
Shared-DB, per-schema: DBMS אחד, סכימה נפרדת לדייר; איזון בין שליטה ובידוד.
פר-די-בי/אשכול: מסד נתונים נפרד/אשכול לדייר; יקר יותר, קל יותר לתביעות ריבוניות.

מנהגי מפתח

בכל מקום עובר במפורש 'דייר _ id' וכולל אותו במפתחות/אינדקסים מורכבים.
מדיניות גישה ברמת RLS/DBMS + אימות שירות נעילה כפולה.
הצפנה: היררכיית מפתח (root KMS # key-terelope per derenant = DEK per object).
ארכיון/שימור ו ”זכות להישכח” מנוהלים על ידי מדיניות ברמת הדייר.

4) הגדרות, תכונות וגרסאות

תצורות דייר

טבלה/אחסון ”tenant _ config” (תוכנית, מכסות, דגלים, לוקליזציה, SLA).
סדרי עדיפויות של הגדרות: תוכנית product program = derenant = secondary ach user.
הגדרות מזומנים עם TTL קצר ונכות על ידי אירוע.

תכונה דגלים ותאימות

פונקציות מאפשרות נקודה (לכל דייר/פר-קוהורט), גלגול קנרי.
API versioning: חוזה יציב + מתאם בגבול (בחזרה/קדימה-תואם פורמטים).

5) מגבלות, מכסות וחיובים

מדיניות הצריכה

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

חיוב

conters by 'terant _ id' (מדדי שימוש) <achoice acgregators.
תצלומי שימוש על הגבול (אידמפוטנטיות והגנת אובדן אירועים).
מודלים: תוכנית קבועה + צריכה, לאחר תשלום/תשלום מראש, הנחות ”נטו”.

6) ביטחון וגישה

אימות/אישור

OIDC/SAML עם הסימנים "דייר _ id'," תפקידים "," סקופים ".

RBAC/ABAC - תפקידים ברמת הדייר (בעלים/אדמין/קורא), תכונות פרוייקט/מחלקה

שירות לשירות עם mTLS ואסימונים מוגבלים.

גבולות אמון

בקשות למדיניות קבלה: אימות חתימת כותרת, nunce/timamp, מחייב מקור.
סודות ומפתחות: סיבוב לכל דייר, קשרים אישיים של KMS, ביקורת של פעולות מפתח.
תושבות נתונים רב-תחומית: הצמדת דייר לאזור, זרימות חוצות-אזוריות מבוקרות.

7) יכולת תצפית ”על ידי דיירים” ‏

עקבות ומטרים

תגיות נדרשות הן "דייר _ id'," תוכנית "," אזור "," נקודה אחרונה "," מצב ".
SLI/SLO לדייר: ”זמינות”, ”p95 latency”, ”תקציב שגיאה”.
לוחות מחוונים והתראות לפי קטע (VIP/רגולרי/חדש).

יומנים וביקורת

רישומי פעילות (who/what/when/where) עם אחסון ושמירה בלתי ניתנים לשינוי בהתאם למדיניות הדייר.
קדם צבירה של אירועים לאחסון זול, שחזור של פרטים ”על ידי לחיצה”.

8) ביצועים ו ”שכן רועש” ‏

אמצעי נגד רעש

מגבלות על רמת התורים/עובדים, מניות מעבד ו-IO-פרופורציה לדייר.
הפרדת מטמון: דייר מקדים מפתח: ', TTL על ידי תוכניות, הגנה מפני ”מנעול מטמון”.
אינדקסים ותוכניות שאילתה המבוססות על סלקטיביות של דייר _ id.

קר מתחיל ובריכות ”חמות”

חימום מראש לחלונות אח "מים/פסגה.
בריכות אלסטיות של עובדים המבוססות על אותות מטריים (backpressure/autoscaling).

9) שדרוגים ונדידות ללא הפסקה

אסטרטגיה

נדידה לאחור-תואמת (התפשטות = Trangate Action).
הגירה ”על ידי דיירים”: חבורות עם בקרת התקדמות, ”pause/rollback” עבור דייר מסוים _ id'.
דגימות ונדידה ”כנרית” על תת-קבוצה של דיירים.

DR ותקריות

DR תוכנית עם RTO/RPO לדייר; ”מצב קריאה בלבד” חלקי ללא השבתה גלובלית.
בידוד התקרית: פיוז על ידי דייר _ id, כיבוי הדייר ”חם” לא משפיע על השאר.

10) אפילים ופרוטוקולים

REST/gRPC עם הקשר דייר חובה (בבולים/כותרות).
אירועים (מונע אירוע): נושאים עם שם 'דייר. event', מסננים ו ACL למנויים.
נקודות כניסה גלובליות: השער L7 נותן תוקף להקשר, מחיל גבולות, מצפין את המח "ש בהתאם למדיניות הדייר.

11) מחזור חיים של דייר

1. מעורר: יצירת שיא דייר, יצירת מפתחות/תצורה, קישור אזור.
2. הפעלה: שחרור לקוח OIDC/SAML, יצירת תפקידים/מדיניות, מכסות עיקריות.
3. מבצע: מעקב, חיוב, עדכוני דגל/תוכנית.
4. להשעות/לחנוק: להקפיא עם שמירת נתונים/יצוא.
5. מחיקה/ייצוא: שימור, גיבויים מותפלים, גריסת קריפטו.

12) ארכיטקטורת מיני-התייחסות (תוכנית מילולית)

אדג '(שער API): TLS/mTLS, חילוץ' terant _ id', גבולות, ביקורת.
מטוס בקרה: קטלוג של דיירים, תצורות, דגלים, חיובים, פוליטיקה.
Data Plane (שירותים): שירותים חסרי פסלים, תורים, מכסות עובדים; redis/kv מוקדם על ידי דייר.
אחסון: RLS-DB/תבניות בודדות/DB; KMS עם מפתחות לדייר; אחסון אובייקטים עם הצפנת מעטפה.
תצפית: איתור/מטריות/יומנים עם תג "tenant _ id', התראות לכל תוכנית.
אדמין: פעולות מבודדות (נדידה/גיבויים) על תת-קבוצה של דיירים.

13) רשימת בדיקות לפני המכירה

[ ] דרך אחת להגדיר דייר _ id בגבול ובשירותים.

[ מדיניות RLS/ACL ] נבחנת עם בדיקות ו ”תסריטים שליליים”.

[ ] מכסות/גבולות/חיובים מותנים בעומסים אמיתיים; יש הגנה מפני ”טיפות חיוב”.

[ ] תצפית ו ־ SLO לדייר; התראות לאח "מים/מוסדרים.

[ ] הנדידה תואמת, יש גלגול חלקי וקבוצות השאלות.

[ ] תרחישי DR עם RTO/RPO לדייר ותרגילים קבועים.

[ ] הצפנת מפתח דייר, סיבוב מפתח, וביקורת מפתח.

[ תיעוד ] של חוזי API/אירועים ומדיניות הסברה.

14) שגיאות אופייניות

נדודים גלובליים ”במכה אחת” ללא היכולת לעצור דייר בעייתי.
תלות חבויה במטמון/תורים של דליפת נתונים/תור.
ערבוב הקשר (פעולות ניהול בטעות ללא "terant _ id').
היעדר ”מנעול כפול”: בדיקת שירות בלבד ללא RLS במסד הנתונים.
מגבלה אחת לכל אשכול = ”שכן רועש” והפרת SLO.
חיוב לא שקוף ללא אידמפוטנטיות ושביל ביקורת.

15) בחירת אסטרטגיה מהירה

בידוד/תקנה קפדנית: Silo (מאגרי נתונים/אשכולות נפרדים), אזור-נעול.
יעילות מאוזנת: Shared-DB per schema + RLS, מפתחות לדייר.
תנועה בזמן אמת: תורים משותפים עם מכסות "משוקללות" ועובדים ייעודיים לאח "מים.
התאמות רבות: דגלי תכונה + מתאם API, אחסון תצורות לפי עדיפות.

סיכום

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