تحمل خطا در سیستم های توزیع شده چیست؟ – به زبان ساده

هدف مهم در طراحی سیستم های توزیع شده این است که سیستم بتواند به طور خودکار از خرابی‌های جزئی بازیابی شود، بدون اینکه عملکرد کلی آن به شدت تحت تاثیر قرار گیرد. به عبارت دیگر، در زمان وقوع خرابی، سیستم باید در حین انجام تعمیرات، همچنان به شکلی قابل قبول به کار خود ادامه دهد. به این ویژگی تحمل خطا در سیستم های توزیع شده گفته می‌شود. ویژگی کلیدی که سیستم های توزیع شده را از سیستم‌های تک‌ماشینی متمایز می‌کند، مفهوم «خرابی جزئی» (Partial Failure) است. این یعنی بخشی از سیستم از کار می‌افتد، در حالی که بخش‌های دیگر به کار خود ادامه می‌دهند و در ظاهر بدون مشکل عمل می‌کنند.

در این مطلب از مجله فرادرس، مسئله تحمل خطا در سیستم های توزیع شده را بررسی می‌کنیم. ابتدا مفهوم «تحمل خطا» را بررسی کرده و سپس انواع شکست‌های ممکن را توضیح می‌دهیم. بعد از آن چندمورد از رایج‌ترین خطاهای ممکن را هم راه با راه‌حل هر کدام به صورت کلی معرفی می‌کنیم.

تحمل خطا چیست؟

برای درک نقش تحمل خطا در سیستم های توزیع شده، ابتدا باید با مفهوم تحمل خطا آشنا شویم. تحمل خطا ارتباط نزدیکی با سیستم‌های «قابل اعتماد» (Dependable) دارد. «قابلیت اعتماد» شامل تعدادی از ویژگی‌های مفید برای سیستم های توزیع شده است. این موارد را در فهرست پایین معرفی کرده‌ایم.

• «دسترس‌پذیری» (Availability): اطمینان از اینکه سیستم در زمان نیاز در دسترس است.
• «قابلیت اطمینان» (Reliability): اطمینان از اینکه سیستم به طور مداوم و بدون خطا کار می‌کند.
• «ایمنی» (Safety): اطمینان از اینکه خرابی سیستم منجر به آسیب یا خطر نمی‌شود.
• «قابلیت نگهداری» (Maintainability): سهولت در تعمیر و نگهداری سیستم.

در دسترس بودن (Availability)

در دسترس بودن یعنی آن که سیستم آماده استفاده فوری است. به طور کلی، این مفهوم به احتمال کارکرد صحیح سیستم در هر لحظه و در دسترس بودن آن برای انجام وظایفش به نفع کاربران اشاره می‌کند.

قابلیت اطمینان (Reliability)

قابلیت اطمینان یعنی آن که سیستم بتواند به طور مداوم و بدون خطا کار کند. برخلاف در دسترس بودن، قابلیت اطمینان در طول زمان تعریف می‌شود، نه در یک لحظه خاص. سیستمی که «قابلیت اطمینان بالایی» دارد، می‌تواند در دوره زمانی طولانی بدون وقفه به کار خود ادامه بدهد.

به عنوان مثال، اگر سیستمی به طور متوسط در هر ساعت برای یک میلی‌ثانیه و به شکل تصادفی از کار بیفتد، در دسترس بودن آن بیش از ۹۹.۹۹۹۹ درصد خواهد بود، اما همچنان غیرقابل اعتماد است. به طور مشابه، سیستمی که هرگز از کار نمی‌افتد اما دو هفته مشخص در ماه اوت تعطیل است، قابلیت اطمینان بالایی دارد. اما تنها ۹۶ درصد در دسترس بودن را ارائه می‌دهد. این دو مفهوم یکسان نیستند.

ایمنی

«ایمنی» (Safety) یعنی آن که وقتی سیستمی به طور موقت عملکرد صحیح خود را از دست می‌دهد، هیچ رویداد فاجعه‌باری رخ ندهد. برای مثال، بسیاری از سیستم‌های کنترل فرآیند، مانند آن‌هایی که برای کنترل نیروگاه‌های هسته‌ای یا اعزام انسان به فضا استفاده می‌شوند، ملزم به ارائه درجه بالایی از ایمنی هستند. اگر چنین سیستم‌های کنترلی برای مدت کوتاهی دچار نقص موقت شوند، اثرات آن می‌تواند ویرانگر باشد. بسیاری از نمونه‌های گذشته نشان داد‌ه‌اند که ساخت سیستم‌های ایمن بسیار دشوار است.

قابلیت نگهداری

در نهایت، «قابلیت نگهداری» (Maintainability) یعنی آن که سیستم معیوب چقدر به راحتی قابل تعمیر است. سیستمی که قابلیت نگهداری بالایی دارد، ممکن است درجه بالایی از در دسترس بودن را نیز نشان دهد، به خصوص اگر خرابی‌ها به صورت خودکار شناسایی و تعمیر شوند. با این حال، همانطور که در این بخش خواهیم دید، بازیابی خودکار خرابی‌ها آسان‌تر از آن است که گفته می‌شود.

امنیت (Security)

اغلب، سیستم‌های قابل اعتماد ملزم به ارائه درجه بالایی از امنیت، به ویژه در مورد مسائلی مانند «یکپارچگی» (Integrity) هستند. در این‌باره باید به سه اصطلاح زیر توجه کنید.

• «شکست» (Fail): هر سیستمی که به وظایف خود عمل نکند، «شکست خورده» در نظر گرفته می‌شود. به طور خاص، فرض کنیم سیستم توزیع شده‌ای با هدف ارائه تعدادی سرویس به کاربران خود طراحی شده است. سیستم زمانی شکست می‌خورد که یک یا چند مورد از آن خدمات به طور کامل قابل ارائه نباشند.
• «خطا» (Error): خطا بخشی از وضعیت سیستم است که ممکن است منجر به شکست شود. به عنوان مثال، هنگام انتقال بسته‌ها در شبکه، انتظار می‌رود که برخی بسته‌ها در هنگام رسیدن به گیرنده آسیب دیده باشند. آسیب‌دیدگی در این زمینه به معنی آن است که گیرنده شاید مقدار بیت را اشتباه درک کند. یعنی ۰ را به جای ۱ بخواند و برعکس. یا شاید حتی نتواند رسیدن پیام‌ها را تشخیص بدهد.
• «نقص» (Fault): نقص، علت خطا است. درک اینکه چه چیزی باعث خطا شده، مهم است. به عنوان مثال، رسانه انتقال نادرست یا نامناسب ممکن است به راحتی باعث آسیب دیدن بسته‌ها شود. در این حالت، حذف نقص نسبت به دیگر مشکلات آسان‌تر است. با این حال، خطاهای انتقال ممی‌توانند به دلیل شرایط آب و هوایی نامناسب، مانند شبکه‌های بی‌سیم، نیز به وجود بیایند. تغییر آب و هوا برای کاهش یا جلوگیری از خطا کار دشوارتری است.

مدل‌های شکست (Failure Models)

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

روابط وابستگی اینچنینی در سیستم های توزیع شده بسیار زیاد هستند. به عنوان مثال، فرض کنیم فایل سروری برای ارائه «فایل سیستم با دسترسی بالا» (Highly Available File System) طراحی شده است. در چنین سیستمی وجود دیسک معیوب می‌تواند کار را دشوار کند. شاید این سرور فایل، بخشی از پایگاه داده توزیع شده باشد. در این صورت عملکرد صحیح کل پایگاه داده نیز ممکن است به خطر بیفتد. زیرا تنها قسمت خاصی از داده‌های آن قابل دسترسی خواهند بود.

در جدول پایین چند مورد از شکست‌ها و توضیح هر کدام نوشته شده‌اند.

بسیاری از موارد ذکر شده در بالا به وضعیتی می‌پردازند که در آن فرآیند P دیگر هیچ اقدامی را از سوی فرآیند Q درک نمی‌کند. با این حال، آیا P می‌تواند نتیجه بگیرد که Q واقعاً متوقف شده است؟ برای پاسخ به این سؤال، باید بین دو نوع سیستم توزیع شده تمایز قائل شویم.

• در سیستم «ناهمگام» (Asynchronous)، هیچ فرضی در مورد سرعت اجرای فرآیندها یا زمان تحویل پیام‌ها صورت نمی‌گیرد. در نتیجه، هنگامی که فرآیند P دیگر متوجه هیچ اقدامی از Q نشود، نمی‌تواند نتیجه بگیرد که Q از کار افتاده است. زیرا شاید Q فقط کند باشد، یا پیام‌های آن گم شده باشند.
• در سیستم «همگام» (Synchronous)، سرعت اجرای فرآیندها و زمان تحویل پیام‌ها محدود است. این بدان معناست که هنگامی که Q دیگر فعالیتی از خود نشان نمی‌دهد، فرآیند P می‌تواند به درستی نتیجه بگیرد که Q از کار افتاده است. زیرا انتظار می‌رود که Q به طور منظم کار کند.

سیستم‌های کاملا همگام فقط در دنیای تئوری وجود دارند. از طرفی، گفتن اینکه همه‌ی سیستم های توزیع شده مثل شبکه‌های ناهمگام هستند (یعنی هیچ نظم زمانی مشخصی ندارند) هم درست نیست. این مسئله باعث می‌شود در طراحی‌ها بیش از حد محتاط باشیم. بهترین رویکرد این است که فرض کنیم سیستم‌ها تا حدی همگام هستند. یعنی بیشتر اوقات مثل سیستم همگام کار می‌کنند، اما گاهی اوقات ممکن است رفتار ناهمگام داشته باشند.

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

چطور مهندسی نرم افزار را در فرادرس بیاموزیم؟

وب سایت آموزشی فرادرس برای کمک به دانشجویان و افراد علاقه‌مند به مهندسی کامپیوتر مجموعه آموزشی تخصصی را در این زمینه تهیه و منتشر کرده است. این مجموعه آموزشی شامل فیلم‌های متنوعی درباره طراحی و توسعه محصولات نرم‌افزاری و کامپیوتری است. مهندسی نرم‌افزار یکی از شاخته‌های تخصصی علوم کامپیوتر است. شاغلان این بخش هم باید با اصول توسعه نرم‌‌افزار و زبان‌های برنامه نویسی مختلف آشنا باشند و هم توانایی درک نیاز‌های مخاطبان و مشتریان خود را بدست بیاورند. موقعیت‌های شغلی متنوع و خوبی در مقابل مهندسان نرم‌افزار قرار دارد.

فرادرس در این مجموعه آموزش تلاش کرده است که کامل‌ترین و جامع‌ترین مطالب را ارائه بدهد. به این منظور، فرادرس از اساتید با تجربه‌ای استفاده کرده و به طور دائم در حال تولید فیلم‌های آموزشی جدید و مدرن است. در فهرست پایین، چند مورد از فیلم‌های آموزشی مجموعه آموزش مهندسی نرم‌افزار را معرفی کرده‌ایم. برای مشاهده فیلم‌های بیشتر می‌توانید بر روی تصویر بالا کلیک کنید.

• فیلم آموزش رایگان دیزاین پترن چیست؟ الگوی طراحی در مهندسی نرم‌ افزار و کاربرد آن
• فیلم آموزش کارگاه کامپیوتر از مبانی تا برنامه نویسی وب + گواهینامه
• فیلم آموزش کوئری‌ نویسی پیشرفته در SQL Server + گواهینامه
• فیلم آموزش رایگان ساختمان داده ها به صورت سریع و آسان در ۱۲۰ دقیقه + گواهینامه
• فیلم آموزش مهندسی نرم افزار، مرور و حل سوالات آزمون های استخدامی + گواهینامه

در ادامه یکی دیگر از روش‌های ایجاد تحمل خطا را بررسی کرده‌ایم.

پوشاندن شکست با افزونگی

برای ایجاد تحمل خطا در سیستم های توزیع شده، بهترین کار این است که سعی کنیم وقوع شکست‌ها را از سایر فرآیندها پنهان کنیم. تکنیک کلیدی برای پوشاندن خطاها، استفاده از «افزونگی» (Redundancy) است.

سه نوع افزونگی زیر وجود دارند.

• افزونگی اطلاعات (Information Redundancy): افزونگی اطلاعات یعنی افزودن اطلاعات اضافه به داده‌ها، طوری که اگر بخشی از داده‌ها خراب شد، بتوانیم با استفاده از آن اطلاعات، داده‌های خراب را درست کنیم. به عنوان مثال، «کد همینگ» (Hamming Code) را می‌توان به داده‌های منتقل شده اضافه کرد تا تا در صورت بروز خطا، بتوان اطلاعات اصلی را بازیابی کرد.
• «افزونگی زمان» (Time Redundancy): در این حالت ابتدا عمل خاصی انجام شده و سپس در صورت نیاز، همان عمل دوباره انجام می‌شود. تراکنش‌ها از این رویکرد استفاده می‌کنند. هر تراکنشی اگر لغو شود، می‌توان آن را بدون هیچ ضرری دوباره انجام داد، زیرا هنوز هیچ چیز نهایی نشده است.
• «افزونگی فیزیکی» (Physical Redundancy): افزونگی فیزیکی یعنی آن که تجهیزات یا فرآیندهای بیشتری اضافه می‌شوند تا سیستم بتواند از بین رفتن یا بد کار کردن برخی از بخش‌ها را تحمل کند. افزونگی فیزیکی را می‌توان هم در سخت‌افزار و هم در نرم‌افزار انجام داد. به عبارت دیگر، با زیاد کردن فرایند‌ها می‌توان به درجه بالایی از تحمل خطا در سیستم های توزیع شده دست یافت.

تاب آوری فرآیند

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

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

تاب‌آوری توسط گروه‌های فرآیندی

کاربردی‌ترین روش برای تحمل فرآیندهای معیوب، سازماندهی چندین فرآیند یکسان در گروه است. ویژگی کلیدی همه گروه‌ها این است که وقتی پیامی به گروه ارسال می‌شود، همه اعضا آن را دریافت می‌کنند. به این ترتیب، اگر فرآیندی در گروه از کار بیفتد، امیدواریم فرآیند دیگری بتواند جایگزین آن شود.

• «گروه‌های فرآیندی» (Process Groups) می‌توانند پویا باشند. یعنی گروه‌های جدید ایجاد شوند و گروه‌های قدیمی از بین بروند.
• فرآیندها می‌توانند در طول عملیات سیستم به گروه بپیوندند یا از آن خارج شوند.
• هر فرآیند می‌تواند همزمان عضو چندین گروه باشد.

در نتیجه، مکانیزم‌هایی برای مدیریت گروه‌ها و عضویت در گروه مورد نیاز است. هدف از معرفی گروه‌ این است که به هر فرآیند اجازه دهد مجموعه‌هایی از دیگر فرآیندها را به عنوان ساختار یکسان در نظر بگیرد. بنابراین، فرآیند P می‌تواند پیامی را به گروه $$Q = {Q1, . . . , QN}$$ از سرورها ارسال کند، بدون نیاز به اینکه آن‌ها را بشناسد، بداند چند نفر هستند یا کجا قرار دارند.

سازماندهی گروهی

تفاوت مهم گروه‌های مختلف مربوط به ساختار داخلی آن‌ها است. در برخی گروه‌ها، همه فرآیندها برابر هستند، یعنی گروه مسطح است. هیچ رهبر مشخصی وجود ندارد و تمام تصمیمات به صورت جمعی گرفته می‌شود. به طور معمول، بسیاری از سیستم‌های «همتا به همتا» (Peer-To-Peer) به این شکل عمل می‌کنند. بعضی از گروه‌ها به شکل سلسله مراتبی کار می‌کنند. یعنی فرآیندی نقش هماهنگ‌کننده را برعهده می‌گیرد و بقیه کارگر هستند. در این مدل، هنگام رسیدن درخواست‌ها اول به هماهنگ‌کننده ارسال می‌شوند. سپس هماهنگ‌کننده تصمیم می‌گیرد که کدام کارگر بهترین گزینه برای بررسی این درخواست است.

هر یک از این ساختار‌ها مزایا و معایب خاص خود را دارد.

بعضی از اصطلاحات جدول بالا را در پایین توضیح داده‌ایم.

• انعطاف‌پذیری در برابر خرابی: نشان‌دهنده میزان توانایی گروه در ادامه فعالیت در صورت بروز مشکل در یک یا چند فرآیند است.
• نیاز به الگوریتم انتخاب رهبر: نشان‌دهنده این است که آیا برای تعیین جانشین در صورت از دست دادن رهبر، نیاز به الگوریتم مشخصی وجود دارد یا خیر.

مدیریت عضویت

وقتی ارتباط از نوع گروهی باشد، باید قوانینی هم برای مدریت گروه‌ها وجود داشته باشد.

• قانون اول: باید سروری مسئول مدیریت رفتار‌های گروه شود. سرور گروه می‌تواند پایگاه داده کاملی از همه گروه‌ها و فهرست دقیق اعضای آن‌ها را نگهداری کند. این روش، سرراست، کارآمد و آسان برای پیاده‌سازی است. نقطه‌ضعف این روش، وجود «نقطه شکست واحد» (Single Point Of Failure) است. یعنی اگر سرور گروه از کار بیفتد، مدیریت گروه به طور کل از بین می‌رود. این مسئله ممکن است موجب توقف کامل کارهای در حال انجام شود.
• قانون دوم: مدیریت عضویت در گروه به صورت توزیع شده انجام شود. برای مثال، عضو بیرونی پیامی برای همه اعضای گروه می‌فرستد و اعلام می‌کند که قصد پیوستن به گروه را دارد.
• قانون سوم: در حالت ایده‌آل، برای خروج از گروه، عضو فقط پیام خداحافظی برای همه ارسال می‌کند. اما مشکل اینجاست که هیچ اعلام مودبانه‌ای هنگام از کار افتادن فرآیندها وجود ندارد. اعضای دیگر باید با مشاهده اینکه عضو از کار افتاده و دیگر به هیچ چیزی پاسخ نمی‌دهد، این موضوع را به صورت تجربی کشف کنند. هنگامی که اطمینان حاصل شد عضو از کار افتاده است، می‌توان آن را از گروه حذف کرد.
• قانون چهارم:‌ مسئله مهم دیگر این است که ورود و خروج باید هم‌زمان با ارسال پیام‌های داده انجام شود. به عبارت دیگر، از لحظه‌ای که فرآیندی به گروهی پیوسته است، باید تمام پیام‌های ارسال شده به آن گروه را دریافت کند. به طور مشابه، به محض اینکه فرآیندی از گروهی خارج شد، نباید دیگر هیچ پیامی از گروه دریافت کند و اعضای دیگر نیز نباید دیگر هیچ پیامی از آن دریافت کنند.
• قانون پنجم: باید به این مسئله پاسخ داد که شاید آنقدر فرآیندها از کار بیفتند که گروه دیگر نتواند کار کند. در این صورت چه باید کرد؟ پروتکلی برای بازسازی گروه مورد نیاز است. در نتیجه، برخی فرآیندها باید ابتکار عمل را برای شروع کار به دست بگیرند، اما اگر دو یا سه فرآیند به صورت همزمان این کار را انجام دهند چه اتفاقی می‌افتد. پروتکل باید بتواند در برابر این وضعیت مقاومت کند.

پوشاندن خطا و تکثیر

«گروه‌های فرآیندی» (Process Groups) بخشی از راه‌حل برای طراحی دستورالعمل تحمل خطا در سیستم های توزیع شده هستند. برای مثال، داشتن گروهی از فرآیندهای یکسان به سیستم اجازه می‌دهد یک یا چند فرآیند معیوب موجود در گروه را پنهان بکند. در حالت تکثیر مبتنی بر سرور، گروهی از فرآیندها به صورت سلسله‌مراتبی سازمان می‌یابند. سپس سرور همه عملیات نوشتن را هماهنگ می‌کند. در عمل، سرور ثابت است، اگرچه در صورت لزوم، یکی از پشتیبان‌ها می‌تواند نقش آن را بر عهده بگیرد.

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

• خطای ساده (فقط از کار افتادن): برای تحمل «k» خطا، «k + 1» نسخه تکثیر شده لازم است.
• خطای پیچیده (جواب اشتباه دادن): برای تحمل k خطا، «2k + 1» نسخه لازم است.
• شکست سیستم: اگر تعداد بخش‌های خراب از k بیشتر شود، کل سیستم از کار می‌افتد و قابل اعتماد نیست.

ارتباط قابل اعتماد کلاینت-سرور

اغلب اوقات، منظور از تحمل خطا در سیستم های توزیع شده، مدیریت فرایندهای معیوب است. اما نباید فراموش کنیم که اختلال در ارتباطات شبکه نیز بسیار مهم است. در واقع، همان خطاهایی که برای پردازشگرها وجود دارند مثل توقف ناگهانی، نرسیدن پیام، تاخیر یا رفتارهای غیرقابل‌پیش‌بینی، برای کانال‌های ارتباطی هم صدق می‌کنند. با این حال، وقتی می‌خواهیم شبکه‌ قابل اعتماد بسازیم، اولویت اصلی پنهان کردن خطاهای «توقف» و «نرسیدن پیام» است.

نکته مهم دیگر، بروز خطاهای غیرقابل پیش‌بینی مثل «تکرار پیام‌ها» است. این اتفاق اغلب به آن دلیل رخ می‌دهند که پیام‌ها برای مدتی طولانی در شبکه ذخیره می‌شوند. بنابراین شاید فرستنده فکر کند پیام قبلی نرسیده است و آن را دوباره ارسال کند. درست در همین، ممکن است پیام اول هم از راه برسد و باعث ایجاد تکرار در شبکه شود. برای درک این بخش لازم است که با مدل کلاینت سرور در شبکه‌های کامپیوتری آشنا باشید. در صورت نیاز به کمک بیشتر در این‌باره، پیشنهاد می‌کنیم که مطلب مربوط به آن را در مجله فرادرس مطالعه کنید.

ارتباط نقطه به نقطه

در بسیاری از سیستم های توزیع شده، ارتباط قابل اعتماد نقطه به نقطه با استفاده از پروتکل انتقالی مانند TCP برقرار می‌شود. TCP تضمین می‌کند که هیچ پیامی گم نشود. اگر پیامی ارسال شود و گیرنده به محض دریافت، آن را تایید می‌کند. اگر فرستنده این تاییدیه را دریافت نکند، یعنی احتمال دارد که پیام گم شده باشد. بنابراین TCP آن را دوباره می‌فرستد. چنین خرابی‌هایی به طور کامل از کلاینت TCP پنهان می‌شوند.

اما پروتکل TCP نمی‌تواند قطع شدن ناگهانی اتصال را پنهان کند. با قطع شدن ناگهانی اتصال TCP، برای مثال به دلیل مشکل شبکه، دیگر هیچ پیامی رد و بدل نمی‌شود. بیشتر اوقات کلاینت با دریافت پیغام خطا از این اتفاق، مطلع می‌شود. تنها راه برای پنهان کردن این نوع از خرابی‌ها آن است که به سیستم توزیع شده اجازه دهیم تا با ارسال مجدد درخواست، تلاش کند تا اتصال جدیدی را برقرار بکند. فرض اساسی این است که طرف مقابل به چنین درخواست‌هایی پاسخ می‌دهد.

معانی RPC در حضور خرابی‌ها

در این قسمت با استفاده از روشی مانند «فراخوانی رویه از راه دور» (Remote Procedure Call | RPC)، نگاهی دقیق‌تر به ارتباط کلاینت-سرور می‌اندازیم. هدف اصلی RPC این است که ارتباط بین دو دستگاه را تا حد امکان به فراخوانی توابع در دستگاه واحد شبیه کند. تا زمانی که همه چیز به درستی کار می‌کند، RPC در این کار موفق است. اما در زمان رویدادن خطا، کار پیچیده می‌شود. برای بررسی بهتر این مشکلات، خطاهای ممکن در سیستم‌های RPC را به پنج دسته اصلی تقسیم می‌کنیم.

• کلاینت قادر به یافتن سرور نیست.
• پیام درخواست از کلاینت به سرور گم می‌شود.
• سرور پس از دریافت درخواست، کرش می‌کند.
• پیام پاسخ از سرور به کلاینت گم می‌شود.
• کلاینت پس از ارسال درخواست، کرش می‌کند.

هر کدام از این دسته‌بندی‌ها مشکلات مختلفی هستند که به راه‌حل اختصاصی خود نیاز دارند.

کلاینت قادر به یافتن سرور نیست

ممکن است کلاینت قادر به یافتن سرور مناسب نباشد. به عنوان مثال، شاید همه سرورها خاموش باشند. از طرف دیگر، فرض کنید کلاینت برای مدت زمان قابل توجهی به‌روزرسانی نشده اما سرور تکامل یافته و نسخه جدیدی از رابط بر روی آن نصب شده است. در نتیجه هنگامی که کلاینت اجرا می‌شود، «اتصال‌دهنده» (Binder) قادر به تطبیق آن با سرور نیست و خرابی را گزارش می‌‌کند.

یکی از راه‌حل‌ها این است که خطا باعث ایجاد «استثنا» (Exception) شود. در برخی زبان‌ها (مانند جاوا)، برنامه‌نویسان می‌توانند رویه‌های ویژه‌ای بنویسند که در صورت بروز خطاهای خاص، مانند تقسیم بر صفر، فراخوانی شوند. در C، می‌توان از «مدیریت‌کننده‌های سیگنال» (Signal Handlers) برای این منظور استفاده می‌شود.

این رویکرد نیز معایبی دارد.

• همه زبان‌ها دارای استثنا یا «مدیریت‌کننده‌ سیگنال» نیستند.
• نکته دیگر آن است که نوشتن رویه‌ای برای مدیریت استثنا یا سیگنال، «شفافیت» (Transparency) را از بین می‌برد.

پیام‌های درخواست گم‌شده

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

کرش سرور

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

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

در مورد نحوه برخورد با خطاهای RPC، سه رویکرد اصلی وجود دارد:

• صبر و امتحان مجدد: منتظر می‌مانیم تا سرور دوباره فعال شود یا «Middleware»، کلاینت را به طور خودکار به سرور دیگری وصل کند. سپس عملیات را تکرار می‌کنیم.
• گزارش فوری شکست: بلافاصله شکست را گزارش می‌دهیم. این تضمین می‌کند که RPC حداکثر یک بار اجرا شده، یا شاید به طور کل اجرا نشده باشد.
• بدون تضمین: هیچ قولی در مورد اجرای عملیات داده نمی‌شود. RPC ممکن است صفر، یک یا چند بار اجرا شود. مزیت اصلی این رویکرد، سادگی پیاده‌سازی آن است.

پیام‌های پاسخ از سرور به کلاینت گم‌شده

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

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

کرش کلاینت

آخرین مورد در لیست خرابی‌ها، کرش کلاینت است. اگر کلاینتی بعد از ارسال درخواست و پیش از پاسخ سرور، کرش کند. در این مرحله عملیات خاصی فعال است ولی هیچ والدی منتظر نتیجه نیست. چنین عملیات «یتیم» (Orphan) نامیده می‌شود. محاسبات یتیم مشکلاتی را ایجاد می‌کنند که به عملکرد عادی سیستم آسیب می‌زند. برای نمونه، آن‌ها توان پردازشی را هدر می‌دهند. همچنین می‌توانند فایل‌ها را قفل کرده یا منابع ارزشمند دیگری را اشغال کنند.

اگر بعد از راه‌اندازی مجدد، کلاینت دوباره درخواست RPC را بفرستد و هم‌زمان پیامی هم از سمت سرور برسد که می‌گوید «این عملیات انجام شده است»، شاید کلاینت دچار سردرگمی بشود. به این وضعیت اجرای «حداکثر یک بار» (At-Most-Once) می‌گویند، یعنی عملیات یا فقط یک بار انجام می‌شود، یا اصلاً انجام نمی‌شود.

برای حل این مشکل، می‌توانیم از «نقطه بازرسی» (Checkpointing) استفاده کنیم. با ایجاد نقطه بازرسی، درست قبل از ارسال درخواست RPC و بازگرداندن کلاینت به آن حالت پس از راه‌اندازی مجدد، می‌توانیم بسیاری از مشکلات مربوط به پردازه‌های یتیم را برطرف کنیم. به عبارت دیگر، اجازه می‌دهیم پردازه‌های یتیم کار خود را انجام دهند و سپس کلاینت را به درستی به حالت قبل از خطا بازمی‌گردانیم.

اما در مورد خود یتیم‌ها چه می‌توان کرد. یکی از راه‌حل‌ها این است که قبل از ارسال پیام RPC، کلاینت ابتدا در فایل گزارش ثبت می‌کند که قصد انجام چه کاری را دارد. این گزارش در جایی امن مانند دیسک، ذخیره می‌شود. در نتیجه پس از خرابی سیستم باقی می‌ماند. پس از راه‌اندازی مجدد، سیستم این گزارش را بررسی کرده و محاسبات یتیم را به طور مشخص متوقف می‌کند. به این راه حل «ریشه‌کن کردن یتیم» (Orphan Extermination) گفته می‌شود.

ارتباط گروهی قابل اعتماد

«ارتباط گروهی قابل اعتماد» (Reliable Group Communication) یعنی تمام پیام‌های ارسال شده به گروه باید به تمام اعضای آن تحویل داده شوند. بنابراین لازم است که منطق مدیریت پیام‌ها را از عملکرد اصلی اعضای گروه جدا کنیم. در این صورت به راحتی می‌توانیم بین دریافت و تحویل پیام‌ها تمایز قائل شویم.

در نتیجه، امکان ارسال پیام قابل اعتماد، ویژگی است که باید از عملکرد اصلی اعضای گروه جدا شود. بیشتر اوقات، این قابلیت توسط مولفه مدیریت پیام یا سیستم عامل پیاده‌سازی می‌شود.

مقیاس‌پذیری در مولتی کست

مشکل اصلی طرح «مولتی‌کست قابل اعتماد» (Reliable Multicasting) این است که نمی‌تواند تعداد زیادی گیرنده را پشتیبانی کند. یعنی آن که اگر N گیرنده وجود داشته باشد، فرستنده در کمترین حالت باید N «تاییدیه» (Acknowledgement) دریافت کند. اگر تعداد گیرنده‌ها زیاد باشد، فرستنده زیر حجم انبوه بازخوردها سردرگم می‌شود. به این حالت، «تراکم بازخورد» (Feedback Implosion) می‌گویند. البته بیشتر اوقات در زمان تکرار فرآیندها برای تحمل خطا در سیستم های توزیع شده این مشکل پیش نمی‌آید، چون گروه‌ها کوچک هستند. اما وقتی هدف افزایش کارایی باشد، شرایط فرق می‌کند. همچنین شاید گیرنده‌ها در شبکه گسترده‌ای پراکنده باشند. این مسئله این مشکل را بیشتر می‌کند.

یکی از راه‌حل‌های مشکل تراکم بازخورد، این است که گیرنده‌ها دریافت پیام را تایید نکنند. در عوض، فقط وقتی بازخورد بفرستند که پیام را دریافت نکرده‌اند. ثابت شده است که بیشتر اوقات استفاده از «تاییدیه‌های منفی» کارآمدتر است، اما باز هم نمی‌توان تضمین کرد که تراکم بازخورد هیچ‌وقت رخ ندهد.

مشکل دیگر در استفاده از تاییدیه‌های منفی این است که فرستنده، در تئوری، مجبور است نسخه‌ای از هر پیام را برای همیشه در بافر حافظه خود نگه دارد. چونکه فرستنده هرگز نمی‌داند که آیا پیام به درستی به همه گیرندگان تحویل داده شده است یا خیر، در نتیجه همیشه باید آماده باشد. زیرا ممکن است گیرنده‌ای درخواست ارسال مجدد پیام را داشته باشد. اما در واقعیت، فرستنده بعد از مدتی پیام‌ها را از حافظه حذف می‌کند تا از سرریز شدن بافر جلوگیری کند. هرچند مشکل بالا هنوز به قوت خود باقیست.

این راه‌حل‌های ساده‌، تحمل خطا در سیستم های توزیع شده را بهتر می‌کنند.

مولتی کست اتمی

به طور معمول، برای تحمل خطا در سیستم های توزیع شده لازم است که هر پیام یا به همه اعضای سالم گروه برسد، یا به هیچ‌کدام نرسد. این مسئله را «چندپخشی اتمی» (Atomic Multicast) یا «مولتی کست اتمی» می‌نامند.

برای درک اهمیت اتمی بودن، «پایگاه داده‌ تکرار شده‌ای» (Replicated Database) را در نظر بگیرید که روی سیستم توزیع شده‌ اجرا می‌شود. این سیستم، امکان «مولتی‌کست قابل اعتماد» را فراهم کرده است. بنابراین می‌توان در آن، گروه‌هایی از فرآیندها را ساخت که پیام‌ها به طور قطعی برایشان ارسال می‌شود. در این حالت، پایگاه داده از چند بخش، تشکیل شده است. هر بخش، نماینده یکی از کپی‌هاست. هر تغییر ایجاد شده در اطلاعات، به تمام کپی‌ها فرستاده می‌شود. سپس هر کپی، آن تغییر را روی خودش اعمال می‌کند. این کار با استفاده از روشی به نام «تکرار فعال» انجام می‌شود.

همگام‌سازی مجازی (Virtual Synchrony)

حتی اگر بعضی قسمت‌های سیستم خراب شوند، باز هم پیام‌ها با اطمینان به همه اعضای سالم گروه می‌رسند. همانطور که اشاره کردیم، بین «دریافت» پیام و «تحویل» آن به برنامه، تفاوت وجود دارد. وقتی پیامی به یکی از بخش‌های سیستم می‌رسد، ابتدا در همان بخش ذخیره می‌شود. این عملیات تا زمانی است که پیام بتواند به برنامه اصلی تحویل داده شود. برنامه اصلی که در لایه بالاتری قرار دارد، نیز به عنوان عضوی از گروه در نظر گرفته می‌شود.

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

ترتیب پیام‌ها (Message Ordering)

همگام‌سازی مجازی، ارسال‌های همگانی (مولتی‌کست‌ها)‌ را دسته‌بندی می‌کند. این دسته‌ها با تغییر اعضای گروه جدا می‌شوند. برنامه‌نویس با کمک این دسته‌بندی می‌تواند مولتی‌کست‌ها را بهتر درک کند. یعنی اینکه راحت‌تر بفهمد کدام پیام‌ها به کدام اعضا و با چه ترتیبی ارسال شده‌اند. به طور کلی، چهار نوع ترتیب برای این مولتی‌کست‌ها وجود دارد.

• «مولتی‌کست‌های نامرتب» (UnOrdered Multicasts)
• «مولتی‌کست‌های با ترتیب FIFO» یا (FIFO-Ordered Multicasts)
• «مولتی‌کست‌های با ترتیب علّی» (Causally Ordered Multicasts)
• «مولتی‌کست‌های با ترتیب کلی» (Totally Ordered Multicasts)

«مولتی‌کست قابل اعتماد و نامرتب» همان «مولتی‌کست همگام‌سازی مجازی» (Virtually Synchronous Multicast) است که در آن هیچ تضمینی در مورد ترتیب تحویل دادن پیام‌های دریافتی توسط فرآیندهای مختلف، ارائه نمی‌شود.

یادگیری مهندسی فناوری اطلاعات با کمک فرادرس

به توسعه، نگهداری و استفاده از نرم‌افزارهای کامپیوتری، سیستم‌ها و شبکه‌ها فناوری اطلاعات یا IT، گفته می‌شود. در IT از نرم‌افزار و سخت‌افزار برای پردازش و توزیع داده‌ها استفاده می‌کنیم. در صورتی که از فناوری لذت می‌برید و همواره خود را با آخرین پیشرفت‌ها در حوزه IT به‌روز نگه می‌دارید، با یادگیری مهارت‌های آی تی می‌توانید سرگرمی خود را به شغلی تمام وقت یا کسب و کاری پردرآمد تبدیل کنید. فرادرس به منظور کمک به افراد علاقه‌مند به این حوزه، مجموعه‌ای از فیلم‌های آموزشی و اختصاصی را تولید و منتشر کرده است.

در فهرست زیر چند مورد از فیلم‌‌های این مجموعه آموزشی را معرفی کرده‌ایم.

• فیلم آموزش مدیریت پروژه‌ های فناوری اطلاعات IT، پیشرفته
• فیلم آموزش رایگان سیلیکون ولی و غول های دنیای تکنولوژی همراه با معرفی و بررسی شرکت‌ ها
• فیلم آموزش رایگان آی تی IT یا فناوری اطلاعات چیست؟ تعریف و مفاهیم کاربردی 
• فیلم آموزش رایگان آشنایی دواپس DevOps همراه با مبانی و مقدمات
• فیلم آموزش مدیریت خدمات فناوری اطلاعات سازمان ها به شکل عملی با ManageEngine ServiceDesk

برای مشاهده و بررسی فیلم‌های بیشتر بر روی تصویر پایین کلیک کنید.

تعهد توزیع شده

مسئله مولتی‌کست اتمی، نمونه‌ای از مسئله کلی‌تری به نام «تعهد توزیع شده» (Distributed Commit) است. تعهد توزیع شده یعنی آن که هر عملیات یا باید توسط تک‌تک اعضای گروه انجام شود، یا اصلا انجام نشود.برای مثال، در مورد مولتی کست قابل اعتماد، آن عملیات، تحویل پیام است.

تعهد توزیع شده اغلب توسط سیستمی به نام «هماهنگ‌کننده» (Coordinator) اجرا می‌شود. به عبارت ساده‌تر هماهنگ‌کننده به تمام فرآیندهای درگیر و شرکت‌کنندگان می‌گوید که آیا عملیات مورد نظر را به صورت محلی انجام بدهند یا خیر. به این طرح، «پروتکل تعهد یک‌مرحله‌ای» (One-Phase Commit Protocol) گفته می‌شود. مشکل این طرح آنجاست که اگر یکی از شرکت‌کنندگان نتواند وظیفه خود را انجام دهد، راهی برای اطلاع دادن به هماهنگ‌کننده وجود ندارد.

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

فاز اول:

1. هماهنگ‌کننده پیام «درخواست رای» (Vote-Request) به تمام شرکت‌کنندگان ارسال می‌کند.
2. هنگامی که شرکت‌کننده‌ای پیام درخواست رای را دریافت می‌کند، یا پیام «رای-تعهد» (Vote-Commit) به هماهنگ‌کننده برمی‌گرداند (با این کار به هماهنگ‌کننده می‌گوید که آماده است بخش خود از تراکنش را به صورت محلی تعهد کند) یا در غیر این صورت، پیام «رای-انصراف» (Vote-Abort) ارسال می‌کند.

فاز دوم:

1. هماهنگ‌کننده تمام آراء را از شرکت‌کنندگان جمع‌آوری می‌کند. اگر همه شرکت‌کنندگان به تعهد تراکنش، رای داده باشند، هماهنگ‌کننده نیز همین کار را انجام خواهد داد. یعنی اینکه پیام «تعهد کلی» (Global-Commit) به تمام شرکت‌کنندگان ارسال می‌کند. با این حال، اگر شرکت‌کننده‌ای به انصراف از تراکنش رای داده باشد، هماهنگ‌کننده نیز تصمیم به انصراف از تراکنش گرفته و پیام «انصراف کلی» (Global-Abort) را پخش می‌کند.
2. هر شرکت‌کننده‌ای که به تعهد رای داده است، منتظر واکنش نهایی هماهنگ‌کننده می‌ماند. اگر شرکت‌کننده پیام تعهد کلی را دریافت کند، تراکنش را به صورت محلی تعهد می‌کند. در غیر این صورت، هنگام دریافت پیام انصراف کلی، تراکنش نیز به صورت محلی لغو می‌شود.

Recovery

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

دو شکل از بازیابی خطا وجود دارد.

برای بازیابی خطا دو روش مشهور وجود دارد.

• استفاده از تکنیک Checkpointing
• ثبت پیام - لاگ کردن وضعیت

نقطه گذاری (Checkpointing)

در سیستم توزیع شده «مقاوم در برابر خطا» (Fault-Tolerant)، برای استفاده از ویژگی «بازیابی خطا رو به عقب» (Backward Error Recovery) باید سیستم به طور منظم وضعیت خود را ذخیره کند. به عبارت دقیق، نیاز به ثبت «وضعیت سراسری سازگار» (Consistent Global State) داریم. به این وضعیت، «تصویر لحظه‌ای توزیع شده» (Distributed Snapshot) نیز گفته می‌شود. در تصویر لحظه‌ای توزیع شده، اگر فرآیند P دریافت پیامی را ثبت کرده باشد، آنگاه باید فرآیند Q نیز ارسال آن پیام را ثبت کرده باشد.

برای بازیابی پس از خرابی فرآیند یا کل سیستم، باید با کمک وضعیت‌های محلی ذخیره شده در هر فرآیند، «وضعیت سراسری سازگار» بسازیم. به طور خاص، مناسب‌ترین نقطه برای بازگشت، آخرین لحظه‌ای توزیع شده‌ای است که به آن «خط بازیابی» (Recovery Line) گفته می‌شود.

ثبت پیام (Message Logging)

توجه کنید که پیاده‌سازی Checkpointing می‌تواند به عملیاتی پرهزینه تبدیل شود. بنابراین باید ضمن حفظ امکان بازیابی وضعیت از روش‌هایی برای کاهش تعداد «نقاط بازرسی» (Checkpoints) نیز استفاده کنیم. یکی از این روش‌ها «ثبت پیام‌» (Logging Message) نام دارد. ایده اصلی این است که اگر دوباره بتوانیم انتقال پیام‌ها را تکرار کنیم به وضعیت سراسری هماهنگ دست پیدا می‌کنیم. در این صورت دیگر نیاز نیست که وضعیت را از حافظه محلی بازیابی کنیم. زیرا وضعیت موجود از نقطه بازرسی قبلی شروع شده و تمام پیام‌های بعد از آن دوباره ارسال و پردازش می‌شوند.

این رویکرد با فرض «مدل اجرای قطعی چندضابطه‌ای» (Piecewise Deterministic Execution Model) به خوبی کار می‌کند. در این مدل، هر فرآیند به چند بخش پشت سر هم تقسیم می‌شود. در هر بخش، رویدادهایی مثل اجرای دستور یا ارسال پیام، اتفاق می‌افتند. در این مدل، هر فاصله (هر بخش از این فرآیند) با رویداد غیرقطعی مانند دریافت پیام شروع می‌شود. اما از آن لحظه به بعد، اجرای فرآیند قطعی است. هر بخش زمانی (یا فاصله) زمانی به پایان می‌رسد که آخرین رویداد قبل از وقوع رویداد غیرقطعی بعدی اتفاق بیفتد. به عبارت دیگر، با دریافت هر پیام، بخشی تمام شده و بخش جدیدی با اتفاقات قطعی آغاز می‌شود. این کار تا زمانی انجام می‌شود که پیام غیرقطعی بعدی دریافت شود.

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

جمع‌بندی

منظور از تحمل خطا در سیستم های توزیع شده این است که سیستم بتواند در مقابل مشکلات غیرمترقبه‌ و ناگهانی از خودش تاب‌آوری نشان بدهد. ساختار سیستم‌های توزیع شده بر روی سرور‌های مجزا از هم پایه‌گذاری شده است. هر کدام از این سرور‌ها ممکن است به دلایل مختلفی دچار مشکل بشنود. معماری سیستم باید به شکلی باشد که در مقابل خطاهای مختلف تاب بیاورد و شکست نخورد. از این دید می‌توان گلوگاه‌های بروز خطا را به بخش‌های سرور، کلاینت، ارتباط بین این دو، ارتباط بین سرور‌های مختلف و غیره تقسیم کرد.

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