> ## Content Index > Fetch the complete content index at: https://arabroot.io/llms.txt > Use this file to discover other available public pages before exploring further. # Ceph أم GlusterFS؟ أي تخزين موزع تختار اليوم - URL: https://arabroot.io/articles/ceph-ام-glusterfs-اي-تخزين-موزع-تختار-اليوم/ - Published: 2026-10-13T04:15:00.000Z - Updated: 2026-10-12T21:17:58.000Z - Description: مقارنة عملية بين Ceph وGlusterFS في البنية والتعافي من الأعطال، ولماذا تحتاج سبباً قوياً لتبدأ اليوم على GlusterFS. - Author: فريق عرب رووت - Tags: الأدلة التقنية, هندسة البرمجيات وتصميم الأنظمة, التشغيل والنسخ الاحتياطي, الاستضافة الذاتية عندما تحتاج مساحة تخزين تتجاوز سيرفراً واحداً وتبقى متاحة إذا تعطل أحد السيرفرات، ستجد في أغلب الأدلة القديمة اسمين يتكرران: Ceph وGlusterFS. وقد شرحنا Ceph بالتفصيل وبتجربة حقيقية في [Ceph للمبتدئين](https://arabroot.io/articles/ceph-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-%D8%AA%D8%AE%D8%B2%D9%8A%D9%86-%D9%85%D9%88%D8%B2%D8%B9-%D9%8A%D8%AA%D8%AD%D9%85%D9%84-%D8%AA%D8%B9%D8%B7%D9%84-%D8%A7%D9%84%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D8%A7%D8%AA/)، أما GlusterFS فكان لسنوات الخيار الأسهل، فهو يجمع مجلدات عادية من عدة سيرفرات في نظام ملفات واحد، ويثبت في دقائق. لكن الذي تغير منذ 2024 كثير: Red Hat أنهت منتجها التجاري المبني عليه، وProxmox حذفت دعمه من الإصدار 9، والنشاط في المستودع قل إلى حد واضح. لذلك هذا المقال ليس مقارنة ميزات فقط، وإنما إجابة عن سؤال عملي: إذا بدأت مشروعاً اليوم، أيهما تختار، وإذا كان لديك GlusterFS يعمل، ماذا تفعل؟ [![](https://arabroot.io/content/images/2026/10/ceph-basics-cover-cover.webp)دليلCeph للمبتدئين: تخزين موزع يتحمل تعطل السيرفراتكيف يوزع Ceph البيانات على عدة سيرفرات ويعيد نسخها وحده عندما يتعطل قرص، ومتى يكون أكبر من حاجتك.](https://arabroot.io/articles/ceph-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-%D8%AA%D8%AE%D8%B2%D9%8A%D9%86-%D9%85%D9%88%D8%B2%D8%B9-%D9%8A%D8%AA%D8%AD%D9%85%D9%84-%D8%AA%D8%B9%D8%B7%D9%84-%D8%A7%D9%84%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D8%A7%D8%AA/)[![](https://arabroot.io/content/images/2026/10/s3-self-hosted-cover-cover.webp)دليلتخزين الكائنات S3 على سيرفرك: التثبيت والبنيةكيف تثبت ثلاث أدوات تخزين S3 مفتوحة المصدر في إعداد صغير يتحمل الأعطال، وماذا يحدث فعلاً عندما يتوقف سيرفر أو يتلف قرص.](https://arabroot.io/articles/%D8%AA%D8%AE%D8%B2%D9%8A%D9%86-%D8%A7%D9%84%D9%83%D8%A7%D8%A6%D9%86%D8%A7%D8%AA-s3-%D8%B9%D9%84%D9%89-%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D9%83-%D8%A7%D9%84%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-%D9%88%D8%A7%D9%84%D8%A8%D9%86%D9%8A%D8%A9/)[![](https://arabroot.io/content/images/2026/10/s3-servers-compare-cover-cover.webp)دليلأي تخزين S3 مستضاف ذاتياً يناسبك؟ وما الذي تغير في MinIOمقارنة عملية بين أشهر أدوات تخزين S3 المستضافة ذاتياً بقياسات على جهاز واحد، لتعرف أيها يناسب سيرفرك وماذا حدث فعلاً ل MinIO.](https://arabroot.io/articles/%D8%A7%D9%8A-%D8%AA%D8%AE%D8%B2%D9%8A%D9%86-s3-%D9%85%D8%B3%D8%AA%D8%B6%D8%A7%D9%81-%D8%B0%D8%A7%D8%AA%D9%8A%D8%A7-%D9%8A%D9%86%D8%A7%D8%B3%D8%A8%D9%83/)[![](https://arabroot.io/content/images/2026/10/zfs-basics-cover-cover.webp)دليلZFS للمبتدئين: كيف يحمي بياناتك من التلف الصامتكيف يكتشف ZFS التلف الصامت ويصلحه، وكيف ترتب الأقراص في Pool يتحمل العطل وتستعيد ملفاتك من Snapshots.](https://arabroot.io/articles/zfs-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-%D9%83%D9%8A%D9%81-%D9%8A%D8%AD%D9%85%D9%8A-%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA%D9%83-%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D9%84%D9%81-%D8%A7%D9%84%D8%B5%D8%A7%D9%85%D8%AA/) وسوف نناقش في هذا المقال ما يلي: - حالة GlusterFS اليوم بالتواريخ: نهاية منتج Red Hat، وقرار Proxmox، وآخر إصدار، وعدد ال Commits في كل سنة. - الفرق في البنية: من يقرر مكان الملف، ومن يكتب النسخ، وأين تحفظ البيانات على القرص. - ماذا يحدث عند العطل في كل منهما، بتجربة حقيقية على GlusterFS 11.1 نقارنها بتجربة Ceph. - الملفات الصغيرة والنصاب Quorum، بالأرقام من التجربة. - البدائل: SeaweedFS وMinIO وLonghorn وDRBD وZFS، ومتى يناسب كل منها. - جدول قرار يجيب عن سؤال «ماذا أستخدم لحالتي؟». ## ماذا حدث لـ GlusterFS؟ قبل أي مقارنة تقنية يجب أن تعرف من يصون الكود الذي سوف تضع عليه بياناتك، لأن نظام التخزين يعيش معك سنوات، ولا تستطيع أن تغيره كما تغير مكتبة في مشروعك. وهذه هي الحقائق كما وجدناها في 12 أكتوبر 2026، كل منها من مصدرها الأصلي: - Red Hat: صفحة [دورة حياة Red Hat Gluster Storage](https://access.redhat.com/support/policy/updates/rhs?ref=arabroot.io) تقول إن المنتج له دورة دعم محددة حتى 31 ديسمبر 2024، وبعدها يصل إلى نهاية الحياة EOL، وإن السلسلة 3.5 هي آخر سلسلة مدعومة. وRed Hat كانت الراعي الأكبر لتطوير GlusterFS، فخروج منتجها يعني أن أكبر ممول للمشروع لم يعد يحتاجه. - Proxmox: في [ملاحظات إصدار Proxmox VE 9.0](https://pve.proxmox.com/wiki/Roadmap?ref=arabroot.io) الذي صدر في 5 أغسطس 2025 تجد العبارة «As GlusterFS is no longer maintained upstream, Proxmox VE 9 drops support for GlusterFS storages»، أي أن Proxmox حذفت نوع التخزين GlusterFS لأنها تعتبره غير مصان، ومن لديه تخزين GlusterFS عليه أن ينقله، أو أن يربطه يدوياً ويستخدمه كمجلد Directory. - الإصدارات: آخر إصدار في [مستودع GlusterFS](https://github.com/gluster/glusterfs?ref=arabroot.io) هو [v11.2](https://github.com/gluster/glusterfs/releases/tag/v11.2?ref=arabroot.io) بتاريخ 2 يوليو 2025، والمستودع غير مؤرشف، وآخر Commit فيه بتاريخ 23 سبتمبر 2026. - النشاط: عددنا ال Commits في الفرع الرئيسي من واجهة GitHub، فكانت 78 Commit من 18 مطوراً في 2023، ثم 31 من 17 في 2024، ثم 30 من 10 في 2025، ثم 35 من 3 مطورين فقط من بداية 2026 حتى 12 أكتوبر. وللمقارنة فإن مستودع Ceph تجاوز 1000 Commit في 2026 في الفترة نفسها، وتوثيق Ceph يذكر سلسلتين نشطتين هما Tentacle 20.2 وSquid 19.2 في [صفحة الإصدارات](https://docs.ceph.com/en/latest/releases/?ref=arabroot.io). هل هذا يعني أن GlusterFS مات؟ لا، فالمستودع ما زال يستقبل إصلاحات، وما زالت التوزيعات تحمله، فـ Debian 13 مثلاً فيه الحزمة [glusterfs-server](https://packages.debian.org/trixie/glusterfs-server?ref=arabroot.io) بالإصدار 11.1 الذي استخدمناه في التجربة. لكن ثلاثة مطورين في سنة كاملة لنظام ملفات موزع يعني أن الثغرات والأعطال النادرة قد تنتظر طويلاً، ولذلك القاعدة التي نصل إليها في آخر المقال بسيطة: لا تبدأ مشروعاً جديداً على GlusterFS، وإذا كان لديك واحد يعمل فخطط للانتقال دون استعجال. ## الفرق في البنية: من يقرر مكان الملف ومن يكتب النسخ؟ النظامان يشتركان في فكرة مهمة: لا يوجد سيرفر بيانات وصفية مركزي يسأله الكلاينت عن مكان كل ملف، وكلاهما يحسب المكان بالهاش. لكن التفاصيل مختلفة تماماً، والصورة التالية تبينها: ![لوحتان: في GlusterFS كلاينت FUSE فيه طبقات Translators، الخطوة الأولى DHT يحسب هاش اسم الملف ليختار مجموعة النسخ، والثانية AFR يكتب الملف إلى كل Brick في المجموعة، والأسهم من الكلاينت إلى ثلاثة سيرفرات gl1 وgl2 وgl3، وتحتها أن ال Brick مجلد عادي على XFS والملف file-7 بحجم 4194304 بايت مع خصائص trusted.gfid. وفي Ceph كلاينت يأخذ الخريطة من MON، ويحسب الهاش ثم PG ثم CRUSH، ويكتب إلى primary OSD فقط، وهو ينسخ إلى osd.0 وosd.3، وتحتها أن ال OSD يستخدم BlueStore على قرص خام والكائنات بحجم 4 MiB](https://arabroot.io/content/images/2026/10/ceph-vs-glusterfs-01-architecture.webp) في GlusterFS الكلاينت يكتب كل نسخة، وفي Ceph يكتب نسخة واحدة وال Primary ينسخ في GlusterFS يعمل على كل سيرفر برنامج الإدارة glusterd، ويصدر كل مجلد مشارك واسمه Brick عبر برنامج glusterfsd، وال Brick بحسب [توثيق البنية](https://docs.gluster.org/en/latest/Quick-Start-Guide/Architecture/?ref=arabroot.io) مجلد على نظام ملفات عادي مثل XFS. والكلاينت يحمل سلسلة من الطبقات اسمها Translators، أهمها اثنتان: DHT (Distributed Hash Table) التي تحسب هاش اسم الملف وتختار له مجموعة Bricks واحدة، والتوثيق يصفها بأنها «دالة توجيه، وليست تقسيماً ولا نسخاً»، ثم AFR (Automatic File Replication) التي تكتب الملف إلى كل Brick في المجموعة. والنتيجة العملية أن ملفاتك موجودة كما هي على أقراص السيرفرات، تستطيع أن تفتحها بـ ls وتحسب لها md5sum، وهذا ما جعل كثيراً من الفرق تثق في GlusterFS: إذا تعطل كل شيء فالملفات ما زالت على القرص. أما Ceph فقد شرحناه في [قسم CRUSH](https://arabroot.io/articles/ceph-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-%D8%AA%D8%AE%D8%B2%D9%8A%D9%86-%D9%85%D9%88%D8%B2%D8%B9-%D9%8A%D8%AA%D8%AD%D9%85%D9%84-%D8%AA%D8%B9%D8%B7%D9%84-%D8%A7%D9%84%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D8%A7%D8%AA/#crush): الكلاينت يأخذ خريطة ال Cluster من ال Monitors، ويحسب مجموعة التوزيع Placement Group ثم ال OSDs، ويكتب نسخة واحدة إلى ال Primary الذي ينسخ إلى البقية، والبيانات تحفظ في BlueStore على القرص مباشرة ككائنات بحجم 4 MiB، فلا تستطيع أن تقرأ ملفاً من القرص دون Ceph. وفوق هذه الطبقة يقدم Ceph أقراص كتل RBD ونظام ملفات CephFS وبوابة S3، بينما GlusterFS نظام ملفات فقط. وقد يتساءل البعض: أليس أسهل أن تكون الملفات عادية على القرص؟ والإجابة أنه أسهل في القراءة عند الكارثة، لكنه يجعل الملف هو وحدة التوزيع، فالملف الكبير جداً يقع كله على مجموعة Bricks واحدة، وكل عملية على ملف تمر بنظام ملفات عادي في كل سيرفر، وكل عملية على المجلدات تحتاج سؤال كل ال Bricks، وهذا ما سوف نراه بالأرقام في قسم الملفات الصغيرة. ## تجربة عملية: GlusterFS بثلاثة سيرفرات الآن سوف نقوم ببناء Volume من نوع replica 3 على ثلاثة Containers، ثم نكتب فيه، ونوقف سيرفراً ونرى كيف يعالج GlusterFS ذلك، ثم نقارن بما رأيناه في [تجربة Ceph](https://arabroot.io/articles/ceph-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-%D8%AA%D8%AE%D8%B2%D9%8A%D9%86-%D9%85%D9%88%D8%B2%D8%B9-%D9%8A%D8%AA%D8%AD%D9%85%D9%84-%D8%AA%D8%B9%D8%B7%D9%84-%D8%A7%D9%84%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D8%A7%D8%AA/#lab-kill). والبيانات في التجربة داخل Docker Volumes وليست على أقراص جهازك، وال Containers تحتاج الصلاحية SYS\_ADMIN لأن GlusterFS يكتب خصائص ممتدة Extended Attributes من نوع `trusted.*`، والكلاينت يحتاج الجهاز `/dev/fuse` ليربط ال Volume. ### ملفات التجربة لا توجد Docker Image رسمية حديثة لـ GlusterFS، لذلك نبني واحدة من حزم Debian 13 بالملف Dockerfile التالي: ```dockerfile # GlusterFS server and FUSE client from Debian 13 packages (lab only). FROM debian:13 RUN apt-get update \ && apt-get install -y --no-install-recommends glusterfs-server glusterfs-client procps attr \ && rm -rf /var/lib/apt/lists/* CMD ["glusterd", "-N", "--log-file=-"] ``` ثم الملف compose.yaml: ```yaml # Lab only: three GlusterFS nodes with one brick each (a Docker volume, not a host disk) and a FUSE client. name: lab-stor2-gluster x-node: &node image: lab-stor2-gluster:local cap_add: [SYS_ADMIN] # trusted.* extended attributes on bricks need it networks: [net] networks: net: { name: lab-stor2-gnet } volumes: b1: { name: lab-stor2-brick1 } b2: { name: lab-stor2-brick2 } b3: { name: lab-stor2-brick3 } services: gl1: { <<: *node, container_name: lab-stor2-gl1, hostname: gl1, volumes: ["b1:/bricks"] } gl2: { <<: *node, container_name: lab-stor2-gl2, hostname: gl2, volumes: ["b2:/bricks"] } gl3: { <<: *node, container_name: lab-stor2-gl3, hostname: gl3, volumes: ["b3:/bricks"] } client: image: lab-stor2-gluster:local container_name: lab-stor2-gclient hostname: client cap_add: [SYS_ADMIN] devices: ["/dev/fuse:/dev/fuse"] networks: [net] command: ["sleep", "infinity"] ``` ثم نبني ونشغل ونربط السيرفرات الثلاثة في مجموعة واحدة، وننشئ ال Volume: ```bash docker build -t lab-stor2-gluster:local . docker compose up -d docker exec lab-stor2-gl1 bash -c 'gluster peer probe gl2; gluster peer probe gl3; gluster pool list' for n in 1 2 3; do docker exec lab-stor2-gl$n mkdir -p /bricks/b; done docker exec lab-stor2-gl1 bash -c 'gluster volume create shared replica 3 gl1:/bricks/b gl2:/bricks/b gl3:/bricks/b gluster volume start shared; gluster volume info shared; gluster volume status shared' ``` والمخرج سوف يكون كما يلي (مختصراً): ```text UUID Hostname State a0bf7c0d-f2fd-4170-8bab-5c44ea192d34 gl2 Connected 971a88fc-a8bc-4fce-a329-8615adc6b370 gl3 Connected 1ac43f06-2c93-41c9-b9be-ded2531d4ed4 localhost Connected volume create: shared: success: please start the volume to access data volume start: shared: success Volume Name: shared Type: Replicate Number of Bricks: 1 x 3 = 3 Brick1: gl1:/bricks/b Brick2: gl2:/bricks/b Brick3: gl3:/bricks/b Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick gl1:/bricks/b 58265 0 Y 110 Brick gl2:/bricks/b 50576 0 Y 60 Brick gl3:/bricks/b 58716 0 Y 60 Self-heal Daemon on localhost N/A N/A Y 127 Self-heal Daemon on gl2 N/A N/A Y 77 Self-heal Daemon on gl3 N/A N/A Y 77 ``` لاحظ أن كل الإعداد ثلاثة أوامر، دون خرائط ولا مفاتيح ولا Monitors، وهذه هي البساطة التي جعلت GlusterFS مشهوراً. ولاحظ أيضاً `Self-heal Daemon` على كل سيرفر، وهو البرنامج الذي سوف يصلح النسخ بعد العطل. ### نكتب ملفات ونراها على ال Brick نفسه ```bash docker exec lab-stor2-gclient bash -c 'mkdir -p /mnt/shared; mount -t glusterfs gl1:/shared /mnt/shared dd if=/dev/urandom of=/tmp/4m.bin bs=1M count=4 status=none time (for i in $(seq 1 50); do cp /tmp/4m.bin /mnt/shared/file-$i; done); md5sum /tmp/4m.bin' docker exec lab-stor2-gl2 bash -c 'ls -la /bricks/b/file-7; getfattr -d -m . -e hex /bricks/b/file-7; md5sum /bricks/b/file-7' ``` ```text real 0m4.465s 25461f9ff4b1ae9dea773335791ab6af /tmp/4m.bin -rw-r--r-- 2 root root 4194304 Oct 12 20:14 /bricks/b/file-7 # file: bricks/b/file-7 trusted.afr.dirty=0x000000000000000000000000 trusted.gfid=0x0a5c83a63de04b3697e0850a3796c228 trusted.gfid2path.671ab7c43aa17bc5=0x3030303030...2f66696c652d37 trusted.glusterfs.mdata=0x0100000000... 25461f9ff4b1ae9dea773335791ab6af /bricks/b/file-7 ``` في المخرج أعلاه لاحظ التالي: - الملف على ال Brick في gl2 هو الملف نفسه بحجمه وMD5 نفسه، ونستطيع نسخه من القرص مباشرة لو توقف GlusterFS كله. - `trusted.gfid` هو المعرف الفريد للملف داخل GlusterFS، و`trusted.afr.dirty` هو العداد الذي تستخدمه AFR لتعرف هل هذه النسخة تحتاج إصلاحاً. - لا تعدل الملفات ولا تحذفها من ال Brick مباشرة، لأن GlusterFS لا يعرف بالتغيير، فتختلف النسخ دون أن يسجل ذلك في قائمة الإصلاح، واقرأ منه فقط عند الكارثة. ### نوقف سيرفراً ثم نعيده ```bash date -u +%T; docker kill lab-stor2-gl3 docker exec lab-stor2-gclient bash -c 'for i in $(seq 51 70); do cp /tmp/4m.bin /mnt/shared/file-$i; done echo changed > /mnt/shared/file-1; ls /mnt/shared | wc -l' docker exec lab-stor2-gl1 gluster volume heal shared info summary ``` ```text 20:14:39 lab-stor2-gl3 70 Brick gl1:/bricks/b Status: Connected Total Number of entries: 22 Number of entries in heal pending: 22 Number of entries in split-brain: 0 Brick gl2:/bricks/b Status: Connected Total Number of entries: 22 Number of entries in heal pending: 22 Brick gl3:/bricks/b Status: Transport endpoint is not connected Total Number of entries: - ``` الكتابة استمرت دون أي خطأ للكلاينت، وال 22 عنصراً هي الملفات والمجلدات التي تغيرت أثناء غياب gl3\. والمهم هنا أن GlusterFS لم ينسخ شيئاً إلى أي مكان آخر، وإنما سجل ما تغير وانتظر. والآن نعيد gl3 ونراقب قائمة الإصلاح كل ثلاث ثوان تقريباً: ```bash docker start lab-stor2-gl3 docker exec lab-stor2-gl1 gluster volume heal shared info summary | grep -m1 "Total Number of entries" ``` ```text 20:15:21 (gl3 started) 20:15:31 Total Number of entries: 22 20:15:37 Total Number of entries: 11 20:15:42 Total Number of entries: 0 ``` خلال 21 ثانية من عودة gl3 أصلح Self-heal Daemon العناصر كلها، وبعدها وجدنا على ال Brick في gl3 سبعين ملفاً ومحتوى file-1 هو `changed`. لكن قارن هذا بما حدث في Ceph: هناك بعد 60 ثانية أخرج ال Monitor ال OSD المتوقف وأعاد نسخ بياناته على سيرفر آخر دون أن يعود ال OSD، أما في GlusterFS فلو لم يعد gl3 أبداً لبقيت البيانات بنسختين إلى أن يقوم المدير بنفسه بأمر `gluster volume replace-brick ... commit force` كما في [توثيق إدارة ال Volumes](https://docs.gluster.org/en/latest/Administrator-Guide/Managing-Volumes/?ref=arabroot.io). والصورة التالية تلخص الفرق: ![صفان: في GlusterFS replica 3 توقف gl3 والكتابة مستمرة على اثنين، ثم قائمة الإصلاح فيها 22 عنصراً على gl1 وgl2 ولا شيء ينتقل إلى سيرفر آخر، ثم يعود gl3 ويصلح Self-heal العناصر من 22 إلى 11 إلى 0 في 20 ثانية تقريباً بشرط عودة ال Brick نفسه، وإذا لم يعد فالمدير يشغل replace-brick. وفي Ceph بأربعة سيرفرات توقف osd.2 والمجموعات active+degraded، ثم انتظار down_out_interval وهو 600 ثانية افتراضياً و60 في التجربة، ثم تعيد CRUSH التوزيع وتنسخ إلى سيرفرات أخرى وتعود الحالة active+clean بعد 78 ثانية من الإيقاف دون تدخل المدير](https://arabroot.io/content/images/2026/10/ceph-vs-glusterfs-02-failure.webp) GlusterFS ينتظر عودة ال Brick نفسه، وCeph ينقل النسخة إلى سيرفر آخر بعد مهلة ### نكسره: سيرفر واحد من ثلاثة ماذا لو توقف سيرفران؟ في replica 3 يكون النصاب من جهة الكلاينت Client Quorum مفعلاً بالقيمة `auto`، وتوثيق [النصاب وال Arbiter](https://docs.gluster.org/en/latest/Administrator-Guide/arbiter-volumes-and-quorum/?ref=arabroot.io) يقول إن الكتابة تحتاج نسختين متاحتين على الأقل، وإن ال Volume منذ الإصدار 3.13 يصبح غير متاح بالخطأ ENOTCONN بدل أن يصبح للقراءة فقط: ```bash docker kill lab-stor2-gl2 lab-stor2-gl3; sleep 5 docker exec lab-stor2-gclient bash -c 'echo test > /mnt/shared/new.txt; echo "write exit=$?"; cat /mnt/shared/file-1; echo "read exit=$?"' docker exec lab-stor2-gl1 gluster volume get shared cluster.quorum-type ``` ```text bash: line 1: /mnt/shared/new.txt: Transport endpoint is not connected write exit=1 cat: /mnt/shared/file-1: Transport endpoint is not connected read exit=1 Option Value ------ ----- cluster.quorum-type auto ``` الكتابة والقراءة توقفتا معاً، وهذا هو السلوك نفسه الذي رأيناه في Ceph عندما بقي OSD واحد تحت min\_size، والفرق أن GlusterFS يرد بالخطأ فوراً بينما انتظرت Ceph حتى انتهت المهلة. وهذا هو السلوك الصحيح في الحالتين، لأن البديل هو انقسام الدماغ Split Brain الذي شرحناه في [مفاهيم التوفر العالي](https://arabroot.io/articles/%D9%85%D9%81%D8%A7%D9%87%D9%8A%D9%85-%D8%A7%D9%84%D8%AA%D9%88%D9%81%D8%B1-%D8%A7%D9%84%D8%B9%D8%A7%D9%84%D9%8A-high-availability-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/#split-brain)، أي أن يكتب كل سيرفر نسخة مختلفة من الملف نفسه. ولهذا السبب لا تنشئ GlusterFS بـ replica 2، فالتوثيق نفسه يشرح أن النصاب لا يمكن تطبيقه فعلاً على نسختين دون أن تخسر التوفر، والحل الموثق إذا كان لديك سيرفران للبيانات فقط هو replica 3 مع Arbiter، أي Brick ثالث يحفظ البيانات الوصفية فقط ليرجح بين النسختين. ### الملفات الصغيرة: حيث يظهر ثمن البساطة بعد أن أعدنا السيرفرات، أنشأنا ألفي ملف صغير في ال Volume ثم في قرص الكلاينت المحلي للمقارنة، ثم عرضنا المجلد بـ `ls -l`: ```bash docker exec lab-stor2-gclient bash -c 'mkdir -p /mnt/shared/small /tmp/small time (for i in $(seq 1 2000); do echo "row $i" > /mnt/shared/small/f$i; done); time ls -l /mnt/shared/small | wc -l time (for i in $(seq 1 2000); do echo "row $i" > /tmp/small/f$i; done); time ls -l /tmp/small | wc -l' ``` | العملية | GlusterFS replica 3 | القرص المحلي | | ----------------------- | ------------------- | ------------ | | إنشاء 2000 ملف صغير | 20.4 ثانية | 0.30 ثانية | | عرض المجلد بـ ls -l | 1.37 ثانية | 0.028 ثانية | | نسخ 50 ملفاً بحجم 4 MiB | 4.5 ثانية | لم نقسه | الأرقام للتوضيح فقط، لأن السيرفرات الثلاثة على جهاز واحد والشبكة بينها افتراضية، لكن النسبة هي المهمة: كل ملف صغير يحتاج عدة رحلات Round Trips إلى ثلاثة سيرفرات للبحث والقفل والكتابة، فصار إنشاء الملف أبطأ بقرابة 70 مرة، بينما الملفات الكبيرة تتحمل هذه التكلفة لأنها تدفعها مرة واحدة لكل 4 MiB. لذلك لا تضع على GlusterFS مجلد كود أو مجلد Cache أو بريداً بصيغة Maildir، وهذه بالضبط الاستخدامات التي تجد شكاوى كثيرة عنها. ولم نقارن السرعة بين النظامين مباشرة، والسبب أن ال OSDs في تجربة Ceph كانت تكتب على ملفات داخل جهاز افتراضي وأعطت تحذير البطء طوال الوقت، بينما ال Bricks هنا مجلدات عادية، فأي رقم يضعهما جنباً إلى جنب سوف يقيس طريقة التجربة وليس النظامين. وأما ما قسناه بإنصاف فهو السلوك عند العطل، وهو في الجدول التالي. ### التنظيف ```bash docker exec lab-stor2-gclient umount /mnt/shared docker compose down -v docker rmi lab-stor2-gluster:local debian:13 ``` ## المقارنة في جدول واحد | المعيار | Ceph | GlusterFS | | ---------------------- | ------------------------------------------------------- | ------------------------------------------------------------ | | أنواع التخزين | كتل RBD وملفات CephFS وكائنات S3 عبر RGW | ملفات فقط | | كيف يعرف مكان البيانات | الهاش ثم CRUSH من خريطة يحفظها ال Monitors | هاش اسم الملف في DHT داخل الكلاينت | | البيانات على القرص | كائنات في BlueStore على قرص خام | ملفات عادية على XFS تقرؤها بـ ls | | من يكتب النسخ | ال Primary OSD | الكلاينت عبر AFR | | عند توقف سيرفر نهائياً | ينسخ إلى سيرفر آخر وحده بعد المهلة، 78 ثانية في التجربة | ينتظر عودة ال Brick، والاستبدال يدوي | | عند عودة السيرفر | ينسخ ما فاته، 26 ثانية في التجربة | Self-heal لما تغير، 21 ثانية في التجربة | | تحت النصاب | الطلبات تنتظر حتى تنتهي المهلة | خطأ ENOTCONN فوراً | | صعوبة البداية | خرائط ومفاتيح وMonitors، أو cephadm وProxmox | ثلاثة أوامر | | الملفات الصغيرة | CephFS يحتاج MDS بذاكرة 8 GiB أو أكثر بحسب التوثيق | أبطأ بقرابة 70 مرة من القرص المحلي في التجربة | | الرخصة | LGPL-2.1 أو LGPL-3 | GPLv2 أو LGPLv3، بحسب ملفي الرخصة في المستودع | | الصيانة اليوم | سلسلتان نشطتان، وأكثر من 1000 Commit في 2026 | آخر إصدار 11.2 في يوليو 2025، و35 Commit من 3 مطورين في 2026 | | Proxmox VE 9 | مدمج ويدار من الواجهة | حذف دعمه | ### Ceph نقاط القوة: نظام واحد للأنواع الثلاثة، ويصلح نفسه دون تدخل، ومشروع نشط له إصدارات منتظمة، ومدمج في Proxmox ويديره Rook في Kubernetes. ونقاط الضعف: يحتاج أربعة سيرفرات ليصلح نفسه، وشبكة 10 Gb/s على الأقل، وذاكرة 4 GB لكل قرص، ومن يفهم حالات ال PG، والبيانات لا تقرأ من القرص دونه. 💡 إذا قررت أن Ceph هو الأنسب لك، فقد شرحنا بنيته وتجربة كاملة عليه نوقف فيها الأقراص واحداً بعد الآخر في دليل [Ceph للمبتدئين](https://arabroot.io/articles/ceph-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-%D8%AA%D8%AE%D8%B2%D9%8A%D9%86-%D9%85%D9%88%D8%B2%D8%B9-%D9%8A%D8%AA%D8%AD%D9%85%D9%84-%D8%AA%D8%B9%D8%B7%D9%84-%D8%A7%D9%84%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D8%A7%D8%AA/). ### GlusterFS نقاط القوة: أسهل نظام ملفات موزع في التثبيت، والملفات عادية على القرص فتنجو من أسوأ الأعطال، ويعمل جيداً مع الملفات الكبيرة. ونقاط الضعف: الصيانة قلت إلى ثلاثة مطورين في 2026، وRed Hat أنهت منتجها في 2024، وProxmox حذفت دعمه، وبطيء مع الملفات الصغيرة والمجلدات الكبيرة، ولا يعيد النسخ إلى مكان آخر دون تدخل. ولهذا لم نكتب له دليل تثبيت مستقل، والتجربة أعلاه تكفي من يحتاج أن يفهم نظاماً يعمل لديه. ## البدائل: ليست كل حاجة تحتاج نظام ملفات موزعاً أغلب من يبحث عن Ceph أو GlusterFS لا يحتاج نظام ملفات موزعاً بالمعنى الكامل، وإنما يحتاج واحداً من أربعة أشياء، ولكل منها أداة أبسط: - ملفات التطبيق والصور والنسخ الاحتياطية: تخزين كائنات S3، فأغلب التطبيقات الحديثة تكتب إلى S3 مباشرة بدل نظام ملفات مشترك. و[SeaweedFS](https://github.com/seaweedfs/seaweedfs?ref=arabroot.io) برخصة Apache-2.0 وآخر إصدار له 4.48 في 28 سبتمبر 2026، يقدم S3 ويقدم أيضاً نظام ملفات عبر ال Filer يربط بـ FUSE كما في ملف README الخاص به، وقد شرحنا تثبيته في [تخزين S3 على سيرفرك](https://arabroot.io/articles/%D8%AA%D8%AE%D8%B2%D9%8A%D9%86-%D8%A7%D9%84%D9%83%D8%A7%D8%A6%D9%86%D8%A7%D8%AA-s3-%D8%B9%D9%84%D9%89-%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D9%83-%D8%A7%D9%84%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-%D9%88%D8%A7%D9%84%D8%A8%D9%86%D9%8A%D8%A9/#seaweedfs). - MinIO: لا تبدأ به مشروعاً جديداً، فالنسخة المجتمعية أصبحت كوداً فقط ثم دخلت الصيانة ثم أرشفت، والتفاصيل بالتواريخ في [مقارنة خوادم S3](https://arabroot.io/articles/%D8%A7%D9%8A-%D8%AA%D8%AE%D8%B2%D9%8A%D9%86-s3-%D9%85%D8%B3%D8%AA%D8%B6%D8%A7%D9%81-%D8%B0%D8%A7%D8%AA%D9%8A%D8%A7-%D9%8A%D9%86%D8%A7%D8%B3%D8%A8%D9%83/#minio-changes). - أقراص ل Pods في Kubernetes: [Longhorn](https://longhorn.io/?ref=arabroot.io) تخزين كتل موزع مخصص ل Kubernetes، برخصة Apache-2.0، وهو مشروع Incubating في CNCF منذ 4 نوفمبر 2021 بحسب [صفحته في CNCF](https://www.cncf.io/projects/longhorn/?ref=arabroot.io)، وآخر إصدار له v1.13.0 في 29 سبتمبر 2026، وهو أخف من Ceph بكثير إذا كان كل ما تحتاجه أقراص للتطبيقات داخل Kubernetes، وقد ذكرنا سبب الحاجة إليه في [هل تحتاج Kubernetes فعلاً؟](https://arabroot.io/articles/%D9%87%D9%84-%D8%AA%D8%AD%D8%AA%D8%A7%D8%AC-kubernetes-%D9%81%D8%B9%D9%84%D8%A7/). - قرص واحد منسوخ بين سيرفرين لقاعدة بيانات أو خدمة بنظام Active-Passive: [DRBD](https://linbit.com/drbd/?ref=arabroot.io) من LINBIT، وهو بحسب موقعه برنامج تخزين كتل موزع ومنسوخ يعمل كوحدة في نواة Linux، ورخصة [مستودعه](https://github.com/LINBIT/drbd?ref=arabroot.io) GPL-2.0، ويستخدم كثيراً خلف قواعد البيانات عالية التوفر، وقد شرحنا نمط Active-Passive في [مفاهيم التوفر العالي](https://arabroot.io/articles/%D9%85%D9%81%D8%A7%D9%87%D9%8A%D9%85-%D8%A7%D9%84%D8%AA%D9%88%D9%81%D8%B1-%D8%A7%D9%84%D8%B9%D8%A7%D9%84%D9%8A-high-availability-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/#active-passive). - سيرفر ملفات واحد قوي مع نسخة على سيرفر آخر: ZFS مع send وreceive كما في [ZFS للمبتدئين](https://arabroot.io/articles/zfs-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-%D9%83%D9%8A%D9%81-%D9%8A%D8%AD%D9%85%D9%8A-%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA%D9%83-%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D9%84%D9%81-%D8%A7%D9%84%D8%B5%D8%A7%D9%85%D8%AA/#send-receive)، أو TrueNAS كما في [TrueNAS عملياً](https://arabroot.io/articles/truenas-%D8%B9%D9%85%D9%84%D9%8A%D8%A7-%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-%D8%A7%D9%84%D9%89-%D8%A7%D9%88%D9%84-%D9%85%D8%B4%D8%A7%D8%B1%D9%83%D8%A9-%D9%85%D8%AD%D9%85%D9%8A%D8%A9/). وهذا يكفي أغلب الشركات الصغيرة، والثمن أن الانتقال إلى النسخة الثانية عند العطل ليس تلقائياً. ## أي حل تختار؟ | حالتك | الحل الأنسب | والسبب | | ------------------------------------------------------- | ----------------------------------------------- | --------------------------------------------------------- | | سيرفر أو اثنان ومشاركة ملفات للموظفين | ZFS أو TrueNAS مع نسخ متماثل إلى سيرفر ثان | أقل تعقيد، والبيانات محمية من التلف الصامت | | تطبيق يحفظ صوراً ومرفقات ونسخاً احتياطية | SeaweedFS أو Garage بواجهة S3 | التطبيق يكتب إلى S3 مباشرة، ولا يحتاج نظام ملفات مشتركاً | | Cluster من Proxmox بثلاثة سيرفرات أو أكثر وشبكة 10 Gb/s | Ceph المدمج في Proxmox، والأفضل بأربعة سيرفرات | أقراص الآلات مشتركة وتنتقل بين السيرفرات، والإصلاح تلقائي | | أقراص لتطبيقات داخل Kubernetes | Longhorn، أو Ceph عبر Rook إذا كان الحجم كبيراً | Longhorn أبسط بكثير للأحجام الصغيرة والمتوسطة | | قاعدة بيانات بسيرفرين نشط واحتياطي | التكرار المدمج في قاعدة البيانات، أو DRBD | النسخ على مستوى القرص بين سيرفرين أبسط من Cluster تخزين | | مؤسسة تحتاج كتلاً وملفات وكائنات من نظام واحد | Ceph | لا يوجد بديل مفتوح بالمستوى نفسه يجمع الثلاثة | | لديك GlusterFS يعمل اليوم | أبقه مع خطة انتقال، ولا تضف إليه أحمالاً جديدة | الصيانة قلت، وProxmox 9 حذف دعمه، والانتقال يحتاج وقتاً | وإذا كنت ستنتقل من GlusterFS، فلا تحتاج أداة خاصة، لأن الملفات عادية: اربط ال Volume ثم انسخ إلى الوجهة الجديدة بـ rsync إذا كانت نظام ملفات، أو بـ rclone إذا كانت S3، وتحقق من العدد والحجم قبل أن توقف القديم، واجعل النسخ الاحتياطي يعمل على الوجهة الجديدة قبل الانتقال كما في [قاعدة 3-2-1](https://arabroot.io/articles/%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D9%8A%D8%A7%D8%B7%D9%8A-%D8%A8%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-3-2-1-%D9%88%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%B9%D8%A7%D8%AF%D8%A9/). ## الخلاصة - GlusterFS لم يمت، لكن Red Hat أنهت منتجها في 31 ديسمبر 2024، وProxmox VE 9.0 حذف دعمه في أغسطس 2025، وآخر إصدار 11.2 في يوليو 2025، و35 Commit من 3 مطورين فقط في 2026، فلا تبدأ عليه مشروعاً جديداً. - النظامان يحسبان المكان بالهاش دون سيرفر مركزي، لكن في GlusterFS الكلاينت يكتب كل نسخة والملفات عادية على القرص، وفي Ceph ال Primary ينسخ والبيانات في BlueStore. - عند توقف سيرفر استمرت الكتابة في الاثنين، وأصلح GlusterFS ما تغير في 21 ثانية بعد عودة السيرفر، لكنه لا ينقل النسخة إلى مكان آخر إذا لم يعد، بينما يفعل Ceph ذلك وحده. - تحت النصاب توقف الاثنان، وهذا هو السلوك الصحيح، ولا تستخدم replica 2 في GlusterFS دون Arbiter. - الملفات الصغيرة أبطأ بقرابة 70 مرة على GlusterFS في تجربتنا، فلا تضع عليه كوداً أو Cache. - أغلب الحالات لا تحتاج نظام ملفات موزعاً: S3 للتطبيقات، وLonghorn ل Kubernetes، وDRBD لقاعدة بيانات بسيرفرين، وZFS للسيرفر الواحد، وCeph عندما تحتاج كل شيء على أربعة سيرفرات أو أكثر. ## سجل التحديثات - أكتوبر 2026: كتابة المقال، والتجربة على GlusterFS 11.1 من حزم Debian 13 في ثلاثة Containers مع كلاينت FUSE، فوق Docker Engine 29.8.0، ومقارنة بنتائج تجربة Ceph 20.2.4 في دليل Ceph للمبتدئين. وحالة المشاريع وعدد ال Commits كما قرأناها من صفحاتها ومن واجهة GitHub في 12 أكتوبر 2026.