همانطور که تمامی دنبال کننده های MSSQLServer در جریان قابلیت Always-On این محصول هستند، ماکروسافت از گذشته قدیم با ارائه راه کارهایی از جمله Log Shipp ، Mirror ، Replication و … سعی داشته الگوریتم هایی در حوزه بحث ارتقاء Availability ارائه دهد، نهایت در سال 2008 با گسترش استفاده از مفاهیم Shared Storage ها (SAN) و در نسخه 2008R2 الگوریتمی تحت عنوان SQL Server Failover Cluster ارائه داد، که تکمیل کننده الگوریتم ها قبلی بود و نقطه قوت آن سطح پیاده سازی Availability بود، بدین ترتیب که در این الگوریتم، پروسه Instance Level بوده و کل سرویس SQL بصورت Redundant پیاده سازی میشد، در صورتی که در الگوریتم های پیش از این که نام برده شد، عموما Database Level بود( یک نمونه از دیتابیس را در چند سرور داشتیم) و یا حتی Data Level (یک نمونه از داده های،مثلا یکسری سطر و ستون از یکسری جدول را در جند سرور جدا داشتیم)پیاده سازی میشد.
مشخصا مزیت الگوریتم Instance Level بدین ترتیب معرفی میشود که در این حالت تمامی system database و user Database در استوریج مشترک قرار داده خواهد شد، و این استوریج همواره دست یک نود از کلاستر خواهد بود، در صورتی که نود Active دچار مشکل شود، پروسه Failover رخ داده و در نتیجه نود دیگر Active خواهد شد و استوریج تحویل آن خواهد شد، پس ما یک نسحه از هر دونوع دیتابیس های سیستمی و یوزری داریم، که در یک لحظه تحت مدیریت یک سرویس خواهد بود. این نکته خیلی مهم می باشد، چرا که در الگوریتم هایDatabase Level ،تارگت دیتابیس بود که منظور User Database است، پس system Database که حاوی Login ها Roleها و Permission هاو Job ها است، را شامل نشده و Admin در استفاده از این الگوریتم ها، باید بصورت دستی موارد نامبرده را برای هر سرور جداگانه تعریف کرده و سعی در سینک نگهداشتن آنها به روش های منوال کرده، تا در زمان Failover دیتابیس، مشکلی به دلیل عدم سینک بود در موارد نامبرده رخ ندهد (مثلا یک Login که در یک سرور تعریف شده، اگر در دیگری با همان SID نباشد، موقع فیلاور، گرچه user در دیتابیس می باشد، ولی چون Login متصل به آن وجود ندارد،امکان اتصال به دیتابیس نخواهیم داشت)
با پیشرفت علوم IT از سال 2012 تا سال 2016 بحث High Availability پیشرفت چشم گیری داشت، و سمتی حرکت کرد که بتوانیم سرویس ها را در بیش از یک دیتاسنتر داشته باشیم که به لحاظ جغرافیای از هم متمایز بوده و بعد مسافت و شبکه های مجزا مطرح شد، پس برای رسیدن به این هدف ، استفاده از SAN به عنوان یک نقطه متمرکز،کمرنگ تر شد، گرچه سرویس های زیر ساختی همانند ESX از کمپانی VMWare هنوز بر همان اگوریتم ها مبتنی بر Shared Storage تکیه کرده بودند و سعی می کردند با استفاده از Replicate کردن SAN تا حدودی خود را به اهداف طراحی توزیع شده برساند، ماکروسافت تصمیم گرفت روی الگوریتم تمرکز کرده و کل پروسه را تغییر دهد ، پس در سال 2012 برای اولین بار قابلیت AG را ارائه داد که معروف هست به Always on Availability Group، که تا سال 2016 آن را تا 90 درصد تکمیل کرد و نهایت در 2017 با اضافه کردن قابلیت های MS DTS و… جایی برای بحث نگزاشت و به عنوان پیشگام در حوزه High Availability در جهان مطرح شد.
در این الگوریتم پایه کار براساس Failover Cluster بوده ، و از قابلیت VIP برای کلاستر مشابه آنچه در SQL Server Failover Cluster دیدم استفاده می شود، اما اینبار نود Active به عنوان Primary بوده و Write ها را پاسخگو خواهد بود و نودهای Secondary نیز می توانستند همزمان پاسخ گو باشند و ترافیک Read را پاسخگو باشند که البته نحوه توزیع ترافیک Read توسط Primary به عنوان توزیع کننده مشخص میشد، و اما برای سینک شدن دیتا بیین سرور ها از الگوریتم مشابه آنچه در Mirror ارائه شده بود با کمی بهینه سازی استفاده میشود و خبری از استوریج مشترک SAN نبود و دیتا بروی هر سرور بصورت لوکال نگهداری شده و به راحتی می توانستیم از الگوریتم های توزیع شده نیز استفاده کنیم. لذا در ورژن 2019 به سمت الگوریتم Multi-Site AG رفته و در اواخر 2019 مفهوم Distributed AG مطرح شد و حال در 2022 مفهوم Contained AG مطرح شده است، و مشخص است که ماکروسافت در این حوزه مشغول بهینه سازی است. (این موضوع هم به نقل از بعضی از مقاله های ماکروسافت قابل ارائه است که ماکروسافت در یک بازه زمانی اینطور بحث High Availability را مطرح میکرد، که قابلیتی داریم به اسم Always-on که با دو الگرویتم AG و FC قابل پیاده است؛ اما بعد از تمرکز روی AG و ارائه انواع متفاوت آن، یواش یواش FC را از این کتگوری خارج کرد!)
اما نقطه ضعف AG بصورت پایه ، اینگونه مطرح بود که با توجه به اینکه دیتابیس ها در سرور ها بصورت لوکال نگهداری میشود، و همانطور که مطرح شد الگوریتم بر گرفته از الگوریتم Mirror برای سینک مورد استفاده بوده، لذا این پروسه بصورت Database Level پیاده سازی میشود، و دیتابیس های سیستمی بصورت لوکال در هر سرور بوده و بحث به روز نگهداشتن login، Permission و.. وحتی Job ها برعهده Admin خواهد بود. گرچه ماکروسافت تا 2022 تمرکز را بر روی انواع AG در جهت پیاده سازی هرچه تکمیل تر High Availability گذاشته بود، اما در 2022 سعی کرده روی این ضعف کار کند که بحث contained AG را مطرح کرد در ادامه به تشریح آن خواهیم پرداخت، اما قبل معرفی آن بد نیست بدانیم عموما برای این ضعف چگونه Admin ها کار را پیش میردند که البته سلیقه ای است:
1.برای انتقال تنظیمات سرور، باید Admin بصورت دستی هر گونه تغییرات در تنظیمات را در هر دو سرور اعمال کند و چه بسا ممکن است سرور ها به دلیل سخت افزار و شرایط متقاوت بوده، و لازم باشد تنظیمات متقاوت داشته باشند ، مثلا memory یکسان نداشته باشند یا… ولی مهم مدیریت بصورت دستی بود.
2.برای انتقال Link Server ها و Backup Device ها و موارد عمومی این چنین، نیز باید بصورت دستی، ادمین اقدام به سینک نگهداشتن اطلاعات می کرد.
3.برای انتقال Login ها با توجه به اینکه نباید ارتباط بین Login و User قطع شود، Login ها را باید با همان SID منتقل کنیم تا این ارتباط قطع نشود، و حتی نمی توان با استفاده از SP_Change_Users_Login این ارتباط را فراهم کرد، چرا که در secondary ها دیتابیس ها Read-Only می باشد.پس معمولا از SP_Help_revLogin تا Login ها با همان SID منتقل شوند، و البته برای عضویت در Server Role ها و پرمیژن هایی در سطح Login مجدد باید بصورت دستی اقدام به سینک نگهداشتن سرور ها میشد.
4.برای بحث SQL Agent و سینک نگهداری Job ها از قابلیت MSX-TSX میتوانستیم استفاده کنیم بدین تریتب که یک سرور نقش Master را گرفته و جاب ها در آن سرور ساخته و ویراش میشد، حال با انتخاب TSX ها بر روی سرورهای Target اعمال میشد.
برای شروع به تعریف Contained AG بد نیست مطالعه ای بر روی Contained Database داشته باشد، همانطور که در مقاله ای جداگانه اقدام به معرفی این قابلیت از SQL به عنوان ابزار امنیتی در محیط MSSQLSERVER مفصل بحث شده ، بصورت خلاصه با استفاده از قابلیت Contained Database این همه تنوع طراحی لایه ای (یعنی استفاده از login در سطح SQL و user در سطح دیتابیس) نادیده گرفته شده و می توانستیم مستقیم یوزرهایی با پسورد در لایه دیتابیس داشته باشیم، که مشخصا بدون داشتن Login به SQL وصل شده و قطعا توانایی انجام هیچ موردی در سطح سرور نداشته وفقط می توانستند به همان دیتابیسی که در آن تعریف شده متصل شوند….
در Contained AG با هدف متمرکز کردن تنظییمات SQL ائم از ساخت Login ها و …. ساخت Job ها و… درسطح کلاستر و حرکت به سمت Instance Level شدن الگرویتم AG، با توجه به اینکه تنظیمات فوق در Master و MSDB نگهداری میشوند، علاوه بر Master و MSDB که هر سرور بصورت لوکال داشته، یک Master و MSDB جدیدی برای AG در نظر گرفته خواهد شد که همانند دیگر User DataBase ها روی همه نودهای کلاستر سینک خواهد شد! پس در اتصال به Listener از AG، از این دیتابیس های سیستمی استفاده خواهد شد و بدین ترتیب نیازمند سینک نگهداشتن job و تظنیمات سرور نخواهیم بود!
برای راه اندازی این قابلیت به شرط داشتن SSMS ورژن 19 ( در زمان تهیه این نوشتار نسخه beta3 آن ارائه شده است) در زمان راه اندازی بصورت زیر اقدام می کنیم:
نکته جالب این هست که با زدن چک باکس در زمان راه اندازی یک Master و MSDB جدید ساخته میشود که از با نام کلاستر آغاز خواهند شد که در لیست User Database ها وقتی بصورت لوکال به نودها وصل میشویم قابل مشاهده است، ولی زمانی که به لیسنر وصل میشویم به منظور User Friendly شدن، از دید کاربر متصل به VIP،این دو دیتابیس بصورت Transparent در نظر گرفته شده است (خیلی جالب که حتی دیتابیس های داخل AG نیز وقتی به لیسنر وصل میشویم عبارت Synchronized را مقابل نام دیتابیس ندارد و اگر دیتابیسی داخل AG نباشد، موقع اتصال به لیسننر نمایش داده نمیشود در صورتی که پیشتر بعد از اتصال به VIP و هدایت به سمت یکی از نودها، همه دیتابیس های آن نود را ائم از داخل AG یا بیرون AG نمایش میداد.)
نکته جالب تر اینکه بعد از اتصال به VIP خبری از فولدر Availability Group نیست:
اما حال بحث این است که با ساخته شدن، Master و MSDB برای AG، چه اطلاعاتی به آنها در بدو شروع منقتل شود و از کجا منتقل شود؟ طبق شواهد در مورد Login ها sysadmin های اولین نود AG همگی به دیتابیس های سیستمی جدید منتقل شدند ، ولی هیچ جاب و دیگر تنظیماتی منتقل نشد. حال یک تیک داریم به اسم Reuse System Database که از اسمش اینطور مشخص است که در شروع کار Master و Model خام نمی سازد و علاوه بر sysadmin ها، همه اطلاعات نود Primary را واکشی میکند و در واقع یک کپی از آن دیتابیس ها برای ما در نظر میگیرد، ولی تا این لحظه اینکار را نکرد! پس معنی این گزینه چیست؟ در بررسی مشخص شد، وقتی یک AG از نوع Contained می ساختیم، نتیجه کار بعد از مراجعه به نود Primary به شکل زیر بود یعنی Master و MSDB با پیشوند نام AG:
خوب حال در این شرایط فرض کنید به دلیلی AG را حذف کردیم (آیا تمامی Login و Job و … نیز از بین خواهد رفت؟)، و خواستیم مجدد همان AG را راه اندازی کنیم(نیازمند همان Login ها و Job ها و… خواهیم بود) شاید این فکر خطور کند که دیتابیس های فوق با حذف AG حذف می شوند ولی جالب است بدانیم این دو دیتابیس باقی خواهند ماند ولی به شکل ساده و همانند دو User DataBase
اگر اسم AG حذف شه S22 باشد(تاکید اسم AG هست نه اسم لیسنر)
حال که مجدد AG با همان نام بسازیم، با فعال کردن گزینه Reuse System Database از همان دیتابیس ها استفاده خواهد کرد که در نتیجه تمامی یوزر ها و لاگین ها باز خواهد گشت
سوال : آیا میشه از این روش تنظیمات یک AG را برای یک AG دیگه استفاده کرد، با Rename یا انتقال Master و MSDB این دیتابیس ها؟ جواب بله هست
برای شرکت در دوره آموزش جامع SQL Server می توانید از این لینک اقدام به مطالعه مباحث و ثبت نام نمایید.
