Tarsnap hizmet kesintisi olay sonrası analizi

• Tarsnap merkezi sunucusu, Amazon EC2 us-east-1 üzerinde failed system status check nedeniyle devre dışı kaldı ve hizmet 2023-07-02 13:07:58 UTC civarından itibaren yaklaşık 26 saat 16 dakika kesintiye uğradı
• Arıza 13:10 UTC’de tespit edildi, ancak beklenmeyen bir yeniden başlatmadan sonra sunucu kodunun otomatik başlatılmasını kapalı tutan ve insan tarafından elle kontrol yapılmasını öngören operasyon ilkesi uygulandı
• Kurtarma, Amazon S3’teki log-structured dosya sisteminden metadata header’larını okuyup işlemleri yerelde sırayla yeniden oynatma yöntemiyle yürütüldü; ilk aşama 2023-07-03 01:49:49 UTC’de tamamlandı
• Durumun yeniden oluşturulması sırasında 2014’te yazılmış machine re-owned işleme mantığında test edilmemiş bir durum ve devam ettirme mantığında başlatma eksikliği ortaya çıktı; disk throughput sınırı da kurtarmayı yavaşlattı
• Tarsnap’in açık bir SLA’i olmasa da adil bulduğu kesintiler için kredi verme politikası kapsamında, 2023-07-13’te tüm hesaplara bir aylık depolama ücretinin %50’si kadar kredi tanımlandı

---

Kesintinin başlaması ve ilk müdahale

• 2023-07-02 13:07:58 UTC civarında Tarsnap’in merkezi sunucusu Amazon EC2 us-east-1 bölgesinde çevrimdışı oldu
  • EC2 durumu failed system status check idi
  • Sanal makinede bu durum elektrik kesintisi, fiziksel sunucu donanım arızası, EC2 ağ arızası gibi çeşitli nedenlere işaret edebilir
  • Aynı anda geniş çaplı bir EC2 arızası raporu görünmüyordu; en olası nedenin izole bir donanım arızası olduğu düşünüldü
• İzleme sistemi arızayı 2023-07-02 13:10 UTC’de tespit etti
  • Başka bir EC2 bölgesinden her 5 dakikada bir arşive yazma, okuma ve silme yaparak izleme gerçekleştiriliyordu
  • 13:10 UTC’deki SMS bildirimi uyandırmadı, ancak 13:15 UTC’deki telefon bildirimiyle müdahale başladı
  • İlk incelemede belirgin bir geçici hata görülmediği için sistemin öldüğü kabul edildi ve yedek EC2 instance’ı hazırlanmaya başlandı

Otomatik yeniden başlatmadan kaçınma ilkesi

• 2023-07-02 13:52 UTC civarında Amazon, arızalı sunucuyu yeni bir EC2 instance’ında yeniden başlattı
  • Bu, arızanın başlamasından yaklaşık 45 dakika sonraydı
  • İşletim sistemi FreeBSD ayağa kalktı, ancak Tarsnap sunucu kodu otomatik olarak başlatılmadı
• Otomatik başlatmanın kapalı tutulmasının nedeni, beklenmeyen bir yeniden başlatmanın ardından trafik kabul etmeden önce durumu elle kontrol etmekti
  • Operasyon ilkesi gereği “bir şey bozulduğunda veri kaybını önlemek”, “hizmet erişilebilirliğini en üst düzeye çıkarmaktan” daha önemliydi
• Yeniden başlatmadan sonra sunucu loglarında dosya sistemi bozulması görüldü
  • Arızanın nedeninin donanımı devre dışı bıraktığı veya dosya sistemini barındıran Elastic Block Store ile sunucu arasındaki bağlantıyı kopardığı düşünüldü
  • Mevcut sunucuyu kurtarmak yerine yeni sunucunun yapılandırılmasına devam edilmeye karar verildi

S3 log yapısı ve kurtarma prosedürü

• Tarsnap hizmeti verileri Amazon S3’te log-structured dosya sistemi olarak saklar
  • Her S3 nesnesi, tüm log girdilerinin metadata’sını içeren bir header ve isteğe bağlı olarak log girdisi verilerini içerir
  • start write transaction log girdisi yalnızca makineyi ve transaction nonce’unu tanımlayan bir header’a sahiptir; log verisi içermez
  • store data block log girdisi, makineyi ve blok adını tanımlayan bir header ile birlikte blok verisini içerir
• Normal durumda log girdisi metadata’sı EC2’de cache’lenir ve Amazon S3’ten yeniden okunmaz
  • Amazon S3 okumaları yalnızca tarsnap istemci isteklerine yanıt olarak blok verisi okunurken gerçekleşir
• EC2 instance durumunun kurtarılması iki aşamaya ayrılır
  • Önce S3’ten tüm metadata header’ları okunur
  • Ardından tüm işlemler yerelde yeniden oynatılır (replay)
  • Log-structured depolamada veri silindiğinde depolama alanı açmak için log girdileri yeniden yazıldığından, iki aşama aynı anda yürütülemez
  • Log girdilerinde sıra numarası bulunduğu için doğru sırada yeniden oynatılabilirler, ancak alındıktan sonra önce sıralanmaları gerekir

Kurtarma sırasında ortaya çıkan kusurlar ve darboğazlar

• İlk aşama sorunsuz ilerledi ve 2023-07-03 01:49:49 UTC’de tamamlandı
  • Kurtarma süreci Amazon S3’e eşzamanlı 250 istek gönderecek şekilde yapılandırılmıştı
  • Bu değer, 10 yıl önce Amazon S3’ün kaldırabildiği seviyeye göre ayarlanmıştı ve bugün çok daha fazla artırılabilmesi muhtemeldi
• İkinci aşama neredeyse hemen başarısız oldu
  • Yeniden oynatılan log girdisinin var olmayan bir makineye ait veriyi kaydettiğini belirten bir hata oluştu
  • Neden, 2014’te yazılan makine hesabı taşıma işleme koduydu
  • Bir Tarsnap kullanıcısının bir makineyi hesaplar arasında taşıması gerektiğinde yeni bir machine registration log girdisinin saklanması ve eski girdinin silinmesi yöntemi kullanılıyordu
  • Testler vardı, ancak veri depolanmış durumdayken makine re-owned edildikten sonra sunucu durumunun yeniden oluşturulması senaryosu eksikti
  • Yeni makine kayıt log girdisinin sıra numarası daha yüksek olduğundan, yeniden oynatma sırasında verinin henüz var olmayan bir makineye kaydedildiği görülüyordu
• Neden anlaşıldıktan sonra söz konusu “seatbelt” devre dışı bırakıldı ve durum yeniden oluşturma işlemi sürdürüldü
  • Kısa süre sonra Amazon S3’te verinin bulunamadığını belirten bir hata oluştu
  • Devam ettirme denemesinde S3 verisi indirme aşaması atlandığı için maximum log entry sequence number değeri başlatılmamış ve 0 olarak kalmıştı
  • Bu sorun düzeltildikten sonra durum yeniden oluşturma normal şekilde devam etti
• Durum yeniden oluşturma, gerekenden daha yavaş ilerledi
  • Disk throughput’unun darboğaz olduğu bilinseydi ilgili EBS volume’unun throughput’u daha yüksek ayarlanabilirdi
  • Uykusuzluk nedeniyle süreç yakından izlenemedi; aksi halde gstat(8) ve Amazon CloudWatch üzerinden darboğaz görülebilir ve EBS volume’u yeniden yapılandırılabilirdi

Hizmetin yeniden başlaması ve kredi verilmesi

• 2023-07-03 15:10 UTC civarında durum yeniden oluşturma süreci tamamlandı
  • Kesin tamamlanma zamanı kaydedilmedi
  • Sunucu salt okunur modda bırakılarak hızlı testler yapıldı
  • Mevcut sunucu durumuyla karşılaştırılarak, arıza anında mevcut sunucu dosya sisteminin kaybettiği son birkaç saniyelik veri dışında eşleştiği doğrulandı
• Arızadan sonraki ilk gerçek hizmet trafiği 2023-07-03 15:25:58 UTC’de gerçekleşti
  • Bu, arızanın başlamasından yaklaşık 26 saat 16 dakika sonraydı
• Tarsnap’in açık bir SLA’i yok, ancak adil görünen kesintiler için kredi sağlama politikası uyguluyor
  • 2023-07-13’te tüm Tarsnap hesaplarına bir aylık depolama ücretinin %50’si kadar kredi tanımlandı
  • Kredi işlemi, arızanın giderilmesi ve dinlenmenin ardından yapıldı

[GN⁺]

Hacker News yorumları

• Bu yazının HN’in en üstüne çıkacağını gerçekten hiç beklemiyordum. Soruları yanıtlamak isterim ama şu an saat 22.00 ve çocuğum 17.00’de uyuyakaldığı için, şanslıysam o uyanmadan önce yaklaşık 4 saat uyuyabileceğim
  Sabah tekrar bakıp soruları yanıtlayacağım

  • restic yerine bu hizmeti kullanmam için sebep ne, merak ediyorum. Colin’e teşekkürler ama bu yazıya bakınca hizmetin altyapı sorumlusu fiilen tek bir kişiymiş gibi görünüyor
    SLA olmadığını açıkça belirtmesi iyi, ama yedeklerimle benim arama büyük bir risk girmiş gibi hissediyorum
  • Gelecekte yine bir olay sonrası analiz yazarsanız —umarım çok nadir olur ya da hiç olmaz— hangi maddelerin neden bir daha tekrarlanmayacağını gösterecek şekilde çıkarılan dersleri açıkça yazmanız iyi olur
  • Gerçekten iyi yazılmış ve düşünceli bir olay sonrası analiz, ama umarım böyle bir yazıyı bir daha görmeyiz :)
  • Artık çocuğa 7/24 destek işini devretme zamanı gelmiş ;)
    https://www.amazon.com/No-Cry-Sleep-Solution-Toddlers-Presch... kitabını okuyorum ve bir miktar faydasını görüyorum. Kütüphanede, yani kitaplar için Blockbuster gibi bir yerde, her yerde bulunabilir
  • İşlem günlüklerinin yeniden yazılmadan önce ne kadar süre saklandığını merak ediyorum
    Son birkaç hafta içinde benim de birkaç EC2 instance’ım EBS’ten kopmuş gibi belirtilerle düştü; benim durumum eu-west’ti

• “Tarsnap’in SLA’sı yok, ama adil görünüyorsa kesintiler için kredi verir” şeklindeki muğlak politika uyarınca, 2023-07-13’te herkesin Tarsnap hesabına bir aylık depolama maliyetinin %50’si kadar kredi yüklenmesi, Percival’ın nasıl biri olduğunu iyi gösteriyor
  Bu kredi, müşterileri yeterince telafi etme tarafında oldukça cömert görünüyor ve büyük bulut sağlayıcılarının aksine her müşteriyi ayrı ayrı gelip yalvarmak zorunda bırakmamış. Üstelik açık, teknik ve ayrıntılı bir olay sonrası analiz de vardı. Bence her yerde böyle yapılmalı

  • “Karanlıkta bir deniz feneri olduğun için teşekkürler” ifadesi tam oturuyor
    Tarsnap’in var olduğu ve fiyatların picodollar birimiyle belirlendiği bir dünyada yaşamak oldukça sevindirici

• Felaket kurtarma prosedürleri düzgün kurulup test edilmiş olsaydı kesinti süresi çok daha kısa olabilirdi
  Tamamen ayrı bir staging sistemi kurmak, onu kapatıp yeniden kurabilmek, çeşitli arıza modlarını düzenli olarak test etmek ve sistem kurtarmanın tüm ayrıntılı adımlarını belgelemek gerekiyor
  Uzun vadede, benzer bir şey olduğunda çok yardımcı olabilecek yarı zamanlı personel alabilmek için geliri artırmayı da düşünmeye değer
  Biz de küçük bir bulut çözümü sağlayıcısıyız ve ML API’lerine odaklanıyoruz; bulut donanımı kullanıldığında, ister dedicated ister sanal olsun, arızaların düzenli olarak yaşandığı yıllar geçtikçe daha da netleşti. RAM, HDD veya diğer donanım parçaları her an bozulabilir; bu yüzden uzun vadede yüksek erişilebilirlikli çevrim içi hizmet işletirken bunlar %100 hesaba katılmalı

• Dürüst olay sonrası analiz ve zor bir durumu iyi ele alışınız için saygılar. Ancak uyku eksikliği konusunda, sorunu düzeltebilecek yalnızca bir kişi varsa, biraz ek kesinti süresini göze alıp zihnin açık olmasını sağlamaktan utanmaya gerek yok
  Alarmlar çalarken kısa bir süre uyumaya gitmek tuhaf hissettirir, ama adrenalin ve yetersiz uyku birleşince sorunu daha da kötüleştirmek çok kolaydır

  • Endişelenmeye gerek yok, arada birkaç kez kısa uyudum. “Bu düzgün çalışıyor gibi ama birkaç saat daha sürecek; alarmı 2 saat sonrasına kurup biraz uyuyayım” demem, ikinci aşamanın gereksiz yere I/O darboğazına takıldığını fark edemememin nedenlerinden biriydi

• Anlatıma bakılırsa bu kurtarma süreci düzenli olarak test etmeye nispeten uygun görünüyor; kalan hataları yakalamak veya kurtarma süresini değerlendirmek mümkün olabilir
  Sık söylendiği gibi, yalnızca test edilmiş yedek gerçek yedektir

  • Test ettikten sonra felaket kurtarma sürecimin çalışmadığını öğrenmiş biri olarak %100 katılıyorum. Gerçekten çalışma ihtimali olan tek plan, tekrarlanabilir ve test edilmiş plandır
  • Doğru. Bir süredir bunu yapmak istiyordum ama her zaman daha yüksek öncelikli bir iş vardı. Bu kesintiden önce neredeyse 10 yıldır test etmediğimi fark etmemiştim
    Bundan sonra her yıl prova yapmayı kesinlikle yüksek öncelik haline getireceğim

• Bu tarz profesyonel, nazik ve dürüst olay sonrası analizleri görmek her zaman güzel

• Eski Tarsnap şirket bilgilerine dayanarak konuşuyor olabilirim ama Tarsnap’i ciddi şekilde kullanmakta tereddüt etmeme neden olan tek unsur, beklenmedik Colin Percival arızası, yani kilit kişi riskiydi
  Bence bu konuda yalnız değilim

  • Bu, ortalama arızalar arası süreyi hesaplamaya benziyor. Hareketli parçası az olan ve iyi tasarlanmış tek kişilik bir şirketin iyi tasarlanmış çözümüne mi güveneceğiniz, yoksa çok daha büyük ama çok daha fazla hareketli parçası olan ve muhtemelen daha kötü tasarlanmış bir çözüm sunan bir şirkete mi güveneceğiniz meselesi
    Şahsen daha basit çözümü seçerim. Deneyimime göre basit bir sistemin sahip olduğu güvenilirlik düzeyine ulaşmak için muazzam miktarda ek karmaşıklık gerekiyor ve karmaşıklığın çoğu işleri daha kötü hale getiriyor
    Sunucu kümelemede bu nokta çok belirgin. Güvenilir güç ve ağa sahip tek bir sunucu, maliyet ve karmaşıklık yaklaşık 5 kat artana kadar, o hizmeti yedeklemeye yönelik her türlü girişimden daha güvenilir olur. Ancak o noktada tek sunucuya benzer bir ortalama arızalar arası süreye ulaşırsınız ve gerçek iyileştirme ancak ondan sonra mümkün olur
    Gerçek güvenilirliğe giden en iyi yolun mümkün olduğunca basitlik ve iyi yedekleme olduğuna kuvvetle inanıyorum. 7/24 erişilebilirlik gerekiyorsa, seçilebilecek teknolojiler epey sınırlanır
  • Bunun bir risk olduğunu anlıyorum ama bunun büyük şirketlere kıyasla mutlaka daha riskli olduğundan emin değilim
    Bu Colin’in işi, Colin’in adıyla anılıyor ve Colin için çok önemli
    BigBackupCorp’ta aynı türden bir hizmet almak zor. Çalışanlar değiştirilebilir, yöneticiler değiştirilebilir ve açıkçası müşteri olarak ben bile şirket yön değiştirip BigFlowerArrangementShippingCorp olmaya karar verirse değiştirilebilir bir varlığım
    Küçük bir işletmenin iyi yanı, tamamen kendi çıkarları doğrultusunda işlemesidir. Hisse senedi oyunları ya da VC tarzı numaralar yoktur. Kârlı bir işse biri gelip onu devralabilir, kendi adını koyup kendi işi haline getirebilir. Açık internetin bundan büyük fayda gördüğünü düşünüyorum
  • Tarsnap’ten önce yok olan rakiplerin bir listesini yaparsanız hesap biraz değişebilir. Değerlendirilmesi gereken risk “işletmecinin başına bir şey gelirse?” değil, “onun başına bir şey gelir, hizmet de kapanır ve ben yedeklerimin yedeğini almamışsam?” olmalı
    Bu risk, dikkatli planlamayla istenen kadar küçültülebilir
  • HN’i takip ediyorsanız Colin’in başına bir şey geldiğini muhtemelen 24 saat içinde öğrenirsiniz. Gerçekçi olarak, yeni bir yedekleme sağlayıcısına geçene kadar olan yaklaşık 24 saatlik pencere içinde ana depolamanın, Tarsnap’in ve Colin’in aynı anda başarısız olması gerekir ki gerçek bir sorun yaşansın
  • Bir yedekleme sağlayıcısına bundan daha fazla güvenmeyi düşünmüyorum. Çünkü ona bağımlı olduğunuz anda, en zor zamanda başarısız olacaktır
    Tarsnap gibi bir hizmeti birkaç katmandan biri olarak konumlandırıp çok katmanlı yedekleme oluşturmak ve bunu düzenli olarak doğrulamak daha iyi

• Yeniden oynatılan günlük girdilerinin var olmayan bir makinenin verilerini kaydettiği hatası gibi şeyler, bir TLA+ modeli yazılırsa yakalanabilir gibi görünüyor

• restic+backblaze gibi bir kombinasyon kullanınca maliyet birkaç basamak düşüyor; Tarsnap kullanmanın avantajının ne olduğunu merak ediyorum. Hangi somut ihtiyaç, TB-yıl başına 3000 dolar ödemeyi motive eder bilmiyorum

  • Bazılarımızın elinde epey para kalıyor ve cperciva’nın berbat bir işte çalışmak yerine beceri ve yeteneğini daha büyük ve daha iyi işlere kullanması için ona para vermeye bahane bulmayı seviyoruz
    Bus factor’ın düşük olduğunu soranlara gelince: Yedeklerinizi tek bir hizmette ya da tek bir konumda tutmuyorsunuzdur herhalde? Tarsnap ile Restic+Backblaze, Rsync.net, S3 vb. birlikte kullanıyorsunuzdur, değil mi? “Yedekleme, geri yükleme lüksünden yararlanmak için ödediğiniz vergidir”
  • Tekilleştirme çok iyi çalıştığı için, Tarsnap’e yedeklediğim çok önemli çekirdek veri kümesinin maliyeti ihmal edilebilir düzeyde. Veriler daha sık değişse hesap muhtemelen farklı olurdu
    Örneğin video ve fotoğraf kütüphanesi için başka hizmetler kullanıyorum ama muhasebe veritabanı ve önemli belgeler gibi şeyleri Tarsnap’e yedekliyorum
    Tarsnap’i 10 yıldır kullanıyorum; erişilebilirlik sorunu neredeyse hiç yaşamadım ve hatırladığım kadarıyla herhangi bir türden sorun da neredeyse hiç olmadı

• 26 saatlik kesintinin büyük kısmı yedek geri yüklemeye harcanmış gibi görünüyor. Tesadüf ki bu, prodüksiyon ortamında Tarsnap kullanamamamın tam nedeni
  Kullanıcı açısından yedek geri yükleme acı verecek kadar yavaş. Sistemim çevrimdışıyken bir yedekleme hizmeti yüzünden saatlerce bekleyecek sabrım yok. Şimdi daha iyi olmuş olabilir ama birkaç yıl önce son kullandığımda birkaç GB’lık yedeği geri yüklemek yaklaşık saatler mertebesinde sürüyordu