شروع کار با مخزن‌های طراحی شبکه

این آموزش از ایده تا تغییرهای گواهی‌شده را فصل به فصل پیش می‌برد. مرجع کامل: [مخزن طراحی شبکه](/docs/fa/network-design). ## ۱. مخزن طراحی شبکه چیست ```diagram type: flow title: منبع حقیقت شبکه، به صورت متن --- متن | سایت‌ها، دستگاه‌ها، پورت‌ها، پیوندها، مدارها و داکت‌ها در فایل‌های `.zevtopo` | accent | 📐 ~ نسخه‌دار بازبینی‌شده | هر تغییر یک کامیت با نویسنده و دلیل، در یک درخواست ادغام | | ⎇ ~ سنجیده قابل اعتماد | مقایسه‌شده با دستگاه‌ها، آزموده در برابر قول‌هایی که نوشته‌اید | good | ✓ ``` **مخزن طراحی شبکه** آنچه شبکه‌تان باید باشد را نگه می‌دارد: سایت‌ها، دستگاه‌ها، پورت‌ها، پیوندهای میانشان، مدارهایی که می‌خرید و داکت‌هایی که از آن‌ها می‌گذرند. متن ساده است و مثل کد نسخه‌دار، پس هر تغییر نویسنده، دلیل و بازبینی دارد. سپس Zaryn آن را با شبکهٔ واقعی و با قول‌هایی که می‌نویسید می‌سنجد. ## ۲. چرا نقشه‌ها دروغ می‌گویند ```diagram type: graph title: افزونه روی نقشه، یک بریدگی در عمل alt: دو سایت با دو مدار به هم وصل‌اند که هر دو از یک داکت می‌گذرند؛ یک بریدگی هر دو مدار را قطع می‌کند legend: down=قطع start: نقشه height: 46 --- box دفتر مرکزی | 3 6 36 34 | accent box مرکز داده | 61 6 36 34 | good node hq1 | hq1 | 14 16 | router node hq2 | hq2 | 14 32 | router node dc1 | dc1 | 86 16 | router node dc2 | dc2 | 86 32 | router link hq1 hq2 link dc1 dc2 link hq1 dc1 | مدار A link hq2 dc2 | مدار B step یک داکت، دو مدار | هر دو مدار از یک داکت زیر یک پل می‌گذرند. نقشه این را نمی‌داند. note 50 44 | هر دو در duct-north | warn step یک بیل مکانیکی | یک بریدگی، هر دو مدار قطع، سایت‌ها از هم جدا. طراحی‌ای که داکت را نام ببرد این را پیش از رخ دادن پیدا می‌کند. link hq1 dc1 | down link hq2 dc2 | down node dc1 | bad node dc2 | bad ``` هر شبکه‌ای جایی یک طراحی دارد، یک نقشه یا یک جدول، و ظرف چند ماه نادرست می‌شود: دستگاهی که با عجله اضافه شد، پیوندی که به پورت دیگری رفت. بدتر اینکه نقشه **ریسک مشترک** را نشان نمی‌دهد: دو پیوند «افزونه» در یک داکت با هم از کار می‌افتند. ## ۳. طراحی، واقعیت، پیش‌بینی ```diagram type: flow title: سه نمای یک شبکه، هم‌گام loop: هر تغییر ادغام‌شده طراحی را به‌روز می‌کند؛ هر گزارش دستگاه آن را می‌سنجد --- طراحی | آنچه باید باشد: همین مخزن | accent | 📐 ~ مقایسه با واقعیت | آنچه دستگاه‌ها می‌گویند: جمع‌آوری‌کنندهٔ یک سایت | good | 📡 ~ پیش‌بینی می‌کند پیش‌بینی | یک تغییر چه می‌کند: دوقلوی دیجیتال | warn | 🔮 ``` این آموزش دربارهٔ نمای اول است. [سایت‌ها](/docs/fa/network-sites) نمای دوم و [دوقلو](/docs/fa/network-twin) نمای سوم را می‌دهند. ## ۴. مخزن را بسازید ```diagram type: flow title: دو راه شروع or: یا --- مخزن تازه | در zaryn.xyz/repos با نوع **Topology**؛ یا `zev new` و انتخاب topology | accent | ➕ ~ سپس از صفر | `topology/main.zevtopo` را با دست یا روی بوم بنویسید | | ✎ ? از یک سایت در حال کار | `zev topo import <owner>/<site>`: هر دستگاه و پیوندی که جمع‌آوری‌کننده می‌بیند ``` از قبل یک [سایت](/docs/fa/network-sites) دارید؟ به‌جای تایپ کردن واردش کنید: ```bash zev clone you/network-design && cd network-design zev topo import you/hq zev add topology && zev commit -m "Design from the live network" && zev push ``` ورودی هر دستگاه (سازنده، مدل، آدرس مدیریتی) و هر پیوندی را که دستگاه‌ها می‌بینند با پورت‌هایش دارد. سپس آن را به یک طراحی تبدیل می‌کنید: نقش‌ها، نام مدارها، ریسک‌های مشترک. ## ۵. نخستین طراحی شما ```toml [[device]] name = "hq1" vendor = "cisco" role = "core" site = "hq" [[device]] name = "dc1" vendor = "cisco" role = "core" site = "dc" [[link]] a = "hq1" b = "dc1" a_if = "Te1/0/1" b_if = "Te1/0/1" provider = "TIC" circuit = "TIC-4411" srlg = ["duct-north"] ``` ```diagram type: cards title: بلوک‌هایی که بیشتر به کار می‌برید --- 🏢 | [[site]] | یک مکان: نام، آدرس، مختصات | 🖧 | [[device]] | name، vendor، role (core، distribution، access، edge…)، site، model، آدرس مدیریتی | accent 🔗 | [[link]] | دو سر و پورت‌هایش، نوع، ظرفیت، تأمین‌کننده، مدار، و `srlg`: آنچه در آن شریک است | good 🏷 | [[vlan]]، [[interface]]، [[static_route]] | آدرس‌دهی و مسیریابی، هر وقت بخواهید | ``` فقط `name` یک دستگاه و `a` و `b` یک پیوند لازم‌اند. طراحی را به هر شمار فایلی زیر `topology/` که برای تیمتان مناسب است تقسیم کنید، مثلاً یکی برای هر سایت. [قالب کامل](/docs/fa/network-design#قالب-zevtopo). ## ۶. کد یا بوم، به انتخاب شما ```diagram type: graph title: یک طراحی، دو ویرایشگر، همیشه هم‌گام alt: فایل .zevtopo و بوم همان طراحی را نشان می‌دهند؛ تایپ کردن بوم را دوباره می‌کشد و تغییر بوم فقط همان خط‌های فایل را ویرایش می‌کند height: 32 --- node code | فایل ‎.zevtopo | 14 16 | file | accent | یک بلوک بنویسید: بوم همان‌طور که می‌نویسید دوباره کشیده می‌شود node canvas | بوم | 86 16 | router | good | افزودن، پیوند، تغییر نام، حذف: فقط همان خط‌های فایل عوض می‌شوند link code canvas | همان طراحی | path link canvas code | همان طراحی | path2 ``` زبانهٔ **Design editor** مخزن، فایل و نقشه را کنار هم نشان می‌دهد. `n` دستگاه اضافه می‌کند، `l` دو تا را پیوند می‌دهد، inspector جزئیات را ویرایش می‌کند و اشتباه‌ها با شمارهٔ خطشان فهرست می‌شوند. **Save** به‌طور پیش‌فرض تغییر را به صورت درخواست ادغام پیشنهاد می‌کند تا پیش از نشستن سنجیده شود. [همهٔ میان‌برها](/docs/fa/network-design#ویرایش-کد-و-بوم). ## ۷. آن را به چهار شکل ببینید ```diagram type: cards --- 🕸 | منطقی | دستگاه‌ها و پیوندها، با نقطه‌های شکست یگانه و پیوندهای حیاتی علامت‌خورده | accent 🏢 | سایت‌ها | دستگاه‌ها گروه‌بندی‌شده با سایت، تا WAN شما برجسته شود | 🎨 | ریسک مشترک | پیوندها رنگ‌شده با آنچه در آن شریک‌اند: یک رنگ، یک خرابی | warn 🔁 | طراحی و واقعیت | طراحی کشیده‌شده روی آنچه سایت پیوندخورده گزارش می‌کند | good ``` **Network overview** مخزن را باز کنید. روی یک دستگاه بزنید تا مدل، سایت، آدرس مدیریتی، پورت‌ها و مدارهایش را ببینید. ## ۸. طراحی و واقعیت ```diagram type: graph title: مقایسه چه نشان می‌دهد alt: پیوند طراحی‌شده‌ای که هیچ دستگاهی گزارش نمی‌کند خط‌چین قرمز است؛ پیوندی که دستگاه‌ها گزارش می‌کنند و طراحی ندارد نقطه‌چین کهربایی است legend: path=هر دو موافق‌اند؛ down=طراحی‌شده، در شبکه نیست؛ warn=در شبکه هست، در طراحی نیست height: 40 --- node core1 | core1 | 20 10 | switch node core2 | core2 | 80 10 | switch node acc1 | acc1 | 20 32 | switch node acc9 | acc9 | 80 32 | switch | warn | وصل شده، هرگز مستند نشده link core1 core2 | | path link core1 acc1 | طراحی‌شده، دیده نشده | down link core2 acc9 | در طراحی نیست | warn ``` در یک سایت، **Collector and settings ← Design repository** این دو را به هم وصل می‌کند. از آن پس طراحی نمی‌تواند بی‌صدا دور شود: هر چه طراحی شده ولی ساخته نشده، ساخته شده ولی طراحی نشده، یا روی پورت‌هایی جز آنچه برنامه بود، روی طراحی و روی نقشهٔ سایت پیدا می‌شود. ## ۹. نیت‌ها: قول‌هایی که طراحی باید حفظ کند ```text # topology/wan.zevintent ducts = survive site:hq site:dc srlg hq-to-dc = max-hops hq1 dc1 3 no-spof ``` ```diagram type: cards title: قول‌هایی که می‌توانید بنویسید --- 🔗 | reach A B | A و B به هم وصل‌اند | 🛡 | survive A B [link، srlg، device، any] | پس از هر خرابی تکی از آن نوع هنوز وصل‌اند | accent 📏 | max-hops A B N | کوتاه‌ترین مسیر حداکثر N پیوند است | 🎯 | no-spof، no-bridge، no-shared-risk | هیچ دستگاه، پیوند یا ریسک مشترک تکی شبکه را دو تکه نمی‌کند | good ``` وقتی نیتی شکست بخورد، Zaryn فقط «شکست» نمی‌گوید؛ خرابی‌ای را که این کار را می‌کند نام می‌برد: `shared risk group duct-north (2 links) → site:hq and site:dc are cut apart`. ## ۱۰. درخواست‌های ادغامی که نمی‌توانند قولی را بشکنند ```diagram type: flow title: نیت‌های شاخهٔ مقصد قرارداد است --- درخواست ادغام | شاخه‌ای که طراحی را عوض می‌کند | accent | ⎇ ~ سنجیده در برابر نیت‌ها | نیت‌های مقصد، به‌اضافهٔ هر چه این تغییر می‌افزاید | | ✓ ~ هر کدام هنوز برقرار | چیزی برای گفتن نیست | good | ✓ ? برقرار بود، حالا شکسته | ادغام را مسدود می‌کند و خرابی را نام می‌برد | bad ? از قبل شکسته | یک هشدار، بدهی‌ای که این تغییر نساخته | warn ``` درخواست ادغام تغییر را هم می‌کشد: دستگاه‌ها و پیوندهای افزوده به رنگ سبز، حذف‌شده خط‌چین قرمز، تغییرکرده کهربایی. حذف یک نیت در همان درخواست، شکستنش را توجیه نمی‌کند. ## ۱۱. «اگر چه»، و پیوندی که کمک می‌کند ```diagram type: graph title: بهترین پیوند برای افزودن alt: core1 نقطهٔ شکست یگانه برای dist1 و دو سوئیچ دسترسی است؛ افزودن پیوندی از core2 به acc1 راه دومی به آن‌ها می‌دهد legend: down=نقطهٔ شکست یگانه؛ new=پیوند پیشنهادی start: امروز height: 44 --- node core1 | core1 | 30 8 | switch | warn | اگر از کار بیفتد، dist1، acc1 و acc2 جدا می‌شوند node core2 | core2 | 70 8 | switch node dist1 | dist1 | 30 22 | switch node acc1 | acc1 | 18 36 | switch node acc2 | acc2 | 42 36 | switch link core1 core2 link core1 dist1 link dist1 acc1 link dist1 acc2 link core2 acc1 | | hidden step پیشنهاد | Zaryn هر پیوندی را که ندارید امتحان و رتبه‌بندی می‌کند: این یکی نقطهٔ شکست یگانه را برمی‌دارد. **Add it in the editor** آن را آمادهٔ یک درخواست ادغام باز می‌کند. link core2 acc1 | new | پیشنهادی node core1 | normal ``` - **What if these fail?** در زبانهٔ **Intents**: داکت‌ها، پیوندها و دستگاه‌ها را برگزینید و ببینید چه می‌ماند و کدام نیت‌ها دیگر برقرار نیستند. - **تاب‌آوری**: سهم خرابی‌های تکی‌ای که کسی را جدا نمی‌کنند، بدترین‌هایشان، و نمای گرمایی روی گراف. - **پیوندهایی که کمک می‌کنند**، رتبه‌بندی‌شده همان‌طور که یک مهندس می‌کند: هر کدام چه چیزی را برمی‌دارد، مسیر کوتاه پیش از مدار تازه. ## ۱۲. دسترس‌پذیری، ظرفیت و مسیرهای جدا ```diagram type: stats title: معنای نُه‌ها در یک سال --- 99.9% | سه نُه | حدود ۸ ساعت و ۴۶ دقیقه قطعی | 73 | warn 99.99% | چهار نُه | حدود ۵۳ دقیقه قطعی | 47 | accent 99.999% | پنج نُه | حدود ۵ دقیقه قطعی | 19 | good ``` ```text up = availability edge dc 99.95 uplinks = capacity edge dc 10000 link two-ways = disjoint edge dc device ``` با پریمیوم، سه نیت دیگر به آنچه «افزونه» نمی‌گوید پاسخ می‌دهند: A چند وقت به B نمی‌رسد (از `mtbf` و `mttr` هر بخش)، آیا مسیر پشتیبان پس از خرابی ترافیک را می‌کشد، و دو مسیری که هیچ اشتراکی ندارند. در طرح رایگان این‌ها «در انتظار» فهرست می‌شوند، هرگز به صورت شکست. [با جزئیات](/docs/fa/network-design#دسترسپذیری-ظرفیت-و-مسیرهای-جدا). ## ۱۳. تاریخچه، و کمک از هوش مصنوعی ```diagram type: cards --- 🕰 | طراحی در گذر زمان | امروز در برابر هر کامیت اخیر، با اینکه چه کسی چه چیزی را عوض کرد؛ Play آن را مرور می‌کند | accent 🤖 | کپی برای عامل هوش مصنوعی | طراحی، نقطه‌های ضعفش و راه‌حل‌ها به صورت Markdown کوتاه | good 🔌 | zev mcp | عامل‌ها نیت‌ها و خرابی‌های «اگر چه» را خودشان می‌خوانند | ``` «از زمان قطعی چه چیزی را عوض کردیم؟» با یک لغزنده پاسخ داده می‌شود. ## ۱۴. آن را به صورت آزمایشگاه اجرا کنید ```diagram type: flow title: از یک طراحی تا یک آزمایشگاه در حال اجرا or: یا --- طراحی | فایل‌های `.zevtopo` | accent | 📐 ~ دانلود Containerlab | `.clab.yml`: `containerlab deploy -t …` | | 📄 ? GNS3 | `.gns3`: File ← Open project ~ اجرا آزمایشگاه | کانتینرها یا ماشین‌های مجازی سیم‌کشی‌شده طبق طراحی: پینگ بگیرید، پیوندی را بکشید، با نیت‌هایتان مقایسه کنید | good | ▶ ``` طراحی‌ای که هرگز اجرا نشده یک فرضیه است. Network overview آن را برای [Containerlab یا GNS3](/docs/fa/network-design#اجرای-طراحی-به-صورت-آزمایشگاه) صادر می‌کند و نوع و ایمیج هر دستگاه را از سازنده‌اش برمی‌گزیند. ## ۱۵. گواهی‌ها، و قدم بعدی ```diagram type: flow title: زنجیره‌ای از تغییرهای امضاشده --- #1 · لینک بالادست دوم | ادغام با sara، تأیید با omid، نیت‌ها برقرار | good | 1 ~ prev #2 · ترمیم رایزر | ادغام‌شده، نیت‌ها برقرار | good | 2 ~ prev #3 · یک لینک بالادست | ادغام با وجود بررسی‌های ناموفق: «forced» ثبت شد | bad | 3 ``` با پریمیوم، هر تغییر طراحی ادغام‌شده یک **گواهی تغییر** می‌گیرد: چه کسی چه چیزی را عوض کرد، چه کسی تأیید کرد، چه چیزی سنجیده شد؛ امضاشده و زنجیرشده به گواهی قبلی، و بی‌نیاز از اعتماد به Zaryn در مرورگرتان بررسی‌پذیر. [چطور یکی را بسنجید](/docs/fa/network-design#گواهیهای-تغییر). طراحی آغاز چرخه است: [دوقلوی دیجیتال](/docs/fa/network-twin) پیش‌بینی می‌کند یک تغییر پیکربندی چه می‌کند و [rolloutها](/docs/fa/network-rollouts) آن را با بازگشت خودکار روی دستگاه‌ها انجام می‌دهند.