مخاطر البيئات متعددة المشتركين: تأثير الجار المزعج واستنزاف النواة

في البنى التحتية المؤسسية للوصول عن بُعد، وعقد الحافة السحابية، ومجمعات الأنفاق الشبكية الكبرى، يمثل تشغيل أعباء عمل متعددة لمؤسسات مختلفة على عتاد فيزيائي مشترك معياراً تشغيلياً معتمداً. غالباً ما يدير خادم واحد مئات الأنفاق المتزامنة، ووكلاء التقسيم الأمني، وخدمات التوجيه المشفرة.

ومع ذلك، فإن تشغيل معماريات VPN متعددة المشتركين (multi-tenant) دون عزل صارم للموارد على المستوى المنخفض يعرض الخادم لمخاطر هيكلية جسيمة:

  1. استنزاف ذاكرة مقابس الشبكة في النواة: تخصص مقابس الشبكة ذاكرة النواة عبر مخصص الذاكرة المجزأة slab (skbuff_head_cache). وإذا تعرض حساب عميل لحلقة حزم داخلية أو هجوم حرمان من الخدمة، يمكن لمخازن المقابس (sk_rmem_alloc) أن تلتهم غيغابايتات من ذاكرة النواة غير القابلة للترحيل. وفي آليات العزل التقليدية، يتسبب ذلك في انهيار OOM عام يسقط كافة أنفاق المشتركين الآخرين على الخادم.
  2. حرمان المعالج بسبب العمليات التشفيرية المكثفة: تستهلك خوارزميات فك التشفير المتناظر (مثل ChaCha20-Poly1305 و AES-256-GCM) قدراً كبيراً من طاقة المعالجة. فعندما يستحوذ مشترك على كافة مسارات المعالجة المتاحة لإجراء عمليات المصافحة، تتعطل عمليات توجيه حزم المشتركين المجاورين، مما يرفع زمن الاستجابة بعشرات الأجزاء من الألف من الثانية.
  3. التنافس على طوابير بطاقة الشبكة الفيزيائية: يؤدي تنافس المقابس المتعددة على طوابير العتاد في بطاقة الشبكة (NIC) إلى ملء مخازن الإرسال، متسبباً في إسقاط عشوائي للحزم على مستوى بطاقة الخادم بالكامل.

ورغم أن الإصدار الأول cgroups v1 قدم ضوابط مبدئية، إلا أن بنيته المتفرقة عجزت عن تتبع ذاكرة النواة وتسببت في تأخيرات تزامن عالية. في المقابل، توفر بنية Control Groups v2 (cgroups v2) الموحدة في لينكس آليات العزل الحتمية لحماية الأنظمة متعددة المشتركين.

البنية الداخلية لنظام cgroups v2: الهيكل الهرمي الموحد

تم تطوير نظام cgroups v2 وتثبيته في إصدارات نواة لينكس من 4.5 حتى 6.x، مستبدلاً الأشجار المنفصلة السابقة بهيكل هرمي موحد للعمليات يتمركز في الدليل /sys/fs/cgroup.

+-------------------------------------------------------------------------+
|                  جذر الهيكل الموحد لنظام cgroups v2 (/sys/fs/cgroup)    |
+-------------------------------------------------------------------------+
                                    |
      +-----------------------------+-----------------------------+
      | cgroup.subtree_control = "+cpu +memory +io"               |
      v                                                           v
+-------------------------------+               +-------------------------------+
| شريحة المشترك: Alpha          |               | شريحة المشترك: Beta           |
| /sys/fs/cgroup/vpn/tenant_a   |               | /sys/fs/cgroup/vpn/tenant_b   |
+-------------------------------+               +-------------------------------+
| - cpu.max = 200000 100000     |               | - cpu.max = 100000 100000     |
|   (الحد الأقصى: نواتا معالج)  |               |   (الحد الأقصى: نواة واحدة)   |
| - memory.high = 2G            |               | - memory.high = 1G            |
| - memory.max = 3G             |               | - memory.max = 1.5G           |
| - eBPF cgroup_skb ingress     |               | - eBPF cgroup_skb ingress     |
| - eBPF cgroup_skb egress      |               | - eBPF cgroup_skb egress      |
+-------------------------------+               +-------------------------------+
       |                                               |
       v العمليات المرتبطة                             v العمليات المرتبطة
+-------------------------------+               +-------------------------------+
|  tun_worker_a (PID 14210)     |               |  tun_worker_b (PID 14502)     |
|  crypto_a     (PID 14211)     |               |  crypto_b     (PID 14503)     |
+-------------------------------+               +-------------------------------+

قاعدة حظر العمليات الداخلية

تقوم البنية المعمارية لـ cgroups v2 على مبدأ صارم: يُمنع احتواء العقد غير الطرفية على عمليات ومجموعات فرعية في آن واحد. وتقتصر استضافة معرّفات العمليات النشطة (cgroup.procs) على العقد الطرفية فقط. يزيل هذا التصميم أي التباس في توزيع الموارد ويضمن جدولة هرمية مستقرة.

لتفعيل وحدات التحكم للشرائح الفرعية، تكتب العقدة الأصلية أسماء وحدات التحكم في ملف cgroup.subtree_control:

# تفعيل وحدات تحكم المعالج والذاكرة والإدخال/الإخراج لشرائح VPN
echo "+cpu +memory +io" > /sys/fs/cgroup/vpn/cgroup.subtree_control

تدقيق ذاكرة المقابس وآليات استرداد الصفحات

تتجلى القفزة النوعية في cgroups v2 في قدرته على دمج ذاكرة النواة بالكامل. في الإصدار الأول، بقيت مخازن مقابس الشبكة (struct sk_buff) خارج قيود الذاكرة دون تعديلات معقدة. أما في cgroups v2، فإن أي حجز لمخازن المقابس تجريه عمليات المجموعة يُحسب تلقائياً ضمن استهلاك الذاكرة الإجمالي لتلك المجموعة.

الحماية متعددة المستويات عبر memory.high و memory.max

توفر وحدة تحكم الذاكرة خطوط دفاع متدرجة لمنع الاستهلاك المفرط:

  • memory.min (الحد المضمون): لا يمكن استرداد الذاكرة الواقعة تحت هذا الحد مطلقاً تحت ضغط الذاكرة العام في النظام.
  • memory.low (الحماية الأولية): تتم حماية الصفحات أسفل هذا الحد ما دامت هناك مصادر أخرى قابلة للاسترداد.
  • memory.high (عتبة التهدئة): عندما يتجاوز الاستهلاك الكلي لمشترك (بما في ذلك مخازن أنفاق UDP و TCP) هذا الحد، لا تلجأ النواة إلى إيقاف العمليات فوراً. بدلاً من ذلك، تبطئ النواة استجابة العمليات عند العودة من استدعاءات النظام وتباشر استرداداً حثيثاً وغير متزامن للصفحات.
  • memory.max (السقف الحاسم): إذا وصل الاستهلاك إلى هذا السقف وفشلت محاولات الاسترداد، يتدخل نظام OOM لإيقاف العمليات داخل شريحة المشترك المخالف حصراً، مع الحفاظ على استقرار كافة المشتركين الآخرين على البوابة.
# تكوين عتبات الحماية لشريحة VPN بحجم 2 غيغابايت
mkdir -p /sys/fs/cgroup/vpn/tenant_alpha
echo "512M" > /sys/fs/cgroup/vpn/tenant_alpha/memory.min
echo "2G"   > /sys/fs/cgroup/vpn/tenant_alpha/memory.high
echo "3G"   > /sys/fs/cgroup/vpn/tenant_alpha/memory.max

ضبط حركة مرور الشبكة عبر برامج eBPF cgroup_skb

تطلبت الحلول القديمة بناء هياكل تحكم بالمرور (tc) معقدة على الجسور الشبكية لتنظيم السرعات بين الخدمات المشتركة. أما في بيئة لينكس الحديثة، فيتكامل نظام cgroups v2 مباشرة مع eBPF من خلال نوع البرنامج BPF_PROG_TYPE_CGROUP_SKB.

يستطيع مهندسو الشبكات ربط مرشحات eBPF مباشرة بمجلد المجموعة باستخدام نقاط الخطاف BPF_CGROUP_INET_INGRESS و BPF_CGROUP_INET_EGRESS. وتخضع كافة المقابس المنشأة بواسطة عمليات المجموعة لهذه القواعد تلقائياً، بغض النظر عن الواجهة الشبكية المستخدمة.

// نموذج برنامج eBPF cgroup_skb لضبط معدل تدفق البيانات الصادرة
#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>

struct {
    __uint(type, BPF_MAP_TYPE_ARRAY);
    __type(key, __u32);
    __type(value, __u64); // تتبع رصيد الرموز المميزة
    __uint(max_entries, 1);
} token_bucket SEC(".maps");

SEC("cgroup_skb/egress")
int throttle_tenant_egress(struct __sk_buff *skb)
{
    __u32 key = 0;
    __u64 *tokens = bpf_map_lookup_elem(&token_bucket, &key);
    if (!tokens)
        return 1; // تمرير الحزمة في حال تعذر العثور على السجل

    // التحقق من حجم الحزمة مقابل رصيد الرموز
    if (skb->len > *tokens) {
        // تجاوز الحصة المحددة للنطاق الترددي؛ إسقاط الحزمة
        return 0;
    }

    *tokens -= skb->len;
    return 1; // السماح بالإرسال
}

char _license[] SEC("license") = "GPL";

يضمن إسناد هذا البرنامج إلى عقدة المجموعة تطبيق تنظيم السرعة بدقة وسرعة فائقة داخل مسار بيانات النواة دون الحاجة لتبديل السياق إلى مساحة المستخدم.

تعزيز أمان الشرائح متعددة المشتركين في RiceGuard

ضمن البنية التحتية الموزعة لبوابات VPNRice، يوظف محرك RiceGuard نظام cgroups v2 لفرض عزل متين وعادل للموارد بين مختلف المؤسسات عبر خوادم الإنتاج عالية الكثافة.

موارد الخادم الفيزيائي (64 نواة معالج، 256 غيغابايت رام، منفذا 100GbE)
                               |
                               v
+-------------------------------------------------------------------+
|               مدير شرائح RiceGuard cgroups v2                     |
+-------------------------------------------------------------------+
       |                                             |
       v شريحة المشترك Alpha (الفئة الذهبية)         v شريحة المشترك Beta (الفئة الفضية)
+-----------------------------+               +-----------------------------+
| - cpu.weight: 200           |               | - cpu.weight: 50            |
| - cpu.max: 800000 100000    |               | - cpu.max: 200000 100000    |
| - memory.min: 4G            |               | - memory.min: 1G            |
| - memory.high: 16G          |               | - memory.high: 4G           |
| - eBPF معدل الدخل: 10Gbps   |               | - eBPF معدل الدخل: 2Gbps    |
+-----------------------------+               +-----------------------------+
       |                                             |
       v                                             v
  منع تسرب الموارد للمجاورين                    منع تسرب الموارد للمجاورين

1. جدولة محكمة لطاقة المعالج

ينظم محرك RiceGuard أعباء العمل عبر دمج الحصص التناسبية cpu.weight أثناء الضغط العالي مع الحدود الصارمة cpu.max وفق جدول CFS. وتحصل شرائح المشتركين ذات الأولوية العالية على أوزان تفضيلية تضمن استمرار مسارات فك التشفير في العمل بسلاسة حتى أثناء موجات التدفق المفاجئة.

2. رصد إجهاد الذاكرة الخالي من الأقفال

بدلاً من تشغيل برمجيات مراقبة متكررة في مساحة المستخدم، يرتبط RiceGuard مباشرة ببيانات Pressure Stall Information (PSI) داخل كل مجموعة (/sys/fs/cgroup/vpn/<مشترك>/memory.pressure). وعند رصد بوادر احتقان في الذاكرة، يعدل النظام حجم نافذة بروتوكول UDP لدى العملاء، مانعاً فقدان الحزم مسبقاً.

3. الدمج مع فضاءات أسماء الشبكة

يجمع RiceGuard بين عزل cgroups v2 وفضاءات أسماء الشبكة (Network Namespace) المستقلة في لينكس. وتقتصر مقابس المشترك على جداول التوجيه المخصصة له، مما يمنع تسرب أي حزم بيانات خارج النطاق المحدد، محققاً مستويات أمان عالية وأداءً مستقراً تحت أشد أعباء العمل التشغيلية.