مایکروسافت SQL Server و قابلیت دسترسی بالا: گروه‌های Always On Availability در مقابل نمونه‌های Failover Cluster – کدام را انتخاب کنیم و چه زمانی؟

مایکروسافت SQL Server، احتمالاً یکی از شناخته‌شده‌ترین و پرکاربردترین سامانه‌های مدیریت پایگاه داده در جهان محسوب می‌شود. در مبحث پایگاه‌های داده، دو جنبه اساسی مطرح است: سرعت و قابلیت دسترسی. در این مقاله، تمرکز اصلی بر روی جنبه قابلیت دسترسی خواهد بود؛ چرا که اغلب درآمد سازمان‌ها مستقیماً به داده‌های آنها وابسته است و از دست دادن این داده‌ها غیرقابل قبول خواهد بود.

خوشبختانه، مایکروسافت در سال 2012 این موضوع را درک کرده و در نسخه SQL Server خود، دو راهکار اصلی را معرفی نمود: گروه‌های Always On Availability (که به اختصار AG نامیده می‌شوند و نه AAG یا AOAG) و Always On Failover Cluster Instances (FCI). همچنین لازم به ذکر است که در این مقاله به دیگر مکانیسم‌های تکثیر مانند Storage Replication یا Log Shipping پرداخته نخواهد شد.

گروه‌های Always On Availability

پیش از هر چیز، لازم به توضیح است که قابلیت Database Mirroring همچنان در نسخه SQL Server 2022 وجود دارد، اما این ویژگی به عنوان یک قابلیت منسوخ (Deprecated) شناخته شده و مایکروسافت تشویق می‌کند تا به سمت استفاده از گروه‌های Availability (AG) حرکت شود.

گروه‌های Always On Availability مکانیسمی است که محیطی تکثیر شده برای مجموعه‌ای از پایگاه‌های داده فراهم می‌سازد. این محیط می‌تواند در دو حالت High Availability یا Disaster Recovery بر اساس نوع پیکربندی، عمل کند. پایگاه‌های داده‌ای که در این گروه قرار می‌گیرند، به عنوان Availability Databases شناخته می‌شوند. با توجه به عضویت این پایگاه‌ها در یک گروه، عملیات Failover به صورت همزمان و هماهنگ بین آنها صورت می‌پذیرد.

گروه‌های AG در سطح پایگاه داده عمل می‌کنند و هر مجموعه از پایگاه‌های داده Availability توسط دو نوع نسخه تکراری (Availability Replicas) میزبانی می‌شود: نسخه اصلی (Primary Replica) و نسخه‌های ثانویه (Secondary Replicas). نسخه اصلی امکان دسترسی‌های خواندن و نوشتن به پایگاه داده را فراهم می‌آورد و حداکثر تا هشت نسخه ثانویه می‌توانند به عنوان جایگزین در صورت بروز Failover عمل کنند. حالت Availability تعیین‌کننده نوع پیاده‌سازی HA یا DR است و همچنین گزینه‌های Failover را مشخص می‌نماید. دو حالت اصلی Availability عبارتند از: حالت Asynchronous-Commit و حالت Synchronous-Commit. به طور خلاصه، در حالت Asynchronous احتمال از دست رفتن داده‌ها وجود دارد، در حالی که حالت Synchronous تضمین می‌کند که هیچ داده‌ای از دست نرود اما این امر منجر به افزایش تأخیر در تراکنش‌ها می‌شود. انتخاب این حالت به اهمیت داده‌ها و میزان قابل قبول بودن از دست دادن داده‌ها (RPO) وابسته است.

استفاده از گروه‌های AG مستلزم وجود Windows Server Failover Cluster (WSFC) است. هر نسخه Availability بر روی یک گره جداگانه از WSFC میزبانی می‌شود و برای هر AG، نقش خاصی در کلاستر تعریف می‌گردد. برخلاف Database Mirroring، در گروه‌های Always On Availability نقش Witness حذف شده است و تعیین اکثریت (Quorum) بر اساس تعداد کل گره‌های موجود در WSFC صورت می‌گیرد، بدون توجه به اینکه آیا آن گره‌ها میزبان نسخه‌ای از پایگاه داده هستند یا خیر.

شایان ذکر است که گروه‌های Availability بدون کلاستر نیز وجود دارند که تحت عنوان Read-Scale Availability Groups شناخته می‌شوند، اما این نوع پیاده‌سازی نه برای High Availability و نه برای Disaster Recovery طراحی شده‌اند و فقط برای Failover دستی کاربرد دارند. همچنین نسخه MS SQL Server برای سیستم‌عامل لینوکس، امکان پیکربندی گروه‌های Always On Availability را داراست، اما برای پیاده‌سازی سناریوهای HA و DR نیازمند Pacemaker می‌باشد. با این وجود، تمرکز اصلی این مقاله بر بستر ویندوز است.

مزایای گروه‌های Always On Availability

مزایای استفاده از گروه‌های Always On Availability احتمالاً برای بسیاری آشکار است، اما به منظور جمع‌بندی، موارد زیر قابل اشاره است:

• گروه‌های AG از حداکثر ۹ نسخه Availability Replica پشتیبانی می‌کنند (یک نسخه اصلی و تا هشت نسخه ثانویه)؛

• امکان انعطاف‌پذیری در فرآیند failover وجود دارد: می‌توانید Failover دستی برنامه‌ریزی شده یا Failover خودکار را (در حالت synchronous-commit که بدون از دست رفتن داده است) انتخاب کنید و همچنین در حالت asynchronous-commit که احتمال از دست رفتن داده وجود دارد، Failover اجباری (Forced Failover) را انجام دهید؛

• برای استفاده بهینه‌تر از نسخه‌های ثانویه به جای اینکه صرفاً منتظر وقوع رویداد Failover باشید، می‌توانید آنها را در حالت فعال (Active) قرار دهید و به عنوان مثال از آنها برای انجام پشتیبان‌گیری یا استفاده در حالت فقط خواندنی (Read-Only) به منظور توزیع بار کاری بهره‌مند شوید؛

• پشتیبانی از رمزنگاری و فشرده‌سازی؛

• ارائه داشبورد Always On برای نظارت بر گروه‌های Always On Availability، نسخه‌های Availability و پایگاه‌های داده Availability.

محدودیت‌های گروه‌های Always On Availability

بدیهی است که هنگام کار با گروه‌های Always On Availability، برخی ملاحظات یا بهتر است گفته شود، محدودیت‌هایی وجود دارد که باید مورد توجه قرار گیرند:

• نسخه‌های Availability باید بر روی گره‌های متفاوتی از یک Windows Server Failover Cluster (WSFC) میزبانی شوند؛

• می‌توانید حالت asynchronous-commit را برای تمامی نسخه‌ها (یک نسخه اصلی و تا هشت نسخه ثانویه) استفاده کنید یا حداکثر تا پنج نسخه (شامل نسخه اصلی) را در حالت synchronous-commit قرار دهید؛

• برای انتقال گروه‌های Availability به گره‌های دیگر یا انجام فرآیند failover نباید از Failover Cluster Manager استفاده نمود؛

• لاگین‌های SQL Server، سرورهای مرتبط (Linked Servers)، کارهای Agent و موارد مشابه به صورت خودکار با پایگاه‌های داده ثانویه همگام‌سازی نمی‌شوند؛

نمونه‌های Always On Failover Cluster Instances (FCI)

نمونه‌های Always On Failover Cluster Instances (FCI) هدفی بسیار مشابه با گروه‌های Always On Availability (AG) دارند؛ یعنی ارائه دسترسی بالا (High Availability) برای SQL Server شما. تفاوت اصلی این است که FCI در سطح نمونه (Instance) سرور کار می‌کند. FCI نمایانگر یک نمونه واحد از SQL Server است که در گره‌های Failover Cluster مستقر شده است. در صورت بروز مشکلات سخت‌افزاری یا نرم‌افزاری در یک گره، نمونه SQL Server به گره دیگری منتقل (Failover) می‌شود.

مشابه گروه‌های AG، FCI نیز در یک Failover Cluster اجرا می‌شود و Quorum حفظ می‌گردد. تفاوت اصلی در ذخیره‌سازی است. در حالی که AG به هیچ گونه ذخیره‌سازی مشترک نیاز ندارد، FCI مستلزم نوعی از ذخیره‌سازی مشترک است. این ذخیره‌سازی می‌تواند شامل دیسک‌های کلاستر روی SANهای iSCSI یا Fiber Channel، Storage Spaces Direct، StarWind Virtual SAN یا اشتراک‌های فایل SMB باشد.

در این حالت، ذخیره‌سازی مشترک امکان انتقال FCI بین گره‌های کلاستر را فراهم می‌کند که این انتقال می‌تواند به صورت دستی (زمانی که نیاز به انجام نگهداری روی گره دیگر باشد) یا به صورت خودکار (در صورت بروز رویداد Failover واقعی) انجام شود. البته در هر لحظه تنها یک گره مالک نمونه SQL Server است.

بنابراین، تنظیمات خاصی برای تکثیر داده‌ها همانند AG وجود ندارد، چرا که عملیات Failover توسط Windows Server Failover Cluster (WSFC) مدیریت می‌شود و هیچ داده‌ای از دست نمی‌رود.

مزایای نمونه‌های Failover Cluster Instances (FCI)

مزایای اصلی استفاده از FCI برای دسترسی‌پذیری بالا (High Availability) در SQL Server به شرح زیر است:

• دسترسی‌پذیری بالا در سطح نمونه (Instance) SQL Server؛

• پشتیبانی از هر دو نوع Failover (خودکار و دستی برنامه‌ریزی‌شده) که توسط Failover Cluster مدیریت می‌شود؛

• انعطاف‌پذیری در انتخاب نوع ذخیره‌سازی مشترک مانند iSCSI یا SAN مبتنی بر Fiber Channel، اشتراک‌های فایل SMB و غیره؛

• عدم نیاز به پیکربندی مجدد برنامه‌ها و کلاینت‌های متصل به نمونه SQL Server در هنگام Failover؛ زیرا نام و آدرس مجازی نمونه ثابت باقی می‌ماند.

محدودیت‌های نمونه‌های Failover Cluster Instances (FCI)

با وجود مزایای متعدد در زمینه دسترسی‌پذیری بالا، استفاده از FCI دارای برخی محدودیت‌ها نیز می‌باشد:

• عدم امکان خواندن از پایگاه‌های داده ثانویه همانند AG، زیرا تنها یک نمونه SQL Server در هر لحظه فعال است؛ بنابراین، امکان توزیع بار خواندن (Load Balancing) وجود ندارد؛

• اتکا به یک ذخیره‌ساز SAN مشترک می‌تواند منجر به ایجاد یک نقطه شکست واحد (Single Point of Failure) شود؛

• فاقد قابلیت‌های بازیابی از فاجعه (Disaster Recovery) است؛ مگر آنکه با گروه‌های Availability (AG) ترکیب گردد.

تفاوت‌های بین گروه‌های Always On Availability و نمونه‌های Always On Failover Cluster

اکنون که با مفهوم گروه‌های Always On Availability و نمونه‌های Always On Failover Cluster و مزایا و معایب اصلی آنها آشنا شدیم، زمان آن رسیده که این دو را به صورت دقیق و موردی با هم مقایسه کنیم. بنابراین، بیایید ببینیم چه شباهت‌ها و تفاوت‌هایی بین این دو وجود دارد. همچنین لازم به ذکر است که مقایسه ما صرفاً بین AG و FCI به صورت مستقل است. امکان استفاده ترکیبی از این دو وجود دارد، اما این موضوع بحث جداگانه‌ای است.

ویژگی	گروه‌های Always On Availability (AG)	نمونه‌های Always On Failover Cluster (FCI)
نیاز به WSFC	بله	بله
سطح حفاظت	پایگاه داده	نمونه (Instance)
نوع ذخیره‌سازی	غیر مشترک (Non-shared)	مشترک (Shared)
نسخه‌های ثانویه قابل خواندن	بله	خیر
حالت‌های Failover	خودکار، دستی برنامه‌ریزی شده، اجباری	خودکار، دستی برنامه‌ریزی شده
مکانیزم در دسترس بودن	HA و DR	فقط HA
منابعی که در هنگام Failover منتقل می‌شوند	پایگاه داده	کل نمونه به همراه پایگاه داده‌ها

نتیجه‌گیری

گروه‌های Always On Availability و نمونه‌های Always On Failover Cluster هر دو هدف مشابهی دارند؛ فراهم آوردن دسترسی بالاتر برای SQL Server شما. اگرچه هدف کلی تقریباً یکسان است، اما مکانیزم‌های پشت این دو روش متفاوت است. AG ممکن است پیاده‌سازی و مدیریت پیچیده‌تری داشته باشد، اما گزینه‌های گسترده‌تری در زمینه High Availability و Disaster Recovery ارائه می‌دهد. FCI راهکاری ساده‌تر است که در سطح نمونه (Instance) کار می‌کند اما نیازمند نوعی ذخیره‌سازی مشترک است. در نهایت، همه چیز به زیرساخت خاص شما و اهدافی که می‌خواهید به آن‌ها دست یابید بستگی دارد. ممکن است یکی از این دو روش (یا ترکیبی از هر دو) برای شرایط شما مناسب‌تر باشد.