مختبر: تكوين Failover Route 53
هدف المختبر
تصميم وتكوين حل failover DNS باستخدام Route 53 لضمان استمرارية الخدمة أثناء حدوث عطل.
الجزء 1: السيناريو
السياق
GlobalBank هي بنك عبر الإنترنت يجب أن تحافظ على توفر بنسبة 99.99%. في حالة حدوث عطل في البنية التحتية الرئيسية، يجب إعادة توجيه العملاء تلقائيًا إلى موقع احتياطي.
الهندسة المستهدفة
┌─────────────────────────────────────────────────────────────┐
│ الهندسة المعمارية FAILOVER GLOBALBANK │
├─────────────────────────────────────────────────────────────┤
│ │
│ www.globalbank.com │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ Route 53 │ │
│ │ │ │
│ │ Health Check │ │
│ └──────┬───────┘ │
│ │ │
│ ┌────┴────┐ │
│ │ │ │
│ ▼ ▼ │
│ PRIMARY SECONDARY │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ us-east-1 │ │ eu-west-1 │ │
│ │ │ │ │ │
│ │ ┌───────────┐ │ │ ┌───────────┐ │ │
│ │ │ ALB │ │ │ │ ALB │ │ │
│ │ └─────┬─────┘ │ │ └─────┬─────┘ │ │
│ │ │ │ │ │ │ │
│ │ ┌─────┴─────┐ │ │ ┌─────┴─────┐ │ │
│ │ │ EC2 ASG │ │ │ │ EC2 ASG │ │ │
│ │ └───────────┘ │ │ └───────────┘ │ │
│ │ │ │ │ │ │ │
│ │ ┌───────────┐ │ │ ┌───────────┐ │ │
│ │ │ RDS Multi │ │ │ │ RDS Read │ │ │
│ │ │ AZ │ │ │ │ Replica │ │ │
│ │ └───────────┘ │ │ └───────────┘ │ │
│ │ │ │ │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
│ عادي: 100% حركة المرور → us-east-1 │
│ Failover: 100% حركة المرور → eu-west-1 │
│ │
└─────────────────────────────────────────────────────────────┘
المتطلبات
| المتطلب | القيمة |
|---|---|
| التوفر | 99.99% |
| RTO (هدف وقت الاسترداد) | < 5 دقائق |
| RPO (هدف نقطة الاسترداد) | < 1 دقيقة |
| كشف العطل | < 90 ثانية |
الجزء 2: تكوين Health Checks
تمرين 2.1: إنشاء Health Check Primary
أكمل تكوين الـ health check:
aws route53 create-health-check \
--caller-reference globalbank-primary-$(date +%s) \
--health-check-config '{
"Type": "_______________",
"ResourcePath": "_______________",
"FullyQualifiedDomainName": "primary-alb.us-east-1.elb.amazonaws.com",
"Port": ___,
"RequestInterval": ___,
"FailureThreshold": ___,
"EnableSNI": true,
"Regions": ["us-east-1", "us-west-2", "eu-west-1"]
}'
💡 الحل
aws route53 create-health-check \
--caller-reference globalbank-primary-$(date +%s) \
--health-check-config '{
"Type": "HTTPS",
"ResourcePath": "/health",
"FullyQualifiedDomainName": "primary-alb.us-east-1.elb.amazonaws.com",
"Port": 443,
"RequestInterval": 10,
"FailureThreshold": 2,
"EnableSNI": true,
"Regions": ["us-east-1", "us-west-2", "eu-west-1"]
}'
توضيحات:
RequestInterval: 10= التحقق كل 10 ثوانٍ (سريع)FailureThreshold: 2= فشلين متتاليين = غير صحي- أقصى وقت للكشف = 10 ث × 2 = 20 ثانية
- 3 مناطق لتجنب الإيجابيات الكاذبة
تمرين 2.2: حساب وقت الكشف
مع المعلمات التالية، احسب الوقت الأقصى للكشف عن عطل:
| المعلمة | القيمة |
|---|---|
| Request Interval | 10 ثوانٍ |
| Failure Threshold | 2 |
| عدد الفاحصين | 3 مناطق |
أقصى وقت للكشف = ؟
💡 الحل
أقصى وقت للكشف = Request Interval × Failure Threshold
= 10s × 2
= 20 ثانية
ملاحظة: يعتبر Route 53 الـ health check "غير صحي" عندما
يبلغ على الأقل 18% من الفاحصين (1 من 3 على الأقل) عن فشل.
الوقت الفعلي النموذجي: 15-25 ثانية
الجزء 3: تكوين الـ Failover
تمرين 3.1: سجل Primary
aws route53 change-resource-record-sets \
--hosted-zone-id Z1234567890ABC \
--change-batch '{
"Changes": [{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "www.globalbank.com",
"Type": "A",
"SetIdentifier": "_______________",
"Failover": "_______________",
"AliasTarget": {
"HostedZoneId": "Z35SXDOTRQ7X7K",
"DNSName": "primary-alb.us-east-1.elb.amazonaws.com",
"EvaluateTargetHealth": ___
},
"HealthCheckId": "xxx-primary-health-check"
}
}]
}'
💡 الحل
aws route53 change-resource-record-sets \
--hosted-zone-id Z1234567890ABC \
--change-batch '{
"Changes": [{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "www.globalbank.com",
"Type": "A",
"SetIdentifier": "primary-us-east-1",
"Failover": "PRIMARY",
"AliasTarget": {
"HostedZoneId": "Z35SXDOTRQ7X7K",
"DNSName": "primary-alb.us-east-1.elb.amazonaws.com",
"EvaluateTargetHealth": true
},
"HealthCheckId": "xxx-primary-health-check"
}
}]
}'
تمرين 3.2: سجل Secondary
aws route53 change-resource-record-sets \
--hosted-zone-id Z1234567890ABC \
--change-batch '{
"Changes": [{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "www.globalbank.com",
"Type": "A",
"SetIdentifier": "_______________",
"Failover": "_______________",
"AliasTarget": {
"HostedZoneId": "Z1234567890DEF",
"DNSName": "secondary-alb.eu-west-1.elb.amazonaws.com",
"EvaluateTargetHealth": ___
}
}
}]
}'
💡 الحل
aws route53 change-resource-record-sets \
--hosted-zone-id Z1234567890ABC \
--change-batch '{
"Changes": [{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "www.globalbank.com",
"Type": "A",
"SetIdentifier": "secondary-eu-west-1",
"Failover": "SECONDARY",
"AliasTarget": {
"HostedZoneId": "Z1234567890DEF",
"DNSName": "secondary-alb.eu-west-1.elb.amazonaws.com",
"EvaluateTargetHealth": true
}
}
}]
}'
ملاحظة: لا يحتاج الـ secondary إلى HealthCheckId لأنه يستخدم فقط عندما يكون الـ primary غير صحي.
الجزء 4: سيناريوهات الاختبار
تمرين 4.1: خطة اختبار Failover
أكمل خطة الاختبار:
| الخطوة | الإجراء | النتيجة المتوقعة | التحقق |
|---|---|---|---|
| 1 | الحالة الأولية | ؟ | ؟ |
| 2 | محاكاة عطل الـ primary | ؟ | ؟ |
| 3 | التحقق من الـ failover | ؟ | ؟ |
| 4 | استعادة الـ primary | ؟ | ؟ |
| 5 | التحقق من الـ failback | ؟ | ؟ |
💡 الحل
| الخطوة | الإجراء | النتيجة المتوقعة | التحقق |
|---|---|---|---|
| 1 | الحالة الأولية | DNS يحل إلى ALB us-east-1 | dig www.globalbank.com |
| 2 | إيقاف الـ ALB primary أو إرجاع 503 | health check يصبح غير صحي | Console Route 53 |
| 3 | الانتظار 30 ثانية | DNS يحل إلى ALB eu-west-1 | dig www.globalbank.com |
| 4 | استعادة الـ ALB primary | health check يصبح صحي | Console Route 53 |
| 5 | انتظار الانتشار | DNS يحل إلى ALB us-east-1 | dig www.globalbank.com |
تمرين 4.2: سكريبت الاختبار
#!/bin/bash
# test-failover.sh
DOMAIN="www.globalbank.com"
PRIMARY_IP="52.xxx.xxx.xxx"
SECONDARY_IP="54.xxx.xxx.xxx"
echo "=== اختبار Failover Route 53 ==="
# الخطوة 1: التحقق من الحالة الأولية
echo "1. الحالة الأولية..."
CURRENT_IP=$(dig +short $DOMAIN | head -1)
if [ "$CURRENT_IP" == "$PRIMARY_IP" ]; then
echo " ✅ DNS يشير إلى PRIMARY"
else
echo " ❌ DNS لا يشير إلى PRIMARY: $CURRENT_IP"
exit 1
fi
# الخطوة 2: محاكاة العطل (يدوي)
echo "2. قم بمحاكاة عطل الـ PRIMARY الآن..."
echo " (أوقف الـ ALB أو عدل /health لإرجاع 503)"
read -p " اضغط على Enter عند الانتهاء..."
# الخطوة 3: انتظار الـ failover
echo "3. انتظار الـ failover (60 ثانية كحد أقصى)..."
for i in {1..12}; do
sleep 5
CURRENT_IP=$(dig +short $DOMAIN | head -1)
echo " تحقق $i: $CURRENT_IP"
if [ "$CURRENT_IP" == "$SECONDARY_IP" ]; then
echo " ✅ Failover ناجح في $((i*5)) ثانية!"
break
fi
done
# الخطوة 4: التحقق من الوصول
echo "4. اختبار الوصول إلى الـ secondary..."
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" https://$DOMAIN/health)
if [ "$HTTP_CODE" == "200" ]; then
echo " ✅ الموقع متاح عبر SECONDARY"
else
echo " ❌ الموقع غير متاح: HTTP $HTTP_CODE"
fi
echo "=== انتهى الاختبار ==="
الجزء 5: المراقبة والتنبيهات
تكوين CloudWatch Alarm
# تنبيه عندما يصبح الـ health check غير صحي
aws cloudwatch put-metric-alarm \
--alarm-name globalbank-primary-unhealthy \
--metric-name HealthCheckStatus \
--namespace AWS/Route53 \
--statistic Minimum \
--period 60 \
--threshold 1 \
--comparison-operator LessThanThreshold \
--dimensions Name=HealthCheckId,Value=xxx-primary-health-check \
--evaluation-periods 1 \
--alarm-actions arn:aws:sns:us-east-1:123456789:ops-alerts \
--alarm-description "GlobalBank primary site is unhealthy"
لوحة القيادة الموصى بها
| المقياس | المصدر | حد التنبيه |
|---|---|---|
| HealthCheckStatus | Route53 | < 1 |
| HealthCheckPercentageHealthy | Route53 | < 100% |
| RequestCount (primary) | ALB | معلومات |
| RequestCount (secondary) | ALB | > 0 (failover نشط!) |
| Latency | ALB | > 1 ثانية |
الجزء 6: تحليل الأثر
تمرين: حساب تأثير TTL
إذا كان TTL هو 60 ثانية وحدث failover، كم من الوقت يمكن للمستخدمين أن يظلوا موجهين إلى الـ primary المعطل؟
💡 الحل
أقصى تأثير TTL = TTL للسجل
= 60 ثانية
السيناريو:
1. T=0s : المستخدم يقوم بطلب DNS، يحصل على IP primary
2. T=0s : التخزين المؤقت المحلي يخزن لـ 60 ثانية
3. T=30s : الـ primary يتعطل، Route 53 يتحول إلى secondary
4. T=30s : طلب DNS جديد → يحصل على IP secondary ✅
5. T=30s : المستخدم مع التخزين المؤقت → يذهب دائمًا إلى primary ❌
6. T=60s : التخزين المؤقت ينتهي، طلب جديد → secondary ✅
الاستنتاج:
- TTL قصير (60 ثانية) = failover سريع ولكن المزيد من طلبات DNS
- TTL طويل (300 ثانية) = طلبات أقل ولكن failover بطيء
- للـ DR الحرج: يوصى بـ TTL 30-60 ثانية
التسليم النهائي
الوثيقة المطلوب إنتاجها
- هندسة Failover (مخطط)
- التكوين الكامل (Health Check + Records)
- خطة الاختبار مع النتائج
- الحسابات (وقت الكشف، تأثير TTL)
- المراقبة (التنبيهات المكونة)
معايير التقييم
| المعيار | النقاط |
|---|---|
| الهندسة الصحيحة | /20 |
| تكوين Health Check بشكل جيد | /20 |
| سجلات Failover صحيحة | /20 |
| خطة اختبار كاملة | /20 |
| المراقبة والتنبيهات | /10 |
| جودة الوثيقة | /10 |
| المجموع | /100 |
الأسبوع القادم: MODULE 11 - Lambda