Tarsnap सेवा बंद होने का पोस्टमॉर्टम

 (mail.tarsnap.com)
1 पॉइंट द्वारा GN⁺ 2023-07-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Tarsnap का केंद्रीय सर्वर Amazon EC2 us-east-1 में failed system status check के साथ डाउन हो गया, और सेवा 2023-07-02 13:07:58 UTC के आसपास से लगभग 26 घंटे 16 मिनट तक बंद रही
  • गड़बड़ी 13:10 UTC पर पकड़ी गई, लेकिन अप्रत्याशित reboot के बाद server code अपने-आप शुरू न हो, ताकि इंसान सीधे जांच करे—यह operational principle लागू था
  • रिकवरी Amazon S3 के log-structured filesystem से metadata headers पढ़कर और स्थानीय रूप से operations को क्रम में replay करके की गई; पहला चरण 2023-07-03 01:49:49 UTC पर पूरा हुआ
  • state reconstruction के दौरान 2014 में लिखे गए machine re-owned handling का एक untested case और resume logic में initialization छूटना सामने आया, और disk throughput limit ने भी recovery धीमी की
  • Tarsnap के पास स्पष्ट SLA नहीं है, लेकिन जिन outages में credit देना उचित लगे उन पर credit देने की policy के तहत, 2023-07-13 को सभी accounts में एक महीने की storage cost का 50% credit दिया गया

गड़बड़ी की शुरुआत और शुरुआती प्रतिक्रिया

  • 2023-07-02 13:07:58 UTC के आसपास Tarsnap का central server Amazon EC2 us-east-1 region में offline हो गया
    • EC2 status failed system status check था
    • virtual machine में यह status power outage, physical server hardware failure, EC2 network failure जैसे कई कारणों की ओर इशारा कर सकता है
    • उसी समय बड़े पैमाने पर EC2 outage reports नहीं दिखीं, इसलिए isolated hardware failure की संभावना सबसे ज्यादा मानी गई
  • monitoring ने 2023-07-02 13:10 UTC पर outage detect किया
    • दूसरे EC2 region से हर 5 मिनट में archive write, read, delete करके monitoring की जाती थी
    • 13:10 UTC का text alert जगा नहीं सका, लेकिन 13:15 UTC के phone alert से response शुरू हुआ
    • शुरुआती जांच में कोई साफ transient error नहीं दिखा, इसलिए माना गया कि system dead है और वैकल्पिक EC2 instance तैयार करना शुरू किया गया

automatic restart से बचने का operational principle

  • 2023-07-02 13:52 UTC के आसपास Amazon ने affected server को नए EC2 instance पर restart किया
    • यह outage शुरू होने के लगभग 45 मिनट बाद था
    • operating system FreeBSD boot हो गया, लेकिन Tarsnap server code automatically start नहीं हुआ
  • automatic start बंद रखने की वजह यह थी कि unexpected reboot के बाद traffic लेने से पहले state को manually verify किया जा सके
    • operational principle के अनुसार, “कुछ टूटने पर data loss रोकना” “service availability maximize करने” से ज्यादा महत्वपूर्ण है
  • reboot के बाद server logs में filesystem corruption दिखा
    • माना गया कि outage की वजह ने hardware को kill किया था, या filesystem रखने वाले Elastic Block Store और server के connection को काट दिया था
    • existing server recover करने के बजाय नया server setup जारी रखने का फैसला किया गया

S3 log structure और recovery procedure

  • Tarsnap service data को Amazon S3 में log-structured filesystem के रूप में store करती है
    • हर S3 object में सभी log entries के metadata वाला header और optionally log entry data शामिल होता है
    • start write transaction log entry में machine और transaction nonce identify करने वाला केवल header होता है, log data नहीं होता
    • store data block log entry में machine और block name identify करने वाला header और block data दोनों होते हैं
  • normal state में log entry metadata EC2 में cache रहता है, और Amazon S3 से दोबारा नहीं पढ़ा जाता
    • Amazon S3 read केवल tarsnap client requests के जवाब में block data पढ़ते समय होता है
  • EC2 instance state recovery दो चरणों में बांटी गई
    • पहले S3 से सभी metadata headers पढ़े गए
    • इसके बाद सभी operations को local रूप से replay किया गया
    • log-structured storage में data delete करते समय storage space free करने के लिए log entries फिर से लिखी जाती हैं, इसलिए दोनों चरण साथ-साथ नहीं किए जा सकते
    • log entries में sequence number होता है, जिससे उन्हें सही क्रम में replay किया जा सकता है, लेकिन search के बाद पहले sort करना जरूरी है

recovery के दौरान सामने आई खामियां और bottleneck

  • पहला चरण बिना समस्या के चला और 2023-07-03 01:49:49 UTC पर पूरा हुआ
    • recovery process को Amazon S3 पर 250 concurrent requests भेजने के लिए configured किया गया था
    • यह value 10 साल पहले Amazon S3 जिस स्तर को संभाल सकता था, उसके हिसाब से set की गई थी, और अब संभवतः इसे काफी बढ़ाया जा सकता था
  • दूसरा चरण लगभग तुरंत fail हो गया
    • error आया कि replayed log entry ऐसे machine से जुड़े data को record कर रही है जो exist नहीं करती
    • कारण 2014 में लिखा गया machine account transfer handling code था
    • जब Tarsnap users को machine को accounts के बीच move करना होता था, तो नया machine registration log entry store करने और पुराना entry delete करने का तरीका इस्तेमाल होता था
    • tests थे, लेकिन उस case की कमी थी जिसमें data store होने के बाद machine re-owned हो और फिर server state recreate की जाए
    • नए machine registration log entry का sequence number ज्यादा था, इसलिए replay process में ऐसा दिखा जैसे data ऐसी machine में store हुआ है जो अभी exist नहीं करती
  • root cause समझने के बाद उस “seatbelt” को disable किया गया और state reconstruction resume किया गया
    • इसके तुरंत बाद Amazon S3 में data नहीं मिलने का error आया
    • resume attempt में S3 data download step skip करते समय maximum log entry sequence number value initialize नहीं हुई और 0 ही रह गई थी
    • इस समस्या को fix करने के बाद state reconstruction normal रूप से आगे बढ़ा
  • state reconstruction जरूरत से ज्यादा धीमा चला
    • अगर पता होता कि disk throughput bottleneck है, तो संबंधित EBS volume का throughput ज्यादा set किया जा सकता था
    • नींद की कमी के कारण process को closely monitor नहीं किया जा सका; अन्यथा gstat(8) और Amazon CloudWatch में bottleneck देखकर EBS volume reconfigure किया जा सकता था

सेवा फिर शुरू होना और credit देना

  • 2023-07-03 15:10 UTC के आसपास state reconstruction process पूरा हुआ
    • exact completion time record नहीं किया गया
    • server को read-only mode में रखकर quick test किए गए
    • existing server state से तुलना करके verify किया गया कि outage के समय existing server filesystem ने जो आखिरी कुछ seconds का data खोया था, उसे छोड़कर state match कर रही है
  • outage के बाद पहला real service traffic 2023-07-03 15:25:58 UTC पर आया
    • यह outage शुरू होने के लगभग 26 घंटे 16 मिनट बाद था
  • Tarsnap के पास स्पष्ट SLA नहीं है, लेकिन जिन outages में credit देना fair लगे, उनके लिए credit देने की policy लागू करता है
    • 2023-07-13 को सभी Tarsnap accounts में एक महीने की storage cost का 50% credit दिया गया
    • outage handling और rest के बाद credit processing की गई

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-07-28
Hacker News टिप्पणियां

  • सच में मुझे उम्मीद नहीं थी कि यह लेख HN के टॉप पर पहुंच जाएगा। सवालों के जवाब देना चाहता हूं, लेकिन अभी रात के 10 बज रहे हैं, और बच्चा शाम 5 बजे ही सो गया था, इसलिए अगर किस्मत अच्छी रही तो उसके जागने से पहले लगभग 4 घंटे सो पाऊंगा
    सुबह फिर देखूंगा और सवालों के जवाब दूंगा

    • जानना चाहता हूं कि restic की जगह यह सेवा इस्तेमाल करने की वजह क्या है। Colin का आभार, लेकिन इस लेख को देखकर लगता है कि इस सेवा का इन्फ्रास्ट्रक्चर इंचार्ज असल में लगभग एक ही व्यक्ति है
      यह साफ बताना अच्छा है कि कोई SLA नहीं है, लेकिन ऐसा लगता है कि मेरे बैकअप और मेरे बीच एक बड़ा जोखिम आ गया है
    • अगर आगे फिर कोई पोस्टमॉर्टम लिखना पड़े—उम्मीद है बहुत कम या बिल्कुल नहीं—तो अच्छा होगा कि सीखी गई बातें साफ-साफ लिखी जाएं, ताकि दिखे कि कौन-सी चीज क्यों दोबारा नहीं होगी
    • वाकई बहुत अच्छी तरह लिखा गया और विचारशील पोस्टमॉर्टम है, लेकिन उम्मीद है कि ऐसा लेख फिर कभी देखने को न मिले :)
    • अब बच्चे को 24 घंटे सपोर्ट संभालने का समय आ गया है ;)
      https://www.amazon.com/No-Cry-Sleep-Solution-Toddlers-Presch... पढ़ रहा हूं और कुछ हद तक फायदा दिख रहा है। यह किसी भी लाइब्रेरी में मिल सकती है—यानी किताबों के लिए Blockbuster जैसी जगह
    • जिज्ञासा है कि ट्रांजैक्शन लॉग फिर से लिखे जाने से पहले कितने समय तक रखे जाते हैं
      पिछले कुछ हफ्तों में मेरे भी कुछ EC2 इंस्टेंस ऐसे लक्षणों के साथ डाउन हुए जैसे वे EBS से कट गए हों, और मेरे मामले में यह eu-west में हुआ था

  • “Tarsnap में SLA नहीं है, लेकिन अगर उचित लगे तो आउटेज के लिए क्रेडिट देता है” जैसी अस्पष्ट नीति के तहत, 2023-07-13 को सभी के Tarsnap खातों में एक महीने के स्टोरेज खर्च का 50% क्रेडिट किया गया—यह हिस्सा अच्छी तरह दिखाता है कि Percival किस तरह के व्यक्ति हैं
    यह क्रेडिट ग्राहकों को पर्याप्त मुआवजा देने के लिहाज से काफी उदार लगता है, और बड़े cloud providers के उलट, हर ग्राहक को अलग से आकर गुहार लगाने के लिए भी मजबूर नहीं किया गया। ऊपर से स्पष्ट, तकनीकी और विस्तृत पोस्टमॉर्टम भी था। मेरी राय में हर जगह ऐसा ही होना चाहिए

    • “अंधेरे में lighthouse बनने के लिए धन्यवाद” वाली अभिव्यक्ति बिल्कुल सही है
      ऐसी दुनिया में रहना काफी खुशी की बात है जहां Tarsnap मौजूद है और कीमतें picodollars में तय होती हैं

  • अगर डिजास्टर रिकवरी प्रक्रिया ठीक से सेटअप और टेस्ट की गई होती, तो downtime काफी कम किया जा सकता था
    एक पूरी तरह अलग staging system बनाना, उसे गिराकर फिर से बना पाना, अलग-अलग failure modes को नियमित रूप से टेस्ट करना, और system recovery की सारी विस्तृत प्रक्रियाओं को document करना जरूरी है
    लंबे समय में revenue बढ़ाकर ऐसा part-time staff रखने पर भी सोचा जा सकता है, जो ऐसी स्थिति आने पर बहुत मददगार होगा
    हम भी एक छोटे cloud solutions provider हैं और ML API पर focus करते हैं, और साल दर साल यह साफ होता गया है कि cloud hardware इस्तेमाल करने पर—चाहे dedicated हो या virtual—failures समय-समय पर आते ही हैं। RAM, HDD या दूसरे hardware components कभी भी fail हो सकते हैं, इसलिए long-term में high-availability online service चलाते समय इसे 100% ध्यान में रखना चाहिए

  • ईमानदार पोस्टमॉर्टम और कठिन स्थिति को अच्छे से संभालने के लिए सम्मान। हालांकि नींद की कमी के बारे में, अगर समस्या ठीक कर सकने वाला व्यक्ति सिर्फ एक ही है, तो थोड़ा extra outage time स्वीकार करके साफ दिमाग हासिल करने में शर्म नहीं करनी चाहिए
    alerts बजते हुए थोड़ी देर सोने जाना अजीब लगता है, लेकिन adrenaline और कम नींद मिलकर समस्या को और बिगाड़ना बहुत आसान बना देते हैं

    • चिंता की जरूरत नहीं, बीच-बीच में मैंने कुछ naps लिए थे। “यह ठीक चलता दिख रहा है, लेकिन कुछ घंटे और लगेंगे, तो alarm 2 घंटे बाद का लगाकर थोड़ा सो लेना चाहिए” यही उन कारणों में से एक था कि मैं यह नहीं समझ पाया कि दूसरा चरण बेवजह I/O bottleneck में फंसा हुआ है

  • विवरण से देखें तो यह recovery process नियमित रूप से टेस्ट करना अपेक्षाकृत आसान लगता है, और बचे हुए bugs पकड़ने या recovery time का आकलन करने में मदद कर सकता है
    जैसा अक्सर कहा जाता है, सिर्फ वही backup असली backup है जिसे test किया गया हो

    • अपनी disaster recovery process टेस्ट करने के बाद ही मुझे पता चला कि वह काम नहीं करती—इस अनुभव के आधार पर 100% सहमत हूं। वास्तव में काम करने की संभावना वाला plan वही है जो repeatable और tested हो
    • सही। कुछ समय से करना चाहता था, लेकिन हमेशा कोई और काम ज्यादा प्राथमिकता वाला होता था। इस outage से पहले मुझे एहसास ही नहीं था कि मैंने लगभग 10 साल तक टेस्ट नहीं किया था
      आगे से हर साल rehearsal करना निश्चित रूप से high priority में रखूंगा

  • इस तरह का professional, विनम्र और ईमानदार पोस्टमॉर्टम देखना हमेशा अच्छा लगता है

  • यह पुराने Tarsnap कंपनी-जानकारी के आधार पर कहा जा रहा हो सकता है, लेकिन मुझे Tarsnap को गंभीरता से इस्तेमाल करने से रोकने वाला इकलौता कारण अप्रत्याशित Colin Percival outage, यानी key-person risk था
    मुझे नहीं लगता कि मैं अकेला हूँ

    • यह mean time between failures की गणना जैसा ही है। सवाल यह है कि क्या आप कम moving parts और अच्छी तरह डिज़ाइन की गई one-person company के well-designed solution पर भरोसा करेंगे, या बहुत बड़ी कंपनी पर, जिसके moving parts कहीं ज़्यादा हैं और शायद solution कम अच्छी तरह डिज़ाइन किया गया है
      निजी तौर पर मैं सरल समाधान चुनूँगा। मेरे अनुभव में, simple system जैसी reliability तक पहुँचने के लिए बहुत भारी अतिरिक्त complexity चाहिए, और ज़्यादातर complexity हालात को और खराब ही करती है
      server clustering में यह बात साफ दिखती है। भरोसेमंद power और network वाला एक single server, उस service को redundant बनाने की किसी भी कोशिश से ज़्यादा reliable होता है, जब तक कि cost और complexity लगभग 5 गुना बढ़ने के स्तर तक न पहुँच जाए। उसी के आसपास जाकर single server जैसा mean time between failures मिलता है, और उसके बाद ही असली सुधार संभव होता है
      मेरा मजबूत विश्वास है कि वास्तविक reliability की सबसे अच्छी राह जितनी संभव हो उतनी simplicity और अच्छे backups हैं। अगर 24/7 availability चाहिए, तो चुनने लायक technologies काफी सीमित हो जाती हैं
    • मैं समझता हूँ कि यह risk है, लेकिन मुझे यकीन नहीं कि यह बड़ी कंपनियों से अनिवार्य रूप से ज़्यादा जोखिम भरा है
      यह Colin का काम है, Colin का नाम इस पर लगा है, और Colin के लिए यह बहुत महत्वपूर्ण है
      BigBackupCorp में आपको इसी तरह की service मिलना मुश्किल है। employee भी replaceable है, management भी replaceable है, और सच कहें तो ग्राहक के रूप में मैं भी replaceable हूँ, अगर company दिशा बदलकर BigFlowerArrangementShippingCorp बनने का फैसला कर ले
      छोटे business की अच्छी बात यह है कि वे पूरी तरह self-interest पर चलते हैं। stock-price games या VC-style tricks जैसी चीज़ें नहीं होतीं। अगर business profitable है, तो कोई आकर उसे acquire कर सकता है, अपना नाम लगाकर उसे अपना काम बना सकता है। मुझे लगता है open internet को ऐसी चीज़ों से बड़ा फायदा होता है
    • Tarsnap से पहले गायब हो चुके competitors की सूची बनाकर देखें, तो calculation थोड़ा बदल सकता है। आंका जाने वाला risk “operator को कुछ हो गया तो?” नहीं, बल्कि “उसे कुछ हो जाए, service भी down हो जाए, और मैंने backup का backup भी न किया हो तो?” होना चाहिए
      सावधानी से planning करके इस risk को जितना चाहें उतना छोटा बनाया जा सकता है
    • अगर आप HN देख रहे हैं, तो Colin को कुछ हुआ है यह बात शायद 24 घंटे के अंदर पता चल जाएगी। व्यावहारिक रूप से, नए backup provider पर जाने से पहले के लगभग 24-hour window में primary storage, Tarsnap और Colin—तीनों को एक साथ fail होना पड़ेगा, तभी सच में समस्या होगी
    • मैं किसी backup provider पर उससे ज़्यादा भरोसा करने वाला नहीं हूँ। क्योंकि जिस पल आप depend करेंगे, वह सबसे मुश्किल समय पर fail होगा
      Tarsnap जैसी service को कई layers में से एक रखना, multi-layer backup बनाना और नियमित रूप से verify करना बेहतर है

  • replay किए गए log entry में ऐसी machine का data record हो रहा है जो मौजूद नहीं है—ऐसी error शायद TLA+ model लिखने पर पकड़ी जा सकती है

  • restic+backblaze जैसे combination का इस्तेमाल करने पर cost कई orders of magnitude कम हो जाती है, इसलिए मैं जानना चाहता हूँ कि Tarsnap इस्तेमाल करने का फायदा क्या है। कौन-सी specific need होनी चाहिए जिससे कोई प्रति TB-year 3000 डॉलर देने के लिए motivated हो, यह समझ नहीं आता

    • हममें से कुछ के पास काफी extra पैसा है, और हमें cperciva को किसी खराब job में काम न करने देने, बल्कि अपनी skill और talent को बड़े और बेहतर कामों में लगाने के लिए पैसे देने का बहाना पसंद है
      जो लोग bus factor कम होने की बात पूछते हैं, उनसे कहूँगा: आप backups को सिर्फ एक service या एक location पर तो नहीं रखेंगे, है ना? आप Tarsnap के साथ Restic+Backblaze, Rsync.net, S3 आदि भी इस्तेमाल करेंगे, है ना? “backup वह tax है जो recovery की luxury पाने के लिए चुकाया जाता है”
    • deduplication बहुत अच्छी तरह होती है, इसलिए जिस बेहद महत्वपूर्ण core data set का मैं Tarsnap पर backup लेता हूँ, उसकी cost नगण्य है। अगर data ज़्यादा बार बदलता, तो calculation अलग हो सकता था
      उदाहरण के लिए, videos और photo library के लिए मैं दूसरी services इस्तेमाल करता हूँ, लेकिन accounting database और महत्वपूर्ण documents आदि का backup Tarsnap पर करता हूँ
      मैं 10 साल से Tarsnap इस्तेमाल कर रहा हूँ, और availability issue लगभग नहीं रहे; जहाँ तक याद है, किसी भी तरह की problems भी लगभग नहीं हुईं

  • 26 घंटे के downtime का अधिकांश हिस्सा backup restore में लगा लगता है। संयोग से, यही वह exact वजह है कि मैं production environment में Tarsnap इस्तेमाल नहीं कर सकता
    user के नजरिए से backup restore दर्दनाक रूप से slow है। जब मेरा system offline हो, तो backup service की वजह से कई घंटे इंतज़ार करने का धैर्य मुझमें नहीं है। अब शायद बेहतर हो गया हो, लेकिन कुछ साल पहले जब आखिरी बार इस्तेमाल किया था, तो कुछ GB backup restore करने में लगभग घंटे भर के order में समय लगा था