چرا از مهاجرت کد در سیستم توزیعی استفاده کنیم ؟

همانطور که در مطالب قبلی هم گفته شد، ارتباطات در سیستم های توزیعی منحصر به انتقال داده هاست؛ با این حال مواردی هم وجود دارند که انتقال برنامه ها، حتی در حین اجرای آنها، باعث ساده شدن طرح سیستم های توزیعی خواهد شد.

در این مطلب مروری داریم بر مفهوم واقعی مهاجرت کد (Code Migration) و رهیافت های مختلف مهاجرت کد را بررسی میکنیم.

در ادامه دلایل سودمند بودن مهاجرت کد را بررسی میکنیم …

دلایل مهاجرت کد

مهاجرت که در سیستم های توزیعی به طور سنتی به شکل مهاجرت فرآیند (Process Migration) انجام میشود، که طی آن کل فرآیند از یک ماشین به ماشین دیگر انتقال می یابد.

انتقال یک برنامه در حال اجرا به ماشینی دیگر کاری هزینه بر و دقیق است و اگر دلیل خوبی برای آن وجود نداشته باشد، میتوان به راحتی از آن گذشت!

همانند سایر ایده ها، دلیل اصلی همواره بهبود کارآیی بوده است.

ایده اصلی این است که میتوان با انتقال فرآیندها از ماشین های دارای بار زیاد به ماشین های کم بار، کارآیی کلی سیستم را افزایش داد.

بار را غالباً به صورت طول صف پردازنده یا بهره وری از پردازنده تعریف میکنند، اما شاخصه های کارآیی دیگری را هم میتوان به تعریف فوق اضافه کرد.

 

الگوریتم های توزیع بار (Load Distribution)، که تصمیمات مربوط به تخصیص و توزیع مجدد کارها با توجه به وضعیت پردازنده های موجود بر عهده آنها قرار دارد، نقش مهمی را در سیستم های محاسباتی سنگین ایفا میکنند.

با این وجود، در بسیاری از سیستم های توزیعی مدرن، بهینه سازی ظرفیت محاسباتی به اندازه مسائلی مشابه به حداقل رساندن ارتباطات اهمیت ندارد.

همچنین، به دلیل ناهمگن بودن بسترهای زیربنایی و شبکه های کامپیوتری، بهبود کارآیی از طریق مهاجرت کد، به جای مدل ریاضی، غالباً بر اساس استدلال کمی استوار است.

 

جهت تفهیم بهتر، یک مثال میزنم:

یک سیستم مشتری – خدمتگزار را در نظر بگیرید که خدمتگزار آن مدیریت یک پایگاه داده عظیم را بر عهده دارد.

چنانچه برنامه کاربردی مشتری نیاز به انجام عملیات متعدد پایگان داده بر روی مقادیر بزرگ داده داشته باشد، شاید بهتر باشد که بخشی از برنامه کاربردی مشتری به خدمتگزار انتقال یافته و صرفاً نتایج عملیات روی شبکه ارسال شود.

در غیراینصورت، ممکن است شبکه با سیل عظیمی از داده های در حال تبادل بین خدمتگزار و مشتری مواجه شود.

حال مهاجرت کد بر اساس این قضیه صورت خواهد گرفت که بهتر است داده ها در مجاورت محل استقرار خودشان پردازش شوند.

 

از همین استدلال میتوان برای مهاجرت بخش هایی از خدمتگزار به مشتری استفاده نمود.

برای مثال، در بسیاری از برنامه های کاربردی پایگاه داده، نیاز داریم تا کاربر (مشتری سیستم) فرم هایی را تکمیل کند تا بعداً به صورت مجموعه ای از عملیات پایگاه داده ترجمه شوند.

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

در نتیجه مشتری با کارآیی بهتری مواجه شده و خدمتگزار هم مدت زمان کمتری را صرف پردازش فرم و ارتباطات خواهد کرد.

 

پشتیبانی از مهاجرت کد همچنین میتواند با بهره گیری از موازی سازی (البته بدون ظرفیت های معمول در برنامه نویسی موازی) به بهبود کارآیی کمک کند.

به عنوان نمونه، میتوان به جستجوی اطلاعات در شبکه وب اشاره کرد.

تقریباً به راحتی میتوان پرس و جو های وب را به شکل یک برنامه سیار کوچک یا به اصطلاح عامل سیار (Mobile Agent) که میتواند از یک سایت به سایت دیگر حرکت کند، اجرا کرد.

با ایجاد چندین کپی از این نوع برنامه ها و ارسال آنها به سایت های مختلف، میتوان سرعت جستجو را به طور خطی (در مقایسه با استفاده از فقط یک برنامه کاربردی) افزایش داد.

 

علاوه بر بهبود کارآیی، دلایل دیگری هم برای پشتیبانی از ایده مهاجرت کد میتوان ارائه کرد، که مهمترین آنها مسئله انعطاف پذیری است.

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

به عنوان مثال، این رهیافت منجر به برنامه کاربردی مشتری – خدمتگزار چند طبقه مختلفی شده است که از بحث این مطلب خارج است!

 

چنانچه کد بتواند بین ماشین های مختلف جابجا شود، پیکربندی پویای سیستم های توزیعی هم امکان پذیر خواهد شد.

به عنوان مثال، فرض کنید یک خدمتگزار مفروض واسط استانداردی به یک سیستم فایل را پیاده سازی کرده است.

برای فرآهم آوردن امکانات دسترسی مشتریان از راه دور به این سیستم فایل، خدمتگزار از یک پروتکل اختصاصی (Proprietary Protocol) استفاده میکند.

پیاده سازی واسط سیستم فایل در طرف مشتری، که بر اساس این پروتکل استوار است، معمولاً نیازمند برقراری پیوند با برنامه کاربردی مشتری است.

در این حالت لازم است که چنین نرم افزاری در زمان ایجاد برنامه کاربردی مشتری، موجود و در دسترس باشد.

 

یک رهیافت جاگزین این است که خدمتگزار، پیاده سازی مورد نیاز مشتری را فقط زمانی که مشتری نیازمند آن است ارائه نماید؛ یعنی زمانی که مشتری به خدمتگزار پیوند میخورد.

در این زمان، مشتری به گونه ای پویا این پیاده سازی را بارگیری کرده، مراحل آماده سازی اولیه را انجام میدهد و در انتها خدمتگزار را فراخوانی میکند.

روش گفته شده، جهت درک بهتر، در تصویر زیر نشان داده شده است.

 

این مدل انتقال پویای کد از سایت راه دور مسلماً نیازمند یک پروتکل استاندارد برای بارگیری کد و گذراندن مراحل آماده سازی است.

علاوه بر این، باید بتوان کد بارگیری شده را روی ماشین مشتری اجرا نمود. (راه حل هایی نیز برای این مسئله وجود دارد …)

 

یکی از مزایای مهم مدل بارگیری پویای نرم افزار سمت مشتری آن است که دیگر لازم نیست مشتریان برای ارتباط به خدمتگزار، از قبل نرم افزار را نصب کرده باشند؛ به جای آن میتوانیم در هنگام نیاز نرم افزار را انتقال دهیم و پس از استفاده آن را حذف کنیم!

 

مزیت دوم این است که در صورت استاندارد بودن واسط ها میتوان پروتکل مشتری – خدمتگزار و پیاده سازی آنرا (به هر تعداد که مورد نیاز باشد) تغییر داد.

این تغییرات تاثیری بر برنامه های کاربردی مشتری که متکی به خدمتگزار هستند، نخواهد داشت.

البته این رهیافت معایبی نیز دارد که از مهمترین آنها میتوان به مشکلات امنیتی اشاره کرد.

اطمینان کورکورانه به اینکه کد بارگیری شده صرفاً همان کاری را انجام میدهد که خودش ادعا میکند و سپس فرستادن محرمانه ترین اطلاعات کاربر (از روی دیسک محافظت نشده) به جایی که اصلاً مشخص نیست، ایده چندان خوبی به نظر نمیرسد!

البته در صورتی که روی مسئله امنیتی این موضوع کار شود، میتواند نتایج و ثمره های خوبی داشته باشد.