Setting up SharePoint Disaster Recovery Sites with SQL AlwaysOn
بطور کلی درحال حاضر چیزی که من به عنوان یک استراتژی اساسی برای رسیدن به high-availability از آن صحبت می کنم، ایجاد Disaster Recover (DR) برای سایت های شیرپوینت است. DR در سایت های شیرپوینت در تعریفی ساده عبارت است از فارم های مجزایی که از یک کپی از content data استفاده کرده و در صورت بروز بحران در فارم اصلی یا اول به هر دلیلی، بتوانیم با بدون از دست دادن وقت از فارم دوم به عنوان جایگزین استفاده کنیم.
نکته: در صورتی که می خواهید در خصوص مفهوم SharePoint DR بیشتر مطالعه کنید، پیشنهاد می کنم به یکی از پست های Microsoft blog مراجعه نمائید.
پیاده سازی Disaster Recovery با استفاده از SQL Server AlwaysOn بدین صورت اتفاق می افتد که با sync شدن content DB فارم اصلی فعال است (منظور این است که content DB فعال و در حال سرویس دهی است) به فارم ثانویه که content DB آن read-only است اتفاق می افتد. البته تا زمان رخ دادن failover. زمانی که failover اتفاق می افتد، ما فارم passive یا ثانویه را فعال می کنیم و همه چیز را به وضعیت read/write می بریم. تا زمانی که مشل فارم اصلی برطرف گردد.
به صورت سنتی این کار توسط تکنولوژی log-shipping انجام می شد. تکنولوژی که با این که خوب کار می کند ولی تا حد زیادی ابتدایی و basic است. از سال 2015 تکنولوژی جدیدی برای همگام سازی content DB توسط شرکت Microsoft ارائه شد که نام آن SQL Server AlwaysOn است.
این مقاله در خصوص استفاده از SQL Server AlwaysOn است یک content DB را برای یک فارم DR شیرپوینت همگام و یا sync می کند. مشابه عمل log-shipping در SQL Server، اما دلایل مختلفی بهتر (لطفا تصویر زیر را مشاهده کنید).
از احاظ منطقی کاملا مشابه راه اندازی SharePoint Disaster Recovery با استفاده از log-shipping است با این تفاوت که بروزرسانی بسیار بهتر و اتوماتیک تری در خصوص content DB خواهیم داشت.
مقایسه Disaster Recovery شیرپوینت با استفاده از SQL Server AlwaysOn با Log
SQL Server AlwaysOn راه بسیار خوبی برای همگام سازی پایگاه های داده بین سایت ها است. چرا؟
- Transaction ها به جای آن که به صورت دسته جمعی و هر X دقیقه (توسط فایل های TRN) پردازش شوند، تک تک انتقال می یابند.
- تفاوت بزرگتر: تغییر از فارم اصلی به فارم ثانویه و مجددا برگشت به فارم اصلی نیاز به تهیه نسخه پشتیبان کامل و بازیابی آن نیست. هر بار که در فارم اولیه قطعی یا failover اتفاق بیوفتد، بعد از برگشت فارم اولیه به صورت اتوماتیک است و نود ثانویه به صورت خودکار به روز رسانی نود فعال شده را انجام می دهد. اگر content DB با حجم قابل توجهی داشته باشید، این یک مزیت بسیار بزرگ است.
البته AlwaysOn نیاز به تنظیمات بیشتری دارد و برای راه اندازی پیچیده تر است (یعنی windows failover clustering و محدودیت هایی که clustering می تواند ایجاد کند). با این همه، اجرا تنظیمات آن بسیار انعطاف پذیر تر است.
هر پایگاه داده شیرپوینت در یک AlwaysOn Group
محدودیت کوچکی در زمان استفاده از SQL Server AlwaysOn وجود دارد و آن هم این است که هر SQL Server تنها می تواند در یک AlwaysOn Group باشد. بدین معنی که هر پایگاه داده ای که برای همگام سازی در یک AlwaysOn قرار گرفته است، نتیجتا زمان تنظیم automatic-failover برای یک فارم قادر به استفاده disaster-recovery نمی باشید. به خاطر این محدودیت شما موظف به اولویت دادن یکی بر دیگری خواهید بود.
برای درک بهتر پیاده سازی به نقشه پایین توجه کنید:
اگر شما می خواهید به صورت حرفه ای این مطلب را درک کنید، اینطور به نظر می رسد که single-point of failure در هر فارم وجود دارد و همچنین هر SQL Instance نیز می تواند در یک failover cluster باشد. نکته این است که زمانی که از AlwaysOn استفاده کرده باشیم، هیچ failover محلی در AlwaysOn-land برای content DB ما وجود ندارد، زیرا زمان استفاده از AlwaysOn تنها تغییرات رخ داده در content DB به فارم بازیابی منتقل می شود.
شما همچنین از لحاظ فنی می توانید همزمان replica content DB را به SQL-N1 انجام دهید و علاوه بر آن همزمان به SQL-N3، اما توجه داشته باشید که بدون استفاده ار شنونده یا listener (که از تمام replica members استفاده می کند) از ارزش آن کم خواهد شد. همچنین با اضافه کردن یک replica همزمان دیگر در SQL-N4 برای تقارن در سایت DR، به نتیجه خواهیم رسید که اوج سرعت اجرا غیرهمزمان در سایت DR را از دست خواهیم داد. به طور خلاصه بهتر است فقط دو نسخه ناهمزمان replica برای content database در AlwaysOn Group با یک نمونه replica جداگانه در هر سایت داشته باشیم.
به نظر می رسد کمی از هدف اصلی گمراه شدیم. در حال حاضر هدف ما تمرکز بر روی بخش میانی کار است.
تنظیم AlwaysOn Group برای Content Database
در مقاله دیگری طریقه راه اندازی SQL Server AlwaysOn Group را توضیح داده ام. ولی به طور کلی با استفاده از Wizard می توانیم مراحل مورد نیاز را انجام دهیم. برای ادامه راه کافی است در SSMS روی گزینه Always On High Availability کلیک کرده و گزینه New Availability Group Wizard را انتخاب نمائید. برای ادامه اسم مناسبی انتخاب کرده، سپس Content db مورد نظر خود را انتخاب کنید. در ادامه تنظیماتی که می تواند جالب تر باشد را خواهیم داشت:
به این نکته توجه کنید در زمان failover این که به صورت خودکار از یک فارم به فارم دیگر سوییچ کنیم هدف ما نیست و همچنان فعال سازی فارم ثانویه نیاز به انجام کارهایی به صورت دستی دارد. نتیجتا به خاطر داشته باشید که در سوییچ کردن به یک DR که inactive است در زمان failover نیاز به اعلام دستی به SQL Server AlwaysOn Group برای content database دارد.
تست سایت DR/Passive
زمانی که content database به AlwaysOn Group اضافه شد، حال می توانیم همانند سایر موارد content database را به فارم دوم اضافه کنیم. فقط توجه کنید که read-only است.
حال content database را به برنامه اضافه کرده و صحت عماکرد آن را در مرورگر خود بررسی کنید. حتما در ادامه می خواهید search را در فارم دوم تنظیم کنید؛ همچنین به بررسی منابع محتوا و crawl schedules نیاز خواهید داشت.
برای تاکید به این نکته توجه کنید که من URL را sp15-failover رها کرده ام. ولی در سناریوهای واقعی شما می بایست برای هر فارم alternative-access-mappings داشته باشید.
Failovers فارم شیرپوینت
زمانی که فاجعه یا همانfailover در سایت ثانویه یا passive رخ می دهد، حداقل کارهای مورد نیاز عبارتند از:
- Failover برای SQL Server AlwaysOn روی content database مورد نیاز خواهد بود نتیجتا فارم ثانویه می بایست دسترسی read/write داشته باشد.
- به شدت توصیه می شود: dismount/mount انجام نشود. بروز رسانی content database انجام گردد نتیجتا فارم ثانویه می تواند بروزرسانی فهرست site-collection را انجام دهد. (در تصاویر زیر می تواندی ببینید)
- حتما DNS های خود را برای انتقال درخواست های HTTP به فارم ثانویه انجام دهید.
- در صورتی که از revers-proxy استفاده می کنید این کار ساده تر خواهد بود. آدرس back-end را تغییر دهید و نیازی به تغییر DNS نخواهید داشت.
قدم اول آن است که تنظیمات مورد نیاز content database را انجام دهیم:
طبیعتا در زمان انجام تنظیمات با هشدارهای زیادی روبرو خواهید شد از قبیل احتمال از دست دادن اطلاعات که البته احتمال بسیار کمی دارد.
و نهایتا نتیجه را می توانید در زیر ببینید:
بسیار عالی؛ تا به این جا سایت DR به read/write تبدیل شد.
همانطور که قبلا ذکر شد، بسیار توصیه می شود که مجددا content database را dismount/mount کنید، بنابراین site-collectionهای جدید توسط فارم ثانویه دیده خواهند شد.
نکته مهم: در واقع راه حل بهتری برای بروزرسانی Content DB بجای dismount کردن وجود دارد. SPContentDatabase.RefreshSitesInConfigurationDatabase. می توانید به سادگی دستور زیر را اجرا کنید که نتیجتا Content DB را بروزرسانی خواهد کرد:
Get-SPContentDatabase | foreach { $_.RefreshSitesInConfigurationDatabase(); }
بسیار خوب، شما برای انتقال کاربران به فارم ثانویه آماده اید.
بسیار مهم: ادامه همگام سازی داده ها بعد از Failover
نکته بسیار مهم آن است که بعد از رفع مشکلات و برگشت شرایط به حالت قبل می بایست به صورت دستی همگام سازی اطلاعات را بر روی فارم اصلی ادامه دهید و سپس فارم ثانویه را مجددا به حالت read-only برگردانید.
برای انجام این کار دلیل مهمی وجود دارد: instance اصلی SQL به زور اطمینان نمی تواند بفهمد که SQL اصلی فعلی همه اطلاعات دقیقا قبل از شکست یا failover را دارد یا خیر که البته به دلیل نحوه تنظیمات ماست. نتیجتا آنچه که instance اصلی قدیمی انجام می دهد آن است که content خود را فریز کرده و از هرگونه بروزرسانی جلوگیری می کند. و این تا زمانی است که شما به عنوان admin سیستم تایید کنید که همه چیز به حالت عادی برگشته است و عملیات همگام سازی می تواند به وضعیت قبلی و طبیعی بازگردد.
اگر در خصوص مشکلات بالقوه بعدی نگران هستید بهتر از مشاوره یک DBA کمک بگیرید. SQL Server تنها مطمئن می شود تا زمانی که شما مایل به ادامه همگام سازی نشده اید، در پایگاه داده ای که بروزتر است چیزی تغییر پیدا نکند. شاید این تنها محدودیت Availability Group باشد و نگرانی دیگر یا کمبود دیگری در این روش وجود نخواهد داشت.
در هرصورت، برای ادامه همگام سازی داده ها می بایست دستور زیر را بر روی instance اصلی گذشته که در حال حاضر ثانویه شده است اجرا کنید:
ALTER DATABASE WSS_Content SET HADR RESUME
بعد از اجرای این دستور همه چیز به حالت نرمال بر می گردد و همه تغییرات در صورت نیاز همگامی می گردد و شرایط آماده failover جدید در صورت نیاز است.در صورت نیز به اطلاعات بیشتر در خصوص این دستور به مقاله ای در این زمینه مراجعه کنید.
تست Failover بر روی سایت DR در شیرپوینت
شیرپوینت بلافاصله بعد از دسترسی read/write متوجه این اتفاق می شود و به حالت عادی باز می گردد.
تا به اینجا سایت Failover ما به عنوان فارم اصلی شیرپوینت فعال است. اگر به SQL-N2 توجه کنید به read-only replica تبدیل شده است و در حال حاضر در حال دریافت اطلاعات برای همگام سازی خود از روی سایت اصلی است که داداه آن بر روی instance به نام SQL-N3 قرار دارد.
دلیل اصلی برتری استفاده از AlwaysOn نسبت تکنولوژی log-shipping آن است که با چند حرکت ساده که در بالا ذکر شد می توانید به شرایط قبل از وقوع failover بازگردیم. در صورتی که در زمان استفاده از log-shipping می بایست شروع به گرفتن backup و همچنین restore کردن آن برویم و همچنین می بایست log-shipping را مجددا تنظیم کنیم که خود زحمت بسیاری به همراه خواهد داشت. ولی با استفاده از AlwaysOn نیاز به دست زدن به بانک اطلاعاتی خود نداریم.
همانطور که ملاحظه کردید این مقاله در خصوص راه اندازی disaster-recovery با استفاده از SQL Server AlwaysOn است. طبیعتا تمام جزئیات را پوشش نداده است ولی ایده کلی پیاده سازی این طرح را می توانید با مطالعه این مقاله کسب کنید. اگر در خصوص این روش ها و توضیحات نکته و یا شک و تردیدی دارید خوشحال می شویم با درج توضیحات و نظرات خود ما را مطلع سازید. امیدوارم این سلسه مقالاتی که در خصوص HA ارائه شد بتواند شما را در رسیدن به مطمئن ترین سیستم های ممکن یاری رسانیده باشد.
