0Pricing
AWS Solutions Architect · درس

أنماط Multi-AZ للخدمات ذات الحالة

طبّق Multi-AZ على RDS وElastiCache وEFS وELB لإزالة نقاط الفشل الوحيدة داخل Region

أنماط Multi-AZ للخدمات ذات الحالة درس مجاني في AWS Solutions Architect على CoddyKit. هذا هو الدرس 2 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في AWS Solutions Architect، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة AWS Solutions Architect 4 دروس في المجموع.

لماذا تحتاج الخدمات ذات الحالة إلى مناطق توافر متعددة

تُعد الخدمات ذات الحالة — قواعد البيانات وذاكرات التخزين المؤقت وأنظمة الملفات — أصعب المكونات من حيث جعلها عالية التوافر، لأنها تحتوي على بيانات يجب أن تبقى محفوظة عند حدوث الأعطال. فإذا تعطلت قاعدة بيانات في منطقة توافر واحدة، يفقد التطبيق بأكمله مخزن بياناته. ويتمثل حل AWS في عمليات النشر متعددة المناطق، حيث تحافظ الخدمة على نسخة متماثلة متزامنة أو شبه متزامنة في منطقة توافر ثانية يمكنها تولي العمل بسرعة عند تعطل النسخة الأساسية.

RDS Multi-AZ: النسخة الاحتياطية المتزامنة

يحافظ RDS Multi-AZ على نسخة احتياطية متزامنة في منطقة توافر مختلفة. وتتم مزامنة كل عملية كتابة إلى النسخة الأساسية قبل تأكيد نجاحها، ما يعني عدم فقدان البيانات (RPO=0)، مع زيادة طفيفة في زمن الكتابة. وعند تعطل النسخة الأساسية، يحدّث RDS نقطة نهاية DNS تلقائيًا لتشير إلى النسخة الاحتياطية خلال 60-120 ثانية. ولا يحتاج تطبيقكم إلا إلى إعادة الاتصال بنقطة النهاية نفسها، من دون الحاجة إلى تغيير الشيفرة.

# Enable Multi-AZ on existing RDS instance
aws rds modify-db-instance \
  --db-instance-identifier mydb \
  --multi-az \
  --apply-immediately

# RDS endpoint stays the same after failover
# Application reconnects to same DNS name

بنية Aurora متعددة مناطق التوافر

تتجاوز Amazon Aurora إمكانات Multi-AZ من خلال طبقة تخزين موزعة مشتركة تُكرّر البيانات تلقائيًا عبر ثلاث مناطق توافر (AZs) في ست نسخ. تكون مثيلات Aurora عديمة الحالة — إذ تقرأ البيانات وتكتبها في وحدة التخزين المشتركة. عند تعطل مثيل Aurora الأساسي المسؤول عن الكتابة، تتم ترقية نسخة قراءة متماثلة في منطقة توافر أخرى لتصبح مسؤولة عن الكتابة خلال أقل من 30 ثانية. ويُعد ذلك أسرع من تجاوز الفشل في RDS Multi-AZ، كما تكون البيانات متسقة دائمًا عبر مناطق التوافر دون الحاجة إلى نسخ صريح إلى مثيل احتياطي.

# Aurora cluster endpoint automatically handles failover
# Writer endpoint: mydb.cluster-xxx.us-east-1.rds.amazonaws.com
# Reader endpoint: mydb.cluster-ro-xxx.us-east-1.rds.amazonaws.com

# Failover time: typically under 30 seconds

النسخ المتماثل متعدد مناطق التوافر في ElastiCache

يدعم ElastiCache for Redis ميزة Multi-AZ من خلال مجموعات النسخ المتماثلة. تقبل عقدة أساسية عمليات الكتابة وتنسخها بشكل غير متزامن إلى نسخ قراءة متماثلة في مناطق توافر أخرى. عند تعطل العقدة الأساسية، ترقّي ElastiCache تلقائيًا إحدى النسخ المتماثلة لتصبح العقدة الأساسية. في وضع Redis الذي يكون فيه cluster mode enabled، تُقسّم البيانات عبر مجموعات عقد متعددة، لكل منها عقدة أساسية ونسخ متماثلة خاصة بها موزعة عبر مناطق التوافر — مما يوفر التوافر العالي والتوسّع الأفقي معًا.

# Create Redis replication group with Multi-AZ
aws elasticache create-replication-group \
  --replication-group-id my-redis \
  --replication-group-description 'Multi-AZ Redis' \
  --num-cache-clusters 3 \
  --cache-node-type cache.r6g.large \
  --multi-az-enabled \
  --automatic-failover-enabled

EFS: متعدد مناطق التوافر بطبيعته

يتميّز Amazon Elastic File System (EFS) بكونه متعدد مناطق التوافر بطبيعته — فهو خدمة إقليمية تخزّن البيانات بشكل مكرر عبر مناطق توافر متعددة داخل المنطقة. تنشئ أهداف التحميل في الشبكة الفرعية لكل منطقة توافر، ويمكن لمثيلات EC2 في أي منطقة توافر تحميل نظام الملفات من خلال هدف التحميل المحلي الخاص بها. لا يلزم إجراء أي إعداد يدوي لميزة Multi-AZ. يوفر EFS تخزين ملفات مشتركًا متوافقًا مع POSIX، ويمكن لعدة مثيلات عبر مناطق التوافر الوصول إليه في الوقت نفسه.

# Mount EFS from EC2 in any AZ
# Mount target is created per AZ automatically
sudo mount -t efs -o tls fs-12345678:/ /mnt/efs

# Or use EFS mount helper
sudo mount -t efs fs-12345678 /mnt/efs

موازنة الحمل عبر مناطق التوافر في Elastic Load Balancer

تتسم Elastic Load Balancers نفسها بكونها متعددة مناطق التوافر — إذ تنشر ALB وNLB عقد موازن الحمل في كل منطقة توافر تحددها. عند تمكين موازنة الحمل عبر المناطق (وهو الإعداد الافتراضي في ALB)، توزّع كل عقدة من عقد موازن الحمل حركة المرور بالتساوي على جميع الأهداف المسجلة في جميع مناطق التوافر، وليس في منطقة التوافر الخاصة بها فقط. ويضمن ذلك استمرار موازن الحمل في تقديم حركة المرور من خلال المثيلات الموجودة في مناطق التوافر المتبقية، حتى عند تعطل جميع المثيلات في إحدى المناطق.

# ALB automatically created in multiple AZs
aws elbv2 create-load-balancer \
  --name my-alb \
  --subnets subnet-AZ1 subnet-AZ2 subnet-AZ3 \
  --security-groups sg-12345

# Cross-zone load balancing is ON by default for ALB

نمط NAT Gateway متعدد مناطق التوافر

من الأخطاء الشائعة نشر NAT Gateway واحد في منطقة توافر واحدة، بينما توجه الشبكات الفرعية الخاصة في مناطق توافر أخرى مسارها من خلاله. فإذا تعطلت تلك المنطقة، تفقد جميع المثيلات الخاصة إمكانية الوصول إلى الإنترنت. يتمثل النمط الصحيح لميزة Multi-AZ في نشر NAT Gateway واحد لكل منطقة توافر، وتهيئة جدول التوجيه الخاص بكل منطقة توافر لتوجيه 0.0.0.0/0 عبر NAT Gateway الخاص بها. ويؤدي ذلك إلى إزالة NAT Gateway باعتباره نقطة فشل فردية (SPOF) عبر مناطق التوافر، كما يقلل تكاليف نقل البيانات عبرها.

# Create NAT Gateway in each AZ
aws ec2 create-nat-gateway \
  --subnet-id subnet-public-AZ1 \
  --allocation-id eipalloc-AZ1

aws ec2 create-nat-gateway \
  --subnet-id subnet-public-AZ2 \
  --allocation-id eipalloc-AZ2

# Each AZ's private route table points to its own NAT GW

DynamoDB متعدد مناطق التوافر افتراضيًا

إن DynamoDB خدمة مُدارة بالكامل، وتنسخ البيانات تلقائيًا عبر ثلاث مناطق توافر داخل المنطقة — ولا تحتاج إلى تهيئة Multi-AZ يدويًا. تُخزّن كل عملية كتابة بشكل دائم عبر مناطق التوافر الثلاث قبل إرجاع نتيجة النجاح. وبذلك يكون DynamoDB متحملًا للأعطال على مستوى منطقة التوافر فورًا ومن دون إعداد إضافي. ولهذا السبب غالبًا ما يُوصى باستخدام DynamoDB كخيار قاعدة البيانات عندما يؤكد سؤال الاختبار على التوافر العالي مع أقل قدر من العبء التشغيلي.

RDS Proxy لمعالجة الاتصالات بشكل أسرع

أثناء تجاوز الفشل في RDS Multi-AZ، قد تواجه التطبيقات التي تحتفظ باتصالات دائمة بقاعدة البيانات أعطالًا عند تغير نقطة النهاية. يعمل RDS Proxy بين تطبيقك وRDS، ويحافظ على مجموعة من الاتصالات بقاعدة البيانات. أثناء تجاوز الفشل، يعيد RDS Proxy توجيه الاتصالات تلقائيًا إلى العقدة الأساسية الجديدة، مما يقلل تأثير تجاوز الفشل من 60-120 ثانية إلى أقل من 30 ثانية للتطبيقات التي تستخدم نقطة نهاية الوكيل. ويساعد RDS Proxy أيضًا مع وظائف Lambda التي تنشئ عددًا كبيرًا من الاتصالات قصيرة العمر.

# Application connects to RDS Proxy endpoint
# Proxy endpoint: myproxy.proxy-xxx.us-east-1.rds.amazonaws.com

# RDS Proxy handles:
# - Connection pooling
# - Failover routing
# - IAM authentication
# - Secrets Manager integration

أوضاع نسخ البيانات: متزامن مقابل غير متزامن

يُعد فهم أوضاع النسخ أمرًا بالغ الأهمية لاختيار أنماط Multi-AZ المناسبة. يضمن النسخ المتزامن (RDS Multi-AZ وEFS) أن تكون RPO=0، لأن كل عملية كتابة يُؤكَّد إتمامها في كلتا منطقتي التوافر قبل إرجاع نتيجة النجاح. والمقابل لذلك هو زيادة طفيفة في زمن استجابة الكتابة. أما النسخ غير المتزامن (نسخ ElastiCache Redis المتماثلة وRDS Read Replicas)، فيوفر زمن استجابة أقل للكتابة، لكنه يقبل تأخرًا بسيطًا في النسخ، ما يعني احتمال فقدان بعض البيانات إذا تعطلت العقدة الأساسية قبل اكتمال النسخ.

# Synchronous replication: RPO = 0, higher write latency
# Used by: RDS Multi-AZ, Aurora storage layer

# Asynchronous replication: RPO > 0 (replication lag)
# Used by: RDS Read Replicas, ElastiCache Redis replicas
# Replication lag can be monitored:
# aws cloudwatch get-metric-statistics \
#   --namespace AWS/RDS --metric-name ReplicaLag

اختبار تجاوز الفشل في Multi-AZ

ينبغي اختبار تجاوز الفشل في Multi-AZ بانتظام للتحقق من افتراضات RTO الخاصة بك. في RDS، يمكنك تشغيل تجاوز الفشل باستخدام خيار Reboot with failover في وحدة التحكم أو باستخدام CLI. راقب CloudWatch بحثًا عن المقياس FailedSQLServerAgentJobsCount، وراقب سجلات تطبيقك للتحقق من نجاح إعادة الاتصال. وثّق مدة تجاوز الفشل الفعلية، فقد تختلف عن المدة الواردة في وثائق AWS حسب فئة المثيل وحِمل العمل.

# Trigger RDS Multi-AZ failover test
aws rds reboot-db-instance \
  --db-instance-identifier mydb \
  --force-failover

# Monitor failover in CloudWatch
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name DatabaseConnections \
  --dimensions Name=DBInstanceIdentifier,Value=mydb

تحقق سريع

اختبر مدى فهمك لمفاهيم AWS Solutions Architect (SAA-C03) الواردة في هذا الدرس.

مراجعة الدرس

تعلمت في هذا الدرس أن RDS Multi-AZ يستخدم النسخ المتزامن مع تجاوز فشل تلقائي عبر DNS، وأن Aurora يستخدم طبقة تخزين مشتركة عبر ثلاث مناطق توافر لتسريع تجاوز الفشل، وأن EFS وDynamoDB متعددا مناطق التوافر بطبيعتهما من دون إعداد يدوي. انشر NAT Gateway واحدًا لكل منطقة توافر لتجنب نقاط الفشل الفردية (SPOFs) عبر مناطق التوافر. سنستكشف بعد ذلك أنماط التشغيل النشط-النشط والنشط-الاحتياطي في مناطق متعددة.

الأسئلة الشائعة

هل درس «أنماط Multi-AZ للخدمات ذات الحالة» مجاني؟

نعم — نص درس «أنماط Multi-AZ للخدمات ذات الحالة» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة AWS Solutions Architect، انتقل إلى CoddyKit PRO. تتضمن دورة AWS Solutions Architect 4 دروس في المجموع.

ماذا ستتعلم في «أنماط Multi-AZ للخدمات ذات الحالة»؟

طبّق Multi-AZ على RDS وElastiCache وEFS وELB لإزالة نقاط الفشل الوحيدة داخل Region تتمرن على AWS Solutions Architect مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.

هل أحتاج إلى خبرة سابقة لأبدأ AWS Solutions Architect؟

لا تُشترط خبرة سابقة. AWS Solutions Architect على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 2 من أصل 4.

كم من الوقت يستغرق درس «أنماط Multi-AZ للخدمات ذات الحالة»؟

معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.

هل يمكنني كتابة وتشغيل أكواد في درس AWS Solutions Architect هذا؟

نعم. كل درس في AWS Solutions Architect يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.

جميع الدروس في هذه الدورة

  1. التوافر العالي في مقابل تحمّل الأعطال: التعريفات والمفاضلات
  2. أنماط Multi-AZ للخدمات ذات الحالة
  3. النشط-النشط والنشط-الخامل متعدد المناطق
  4. فحوصات الصحة وقواطع الدائرة ومنطق إعادة المحاولة
← العودة إلى AWS Solutions Architect