მრავალ ჩრდილოვანი ბირთვი

მრავალ-ჩრდილოვანი ბირთვი არის პლატფორმის/პროდუქტის ძირითადი ფენა, რომელიც ემსახურება ბევრ დამოუკიდებელ მომხმარებელს (ტენანტს) საერთო რესურსებზე გარანტირებული იზოლაციით, კონტროლირებადი ლიმიტებით და უსაფრთხო კასტომიზაციით. კარგად შექმნილი ბირთვი ამცირებს TCO- ს, აჩქარებს ონბორდინგს, ამარტივებს გამოშვებებს და უზრუნველყოფს პროგნოზირებულ ხარისხს თითოეული გამქირავებლისთვის.

1) მოიჯარე და იზოლაციის საზღვრები

განმარტებები

ტენანტი (Tenant/Org/Account): ლოგიკური ორგანიზაცია საკუთარი მომხმარებლებთან, მონაცემებთან, პოლიტიკოსებთან და შეზღუდვებთან.
იზოლაცია: ერთი მოიჯარის გავლენის თავიდან აცილების შესაძლებლობა სხვის მონაცემებზე, პროდუქტიულობასა და უსაფრთხოებაზე.

იზოლაციის დონე

1. მონაცემები: ინდივიდუალური BD/სქემები/ცხრილები, დაშიფვრა „მოიჯარის გასაღებით“, ფილტრები 'tenant _ id'.
2. გამოთვლები: კვოტები CPU/RAM/IO, ვარჯიშების აუზები ტენანტზე ან „შეჩერებული“ ხაზები.
3. ქსელი: სეგმენტი, პირადი endpoints/VPN, იჯარის ნებართვების სიები.
4. ოპერაციები: მიგრაცია, ზურგჩანთები, DR და ინციდენტები „ერთი მოიჯარეზე“ ზემოქმედების საზღვრებით.

მრავალმხრივი ნიმუშები

Silo (მკაცრი იზოლაცია): ცალკეული მტევანი/BD ტენანტისთვის. მაქსიმალური უსაფრთხოება, მაღალი ფასი.
აუზი (ზოგადი რესურსები): ზოგადი ინფრასტრუქტურა ლოგიკური იზოლაციით; საუკეთესო ეფექტურობა უფრო მაღალია, ვიდრე „neighbor neighbor“ რისკი.
Bridge/Hybrid: ჰიბრიდი - საერთო საკონტროლო თვითმფრინავი + შერჩევით „silo“ VIP/რეგულირებადი მომხმარებლებისთვის.

2) ქირავნობის მოთხოვნების იდენტიფიკაცია და მარშრუტიზაცია

მოიჯარის ნებართვა (Tenant Resolution)

დომენში: 'https ://{ tenant} .example. com`

გზაზე: '/t/{ tenant }/... '

სათაურით: 'X-Tenant-Id', 'X-Org' (ხელმოწერის შემოწმება)

ნიშნის მიხედვით: სტიგმები 'tenant _ id', 'org _ id', 'plan', 'scopes'

მარშრუტიზაცია

L7 კარიბჭე (API კარიბჭე/Ingress) ამოიღებს 'tenant _ id', ამდიდრებს კონტექსტს ('plan', ლიმიტები, რეგიონი), წერს ტრეისებს/ლოგებს.
ფუნქციური სერვისები იღებენ კონტექსტს „მხოლოდ კითხვისთვის“; გადაწყვეტილებები მარშრუტზე და ლიმიტებზე იღებს გეითვეის/პოლისის ძრავას.

3) მონაცემები და სქემები: სტრატეგიები

შენახვის პარამეტრები

Shared-schema, row-level: ცხრილების ერთი ნაკრები, ველი 'tenant _ id', მკაცრი RLS (Row-Level Security).
Shared-DB, per-schema: ერთი DBM, ცალკეული სქემა ტენანტზე; ბალანსი კონტროლსა და იზოლაციას შორის.
Per-DB/cluster: ცალკეული BD/მტევანი ტენანტზე; უფრო ძვირი, უფრო ადვილია სუვერენული მოთხოვნებისთვის.

ძირითადი პრაქტიკა

ყველგან აშკარად გადმოგცეთ 'tenant _ id' და შეიტანეთ იგი კომპონენტურ გასაღებებში/ინდექსებში.
RLS/DBMS + წვდომის პოლიტიკოსები „ორმაგი საკეტის“ სერვისის ხელშემწყობი.
დაშიფვრა: საკვანძო იერარქია (root KMS-key-envelope ტენანტზე DEK ობიექტისთვის).
არქივი/retenshny და „დავიწყების უფლება“ მართავენ პოლიტიკოსებს მოიჯარის დონეზე.

4) პარამეტრები, ფიჩები და ვერსიები

ტენანტის კონფიგურაცია

ცხრილი/საცავი 'tenant _ config' (გეგმა, კვოტები, ფიგურის დროშები, ლოკალიზაცია, SLA).
კონფიგურაციის პრიორიტეტები: ნაგულისხმევი - გეგმა - ტენანტი და გარემო - მომხმარებელი.
მოკლე TTL- ით ჩამორთმევა და ღონისძიების ინვალიდობა.

Fich დროშები და თავსებადობა

ფუნქციების ჩართვა წერტილოვანი (per-tenant/per-cohort), კანარის ჩამოსხმა.
API ვერსიები: სტაბილური კონტრაქტი + გადამყვანები საზღვარზე (ორმაგი/კონტრასტული ფორმატები).

5) ლიმიტები, კვოტები და ბილინგი

მოხმარების პოლიტიკოსები

Rate limiting: 'requests/sec' per tenant/route, „ნიშნის ბაკეტი“ გეგმების პრიორიტეტებით.
É tas: საცავის მოცულობა, ობიექტების რაოდენობა, შეტყობინებები/წთ, jobs/საათი.
Fairness: რიგების „დაბალანსებული გრაფიკი“ + VIP ვორკერების იზოლაცია.

ბილინგი

მრიცხველები 'tenant _ id' (ძლიერი მეტრიკა) - აგრეგატორები - ინვოისი.
საზღვარზე მოქცეული ჭურვები (იდემპოტენტობა და დაცვა მოვლენების დაკარგვისგან).
მოდელები: ფიქსირებული გეგმა + გადაფარვა, პოსტ-პეი/პრე-პეი, ფასდაკლებით „tiered“.

6) უსაფრთხოება და წვდომა

ავთენტიფიკაცია/ავტორიზაცია

OIDC/SAML სტიგმებით 'tenant _ id', 'roles', 'scopes'.
RBAC/ABAC: როლები მოიჯარეზე (Owner/Admin/Reader), პროექტის/განყოფილების ატრიბუტები.
დელეგირებული წვდომა (მომსახურება) mTLS და შეზღუდული ნიშნით.

ნდობის საზღვრები

მოთხოვნის მიღების პოლიტიკოსები: სათაურების ხელმოწერის შემოწმება, nonce/timestamp, წყაროსთან დაკავშირება.
საიდუმლოებები და გასაღებები: per-tenant როტაცია, ცალკეული KMS კონტექსტები, საკვანძო ოპერაციების აუდიტი.
Multi-region & dation residence: tenant pinning რეგიონში, აკონტროლებს ჯვარედინი რეგიონალური ნაკადები.

7) დაკვირვება „მოიჯარეებისთვის“

კვალი და მეტრიკა

სავალდებულო ჭდეები: 'tenant _ id', 'plan', 'region', 'endpoint', 'status'.
SLI/SLO per tenant: `availability`, `p95 latency`, `error budget`.
დაშბორდები და ალერტები სეგმენტების მიხედვით (VIP/რეგულირებადი/ახალი).

ლოგოები და აუდიტი

სამოქმედო ჟურნალები (ვინ/რა/როდის/სად) უცვლელი შენახვით და მოიჯარე პოლიტიკით.
მოვლენების წინასწარი აგრეგაცია იაფი შენახვისთვის, დეტალების აღდგენა „დაწკაპუნებით“.

8) შესრულება და „neighbor neighbor“

ანტი-ხმაურის ზომები

ხაზების/ვორკერების, CPU-shares და IO- ს პერ ტენანტის პროპორციების შეზღუდვები.
ქეშის გამიჯვნა: 'tenant გასაღების პრეფიქსი: {id}:...', TTL გეგმის მიხედვით, დაცვა „cache stampede“ - სგან.
ინდექსები და მოთხოვნის გეგმები 'tenant _ id' სელექციურობის გათვალისწინებით.

ცივი სტარტები და „თბილი“ აუზები

VIP/მწვერვალი ფანჯრებისთვის.
ვორკერების ელასტიური აუზები მეტრიკის სიგნალების მიხედვით (backpressure/autoskaling).

9) განახლებები და მიგრაცია

სტრატეგია

Backward თავსებადი მიგრაცია (expand - migrate - contract).
მიგრაცია „მოიჯარეებზე“: ბრძოლები პროგრესის კონტროლით, „პაუზა/გამოტოვება“ კონკრეტული „tenant _ id“.
სიმულაცია და „კანარის“ მიგრაცია მოიჯარეების ქვესათაურში.

DR და ინციდენტები

DR გეგმა RTO/RPO per tenant; ნაწილობრივი „read-only რეჟიმი“ გლობალური დაუთმობის გარეშე.
ინციდენტის იზოლაცია: 'tenant _ id' ფუზინგი, „ცხელი“ მოიჯარის ჩაქრობა არ მოქმედებს დანარჩენზე.

10) API და ოქმები

REST/gRPC მოიჯარის სავალდებულო კონტექსტით (სტიგმებში/სათაურებში).
მოვლენები (event-driven): ტოპები ნეიმინგის 'tenant. {id} .event', ფილტრები და ACL გამოწერისთვის.
გლობალური შესასვლელი წერტილები: L7 კარიბჭე ხელმძღვანელობს კონტექსტს, იყენებს ლიმიტებს, დაშიფრავს PII ტენანტის პოლიტიკის შესახებ.

11) ქირაობის სასიცოცხლო ციკლი

1. დებულებები: მოიჯარეების ჩანაწერის შექმნა, გასაღებების/ჩამორთმევის წარმოება, რეგიონის კავშირი.
2. გააქტიურება: OIDC/SAML კლიენტის გამოშვება, როლების/პოლიტიკის შექმნა, პირველადი კვოტების შექმნა.
3. ოპერაცია: მონიტორინგი, ბილინგი, დროშების/გეგმების განახლება.
4. შეჩერება/trottling: გაყინვა მონაცემთა/ექსპორტის შენარჩუნებით.
5. მოცილება/ექსპორტი: retenshne, მორცხვი bacaps, crypto-shredding.

12) არქიტექტურის მინი სტანდარტი (სიტყვიერი სქემა)

Edge (API კარიბჭე): TLS/mTLS, ამონაწერი 'tenant _ id', ლიმიტები, აუდიტი.
Control Plane: მოიჯარეების კატალოგი, კონფიგურაცია, წინა დროშები, ბილინგი, პოლიტიკა.
Data Plane (სერვისები): სახელმწიფო სერვისები, ხაზები, ვორკერები კვოტებით; Redis/kv ტენიანობის პრეფიქსებით.
სცენა: RLS-BD/ინდივიდუალური სქემები/BD; KMS ქირაობის კლავიშებით; ობიექტის საცავი envelope დაშიფვრის საშუალებით.
Observability: tracing/მეტრიკა/logs 'tenant _ id', alerty per plan.
ადმინი: იზოლირებული ოპერაციები (მიგრაცია/ზურგჩანთები) მოიჯარეების ქვესათაურზე.

13) საკონტროლო სია გაყიდვამდე

• საზღვარზე და მომსახურებებში 'tenant _ id' განსაზღვრის ერთიანი მეთოდი.
• RLS/ACL პოლიტიკოსები შემოწმებულია ტესტებით და „უარყოფითი სცენარებით“.
• კვოტები/ლიმიტები/ბილინგი ვალიდდება რეალურ დატვირთვებზე; არსებობს დაცვა „ბილინგის თვითმფრინავებისგან“.
• დაკვირვება და SLO per tenant; ალერტები VIP/რეგულირებადი.
• მიგრაციები თავსებადია, არის ნაწილობრივი გამოტოვება და საარტილერიო ბრძოლები.
• DR სცენარები RTO/RPO per tenant და რეგულარული წვრთნები.
• „მოიჯარის გასაღების“ დაშიფვრა, გასაღების როტაცია და აუდიტი.
• API/ღონისძიებების კონტრაქტების დოკუმენტაცია და ვერსიის პოლიტიკა.

14) ტიპიური შეცდომები

გლობალური მიგრაცია „ერთი ბეწვით“ პრობლემური მოიჯარეზე შეჩერების გარეშე.
ფარული დამოკიდებულება 'tenant _ id' ქეში/რიგებში - მონაცემთა გაჟონვა/რიგების გადაკვეთა.
კონტექსტების ნაზავი (admin ოპერაციები შემთხვევით 'tenant _ id').
„ორმაგი ციხის“ არარსებობა: მხოლოდ მომსახურების შემოწმება RLS- ის გარეშე BD- ში.
მთელი კლასტერის ერთი ლიმიტი არის „neisy neighbor“ და SLO დარღვევა.
გაუმჭვირვალე ბილინგი იდემპოტენტურობისა და აუდიტის ბილიკის გარეშე.

15) სტრატეგიის სწრაფი შერჩევა

მკაცრი იზოლაცია/რეგულირება: Silo (ცალკეული DD/კლასტერის), რეგიონი-ლოკი.
დაბალანსებული ეფექტურობა: Shared-DB per schema + RLS, გასაღებები per tenant.
მაღალი რეალური ტრაფიკი: საერთო ხაზები „შეჩერებული“ კვოტებით და VIP- ისთვის გამოყოფილი ვორკერები.
მრავალი კასტომია: fich დროშები + API გადამყვანები, პრიორიტეტების მიხედვით კონფიგურაციების შენახვა.

დასკვნა

მრავალ ჩრდილოვანი ბირთვი არის საინჟინრო საზღვრების დისციპლინა: აშკარა განმარტება 'tenant _ id', მკაცრი იზოლაცია ყველა ფენაზე, კონტროლირებადი კვოტები და გამჭვირვალე ბილინგი, პლუს დაკვირვება და გამოშვებების თავსებადობა. აღწერილი ნიმუშების შემდეგ საშუალებას გაძლევთ შეაფასოთ პროდუქტი თითოეული მოიჯარეისთვის უსაფრთხოების, ხარისხისა და ცვლილების სიჩქარის გარეშე.