فیلم گفتگو: در دسترس پذیری بالا (High Availability) در نرم افزارها

دسترس‌پذیری بالا (High Availability یا HA) یک ویژگی مهم در سیستم‌ها و خدمات آنلاین است که به معنی تلاش برای بالا بردن سطح دسترسی پذیری و افزایش زمان uptime یک دستگاه است. هدف اصلی دسترس‌پذیری بالا این است که مشتریان و کاربران بتوانند به طور مداوم و بدون هیچ اختلالی از سیستم استفاده کنند. یک دستگاه برای High Available بودن، باید بتواند هنگام بروز مشکل، در سریع‌ترین زمان ممکن آن را شناسایی کند و اگر یک سرویس به این دلیل از دسترس خارج شده بود، برای آن جایگزینی داشته باشد و تا زمان رفع مشکل به درخواست‌های کاربران پاسخ بدهد.
در فیلم گفتگوی 34 دقیقه ای زیر، مهندس معمارزاده و دکتر تجویدی در خصوص مباحث مرتبط با دسترس‌پذیری بالا (HA)، مزایای آن و مسیر پیاده سازی HA در سازمان‌ها صحبت کردند که سرفصل مباحثی که در این فیلم به آن پرداخته شده به همراه متن کامل گفتگو را می‌توانید در ادامه مطالعه نمایید.

فیلم کامل گفتگو

محتوای متن کامل این گفتگو را از اینجا بخوانید :

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

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

+ خواهش میکنم سلامت باشید

 آقای دکتر ما در فیلم قبلی در ارتباط با اهمیت اخذ بک آپ و در واقع کپی اطلاعات صحبت کردیم بله گفتیم که در واقع اطلاعات ثروت سازمان است در واقع انواع بک آپ رو در حوزه‌ی در واقع دیتابیس پایگاه داده شما زحمت کشیدید و تشریح کردید best practice هایی در این خصوص ارائه دادید روش های در واقع اطمینان از حوزه بازیابی صحیح را در واقع فرمودید و در واقع روی این حوزه باهم صحبت کردیم یادم هست زمانیکه در خصوص دوتا عبارت RTO  و  RPO صحبت میکردیم در واقع اون میزانی که سازمان ها و کسب و کارها میپذیرند بابت بازیابی در واقع اطلاعات و اون از لحاظ زمانی و از لحاظ حجمی فرمودید که اگر سازمان ها به سمت راه اندازی HA بروند این در واقع عدد کوچک میشه به صفر نزدیک میشه درست هستش این عرض بنده؟

– بله

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

– بله خواهش میکنم.  پس در واقع ما امروز میخواهیم در مورد HA (High availability) یا دسترسی پذیری بالا صحبت کنیم قاعدتا HA بایده مثل بک آپ که بایده و هیچ کدوم جای اون یکی رو نمیگیره پس مفهوم بک آپ تقریبا برای همه دوستان قابل درکه به نظرم یه خورده هم در مورد HA صحبت کنیم و بعد برسیم به RPO  و RTO  و اینها را به هم ربط بدهیم

High Availability یا در دسترس پذیری بالا چیست و چه مزایایی دارد؟

(از زمان 03:00 تا 05:۱7 )

– HA یا همان دسترسی پذیری بالا دیگه الان تو کمتر سازمانیه که به این سمت نرفته باشه چون براش مهمه که اون سیستمش همیشه پاسخگو باشه و اگر اتفاقی افتاد برای سروری که در نظر گرفته یه سرور جایگزینی وجود داشته باشه که بتونه جای اون رو به سرعت بگیره و down time خیلی کم باشه. و اینکه کاربر خیلی حس نکنه که سیستم قطع شده. خوب تو این موضوع جذابه برای سازمان‌ها و قطعا هر سازمانی هر شرکتی که بخواد سرویس خوب بده براشون این موضوع مهمه بنابراین همه به سمت HA میروند خب داستانای خودشو داره دیگه یعنی تقریبا میشه گفت این صحبتی که من کردم مزیت اصلی HA است حالا میشه خیلی موارد دیگه گفت مثلا ممکنه که شما بخواهید سخت‌افزار یا نرم افزارتونو ارتقا بدید مثلا ویندوزتون رو یه ورژن بالاتر ببرید SQL رو یه ورژن بالاتر ببرید به هر حال نیاز دارید که اون کامپیوتر رو خاموش کنید ماشینو ریست کنید خوب برای سیستم‌هایی که خصوصاً 7/24 باشه عملاً زمانی وجود نداره برای قطع کردن خب پس اینا باید به سمت HA  بروند یعنی همواره باید نود یا نودهای جایگزینی وجود داشته باشه که مسئولیت پاسخ دهی و  مسئولیت سرویس دهی رو داشته باشه که بتونه نودهای دیگری در بازه های زمانی در واقع قطع بشن برای بحث‌های  maintenance قطعا  HA  به درد میخوره و حالا همینطور که بریم جلوتر با هم صحبت کنیم به مزایای بیشتری از اون میرسیم اما بد نیست اینجا این نکته رو بگم که نه بک آپ جای HA رو میگیره نه HA جای بک آپ رو میگیره

RPO و RTO چیست و نقش کپی پشتیبان و HA

(از زمان 05:۱7تا 12:06 )

– مثلا فرض کنیم خوب فکر کنم اینجا بد نباشه که RPO و RTO  رو تعریفش رو بگیم و توی مثالی که در مورد RPO و RTO  هست بگیم بک آپ چه نقشی دارد HA چه نقشی داردRPO  که  Recovery Point Objective یا RTO، Recovery Time Objective هر دو یه مفاهیمی اند که به هم شبیه اند ولی با هم فرق دارند RPO میگه یه سازمان چقدر تحمل از دست دادن دیتا رو داره یعنی آیا میتونه یه ساعت دیتاش رو از دست بده دو دقیقه دیتاش را از دست بده یه روز دیتاش از دست بده هر دو زمان اند و  تو هر دو تایم مطرحه. RTO میگه اوکی سیستم از حالت سلامت رفت به یه حالتی که نمیتونه پاسخ دهی داشته باشد از زمانی که سیستم از کار می افتد تا زمانی که سیستم سلامت و سرحال بالا میاد که میتونه پاسخ بده این تایم چقدره و اون سازمان چقدر زمان داره برای تحمل این. یه مثال بزنیم فرض کنید یه شرکتی هر شب ساعت ۱۱ شب داره بک آپشو میگیره یه دونه بک آپ ۱۱ شب میده و در بدترین حالت ممکنه ۲۴ ساعت دیتا از دست بده یعنی ۱۱ شب امروز بک آپرو گرفته میرسه به ۱۱ شب فردا قبل از گرفتن بک آپ سیستم از کار میفته دیتا کلا از دست میره خب چیکار میتونه بکنه بک آپ روز قبل رو برگردونه پس میتونیم بگیم حداکثر ۲۴ ساعترو از دست میده اینجا در واقع RPO میشه ۲۴ ساعت و حالا از زمانی که اون سیستم از کار میفته توی همین مثال خودمون فرض کنیم ۱۰ شب سیستمش از کار میفته ۲۳ ساعت دیتا از دست میده زمانی که سیستم از کار میفته با متخصصش تماس میگیرند میاد وصل میشه به سیستم شروع میکنه حالا اگه لازمه بک آپ رو برگردوندن تا سیستم سرحال میشه این تایمی که از کار افتاد و این تایمی که متخصصو پیدا کرد  Restore کرد بک آپ سرحال شد اون میشه RTO  ممکنه دو سه ساعت اینم طول بکشه

+ آقای دکتر فراموش نکنید فرمایشاتتون رو یکی از در واقع مشتریان که در حوزه خودرو بودش من یهو تو ذهنم اومد این مثال از مدیر فناوریشون پرسیدم چرا شما منزلتون فلان جا هستش مثلا یکی از خودرو سازان بودش و منزلشون سمت اکباتان بود گفتم شما چرا نیاوران نیستید؟ گفت والا به من اجازه نمیدن که با توجه به این قضیه حتی زمانی که در واقع من میتونم خودمو برسونم از محل سکونتم باید در این RTO بگنجه در این حد در واقع این قضیه حساسیت برانگیزه

– بله همینی که الان در واقع دسترسی های ریموت خیلی باب شده و خیلی سازمان ها دارند این هم میشه گفت در همون بحث RTO هست میخواد اگه سیستم از کار افتاد نصف شب بود یا هر زمانی اون فرد بتونه تو کوتاه ترین زمان ممکن وصل شود به سیستم و مشکل را برطرف کنه بله به نوعی اینها همه تو همون RTO میگنجد

+ درسته

– خب این شد مفهوم RTO و RPO قبلش عرض کردم نه بک آپ جای HA رو میگیره نه HA جای بک آپ رو میگیره  خوب چرا بک آپ جای HA رو نمیگیره بخاطر اینکه فرض کنید ما راهکار HA  رو نداریم میشه همین مثالی که من زدم سیستم از کار افتاد باید یه سیستم سرحال داشته باشیم وای به وقتی که نیاز داشته باشی ویندوز نصب کنیم  SQL  رو نصب کنیم حالا اگه بک آپ چند صد گیگ یا چند ترابایته کپی بشه اونجا قرار بگیره  Restoreکنه ممکنه یه روز طول بکشه این فرایند خب پس عملاً RTO خیلی وضعش خراب میشه اینجاست که ما میگیم که اوکی بریم سراغ HA  که اگر اتفاقی برای این سیستم افتاد یه اتوماتیک  Failover وجود داشته باشه یه نود دیگه سریع حداکثر در چند ثانیه جایگزین بشه و خب به هر حال RTO عدد خیلی خوبی باشه قطعا RTO  و RPO هر چقدر به صفر میل کنه از همه بهتره و خب پس اینجا میدونیم HA  از اون طرف میگن اوکی پس شما دیتا روی نود داری یه نود دیگه داری یه نود دیگه هم داری یه  HA سه نوده داری پس دیگه چرا بک آپ میخوای این از کار افتاد اون یکی هست دیگه خب نه واقعا اینجوری نیست به دو دلیل لااقل میشه گفت اینجوری نیست یکی اینکه ممکنه خدایی نکرده اون دیتا سنتر که همه نودها داخلش هست آتیش بگیره همه دیتا از بین میره ولی شما بک آپ رو میتونی در جای دیگه‌ای نگهداری کنی و دلیل دیگه اینکه شما ممکنه دیتا رو پاک کنی حالا از قصد، سهوی باشه عمدی باشه به هر شکل خب اون پاک کردنه میره رو همه جای دیگه به طور اتوماتیک شکل میگیره و اگر بک آپ نداشته باشیم اون دیتا را از دست دادیم پس هر دو باید باشند سر جای خودش من نمیدونم خیلی HA  رو تونستم خوب توضیح بدم یا نه ولی حالا یه بار دیگه مختصر بگم ما وقتی میگیم HA  یا دسترسی پذیری بالا یعنی حداقل باید دو به بالا نود داشته باشیم نود یعنی همون کامپیوتر حالا فیزیکی، مجازی یه ماشینی داشته باشیم که اگر هر کدام از اونا کار افتاد یه نود دیگه ای مسئولیت اونو به عهده بگیره این تعریف ساده اشه حالا بحث‌های load  balance و ایناهم مطرحه که شما میتونید بارو روی نودهای مختلف توزیع کنید ولی معمولا چیزی که مرسومه و حالا پیشنهاد داده میشه میگنحداقل سه تا نود داشته باشیم یه نود کار HA  انجام بده یه نود و سعی کن از اون دیتا سنتر خارج کنی کار  DR را انجام بده بحث  disast ریکاوری که حتی اگه بلایی سر اون دیتا سنتر هم اومد شما یه نود دیگه جای داشته باشی که اونم بتونی تو زمان کوتاه جایگزین کنی که در واقع به نوعی داره هم RTO  و RPO را کاور میکنه و ما در واقع به اعداد خوبی میرسیم

Always On روشی برای پیاده سازی HA در محصولات ماکروسافتی

(از زمان  12:06 تا 13:05)

+ خیلی تشکر میکنم آقای دکتر HA که در واقع اسم راهکار نیستش به اون کانسپت قضیه گفته میشه دسترس پذیری بر اساس اون تکنولوژی که در یک محصول استفاده میشه در واقع میتونه از راهکار‌های ماکروسافتی استفاده بشه از راهکار های جاوایی، oracle و این ها من فکر کنم  هر کدوم قطعا راهکار‌های دقیق  در حوزه HA دارند مثلا خود فراگستر و در واقع خیلی از شرکت ها رو راهکار‌های ماکروسافتی کار میکنند به دلایل بسیار مختلف اگر در واقع دقیق بخواهیم در خصوص راهکار ماکروسافتی در واقع سوال و محدود بکنیم اسمش چیه ما با چه در واقع راهکار‌هایی HA  رو توی پلتفرم ماکروسافتی Run بکنیم

مروری بر انواع روش‌های پیاده سازی HA و معرفی بهروش آن

(از زمان  13:05 تا 24:22)

– خیلی سوال خوبیه میگن خوب ما میخواهیم بریم سراغ HA  چیکار باید بکنیم Sql sever اگه برگردیم به قدیمش یعنی بگیم از 2000 Sql که من خوب  با Sql    هفت شروع کردم 2000 Sql میشه هشت.یه Failover کلاسترینگی از قدیم داره

+ از همون نسخه از 2000؟

– بله میخوام راهکار رو خیلی مختصر در موردشون توضیح بدم و برسیم به این  best practiceکه دیگه تقریبا همه اهل فن میدونن که best practice، Always on است که میخواهیم بهش برسیم. Failover کلاسترینگ یه ساختاری داره که حالا ما تو همون دو نود تصورش کنیم که یک نود A و یک نود B قرار داره اگر بخواهیم این ساختار را اندازی کنیم حتما باید یه SAN Storage وجود داشته باشد خوب برای خیلی از شرکت های متوسط و کوچیک هزینه زیادی داره خرید SAN Storage و به غیر از این  single  point  of failure هم هست یعنی اگر SAN Storage آسیب ببینه کل دیتا آسیب میبینه و به نوعی این active-passive هم هست یعنی همیشه یه نود فعاله یه نود دیگه مونده که اگه این افتاد اون بیاد جاش جایگزین بشه یعنی ۵۰ درصد سرمایه خوابیده کنار تا یه روزی باشه خب این راهکار ماکروسافت خیلی قدیمی شده دیگه و با توجه به این مواردی که خدمتتون عرض کردم خیلی کمتر استفاده میشه معادل این تو oracle رک یا rac اوراکل هست که active-active  است و تقریبا اصلHA ، oracle روی این rac است از Failover کلاسترینگ  که عبور کنیم یه Replication هست که Replication Transitional است که اونم به نوعی تو دسته HA قرار میگیره شما میتونید دوتا نود داشته باشید دیتاهات سینک بشه از طریق همین Transitional Replication که اگر نودی آسیب دید نود دیگرو روش جایگزین کنیم خب اینم یه تاخیر زمانی حدود مثلاً ۱۵ ثانیه‌ای توش وجود داره و اگر سریع این از کار افتاد اونو بخواین جایگزین کنید یه بخش دیتای چند ثانیه این وسط از دست میره و این خیلی خبر بدیه پس میشه گفت که راهکار خوبی برای بحث HA نیست برای کارهای دیگه هست مثلا یه سرور گزارش گیری باشه از اون گزارش بگیره بارو از روی سرور اصلی جدا کنه برای این تیپ کارا یا کارای maintenance میشه ازش استفاده کرد ولی راهکار خوبی برای  HA نیست بعد از اون Log Shipping است Log Shipping هم راهکاریه که راه اندازیش خیلی ساده است میشه گفت بزرگترین مزیت Log Shipping راه اندازی ساده اشه حتی اگر سایت‌های متفاوت با در واقع دومین های مختلف باشه  باز شما میتونید اینو راه اندازی کنید چون یه کپی دیتا بین همدیگر است اگر بخوام Log Shipping رو  خیلی مختصر توضیح بدم شما یه نود اصلی دارید که داره تو اون عملیات insert،update ،delete انجام میشه از راهکار بک آپ Restore استفاده میکنیم به وسیله‌ی جابی و یه حالا فولدر share که وجود داره یه نود دیگه ای کنار قرار می‌گیره شروع میکنه این فایل های بک آپ رو Restore کردن روی خودش و البته به نوعی می‌تونیم اون رو Read only  هم بالا بیاریم منتها Log Shipping  بدیش اینه که مثلا ممکنه شما پنج دقیقه یکبار دیتا رو Restore کنی همیشه پنج دقیقه دیتا نداره بعد اگر بخواهیم به عنوان نودی که ازش گزارش بگیریم با بحث ریپورتینگ بخواهیم ازش استفاده کنیم پنج دقیقه یکبار هی قطع میشه چون وقتی بک آپ روش داره Restore  سیستم قطع میشه بخوای مساعتی یک بار این کارو کنید بازم تو ساعتی یک بار ممکنه قطع شه ممکنه اون ریپورتی که شما دارین میگیرین سر یه ساعت باشد نه تنها قطع میشه بلکه یک ساعت عقبه از دیتای اصلی خوب پس Log Shipping هم عملا میشه گفت برای HA خیلی راهکار خوبی نیست ولی چون راه اندازیش خیلی ساده است با توجه به این محدودیت‌هاش باز محبوبه برای خیلی از سازمان‌ها و ازش استفاده میکنن که به نظر من با وجود آنالیزور اصن نیاز نیست یعنی الان که برسم به        on   always   میبینی همه‌ی این خوبی‌ها تو دل always on  هم هست بعد از Log Shipping، mirroring است که تقریبا میشه گفت mirroring دیگه منسوخ شده است یا بازنشسته شده، mirroring پدر Always on هست. mirroring بدی های Log Shipping رو نداره سرعت انتقال بین نودها بیشتره ولی تو mirroring هم در واقع میشه گفت per instance نیست به ازای هر دیتابیس شما باید اینو راه اندازی کنید از نود ثانویه  نمیتونین استفاده ببرین تهش هر کدوم اینا یه ضعف‌هایی داره. Log Shipping  خوبیش اینه نود ثانویه  شو میده ازش ریپورت بگیری ولی برای بحث اتوماتیک Failover، اصلا اتوماتیک Failover نداره. mirroring  اتوماتیک Failover داره ولی نود ثانویش  از کار میوفته،per database  هم هست پس هرکدوم از اینا یه بدی دارد از server Sql 2012 به بعد مایکروسافت همه خوبی ها رو از هر کدوم از این راهکارها گرفت Always on رو تولید کرد الان Always on هم اتوماتیک Failover داره هر تعداد دیتابیس شما میتونید تو گروه‌های در دسترسش قرار بدین از نودهای ثانویه میتونیم به عنوان گزارش گیری استفاده کنیم هر چیزی که ما HA تو ذهنمون هست داره

+ از چه ورژنی؟

– از ورژن 2012 به بالا. SAN less هم هست یعنی چی؟ یعنی دیتا کپی میشه توی نودهای ثانویه و دیگه اون سازمان نیاز نداره حتماً san خریداری کنه از طرفی چون دیتا داره کپی میشه تو جاهای دیگه single  point  of failure هم نداره اون نقطه شکست نیست اونجا san  اگر از کار میفته همه چیز از کار میفته ولی اینجا هارد اون سرور اون هاردی که در واقع تخصیص داده شده به ماشین اول از کار بیفته هیچ اشکالی نداره

هیچ اشکالی نداره یعنی اشکال داره دیگه هارد از دست رفته اشکال داره ولی چون Failover میزنه هارد دیگری هست دیتای دیگه‌ای هست و ماشین دیگه‌ای نقش  primary رو بازی میکنه سیستم up میمونه بله پس همه اینا رو جمع کنیم میرسیم به Always on

+ آقای دکتر یه سوالی رو از من خیلیا پرسیدن بعد از اینکه در واقع HA و  Always on رو خواستند بعد تو مسیر که قرار گرفتند دیدن که بالاخره مسیر خودشو داره دیگه هم از سخت افزار از بعد DR از بعد منابع انسانی گفتند فعلا بیایم در واقع با  mirroring مثلا کارو هندل کنیم یا در واقع بیایم حالا فعلا عجالتاً راهکارهای در واقع دیگری را انجام بدهیم تا بعد بریم سراغ اون قضیه این مورد تایید شما هستش؟ ما میتونیم بگیم که میخواهیم  در بازه‌ی مثلا شش ماه mirroring داشته باشیم بعد شش ماه Log Shipping، بعد به سمت Always on بریم؟

– نه واقعا نه من یه خورده برگردم به عقب، اون سازمان میتونه بگه آقا من هیچی نمیخوام HA   بگه من اونقدر اهمیت نداره up بودن سیستمم من نمی‌خوام هزینه کنم حالا اگر که سیستمم از کار افتاد اوکی مسئول فنی ما میاد بک آپ رو Restore می کند یکی دو ساعت سیستم قطعه اوکیه خیلی خب هزینه نکن ولی اگر که میخواد هزینه کنه بگه حالا فعلا بریم سراغ Log Shipping،mirroring نه اون که داره به هر حال هزینه میکنه سرورهای دیگه رو داره در اختیار این راهکار میخواد قرار بده خوب پس برو بهترین و پیاده سازی کن Always on اصلا هزینه اضافه تری نسبت به راهکارهای  HAدیگه نداره که بگیم بخاطر هزینه میخواد به اون سمت بره بنابراین به نظر من هر سازمان که میخواد سراغ  Log Shipping،mirroring بره داره اشتباه  میکنه شاید به این دلیل باشه که اون آدم های قدیمی که تو سازمان بودند با اون راهکار آشنا هستند با Always on کمتر آشنان معمولا آدم چیزی که بلده دوست داره به اون سمت بره پس وقتی سازمان قراره اون هزینه رو بکنه بره دنبال بهترینش چرا چرا دنبال راهکاری که تهش هزینه میکنه آخرم به جواب نمیرسه اما من جای شما فکر کنم ممکنه شما بفرمایید که خب این راه‌اندازی HA  هست در Always on همه چیز خوبه هزینه هم داریم پرداخت میکنیم پس اوکی بریم به این سمت و هیچ دغدغه‌ای توش وجود ندار؟به به نظر من اگه هزینه‌شو داریم به این سمت بره بره سازمان. اگه سازمان هزینشو داره حتماً به این سمت بره ولی نگهداری سیستم هایی که Always on روش هست سخت میشه به نظر من دیگه اونجا یا DBA میخواد یا باید به یه مجموعه بیرونی تکیه کند Out Source کند اون براش نگهداری کنه چون که مسائل  Networkچیزهای دیگه دخیل میشن و ممکنه یه مشکلاتی ایجاد کنه که تو اون نود سینگلی که قبلا داشت این مشکلات وجود نداشت غالباً تو دنیا همینه دیگه شما هر راهکاری، هر ماشین خوبی هم که میخواید خریداری کنید باید بهاش رو پرداخت کنید

بنابراین راه اندازی  HA و به سمت  Always on رفتن علاوه بر اینکه بهاش باید بدی و سخت افزار اولیه را خریداری کنی هزینه بابتش بکنی بابت نگهداریش هم باید بهاش رو بدید

+ پس شما اینکه میفرمایید چون اینها در واقع چیزی اضافه بر سازمان نسبت به سایر راهکارها ندارد منطقا ادم میره سراغ بهترین راهکار نیازی نیستش که بخوام یک مسیری رو طی بکنم به اون بخوام برسم اگر ندارم میرم سراغ Always on

مسیر پیاده سازی HA در سازمان‌ها

(از زمان  24:22 تا 34:25)

+ آقای دکتر من دو تا سوال دارم میخوام این دورو ترکیب بکنم یکی می‌خوام در ارتباط با مسیر پیاده سازی  HA سوال بکنم بپرسم که از خدمت شما که از بعد سخت افزار از بعد منابع انسانی من الان میخوام همین الان شروع کنم به پیاده سازی HA چه مسیری را باید طی بکنم فرضا یک سیستم اتوماسیون اداری دارم یا سیستم‌های مشابه دارم میخوام در واقع کار شروع بکنم من اون Tech نیستم من در واقع هد سازمانم که در جزئیات نیستم ولی مسیر را به صورت کلی میخوام بدونم که به چه ترتیبه؟ سوال اولم این هست. سوال دومم این هستش که بهترین پیاده سازی HA چی هستش من میدونم که در واقع خیلی جاها شما اشاره فرمودید که در خصوص در واقع عرضم به حضور شما که توزیع بارو وارد بازی بکنیم حالا که داریم HA پیاده سازی می‌کنیم حالا بیایم علاوه بر گارانتی در دسترس پذیری دیتا از بعدResponse Time  هم بالاتر ببریم و اینکه اون ریسک در واقع نگهداشت دیتا توی یک مکان فیزیکی را با پخش کردن نودها از بعد مکان‌های فیزیکی کاهش بدیم و و مباحث دیگه که شما قطعا بهتر از من میدونید لذا در واقع در ارتباط با این بحث و در ارتباط با بهترین روش در واقع میخواستم که از تجارب شما استفاده کنم

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

+ میتونم بهترین روش رو ازتون داشته باشم اگر شما بخواهید ترسیم بکنید در واقع یکی از تجربه‌ی خیلی خوب رو چه پیشنهادی میکنید فرض بکنید که سازمان میخواد هزینه بکنه سیستم، سیستم پر اهمیتی هستش باید up time بالا باشه down time  کم باشه تقریبا به صفر نزدیک بشه به چه ترتیبی باید باشه؟ شما پیشنهادتون چی هست؟

– بهترین روش که واقعا باید رفت تو اون سازمان دید ولی یه شرایط در واقع استانداردی اگر بخواهیم براش در نظر بگیریم همون سه نودی هست که خدمت شما عرض کردم یعنی هم HA و هم DR بگیم داخل اون دیتاسنتر دوتا نود باشه اولیه (primary) و ثانویه (secondary) و یه نود دیگر را ترجیحاً خارج از اون دیتاسنتر به عنوان DR در نظر بگیرند که خوب نودهایی که داخل یک دیتا سنتر هستند با اون به صورت سنکرون باشند سینک باشه دیتاشون low data less باشه و حالا میشه اونی که به عنوان DR خارج از اون مجموعه قرار دادیم به صورت آسنکرون باشه عملاً delay نداره فقط بحث سر اینه که اولیه نود (primary) وقتی دیتا رو مینویسه منتظر نمی‌مونه که نود ثانویه secondary بهش بگه من نوشتم تو هم برو کامیت کن چون توی سنکرون همینه شما رو نود A دیتا را وارد میکنید این دیتا میره رو نود B نوشته میشود نود B به نود  Aمیگه من نوشتم خیالت راحت کامیت کردم توام برو کامیت کن پس low data lost هست و یعنی اینکه کاملا سنکرونه ولی اون مدل آسنکرن نود A مینویسه دیگه منتظر نود  C نمی‌مونه کامیت میکنه ولی به طور واقعی معمولا اون هم data lost توش نیست ولی چون منتظر نمی‌مونه بنابراین اینجا  sql server تضمین نمیکنه میگه تو مدل آسنکرن ممکنه  data lost داشته باشه بحث DR خوبه چون خیلی کم پیش بیاد مسئله DR بخواد اتفاق بیفته بنابراین عملا data lost هم داخلش نیست.

+ آقای دکتر خیلی تشکر میکنم خستتون که نکردم من یه سوال دیگه ازتون دارم؟

– خواهش میکنم اختیار دارید

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

– به نظرم خیلی سوال خوب و مهمیه اینکه راه اندازی HA هم میتونه باعث افت عملکرد بشه و هم میتونه باعث افزایش عملکرد بشه هر دو هست اول قسمت خوبش رو بگم بعد قسمت بدش رو. اولین خوبیش اینه که شما میتونید  load  balancer راه اندازی کنید، بار بک آپ گیری رو بذارید روی نود ثانویه، خیلی پیش میاد تو خیلی سیستم ها اصلا بچه های عملیات میخواهند Selecet مستقیم رو بانک بزنند یک سری اطلاعات استخراج کنند و ممکنه query هاشون هم خیلی تیم شده memory سیستم را بگیره باید میتونید هدایتشون سمت نود ثانویه (secondary) و تاثیری روی نود اولیه (primary) نداره پس همه اینها یعنی افزایش عملکرد اما از اون طرف ممکنه بستر مناسب نباشه برای سینک شدن بین دوتا نود و ما همیشه تو بحث rebuild-index  که خیلی لایه زیاد تولید میکنه شما میتونید توی وقتی که سینگل نود هست قبل از، rebuild ریکاوری مدلتون رو از  full به back log تغییر بدید و مینیموم لاگ رو برای شما تولید کنه و دوباره به full برش گردونید ولی وقتی ما always on  داریم نمیتونیم این کارو بکنیم و میبینیم که زمانی که rebuild-index رخ میده این ترانزکشن‌هایی که باید بره سمت نود ثانویه (secondary) اجرا بشه پهنای باند شبکرو گرفته و خب اینها هم قسمت های  بدشه ولی در مجموع اگه بخوام نتیجه گیری کنم اگه بستر مناسب داریم حتما باید به سمت راه اندازی HA که ما توی محیط sql server میگیم  always on حتما باید به این سمت بریم

+ یعنی محسناتش به بدیاش میچربه

– بله

+  آقای دکتر من خیلی یاد گرفتم خیلی تشکر میکنم ازتون

– خواهش میکنم اختیار دارین، خواهش میکنم سلامت باشین

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