خلاصه اجرایی: NSX در VCF باید بهعنوان یک سیستم شبکه و عملیات طراحی شود، نه یک افزونه روی vSphere. ابتدا نیازهای ترافیک و Trust Boundary مشخص میشوند؛ سپس Underlay، Overlay، Edge، Routing، Segmentation، Observability و Recovery به یک Low-Level Design قابل اجرا تبدیل میشوند.
پیش از NSX چه باید بدانیم؟
اولین ورودی طراحی، لیست VLAN نیست. باید جریانهای کسبوکار، مرز Trust، مسیرهای North-South و East-West، سرویسهای مشترک، نیاز به Load Balancing یا NAT، اتصال به Firewall فیزیکی و الزامات DR مشخص شوند. بدون این اطلاعات، شبکه منطقی فقط نامهای جدیدی برای ساختار قدیمی میسازد.
همچنین باید معلوم باشد چه کسی Day-۲ را اداره میکند. تیم Virtualization، Network و Security باید روی مالکیت Change، Monitoring، Route، Policy و Incident توافق کنند.
NSX نباید ابهام Underlay را پنهان کند. اگر MTU، Redundancy و Routing فیزیکی قابل اثبات نیستند، Overlay فقط عیبیابی را دشوارتر میکند.
Underlay و MTU را end-to-end بسنجید
Underlay باید Reachability پایدار میان Transport Nodeها و Edgeها فراهم کند. MTU باید در کل مسیر—از vNIC و vDS تا NIC، ToR، Interconnect و مقصد—هماهنگ باشد. تست باید روی مسیرهای Active و Failover انجام شود.
| لایه | سؤال کنترل | Evidence |
|---|---|---|
| Host uplink | Redundancy، Driver/Firmware و Queue مناسب است؟ | Inventory + failover test |
| Top of Rack | VLAN، MTU، LAG/MLAG و Route همگناند؟ | Config export + path test |
| Inter-site | Latency، MTU و Failure path مشخص است؟ | Measurement + network diagram |
| Edge uplink | Gateway، BGP/static route و Firewall rule معتبرند؟ | Route table + packet capture |
Overlay، Segment و آدرسدهی
Segment design باید براساس Application zone، Tenant، Lifecycle و Policy ساخته شود. تولید Segmentهای زیاد بدون Naming، IPAM و Decommission process، محیط را سریعاً به Sprawl میرساند. از طرف دیگر، چسباندن همه Workloadها به چند Segment بزرگ، دامنه Failure و Security را افزایش میدهد.
برای هر Segment باید Owner، CIDR، Gateway model، DHCP/DNS/IPAM، Route advertisement، Security profile و تاریخ بازبینی مشخص باشد. اگر VPC یا مدل چندمستاجری استفاده میشود، مرز مسئولیت Provider و Consumer باید از ابتدا روشن شود.
Edge را با Service و Failure طراحی کنید
تعداد Edge Node از روی تعداد Host تعیین نمیشود. Serviceهای مورد استفاده، Throughput، Encryption، NAT، Load Balancing، Routing، Active/Standby یا ECMP، Maintenance و Failure همزمان روی Sizing اثر دارند.
Service Placement
کدام سرویس روی کدام Tier/Edge اجرا میشود و وابستگی آن به Site چیست؟
Failure Model
در خرابی Node، Rack، ToR یا Site چه ظرفیتی باقی میماند و Sessionها چه میشوند؟
Scale
Route، Session، Rule، Throughput و رشد با Limitهای نسخه مقصد سنجیده میشوند.
Operations
Upgrade، Backup، Certificate و دسترسی اضطراری Edge چگونه انجام میشود؟
Routing و مسیر North-South
انتخاب BGP یا Static، Route aggregation، Default route، ECMP و تعامل با Firewall فیزیکی باید با تیم شبکه توافق شود. Route redistribution بدون کنترل میتواند دامنه خطا را از Overlay به کل دیتاسنتر گسترش دهد.
Design باید مسیر Normal و Failure را نشان دهد. فقط Draw کردن فلش Active کافی نیست؛ در قطع Uplink، Edge یا ToR، مسیر برگشت و Symmetry باید بررسی شود. Route filtering و Summarization نیز باید بخشی از LLD باشند.
Segmentation با خرید Feature حل نمیشود
Micro-segmentation نیازمند Application inventory، Policy ownership، نامگذاری Groupها، استثنا، Log retention و فرایند تغییر است. شروع مستقیم با Rule نویسی معمولاً به Policyهای گسترده و استثناهای دائمی ختم میشود.
Discover
جریانها، Owner و حساسیت سرویس ثبت میشوند.
Model
Zone، Group، Tag و Naming استاندارد تعریف میشوند.
Observe
Policy پیشنهادی در حالت مشاهده و با تیم اپلیکیشن اعتبارسنجی میشود.
Enforce
اجرا موجبندی و Rollback/exception process مشخص میشود.
قابلیتهای امنیتی و Add-onها را باید با Feature Matrix و قرارداد روز تطبیق داد. حضور NSX به معنی مجازبودن همه قابلیتهای Security نیست.
Capacity را در وضعیت Failure بسنجید
Throughput آزمایشگاهی یا ظرفیت اسمی VM بهتنهایی کافی نیست. باید East-West و North-South، Packet size، Connection rate، Service overhead و رشد دیده شوند. سپس ظرفیت در شرایط Maintenance و خرابی Node محاسبه شود.
| حالت | چیزی که باید سنجیده شود | معیار پذیرش نمونه |
|---|---|---|
| Normal | Throughput، latency، CPU و session | زیر SLO با Headroom تعریفشده |
| Maintenance | خروج یک Edge/Host | پایداری Route و ظرفیت باقیمانده |
| Failure | Node/Link/ToR loss | Convergence و اثر روی Application |
| Growth | Route/Rule/Segment/Traffic آینده | عبور نکردن از Scale limit |
Visibility بخشی از معماری است
Monitoring باید Health اجزا، Tunnel، Route، Drop، Edge resource، Certificate و Capacity را پوشش دهد. Log بدون Time sync و Retention مشخص در Incident ارزش محدودی دارد. Packet capture و Traceflow ابزارند؛ تیم باید بداند در چه ترتیب و با چه Baseline از آنها استفاده کند.
Runbookهای Day-۲ شامل ایجاد Segment، تغییر Route، Policy exception، Certificate renewal، Backup/Restore، Upgrade و Escalation باید پیش از تحویل آماده باشند.
مهاجرت شبکه را موجبندی کنید
انتقال از VLAN/VDS یا طراحی NSX قدیمی به معماری جدید باید با Application dependency انجام شود. مهاجرت صرفاً جابهجایی Port Group نیست؛ Gateway، Firewall، NAT، Load Balancer، DNS و Monitoring نیز ممکن است تغییر کنند.
برای هر موج، Source/Destination، Maintenance، Test، Backout و Owner تعریف میشود. یک Application کماهمیت فقط زمانی Canary خوبی است که الگوی شبکه آن نماینده سناریوی اصلی باشد.
چه تصمیمهایی باید در ADR ثبت شوند؟
- Transport Zone و Uplink profile؛
- MTU و روش اثبات end-to-end؛
- Tier topology، Edge form factor و Placement؛
- Routing protocol، AS design و Route filtering؛
- Segment/VPC/Tenant model و Naming؛
- Security zone، Tag governance و Exception process؛
- IPAM/DNS/DHCP integration؛
- Monitoring، Log retention و Support access؛
- DR، Backup و Recovery برای اجزای مدیریتی.
یک مسیر عیبیابی کوتاه و قابل تکرار
عیبیابی از Application symptom شروع میشود و لایهبهلایه پایین میرود: Endpoint و Policy، Segment و Gateway، Tunnel، Edge، Underlay و سرویس بیرونی. پرش مستقیم به Reboot یا تغییر چند Rule، Evidence را از بین میبرد.
Baseline سالم، Diagram بهروز و Time sync سه پیشنیاز Incident response هستند. هر تغییر اضطراری باید بعداً به Configuration و Documentation اصلی برگردد.
پرسشهای متداول
آیا برای NSX حتماً BGP لازم است؟
نه. انتخاب Routing به مقیاس، Redundancy و استاندارد شبکه بستگی دارد؛ مزایا و پیچیدگی هر گزینه باید سنجیده شود.
آیا Jumbo Frame کافی است؟
تنظیم MTU کافی نیست؛ مسیر end-to-end و Failover path باید آزمایش شود.
آیا Micro-segmentation را میتوان از روز اول Enforce کرد؟
از نظر فنی ممکن است، اما بدون Discovery و مالکیت Policy، ریسک اختلال و Exceptionهای گسترده بالا میرود.
Edge را فیزیکی انتخاب کنیم یا مجازی؟
پاسخ به Service، Throughput، Availability، Placement و محدودیت سختافزار وابسته است. Sizing و Failure model تعیینکنندهاند.
منابع رسمی و یادداشت نسخه
برای Limit، Scale و قابلیت دقیق NSX، مستند همان Build و Entitlement سازمان مرجع نهایی است.
برای مطالعه بعدی
طراحی NSX را از Underlay و Use Case شروع کنید
در Assessment، جریانها، Edge، MTU، Route، Security و مدل عملیات به تصمیمهای قابل اجرا تبدیل میشوند.