مختبر: إدارة تخزين EBS
هدف المختبر
في هذا المختبر، ستتعلم كيفية إدارة تخزين EBS: إنشاء وحدات التخزين، إرفاقها بالحالات، اللقطات، وأفضل ممارسات الإدارة. إنه تمرين في التحليل والتوثيق.
Approche Pédagogique
يجمع هذا المختبر بين النظرية وتحليل السيناريوهات. ستقوم بتوثيق إجاباتك وتبريراتك.
الجزء 1: المفاهيم الأساسية
تذكير بأنواع وحدات التخزين EBS
┌─────────────────────────────────────────────────────────────┐
│ TYPES DE VOLUMES EBS │
├─────────────────────────────────────────────────────────────┤
│ │
│ TYPE │ USAGE │ IOPS │ COÛT │
│ ─────────────┼───────────────────┼───────────┼────────────│
│ gp3 │ Usage général │ 3,000-16K │ $0.08/GB │
│ gp2 │ Usage général │ 3,000 max │ $0.10/GB │
│ io2 │ I/O intensif │ 64,000 │ $0.125/GB │
│ st1 │ Big data, logs │ 500 │ $0.045/GB │
│ sc1 │ Archives froides │ 250 │ $0.025/GB │
│ │
│ Recommandation pour débutants : │
│ • gp3 pour tout usage général │
│ • st1 pour logs/données séquentielles │
│ │
└─────────────────────────────────────────────────────────────┘
تمرين 1.1: اختيار نوع وحدة التخزين
لكل سيناريو، اختر نوع وحدة التخزين EBS المناسب وقدم تبريرًا:
| السيناريو | اختيارك | التبرير |
|---|---|---|
| قاعدة بيانات MySQL الإنتاجية | ? | ? |
| سجلات التطبيق (100GB) | ? | ? |
| خادم ويب ثابت | ? | ? |
| تطبيق تداول عالي التردد | ? | ? |
| أرشيفات الوثائق (نادراً ما يتم الوصول إليها) | ? | ? |
💡 الحلول
| السيناريو | الاختيار | التبرير |
|---|---|---|
| قاعدة بيانات MySQL الإنتاجية | io2 | IOPS عالية ومتسقة ضرورية |
| سجلات التطبيق (100GB) | st1 | وصول تسلسلي، تكلفة محسنة |
| خادم ويب ثابت | gp3 | توازن جيد بين التكلفة والأداء |
| تطبيق التداول | io2 | زمن استجابة منخفض حرج |
| أرشيفات الوثائق | sc1 | وصول نادر، تكلفة منخفضة |
الجزء 2: دورة حياة وحدة تخزين EBS
مخطط دورة الحياة
┌─────────────────────────────────────────────────────────────┐
│ CYCLE DE VIE D'UN VOLUME EBS │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ │
│ │ Créer │ │
│ │ Volume │ │
│ └──────┬──────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ État: │ │ Attacher │ │
│ │ available │───────►│ à EC2 │ │
│ └─────────────┘ └──────┬──────┘ │
│ ▲ │ │
│ │ ▼ │
│ ┌──────┴──────┐ ┌─────────────┐ │
│ │ Détacher │◄───────│ État: │ │
│ │ de EC2 │ │ in-use │ │
│ └─────────────┘ └──────┬──────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ Snapshot │ │
│ │ (backup) │ │
│ └─────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ Supprimer │ │
│ │ Volume │ │
│ └─────────────┘ │
│ │
│ ⚠️ Attention : Supprimer un volume efface toutes les │
│ données ! Toujours faire un snapshot avant. │
│ │
└─────────────────────────────────────────────────────────────┘
تمرين 2.1: أوامر CLI
قم بربط كل إجراء بالأمر CLI الصحيح:
| الإجراء | الأمر |
|---|---|
| إنشاء وحدة تخزين بحجم 100GB | ? |
| عرض جميع وحدات التخزين | ? |
| إرفاق وحدة تخزين بحالة | ? |
| إنشاء لقطة | ? |
| فصل وحدة تخزين | ? |
💡 الحلول
# Créer un volume de 100GB
aws ec2 create-volume \
--size 100 \
--volume-type gp3 \
--availability-zone us-east-1a
# Lister tous les volumes
aws ec2 describe-volumes
# Attacher un volume à une instance
aws ec2 attach-volume \
--volume-id vol-xxx \
--instance-id i-xxx \
--device /dev/sdf
# Créer un snapshot
aws ec2 create-snapshot \
--volume-id vol-xxx \
--description "Backup before maintenance"
# Détacher un volume
aws ec2 detach-volume --volume-id vol-xxx
الجزء 3: سيناريوهات عملية
السيناريو أ: زيادة السعة
السياق: وحدة التخزين الجذرية لخادم قاعدة البيانات الخاص بك (20GB) ممتلئة تقريبًا (95%). يجب عليك زيادة السعة إلى 50GB دون توقف.
الأسئلة:
- ما هي الطريقة التي ستستخدمها؟
- ما هي الخطوات؟
- هل هناك خطر فقدان البيانات؟
💡 حل السيناريو أ
الطريقة: تعديل وحدة التخزين (EBS Elastic Volumes)
تسمح AWS بتعديل حجم وحدة تخزين EBS أثناء التشغيل (دون إيقاف الحالة)!
الخطوات:
- إنشاء لقطة (كإجراء احترازي)
aws ec2 create-snapshot --volume-id vol-xxx --description "Before resize"
- تعديل حجم وحدة التخزين
aws ec2 modify-volume --volume-id vol-xxx --size 50
- مراقبة التعديل
aws ec2 describe-volumes-modifications --volume-id vol-xxx
# Attendre que l'état soit "completed"
- توسيع نظام الملفات (على الحالة)
# Pour ext4
sudo resize2fs /dev/xvda1
# Pour XFS
sudo xfs_growfs /
المخاطر:
- الحد الأدنى إذا تم عمل لقطة قبل
- تبقى وحدة التخزين متاحة أثناء التعديل
- توسيع نظام الملفات فوري
السيناريو ب: ترحيل البيانات
السياق: يجب عليك ترحيل قاعدة بيانات MySQL من حالة EC2 (us-east-1a) إلى حالة أخرى في منطقة توافر مختلفة (us-east-1b).
الأسئلة:
- هل يمكنك ببساطة فصل وإعادة إرفاق وحدة التخزين؟
- ما هي الإجراءات الصحيحة؟
- كيف تقلل من التوقف؟
💡 حل السيناريو ب
الإجابة 1: لا! لا يمكن إرفاق وحدة تخزين EBS إلا بحالات في نفس منطقة التوافر.
الإجراءات الصحيحة:
- إيقاف MySQL بشكل صحيح (لتقليل البيانات الجارية)
sudo systemctl stop mysql
- إنشاء لقطة لوحدة التخزين
aws ec2 create-snapshot --volume-id vol-xxx --description "Migration"
- إنشاء وحدة تخزين جديدة من اللقطة في منطقة التوافر الجديدة
aws ec2 create-volume \
--snapshot-id snap-xxx \
--availability-zone us-east-1b \
--volume-type gp3
- إرفاق وحدة التخزين الجديدة بالحالة الجديدة
aws ec2 attach-volume \
--volume-id vol-new \
--instance-id i-new \
--device /dev/sdf
- تركيب وبدء MySQL
sudo mount /dev/sdf /var/lib/mysql
sudo systemctl start mysql
تقليل التوقف:
- إعداد الحالة الجديدة مسبقًا
- استخدام تكرار MySQL قبل الترحيل
- إجراء الترحيل خلال نافذة الصيانة
السيناريو ج: الاسترداد بعد الحادث
السياق: قام مطور بحذف ملفات مهمة عن طريق الخطأ على وحدة تخزين. وحدة التخزين بحجم 200GB وآخر نسخة احتياطية كانت بالأمس.
الأسئلة:
- كيف تستعيد الملفات؟
- ما هي الإجراءات إذا كانت اللقطة موجودة؟
- كيف تتجنب هذه المشكلة في المستقبل؟
💡 حل السيناريو ج
الاسترداد عبر اللقطة:
- تحديد اللقطة الأحدث
aws ec2 describe-snapshots \
--filters "Name=volume-id,Values=vol-xxx" \
--query 'Snapshots[*].[SnapshotId,StartTime]' \
--output table
- إنشاء وحدة تخزين جديدة من اللقطة
aws ec2 create-volume \
--snapshot-id snap-xxx \
--availability-zone us-east-1a \
--volume-type gp3
- إرفاق وحدة التخزين للاسترداد
aws ec2 attach-volume \
--volume-id vol-recovery \
--instance-id i-xxx \
--device /dev/sdg
- تركيب ونسخ الملفات المفقودة
sudo mkdir /mnt/recovery
sudo mount /dev/sdg /mnt/recovery
cp /mnt/recovery/path/to/files /path/to/restore/
- التنظيف بعد الاسترداد
sudo umount /mnt/recovery
aws ec2 detach-volume --volume-id vol-recovery
aws ec2 delete-volume --volume-id vol-recovery
الوقاية:
- لقطات تلقائية مع Amazon Data Lifecycle Manager
- نسخ احتياطية منتظمة (ساعية للبيانات الحرجة)
- أذونات مقيدة (IAM) لتجنب الحذف العرضي
- إصدار لـ S3 إذا كان ذلك ممكنًا
الجزء 4: أفضل الممارسات
قائمة مراجعة إدارة EBS
┌─────────────────────────────────────────────────────────────┐
│ CHECKLIST BONNES PRATIQUES EBS │
├─────────────────────────────────────────────────────────────┤
│ │
│ SNAPSHOTS ET BACKUPS │
│ ☐ Snapshots automatiques configurés (DLM) │
│ ☐ Rétention définie (7 jours min pour prod) │
│ ☐ Snapshots testés (restauration validée) │
│ ☐ Snapshots cross-region pour DR │
│ │
│ PERFORMANCE │
│ ☐ Type de volume adapté à l'usage │
│ ☐ IOPS provisionnées si nécessaire (io2) │
│ ☐ Monitoring CloudWatch activé │
│ ☐ Alertes sur utilisation > 80% │
│ │
│ SÉCURITÉ │
│ ☐ Encryption activée (AES-256) │
│ ☐ Clés KMS gérées correctement │
│ ☐ Permissions IAM restrictives │
│ │
│ COÛTS │
│ ☐ Volumes non utilisés supprimés │
│ ☐ Snapshots anciens nettoyés │
│ ☐ Type gp3 préféré à gp2 (meilleur rapport coût) │
│ │
│ TAGS │
│ ☐ Nom descriptif │
│ ☐ Environnement (prod/dev/test) │
│ ☐ Application associée │
│ ☐ Propriétaire/équipe │
│ │
└─────────────────────────────────────────────────────────────┘
Data Lifecycle Manager (DLM)
┌─────────────────────────────────────────────────────────────┐
│ AMAZON DATA LIFECYCLE MANAGER │
├─────────────────────────────────────────────────────────────┤
│ │
│ Automatise les snapshots EBS │
│ │
│ Exemple de politique : │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ Nom : daily-backup-policy │ │
│ │ │ │
│ │ Cible : Volumes avec tag "Backup=true" │ │
│ │ │ │
│ │ Schedule : │ │
│ │ • Fréquence : Tous les jours à 03:00 UTC │ │
│ │ • Rétention : 7 snapshots (1 semaine) │ │
│ │ │ │
│ │ Options : │ │
│ │ • Copie cross-region : us-west-2 │ │
│ │ • Tags copiés : Oui │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Configuration CLI : │
│ aws dlm create-lifecycle-policy \ │
│ --description "Daily EBS backup" \ │
│ --state ENABLED \ │
│ --execution-role-arn arn:aws:iam::xxx:role/dlm-role \ │
│ --policy-details file://policy.json │
│ │
└─────────────────────────────────────────────────────────────┘
الجزء 5: التسليم
الوثيقة المطلوبة
قم بإنشاء وثيقة "خطة إدارة EBS" لتطبيق خيالي مع:
-
جرد وحدات التخزين (جدول)
- الاسم، الحجم، النوع، منطقة التوافر، الحالة المرفقة
-
سياسة اللقطات
- التردد حسب البيئة
- الاحتفاظ
- اختبارات الاستعادة
-
إجراءات موثقة
- زيادة السعة
- الترحيل بين مناطق التوافر
- الاسترداد بعد الحادث
-
تقدير التكاليف الشهرية
- وحدات التخزين
- اللقطات
- IOPS المخصصة (إذا كانت قابلة للتطبيق)
معايير التقييم
| المعيار | النقاط |
|---|---|
| تم إكمال التمارين 1-3 بشكل صحيح | /40 |
| جرد وحدات التخزين | /15 |
| سياسة اللقطات واضحة | /15 |
| الإجراءات موثقة جيدًا | /20 |
| تقدير التكاليف | /10 |
| المجموع | /100 |
ملخص
| المفهوم | النقاط الرئيسية |
|---|---|
| أنواع وحدات التخزين | gp3 افتراضيًا، io2 لـ IOPS |
| اللقطات | تزايدية، مخزنة على S3 |
| قيد منطقة التوافر | وحدة التخزين = منطقة توافر واحدة فقط |
| الترحيل | عبر لقطة + وحدة تخزين جديدة |
| DLM | أتمتة النسخ الاحتياطية |
العودة: نظرة عامة على الوحدة 4