صفحه محصول - طراحي و پياده سازي يک زمانبندِکار اشکال آگاه در سيستمهاي محاسبات ابری

طراحي و پياده سازي يک زمانبندِکار اشکال آگاه در سيستمهاي محاسبات ابری (docx) 1 صفحه

دسته بندی : تحقیق

نوع فایل : Word (.docx) ( قابل ویرایش و آماده پرینت )

تعداد صفحات: 1 صفحه

قسمتی از متن Word (.docx) :

دانشکده آموزشهای الکترونیکیپايان‌نامه كارشناسی ارشد در رشته ی مهندسی فناوری اطلاعات(طراحی و تولید نرم افزار)طراحي و پياده سازي يک زمانبندِکار اشکالآگاه در سيستمهاي محاسبات ابريبه کوششروشنک لکی شیرازاستاد راهنماآقای دکتر فرشاد خون جوشاستادان مشاورآقای دکتر غلامحسین دستغیبی فردخانم دکتر منیژه کشتگریاسفند ماه 1391ﺑـﻪ ﻧﺎم ﺧـﺪاﺍﻇﻬﺎﺭﻧﺎﻣــﻪﺍﯾﻨﺠﺎﻧﺐ روشنک لکی شیراز( 897159 )ﺩﺍﻧﺸﺠــﻮی ﺭﺷﺘـــﻪی مهندسی فناوری اطلاعات ﮔﺮﺍﯾش طراحی و تولید نرم افزار، دانشکدﻩی‌ آموزشهای الکترونیکی ﺍﻇﻬﺎﺭﻣﯽﮐﻨﻢ ﮐﻪ ﺍﯾﻦ ﭘﺎﯾﺎﻥ ﻧﺎﻣﻪ ﺣﺎﺻﻞ ﭘﮋوﻫﺶ ﺧﻮﺩﻡ ﺑﻮﺩﻩ و ﺩﺭ ﺟﺎﻫﺎﯾﯽ ﮐﻪ ﺍﺯ ﻣﻨﺎﺑﻊ ﺩﯾﮕﺮﺍﻥ ﺍﺳﺘﻔﺎﺩﻩ ﮐﺮﺩﻩﺍﻡ، ﻧﺸﺎﻧﯽ ﺩﻗﯿﻖ و ﻣﺸﺨﺼﺎﺕ ﮐﺎﻣﻞ ﺁﻥ ﺭﺍ ﻧﻮﺷﺘﻪﺍﻡ. ﻫﻤﭽﻨﯿﻦ ﺍﻇﻬﺎﺭﻣﯽﮐﻨﻢ ﮐﻪ ﺗﺤﻘﯿﻖ و ﻣﻮﺿﻮﻉ ﭘﺎﯾﺎﻥ ﻧﺎﻣﻪﺍﻡ ﺗﮑﺮﺍﺭیﻧﯿﺴﺖ و ﺗﻌﻬﺪ ﻣﯽﻧﻤﺎﯾﻢ ﮐﻪ ﺑﺪوﻥ ﻣﺠﻮﺯ ﺩﺍﻧﺸﮕﺎﻩ ﺩﺳﺘﺎوﺭﺩﻫﺎی ﺁﻥ ﺭﺍ ﻣﻨﺘﺸر ﻧﻨﻤﻮﺩﻩ و ﯾﺎ ﺩﺭ ﺍﺧﺘﯿﺎﺭ ﻏﯿﺮ ﻗﺮﺍﺭ ﻧﺪﻫﻢ. ﮐﻠﯿﻪ ﺣﻘﻮﻕ ﺍﯾﻦ ﺍﺛﺮ ﻣﻄﺎﺑﻖ ﺑﺎ ﺁﯾﯿﻦﻧﺎﻣﻪ ﻣﺎﻟﮑﯿﺖ ﻓﮑﺮی و ﻣﻌﻨﻮی ﻣﺘﻌﻠﻖ ﺑﻪ ﺩﺍﻧﺸﮕﺎﻩ ﺷﯿﺮﺍﺯ ﺍﺳﺖ.ﻧﺎﻡ وﻧﺎﻡ ﺧﺎﻧﻮﺍﺩﮔﯽ :ﺗﺎﺭﯾﺦ و ﺍﻣﻀﺎ:به نام خداطراحي و پياده سازي يک زمانبندِ کار اشکالآگاه در سيستمهاي محاسبات ابريبه کوششروشنک لکی شیرازپایان نامهاﺭﺍﺋﻪ ﺷﺪﻩ ﺑﻪ ﺗﺤﺼﯿﻼﺕ ﺗﮑﻤﯿﻠﯽ ﺩﺍﻧﺸﮕﺎﻩ ﺷﯿﺮﺍﺯ ﺑﻪ ﻋﻨﻮﺍﻥ ﺑﺨﺸﯽ ﺍﺯ ﻓﻌﺎﻟﯿﺖﻫﺎی ﺗﺤﺼﯿﻠﯽ ﻻﺯﻡ ﺑﺮﺍی ﺍﺧﺬ ﺩﺭﺟﻪ ﮐﺎﺭﺷﻨﺎﺳﯽ ﺍﺭﺷﺪﺩﺭ ﺭﺷﺘﻪی: فناوری اطلاعاتاز دانشگاه شیرازشیرازجمهوری اسلامی ایرانارزﻳﺎﺑﻲ ﻛﻤﻴﺘﻪي ﭘﺎﻳﺎنﻧﺎﻣﻪ، ﺑﺎ درﺟﻪي: ------------ دکتر فرشاد خون جوش استادیار بخش مهندسی و علوم کامپیوتر دانشگاه شیراز(رئیس کمیته)-----------------دکتر غلامحسین دسنغیبی فرد استادیار بخش مهندسی و علوم کامپیوتر دانشگاه شیراز-----------------------دکتر منیژه کشتگری استادیار بخش مهندسی کامپیوتر و فناوری اطلاعات دانشگاه صنعتی شیراز----------------ماحصل آموخته هایم را تقدیم می کنم به آنان که مهر آسمانی شان آرام بخش آلام زمینی ام است به استوارترین تکیه گاهم، دستان پرمهر پدرم  به پراميدترين نگاه زندگیم، چشمان اميدبخش مادرم که هرچه آموختم در مکتب عشق شما آموختم و هرچه بکوشم قطره ای از دریای بی کران مهربانیتان را سپاس نتوانم بگویم. بوسه بر دستان پرمهرتانكه تمام تجربه های یکتا و زیبای زندگیم، مدیون حضور سبز شماستسپاسگزاریاکنون که این رساله به پایان رسیده است، بر خود لازم می دانم که پس از سپاسگزاری از خدای منان، از استاد راهنمای ارجمندم، جناب آقای دکتر فرشاد خون جوش، استادیار بخش مهندسی و علوم کامپیوتر دانشگاه شیراز، که در مسير انجام اين پروژه از مساعدت‌ها و راهنمايي‌های بي‌شائبه ايشان بهره‌های فراوان بردم، تشکر نمایم. بي‌شک بدون کمک‌های ايشان پيمودن اين راه بسيار سخت مي‌نمود.همچنین از اساتید گرانقدرم، جناب آقای دکتر غلامحسین دسنغیبی فرد استادیار بخش مهندسی و علوم کامپیوتر دانشگاه شیراز و سرکار خانم دکتر منیژه کشتگری استادیار بخش مهندسی کامپیوتر و فناوری اطلاعات دانشگاه صنعتی شیراز که بر من منت نهاده و اساتید مشاور من در این رساله بوده اند سپاسگزارم.روشنک لکی شیرازاسفند ماه 91 چکيدهطراحي و پياده سازي يک زمانبندِکار اشکالآگاه در سيستمهاي محاسبات ابريبه کوششروشنک لکی شیراز با افزایش بازار استفاده از تکنولوژی محاسبات ابری، مراکز داده عظیمی به وجود آمدهاند تا محاسبات را سریعتر انجام دهند. يکي از دغدغههاي اصلي در محاسبات ابری، مواجهشدن با اشکالها در حين اجرا کردن يک برنامه موازي زمانبر است. براي غلبه بر اين قبيل مشکلات، عموما از روشهاي آزمون نقطهمقابلهگيري يا آرشيوکردن استفاده ميشود. اما اين روشها غالبا سربار بالايي دارند و به صورت واکنشي عمل ميکنند. در اين پایاننامه روشي را معرفي ميکنيم که علاوه بر بازيافت و بازگشت به عقب برای تحمل پذیری اشکال، بتواند گرههای محاسباتی که احتمال وقوع خرابی در آنها بیشتر است را شناسایی نماید و به صورت پیشکنشی عمل کرده و ماشینهای مجازی را که بر روی آنها قرار دارد به گرههای محاسباتی امنتر مهاجرت دهد تا در صورت وقوع اشکال در گره مشکوک برنامه موازی بدون وقفه به کار خود ادامه دهد. علاوه بر آن، در این الگوریتم با بهرهگیری از قانون بیز و مدل هزینه پیشنهادی، آزمون نقطهمقابلهگيري زائد تا حد امکان حذف شده و زمان اجرای برنامه بهبود خواهد یافت. با استفاده ازشبیهسازی نشان میدهیم که روش پیشنهادی بسته به شرایط مختلف تا 78% زمان اجرا را بهبود میبخشد و از منابع کمتری استفاده میکند. واژههای کلیدی: سیستمهای محاسبات ابر، پیشبینی اشکال، مدل مبتنی بر هزینه، قانون بیز، پیشکنشی، آزمون نقطهمقابلهگيري هماهنگ ، مهاجرت. فهرست مطالب عنوان صفحه TOC \o "1-3" \h \z \u 1مقدمه PAGEREF _Toc347985971 \h 22قابليت دسترسي بالا PAGEREF _Toc347985972 \h 92-1مفاهيم پايه قابليت دسترسي بالا PAGEREF _Toc347985973 \h 102-1-1تعريف قابليت دسترسي بالا PAGEREF _Toc347985974 \h 102-1-2مفاهيم و مباحث مرتبط با قابليت دسترسي بالا PAGEREF _Toc347985975 \h 112-1-3معيارهاي سنجش قابليت دسترسي PAGEREF _Toc347985976 \h 132-1-4سطوح قابليت دسترسي بالا PAGEREF _Toc347985977 \h 152-1-5توقف برنامه‌ريزي شده و توقف برنامه‌ريزي نشده PAGEREF _Toc347985978 \h 162-1-6عوامل مؤثر بر ميزان دسترسي سيستم PAGEREF _Toc347985979 \h 182-2دستيابي به قابليت دسترسي بالا در سيستم‌هاي كلاستر PAGEREF _Toc347985980 \h 192-2-1تعريف نقاط منفرد بروز خرابی PAGEREF _Toc347985981 \h 192-2-2از بين بردن نقاط منفرد بروز خرابی در اجزاي سخت‌افزاري PAGEREF _Toc347985982 \h 192-2-3از بين بردن نقاط منفرد بروز اشكال در اجزاي نرم‌افزاري PAGEREF _Toc347985983 \h 282-2-4تشخيص دهندۀ خرابي در كلاسترهاي با قابليت دسترسي بالا PAGEREF _Toc347985984 \h 302-2-5معماري کلاسترهاي با قابليت دسترسيبالا PAGEREF _Toc347985985 \h 322-2-6اتصالات و شبکه کلاستر PAGEREF _Toc347985986 \h 342-2-7مديريت و نظارت بر کلاستر PAGEREF _Toc347985987 \h 342-2-8تصوير يکپارچه سيستم (SSI) PAGEREF _Toc347985988 \h 413روالهای تحمل‌پذیر اشکال برای رسیدن به قابلیت دسترسی بالا در سیستمهای مبادله پیام PAGEREF _Toc347985989 \h 363-1پيشزمينه و تعاريف PAGEREF _Toc347985990 \h 393-1-1مدل سيستم PAGEREF _Toc347985991 \h 393-1-2حالت‌هاي سيستم يكپارچه PAGEREF _Toc347985992 \h 403-1-3تعامل با دنياي خارج PAGEREF _Toc347985993 \h 423-1-4پيام در حال گذر PAGEREF _Toc347985994 \h 433-1-5قراردادهاي ثبت وقايع PAGEREF _Toc347985995 \h 443-1-6ذخيره‌ساز پايدار PAGEREF _Toc347985996 \h 463-1-7جمع‌آوري داده‌هاي زائد PAGEREF _Toc347985997 \h 473-2بازيافت براساس نقطه مقابله PAGEREF _Toc347985998 \h 483-2-1نقطه مقابله گرفتن به صورت غيرهماهنگ PAGEREF _Toc347985999 \h 483-2-2نقطه مقابله گرفتن به صورت هماهنگ PAGEREF _Toc347986000 \h 533-2-3نقطه مقابله گرفتن بر اساس ارتباطات PAGEREF _Toc347986001 \h 573-3بازيافت بر اساس ثبت وقايع PAGEREF _Toc347986002 \h 623-3-1شرط يكپارچگي بدون پروسه‌هاي يتيم PAGEREF _Toc347986003 \h 633-3-2ثبت بدبينانه وقايع PAGEREF _Toc347986004 \h 643-3-3ثبت خوشبينانه وقايع PAGEREF _Toc347986005 \h 683-3-4ثبت علّي وقايع PAGEREF _Toc347986006 \h 713-3-5مقايسه قراردادهاي بازيافت PAGEREF _Toc347986007 \h 743-4مباحث مطرح در پياده‌سازي PAGEREF _Toc347986008 \h 743-4-1بررسي PAGEREF _Toc347986009 \h 743-4-2پياده‌سازي تکنيکهاي نقطه مقابله گرفتن PAGEREF _Toc347986010 \h 753-4-3مقايسة قراردادهاي نقطه مقابله‌ گرفتن PAGEREF _Toc347986011 \h 773-4-4قراردادهاي ارتباطي PAGEREF _Toc347986012 \h 783-4-5بازيافت بر اساس روش ثبت وقايع PAGEREF _Toc347986013 \h 793-4-6ذخيره‌ساز پايدار PAGEREF _Toc347986014 \h 803-4-7دنبال كردن وابستگي PAGEREF _Toc347986015 \h 813-4-8بازيافت PAGEREF _Toc347986016 \h 824کارهاي انجام شده اخیر PAGEREF _Toc347986017 \h 714-1مروري بر روش‌هاي پيشبيني اشکال PAGEREF _Toc347986018 \h 724-1-1کلاسه بندي و اشکالهاي ريشه آماری PAGEREF _Toc347986019 \h 734-1-2مدل آماري زمان ميان خرابي‌ها PAGEREF _Toc347986020 \h 744-1-3جمع‌آوري و پيش‌پردازش داده‌هاي مرتبط با خرابي PAGEREF _Toc347986021 \h 744-2تکنيک‌هاي پيش‌بيني اشکال PAGEREF _Toc347986022 \h 764-2-1حدآستانه مبتني بر آمار PAGEREF _Toc347986023 \h 764-2-2آناليز سري‌هاي زماني PAGEREF _Toc347986024 \h 764-2-3کلاسه‌بندي مبتني بر قانون PAGEREF _Toc347986025 \h 774-2-4مدل‌هاي شبکه بيزي PAGEREF _Toc347986026 \h 784-2-5مدل‌هاي پردازش شبه مارکوف PAGEREF _Toc347986027 \h 794-3مطالعات انجام گرفته PAGEREF _Toc347986028 \h 805روش پيشنهادي PAGEREF _Toc347986029 \h 865-1مدل اشکال PAGEREF _Toc347986030 \h 865-1-1متوسط زماني تا خرابي PAGEREF _Toc347986031 \h 905-2مبانی احتمال و پیشبینی PAGEREF _Toc347986032 \h 925-2-1مفاهیم اولیه PAGEREF _Toc347986033 \h 925-2-2رابطه قانون بيز و احتمال درستي پيش‌بيني PAGEREF _Toc347986034 \h 945-3رابطه الگوريتم پيش‌بيني و مدل اشکال PAGEREF _Toc347986035 \h 965-3-1تحليل روابط احتمالي PAGEREF _Toc347986036 \h 965-4مدل پيشنهادي PAGEREF _Toc347986037 \h 1005-4-1ارائه الگوريتم PAGEREF _Toc347986038 \h 1035-4-2مدل مبتني بر هزينه PAGEREF _Toc347986039 \h 1055-4-3اثر پيش‌بيني‌کننده بر روي مدل‌هاي هزينه PAGEREF _Toc347986040 \h 1105-4-4تصميم‌گيري سيستم در کارگزار ابر PAGEREF _Toc347986041 \h 1126نتایج آزمایشها PAGEREF _Toc347986042 \h 1096-1معرفی شبیه‌ساز CloudSim PAGEREF _Toc347986043 \h 1096-1-1اجزای ابر PAGEREF _Toc347986044 \h 1106-1-2اجزای اصلی هسته PAGEREF _Toc347986045 \h 1126-1-3سرویس‌های موجود و الگوریتم‌های آن‌ها PAGEREF _Toc347986046 \h 1166-1-4روند کار شبیهساز PAGEREF _Toc347986047 \h 1186-2نحوه پیادهسازی سیستم تحمل‌پذیر اشکال در شبیهساز PAGEREF _Toc347986048 \h 1196-2-1FaultInjector PAGEREF _Toc347986049 \h 1216-2-2FaultPredictor PAGEREF _Toc347986050 \h 1246-2-3FTHost PAGEREF _Toc347986051 \h 1266-2-4FTDatacenter PAGEREF _Toc347986052 \h 1266-2-5FTDatacenterBroker PAGEREF _Toc347986053 \h 1276-3نتایج آزمایشات PAGEREF _Toc347986054 \h 1306-3-1بررسی اثر سربار نقطه مقابله‌گیری PAGEREF _Toc347986055 \h 1336-3-2بررسی عمل‌های انتخابی PAGEREF _Toc347986056 \h 1346-3-3خرابی‌های متوقف سازنده و غیر متوقف سازنده PAGEREF _Toc347986057 \h 1377نتیجه گیری و پیشنهادات PAGEREF _Toc347986058 \h 140منابع PAGEREF _Toc347986059 \h 142 فهرست شکلها TOC \h \z \c "شکل" شکل ‏11رویکرد یه تکنولوژی‌های مختلف محاسبات توزیع شده [1] PAGEREF _Toc347719165 \h 3 شکل ‏21 سهم عوامل مختلف در از کارافتادگی سیستم HA [11] PAGEREF _Toc347719166 \h 16 شکل ‏22 برخی SPOFها در سیستم سرویسدهنده/سرویسگیرنده PAGEREF _Toc347719167 \h 18 شکل ‏23 SPOFها در یک شبکه اترنت نوعی PAGEREF _Toc347719168 \h 22 شکل ‏24 حذف SPOFهای شبکه به روش افزونگی کامل PAGEREF _Toc347719169 \h 23 شکل ‏25 نمونهای از تشخیص خرابی با سیگنال ضربان قلب PAGEREF _Toc347719170 \h 26 شکل ‏26 نمای ساده از نظارت PAGEREF _Toc347719171 \h 31 شکل ‏27 ارتباط اجزا مختلف EMS PAGEREF _Toc347719172 \h 31 شکل ‏31 مثالی از يك سيستم مبادله پيام با سه واحد موازی PAGEREF _Toc347719173 \h 38 شکل ‏32 مثالی از حالت يكپارچه و غيريكپارچه سيستم PAGEREF _Toc347719174 \h 40 شکل ‏33 پياده‌سازي مكانيسمهاي بازيافت PAGEREF _Toc347719175 \h 42 شکل ‏34 ثبت كردن پيام براي اجراي مجدد قطعي PAGEREF _Toc347719176 \h 43 شکل ‏35 انديس نقطه مقابله و بازه نقطه مقابله PAGEREF _Toc347719177 \h 46 شکل ‏36 (a) يك اجراي مثال (b) گراف وابستگي بازگشت به عقب (c) گراف نقطه مقابله PAGEREF _Toc347719178 \h 47 شکل ‏37 انتشار بازگشت به عقب، خط بازيافت و اثر دومينو PAGEREF _Toc347719179 \h 48 شکل ‏38 نقطه مقابله گرفتن به صورت هماهنگ و غيربلوكه شونده (a) غيريكپارچگي نقطه مقابله (b) با كانال FIFO (c) با كانال غيرFIFO PAGEREF _Toc347719180 \h 49 شکل ‏39 مسير Z سيكل Z PAGEREF _Toc347719181 \h 52 شکل ‏310 روش ثبت بدبينانه وقايع PAGEREF _Toc347719182 \h 57 شکل ‏311 روش ثبت خوشبينانه وقايع PAGEREF _Toc347719183 \h 60 شکل ‏312 روش ثبت علّي وقايع (الف) حالتهاي قابل بازيافت حداكثر (ب)گراف مقدم را براي پروسه P0 در حالت X PAGEREF _Toc347719184 \h 62 شکل ‏51 منحنی وان PAGEREF _Toc347719185 \h 88 شکل ‏52 نمودار مثبت واقعی، منفی واقعی و دقت پیشبینی PAGEREF _Toc347719186 \h 95 شکل ‏53 اثر تغییرات MTTF بر روی دقت پیشبینی PAGEREF _Toc347719187 \h 96 شکل ‏54 اثر حساسیت و ویژگی بر روی دقت پیشبینی PAGEREF _Toc347719188 \h 97 شکل ‏55 شماتیک خط زمانی نقطه مقابلهگیری هماهنگ دورهای PAGEREF _Toc347719189 \h 98 شکل ‏56 شماتیک خط زمانی نقطه مقابلهگیری هماهنگ دورهای در برخورد با اشکال PAGEREF _Toc347719190 \h 99 شکل ‏57 شماتیک خط زمانی الگوریتم تطبیقی پیشنهادی PAGEREF _Toc347719191 \h 101 شکل ‏61دیاگرام کلی شبیه‌ساز[92] PAGEREF _Toc347719192 \h 116 شکل ‏62 جریان کار اجزای برنامه‌های موازی در شبیه‌ساز [92] PAGEREF _Toc347719193 \h 116 شکل ‏63 نمونه‌ای از محتویات یک فایل سناریوی خرابی گرها در یک مرکز داده PAGEREF _Toc347719194 \h 118 شکل ‏64 ماشین حالت خرابی یک گره محاسباتی در ابر PAGEREF _Toc347719195 \h 119 شکل ‏65 تکه کد تغییر وضعیت حالت میزبان‌های یک مرکزداده به صورت بهینه PAGEREF _Toc347719196 \h 120 شکل ‏66 تکه کد پیش‌بینی وضعیت یک گره محاسباتی در زمان آینده time PAGEREF _Toc347719197 \h 121 شکل ‏67 در صد بهبود زمان اجرای الگوریتم‌های پیشنهادی نسبت به الگوریتم آزمون نقطه مقابله‌گیری دوره‌ای کلاسیک PAGEREF _Toc347719198 \h 126 شکل ‏68 در صد بهبود زمان اجرای الگوریتم‌های پیشنهادی نسبت به الگوریتم آزمون نقطه مقابله‌گیری دوره‌ای کلاسیک با افزایش زمان نقطه مقابله‌گیری به 5 دقیقه PAGEREF _Toc347719199 \h 127 شکل ‏69 تعداد عمل‌های انتخابی در طول زمان اجرا با الگوریتم نقطه مقابله‌گیری دوره‌ای PAGEREF _Toc347719200 \h 128 شکل ‏610 تعداد عمل‌های انتخابی در طول زمان اجرا با الگوریتم تطبیقی اولیه PAGEREF _Toc347719201 \h 128 شکل ‏611 تعداد عمل‌های انتخابی در طول زمان اجرا با الگوریتم تطبیقی تصحیح شده PAGEREF _Toc347719202 \h 129 شکل ‏612 تعداد اشکال‌هایی که در طول اجرای برنامه سبب توقف یا عدم توقف ابر می‌شوند PAGEREF _Toc347719203 \h 130 فهرست جداول TOC \h \z \c "جدول" جدول ‏11 قابلیت اطمینان در مراکز داده مختلف[4] PAGEREF _Toc347719204 \h 5 جدول ‏21 مقایسه کلاسترهای HA و FT [13] PAGEREF _Toc347719205 \h 11 جدول ‏22 زمانهای توقف و کارکرد یک سیستم 52×7×12 PAGEREF _Toc347719206 \h 14 جدول ‏23 زمان‌هاي توقف و كاركرد يك سيستم 52×5×12 PAGEREF _Toc347719207 \h 14 جدول ‏31 مقايسه بين قراردادهاي مختلف بازيابي [47] PAGEREF _Toc347719208 \h 64 جدول ‏51 رابطه وضعیت محیط و الگوریتم پیشبینی PAGEREF _Toc347719209 \h 91 جدول ‏52 تعاریف پارامترهای استفاده شده در مدلها PAGEREF _Toc347719210 \h 102 جدول ‏53 مدل هزینه عمل مهاجرت PAGEREF _Toc347719211 \h 103 جدول ‏54 مدل هزینه عمل نقطه مقابلهگیری PAGEREF _Toc347719212 \h 104 جدول ‏55 مدل هزینه عمل اجرای بلافاصل PAGEREF _Toc347719213 \h 105 جدول ‏61 مقداردهی اولیه متغیرهای شبیهساز PAGEREF _Toc347719214 \h 125 فصل اول مقدمه مقدمه جهان محاسباتی که امروزه با آن روبرو هستیم روز به‌روز در حال بزرگتر و پیچیده‌تر شدن است. محاسبات ابری نیز در ادامه سبک‌های دیگر مانند محاسبات توری با هدف پردازش حجم عظیمی از داده با استفاده از خوشه‌هایی از کامپیوتر‌هاست. طبق گراش ارائه شده ای از گوکل، در حال حاضر به لطف محاسبات توزیع شده روزانه بیش از 20 ترابایت داده خام اینترنتی مورد پردازش قرار می‌گیرد. تکامل و شکل‌گیری محاسبات ابری خواهد توانست این چنین مسائلی را به راحتی و به شکلی مناسب‌تر از طریق سرویس‌های مبتنی بر تقاضا حل و فصل نماید. از زاویه دیگر، جهان محاسباتی اطراف ما در حال حرکت به سمت الگوهای "پرداخت برای استفاده" حرکت می‌کند و همین الگو یکی دیگر از پایه‌های اصلی محاسبات ابری محسوب می‌شود. محاسبات ابری که در اواخر سال 2007 پا به عرضه ظهور گذاشت هماکنون به دلیل توانایی‌اش در ارائه زیر ساخت فناوری پویا و بسیار منعطف، محیط‌های محاسباتی تصمین شده از نظر کیفیت و همچنین سرویس‌های نرم‌افزاری قابل پیکربندی به موضوع داغ بدل شده است . در گزارش رویکردی گوگل همانطور که در REF _Ref347364413 \h \* MERGEFORMAT شکل ‏11 مشاهده می‌نمایید، محاسبات ابری، محاسبات توری را پشت سر گذاشته است [1]. محاسبات ابری از رویکرد مجازیسازی بهرهگیری مینماید که این امر سبب انعطافپذیری بیشتر سیستم ابر میشود. در حقیقت با استفاده از این تکنولوژی، برنامهها میتوانند سرویس‌های مختلف را به صورت مجزا و انتزاعی از گره‌های سرویس‌دهنده دریافت نمایند. شکل STYLEREF 1 \s ‏1 SEQ شکل \* ARABIC \s 1 1رویکرد یه تکنولوژی‌های مختلف محاسبات توزیع شده [1] تعاریف زیادی در مورد محاسبات ابری ارائه شده است که سعی می‌نمایند مشخصه‌های اصلی محاسبات ابری را مد نظر بگیرند که سیستم ابری را " یک مدل برای دسترسی بنابر تقاضا و راحت تحت شبکه به یک مجموعه اشتراکی از منابع محاسباتی قابل پیکربندی" تعریف می‌نمایند درحالیکه "این منابع با کمترین تلاش و هزینه به صورت آزاد" فراهم گردند [2]. محاسبات ابری از خصوصیات منحصر به فردی بهره می‌برد که این سبک محاسباتی را از سایر سبک‌ها متمایز می‌کند. البته برخی از این خصوصیات کما بیش در سبک‌های پیشین نیز وجود داشتهاند. بعضی از این خصوصیات عبارتند از: ارائه سرویس مبتنی بر تقاضا: در اینجا لازم نیست تا برای آن چه استفاده نمی‌کنید هزینه پرداخت کنید. این بدان معناست که مشتریان تنها بر اساس مقدار و کیفیت سرویسی که مصرف می‌نمایند، هزینه استفاده پرداخت می‌نمایند. در حقیقت رویکرد این تکنولوژی همانند سرویس‌های عمومی قابل استفاده دیگر امروزی است. برای مثال همانطور که برای تولید برق نیاز نیست که هر خانوار دارای ژنراتور و سایر وسایل تولید الکتریسیته باشد، دریافت سرویسی مانند محاسبات یا محل ذخیره داده نیز دیگر نیازی به خصوصی بودن ندارد و می‌توان آن را از فراهم آوردنگان ابر اجاره کرد. دسترسی شبکه گسترده (اینترنت): این سیستم برای تحویل و ارئه سرویس‌ها از بستر موجود برای اینترنت استفاده می‌نماید. بنابراین مشتریان سرویس‌ها به هیچگونه نرم‌افزار یا سخت‌افزار خاصی نیاز ندارند و با همان مرورگری که هر روزه به گشت و گذار در وب می‌پردازند می‌توانند از سرویس‌های ابر بهره ببرند. استخر منابع: در این سیستم با حجم وسیعی از منابع روبرو هستیم. این منابع از طریق مجازیسازی از محل فیزیکی خود مستقل شدهاند. بنابراین به راحتی می‌توانند در بستر شبکه جابهجا شوند. در واقع نرم‌افزارها، پایگاه‌های داد، وب سرورها و سیستم‌های عامل همگی به عنوان سرورهای مجازی در سیستم ابر حضور دارند. قابلیت اطمینان بالا: فراهم آورندگان ابر به مشتریان خود تضمین می‌دهند که سیستم ابر همیشه قابلیت ارائه سرویس را داشته باشد. حال آنکه در سیستم‌های خانگی یک اشکال در نرم‌افزار یا سخت‌افزار می‌تواند موجب عدم دسترسی به اطلاعات و سرویس شود. هزینه پایین: به صورت سنتی برای اجرای برنامه‌های سنگین محاسباتی یا داده ای عظیم نیاز به یک سیستم با توان بالای محاسباتی و دادهای احساس می‌شده است. این سیستم هزینه سنگینی را برای شرکت و یا افراد سرویسگیرنده فراهم می‌آورده است. حال با استفاده از سرویس‌های موجود بر روی ابر، کاربران می‌توانند بر روی پروژه خود تمرکز بیشتری داشته باشد و هزینه گزافی را بابت تهیه زیرساخت‌ها نپردازد. به‌روز بودن: هزینه‌های گزافی که برای برپا بودن و به‌روز بودن زیرساخت‌های سخت‌افزاری و نرم‌افزاری باید پرداخت شوند با استفاده از ابر از بین می‌رود. در حقیقت به‌روز در آوردن زیرساخت‌ها از وظایف فراهمآورندگان ابر می‌شود که بدون آنکه کاربر نهایی از این موضوع مطلع شود انجام می‌پذیرد. در سیستمهای محاسبات توزیعی به دلیل کم کردن هزینه و توان مصرفی، از اجزاء تجاری عاممنظوره موجود در بازار استفاده میشود[3]. این اجزا به مرور زمان مستهلک شده و دچار خرابی می‌شوند تا جایی‌که برای همیشه غیرقابلاستفاده میگردند. همچنین با توجه به آمار ذکر شده، تعداد پردازندهها به منظور بهبود کارآیی سیستم محاسباتی توزیعی رو به افزایش است. با این حال احتمال وقوع خرابی در کل سیستم توزیعی با یک رابطه نمایی بالا میرود. برای مثال سیستم کلاستری که برای یکی از قسمت‌های سایت گوگل استفاده میشود، بیش از 15000 پردازنده دارد که بر اساس آمار ذکر شده در [4]، نرخ خرابی هر گره محاسباتی تقریبا 2-3% در سال است. این سیستم به طور میانگین 20 بار در هر روز به علت خرابی ناگزیر به راه‌اندازی مجدد است. بزرگترین مرکز داده جهان بیش از 560000 هسته پردازشی دارد و در کم‌تر از هر 10 دقیقه با یک اشکال در سیستم مواجه می‌شود. درجدول 1-1 چند نمونه از تعداد اشکال‌های گزارش شده در مراکز داده آمده است. جدول STYLEREF 1 \s ‏1 SEQ جدول \* ARABIC \s 1 1 قابلیت اطمینان در مراکز داده مختلف[4] سیستمتعداد پردازندهمیانگین زمان تا خرابی بعدیASCI Q81926.5 ساعتASCI White81925 ساعت و 40 دقیقهPSC Lemieux30169.7 ساعتGoogle1500020 راهاندازی مجدد در روز برای برنامههای علمی-کاربردی موازی امروزی که بسیار پیچیده‌تر شده‌اند و معمولا برای روزها، هفتهها و یا بیشتر طراحی شدهاند تا به اتمام برسند، برخورد با اشکال در حین اجرا برنامه موازی امری اجتنابناپذیر به نظر می‌رسد. امروزه رویکردهای تحمل‌پذیر اشکال در مراکز به یکی از چالش‌های اصلی در محاسبات توزیعی تبدیل شده است. آزمون نقطه مقابلهگیری(cp) و بازیافت یک تکنیک معمول برای مدیریت اشکال در محاسبات توزیع شده میباشد و مقالات ارزشمندی در مورد بازیابی بر اساس الگوریتمهای آزمون نقطه مقابلهگیری مختلف موجود میباشد[5 و6 و7]. مطالعه بر روی هزینه نقطه مقابله‌ گرفتن به صورت گسترده کماکان در حال انجام است. بیش‌تر کارها بر روی انتخاب بازه بهینه نقطه مقابله‌ و کم کردن سربار برای عمل نقطه مقابله انجام شده است. در واقع مهمترین مساله در بازیافت، برخورد با اشکالها بعد از وقوع آن و رویکرد بازگشت به عقب است. در روش نقطه مقابله بهصورت هماهنگ دورهای، در ابتدای بازه‌های زمانی از پیش تعریف شده حالت کنونی تکتک واحدهای محاسباتی موجود (این واحد در ابر ماشین‌های مجازی است) ذخیره می‌شود. پس از اتمام ذخیرهسازی تمام ماشین‌های مجازی، سیستم تا ابتدای بازه زمانی بعدی به کار خود ادامه می‌دهد. زمانیکه در یکی از گرههای محاسباتی خرابی رخ داد، این خرابی کشف میشود و تمام کارهای موازی متوقف شده تا اشکال در سیستم بر طرف گردد. پس از رفع اشکال سیستم به آخرین حالت ذخیره شده ماشین‌های مجازی باز میگردد و عملیات را از آن نقطه دوباره آغاز میکند و به کار خود ادامه می‌دهد. در اغلب پیادهسازیها، پروتکل کشف و بازیافت اشکال از دید برنامهنویس پنهان میباشد. این قبیل پروتکلها به صورت واکنشی پس از وقوع اشکال در سیستم عمل مینماید. بنابراین در این حالت ممکن است زمان زیادی به لحاظ تعمیر سیستم و بازیابی مجدد ماشین‌های مجازی از دست برود که روی کارآیی ابر بهصورت مستقیم تاثیر منفی میگذارد. در مقابل این روشها، اخیرا روشهای دیگری پیشنهاد شده که مبتنی بر پیشبینی اشکال در هر گره محاسباتی هستند. در این سیستمها، یک مکانیسم مدیریت اشکال تطبیقی وجود دارد که سعی دارد تا بهصورت بهینه، بهترین عمل را در ابتدای هر بازه تصمیمگیری نماید. در دهههای گذشته پیشرفتهایی در زمینه پیشبینی اشکال حاصل شده است. برای نمونه، وسایل سختافزاری مدرنی با خصیصههای مختلفی همچون سنسورهای سختافزاری طراحی شدهاند که میتوانند افت یک ویژگی در طول زمان را (برای شناسایی خرابیهای نزدیک) نشان دهند[8 و 9] و تعدادی روشهای یادگیری ماشینی و آماری مبتنی بر تکنیکهای احتمال برای بالابردن دقت آنها ارائه شده است[3 و 10]. تکنیکهای مقاومت در برابر اشکال پیشکنشی مبتنی بر پیشبینی به منظور دستیابی به دسترسی‌بالا، برای کاربردهای بحرانی- امن اتخاذ گردیده است. اما تاکنون مطالعات خوبی بر روی ابر صورت نگرفته است. در این پایاننامه سیستم‌های محاسبات ابری را به عنوان یکی از سیستمهای پردازش موازی مبتنی بر مبادله پیام مورد بررسی قرار می‌دهیم. این محیطها به علت ویژگی خاص خود که ارتباط کارهای موازی فقط از پیام‌های رد و بدل شده انجام می‌پذیرد، دارای توانمندی‌های بالقوه برای انجام عملیات بازیافت می‌باشند. از این رو، آنچه ما به طور خلاصه مورد مطالعه قرار خواهیم داد، قراردادهای بازیافت مختلف برای محیط مبادله پیام خواهد بود. این قراردادها برای توانمند کردن محیط پردازش موازی به منظور تحمل‌پذیر کردن در برابر اشکال، اطلاعاتی نظیر حالت ماشین‌های مجازی یا محتوی پیام‌ها را در طول اجرای عادی نگهداری می‌کنند تا در زمان وقوع اشکال با استفاده از آنها، عملیات بازیافت انجام پذیرد. در این پایاننامه در فصل دوم با قابلیت دسترسی‌بالا آشنا خواهیم شد و سپس در فصل سوم قراردادهای بازیافت در یک محیط پردازش موازی مبتنی بر مبادله پیام را مورد بررسی و مقایسه قرار می‌دهیم. در فصل چهارم به مطالعه کارهای اخیر انجام شده در زمینه برخورد پیش‌کنشی با اشکال‌های محتمل می‌پردازیم. فصل پنجم را به معرفی الگوریتم پیشنهادی اختصاص داده و در آخر به پیادهسازی و ارزیابی الگوریتم‌های پیشنهادی و مقایسه آن با روش کلاسیک پرداخته و نتیجهگیری می‌نماییم. فصل دوم قابليت دسترسيبالا قابليت دسترسيبالا با توجه به اين كه تمايل در مراکز داده به سمت استفاده از سيستم‌هاي پردازش موازي كلاستر با تعداد پردازنده خيلي زياد مي‌رود، توجه به خرابي اين سيستم‌ها بسيار اهميت پيدا مي‌كند. لذا توجه به تحمل اشکال و قابليت دسترسيبالا در سيستم‌هاي كلاستر امري اجتناب‌ناپذير است. مسائل مهم در اين ارتباط پيشگيري از وقوع اشکال، پيدا كردن اشکالها و بازگرداندن جزء خراب شده به حالت قبل از خرابي است. پيشگيري اشکال در سيستم‌‌هاي پردازش موازي مبتني بر كلاستر را مي‌توان با طراحي مناسب و داراي افزونگي اجزايي چون شبكه‌هاي ارتباطي يا پردازنده‌ها به وجود آورد. در مورد پيدا كردن اشکال‌ها نيز مي‌توان از انواع ابزارهاي نظارت و هشداردهندۀ سيستم‌هاي كلاستر بهره برد. در زمينه بازگرداندن سيستم در صورت وقوع خرابي به حالت قبل خود، با توجه به نوع سيستم مورد استفاده در محيط كلاستر اين بحث بررسي خواهد شد. به عنوان مثال سيستمهاي سرويسدهنده در صورت وقوع اشکال تنها بايد تقاضاي سرويسگيرنده را به ديگر گره‌ها هدايت كنند ولي در مراکز داده سرویس دهنده به ابر كه وقوع خرابي در حين اجراي يك برنامه به وقوع مي‌پييوندد، بايد اين قابليت دسترسيبالا ایجاد شود تا در مدت زمان کوتاهی به شرایط قبل از وقوع اشکال بازگردند. در اين فصل ابتدا به مفاهيم پايه قابليت دسترسي بالا و مباحث مرتبط با آن خواهيم پرداخت و در ادامه براي بررسي قابليت دسترسيبالا در ابر بهطور خاص، روشهاي دستيابي به قابليت دسترسيبالا در مراکز داده را توضيح خواهيم داد. مفاهيم پايه قابليت دسترسي بالا تعريف قابليت دسترسي بالا قابليت دسترسي بالا مشخصۀ سيستم‌هايي است كه به منظور ارائۀ بدون وقفۀ خدمات به كاربران طراحي مي‌شوند. در اينگونه سيستم‌ها علاوه بر استفاده از راهكارهايي به منظور كاهش بروز خرابي در اجزاي سخت‌افزاري و نرم‌افزاري، تدابيري نيز براي برخورد با چنين خرابي‌هايي در نظر گرفته مي‌شود. به اين ترتيب اولاً امكان وقوع اشکال در سيستم‌هاي دسترس بالا (یا به اختصار HA) كاهش مي‌يابد و ثانياً در اثر بروز اشکال، سيستم همچنان مي‌تواند به كار خود ادامه داده و خدمات در دست اقدام خود را بدون توقف پيگيري كند. البته روشن است كه بروز خرابي باعث كاهش كارايي سيستم خواهد شد. يكي ديگر از امكاناتي كه معمولاً در سيستم‌هاي HA در نظر گرفته مي‌شود امكان تعمير، ارتقاء و تغيير پيكربندي سيستم در حين ارائۀ خدمات به كاربران يا مشتريان است؛ اين امكان نيز در جهت كاهش مدت زمان توقف سيستم از اهميت ويژه‌اي برخوردار است. براي مقايسۀ سيستم‌هاي HA از معياري با عنوان قابلیت دسترسي استفاده مي‌شود. قابلیت دسترسي يك سيستم به صورت (متوسط) درصدي از زمان كه سيستم قابل استفاده است تعريف مي‌شود. به عنوان مثال سيستمي را تصور كنيد كه بايد در تمام روزهاي هفته و در تمام 24 ساعت شبانه‌روز آماده ارادۀ خدمات به مشتريان نباشد. در صورتي كه اين سيستم به طور متوسط در هفته به مدت يك ساعت از كار بيافتد ميزان دسترسي برابر با 1-7×247×24×100=%99.4 خواهد داشت. هر چه مدت توقف و از كارافتادگي سيستم كمتر باشد ميزان دسترسي آن بيشتر خواهد بود. مفاهيم و مباحث مرتبط با قابليت دسترسي بالا قابليت دسترسي پيوسته اين حالت، ايده آل HA است، به اين معني كه سيستم با قابليت دسترسي پيوسته هيچگاه متوقف نمي‌شود. واضح است كه قابليت دسترسي پيوسته يك حالت فرضي است و در دنياي خارجي محقق نخواهد شد. اما گاهاً اين اصطلاح در مورد سيستم‌هايي كه قابليت دسترسي بسيار بالايي دارند و تنها مدت توقف معين و بسيار كوتاه قابل پذيرشي دارند، به كار مي‌رود[11]. قابليت تحملپذیری اشکال سيستم‌هاي با قابليت تحملپذیری اشکال (FT) چنانكه از نامشان پيداست اين قابليت را دارند كه در اثر بروز يك اشکال در واحدهاي مختلف سخت‌افزاري يا نرم‌افزاي، همچنان به كار خود ادامه دهند، بهطوريكه كاربر از وقوع اشکال مطلع نشود. نكتۀ اصلي در دستيابي به قابليت تحملپذیری اشکال ، استفاده از بلوك‌هاي سخت‌افزاري و نرم‌افزاري اضافه است. اين بلوك‌ها پيش از اينكه سيستم دچار اشکال شود نقشي در كاركرد سيستم ندارند اما به محض وقوع اشکال در يك واحد از سيستم، بلوك اضافي متناظر با آن وارد عمل شده و جاي واحد خراب را مي‌گيرد و وظايف آن را انجام مي‌دهد. در سيستم‌هايي كه قابليت تحملپذیری اشکال كامل دارند همۀ اجزاي تشكيل دهندۀ سيستم داراي افزونگي هستند تا وقوع هيچ اشکالی منجر به توقف سيستم نشود. لازم به ذكر است كه قابليت تحملپذیری اشکال و قابليت دسترسي بالا به يك معنا نيستند. در واقع يك سيستم با قابليت تحملپذیری اشکال در صورتي كه نرخ بروز خطا يا اشکال بالايي داشته باشد به هيچ‌ وجه HA نخواهد بود [12]. البته بايد توجه داشت كه براي دستيابي به قابليت دسترسيبالا چاره‌اي جز بكارگيري بلوك‌هاي اضافي براي برخي از اجزاء سيستم نخواهيم داشت. ولي در سيستم‌هاي HA علاوه بر بكارگيري افزونگي براي برخي از اجزاء و استفاده از اجزاي مرغوب، مكانيسم‌هايي نيز در نظر گرفته مي‌شود تا در صورت وقوع اشکال در يكي از اجزاء، ساير اجزاء بتوانند علاوه بر وظيفۀ خود، وظيفۀ جزء خراب را نيز بر عهده بگيرند و در نتيجه سيستم به كار خود ادامه دهد. به اين مكانيسم‌ها دور زدن خرابی گفته مي‌شود. از آنجا كه سيستم‌هاي FT از اجزاي سخت‌افزاري و نرم‌افزاري خاصي استفاده مي‌كنند و حاوي حجم انبوهي از افزونگي‌ها هستند لذا از سيستم‌هاي HA گران‌تر مي‌باشند. در جدول 2-1 ساير مشخصات سيستم‌هاي HA و FT با هم مقايسه شده‌اند [13]. جدول STYLEREF 1 \s ‏2 SEQ جدول \* ARABIC \s 1 1 مقایسه کلاسترهای HA و FT [13] کلاسترHAسیستم FTزمان بازیابیچند ثانیه تا چند دقیقهچند میلی ثانیهمدل بازیابیبازیابی تراکنشی دادهمبتنی بر حافظه و دیسک سختدادههای بحرانیدیسکدیسک و حافظهپیادهسازیتوسعه اسکریپنیازمند به شبکهسیستمکلاسترسیستم منفردبرد محصولارزان قیمت تا دقت بالاچند برده قابليت تحمل حادثه قابليت تحمل حادثه به معناي اين است كه يك تأسيسات كامپيوتري اين امكان را داشته باشد كه در اثر بروز چند اشکال در يك سايت و يا در اثر از كارافتادگي كامل يك سايت همچنان به ارائه خدمات ادامه دهد. در اين دسته از سيستم‌ها سايت‌ها در يك ساختمان يا شهر و يا حتي قارّه پراكنده شده‌اند و مكانيزمي پيش‌بيني شده است كه در اثر وقوع حادثه‌اي چون آتش‌سوزي براي يك از سايت‌ها، سايت‌ ديگر عمليات را برعهده بگيرد. ناگفته پيداست كه اين گونه سيستم‌ها نياز به طراحي و پياده‌سازي دقيق دارند و بسيار گران هستند. قابليت اطمينان قابليت اطمينان و قابليت دسترسي مفاهيم مرتبطي هستند ولي بايد به اختلاف بين آن دو توجه كرد. چنانچه پيش از اين ذكر شد ميزان دسترسي يك سيستم درصدي از كل زمان‌هاست كه سيستم قابل استفاده براي كاربرد معمول آن است. اما قابليت اطمينان مدت زماني است كه انتظار مي‌رود سيستم بدون از كارافتادگي همچنان به كار خود ادامه دهد. واضح است كه يك سيستم HA از قابليت اطمينان بالايي نيز برخوردار خواهد بود. ولي يك سيستم با قابليت اطمينان بالا ممكن است به دليل زمان زياد مورد نياز براي تشخيص و تعمير خرابي و راه‌اندازي مجدد، HA نباشد. معيارهاي سنجش قابليت دسترسي مهم‌ترين و كامل‌ترين اين معيارها، قابلیت دسترسي سيستم است كه در ضمن تعريف سيستم‌هاي HA توضيح داده شد. در ادامه به معرفي برخي ديگر از معيارهاي سنجش قابليت دسترسي مي‌پردازيم كه تنها از يك منظر، كيفيت سيستم HA را مشخص مي‌كنند و لذا معيار كاملي از سيستم‌هاي HA نيستند. متوسط فاصلۀ زماني بين خرابیها (MTBF) اين معيار مشخصه‌اي براي ميزان قابليت اطمينان سيستم است و معمولاً براي واحدهاي منفرد تشكيل دهندۀ سيستم مانند ديسك‌ها بكار مي‌رود. MTBF از فرمول زير محاسبه مي‌شود: MTBF=کارکرد زمان کلآمده پیش اشکالات کل تعداد در صورتي كه بخواهيم MTBF را براي يك سيستم مركب محاسبه كنيم بايد مجموع خالص زمان‌هاي كاركرد واحدهاي تشكيل‌دهندۀ سيستم (اعم از واحدهايي كه دچار اشكال نمي‌شوند) را بر تعداد كل اشكالات رخ داده در واحدهاي مختلف تقسيم كنيم. معمولاً MTBF از روي عملكرد گذشته سيستم محاسبه مي‌شود و بهعنوان تخميني از عملكرد گذشته سيستم مورد استفاده قرار مي‌گيرد. متوسط زمان تعمير (MTTR) اين معيار متوسط زمان مورد نياز براي تعمير سيستم را نشان مي‌دهد. هر چه اين زمان كوتاهتر باشد، بهتر است و به مفهوم بازگشت دوبارۀ واحد خراب به سيستم است. لازم به ذكر است كه ميزان دسترسي به هر دو پارامترهاي MTBF و MTTR بستگي دارد. سطوح قابليت دسترسي بالا ميزان دسترسي قابل قبول براي يك سيستم، به كاربرد آن و ميزان خسارات ناشي از بروز اشكالات در سيستم بستگي دارد. از طرف ديگر با افزايش ميزان دسترسي يك سيستم قيمت آن به سرعت رشد مي‌كند. لذا پيش از اقدام براي خريد و نصب سيستم بايد مطالعات كافي به منظور يافتن سطح HA مورد نياز در آن كاربرد انجام شده باشد. مسئلۀ ديگري كه در انتخاب سيستم HA بايد مد نظر باشد ساعات كاري سيستم است. در جدول 2-2 و جدول 2-3 سطوح مختلف HA و زمان‌هاي توقف و در دسترس بودن سيستم‌هايي با ساعات كاري 52×7×24 (يعني 24 ساعت در روز، 7 روز در هفته و 52 هفته در سال) و 52×5×12 درج شده است. در سيستم‌هايي كه در تمام طول شبانه‌روز مشغول خدمات‌رساني نيستند ممكن است بتوان تعمير سيستم را تا پايان ساعت خدمات‌رساني روزانه، به تعويق انداخت و به اين ترتيب زمان در دسترس بودن سيستم را افزايش داد اما در مورد سيستم‌هاي شبانه‌روزي معمولاً مكانيزم‌هايي براي تعمير سيستم به صورت برخط و بدون توقف در نظر گرفته مي‌شود. جدول STYLEREF 1 \s ‏2 SEQ جدول \* ARABIC \s 1 2 زمانهای توقف و کارکرد یک سیستم 52×7×12قابلیت دسترسیکمترین زمان مورد انتظار دسترس بودنکمترین زمان مجاز خارج از دسترس بودنزمان باقیمانده99%867288099.5%871644099.95%875550100%876000 جدول STYLEREF 1 \s ‏2 SEQ جدول \* ARABIC \s 1 3 زمان‌هاي توقف و كاركرد يك سيستم 52×5×12قابلیت دسترسیکمترین زمان مورد انتظار دسترس بودنکمترین زمان مجاز خارج از دسترس بودنزمان باقیمانده99%308332564299.5%310416564299.95%311825642100%312005642 توقف برنامه‌ريزي شده و توقف برنامه‌ريزي نشده سيستم HA ممكن است به دو صورت متوقف شود: برنامه‌ريزي شده و يا برنامه‌ريزي نشده. توقف برنامه‌ريزي شدۀ سيستم طبق برنامۀ از پيش تعيين شده‌اي توسط اپراتور انجام مي‌شود. توقف برنامه‌ريزي شدۀ سيستم ممكن است به صورت روزانه، هفتگي، ماهانه و بیش‌تر انجام شود. هدف از توقف برنامه‌ريزي شده مي‌تواند برخي از موارد زير باشد[11] : تهيۀ نسخۀ پشتيبان به طور متناوب ارتقاء نرم‌افزاري سيستم توسعه و يا تعمير سخت‌افزار تغيير پيكربندي سيستم تغيير و بهروز كردن داده‌ها توقف برنامه‌ريزي شده در صورتي كه به نحو مناسب زمان‌بندي شده باشد معمولاً مشكلي ايجاد نمي‌كند. چنانكه پيش از اين هم اشاره شد، يك انتخاب جايگزين براي توقف برنامه‌ريزي شده، روش‌هاي تهيۀ نسخه‌هاي پشتيبان به صورت برخط و روش‌هاي تعمير و ارتقاء سخت‌افزاري به صورت اتصال در زمان روشن بودن دستگاه است. نوع ديگري از توقف‌هاي سيستم، توقف‌هاي برنامه‌ريزي نشده يا از كارافتادگي‌ها هستند و در سيستم‌هاي HA بسيار نامطلوب مي‌باشند. بعضي از علل وقوع اين گونه از توقف‌ها عبارتند از [11]: از كار افتادن بخشي از سخت‌افزار خطاي سيستم فايل پر شدن ديسك و نبودن جا براي ذخيره‌سازي رويداد پرش ناگهاني در تغذيۀ سيستم از كار افتادن منبع تغذيه مسائل مربوط به شبكۀ ارتباطي نقص نرم‌افزاري خطاي كاربرد نقص ميان‌افزاري حوادث طبيعي (مانند آتش‌سوزي، سيل) اشتباه اپراتور يا مدير سيستم. در شكل 1-1 سهم هر يك از گروه‌هايي را كه منشاء توقف برنامهريزي نشده هستند، به صورت آماري نشان مي‌دهد [11]. شکل STYLEREF 1 \s ‏2 SEQ شکل \* ARABIC \s 1 1 سهم عوامل مختلف در از کارافتادگی سیستم HA [11] عوامل مؤثر بر ميزان دسترسي سيستم عامل‌هاي مؤثر بر ميزان دسترسي يك سيستم را مي‌توان به سه دسته تقسيم كرد: پرسنل، پروسه و فناوري [14]. پرسنل و مديران سيستم‌هاي HA، خصوصاً سيستم‌هاي با مأموريت بحراني بايد مهارت‌ها و دانش لازم براي مديريت اين گونه سيستم‌ها و آگاهي از نحوۀ برخورد با خرابي‌ها و اشكالات به وجود آمده در سيستم را دارا باشند. همچنين سازمان‌هايي كه از چنين سيستم‌هايي بهره مي‌گيرند بايد پروسه‌هاي مشخصي را براي مواجهه با خرابي‌ها و اشكالات احتمالي پيش‌بيني كرده باشند. عنصر سوم، فناوري به كار رفته در سيستم است. به اين معنا كه طراحان سيستم‌هاي HA مي‌بايستي از قطعات سخت‌افزاري و نرم‌افزاري مناسب، شبكه‌هاي ارتباطي كارا، سيستم‌هاي عامل و برنامه‌هاي كاربردي خوبي استفاده كرده باشند. اگر چه ضعف هر يك از اين سه عامل منجر به كاهش ميزان دسترسي سيستم از ديد كاربران مي‌شود ولي ما در اين نوشته‌ تنها به بُعد فناوري سيستم‌هاي HA خواهيم پرداخت. دستيابي به قابليت دسترسي بالا در سيستم‌هاي كلاستر با توجه اينكه تمايل در سطح سيستم‌هاي موازي به سمت استفاده از سيستم‌هاي پردازش موازي كلاستر با تعداد پردازشگر خيلي زياد مي‌رود، توجه به خرابي اين سيستم‌ها بسيار اهميت پيدا مي‌كند. اين سيستم‌ها از كامپيوترهايي كه با استفاده از يك شبكۀ ارتباطي به يكديگر متصل شده‌اند تشكيل مي‌شوند. همۀ اين كامپيوترها در يك جعبه قرار مي‌گيرند و به صورت يك سيستم واحد و يكپارچه ديده مي‌شوند. در اين بخش نقاط منفرد بروز خرابی كه در اين فصل گاهي آن را اختصاراً SPOF مي‌ناميم، در يك سيستم كلاستر مشخص كرده و راهكارهاي حذف آنها را بررسي مي‌كنيم. با حذف نقاط منفرد بروز اشكال نخستين گام به سوي سيستم HA برداشته خواهد شد. تعريف نقاط منفرد بروز خرابی نقاط منفرد بروز خرابی اجزائي هستند كه نبودن يا از كارافتادگي هر يك از آنها منجر به توقف خدمات ارائه شده توسط سيستم مي‌گردد. معمولاً جزئي از سيستم كه براي آن افزونگي در نظر گرفته نشده است يك SPOF خواهد بود. به عنوان مثال، در شكل 1-2 تعدادي از SPOFها در يك سيستم سرويس‌دهنده/ سرويسگيرنده نشان داده شده است. از بين بردن نقاط منفرد بروز خرابی در اجزاي سخت‌افزاري از بين بردن نقاط منفرد بروز خرابی مربوط به منابع تغذيه چنانكه در شكل 2-2 ملاحظه مي‌شود همۀ اجزاي مدار به يك منبع تغذيه متصل شده‌اند. در نتيجه اين منبع تغذيه به وضوح يكي از SPOFهاي سيستم‌ خواهد بود. به منظور رفع اين نقيصه مي‌توان از منابع تغذيۀ اضطراري (UPS) استفاده كرد كه به صورت كلي دو نوع هستند. UPSهاي منفرد، منافع تغذيه‌اي هستند كه در صورت قطع توان ورودي، به يك باتري سوييچ مي‌كنند و براي مدت كوتاهي توان سيستم را تأمين مي‌كنند. در اين مدت سيستم مي‌تواند به نحو مناسب خاموش شود. در صورتي كه در اين مدت تغذيۀ سيستم مجدداً به حالت اول برگردد سيستم بدون خاموش شدن ادامۀ كارهايش را پي‌گيري مي‌كند. بايد توجه داشت كه اين نوع UPS خود مي‌تواند دچار اشكال شود و از كار بيفتد و لذا يك SPOF محسوب مي‌شود. براي حذف اين SPOF بايد از دو يا چند UPS استفاده كرد. علاوه بر اين براي اينكه در اثر از كارافتادن يك UPS، تمام سيستم يكباره متوقف نشود مي‌توان براي قسمت‌هاي مختلف سيستم از UPSهاي مجزا استفاده كرد شکل STYLEREF 1 \s ‏2 SEQ شکل \* ARABIC \s 1 2 برخی SPOFها در سیستم سرویسدهنده/سرویسگیرنده نوعي ديگر از آنها، UPS عبور دهندۀ توان نام دارد. اين نوع كه از UPS منفرد گران‌تر است، خودش SPOF نيست زيرا در حالتي كه توان ورودي در وضعيتي مناسب قرار دارد و دچار اشكال نشده است اين نوع UPS تنها توان را عبور مي‌دهد و به عبارت ديگر در مدار قرار ندارد. اما به محض بروز اشكال، اين نوع UPS وارد عمل شده و توان سيستم را از طريق يك باتري يا ژنراتور اضطراري تأمين مي‌كند. از بين بردن نقاط منفرد بروز خرابی مربوط به ديسك‌ها همان‌طور كه در شكل 2-2 مشاهده مي‌شود سيستم مورد نظر از دو ديسك استفاده مي‌كند: ديسك ريشه و ديسك داده. ديسك ريشه محل قرار گرفتن سيستم عامل است و داده‌هاي كاربردهاي مختلف بر روي ديسك داده نگهداري مي‌شوند. در صورت بروز اشكال در ديسك ريشه، سيستم نمي‌تواند پردازش‌هاي معمول خود را انجام دهد. براي رفع اشكال، اين ديسك بايد عوض شود و محتواي ديسك با نصب مجدد نرم‌افزارهاي سيستم و يا با استفاده از نسخه‌هاي پشتيبان بازيابي شود. در صورت بروز اشكال در ديسك داده كاربردها متوقف مي‌شوند و پس از جايگزيني ديسك داده‌ها با ديسك مشابه بايد داده‌هاي موجود در آخرين نسخۀ پشتيبان موجود، بر روي ديسك جديد بارگذاري شود. داده‌هايي كه پس از تهيۀ آخرين نسخۀ پشتيبان تغيير كرده‌اند قابل بازيابي نخواهند بود. چنانكه ملاحظه مي‌شود هر يك از ديسك‌ها يك SPOF هستند و تنها راه از بين بردن اين SPOFها استفاده از افزونگي است. دو روش براي به كارگيري افزونگي در مورد ديسك‌ها وجود دارد كه عبارتند از: محافظت داده‌ها با استفاده از آرايه‌اي از ديسك‌ها حافظت نرم‌افزاري از داده‌ها با بكارگيري ايدۀ قرينه‌سازي محافظت داده‌ها با استفاده از آرايهاي از ديسك‌ها در اين روش آرايه‌اي از ديسك به صورت يك پيكربندي RAID مورد استفاده قرار مي‌گيرد و مي‌توان از سطوح مختلف RAID بهره جست. برخي از اين سطوح RAID به روش قرينهسازي سخت‌افزاري و برخي ديگر با استفاده از توازن از داده‌ها محافظت مي‌كنند بهطوري كه در اثر بروز اشكال در يك ديسك، همچنان بتوان داده‌ها را بازيابي كرد. سطوح متداول RAID عبارتند از: RAID 0: داده به طور معمول بر روي ديسك‌ها نوشته مي‌شود و محافظتي از داده‌ها به عمل نمي‌آيد. RAID 1: داده بر روي گروهي از ديسك‌ها كه قرينه يكديگر هستند نوشته مي‌شود. RAID 3: داده به صورت بايت- بايت خرد مي‌شوند و بيت‌هاي مختلف هر بايت بر روي ديسك مختلف نوشته مي‌شوند و در ضمن بيت توازن براي هر بايت بر روي يك ديسك معين ذخيره مي‌شود. RAID 5: داده به بلوك‌هايي شكسته مي‌شود و علاوه بر ذخيره‌سازي بلوك‌ها اطلاعات مربوط به بلوك‌ها نيز بر روي ديسك پراكنده شده و ذخيره مي‌شود. از مزاياي استفاده از آرايه‌اي از ديسك‌ها مي‌توان موارد زير را برشمرد: امكان و سهولت تعويض بر خط بلوكي از ديسك‌ها كه يكي از آنها دچار اشكال شده است. قابليت تخصيص خودكار يك بلوك از ديسك‌ها به منظور بر عهد گرفتن وظيفۀ يكي از بلوك‌هايي كه دچار اشكال شده است (در حالت عادي بلوك مورد بحث در حالت منتظر مي‌باشد). انعطاف‌پذيري در پيكربندي آرايه (حالت‌هاي مختلف). امكان حذف SPOFها با استفاده از كنترل كننده‌ها، منبع تغذيه و فن اضافي. حجم بالاي حافظۀ پيوسته. محافظت از داده‌ها با استفاده از قرينه‌سازي نرم‌افزاري اين روش همان سطح RAID 1 است كه بر روي ديسك‌هاي منفرد و به صورت نرم‌افزاري پياده‌سازي شده است. از مزاياي اين روش مي‌توان به موارد زير اشاره كرد: قرينه‌سازي با دو يا چند كپي قابل انجام است و مي‌توان تعداد كپي‌ها را به صورت نرم‌افزاري تعيين كرد. كپي‌هاي داده را مي‌توان به منظور تهيۀ نسخۀ پشتيبان به تكه‌هاي كوچك‌تري خرد كرد و حتي مي‌توان نسخۀ پشتيبان را بر روي يك سيستم ديگر نگهداري كرد. مي‌توان نحوۀ چنيش داده‌ها بر روي ديسك‌ها را كنترل كرد تا كارايي يك كاربرد خاص افزايش يابد. مي‌توان قرينه‌ها را طوري پيكربندي كرد كه از کانالهای فیبری يا گذرگاه‌هاي SCSI مختلفي استفاده كنند و به اين ترتيب نرخ عمليات I/O را چند برابر كرد. ديگر يك كنترلكنندۀ ديسك، گلوگاه نخواهد بود. حذف نقاط منفرد بروز اشكال مربوط به اجزاي واحدهاي پردازشي (SPUها) هر يك از واحدهاي پردازشي كه آن را اختصاراً SPU مي‌ناميم، در يك سيستم از اجزايي تشكيل شده‌اند كه آن اجزاء مستعد بروز اشکال هستند. مهم‌ترين اين اجزاء عبارتند از: يك يا چند پردازه كنترل‌هاي I/O بُردهاي حافظه در صورت بروز اشكال در اين گونه اجزاء SPU قادر به انجام عمليات مورد انتظار نخواهد بود. براي حذف اين نوع از SPOFها دو راه وجود دارد: يكي استفاده از اجزاي SPU به صورت افزونگي و ديگري استفاده از كلاسترهاي HA. در روش اول جعبه‌هايي حاوي پردازنده‌ها، كارت‌هاي شبكه، كارت‌هاي I/O، حافظه‌ها، منابع تغذيه و اتصال دهنده‌ها در نظر گرفته مي‌شود كه در صورت وقوع خرابي، جايگزين اجزاي خراب مي‌شوند. در روش دوم SPUهاي پشتيبان در نظر گرفته مي‌شود كه اين SPUها ممكن است در حالت عادي فعال بوده و يا منتظر باشند. در اثر وقوع خرابي در يكي از SPUها، SPUي پشتيبان طي فرايندي موسوم به دور زدن خطا، كاربردي كه در حال اجرا بر روي SPUي خراب بوده است را از سر مي‌گيرد. پروسۀ دور زدن خطا در مدت كوتاهي انجام مي‌شود و نرم‌افزار مربوط به آن همواره بر روي تمام واحدهاي كلاستر در حال اجرا است. اين روش نسبت به روش قبل انعطاف‌پذيرتر بوده و در مورد برخي از كاربردها مقرون به صرفه‌تر است. حذف نقاط منفرد بروز اشكال مربوط به شبكه در سيستم‌هاي كلاستر شبكه‌ها به دو منظور مورد استفاده قرار مي‌گيرند: دسترسي سرويسگيرنده‌ها و سيستم‌هاي ديگر به كاربردها مبادلۀ پيام بين واحدهاي كلاستر به منظور دسترسي گيرنده به كاربرد موجود بر روي سرويس‌دهنده معمولاً از شبكه‌هاي محلي استفاده مي‌شود. در شكل 2-3 يك شبكه اترنت نوعي با همبندي ستاره به همراه SPOFها نشان داده شده است. چنانكه در اين مشاهده مي‌شود كابل‌ها، مسيرياب‌ها، هاب‌ها و كارت‌هاي شبكه همگي مي‌توانند SPOF باشند. علاوه بر اين نرم‌افزارهاي شبكه مانند كنترل كنندۀ DNS مي‌توانند باعث وقوع اشكال شوند و از اين رو در زمرۀ SPOFها محسوب مي‌شوند. شکل STYLEREF 1 \s ‏2 SEQ شکل \* ARABIC \s 1 3 SPOFها در یک شبکه اترنت نوعی چنانكه ذكر شد واحدهاي كلاستر نيز براي برقراري ارتباط با يكديگر از شبكه‌ها بهره مي‌جويند. پيام‌هايي كه واحدهاي شبكۀ HA با هم مبادله مي‌كنند دو گونه هستند. دسته‌اي از اين پيام‌ها كار رد و بدل داده‌ها و برنامه‌ها را انجام مي‌دهند و دستۀ ديگري از آنها پيام‌هايي است كه به منظور اطلاع از سلامت و صحت واحدهاي شبكه مبادله مي‌شوند و به پيام‌هاي ضربان قلب موسوم هستند. گاهي اوقات در برخي سيستم‌ها از دو شبكۀ مجزا براي اين دو دسته از پيام‌ استفاده مي‌شود. SPOFها در شبكه‌هايي كه به منظور ارتباط بين واحدها در نظر گرفته شده‌اند، شامل كابل‌ها و كارت‌هاي شبكه مي‌باشند. البته لازم به ذكر است كه در بعضي از سيستم‌ها ارتباط بين واحدها نيز از طريق همان شبكه‌اي كه براي دسترسي سرويس‌گيرنده‌ها به كلاستر در نظر گرفته شده است انجام مي‌شود. براي حذف SPOFهاي شبكه دو راه حل وجود دارد: افزونگي كامل در شبكه راه‌گزيني محلي بر روي كارت‌هاي شبكه در روش اول تمام ابزارهاي شبكه از جمله كارت‌هاي شبكه، مسيرياب‌ها، هاب‌ها و كابل‌ها به صورت افزونگي مورد استفاده قرار مي‌گيرند و نمونه‌اي از اين شبكه در شكل 2-4 نشان داده شده است. در روش دوم در صورت قطع ارتباط، واحد مورد نظر از كارت شبكه اي كه قبلاً استفاده مي‌كرد به يك كارت شبكه ديگر كه پيش از اين در حالت منتظر بوده سوئيچ مي‌كند و به اين ترتيب ارتباط خود را با ساير واحدها حفظ مي‌كند. شکل STYLEREF 1 \s ‏2 SEQ شکل \* ARABIC \s 1 4 حذف SPOFهای شبکه به روش افزونگی کامل يكي از روشهايي كه مي‌توان به منظور افزايش قابليت دسترسي شبكه از آن استفاده كرد APA است. APA تعدادي پورت‌ اترنت سريع يا اترنت گيابيت را كه بر روي كارت‌هاي مختلفي قرار دارند به دسته‌اي از اتصالات كه همگي آدرس IP يكساني دارند متصل مي‌كند. با استفاده از اين فنّاوري امكان تشخيص و بازيابي اشکال به طور خودكار فراهم مي‌شود و علاوه بر آن مي‌توان بار را بر روي اتصالات فيزيكي به نحو مناسب توزيع كرد. از بين بردن نقاط منفرد بروز اشكال در اجزاي نرم‌افزاري بسياري از اجزاي نرم‌افزاري از جمله موارد اشاره شده در زير مستعد بروز اشكال هستند: سيستم عامل نرم‌افزار مديريت پايگاه داده Transaction Processing (TP) Monitors برنامه‌هاي كاربردي سرويس‌دهنده برنامه‌هاي كاربردي سرويسگيرنده استفاده از كلاسترها مي‌تواند آثار سوء اين گونه اشكال‌ها را كاهش دهد. به عنوان مثال در صورت بروز اشكال در سيستم‌ عامل يك گره، آن گره خاموش شده و سرويس‌هايي كه بر روي آن در حال اجرا بودند بر روي واحدهاي ديگر ادامه يافته و يا از سر گرفته مي‌شوند. در واقع كاربردها به منزلۀ بسته‌هايي مي‌باشند كه در صورت نياز از گرهي به گره ديگر منتقل مي‌شوند. ايدۀ ديگر اين است كه چند نمونه از يك برنامۀ كاربردي بر روي گره‌هاي كلاستر در حال اجرا باشد تا در صورت بروز اشكال در يك گره، كاربر به طور خودكار به گره ديگري كه در حال اجراي آن برنامۀ كاربردي است متصل شود. در هر دو حالت استفاده از كلاستر امكان بازيابي برنامۀ كاربردي را در زمان قابل قبولي فراهم مي‌كند. نرم‌افزارهاي مديريت پايگاه داده و ناظرهاي TP نيز ممكن است دچار اشكال شوند. با تشكيل اين نرم‌افزارها از بسته‌هاي نرم‌افزاري كوچك‌تر، مي‌توان قابليت HA را در آنها ايجاد كرد. برنامه‌هاي كاربردي سرويس‌دهنده نيز متداول است. در صورت بروز اشكال در برنامۀ كاربردي سرويس‌دهنده كلاستر بايد مجدداً راه‌اندازي شود، يا برنامۀ كاربردي مورد نظر از ابتدا آغاز شود و يا بر روي يك SPUي ديگر اجرا شود. بالاخره با توجه به امكان وقوع اشكال در برنامۀ كاربردي سرويسگيرنده، اين برنامه‌هاي كاربردي بايد طوري طراحي شوند كه امكان از سرگيري دوباره و ارتباط مجدد با سرويس‌دهنده به طور خودكار وجود داشته باشد. علاوه بر حذف SPOFهاي مذكور برنامه‌هاي كاربرديي كه براي يك محيط HA نوشته مي‌شوند بايد مشخصات زير را داشته باشند: امكان دور زدن خطا بر روي گره ديگر امكان از سرگيري مجدد بدون دخالت اپراتور توابع مخصوص نظارت براي تشخيث برپا بودن يا توقف برنامۀ كاربردي روال‌هاي تعريف شده براي شروع، اجرا و پايان آن روال‌هاي مناسب براي تهيۀ نسخۀ پشتيبان، بازيابي و ارتقاء امكان ارتباط كاربر با آن، مستقل از اينكه بر روي كدام گره كلاستر در حال اجرا باشد. تشخيص دهندۀ خرابي در كلاسترهاي با قابليت دسترسي بالا در يك كلاستر HA بايد همۀ واحدها فعال باشند و در صورتي كه واحدي به دلايلي از كار افتاد بايد از مجموعۀ كلاستر خارج شود. براي تست فعاليت يا به اصطلاح زنده بودن يك واحد دو روش عمده وجود دارد: ضربان قلب ديسك Quorum تكنيك ضربان قلب در اين روش كه يكي از معروف‌ترين تكنيك‌ها براي تشخيص خرابي است، واحدها با ارسال سيگنال‌هايي به يكديگر از سلامت همديگر مطلع مي‌شوند. اين سيگنال‌ها به صورت ضرباني و در هر فاصلۀ زماني مشخص در شبكه ارسال و دريافت مي‌شوند. فاصلۀ زماني بين سيگنال‌هاي ضربان وابسته به نوع كاربرد، ممكن است متغير باشد. در اينجا، هر واحد يك سيگنال به مفهوم «آيا تو زنده هستي؟» ارسال مي‌كند و واحد گيرنده در صورت سالم بودن پاسخ «من زنده هستم» را به او برمي‌گرداند. در صورتي كه بعد از زمان مشخصي سيگنال پاسخ نيايد مي‌توان نتيجه گرفت كه واحد مقصد دچار خرابي شده است. البته ممكن است واحد فرستنده اين عمل را در چند نوبت انجام دهد، زيرا ممكن است واحد گيرنده مشغول باشد و پاسخ را با تأخير ارسال كند. نوع ديگر پياده‌سازي اين روش، تخصيص يك سرويسدهندۀ خاص براي عمل ضربان قلب است. در اين روش سيگنال‌هاي درخواست از طرف سرويس‌دهنده به همۀ واحدها ارسال مي‌شود و واحدها بايد پاسخ خود را در زمان مشخص به سرويس‌دهنده ارسال كنند. همان‌طور كه قبلاً اشاره شد در بعضي از سيستم‌هاي كلاستر يك شبكۀ مجزا باري سيگنال ضربان قلب نصب مي‌شود تا ترافيك آن به شبكۀ ارتباطي گره‌ها منتقل نشود. در شكل 2-5 يك نمونه از اين سيستم را مشاهده مي‌كنيد. شکل STYLEREF 1 \s ‏2 SEQ شکل \* ARABIC \s 1 5 نمونهای از تشخیص خرابی با سیگنال ضربان قلب مشكل بزرگي كه در اين تكنيك وجود دارد، عدم تشخيص خرابي در شبكه (قطع اتصالات) است. اين امر باعث مي‌شود كه اگر سيگنال ضربان به دليل قطع شدن شبكه به گرهاي نرسد، فرستنده تصور مي‌كند كه گره گيرنده دچار خرابي شده كه صحيح نيست. براي حل اين مشكل از روش ديسك Quorum استفاده مي‌كنند. تکنيک ديسک Quorum در اين روش يک ديسک يا قسمتي از يک ديسک بين همه گره‌ها به صورت مشترک وجود دارد. در اين حالت هر گره مي‌تواند به صورت مستقل به آن دسترسي پيدا کند و داده‌اي را در آن بنويسد يا از آن بخواند. نحوه استفاده از آن براي تشخيص خرابي به اين صورت است که هر گره پيام زنده بودن خود را در ديسک مي‌نويسد و بقيه مي‌توانند آن را بخوانند. در اين صورت اگر در اثر قطع شدن شبکه امکان استفاده از سيگنال ضربان قلب وجود نداشته باشد، مي‌توان با مراجعه به ديسک Quorum از سلامتي واحد مطلع شد. بنابراين تشخيص خرابي در اتصالات شبکه نيز فراهم مي‌شود. معماري کلاسترهاي با قابليت دسترسيبالا کلاسترهاي HA مانند ساير کلاسترها از مجموعه‌اي از کامپيوترهاي مستقل تشکيل مي‌شوند که توسط يک شبکه با پهناي باند زياد و تأخير کم به يکديگر متصل شده‌اند و تمامي سيستم با وجود منابع متعدد، از ديد کاربر به صورت يک سيستم يکپارچه ديده مي‌شوند. هر يک از ايستگاه‌هاي کاري در يک کلاستر به طور کلي دربردارنده يک يا چند پردازنده، مقداري حافظه فرّار و غير فرّار و رابط‌هاي خارجي از قبيل USB و PCI مي‌باشد. البته امکان استفاده از ديسک، ديسک‌هاي فشرده، صفحه کليد، درگاه سريال RS-223، صفحات نمايش و غیره نيز در همه يا برخي از گره‌هاي کلاستر وجود دارد [15]. واحدهاي موجود در کلاستر به منظور انجام محاسبات و آگاهي از وضعيت ساير واحدها، پيام‌هايي را از طريق شبکه ارتباطي، رد و بدل مي‌کنند. شبکه مورد بحث ممکن است يک شبکه اترنت سريع، Myrinet, SI, Infiniband و يا هر چیز دیگری باشد. دو پارامتر مهم در کيفيت شبکه‌هاي کامپيوتري «پهناي باند» و «تأخير شبکه» است. پارامتر ديگري که در انتخاب شبکه بايد مد نظر قرار گيرد قيمت ابزارهاي شبکه مي‌باشد [15]. کلاسترهاي HA به منظور دستيابي به مشخصه HA علاوه بر تمهيدات عمومي کلاسترها، تدابير ويژه‌اي را در معماري رعايت مي‌کنند. به طور کلي از نظر پيکربندي مي‌توان کلاسترهاي HA را به سه دسته تقسيم کرد که در ادامه به توضيح آنها خواهيم پرداخت [11]. پيکربندي فعال/ منتظر در اين پيکربندي دو يا چند SPU به ديسک داده يکساني متصل هستند. در صورتي که يکي از اين SPU‌ها دچار اشکال شود، SPU ديگر پشتيباني برنامه کاربرديي را که بر روي SPU اصلي در حال اجرا بود از سر مي‌گيرد. در اين نوع پيکربندي SPUي پشتيبان در حالت عادي يا در وضعيت منتظر است و يا برنامه کاربردي کم اهميتتري بر روي آن در حال اجرا مي‌باشد. ابزار Service Guard که محصولي از شرکت HP است، قابليت پيکربندي به اين نحو را دارا مي‌باشد. در اين نوع پيکربندي سيستم عامل و نرم‌افزار HA بر روی SPUي پشتيبان در حال اجرا هستند و در نتيجه نياز به راهاندازي SPUي پشتيباني نيست و سرعت بازيافت نسبتاً بالا است. در آرايش فعال/ منتظر ممکن است يک واحد از چند واحد پشتيباني به عمل آورد. لازم به ذکر است که انتقال بسته‌ها و برنامه‌هاي کاربردي از يک واحد به واحد ديگر تنها در حالت وقوع اشکال انجام نمي‌پذيرد، بلکه گاهي اوقات مدير سيستم به منظور راحتي کار مديريت، مي‌تواند بسته‌ها و کاربردها را از واحدي به واحد ديگر منتقل سازد. مزيت اصلي سيستم‌هاي فعال/منتظر اين است که کارايي در اثر بروز اشکال کاهش نمي‌يابد. پيکربندي فعال/ فعال در اين پيکربندي دسته‌اي از واحدها در حال اجراي برنامه کاربردي با مأموريت بحراني مي‌باشند و تعدادي از آنها علاوهبر اجراي برنامه کاربردي خود، از ساير واحدها نيز پشتيباني مي‌کنند. واضح است که در صورت بروز اشکال کارايي سيستم در اين پيکربندي کاهش مي‌يابد. در عوض ميزان بهره‌برداري از منابع سيستم در اين پيکربندي حداکثر مي‌باشد. براي مثال، ابزار Service Guard را به صورت فعال/ فعال نيز مي‌توان پيکربندي کرد. در اين پيکربندي نيز به هر ديسک داده چند SPU متصل مي‌شود. پيکربندي پايگاه داده موازي در اين پيکربندي هر يک از واحدها به طور مجزا در حال اجراي برنامه کاربرد پايگاه داده يکساني هستند و به طور همزمان به يک پايگاه داده دسترسي دارند. در صورت بروز اشکال در يکي از واحدها تنها کافيست کاربر را به برنامه کاربردي مورد درخواست او بر روي يکي از واحدهاي ديگر متصل کنيم. به منظور فراهمسازي امکان دسترسي همزمان به پايگاه داده يکسان بايستي از نرم‌افزارهاي خاصي چون (OPS) Oracle Parallel Server استفاده نمود. اتصالات و شبکه کلاستر يکي ديگر از واحدهاي موجود در کلاسترها شبکه ارتباطي واحدهاست. همبندي اين شبکه همان روش‌هاي شناخته شده در پردازش موازي و شبکه‌هاي کامپيوتري است. چنان که پيش از اين ذکر شد مبادله پيام‌هاي مربوط به سلامت واحدهاي کلاستر ممکن است از طريق شبکه مجزايي موسوم به شبکه ضربان قلب انجام پذيرد. در مورد پارامترهاي کيفيت و انواع شبکه‌هاي به کار رفته در کلاسترها در بخش پيش، و در مورد بکارگيري افزونگي در شبکه در بخش «حذف نقاط منفرد بروز اشکال مربوط به شبکه» توضيح کافي ارائه شد. مديريت و نظارت بر کلاستر با استفاده از کلاسترهاي HA مي‌توان SPOF‌ها را حذف کرد. اما به هر حال اجزاي سيستم در زمان‌هاي نامشخصي از کار خواهند افتاد. يکي از مسائل مهمي که در طراحي‌هاي HA بايد مورد توجه قرار گيرد چگونگي تشخيص و مديريت اشکال‌هاست. به منظور تشخيص اشکال‌ها يا نقاط مستعد بروز اشکال در سيستم کلاستر، اجزاي مختلف سخت‌افزاري و نرم‌افزاري سيستم بايد به طور مداوم تحت نظارت قرار داشته باشند و چون سيستم‌هاي کلاستر داراي پيچيدگي‌هاي بسياري هستند لذا بايد نظارت به صورت خودکار انجام شود. يک سيستم نظارت ايده‌آل بايد به صورتي باشد که پيش از بروز خرابی بتواند نقاط مستعد اشکال را به مديران شبکه گوشزد کند تا به اين ترتيب مديران با استفاده از افزونگي‌هاي در نظر گرفته شده براي آن قسمت يا طي عمليات دور زدن خطا وظايف آن بخش را به ساير بخش‌ها محول کرده و پس از تعويض يا تعمير قسمت مورد نظر، سيستم را به حالت قبلي برگردانند. با به کارگيري چنين ناظرهايي مي‌تواند مدت توقف سيستم را به حداقل رساند و قابليت دسترسي سيستم را افزايش داد. مديران سيستم علاوه بر ابزارهاي نظارت مناسب، نياز به ابزارهاي مديريتي ديگري دارند تا به راحتي بتوانند سيستم را تحت کنترل داشته باشند و وظايف خود را انجام دهند. از جمله وظايف مديران سيستم مي‌توان مديريت بار شبکه و واحدها، نصب نرم‌افزارها، مديريت پيکربندي کلاستر، مديريت امنيت کلاستر، تخصيص پردازنده، حافظه و ديسک به صورت دستي يا خودکار، ايجاد شناسه کاربر، تغيير پيکربندي در نرم‌افزارها، سيستم فايل و ابزارهاي جانبي، شبيه‌سازي تغييرات پيش از اعمال آنها به کلاستر، تهيه اسکريپت‌هاي مناسب به منظور خودکارسازي فرايندها، تعيين نحوه انجام فرايند دور زدن خطا، نظارت بر شبکه و بسته‌هاي در حال اجرا بر روي واحدها، بازيابي سيستم در صورت بروز برخي مسائل پس از اعمال تغييرات در سيستم و پاسخ مناسب به اعلان وضعيت‌هاي غيرعادي از سوي ناظرها را برشمرد. همگي اين وظايف ابزار مناسبي را طلب مي‌کنند تا مديران بتوانند بهسادگي و بهطور سرراست تغييرات مورد نظرشان را به سيستم اعمال کنند. انواع روشهاي نظارت پيش از توضيح در مورد انواع ناظرها به توضيح دو مفهوم رويداد و وضعيت مي‌پردازيم. يک «رويداد» در لحظه‌اي از زمان اتفاق مي‌افتد، به طوري که در آن لحظه شرط از پيش تعيين شده‌اي محقق مي‌شود. به عنوان مثال در صورتي که بخواهيم با پيوستن کاربر صدم به جمع کاربران سيستم کلاستر، مدير سيستم را مطلع کنيم در صدد تشخيص يک رويداد هستيم که در لحظه ورود کاربر صدم به وقوع مي‌پيوندد. «وضعيت» يک سيستم يا يک نرم‌افزار مفهومي است که ممکن است با گذشت زمان تغيير کند و بر مقدار يک يا چند پارامتر تأکيد دارد. به عنوان مثال اگر در طول يک روز تعداد کاربران سيستم را در فواصل ده دقيقه‌اي در يک فايل ذخيره کنيم اين فايل نشانگر وضعيت سيستم در طول روز خواهد بود. حال به بحث اصلي باز مي‌گرديم. به طور کلي ناظرها به دو دسته تقسيم مي‌شوند: نمايشگرهاي وضعيت سخت‌افزار و ناظرهاي نرم‌افزار. نمايشگرهاي وضعيت سخت‌افزار اين نمايشگرها معمولاً براي ديسک‌ها، ابزارهاي شبکه و کارت‌هاي رابط مورد استفاده قرار مي‌گيرند و حالت فعلي آن بخش سخت‌افزاري را نمايش مي‌دهند. ساده‌ترين نوع اين نمايشگرها چراغ قرمز يا چشمک زني است که بروز اشکال را نشان مي‌دهند. استفاده از اين چراغ‌ها بسيار ساده است اما در يک محيط بزرگ که شامل ديسک‌ها و ابزارهاي زيادي است بررسي مداوم اين چراغ‌ها خسته کننده و مشکل است. بهعنوان مثال برای جايگزيني براي اين چراغ‌ها مي‌توان اجزاي سخت‌افزاري را طوري طراحي کرد که در صورت بروز اشکال، سيگنالي را ارسال کنند. يک کامپيوتر وظيفه دريافت اين سيگنال‌ها را بر عهده دارد و تنها در صورت نياز به رفع اشکال، پرسنل را مطلع مي‌سازد. اما اين روش، روش مطمئن و کاملي نيست زيرا جزئي که دچار اشکال مي‌شود ممکن است ديگر قادر به ارسال سيگنال نباشد. راه حل ديگر سرکشي است. در اين روش به صورت متناوب اجزاي مختلف تحريک مي‌شوند و در صورتي که يک جزء به اين تحريک پاسخ ندهد بهعنوان يک جزء خراب شناخته مي‌شود. ناظرهاي نرم‌افزار اين ناظرها براي کنترل برنامه‌هاي کاربردي (مثلاً يک پايگاه داده) به کار مي‌روند و هدف آنها اين است که تشخيص دهند يک برنامه کاربردي متوقف شده است يا نه؟ براي اين منظور يک برنامه نرم‌افزاري به طور پيوسته با برنامه کاربردي مورد نظر ارتباط برقرار مي‌کند. مثلاً محتواي يک جدول کوچک را که بين دو نرم‌افزار مشترک است مي‌خواند و در صورتي که برنامه کاربردي عمليات مورد انتظار را انجام نمي‌داد با ارسال پيام‌هاي مناسب، مدير سيستم را مطلع مي‌کند. بعضي از اين ناظرها نقشه‌اي از ابزارهاي سيستم را نمايش مي‌دهند و مدير امکان مشاهده اطلاعات حالت هر يک از آنها را دارد. ايده چراغ‌هاي هشداردهنده را مي‌توان در اين محيط‌هاي GUI به وسيله نمايش آيکن‌هاي کوچکي در کنار ابزارها، شبيه‌سازي کرد. سرويس‌هاي نظارت بر رويدادها (EMS) سرويس نظارت بر رويدادها، امکان تعيين نحوه نظارت و استفاده از اطلاعات بهدستآمده از آن را در اختيار مديران سيستم قرار مي‌دهد. در يک محيط EMS امکان پيکربندي منابع نظارت، دسته‌اي از روش‌هاي هشدار دهنده بهمنظور ارسال پيام‌ها در صورت بروز وضعيت‌هاي غيرعادي يا رسيدن به وضعيت‌هاي بحراني، و امکان ايجاد منابع جديد نظارت با استفاده از برنامه‌هاي استاندارد API فراهم مي‌شود. ناظرهاي تعريف شده در محيط EMS وظيفه تشخيص رويدادهايي را بر عهده دارند که در يک محيط HA بايد مورد توجه واقع شوند. اين رويدادها شامل بروز اشکال در يک واحد، از دست رفتن قابليت دسترسيبالا (يعني تشخيص و يافتن يک SPOF) و يا کاهش تدريجي کيفيت يکي از واحدها مي‌باشد. شکل 2-6 چگونگی ارتباط ناظرها را نشان میدهد. EMS از اجزاي زير تشکيل مي‌شود: برنامه‌هاي کاربردي ناظر رجيستري نرم‌افزار پيکربندي کننده (Configuration Clients) برنامه‌هاي کاربردي هدف (Target Applications) در شکل 2-7 اجزای EMS و نحوه ارتباط آنها با هم نشان داده شده است. شکل STYLEREF 1 \s ‏2 SEQ شکل \* ARABIC \s 1 6 نمای ساده از نظارت شکل STYLEREF 1 \s ‏2 SEQ شکل \* ARABIC \s 1 7 ارتباط اجزا مختلف EMS ابزارهاي نظارت، برنامه‌هايي هستند که حالت منابع سيستم را مشاهده کرده و در صورت بروز وضعيت غيرعادي، رجيستري را مطلع مي‌کنند. اين ناظرها در بازه‌هاي زماني معيني توسط رجيستري فعال مي‌شوند. گاهي اوقات شرکت‌هاي سازنده به همراه اجزاي سخت‌افزاري (مانند آرايه ديسک‌ها، ابزارهاي شبکه، حافظه‌ها) مانيتورهاي متناسب با آنها را نيز ارائه مي‌کنند که مي‌توان از آنها در محيط EMS استفاده نمود. ابزارهاي نظارت امکان شناسايي اجزائي که رو به اشکال و خرابی حرکت مي‌کنند را نيز فراهم مي‌سازند. نرم‌افزار پيکربندي کننده، نرم‌افزاري است که امکان تعريف تقاضاهاي نظارت را به مديران مي‌دهد. يک تقاضاي نظارت از قسمت‌هاي زير تشکيل مي‌شود: چه منابعي از سيستم بايد مورد نظارت قرار گيرند؟ چه رويدادهايي تحت نظارت باشند و در چه فواصل زماني رويدادها ديده شوند؟ در صورت وقوع رويداد، نحوه هشدار دادن چگونه باشد؟ هشدارها به کجا فرستاده شوند؟ انواع هشدارهاي به کار رفته در نظارت مي‌تواند بسيار متنوع باشد که به عنوان نمونه مي‌توان به سه مورد زير اشاره کرد: روشن کردن چراغ‌هاي هشداردهنده قرمز رنگ ارسال پيام به يک پيجر نمايش پيغام بر روي صفحه نمايش کامپيوتر مدير سيستم رجيستري وظيفه فعالسازي ناظرها را در زمان‌هاي معين به عهده دارد و به عنوان رابط بين سه جزء ديگر EMS عمل مي‌کند. وقتي يک تقاضاي نظارت در رجيستري ثبت مي‌شود اطلاعات آن در يک ليست نگهداري مي‌شود. در صورتي که يکي از ناظرها رويدادي را تشخيص دهد و به رجيستري اطلاع دهد، رجيستري برنامه کاربردي هدف را از وقوع رويداد باخبر مي‌کند. برنامه‌هاي کاربردي هدف، برنامه‌هايي هستند که مديران سيستم به منظور دريافت هشدارها و احتمالاً مديريت رويداد مورد استفاده قرار مي‌دهند. اين برنامه‌هاي کاربردي مي‌توانند هر برنامه‌اي که با قراردادهاي EMS سازگار است، باشند. در برخي موارد ممکن است نتيجه نظارت به صورت فايل‌هاي ثبت (وقايع) به مدير سيستم ارائه شود. در زير تعدادي از ناظرهايي که به صورت مجزا در اختيار مشتريان قرار مي‌گيرد، اشاره شده است: ناظر ديسک به منظور کسب اطلاعات در مورد فضاهاي منطقي و فيزيکي حافظه ناظر کلاستر به منظور گزارش وضعيت کلاستر، واحدها و بسته‌ها ناظر شبکه به منظور گزارش وضعيت رابط‌هاي شبکه ناظر سيستم به منظور کنترل بر تعداد برنامه‌هاي کاربردي، اندازه صف کارها و فضاي خالي سيستم فايل ناظر پايگاه داده به منظور کسب اطلاعات در مورد سرويس‌دهنده‌هاي پايگاه داده (مثل Informix و Oracle) سنجش ميزان قابليت دسترسيبالا سنجش دسترسی پذیری به عنوان وسيله‌اي براي تهيه گزارش از منابعي که منجر به اشکال در سيستم شده‌اند و نيز به منظور تعيين ميزان دسترسي سيستم مي‌تواند در سيستم‌هاي HA مورد استفاده قرار گيرد. سنجش دسترسی پذیری به درستي رويدادهايي را که منجر به از کارافتادگي سيستم مي‌شوند را شناسايي مي‌کند و تاريخچه وقوع اشکالات سيستم را در اختيار مديران قرار مي‌دهد. سنجش دسترسیپذیری به عنوان يکي از مانيتورهاي EMS وظايف خود را انجام مي‌دهد. تصوير يکپارچه سيستم (SSI) تصوير يکپارچه، يک ويژگي از سيستم است که طبيعت غيريکنواخت و توزيع شده منابع موجود در سيستم را مخفي کرده و سيستم را به صورت يک منبع محاسباتي واحد به کاربران و کاربردها مي‌نماياند. به عبارت ديگر کاربران يک سيستم SSI مستقل از اين که به طور فيزيکي به کدام واحد متصل شده‌اند يک ديد کلي نسبت به منابع سيستم خواهند داشت. علاوه بر اين SSI امکان پوشاندن اشکال‌ها از ديد کاربر، توزيع يکنواخت بار در سيستم و استفاده همزمان از منابع پردازشي سيستم را فراهم مي‌سازد. به طور کلي مي‌توان اهداف SSI را به قرار زير برشمرد: شفافيت کامل مديريت منابع، کارايي مقياس پذير و در دسترس بودن سيستم براي کاربردهاي کاربران. سرويس‌هاي ارائه شده توسط SSI سرويس‌هاي ارائه شده توسط يک ميانافزار SSI را مي‌توان به قرار زير برشمرد: ارتباط با کلاستر از طريق نقطه منفرد: کاربران هنگام ارتباط برقرار کردن با کلاستر چنين مي‌پندارند که به يک ميزبان مجازي متصل مي‌شوند در حالي که سيستم کلاستر از واحدهاي ميزبان فيزيکي متعددي تشکيل شده است. سيستم به طور کاملاً شفاف تقاضاهاي ارتباط کاربران با کلاستر را بر روي واحدهاي مختلف سيستم توزيع مي‌کند تا بار سيستم را متعادل سازد. رابط منفرد با کاربر: ارتباط با کاربر از طريق يک GUI منفرد صورت مي‌گيرد و کاربر دقيقاً همان ديد و احساسي را دارد که در کار با ايستگاه‌هاي کاري منفرد دارد. فضاي پروسه يکتا: همه پروسه‌هاي کاربر در تمام کلاستر با يک شناسه منحصر به فرد شناخته مي‌شوند، اگر چه ممکن است پروسه‌ها بر روي واحدهاي ديگر ارتباط برقرار کند و يا پروسه‌هاي کوچک‌تري را ايجاد کند و بر روي همان واحد يا واحدهاي ديگر اجرا شوند. فضاي حافظه يکتا: کاربر حافظه سيستم را به صورت يک حافظه متمرکز با حجم بسيار زياد مشاهده مي‌کند در حالي که در واقع ممکن است حافظه‌ها در سيستم به صورت محلي و توزيع شده باشند. فضاي ورودي/ خروجي منفرد: اين قابليت به هر واحد امکان انجام عمليات ورودي/ خروجي محلي و يا انجام عمليات ورودي/ خروجي بر روي ديسک‌ها يا ادوات جانبي که بر روي يک واحد ديگر قرار دارند را مي‌دهد. سلسله مراتب فايلي يکسان: کاربر پس از ورود، يک سيستم فايل واحد را مي‌بيند که سلسله مراتب فايل‌ها و دايرکتوري‌ها نيز به صورت يکپارچه است، اگر چه اين فايل‌ها در واقع ممکن است بر روي ديسک‌هاي محلي يا سراسري و يا ساير ادوات نگهدارنده فايل‌ها قرار داشته باشند. شبکه مجازي منفرد: اگر چه ممکن است در سيستم شبکه‌هاي متعددي وجود داشته باشند که به طور فيزيکي همگي به هم متصل نيستند اما هر واحد مي‌تواند با ساير واحدهاي شبکه ارتباط برقرار کند. سيستم واحد مديريت کارها: به وسيله يک زمان‌بند، کارهاي رسيده از سوي کاربران براي اجرا بر روي يک يا چند واحد زمان‌بندي مي‌شوند. کارها مي‌توانند به منظور اجراي گروهي، تعاملي و يا موازي زمان بندي شوند. نقطه کنترل و مديريت واحد: تمام کلاستر و واحدها مي‌توانند با استفاده از يک ابزار واسط گرافیکی (GUI) و از يک نقطه معين پيکربندي، مانيتور، تست و کنترل شوند. تهيه نقطه مقابله و انتقال پروسه‌ها: که به منظور بازيابي سيستم در حالت بروز اشکال و همچنين براي مديريت بار انجام مي‌شوند. مزاياي تصوير يکپارچه از سيستم مزاياي تصوير يکپارچه از سيستم به قرار زير است: ارائه يک ديد ساده نسبت به همه منابع و فعاليت‌ها در يک سيستم کلاستر عدم نياز کاربران به دانستن اين که کاربرد آنها در کدام قسمت از کلاستر اجرا مي‌شود. امکان استفاده از منابع سيستم به صورتي کاملاً شفاف و بدون نگراني در مورد محل فيزيکي آنها امکان کار کردن کاربران با رابط‌ها و دستورات آشنا امکان مديريت کلاستر به صورت يک سيستم منفرد براي مديران سيستم کاهش ريسک اشتباهات اپراتورها (به دليل آشنا بودن دستورات) و در نتيجه کارايي و قابليت اطمينان و قابليت دسترسي بالاتر از ديد کاربران فراهم سازي امکان مديريت و کنترل به صورت متمرکز يا غير متمرکز و در نتيجه عدم احتياج به مديران بسيار ماهر براي سيستم تسهيل مديريت سيستم و کاهش هزينه مالکيت سيستم امکان ارسال و دريافت پيام‌ها مستقل از محل عدم نياز به زمان، مهارت و دانش زياد براي انجام کارها توسط برنامه نويسان سيستم و امکان کار کردن کارکنان موجود با سيستم‌هاي پيچيده‌تر و بزرگ‌تر عامل مثبتي در جهت توسعه و پيشرفت ابزارهاي استاندارد. البته بحث تصوير يکپارچه سيستم بسيار مفصل است و در محدوده اين پایاننامه نمي‌گنجد. آنچه اهميت دارد توجه به اين نکته است که با وجود قابليت دسترسيبالا و تحملپذیری اشکال امکان فراهم شدن تصوير يکپارچه محقق خواهد شد و کاربر از اشکال‌هاي احتمالي مطلع نمي‌شود. همان طور که قبلاً عنوان شد، ما در اين پروژه سيستم‌هاي محاسبات ابری مبتنی بر مراکز داده که از روش مبادله پيام استفاده مي‌کنند را مورد بررسي قرار خواهيم داد. اين محيط‌ها به علت ويژگي خاص خود که ارتباط کارهای موازي فقط از طريق پيام‌هاي رد و بدل شده انجام مي‌پذيرد، داراي توانمندي‌هاي بالقوه براي انجام عمليات بازيافت مي‌باشند. از اين رو در فصل آينده قراردادهاي مختلف بازيافت را در اين گونه محيط‌ها معرفي مي‌کنيم. فصل سوم روالهاي تحملپذیر اشکال براي رسيدن به قابليت دسترسي بالا در سيستمهاي مبادله پيام روالهای تحمل‌پذیر اشکال برای رسیدن به قابلیت دسترسی بالا در سیستمهای مبادله پیام يكي از مهم‌ترين تكنيك‌ها در افزايش قابليت اطمينان و قابليت دسترسي بالا، بازيافت مي‌باشد. اين تكنيك كه به صورت مخفي‌ از ديد كاربر انجام مي‌گيرد به ما كمك مي‌كند تا بتوانيم عمل تحملپذیری اشکال را انجام دهيم. اين قراردادها در يك محيط توزيع شده كه مجموعه‌اي از تکه برنامههای موازی (پروسه‌ها، ماشینهای مجازی و...) در آن وجود دارند و بر روي يك شبكه با يكديگر ارتباط دارند، عمل مي‌كند. این تکه برنامهها به يك ذخيره‌ساز پايدار دسترسي دارند كه اشکالهاي تحمل شده را به كمك آن بازيابي مي‌كنند. در واقع ماشینهای مجازی اطلاعات مرتبط به بازيافت را در زمان اجرا روي اين ذخيره‌ساز ثبت مي‌كنند. در زمان رويداد يك اشکال، ماشین مجازی مي‌تواند با استفاده از اين داده‌ها از آخرين محاسبات، كار خود را ادامه دهد و بنابراين در زمان پردازش صرفه‌جويي كند. حداقل اطلاعات بازيافت، شامل حالت ماشین مجازی است كه به آن نقطه مقابله گفته مي‌شود. بعضي از قراردادهاي بازيافت ممكن است به اطلاعاتي نظير ارتباطات بين دستگاه‌هاي ورودي/ خروجي، اتفاق‌هايي كه روي هر ماشین مجازی افتاده است و پيام‌هايي كه بين کارهای درون ماشین مجازی مبادله شده است، احتياج داشته باشد. قراردادهاي بازيافت مي‌توانند به طرق مختلف استفاده شوند كه بهترين نوع آنها تكنيك‌هايي است كه به صورت مخفي عمل مي‌كنند و برنامه‌ كاربردي و برنامه‌نويس دخالتي در عملكرد آن ندارند. در اين حالت سيستم به صورت خودكار و بر اساس سياست مشخص شده نقطه مقابله را مي‌گيرد و در صورت رويداد اشکال آن را به صورت خودكار بازيابي مي‌نمايد. حسن اين روش، راحت شدن برنامه‌نويس از پيچيدگي مورد نياز براي تحمل‌پذیری اشکال در برنامه است و در اين صورت برنامه‌ها بدون ملاحظات تحمل‌پذیری اشکال نوشته خواهند شد. بازيافت در سيستم‌هاي مبادلة پيام مشكل است، زيرا پيام‌ها باعث ايجاد وابستگي بين تکه برنامههای محییط موازی در زمان اجراي عادي آنها مي‌شود. اين وابستگي باعث مي‌شود كه گاهي واحدهايي كه خراب نشده‌اند نيز بازيافت شوند. براي ديدن اينكه چرا عمل انتشار بازيافت اتفاق مي‌افتد، فرض كنيد فرستنده يك پيام مثل m، به حالت قبل ارسال پيام بازيافت شود. گيرنده پيام m نيز بايد در حالت قبل از دريافت پيام m قرار گيرد. در غير اينصورت، حالت دو ماشین مجازی غير يكپارچه خواهد شد و نشان مي‌دهد كه پيام m ارسال نشده است اما يك ماشین مجازی آن را دريافت كرده است و اين غيرممكن است. تحت شرايطي ممكن است عمل انتشار بازيافت آنقدر به عقب برگردد كه باعث شود تمام كارهاي انجام شده از بين برود و نهايتاً ماشین مجازی به حالت اوليه بازيافت شود كه به آن اثر دومينو گفته مي‌شود[16]. اثر دومينو ممكن است در اثر گرفتن نقطه مقابلههاي مستقل در هر ماشین مجازی اتفاق بيفتد كه به اين روش نقطه مقابله گرفتن مستقل يا غيرهماهنگ گفته مي‌شود. واضح است كه از بين بردن اثر دومينو مورد نظر طراحان روش‌هاي تحمل‌پذیر اشکال است. يكي از روش‌هاي از بين بردن آن گرفتن نقطه مقابله به صورت هماهنگ است كه در آن ماشینهای مجازی، نقطه مقابله را به صورت هماهنگ با يكديگر به‌دست مي‌آورند [17]. اين مجموعه يكپارچه از نقطه مقابله‌ها مي‌تواند براي محدود كردن انتشار بازيافت مورد استفاده قرار گيرد. همچنين روش نقطه مقابله گرفتن بر اساس ارتباطات، هر ماشین مجازی را مجبور به گرفتن نقطه مقابله بر اساس پيام‌هاي دريافتي از بقيه ماشینهای مجازی مي‌كند[17]. نقطه مقابله‌هايي كه به اين صورت گرفته شوند يك حالت هميشه يكپارچه را براي سيستم، روي ذخيره ساز پايدار حفظ مي‌نمايد و بنابراين اثر دومينو را از بين خواهد برد. علاوه بر تكنيك گفته شده براي بازيافت كه بر اساس نقطه مقابله‌ مي‌باشد، روش ديگري نيز براي بازيافت مطرح است كه بر اساس ثبت وقايع استوار است. در اين روش رويدادها يا پيام‌ها ثبت مي‌شوند تا براي بازيافت حالت سيستم در هنگام رويداد اشکال استفاده شود. بازيافت بر اساس ثبت‌ وقايع به فرض PWD تكيه دارد[19] كه ادعا مي‌كند همه رويدادهاي غيرقطعي كه توسط يك ماشین مجازی اجرا مي‌گردد مي‌تواند تشخيص داده شود و اطلاعات لازم براي پاسخ هر رويداد در زمان بازيافت مي‌تواند در يك تعيين‌كننده رويداد ثبت شود[19]. با ثبت وقايع وپاسخدهي به رويدادهاي غيرقطعي به ترتيب اصلي، يك ماشین مجازی مي‌تواند حالت قبل از اشکال خود را بازسازي كند حتي اگر اين حالت نقطه مقابله نشده باشد. در حالت كلي قراردادهاي بازيافت بر اساس ثبت وقايع امكان بازيافت را براي يك سيستم فراتر از مجموعه نقطه مقابله يكپارچه فراهم مي‌آورد. اين خاصيت مي‌تواند براي كاربردهايي كه با دنياي بيرون ارتباط دارند، بسيار مهم باشد زيرا تعدادي از دستگاه‌هاي ورودي و خروجي هستند كه نمي‌توانند بازگشت به عقب داشته باشند. بازيافت به اين روش داراي سه نوع مختلف است: ثبت بدبينانه وقايع ثبت خوشبينانه وقايع ثبت علّي وقايع پيشزمينه و تعاريف مدل سيستم يك سيستم مبادله پيام شامل يك تعداد ثابت از ماشینهای مجازی یا پروسههای موازی است كه فقط از طريق پيام با يكديگر در ارتباط هستند. در اين فصل ما N را به‌ عنوان تعداد پروسه‌هاي موجود در سيستم استفاده مي‌نماييم. پروسه‌‌ها با همكاري يكديگر يك برنامه كاربردي توزيع شده را اجرا مي‌كنند و بوسيله دريافت و ارسال پيام با دنياي خارج ارتباط برقرار مي‌كنند. شکل 3-1 يك سيستم ساده شامل سه پروسه را نشان مي‌دهد. شکل STYLEREF 1 \s ‏3 SEQ شکل \* ARABIC \s 1 1 مثالی از يك سيستم مبادله پيام با سه واحد موازی در حالت كلي قراردادهاي بازيافت فرض مي‌كنند كه شبكة ارتباطي از قسمتبندي شدن در امان است. البته اين موضوع با قابليت اطمينان شبكه متفاوت است. بعضي از قراردادها فرض مي‌كنند كه زير سيستم ارتباطي، پيام را به صورت مطمئن تحويل مي‌دهد، به شكل FIFO [17] در حاليكه بقيه قرارداد‌ها فرض مي‌كنند كه زير سيستم ارتباطي مي‌تواند پيامها را گم يا تكرار كند و يا خارج از ترتيب تحويل دهد [12]. انتخاب يكي از اين دو فرض بر روي پيچيدگي بازيافت مؤثر است وپياده‌سازي متفاوتي نيز طلب خواهد كرد. در حالت كلي، فرض داشتن يك شبكه قابل اطمينان، طراحي قرارداد بازيافت را ساده خواهد كرد، اما باعث پيچيدگي در پياده‌سازي مي‌شود كه در قسمت‌هاي بعدي توضيح داده خواهد شد. اجراي يك پروسه دنبا‌له‌اي از بازه‌هاي حالت است كه هر كدام با يك رويداد غير قطعي آغاز مي‌شود. اجرا درهر بازه زمان قطعي است، به صورتي كه اگر يك پروسه از يك حالت مساوي شروع كند و با رويدادهاي غيرقطعي مساوي در مكان‌هاي مساوي مورد تأثير قرار گيرد، هميشه خروجي يكسان توليد خواهد نمود. يك مفهوم وابسته به بازه حالت فرض PWD مي‌باشد. اين فرض بيان مي‌كند كه سيستم مي‌تواند اطلاعات كافي در مورد رويداد‌هاي غير قطعي كه بازه‌هاي حالت را مقدار اوليهدهي مي‌كند، تشخيص و ذخيره نمايد. يك شرط كلي براي صحت عمل بازيافت را مي‌توان به اين صورت تعريف كرد:”يك سيستم به درستي بازيافت مي‌شود اگر حالت داخلي آن با رفتار سيستم قبل از اشکال تطابق داشته باشد“ [21]. بنابراين قرارداد‌هاي بازيافت بايد اطلاعاتي در مورد تعامل‌هاي داخلي بين پروسه‌ها و ارتباطات با دنياي خارج را نيز نگهداري كنند. حالت‌هاي سيستم يكپارچه حالت سراسري دريك سيستم مبادله پيام، مجموعه‌اي از حالت‌هاي تك تك پروسه‌هاي فعال بههمراه حالت كانال‌هاي ارتباطي مي‌باشد. حالت سيستم يكپارچه در واقع حالتي است كه اگر حالت يك پروسه نشان دهدكه دريافت‌كننده يك پيام است، حالت پروسه مقابل آن نشان دهنده ارسال آن پيام باشد[17]. براي مثال، شکل 3-2 دو مثال از حالت سراسري را نشان مي‌دهد. در قسمت (a) يك حالت يكپارچه و در قسمت (b) يك حالت غير يكپارچه مشخص شده است. توجه كنيد كه در قسمت (a) حالتي نشان داده شده است كه در آن پيام m1 ارسال شده است، اما هنوز دريافت نشده است. اين حالت يكپارچه است زيرا موقعيتي را نشان مي‌دهد كه يك پيام در حالت عبور از شبكه مي‌باشد. از سوي ديگر در شكل (b) پروسه P2 پيام m2 را دريافت كرده است اما حالت پروسه P1 نشان نمي‌دهد كه m2 ارسال شده است واين در حالت عادي غير ممكن مي‌باشد وبنابراين اين حالت غير يكپارچه خواهد بود. به‌طور كلي حالت‌هاي غير يكپارچه در اثر رويداد اشکال اتفاق مي‌افتند. براي مثال در شكل (b) موقعيت مشخص شده ممكن است در اثر خراب شدن پروسه P1 بعد از ارسال پيام m2 براي پروسه P2، اتفاق افتاده باشد كه در نتيجه به حالت نشان داده شده در شكل بازيافت شده و حالت يكپارچه ايجاد شده است. يك هدف اساسي در تمامي قراردادهاي بازيافت، تغيير حالت غير يكپارچه سيستم به حالت يكپارچه مي‌باشد. شکل STYLEREF 1 \s ‏3 SEQ شکل \* ARABIC \s 1 2 مثالی از حالت يكپارچه و غيريكپارچه سيستم تعامل با دنياي خارج يك سيستم مبادله پيام اغلب براي دريافت داده‌هاي ورودي و ارسال نتايج محاسبات با دنياي خارج در تعامل است. اگر يك اشکال اتفاق بيفتد، دنياي خارج نمي‌تواند به بازگشت به عقب تكيه كند [21]. براي مثال يك چاپگر نمي‌تواند عمل چاپ كاراكترها را به عقب برگرداند و يا يك خود پرداز بانك نمي‌تواند پولي كه تحويل مشتري داده است را برگرداند. براي سادهسازي نحوه تعامل قراردادهاي بازيافت با دنياي خارج، ما پروسه‌ها را به صورت خاص براي ارتباط با دنياي خارج مدل مي‌كنيم. اين پروسه‌ها نمي‌توانند خراب شوند، در قرارداد بازيافت نيز شركت ندارند و حالتي را حفظ نمي‌كنند. اين پروسه‌هاي خاص را پروسه‌هاي دنياي خارج (OWP) اسمگذاري مي‌كنيم. در ارتباط با دنياي خارج نياز است كه رفتار سيستم عليرغم وجود اشکال به صورت يكپارچه درك شود. بنابراين، قبل از ارسال پيام به خروجي سيستم بايد مطمئن شود كه حالت پروسه ارسالكننده پيام، در صورت رويداد اشکال‌هاي آتي قابل بازيافت است. به اين مسئله ثبتِ خروجي گفته مي‌شود. به صورت مشابه، پيام‌هاي ورودي از دنياي خارج كه سيستم دريافت مي‌كند در زمان بازيافت قابليت توليد را ندارد، به اين دليل كه OWP ممكن است نتواند آنها را دوباره توليد كند. بنابراين، قرارداد بازيافت بايد بهصورتي سازماندهي شود كه اين پيام‌هاي ورودي را ذخيره نمايد تا در زمان بازيافت امكان بازيابي آنها وجود داشته باشد. يك راه حل عمومي براي اين مسئله، ذخيره كردن پيام‌هاي ورودي روي ذخيرهساز پايدار قبل از اينكه برنامه‌هاي كاربردي پردازشي روي آن انجام دهند، مي‌باشد. با توجه به اين مطالب، قراردادهاي بازيافت بايد داراي سياست خاصي براي تعامل با دنياي خارج باشند. دو پارامتر تأخير ورودي/خروجي وكاهش سرعت اجراي سيستم در زمان ورودي/خروجي تأثير ارتباط با دنياي خارج را مشخص مي‌نمايد. پارامتر اول نشان دهنده زمان مورد نياز براي يك پيام خروجي است كه از سيستم وارد OWP گردد و يا زماني كه طول مي‌كشد تا يك پروسه پيام ورودي را كه از يك OWP ارسال شده است، دريافت كند. پارامتر دوم نشان دهنده سربار است كه سيستم براي اطمينان از اينكه حالت سيستم با مبادله پيام با OWP در صورت اتفاق افتادن اشکال در آينده يكپارچه مي‌ماند، مي‌پردازد. پيام در حال گذر شکل 3-2 (a) حالت سراسري را نشان مي‌دهد كه پيام m1 ارسال شده است. به چنين پيام‌هايي پيام در حال گذر گفته مي‌شود. وقتي پيام‌هاي در حال گذر قسمتي از حالت سيستم باشند، باعث غير يكپارچگي نمي‌شوند. اما وابسته به فرض قابل اطمينان بودن كانال ارتباطي، قرارداد بازيافت ممكن است مجبور به تضمين كردن تحويل پيام‌هاي در حال گذر در زمان اتفاق افتادن اشکال شود. براي مثال، قرارداد بازيافت در شکل 3-3 قسمت (الف) فرض مي‌كند ارتباطات به صورت قابل اطمينان انجام مي‌گيرد و بنابراين بايد روي لاية ارتباطي مطمئن پياده‌سازي گردد. برعكس آن درقسمت (ب) مي‌باشد كه قرارداد بازيافت فرضي در مورد قابليت اطمينان كانال ارتباطي ندارد. قرارداد‌هاي ارتباطي قابل اطمينان، تضمين مي‌كند كه در زمان اجراي بدون اشکال پيام‌ها بهدرستي تحويل گيرنده شوند. واضح است كه در زمان رويداد اشکال اين تضمين وجود نخواهد داشت. براي مثال، اگر يك پيام در حال گذر بهدليل خراب شدن گيرنده آن گم شود، قراردادهاي ارتباطي عادي با توليد يك پايان مهلت به فرستنده خبر مي‌دهند كه پيام را نمي‌توانند تحويل دهند. اما در يك سيستم بازيافت، گيرنده بازيابي خواهد شد. بنابراين سيستم بايد زمان اشاره شده را از ديد برنامه كاربردي در پروسه فرستنده بپوشاند و پيام در حال گذر را بعد از بازيابي گيرنده به آن تحويل دهد. به اين ترتيب يك تصوير يكپارچه از سيستم قابل اطمينان به‌دست مي‌آيد. شکل STYLEREF 1 \s ‏3 SEQ شکل \* ARABIC \s 1 3 پياده‌سازي مكانيسمهاي بازيافت از طرف ديگر، اگر يك مدل سيستم مانند شکل 3-3 قسمت(ب) فرض كانال ارتباطي غيرمطمئن داشته باشد، قرارداد بازيافت كار خاصي روي پيام‌هاي در حال‌گذر انجام نخواهد داد. در چنين سيستم‌هايي گم شدن يك پيام در حال گذر مي‌تواند هم بهدليل وجود كانال ارتباطي غيرمطمئن باشد كه در زمان اجراي بدون اشکال صورت مي‌گيرد و يا همانطور كه اشاره شد در اثر يك اشکال اتفاق بيفتد، بنابراين دوحالت اشاره شده قابل تفكيك از يكديگر نيستند. قراردادهاي ثبت وقايع بازيافت بر اساس ثبت وقايع با استفاده از نقطه مقابله و ثبت اطلاعات پروسه‌ها بعد از اتفاق افتادن اشکال انجام مي‌گيرد. اين نحوه بازيافت براي پروسه‌هايي كه با دنياي خارج ارتباط زيادي دارند مي‌تواند مفيد باشد به اين دليل كه در اين تعامل‌ها نياز به گرفتن نقطه مقابله‌هاي دقيق و با هزينه زياد وجود ندارد. بهعلاوه، قراردادهاي بازيافت بر اساس ثبت وقايع اثر دومينو ندارند و بنابراين پروسه‌ها مي‌توانند نقطه مقابله را به صورت غيرهماهنگ ثبت كنند. بازيافت بر اساس ثبت وقايع روي فرض PWD استوار است [21]. بر طبق اين فرض، قرارداد بازيافت مي‌تواند همة‌ رويدادهاي غيرقطعي را كه هر پروسه اجرا مي‌كند، تشخيص دهد و براي هر كدام از اين رويدادها يك تعيين‌كننده كه شامل همه اطلاعات لازم براي پاسخ‌دهي به رويداد در هنگام بازيافت است را ثبت كند. مثال‌هايي از رويدادهاي غيرقطعي، پيام‌هاي دريافتي، دريافت ورودي از دنياي خارج و يا دريافت يك وقفه مي‌باشد. البته پياده‌سازي‌هاي مختلف قراردادهاي بازيافت در پوشاندن انواع رويدادهاي غير قطعي با يكديگر متفاوت هستند. در مورد اين مطلب در قسمت پياده‌سازي بحث خواهد شد. يك بازه حالت را قابل بازيافت گويند اگر اطلاعات كافي براي شروع مجدد اجرا از آن فاصله حالت در صورت اتفاق افتادن اشکال درآينده وجود داشته باشد. همچنين يك بازه حالت پايدار است اگر تعيين‌كننده رويداد غيرقطعي شروع شده بر روي ذخيره‌ساز پايدار ثبت شده باشد [23]. يك بازه حالت قابل بازيافت هميشه پايدار است اما عكس آن درست نيست [12]. شکل 3-4 يك اجرا را نشان مي‌دهد كه در آن رويدادهاي غيرقطعي فقط تحويل پيام‌ها مي‌باشد. فرض كنيد پروسه‌هاي P1 و P2 قبل از ثبتِ تعيين‌كنندة تحويلِ پيام‌هاي m6 و m5 دچار اشکال شوند. در اين حالت پيام m7 يك پيام يتيم خواهد شد به اين دليل كه پروسه P2 نمي‌تواند توليد دوباره پيام m6 را در زمان بازيافت تضمين كند و پروسه P1 نيز نمي‌تواند توليد دوباره پيام m7 را بدون وجود پيام اصلي m6 تضمين نمايد. در نتيجه، پروسه نجات يافتة P0 يك پروسه يتيم مي‌شود و مجبور به بازگشت به عقب خواهد شد. حالت‌هاي X، Y وZ حالت قابل بازيافت حداكثر را تشكيل مي‌دهند [11] كه آخرين حالت يكپارچه سيستم است كه قابل بازيابي مي‌باشد. پروسه‌هاي P0 و P2 به نقطه مقابلههاي A و C بر مي‌گردند و عمل تحويل پيام‌هاي m4 و m2 را دوباره اجرا مي‌كنند تا به حالت‌هاي X و Z برسند. پروسه P1 و نقطه مقابله شمارة B برگشت مي‌كند و عمل تحويل پيام‌هاي m4 و m2 را به ترتيب اوليه انجام مي‌دهد تا به حالت Y برسد. در زمان بازيافت، قراردادهاي بازيافت بر اساس ثبت وقايع، اجراي سيستم را در نقطه‌اي مشابه با قبل از رويداد اشکال تا حالت ‌قابل بازيافت حداكثر قرار مي‌دهند. بنابراين، سيستم هميشه به يك حالت يكپارچه تا حالت قابل بازيافت حداكثر بازيابي مي‌شود. شکل STYLEREF 1 \s ‏3 SEQ شکل \* ARABIC \s 1 4 ثبت كردن پيام براي اجراي مجدد قطعي ذخيره‌ساز پايدار قرارداد‌هاي بازيافت براي ذخيره كردن نقطه مقابله‌ها و ثبت رويدادها و ديگر اطلاعات مربوط به بازيافت از ذخيره‌ساز پايدار استفاده مي‌نمايند. ذخيره‌ساز پايدار بايد اطمينان دهد كه داده‌هاي بازيافت در آن بهدرستي ذخيره مي‌شود و در اثر رويداد اشکال روي آن باز هم داده‌ها قابل دسترسي هستند. اين نيازمندي مي‌تواند پياده‌سازي‌هاي متفاوتي را به دنبال داشته باشد: در يك سيستم كه فقط يك اشکال را تحمل مي‌كند، ذخيره‌ساز پايدار مي‌تواند شامل حافظه فرار از پروسه ديگر باشد [24]. در يك سيستم كه خواهان تحمل تعداد دلخواهي اشکال گذرا است، ذخيره‌ساز پايدار ممكن است يك ديسك محلي در هر ايستگاه باشد. در يك سيستم كه اشکال‌هاي غيرگذرا را تحمل مي‌كند، ذخيره‌ساز پايدار ممكن است شامل يك ذخيره‌ساز پايدار خارج از ايستگاه‌ها و در جايي كه پروسه در حال اجرا است، باشد. يك سيستم فايل تكرار شده مي‌تواند پياده‌سازي اين سيستم باشد [25]. جمع‌آوري داده‌هاي زائد اشاره شد كه نقطه مقابله‌ها و ثبت وقايع نياز به منابع ذخيره‌سازي دارند. همانطور كه اجراي برنامه‌ها پيشرفت مي‌كند، اطلاعات بازيافت نيز در ذخيره‌سازها جمع مي‌شود. اين اطلاعات بعد از يك زماني ديگر مفيد نيستند و فقط فضاي ذخيره‌ساز را اشغال مي‌نمايند. جمع‌آوري داده‌هاي زائد به معني از بين بردن اطلاعات بازيافت غيرمفيد است. يك راه ساده براي اين كار، پيدا كردن آخرين مجموعة يكپارچة از نقطه مقابله‌ها، كه به آن خط بازيافت گويند [16]، و از بين بردن همة اطلاعات كه وابسته به رويدادهاي قبلي هستند، مي‌باشد. براي مثال، پروسه‌هايي كه عمل نقطه مقابله را به صورت هماهنگ انجام مي‌دهند، هميشه مي‌تواند از آخرين نقطه مقابله بازيافت شوند و به همين دليل بقيه‌ نقطه مقابله‌ها مي‌تواند از بين برود. عمل جمع‌آوري داده‌هاي زائد نقش مهمي در قراردادهاي بازيافت عمل مي‌كند چون از بين بردن اطلاعات زيادي، روي عمل بازيافت سربار ايجاد مي‌كند. همچنين قراردادهاي بازيافت در نحوه ذخيره كردن اطلاعات و حجم آنها با يكديگر متفاوت هستند و بنابراين بايد الگوريتم‌هاي متفاوتي براي جمع‌آوري داده‌هاي زائد استفاده نمايند. بازيافت براساس نقطه مقابله روش‌هاي بازيافت بر اساس نقطه مقابله بدليل تكيه نداشتن بر فرضPWD و احتياج نداشتن به تشخيص، ثبت يا دوباره انجام دادن رويدادهاي غيرقطعي از روش‌هاي بر اساس ثبت وقايع ساده‌تر هستند. اما عيب‌ آن‌ها اين است كه توليد دوبارة وضعيت اجراي پروسه قبل از اشکال را تضمين نمي‌كنند. بنابراين روش نقطه مقابله براي كاربردهايي كه با دنياي خارج ارتباط زيادي دارند مناسب نيست زيرا بازيافت دقيق و كامل حالت اجراي قبل از اشکال را تضمين نمي‌كند. روش‌هاي بازيافت بر اساس آزمون نقطه مقابلهگیری به سه گروه تقسيم‌ مي‌شوند كه در زيرآمده است و در ادامه اين روش‌ها توضيح داده مي‌شود: نقطه مقابله به صورت غيرهماهنگ نقطه مقابله به صورت هماهنگ نقطه مقابله بر اساس ارتباطات نقطه مقابله گرفتن به صورت غيرهماهنگ بررسي ديدگاه در اين روش هر پروسه در هر زماني مي‌تواند نقطه مقابله خود را ذخيره كند. حسن اين روش خودمختاري پروسه براي نقطه مقابله گرفتن است و بنابراين مي‌تواند در زمان مناسبي انجام گيرد. براي مثال يك پروسه ممكن است براي كاهش سربار، عمل نقطه مقابله گرفتن را وقتي اطلاعاتِ حالت مقدار كمي دارند، انجام دهد [26]. اما در اين صورت ما چندين عيب خواهيم داشت. اول، احتمال اتفاق افتادن اثر دومينو وجود خواهد داشت كه باعث از بين رفتن مقدار زيادي از كارهاي مفيد خواهد شد و حتي ممكن است پروسه‌ها به ابتداي اجرا برگردند. دوم، يك پروسه ممكن است نقطه مقابله بيمصرف را ذخيره كند كه هرگز قسمتي از حالت يكپارچه سراسري نخواهد بود. اين نقطه مقابلهها باعث افزايش سربار مي‌شوند. سوم، نقطه مقابله گرفتن به صورت غير هماهنگ هر پروسه را مجبور به نگهداري چندين نقطه مقابله مي‌كند و بنابراين به صورت متناوب بايد الگوريتم جمع‌آوري داده‌هاي زائد براي از بين بردن‌ اطلاعات غيرمفيد اجرا گردد. چهارم، ‌اين روش براي كاربردهايي كه خروجي زياد دارند، ‌مناسب نيست زيرا اين برنامه‌ها براي محاسبه خط بازيافت نياز به هماهنگي سراسري دارند كه در اين صورت حسن خودمختار بودن از بين مي‌رود. براي مشخص شدن نقطه مقابله سراسري يكپارچه در زمان بازيافت، پروسه، وابستگي بين نقطه مقابله‌هاي خود را در زمان اجراي بدون اشکال با استفاده از تكنيك زير ثبت مي‌كند [27]. فرض كنيد Ci,x، نقطه مقابله شماره x از پروسه Pi باشد. ما به x، انديس نقطه مقابله مي‌گوييم. فرض كنيد I i,x بازه نقطه مقابله يا به صورت ساده فاصله بين دو نقطه مقابله، Ci,x و Ci,x-1 باشد. همانطور كه در شکل 3-5 مشخص است، اگر پروسه Pi در بازه Ii,x پيام m را به Pj ارسال كند. زوج (i,x) نيز همراه پيام m ارسال خواهد شد. وقتي Pj پيام m را در بازه Ii,y دريافت كرد، وابستگي از Ii,x به Ii,y را ثبت مي‌كند كه در ادامه و در زماني كه Pj عمل گرفتن نقطه مقابله Cj,y را انجام داد، روي ذخيره‌ساز پايدار ذخيره مي‌شود. شکل STYLEREF 1 \s ‏3 SEQ شکل \* ARABIC \s 1 5 انديس نقطه مقابله و بازه نقطه مقابله اگر يك اشکال اتفاق بيفتد، پروسه بازيافت براي شروع يك پيام درخواست وابستگي را براي همه و به‌منظور جمع‌آوري اطلاعات وابستگي كه هر پروسه در اختيار دارد، ارسال مي‌كند. وقتي يك پروسه اين پيام را دريافت كرد، اجراي خود را متوقف مي‌كند و اطلاعات وابستگي كه روي ذخيره‌ساز پايدار نوشته است و همچنين اطلاعات وابستگي كه ممكن است در حالت جاري خود وجود داشته باشد را برمي‌گرداند. پروسه بازيافت با استفاده از اطلاعات ارسالي توسط همه پروسه‌ها، خط بازيافت را محاسبه مي‌كند و پيام درخواست‌ بازگشت به عقب را در قالب يك پيام ارسال مي‌كند وقتي هر پروسه اين پيام را دريافت كرد، اگر حالت جاري آن در خط بازيافت بود، فقط كافي است كه اجراي خود را ادامه دهد؛ در غير اين صورت پروسه به نزديك‌ترين نقطه مقابله كه خط بازيافت آن را مشخص مي‌كند، بر مي‌گردد و از آنجا شروع به اجرا مي‌كند. محاسبة خط بازيافت و گراف‌هاي وابستگي در مقالات و گزارش‌هاي موجود دو راه‌حل براي پيدا كردن خط بازيافت در روش‌هاي مبتني بر نقطه مقابله ارائه شده است. روش اول بر اساس گراف وابستگي بازگشت به عقب [27] است كه در آن هر گره گراف نشان دهنده يك نقطه مقابله و يال‌هاي جهت‌دار از Ci,x و Cj,y خواهند بود اگر: i≠j و يك پيام مثل m از Ii,x ارسال شده باشد و I j,y آن را دريافت كرده باشد، يا i=j و y=x+1 نام گراف از آنجايي كه گرفته شده است كه اگر يك يال از Ci,x به Cj,y وجود داشته باشد و يك اشکال باعث شود كه Ii,x به عقب برگردد،‌آن گاه Ij,y نيز بايد بازگشت به عقب داشته باشد. در شکل 3-6 قسمت(b )يك گراف وابستگي بازگشت به عقب براي اجراي قسمت(a) رسم شده است. الگوريتم پيدا كردن خط بازيافت، در ابتدا گره‌هايي از گراف را كه حالت دو پروسه P1 و P0 را در نقطه اشکال نشان مي‌دهد علامت‌گذاري مي‌كند(در شكل به صورت بيضي سياه ديده مي‌شود). سپس آناليز دسترسي [27] براي تمام گره‌هاي قابل دسترسي از هر گره علامت‌گذاري شده اوليه انجام مي‌گيرد. اجتماع آخرين گره‌هاي علامت نخورده در كل سيستم خط بازيافت را تشكيل مي‌دهد كه در شکل 3-6 قسمت (b) مشخص شده است. روش دوم بر اساس گراف نقطه مقابله است[26]. اين گراف شبيه گراف روش اول است، بهجز اينكه وقتي يك پيام از Ii,x فرستاده مي‌شود و توسط Ij,y دريافت مي‌شود، يك يال جهت‌دار از Ci,x-1 به Cj,y كشيده مي‌شود (بهجاي Ci,x به Cj,x) كه در شکل 3-6 قسمت (c) نشان داده شده است. در اين روش براي پيدا كردن خط بازيافت، در ابتدا دو گروه و يال‌هاي مربوط به آنها كه حالت پروسه‌هاي خراب را نشان مي‌دهد از بين مي‌روند و سپس الگوريتم انتشار بازگشت به عقب [26] روي گراف اعمال مي‌شود. نتايج به‌دست آمده در هر دو روش يكسان خواهد بود. اين تكنيك‌ها روش‌هاي پايه جمع‌آوري اطلاعات زائد را شكل مي‌دهند كه در آن‌ها آخرين خط بازيافت به‌دست مي‌آيد و بنابراين نقطه مقابله‌ها قبل از آن زائد مي‌باشند و مي‌توانند از بين بروند [26]. در نهايت نشان داده شده است كه با نقطه مقابله گرفتن به صورت مستقل، حداكثر تعداد نقطه مقابله‌هاي مفيد كه بايد روي ذخيره‌ساز پايدار نگهداري مي‌شوند نمي‌تواند از بيشتر شود [28]. شکل STYLEREF 1 \s ‏3 SEQ شکل \* ARABIC \s 1 6 (a) يك اجراي مثال (b) گراف وابستگي بازگشت به عقب (c) گراف نقطه مقابله اثر دومينو عيب بزرگ نقطه مقابله گرفتن به صورت مستقل و غير هماهنگ با ديگر پروسه‌ها، اثر دومينو مي‌باشد. براي مثال، در شکل 3-7 يك اجرا از سه پروسه و نقاط نقطه مقابله آنها نشان داده شده است. نقطه مقابله‌ها به صورت مستقل از يكديگر بدست آمده‌اند. فرض كنيد پروسه P2 خراب شود و مجبور به بازگشت به نقطه مقابله با شمارة C شود. اين عمل باعث غيرمعتبر شدن ارسال پيام m6 مي‌شود و بنابراين پروسه P1 بايد به نقطه مقابله شمارة B برگردد و اين كار باعث غيرمعتبر شدن پيام m7 و بازگشت پروسه P0 به نقطه مقابله شمارة A مي‌شود. اين بازگشت‌هاي پشت سرهم كه باعث برگشت سيستم به حالت اوليه مي‌شود، همان اثر دومينو است كه در اثر آن قسمت زيادي از كارهاي مفيد سيستم از بين مي‌رود. شکل STYLEREF 1 \s ‏3 SEQ شکل \* ARABIC \s 1 7 انتشار بازگشت به عقب، خط بازيافت و اثر دومينو نقطه مقابله گرفتن به صورت هماهنگ بررسي ديدگاه در اين روش پروسه‌ها بايد با هماهنگي يكديگر در نقطه مقابله گرفتن يك حالت سراسري يكپارچه را ايجاد نمايند. اين روش باعث ساده شدن عمل بازيافت و رفع اثر دومينو خواهد شد، زيرا پروسه‌ها هميشه از آخرين نقطه مقابله مي‌توانند دوباره اجرا گردند. همچنين در نقطه مقابله‌ گرفتن هماهنگ هر پروسه نياز به داشتن فقط يك نقطه مقابله در ذخيره‌ساز پايدار دارد و بنابراين سربار ذخيره‌سازي كاهش مي‌يابد و ديگري نياز به استفاده از روش‌هاي جمع‌آوري اطلاعات زائد نيست. اما از آنجاييكه يك نقطه مقابله سراسري بايد قبل از ارسال پيام به OWP انجام گيرد، عيب اصلي اين روش، تأخير زياد است كه شامل ارسال به خروجي نيز مي‌باشد. يك راه ساده براي نقطه مقابله گرفتن به صورت هماهنگ، ارتباطات بلوكه در زمان اجراي قراردادهاي نقطه مقابله گرفتن است [29]. هماهنگ‌كننده يك نقطه مقابله مي‌گيرد و يك پيام درخواست را براي همه ارسال مي‌كند و از آنها درخواست مي‌كند كه يك نقطه مقابله بگيرند. وقتي يك پروسه اين پيام را دريافت مي‌كند، اجراي خود را متوقف مي‌كند، همه كانال‌هاي ارتباطي را پاك مي‌كند و يك نقطه مقابله آزمايشي مي‌گيرد و يك پيام تصديق براي هماهنگ‌كننده ارسال مي‌نمايد. بعد از اينكه هماهنگ‌كننده از همه پروسهها پيام تصديق را دريافت كرد پيام تكميل، نقطه مقابله قديمي را از بين مي‌برد و نقطه مقابله آزمايشي را بهجاي آن قرار مي‌دهد. اين كار به صورت اتميك انجام مي‌گيرد. در اين حالت پروسه مي‌تواند اجراي خود را از سر بگيرد و با پروسه‌هاي ديگر ارتباط برقرار كند. اين روش ساده داراي سربار زيادي است و بنابراين روش گرفتن نقطه مقابله به صورت غير بلوكه شونده ترجيح داده مي‌شود [30]. نقطه مقابله گرفتن به صورت هماهنگ و غير بلوكه شونده يك مسئله اساسي در گرفتن نقطه مقابله‌ هماهنگ‌، جلوگيري از دريافت پيام توسط پروسه است كه باعث غير يكپارچه شدن نقطه مقابله مي‌شود براي مثال شکل 3-8 قسمت (a) را ملاحظه كنيد كه پيام m بعد از دريافت درخواست نقطه مقابله از هماهنگ‌كننده توسط P0 ارسال مي‌شود. حال اگر فرض كنيم كه پيام m قبل از گرفتن نقطه مقابله توسط پروسه P1 دريافت شود، نتيجه يك نقطه مقابله يكپارچه خواهد شد زيرا، C1,x نشان مي‌دهد كه يك پيام از P0 به P1 ارسال شده است اما C0,x اين ارسال را شامل نمي‌شود. اگر كانال‌ها به صورت FIFO باشد اين مسئله حل خواهد شد. زيرا درخواست نقطه مقابله زودتر وارد كانال شده است و بنابراين در اين مثال قبل از پيام m به پروسه P1 مي‌رسد كه در قسمت ((b مشخص شده است. شکل STYLEREF 1 \s ‏3 SEQ شکل \* ARABIC \s 1 8 نقطه مقابله گرفتن به صورت هماهنگ و غيربلوكه شونده (a) غيريكپارچگي نقطه مقابله (b) با كانال FIFO (c) با كانال غيرFIFO يك مثال از قرارداد نقطه مقابله هماهنگ به صورت غيربلوكه شونده استفاده از اين ايده در تصوير لحظه‌اي توزيع شده است [17] كه در آن نشانه‌ها نقش پيام‌هاي درخواست نقطه مقابله را ايفا مي‌كنند. در اين قرار داد، هماهنگ‌كننده يك نقطه مقابله مي‌گيرد و يك نشانه (يك درخواست نقطه مقابله) را براي همه پروسه‌ها ارسال مي‌كند. هر پروسه با دريافت اولين نشانه‌ يك نقطه مقابله مي‌گيرد و نشانه دريافتي را قبل از ارسال هرگونه پيامي به همه پروسه‌ها مي‌فرستد. اين قرارداد فرض مي‌كند كه كانال‌ها به صورت FIFO و قابل اطمينان عمل مي‌كنند. اگر كانال‌ها به صورت FIFO نباشد، نشانه مي‌تواند روي پيام‌هاي بعد از نقطه مقابله سوار شوند كه در شکل 3-8 قسمت((c مشخص شده است. نقطه مقابله گرفتن با كلاك همگام شده كلاك همگام شده مي‌تواند عمل نقطه مقابله گرفتن هماهنگ را راحت‌تر انجام دهد [31]. در اين حالت بدون استفاده از هماهنگ‌كننده و با استفاده از يك كلاك همگام همه پروسه‌هاي درگير در پردازش در زمان تقريباً مساوي عمل نقطه مقابله گرفتن را انجام مي‌دهند. هر پروسه يك نقطه مقابله مي‌گيرد و براي يك زماني منتظر مي‌ماند كه اين زمان برابر مجموع حداكثر فاصله زماني بين كلاك‌ها و حداكثر زمان براي تشخيص يك اشکال در پروسة ديگر سيستم مي‌باشد. پروسه مي‌تواند مطمئن باشد كه بدون مبادله پيام با ديگر پروسه‌ها مي‌تواند نقطه مقابله‌هاي يكپارچه سيستم را به‌دست آورد. نقطه مقابله گرفتن و قابليت اطمينان ارتباطات وابسته به فرض قابليت اطمينان كانال ارتباطي، قرارداد ممكن است بعضي از پيام‌ها را بهعنوان قسمتي از نقطه مقابله ذخيره كند. حالتي را فرض كنيد كه كانال‌ به صورت قابل اطمينان باشد. فرض كنيد پروسه p قبل از نقطه مقابله گرفتن پيام m را ارسال مي‌كند و پروسه q بعد از نقطه مقابله گرفتن آن را دريافت كند. در اين جا، حالت پروسه p نشان‌دهنده ارسال پيام است در حالي كه حالت پروسه q اين موضوع را نشان نمي‌دهد. اگر يك اشکال باعث بازگشت p و q به نقطه مقابله‌ها شود، تحويل پيام m به صورت قابل اطمينان تضمين نخواهد شد. براي رفع اين مشكل، قراردادها بايد همة پيام‌هاي در حال گذر را بهعنوان قسمتي از حالت خود ثبت نمايند. اما اگركانال‌ها به صورت قابل اطمينان فرض نشوند، نياز به ذخيره‌شدن پيام‌هاي در حال گذر نيست، در اين حالت اگر اشکالی اتفاق بيفتد و پيام m گم شود مانند مشكلي است كه در اثر گم شدن m بهدليل قابل اطمينان نبودن كانال ارتباطي بهوجود مي‌آيد. حداقل‌سازي نقطه مقابله گرفتن هماهنگ نقطه مقابله گرفتن به صورت هماهنگ نيازمند مشاركت همه پروسه‌ها مي‌باشد. بنابراين مسئله مقياس‌پذيري اين روش ممكن است با مشكل مواجه شود. مطلوب‌ ما اين است كه تعداد پروسه‌هاي كمتري در عمل نقطه مقابله مشاركت كنند. اين كار قابل انجام است زيرا پروسه‌هايي نياز به نقطه مقابله گرفتن جديد دارند كه از آخرين نقطه مقابله به صورت مستقيم يا غيرمستقيم با هماهنگ‌كننده نقطه مقابله ارتباط داشته‌اند[32]. قرارداد دو فاز كه در ادامه آمده است براي حداقل‌سازي نقطه مقابله هماهنگ استفاده مي‌شود[32]. در زمان اولين فاز، هماهنگ‌كننده نقطه مقابله تمام پروسه‌هايي كه از آخرين نقطه مقابله ارتباط داشته‌اند را شناسايي مي‌كند و يك درخواست به آنها ارسال مي‌كند. وقتي پروسه پيام درخواست را دريافت مي‌كند، همة پروسه‌هايي كه با آنها از آخرين نقطه مقابله ارتباط داشته است را شناسايي كرده و سپس يك درخواست به آن‌ها مي‌فرستند و اين كار ادامه پيدا مي‌كند. در هنگام فاز دوم، همه پروسه‌هايي كه در فاز اول شناسايي شده‌اند يك نقطه مقابله مي‌گيرند، نتيجه يك نقطه مقابله سراسري است كه فقط پروسه‌هاي شركت‌كننده در آن هستند. در اين قرارداد، بعد از اينكه يك پروسه نقطه مقابله مي‌گيرد، تا پايان كامل فاز دوم نمي‌تواند هيچ پيامي را ارسال كند. البته در اين فاز مي‌تواند بعد از نقطه مقابله گرفتن پيامي دريافت نمايد. نقطه مقابله گرفتن بر اساس ارتباطات بررسي ديدگاه اين نوع قراردادها اثر دومينو را بدون نياز به هماهنگ‌كردن همة نقطه مقابلهها از بين مي‌برد. در اين قراردادها از پروسه‌ها دو نوع نقطه مقابله، محلي و اجباري گرفته مي‌شود. نقطه مقابله‌هاي محلي به صورت مستقل گرفته مي‌شوند، اما نقطه مقابله‌هاي اجباري براي بدست آمدن مجموعة نقطه مقابله براي خط بازيافت گرفته مي‌شوند. در واقع در اين روش با نقطه مقابله گرفتنهاي اجباري از ايجاد نقطه مقابلههای بدون استفاده جلوگيري مي‌شود. (مثل C2,2 در شکل 3-9). اين نوع نقطه مقابله‌ها فقط باعث سربار و مصرف منابع مي‌شوند. برخلاف قراردادهاي نقطه مقابله‌ گرفتن هماهنگ، در اين روش پروسه‌ها نيازي به مبادله پيام براي هماهنگي و نقطه مقابله گرفتن ندارند. بهجاي آن، اطلاعات مربوط به قرارداد روي پيام‌هاي ارسالي بين پروسه‌ها سوار و منتقل مي‌شود. اين اطلاعات درگيرنده براي نقطه مقابله گرفتن اجباري مورد استفاده قرار مي‌گيرد. بنابراين در هر پروسه يك تصميم‌گيري در مورد نقطه مقابله گرفتن اجباري انجام مي‌شود. اين تصميم بر اساس ارتباطات قبلي گيرنده و الگوهاي نقطه مقابله است كه مي‌تواند يك نقطه مقابله بدون استفاده را حاصل كند يا خير. اين عمل مي‌تواند در يك تئوري بر اساس مسير Z و سيكل Z بيان شود. شکل STYLEREF 1 \s ‏3 SEQ شکل \* ARABIC \s 1 9 مسير Z سيكل Z مسيرZ- (مسير زيگ‌زاگ) يك دنباله از پيام‌ها است كه دو نقطه مقابله را به هم متصل مي‌كند [33]. فرض كنيد نشان‌دهنده رابطة رويداد قبل لمپورت باشد[34]. فرض كنيد Ci,x، نقطه مقابله‌ شمارة x از پرسة Pi باشد. اگر دو نقطه مقابله Ci,x و Cj,y را در نظر بگيريم، يك مسيرZ- بين Ci,x و Cj,y وجود دارد اگر و فقط اگر يكي از دو شرط زير برقرار گردد: x=specifity)result = HostStatus.FAULTY;elseresult = HostStatus.LIVE;if(nextState!=HostStatus.LIVE)if(threshold>=sensitivity)result = HostStatus.LIVE;elseresult = HostStatus.FAULTY;return result;} شکل STYLEREF 1 \s ‏6 SEQ شکل \* ARABIC \s 1 6 تکه کد پیش‌بینی وضعیت یک گره محاسباتی در زمان آینده time FTHost یک میزبان با قابلیت تحمل‌پذیری اشکال FTHost نام دارد. این میزبان مشتقی از میزبان شبیه‌ساز اصلی است که تغییراتی در آن اعمال شده است. مشخصه‌های اضافه شده به این کلاس عبارتند از hostStatus: وضعیت جاری گره مذکور؛ predictedStatus: وضعیت آینده پیش‌بینی شده گره مذکور؛ lastFailTime: آخرین زمان خرابی گره؛ FailureTimes: تعداد دفعاتی که گره خراب شده است. از lastFailTime و FailureTimes برای کمک در انتخاب مکان مناسب در تعیین مقصد مهاجرت استفاده می‌شود. FTDatacenter موجودیتی مشتق شده از Datacenter با قابلیت تحمل‌پذیری اشکال را FTDatacenter می‌نامیم. این موجودیت شامل لیستی از FTHost‌ها می‌باشد. به علاوه، همانطور که توضیح داده شد، تزریق کننده اشکال (FaultInjector) در هنگام تغییر وضعیت هر میزبان به این موجودیت رویدادهای ارسال می‌نماید. این رویدادها عبارتند از FAULT_REQUEST: رویداد تزریق اشکال و تغییر وضعیت به خرابی گره، LIVE_REQUEST: رویداد بازگشت یک میزبان به وضعیت سالم، REPAIR_REQUEST: رویداد تغییر وضعیت به حالت تعمیر یک گره. پس از آنکه یک رویداد بازگشت به سیستم گره خراب شده به مرکز داده ارسال شد، این شرایط جدید به اطلاع کارگزار ابر می‌رسد تا در صورت تمایل الگوریتم بهینه سازی نگاشت ماشین‌های مجازی بر روی گره‌های محاسباتی را اجرا نماید. همچنین آخرین زمان خرابی میزبان نیز بهروز می‌شود و به تعداد خرابی‌های آن هم یکی اضافه می‌گردد FTDatacenterBroker به کارگزار با قابلیت تحمل‌پذیری اشکال که از موجودیت DatacenterBroker مشتق شده است، اطلاق می‌گردد. . اطلاعات مربوط کارها، ماشین‌های مجازی و‌هاست‌ها به آن ارسال می‌گردد و این ماشین بر اساس الگوریتم‌های خود، کارها را بین ماشین‌های مجازی تخصیص می‌دهد. در این قسمت بر آن داشته‌ایم تا قابلیت تحمل‌پذیری اشکال را به آن اضافه کنیم و سامانه مدیریت تطبیقی خود را در آن اعمال نماییم. چنانچه بر روی یک گره خراب، حداقل یک ماشین مجازی قرار گرفته شده باشد که کاری برای انجام دارد، سیستم باید پس از کشف اشکال، بازیابی انجام شود وماشین‌های مجازی به آخرین حالت رزو شده خود بر گردند. در طرف مقابل، اگر بر روی یک گره، کاری در حال اجرا قرار نگرفته شده باشد، سیستم به روند کلی خود ادامه داده، و آن میزبان را تا زمان برگشت به وضعیت LIVE از لیست گره‌های خود خارج می‌نماید. بنابراین، هر گاه یک رویداد خرابی یک گره محاسباتی از مرکز داده به کارگزاری اطلاع داده شود یکی از دو حالت ممکن است رخ دهد. Roll-backing: کاری در حال اجرا بر روی گره محاسباتی خراب شده وجود دارد، پس سیستم تا زمان درست شدن گره مورد نظر منتظر می‌ماند، سپس یک به آخرین وضعیت ماشین مجازی نگه داشته شده بر می‌گردد. ماشین‌های مجازی بر روی گره‌های دیگر نیز تا برگشت این گره به حالت توقف نگه داشته می‌شوند. Non- Roll-backing: کاری بر روی گره محاسباتی خراب شده وجود ندارد و سیستم به روند کلی اجرای برنامه‌های خود ادامه می‌دهد و میزبان مورد نظر را تا بر گشت به سیستم از لیست‌ گره‌های خود خارج می‌نماید. الگوریتم کلاسیک این قسمت برای آن طراحی شده است تا بتوان نتایج کارآیی الگوریتم تطبیقی پیشنهادی را با روش کلاسیک بهتر مقایسه کرد. برای این منظور باید در هر نقطه تصمیم‌گیری عمل نقطه مقابله گرفتن انجام شود. اگر وضعیت یک گره کاری در حال انجام دارد تعمیر یا خرابی بود کل سیستم متوقف می‌گردد. بدین معنی که سیستم برای اشکال یک گره نیز باید متوقف شود. این توقف به اندازه زمان تعمیری که تزریق کننده اشکال تعیین می‌کند صورت می‌پذیرد. الگوریتم پیشنهادی اولیه این الگوریتم به صورت تطبیقی انجام می‌شود. در ابتدای هر بازه تصمیم گیری چنانچه یک تصمیم برای انجام آزمون نقطه مقابله‌گیری وجود داشت. کارگزار به مرکز داده مربوطه دستور CHECKPOINT__REQUEST صادر می‌کند. این رویداد سبب می‌شود یا تمام کارهای روی ماشین‌های مجازی مرکز داده متوقف شده و به حالت نقطه مقابله‌گیری بروند. پس از ذخیره حالت جاری خود به کارگزار پیامی ‌مبنی بر تصدیق عمل صادر می‌کنند. چنانچه تمام ماشین‌ها با موفقیت این عمل را انجام دهند و پیام‌های تصدیق به کارگزار ارسال شود، کارگزار به مرکز داده پیام RESUME ارسال می‌نماید. با دریافت این رویداد از طرف مرکز داده، تمام ماشین‌های مجازی منتسب به آن روند اجرای برنامه را از سر می‌گیرند. چنانچه در ابتدای یک بازه، ماشین‌های مجازی یک گره محاسباتی، درخواست مهاجرت را پیشنهاد دهند کارگزار پیام تصدیق این عمل را به مرکز داده صادر می‌نماید. همچنین به همراه این عمل کارگزار بهترین گره مقصد را به مرکز داده ارسال می‌کند. پس از دریافت رویداد MIGRATION_REQUEST مرکز داده ماشین‌های مجازی گره مورد نظر به مقصدهای تعیین شده مهاجرت می‌دهد. لازم به ذکر است با توجه به الگوریتمی که در فصل قبل توضیح داده شد، مقصد ماشین‌های مجازی یک گره می‌تواند با هم متفاوت باشد. همچنین در پیاده‌سازی مهاجرت زنده به اندازه 10% سرعت ماشین مجازی (بر حسب میلیون دستور بر ثانیه) توان محاسباتی گره مبدا افزایش می‌یابد. این مقدار بار اضافی، کاملا با محیط واقعی همخوانی دارد. ماشین‌های مجازی دیگر گره‌های دیگر به روال عادی خود ادامه می‌دهند. چنانچه هیچ پیشنهادی مبنی بر آزمون نقطه مقابله‌گیری یا مهاجرت از طرف کارگزار دریافت نشد، کارگزار پیامی مبنی بر SKIP_REQUEST به مرکز داده مربوطه ارسال می‌کند تا ماشین‌های مجازی آن، بدون نقطه مقابله‌گیری به کار خود ادامه دهند. الگوریتم تصحیح شده روند کاری این روش بسیار شبیه به روند کاری توضیح داده شده مرحله پیشین می‌باشد. همانطور که در نتایج آزمایشات نشان خواهند داد، با زیاد شدن تعداد گره‌های محاسباتی احتمال بر خورد با پیشنهاد نقطه مقابله‌گیری افزایش می‌یابد. در حقیقت پس از گذشت زمان، احتمال آنکه یک ماشین مجازی پیشنهادی مبنی بر نقطه مقابله‌گیری نماید افزایش می‌یابد. علت پیشنهاد این عمل این است که گره محاسباتی منتسب به آن مدت زمانی کار کرده و احتمال خرابی آن زیادتر شده است. دراین روش برای اجتناب از انجام آزمون نقطه مقابله‌گیری زیاد یک حد آستانه تعریف کرده‌ایم. چنانچه تعداد این درخواست‌ها بیشتر از یک مقدار مضخص شد کارگزار درخواست CHECKPOINT_REQUEST را به مرکز داده ارسال می‌نماید. در غیر اینصورت رویداد SKIP_REQUEST به مرکز داده ارسال می‌شود. بعد از بررسی نتایج اولیه اجرای الگوریتم پیشنهادی دریافتیم که بعد از چند پیشنهاد مهاجرت، تعداد گره‌های محاسباتی فعال که برنامه موازی را اجرا می‌کنند به شدت کاهش می‌یابد. برای همین منظور در کارگزار مکانیسمی پیاده‌سازی کردیم که بعد از آنکه تعداد گره‌های سالم غیرفعال از 20% تعداد کل گره‌های سالم افزایش یافت، کارگزار با استفاده از سرویس VMAllocationPolicy استقرار بهینه‌ای برای ماشین‌های مجازی انجام دهد. در حقیقت این مکانیسم سعی می‌نماید تا توزیع بار توان محاسباتی بر روی ابر انجام دهد. معمولا در محیط‌های واقعی از 10% تا 20% گره‌ها به عنوان گره یدکی استفاده می‌نمایند. در سیستمی که ما طراحی کردیم، هیچ گره یدکی وجود ندارد. بنابراین اگر تعداد گره‌های غیرفعال از این مقدار بیشتر شد، توزیع بار انجام می‌دهیم. نتایج آزمایشات در این قسمت به بررسی و تحلیل نتایج شبیه‌سازی می‌پردازیم. متغیر‌های شبیه‌ساز طراحی شده را به صورت جدول 6-1 مقداردهی اولیه می‌کنیم. فرض کنید هر گره محاسباتی دارای قدرت محاسباتی 10000 میلیون دستور در هر ثانیه باشد و تعداد 10 عدد ماشین مجازی بر روی هر گره موجود باشد. هر ماشین مجازی قادر خواهد بود حداکثر 1000 میلیون دستور را در یک ثانیه اجرا کند. تعداد گره‌های موجود در این آزمایشات 8، 16، 32، 64 و 128عدد می‌باشد. کارهای وارد شده به سیستم ابر با توزیع یکنواخت10000000 تا 50000000 میلیون دستور، و میانگین 20 کار در هر ساعت وارد سیستم می‌شود. سیستم ابر را برای 100 روز شبیه‌سازی کرده‌ایم زیرا در ساعات و روزهای اولیه سیستم تازه شروع به کار کرده و احتمال برخورد با اشکال آن بسیار پایین می‌باشد. بعد از گذشت زمان حدود MTTF، میزبان‌ها کم کم شروع به خراب شدن می‌کنند و بنابراین سیستم از مرحله Warm Up عبور کرده، پایدار شده است. جدول STYLEREF 1 \s ‏6 SEQ جدول \* ARABIC \s 1 1 مقداردهی اولیه متغیرهای شبیهسازمقداردهینام متغیر15 روزMTTF400 دقیقهMTTR2 دقیقهcpOverhead1 دقیقهmigOverhead(0.8,0.8)(sens,spec) یادآور میشویم که طول بازه زمانی تصمیم‌گیری را با توجه به [90]، 2×cpOverhead×MTTFTotal در نظر می‌گیریم که حالت بهینه در عمل نقطه مقابله گرفتن هماهنگ دوره‌ای است. برای راحتی مقایسه زمان اجرای برنامه (درصد) بهبود زمان اجرای برنامه را به صورت اجرا زمان بهبود=tcp-tptcp×100 تعریف می‌نماییم که در آن tp را زمان اجرای کارها با الگوریتم پشنهادی و tcp با الگوریتم کلاسیک آزمون نقطه مقابلهگیری دوره‌ای است. REF _Ref347022660 \h \* MERGEFORMAT شکل ‏67 درصد بهبود زمان اجرای الگوریتم‌های پیشنهادی نسبت به الگوریتم آزمون نقطه مقابله‌گیری دوره‌ای کلاسیک را نشان می‌دهد. همانطور که مشاهده می‌کنیم الگوریتم تصحیح شده از زمان اجرای بهتری نسبت به الگوریتم پیشنهادی اولیه بر خوردار است. با اضافه شدن تعداد گره‌ها به سیستم ابر مشاهده می‌نماییم که بهبود این زمان بهتر می‌شود. علت اصلی آن این است که سیستم با احتمال بیشتری با اشکال مواجه می‌شود چراکه تعداد گره‌های رابطه نمایی با کم شدن MTTF کلی سیستم دارد. پس از گذشت زمان قابل ملاحظه‌ای از اجرای برنامه، گره‌ها با فرکانس بسیار بالایی خراب می‌شوند و مجال برای ادامه روند اجرای برنامه به الگوریتم کلاسیک نمی‌دهند. حال آنکه الگوریتم‌های پیشنهادی در صورت پیش‌بینی اشکال قبل از وقوع آن و مهاجرت ماشین‌های مجازی به گره‌های سالمی که احتمال برخورد با اشکال آن‌ها کم‌تر است سبب می‌شوند سیستم متوقف نشده و به روال معمول اجرای برنامه‌های خود ادامه دهد. شکل STYLEREF 1 \s ‏6 SEQ شکل \* ARABIC \s 1 7 در صد بهبود زمان اجرای الگوریتم‌های پیشنهادی نسبت به الگوریتم آزمون نقطه مقابله‌گیری دوره‌ای کلاسیک بررسی اثر سربار نقطه مقابله‌گیری یکی از مزایایی که الگوریتم‌های پیشنهادی نسبت به الگوریتم کلاسیک داراست، کم کردن تعداد آزمون نقطه مقابله‌گیری‌ها در شرایطی است که گره‌ها سالم هستند و احتمال برخورد با خرابی در آن‌ها بسیار کم می‌باشد. در این قسمت سعی داریم تا با اضافه کردن زمان آزمون نقطه مقابله‌گیری اثر اجرای عمل اجرای بلافاصل برنامه در الگوریتم‌های پیشنهادی را نسبت به الگوریتم کلاسیک مورد بررسی قرار دهیم. برای این منظور زمان نقطه مقابله‌گیری را به 5 دقیقه افزایش داده و سیستم را مجددا مورد ارزیابی قرار می‌دهیم. همانطور که در REF _Ref347024424 \h \* MERGEFORMAT شکل ‏68 قابل مشاهده است بهبود زمان اجرا نسبت به حالت قبل بهتر شده است. به عبار ت دیگر، جلوگیری از انجام نقطه مقابله‌گیری اضافی سبب شده است تا سیستم با راندمان بهتری به کار خود ادامه دهد. همچنین اختلاف بهبود زمان اجرا الگوریتم پیشنهادی اولیه و تصحیح شده با افرایش تعداد گره‌ها بیشتر می‌شود. علت بیشتر شدن این اختلاف این است که احتمال آنکه یک ماشین مجازی تصمیم آزمون نقطه مقابله‌گیری را با کارگزار ابر پیشنهاد دهد بیشتر است. بنابراین ماشین‌های مجازی محتاطانه‌تر برخورد می‌نمایند و بیشتر عمل آزمون نقطه مقابله‌گیری را انتخاب می‌نمایند. نتیجتا درخواست این عمل بالاتر می‌رود. نکته دیگری که از مقایسه این شکل با REF _Ref347022660 \h \* MERGEFORMAT شکل ‏67 می‌توان دریافت کرد این است که بیشتر بهبود زمان اجرا نسبت به الگوریتم دوره‌ای به سبب مهاجرت ماشین‌های مجازی قبل از رویداد خرابی در گره محاسباتیشان است. در حقیقت سهم کشف اشکال و پیشگیری از عدم برخورد با آن بیشتر از اجتناب از گرفتن نقطه مقابله‌گیری‌های اضافه است. شکل STYLEREF 1 \s ‏6 SEQ شکل \* ARABIC \s 1 8 در صد بهبود زمان اجرای الگوریتم‌های پیشنهادی نسبت به الگوریتم آزمون نقطه مقابله‌گیری دوره‌ای کلاسیک با افزایش زمان نقطه مقابله‌گیری به 5 دقیقه بررسی عمل‌های انتخابی در این قسمت به بررسی عمل‌های انتخابی در سه الگوریتم مقابله با اشکال مطرح شده می‌پردازیم. لازم به یادآوری است که طول بازه‌های و نتیجتا تعداد بازه‌های تصمیم گیری به علت تفاوت در MTTF کلی سیستم با هم اختلاف دارد. به عبارت دیگر افزایش تعداد گره‌ها اثر مستقیمی درکاهش MTTF کلی سیستم می‌گذارد که این امر سبب می‌شود طول بازه تصمیمگیری نیز کاهش یابد. از طرفی افزایش تعداد گره‌های محاسباتی سبب سریع‌تر اجرا شدن کارها می‌گردد. بنابراین به نظر می‌رسد مقایسه دقیق عمل‌های انتخابی در حالت‌هایی که تعداد گره‌ها با هم اختلاف داشته باشند قدری پیچیده باشد. همچنین تعداد مواجهه با خرابی‌های گره‌های محاسباتی نیز در این الگوریتم‌ها با هم متفاوت است. REF _Ref347025799 \h \* MERGEFORMAT شکل ‏69 تعداد عمل‌های انتخابی در طول زمان اجرا با استفاده از الگوریتم نقطه مقابله‌گیری دوره‌ای را نشان می‌دهد. پر واضح است که تنها عملی که انتخاب می‌شود عمل آزمون نقطه مقابله‌گیری می‌باشد. شکل STYLEREF 1 \s ‏6 SEQ شکل \* ARABIC \s 1 9 تعداد عمل‌های انتخابی در طول زمان اجرا با الگوریتم نقطه مقابله‌گیری دوره‌ای علت کاهش تعداد نقطه مقابله‌گیری‌ها با افزایش تعداد گره‌ها، افزایش توان محاسباتی ابر و همچنین کاهش احتمال برخورد با خرابی در روز‌های نخستین شروع به کار سیستم می‌باشد. شکل STYLEREF 1 \s ‏6 SEQ شکل \* ARABIC \s 1 10 تعداد عمل‌های انتخابی در طول زمان اجرا با الگوریتم تطبیقی اولیه حال به بررسی تعداد عمل‌های انتخابی در الگوریتم‌های پیشنهادی می‌پردازیم. REF _Ref347026414 \h \* MERGEFORMAT شکل ‏610 تعداد عمل‌های انتخابی در الگوریتم پیشنهادی اولیه را نشان می‌دهد. اختلاف کم مجموع تعداد عمل‌های انتخابی متناظر با همین تعداد در الگوریتم کلاسیک نسبت به بهبود زمان اجرای توضیح داده شده این است که الگوریتم کلاسیک زمان بیشتری را در حالت توقف به سر برده است. چراکه در صورت بروز اشکال مجبور بوده که توقف کند تا اشکال بر طرف شود (در ادامه به تفصیل در این باره بحث خواهیم کرد). شکل STYLEREF 1 \s ‏6 SEQ شکل \* ARABIC \s 1 11 تعداد عمل‌های انتخابی در طول زمان اجرا با الگوریتم تطبیقی تصحیح شده REF _Ref347026858 \h \* MERGEFORMAT شکل ‏611 تعداد عمل‌های انتخابی با استفاده از الگوریتم پیشنهادی تصحیح شده را نشان می‌دهد. با مقایسه این دو الگوریتم خواهیم دید که تعداد استفاده از عمل اجرای بلافاصل به طرز فوق العاده‌ای بیشتر شده است. از طرف دیگر تعداد انتخاب عمل محتاطانه آزمون نقطه مقابله‌گیری کمتر شده است. لازم به ذکر است تعداد عملیات‌های مهاجرت در REF _Ref347026858 \h \* MERGEFORMAT شکل ‏611، تنها به تصمیم گیری بوده و تعداد عملیات‌های مهاجرت بهینه سازی استقرار ماشین‌های مجازی در آن لحاظ نشده است. خرابی‌های متوقف سازنده و غیر متوقف سازنده در این بخش به بحث در مورد تعداد اشکال‌هایی که پیش‌بینی شده و به درستی الگوریتم‌های پیشنهادی آن را با مهاجرت تصحیح رد کرده‌اند می‌پردازیم. اشکال‌هایی که سبب توقف سیستم می‌گردند را متوقف شونده و اشکال‌هایی که در طول زمان اجرا برنامه اتفاق می‌افتند اما سیستم نیازی به برگشت به عقب و توقف ندارد غیرمتوقف شونده می‌نامیم. همانطور که در قبل توضیح داده شد، اثر اشکال‌هایی که به درستی پیش‌بینی می‌شوند و گره مشکوک را از حالت فعال به غیرفعال تبدیل می‌کنیم، نقش به سزایی در کاهش زمان اجرای برنامه‌های موازی و در نتیجه افزایش راندمان ابر دارند. شکل STYLEREF 1 \s ‏6 SEQ شکل \* ARABIC \s 1 12 تعداد اشکال‌هایی که در طول اجرای برنامه سبب توقف یا عدم توقف ابر می‌شوند همانطور که در REF _Ref347027730 \h \* MERGEFORMAT شکل ‏612 قابل مشاهده است، تمام اشکال‌هایی که با استفاده از الگوریتم دوره‌ای کلاسیک رخ می‌دهند، سبب توقف سیستم می‌شوند. حال آنکه این اشکال‌ها در الگوریتم‌های پیشنهادی بعضا می‌توانند سبب عدم توقف اجرای کار ابر شوند. همچنین کاهش تعداد اشکال‌ها ( اعم از متوقف شونده یا غیر متوقف شونده) در الگوریتم‌های پیشنهادی، سریع‌تر به اتمام رسیدن کارهای موازی می‌باشد. به عبارت دیگر چون الگوریتم‌های پیشنهادی زودتر کارها را اجرا می‌نمایند، مواجهه با اشکال‌های گره‌های محاسباتی در آن‌ها کاهش می‌یابد. نکته دیگر این است که افزایش تعداد گره‌های محاسباتی سبب کاهش زمان اجرای برنامه‌های موازی می‌شود. در نتیجه، مواجه شدن با اشکال در این حالات به مراتب نسبت به تعداد گره‌های کمتر، کاهش می‌یابد. فصل هفتم نتیجه گیری و پیشنهادات نتیجهگیری و پیشنهادات در این پایاننامه پس از مطالعه دقیق روشهای کلاسیک در تحملپذیری اشکال، الگوریتمی تطبیقی مبتنی بر پیشبینی اشکال با استفاده از مدلهای هزینه احتمالی را ارائه دادیم. در نتایج به دست آمده شاهد بهبود بسیار خوبی در زمان اجرای برنامههای موازی بودیم و اثر پارامترهای مختلف الگوریتم و محیطی را روی آن بررسی نمودیم. این الگوریتم کاملا به نتیجه پیشبینیکننده اعتماد نمیکند و در انتخاب عمل پیشنهادی هزینههای پیشبینی اشتباهات محتمل را نیز در نظر میگیرد. یکی از مزایای این الگوریتم توزیعی بودن آن است که موجب میشود تا سربار زیادی به کارگزار ابر تحمیل نشود. کارهایی که در آینده در راستای این مطالعه مفید به نظر میرسد عبارتند از ارائه مدل‌های هزینه بهتر؛ بررسی دقیق ارتباط تحمل‌پذیری اشکال و نحوه تخصیص ماشینهای مجازی به گرهها در بهبود زمان اجرای برنامه؛ ارائه الگوریتم پیشبینی متغیر با زمان؛ تخمین لحظهای پارامترهای پیشبینی و متوسط زمان تا خرابی بعدی؛ پیادهسازی الگوریتم‌های تطبیقی مشابه بر روی متدهای دیگر تحمل‌پذیر اشکال و بررسی بهبود زمان اجرا در آنها؛ استفاده از رویدادهای محیطی در کشف اشکال‌های محتمل سیستم؛ پیدا کردن حد آستانه بهینه برای نقطه مقابله گرفتن. منابع Google Trends, http://www.google.com/trends?q=Grid+Computing%2C+vitualization%2C+Cloud+computing. Sriram, Ilango, Ali Khajeh-Hosseini, "Research agenda in cloud technologies." CoRR, 1001.3259 (2010). R. K. Sahoo, A. Oliner, I. Rish, M. Gupta, J. E. Moreira, S. Ma, R. Vilalta, A. Sivasubramaniam, "Critical Event Prediction for Proactive Management in Large-Scale Computer Clusters", KDD’03, PP 426-435, August 2003. A. B. Nagarajan, F. Mueller, C. Engelmann, S. L. Scott, "Proactive Fault tolerance for HPC with Xen virtualization", ICS’07, PP 23-32, Seattle, WA, USA, June 2007. Duda, "The Effects of Checkpointing on Program Execution Time", Information Processing Letters, Vol. 16, No. 5, PP 221-229, June 1983. A. Oliner, R. K. Sahoo, J. E. Moreira, M. Gupta, "Performance Implications of periodic Checkpointing on Large-Scale Cluster Systems", IPDPS’05, April 2005. P. Lemarinier, A. Bouteiller, G. Krawezik, F. Cappello, "Coordinated Checkpoint versus Message Logging for Fault Tolerance MPI", International Journal of High Performance Computing and Networking, Vol. 2, No. 2/3/4, PP. 146-155, 2004. Health Application Programming Interface (HAPI), http://www.renci.org/software/hapi/. Hardware Monitoring by Lm-Sensors, http://secure.netroedge.com/lm78/info.html. R. Vilalta, S. Ma, "Predicting Rare Events in Temporal Domains Using Associative Classification Rules", Technical Report, IBM Research, T. J. Watson Research Center, Yorktown Heights, Vol. 41, No 3, 2002. P.S. Weygant, "Clusters for High Availability: A Primer of HP Solutions", Hewlett-Parker Company, Packard Company, Prentice Hall, Inc., 2nd ed., 2001. B. Johnson, "Design & Analysis of Fault-Tolerant Digital Systems", Addison-Wesley Longman Publishing Co. Inc, 1989. L. Sherman, "Choosing the Right Availability Solution: High Avaialbility Clusters & Fault Tolerant Systems", White Paper, Stratus Computer Inc., 1998. "Stategies for Fault-Tolerant Computing", Microsoft Corporation, White Paper, 2003. H. Shah, "Fault Tolerance in Cluster Computing Enviroment", CSCI 555 Research Paper Assignment, University of South California, 2002. B. Randell, "System Structure for Software Fault Tolerance", IEEE Trans. Softw. Engin. 1, 2, PP 220–232, 1975. M. Chandy, L. Lamport, "Distributed Snapshots: Determining Global States of Distributed Systems", ACM Trans Comput. Syst. 31, 1, PP 63–75, 1985. D.L. Russell, "State Restoration in Systems of Communicating Processes", IEEE Trans. Softw. Eng., 6, 2, PP 183–194, 1980. R. Strom, S. Yemini, "Optimistic Recovery in Distributed Systems", ACM Trans. Comp. Sys., 3, 3, PP 204–226, 1985. L. Alvisi, "Understanding the Message Logging Paradigm for Masking Process Crashes", Ph.D. Thesis, Cornell university, Department of Computer Science, 1996. E. N. Elnozahy, W. Zwaenepoel, "on the Use and Implementing of Message Passing", In Digest of Papers, FTCS-24, the Twenty Fourth International Symposium on Fault Tolerance Computing, PP 298-307, 1994. R. Pausch, "Adding Input and Output to the Transactional Model", Ph.D. Thesis, Carnegie Mellon University, Department of Computer Science, 1988. D.B. Johnson, W. Zwaenpoe, W. "Recovery in Distributed Systems Using Optimistic Message Logging and Checkpointing", J. Algorithms, 11, 3, PP 462–491, 1990. A. Borg, W.Blau, W. Graetsch, F. Hermann, W. Oberle, "Fault Tolerance under UNIX ", ACM Trans. Comput. Syst., 34, 3, PP 1–24, 1989. B.W. Lampson, H.E. Sturgis, "Crash Recovery in a Distributed Data Storage System", Technical Report, Xerox Palo Alto Research Center, 1979. Y.M. Wang, "Space Reclamation for Uncoordinated Checkpointing in Message-Passing Systems", Ph.D. Thesis, University of Illinois, Department of Computer Science, 1993. B. Bhargava, S.R. Lian, "Independent Checkpointing and Concurrent Rollback for Recovery—an Optimistic Approach", In Proceedings of Seventh Symposium on Reliable Distributed Systems, 3–12, 1988. Y.M. Wang, "Consistent Global Checkpoints that Contain a Set of Local Checkpoints", IEEE Trans. Comp. 46, 4, PP 456–468, 1997. Y. Tamir, C. H. Sequin, "Error Recovery in Multicomputers Using Global Checkpoints", In Proceedings of the International Conference on Parallel Processing, PP 32–41, 1984. E.N. Elnozahy, D.B.Johnson, W.Zwaenepoel, "The Performance of Consistent Checkpointing", In Proceedings of Eleventh Symposium on Reliable Distributed Systems, PP 39–47, 1992. Z. Tong R.Y. Kain, W.T. Tsai, "Rollback Recovery in Distributed Systems Using Loosely Synchronized Clocks", IEEE Trans. Parallel and Distributed Syst., 3, 2, PP 246–251, 1992. R. Koo, S. Toueg, "Checkpointing and Rollback Recovery for Distributed Systems", IEEE Trans. Softw. Eng., 13, 1, PP 23–31, 1987. R.H. Netzer, J. Xu, "Necessary and Sufficient Conditions for Consistent Global Snapshots", IEEE Trans. Parallel and Distributed Syst., 6, 2, PP 165–169, 1995. L. Lamport, "Time, Clocks, and the Ordering of Events in a Distributed System", Com. ACM, 21, 7, PP 588–565, 1978. J.M. Helary, A. Mostefaoui, R.H. Netzer, M. Raynal, "Preventing Useless Checkpoints in Distributed Computations", In Proceedings of Sixteenth Symposium on Reliable Distributed Systems, PP 183–190, 1997. L. Alvisi, E.N. Elnozahy, S. Rao, S.A. Husain, A.D. Mel "An Analysis of Communication-Induced Checkpointing", In Digest of Papers, FTCS-29, The Twenty Nineth Annual International Symposium on Fault-Tolerant Computing (Madison,Wisconsin), PP 242–249, 1999. J.F. Bartlett, "A Non Stop Kernel", In Proceedings of the Eighth ACM Symposium on Operating Systems Principles, PP 22–29, 1981. R. Baldoni, F. Quaglia, B. Ciciani, "AVP-Accordant Checkpointing Protocol Preventing Useless Checkpoints", In Proceedings of Seventeenth Symposium on Reliable Distributed Systems, PP 61–67, 1998. D. Briatico, A. Ciuffoletti, L. Simoncini "A Distributed Domino-Effect Free Recovery Algorithm", In IEEE International Symposium on Reliability, Distributed Software, and Databases, PP 207–215, 1984. J.S. Plank, M. Beck, G. Kingsley, K. Li, "Libckpt: Transparent Checkpointing under UNIX," In Proceedings of the USENIX, PP 213–223, 1995. Y. Huang, Y.M. Wang, "Why Optimistic Message Logging Has not Been Used in Telecommunication Systems", In Digest of Papers, FTCS-25, the Twenty Fifth Annual International Symposium on Fault-Tolerant Computing, PP 459– 463, 1995. J.P. Banatre, M. Banatre, G. Muller, "Ensuring Data Security and Integrity with a Fast Stable Storage", In Proceedings of the Fourth Conference on Data Engineering, PP 285–293. 1988. D.B. Johnson, W. Zwaenpoe, "Sender-Based Message Logging", In Digest of Papers, FTCS-17, the Seventeenth Annual International Symposium on Fault-Tolerant Computing, PP 14–19, 1987. T.Y. Juang, S. Venkatesan, "Crash Recovery with Little Overhead", In Proceedings of the 11th International Conference on Distributed Computing Systems, PP 454–461, 1991. E.N. Elnozahy, "Manetho: Fault Tolerance in Distributed Systems Using Rollback-Recovery and Process Replication", Ph.D. Thesis, Rice University, Department of Computer Science, 1993. A. Sistla, J. Welch, "Efficient Distributed Recovery Using Message Logging", In Proceedings of the 8th Annual ACM Symposium on Principles of Distributed Computing (PODC), PP 223–238, 1989. M. Elnozahy, L. Alvisi, Y. M. Wang, D. B. Johnson, "A Survey of Rollback-Recovery Protocols in Message Passing Systems,” Technical Report CMU-CS-96- 181, School of Comp. Scie., Carnegie Mellon University, Pittsburgh, PA, USA, October 1996. J.S. Plank, "Efficient Checkpointing on MIMD Architectures", Ph.D. Thesis, Princeton University, Department of Computer Science, 1993. C.C. Li, W.K. Fuchs, "CATCH: Compiler Assisted Techniques for Checkpointing", In Digest of Papers, FTCS-20, the Twentieth Annual, International Symposium on Fault-Tolerant Computing, PP 74–81, 1990. M. Chandy, C.V. Ramamoorthy, "Rollback and Recovery Strategies for Computer programs", IEEE Trans. Comp., 21, 6, PP 546–556, 1972. M. Ruffin, "KITLOG: A Generic Logging Service", In Proceedings of Eleventh Symposium on Reliable Distributed Systems, PP 139–148, 1992. L.M. Silva, "Checkpointing Mechanisms for Scientific Parallel Applications", Ph.D. Thesis, University of Coimbra, Department of Computer Science, 1997. S. Rao, L. Alvisi, H.M. Vin, "The Cost of Recovery in Message Logging Protocols", In Proceedings of Seventeenth Symposium on Reliable Distributed Systems, PP 10–18, 1998. G. M. Weiss, H. Hirsh, "Learning to Predict Rare Events in Categorical Time-Series Data", AAAI Workshop, PP 359-363, 1998. G. M. Weiss, H. Hirsh, "Learning to Predict Rare Events in Event Sequences", KDD, 1998. B. Rasndell, "On Failures and Faults", In Formal Methods (FME), vol. 2805, LCNS, PP 18-39, 2003. B. Schroeder, G. Gibson, "A Large Study of Failures in HPC Systems", In Proceedings of International Conf. on Dependable Systems and Networks, June 2006 T. Heath, R. P. Martin, T. D. Nguyen, "Improving Cluster Availability Using Workstation Validation", In Proceedings of ACM SIGMETRICS, 2002. D. Nurmi, J. Brevik, R Wolski, "Modeling Machine Availability in Enterprise and Wide-Area Distributed Computing Environments", In Proceedings of EuroPar’05, August 2005. F. Salfner, S. Tschirpke, M. Malek, "Comprehensive LogFiles for Autonomic Systems", In Proceedings of 9th IEEE Workshop on Fault-Tolerant Parallel Distributed and Network-Centric Systems ,2004. Y. Liang, Y. Zhang, A. Sivasubramaniam, M. Jette, R. Sahoo, "BlueGene/L Failure Analysis and Prediction Models", In Proceedings of IEEE International Conference on Dependable System and Network (DSN '06), PP 425-434, 2006. Y. Liang, Y. Zhang, A. Sivasubramaniam, R. Sahoo, J. Moreira, M. Gupta, "Filtering Failure Logs for a BlueGene/L Prototype", In Proceedings of the International Conference on Dependable Systems and Networks (DSN), 2005. F. A. Nassar, D. M. Andrews, "A Methodology for Analysis of failure Prediction Data", CRC Technical Report No. 85-20, Stanford University, Polo Alto, CA, 1985. B. Zou, Q. Liu, "ARMA-Based Traffic Forecasting and Overload Detection of Network", J. of Comp. Eng., 32, 12, PP 1645-1652, 2004. X. Ren, S. Lee, R. Eigenmann, S. Bagchi, "Resource Failure Prediction in Fine-Grained CycleSharing Systems", In proceedings of the 15th IEEE International Syposium on High Performance Distributed Computing, June 2006 P. Gujrati, Y. Li, Z. Lan, R. Thakur, J. White, "Exploring Meta-Learning to Improve Failure Prediction in Supercomputing Clusters", In Proceedings of ICPP'07, 2007. Z. Lan, Y. Li, "Adaptive Fault Management of Parallel Applications for High Performance Computing", IEEE Trans. on Comp., 57, 12, PP 1647-1660, December 2008. Y. Li, P. Gujrati, Z. Lan, X. Sun, "Fault-Driven Re-Scheduling for Improving System-Level Fault Resilience", ICPP’07, 2007. Y. Li, Z. Lan, P. Gujrati, X. Sun, "Fault-Aware Runtime Strategies for High Performance Computing", IEEE Trans. on Parallel and Distributed Systems, 99, 2, 2008. Y. Li, Z. Lan, "Exploit Failure Prediction for Adaptive Fault-Tolerance in Cluster Computing", CCGrid06, 1, PP 531-538, Singapore, May 2006. A. J. Oliner, L. Rudolph, R. K. Sahoo, "Cooperative Checkpointing Theory", In Proceedings of the International Parallel and Distributed Processing Symposium (IPDPS), Rhodes Island, Greece, April 2006. A. J. Oliner, R. K. Sahoo, J. E. Moreira, M. Gupta, A. Sivasubramaniam, "Fault-Aware Job Scheduling for BlueGene/L Systems", In Proceedings of the International Parallel and Distributed Processing Symposium (IPDPS), Santa Fe, NM, April 2004. Y. Li, Z. Lan, P. Gujrati, X. Sun, "Fault-Aware Runtime Strategies for High Performance Computing", IEEE Trans. on Parallel and Distributed Systems , 20, 4, PP 460-473, 2009. Ganglia, http://ganglia.sourceforge.net/. X. Gu, S. Papadimitriou, P. S. Yu, S. Chang, "Toward Predictive Failure Management for Distributed Stream Processing Systems", IEEE International Conf. on Distributed Computing Systems (ICDCS), Beijing, China, June 2008. X. Gu, S. Papadimitriou, P. S. Yu, S. Chang, "Online Failure Forecast for Fault-Tolerant Data Stream Processing", IEEE International Conf. on Data Eng. (ICDE), Cancun, Mexico, April 2008. H. Jitsumoto, T. Endo, S. Matsuoka, "ABARIS: An Adaptable Fault Detection/Recovery Component Framework for MPIs", 12th IEEE Workshop on Dependable Parallel, Distributed and Network-Centric Systems DPDNS '07, CA, March 2007. MPICH-P4MPD, http://mpich-v.lri.fr/. Egwutuoha, Ifeanyi P., Shiping Chen, David Levy, and Bran Selic. "A Fault Tolerance Framework for High Performance Computing in Cloud." In Cluster, Cloud and Grid Computing (CCGrid), 2012 12th IEEE/ACM International Symposium on, pp. 709-710. IEEE, 2012. Litvinova, Antonina, Christian Engelmann, and Stephen L. Scott. "A proactive fault tolerance framework for high-performance computing." In Proceedings of the 9th IASTED International Conference on Parallel and Distributed Computing and Networks (PDCN), pp. 16-18. 2010. Malik, Sheheryar, and Fabrice Huet. "Adaptive Fault Tolerance in Real Time Cloud Computing." In Services (SERVICES), 2011 IEEE World Congress on, pp. 280-287. IEEE, 2011. Bala, Anju, and Inderveer Chana. "Fault Tolerance-Challenges, Techniques and Implementation in Cloud Computing." IJCSI International Journal of Computer Science Issues 9, no. 1 (2012). Yang, Chao-Tung, Wei-Li Chou, Ching-Hsien Hsu, and Alfredo Cuzzocrea. "On improvement of cloud virtual machine availability with virtualization fault tolerance mechanism." In Cloud Computing Technology and Science (CloudCom), 2011 IEEE Third International Conference on, pp. 122-129. IEEE, 2011. Padhy, Smruti, Diego Kreutz, António Casimiro, and Marcelo Pasin. "Trustworthy and resilient monitoring system for cloud infrastructures." InProceedings of the Workshop on Posters and Demos Track, p. 3. ACM, 2011. Sun, Dawei, Guiran Chang, Changsheng Miao, and Xingwei Wang. "Building a High Serviceability Model by Checkpointing and Replication Strategy in Cloud Computing Environments." In Distributed Computing Systems Workshops (ICDCSW), 2012 32nd International Conference on, pp. 578-587. IEEE, 2012. Zhu, Jun, Zhefu Jiang, Zhen Xiao, and Xiaoming Li. "Optimizing the performance of virtual machine synchronization for fault tolerance." Computers, IEEE Transactions on 60, no. 12 (2011): 1718-1729. Garraghan, Peter, Paul Townend, and Jie Xu. "Real-Time Fault-Tolerance in Federated Cloud Environments." In Object/Component/Service-Oriented Real-Time Distributed Computing Workshops (ISORCW), 2012 15th IEEE International Symposium on, pp. 118-123. IEEE, 2012. M. L. Shooman, "Probabilistic Reliability: An Enineering Approach", McGraw-Hill, NY 1968. D. P. Siewiorek, R. S. Swarz, "The Theory and Practice of Reliable System Design", Digital Press, Bedford, Mass., 1982. J. W. Young, "A First Order Approximation to the Optimal Checkpoint Interval", Comm. ACM, 17, 9, PP 530-531, 1974. Buyya, Rajkumar, Rajiv Ranjan, and Rodrigo N. Calheiros. "Modeling and simulation of scalable Cloud computing environments and the CloudSim toolkit: Challenges and opportunities." In High Performance Computing & Simulation, 2009. HPCS'09. International Conference on, pp. 1-11. IEEE, 2009. Calheiros, Rodrigo N., Rajiv Ranjan, Anton Beloglazov, César AF De Rose, and Rajkumar Buyya. "CloudSim: a toolkit for modeling and simulation of cloud computing environments and evaluation of resource provisioning algorithms."Software: Practice and Experience 41, no. 1 (2011): 23-50. Buyya, Rajkumar, and Manzur Murshed. "Gridsim: A toolkit for the modeling and simulation of distributed resource management and scheduling for grid computing." Concurrency and Computation: Practice and Experience 14, no. 13‐15 (2003): 1175-1220. ABSTRACT Design & Implementation of a Fault-aware Job Scheduler in Cloud Computing Systems BY ROSHANAK LAKISHIRAZ With increasing market to use Cloud computing technology, huge data-centers are existed to execute calculations fast. One of the main challenges in cloud computing is facing to faults when a time-consuming parallel program runs. To overcome this problem, checkpointing or logging techniques are proposed. However, these techniques typically have considerable overheads. Besides, they operate reactively. In this thesis, we propose an approach which more than recovery and rolling back for fault tolerance, can detect the computing nodes that are more likely to experience faults, and migrates their allocated virtual machines into safe computing nodes. Furthermore, using Bayes’ rule and proposed cost models, the algorithm avoid excess checkpointing with purpose of improve time executions of running programs. By simulation, we show that proposed method ameliorate the execution time up to 78% in cases and take advantage of less resource. Keywords: Cloud Computing Systems, Fault Prediction, Cost-Based Model, Bayes’ Rules, Proactive, Coordinated Checkpoint, Migration. Shiraz UniversityFaculty of Engineering Computer Engineering and IT DepartmentMaster of Science ThesisDesign & Implementation of a Fault-aware Job Scheduler in Cloud Computing SystemsBy:Roshanak LakishirazSupervisor:Dr. Farshad KhunjushMarch 2013