CDN ابری

راهکارهای حل Failover | مرجعی کامل + استراتژی های کاربردی

Shahin Noei Shahin Noei
15 بازدید 0 دیدگاه 20 آبان 1401
/storage/post-covers/1667735881_2022-11-06_cloud-servers-370x370.png /storage/post-images/1667735881_2022-11-06_cloud-servers-830x250.png
راهکارهای حل Failover | مرجعی کامل + استراتژی های کاربردی

Failover یک اصطلاح شبکه ای است که در اصل در زمان های از کار افتادگی سرویس، طی یک فرآیند عملیاتی بین سیستم های اولیه و ثانویه یا عناصر آنها (سرور، پردازشگر، شبکه یا دیتابیس) جا به جایی به عمل می آید. این قطعی ها یا downtime ها می توانند به علت اجرای یک عملیات تعمیراتی برنامه ریزی شده و یا از کار افتادگی غیر منتظره یک قطعه سیستمی رخ داده باشد. در هر دو صورت، هدف ایجاد تحمل خطا یا fault tolerance برای اطمینان از در دسترس بودن اپلیکیشن های ضروری بدون توجه به نوع خطا یا شدت آن است. در وسعت بزرگتر، failover یک عنصر حیاتی در برنامه بقای کسب و کارهاست ، بخصوص برای آنهایی که مبتنی بر کامپیوتر هستند.

دسترسی بالا و failover وب سرورها

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

High availability به رویکرد طراحی یک سیستم یا توافقاتی اشاره دارد که از لحاظ عملکردی برای یک کسب و کار سطح عملیاتی از پیش تعریف شده ای را تضمین می کند.

دسترسی بالا برای توصیف فرآیندهای سیستمی مورد استفاده قرار می گیرد که افت یا توقف آنها، تأثیری منفی بر درآمد کسب و کار، رضایت مشتریان، کارایی کارمندان و حتی برند دارد.

 برای حذف دسترسی بالا، در جریان اقدامات بهینه سازی و تعمیرات از پیش برنامه ریزی شده و downtime های غیر منتظره ،

یک کسب و کار آنلاین همیشه باید یک استراتژی مشخص برای بازیابی وب سرور در نظر داشته باشد.

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

البته پیاده سازی این طرح مستمر می تواند هزینه بر و پیچیده باشد؛ به همین دلیل سازمان ها معمولاً هزینه و اهمیت سیستم را در مقابل تأثیر کلی downtime قرار داده و آنها را ارزیابی می کنند، و سپس یکی از سه سطح failover وب سرور زیر را انتخاب می کنند:

  • Cold failover: ساده ترین و در کل کم هزینه ترین رویکردی است که شامل تعمیرات موازی و سیستم های غیرفعال آماده (سیستم های standby) می شود. در صورت از کار افتادن سیستم اصلی، این سیستم های غیرفعال روشن شده، آنلاین می شوند و فرایندهای کاری سرویس را به جریان می اندازند.

نقطه ضعف این استراتژی این است که در این سناریو downtime می تواند حتی به اندازه اندکش ، بر کیفیت سرویس تأثیرگذار باشد. با توجه به هزینه های نگهداری این سیستم ها و sync کردنشان با سرورها، این استراتژی بیشتر برای دیتاسنترها مناسب است.

  • Warm failover: این رویکرد سیستم standby را بهینه تر کرده و با سرعت بیشتری آنها را جایگزین سیستم از کار افتاده می کند. اگرچه ممکن است در صورت وقوع قطعی کاربران برای مدت کوتاهی با لگ هایی رو به رو شوند، ولی warm failover تأثیر منفی بر عملکرد بر سیستم را به حداقل می رساند. در این صورت بقای سرویس و هزینه ها در سطحی قابل قبول باقی می مانند.

همانند cold failover، این استراتژی نیز بیشتر برای دیتاسنترها کارایی دارد چون از لحاظ نگهداری سیستم های جایگزین و sync کردن آنها با سرورهای اختصاصی، ممکن است هزینه ها به صرفه نباشند.

  • Hot failover: این رویکرد در بالاترین سطح پیچیدگی و هزینه ای قرار داشته و آپ تایم را به 100% نزدیک تر می کند. در این سناریو، دو سیستم موازی یا قطعات آنها به طور مستمر و همیشگی در حال فعالیت خواهند بود. هر تولید یا سرویس دهی، یک بک آپ. سیستم بک آپ گیری در این سناریو به طور منظم و مستمر sync شده و آماده جایگزینی در لحظات قطعی است.

یک استراتژی hot failover عموماً برای یک هر سرور به طور مجزا مورد استفاده قرار می گیرد، چراکه هزینه های اجرای این متد برای کل دیتاسنتر می تواند یک عامل بازدارنده باشد، مگر در مواقع بسیار حساس.

تعیین استراتژی failover وب سرور

زمان انتخاب بین انواع استراتژی های failover وب سرور، سازمان ها معمولاً سعی می کنند تا RTO (Recovery time objective) و RPO (Recovery point objective) را محاسبه کنند. با احتساب این دو مقدار، انتخاب بین موثرترین رویکرد برای failover وب سرور آسان تر خواهد شد:

RTO: این معیار مدت زمانی است که از حین آن سرویس باید برای دوری از عواقب غیر قابل قبول، بازیابی یا Restore شود. با محاسبه اینکه بازیابی وب سرور تا چه حد باید سریع باشد، سازمان ها می دانند که چه اقداماتی را باید از قبل آماده کنند.

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

RPO: این معیار، حداکثر مدت زمان قابل تحملی است که داده ها می توانند در دسترس نباشد؛ اساساً RPO تعیین می کند که یک سازمان تا چه اندازه می تواند داده ها را از دست بدهد (یک هفته، یک ساعت، یا یک روز). بر این اساس، تکرار بک آپ و سرعت ریکاوری تعیین می شود که البته در آن سطوح Failover سرور نیز در نظر گرفته می شود.

DNS Failover در برابر Cloud failover

Dns failover جایگزینی برای راهکارهای failover دستگاه محور است که می تواند تضمین دهد که اگر سایت، سرویس یا اتصال اینترنتی آفلاین شود، ترافیک به طور خودکار به سمت یک آدرس IP ، سرور یا ارائه دهنده دیگر هدایت خواهد شد.

راهکارهای DNS Failover عموماً شامل بخش های سلامت سنجی بوده که در دسترس بودن هر موقعیت اپلیکیشن را مداوماً رصد می کنند. در زمان هایی که یک endpoint از کار بیافتد، این راهکارها ترافیک را از نقطه قطع شده دور کرده و آن را به سمت یک یا چند endpoint سالم هدایت می کند؛ معمولاً برای این کار از متد round robin استفاده می شود.

اگرچه راهکارهای DNS failover می توانند برای وب سایت های یا اپلیکیشن های کم ترافیک موثر باشند، اما با وجود محدودیت های حیاتی شان نمی توانند برای موارد بسیار حساس و عظیم کاربرد موثری داشته باشند؛ از آن مهم تر، در یک سناریوی DNS failover نمی توان مشخص کرد که چه درصدی از کاربران همچنان نسخه های کش شده DNS را دریافت خواهند کرد، چون TTL هر کدام می تواند متفاوت باشد.

 

راهکار میزبان کلود

به کمک سرویس DNS ابری و CDN میزبان کلود می توانید از تکنولوژی ها و معماری های پیشرفته Anycast و سلامت سنج پیشرفته بهره مند شوید. کارکرد این معماری ها به این صورت است که به طور مستمر سرورهای فعال در شبکه را از لحاظ در دسترس بودن بررسی کرده و در صورت از کار افتادن یک سرور، ترافیک را به طور هوشمند به سمت سایر سرورها هدایت خواهند کرد. علاوه بر این می توانید برای سرورهای متصل در شبکه توزیع بار یا load balancing کرده و با توجه به ظرفیت آنها، موقعیت شان و سایر سیاست های توزیع، ترافیک را بین آنها پخش کنید. به این ترتیب سرویس شما به آپ تایم 100% واقعی رسیده و بار ترافیکی سنگین از دوش سرور اصلی تان برداشته خواهد شد.

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

پیشنهاد می کنیم به صفحات DNS ابری و CDN میزبان کلود مراجعه کرده و با ویژگی های پیشرفته و منحصر به فرد آنها بیشتر آشنا شوید. در صورت نیاز به مشاوره در فعالسازی این سرویس ها نیز می توانید با کارشناسان ما در ارتباط باشید.

جمع بندی

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

پیشنهاد ویژه

CDN ابری میزبان کلود

سرعت در بارگذاری و تحویل محتوای سایت

سرعت در بارگذاری و تحویل محتوای سایت

سرعت در بارگذاری و تحویل محتوای سایت

سرعت در بارگذاری و تحویل محتوای سایت

مشاهده پلانها
برچسب‌ها :
نویسنده مطلب Shahin Noei

نویسنده مطلب

راهکارهای حل Failover | مرجعی کامل + استراتژی های کاربردی 0 دیدگاه