Meta Linux को बड़े पैमाने पर कैसे patch करता है

• Linux server को patch करना आसान है, लेकिन बिना downtime के दसियों हज़ार server को patch करना आसान नहीं है
• Meta लाखों Linux server को patch करने के लिए Red Hat के Kpatch और KLP(Kernel Live Patching) का उपयोग करता है
  • KLP बिना reboot किए Linux kernel पर नवीनतम security update लागू कर सकता है

Live kernel patching

• Live kernel patching मुख्य kernel package से अलग, संशोधित code वाले package के रूप में दिया जाता है
• Live patch cumulative होते हैं, इसलिए नवीनतम patch में पिछले patch के सभी fixes शामिल होते हैं
• Live patch हर चीज़ पर लागू नहीं होते; data या structure को patch नहीं किया जा सकता, और live patch बनाने के लिए अतिरिक्त engineering काम की ज़रूरत होती है

Kpatch

• Kpatch मूल kernel और patched kernel की तुलना करता है, फिर custom kernel module का उपयोग करके चल रहे kernel में नया code patch करता है
• इसके बाद Kpatch process ftrace का उपयोग करके मौजूदा process के stack की निगरानी करता है, ताकि यह सुनिश्चित किया जा सके कि patch बिना हानिकारक प्रभाव के लागू किया जा सकता है
• यदि इसे सुरक्षित माना जाता है, तो यह चल रहे code को patched function की ओर redirect करता है और फिर पुराने code को हटा देता है
• अब server पर patch लागू हो चुका होता है और कोई downtime नहीं होता

Meta के मामले में

• बेशक, वास्तविकता में यह इतना सरल नहीं है
• Meta में live patch लागू करते समय आमतौर पर host पर patch लगाने में 1–2 second लगते हैं
• एक host पर 1–2 second का समय, Linux kernel के उस mechanism kexec की तुलना में वास्तव में तेज़ है जो नया kernel boot करता है
• इसमें downtime या workload migration की ज़रूरत नहीं होती; live patch लागू करते ही इसे तुरंत उपयोग किया जा सकता है

लाखों मशीनों को patch करने का तरीका

• लाखों मशीनों को patch करते समय कहानी यहीं खत्म नहीं होती
• Meta में patch rollout के दौरान bug मिल सकते हैं, इसलिए admin पहले release candidate tier पर patch लागू करते हैं
• RPM-based patch देने वाला package roller server की health भी अपने आप जांचता है
• Meta नए kernel में crash, major alert, application issue और performance की निगरानी करता है, और अगर error rate 1000 server पर 1 crash से ऊपर चला जाए तो patch रोक दिया जाता है और पिछले kernel पर restore कर दिया जाता है
• Meta Kpatch का उपयोग करता है, लेकिन दूसरे विकल्प भी मौजूद हैं
  • SUSE kGraft देता है, Oracle Ksplice का उपयोग करता है, और Canonical Livepatch को support करता है
  • code चाहे जैसा भी हो, सभी लगभग समान परिणाम देते हैं

GN⁺ की राय

इस लेख की सबसे महत्वपूर्ण बात यह है कि Meta ने दुनिया भर में लाखों server के लिए बिना downtime के एक कुशल patching तरीका लागू किया है। यह शुरुआती software engineer के लिए भी एक दिलचस्प विषय है और Linux system के maintenance और security के महत्व को रेखांकित करता है। साथ ही, यह लेख live patching तकनीक की जटिलता और आवश्यकता को समझने में मदद कर सकता है।

[GN⁺]

Hacker News राय

• Ksplice वह मूल live patching तकनीक है जिसे Oracle द्वारा अधिग्रहित किए जाने के बाद, जब मैं वहाँ काम कर रहा था, user-space programs तक बढ़ाया गया था. cloud की ओर शिफ्ट के बावजूद यह बहुत शानदार तकनीक है, क्योंकि बड़े पैमाने पर भी पूरे सिस्टम को restart करने की ज़रूरत नहीं पड़ती, इसलिए यह पुरानी नहीं हुई.
• यह कि Meta ने यह नहीं बताया कि इस तरीके से पूरे deployment में कितना समय लगता है, एक महत्वपूर्ण विवरण छूटने जैसा लगता है. live patching का उपयोग करने से servers, data centers और cloud में downtime के बिना संचालन किया जा सकता है.
• अगर आप Meta जैसे scale पर काम करते हैं, तो live patching समझ में आ सकता है, लेकिन ज़्यादातर अच्छी तरह डिज़ाइन की गई services और applications को server के full reboot को आसानी से सहन कर पाना चाहिए. लाखों servers को मैनेज करने की जटिलता की कल्पना करना मुश्किल है.
• KernelCare kernel live patching के लिए एक service है जो अधिकांश Linux distributions को support करती है.
• मैंने कई virtual machines पर Kpatch का उपयोग किया है, और यह काफ़ी अच्छी तरह काम करता है.
• अभी लगभग 1.3 करोड़ servers चलाए जा रहे हैं, और 2023 में नए data center equipment पर 20 अरब डॉलर तथा 2024 में अतिरिक्त 20 अरब डॉलर खर्च करने की योजना है. अभी CentOS 8 Stream इस्तेमाल हो रहा है, और जल्द ही 9 पर जाने की योजना है.
• कहा जाता है कि hosts का draining और undraining मुश्किल है. इसका मतलब मूलतः यह है कि service से hosts को drain करके फिर बहाल करना आसान नहीं है, और यह दिखाता है कि Linux kernel live patching के लिए डिज़ाइन नहीं किया गया था; इसे आज़माना हमेशा अनिश्चितता का स्रोत रहता है, engineering effort के लिहाज़ से महँगा पड़ता है, और disaster हमेशा सिर पर मंडराता रहता है. दूसरी ओर, hosts के लिए service draining और recovery system को बदलकर उसे बहुत मज़बूत और विश्वसनीय बनाना reliability के लिहाज़ से बड़ा फ़ायदा देगा. यह approach संगठन की dysfunction को ढकने जैसा लगता है. एक team सभी kernels को patch कर सकती है, लेकिन सभी hosts को service draining और recovery support करने लायक बनाना संभव नहीं होता, और इसे ठीक करने के लिए वास्तविक incentive न होने से कोई इसे ठीक करने की कोशिश नहीं करता. सिर्फ़ शानदार hacks और नए projects को ही सही मायने में इनाम मिलता है.
• अधिकांश organizations को Meta की नकल करने से फ़ायदा नहीं होगा, और उन्हें ऐसा करने की ज़रूरत भी नहीं है.
• मैंने पहली बार "hyperscale" की अवधारणा सुनी है. यह साधारण scaling से कैसे अलग है, यह जानने की जिज्ञासा है.