SONiC چیست؟ سیستمعامل متنباز سوئیچ و شرایط استفاده
SONiC یک سیستمعامل شبکه متنباز مبتنی بر لینوکس است که روی پلتفرمهای سازگارِ سوئیچ اجرا میشود. ایده آن جداکردن انتخاب نرمافزار شبکه از سختافزار است؛ اما این آزادی، مجوز نصب روی هر سوئیچ یا تضمین کاهش هزینه نیست. پیش از انتخاب، باید مدل دقیق دستگاه، توزیع نرمافزار، قابلیتهای لازم و مسئول پشتیبانی را با هم بررسی کرد.
گزارش ۲۱ اکتبر ۲۰۲۶ Network World درباره رشد SONiC، در بخش Popular topics شبکه این رسانه نیز قرار گرفته است. نکته مهم گزارش برای خریدار تجهیزات، گسترش گزینههای سازمانی و خدمات پشتیبانی پیرامون این سیستمعامل است؛ نه اینکه تمام شبکهها باید سیستمعامل فعلی خود را عوض کنند. این مقاله به همین تصمیم میپردازد: چه زمانی شبکه باز ارزش بررسی دارد و پیش از خرید چه مدرکی لازم است؟
SONiC چیست و چه تفاوتی با خود سوئیچ دارد؟
نام کامل SONiC عبارت است از Software for Open Networking in the Cloud. بنیاد این پروژه آن را یک Network Operating System یا NOS معرفی میکند که روی سوئیچها و تراشههای چند سازنده اجرا میشود. بنابراین SONiC نام یک مدل سختافزار، یک نوع پورت یا جایگزین فیزیکی سوئیچ نیست؛ لایه نرمافزاری مدیریت عملکرد شبکه است.
برای خرید، این تفکیک را به یک سؤال روشن تبدیل کنید: پیشنهاد فروشنده شامل چه سختافزاری، کدام نسخه نرمافزار و چه خدماتی است؟ اگر تنها عبارت «سوئیچ با SONiC» در پیشنهاد آمده، اطلاعات لازم برای مقایسه هنوز کامل نیست. نام پروژه بهتنهایی نه وضعیت قطعه را مشخص میکند و نه دامنه تعهد پشتیبان را.
معماری SONiC چگونه نرمافزار را به سختافزار وصل میکند؟
در معماری مستند پروژه، بسیاری از اجزای اصلی در کانتینرهای Docker قرار میگیرند و بعضی اجزا روی میزبان لینوکس اجرا میشوند. برای ارتباط با بخش ارسال بسته، Switch Abstraction Interface یا SAI یک رابط مشترک در اختیار نرمافزار میگذارد. پیادهسازی سازگار SDK و درایورهای تراشه همچنان به سختافزار وابسته است.
وجود این لایه مشترک را نباید با یکسان بودن همه قابلیتها روی همه دستگاهها اشتباه گرفت. تفسیر اجرایی ما این است که در ارزیابی، نام ASIC فقط یکی از دادههای لازم باشد؛ مدل کامل پلتفرم و نسخهای که واقعاً روی آن آزموده شده نیز باید ثبت شود. هیچ فرمان نصب یا تعویض سیستمعامل را صرفاً بر اساس شباهت تراشه اجرا نکنید.
نسخه جامعهمحور یا توزیع سازمانی؛ کدام را بررسی کنیم؟
Network World میان استفاده مستقیم از پروژه متنباز و راهکارهایی که فروشندگان با سازگاری تأییدشده و پشتیبانی تجاری ارائه میکنند، تفاوت میگذارد. انتخاب فقط میان «رایگان» و «پولی» نیست؛ باید معلوم شود چه کسی نسخه را آماده میکند، ایراد را پیگیری میکند و مسئول رفع مشکل میان نرمافزار و سختافزار است.
| موضوع | مسیر جامعهمحور | توزیع با پشتیبانی تجاری |
|---|---|---|
| نسخه و تغییرات | چه کسی ساخت، آزمون و نگهداری نسخه را انجام میدهد؟ | چرخه انتشار، اصلاحیه و پایان پشتیبانی در قرارداد چیست؟ |
| تطبیق سختافزار | مدرک کارکرد روی مدل و بازبینی سختافزاری شما چیست؟ | کدام مدلها و قابلیتها رسماً در دامنه پشتیبانیاند؟ |
| زمان خرابی | تیم داخلی چه مسیر تشخیص و بازیابی دارد؟ | مسئول پاسخگویی و شرایط ارجاع مشکل چه کسی است؟ |
| هزینه واقعی | زمان مهندسی، آزمایش و نگهداری را حساب کردهاید؟ | کدام خدمات در مبلغ هستند و کدام جدا محاسبه میشوند؟ |
این جدول مقایسه تضمینشده همه توزیعها نیست؛ چارچوب پرسش از فروشنده و تیم فنی است. برای مجموعهای با تیم کوچک، انتقال بخشی از مسئولیت به پشتیبان ممکن است مهمتر از آزادی ساخت نسخه باشد. تیمی که توسعه و عملیات شبکه را خودش انجام میدهد، ممکن است اولویت متفاوتی داشته باشد. نتیجه را بر اساس منابع واقعی همان سازمان بنویسید.
آیا میتوان SONiC را روی سوئیچ سیسکو فعلی نصب کرد؟
از نام برند یا خانواده محصول نمیتوان چنین نتیجهای گرفت. سیسکو در معرفی Cisco-validated SONiC برای N9000 از گزینههای تأییدشده و مدل عملیاتی پشتیبانیشده صحبت میکند. این معرفی را نباید به تمام Nexusها، سوئیچهای Catalyst یا تجهیزات قدیمیتر تعمیم داد. این مطلب نیز نصب SONiC روی هیچ مدل موجود در فروشگاه را تأیید نمیکند.
فهرست عمومی Supported Devices and Platforms پروژه، مدل پلتفرم، سازنده تراشه و پیکربندی پورت را جدا ثبت میکند. برای سفارش، همان فهرست را نقطه شروع بدانید و سپس نسخه دقیق توزیع و دامنه پشتیبانی فروشنده را تطبیق دهید. یک سابقه ساخت نرمافزار، بهتنهایی قرارداد خدمات یا تأیید تمام قابلیتهای مورد نیاز شما نیست.
برای دیتاسنتر AI چه چیزی را باید جداگانه آزمایش کرد؟
گزارش Network World رشد شبکههای آموزش و استنتاج، خودکارسازی و پایش را از زمینههای توجه به SONiC میداند. با این حال، انتخاب نام سیستمعامل جای طراحی شبکه را نمیگیرد. قابلیت مورد نیاز پروژه، رفتار زیر بار و ابزار عملیاتی باید در ترکیب مشخص سختافزار و نرمافزار بررسی شوند.
پیشنهاد عملی ما تهیه یک فهرست قابلیت است: مسیریابی و همسایگیهای لازم، شیوه اتصال به پایش، سیاست صفها، کنترل دسترسی مدیریتی و روش بازیابی پیکربندی. اگر بار شما به سازوکارهای خاص کنترل ازدحام وابسته است، نتیجه آنها را در آزمون همان بار بخواهید. عبارت «مناسب AI» بهتنهایی معیار پذیرش نیست و ما برای این مقاله آزمایش کارایی انجام ندادهایم.
خریدار ایرانی پیش از سفارش چه مدارکی بخواهد؟
۱. یک شناسنامه مشترک برای دستگاه و نرمافزار
مدل کامل، بازبینی سختافزار، جهت جریان هوا، پاور، اپتیکهای مورد استفاده و نام و نسخه توزیع را در یک برگه ثبت کنید. کنار هر قابلیت ضروری، مدرک یا نتیجه آزمون همان ترکیب را قرار دهید. اگر قرار است بخشی از تجهیزات از تأمینکنندگان متفاوت خریداری شود، مسئول تطبیق آنها باید از قبل مشخص باشد؛ نه پس از بروز خطا.
۲. مسیر دریافت اصلاحیه و پاسخ به خرابی
برای محیط ایران، پیشنهاد ما این است که دسترسی قانونی و عملی به فایل نسخه، اصلاحیه امنیتی، مستندات و خدمات را پیش از پرداخت بررسی کنید. امکان بازیابی نسخه و پیکربندی در شرایط محدودیت ارتباط خارجی را نیز آزمایش کنید. وعده کلی «پشتیبانی دارد» کافی نیست؛ شیوه ارتباط، مسئول پاسخگو و اقلام قابل جایگزینی باید روشن باشند. هیچ قرارداد یا سطح خدمتی را در این مقاله برای نت یک یا فروشنده دیگری فرض نکردهایم.
۳. بودجهای که زمان تیم را هم ببیند
هزینه را فقط با قیمت شاسی مقایسه نکنید. ساعت آموزش، نگهداری نسخه، آزمایش تغییرات، قطعه یدکی و زمان توقف احتمالی را جدا بنویسید. ممکن است یک گزینه در فاکتور ارزانتر باشد ولی برای تیم فعلی بار عملیاتی بیشتری ایجاد کند. بدون داده واقعی، درصد صرفهجویی یا برتری اقتصادی اعلام نکنید.
برای مقایسه گزینههای سختافزاری از دسته سوئیچ شبکه شروع کنید و سیستمعامل و پشتیبانی را نیز کنار مشخصات دستگاه قرار دهید. اگر طرح شما تجهیزات سیسکو را در بر میگیرد، مدلهای سوئیچ سیسکو را بر اساس نقش واقعیشان مقایسه کنید؛ این لینک به معنی سازگاری مدلهای آن دسته با SONiC نیست.
پیش از استقرار تولیدی چه آزمونی بگیریم؟
یک سناریوی محدود و قابل بازگشت تعریف کنید. در آن راهاندازی مجدد، بازگردانی پیکربندی، قطع یک لینک، بازیابی همسایگی مسیریابی و ثبت هشدارها را در محیط آزمایشی کنترل کنید. زمان بازیابی قابل قبول را از نیاز سرویس استخراج کنید، نه از یک عدد عمومی در اینترنت. نتیجه آزمون باید با نسخه و پیکربندی اجراشده ثبت شود تا پس از ارتقا قابل مقایسه باشد.
در پایان آزمایش، از دو نفر پاسخ روشن بگیرید: مسئول برنامه تأیید کند سرویس درست کار میکند و مسئول شبکه تأیید کند تیم توان نگهداری و رفع خرابی را دارد. اگر یکی از این دو پاسخ نامشخص است، خرید گسترده را جلو نیندازید. بازبودن کد یک امکان است؛ برنامه نگهداری، مسئولیت و مهارت تیم تصمیم استقرار را تعیین میکنند.
جمعبندی: SONiC برای کدام تصمیم ارزش بررسی دارد؟
SONiC برای سازمانی ارزش بررسی دارد که میخواهد انتخاب سیستمعامل شبکه را آگاهانه از سختافزار جدا کند و مسئولیت بهرهبرداری آن را هم روشن کرده باشد. گزارش تازه Network World از گسترش این اکوسیستم خبر میدهد، اما تصمیم شما باید روی مدل، نسخه، قابلیت، پشتیبانی و آزمون مشخص استوار باشد. شبکه پایدار موجود را صرفاً بهخاطر متنباز بودن یک گزینه تغییر ندهید.
منبع
- Network World، Neal Weinberg، ۲۱ اکتبر ۲۰۲۶؛ عنوان اصلی: AI networks drive SONiC boom. مطالعه مقاله اصلی در Network World.
- برای راستیآزمایی تعریف و معماری: معرفی رسمی SONiC Foundation و مستند معماری پروژه SONiC.
- برای کنترل حدود سازگاری: فهرست رسمی پلتفرمهای SONiC و معرفی Cisco-validated SONiC روی N9000. تأیید نهایی باید با مدل و نسخه انتخابی انجام شود.



رک شبکه