راهنمای گام‌به‌گام استقرار SQL Server Always On Availability Groups برای پایداری کسب‌وکار

خلاصه پاسخ

Always On Availability Groups در SQL Server یک راهکار جامع برای دسترسی‌پذیری بالا (HA) و بازیابی فاجعه (DR) است که با تکرار پایگاه‌های داده بین نمونه‌های SQL Server، از پایداری و تداوم عملیات کسب‌وکار اطمینان حاصل می‌کند. این فناوری امکان سوییچ خودکار (failover) و توزیع بار کاری خواندن (read-scale) را فراهم کرده و جایگزین مدرنی برای Database Mirroring به شمار می‌رود.

نکات کلیدی

• ✅ Always On Availability Groups راهکاری برای HA و DR در سطح Enterprise برای SQL Server است که جایگزین Database Mirroring شده است. (منبع: Microsoft Learn)
• 💡 یک Availability Group از یک مجموعه پایگاه داده اولیه قابل خواندن/نوشتن و حداکثر هشت مجموعه پایگاه داده ثانویه پشتیبانی می‌کند. (منبع: Microsoft Learn)
• 🛡️ در نسخه‌های SQL Server Standard Edition، می‌توان از Basic Availability Groups استفاده کرد که محدودیت‌هایی مانند پشتیبانی از یک پایگاه داده در هر گروه و حداکثر دو replica را دارد. (منبع: Microsoft Learn, SQLServerCentral)
• ☁️ Always On Availability Groups را می‌توان برای سناریوهای مختلفی از جمله HA، DR، مهاجرت و افزایش مقیاس برای بارهای کاری خواندنی به کار برد. (منبع: Microsoft Learn)
• ⚙️ فعال‌سازی قابلیت Always On بر روی هر نمونه SQL Server و پیکربندی یک Endpoint Database Mirroring از پیش‌نیازهای راه‌اندازی است. (منبع: Microsoft Learn)
• 📈 لایسنس SQL Server Enterprise Edition امکانات کامل Always On از جمله تعداد نامحدود replica، قابلیت‌های پیشرفته DR و Failover خودکار را ارائه می‌دهد. (منبع: SQLServerCentral)

پیش‌نیازها و مفاهیم کلیدی برای راه‌اندازی Always On Availability Groups

برای اطمینان از دسترسی‌پذیری و تداوم فعالیت‌های کسب‌وکار در برابر خرابی‌های سخت‌افزاری، نرم‌افزاری یا بلایای طبیعی، سازمان‌ها به راهکارهای قدرتمندی برای پایگاه داده‌های خود نیاز دارند. در اکوسیستم مایکروسافت، Always On Availability Groups در SQL Server یکی از پیشرفته‌ترین و جامع‌ترین راهکارها برای دستیابی به دسترسی‌پذیری بالا (High Availability - HA) و بازیابی فاجعه (Disaster Recovery - DR) محسوب می‌شود. این فناوری که جایگزینی برای Database Mirroring است، از SQL Server 2012 به بعد معرفی شد و با هر نسخه جدید، قابلیت‌های آن گسترش یافته است (منبع: Microsoft Learn).

پیش از شروع فرآیند گام‌به‌گام راه‌اندازی Always On Availability Groups، لازم است با مفاهیم و پیش‌نیازهای کلیدی آن آشنا شویم:

Always On Availability Group چیست و چرا از آن استفاده می‌کنیم؟

به گزارش Microsoft Learn، یک Availability Group (AG) مجموعه‌ای از پایگاه‌های داده کاربردی است که به صورت یک واحد، failover می‌شوند. این بدان معناست که اگر سرور اصلی میزبان این پایگاه‌های داده (Primary Replica) دچار مشکل شود، تمامی پایگاه‌های داده موجود در گروه به صورت خودکار یا دستی به یک سرور ثانویه (Secondary Replica) منتقل می‌شوند و بدین ترتیب، زمان قطعی (downtime) به حداقل می‌رسد.

Always On Availability Groups برای سناریوهای مختلفی طراحی شده است (منبع: Microsoft Learn):

• 🛡️ دسترسی‌پذیری بالا (HA): با فراهم کردن Redundancy در سطح پایگاه داده، از عملکرد بی‌وقفه برنامه‌های کاربردی اطمینان حاصل می‌کند.
• ⚡ بازیابی فاجعه (DR): امکان ایجاد Replicaها در دیتاسنترهای مختلف یا مناطق ابری را فراهم می‌آورد تا در صورت بروز فاجعه در یک مکان، داده‌ها در مکان دیگری در دسترس باشند.
• 📈 افزایش مقیاس برای خواندن (Read-Scale): امکان توزیع بارهای کاری خواندنی به Replicaهای ثانویه را فراهم می‌کند و بدین ترتیب، عملکرد سرور اصلی را بهبود می‌بخشد.
• 🔄 مهاجرت و ارتقاء (Migrations and Upgrades): می‌تواند برای کاهش زمان قطعی در حین فرآیندهای مهاجرت یا ارتقاء SQL Server مورد استفاده قرار گیرد.

تفاوت‌های نسخه‌های Standard و Enterprise Edition

انتخاب نسخه مناسب SQL Server برای پیاده‌سازی Always On Availability Groups بسیار حائز اهمیت است. در حالی که SQL Server Enterprise Edition امکانات کامل و بدون محدودیت را برای این قابلیت ارائه می‌دهد، Standard Edition نیز با معرفی Basic Availability Groups (BAG) در SQL Server 2016، امکانات اولیه‌ای را فراهم کرده است (منبع: Microsoft Learn).

جدول زیر تفاوت‌های اصلی این دو نسخه را از نظر Always On نشان می‌دهد:

همانطور که SQLServerCentral اشاره می‌کند، اگر نیاز به HA و DR به صورت همزمان دارید، معمولاً نیازمند Enterprise Edition خواهید بود. اگرچه می‌توان با Basic AGها و Failover دستی به اهداف DR رسید، اما این کار پیچیدگی بیشتری دارد و نیازمند مدیریت دقیق‌تر است، خصوصاً اگر پایگاه‌های داده متعددی دارید که باید به صورت هماهنگ Failover شوند (منبع: SQLServerCentral).

پیش‌نیازهای سیستمی

برای راه‌اندازی موفقیت‌آمیز Always On Availability Groups، باید پیش‌نیازهای زیر فراهم باشد (منبع: Microsoft Learn):

1. Windows Server Failover Clustering (WSFC): گره‌های سرور میزبان SQL Server باید بخشی از یک کلاستر WSFC باشند. این امر برای مدیریت Failover و هماهنگی بین Replicaها ضروری است.
2. SQL Server Edition مناسب: همانطور که ذکر شد، بسته به نیازهای HA/DR خود، باید نسخه Standard یا Enterprise را انتخاب کنید.
3. Endpoint Database Mirroring: هر نمونه SQL Server که در Availability Group شرکت می‌کند، باید یک Database Mirroring Endpoint برای ارتباط با سایر نمونه‌ها داشته باشد.
4. حالت ریکاوری (Recovery Model) پایگاه داده: تمام پایگاه‌های داده‌ای که قرار است در یک Availability Group قرار گیرند، باید در حالت Full Recovery Model باشند.
5. پشتیبان‌گیری اولیه (Initial Backup): باید حداقل یک پشتیبان‌گیری کامل (Full Backup) از هر پایگاه داده و همچنین یک پشتیبان‌گیری از Log Transaction آن‌ها (Transaction Log Backup) انجام شده باشد تا بتوان Replicaهای ثانویه را راه‌اندازی کرد.

گام‌به‌گام: راه‌اندازی Always On Availability Groups

این بخش شما را در فرآیند راه‌اندازی یک Always On Availability Group راهنمایی می‌کند. این مراحل شامل آماده‌سازی محیط، فعال‌سازی قابلیت‌ها و ایجاد خود Availability Group است.

گام 1: فعال‌سازی قابلیت Always On Availability Groups

اولین گام برای استفاده از Always On Availability Groups، فعال‌سازی این قابلیت بر روی تمامی نمونه‌های SQL Server است که قرار است در گروه شرکت کنند (منبع: Microsoft Learn).

1. باز کردن SQL Server Configuration Manager:
   • به Start رفته و SQL Server Configuration Manager را جستجو کنید و آن را باز کنید.
2. انتخاب سرویس SQL Server:
   • در پنل سمت چپ، SQL Server Services را گسترش دهید.
   • بر روی SQL Server (MSSQLSERVER) یا نام نمونه خود کلیک راست کرده و Properties را انتخاب کنید.
3. فعال‌سازی Always On High Availability:
   • به تب AlwaysOn High Availability بروید.
   • گزینه Enable AlwaysOn Availability Groups را تیک بزنید.
   • اگر از کلاستر WSFC استفاده می‌کنید (که برای HA ضروری است)، نام کلاستر شما باید در اینجا نمایش داده شود.
   • بر روی OK کلیک کنید.
4. ری‌استارت کردن سرویس SQL Server:
   • برای اعمال تغییرات، سرویس SQL Server را ری‌استارت کنید. این کار را برای تمامی نمونه‌های SQL Server که در Availability Group قرار می‌گیرند، تکرار کنید.

گام 2: ایجاد Database Mirroring Endpoint (در صورت عدم وجود)

هر نمونه SQL Server برای برقراری ارتباط و انتقال داده‌ها بین Replicaها به یک Endpoint نیاز دارد. این Endpoint از نوع Database Mirroring است (منبع: Microsoft Learn).

1. بررسی وجود Endpoint:
   • در SQL Server Management Studio (SSMS)، به نمونه SQL Server متصل شوید.
   • کوئری زیر را اجرا کنید تا ببینید آیا Endpoint از قبل وجود دارد:

     SELECT * FROM sys.database_mirroring_endpoints;
     

   • اگر نتیجه‌ای برنگرداند یا Endpoint موجود برای Always On مناسب نباشد، باید یک Endpoint جدید ایجاد کنید.
2. ایجاد Endpoint جدید:
   • کوئری زیر را برای ایجاد Endpoint اجرا کنید. حتماً PORT_NUMBER و YOUR_SQL_SERVER_INSTANCE_NAME را با مقادیر واقعی خود جایگزین کنید.
   • پیشنهاد می‌شود از پورت 5022 استفاده کنید که پورت پیش‌فرض برای Database Mirroring است.

   CREATE ENDPOINT [Hadr_Endpoint]
   STATE=STARTED
   AS TCP (LISTENER_PORT = 5022)
   FOR DATABASE_MIRRORING
   (ROLE = ALL, ENCRYPTION = REQUIRED ALGORITHM AES);
   ALTER ENDPOINT [Hadr_Endpoint] OWNER = [NT AUTHORITY\SYSTEM];
   GRANT CONNECT ON ENDPOINT::[Hadr_Endpoint] TO [PUBLIC];
   

   • این عملیات را بر روی تمامی نمونه‌های SQL Server شرکت‌کننده انجام دهید.
   • اطمینان حاصل کنید که پورت Endpoint در فایروال سرورها باز است.

گام 3: ایجاد یک Availability Group جدید

پس از پیکربندی نمونه‌های SQL Server، می‌توانید یک Availability Group جدید ایجاد کنید. این کار را می‌توان از طریق SQL Server Management Studio (SSMS) یا با استفاده از T-SQL انجام داد.

1. استفاده از New Availability Group Wizard در SSMS:
   • در SSMS، به نمونه SQL Server که قرار است Primary Replica باشد متصل شوید.
   • در Object Explorer، AlwaysOn High Availability را گسترش دهید.
   • بر روی Availability Groups کلیک راست کرده و New Availability Group Wizard را انتخاب کنید.
   • مرحله 1: Introduction: بر روی Next کلیک کنید.
   • مرحله 2: Specify Availability Group Name: یک نام برای Availability Group خود وارد کنید (مثلاً MyAG). بر روی Next کلیک کنید.
   • مرحله 3: Select Databases: پایگاه‌های داده‌ای که می‌خواهید در این AG قرار گیرند را انتخاب کنید. اطمینان حاصل کنید که تمامی پایگاه‌های داده در Full Recovery Model هستند و از آن‌ها پشتیبان‌گیری کامل و Log Transaction صورت گرفته است. بر روی Next کلیک کنید. انتخاب پایگاه داده برای Availability Group در SQL Server
   • مرحله 4: Specify Replicas:
     • بر روی Add Replica... کلیک کنید و نام نمونه SQL Server ثانویه (Secondary Replica) را وارد کنید.
     • برای هر Replica، تنظیمات زیر را پیکربندی کنید:
       • Availability Mode:
         • Synchronous Commit: برای دسترسی‌پذیری بالا، تضمین می‌کند که داده‌ها قبل از تایید تراکنش، در تمامی Replicaها ثبت شده‌اند. (کمی تاخیر بیشتر، اما بدون از دست دادن داده)
         • Asynchronous Commit: برای بازیابی فاجعه در مسافت‌های طولانی، به Replication با تاخیر اجازه می‌دهد. (عملکرد بالاتر، اما احتمال از دست دادن داده در صورت Failover)
       • Failover Mode:
         • Automatic: برای Failover خودکار (فقط با Synchronous Commit و Enterprise Edition).
         • Manual: برای Failover دستی.
       • Readable Secondary:
         • Yes: برای امکان خواندن داده‌ها از Replica ثانویه.
         • No: Replica ثانویه فقط برای Failover استفاده می‌شود.
     • تب Listener را انتخاب کنید. بر روی Create an availability group listener کلیک کنید.
     • یک DNS Name برای Listener (مثلاً MyAGListener)، پورت (مثلاً 1433) و یک آدرس IP استاتیک (VIP) را وارد کنید که در شبکه شما آزاد باشد. این Listener نقطه اتصال برنامه‌های شما به Availability Group خواهد بود.
     • تب Backup Preferences را پیکربندی کنید. بر روی Next کلیک کنید.
   • مرحله 5: Select Initial Data Synchronization:
     • Full را انتخاب کنید تا Wizard به صورت خودکار پشتیبان‌گیری و Restore پایگاه داده را بر روی Replica ثانویه انجام دهد.
     • یک مسیر شبکه مشترک (Network Share) را مشخص کنید که تمامی گره‌های کلاستر به آن دسترسی داشته باشند.
     • بر روی Next کلیک کنید.
   • مرحله 6: Validation: Wizard صحت پیکربندی را بررسی می‌کند. تمامی هشدارها یا خطاها را برطرف کنید. بر روی Next کلیک کنید.
   • مرحله 7: Summary: تنظیمات را بازبینی کرده و بر روی Finish کلیک کنید.
   • مرحله 8: Results: پس از اتمام موفقیت‌آمیز، پنجره را ببندید.

گام 4: تست Failover و مانیتورینگ

پس از راه‌اندازی Availability Group، ضروری است که عملکرد آن را تست و به طور مداوم مانیتور کنید.

1. تست Failover دستی:
   • در SSMS، در Object Explorer، به AlwaysOn High Availability > Availability Groups بروید.
   • بر روی Availability Group خود کلیک راست کرده و Failover را انتخاب کنید.
   • Failover Wizard شما را در فرآیند Failover دستی راهنمایی می‌کند. این کار به شما اطمینان می‌دهد که Replica ثانویه می‌تواند به عنوان Primary Replica عمل کند.
2. مانیتورینگ:
   • SQL Server Management Studio ابزارهای مانیتورینگ داخلی برای Always On Availability Groups ارائه می‌دهد.
   • در Object Explorer، به AlwaysOn High Availability > Availability Groups بروید.
   • بر روی Availability Group خود کلیک راست کرده و Show Dashboard را انتخاب کنید.
   • Dashboard وضعیت سلامت کلی AG، Replicaها، و پایگاه‌های داده را نمایش می‌دهد.
   • همچنین می‌توانید از Dynamic Management Views (DMVs) مانند sys.dm_hadr_availability_group_states و sys.dm_hadr_database_replica_states برای مانیتورینگ پیشرفته استفاده کنید.

نکته مهم: Brent Ozar (منبع: Brent Ozar) تاکید می‌کند که Always On Availability Groups بر روی Windows clustering تکیه دارد و آشنایی با مفاهیم کلاسترینگ ویندوز برای راه‌اندازی موفقیت‌آمیز ضروری است. همچنین، پایداری شبکه بین Replicaها حیاتی است، چرا که حتی قطعی‌های کوتاه شبکه می‌تواند باعث Offline شدن پایگاه داده‌ها در AG شود.

عیب‌یابی رایج و راه‌حل‌ها

پیاده‌سازی Always On Availability Groups می‌تواند چالش‌برانگیز باشد. در اینجا به برخی از مشکلات رایج و راه‌حل‌های آن‌ها اشاره می‌کنیم:

❓ چرا Availability Group ایجاد نمی‌شود یا Replicaها به درستی همگام‌سازی نمی‌شوند؟

این مشکل معمولاً ناشی از پیکربندی نادرست پیش‌نیازها یا مشکلات شبکه است.

• راه‌حل:
  • 💡 بررسی فایروال: اطمینان حاصل کنید که پورت Database Mirroring Endpoint (معمولاً 5022) و پورت Listener (معمولاً 1433) در فایروال تمامی سرورهای شرکت‌کننده باز هستند.
  • 🔒 بررسی مجوزها: حساب‌های سرویس SQL Server در تمامی Replicaها باید دارای مجوزهای کافی (از جمله مجوز Connect بر روی Endpoint) باشند.
  • 🌐 مشکلات شبکه: از پایداری و پهنای باند کافی شبکه بین Replicaها اطمینان حاصل کنید. مشکلات Latency یا قطع و وصل شدن شبکه می‌تواند Replication را مختل کند.
  • 🔄 ری‌استارت سرویس‌ها: گاهی اوقات ری‌استارت کردن سرویس SQL Server پس از تغییرات پیکربندی Always On ضروری است.
  • 💾 پشتیبان‌گیری اولیه: اطمینان حاصل کنید که تمامی پایگاه‌های داده‌ای که اضافه می‌شوند، از قبل دارای Full Backup و Transaction Log Backup هستند و در Full Recovery Model قرار دارند.

❓ چرا Failover خودکار کار نمی‌کند؟

Failover خودکار نیازمند پیکربندی دقیق و شرایط خاصی است.

• راه‌حل:
  • ⚙️ Availability Mode: مطمئن شوید که Replicaها در حالت Synchronous Commit و Automatic Failover پیکربندی شده‌اند. این قابلیت تنها در Enterprise Edition و برای حداقل دو Replica در حالت Synchronous Commit در دسترس است.
  • 🗳️ Quorum در WSFC: کلاستر WSFC باید دارای Quorum (اکثریت آرا) باشد. اگر تعداد گره‌های کافی آنلاین نباشند، کلاستر ممکن است Offline شود و Failover اتفاق نیفتد. برای کلاسترهای با دو گره، حتماً یک Witness (مانند File Share Witness) پیکربندی کنید.
  • 🚨 وضعیت سلامت Replicaها: تمامی Replicaها باید در وضعیت سلامت (Health State) مناسبی باشند. مشکلات I/O، Log Queue یا Redo Queue بزرگ می‌تواند Failover را با مشکل مواجه کند.

❓ چرا برنامه‌های کاربردی پس از Failover نمی‌توانند به پایگاه داده متصل شوند؟

این مشکل معمولاً به دلیل عدم پیکربندی صحیح Listener یا Cache DNS رخ می‌دهد.

• راه‌حل:
  • 👂 پیکربندی Listener: اطمینان حاصل کنید که Availability Group Listener به درستی ایجاد شده و در DNS ثبت شده است. نام Listener باید به آدرس IP مجازی (VIP) مربوطه Resolution شود.
  • 🔗 Connection String برنامه‌ها: برنامه‌های کاربردی شما باید از نام Listener (به جای نام نمونه SQL Server) در Connection String خود استفاده کنند و پارامتر MultiSubnetFailover=True را اضافه کنند تا Failover در محیط‌های Multi-Subnet سریع‌تر انجام شود.
  • 🗑️ پاک کردن Cache DNS: ممکن است Clientها نیاز داشته باشند Cache DNS خود را پاک کنند تا آدرس IP جدید Listener را دریافت کنند.

❓ آیا می‌توان از Always On Availability Groups در AWS یا Azure استفاده کرد؟

بله، Always On Availability Groups کاملاً با محیط‌های ابری سازگار است (منبع: AWS Prescriptive Guidance، Brent Ozar).

• راه‌حل:
  • ☁️ پیکربندی شبکه ابری: اطمینان حاصل کنید که Subnetها، Security Groupها و Network ACLها به درستی برای Allow کردن ترافیک بر روی پورت‌های SQL Server و Endpoint پیکربندی شده‌اند.
  • 🌐 Multi-Subnet Listener: در محیط‌های ابری، به دلیل استفاده از Multi-Subnet برای افزایش Redundancy، حتماً Listener را با چندین IP و MultiSubnetFailover=True در Connection String Client پیکربندی کنید.

نکات پیشرفته و بهترین شیوه‌ها

برای بهینه‌سازی عملکرد و اطمینان از حداکثر پایداری Always On Availability Groups، نکات پیشرفته زیر را در نظر بگیرید:

1. تنظیمات مناسب برای HA و DR

• HA محلی (در یک دیتاسنتر): برای HA در یک دیتاسنتر، از Synchronous Commit و Automatic Failover استفاده کنید. این پیکربندی کمترین RPO (Recovery Point Objective) و RTO (Recovery Time Objective) را فراهم می‌کند، به این معنی که کمترین از دست رفتن داده و سریع‌ترین زمان بازیابی را خواهید داشت.
• DR در دیتاسنتر دوردست: برای بازیابی فاجعه بین دیتاسنترها، از Asynchronous Commit استفاده کنید. این حالت عملکرد بهتری را در فواصل طولانی ارائه می‌دهد، اما ممکن است در صورت Failover، مقداری از داده‌ها (معمولاً در حد چند ثانیه) از دست برود. در این سناریو، Failover معمولاً Manual است.

2. استفاده از Read-Only Routing برای بهینه‌سازی بار

• همانطور که Microsoft Learn اشاره می‌کند، می‌توانید Replicaهای ثانویه را برای بارهای کاری خواندنی پیکربندی کنید. این کار به توزیع بار کاری و بهبود عملکرد سرور اصلی کمک می‌کند.
• برای فعال‌سازی Read-Only Routing، نیاز به پیکربندی Read-Only Routing URL و Read-Only Routing List دارید که به Listener می‌گوید درخواست‌های خواندنی را به کدام Replica ثانویه هدایت کند.

3. پشتیبان‌گیری از Replicaهای ثانویه

• می‌توانید از Replicaهای ثانویه برای انجام برخی عملیات پشتیبان‌گیری استفاده کنید تا بار از روی Primary Replica برداشته شود (منبع: Microsoft Learn).
• این قابلیت به شما امکان می‌دهد تا پشتیبان‌گیری‌های کامل (copy-only full backup) و پشتیبان‌گیری‌های Log Transaction را از Replicaهای ثانویه انجام دهید.

4. مدیریت کلاستر WSFC

• همانطور که Brent Ozar نیز اشاره دارد، Never On Availability Groups به شدت به کلاستر Windows Server Failover Clustering متکی است.
• به طور منظم وضعیت سلامت کلاستر را مانیتور کنید.
• از پیکربندی Witness مناسب برای کلاستر خود اطمینان حاصل کنید (Disk Witness یا File Share Witness).
• در محیط‌های Multi-Subnet، نیاز به پیکربندی دقیق IP Address منابع کلاستر برای هر Subnet دارید.

5. بهینه‌سازی Log Shipping (در صورت لزوم)

• در حالی که Always On Availability Groups راهکار اصلی HA/DR است، Log Shipping نیز می‌تواند به عنوان یک راهکار مکمل یا جایگزین در شرایط خاص، مثلاً برای DR بسیار طولانی‌مدت یا سناریوهایی که نیاز به Point-in-Time Recovery دارید، استفاده شود (منبع: Microsoft Learn).
• Log Shipping داده‌ها را با استفاده از پشتیبان‌گیری‌های Log Transaction از یک سرور به سرور دیگر منتقل می‌کند.

6. امنیت و رمزگذاری

• Always On Availability Groups از رمزگذاری داخلی برای ترافیک Endpoint استفاده می‌کند. با این حال، همیشه بهترین practice این است که ارتباطات شبکه بین Replicaها را با ابزارهایی مانند VPN یا IPsec بیشتر امن کنید، خصوصاً در سناریوهای DR بین دیتاسنترها یا در فضای ابری.

با در نظر گرفتن این نکات و پیروی از راهنمای گام‌به‌گام، سازمان‌ها می‌توانند یک راهکار Always On Availability Groups قوی و قابل اطمینان برای SQL Server خود پیاده‌سازی کنند که به پایداری کسب‌وکار آن‌ها کمک شایانی خواهد کرد.

راهنمای خرید و ملاحظات ایران

استفاده از Always On Availability Groups نیازمند لایسنس SQL Server است که بسته به نسخه انتخابی (Standard یا Enterprise) و نحوه لایسنسینگ (Core-based یا Server+CAL) هزینه‌های متفاوتی خواهد داشت. برای سازمان‌های ایرانی، دستیابی به لایسنس‌های اورجینال مایکروسافت، به دلیل تحریم‌ها، از اهمیت و پیچیدگی خاصی برخوردار است.

نکات مهم برای خرید و لایسنسینگ در ایران:

• لایسنس SQL Server Enterprise Edition: برای بهره‌مندی کامل از قابلیت‌های Always On Availability Groups از جمله Failover خودکار، تعداد Replicaهای متعدد و Read-Scale، نیاز به لایسنس SQL Server Enterprise Edition دارید. این نسخه معمولاً بر اساس تعداد Core لایسنس می‌شود.
• لایسنس SQL Server Standard Edition: اگرچه با Standard Edition می‌توانید از Basic Availability Groups (BAG) استفاده کنید (محدود به یک پایگاه داده در هر گروه و یک Replica ثانویه و Failover دستی)، این گزینه برای HA و DR سطح Enterprise کافی نیست و برای سازمان‌های کوچک‌تر با نیازهای محدودتر مناسب است. این نسخه هم می‌تواند بر اساس Core یا Server+CAL لایسنس شود.
• انواع لایسنس (OEM، Retail، Volume):
  • OEM: معمولاً همراه با سرورهای جدید ارائه می‌شود و به سخت‌افزار خاصی گره خورده است. قابلیت انتقال‌پذیری محدودی دارد.
  • Retail: برای کاربران نهایی و در حجم کم مناسب است. معمولاً شامل پکیج فیزیکی می‌شود.
  • Volume Licensing: برای سازمان‌ها و شرکت‌ها با حجم خرید بالاتر، بهترین گزینه است. این نوع لایسنسینگ انعطاف‌پذیری بیشتری در مدیریت و استقرار ارائه می‌دهد و امکاناتی مانند Software Assurance را فراهم می‌کند که شامل حقوق استفاده از نسخه‌های جدید و پشتیبانی پیشرفته می‌شود. در ایران، تهیه Volume Licensing از طریق شرکت‌های معتبر و واسطه‌ای که با محدودیت‌های تحریم آشنا هستند، انجام می‌شود.
• خرید قانونی از داخل ایران: با توجه به تحریم‌ها، خرید مستقیم لایسنس‌ها از مایکروسافت برای کاربران ایرانی ممکن نیست. سازمان‌ها و افراد در ایران می‌توانند از طریق شرکت‌های واسط و نمایندگی‌های معتبر در منطقه که دارای مجوزهای لازم هستند، لایسنس‌های اورجینال مایکروسافت را تهیه کنند. این شرکت‌ها معمولاً با واردات قانونی و مدیریت لایسنس‌ها، امکان دسترسی به محصولات مایکروسافت را فراهم می‌کنند.
• Software Assurance (SA): برای راهکارهای HA/DR مانند Always On Availability Groups، داشتن Software Assurance بسیار توصیه می‌شود. SA امکانات کلیدی مانند Disaster Recovery Rights (حق استفاده از یک سرور DR رایگان در سایت دوم)، Upgrade Rights به نسخه‌های جدید و پشتیبانی فنی را فراهم می‌آورد که در بلندمدت هزینه‌ها را کاهش داده و پایداری زیرساخت را تضمین می‌کند.
• مشاوره و انتخاب لایسنس: برای انتخاب نسخه مناسب SQL Server و مدل لایسنسینگ بهینه برای نیازهای خاص کسب‌وکار خود در ایران، استفاده از ابزارهایی مانند انتخاب‌گر نسخه SQL Server و مشاوره با کارشناسان لایسنسینگ می‌تواند بسیار مفید باشد. همچنین، برای اطلاع از جزئیات بیشتر در مورد لایسنس SQL Server و سایر محصولات مایکروسافت، می‌توانید به بخش مربوطه در وب‌سایت ما مراجعه کنید.

پرسش‌های متداول

آیا Always On Availability Groups می‌تواند جایگزین مناسبی برای Database Mirroring باشد؟

بله، Always On Availability Groups در واقع راهکاری پیشرفته‌تر و جامع‌تر نسبت به Database Mirroring است که مایکروسافت آن را جایگزین Mirroring معرفی کرده است (منبع: Microsoft Learn). AGs قابلیت‌هایی مانند چندین Replica ثانویه، Failover خودکار پیشرفته‌تر، Read-Scale و انعطاف‌پذیری بیشتر در پیکربندی HA و DR را ارائه می‌دهد.

چه تفاوتی بین Synchronous Commit و Asynchronous Commit در Always On Availability Groups وجود دارد؟

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

آیا می‌توان یک Availability Group را بین سرورهای فیزیکی و مجازی پیکربندی کرد؟

بله، Always On Availability Groups می‌تواند بین سرورهای فیزیکی، مجازی یا ترکیبی از هر دو پیکربندی شود. در محیط‌های مجازی، مانند آنچه در دیتاسنترهای داخلی ایران یا سرویس‌دهندگان ابری مانند Azure و AWS وجود دارد، پیاده‌سازی AGs کاملاً پشتیبانی می‌شود (منبع: Microsoft Learn). مهم است که پیش‌نیازهای شبکه و منابع سخت‌افزاری/مجازی به درستی تامین شود.

Listener در Always On Availability Group چه نقشی دارد؟

Listener یک نام شبکه مجازی است که به کلاینت‌ها اجازه می‌دهد بدون دانستن اینکه کدام Replica در حال حاضر Primary است، به Availability Group متصل شوند. Listener درخواست‌های اتصال را به Primary Replica فعلی هدایت می‌کند. این ویژگی شفافیت failover را برای برنامه‌های کاربردی فراهم می‌کند و نیازی به تغییر Connection String در هنگام Failover نیست.

چگونه می‌توان Always On Availability Groups را در SQL Server Standard Edition پیاده‌سازی کرد؟

در SQL Server Standard Edition، می‌توانید از قابلیت Basic Availability Groups (BAG) استفاده کنید. BAG محدود به یک پایگاه داده در هر گروه، یک Primary Replica و یک Secondary Replica است و فقط از Failover دستی پشتیبانی می‌کند (منبع: SQLServerCentral). برای پیاده‌سازی BAG، مراحل کلی مشابه راه‌اندازی AG در Enterprise Edition است، اما باید محدودیت‌های ذکر شده را در نظر بگیرید.

آیا برای فعال‌سازی Always On Availability Groups، نیاز به Windows Server Failover Clustering (WSFC) است؟

بله، برای تمامی انواع Always On Availability Groups (چه Basic و چه Enterprise)، استفاده از Windows Server Failover Clustering (WSFC) به عنوان بستر اصلی برای هماهنگی و مدیریت Failover بین Replicaها ضروری است (منبع: Microsoft Learn). تمامی گره‌های SQL Server شرکت‌کننده در AG باید بخشی از یک کلاستر WSFC باشند.

چگونه از امنیت داده‌ها در Always On Availability Groups اطمینان حاصل کنیم؟

Always On Availability Groups از رمزگذاری داخلی برای ترافیک Endpoint بین Replicaها استفاده می‌کند. علاوه بر این، باید از روش‌های استاندارد امنیت پایگاه داده مانند رمزگذاری TDE برای پایگاه داده‌ها، کنترل دسترسی دقیق به SQL Server و سیستم عامل، و امنیت شبکه (فایروال، VPN) استفاده کنید. مانیتورینگ مداوم وضعیت امنیتی نیز از اهمیت بالایی برخوردار است.

جمع‌بندی

در این راهنمای جامع، به بررسی Always On Availability Groups در SQL Server پرداختیم و نحوه استقرار گام‌به‌گام این راهکار قدرتمند برای دسترسی‌پذیری بالا (HA) و بازیابی فاجعه (DR) را تشریح کردیم. از فعال‌سازی قابلیت‌ها و پیکربندی Endpoint گرفته تا ایجاد Availability Group و مانیتورینگ، تمامی مراحل ضروری را پوشش دادیم. همچنین، به تفاوت‌های کلیدی بین نسخه‌های Standard و Enterprise Edition و بهترین شیوه‌ها برای بهینه‌سازی و عیب‌یابی اشاره شد.

برای سازمان‌های ایرانی، پایداری زیرساخت‌های فناوری اطلاعات، به ویژه پایگاه‌های داده حیاتی، از اهمیت بالایی برخوردار است. Always On Availability Groups راهکاری مطمئن برای تضمین تداوم کسب‌وکار در برابر هرگونه اختلال است. انتخاب صحیح نسخه SQL Server و مدیریت لایسنسینگ، گام‌های اساسی در این مسیر محسوب می‌شوند.

برای کسب اطلاعات بیشتر در مورد لایسنس‌های SQL Server و سایر محصولات مایکروسافت، و دریافت مشاوره تخصصی برای نیازهای خاص کسب‌وکار خود در ایران، به لایسنس سنتر دات نت (licensecenter.net) مراجعه فرمایید. ما آماده ارائه راهکارهای مطمئن و قانونی برای تامین لایسنس‌های اورجینال مایکروسافت در ایران هستیم.