لماذا تتنافس تطبيقات NAS المنزلية والأرشيفات الضخمة في نفس مساحة التخزين؟

إيفا وونغ هي كاتبة تقنية و ومهندسة هاوية في ZimaSpace. مهووسة بالتكنولوجيا مدى الحياة ولديها شغف بالمختبرات المنزلية والبرمجيات مفتوحة المصدر، تتخصص في تبسيط المفاهيم التقنية المعقدة إلى أدلة عملية وسهلة الفهم. تؤمن إيفا بأن الاستضافة الذاتية يجب أن تكون ممتعة وليست مخيفة. من خلال دروسها، تمكّن المجتمع من تبسيط إعدادات الأجهزة، بدءًا من بناء أول نظام تخزين شبكي NAS وحتى إتقان حاويات Docker.

تطبيقات NAS المنزلية والأرشيفات الكبيرة تتنافس لأن تجمع التخزين الواحد يجب أن يحدد جدول عمل لعمليتين تقدران أنواع أداء مختلفة تمامًا.

التطبيقات تولد قراءات صغيرة حساسة للكمون، والتزامات قواعد البيانات، والسجلات، وتغييرات البيانات الوصفية. مهام الأرشيف تنقل تدفقات طويلة متسلسلة وتحاول استهلاك كل ميغابايت متاح في الثانية. عندما يستخدم كلاهما نفس التجمع، فإنهما يشتركان في قوائم الانتظار للأجهزة، والذاكرة المخبأة، وتخصيص نظام الملفات، والكتابة الخلفية، وأعمال التماثل، ومخاطر الاسترداد—وليس فقط سعة القرص.

انتظار عمليات الإدخال/الإخراج الصغيرة للتطبيق خلف قوائم انتظار الأرشيف الطويلة

يمكن لنسخة الأرشيف أن تبقي العديد من الطلبات الكبيرة معلقة. هذا يزيد من معدل النقل عن طريق إبقاء خط أنابيب التخزين مشغولًا، لكن طلب التطبيق الذي يصل خلف القائمة قد ينتظر لفترة أطول بكثير من وقت خدمته الخاص. عندها يشعر المستخدم بأن لوحة التحكم بطيئة رغم أن نافذة النقل تظهر عرض نطاق ممتاز.

هذه مشكلة تعارض بين الكمون ومعدل النقل. اختبارات تخزين PostgreSQL الحالية تشرح كيف أن WAL، ونقاط التحقق، وقراءات الفهرس، والعملاء المتزامنين يعمقون نفس قائمة الانتظار في معيار تشبع قائمة الانتظار للتخزين. يحتوي NAS المنزلي على عدد أقل من العملاء، لكن عامل النسخ الاحتياطي أو الأرشيف يمكن أن يخلق نفس نمط التنافس بجانب قاعدة بيانات التطبيق.

تجمع التخزين المشترك يحتوي على نقاط تنافس أكثر من أقراصه

تلتقي الطلبات أولاً بذاكرة التخزين المؤقت للتطبيق، وذاكرة التخزين المؤقت لصفحات نظام التشغيل، ونظام الملفات، وجدول كتلة الإدخال/الإخراج، والتجمع الافتراضي، وبرمجيات الجهاز. قد تضيف الضغط على وحدة المعالجة المركزية أو الذاكرة عمليات الضغط، والتشفير، وفحوصات التحقق، والتماثل قبل أن يصل الطلب إلى الأقراص. لذلك يمكن أن يظهر التجمع استخدامًا معتدلاً للقرص بينما تؤخر طبقة عليا العمل بالفعل.

يكشف نظام Linux عن ضوابط التخزين لأن عرض النطاق وحده لا يمكنه حماية خدمة تفاعلية. يشرح دليل تحكم كمون الإدخال/الإخراج كيف يمكن تعديل عمق قائمة الانتظار والتأخير الاصطناعي عندما يفشل عبء العمل المحمي في تحقيق هدفه. التصميم نفسه يؤكد المشكلة الأساسية: يمكن للأقران على نفس الجهاز أن يضروا بعضهم البعض دون مشاركة الملفات.

عبء العمل نمط الإدخال/الإخراج الهدف الأساسي التأثير على الجار
قاعدة بيانات التطبيق قراءات عشوائية صغيرة وكتابات متزامنة كمون استجابة والتزام منخفض يخلق انتقالات متكررة في قائمة الانتظار
السجلات والبيانات الوصفية إضافات وتحديثات صغيرة للتطبيق إقرار سريع ودائم يزيد الضغط على الكتابة الخلفية والسجل
الأرشيف الكبير قراءات أو كتابات متسلسلة كبيرة أقصى معدل نقل يعمق قوائم الانتظار ويشغل الذاكرة المخبأة
فحص السلامة مسح قراءة طويل تغطية كاملة يطرد الصفحات الساخنة ويستهلك عرض النطاق

الذاكرة المخبأة تساعد عبء عمل واحد بينما يطرده آخر

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

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

الكتابة الخلفية والصيانة تطيل المنافسة

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

توثق برامج النسخ الاحتياطي هذا التأثير الجانبي مباشرة: تحديد ضغط إدخال/إخراج النسخ الاحتياطي يحد من الضغط على عمل قاعدة البيانات الحساس للكمون. كما يوضح تحليل موارد النسخ الاحتياطي الأوسع سبب ضرورة النظر في حدود التخزين، والشبكة، والمعالجة معًا بدلاً من لوم قرص واحد فقط.

الفصل يغير جدولة العمل وحدود الفشل

تمنح تجمعات التطبيقات والأرشيف المنفصلة كل عبء عمل قائمة انتظار خاصة به، وسياسة ذاكرة مخبأة، وسلوك مساحة حرة، ونافذة صيانة. يمكن لمجموعات البيانات المنفصلة على تجمع واحد تحسين سياسة حجم السجلات، واللقطات، والحصص، لكنها لا تزال تشترك في الأجهزة الفيزيائية. يمكن لضوابط الإدخال/الإخراج حماية الكمون دون نقل البيانات، لكنها تقلل عمدًا من معدل نقل العمل المتنافس عندما يكون التجمع مشبعًا.

تعتمد الحدود الصحيحة على العرض. إذا كانت نوافذ الأرشيف فقط تسبب توقف التطبيقات، فقد تكون الجدولة أو التحديد كافية. إذا ظلت قواعد البيانات، والصور المصغرة، والحاويات حساسة للكمون طوال اليوم، يوفر الفصل الفيزيائي عزلاً أقوى. يجعل حماية عبء العمل بناءً على الكمون في النواة هذا التوازن واضحًا: يمكن للتخزين أن يحافظ على العمل حتى يفشل خدمة محمية في تحقيق هدفها، عندها يجب أن يتنازل العمل الكبير.

الأسئلة الشائعة

هل سيوقف تجمع SSD الأسرع تنافس التطبيقات والأرشيفات؟

يزيد نقطة التشبع لكنه لا يزيل قوائم الانتظار المشتركة، وطرد الذاكرة المخبأة، والكتابة الخلفية، أو الصيانة. يمكن لعمل متزامن كافٍ أن يزيد كمون التطبيق حتى على التخزين السريع.

هل مجموعات البيانات المنفصلة هي نفسها التجمعات المنفصلة؟

لا. يمكن لمجموعات البيانات أن تفصل السياسات والمحاسبة، لكن الطلبات لا تزال تصل إلى نفس الأجهزة الأساسية. تخلق التجمعات المنفصلة حدًا فيزيائيًا أقوى للإدخال/الإخراج.

هل يجب دائمًا تحديد مهام الأرشيف؟

فقط عندما تتداخل مع العمل الحساس للكمون أو تزعزع استقرار الخادم. قد تحافظ الجدولة خارج ساعات العمل على معدل نقل كامل؛ قد يبرر الاستخدام المختلط المستمر حدود إدخال/إخراج صريحة.

مركز التكنولوجيا والذكاء الاصطناعي

المزيد للقراءة

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.