Şaşırtıcı olmayan bir şekilde, burada Geri sarma, korumamız gereken çok fazla veri var (2 petabayttan fazla değer). Kullandığımız veritabanlarından birinin adı Elasticsearch (ES veya şu anda AWS’de bilindiği gibi Opensearch). Basitçe söylemek gerekirse, ES yıldırım hızında arama sonuçlarını kolaylaştıran bir belge veritabanıdır. Müşteriler, kullanarak geri yüklemeleri gereken belirli bir dosya veya öğeyi ararken hız çok önemlidir. Geri sarma. Kesinti süresinin her saniyesi önemlidir, bu nedenle arama sonuçlarımızın hızlı, doğru ve güvenilir olması gerekir.
Başka bir düşünce felaketti iyileşmek. bizim bir parçası olarak Sistem ve Organizasyon Kontrolleri Seviye 2 (SOC2) Sertifikasyon sürecinde, tüm AWS bölgesinin kapalı olması gibi pek olası olmayan bir durumda hizmeti geri yüklemek için çalışan bir olağanüstü durum kurtarma planımız olduğundan emin olmamız gerekiyordu.
“Bütün bir AWS bölgesi mi? Bu asla olmayacak!” (Dışında ne zaman yaptı)
Her şey mümkün, işler ters gidiyor ve SOC2 gereksinimlerimizi karşılamak için çalışan bir çözüme ihtiyacımız vardı. Spesifik olarak ihtiyacımız olan şey, müşterilerimizin verilerini güvenli, verimli ve uygun maliyetli bir şekilde alternatif bir AWS bölgesine çoğaltmanın bir yoluydu. Cevap, Rewind’in çok iyi yaptığı şeyi yapmaktı – yedek alın!
Elasticsearch’ün nasıl çalıştığına, verileri güvenli bir şekilde yedeklemek için nasıl kullandığımıza ve mevcut olağanüstü durum kurtarma sürecimize bakalım.
anlık görüntüler
İlk olarak, hızlı bir kelime bilgisi dersine ihtiyacımız olacak. ES’deki yedeklemeler denir anlık görüntüler. Anlık görüntüler bir anlık görüntü deposu. Var birden çok anlık görüntü deposu türüAWS S3 tarafından desteklenenler de dahil olmak üzere. S3, içeriğini başka bir bölgedeki bir kovaya kopyalama yeteneğine sahip olduğundan, bu özel sorun için mükemmel bir çözümdü.
AWS ES, sizin için önceden etkinleştirilmiş otomatik bir anlık görüntü deposuyla birlikte gelir. Depo, varsayılan olarak saatlik anlık görüntüler alacak şekilde yapılandırılmıştır ve bununla ilgili hiçbir şeyi değiştiremezsiniz. Bu bizim için bir sorundu çünkü bir günlük içeriklerini başka bir bölgeye kopyalayacak şekilde yapılandırılmış kendi S3 klasörlerimizden biri tarafından desteklenen bir depoya gönderilen anlık görüntü.
 |
| Otomatik anlık görüntülerin listesi GET _cat/snapshots/cs-automated-enc?v&s=id |
Tek seçeneğimiz, kendi anlık görüntü depomuzu ve anlık görüntülerimizi oluşturmak ve yönetmekti.
Kendi anlık görüntü depomuzun bakımı ideal değildi ve kulağa pek çok gereksiz iş gibi geldi. Tekerleği yeniden icat etmek istemedik, bu yüzden bizim için ağır yükleri kaldıracak mevcut bir aleti aradık.
Anlık Görüntü Yaşam Döngüsü Yönetimi (SLM)
Denediğimiz ilk araç Elastic’in Anlık görüntü yaşam döngüsü yönetimi (SLM)şu şekilde açıklanan bir özellik:
Bir kümeyi düzenli olarak yedeklemenin en kolay yolu. Bir SLM ilkesi, önceden ayarlanmış bir programa göre otomatik olarak anlık görüntüler alır. Politika, tanımladığınız saklama kurallarına göre anlık görüntüleri de silebilir.
Hatta kendi anlık görüntü deponuzu da kullanabilirsiniz. Ancak, bunu alanlarımızda kurmaya çalıştığımız anda başarısız oldu. AWS ES’nin Elastic’in değiştirilmiş bir versiyonu olduğunu çabucak öğrendik. co’s ES ve bu SLM, AWS ES’de desteklenmedi.
küratör
Araştırdığımız bir sonraki aracın adı Elasticsearch Küratörü. Açık kaynak kodluydu ve Elastic.co’nun kendileri tarafından sürdürüldü.
Küratör, dizinlerinizi ve anlık görüntülerinizi yönetmenize yardımcı olan bir Python aracıdır. Ek bir avantaj olan özel anlık görüntü depoları oluşturmak için yardımcı yöntemlere bile sahiptir.
Küratör’ü, tümü AWS SAM’de paketlenmiş, planlanmış bir EventBridge kuralı tarafından yönlendirilen bir Lambda işlevi olarak çalıştırmaya karar verdik.
İşte nihai çözüm nasıl görünüyor:
ES Anlık Görüntü Lambda İşlevi
Lambda, Küratör aracını kullanır ve anlık görüntü ve depo yönetiminden sorumludur. İşte mantığın bir diyagramı:
Yukarıda gördüğünüz gibi, çok basit bir çözüm. Ancak, çalışması için birkaç şeyin var olmasına ihtiyacımız vardı:
- İzin vermek için IAM rolleri
- Başka bir bölgeye replikasyonu olan bir S3 kovası
- Dizinlere sahip bir Elasticsearch etki alanı
IAM Rolleri
S3SnapshotsIAMRole hibeleri küratör anlık görüntü deposunun oluşturulması ve gerçek anlık görüntülerin yönetilmesi için gereken izinler:
EsSnapshotIAMRole hibeleri Lambda Küratörün Elasticsearch etki alanıyla etkileşim kurmak için ihtiyaç duyduğu izinler:
Çoğaltılmış S3 Kovaları
Ekip, Terraform’da bölgeler arası çoğaltmayı kolaylaştırmak için daha önce diğer hizmetler için çoğaltılmış S3 kovaları kurmuştu. (Bununla ilgili daha fazla bilgi burada)
Her şey yerli yerindeyken, üretimin ilk testinde dağıtılan bulut bilgi yığını iyi gitti ve işimiz bitti… yoksa bitti mi?
Yedekleme ve Geri Yükleme I
SOC2 sertifikasının bir kısmı, tüm kritik hizmetler için üretim veritabanı yedeklerinizi doğrulamanızı gerektirir. Biraz eğlenmeyi sevdiğimiz için üç ayda bir “Yedekle ve Geri Yükle” düzenlemeye karar verdik. Orijinal bölgenin gittiğini ve her bir veritabanını bölgeler arası replikamızdan geri yüklememiz ve içeriği doğrulamamız gerektiğini varsayardık.
“Aman Tanrım, bu çok gereksiz bir iş!” diye düşünebilirsiniz. ve yarı haklı olurdun. Bu çok iş, ama kesinlikle gerekli! Her Restore-a-thon’da, hizmetlerde yedeklemelerin etkinleştirilmemesi, nasıl geri yükleneceğini bilmeme veya geri yüklenen yedeklemeye erişme konusunda en az bir sorunu ortaya çıkardık. Ekip üyelerinin gerçek bir kesintinin yüksek baskısı altında olmayan bir şeyi yaparak kazandıkları uygulamalı eğitim ve deneyimden bahsetmiyorum bile. Bir yangın tatbikatı yapmak gibi, üç aylık Restore-a-thon’larımız, ekibimizin herhangi bir acil durumla başa çıkmak için hazırlıklı ve hazır olmasına yardımcı olur.
İlk ES Restore-a-thon, özelliğin tamamlanmasından ve üretimde dağıtılmasından aylar sonra gerçekleşti, bu nedenle birçok anlık görüntü alındı ve birçok eski görüntü silindi. Aracı, 5 günlük anlık görüntüleri saklayacak ve diğer her şeyi silecek şekilde yapılandırdık.
Depomuzdan çoğaltılmış bir anlık görüntüyü geri yükleme girişimleri, bilinmeyen bir hatayla başarısız oldu ve devam edecek pek bir şey yok.
ES’deki anlık görüntüler artımlıdır, yani anlık görüntülerin sıklığı ne kadar yüksek olursa, o kadar hızlı tamamlanır ve boyutları o kadar küçük olur. En büyük alanımız için ilk anlık görüntünün tamamlanması 1,5 saatten fazla sürdü ve sonraki tüm günlük anlık görüntüler dakikalar aldı!
Bu gözlem, ilk anlık görüntüyü denemeye ve korumaya ve havuz oluşturulduktan sonra alınan ilk anlık görüntü için bir ad son eki (-initial) kullanarak silinmesini önlemeye yönlendirdi. Bu ilk anlık görüntü adı daha sonra Küratör tarafından bir normal ifade filtresi kullanılarak anlık görüntü silme işleminden çıkarılır.
S3 kovalarını, anlık görüntüleri ve depoları temizledik ve yeniden başladık. Anlık görüntülerin birikmesi için birkaç hafta bekledikten sonra, geri yükleme aynı şifreli hatayla yeniden başarısız oldu. Ancak, bu sefer (koruduğumuz) ilk anlık görüntünün de eksik olduğunu fark ettik!
Konuya harcayacak hiçbir döngü kalmadığından, burada üzerinde çalıştığımız diğer harika ve harika şeyler üzerinde çalışmak için onu park etmek zorunda kaldık. Geri sarma.
Yedekleme ve Geri Yükleme-a-thon II
Siz farkına bile varmadan, bir sonraki çeyrek başlıyor ve yeni bir Yedekleme ve Geri Yükleme zamanı geldi ve bunun felaket kurtarma planımızda hâlâ bir boşluk olduğunun farkındayız. Başka bir bölgedeki ES verilerini başarıyla geri yükleyebilmemiz gerekiyor.
Lambda’ya fazladan günlük kaydı eklemeye ve yürütme günlüklerini günlük olarak kontrol etmeye karar verdik. 1. ila 6. günler gayet iyi çalışıyor – işi geri yükler, tüm anlık görüntüleri listeleyebiliriz ve ilki hala oradadır. 7. günde garip bir şey oldu – mevcut anlık görüntüleri listeleme çağrısı, yalnızca ilk anlık görüntü için “bulunamadı” hatası verdi. Anlık görüntülerimizi hangi dış güç siliyor?
S3 kova içeriğine daha yakından bakmaya karar verdik ve eksik olan ilk anlık görüntü dışında tüm UUID’ler (Evrensel Olarak Benzersiz Tanımlayıcı) olduğunu ve bazı nesnelerin anlık görüntülerle ilişkili olduğunu gördük.
Konsoldaki “versiyonları göster” geçiş anahtarını fark ettik ve kovanın üzerinde sürüm oluşturmanın etkinleştirilmesinin garip olduğunu düşündük. Sürüm geçişini etkinleştirdik ve tüm anlık görüntü setini bozan ilk anlık görüntü de dahil olmak üzere hemen her yerde “İşaretçileri Sil” ifadesini gördük.
Önce sonra
Kullandığımız S3 kovasının 7 günden eski tüm nesneleri temizleyen 7 günlük bir yaşam döngüsü kuralına sahip olduğunu çok çabuk fark ettik.
Yaşam döngüsü kuralı, maliyetleri düşük ve kovayı düzenli tutmak için kovalardaki yönetilmeyen nesnelerin otomatik olarak temizlenmesi için mevcuttur.
Silinen nesneyi geri yükledik ve işte, anlık görüntülerin listesi iyi çalıştı. En önemlisi, geri yükleme başarılı oldu.
Ev Esneme
Bizim durumumuzda, Küratör anlık görüntü yaşam döngüsünü yönetmelidir, bu nedenle tek yapmamız gereken yaşam döngüsü kuralının, kural üzerinde kapsamlı bir yol filtresi kullanarak anlık görüntü depolarımızdaki herhangi bir şeyi kaldırmasını engellemekti.
Kuralın kapsamına giren “/auto-purge” adlı belirli bir S3 öneki oluşturduk. /auto-purge içindeki 7 günden daha eski olan her şey silinecek ve kovadaki diğer her şey kendi haline bırakılacaktır.
Her şeyi bir kez daha temizledik, > 7 gün bekledik, çoğaltılan anlık görüntüleri kullanarak geri yüklemeyi yeniden çalıştırdık ve sonunda kusursuz çalıştı – Yedekleme ve Geri Yükleme sonunda tamamlandı!
Çözüm
Bir felaket kurtarma planı oluşturmak zorlu bir zihinsel egzersizdir. Her bir parçasını uygulamak ve test etmek daha da zordur, ancak kuruluşunuzun her türlü fırtınayı atlatmasını sağlayan temel bir iş uygulamasıdır. Elbette, bir ev yangını olası bir olay değildir, ancak olursa, duman yükselmeye başlamadan önce ne yapacağınızı uyguladığınız için muhtemelen memnun olacaksınız.
Altyapınızın kritik kısımları için bir sağlayıcı kesintisi olması durumunda iş sürekliliğini sağlamak yeni zorluklar ortaya çıkarır, ancak burada sunulana benzer çözümleri keşfetmek için harika fırsatlar da sağlar. Umarım buradaki küçük maceramız, kendi Elasticsearch felaket kurtarma planınızı oluştururken karşılaştığımız tuzaklardan kaçınmanıza yardımcı olur.
Not – Bu makale, Rewind’de DevOps Uzmanı olan Mandeep Khinda tarafından yazılmış ve katkıda bulunmuştur.