وقتی سرنوشت‌ها به هم گره می‌خورند: کوتاه درباره‌ی اصطلاح Fate sharing

یه فلسفه‌ای هست تو دنیا که میگه اتفاقایی که برای ما میوفته بخشیش دست ما نیست و در گروی اثر عملی هست که سایر عناصر عالم بر زندگی ما دارن که بهش میگن تقدیر یا سرنوشت. حالا همین موضوع در دنیای شبکه هم صدق می‌کنه. اولین‌بار این اصطلاح رو در دنیای شبکه، آقای کلارک (David D. Clark) در سندی تحت عنوان “فلسفه‌ی طراحی پروتکل‌های اینترنتی DARPA” در سال 1988 معرفی کرد. به زبون ساده، fate sharing میگه:

“اگر ما مجموعه‌ای از عناصر متصل به هم رو داشته باشیم که عملکرد هر کدومشون در گرو عملکرد صحیح سایر عناصر باشه، در این صورت اگر یک عنصر بنا به هر دلیلی fail بشه، سایر عناصر هم به صورت خودکار fail خواهند شد.”

یه مثال تو دنیای واقعی برای درک بهتر این موضوع: سوار پرایدتون (مثلاً) هستین و دارین برمیگردین خونه که یهو متوجه میشین ماشین داره به سختی حرکت میکنه. سریع میزنین کنار و پیاده میشین و می‌بنین که بله یکی از چرخای عقبتون پنچر شده. موتور ماشین سالمه، سه تا چرخ دیگش سالمه امّا چون یه چرخش دچار مشکل شده عملکرد ماشینتون هم دچار مشکل شده و ماشین نمیتونه به حرکت خودش ادامه بده.

امّا ببینیم تو دنیای شبکه کجاها ممکنه fate sharing رخ بده. یکی از مصداقای اصلی بروز fate sharing در هنگام مجازی‌سازی (virtualization) هست. یعنی زمانی که ما یک یا چندتا توپولوژی مجازی رو بر روی یک بستر فیزیکی پیاده‌سازی می‌کنیم. در این صورت هر مشکلی برای اون بستر فیزیکی رخ بده، قطعاً توپولوژی‌های مجازی که بر روی اون پیاده‌سازی شدن هم دچار مشکل میشن.

  • مثلاً: فرض کنین روی یک سوییچ 100 تا VLAN پیاده‌سازی کردین و یه پورت رو هم ترانک در نظر گرفتین که این پورت در واقع مرتبط با یه لینک فیزیکی اترنت هست و حالا اگر اون لینک فیزیکی دچار مشکل بشه، عملاً تمام VLAN‌های شما دچار مشکل میشن.

 

  • یک مثال دیگه: معمولاً در ساختارهای سوییچینگ (device‌های سیسکو به عنوان مثال) برای ساده‌تر شدن مدیریت و پیکربندی سوییچ‌ها، افزایش redundancy و همینطور تحمل خطا یا همون fault tolerance و … از تکنولوژی‌هایی مثل Cisco StackWise یا Virtual Switching System (VSS) استفاده میشه. با استفاده از این تکنولوژی‌ها در واقع ما control plane همه‌ی سوییچ‌ها رو یکی می‌کنیم و به جای چندتا سوییچ، یک سوییچ مجازی خواهیم داشت که کل تغییرات و پیکربندی‌ها رو بر روی اون انجام میدیم. امّا در پس این رخداد مجازی، در واقع یک سوییچ حقیقی هست که نقش master رو به عهده میگیره.

زمانی که control planeها یکی میشن در واقع switch engine سوییچی که نقش master رو داره وظیفه‌ی فوروارد ترافیک‌ها رو به عهده داره. در یکسری از سوییچ‌ها مثل سری 4500، میشه از ماژول‌های supervisor engine استفاده کرد و بار پردازش رو تا حد زیادی افزایش داد اما این موضوع برای تمام سری‌ها صدق نمیکنه و اون‌ها فقط یک switch engine دارن که وظیفه‌ی پردازش رو بر عهده داره و نمیشه به هیچ طریقی هم ارتقاش داد. بنابراین اگر میزان بار ترافیک از حدی بیشتر بشه، switch engine توان پردازش این حجم عظیم رو نداره و fail میشه و این fail شدن منجر میشه ارتباطات خیلی از end-pointهای متصل به لینک‌های افزونه هم از دست بره.

  • یک مثال دیگه در دنیای سرویس پروایدرها: یه سازمانی برای کسب و کار خودش میاد و با یه ISP قرارداد می‌بنده و از طریق اون ISP چندین L3VPN با شعب خودش برقرار میکنه. در همچین حالتی اگر تنها راه ارتباطی این شعب با هم، همین ارتباط لایه سه VPN باشه، هر اتفاقی که برای زیرساخت اون ISP یا حتّی روتر edge اون ISP رخ بده که از دسترس خارج بشه، کل ارتباطات L3VPN اون سازمان با شعبش هم دچار اختلال میشه.

علاوه بر مشکلاتی که برای بستر مجازی مطرح شد گاهی اوقات که درصدش هم ممکنه خیلی کم باشه امّا احتمال بروزش هست، fate sharing رو زمانی خواهیم داشت که مثلاً یه سازمان برای این که redundancy رو افزایش بده از دوتا لینک ارتباطی برای ارتباط با روتر edge در ISP استفاده میکنه. اگر این دوتا لینک از طریق یک مجرای کابل (conduit) یکسان به روتر edge در ISP برسن، هر اتفاقی برای این مجرای کابل بیوفته، در واقع هر دو لینک ارتباطی از دسترس خارج میشن.

امّا همیشه هم الزاماً وقوع fate sharing بد نیس.

مثلاً فرض کنید که یکسری BGP Speaker به صورت غیر مستقیم با هم peer شده باشن (از طریق یه ارتباط لایه دو مثلاً یه بستر IXP) و  تو این ساختار از مکانیزمای تشخیص خطایی مثل BFD هم بنا به هر دلیلی استفاده نشده باشه. در همچین حالتی اگر یکی از روترهای BGP از دسترس خارج بشه؛ مثلاً کابلش از سوییچی که بین روترهای BGP قرار داره کشیده بشه؛ بقیه‌ی BGP Speaker ها نمی‌تونن بلافاصله از این تغییر باخبر بشن و در نتیجه مسیرهایی که الان در دسترس نیستن (یعنی مسیرهایی که از طریق روتر BGP ای که الان در دسترس نیست، در دسترس بودن) باید Hold Timer (که معمولا زمانی بین 90 تا 180 ثانیه هست) براشون سپری بشه تا از BGP Table سایر روترهای BGP حذف بشن. دراین صورت تا زمانی که Hold Timer منقضی بشه، اگر روتر BGP از دسترس خارج شده هنوز به ساختار برنگشته باشه و نتونه ترافیک رو به مقصد درست هدایت کنه، blackhole در ساختار ایجاد میشه (پکت ها به مقاصدی میرن که الان در دسترس نیستن).

مثال بالا هم مصداقی از fate sharing هست و بر عکس موارد قبلی بهتره که در همچین حالتی اتفاقاً fate sharing رخ بده و بلافاصله با قطعی لینک یک همسایه، کلاً ارتباطش با بقیه‌ی همسایه‌هاش در همون لحظه قطع بشه که البته قبلاً طی مطلبی در بلاگ، به این موضوع پرداخته شد.

موارد بالا فقط تعداد کمی از مصادیق بروز fate sharing بودن. همونطور که دیدین چیزایی که در زمان پیاده‌سازی، در واقع خیلی ساده و ابتدایی و حتّی مفید و به‌صرفه به نظر می‌رسیدن، از دید یه طراح و با یه نگاه و بررسی دقیق‌، می‌تونن حتّی بحران‌ساز تلقی بشن.

نتیجه این که:  اصطلاح fate sharing یه اصطلاح در طراحی شبکه هست که طراح شبکه در زمان طراحی ساختار برای به حداقل رسوندن مشکلات احتمالی حتماً باید اون رو مد نظر قرار بده. این که چطور میشه از بروز مشکلات یاد شده و وقوع fate sharing جلوگیری کرد، متناسب با هر ساختار و شرایط و امکانات موجود، متفاوته و صد البته که انتخاب بهترین روش، مستقیماً وابسته به هوش، آینده‌نگری و هنر طراحی، طراح شبکه هست.

نویسنده: مینا رضائی

محقق و همیشه در حال یادگیری، عاشق نقاشی، گاهی هم نویسندگی یا تألیف کتابای بزرگ :) (مسئولیت و صحت و سقم کلیه ی مطالب منتشر شده از جانب من تنها بر عهده ی خودم می باشد)

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

این سایت از اکیسمت برای کاهش هرزنامه استفاده می کند. بیاموزید که چگونه اطلاعات دیدگاه های شما پردازش می‌شوند.