Aracılığıyla paylaş


Yedeklilik için tasarlama önerileri

Bu Azure İyi Tasarlanmış Çerçeve 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 çok bölgeli tasarım | Kullanılabilirlik alanlarını ve bölgelerini kullanma

Bu kılavuzda, dayanıklılığı iyileştiren farklı iş yükü katmanlarında kritik akışlar boyunca yedeklilik ekleme önerileri açıklanmaktadır. İş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 iş yükünüz için temel oluşturacak güçlü ve güvenilir bir temel sağlamak için uygulayın. İş 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 eşitlenmesinin veya eşitlenme durumunun birden çok depoda nasıl yapıldığını gösteren ölçü.
Bölümleme Verileri fiziksel olarak ayrı veri depolarına bölme işlemi.
Parça 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, yedekliliği tek bir kaynağı etkileyen sorunlar içerecek şekilde kullanın ve bu sorunların sistemin tamamının güvenilirliğini etkilemediğinden emin olun. 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üğümleriniz olabilir. 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ı emmek için yedek kapasitede 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 dağıtırsanız ve her 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 bunalma riski vardır. Performans ve güvenilirlik hedeflerinizin karşılandığından emin olmak için yükü başka bir düğüme dağıtın.

Dezavantajlar:

  • Daha fazla iş yükü yedekliliği daha fazla maliyete eşit olur. Yedeklilik eklemeyi dikkatlice göz önünde bulundurun ve özellikle fazla sağlama kullanırken maliyetleri yönettiğinizden emin olmak için mimarinizi düzenli olarak gözden geçirin. 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 dengeleri olabilir. Örneğin, kullanılabilirlik alanlarına veya bölgelere yayılan kaynaklar, web sunucuları veya veritabanı örnekleri gibi yedekli kaynaklar arasında yüksek gecikme süreli bağlantılar üzerinden trafik göndermeniz gerektiğinden performansı etkileyebilir.
  • 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 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 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 tek bir bölge için bu tasarım yaklaşımlarını da 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 etkin-pasif modelde dağıtı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şletmeyi planlamak 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ölgeler içindeki kullanılabilirlik alanlarından yararlanın. Birçok Azure bölgesi, bir bölge içindeki veri merkezlerinin ayrılmış grupları olan birden çok kullanılabilirlik alanı sağlar. Azure hizmetine bağlı olarak, iş yükünüzün öğelerini bölgeler 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ölgelerini 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 en uygundur. Kapsayıcılı bir uygulama için, Azure Kubernetes Service (AKS) veya hizmet olarak platform (PaaS) çözümünün kullanılıp kullanılmayacağını belirlemek için denetlemeniz gereken belirli işlevleri belirleyin. Bulut platformunuz bir PaaS hizmetini tamamen 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 sayesinde, işlemlerinizi otomatik olarak kullanılabilirlik alanlarına eşit olarak yayabilirsiniz.

  • İsteklere hizmet eden tek tek düğümler herhangi bir zamanda silinebileceği, hataya neden olabileceği veya değiştirilebileceği için işlem katmanınızı herhangi bir 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şletme anlamına gelir; bu da herhangi bir tek ö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.

  • Çözümünüzü uygulamayı planladığınız her kullanılabilirlik alanında veya bölgede IaaS hizmetlerini el ile veya otomasyon yoluyla 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 belirlemeyi yapmanıza yardımcı olmak için bkz . Kullanılabilirlik alanlarını ve bölgelerini 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 depolarını 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 verince 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 tek bir işlem kapsamına koymak yerine iki veritabanını güncelleştirirse, 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 erişilebilir durumda olur. Tek parçadaki bir 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 belirleyin. Bulut altyapınızı yedeklilik tasarımınızın oluşturulmasını ve ölçeklendirilmesini 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ı yedekliliğe ve coğrafi yedekliliğe sahip 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 alanlar arası yedekliliğe 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 dayanıklı genel hizmetlerdir.

  • Şirket içi ve bulut ortamları arasındaki karma ad çözümleme senaryoları için Azure DNS Özel Çözümleyicisi'ni kullanın. bu hizmet, iş yükünüz kullanılabilirlik alanlarını destekleyen bir bölgede bulunuyorsa alanlar arası yedekliliği destekler. Bölge genelinde kesinti, bölge kurtarma sırasında herhangi bir işlem gerektirmez. Hizmet, sağlıklı 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

Öneriler kümesinin tamamına bakın.