یکی از اشتباهات رایج، حتی بین کارشناسان فنی باتجربه، این است که سوئیچهای Cisco MDS و Catalyst را صرفا دو خانواده متفاوت از یک محصول بدانند. در حالی که این دو پلتفرم نهتنها کاربرد متفاوت دارند، بلکه اساسا برای دو فلسفه کاملا متفاوت از شبکه طراحی شدهاند. مقایسه MDS و Catalyst، مقایسه Fibre Channel با Ethernet نیست؛ مقایسه «شبکه برای داده» با «شبکه برای سرویس» است.
در این مقاله، تفاوت MDS و Catalyst را نه از زاویه جدول مشخصات، بلکه از زاویه رفتار واقعی در دیتاسنتر، طراحی، ریسک عملیاتی و تجربه پروژهای بررسی میکنیم. هدف این است که دقیقا بدانیم چرا این دو سوئیچ قابل جایگزینی با هم نیستند و چه زمانی انتخاب اشتباه آنها هزینهساز میشود.
تفاوت فلسفه طراحی بین SAN و Network دقیقا از جایی شروع میشود که هدف شبکه مشخص میگردد. شبکههای IP که Catalyst برای آنها ساخته شده، با این فرض طراحی میشوند که ترافیک متنوع است، رفتارها قابل پیشبینی نیستند و شبکه باید خودش را با تغییرات مداوم تطبیق دهد. در این دنیا، قطع کوتاهمدت، Retry، Load Balancing و حتی Drop شدن Packet در حد محدود قابل قبول است، چون اغلب Applicationها برای چنین شرایطی طراحی شدهاند. فلسفه Catalyst انعطافپذیری، چندمنظوره بودن و سازگاری با سناریوهای مختلف است؛ حتی اگر این انعطاف به بهای پیچیدگی بیشتر و رفتار غیرقطعی تمام شود.
در مقابل، SAN با یک فرض کاملا متفاوت طراحی میشود: Storage نباید حدس بزند، Retry کند یا منتظر بماند. در دنیای Storage، هر I/O بخشی از یک عملیات حیاتی است و تاخیر یا ناپایداری میتواند مستقیما به Crash سرویس، قفل شدن دیتابیس یا Corruption داده منجر شود. به همین دلیل، فلسفه طراحی SAN بر پایه حذف عدمقطعیت است، نه مدیریت آن. Fibre Channel و در نتیجه Cisco MDS با این دید ساخته شدهاند که شبکه نباید «سازگار» باشد، بلکه باید قابل پیشبینی باشد. رفتار باید همیشه یکسان باشد، چه در Load پایین و چه در اوج مصرف.
این تفاوت فلسفی در همهچیز خودش را نشان میدهد. در Catalyst، شما با مکانیزمهایی مثل QoS، Buffer، ECMP و Policy تلاش میکنید ترافیکهای مختلف را با هم آشتی دهید. یعنی شبکه ذاتا محل رقابت Flowهاست و شما آن را مدیریت میکنید. اما در MDS، اصلا رقابتی وجود ندارد. Fabric فقط برای Storage است و هیچ ترافیک دیگری اجازه ورود ندارد. این یعنی بسیاری از مسائلی که در Network باید «حل» شوند، در SAN از اساس وجود ندارند.
از نظر طراحی عملی، Catalyst برای تغییر ساخته شده است. VLAN اضافه میشود، Routing عوض میشود، سرویس جدید میآید و شبکه باید خود را وفق دهد. اما SAN برای ثبات ساخته شده است. تغییرات در SAN باید کم، کنترلشده و با کمترین Impact باشند. به همین دلیل است که مفاهیمی مثل VSAN و Zoning در MDS اینقدر سختگیرانه و مرحلهای هستند. این سختگیری ضعف نیست، بلکه بازتاب همان فلسفه طراحی است: در Storage، جلوگیری از یک خطا مهمتر از سرعت اعمال تغییر است.
تفاوت پروتکل Ethernet و Fibre Channel فقط تفاوت دو تکنولوژی نیست، تفاوت دو نگاه به ارتباط است. Ethernet با این فرض طراحی شده که شبکه یک محیط اشتراکی است؛ جایی که Flowهای مختلف با هم رقابت میکنند و شبکه تلاش میکند این رقابت را مدیریت کند. حتی در پیشرفتهترین پیادهسازیهای دیتاسنتری، Ethernet ذاتا Best-Effort باقی میماند. Packet ممکن است Drop شود، دوباره ارسال شود یا با تاخیر برسد و این رفتار از دید پروتکل طبیعی است. Catalyst دقیقا برای همین دنیا ساخته شده؛ دنیایی که انعطافپذیری و چندمنظوره بودن بر قطعیت اولویت دارد.
در مقابل، Fibre Channel با این پیشفرض طراحی شده که هیچ Packetی نباید گم شود و هیچ I/Oای نباید وارد حالت حدس و Retry شود. FC یک پروتکل Session-محور است، نه Packet-محور به معنای رایج در IP. قبل از اینکه دادهای جابهجا شود، Login انجام میشود، هویتها ثبت میشوند و مسیر ارتباطی مشخص میگردد. این یعنی Storage قبل از ارسال دیتا دقیقا میداند با چه کسی، روی چه مسیری و با چه انتظاری ارتباط برقرار میکند. Cisco MDS دقیقا برای مدیریت همین منطق ساخته شده است، نه برای حمل ترافیک متنوع.
از نظر عملی، تفاوت این دو پروتکل زمانی کاملا ملموس میشود که شبکه تحت فشار قرار میگیرد. در Ethernet، وقتی Load بالا میرود، شبکه تلاش میکند شرایط را با Buffer، Queue و QoS کنترل کند. این مکانیزمها هوشمند هستند، اما باز هم نتیجه نهایی میتواند نوسان Latency یا Delay غیرمنتظره باشد. برای بسیاری از Applicationها این موضوع قابل تحمل است، اما برای Storage اغلب فاجعهبار است. Fibre Channel این مشکل را از ریشه حذف میکند، چون اصلا اجازه نمیدهد رقابت ترافیکی شکل بگیرد.
نکته مهم دیگر این است که Fibre Channel مفاهیمی دارد که در Ethernet اساسا وجود ندارند یا معنا ندارند. Name Server، FLOGI، PLOGI و Zoning مفاهیمی هستند که مستقیما با Storage کار میکنند. اینها معادل VLAN یا ACL نیستند و نمیتوان آنها را با ذهنیت Network تفسیر کرد. Catalyst ابزارهایی برای مدیریت Flow دارد، اما MDS ابزارهایی برای کنترل هویت و مسیر Storage دارد. این تفاوت در عیبیابی هم خودش را نشان میدهد؛ در SAN، مشکل اغلب در Login یا Session است، نه در Packet Drop.
تفاوت در کنترل Failure Domain بین Catalyst و MDS یکی از بنیادیترین مرزهایی است که این دو پلتفرم را از هم جدا میکند، چون دقیقا مشخص میکند یک خطا تا کجا اجازه گسترش دارد. در شبکههای مبتنی بر Catalyst، Failure Domain معمولا بهصورت غیرمستقیم و وابسته به طراحی شکل میگیرد. VLAN، Trunk، Routing و STP همگی در تعیین دامنه اثر یک خطا نقش دارند، اما این کنترل بیشتر «مدیریتشده» است تا «ذاتی». اگر اشتباهی در طراحی یا پیادهسازی رخ دهد، امکان دارد اثر آن از یک VLAN یا یک Link فراتر برود و بخش بزرگی از شبکه IP را درگیر کند.
در مقابل، در Cisco MDS کنترل Failure Domain یک بخش ذاتی از معماری SAN است، نه نتیجه تنظیمات جانبی. مفاهیمی مثل VSAN باعث میشوند Fabric بهصورت طبیعی به چند دامنه مستقل تقسیم شود. هر VSAN Name Server، Zoning Database و منطق Fabric مخصوص به خودش را دارد. این یعنی اگر در یک VSAN خطایی رخ دهد، چه خطای انسانی مثل Zoning اشتباه و چه خطای سیستمی مثل Login Loop، این خطا اصولا راهی برای سرایت به VSAN دیگر ندارد. Failure Domain از ابتدا کوچک و مشخص طراحی شده است.
در عمل، این تفاوت زمانی بسیار مهم میشود که تغییرات اجتنابناپذیر هستند. در شبکههای Catalyst، یک تغییر اشتباه روی Trunk یا VLAN میتواند باعث Broadcast Storm، Loop یا قطع ارتباط گسترده شود. حتی اگر مکانیزمهای حفاظتی وجود داشته باشند، باز هم احتمال Impact سراسری وجود دارد. اما در MDS، تغییرات SAN معمولا داخل یک VSAN انجام میشوند. اگر اشتباهی رخ دهد، اثر آن محدود به همان Fabric منطقی باقی میماند و Production گسترده تحت تاثیر قرار نمیگیرد. این محدودسازی دامنه خطا در SAN حیاتی است، چون بازیابی Storage همیشه پرهزینه و زمانبر است.
نکته مهم دیگر این است که در شبکه IP، Failover معمولا بخشی از طراحی عادی است. Routing تغییر میکند، مسیر جدید انتخاب میشود و بعد از چند ثانیه یا دقیقه همهچیز به حالت پایدار برمیگردد. اما در SAN، Failover باید نامحسوس و بدون اختلال عملی باشد. Cisco MDS با Dual Fabric و VSAN این مدل را پیادهسازی میکند؛ بهطوری که حتی از دست رفتن کامل یک Fabric نباید باعث قطع دسترسی Storage شود. Catalyst چنین سطحی از ایزولاسیون و پیشبینیپذیری را ذاتا ارائه نمیدهد، چون کاربرد آن چنین چیزی را الزام نمیکند.
تفاوت Zoning در Cisco MDS با مفاهیم امنیتی Catalyst از همان نقطهای شروع میشود که هدف از محدودسازی مشخص میگردد. در شبکههای مبتنی بر Catalyst، ابزارهایی مثل VLAN، ACL، Port Security یا Policy-Based Access Control برای مدیریت دسترسی استفاده میشوند. این مکانیزمها معمولا با این فرض طراحی شدهاند که اگر خطایی رخ دهد، اثر آن در حد دسترسی غیرمجاز، افزایش ترافیک یا اختلال سرویس خواهد بود؛ یعنی پیامدها اغلب قابل برگشت و قابل جبران هستند. امنیت در Catalyst بیشتر به معنای «کنترل ارتباط» است تا محافظت مستقیم از داده.
در مقابل، Zoning در Cisco MDS مستقیما با یکپارچگی داده سروکار دارد، نه صرفا با دسترسی. در SAN، اگر یک Host بتواند یک Storage Port را ببیند، از نظر پروتکل Fibre Channel هیچ مانع ذاتی برای برقراری Session وجود ندارد. این یعنی یک Zoning اشتباه میتواند باعث شود سروری به LUN اشتباهی متصل شود و دادهای را بخواند یا بنویسد که اساسا متعلق به آن نیست. در اینجا پیامد خطا نه فقط نقض امنیت، بلکه Corruption داده است؛ چیزی که در بسیاری از موارد غیرقابل بازگشت است. به همین دلیل، Zoning در MDS یک مکانیزم محافظتی حیاتی است، نه صرفا یک Policy امنیتی.
از نظر عملی، تفاوت دیگر در رفتار پیشفرض است. در Catalyst، اگر ACL یا Policy تعریف نشود، شبکه معمولا باز است و ترافیک عبور میکند. یعنی محدودسازی باید بهصورت آگاهانه اضافه شود. اما در MDS، فلسفه کاملا برعکس است. بدون Zoning، Fabric یا کار نمیکند یا بهشدت ناامن است. Zoning در SAN یک وضعیت اختیاری نیست، بلکه شرط لازم برای بهرهبرداری امن از Storage است. Cisco MDS این واقعیت را در طراحی خودش لحاظ کرده و به همین دلیل Zoning را مرحلهای، سختگیرانه و کنترلشده پیادهسازی میکند.
نکته مهم دیگر این است که تغییرات Zoning در MDS عمدا «سریع» نیستند. شما نمیتوانید مثل تغییر یک ACL، بهصورت آنی و بدون بررسی Zoning را عوض کنید. مفهوم Zone Set و Active Zone Set دقیقا برای همین ساخته شده است. تغییرات ابتدا آماده میشوند، سپس بررسی میشوند و فقط با یک تصمیم آگاهانه وارد Fabric فعال میشوند. این مکانیسم شاید برای مهندسی که از دنیای Catalyst میآید دستوپاگیر به نظر برسد، اما در SAN یک مزیت حیاتی است. این تأخیر کنترلشده، جلوی بسیاری از اشتباهات پرهزینه انسانی را میگیرد.
Catalyst برای شبکههایی طراحی شده که مقدار محدودی Downtime یا Failover قابل قبول است. حتی در دیتاسنتر، بسیاری از سرویسها میتوانند با چند ثانیه قطع ارتباط کنار بیایند.
اما در SAN، Downtime اغلب مساوی با Crash سرویس است. Database، Hypervisor یا Core Systemها معمولا Tolerance پایینی دارند. MDS با Redundant Supervisor، Control Plane مجزا و طراحی Fabric-Based این نیاز را پاسخ میدهد. High Availability در MDS یک Feature نیست؛ پیشفرض طراحی است.
در Catalyst، عیبیابی معمولا بر اساس Flow، Packet و Counter انجام میشود. ابزارها متنوعاند، اما دید شبکه بیشتر در سطح IP و Transport است.
در MDS، Visibility دقیقا در سطح Storage است. Loginها، Sessionها، Pathها و وضعیت هر Initiator و Target قابل مشاهده است. این نوع دید برای عیبیابی SAN حیاتی است، چون بسیاری از مشکلات Storage اصلا در سطح IP قابل تشخیص نیستند. MDS ابزارهایی میدهد که Catalyst اساسا به آنها نیازی ندارد.
یکی از خطرناکترین برداشتها این است که بتوان با یک Catalyst پیشرفته، نقش MDS را ایفا کرد یا بالعکس. Catalyst حتی در بهترین حالت، یک سوئیچ Ethernet است که میتواند Storage Traffic حمل کند. MDS یک SAN Switch است که برای شبکه عمومی ساخته نشده است.
در پروژههای واقعی، تلاش برای سادهسازی بیشازحد معمولا به افزایش ریسک منجر میشود. جایی که Storage Mission-Critical است، استفاده از Catalyst بهجای MDS معمولا یک تصمیم کوتاهمدت و پرریسک است. و جایی که شبکه IP پویا و سرویسمحور است، MDS اساسا انتخاب درستی نیست.
تفاوت Cisco MDS و Catalyst تفاوت دو خانواده محصول نیست؛ تفاوت دو جهان فکری است. Catalyst برای شبکهای ساخته شده که باید سریع تغییر کند، رشد کند و سرویسهای متنوع را حمل کند. MDS برای محیطی ساخته شده که تغییرات کنترلشده، رفتار قابل پیشبینی و حفاظت از داده اولویت مطلق دارد. مهندسی که این تفاوت را درک کند، دیگر این دو را جایگزین هم نمیبیند، بلکه آنها را مکمل یک دیتاسنتر حرفهای میداند.
درک تفاوت واقعی MDS و Catalyst نیازمند تجربه عملی دیتاسنتر است، نه فقط مطالعه دیتاشیتها. وینو سرور با تمرکز بر آموزشهای عمیق، پروژهمحور و مبتنی بر سناریوهای واقعی Cisco، تلاش میکند این تفاوتها را همانطور که در عمل دیده میشوند آموزش دهد. به همین دلیل، برای بسیاری از متخصصان شبکه و Storage، وینو سرور بهعنوان یک مرجع تخصصی قابل اعتماد شناخته میشود.
وینو سرور، اولین استارتاپ ارائه تجهیزات و سیستم های سخت افزاری، به صورت مستقیم از تولید کننده به مصرف کننده است. همواره تلاش مجموعه بر این اصل استوار بوده است تا مشتریان بتوانند بهترین سیستم را برای پروژه خود انتخاب کرده و با مناسبترین قیمت، آن را تهیه کنند. تیم وینو سرور، همواره سعی میکند تا جامعترین خدمات را به مشتریان ارائه دهد تا خرید را برای شما به کاری لذتبخش و آسان تبدیل کند.
مطلع شدن از پست های جدید
میخواهم اولین نفری باشم که از مقالههایی که در وینو سرور منتشر میشود، آگاه شوم.
