Amazon EC2 Yedekleme Stratejisi

Amazon'un EC2'sini kullanarak birkaç Web sunucusu / DB sunucu kurulumum var. Şu anda tüm uygulama dosyaları, DB dosyaları, kaynak kodu ve DB yedeklerini içeren tüm sistemimin ve EBS sürücülerinin günlük anlık görüntülerini alıyorum. Yedekleme tasarımlarını bir zamanlamaya göre çalıştıran bir konsol uygulamam var. Resimlerim EBS resimleri.

Ben çok gün sonra anlık görüntülerimi bırakacak bir görev üzerinde çalışıyorum. Sanırım sorum şu, Tam bir görüntü / EBS görevini de planlamalı / planlayabilir miyim? Bu şekilde, sunucu arızalanırsa veya bozulursa, en son görüntüyü başlatabilir ve en son anlık görüntüyü uygulayabilirim.

Yedekleme stratejim üzerinde çalışırken, veri disklerimi yedeklemek için Jungle Disc kullanıyorum.

Önerilerim:

1. Örneği kaybetmeniz durumunda yazılım kurulumunu ve sistem yapılandırmasını yeniden oluşturabilmeniz için her yeni örneğin kurulumunu daima belgeleyin ve / veya komut dosyasını yazın. Yeni bir örnek başlatıp prosedürü izleyerek bunu test edin. Kurulum uzun zaman alıyorsa ve örnekleri hızlı bir şekilde başlatmanız gerekiyorsa özel, özel bir AMI kullanabilirsiniz, ancak AMI'nin kendisinin belgelenmiş ve / veya komut dosyası kullanılarak yazılmış bir prosedür kullanılarak oluşturulması gerekir.

2. Önemli verilerinizi kök EBS biriminde değil ayrı EBS birimlerinde saklayın. Bunun, verilerinizi yeni örneklere taşımayı kolaylaştırmak (örneğin, farklı AMI'lere dayalı) ve verilerinizin diğer örneklere (örn. Anlık görüntüler ve yeni birimlerle) kopyalanmasını kolaylaştırmak gibi birçok faydası vardır.

3. EBS veri birimlerinin düzenli anlık görüntülerini oluşturun. Mümkünse / uygulanabilirse, tutarlı bir dosya sisteminin / veritabanının anlık görüntüsünü alma şansınızı artırmak için ec2-tutarlı-anlık görüntüm gibi bir araç kullanın . AWS hesabınızın kendisi tek bir hata noktası olduğundan, AWS / EC2 dışındaki verileri yedekleyin.

4. Önemli örneklerde zaman zaman kök EBS biriminin anlık görüntülerini oluşturun. Bu, örnek veya EBS birim hatası durumunda size yardımcı olsa da, yukarıdaki # 1 ve # 2 nedeniyle bu bölüm çok kritik değildir. Bunu yapmamın temel nedeni, anlık görüntüler oluşturmanın kök EBS biriminin kendisinin başarısız olma riskini azaltmasıdır.

Bir EBS biriminin başarısızlık oranı, son EBS anlık görüntüsünden bu yana bu birimde değiştirilen blok sayısı ile doğrudan ilişkilidir.

Tam bir görüntü / EBS görevini de planlamalı mıyım / planlayabilir miyim?

evet, tavsiye edilir. Bir kere beni kurtardı, çünkü önyükleme diski artık okunamayana kadar çekirdek sorunları nedeniyle birçok kez sıfırlamak zorunda kaldım ve en son anlık görüntüden önyükleme yaptım.

İlgileniyorsanız, bağlı tüm EBS birimlerinin anlık görüntüsünü almak ve belirli bir süre sonra silmek için bir Java sınıfı yazdım. Şu anda her hafta bir yedekleme yapıyorum ve iki hafta sonra üçüncü yedeklemeyi atıyorum.

https://github.com/stivlo/obliquid-cp/blob/master/src/main/java/org/obliquid/sherd/runner/RequestSnapshots.java

Anlık görüntü alma veya silme gibi çalıştırma başına yalnızca bir eylem gerçekleştirir, çünkü benim yaptığım birçok EBS'ye sahip olmanız durumunda aynı anda onlarca anlık görüntü ile aşırı yüklenmeyi önlemek için saatte bir cron'a konulması gerekir.

Basit ama güçlü bir yedekleme stratejisi kullanıyoruz: EC2 EBS örneklerini günde iki kez çalıştırmaya dayanarak yeni AMI oluşturun ve “eski” AMI'ları silin. API (CreateImage) aracılığıyla, yeni AMI oluştururken bayrağı yeniden başlatmayın örneğini ayarlayabilirsiniz veya CreateIImage API çağrısından önce örnek olarak raid - ssh kullanırsanız ve yeni çekirdeklerdeki en popüler dosya sistemlerinde “fsfreeze” ile dosya sistemini dondurursanız veya xfs_freeze eski çekirdek ve xfs kullanırsınız.

Oluşturulan “yedek” AMI, orijinal çalışan örnek EBS disklerine (oluşturulan anlık görüntülere bağlantılar aracılığıyla) bağlı olanların tümünü hatırlar ve birden çok diske sahip yazılım baskınları kullanılması durumunda, herhangi bir AZ'de yeni örneği tek bir API çağrısı veya web üzerinden geri yüklemeye izin verir -arayüz.