المعايير #
تظهر أحدث معايير الأداء، المؤرخة في يونيو 2018، تحسنًا مهمًا في الأداء عند استخدام nftables كمسار بيانات بدلاً من iptables.
بالنظر إلى بيئة اختبار تتكون من عميلين يقومان بتشغيل أداة اختبار ضغط تحميل HTTP، وموازن تحميل واحد، و3 خوادم خلفية مع مُنهي HTTP يُقدم استجابة بحجم 210 بايت تقريبًا، نحصل على المعايير التالية في تدفقات HTTP في الثانية :
iptables DNAT 256.864,07 RPS / cpu iptables SNAT 262.088,94 RPS / cpu nftables DNAT 560.976,44 RPS / cpu nftables SNAT 608.941,57 RPS / cpu nftables DSR 7.302.517,31 RPS / cpu
الأرقام المذكورة أعلاه مُقاسة لكل وحدة معالجة مركزية فعلية، حيث أن قابلية التوسع بإضافة المزيد من النوى تكاد تكون خطية. مع أن هذه الاختبارات المعيارية أُجريت باستخدام 3 واجهات خلفية فقط، إلا أن أداء iptables سينخفض بشكل ملحوظ عند إضافة المزيد من الواجهات الخلفية ، لأن ذلك يعني المزيد من القواعد المتسلسلة.
تم تنفيذ هذه المعايير المرجعية مع تعطيل retpoline (لا توجد تخفيفات Spectre/Meltdown)، ولكن بمجرد تمكينها، فإن عقوبات الأداء التي تم اكتشافها في حالات NAT مع تمكين conntrack لكل من حالات iptables وnftables أسوأ بكثير في الحالة الأولى:
iptables: عقوبة وحدة المعالجة المركزية بنسبة 40.77% nftables: عقوبة وحدة المعالجة المركزية بنسبة 17.27%
مفاتيح الأداء #
تم شرح عقوبات retpoline نظرًا لاستخدام استدعاءات غير مباشرة أكثر بكثير في iptables مقارنةً بـ nftables. ولكن، هناك أيضًا بعض مفاتيح الأداء الإضافية التي سيتم شرحها أدناه.
تحسين القواعد #
مفتاح الأداء الرئيسي هو تحسين القواعد. كان معروفًا في iptables أن استخدام ipset يُحسّن الأداء لأنه يُقلل من معالجة القواعد المتسلسلة.
في nftlb، على الرغم من إمكانية توسيعه لاستخدامات أخرى، فقد وضعنا قواعد أساسية لكل خدمة افتراضية باستخدام لغة تعبيرية تدعم استخدام المجموعات والخرائط بشكل أصلي. يرجى الاطلاع أدناه على القواعد المُنشأة لخدمة TCP افتراضية باسم vs01 مع خادمين خلفيين :
جدول ip nftlb { خريطة tcp-services { نوع ipv4_addr . inet_service : حكم
العناصر = { 192.168.0.100 . http: goto vs01 }
} سلسلة التوجيه المسبق { نوع nat hook التوجيه المسبق الأولوية 0؛ قبول السياسة؛
ip daddr . tcp dport vmap @tcp-services
} سلسلة إعادة التوجيه { نوع nat hook إعادة التوجيه الأولوية 100؛ قبول السياسة؛ }
سلسلة vs01 {خريطة dnat إلى jhash ip saddr mod 2 {0: 192.168.1.10، 1: 192.168.1.11} }
}
بمجرد أن نحتاج إلى إضافة واجهة خلفية جديدة، فما علينا سوى إعادة إنشاء السلسلة المرتبطة بالخدمة الافتراضية دون تضمين قواعد جديدة ودون التأثير على بقية الخدمات الافتراضية الأخرى.
سلسلة vs01 {
خريطة dnat إلى jhash ip saddr mod 3 { 0 : 192.168.1.10، 1 : 192.168.1.11، 2 : 192.168.1.12 }
}
ثم، إذا كانت هناك حاجة لإنشاء خدمة افتراضية جديدة vs02 ، فإن مجموعة القواعد تصبح كما هو موضح أدناه، دون إضافة قواعد جديدة أو التأثير على الخدمات الافتراضية الأخرى:
جدول ip nftlb { خريطة tcp-services { نوع ipv4_addr . inet_service : عناصر الحكم = { 192.168.0.100 . http : انتقل إلى vs01،
192.168.0.102 . https: انتقل إلى vs02 } } سلسلة التوجيه المسبق { نوع nat hook التوجيه المسبق الأولوية 0؛ قبول السياسة؛ ip daddr . tcp dport vmap @tcp-services } سلسلة التوجيه اللاحق { نوع nat hook التوجيه اللاحق الأولوية 100؛ قبول السياسة؛ } سلسلة vs01 { dnat إلى jhash ip saddr mod 3 map { 0 : 192.168.1.10، 1 : 192.168.1.11، 2 : 192.168.1.12 } }
سلسلة vs02 {خريطة dnat إلى jhash ip saddr mod 2 {0: 192.168.2.10، 1: 192.168.2.11} }
}
الخطافات المبكرة #
يسمح nftables باستخدام خطاف الدخول المبكر المستخدم في nftlb أثناء سيناريوهات DSR.
يمكن أيضًا استخدام هذه الميزة المبكرة لأغراض التصفية، مما يُحسّن الأداء في حالات فقدان الحزم. يظهر ذلك أدناه في المرحلة المبكرة من حالات iptables وnftables بعدد الحزم في الثانية:
انخفاض معدل التوجيه المسبق لـ iptables: 38.949.054,35 PPS / core انخفاض معدل الدخول لـ nftables: 45.743.628,64 PPS / core
تقنيات التسريع #
لا يزال هناك مجال أكبر للتحسين، إذ تدعم nftables بالفعل مسارات سريعة وتقنيات خفيفة الوزن تُستخدم لتعديل الحزم. ومن الأمثلة على ذلك:
جداول التدفق . مسار Conntrack السريع لتفويض الاتصالات القائمة بالفعل إلى مرحلة الدخول دون المرور عبر المسار البطيء بأكمله. مزيد من المعلومات هنا.
NAT عديم الحالة . في بعض حالات موازنة الأحمال، يمكن تنفيذ NAT عديم الحالة بدون تتبع الاتصال ومن مرحلة الدخول للحصول على جميع الأداء المطبق على سيناريوهات NAT.