به "وبلاگ فالنیک ( ایران اچ پی)" خوش آمدید    |   وبسایت فالنیک (ایران اچ پی)
امروز جمعه ۲۷ مهر ۱۳۹۷ - تماس با فالنیک : 8363-021

چگونه Availability را در شبکه محاسبه کنیم؟

وبلاگ فالنیک ( ایران اچ پی)

چگونه Availability را در شبکه محاسبه کنیم؟

شاید در نگاه اول و آنچه همه ما تصور می‌کنیم، Availability و Uptime هم معنا هستند اما در واقع اینطور نیست. این استانداردها برای اپلیکیشن‌های Mission Critical حیاتی هستند مثل ویدئو یا VoIP چرا که حتی ثانیه‌ای قطعی در این سیستم‌ها خسارات مالی و یا حتی جانی را به دنبال دارد. تصور کنید مرکز کنترل خطوط هوایی لحظه‌ای قطع شود و یا سیستم اورژانس دچار اختلال شود. Availability یا دسترس‌پذیری، به موارد متفاوتی بستگی دارد مثلا طراحی و اهداف کاری شبکه، امنیت و سازگاری تجهیزات. آنچه که مهم است این است که هر ثانیه Downtime می‌تواند هزینه‌های گزافی را به شما تحمیل کند.

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

چگونه Availability را در شبکه محاسبه کنیم؟

فرض کنید در حال عیب‌یابی یک Remote Application هستید: شما باید بدانید که آیا اپلیکیشن Down شده و یا شبکه‌ای که این اپلیکیشن تحت آن به کاربران، از راه دور سرویس می‌دهد. بیایید این دو استاندارد را بیشتر بررسی کنیم.

Uptime چیست؟

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

user@unix# uptime

10:28:24 <strong>up 16 days, 1:24</strong>, 1 user, load average: 0.16, 0.03, 0.01

switch# show version | include uptime

switch uptime is <strong>2 weeks, 2 days, 2 hours, 30 minutes</strong>

Availability چیست؟

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

فرمولی که البته ساد‌ه‌ترین فرمول برای محاسبه Uptime است و اغلب از آن استفاده می‌شود به صورت زیر است:

Availability (%) = Uptime/Total Time

Total Time = Downtime + Uptime

با این فرمول می‌توانیم حداکثر میزان Downtime که یک سرویس می‌تواند داشته باشد تا به Sevice Level Agreement یا SLA خود برسد را بدست آوریم.

معمولا Availability را به صورت 3 تا 9 و یا 6 تا 9 بیان می‌کنند. طبق جدول زیر اگر 6 تا 9 یعنی 99.9999% دسترس‌پذیری داشته باشیم، در طول سال تنها 31 ثانیه Downtime را تجربه می‌کنید که این مساله برای اپلیکشین‌های Mission Critical ایده‌آل و ضروری است. و اگر 3 تا 9 یعنی 99.9% داشته باشیم، در طول سال، 8.76 ساعت، تجربه Downtime و قطعی را خواهیم داشت.

چگونه Availability را در شبکه محاسبه کنیم؟

انترپرایزها و تامین‌کنندگان سرویس کلود خواستار دستیابی به 5 تا 9 یعنی 99.999% هستند ولی در عمل تنها تعدادی از آنها به این عدد دست می‌یابند.

دسترس‌پذیری شبکه یا Network Availability

 با اینکه فرمول محاسبه دسترس‌پذیری شبکه ساده است اما باید دید که شامل چه چیزهایی است.

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

حال تصور کنید، تانل VPN قطع شده (Down) ولی اتصال اینترنت برقرار است. عدد Network Availability چند است؟ اگر اتصال اینترنت قطع شود، این عدد چه تغییری می‌کند؟

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

Network availability = Weightexternal_apps x Network AvailabilityInternet + WeightInternal_apps x Network AvailabilityVPN

فرض کنید 80 درصد از اپلیکیشن‌های کاری، اکسترنال (اینترنت) هستند پس 20 درصد باقی می‌ماند که مربوط به اپلیکیشن‌های کاری اینترنال (VPN) است. اگر در طول یک سال قطعی اینترنت نداشته باشیم و تنها یک روز VPN قطع باشد، میزان Network Availability به صورت زیر حساب می‌شود:

Network Availability = 80% * 100% + 20% * (99.726%) = 99.945%

چگونه Availability را در شبکه محاسبه کنیم؟

موارد تاثیرگذار بر Uptime و Downtime

مهمترین عناصری که بر Uptime و Downtime اثر دارد موارد زیر هستند:

  1. MTBF (Mean Time Between Failure)
  2. MTTR (Mean Time To Repair)
  3. Impacted User Minates (IUM)
  4. Defects per Million (DPM)
  5. Performance (e.g latency, drop)

همان طور که گفته شد، فرمول زیر ساد‌ترین فرمول برای محاسبه Uptime است:

Availability (%) = MTBF / (MTBF + MTTR)

اگر MTBF برابر با ده هزار ساعت و MTTR برابر با 12 ساعت باشد، Availability چقدر می‌شود؟

Availability (%) = 10,000 / (10,000 + 12) = 99.88 %

Uptime سالیانه چقدر است؟

Annual Uptime (hrs) = 8,749 hrs/year  x  (0.9988) = 8,749.5 hrs

Downtime سالیانه چقدر است؟

Annual Downtime (hrs) = 8,760 hrs/year  x  (1 – 0.9988) = 10.5 hrs

اگر شما بتوانید بلافاصله و بدون هیچ وقفه‌ای تعمیر را انجام دهید، MTTR صفر خواهد بود در نتیجه Availability صد در صدی دارید. این دقیقا کاریست که در HA Clustring سعی در انجامش داریم یعنی بتوانیم MTTR را به صفر برسانیم. چگونه؟ اگر بتوان در صورت خرابی قطعات با نهایت سرعت، به قطعات افزونه سوئیچ کرد. بسته به اینکه معماری اپلیکیشن چیست و یا چقدر سریع می‌توان خرابی را تشخیص داد و تعمیر کرد، ممکن است کاربر حتی متوجه این وقفه نشود و انگار هیچ اتفاقی نیفتاده است. و یا می‌توانیم سرور دیگری در نظر بگیریم که ریپلیکیشن و ریداندنت را انجام دهد: یعنی به شبکه وصل نیست فقط به سرور وصل است.

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

نکاتی که در زمینه Availability باید مورد توجه قرار گیرد به صورت زیر است:

  1. پیچیدگی، دشمن Raliability است (MTTR) و می‌تواند در صورت‌های مختلفی ظاهر شود:
  • پیچیدگی نرم‌افزاری: نرم‌افزار پیچیده بیشتر از نرم‌افزارهای ساده خراب می‌شوند.
  • پیچیدگی سخت‌افزاری: سخت‌افزار پیچیده بیشتر از سخت‌افزارهای ساده خراب می‌شوند.
  • وابستگی نرم‌افزارها: معمولا یعنی اگر قطعه‌ای خراب شود، کل سرویس ایراد پیدا می‌کند.
  • پیچیدگی، امکان خطای انسانی را افزایش می‌دهد.
  1. افزونگی یا Redundancy، دوست Availability است. زیرا امکان ریکاوری سریع را می‌دهد و باعث بهبود MTTR می‌شود. Replication کلمه دیگری است که می‌توان به جای Redundancy استفاده کرد.
  2. تشخیص به موقع و سریع خرابی، حیاتی است.
  3. مولفه‌های غیرضروری را نباید به حساب آورد زیرا خرابی این مولفه‌ها تاثیری بر دسترس‌پذیری ندارد. این قطعات ممکن است نرم‎افزاری، سخت‌افزاری و یا سخت‌افزارهایی باشند که نرم‌افزاری غیرضروری روی آن اجرا می‌شود.

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

  1. Mission Critical: اپلیکیشن‌هایی هستند که حتی یک ثانیه قطع شدن آنها، باعث ضرر مالی و جانی در کشور می‌شود. پس باید دسترس‌پذیری صد درصدی داشته باشد. درنتیجه Availability و Downtime مهم است، ولی بودجه مهم نیست.
  2. Business Critical: اپلیکیشن‌هایی که قطع شدن آنها، باعث ضرر مالی برای یک سازمان می‌شود. مثلا قطعی سایت، CRM، سرور تراکنش آنلاین بانک، وب سرور دیجیکالا. سرویس بانک‌ها، سرویس اینترنت. پس سطح بالای Availability احتیاج دارند اما می‌توانند قطعی داشته باشند و میزان خیلی کمی Downtime برای آنها قابل قبول است.
  3. Non-Critical (Archiving): سرور DHCP، AD، وایرلس، پرینت و فایل سرور، ضبط تصاویر مدار بسته.

 

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

منابع:
Techthoughts
Mitigationlog
Delaat
Netbeez
cisco


نویسنده :

چگونه Availability را در شبکه محاسبه کنیم؟
4 رای، میانگین 5 از 5

دیدگاه بگذارید

avatar
  اشتراک  
اطلاع رسانی
قرعه کشی ماهانه فالنیک (ایران اچ پی)
ایبوک فالنیک
فالنیک کست
تک تاک
پربازدید ترین مطالب
  • ماه
  • فصل
  • کل
پر بحث ترین ها
استفاده از مطالب سایت فالنیک (ایران اچ پی) فقط برای مقاصد غیر تجاری و با ذکر منبع بلامانع است. کلیه حقوق سایت متعلق به فالنیک (ایران اچ پی) است.
عضویت در خبرنامه سرور فالنیک (ایران اچ پی)

عضویت در خبرنامه سرور فالنیک (ایران اچ پی)

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

تبریک، شما با موفقیت در خبرنامه عضو شدید.