Yedekleme ve kurtarma tasarımı
Tailwind Traders gibi kuruluşlar, görev açısından kritik uygulamalarından yüksek düzeyde güvenilirlik gerektirir. Şirket içi tabanlı uygulamalarda istenen güvenilirliği elde etmek için sunucular ve depolama gibi daha fazla bilgi işlem kaynağı satın almak normaldir. Daha fazla bilgi işlem kaynağı satın almak, şirket içi altyapıda yedeklilik oluşturur.
Görev açısından kritik tüm uygulamalar ve ilişkili verilerin hata noktasına ideal bir şekilde bir hata sonrasında kurtarılabilir olması da çok önemlidir. Bu kurtarılabilirlik genellikle yedekleme, geri yükleme bileşenleri ve yordamlar tarafından sağlanır. Azure'da barındırılan uygulamaları olan kuruluşlar veya karma uygulama dağıtımları olan kuruluşlar için dikkat edilmesi gereken başka noktalar ve seçenekler vardır.
Güvenilir uygulamalar şunlardır:
Bileşen hatasına dayanıklı.
Yüksek oranda kullanılabilir ve önemli bir kapalı kalma süresi olmadan iyi durumda çalışabilir.
İstenen dayanıklılığı ve yüksek kullanılabilirliği elde etmek için önce gereksinimlerinizi tanımlamanız gerekir.
Not
Bu modülde dayanıklılık terimi, sistemin yanlışlıkla ve kötü amaçlı olarak hataları düzgün bir şekilde işleyebilmesi ve kurtarabilmesi olarak kullanacaktır.
Gereksinimlerinizi tanımlama
Gereksinimlerinizi tanımlamak şunları içerir:
İş gereksinimlerinizi tanımlama.
Bu ihtiyaçları karşılamak için dayanıklılık planınızı oluşturma.
Bu işlemle ilgili rehberlik sağlamak için aşağıdaki önemli noktalar tablosunu kullanın.
| Dikkate Alınacak Nokta | Açıklama |
|---|---|
| İş yükleriniz ve kullanımları nelerdir? | İş yükü, iş mantığı ve veri depolama gereksinimleri açısından diğer görevlerden mantıksal olarak ayrılabilen, farklı bir özellik veya görevdir. Her iş yükünün kullanılabilirlik, ölçeklenebilirlik, veri tutarlılığı ve olağanüstü durum kurtarma için büyük olasılıkla farklı gereksinimleri vardır. |
| İş yükleriniz için kullanım desenleri nelerdir? | Kullanım desenleri gereksinimlerinizi belirleyebilir. Hem kritik hem de kritik olmayan dönemlerdeki gereksinimlerdeki farkları belirleyin. Çalışma süresini sağlamak için, bir bölgenin başarısız olması durumunda birkaç bölgede yedeklilik planlayın. Buna karşılık kritik olmayan dönemlerde maliyetleri en aza indirmek için uygulamanızı tek bir bölgede çalıştırabilirsiniz. |
| Kullanılabilirlik ölçümleri nelerdir? | Ortalama kurtarma süresi (MTTR) ve hatalar arasındaki ortalama süre (MTBF) genellikle kullanılan ölçümlerdir. MTBF, bileşenin kesintiler arasında çalışmaya devam etmesi beklenebilecek çalışma zamanıdır. MTTR, hata sonrasında bir bileşeni geri yüklemek için gereken ortalama süredir. Yedeklilik eklemeniz gereken yeri belirlemek ve müşteriler için hizmet düzeyi sözleşmelerini (SLA) belirlemek için bu ölçümleri kullanın. |
| Kurtarma ölçümleri nelerdir? | Kurtarma süresi hedefi (RTO), bir olay sonrasında uygulamalarınızdan birinin kullanılamayabileceği kabul edilebilir en uzun süredir. Kurtarma noktası hedefi (RPO), olağanüstü durum sırasında kabul edilebilir maksimum veri kaybı süresidir. Kurtarma düzeyi hedefini (RLO) de göz önünde bulundurun. Bu ölçüm kurtarmanın ayrıntı düzeyini belirler. Başka bir deyişle, bir sunucu grubu, web uygulaması, site veya yalnızca belirli bir öğeyi kurtarabilmeniz gerekip gerekmediği. Bu değerleri belirlemek için bir risk değerlendirmesi gerçekleştirin. Kuruluşunuzda kapalı kalma süresinin veya veri kaybının maliyetini ve riskini anladığınızdan emin olun. |
| İş yükü kullanılabilirlik hedefleri nelerdir? | Uygulama mimarinizin iş gereksinimlerinizi karşıladığından emin olmak için her iş yükü için hedef SLA'lar tanımlayın. Uygulama bağımlılıklarına ek olarak kullanılabilirlik gereksinimlerinin maliyetini ve karmaşıklığını da hesaba katın. |
| SLA'larınız nelerdir? | Azure’da SLA, Microsoft’un çalışma süresi ve bağlantı hakkındaki taahhütlerini belirtir. Belirli bir hizmet için SLA yüzde 99,9 ise hizmetin zamanın yüzde 99,9’unda kullanılabilir durumda olmasını bekleyebilirsiniz. |
İpucu
Yüksek oranda kullanılabilir bir senaryoda herhangi bir kritik bileşenin MTTR değeri sistem RTO'sunu aşarsa, sistemdeki bir hata kabul edilemez bir iş kesintisine neden olabilir. Başka bir deyişle, sistemi tanımlı RTO içinde geri yükleyemezsiniz.
Yukarıdaki soruları yanıtlayarak çözümünüzdeki her iş yükü için kendi hedef SLA'larınızı tanımlayın. Bu, mimarinin iş gereksinimlerinizi karşılamasını sağlamaya yardımcı olur. Örneğin, bir iş yükü yüzde 99,99 çalışma süresi gerektiriyorsa ancak yüzde 99,9 SLA'ya sahip bir hizmete bağlıysa, bu hizmet sistemde tek bir hata noktası olamaz.
Kurtarma gereksinimlerinizi tanımladıktan sonra uygun bir kurtarma teknolojisi seçebilirsiniz.