معماری چندکسب‌وکاری، تجاری و تجارت الکترونیک · فصل ۱ — Venture Separation، Shared Interface، Resource و Tenant · 222
Resource Broker Metadata
معماری یا تصمیم تجاری را با preference و الگوهای آماده می‌گیرد و constraint/cost/serviceability را مدل نمی‌کند. موضوع جاری: «Resource Broker Metadata». می‌تواند برای «Resource Broker Metadata» یک تصمیم bounded با constraints، cost/risk و stop/pivot condition طراحی کند.
خلاصهٔ درس
معماری یا تصمیم تجاری را با preference و الگوهای آماده می‌گیرد و constraint/cost/serviceability را مدل نمی‌کند. موضوع جاری: «Resource Broker Metadata».
می‌تواند برای «Resource Broker Metadata» یک تصمیم bounded با constraints، cost/risk و stop/pivot condition طراحی کند.
خروجی این درس
می‌تواند برای «Resource Broker Metadata» یک تصمیم bounded با constraints، cost/risk و stop/pivot condition طراحی کند.
1. مسئله‌ای که این درس مالک آن است
یک Broker نباید از روی اسم «GPU»، برچسب provider یا چراغ سبز Health تصمیم بگیرد. سؤال واقعی این است: آیا یک Resource مشخص، برای همین Workload، همین مقدار، همین Tenant و همین لحظه واجد شرایط و قابل تخصیص است؟ ARC-003 فقط Metadata لازم برای این تصمیم و دلیل رد هر Candidate را مالک است؛ Versioned Shared Interfaces و Quota/Reservation outcomeهای جدا هستند.
2. خروجی قابل تحویل
خروجی شما Resource Broker Capability & Allocation Metadata Sheet v1 است. Sheet باید Demand و Supply را جدا نگه دارد و حداقل این‌ها را ثبت کند: Resource ID/Type/Provider، Total و Allocatable، Request Quantity و Unit، Capabilities، Locality، Tenant Scope، Reservation، Health، Availability، Cost Basis، Candidate State، Rejection Reason، Observed At و Provenance.
3. مدل ذهنی: Demand → Gates → Rank
ابتدا Workload Demand را normalize کنید؛ سپس هر Resource را از Hard Gateها عبور دهید؛ فقط Candidateهای ELIGIBLE وارد Ranking می‌شوند. ترتیب ساده این است: normalized demand → resource metadata → hard eligibility filters → eligible set → ranking → decision + rejection evidence. Cost یک preference بعد از eligibility است، نه جایگزین آن.
4. قرارداد شواهد
سه فیلد request_quantity, capacity_allocatable, unit باید با هم قابل مقایسه باشند. Capability، Locality، Tenant Scope، Reservation و Health هرکدام مستقل‌اند. observed_at و provenance_ref نشان می‌دهند این تصمیم بر چه Snapshotی تکیه دارد. اگر یکی از فیلدهای decisive نامعلوم باشد، State باید ضعیف‌تر شود؛ حدس‌زدن برای کامل‌کردن Sheet ممنوع است.
5. Request با Limit یکی نیست
Kubernetes بین Request و Limit فرق می‌گذارد و Scheduler برای Placement به Request نگاه می‌کند. نتیجه آموزشی این است که Broker هم باید تقاضای لازم برای placement را صریح نگه دارد؛ نام Resource یا سقف تئوریک آن جای Request workload را نمی‌گیرد.
6. Capacity Total با Allocatable یکی نیست
capacity_total ظرفیت اسمی است، اما capacity_allocatable مقداری است که در Snapshot تصمیم برای workload قابل حساب‌کردن است. یک Resource می‌تواند بزرگ و سالم باشد ولی Allocatable آن کمتر از Request باشد. در این حالت Health سبز هیچ مجوزی برای ELIGIBLE شدن نمی‌دهد.
7. Capability و Unit Hard Gate هستند
اگر Workload به GPU/CUDA یا Feature مشخص نیاز دارد، Candidate بدون آن Capability رد می‌شود. اگر Quantity داریم ولی Unit نداریم، مقایسه معنی ندارد؛ مثلاً «24» بدون GiB/GB یا «1» بدون GPU/device unit قابل اتکا نیست. Missing unit یا capability decisive باید UNKNOWN شود، نه conversion یا label ساختگی.
8. Baseline کارشده
Workload یک GPU، حداقل 24 GiB حافظه، Locality مجاز eu-central یا eu-west و Tenant A می‌خواهد. Local CPU node به‌خاطر capability mismatch رد می‌شود. Shared GPU worker از نظر capacity و health مناسب است اما برای Tenant B رزرو شده و INELIGIBLE می‌شود. Cloud GPU worker دو واحد allocatable، capability مناسب، locality مجاز و reservation خالی دارد؛ بنابراین ELIGIBLE و پس از ranking انتخاب می‌شود.
| Resource | Type | Provider | Total | Allocatable | Request | Unit | Capabilities | Locality | Tenant Scope | Reservation | Health | Availability | Cost Basis | Candidate State | Rejection Reason | Observed At | Provenance |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| cpu-local-01 | CPU | local | 32 | 24 | 1 | GPU | cpu,avx | eu-central | TENANT-A | none | GREEN | now | 1.0 cost-unit | INELIGIBLE | CAPABILITY_MISMATCH | 2026-09-15T18:00:00 | SYN-CPU |
| gpu-shared-01 | GPU | shared-fleet | 2 | 1 | 1 | GPU | gpu,cuda | eu-central | TENANT-A | TENANT-B:ACTIVE | GREEN | now | 1.8 cost-unit | INELIGIBLE | RESERVED_OTHER_TENANT | 2026-09-15T18:00:00 | SYN-SHARED |
| gpu-cloud-01 | GPU | cloud | 4 | 2 | 1 | GPU | gpu,cuda | eu-central | TENANT-A | none | GREEN | now | 2.8 cost-unit | ELIGIBLE | 2026-09-15T18:00:00 | SYN-CLOUD |
9. چرا Health سبز کافی نیست
یک Shortcut رایج این است که health_state=GREEN را نشانه availability بگیریم. در Mutation، Cloud GPU هنوز GREEN است اما capacity_allocatable=0.5 GPU و Request برابر 1 GPU است. Candidate باید INELIGIBLE شود. Health فقط یک Gate است؛ ظرفیت، reservation، tenant و locality را حذف نمی‌کند.
10. Reservation و Tenant Scope
Resource ممکن است shared باشد اما reservation فعال آن به Tenant دیگری تعلق داشته باشد. در این وضعیت Capacity فیزیکی وجود دارد، ولی Candidate برای Request جاری eligible نیست. اگر ownership/reservation evidence با هم تناقض داشته باشند، DISPUTED بهتر از حدس‌زدن Owner است.
11. Locality و Availability Window
Locality فقط اسم Region نیست؛ باید با constraint workload سازگار باشد. Window زمانی نیز ممکن است Candidate را موقتاً خارج کند. تغییر locality یا reservation بعد از Ranking یک تغییر مادی است؛ نتیجه قبلی را Copy نکنید و State را تا recompute شدن PARTIAL نگه دارید.
12. Staleness، Provenance و Stateهای غیرموفق
Resource Metadata سریع تغییر می‌کند. Evidence قدیمی برای scarce resource می‌تواند STALE شود. Missing quantity/unit/capability می‌تواند UNKNOWN ایجاد کند. Conflict مالکیت DISPUTED، policy block BLOCKED و تغییر مادیِ recomputeنشده PARTIAL است. این Stateها مانع overclaim هستند.
13. Transfer: GPU سالم، Reservation و Locality عوض شده‌اند
در Transfer، همان Shared GPU سالم می‌ماند اما Reservation Tenant B آزاد می‌شود و Locality آن از eu-central به eu-west تغییر می‌کند؛ workload از قبل هر دو locality را مجاز می‌دانست. با همان Request، Candidate باید از نو ارزیابی شود. حالا Shared GPU ELIGIBLE است و چون Cost Basis پایین‌تری از Cloud Worker دارد، می‌تواند انتخاب جدید باشد. هیچ تصمیم Baseline به‌عنوان Oracle استفاده نمی‌شود.
14. Lab و روش اجرا
به lab/ARC-003-LAB1/learner/ بروید و python run_checks.py را Offline اجرا کنید. هشت Fixture شامل Baseline، GREEN-but-under-capacity، missing unit، tenant-scope change، stale evidence، reservation conflict، missing capability و Transfer هستند. هدف حفظ‌کردن Verdict نیست؛ باید اولین Hard Gate یا Evidence state کنترل‌کننده را توضیح دهید.
15. ارزیابی، Freshness و مرز ادعا
ارزیابی شامل boundary، ساخت Baseline Sheet، تشخیص shortcut و Transfer است. مستندات Kubernetes فقط FACTهای request/capacity/extended-resource scheduling را محدود می‌کنند. Schema، State vocabulary و ranking policy طراحی MAKNOW هستند. تغییر مادی source semantics یا broker policy باید با Package version جدید requalify شود، نه با تغییر silent همین Golden.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
ARC-003-S1 retrieval
State the owned decision boundary of Resource Broker Metadata and name one adjacent outcome that remains out of scope.
ARC-003-S2 application
Build Resource Broker Capability & Allocation Metadata Sheet v1 for the baseline fixture and explain the selected candidate plus each rejection.
ARC-003-S3 diagnosis
A resource is GREEN but allocatable capacity is below the request. Which state and reason should change, and why?
ARC-003-S4 transfer
The shared GPU remains healthy, its reservation is released, and locality changes to another allowed locality. Recompute eligibility and ranking without changing workload demand.
ملاک‌های ارزیابی (rubric)
Critical dimensions: boundary correctness, exact demand/supply evidence binding, negative evidence, bounded candidate decision, and changed-context transfer. A positive result is insufficient if quantity/unit, capability, tenant/reservation, locality, timestamp, or provenance is unsupported. Typed uncertainty must remain visible.
منابع و تازگی
مطالعهٔ موارد (case studies)
فایل‌های آزمایشگاه
دستور python run_checks.py را Offline اجرا کنید. در هشت Fixture اولین فیلد Demand/Supply، Hard Gate یا Evidence State کنترل‌کننده را توضیح دهید. Health سبز هیچ‌وقت Capacity، Unit، Capability، Locality، Tenant Scope، Reservation، Timestamp یا Provenance را override نمی‌کند.