أساسيات السحابة: خدمات AWS الأساسية

التخزين EBS وتخزين النسخة

18 دقيقة الدرس 4 من 30

التخزين EBS وتخزين النسخة

التخزين هو المكان الذي تبدأ فيه معظم الحوادث الإنتاجية المتعلقة بـ EC2. اختيار نوع وحدة التخزين الخاطئ يكلفك إما المال أو الأداء؛ وإهمال التشفير يكلفك الامتثال؛ وإهمال اللقطات (snapshots) يكلفك بياناتك. يغطي هذا الدرس كل أبعاد تخزين الكتل (block storage) على AWS التي يتحمل مهندس الإنتاج مسؤوليتها، وأنماط الفشل التي تميز الفرق ذات الخبرة عن غيرها.

أنواع وحدات تخزين EBS

يوفر Elastic Block Store (EBS) أجهزة كتلية دائمة مرتبطة بالشبكة. كل وحدة تخزين تعيش في منطقة توافر (Availability Zone) واحدة وتُنسخ تلقائيًا داخل تلك المنطقة. تقدم AWS أربع عائلات من وحدات التخزين:

gp3 (SSD متعدد الأغراض) — الخيار الافتراضي لمعظم الاستخدامات. أداء أساسي يبلغ 3,000 IOPS و125 ميغابايت/ثانية من معدل النقل، قابلان للتهيئة بشكل مستقل حتى 16,000 IOPS و1,000 ميغابايت/ثانية. محسَّن من حيث التكلفة: معدل النقل مستقل عن الحجم (خلافًا لـ gp2). استخدمه لوحدات نظام التشغيل وخوادم التطبيقات وقواعد البيانات ذات الحمل المعتدل وعُمَّال CI/CD.
gp2 (SSD متعدد الأغراض — إصدار قديم) — ذروة IOPS تصل إلى 3,000 مرتبطة بدلو ائتمان؛ الأداء الأساسي يرتفع بالحجم (3 IOPS/GB). ترحيل وحدات gp2 الموجودة إلى gp3 هو إجراء قياسي لتخفيض التكاليف على نطاق واسع: تحصل على أداء مماثل أو أفضل بما يقارب 20% أقل تكلفة.
io2 Block Express (SSD بـ IOPS مُخصَّصة) — حتى 256,000 IOPS و4,000 ميغابايت/ثانية لكل وحدة. زمن استجابة دون الميلي ثانية. مطلوب لـ Oracle وSQL Server وPostgreSQL عالي الإنتاجية على نطاق واسع. يمكن توصيل وحدة io2 واحدة بتقنية Multi-Attach بما يصل إلى 16 نسخة Nitro في آنٍ واحد — أمر بالغ الأهمية للتخزين المُدرَك على مستوى العناقيد في قواعد البيانات عالية التوافر.
st1 (HDD محسَّن للإنتاجية) — لأحمال العمل التسلسلية: شرائح سجلات Kafka، وابتلاع بيانات data lake، وHadoop. معدل نقل يصل إلى 500 ميغابايت/ثانية بجزء بسيط من تكلفة SSD. سقف IOPS منخفض والوصول العشوائي بطيء. لا تستخدمه أبدًا لوحدات نظام التشغيل.
sc1 (HDD بارد) — للأرشفة. أقل تكلفة لكل غيغابايت على EBS. معدل نقل أقصاه 250 ميغابايت/ثانية. استخدمه للبيانات التي نادرًا ما يُصل إليها والتي يجب أن تبقى على مستوى الكتلة (الاحتفاظ بها لأغراض الامتثال، والنسخ الاحتياطية الباردة).

عائلات وحدات تخزين EBS وحالات استخدامها في الإنتاج.

تخزين النسخة: NVMe المؤقت

وحدات تخزين النسخة (Instance Store) هي أقراص NVMe SSD مرتبطة فعليًا بمضيف hypervisor. تقدم أعلى إنتاجية خام على EC2 — بعض أنواع النسخ مثل i4i.metal تعرض 60 تيرابايت من NVMe بملايين IOPS وزمن استجابة أقل من 100 ميكروثانية. التكلفة: تُفقد جميع البيانات عند إيقاف النسخة أو إنهائها. لا يُحفظ الجهاز أبدًا عبر عمليات نقل المضيف.

الاستخدامات الإنتاجية المشروعة: شرائح سجلات وسيط Kafka (مع النسخ على مستوى التطبيق)، وجداول SSTable في Cassandra (مع النسخ عبر العقد)، والبيانات الدافئة لـ ElasticSearch، ومخازن الفرز الموزعة في Spark. النمط دائمًا هو نفسه: طبقة التطبيق تتولى الديمومة؛ وتخزين النسخة يتولى السرعة.

لا تضع أبدًا وحدة قاعدة بيانات رئيسية، أو طابور رسائل يُعدّ مصدر السجل الحقيقي، أو أي بيانات بدون نسخة خارجية في تخزين النسخة. الفرق التي تتجاهل هذه القاعدة تكتشف القيد الساعة الثالثة صباحًا خلال حدث صيانة مضيف AWS.

اللقطات (Snapshots)

لقطات EBS هي نسخ احتياطية تزايدية في لحظة محددة مخزنة في S3 (تديرها AWS — وليس في حاوية S3 الخاصة بك). تنسخ اللقطة الأولى الوحدة بأكملها؛ أما اللقطات اللاحقة فتنسخ الكتل المتغيرة فقط. الحذف آمن: تتتبع AWS مراجع الكتل عبر السلسلة ولا تزيل أبدًا كتلة لا تزال مُشار إليها بلقطة أخرى.

# إنشاء لقطة بوسم وصفي
aws ec2 create-snapshot \
  --volume-id vol-0abc123def456 \
  --description "pre-deploy-$(date +%Y%m%d-%H%M)" \
  --tag-specifications 'ResourceType=snapshot,Tags=[{Key=Env,Value=prod},{Key=Service,Value=api-db}]'

# عرض اللقطات المملوكة للحساب
aws ec2 describe-snapshots --owner-ids self \
  --filters "Name=tag:Service,Values=api-db" \
  --query 'Snapshots[*].[SnapshotId,StartTime,State,VolumeSize]' \
  --output table

# الاستعادة: إنشاء وحدة من لقطة في منطقة توافر محددة
aws ec2 create-volume \
  --snapshot-id snap-0xyz789 \
  --availability-zone us-east-1a \
  --volume-type gp3 \
  --iops 6000 \
  --throughput 500 \
  --encrypted \
  --tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=restored-api-db}]'

للأتمتة، استخدم Data Lifecycle Manager (DLM). عرِّف سياسة تستهدف الوحدات بالوسوم، وتنشئ لقطات يومية، وتحتفظ بآخر 14 لقطة، وتنسخها إلى منطقة ثانوية للتعافي من الكوارث. هذا يحل محل مهام cron اليدوية وهو المعيار الإنتاجي.

قبل كل بناء AMI أو نشر رئيسي، التقط لقطة لوحدة الجذر. تستغرق اللقطة ثوانٍ للبدء (حتى على وحدات متعددة التيرابايت) وهي أسرع مسار للتراجع المتاح — أسرع من أي خط أنابيب للنشر مجددًا.

التشفير

يستخدم تشفير EBS معيار AES-256 مع مفاتيح AWS KMS. عند تمكينه، تكون جميع البيانات في حالة الراحة على الوحدة، وجميع البيانات أثناء النقل بين الوحدة والنسخة، وجميع اللقطات المستمدة من الوحدة مشفرة. التشفير شفاف لنظام التشغيل — لا تغييرات تطبيقية مطلوبة.

# تمكين التشفير الافتراضي على مستوى الحساب (افعل هذا في كل حساب/منطقة جديدة)
aws ec2 enable-ebs-encryption-by-default --region us-east-1

# التحقق من الإعداد
aws ec2 get-ebs-encryption-by-default --region us-east-1

# تشفير وحدة غير مشفرة موجودة:
# 1. التقط لقطة للوحدة
# 2. انسخ اللقطة مع تمكين التشفير
aws ec2 copy-snapshot \
  --source-region us-east-1 \
  --source-snapshot-id snap-0abc123 \
  --description "encrypted copy" \
  --encrypted \
  --kms-key-id alias/aws/ebs

# 3. أنشئ وحدة جديدة من اللقطة المشفرة، وصِّلها، وبدِّل القديمة

استخدم مفتاح مُدار من قِبَل العميل (CMK) في KMS بدلًا من المفتاح المُدار بواسطة AWS (alias/aws/ebs) في أي بيئة تحتاج فيها إلى: التحكم في دوران المفاتيح، ومشاركة اللقطات عبر الحسابات، والتحكم الدقيق عبر IAM في استخدام المفاتيح، أو مسارات التدقيق في CloudTrail لكل مفتاح. يكلف CMK دولارًا واحدًا شهريًا بالإضافة إلى تكاليف استدعاء API — تافهة مقارنة بقيمة الامتثال.

تمكين التشفير الافتراضي يؤثر فقط على الوحدات الجديدة. الوحدات غير المشفرة الموجودة تبقى كذلك. دقِّق حسابك بانتظام باستخدام قاعدة AWS Config المسماة encrypted-volumes. في البيئات المنظَّمة (PCI-DSS، HIPAA)، وحدة EBS غير مشفرة تُعدّ نقطة ضعف في التدقيق.

ضبط الأداء

لإنتاجية EBS سقفان: سقف الوحدة وسقف عرض النطاق الترددي المحسَّن لـ EBS للنسخة. وحدة gp3 بـ 16,000 IOPS لا قيمة لها إذا كان سقف عرض النطاق الترددي لـ EBS لنسخة t3.medium هو 2,085 ميغابت/ثانية. طابق دائمًا تهيئة الوحدة مع عرض النطاق الترددي الأساسي لـ EBS للنسخة.

# فحص حدود عرض النطاق الترددي لـ EBS للنسخة
aws ec2 describe-instance-types \
  --instance-types r6i.2xlarge \
  --query 'InstanceTypes[*].EbsInfo' \
  --output json

# قياس أداء IOPS للوحدة بـ fio (شغِّله على النسخة)
sudo fio \
  --filename=/dev/nvme1n1 \
  --direct=1 \
  --rw=randread \
  --bs=4k \
  --numjobs=32 \
  --iodepth=256 \
  --runtime=60 \
  --time_based \
  --group_reporting \
  --name=4k-rand-read

# مراقبة مقاييس EBS في CloudWatch
aws cloudwatch get-metric-statistics \
  --namespace AWS/EBS \
  --metric-name VolumeReadOps \
  --dimensions Name=VolumeId,Value=vol-0abc123def456 \
  --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 300 \
  --statistics Average

مقاييس CloudWatch الرئيسية لإعداد التنبيهات: VolumeQueueLength (إذا تجاوز 1 لكل IOPS مُخصَّصة بصورة مستدامة فهذا يشير إلى تشبع)، وBurstBalance على gp2 (أقل من 20% يعني أنك بحاجة إلى الترحيل إلى gp3 أو التوسعة)، وVolumeIdleTime لتحديد الوحدات المُضخَّمة بالموارد التي يمكن تصغيرها.

لقواعد البيانات، اضبط دائمًا جدول I/O في Linux على none وزد قيمة القراءة المسبقة (read-ahead) لأحمال العمل التسلسلية. التحسين لـ EBS مُفعَّل افتراضيًا في جميع نسخ الجيل الحالي، لكن تحقق من ذلك عند العمل مع أنواع نسخ أقدم في عمليات الترحيل.

أعلى إجراء بمفرده لمعظم الفرق: شغِّل aws ec2 enable-ebs-encryption-by-default في كل منطقة لكل حساب، وسياسة DLM تلتقط لقطات يومية للوحدات المُوسَمة مع احتجاز 14 يومًا. هذان الإجراءان، عند تطبيقهما عند إنشاء الحساب، يمنعان أكثر الحوادث والنتائج التدقيقية المتعلقة بالتخزين شيوعًا.