Share via


Yedeklilik için tasarlama önerileri

Bu Azure Well-Architected Framework Güvenilirliği denetim listesi önerisi için geçerlidir:

RE:05 Özellikle kritik akışlar için farklı düzeylerde yedeklilik ekleyin. Tanımlanan güvenilirlik hedeflerine uygun olarak işlem, veri, ağ ve diğer altyapı katmanlarına yedeklilik uygulayın.

İlgili kılavuzlar:Yüksek oranda kullanılabilir çoklu bölge tasarımı | Kullanılabilirlik alanlarını ve bölgeleri kullanma

Bu kılavuzda, farklı iş yükü katmanlarında kritik akışlar boyunca yedeklilik eklemeye yönelik öneriler açıklanır ve bu da dayanıklılığı iyileştirir. İşlem, veri, ağ ve diğer altyapı katmanlarınıza uygun yedeklilik düzeylerini uygulayarak tanımlı güvenilirlik hedeflerinizin gereksinimlerini karşılayın. bu yedekliliği uygulayarak iş yükünüz üzerinde derlemeniz için güçlü ve güvenilir bir temel oluşturun. İş yükünüzü altyapı yedekliliği olmadan oluşturduğunuzda olası hatalardan dolayı uzun kapalı kalma süresi riski yüksektir.

Tanımlar

Süre Tanım
Yedeklilik bir iş yükü bileşeninin birden çok özdeş örneğinin uygulanması.
Çok teknolojili kalıcılık Her bileşenin en iyi özelliklerinden yararlanmak için aynı uygulama veya çözüm tarafından farklı depolama teknolojilerini kullanma kavramı.
Veri tutarlılığı Belirli bir veri kümesinin nasıl eşitlenmiş veya eşitlenmemiş olduğunu gösteren ölçü birden çok depodadır.
Bölümleme Verileri fiziksel olarak ayrı veri depolarına bölme işlemi.
Shard Ortak şemaya sahip birden çok depolama örneğini destekleyen yatay veritabanı bölümleme stratejisi. Veriler tüm örneklerde çoğaltılamaz.

Temel tasarım stratejileri

Güvenilirlik bağlamında, tek bir kaynağı etkileyen sorunlar içermek ve bu sorunların tüm sistemin güvenilirliğini etkilemediğinden emin olmak için yedekliliği kullanın. Her akışın yedekliliği için gerekli olan bilinçli kararlar almak için kritik akışlarınız ve güvenilirlik hedefleriniz hakkında tanımladığınız bilgileri kullanın.

Örneğin, aynı anda çalışan birden çok web sunucusu düğümüne sahip olabilirsiniz. Destekledikleri akışın kritikliği, havuzun tamamını etkileyen bir sorun varsa (örneğin bölgesel bir kesinti) tüm bunların trafiği kabul etmeye hazır çoğaltmalara sahip olmasını gerektirebilir. Alternatif olarak, büyük ölçekli sorunlar nadir olduğundan ve bir çoğaltma kümesinin tamamını dağıtmak maliyetli olduğundan, siz sorunu çözene kadar akışın düzeyi düşürülmüş durumda çalışması için sınırlı sayıda çoğaltma dağıtabilirsiniz.

Performans verimliliği bağlamında yedeklilik tasarlarken, her düğümün en iyi şekilde çalıştığından emin olmak için yükü birden çok yedekli düğüme dağıtın. Güvenilirlik bağlamında, bir veya daha fazla düğümü etkileyen hataları veya arızaları absorbe etmek için yedek kapasite oluşturun. Yedek kapasitenin, etkilenen düğümleri kurtarmak için gereken tüm süre boyunca hataları emediğinden emin olun. Bu ayrım göz önünde bulundurularak her iki stratejinin de birlikte çalışması gerekir. Trafiği performans için iki düğüme yayarsanız ve ikisi de yüzde 60 kullanımda çalışır ve bir düğüm başarısız olursa, kalan düğümünüzün yüzde 120'de çalışamaması nedeniyle aşırı yüklenme riski vardır. Performans ve güvenilirlik hedeflerinizin karşılandığından emin olmak için yükü başka bir düğümle dağıtın.

Dezavantajlar:

  • Daha fazla iş yükü yedekliliği daha fazla maliyete neden olur. Yedeklilik eklemeyi dikkatle göz önünde bulundurun ve mimarinizi düzenli olarak gözden geçirerek özellikle fazla sağlama kullanırken maliyetleri yönettiğinizden emin olun. Fazla sağlamayı dayanıklılık stratejisi olarak kullandığınızda, maliyet verimsizliklerini en aza indirmek için bunu iyi tanımlanmış bir ölçeklendirme stratejisiyle dengeleyin.
  • Yüksek düzeyde yedeklilik oluştururken performans dezavantajları olabilir. Örneğin, kullanılabilirlik alanlarına veya bölgelere yayılan kaynaklar performansı etkileyebilir çünkü web sunucuları veya veritabanı örnekleri gibi yedekli kaynaklar arasında yüksek gecikme süresine sahip bağlantılar üzerinden trafik göndermeniz gerekir.
  • Aynı iş yükü içindeki farklı akışların farklı güvenilirlik gereksinimleri olabilir. Akışa özgü yedeklilik tasarımları, genel tasarıma karmaşıklık katabilir.

Yedekli mimari tasarımı

Yedekli bir mimari tasarlarken iki yaklaşımı göz önünde bulundurun: etkin-etkin veya aktif-pasif. Altyapı bileşenlerinin desteklediği kullanıcı akışının ve sistem akışının kritikliğine bağlı olarak yaklaşımınızı seçin. Güvenilirlik açısından, çok bölgeli etkin-aktif tasarım mümkün olan en yüksek güvenilirlik düzeyine ulaşmanıza yardımcı olur, ancak aktif-pasif bir tasarımdan önemli ölçüde daha pahalıdır. Uygun coğrafi bölgelere karar vermek bir sonraki kritik seçim haline gelir. Kullanılabilirlik alanlarını kullanarak bu tasarım yaklaşımlarını tek bir bölge için de kullanabilirsiniz. Daha fazla bilgi için bkz. Yüksek oranda kullanılabilir çok bölgeli tasarım önerileri.

Dağıtım damgaları ve ölçek birimleri

İster etkin-etkin ister aktif-pasif modelde dağıtım yapın, iş yükünüzü yinelenebilir, ölçeklenebilir bir şekilde dağıttığınızdan emin olmak için Dağıtım DamgaLarı tasarım desenini izleyin. Dağıtım damgaları, iş yükünüzü müşterilerinizin belirli bir alt kümesine teslim etmek için gereken kaynak gruplarıdır. Örneğin, alt küme bölgesel bir alt küme veya iş yükünüzle aynı veri gizliliği gereksinimlerine sahip bir alt küme olabilir. Her damga pulu, iş yükünüzü yatay olarak ölçeklendirmek veya mavi-yeşil dağıtımlar gerçekleştirmek için çoğaltabileceğiniz bir ölçek birimi olarak düşünün. Dayanıklılık ve yönetim yükü için etkin-etkin veya aktif-pasif uygulamanızı iyileştirmek için iş yükünüzü dağıtım damgaları ile tasarlar. Bir bölgedeki olası geçici kaynak kapasitesi kısıtlamalarının üstesinden gelmek için çok bölgeli ölçeği genişletme planlaması da önemlidir.

Azure bölgeleri içindeki kullanılabilirlik alanları

İster etkin-etkin ister aktif-pasif bir tasarım dağıtın, dayanıklılığınızı tam olarak iyileştirmek için etkin bölgelerdeki kullanılabilirlik alanlarından yararlanın. Birçok Azure bölgesi, bir bölge içinde ayrılmış veri merkezi grupları olan birden çok kullanılabilirlik alanı sağlar. Azure hizmetine bağlı olarak, iş yükünüzün öğelerini alanlar arasında yedekli olarak dağıtarak veya öğeleri belirli bölgelere sabitleyerek kullanılabilirlik alanlarından yararlanabilirsiniz. Daha fazla bilgi için bkz. Kullanılabilirlik alanlarını ve bölgeleri kullanma önerileri.

Altyapı katmanı kılavuzu

İşlem kaynakları

  • İş yükünüz için uygun işlem hizmetini seçin. Tasarladığınız iş yükünün türüne bağlı olarak, çeşitli seçenekler kullanılabilir. Kullanılabilir hizmetleri araştırın ve belirli bir işlem hizmetinde en iyi hangi iş yükü türlerinin çalıştığını anlayın. Örneğin SAP iş yükleri genellikle hizmet olarak altyapı (IaaS) işlem hizmetleri için idealdir. Kapsayıcılı bir uygulama için, Azure Kubernetes Service (AKS) veya hizmet olarak platform (PaaS) çözümünü kullanıp kullanmayabileceğinizi belirlemek için denetime sahip olmanız gereken belirli işlevleri belirleyin. Bulut platformunuz bir PaaS hizmetini tam olarak yönetir.

  • Gereksinimleriniz izin verirse PaaS işlem seçeneklerini kullanın. Azure, Yönetim yükünüzü azaltan PaaS hizmetlerini tam olarak yönetir ve belgelenmiş bir yedeklilik derecesi yerleşik olarak bulunur.

  • Sanal makineleri (VM) dağıtmanız gerekiyorsa Azure Sanal Makine Ölçek Kümeleri kullanın. Sanal Makine Ölçek Kümeleri ile, işlemlerinizi otomatik olarak kullanılabilirlik alanlarına eşit olarak yayabilirsiniz.

  • İstekleri sunan tek tek düğümler herhangi bir zamanda silinebileceğinden, hatalı olabileceğinden veya değiştirilebileceği için işlem katmanınızı her durumdan temiz tutun.

  • Operasyonel yükünüzü artırmadan daha yüksek dayanıklılık sağlamak için mümkün olduğunda alanlar arası yedekli hizmetleri kullanın.

  • Otomatik ölçeklendirme işlemleri başlamadan önce bile yedekli örneklerin hatalarını azaltmak için kritik kaynaklara fazla sağlama, böylece sistem bir bileşen hatasından sonra çalışmaya devam eder. Fazla sağlamayı yedeklilik tasarımınıza eklerken hatanın kabul edilebilir etkisini hesaplayın. Yedeklilik karar alma sürecinizde olduğu gibi, güvenilirlik hedefleriniz ve finansal denge kararları, fazla sağlama ile yedek kapasite eklediğiniz kapsamı belirler. Fazla sağlama özellikle ölçeği genişletmeyi ifade eder; başka bir deyişle, tek bir örneğin işlem özelliklerini artırmak yerine belirli bir işlem kaynağı türünün ek örneklerinin eklenmesi anlamına gelir. Örneğin, bir VM'yi daha düşük katmanlı bir SKU'dan daha yüksek katmanlı bir SKU'ya değiştirirseniz.

  • IaaS hizmetlerini el ile veya çözümünüzü uygulamayı amaçladığınız her kullanılabilirlik alanında veya bölgede otomasyon aracılığıyla dağıtın. Bazı PaaS hizmetleri, kullanılabilirlik alanları ve bölgeler arasında otomatik olarak çoğaltılan yerleşik özelliklere sahiptir.

Veri kaynakları

  • İş yükünüzün işlevselliği için zaman uyumlu veya zaman uyumsuz veri çoğaltmanın gerekli olup olmadığını belirleyin. Bu belirlemeye yardımcı olmak için bkz. Kullanılabilirlik alanlarını ve bölgeleri kullanma önerileri.

  • Verilerinizin büyüme oranını göz önünde bulundurun. Kapasite planlaması için, çözümünüzdeki veri miktarı arttıkça güvenilirlik gereksinimlerinizin karşılandığından emin olmak için veri büyümesi, veri saklama ve arşivleme planlayın.  

  • Coğrafi olarak yerelleştirilmiş hataların etkisini en aza indirmek için hizmetiniz tarafından desteklenen verileri coğrafi olarak dağıtın.

  • Bölgesel kesintilere ve yıkıcı hatalara dayanıklılık sağlamak için verileri coğrafi bölgeler arasında çoğaltın.

  • Veritabanı örneği hatasından sonra yük devretmeyi otomatikleştirme. Birden çok Azure PaaS veri hizmetinde otomatik yük devretmeyi yapılandırabilirsiniz. Azure Cosmos DB gibi çok bölgeli yazmaları destekleyen veri depoları için otomatik yük devretme gerekli değildir. Daha fazla bilgi için bkz. Olağanüstü durum kurtarma stratejisi tasarlama önerileri.

  • Verileriniz için en iyi veri depoyu kullanın. Çok teknolojili kalıcılığı veya veri deposu teknolojilerinin bir karışımını kullanan çözümleri benimseyin. Veriler, kalıcı uygulama verilerinden fazlasını içerir. Bunlara ek olarak uygulama günlükleri, olaylar, iletiler ve önbellekler de içerir.

  • Veri tutarlılığı gereksinimlerini göz önünde bulundurun ve gereksinimler izin verdiyse nihai tutarlılığı kullanın. Veriler dağıtıldığında, güçlü tutarlılık garantilerini zorunlu kılmak için uygun koordinasyonu kullanın. Koordinasyon, aktarım hızınızı azaltabilir ve sistemlerinizi sıkı bir şekilde birleştirebilir ve bu da onları daha kırılgan hale getirir. Örneğin, bir işlem iki veritabanını güncelleştirirse, bunu tek bir işlem kapsamına koymak yerine sistemin nihai tutarlılığa uyum sağlaması daha iyidir.

  • Kullanılabilirlik için verileri bölümleme. Veritabanı bölümleme ölçeklenebilirliği artırır ve kullanılabilirliği de iyileştirebilir. Bir parça yıkılırsa, diğer parçalar hala ulaşılabilir durumdadır. Bir parçadaki hata, toplam işlemlerin yalnızca bir alt kümesini kesintiye uğratır.

  • Parçalama bir seçenek değilse, okuma-yazma ve salt okunur veri modellerinizi ayırmak için Komut ve Sorgu Sorumluluğu Ayrımı (CQRS) desenini kullanabilirsiniz. Daha fazla dayanıklılık sağlamak için daha fazla yedekli salt okunur veritabanı örneği ekleyin.  

  • Kullandığınız durum bilgisi olan platform hizmetlerinin yerleşik çoğaltma ve yedeklilik özelliklerini anlayın. Durum bilgisi olan veri hizmetlerinin belirli yedeklilik özellikleri için bkz . İlgili bağlantılar.

  • Güvenilir ve ölçeklenebilir bir ağ topolojisi belirleme. Bulut altyapınızı yedeklilik tasarımınızı oluşturmayı ve ölçeklendirmeyi kolaylaştıran mantıksal desenlerde düzenlemenize yardımcı olması için merkez-uç modeli veya Azure Sanal WAN modeli kullanın.

  • İstekleri bölgeler içinde veya bölgeler arasında dengelemek ve yeniden yönlendirmek için uygun ağ hizmetini seçin. Güvenilirlik hedeflerinizi karşılamak için mümkün olduğunda genel veya alanlar arası yedekli yük dengeleme hizmetlerini kullanın.

  • Ölçeği genişletme gereksinimleri dahil olmak üzere planlı kullanımı hesaba katmak için sanal ağlarınızda ve alt ağlarınızda yeterli IP adresi alanı ayırdığınızdan emin olun.

  • Uygulamanın, seçilen uygulama barındırma platformunun bağlantı noktası sınırları içinde ölçeklendirilediğinden emin olun. Bir uygulama birkaç giden TCP veya UDP bağlantısı başlatırsa, tüm kullanılabilir bağlantı noktalarını tüketebilir ve uygulama performansının düşmesine neden olabilir.

  • SKU'ları seçin ve bant genişliği ve kullanılabilirlik gereksinimlerinizi karşılayabilecek ağ hizmetlerini yapılandırın. VPN ağ geçidinin aktarım hızı SKU'larına göre değişir. Alanlar arası yedeklilik desteği yalnızca bazı yük dengeleyici SKU'ları için kullanılabilir.

  • DNS işleme tasarımınızın dayanıklılığa odaklanarak oluşturulduğuna ve yedekli altyapıyı desteklediğinden emin olun.

Azure kolaylaştırma

Azure platformu, aşağıdakiler sayesinde iş yükünüzün dayanıklılığını iyileştirmenize ve yedeklilik eklemenize yardımcı olur:

DNS'ye özgü Azure kolaylaştırma

  • İç ad çözümleme senaryoları için yerleşik alanlar arası yedeklilik ve coğrafi yedeklilik içeren Azure DNS özel bölgelerini kullanın. Daha fazla bilgi için bkz. Azure DNS özel bölge dayanıklılığı.

  • Dış ad çözümleme senaryoları için yerleşik bölge yedekliliği ve coğrafi yedekliliğe sahip Azure DNS ortak bölgelerini kullanın.

  • Genel ve özel Azure DNS hizmetleri, bölge verileri genel kullanıma sunulduğundan bölgesel kesintilere karşı dayanıklı küresel hizmetlerdir.

  • Şirket içi ve bulut ortamları arasındaki karma ad çözümleme senaryoları için Azure DNS Özel Çözümleyicisi'ni kullanın. İş yükünüz kullanılabilirlik alanlarını destekleyen bir bölgede bulunuyorsa bu hizmet bölge yedekliliğini destekler. Bölge genelinde kesinti, bölge kurtarma sırasında herhangi bir eylem gerektirmez. Hizmet, iyi durumdaki bölgeden yararlanmak için otomatik olarak kendi kendini iyileştirir ve yeniden dengeler. Daha fazla bilgi için bkz. Azure DNS Özel Çözümleyicisi'nde Dayanıklılık.

  • Tek bir hata noktasını ortadan kaldırmak ve bölgeler arasında daha dayanıklı bir karma ad çözümlemesi elde etmek için farklı bölgelere iki veya daha fazla Azure DNS özel çözümleyicisi dağıtın. Koşullu iletme senaryosunda DNS yük devretmesi, birincil DNS sunucunuz olarak bir çözümleyici atanarak elde edilir. Farklı bir bölgedeki diğer çözümleyiciyi ikincil DNS sunucusu olarak atayın. Daha fazla bilgi için bkz. Özel çözümleyicileri kullanarak DNS yük devretmesini ayarlama.

Örnek

Çok bölgeli yedekli dağıtım örneği için bkz. Temel yüksek oranda kullanılabilir alanlar arası yedekli web uygulaması.

Aşağıdaki diyagramda başka bir örnek gösterilmektedir:

Başvuru uygulamasının mimarisini gösteren diyagram.

Yedeklilik hakkında daha fazla bilgi edinmek için aşağıdaki kaynaklara bakın:

Güvenilirlik denetim listesi

Önerilerin tamamına bakın.