راهکار Always On آخرین راهکار برای High Availability و Disaster Recovery که ماکروسافت برای SQL Server از نسخه SQLServer2012 ارائه کرده است.
این تکنولوژی امکانی را در اختیار قرار می‌دهد که مجموعه‌ای از پایگاههای داده در سطح سازمانی و بزرگ به صورت «همیشه در دسترس» باشند؛ بطوریکه از دید کاربر نهایی پایگاههای داده، همیشه فعال و قابل استفاده هستند. از دیگر امکانات این راهکار می‌توان از Failover ها یا مجموعه خاصی از دیتابیس‌ها نام برد که وارد AO می‌شوند. این دیتابیس‌ها که اصطلاحا وارد Availability Group می‌شوند، شامل یک سرورPrimary و 1 تا 4 دیتابیس با نقش Secondary است.
قابلیت جالب دیگر راهکار Always On این است که به ادمین اجازه می‌دهد تا سرور‌هایی با نقشSecondary را با دسترسی Read-Only پیکربندی کند و بخشی از بار ترافیک Queryهای فقط خواندنی SQL را از سمت لایه Application به سرورهای ثانویه منتقل کند. به این ترتیب کاربران می‌توانند از Load Balancing در لایه دیتابیس بهره‌برداری کنند.
قابلیت‌های راهکار Always On
در این مقاله قصد داریم تا امکاناتی که راهکار Always On Availability Groups ارائه می‌کند را با هم مرور کنیم:
• Always on Availability Groups می‌تواند 5 سرور را به طور هم‌زمان پشتیبانی کند:
یک سرور با نقش Primary و حداکثر 4 سرور با نقش Secondary. هر یک از این سرورها که وارد گروه می‌شوند اصطلاحا replica نامیده می‌شوند. هر Replica یک Instance SQLServer نصب شده و مستقل است که یک کپی از اطلاعات دیتابیس‌های عضو شده در گروه AO را به صورت محلی در خود نگهداری می‌کنند.
• امکان 2 مدل پایداری در فرآیند انتقال اطلاعات از سرور اصلی به سرور(های) ثانویه را ارائه می‌کند:
Asynchronous-commit mode: این مدل برای راهکارهای disaster-recovery کارایی دارد، به ویژه در شرایطی که هر یک از replicaها در فاصله‌های جغرافیایی قابل ملاحظه‌‌ای از یکدیگر قرار دارند. با توجه به پهنای باند پایین و تاخیر بالا در شبکه این مدل، اختلال و مشکلات کمتری در جابجایی دیتا به وجود خواهد آمد.
Synchronous-commit mode: این مدل بر حفظ دیتا‌ها، high availability و عملکرد سریع و کارایی بالا تاکید بیشتری دارد. رفتار Sync دقیقا بر خلاف مود Async است به این صورت که هر تراکنش CRD) Insert ,Update ,Delete) که در سرور Primary انجام می‌شود تا لحظه‌ای که در همه سرورهای با نقش Secondary این تراکنش Commit نشود روی سرور Primary اولیه به صورت Wait می‌ماند تا فرآیند Commit روی همه‌ی سرورها انجام شود و در نهایت روی سرور Primary نیز Commit شود. این در حالیست که در مود Async تراکنش‌های ذکر شده در سرور اولیه مستقل از سرورهای ثانویه Commit می‌شوند.
لازم به اشاره است که در هر گروه AO این امکان وجود دارد که تا حداکثر سه replica با مود Synchronous پیکربندی شوند.
• پشتیبانی چند مدل Failover :
o Failover خودکار: در صورت بروز مشکل در سرور با نقش primary فعالیت‌های SQL از replica اصلی به replica دیگری به صورت خودکار جابجا می‌شود.
Failover برنامه ریزی شده: در این مدل می‌توان در صورت صلاح‌دید و شرایط خاص، توسط اسکریپت‌هایی برای انجام فرآیند Failover به صورت برنامه‌ریزی شده و هوشمندتر اقدام کرد. این مدل Failover با توجه به ذات آن عموما General Failover نامیده می‌شود.
Failover دستی: این مدل در شرایط اضطرار، کاربرد دارد که عموما به آن Manual Failover می‌گویند. در فرآیند به شما اجازه دارید که در صورت صلاح‌دید، سرور با نقش Primary را با سروری با نقش Secondary تعویض کنید.
• بهره‌برداری بهتر از منابع سرورهای ثانویه:
AO اجازه می‌دهد که از منابع رزرو شده در سرورهای ثانویه استفاده‌های بهتری داشته باشیم که عبارتند از:
Read-only connection access: در AO به صورت پیش فرض دیتابیس‌های موجود در replicaهای ثانویه برای Queryهای لایه کاربری در دسترس نیستند؛ اما اگر این مدل، پیکربندی شود، دیتابیس‌های موجود در Replicaهای ثانویه به صورت Read-only قابل دسترس خواهند بود؛ به این معنی که می‌توان Queryهای Read-only را روی سرورهای ثانویه اجرا کرد به طوریکه جداول در سرور اصلی Lock نشوند و یا منابع سرور اصلی برای این دست پرس و جوها، اشغال نشوند.
Backup operations: اگر منابع رزرو شده در سرورهای ثانویه در این مدل پیکربندی شود، امکان فرآیند تهیه نسخ پشتیبان بر روی سرورهای ثانویه وجود دارد و نباید نگران بار کاری سرور اصلی برای انجام این مهم، باشیم. قابلیت‌های ذکر شده درباره AO باعث می‌شوند بهره‌وری بهتری از سخت‌افزارها و منابع اختصاص یافته به سرورها وجود داشته باشد. این مدل همچنین انتقال بار ترافیکی کانکشن‌های فقط خواندنی یا اصطلاحا read-intent، فرآیندهای تهیه نسخ پشتیبان در سرورهای ثانویه، توزیع جغرافیا‌ی سرورهای ثانویه، امکان نزدیک نگهداشتن حداکثری سرورها به کاربران، ایجاد Disaster-Siteهای ایمن را ایجاد می‌کند که همه این موارد کمک شایانی به کارایی سرور اصلی می‌کنند.
• هر یک از این availability groupها یک Listener اختصاصی دارد
listener یک Server Name مجازی است که کانکشن‌های لایه کاربر را به سمت دیتابیس‌های موجود در گروه به سرور اصلی منتقل می‌کند و درصورتیکه کانکشن‌ها همراه با تگread-intent باشند، listener این قابلیت را دارد که کانکشن‌ها را مستقیما و بر اساس الگورتیم round robin به سرورهای ثانویه فقط خواندنی (read-only secondary replica) منتقل کند. از دیگر مواردی که listener برعهده دارد، این است که در صورت انجام فرآیند failover همه کانکشن‌های سرور primary قدیم را به سرور primary جدید منتقل می‌کند.
• Always On Automatic Page Repair:
این قابلیت در راهکار Mirroring و Always On توسط ماکروسافت ارائه شده است. نحوه کار این قابلیت اینگونه است که در صورت بروز مجموعه‌ای از خطا‌های از پیش تعریف شده، اقدام به بازسازی واحد ذخیره‌سازی داده‌‌ها (Page) در سیستم‌های دیتابیس مبتنی بر MS SQL Server می‌کند. فرآیند بازسازی یا بازیابی اینگونه است که در زمان خواندن اطلاعات یک Page خاص در سروری که توسط Select اجرا شده، و معیوب بودن Page آن، AO در اولین گام سعی می‌کند این صفحه معیوب را از سرورهای دیگر به ترتیب توسط الگوریتم round robin بازیابی کند، اگر بازیابی اطلاعات این Page با موفقیت صورت گرفت، این اطلاعات را در سرور با اطلاعات معیوب جایگذاری و جایگزین می‌کند و ادامه فرآیند عادی دستور Select طی می‌شود. این فرآیند پیچیده، کاملا از دید کاربر مخفی است و به صورت خودکار انجام می‌شود.
• AO به صورت داشبورد این امکان را به ادمین می‌دهد که به صورت کامل جزیيات تنظیمات انجام شده در AO را بررسی و تغییرات لازم را اعمال کند.
درخواست دموی نرم‌افزار ارزیابی عملکرد دیدگاه
