Firecracker को QEMU से बदलने की वजह

• Hocus (self-hosted GitPod/GitHub Codespaces का विकल्प) ने Firecracker को QEMU से बदल दिया

Firecracker कम समय के लिए चलकर बंद हो जाने वाले workloads के लिए ऑप्टिमाइज़ किया गया है

• AWS Lambda में इस्तेमाल होने वाला हल्का, तेज़ और सुरक्षित microVM hypervisor
• लेकिन यह उतना भी हल्का नहीं है
  • यह लंबे समय तक चलने वाले workloads के लिए ज़रूरी "dynamic RAM management" फीचर नहीं देता। एक बार allocate की गई RAM को host को वापस नहीं करता
  • storage को host को वापस लौटाने की सुविधा भी नहीं है। VM के अंदर बड़ी फ़ाइल बनाकर delete कर देने पर भी host को खाली space वापस नहीं मिलता। पूरे VM drive को delete करने तक वह जगह घिरी रहती है
  • GPU support नहीं है, और high-performance disk IO भी नहीं मिलता

QEMU भी परफेक्ट नहीं है

• configure करने के लिए बहुत कुछ है
• unused RAM वापस दिलाने के लिए host को 3 चुनौतियाँ हल करनी पड़ती हैं
  • पहले यह जानना कि ऐसा फीचर मौजूद है (इसे free page reporting कहा जाता है, और इसे manually enable करना पड़ता है)
  • Linux के DAMON फीचर को समझना, उसका उपयोग और configuration जानना, और उसे support करने वाला Linux kernel compile करना
  • guest में Transparent Huge Pages का उपयोग बंद करना पड़ता है, वरना VM बड़ी मात्रा में memory वापस नहीं करता
• इसे test deployment तक लाने में 2 महीने लगे
  • Firecracker/QEMU code पढ़ना,
  • DAMON configure करने के लिए developers के साथ email भी करनी पड़ी
    → (DAMON के developer दक्षिण कोरिया के Park Seongjae हैं.)

निष्कर्ष

• QEMU में general-purpose workloads चलाने के लिए ज़रूरी फीचर्स हैं
• लेकिन configuration के लिए समय और धैर्य चाहिए
• Short-lived, Untrusted Workload के लिए Firecracker एक अच्छा विकल्प है
• लेकिन अगर आप अपना development environment VM पर चलाना चाहते हैं, तो Hocus का उपयोग कर सकते हैं (कठिन काम हम पहले ही कर चुके हैं)

[tujuc]

अपने प्रोडक्ट का परिचय देना अच्छी बात है, लेकिन यह सोच भी आती है कि AWS services को बस सीधे इस्तेमाल करना ही बेहतर है.. ssssut जी की बात की तरह, यह ऐसी service है जो fargate में भी चलती है, इसलिए मुझे नहीं लगता कि मामला उस हद तक जाता है।

मेमोरी वापस न करने में समस्या क्या है, यह अभी भी मुझे पूरी तरह समझ नहीं आ रहा। CPU में contention हो जाए तो application धीमी तो पड़ सकती है, लेकिन चलने में समस्या नहीं होती; मगर memory का तो कोई जवाब ही नहीं है...

[ssssut]

अतिरिक्त: AWS Lambda के अलावा, लंबे समय तक चलने वाले ECS Fargate में भी Firecracker का उपयोग किया जा रहा है।

[GN⁺]

Hacker News की राय

• Firecracker का उपयोग CodeSandbox में development environments होस्ट करने के लिए किया जाता है, लेकिन मेरा मानना है कि इसका उपयोग लंबे समय तक चलने वाले workloads के लिए भी किया जा सकता है.
• QEMU में Firecracker से प्रेरित microvm नाम का एक target है, जो PCI या ACPI support के बिना एक न्यूनतम machine type है, और कम समय के लिए चलने वाले guests के लिए डिज़ाइन किया गया है.
• Cloud-hypervisor, Firecracker जैसा एक और विकल्प है, जो memory reclamation और अन्य features को support करता है.
• Firecracker में एक balloon device है जो host system से memory reclaim करने के लिए फैल और सिकुड़ सकता है.
• यह लेख Firecracker की सीमाओं का ज़िक्र करता है, लेकिन QEMU के बारे में ज़्यादा जानकारी नहीं देता.
• लंबे समय तक चलने वाली processes होस्ट करने के लिए Fly, Firecracker का उपयोग करता है.
• मैं चाहता हूँ कि VM host के साथ और अधिक स्मार्ट तरीके से integrate हों, जिसमें block cache deduplication और zero-copy integration शामिल हैं.
• QEMU, Firecracker के विपरीत, volumes को bind mount कर सकता है, लेकिन यह एक security risk हो सकता है.