دانلود رایگان ترجمه مقاله بازیافت شفاف در سیستمهای توزیع شده – ۱۹۹۰

logo-4

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

 

عنوان فارسی مقاله: بازیافت شفاف در سیستمهای توزیع شده
عنوان انگلیسی مقاله: Transparent Recovery in Distributed Systems
رشته های مرتبط: مهندسی برق و مهندسی قدرت
 فرمت مقالات رایگان مقالات انگلیسی و ترجمه های فارسی رایگان با فرمت PDF میباشند
 کیفیت ترجمه کیفیت ترجمه این مقاله متوسط میباشد 
کد محصول F11

 مقاله انگلیسی رایگان

دانلود رایگان مقاله انگلیسی

ترجمه فارسی رایگان 

دانلود رایگان ترجمه مقاله
جستجوی ترجمه مقالات جستجوی ترجمه مقالات برق

  

بخشی از ترجمه فارسی:

۱٫مقدمه
ما راه حل های خوش بینانه ی شفاف را برای مشکلات سیستمهای توزیع شده همچون بازیافت،تکرار(تکثیر)،و موازی بودن وچاره های رقابت همزمان بررسی میکنیم.
با یک راه حل شفاف برای یک مسأله،ما آن را معنی میکنیم یک برنامه ای که به صورت اتوماتیک تبدیل شده است ورفتار آن برنامه مشابه رفتار یک برنامه ی تبدیل نشده است.علاوه بر این برنامه نویس و کاربرنهایی نیازی ندارند که از این تبدیل باخبر باشند. برای این قبیل مشکلات ،راه حل های شفاف نسبتأدرست هستنداگربر روی همزمان سازی تکیه کرده باشند.اما کارایی چنین متدهایی معمولأ ناچیز(ضعیف) است و همچنین پیاده سازی آن نیز گران است و شاخص نیستند.
روش (دیدگاه) ما استفاده از متدهای خوش بینانه ای است که فرض می کنیم همزمان سازی ضروری نیست و به این ناهمزمانی هنگامی رسیدگی میشود که برنامه به اجرا ادامه میدهد.ما روابط(وابستگیها ی) پردازه ی مدفون شده را پیدا می کنیم و رویدادهای غیرقطعی را ثبت می کنیم به طوری که بتوانیم برگردیم به حالت قبلی یک محاسبه که به یک فرض نادرست مربوط است.

۲٫بازیافت خوش بینانه
روش ما برای بازیافت مبنی بر بازیافت خوش بینانه است اضافه شده با بهینه سازی هایی برای کاهش اندازه ی ثبت و توسعه هایی که فایل سیستم و مؤلفه های خارجی(بیرونی)دیگر را داخل فرایند بازیافت ترکیب می کنند.
در بازیافت خوش بینانه فرض می کنیم پردازه ها خراب نیستند بویژه برای هر رویداد غیرقطعی(معمولأ یک پیام)فرض می کنیم معیوب نخواهد شد قبل از اینکه پیام آن به صورت ناهمزمان ثبت شود.هرکدام از این فرضها با یک شماره مشخص شده است و هر پردازه فرضی را که بیشترین شماره را از پردازه های دیگر دارد ثبت می کند بر اساس اینکه آن به کدام مربوط است.
در یک رویداد معیوب،پردازه ی معیوب دوباره شروع می شود وسپس همگام می شود با مجاورش با به عقب غلتیدن برای رسیدن به یک حالت سازگار (پایداری) دو طرفه (متقابل). بنابراین بازیافت در یک مکانیزم محافظه کار بسیار گران تر است. اما اجرای بدون خرابی اصولأ پیشرفت کرده است (بهبود یافته است ) زیرا وبسیاری از محاسبات می تواند به صورت ناهمزمان و با اجرای نرمال برنامه انجام شود.

۳٫تراکنشها (نقل و انتقال ها ) نارسا هستند
این موقعیت ماست که تلرانس خطای شفاف مورد نیاز است زیرا سیستمهای مبتنی بر تراکنش برای موارد کاربری توزیع شده ی بزرگ نارسا هستند. برای این امر دو دلیل اصلی وجود دارد:
اولأ تراکنشها فقط داده را بازمی گردانند نه حالت فرایند را. این در محیط محاسبات متمرکز قابل قبول بود در تراکنشهایی که توسعه یافته بودند اما در یک سیستم توزیع شده ی بزرگ حالت مؤلفه های معیوب باید ترمیم شود (به حالت اول بازگردانده شود ) تا تلرانس خطای آنها درست باشد . برای نمونه ،در یک برنامه ی کاربردی توزیع شده شامل مجموعه ای از نمایشگر ، محاسبه گر و کارسازدادگان( ) اگر یک گره پایگاه داده درهم شکند و دوباره شروع شود باید به هر طریقی دوباره ارتباطات آن را با مؤلفه های دیگر سیستم برپا کند (تجدید کند) و کاری را که نمایش داده شده است (اجرا شده است ) قبول داشته باشد و فقط پس از آن برنامه ی کاربردی توزیع شده می تواند به اجرا ادامه دهد.
در یک مورد کاربری توزیع شده ، تراکنشها هیچ پشتیبانی از نوسازی یک حالت معیوب نمی کنند. در نتیجه،حتی اگر این همزمان سازی و توافق ها ( قراردادها ) به درستی برنامه ریزی شده باشد ، برنامه ی کاربردی خراب خواهد شد گرچه پایگاه داده خراب نشده باشد.
به همین دلیل، به درستی نوشتن تلرانس خطای برنامه ی کاربردی توزیع شده نیاز خواهد داشت به برنامه نویسی اضافه شدنی گسترده برای بازآفرینی حالات همزمان سازی داخل پردازه ای.
این کد پیچیده خواهد بود و احتمالش کم است که امتحانش (آزمودنش) خوب باشد چون آن در مسیر برنامه ی کاربردی اصلی نیست و تعداد روش های معیوب زیاد خواهد بود. در نتیجه کدی که کدی که برای تهیه ی تلرانس خطا فرض شده است کوچکترین مؤلفه ی معتبر بی عیب ( یکپارچه ) سیستم خواهد بود . از طرف دیگر این کد اغلب اوقات به سادگی حذف خواهد شد هنگامی که پس از اینکه یک قسمت زیادی از نرم افزار نوشته شده و یک برنامه ی کاربردی کامل ( بی عیب ) زمانی که با یک خطای پیش بینی نشده مواجه شود و بی نتیجه بماند.
مشکل دوم تراکنش ها این است که حتی زمانی هم که فقط بازیافت داده مورد نیاز است برنامه نویس باید به طور واضح برای خرابی برنامه ریزی کند با اطمینان از اینکه تراکنش ها بقدر کافی کوتاه هستند و جابجایی به وسیله ی آگاهی دادان به کاربر ، تجدید نظر کردن (دوباره آزمایش کردن ) در تراکنش ها و… بی نتیجه می ماند.

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

بخشی از مقاله انگلیسی:

Introduction

We are investigating transparent optimistic solutions to problems in distributed systems such as recovery [6], replication [3], parallelization [2], and concurrent competing alternatives [4]. By a transparent solution to such a problem we mean that a program is transformed automatically, and that the behavior of the program is equivalent to a possible behavior of the untransformed program; in addition, the programmer and the end-user need not be aware of the transformation. Transparent solutions to such problems are relatively straightforward if synchronization is relied upon, but performance of such methods is generally poor or the implementation is too expensive, and they do not scale. Our approach is to use optimistic methods in which we guess that synchronization is unnecessary, and verify this asynchronously while the program continues execution. We track inter-process dependencies and log non-deterministic events so that we can roll back a computation that depends upon an incorrect guess. Where virtual memory virtualizes the space of a process, we virtualize time, “paging in” a previous process state when a “time fault” (or incorrect guess) occurs. 2 Optimistic Recovery Our approach to recovery is based upon optimistic recovery [6] enhanced by optimizations to reduce the amount of logging [5, 1] and extensions which incorporate the filesystem and other external components into the recovery process [7, 8]. In optimistic recovery, we guess that processors do not fail; specifically, for every non-deterministic event (usually a message), we guess that there will not be a failure before that message has been asynchronously logged. Each of these guesses is assigned a number, and each process records the highest-numbered guess of every other process upon which it depends. In the event of a failure, the failed process is restarted and then synchronized with its neighbors by rolling back to a mutually consistent state. Thus recovery is more expensive than in a conservative mechanism, but failurefree performance is substantially improved because checkpointing, logging, and much of committing can be done asynchronously and concurrently with the normal execution of the program.

  

دیدگاه ها

  • hamid ۱۳۹۶-۰۱-۱۷ :: ۱۸:۴۴

    سلام
    خیلی خیلی خیلی عالی بود
    دم همه تون گرم

ارسال دیدگاه

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