فصل ۲

بهبودهای دسترس‌پذیری بالا و بازیابی پس از فاجعه

Microsoft SQL Server 2012 بهبودهای مهمی را برای قابلیت‌های حیاتی و شناخته‌شده‌ای مانند دسترس‌پذیری بالا (High Availability یا HA) و بازیابی پس از فاجعه ارائه می‌کند. این بهبودها به سازمان‌ها کمک می‌کنند بالاترین سطح اطمینان خود تا به امروز را در محیط‌های سرور به دست آورند. پشتیبانی از Server Core، ویژگی‌های تحول‌آفرینی مانند گروه‌های دسترس‌پذیری AlwaysOn و رپلیکاهای ثانویهٔ فعال، و بهبودهای کلیدی در قابلیت‌هایی مانند خوشه‌بندی Failover، گزینه‌های متنوع و سازگاری را در اختیار سازمان‌ها قرار می‌دهند تا برای نمونه‌ها و پایگاه‌داده‌های SQL Server درون یک مرکز داده یا میان چند مرکز داده، بیشترین دسترس‌پذیری برنامه و حفاظت از داده را به دست آورند.

هدف این فصل آن است که خوانندگان را با قابلیت‌های دسترس‌پذیری بالا و بازیابی پس از فاجعه که در نتیجهٔ سرمایه‌گذاری گستردهٔ مایکروسافت روی AlwaysOn به‌طور کامل با SQL Server 2012 یکپارچه شده‌اند، به‌روز کند.

SQL Server AlwaysOn: راهکاری انعطاف‌پذیر و یکپارچه

موفقیت و اعتبار خدمات هر سازمان بر این پایه استوار است که داده‌های آن همواره در دسترس و محافظت‌شده باشند. در دنیای فناوری اطلاعات، این موضوع به معنای ارائهٔ محصولی است که ضمن کمینه‌کردن ازدست‌رفتن داده و زمان توقف، بالاترین سطح دسترس‌پذیری و بازیابی پس از فاجعه را فراهم کند. در نسخه‌های پیشین SQL Server، سازمان‌ها با استفاده از فناوری‌هایی مانند خوشه‌بندی Failover، Database Mirroring، Log Shipping و تکثیر همتا‌به‌همتا (Peer-to-peer Replication) به دسترس‌پذیری بالا و بازیابی پس از فاجعه دست می‌یافتند. با وجود موفقیت چشمگیر این راهکارها، سازمان‌ها ناچار بودند برای برآورده‌کردن نیازهای کسب‌وکار مرتبط با هدف نقطهٔ بازیابی (Recovery Point Objective یا RPO) و هدف زمان بازیابی (Recovery Time Objective یا RTO)، چند فناوری بومی SQL Server را با یکدیگر ترکیب کنند.

شکل ۲-۱ یک راهبرد رایج دسترس‌پذیری بالا و بازیابی پس از فاجعه در نسخه‌های پیشین SQL Server را نشان می‌دهد. این راهبرد برای محافظت از نمونه‌های SQL Server در هر مرکز داده از خوشه‌بندی Failover و برای فراهم‌کردن بازیابی پس از فاجعهٔ پایگاه‌داده‌های مأموریت‌حیاتی از Database Mirroring ناهمگام استفاده می‌کند.

به همین ترتیب، سازمان‌هایی که به بیش از یک مرکز دادهٔ ثانویه نیاز داشتند یا ذخیره‌سازی اشتراکی در اختیار نداشتند، در استقرار دسترس‌پذیری بالا و بازیابی پس از فاجعهٔ خود، Database Mirroring همگام همراه با یک Witness را در مرکز دادهٔ اصلی با Log Shipping برای انتقال داده به چندین مکان ترکیب می‌کردند. این راهبرد استقرار در شکل ۲-۲ نشان داده شده است.

شکل‌های ۲-۱ و ۲-۲ هر دو راهکارهای موفقی برای دستیابی به دسترس‌پذیری بالا و بازیابی پس از فاجعه را نشان می‌دهند. با این حال، این راهکارها محدودیت‌هایی داشتند که تغییر را ضروری می‌کرد. افزون بر آن، سازمان‌ها پیوسته در حال تحول بودند و طبیعی بود که پس از مدتی نگرانی‌های خود را بیان کنند و گزینه‌ها و تغییرات بیشتری بخواهند.

یکی از نگرانی‌های بسیاری از سازمان‌ها به Database Mirroring مربوط می‌شد. این فناوری روش مناسبی برای حفاظت از پایگاه‌داده است، اما نگاشت آن یک‌به‌یک است و در نتیجه امکان داشتن چند رپلیکای ثانویه وجود ندارد. بسیاری از سازمان‌ها در چنین شرایطی به‌جای Database Mirroring از Log Shipping استفاده می‌کردند، زیرا Log Shipping از چند مقصد ثانویه پشتیبانی می‌کند. متأسفانه Log Shipping نیز محدودیت داشت، زیرا ازدست‌نرفتن صفرِ داده و Failover خودکار را فراهم نمی‌کرد. سازمان‌هایی که با خوشه‌بندی Failover کار می‌کردند نیز نگران بودند که تجهیزات ذخیره‌سازی اشتراکی مانند شبکهٔ ذخیره‌سازی (Storage Area Network یا SAN) به نقطهٔ شکست منفرد تبدیل شوند. همچنین بسیاری از سازمان‌ها معتقد بودند سرمایه‌گذاری‌هایشان از دید هزینه به‌طور کامل استفاده نمی‌شود؛ برای مثال، سرورهای Passive در بسیاری از این راهکارها بیکار بودند. در نهایت، سازمان‌های زیادی می‌خواستند گزارش‌گیری و وظایف نگه‌داری را از سرورهای اصلی پایگاه‌داده منتقل کنند، اما انجام این کار ساده نبود.

SQL Server برای پاسخ‌گویی به بسیاری از این نگرانی‌ها تکامل یافت و راهکار یکپارچه‌ای با نام AlwaysOn را ارائه کرد. AlwaysOn Availability Groups و AlwaysOn Failover Cluster Instances ویژگی‌های جدیدی هستند که در SQL Server 2012 معرفی شده‌اند، گزینه‌های فراوانی دارند و بالاترین سطح دسترس‌پذیری و بازیابی پس از فاجعه را برای مشتریان فراهم می‌کنند. در سطح کلان، AlwaysOn Availability Groups برای حفاظت از پایگاه‌داده به کار می‌رود و Failover چندپایگاه‌داده‌ای، چند رپلیکای ثانویه، رپلیکاهای ثانویهٔ فعال و مدیریت یکپارچهٔ دسترس‌پذیری بالا را ارائه می‌کند. در مقابل، AlwaysOn Failover Cluster Instances برای حفاظت در سطح نمونه، خوشه‌بندی چندسایتی و تجمیع طراحی شده است و در عین حال سیاست‌های انعطاف‌پذیر Failover و تشخیص‌های بهبودیافته را فراهم می‌کند.

گروه‌های دسترس‌پذیری AlwaysOn

AlwaysOn Availability Groups یک جایگزین سازمانی برای Database Mirroring است و به سازمان‌ها امکان می‌دهد گروهی از پایگاه‌داده‌ها را به‌عنوان یک واحد، به‌صورت خودکار یا دستی Failover کنند. این راهکار از حداکثر چهار رپلیکای ثانویه پشتیبانی می‌کند، حفاظت بدون ازدست‌رفتن داده را فراهم می‌سازد و انعطاف‌پذیر است. می‌توان آن را روی ذخیره‌سازی محلی یا اشتراکی مستقر کرد و هر دو جابه‌جایی همگام و ناهمگام داده را پشتیبانی می‌کند. Failover برنامه بسیار سریع است، تعمیر خودکار صفحه پشتیبانی می‌شود و می‌توان از رپلیکاهای ثانویه برای انتقال بار گزارش‌گیری و برخی وظایف نگه‌داری مانند نسخهٔ پشتیبان استفاده کرد.

شکل ۲-۳ یک راهبرد استقرار AlwaysOn Availability Groups را با یک رپلیکای اصلی و سه رپلیکای ثانویه نشان می‌دهد.

در این شکل، جابه‌جایی همگام داده برای فراهم‌کردن دسترس‌پذیری بالا درون مرکز دادهٔ اصلی و جابه‌جایی ناهمگام برای بازیابی پس از فاجعه استفاده می‌شود. همچنین Replica3 و Replica4 برای انتقال بار گزارش‌ها و نسخه‌های پشتیبان از رپلیکای اصلی به کار گرفته شده‌اند.

اکنون زمان آن است که با مرور مفاهیم و اصطلاحات جدید مرتبط با این قابلیت تحول‌آفرین، بررسی عمیق‌تری از AlwaysOn Availability Groups انجام دهیم.

شناخت مفاهیم و اصطلاحات

گروه‌های دسترس‌پذیری روی Windows Failover Clustering ساخته می‌شوند و هم از ذخیره‌سازی اشتراکی و هم غیرمشترک پشتیبانی می‌کنند. بسته به الزامات RPO و RTO سازمان، گروه دسترس‌پذیری می‌تواند برای جابه‌جایی داده میان رپلیکاهای اصلی و ثانویه از حالت دسترس‌پذیری با ثبت ناهمگام (Asynchronous-commit) یا ثبت همگام (Synchronous-commit) استفاده کند. گروه‌های دسترس‌پذیری دارای فشرده‌سازی و رمزگذاری داخلی هستند و از تکثیر FILESTREAM و تعمیر خودکار صفحه پشتیبانی می‌کنند. Failover میان رپلیکاها می‌تواند خودکار یا دستی باشد.

نخستین گام در استقرار AlwaysOn Availability Groups، استقرار یک Windows Failover Cluster است. این کار با Snap-in مربوط به Failover Cluster Manager در Windows Server 2008 R2 انجام می‌شود. پس از تشکیل خوشهٔ Windows Failover، ادامهٔ پیکربندی گروه‌های دسترس‌پذیری در SQL Server Management Studio انجام می‌گیرد. هنگام استفاده از راهنماهای Availability Groups، SQL Server Management Studio به‌طور خودکار سرویس‌ها، برنامه‌ها و منابع مناسب را در Failover Cluster Manager ایجاد می‌کند؛ بنابراین استقرار برای مدیران پایگاه‌داده‌ای که با خوشه‌بندی Failover آشنا نیستند بسیار آسان‌تر می‌شود.

اکنون که مبانی AlwaysOn Availability Groups بیان شد، سؤال طبیعی این است که این ویژگی چگونه عملیات سازمان را بهبود می‌دهد. برخلاف Database Mirroring که فقط از یک رپلیکای ثانویه پشتیبانی می‌کند، AlwaysOn Availability Groups از یک رپلیکای اصلی و حداکثر چهار رپلیکای ثانویه پشتیبانی می‌کند. گروه دسترس‌پذیری همچنین می‌تواند بیش از یک پایگاه‌دادهٔ دسترس‌پذیری داشته باشد. نکتهٔ جذاب دیگر این است که می‌توان در یک پیاده‌سازی، بیش از یک گروه دسترس‌پذیری میزبانی کرد. در نتیجه، می‌توان پایگاه‌داده‌هایی را که وابستگی برنامه‌ای دارند در یک گروه دسترس‌پذیری کنار هم قرار داد تا همهٔ پایگاه‌داده‌های آن گروه، همان‌گونه که در شکل ۲-۴ نشان داده شده، به‌عنوان یک واحد منسجم Failover شوند.

در شکل ۲-۴، یک رپلیکای اصلی و دو رپلیکای ثانویه همراه با دو گروه دسترس‌پذیری وجود دارد. یکی Finance نام دارد و همهٔ پایگاه‌داده‌های مالی را شامل می‌شود؛ دیگری HR نام دارد و همهٔ پایگاه‌داده‌های منابع انسانی را در بر می‌گیرد. گروه Finance می‌تواند مستقل از گروه HR Failover شود و برخلاف Database Mirroring، تمام پایگاه‌داده‌های یک گروه دسترس‌پذیری به‌عنوان یک واحد Failover می‌شوند. سازمان‌ها همچنین می‌توانند با استفادهٔ بهتر از سخت‌افزار ثانویه یا Passive، بهره‌وری فناوری اطلاعات را افزایش دهند، کارایی را بهتر کنند و هزینهٔ کل مالکیت را کاهش دهند.

این رپلیکاهای ثانویه را می‌توان برای تهیهٔ نسخهٔ پشتیبان و عملیات فقط‌خواندنی مانند گزارش‌گیری و نگه‌داری به کار گرفت. این موضوع در بخش «رپلیکاهای ثانویهٔ فعال» در ادامهٔ فصل بررسی می‌شود.

اکنون که با برخی مزایای AlwaysOn Availability Groups برای سازمان آشنا شدید، مفاهیم این قابلیت و شیوهٔ عملکرد آن را دقیق‌تر بررسی می‌کنیم. مفاهیم مورد بحث عبارت‌اند از:

• نقش‌های رپلیکای دسترس‌پذیری.
• حالت‌های همگام‌سازی داده.
• حالت‌های Failover.
• حالت اتصال در رپلیکاهای ثانویه.
• Listenerهای گروه دسترس‌پذیری.

نقش‌های رپلیکای دسترس‌پذیری

هر گروه دسترس‌پذیری AlwaysOn از مجموعه‌ای شامل دو یا چند شریک Failover تشکیل می‌شود که رپلیکای دسترس‌پذیری نام دارند. هر رپلیکا می‌تواند نقش اصلی یا ثانویه داشته باشد. حداکثر چهار رپلیکای ثانویه ممکن است وجود داشته باشد و از میان آن‌ها حداکثر دو رپلیکا را می‌توان برای حالت ثبت همگام پیکربندی کرد.

نقش‌های رپلیکاهای دسترس‌پذیری در AlwaysOn از همان اصل مشهور «قانون دو نفر» Sithها در مجموعهٔ Star Wars پیروی می‌کنند. در Star Wars در هر لحظه فقط دو Sith وجود دارد: یک استاد و یک شاگرد. به همین شکل، یک نمونهٔ SQL Server در گروه دسترس‌پذیری فقط می‌تواند رپلیکای اصلی یا رپلیکای ثانویه باشد و هرگز هم‌زمان هر دو نقش را ندارد، زیرا تعویض نقش توسط Windows Server Failover Cluster یا WSFC کنترل می‌شود.

هر نمونهٔ SQL Server در گروه دسترس‌پذیری روی یک SQL Server Failover Cluster Instance یا یک نمونهٔ مستقل SQL Server 2012 میزبانی می‌شود. هر نمونه روی گرهٔ متفاوتی از WSFC قرار دارد. WSFC معمولاً برای فراهم‌کردن دسترس‌پذیری بالا و بازیابی پس از فاجعه در محصولات شناخته‌شدهٔ مایکروسافت استفاده می‌شود. گروه‌های دسترس‌پذیری از WSFC به‌عنوان سازوکار زیربنایی برای تشخیص سلامت میان‌گرهی، هماهنگی Failover، تشخیص سلامت رپلیکای اصلی و اعلان‌های تغییر توزیع‌شده استفاده می‌کنند.

هر رپلیکای دسترس‌پذیری یک نسخه از پایگاه‌داده‌های دسترس‌پذیری گروه را میزبانی می‌کند. چون چندین نسخهٔ پایگاه‌داده روی رپلیکاهای مختلف میزبانی می‌شوند، برخلاف خوشه‌های سنتی SQL Server، استفاده از ذخیره‌سازی اشتراکی پیش‌نیاز نیست. در مقابل، سازمانی که ذخیره‌سازی غیرمشترک استفاده می‌کند باید بداند با افزایش تعداد رپلیکاها، نیاز فضای ذخیره‌سازی نیز بیشتر می‌شود.

حالت‌های همگام‌سازی داده

برای انتقال داده از رپلیکای اصلی به رپلیکای ثانویه، هر پیکربندی از حالت ثبت همگام یا ثبت ناهمگام استفاده می‌کند. هنگام انتخاب هر گزینه، موارد زیر را در نظر بگیرید:

• حالت Synchronous-commit: تراکنش روی هر دو رپلیکا ثبت می‌شود تا سازگاری تراکنشی تضمین شود. این موضوع تأخیر را افزایش می‌دهد؛ بنابراین ممکن است برای شریک‌هایی که شبکهٔ پرسرعت مشترک ندارند یا در مکان‌های جغرافیایی متفاوت قرار دارند مناسب نباشد.
• حالت Asynchronous-commit: تراکنش‌ها میان شریک‌ها بدون انتظار برای نوشتن Log روی دیسک شریک ثبت می‌شوند. این حالت کارایی میان برنامه و رپلیکای اصلی را بیشینه می‌کند و برای راهکارهای بازیابی پس از فاجعه مناسب است.

حالت‌های Failover گروه دسترس‌پذیری

هنگام پیکربندی گروه‌های دسترس‌پذیری AlwaysOn، مدیران پایگاه‌داده می‌توانند برای جابه‌جایی نقش از رپلیکای اصلی به ثانویه یکی از دو حالت Failover را انتخاب کنند. برای مدیرانی که با Database Mirroring آشنا هستند، این حالت‌ها بسیار شبیه حالت‌های آن فناوری برای دستیابی به دسترس‌پذیری بالا و بازیابی پس از فاجعه‌اند. دو حالت موجود در New Availability Group Wizard عبارت‌اند از:

• Failover خودکار: این رپلیکا از حالت ثبت همگام استفاده می‌کند و از Failover خودکار و دستی میان شریک‌ها پشتیبانی می‌کند. هنگام انتخاب Failover خودکار، حداکثر دو شریک رپلیکای Failover پشتیبانی می‌شوند.
• Failover دستی: این رپلیکا می‌تواند از حالت ثبت همگام یا ناهمگام استفاده کند و فقط Failover دستی میان شریک‌ها را پشتیبانی می‌کند.

حالت اتصال در رپلیکاهای ثانویه

همان‌طور که پیش‌تر اشاره شد، هر رپلیکای ثانویه را می‌توان برای دسترسی فقط‌خواندنی جهت گزارش‌گیری یا وظایف نگه‌داری مانند نسخهٔ پشتیبان پیکربندی کرد. در مرحلهٔ پایانی پیکربندی گروه‌های دسترس‌پذیری، مدیر پایگاه‌داده حالت اتصال رپلیکاهای ثانویه را تعیین می‌کند. سه حالت وجود دارد:

• عدم اجازهٔ اتصال: رپلیکا در نقش ثانویه هیچ اتصالی را نمی‌پذیرد.
• فقط اتصال‌های با هدف خواندن: رپلیکا در نقش ثانویه فقط اتصال‌های Read-intent را می‌پذیرد.
• اجازهٔ همهٔ اتصال‌ها: رپلیکا در نقش ثانویه همهٔ اتصال‌ها را برای دسترسی خواندنی، از جمله اتصال‌های کلاینت‌های قدیمی‌تر، می‌پذیرد.

Listenerهای گروه دسترس‌پذیری

Listener گروه دسترس‌پذیری راهی برای اتصال به پایگاه‌داده‌های درون یک گروه از طریق نام شبکهٔ مجازیِ متصل به رپلیکای اصلی فراهم می‌کند. برنامه‌ها می‌توانند نام شبکهٔ Listener را در رشته‌های اتصال قرار دهند. پس از Failover گروه از رپلیکای اصلی به ثانویه، نام شبکه اتصال‌ها را به رپلیکای اصلی جدید هدایت می‌کند. این مفهوم شبیه Virtual SQL Server Name در خوشه‌بندی Failover است؛ با این تفاوت که در گروه دسترس‌پذیری برای هر گروه یک نام شبکهٔ مجازی وجود دارد، در حالی که در خوشه‌بندی Failover SQL Server یک نام شبکهٔ مجازی برای هر نمونه وجود دارد.

می‌توانید تنظیمات Listener را هنگام استفاده از Create A New Availability Group Wizard در SQL Server Management Studio مشخص کنید یا پس از ایجاد گروه، Listener را به‌صورت دستی ایجاد یا ویرایش کنید. همچنین می‌توان از Transact-SQL استفاده کرد. همان‌گونه که شکل ۲-۵ نشان می‌دهد، هر Listener به یک نام DNS، یک نشانی IP و یک پورت مانند ۱۴۳۳ نیاز دارد. پس از ایجاد Listener، یک منبع خوشه‌ای نام سرور و یک منبع نشانی IP به‌طور خودکار در Failover Cluster Manager ایجاد می‌شود. این موضوع انعطاف‌پذیری و یکپارچگی عمیق گروه دسترس‌پذیری با SQL Server را نشان می‌دهد، زیرا بیشتر پیکربندی‌ها در خود SQL Server انجام می‌شوند.

میان Listenerها و گروه‌های دسترس‌پذیری نگاشت یک‌به‌یک وجود دارد؛ یعنی برای هر گروه می‌توان یک Listener ایجاد کرد. با این حال، اگر در یک رپلیکا بیش از یک گروه وجود داشته باشد، می‌توان بیش از یک Listener داشت. برای مثال، شکل ۲-۶ دو گروه را نشان می‌دهد: یکی برای پایگاه‌داده‌های Finance و دیگری برای پایگاه‌داده‌های Accounting.

هر گروه دسترس‌پذیری Listener مخصوص خود را دارد که کلاینت‌ها و برنامه‌ها به آن متصل می‌شوند.

پیکربندی گروه‌های دسترس‌پذیری

هنگام ایجاد یک گروه دسترس‌پذیری جدید، مدیر پایگاه‌داده باید نامی مانند AvailablityGroupFinance تعیین و سپس یک یا چند پایگاه‌داده را برای عضویت در گروه انتخاب کند. گام بعدی تعیین یک یا چند نمونهٔ SQL Server برای میزبانی رپلیکاهای ثانویه و سپس تعیین تنظیم Listener است. گام پایانی، انتخاب روش همگام‌سازی داده و حالت اتصال رپلیکاهای ثانویه است. این پیکربندی‌ها با New Availability Group Wizard یا اسکریپت‌های Transact-SQL و PowerShell انجام می‌شوند.

پیش‌نیازها

برای استقرار AlwaysOn Availability Groups باید پیش‌نیازهای زیر برقرار باشند:

• تمام رایانه‌های اجراکنندهٔ SQL Server، از جمله سرورهای سایت بازیابی پس از فاجعه، باید در یک دامنهٔ مبتنی بر Windows قرار داشته باشند.
• تمام رایانه‌های SQL Server باید در یک Windows Server Failover Cluster واحد عضو باشند، حتی اگر در چند سایت قرار داشته باشند.
• همهٔ سرورها باید در یک خوشهٔ Failover ویندوزی مشارکت داشته باشند.
• AlwaysOn Availability Groups باید روی هر سرور فعال باشد.
• همهٔ پایگاه‌داده‌ها باید در حالت بازیابی کامل باشند.

• پیش از استقرار باید از همهٔ پایگاه‌داده‌ها نسخهٔ پشتیبان کامل گرفته شود.
• سرور نمی‌تواند نقش Active Directory Domain Services را میزبانی کند.

نمونه‌های استقرار

شکل ۲-۷ صفحهٔ Specify Replicas در New Availability Group Wizard را نشان می‌دهد. در این مثال سه نمونهٔ SQL Server در گروه Finance وجود دارند: SQL01\Instance01، SQL02\Instance01 و SQL03\Instance01. نمونهٔ اول رپلیکای اصلی و دو نمونهٔ دیگر رپلیکای ثانویه‌اند. SQL01\Instance01 و SQL02\Instance01 از Failover خودکار همراه با جابه‌جایی همگام داده پشتیبانی می‌کنند، در حالی که SQL03\Instance01 از حالت ثبت ناهمگام استفاده می‌کند و فقط Failover اجباری را می‌پذیرد. نمونهٔ اصلی اجازهٔ اتصال فقط‌خواندنی به رپلیکای ثانویه را نمی‌دهد، اما دو نمونهٔ ثانویه اتصال‌های Read-intent را می‌پذیرند. در این مثال، دو نمونهٔ نخست در مرکز دادهٔ اصلی قرار دارند تا دسترس‌پذیری بالا درون سایت را فراهم کنند و نمونهٔ سوم در مرکز دادهٔ بازیابی پس از فاجعه قرار دارد و اگر مرکز دادهٔ اصلی از دسترس خارج شود، به‌صورت دستی آنلاین خواهد شد.

از شکل ۲-۷ و مثال پیشین یک نکته به‌روشنی مشخص می‌شود: پیکربندی‌های استقرار بسیار متنوعی برای برآورده‌کردن نیازهای دسترس‌پذیری بالا و بازیابی پس از فاجعهٔ هر سازمان وجود دارد. شکل ۲-۸ گزینه‌های اضافی زیر را نشان می‌دهد:

• ذخیره‌سازی غیرمشترک با مقصد محلی، منطقه‌ای و جغرافیایی.
• خوشهٔ چندسایتی همراه با خوشه‌ای دیگر به‌عنوان مقصد بازیابی پس از فاجعه.

• خوشهٔ سه‌گرهی همراه با مقصد مشابه بازیابی پس از فاجعه.
• مقصدهای ثانویه برای نسخهٔ پشتیبان، گزارش‌گیری و بازیابی پس از فاجعه.

پایش گروه‌های دسترس‌پذیری با داشبورد

مدیران می‌توانند از یک داشبورد مدیریت‌پذیری جدید و بسیار شهودی در SQL Server 2012 برای پایش گروه‌های دسترس‌پذیری استفاده کنند. داشبورد شکل ۲-۹، سلامت و وضعیت هر نمونه و هر پایگاه‌دادهٔ دسترس‌پذیری در گروه را گزارش می‌کند. همچنین نقش دقیق هر رپلیکا و وضعیت همگام‌سازی را نمایش می‌دهد. اگر مشکلی وجود داشته باشد یا اطلاعات بیشتری دربارهٔ یک رویداد خاص لازم باشد، مدیر پایگاه‌داده می‌تواند برای دریافت جزئیات بیشتر روی پیوندهای وضعیت گروه دسترس‌پذیری، نام نمونهٔ سرور یا وضعیت سلامت کلیک کند. برای اجرای داشبورد، در Object Explorer از SQL Server Management Studio روی پوشهٔ Availability Groups راست‌کلیک و Show Dashboard را انتخاب کنید.

رپلیکاهای ثانویهٔ فعال

همان‌طور که پیش‌تر بیان شد، بسیاری از سازمان‌ها نیاز خود را به بهبود بهره‌وری فناوری اطلاعات از طریق بهینه‌سازی سرمایه‌گذاری‌های سخت‌افزاری موجود به تیم SQL Server اعلام کردند. سازمان‌ها به‌طور مشخص امیدوار بودند سامانه‌های تولیدیِ درنظرگرفته‌شده برای بارهای کاری Passive به‌جای بیکار ماندن، در ظرفیت دیگری به کار گرفته شوند. همین سازمان‌ها همچنین می‌خواستند وظایف گزارش‌گیری و نگه‌داری از سرورهای تولیدی منتقل شوند، زیرا این وظایف بر بارهای کاری تولیدی اثر منفی داشتند. در SQL Server 2012، سازمان‌ها می‌توانند از AlwaysOn Availability Groups استفاده کنند تا رپلیکاهای ثانویه، که «رپلیکاهای ثانویهٔ فعال» نیز نامیده می‌شوند، برای دسترسی فقط‌خواندنی به پایگاه‌داده‌های وابسته به گروه دسترس‌پذیری پیکربندی شوند.

تمام عملیات فقط‌خواندنی روی رپلیکاهای ثانویه با نسخه‌بندی ردیف‌ها پشتیبانی می‌شوند و به‌طور خودکار به سطح تراکنش Snapshot Isolation نگاشت می‌شوند؛ بنابراین رقابت میان خواننده و نویسنده حذف می‌شود. دادهٔ رپلیکاهای ثانویه تقریباً بلادرنگ است. در بسیاری از شرایط، تأخیر داده میان پایگاه‌دادهٔ اصلی و ثانویه باید در حد چند ثانیه باشد. توجه کنید که تأخیر همگام‌سازی Log بر تازگی داده اثر می‌گذارد.

برای سازمان‌ها، رپلیکای ثانویهٔ فعال مترادف با بهینه‌سازی کارایی رپلیکای اصلی و افزایش بهره‌وری کلی فناوری اطلاعات و استفاده از سخت‌افزار است.

دسترسی فقط‌خواندنی به رپلیکاهای ثانویه

به یاد داشته باشید هنگام پیکربندی حالت اتصال رپلیکاهای ثانویه می‌توان یکی از گزینه‌های Disallow Connections، Allow Only Read-Intent Connections و Allow All Connections را انتخاب کرد. دو گزینهٔ اخیر دسترسی فقط‌خواندنی به رپلیکاهای ثانویه را فراهم می‌کنند. گزینهٔ Disallow Connections همان‌گونه که از نامش پیداست اجازهٔ چنین دسترسی‌ای را نمی‌دهد.

تفاوت عمده میان Allow Only Read-Intent Connections و Allow All Connections چیست؟ گزینهٔ نخست هنگامی اتصال به پایگاه‌داده‌های رپلیکای ثانویه را می‌پذیرد که ویژگی Application Intent Connection در SQL Server Native Client روی Read-only تنظیم شده باشد. در حالت Allow All Connections همهٔ اتصال‌های کلاینت مستقل از ویژگی Application Intent پذیرفته می‌شوند. ویژگی Application Intent در رشتهٔ اتصال، نوع بار کاری برنامه را هنگام اتصال به سرور اعلام می‌کند. مقادیر ممکن آن Read-only و Read Write هستند. فرمان‌هایی که تلاش کنند روی رپلیکای ثانویه داده ایجاد یا ویرایش کنند با خطا مواجه می‌شوند.

نسخه‌های پشتیبان روی رپلیکای ثانویه

می‌توان از پایگاه‌داده‌های دسترس‌پذیری عضو یک گروه روی هر یک از رپلیکاها نسخهٔ پشتیبان تهیه کرد. نسخهٔ پشتیبان همچنان روی رپلیکای اصلی پشتیبانی می‌شود، اما نسخهٔ پشتیبان Log را می‌توان روی هر رپلیکای ثانویه گرفت. این قابلیت مستقل از حالت Commit تکثیر، یعنی همگام یا ناهمگام، است. نسخه‌های پشتیبان Log که روی همهٔ رپلیکاها گرفته می‌شوند یک زنجیرهٔ Log واحد تشکیل می‌دهند، همان‌گونه که در شکل ۲-۱۰ نشان داده شده است.

در نتیجه، لازم نیست تمام نسخه‌های پشتیبان گزارش تراکنش روی یک رپلیکا ایجاد شوند. با این حال، همچنان باید مکان نگه‌داری نسخه‌های پشتیبان را با دقت انتخاب کرد. توصیه می‌شود همهٔ نسخه‌های پشتیبان در یک محل مرکزی ذخیره شوند، زیرا برای بازیابی در زمان فاجعه به همهٔ نسخه‌های پشتیبان Log نیاز است.

اگر سروری که نسخه‌های پشتیبان را در خود داشته دیگر در دسترس نباشد، فرایند بازیابی آسیب خواهد دید. هنگام خرابی، از Database Recovery Advisor Wizard جدید استفاده کنید؛ این ابزار مزایای زیادی در زمان Restore دارد. برای مثال، اگر روی رپلیکاهای ثانویهٔ متفاوت نسخهٔ پشتیبان می‌گیرید، راهنما با کنار هم قراردادن همهٔ فایل‌های Log بر اساس شمارهٔ توالی Log یا Log Sequence Number (LSN)، یک تصویر بصری از خط زمانیِ زمانی‌مرتب تولید می‌کند.

نمونه‌های خوشهٔ Failover در AlwaysOn

تا اینجا نتیجهٔ تلاش‌های توسعه برای ساخت قابلیت جدید AlwaysOn Availability Groups و رپلیکاهای ثانویهٔ فعال را مشاهده کردید. اکنون بهبودهای مهم قابلیت‌های سنتی مانند خوشه‌بندی Failover از SQL Server را بررسی می‌کنیم که از ذخیره‌سازی اشتراکی استفاده می‌کند. بهبودهای زیر برای مدیرانی که می‌خواهند دسترس‌پذیری بالای نمونه‌های SQL Server را به دست آورند جذاب‌اند:

• خوشه‌بندی چندزیرشبکه‌ای: با پشتیبانی جدید از خوشه‌بندی Failover چندزیرشبکه‌ای، علاوه بر دسترس‌پذیری بالا یک راهکار بازیابی پس از فاجعه نیز فراهم می‌شود.
• پشتیبانی از TempDB روی دیسک محلی: TempDB دیگر مانند نسخه‌های پیشین مجبور نیست روی ذخیره‌سازی اشتراکی قرار گیرد و اکنون روی دیسک محلی پشتیبانی می‌شود. این تغییر مزایای عملی فراوانی دارد؛ برای نمونه، می‌توان ورودی/خروجی TempDB را از تجهیزات ذخیره‌سازی اشتراکی مانند SAN منتقل کرد و برای بهینه‌سازی بارهای کاری TempDB که معمولاً I/O تصادفی دارند، از ذخیره‌سازی سریع SSD در گره‌های سرور استفاده کرد.
• سیاست انعطاف‌پذیر Failover: SQL Server 2012 با افزودن ویژگی‌های سطح شرایط خرابی، تشخیص شکست نمونهٔ خوشهٔ Failover را بهبود می‌دهد و اجازه می‌دهد سیاست Failover انعطاف‌پذیرتری پیکربندی شود.

با انتشار Windows Server 2008، قابلیت جدیدی فراهم شد که گره‌های خوشه را بدون نیاز به شبکهٔ محلی مجازی کشیده (Stretch VLAN) میان شبکه‌ها، در زیرشبکه‌های متفاوت متصل می‌کرد. گره‌ها می‌توانستند روی زیرشبکه‌های متفاوت در یک مرکز داده یا در مکان جغرافیایی دیگری مانند سایت بازیابی پس از فاجعه قرار گیرند. این مفهوم معمولاً خوشه‌بندی چندسایتی، چندزیرشبکه‌ای یا کشیده نامیده می‌شود. متأسفانه نسخه‌های پیشین SQL Server نمی‌توانستند از این قابلیت Windows Failover Clustering استفاده کنند. سازمان‌ها برای ساخت خوشهٔ Failover چندسایتی یا چندزیرشبکه‌ای SQL Server همچنان مجبور بودند Stretch VLAN ایجاد کنند تا یک نشانی IP واحد برای Failover میان سایت‌ها در معرض قرار گیرد؛ کاری پیچیده و دشوار.

در SQL Server 2012 این محدودیت از میان رفته است، زیرا خوشه‌بندی چندزیرشبکه‌ای و چندسایتی به‌صورت داخلی پشتیبانی می‌شود و دیگر نیازی به پیاده‌سازی فناوری Stretch VLAN نیست.

شکل ۲-۱۱ نمونه‌ای از یک خوشهٔ Failover چندزیرشبکه‌ای SQL Server میان دو زیرشبکه در دو سایت را نشان می‌دهد. هر گرهٔ خوشه روی زیرشبکه‌ای متفاوت قرار دارد. Node 1 در Site 1 و زیرشبکهٔ 192.168.115.0/24 است و Node 2 در Site 2 و زیرشبکهٔ 192.168.116.0/24 قرار دارد. هنگامی که Failover از یک زیرشبکه به زیرشبکهٔ دیگر رخ می‌دهد، نشانی IP در DNS که به نام شبکهٔ مجازی خوشهٔ SQL Server وابسته است به‌طور خودکار به‌روزرسانی می‌شود.

برای اتصال کلاینت‌ها و برنامه‌ها به خوشهٔ Failover SQL Server، باید دو نشانی IP برای نام منبع خوشه در WSFC ثبت شوند. برای مثال، فرض کنید نام سرور SQLFCI01 و نشانی‌ها 192.168.115.5 و 192.168.116.5 هستند. WSFC به‌طور خودکار Failover را کنترل می‌کند و بسته به گره‌ای که مالک فعلی منبع SQL Server است، نشانی مناسب را آنلاین می‌کند. اگر Node 1 روی زیرشبکهٔ 192.168.115.0/24 باشد و مالک خوشه شود، منبع IP با نشانی 192.168.115.6 آنلاین می‌شود. اگر Failover رخ دهد و Node 2 مالک منبع شود، نشانی اول آفلاین و 192.168.116.6 آنلاین خواهد شد.

چون چند نشانی IP به نام مجازی نمونهٔ خوشهٔ Failover SQL Server وابسته‌اند، هنگام Failover نشانی آنلاین به‌طور خودکار تغییر می‌کند. Windows Failover Cluster نیز بلافاصله پس از آنلاین‌شدن منبع نام شبکه، به‌روزرسانی DNS را صادر می‌کند. ممکن است به‌دلیل تنظیمات Cache، تغییر نشانی IP در DNS فوراً روی کلاینت‌ها اعمال نشود؛ بنابراین توصیه می‌شود با تنظیم HostRecordTTL در DNS روی ۶۰ ثانیه، زمان توقف کلاینت کمینه شود. پیش از هر تغییر DNS با مدیر DNS مشورت کنید، زیرا تنظیم TTL رکورد میزبان می‌تواند بار درخواست‌های اضافی ایجاد کند.

پشتیبانی از استقرار SQL Server 2012 روی Windows Server Core

Windows Server Core نخست با Windows Server 2008 معرفی شد و با Windows Server 2008 R2 بهبودهای مهمی یافت. Server Core یک گزینهٔ نصب برای Windows Server 2008 و Windows Server 2008 R2 است. از آنجا که Server Core استقرار حداقلی Windows است، به‌دلیل کاهش چشمگیر سطح حمله امنیت بیشتری دارد. Server Core رابط گرافیکی سنتی Windows را شامل نمی‌شود و از طریق خط فرمان یا ابزارهای مدیریت از راه دور اداره می‌شود.

نسخه‌های پیشین SQL Server از Server Core پشتیبانی نمی‌کردند، اما این وضعیت تغییر کرده است. برای نخستین‌بار، Microsoft SQL Server 2012 نصب روی Server Core مبتنی بر Windows Server 2008 R2 Service Pack 1 یا نسخهٔ بعدی را پشتیبانی می‌کند.

چرا Server Core برای SQL Server مهم است و چگونه دسترس‌پذیری را افزایش می‌دهد؟ هنگام اجرای SQL Server 2012 روی Server Core، نیاز به نصب وصله‌های سیستم‌عامل تا ۶۰ درصد کاهش می‌یابد. این موضوع به دسترس‌پذیری بیشتر و کاهش توقف برنامه‌ریزی‌شده برای پایگاه‌داده‌ها و بارهای کاری مأموریت‌حیاتی منجر می‌شود. افزون بر این، حمله‌های سطحی به‌شدت کاهش می‌یابند.

در نتیجه، امنیت کلی سکوی پایگاه‌داده تقویت می‌شود که بار دیگر به بیشترین دسترس‌پذیری و حفاظت از داده منجر خواهد شد.

هنگامی که Server Core نخست معرفی شد، مدیریت آن به دانش و استفاده از نحو خط فرمان نیاز داشت. بیشتر متخصصان فناوری اطلاعات در آن زمان به رابط کاربری گرافیکی (Graphical User Interface یا GUI) برای مدیریت و پیکربندی Windows عادت داشتند و در پذیرش Server Core مشکل داشتند. این موضوع محبوبیت و در نهایت میزان پیاده‌سازی آن را کاهش داد. مایکروسافت برای کاهش این چالش‌ها ابزار آمادهٔ SCONFIG را با Windows Server 2008 R2 معرفی کرد تا پیکربندی سرور به‌طور چشمگیری ساده شود. برای حرکت در گزینه‌های SCONFIG کافی است یک یا چند عدد را برای پیکربندی ویژگی‌های سرور وارد کنید، همان‌گونه که در شکل ۲-۱۳ نشان داده شده است.

بخش‌های بعدی پیش‌نیازهای SQL Server 2012 روی Server Core، ویژگی‌های پشتیبانی‌شده و گزینه‌های نصب را توضیح می‌دهند.

پیش‌نیازهای SQL Server 2012 برای Server Core

سازمان‌هایی که SQL Server 2012 را روی Windows Server 2008 R2 Server Core نصب می‌کنند باید پیش‌نیازهای سیستم‌عامل، ویژگی‌ها و مؤلفه‌های زیر را برآورده کنند.

نیازمندی‌های سیستم‌عامل:

• Windows Server 2008 R2 SP1 64-bit x64 Data Center Server Core.
• Windows Server 2008 R2 SP1 64-bit x64 Enterprise Server Core.
• Windows Server 2008 R2 SP1 64-bit x64 Standard Server Core.
• Windows Server 2008 R2 SP1 64-bit x64 Web Server Core.

ویژگی‌ها و مؤلفه‌ها:

• .NET Framework 2.0 SP2.
• .NET Framework 3.5 SP1 Full Profile.
• .NET Framework 4 Server Core Profile.

• Windows Installer 4.5.
• Windows PowerShell 2.0.

پس از فراهم‌کردن همهٔ پیش‌نیازها، باید با مؤلفه‌های SQL Server پشتیبانی‌شده روی Server Core آشنا شوید.

ویژگی‌های SQL Server پشتیبانی‌شده روی Server Core

ویژگی‌های متعددی از SQL Server به‌طور کامل روی Server Core پشتیبانی می‌شوند، از جمله Database Engine Services، SQL Server Replication، Full Text Search، Analysis Services، Client Tools Connectivity و Integration Services. در مقابل، Server Core از ویژگی‌های دیگری مانند Reporting Services، Business Intelligence Development Studio، Client Tools Backward Compatibility، Client Tools SDK، SQL Server Books Online، Distributed Replay Controller، SQL Client Connectivity SDK، Master Data Services و Data Quality Services پشتیبانی نمی‌کند. برخی ویژگی‌ها مانند Management Tools - Basic، Management Tools - Complete، Distributed Replay Client و Microsoft Sync Framework فقط از راه دور پشتیبانی می‌شوند. بنابراین می‌توان این ویژگی‌ها را روی ویرایش‌های غیر Server Core ویندوز نصب و سپس برای اتصال از راه دور به نمونهٔ SQL Server اجراشده روی Server Core استفاده کرد. برای فهرست کامل ویژگی‌های پشتیبانی‌شده و پشتیبانی‌نشده به منبع درج‌شده در کتاب مراجعه کنید.

گزینه‌های نصب SQL Server روی Server Core

SQL Server Installation Setup Wizard معمول هنگام نصب SQL Server 2012 روی Server Core پشتیبانی نمی‌شود. بنابراین باید فرایند نصب را با یکی از روش‌های نصب خط فرمان، فایل پیکربندی یا روش DefaultSetup.ini خودکار کنید. جزئیات و نمونه‌های هر روش در Books Online و نشانی درج‌شده در نسخهٔ اصلی کتاب موجود است.

سایر بهبودهای دسترس‌پذیری بالا و بازیابی پس از فاجعه

این بخش برخی از بهبودهای اضافی دسترس‌پذیری بالا و بازیابی پس از فاجعه در SQL Server 2012 را خلاصه می‌کند.

پشتیبانی از Server Message Block

یکی از روندهای رایج سال‌های اخیر، تجمیع پایگاه‌داده‌ها و برنامه‌ها روی تعداد کمتری سرور بوده است؛ به‌طور مشخص، میزبانی چند نمونهٔ SQL Server روی یک خوشهٔ Failover. نسخه‌های پیشین SQL Server برای هر Failover Cluster Instance به یک حرف درایو جداگانه نیاز داشتند. چون بدون درنظرگرفتن رزروها فقط ۲۳ حرف درایو در دسترس است، بیشینهٔ تعداد نمونه‌های SQL Server پشتیبانی‌شده روی یک خوشه ۲۳ بود. شاید این تعداد زیاد به نظر برسد، اما این محدودیت بر سازمان‌هایی که سرورهای قدرتمند با منابع پردازشی و حافظهٔ کافی برای بیش از ۲۳ نمونه داشتند اثر منفی می‌گذاشت. SQL Server 2012 و خوشه‌بندی Failover اکنون پشتیبانی از Server Message Block یا SMB را معرفی می‌کنند.

مزایای SMB در SQL Server 2012 شامل تجمیع ذخیره‌سازی پایگاه‌داده و امکان پشتیبانی از بیش از ۲۳ نمونهٔ خوشه‌ای در یک WSFC است. برای بهره‌گیری از این ویژگی‌ها، فایل‌سرورها باید Windows Server 2008 یا نسخهٔ جدیدتر را اجرا کنند.

Database Recovery Advisor

Database Recovery Advisor ویژگی جدیدی برای بهینه‌سازی تجربهٔ Restore مدیران پایگاه‌داده در وظایف بازیابی است. این ابزار دارای خط زمانی جدیدی است که تاریخچهٔ نسخه‌های پشتیبان را به‌صورت بصری، همانند شکل ۲-۱۴، نمایش می‌دهد.

عملیات آنلاین

SQL Server 2012 چند بهبود را برای عملیات آنلاین نیز شامل می‌شود که زمان توقف در طول نگه‌داری برنامه‌ریزی‌شده را کاهش می‌دهند. ایندکس‌گذاری مجدد داده‌های Line-of-business یا LOB و افزودن ستون‌ها با مقادیر پیش‌فرض اکنون پشتیبانی می‌شوند.

ارتقای چرخشی و مدیریت وصله‌ها

تمام قابلیت‌های جدید AlwaysOn با پشتیبانی از ارتقا و نصب وصله به‌صورت چرخشی، زمان توقف برنامه را تنها به یک Failover دستی کاهش می‌دهند. مدیر پایگاه‌داده می‌تواند در صورت استفاده از خوشهٔ Failover، Service Pack یا اصلاحیهٔ حیاتی را روی گره‌های Passive و در صورت استفاده از گروه‌های دسترس‌پذیری، روی رپلیکاهای ثانویه نصب کند. پس از تکمیل نصب روی همهٔ گره‌های Passive یا رپلیکاهای ثانویه، مدیر یک Failover دستی انجام می‌دهد و سپس Service Pack یا اصلاحیه را روی گره FCI یا رپلیکای باقی‌مانده اعمال می‌کند. این راهبرد چرخشی هنگام ارتقای سکوی پایگاه‌داده نیز قابل استفاده است.