EBS مقابل EFS لمشاركة المجلدات بين عدة EC2 Instances

عندما تحتاج إلى مشاركة مجلد واحد بين خمسة EC2 instances تعمل في نفس الوقت، فإن الخطأ الأكثر شيوعاً هو محاولة تركيب EBS volume على أكثر من instance واحد — وهو سيناريو يبدو منطقياً للوهلة الأولى لكنه يؤدي إلى تلف البيانات في معظم الحالات. الفهم الصحيح للفرق بين EBS وEFS يوفر عليك ساعات من استكشاف الأخطاء وربما خسارة بيانات حقيقية في بيئة الإنتاج.

TL;DR — EBS مقابل EFS لمشاركة الملفات

المعيار	EBS	EFS
المشاركة بين instances متعددة	محدودة جداً (Multi-Attach لـ io1/io2 فقط)	نعم، بشكل أصلي
بروتوكول الوصول	Block storage (مثل قرص محلي)	NFS v4.1/4.0
نظام الملفات المشترك	يتطلب cluster-aware filesystem	مدمج ومُدار بالكامل
الأداء	أعلى (latency أقل)	مناسب لمعظم حالات الاستخدام
التسعير	يُدفع بحجم المساحة المحجوزة	يُدفع بحجم البيانات المخزنة فعلياً
التوافر عبر Availability Zones	محدود بـ AZ واحد (في الغالب)	Regional — عبر AZs متعددة

كيف يعمل EBS وEFS — الفرق الجوهري

EBS هو block storage — يتصرف بالضبط كقرص صلب مرتبط بـ instance واحد. عندما تُركّب EBS volume على instance، يصبح الـ instance هو المتحكم الكامل في نظام الملفات. تخيل الأمر كقرص USB مُوصَّل بجهاز كمبيوتر واحد فقط في وقت واحد.

EFS يشبه خادم NAS في شبكتك المحلية — أي جهاز في الشبكة يمكنه الوصول إليه في نفس الوقت دون أن يحتاج أحدهم إلى 'امتلاكه'.

EFS هو managed NFS service — يُقدّم نظام ملفات مشتركاً عبر بروتوكول NFS يمكن لعشرات أو آلاف الـ instances الوصول إليه في آن واحد. AWS تتولى إدارة التزامن والتوافر والتوسع التلقائي.

graph LR subgraph EBS_Model ["EBS — Instance واحد فقط"] EBS_Vol["EBS Volume"] Inst1["EC2 Instance 1"] Inst2["EC2 Instance 2 ❌"] Inst3["EC2 Instance 3 ❌"] EBS_Vol --> Inst1 EBS_Vol -.->|"غير مدعوم"| Inst2 EBS_Vol -.->|"غير مدعوم"| Inst3 end subgraph EFS_Model ["EFS — مشاركة حقيقية"] EFS_FS["EFS Filesystem"] MT["Mount Target"] A1["EC2 Instance A"] A2["EC2 Instance B"] A3["EC2 Instance C"] EFS_FS --> MT MT --> A1 MT --> A2 MT --> A3 end

EBS Volume: مرتبط بـ instance واحد فقط في الحالة الافتراضية — الـ instance الآخر لا يرى الـ volume أصلاً.
EFS Mount Target: نقطة وصول مشتركة داخل كل AZ — كل instance يتصل بها عبر NFS.
EFS Filesystem: يستقبل طلبات القراءة والكتابة من جميع الـ instances في نفس الوقت مع ضمان الاتساق.

لماذا EBS وحده لا يكفي لمشاركة المجلدات

يوجد استثناء واحد يجب ذكره بدقة: ميزة EBS Multi-Attach متاحة لأنواع io1 وio2 فقط، وتسمح بتركيب الـ volume على عدة instances داخل نفس AZ. لكن هذه الميزة تأتي مع قيد جوهري: AWS تشترط صراحةً استخدام cluster-aware filesystem مثل GFS2 أو OCFS2 — لأن نظام ملفات عادي مثل ext4 أو XFS لا يدعم الكتابة المتزامنة من أكثر من مصدر، مما يؤدي إلى تلف البيانات.

في الواقع العملي: معظم الفرق لا تمتلك خبرة تشغيل cluster filesystem، وإعداده بشكل صحيح أصعب بكثير من استخدام EFS مباشرة. إذا كان هدفك مشاركة مجلد بين خمسة instances بدون تعقيد إضافي، EFS هو الخيار الصحيح.

graph TD Q1["هل تحتاج مشاركة الملفات
بين instances متعددة؟"] Q2["هل تحتاج block-level access
مع cluster filesystem؟"] Q3["هل جميع الـ instances
في نفس AZ؟"] EFS_REC["✅ استخدم EFS
الخيار الموصى به"] MULTI["⚠️ EBS Multi-Attach
io1/io2 فقط + cluster FS"] EBS_STD["✅ EBS Standard
Instance واحد"] Q1 -->|نعم| Q2 Q1 -->|لا — instance واحد| EBS_STD Q2 -->|لا| EFS_REC Q2 -->|نعم| Q3 Q3 -->|نعم| MULTI Q3 -->|لا| EFS_REC

الحالة الافتراضية (Single-Attach): EBS volume مرتبط بـ instance واحد — محاولة الربط بـ instance ثانٍ ستفشل أو تتطلب فصله أولاً.
Multi-Attach: متاح فقط لـ io1/io2 في نفس AZ، ويتطلب cluster filesystem — ليس ext4 أو XFS.
EFS: المسار الموصى به لمشاركة الملفات بين instances متعددة بدون تعقيد إضافي.

إعداد EFS ومشاركة مجلد بين EC2 Instances

الخطوات التالية تغطي إنشاء EFS filesystem وتركيبه على عدة instances. تأكد أن جميع الـ instances في نفس VPC وأن Security Groups تسمح بحركة NFS (المنفذ 2049).

الخطوة 1: إنشاء EFS Filesystem

نبدأ بإنشاء الـ filesystem نفسه — هذا هو المورد المركزي الذي ستتشارك فيه جميع الـ instances.

aws efs create-file-system \
  --performance-mode generalPurpose \
  --throughput-mode bursting \
  --encrypted \
  --tags Key=Name,Value=shared-folder-fs \
  --region us-east-1

احتفظ بقيمة FileSystemId من الناتج — ستحتاجها في الخطوات التالية.

الخطوة 2: إنشاء Mount Targets في كل AZ

كل AZ تحتاج إلى Mount Target خاص بها حتى تتمكن الـ instances في تلك المنطقة من الوصول إلى EFS بكفاءة. بدون Mount Target في نفس AZ، الـ instance سيصل عبر AZ أخرى مما يزيد الـ latency ويضيف تكلفة نقل البيانات.

aws efs create-mount-target \
  --file-system-id fs-0123456789abcdef0 \
  --subnet-id subnet-0abc123456789def0 \
  --security-groups sg-0abc123456789def0 \
  --region us-east-1

كرر هذا الأمر لكل subnet/AZ تحتوي على instances تريد ربطها.

الخطوة 3: التحقق من حالة Mount Targets

لا تحاول التركيب قبل أن تصبح الـ Mount Targets في حالة available — التركيب على target في حالة creating سيفشل.

aws efs describe-mount-targets \
  --file-system-id fs-0123456789abcdef0 \
  --region us-east-1 \
  --query 'MountTargets[*].{AZ:AvailabilityZoneName,State:LifeCycleState,IP:IpAddress}'

الخطوة 4: إعداد Security Group لـ NFS

Security Group الخاص بـ Mount Target يجب أن يسمح بالحركة الواردة على المنفذ 2049 من Security Groups الخاصة بالـ instances. هذا الإعداد يُغفله كثيرون ويؤدي إلى فشل التركيب بدون رسالة خطأ واضحة في البداية.

aws ec2 authorize-security-group-ingress \
  --group-id sg-0abc123456789def0 \
  --protocol tcp \
  --port 2049 \
  --source-group sg-0instance123456789 \
  --region us-east-1

الخطوة 5: تركيب EFS على كل EC2 Instance

AWS توصي باستخدام EFS mount helper (amazon-efs-utils) بدلاً من الأمر mount المباشر — فهو يدعم TLS encryption وتحسينات الأداء تلقائياً.

🔽 أوامر التركيب على EC2 Instance (انقر للتوسيع)

# تثبيت EFS mount helper على Amazon Linux 2
sudo yum install -y amazon-efs-utils

# إنشاء نقطة التركيب
sudo mkdir -p /mnt/shared

# تركيب EFS باستخدام mount helper مع TLS
sudo mount -t efs -o tls fs-0123456789abcdef0:/ /mnt/shared

# التحقق من نجاح التركيب
df -h /mnt/shared

الخطوة 6: جعل التركيب دائماً عبر /etc/fstab

بدون إضافة الـ entry في /etc/fstab، سيختفي التركيب عند إعادة تشغيل الـ instance. الخيار _netdev ضروري لأنه يخبر نظام التشغيل بانتظار الشبكة قبل محاولة التركيب.

echo 'fs-0123456789abcdef0:/ /mnt/shared efs _netdev,tls 0 0' | sudo tee -a /etc/fstab

IAM Permissions المطلوبة

لتنفيذ الأوامر السابقة، يحتاج المستخدم أو الـ role إلى الصلاحيات التالية كحد أدنى:

🔽 IAM Policy لإدارة EFS (انقر للتوسيع)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EFSManagement",
      "Effect": "Allow",
      "Action": [
        "elasticfilesystem:CreateFileSystem",
        "elasticfilesystem:CreateMountTarget",
        "elasticfilesystem:DescribeFileSystems",
        "elasticfilesystem:DescribeMountTargets",
        "elasticfilesystem:DescribeMountTargetSecurityGroups"
      ],
      "Resource": "*"
    },
    {
      "Sid": "EC2NetworkForEFS",
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeSubnets",
        "ec2:DescribeSecurityGroups",
        "ec2:AuthorizeSecurityGroupIngress"
      ],
      "Resource": "*"
    }
  ]
}

لاحظ أن بعض عمليات EFS مثل DescribeFileSystems وDescribeMountTargets تتطلب "Resource": "*" لأنها لا تدعم تقييد ARN على مستوى الـ resource في جميع الحالات — تحقق دائماً من Service Authorization Reference للتفاصيل المحدّثة.

تجربة حقيقية: التشخيص الخاطئ الشائع

سيناريو يتكرر كثيراً: فريق يُركّب EBS volume على instance أول ويكتب بيانات، ثم يحاول تركيبه على instance ثانٍ بعد فصله من الأول. يلاحظون أن الملفات موجودة — فيظنون أن المشاركة تعمل. ثم يُشغّلون التطبيق على كلا الـ instances في نفس الوقت، كل instance يكتب على نسخته المحلية المؤقتة (من snapshot أو AMI)، والبيانات تتشعب بصمت.

التشخيص الخاطئ: 'المشكلة في الكود — الـ instances لا تتزامن.' السبب الحقيقي: لا يوجد تزامن أصلاً — كل instance يعمل على storage منفصل تماماً.

الإصلاح: الانتقال إلى EFS وتركيبه على جميع الـ instances في نفس الوقت. عند ذلك، الكتابة من أي instance تظهر فوراً لجميع الـ instances الأخرى.

نقطة غير واضحة من التوثيق: EFS يستخدم نموذج close-to-open consistency — الكتابة مضمونة للظهور للـ instances الأخرى بعد إغلاق الملف، وليس بالضرورة أثناء الكتابة المستمرة. إذا كان تطبيقك يعتمد على قراءة ملف بينما instance آخر يكتب فيه بشكل مستمر دون إغلاقه، فأنت بحاجة إلى آلية تزامن إضافية على مستوى التطبيق.

متى تستخدم EBS Multi-Attach بدلاً من EFS

EBS Multi-Attach له حالات استخدام مشروعة، لكنها محددة جداً. إذا كنت تبني نظاماً يتطلب block-level access مشتركاً مع أداء عالٍ جداً وتحكم كامل في نظام الملفات — مثل بعض قواعد البيانات المتخصصة أو أنظمة التخزين المخصصة — فقد يكون Multi-Attach مناسباً. لكن هذا يتطلب:

نوع volume io1 أو io2 حصراً
جميع الـ instances في نفس AZ
cluster-aware filesystem مُعدّ ومُختبر بشكل صحيح
فريق يمتلك خبرة تشغيل هذه الأنظمة في الإنتاج

لمشاركة مجلد بسيطة بين خمسة instances، هذا المستوى من التعقيد غير مبرر.

الخلاصة والخطوات التالية لـ EFS

الإجابة المختصرة: لمشاركة مجلد بين عدة EC2 instances، استخدم EFS. EBS في وضعه الافتراضي مصمم للارتباط بـ instance واحد، وحتى Multi-Attach يتطلب تعقيداً لا مبرر له في معظم حالات مشاركة الملفات.

راجع توثيق Amazon EFS الرسمي لفهم خيارات الأداء والتشفير.
إذا كانت التطبيقات تحتاج إلى أداء عالٍ جداً، استكشف EFS Performance Modes وخيار Provisioned Throughput.
للبيئات التي تتطلب امتثالاً أمنياً، تأكد من تفعيل EFS encryption at rest وفي النقل عبر TLS.
تحقق من التسعير الحالي في صفحة تسعير EFS — التسعير والحدود تتغير، لا تعتمد على أرقام ثابتة.

مسرد المصطلحات

المصطلح	التعريف
EBS (Elastic Block Store)	خدمة block storage من AWS — تعمل كقرص صلب افتراضي مرتبط بـ EC2 instance.
EFS (Elastic File System)	خدمة NFS مُدارة من AWS تتيح مشاركة نظام ملفات بين instances متعددة.
Mount Target	نقطة وصول شبكية لـ EFS داخل Subnet محددة — تتيح للـ instances في نفس AZ الوصول إلى الـ filesystem.
Multi-Attach	ميزة EBS تسمح بتركيب volume واحد على عدة instances — متاحة لـ io1/io2 فقط وتتطلب cluster filesystem.
Close-to-Open Consistency	نموذج الاتساق في EFS — يضمن ظهور الكتابات للـ instances الأخرى بعد إغلاق الملف.

📄 الاختيار بين EBS gp2 و gp3: أيهما يتيح ضبط IOPS باستقلالية وأيهما أوفر؟

بحث هذه المدونة الإلكترونية

SW BBANG A