مقدمه ای بر BC
در این قسمت در رابطه با اهمیت Business Continuity در سازمان ها، عوامل و فاکتورهایی که بر Information Availability یا IA تاثیر می گذارند و عواقبی که عدم دسترسی به اطلاعات برای ما خواهد داشت، بحث خواهد شد.
بطور کلی به پروسه ای که در طی آن ایجاد آمادگی، واکنش نشان دادن و بازیابی از قطعی ایجاد شده در سیستم که می تواند تاثیر منفی بر روی عملیات کسب و کار بگذارد، را فراهم می کند، BC گفته می شود. هدف نهایی از راهکار BC دستیابی به در دسترس بودن بیشتر اطلاعات برای رسیدن به SLA مورد نیاز است بصورتی که اینکار بصورت اتوماتیک و با حداکثر کاهش مداخله دستی انجام گیرد. بدین ترتیب بعد از هر قطعی، تمامی وظایف ضروری همچنان و بدون هیچگونه وقفه ای صورت خواهد پذیرفت.
امروزه کسب و کارها بیشتر از هر زمان دیگری متکی به اطلاعات شده اند و دسترسی دائمی به این اطلاعات به یک ضرورت اجتناب ناپذیر تبدیل شده است. سازمان ها تحت فشاری قرار گرفته اند که می بایست حتما سرویس های خود را بر اساس SLA درست و دقیق به مشتریان عرضه کنند. خسارت ناشی از عدم دسترسی به اطلاعات برای سازمان های کلیدی گاهی اوقات به میلیون ها دلار در ساعت می رسد. همچنین این مساله برای سازمان هایی که اطلاعات مشتریان خود را نگهداری می کنند از اهمیت بیشتری برخوردار است زیرا قوانین دولتی جریمه های سنگینی را برای آنها در نظر گرفته است که از لحاظ مالی تاثیر بسزایی بر روی آنها خواهد داشت.
تهدیدهای مختلفی در مقابل BC قرار دارد از فجایع طبیعی گرفته تا رخدادهای برنامه ریزی شده و برنامه ریزی نشده. بسیاری از سازمان ها نیز امروزه از BYOD یا همان Bring-your-own-device حمایت می کنند که در کنار مزیت هایی که دارد دارای ریسک های بالقوه ای نیز از لحاظ ذخیره سازی اطلاعات مهم بر روی سخت افزارهای شخصی، است. بنابراین باید استراتژی های مناسبی برای این موارد در نظر گرفت که استفاده از BC راهکاری مناسب برای تعیین این استراتژی ها است.
دلایلی بر عدم دسترسی به اطلاعات
تنها این نیست که قطعی مرکز داده که بدلیل فجایع طبیعی مانند زلزله، سیل و غیره ایجاد شده است، باعث از دسترس خارج شدن اطلاعات شود، بلکه طراحی ضعیف نرم افزار یا پیکربندی نادرست منابع نیز می توانند دلیلی بر این موضوع باشند. برای مثال اگر سرور دیتابیس به دلایلی از کار بیافتد، دسترسی کاربران به دیتا از بین خواهد رفت. در این مواقع دپارتمان آی تی وظایفی را برای انجام امور نگهداری معمول و حتی جابجایی به مرکز داده جدید یا migration انجام می دهد مانند تازه کردن زیرساخت مرکز داده جدید. هر کدام از این امور می توانند تاثیر منفی بر روی در دسترس بودن اطلاعات داشته باشند که می بایست مورد بررسی دقیق تر قرار بگیرند.
اصطلاحات کلیدی BC
Disaster Recovery
قسمتی کلیدی از BC می باشد که مطابق آن تمامی زیرساخت های IT در یک مرکز داده دیگر به همان شکل اصلی خود راه اندازی می شود تا در صورت بوجود آمدن هرگونه فاجعه ای بتوان به سرعت به مرکز داده دوم سوئیچ کرد. البته به دلیل هزینه های بسیار زیادی که راه اندازی مرکز داده دوم بر دوش شرکت ها می گذارد و بسیاری از آنها از عهده این هزینه ها بر نمی آیند، راهکار دیگری نیز با نام DRaaS در نظر گرفته شده است که به عنوان یک محصول توسط شرکت های ارائه دهنده خدمات ابری ارائه می شود و هزینه راه اندازی آن بسیار به صرفه تر می باشد.
Operational Recovery
در این مبحث تنها قسمتی از زیرساخت آی تی دچار مشکل می شود و نه تمام زیرساخت. برای مثال یک فایل، یک ایمیل، یک دیتابیس یا یک VM.
Recovery Point Objective (RPO)
RPO تعریف کننده حداکثر داده ای است که سازمان پذیرش از دست دادن آنها را دارد . به عنوان مثال اگر شما از سرور خود بصورت روزانه و در ساعت ۲۳:۰۰ یک بکاپ تهیه می نمایید، آنگاه RPO در این حال در بدترین وضعیت برابر ۲۴ ساعت است.
Recovery Time Objective (RTO)
RTO به معنی مدت زمان مورد نیاز جهت ریکاوری سیستم پس از بروز حادثه می باشد. در واقع به نوعی به Downtime مورد نیاز در صورت بروز حادثه اشاره می نماید.
راه کارهای ارائه شده توسط BC
Single Point of failure (SPOF)
اصطلاحی است که مطابق آن اگر یکی از اجزای زیرساخت به هر دلیلی قطع شود، در روند کار کل سیستم و یا سرویس اختلال و قطعی پیش خواهد آمد. این اجزای زیر ساخت را به دو قسمت تفکیک می کنیم:
۱ – قسمت سرور، استوریج و شبکه (Component Level)
۲ – قسمت مرکز داده (Site Level)
در شکل بالا می توانید SPOF را در لایه های مختلف مشاهده نمایید. برای مثال فرض کنید بر روی یک ماشین مجازی یک برنامه وب دارید که از دیتابیسی استفاده می کند که بر روی ماشین دیگری اجرا شده است. اگر به هر دلیل دیتابیس دچار مشکل شود، برنامه نیز دیگر قادر به سرویس دهی نخواهد بود و از کار می افتد. حال در مثالی دیگر فرض کنید چندین سرور دارید که همگی به یک سوئیچ FC متصل هستند. در واقع این سوئیچ یک SPOF خواهد بود زیرا اگر از کار بیافتد، کل سرورها نیز از دسترس خارج خواهد شد.
بنابراین ایجاد fault tolerance در زیرساخت مرکز داده برای حذف SPOF در سازمان ها، از اهمیت بسزایی برخوردار است. برای اینکار می بایست برای هر قسمتی که می خواهیم اقدام به حذف SPOF کنیم، یک نمونه دیگر از آن (redundant) را تهیه کنیم. برای نمونه باید دارای دو مرکز داده باشیم تا اگر یکی از کار افتاد، دیگری آماده بکار باشد.
پیاده سازی Redundancy در Component level
فعال سازی redundancy و حذف SPOF در لایه component که منظور همان سرور، استوریج و شبکه می باشد، از اهمیت بسیار زیادی برخوردار است. در شکل زیر می توانید نمونه ای از یک طراحی زیرساخت شبکه که در آن SPOF به میزان زیادی کم شده است را مشاهده نمایید.
همانطور که مشاهده می نمایید، در لایه compute، با افزودن یک سرور دیگر در پیکربندی کلاستر توانسته ایم SPOF را حذف نماییم. در لایه شبکه با استفاده از دو سوئیچ FC و داشتن چند مسیر از سمت سرور به استوریج، می توانیم SPOF را در این لایه نیز حذف کنیم و در نتیجه اگر در مسیر اصلی مشکلی ایجاد شود، سرورها از مسیر جایگزین استفاده خواهند کرد. در لایه استوریج نیز از روش های مختلفی مانند RAID، RAIN و غیره، برای این منظور استفاده می شود که در رابطه با آنها بیشتر صحبت خواهد شد.
Compute Clustering
تکنیکی است که مطابق آن حداقل دو سرور با یکدیگر کار کرده و همگی آنها به عنوان یک سرور دیده می شوند که در نتیجه آن high availability و load balancing فراهم می شوند. در این حالت اگر یکی از سرورها از کار بیافتد، تمامی سرویس های آن به سرور دیگر منتقل می شوند.
دو نوع پیاده سازی رایج در این تکنیک وجود دارد. روش Active/Active که در آن تمام سرورهایی که عضو یک کلاستر می شوند فعال هستند و بار سرویس ها بین آنها تقسیم می شود. اگر در این روش یکی از سرورها از مدار خارج شود، سرور دوم، بار سرویس های آن سرور را گرفته و آنها را اجرا می نماید. در اینجا هم Availability و هم performance با هم فراهم شده است. همچنین باید در نظر داشته باشید که تمامی سرورهای یک کلاستر باید به یک Share storage volume دسترسی داشته باشند.
در روش Active/Passive سروری که نقش passive را بر عهده دارد منتظر می ماند تا سرور Active از کار بیافتد و آنگاه سرویس های از دسترس خارج شده را بازیابی می کند. در این روش دیگر performance به مانند روش قبلی فراهم نمی شود. در کلاستر از مکانیزم heartbeat برای اینکه سرورها از سلامتی یکدیگر با خبر شوند استفاده می شود.
کلاستر می تواند بین چند سرور فیزیکالی، بین چند ماشین مجازی، بین ماشین مجازی و سرور فیزیکی یا بین چند هایپروایزر، پیاده سازی شود.
در رابطه با این مبحث، دو نوع پیاده سازی کلاستر سرور در بحث vmware همراه با تفاوت های میان آنها را با نام های HA و FT بیشتر مطالعه نمایید.
Network Fault Tolerance
یک وقفه کوچک در شبکه می تواند تاثیر بزرگی بر روی سرویس های یک مرکز داده بگذارد. بنابراین می بایست زیرساخت شبکه کاملا redundant و single point of failure در آن حذف شده باشد. تکنیک هایی مانند link aggregation، NIC Teaming و Multipathing مکانیزم هایی را در این زمینه برای ما فراهم می نماید که به تفکیک مورد بررسی قرار می گیرند.
مطابق شکل زیر مکانیزم link aggregation چند لینک شبکه را در بین سوئیچ ها، با هم ترکیب کرده و یک لینک logical را به ما ارائه می دهد که port channel نامیده می شود که در نتیجه آن نه تنها پهنای باند بالاتری را به ما عرضه می کند بلکه در صورتی که هر کدام از لینک ها از کار بیافتد، ترافیک از لینک های باقیمانده عبور خواهد کرد.
مکانیزم NIC Teaming که در رابطه با Network استفاده می شود، می تواند چند کارت شبکه را با هم یکی کرده و تحت عنوان یک Logical NIC به سیستم عامل یا هایپروایزر ارائه دهد. استفاده از این قابلیت نه تنها باعث می شود که از پهنای باند کل کارت شبکه ها استفاده شود بلکه در صورت قطعی یکی از کارت شبکه ها، همچنان می توان از سایر کارت شبکه ها استفاده کرد.
مکانیزم Multipathing که در رابطه با شبکه SAN استفاده می شود، باعث ایجاد چندین مسیر از سمت سرورها به استوریج می شود که بصورت اتوماتیک بین این مسیرها failover انجام می دهد. هر مسیر می تواند بصورت Active و یا Standby پیکربندی شود. در صورتی که یک مسیر در حالت standby باشد، هیچ ترافیکی را از خود عبور نمی دهد تا زمانی که مسیر Active از کار بیافتد. همچنین می توان از این مکانیزم برای load balancing نیز استفاده کنیم. در این حالت می بایست تمام مسیرها در حالت Active قرار بگیرند. نرم افزار PowerPath که محصول شرکت emc می باشد، نمونه ای است که برای راه اندازی مکانیزم مذکور مورد استفاده قرار می گیرد.
Storage Fault Tolerance
دیسک درایوهای موجود در مراکز داده از اهمیت بسیار زیادی برخوردار هستند و از دست رفتن هر کدام از آنها باعث از بین رفتن اطلاعات و در نتیجه از دسترس خارج شدن سرویس ها می گردد. تکنیک های زیر در جهت data protection در صورت خراب شدن دیسک ها، استفاده می شوند:
RAID
تکنیکی است که چند دیسک را با هم ترکیب کرده و تحت عنوان یک واحد منطقی آنرا ارائه می نماید. دارای سطوح مختلفی است که برای کسب اطلاعات بیشتر در رابطه با آن اینجا را مطالعه نمایید.
Erasure Coding (EC)
روش جدیدی است که جایگزینی برای RAID به حساب می آید و به میزان زیادی زمان و بار ایجاد شده در جهت ساخت دوباره دیتا را پایین می آورد. در این روش دیتا به قطعاتی به نام fragment تقسیم می شود و بین تمامی استوریج ها و دیسک ها پخش می شوند و سپس هر fragment بشکل ریاضی encoding می شود. در این روش حتی اگر چند درایو بصورت همزمان خراب شوند، عملیات بازیابی به سرعت انجام می شود.
Dynamic disk sparing
مکانیزمی است که در آن یک یا چند دیسک را در استوریج فقط برای spare تعیین می کنیم. در صورتی که تعداد خطاهای قابل بازیابی یک دیسک از حد مورد انتظار بیشتر شود، استوریج شروع به کپی کردن دیتای آن دیسک به دیسک spare می کند. البته فضای دیسک جایگزین باید به اندازه ای بزرگ باشد که قابلیت نگهداری دیتای دیسک خراب را داشته باشد. اگر مرحله کپی قبل از اینکه دیسک مورد نظر fail دهد بطور کامل انجام شود، سیستم به دیسک جایگزین سوئیچ می کند، در غیر اینصورت از دیسک های parity و یا mirror برای عملیات کپی دیتا استفاده می کند.
Storage virtualization appliance
راه کار دیگر استفاده از یک appliance مخصوص مجازی سازی استوریج است که با استفاده از آن volume های مجازی از طریق lun های ساخته شده در استوریج ها، ساخته می شوند و بجای اینکه فضای ذخیره سازی سرورها مستقیما از Lun ها تامین شوند، از virtual volume ها اختصاص داده خواهند شد.
همانطور که در شکل بالا مشاهده می نمایید، virtual volume ساخته شده در appliance ، بین دو LUN از دو استوریج مختلف mirror شده است. حال هر زمان که یکی از استوریج ها به مشکل بر بخورد، appliance تمامی I/O های خود را بر روی leg دوم خود می اندازد و در نتیجه هیچگونه قطعی احساس نخواهد شد. هر زمان که leg اصلی برگردد، مجدد هر دو با هم resync می گردند. از این روش بخصوص برای سرویس های بسیار مهم استفاده می شود.
پیاده سازی Redundancy در Site Level
بهترین طراحی که می توان برای تامین HA انجام داد، ایجاد یک zone دیگر برای مرکز داده است. این زون جدید مکانی است که منابع مخصوص به خود را دارد و از سایر زون ها جدا است. این زون می توان درون همان مرکز داده اصلی باشد و یا اصلا در یک مرکز داده دیگر ایجاد شود. به وضوح مشخص است که اگر هر زون در یک مرکز داده ایجاد شود که از لحاظ جغرافیایی در جاهای مختلفی قرار دارند، به میزان زیادی میزان HA بالاتر از زمانی خواهد بود که زون ها در یک مرکز داده قرار بگیرند. زیرا در این حالت حتی اگر مشکل در سطح مرکز داده ایجاد شود، باز سرویس ها از طریق مرکز داده دوم به کار خود ادامه خواهند داد. البته این موضوع خیلی مهم است که مکانیزمی طراحی شود که جابجایی بین مراکز داده بصورت اتوماتیک انجام شود تا RTO بشکل قابل توجهی نسبت به حالت دستی پایین تر بیاید.
عکس بالا نمونه ای از یک طراحی HA در دو زون مختلف در دو مرکز داده متفاوت است. در این طراحی در بخش سرور از طراحی streched cluster استفاده شده است. در طراحی streched سرورها بصورت Active/Active نه تنها HA را تامین می کنند بلکه بار ورودی نیز بین سرورها تقسیم می گردد. برای این منظور یک vCenter در یک قسمت ساخته و سرورهای هر دو سمت را در زیر یک کلاستر قرار می دهیم و در ادامه با فعال سازی VCHA امکان داشتن vCenter را در هر دو سمت فراهم می نماییم. در بخش استوریج نیز همانطور که در بالا توضیح داده شد و در عکس نیز به وضوح مشخص است، با استفاده از یک virtualization appliance می توانیم HA را تامین نماییم.
