سجل الالعاب النارية microvirtuals. نأخذ طريقتين شائعتين لعزل أعباء العمل متعددة المستخدمين - الأجهزة والحاويات الافتراضية. نحن نضغط على أفضل ما في كلا الاتجاهين ، ونبسط قدر الإمكان ، ونختبر حمولة عالية حقيقية. نتيجة لذلك ، نحصل على عزلة لا يمكن اختراقها من أجهزة الكمبيوتر الافتراضية التي يمكن إطلاقها في مئات المللي ثانية. يعمل هذا الحل تحت غطاء AWS Lambda و Fargate ، حيث يدير ملايين الوظائف والحاويات بدون خادم في السحابة كل ثانية. ويسمى الالعاب النارية.
تتوفر هذه الأداة في microSource. إذا كانت مهامك تتطلب عزلة متعددة المستأجرين ، (حسنا ، على سبيل المثال ، قررت إنشاء سحابة خاصة بك) ، فإن Firecracker هي ما تحتاجه.
يتحدث
Vasily Pantyukhin ، مهندس خدمات الويب من Amazon ، عن بنية Firecracker ، وكيفية استخدامها من قبل AWS Lambda ، ويقارنها بالحلول البديلة ويعطي أمثلة على التكامل.
إخلاء المسئولية: كل ما سبق هو رأي فاسيلي الشخصي ، وقد لا يتطابق مع موقع Amazon Web Services.السمات الطبيعية للسحب العامة
واحدة من الخصائص الأساسية للسحب العامة هي الإيجار المتعدد.
يقوم شخص ما بترجمة هذا المصطلح إلى "بيئة متعددة الإيجار" أو "بيئة متعددة المستخدمين". ولكن من وجهة نظري ، هذا لا يعكس الجوهر. تعدد الاستئجار هو عندما يعيش مستخدمون مختلفون وأحمالهم على نفس البنية الأساسية المادية ، ويشاركونها فيما بينهم ، ولكن لا يعرفون شيئًا عن بعضهم البعض. من أعباء العمل متعددة المستخدمين ، تتميز الإيجار المتعدد بمتطلبات أكثر صرامة بشكل أساسي لعزل الموارد والوصول إليها.
خاصية أخرى متأصلة في السحب العامة هي الحمولة الكبيرة.
صدقوني ، في حالة AWS ، هذا عبء ضخم! لقطة الشاشة هي مثال على البيانات الحقيقية. لا أقول كم من الوقت وفي أي منطقة تم قياس هذه الملايين من "الببغاوات" ، لكن هذا ليس نوعًا من حالات الطوارئ ، ولكنه وضع التشغيل المعتاد بالنسبة لنا.
اتضح بعض التناقض. من ناحية ، نحتاج إلى إبقاء المستخدمين معزولين قدر الإمكان. من ناحية أخرى ، يجب أن نضمن مستوى عال جدا من الإنتاجية واستخدام الموارد. تحسين واحد غالبا ما يؤدي إلى قيود الآخر. كيفية العثور على حل وسط ، وحتى أفضل ، للحصول على الحد الأقصى على جميع الجبهات؟
آلات أو حاويات افتراضية؟
هناك طريقتان أساسيتان يمكن أن يساعدان. هذه هي الأجهزة الافتراضية والحاويات. كل له إيجابيات وسلبيات.
العيب الرئيسي للأجهزة الافتراضية هو أنها تستغرق وقتًا
طويلاً للتحميل . عادة ما يستغرق تشغيل الجهاز عدة عشرات من الثواني أو حتى دقائق. لكن virtualoks لها فضيلة - أنها
عزل الأحمال
ملموسة من بعضها البعض. ومن كلا وجهتي النظر:
- الأمان عندما يتعذر على جهاز ظاهري واحد الوصول إلى البيانات في جهاز آخر ؛
- الموارد ، عندما طلبت 8 غيغابايت من الذاكرة ، آمل أن تكون ذاكرة الوصول العشوائي هذه لي ولن يستطيع أحد المطالبة بالمورد الذي دفعته.
العكس هو الحال مع الحاويات: فهي خفيفة الوزن وبالتالي
تحميل بسرعة كبيرة. يمكن تحجيمها بسهولة أفقياً. ولكن هناك ميزة واحدة لا يمكننا العيش بها ، كموفر سحابة عام. يستخدمون
kernel مشترك - تتم مشاركة kernel OS بين جميع الحاويات .
هل يمكن القول بأن الحاويات غير آمنة؟ لا ، رغم وجود ثغرات خطيرة.
أعتقد أن اليوم حاوية "ملحومة" بشكل صحيح يوفر مستوى كاف من الأمن.
المشكلة مختلفة - نواة مشتركة لا تضمن بشكل أساسي أنه في وقت ما في المستقبل ، لن تظهر نقاط الضعف التي تكسر عزلة المستأجرين. لا تستطيع السحابة العامة تحملها حتى من الناحية النظرية.
هناك تناقض آخر ، ويجب البحث عن حل. أسهل طريقة هي أن تأخذ كل ما هو أفضل من أمي - آلة افتراضية ، وأبي - حاوية ، تعبر وتحصل على شيء
متقارب . في الواقع ، لقد فعلنا ذلك. اتضح الالعاب النارية.
الالعاب النارية بالفعل في الإنتاج. في نفس العبء الكبير من الخدمات الهامة ، على سبيل المثال ، AWS Lambda (وظائف بدون خادم) و AWS Fargate (حاويات بدون خادم).
مشاكل AWS امدا القديمة
AWS Lambda هي خدمة ميزة بدون خادم. نحن نأخذ الوظيفة في Java أو Go أو Python أو أي لغة أخرى ، ونرميها في Lambda ، ويتم تنفيذها بطريقة سحرية. ليس من الضروري تخصيص الموارد وإدارتها. كيف تم تنفيذ هذا من قبل؟
لكل حساب AWS ، تم تخصيص جهاز واحد أو أكثر من أجهزة EC2 المنفصلة لعزل الوظائف التي تنتمي إلى مستأجرين مختلفين. مثل هذا الجهاز الظاهري يستهلك الموارد ، حتى عندما لا يفعل شيئًا. لنفترض أننا نقوم بتشغيل وظيفة مرة واحدة كل 10 دقائق ، وأنها تنفذ في 200 مللي ثانية مثل Lambda العادية. اتضح أنه خلال ساعة واحدة يتم استخدام آلة EC2 فقط لبضع ثوان. علاوة على ذلك ، حتى في وقت التشغيل ، لا تستهلك جميع الموارد المتاحة - التخلص منها أسفل اللوح. هذا غير مربح غاضب.
كيف حلت مشكلة إعادة التدوير؟
وضعت من الصفر حل الالعاب النارية الخاصة بهم. هذا واضح من عنوان التقرير :)
لبدء تطوير منتج جديد ، تحتاج إلى مهمة فنية. يحتوي على الكثير من النص ، ولكن إذا حددت المعنى فقط ، فستحصل على ما يلي.
- مدعوم من KVM كمشرف. كل من يعمل مع AWS يعلم أن لدينا برنامجين من برامج Hypervisor المفضلة. VMs القديمة تعمل على Xen. منذ نهاية عام 2017 ، كانت KVM تعيش تحت غطاء جميع السيارات.
- يبدأ بأسرع وقت ممكن. على الأجهزة المرجعية ، كان المتطلب حمولة كاملة من microvirtual في 125 مللي ثانية.
- الحد الأدنى الافتراضية الحمل . في البنية المرجعية ، يستهلك جهاز واحد ظاهري من Firecracker الظاهري 5 ميغابايت فقط من الذاكرة.
- إمكانية البدء الأكثر كثافة . معلمات التصميم - حمولة كاملة من 5 microvirtuals لكل جوهر في الثانية الواحدة. هذا المطلب أساسي للخدمات مثل AWS Lambda. يجب أن تنطلق المهام بسرعة ، وتمارس التمارين وتموت ، وتحرر الموارد من أجل التالي.
- إمكانية إعادة الاشتراك . إنها فرصة - ليس من الضروري استخدامها. في الواقع ، هذا هو تخصيص الموارد الافتراضية إلى حد أكبر مما هو متاح فعليًا. هذا يعني أن الخادم يحتوي على 16 جيجابايت من ذاكرة الوصول العشوائي ، وأنك تقوم في نفس الوقت بتشغيل 4 أجهزة افتراضية ، وكل منها على يقين من أن لديه ذاكرة 8 جيجابايت.
AWS امدا مع الالعاب النارية تحت غطاء محرك السيارة
ما الذي تغير في الإصدار الجديد من AWS Lambda؟ من وجهة نظر المستخدم النهائي ، لم يتغير شيء. كان الانتقال إلى بنية محدثة في الإنتاج شفافًا وغير مرئي تمامًا للمستهلكين. ميزات Lambda قصيرة الأجل - كان من السهل القيام به.
كيف تبدو العمارة الحديثة؟
على أدنى مستوى الآن ليست آلة افتراضية ، ولكن المعدنية العارية المادية.
تتيح هذه الخوادم الاستخدام الكامل لجميع وظائف وحدة المعالجة المركزية ، على سبيل المثال ، Intel VT. يوفر هذا فوائد إضافية عند استخدام المحاكاة الافتراضية في المستويات العليا.
على قمة قطعة الحديد يوجد
نظام التشغيل المضيف مع وحدة KVM في النواة. Firecracker microvirtuals مع
أنظمة تشغيل الضيف الخاصة بهم يتم إطلاقها أعلاه. حسنًا ، لقد قاموا بالفعل بتنفيذ مكونات خدمة AWS Lambda نفسها.
في السابق ، لكل عميل يستخدم ميزات Lambda ، قمنا بتخصيص أجهزة افتراضية EC2 منفصلة مع استخدام منخفض. يتيح لك النهج الجديد تشغيل صورة افتراضية خفيفة الوزن فقط عندما تحتاجها حقًا. يتيح لنا عزل موارد Firecracker من بعضنا البعض القيام بذلك على أجهزة مشتركة بأقصى كثافة. تحسن استخدام الموارد بشكل أساسي.
ماذا يوجد في الصندوق؟
لقد وعدت ببناء علبة الوارد ، لذلك دعنا ننتقل إلى المكونات الرئيسية لـ Firecracker ، وننظر في كل منها على حدة ، ثم نجمعها جميعًا.
مبادئ التصميم
عندما بدأنا مناقشة تطوير Firecracker لأول مرة ، وافقنا على الالتزام بمبدأين.
تخلص من كل شيء غير ضروري. لماذا يتم تحميل الأجهزة الافتراضية الكلاسيكية ببطء؟ على وجه الخصوص ، لأنه تم تحميل الرمز. لديهم لدعم عدد كبير من الأجهزة القديمة. ولكن لماذا تحاكي جهازًا لم يستخدمه أي شخص آخر منذ 10 سنوات؟ ليست هناك حاجة ، لذلك ، نحن نتخلص من كل شيء غير ضروري. نحن نحل مهمة ضيقة محددة وأي وظيفة لا تساعد في حل هذه المشكلة تعتبر غير ضرورية.
تخلص من كل شيء لا لزوم له والتركيز على مهمة واحدة.
تبسيط ما تبقى. حتى ما تبقى يجب أن يكون بسيطا قدر الإمكان.
ماذا يكتبون؟
الالعاب النارية مكتوبة في الصدأ العصرية للأسباب التالية:
- يتيح لك كتابة رمز أكثر أمانًا ، على وجه الخصوص ، من حيث الذاكرة ؛
- الأداء والحمل قابلة للمقارنة C ++ الحديثة.
- تم استخدام الصدأ لفترة طويلة ، ومنذ عام 2015 ، كتب الكثير من حلول الحمل المرتفعة.
حديد
أكرر - يتطلب Firecracker التثبيت على أجهزة حقيقية. كتكوين مرجعي ، تم اختيار آلة المعادن العارية i3.metal.
ملحوظة: كان التقرير في أوائل أبريل 2019. في ذلك الوقت ، تم دعم منصة Intel فقط. في شهر مايو ، قاموا بإضافة دعم alpha لـ AMD ، وفي يونيو ARM. قد يكون AMD أرخص قليلاً من Intel ، ويوفر دعم ARM فرصًا مثيرة للاهتمام للعمل مع إنترنت الأشياء متعدد المستأجرين.إذا طلبت i3.metal أو أي آلة معدنية عارية أخرى في AWS ، فسيكون التكوين قويًا ومكلفًا للغاية بالنسبة للتجارب. لذلك ، إذا قررت تثبيت Firecracker عليها ، فلا تنس أن تسدد هذه الأجهزة بعد التجارب. خلاف ذلك ، سوف تأتي نتيجة لائقة في نهاية الشهر.
هل هناك خيار أرخص؟ نعم ، يمكنك تشغيل Firecracker في بيئة افتراضية. ولكن ليس في AWS بعد الآن - نحن لا ندعم الافتراضية الافتراضية المتداخلة على EC2. ولكن يمكنك القيام بذلك في GCP أو Azure أو DigitalOcean أو استخدام Proxmox أو Parallels أو VMware Fusion. سيعمل كل شيء إذا التزمت بالمتطلبات ، على وجه الخصوص ، وفقًا لإصدار kernel لنظام التشغيل الضيف.
جوهر
العنصر الأساسي للحل هو وحدة KVM للنواة.
فقط في حالة ، سوف أصف كما استطرادا ما هو KVM. ليس هذا هو برنامج Hypervisor بالكامل ، ولكنه جزء منه. وتتمثل مهامها الرئيسية في
إعداد معالج افتراضي (vCPU)
وبدء تشغيل جهاز افتراضي .
ولكن هذا لا يكفي لعمل كامل. بالإضافة إلى المعالج ، هناك حاجة إلى بعض الأجهزة الأخرى. مضاهاة يحدث في مساحة المستخدم.
VMM
حتى تظهر الأجهزة الأساسية على الأقل ، فأنت بحاجة إلى مكون آخر - إدارة الجهاز الظاهري (VMM). قبل Firecracker ، كان خيار VMM الأساسي هو QEMU.
نظرنا بجدية في إمكانية استخدام QEMU ، لكننا قررنا تطوير "الدراجة" الخاصة بنا. كانت هناك عدة أسباب لذلك.
إدارة التطوير . QEMU منتج كبير وناضج يحتوي على أكثر من مليون سطر من التعليمات البرمجية. لإجراء تغييرات ، تحتاج إلى عرض الكثير من أكواد المصدر. يشارك الكثير من الناس في التطوير وصنع القرار في التنمية.
الأمن. تستطيع QEMU محاكاة الكثير من الأجهزة. هذا هو السبب في أنه يحتوي على سطح الهجوم كبيرة إلى حد ما. مهمتنا هي جعل microvirtual. من وجهة نظر أمنية ، يجب علينا تقليل سطح الهجوم.
الحاجة إلى تنفيذ ميزات جديدة. QEMU لديه رمز جيد. هذا منتج ناضج يتم فيه اكتشاف جميع الأخطاء الواضحة بالفعل. ولكن في شكلها الحالي ، لا تزال وظائف QEMU لا تناسبنا - وسيتعين علينا إضافة الكثير. من وجهة النظر هذه ، سيكون الكود الجديد في QEMU وفي المنتج الجديد بنفس الجودة. لذلك ، لن يعمل فوز خاص.
الأجهزة
يقوم Firecracker بتنفيذ VMM ، والذي يستخدم لمحاكاة الأجهزة. نحن نحاكي الأجهزة التالية:
- وحدة التحكم. شيء مفيد وضروري ، على الرغم من أنه يمكن إيقاف تشغيله.
- لوحة المفاتيح. لقد صنعنا لوحة مفاتيح صعبة - مع زر "إعادة ضبط" واحد فقط. نحن ببساطة لا نثق في برنامج "إعادة ضبط" لأنظمة التشغيل التي يمكن أن تعمل في Firecracker. لذلك ، صنعوا الحديد.
- برامج تشغيل Virtio للقرص والشبكة . Virtio هو جهاز بدائي للغاية. في جوهرها ، وهذا هو "حلقة عازلة". كتب نظام الضيف شيئًا ما إلى المخزن المؤقت ، ثم نقر على المكالمة ، وقراءة النظام المضيف البيانات من هذا المخزن المؤقت من خلال ملف.
في بعض الحالات ، على سبيل المثال ، للتكامل مع الحاويات ، ما زلنا بحاجة إلى جهاز شبكة يمثل الوظيفة الأساسية لبطاقة شبكة عادية. Virtio لا يصلح هنا ، بسيطة للغاية. لذلك ، بالنسبة للشبكة ، نستخدم جهازًا آخر -
Vsock .
حسنًا ، نحتاج أيضًا إلى القدرة على التحكم في استهلاك الموارد.
محدد معدل هو المسؤول عن هذا.
هناك أجهزة. ولكن كيفية إدارة وتكوين microvirtuals؟ واجهة برمجة تطبيقات الإدارة ستساعدنا هنا.
إدارة
الأمازون لديها العديد من المبادئ الأساسية غير قابلة للكسر. واحد منهم هو أن أي خدمات التواصل مع بعضها البعض فقط من خلال API. لا يهم ما إذا كانت هذه خدمات خارجية تستخدمها كمستخدم أو خدمات داخلية. لا يحدث أن تذهب إحدى الخدمات مباشرةً إلى قاعدة بيانات خدمة أخرى - فهي محظورة ويعاقب عليها. يتم استخدام مؤشر ترابط Firecracker API للتوصل إلى إعدادات ووظائف microvirtuals من خلال REST API.
نلتزم بمواصفات API المفتوحة ، حتى تتمكن من استخدام Swagger.
الفوقية
هناك مثل هذا الترميز الصعب الشر. هذا هو عندما يتم مخيط بعض البيانات مباشرة في التعليمات البرمجية ، على سبيل المثال ، تسجيل الدخول وكلمة المرور للوصول إلى مصدر آخر. هذا ، بالطبع ، غير مسموح به. بشكل دوري ، نحتاج إلى نقل بعض البيانات داخل microvirtual. يتم ذلك من خلال
خدمة البيانات الوصفية .
نقوم بتمرير المعلومات المطلوبة من خلال المقبس إلى تداول بيانات تعريف IMDS. للحصول على هذه المعلومات داخل microvirtual ، تحتاج إلى طلب
http://169.254.169.254/latest/meta-data باستخدام REST API. يعرف مستخدمي AWS هذا IP السحري بالفعل. بنفس الطريقة ، يمكن لـ microvirtuals الحصول على معلومات مفصلة حول التكوين الخاص بهم.
السجلات
لا بد من أن تكون قادرة على رمي سجلات microvirtuals في العالم الخارجي قبل وفاتها. يتم ذلك من خلال نظام يونيكس
FIFO العادي.
عزل إضافي
زائد الرئيسي للجهاز الظاهري في عزلة. يبدو أن هذا ينبغي أن يكون كافيا ، لكننا ذهبنا أبعد من ذلك. فقط في حالة التشغيل في الإنتاج ، يوصى بوضع طبقة إضافية من العزل تسمى
Jailer .
هذه هي الاحتياطات القياسية:
- cgroups للحد من الموارد ؛
- مساحة الاسم لعزل العمليات ؛
- seccomp - تناظرية لجدار الحماية لمكالمات النظام ؛
- وبطبيعة الحال ، chroot المفضل للجميع .
التكامل مع الخدمات الأخرى
هل هناك أي حلول جاهزة تعتمد على Firecracker؟ بالطبع نعم.
OSV
تم تصميم نظام التشغيل هذا لتشغيل تطبيق واحد فقط. وبسبب هذا ، فقد نظمت ببساطة العمل مع الذاكرة وجدولة.
يعمل الآن نظام تشغيل قوي وسهل الإدارة
على قمة Firecracker .
Containerd
نحن أيضا جعل التكامل مع containerd. إذا كنت تعمل معه بالفعل ، فأنت بحاجة إلى الحد الأدنى من الجهد لإطلاق حاويات ملفوفة في Firecracker للعزل.
بدلا من الرقائق المعتادة ، يشير containerd إلى الرقائق Firecracker. يدير بالفعل runc ، من خلال وكيل مثبت داخل microvirtual.
فحص ، يعمل .
حاويات كاتا
عندما أعلنا لأول مرة Firecracker ، كان أحد أكثر أسئلة العملاء شيوعًا:
- تم بالفعل اختراع آلية عزل الحاويات - وهي حاويات كاتا. لماذا لم تستخدمها؟ لماذا تطوير الخاصة بك؟- تعمل Kata مع QEMU ، لكننا لا نريد العمل مع QEMU. لذلك ، قررنا طهي الطعام الخاصة بنا.ولكن اتضح للاهتمام. قابل مطورو Kata مطوري Firecracker ووافقوا على الاندماج. لأن الجميع يرى هذا كإضافة ضخمة.
حاويات Kata v1.5 تدعم كلاً من QEMU و Firecracker.
اتضح أننا لا نتنافس ، ولكننا نكمل بعضنا البعض بشكل متناغم. في Kubernetes بـ v1.12 ، يمكنك تعريف runtimeClassName باسم Kata FC أو Kata QEMU ، وتشغيل حاوياتك في مكان مناسب.
كيفية اختيار العزل الذي يناسب طلبك - Firecracker أو QEMU؟ رأيي الشخصي هو أن ما
يهم هو ما إذا كان التطبيق الخاص بك هو
الحيوانات الأليفة أو الماشية ؟
كاتا مع QEMU هو الحل للحيوانات الأليفة. QEMU هو نظام كبير متعدد الوظائف. من المحتمل ، أنه يوفر المزيد من الدعم والعلاج لخيارات الحيوانات الأليفة المفضلة لديك.
الالعاب النارية هي مناسبة عندما يكون الحمل الماشية. في حالة تصميم التطبيق عديم الجنسية أصلاً من أجل القياس الأفقي المرن وفشل حاوية أو أكثر ليس أمرًا بالغ الأهمية. يوفر عزلًا موثوقًا ، ويسمح لك بسرعة بتحميل العدد المطلوب من الحاويات الجديدة لتحل محل الحاويات الفاشلة.
ما هي النتيجة؟
لقد بدأنا بالتناقضات. يبدو أن حل التناقض هو نهج "نحن ولك" ، وهو أمر يرضي الجميع. لكن التجربة تقول إن التسوية ليست ضرورية.
لقد حددنا لأنفسنا هدف تطوير حل جديد لن يكون فيه شيء غير ضروري غير مطلوب لحل مهمة ضيقة. كان من المهم أيضًا تبسيط كل شيء نستخدمه قدر الإمكان. أود أن أصدق أننا لم نتوصل إلى حل وسط ، ولكن حلاً متينًا يسمح لك بإطلاق الآلاف من الكائنات الحية الدقيقة بسرعة ودون كثرة دون التضحية بعزلتها.
نحن نستخدم بالفعل Firecracker في إنتاج العديد من خدماتنا. الإيجابيات الرئيسية التي حصلنا عليها هي تحسين استخدام الخدمات. هذا يسمح للحفظ بشكل كبير. جزء من هذه المدخرات التي شاركناها مع العملاء. على سبيل المثال ، بعد إدخال Firecracker ، انخفضت أسعار الحاويات بدون خادم AWS Fargate في يناير 2019 بنسبة 35-50 ٪. الفائدة واضحة للعين المجردة ، لذلك لا شك في أننا سنواصل تطوير هذا المنتج ومشاركة أفضل ممارساتنا مع Open Source. حقيقة أن Firecracker قد بدأت بالفعل في الاندماج مع حلول أخرى تشير إلى اهتمام متزايد من جانب المجتمع.
إذا كانت لديك فكرة أو منتج نهائي يوجد في وصفه عبارة "عزلة متعددة المستأجرين" - فهذا مؤشر واضح على ما يجب أن تجربه مع ألعاب Firecracker microvirtuals.
يوضح هذا التقرير تمامًا المبدأ الذي نحاول الالتزام به في مؤتمرات Ontiko - لتلقي الخبرة العالمية من الخبراء الناطقين بالروسية . وهذه النقطة ليست فقط في حاجز اللغة ممكن ، ولكن في الثقافة نحن معتادون على تبادل التفاصيل التقنية. في نوفمبر ، سيعزف فاسيلي على HighLoad ++ مرة أخرى ، وسينضم إليه ، على سبيل المثال ، Artemy Kolesnikov من Facebook ، و Vittorio Cioe من Oracle ، وبطبيعة الحال Petr Zaitsev من Percona. سيكون لدينا أيضًا تقارير باللغة الإنجليزية والاشتراك في النشرة الإخبارية - وسنخبرك بموعد إضافة تقارير جديدة إلى التقارير المقبولة والأربعين.