🌛 🔗 👩‍🎓 إلخ 3.4.3: موثوقية التخزين والأبحاث الأمنية 🎅 🏹 👩‍💼

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

القيمة الرئيسية (KV) إلخ هي قاعدة بيانات موزعة تعتمد على خوارزمية إجماع رافت. في تحليل أجري في عام 2014 ، وجدنا أن etcd 0.4.1 تأثر بما يسمى بالقراءات القديمة بشكل افتراضي(اقرأ العمليات التي تُرجع قيمة قديمة غير ذات صلة بسبب تأخر المزامنة - ترجمة تقريبًا.) . قررنا العودة إلى etcd (هذه المرة - إلى الإصدار 3.4.3) لكي نقيم بالتفصيل إمكاناته في مجال الموثوقية والأمن.

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

رعت الدراسة مؤسسة الحوسبة السحابية الأصلية (CNCF) ، وهي جزء من مؤسسة لينكس. تم تنفيذ ذلك في الامتثال الكامل لسياسات Jepsen الأخلاقية .

1. الخلفية

إن مستودع Etc KV هو نظام موزع مصمم للاستخدام كأساس للتنسيق. مثل Zookeeper و Consul ، يقوم موقع etcd بتخزين كميات صغيرة من الحالات النادرة التحديث ( افتراضيًا حتى 8 جيجا بايت ) في شكل خريطة ذات قيمة رئيسية وتوفر قراءة وكتابة وتحويلات متسلسلة بشكل صارم في جميع أنحاء مستودع البيانات ، بالإضافة إلى بدائل التنسيق مثل الأقفال والتتبع (ساعات) واختيار القائد. تستخدم العديد من الأنظمة الموزعة ، مثل Kubernetes و OpenStack ، وما إلى ذلك لتخزين البيانات الوصفية للكتلة ، وتنسيق طرق العرض المنسقة للبيانات ، واختيار قائد ، إلخ.

في 2014 ، أجرينا بالفعل تقييمًا لـ etcd 0.4.1 . ثم وجدنا أنه بشكل افتراضي عرضة للقراءات التي لا معنى لها بسبب التحسين. بينما يناقش العمل على مبادئ الطوافة الحاجة إلى تقسيم عمليات القراءة إلى خيوط وتمريرها من خلال نظام إجماع لضمان قابليتها للبقاء ، يقرأ إلخ على أي قائد محليًا دون التحقق من حالة أحدث على القائد الأحدث. قام فريق تطوير etcd بتطبيق علامة النصاب الاختيارية ، وفي API etcd version 3.0 ، ظهرت إمكانية الخطية لجميع العمليات باستثناء عمليات التتبع بشكل افتراضي . تركز الـ etcd 3.0 API على خريطة مسطحة KV حيث المفاتيح والقيم معتمة

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

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

1.1 ضمانات الاتساق في التوثيق

اعتبارًا من أكتوبر 2019 ، تنص وثائق etcd الخاصة بواجهة برمجة التطبيقات (API) على أن "جميع مكالمات API تُظهر اتساقًا متسقًا - أقوى شكل لضمان الاتساق متاح على الأنظمة الموزعة." الأمر ليس كذلك: الاتساق المستمر أضعف من قابلية الخطية، وقابلية الخطية يمكن تحقيقها بالتأكيد في الأنظمة الموزعة. علاوة على ذلك ، تنص الوثائق على أنه "أثناء عملية القراءة ، إلخ ، لا يضمن نقل [أحدث (تم قياسه بواسطة الساعة الخارجية بعد إكمال الاستعلام)] المتوفرة على أي عضو في المجموعة". هذا أيضًا بيان متحفظ للغاية: إذا كان etcd يوفر إمكانية الخطية ، فإن عمليات القراءة ترتبط دائمًا بأحدث حالة ملتزمة بترتيب خطي.

تزعم الوثائق أيضًا أن etcd تضمن عزلًا قابلًا للتسلسل: يتم تنفيذ جميع العمليات (حتى تلك التي تؤثر على عدة مفاتيح) بترتيب عام. يصف المؤلفون العزل القابل للتسلسل بأنه "أقوى مستوى عزل متاح في الأنظمة الموزعة". هذا (اعتمادًا على ما تعنيه بـ "مستوى العزل") ليس صحيحًا أيضًا ؛ القابلية التسلسلية الصارمة أقوى من إمكانية التسلسل البسيط ، بينما يمكن تحقيق الأول أيضًا في الأنظمة الموزعة.

تقول الوثائق أن جميع العمليات (باستثناء التتبع) في etcd تكون خطية بشكل افتراضي. في هذه الحالة ، يتم تعريف قابلية الخطية على أنها الاتساق مع الساعات العالمية المتزامنة ضعيفة. وتجدر الإشارة إلى أن هذا التعريف لا يتعارض فقط مع تعريف قابلية الخطيةHerlihy & Wing ، ولكنه يشير أيضًا إلى حدوث انتهاك للسببية: ستحاول العقد ذات الساعات الرائدة قراءة نتائج العمليات التي لم تبدأ حتى. نفترض أن etcd لا تزال ليست آلة زمنية ، وبما أنها تستند إلى خوارزمية Raft ، فيجب تطبيق التعريف المقبول عمومًا لقابلية الخطية.

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

العلم الاختياريserializable مستوى عمليات القراءة من الاتساق الصارم إلى التسلسل المنتظم ، مما يسمح بقراءة حالة ملتزمة قديمة. لاحظ أن العلم serializableلا يؤثر على تسلسل القصة ؛ عمليات KV الخ قابلة للتسلسل في جميع الحالات.

2. تطوير الاختبار

لإنشاء مجموعة اختبار ، استخدمنا مكتبة Jepsen المناسبة. تم تحليل إصدار etcd 3.4.3 (الأحدث اعتبارًا من أكتوبر 19) ، بالعمل على مجموعات دبيان تمتد التي تتكون من 5 عقد. قمنا بتنفيذ عدد من الأخطاء في هذه المجموعات ، بما في ذلك أقسام الشبكة ، وعزل العقد الفردية ، وتقسيم الكتلة إلى أغلبية وأقلية ، بالإضافة إلى الأقسام غير متعدية بأغلبية متداخلة. لقد "أسقطوا" وأوقفوا مجموعات فرعية عشوائية من العقد ، كما عطلوا القادة عمدا. تم إدخال التشوهات الزمنية التي تصل إلى عدة مئات من الثواني ، على فترات متعددة الثواني وفي الثانية مللي ثانية ("وميض سريع"). نظرًا لأن etcd يدعم تغيير عدد المكونات ديناميكيًا ، فقد أضفنا وأزلنا العقد بشكل عشوائي أثناء الاختبار.

تضمنت أحمال الاختبار السجلات والمجموعات واختبارات المعاملات لفحص العمليات على KV ، بالإضافة إلى الأحمال المتخصصة للأقفال والساعات.

2.1 السجلات

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

2.2 مجموعات

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

2.3 إلحاق الاختبار

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

بينما يمنع etcd المعاملات من كتابة نفس المفتاح عدة مرات ، يمكنك إنشاء المعاملات بسجل واحد لكل مفتاح. لقد تأكدنا أيضًا من أن عمليات القراءة في نفس المعاملة تعكس عمليات الكتابة السابقة من نفس المعاملة.

2.4 الأقفال

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

من أجل اختبار أكثر عملية (ولتحديد عدد مرات فشل القفل) ، استخدمنا الأقفال وما إلى ذلك لتنظيم الاستبعاد المتبادل عند إجراء تحديثات للمجموعة في الذاكرةوبحثت عن التحديثات المفقودة في هذه المجموعة. سمح لنا هذا الاختبار بتأكيد ما إذا كانت الأنظمة التي تستخدم etcd كمؤشر يمكن أن تقوم بتحديث الحالة الداخلية بأمان.

تضمن الإصدار الثالث من اختبار القفل الحراس على مفتاح التأجير لتعديل المجموعة المخزنة في etcd.

2.5 التتبع

من أجل التحقق من أن الساعات توفر معلومات حول كل تحديث مفتاح ، تم إنشاء مفتاح واحد كجزء من الاختبار وتعيين قيم صحيحة فريدة بشكل أعمى . وفي الوقت نفسه ، شارك العملاء هذا المفتاح لعدة ثوانٍ في كل مرة. في كل مرة بعد بدء الساعة ، بدأ العميل في المراجعة التي توقف عندها آخر مرة.

في نهاية هذه العملية ، تأكدنا من ملاحظة كل عميل لنفس تسلسل التغييرات الرئيسية.

3. النتائج

3.1 تتبع من المراجعة 0

عند تعقب المفتاح ، يمكن للعملاء تحديد مراجعة أولية ، وهي "مراجعة اختيارية يبدأ التتبع من خلالها (بشكل شامل)". إذا أراد المستخدم رؤية كل عملية بمفتاح معين ، يمكنه تحديد المراجعة الأولى لـ etcd. ما هذا التدقيق؟ نموذج البيانات و مسرد لا توفر جوابا على هذا السؤال. توصف المراجعات بأنها تزيد عدادات 64 بت بشكل رتيب ، ولكن من غير الواضح ما إذا كان etcd يبدأ من 0 أو 1. فمن المعقول افتراض أن العد التنازلي من نقطة الصفر (فقط في حالة).

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

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

3.2 الأقفال الأسطورية

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

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

etcd , ( ) , ( etcd), - :

etcd;
- ( , etcd);
.

تم إعطاء مثل هذا المثال في etcdctl: تم استخدام قفل لحماية الفريق put، لكنه لم يربط مفتاح القفل بالتحديث.

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

كان انتهاك كائن المزامنة ملحوظًا بشكل كبير في عقود الإيجار التي تحتوي على TTLs قصيرة: لم تكن TTLs من 1 و 2 و 3 ثوانٍ قادرة على توفير الاستبعاد المتبادل بعد بضع دقائق فقط من الاختبار (حتى في العناقيد الصحية). أدت عمليات تعليق العملية وأقسام الشبكة إلى مشكلات بشكل أسرع.

في أحد متغيرات اختبار القفل الخاصة بنا ، تم استخدام ملفات mutex لحماية حماية التحديثات المشتركة لمجموعة من الأعداد الصحيحة (كما تقترح الوثائق إلخ). يقرأ كل تحديث قيمة العينة الحالية في الذاكرة ، وبعد حوالي ثانية واحدة ، يكتب هذه المجموعة مرة أخرى مع إضافة عنصر فريد. مع عقود الإيجار مع TTL لمدة ثانيتين ، وخمس عمليات متوازية ، وإيقاف مؤقت للعملية كل خمس ثوانٍ ، تمكنا من التسبب في فقدان ثابت لحوالي 18٪ من التحديثات المؤكدة.

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

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

ولكن حتى إذا كانت خدمة الحظر الموزعة تستخدم ، على سبيل المثال ، نوعًا ما من كاشف الفشل السحري ويمكنها بالفعل ضمان الاستبعاد المتبادل ، في حالة بعض الموارد غير المحلية ، فسيظل استخدامها غير آمن. افترض أن العملية A ترسل رسالة إلى قاعدة البيانات D أثناء الضغط مع القفل. بعد ذلك ، تتعطل العملية A ، وتتلقى العملية B قفلًا وترسل أيضًا رسالة إلى القاعدة D. المشكلة هي أن الرسالة من العملية A (بسبب عدم التزامن) يمكن أن تأتي بعد رسالة من العملية B ، تنتهك الاستثناء المتبادل الذي كان من المفترض أن يوفره القفل. .

لمنع هذه المشكلة ، من الضروري الاعتماد على حقيقة أن نظام التخزين نفسه سيدعم صحة المعاملات أو ، إذا كانت خدمة القفل توفر مثل هذه الآلية ، استخدم" المبارزة" رمز التي سيتم تضمينها في جميع العمليات التي يقوم بها صاحب القفل. سيضمن عدم حدوث أي عمليات لحامل القفل السابق فجأة بين عمليات مالك القفل الحالي. على سبيل المثال ، في خدمة حظر السمين من Google ، تسمى هذه الرموز المميزة التسلسل . في etcd ، يمكنك استخدام مراجعة مفتاح القفل كرمز للحظر أمر عالمي.

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

نتائج العمل في قضايا المشروع:

تبدأ الساعات في المراجعة 0 في وقت لاحق - لم تقرر
عودة الأقفال بعد الحظر دون التحقق من الملكية - في سيد ؛
لم يتم توثيق الأقفال على أنها غير آمنة - لم يتم حلها.

4. مناقشة

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

مراقب (ساعات) للعمل بشكل صحيح - على الأقل على المفاتيح الفردية. إلى أن دمّر ضغط التاريخ البيانات القديمة ، أصدرت الساعة بنجاح كل تحديث رئيسي.

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

نتيجة لتعاوننا ، أجرى فريق etcd عددًا من التعديلات على الوثائق (ظهرت بالفعل على GitHub وسيتم نشرها في الإصدارات المستقبلية من موقع المشروع). تنص صفحة واجهة برمجة تطبيقات GitHub Warranties الآن على أنه يمكن افتراضيًا إجراء تسلسل صارموتمت إزالة الادعاء بأن التسلسل والقابل للتسلسل هما أقوى مستويات الاتساق المتاحة في الأنظمة الموزعة. فيما يتعلق بالمراجعات ، يشار الآن إلى أن البداية يجب أن تكون من الوحدة (1) ، على الرغم من أن وثائق API لا تزال لا تقول أن محاولة البدء من المراجعة 0 ستؤدي إلى "إخراج الأحداث التي حدثت بعد المراجعة الحالية بالإضافة إلى 1" بدلاً من "إرسال جميع الأحداث" المتوقعة. توثيق مشكلات أمان القفل قيد التطوير .

بعض التغييرات في الوثائق ، مثل وصف السلوك الخاص لـ etcd عند محاولة القراءة ، بدءًا من المراجعة الصفرية ، لا تزال تتطلب الانتباه.

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

4.1 التوصيات

إذا كنت تستخدم أقفال في etcd ، فكر في ما إذا كنت بحاجة إليها للأمان أو ببساطة لزيادة الأداء عن طريق الحد المحتمل من التزامن. يمكن استخدام أقفال Etcd لزيادة الأداء ، ولكن استخدامها لأغراض أمنية يمكن أن يكون محفوفًا بالمخاطر.

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

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

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

4.2 خطط أخرى

يعتبر مشروع etcd مستقراً لعدة سنوات: لقد عملت خوارزمية Raft المبنية عليه بشكل جيد ، وواجهة برمجة التطبيقات لعمليات KV بسيطة ومباشرة. على الرغم من أن بعض الميزات الإضافية قد تلقت مؤخرًا واجهة برمجة تطبيقات جديدة ، إلا أن دلالاتها بسيطة نسبيًا. ونحن نعتقد أننا قد درست بالفعل ما يكفي من الأوامر الأساسية مثل getو put، والمعاملات، ومنع وتتبع. ومع ذلك ، هناك اختبارات أخرى يجب إجراؤها.

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

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

تم دعم العمل من قبل مؤسسة الحوسبة السحابية الأصلية.وهو جزء من مؤسسة Linux ، ويتوافق مع سياسات Jepsen الأخلاقية . نريد أن نشكر فريق etcd على مساعدتهم ، والممثلين التاليين على وجه الخصوص: Chris Aniszczyk و Gyuho Lee و Xiang Li و Hitoshi Mitake و Jingyi Hu و Brandon Philips.

إلخ 3.4.3: موثوقية التخزين والأبحاث الأمنية