The Cloud Warrior

كل ما تحتاج معرفته عن SQL Server Always On على Azure وفي البيئات الهجينة

تطبيقات الأعمال الحساسة تحتاج دائمًا إلى توافر عالي (High Availability) وخطة تعافي من الكوارث (Disaster Recovery) مع تقليل التوقف لأدنى حد.
هنا بيجي دور SQL Server Always On اللي بيوفر آلية قوية تخلي قواعد البيانات متاحة حتى أثناء الأعطال أو الصيانة، سواء داخل بيئة محلية أو على Azure أو في سيناريو هجين يجمع بين الاثنين.

🔹 فكرة عمل Always On

• يقوم Always On Availability Groups (AGs) بإنشاء مجموعة من النسخ المتماثلة (Replicas) لقاعدة البيانات:
  • Primary Replica: النسخة الرئيسية التي تستقبل عمليات القراءة والكتابة.
  • Secondary Replicas: نسخ متزامنة أو شبه متزامنة للتعافي عند فشل النسخة الرئيسية.
• يمكن أن يكون الـ Failover أوتوماتيكيًا أو يدويًا.
• التطبيقات بتوصل لقاعدة البيانات دائمًا عن طريق Listener بدون الحاجة لمعرفة أي نسخة هي الأساسية حاليًا.

🔹 المكونات الرئيسية

• Availability Group: مجموعة قواعد بيانات تتحرك كوحدة واحدة عند الفشل.
• Primary Replica: نقطة الكتابة الأساسية.
• Secondary Replica: قد تكون للـ HA (متزامنة) أو للـ DR (غير متزامنة).
• Listener: اسم وشبكة افتراضية لسهولة الاتصال بالتطبيقات.
• Cloud Witness: يستخدم لتحديد حالة الـ quorum في بيئات Azure أو الهجينة.

🔹 خيارات Always On على Azure

1. تشغيل SQL Server على VMs (IaaS)
   • هتبني Windows Server Failover Cluster (WSFC) مع Cloud Witness في Azure.
   • وزّع الـ VMs على Availability Zones داخل نفس الإقليم لضمان التوافر العالي.
   • استخدم Internal Load Balancer لتوفير Listener.
   • التخزين الموصى به: Premium SSD أو Ultra Disk.
2. استخدام Azure SQL Managed Instance (MI)
   • خيار مُدار بالكامل يوفر توافر عالي داخل الإقليم.
   • يمكن ربطه بالبيئة المحلية باستخدام Managed Instance Link لمزامنة بيانات شبه لحظية من SQL Server المحلي إلى MI.
   • يدعم Auto-failover groups بين الأقاليم المختلفة لتوفير DR داخل Azure.

🔹 الربط بين Azure وOn-Premises (سيناريو هجين)

• On-Prem ↔ Azure VMs
  • ربط الشبكة عبر ExpressRoute أو VPN.
  • عادةً بيكون الاتصال Asynchronous بسبب قيود الـ latency، وبكده بيكون مناسب للـ DR.
  • إعداد Multi-Subnet Listener باستخدام DNS وAzure Load Balancer.
  • حماية الاتصال باستخدام NSG وAzure Firewall.
• On-Prem ↔ Azure SQL Managed Instance
  • استخدام Managed Instance Link لمزامنة البيانات شبه اللحظية.
  • مناسب للتحول التدريجي إلى السحابة أو تشغيل تقارير ثقيلة على نسخة Azure دون التأثير على النسخة المحلية.
• Azure Region ↔ Azure Region
  • في بيئات Azure فقط يمكن استخدام:
    • Distributed AG على VMs.
    • أو Auto-failover groups مع MI أو Azure SQL Database.

🔹 نصائح عملية

• ما تعتمدش على synchronous commit إلا في نفس الموقع أو عند وجود latency أقل من 10ms.
• احرص على وجود Runbooks وخطط اختبار دورية لسيناريوهات الفشل.
• قم بتأمين البورت زي TCP 5022، واستخدم Private Endpoints عند الإمكان.
• ضع خطة واضحة للـ RPO وRTO بما يناسب متطلبات عملك.

✅ في النهاية 

• داخل Azure فقط: VMs مع Always On AG + Cloud Witness أو Managed Instance مع Auto-failover.
• هجين On-Prem ↔ Azure: يفضل asynchronous commit مع Listener متعدد الشبكات وExpressRoute لضمان أمان وسرعة الاتصال.
• DR بسيط: استخدم Managed Instance Link لنسخ البيانات دون إدارة معقدة للـ WSFC.