Kullanılabilirlik alanlarını ve bölgeleri kullanma önerileri

Bu Azure Well-Architected Framework Güvenilirlik 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 | Yedeklilik

Bu kılavuzda, kullanılabilirlik alanları veya bölgeler arasında iş yüklerinin ne zaman dağıtılacağına ilişkin öneriler açıklanmaktadır.

Azure için bir çözüm tasarlarken, bir bölgedeki birden çok kullanılabilirlik alanına mı yoksa birden çok bölgeye mi dağıtım yapacağınıza karar vermeniz gerekir. Bu karar çözümünüzün güvenilirliğini, maliyetini ve performansını ve ekibinizin çözümü çalıştırma becerisini etkiler. Bu kılavuzda kararınızı etkileyen temel iş gereksinimleri, göz önünde bulundurabileceğiniz yaklaşımlar, her yaklaşımda yer alan ödünler ve her yaklaşımın Azure Well-Architected Framework'ün temel yapı taşlarına etkisi hakkında bilgi sağlanır.

Çözümünüz için kullanılacak en iyi Azure bölgeleriyle ilgili karar kritik bir seçimdir. Azure Bölgelerini Seçin kılavuzunda birden çok coğrafi bölgenin nasıl seçilip çalıştırıldığı açıklanır. Çözümünüzdeki bölgeleri ve kullanılabilirlik alanlarını nasıl kullanacağınız seçiminiz, Well-Architected Framework'ün birkaç sütununu da etkiler:

• Güvenilirlik: Seçtiğiniz dağıtım yaklaşımı, çeşitli risk türlerini azaltmanıza yardımcı olabilir. Genel olarak, iş yükünüzü coğrafi olarak daha dağıtılmış bir alana yayarak daha yüksek dayanıklılık elde edebilirsiniz.
• Maliyet İyileştirme: Bazı mimari yaklaşımlar diğerlerinden daha fazla kaynak dağıtmayı gerektirir ve bu da kaynak maliyetlerinizi artırabilir. Diğer yaklaşımlar coğrafi olarak ayrılmış kullanılabilirlik alanları veya bölgeleri arasında veri göndermeyi içerir ve bu da ağ trafiği ücretlerine neden olabilir. Ayrıca, kapsamlı iş gereksinimleriniz olduğunda genellikle daha yüksek olan kaynaklarınızı yönetmenin sürekli maliyetini göz önünde bulundurmanız da önemlidir.
• Performans Verimliliği: Kullanılabilirlik alanları, bölgeler arasında zaman uyumlu çoğaltmayı ve iletişimi etkinleştirmek için çoğu iş yükü için yeterli olan yüksek bant genişliğine sahip, düşük gecikme süreli bir ağ bağlantısı aracılığıyla birbirine bağlanır. Ancak, iş yükünüz test edildiyse ve bölgeler arasında ağ gecikme süresine duyarlıysa, iletişim kurarken gecikme süresini en aza indirmek için iş yükünüzün bileşenlerini fiziksel olarak birbirine yakın bir şekilde konumlandırmayı göz önünde bulundurmanız gerekebilir.
• Operasyonel Mükemmellik: Karmaşık bir mimarinin dağıtılması, yapılandırılması ve yönetilmesi daha fazla çaba gerektirir. Ayrıca, yüksek oranda kullanılabilir bir çözüm için ikincil bir kaynak kümesine yük devretmeyi planlamanız gerekebilir. Yük devretme, yeniden çalışma ve trafiğinizi saydam bir şekilde yeniden yönlendirme, özellikle el ile gerçekleştirilen adımlar gerektiğinde karmaşık olabilir. Dağıtım ve yönetim süreçlerinizi otomatikleştirmek iyi bir uygulamadır. Daha fazla bilgi için bkz. OE:05 Kod olarak altyapı, OE:09Görev otomasyonu, OE:10 Otomasyon tasarımı ve OE:11 Dağıtım uygulamaları da dahil olmak üzere Operasyonel Mükemmellik sütun kılavuzları.

Çözümünüzü nasıl tasarlarsanız tasarlasanız da Güvenlik sütunu geçerlidir. Genellikle, kullanılabilirlik alanlarını ve bölgeleri kullanıp kullanmadığınız ve kullanma şekliniz hakkındaki kararlar güvenlik duruşunuzu değiştirmez. Azure, her bölgeye ve kullanılabilirlik alanına aynı güvenlik donanımını uygular.

İpucu

Birçok üretim iş yükü için alanlar arası yedekli dağıtım , en iyi dengeyi sağlar. Zaman uyumsuz veri yedekleme ile bu yaklaşımı başka bir bölgeye genişletebilirsiniz. Hangi yaklaşımı seçeceğinizi bilmiyorsanız, bu dağıtım türüyle başlayın.

Bu yaklaşımların sağladığı belirli avantajlara ihtiyacınız olduğunda diğer iş yükü yaklaşımlarını göz önünde bulundurun, ancak ilgili dezavantajları göz önünde bulundurun.

Tanımlar

Süre	Tanım
Aktif-aktif	Bir çözümün birden çok örneğinin istekleri aynı anda etkin bir şekilde işlediği mimari.
Aktif-pasif	Çözümün bir örneğinin birincil olarak belirlendiği ve trafiği işlediği ve birincil örnek kullanılamıyorsa trafiğe hizmet vermek için bir veya daha fazla ikincil örneğin dağıtıldığı mimari.
Zaman uyumsuz çoğaltma	Verilerin tek bir konuma yazıldığı ve işlendiği bir veri çoğaltma yaklaşımı. Daha sonra değişiklikler başka bir konuma çoğaltılır.
Kullanılabilirlik alanı	Bir bölge içindeki ayrılmış veri merkezleri grubu. Her kullanılabilirlik alanı kendi gücü, soğutması ve ağ altyapısıyla diğerlerinden bağımsızdır. Birçok bölge kullanılabilirlik alanlarını destekler.
Veri merkezi	Azure kaynaklarını ve iş yüklerini desteklemek için sunucular, ağ ekipmanı ve diğer donanımları içeren bir tesis.
Yerel olarak yedekli dağıtım	Bir kaynağın kullanılabilirlik alanına başvurmadan tek bir bölgeye dağıtıldığı dağıtım modeli. Kullanılabilirlik alanlarını destekleyen bir bölgede, kaynak bölgenin kullanılabilirlik alanlarından herhangi birinde dağıtılabilir.
Çok bölgeli dağıtım	Kaynakların birden çok Azure bölgesine dağıtıldığı bir dağıtım modeli.
Eşleştirilmiş bölgeler	İki Azure bölgesi arasındaki ilişki. Bazı Azure bölgeleri , belirli türlerde çok bölgeli çözümleri etkinleştirmek için tanımlanmış başka bir bölgeye bağlanır. Daha yeni Azure bölgeleri eşlenmez.
Region	Bir veri merkezi kümesi içeren coğrafi çevre.
Bölge mimarisi	Kullanılabilirlik alanlarının sayısı ve bölgenin başka bir bölgeyle eşlenip eşlenmediği dahil olmak üzere Azure bölgesinin belirli yapılandırması.
Zaman uyumlu çoğaltma	Verilerin birden çok konuma yazıldığı ve işlendiği bir veri çoğaltma yaklaşımı. Genel yazma işleminin tamam olduğu kabul edilmeden önce her konumun yazma işleminin tamamlanmasını kabul etmesi gerekir.
Bölgesel (sabitlenmiş) dağıtım	Kaynağın belirli bir kullanılabilirlik alanına dağıtıldığı dağıtım modeli.
Alanlar arası yedekli dağıtım	Bir kaynağın birden çok kullanılabilirlik alanına dağıtıldığı dağıtım modeli. Microsoft, bir bölgede kesinti yaşandığında veri eşitlemeyi, trafik dağıtımlarını ve yük devretmeyi yönetir.

Temel tasarım stratejileri

Azure büyük bir küresel ayak izine sahiptir. Azure bölgesi , bir dizi veri merkezi içeren bir coğrafi çevredir. Azure bölgeleri ve kullanılabilirlik alanları hakkında tam bilgi sahibi olmanız gerekir.

Azure bölgeleri, bölge mimarileri olarak da adlandırılan çeşitli yapılandırmalara sahiptir.

Birçok Azure bölgesi, ayrılmış veri merkezi grupları olan kullanılabilirlik alanları sağlar. Bir bölge içinde, kullanılabilirlik alanları diğer kullanılabilirlik alanlarına düşük gecikme süreli bağlantılara sahip olacak kadar yakındır, ancak yerel kesintilerden veya hava durumundan birden fazla kişinin etkilenme olasılığını azaltmak için yeterince uzaktadır. Kullanılabilirlik alanları bağımsız güç, soğutma ve ağ altyapısına sahiptir. Bir bölgede kesinti yaşanırsa bölgesel hizmetler, kapasite ve yüksek kullanılabilirlik diğer bölgeler tarafından desteklenmek üzere tasarlanmıştır.

Aşağıdaki diyagramda birkaç örnek Azure bölgesi gösterilmektedir. Bölgeler 1 ve 2 kullanılabilirlik alanlarını destekler.

Kullanılabilirlik alanları içeren bir Azure bölgesine dağıtım yaparsanız, birden çok kullanılabilirlik bölgesini birlikte kullanabilirsiniz. Birden çok kullanılabilirlik alanı kullanarak, uygulamanızın ve verilerinizin ayrı kopyalarını büyük bir metropoldeki ayrı fiziksel veri merkezlerinde tutabilirsiniz.

Bir çözümde kullanılabilirlik alanlarını kullanmanın iki yolu vardır:

• Bölgesel kaynaklar belirli bir kullanılabilirlik alanına sabitlenir. Yüksek güvenilirlik gereksinimlerini karşılamak için farklı bölgelerde birden çok bölgesel dağıtımı birleştirebilirsiniz. Veri çoğaltmayı yönetmek ve istekleri bölgeler arasında dağıtmak sizin sorumluluğundadır. Tek bir kullanılabilirlik alanında kesinti oluşursa, başka bir kullanılabilirlik alanına yük devretme sizin sorumluluğundadır.
• Alanlar arası yedekli kaynaklar birden çok kullanılabilirlik alanına yayılır. Microsoft, istekleri bölgelere yayma ve verilerin bölgeler arasında çoğaltılması gibi işlemleri yönetir. Tek bir kullanılabilirlik alanında bir kesinti oluşursa, Microsoft yük devretmeyi otomatik olarak yönetir.

Azure hizmetleri bu yaklaşımlardan birini veya her ikisini destekler. Hizmet olarak platform (PaaS) hizmetleri genellikle alanlar arası yedekli dağıtımları destekler. Hizmet olarak altyapı (IaaS) hizmetleri genellikle bölgesel dağıtımları destekler. Azure hizmetlerinin kullanılabilirlik alanlarıyla nasıl çalıştığı hakkında daha fazla bilgi için bkz. Kullanılabilirlik alanı desteğine sahip Azure hizmetleri.

Microsoft hizmetlere güncelleştirme dağıttığında, sizin için en az kesintiye neden olan yaklaşımları kullanmaya çalışırız. Örneğin, güncelleştirmeleri tek seferde tek bir kullanılabilirlik alanına dağıtmayı hedefliyoruz. Güncelleştirme devam ederken iş yükü diğer bölgelerde çalışmaya devam ettiğinden bu yaklaşım güncelleştirmelerin etkin bir iş yükü üzerindeki etkisini azaltabilir. Ancak, platform yükseltmeleri sırasında iş yüklerinin çalışmaya devam etmesini sağlamak nihai olarak iş yükü ekibinin sorumluluğundadır. Örneğin, esnek düzenleme moduyla sanal makine ölçek kümelerini veya çoğu Azure PaaS hizmetini kullandığınızda, Azure platform güncelleştirmelerinin etkisini azaltmak için kaynaklarınızı akıllıca yerleştirir. Ayrıca, diğer örnekler yükseltilirken bazı örneklerin kullanılabilir durumda kalması için fazla sağlamayı (bir kaynağın daha fazla örneğini dağıtma) göz önünde bulundurabilirsiniz. Azure'ın güncelleştirmeleri nasıl dağıttığı hakkında daha fazla bilgi için bkz. Güvenli dağıtım uygulamalarını geliştirme.

Birçok bölgenin eşleştirilmiş bir bölgesi de vardır. Eşleştirilmiş bölgeler, çok bölgeli dağıtım yaklaşımlarının belirli türlerini destekler. Daha yeni bazı bölgelerin birden çok kullanılabilirlik alanı vardır ve eşleştirilmiş bir bölgesi yoktur. Bu bölgelere çok bölgeli çözümler dağıtmaya devam edebilirsiniz, ancak kullandığınız yaklaşımlar farklı olabilir.

Azure'ın bölgeleri ve kullanılabilirlik alanlarını nasıl kullandığı hakkında daha fazla bilgi için bkz. Azure bölgeleri ve kullanılabilirlik alanları nedir?

Paylaşılan sorumlulukları anlama

Paylaşılan sorumluluk ilkesi, sorumlulukların bulut sağlayıcısı (Microsoft) ile sizin aranızda nasıl bölündüğünü açıklar. Kullandığınız hizmetlerin türüne bağlı olarak, hizmetin çalıştırılmasıyla ilgili daha fazla veya daha az sorumluluk üstlenebilirsiniz.

Microsoft, gereksinimlerinizi karşılamak için çözümünüzü tasarlama konusunda size esneklik sağlayan kullanılabilirlik alanları ve bölgeleri sağlar. Yönetilen hizmetleri kullandığınızda Microsoft, kaynaklarınızın yönetim sorumluluklarından daha fazlasını üstlenir. Bu sorumluluklar veri çoğaltma, yük devretme, yeniden çalışma ve dağıtılmış bir sistemi çalıştırmayla ilgili diğer görevleri bile içerebilir.

Kendi kodunuzun hataları düzgün bir şekilde işlemek için önerilen uygulamalar ve tasarım desenleri olması gerekir. Bu uygulamalar, kullanılabilirlik alanı veya bölge yük devretmesi gerçekleştiğinde gerçekleşenler gibi yük devretme işlemleri sırasında daha da önemlidir çünkü bölgeler veya bölgeler arasında yük devretme genellikle uygulamanızın hizmetlerle bağlantıları yeniden denemesini gerektirir.

Önemli iş ve iş yükü gereksinimlerini belirleme

Çözümünüzde kullanılabilirlik alanlarını ve bölgelerini kullanma hakkında bilinçli bir karar vermek için gereksinimlerinizi anlamanız gerekir. Bu gereksinimler, çözüm tasarımcıları ve iş paydaşları arasındaki tartışmalar tarafından yönlendirilmelidir.

Risk toleransı

Farklı kuruluşların farklı risk toleransı dereceleri vardır. Bir kuruluşta bile risk toleransı genellikle her iş yükü için farklıdır. Çoğu iş yükünün son derece yüksek kullanılabilirliğe ihtiyacı yoktur. Ancak bazı iş yükleri o kadar önemlidir ki, geniş bir coğrafi alanı etkileyen büyük doğal afetler gibi olası olmayan riskleri azaltmaya bile değer.

Bu tabloda, bulut ortamında göz önünde bulundurmanız gereken yaygın risklerden birkaçı listelenir:

Risk	Örnekler	Olasılığını
Donanım kesintisi	Sabit disk veya ağ donanımıyla ilgili sorun. Ana bilgisayar yeniden başlatılır.	Yüksek. Tüm dayanıklılık stratejilerinin bu riskleri hesaba vermesi gerekir.
Veri merkezi kesintisi	Veri merkezinin tamamında güç, soğutma veya ağ arızası. Metropol bölgesinin bir bölümünde doğal afet.	Orta
Bölge kesintisi	Geniş bir coğrafi alanı etkileyen büyük doğal afetler. Bir veya daha fazla Azure hizmetinin tüm bölgede kullanılamaz duruma geldiğini belirten ağ veya hizmet sorunu.	Düşük

Her iş yükü için olası her riski azaltmak ideal olacaktır, ancak bunu yapmak pratik veya uygun maliyetli değildir. Azaltmanız gereken riskler hakkında bilinçli kararlar verebilmeniz için iş paydaşlarıyla açık bir tartışma yapmak önemlidir.

İpucu

Güvenilirlik hedeflerinden bağımsız olarak, tüm iş yüklerinin olağanüstü durum kurtarma için bazı risk azaltmaları olmalıdır. İş yükünüz yüksek güvenilirlik hedefleri gerektiriyorsa, azaltma stratejilerinizin kapsamlı olması ve düşük olasılıklı olayların riskini azaltmanız gerekir. Diğer iş yükleri için, hangi riskleri kabul etmeye hazır olduğunuz ve hangi riskleri azaltmanız gerektiği konusunda bilinçli bir karar verin.

Dayanıklılık gereksinimleri

Kurtarma süresi hedefi (RTO) ve kurtarma noktası hedefi (RPO) dahil olmak üzere iş yükünüz için dayanıklılık gereksinimlerini anlamanız önemlidir. Bu hedefler, hangi yaklaşımları eleyebileceğinize karar vermenize yardımcı olur. Net gereksinimleriniz yoksa, hangi yaklaşımı izleyeceğiniz konusunda bilinçli bir karara varamazsınız. Daha fazla bilgi için bkz . İşlevsel ve işlev dışı gereksinimleri hedefleme.

Hizmet düzeyi hedefleri

Çözümünüzün beklenen çalışma süresi hizmet düzeyi hedefini (SLO) anlamanız gerekir. Örneğin, çözümünüzün %99,9 çalışma süresini karşılaması gereken bir iş gereksiniminiz olabilir.

Azure, her hizmet için hizmet düzeyi sözleşmeleri (SLA) sağlar. SLA, hizmetten beklemeniz gereken çalışma süresi düzeyini ve beklenen SLA'yı elde etmek için karşılamanız gereken koşulları gösterir. Ancak, Azure SLA'sının hizmetin kullanılabilirliğini gösterdiği yöntemin her zaman iş yükünüzün durumunu göz önünde bulundurduğunuz yöntemle eşleşmediğini unutmayın.

Mimari kararlarınız çözümünüzün bileşik SLO'larını etkiler. Genel olarak, çözümünüzde ne kadar fazla yedeklilik oluşturursanız, SLO'nuz o kadar yüksek olabilir. Birçok Azure hizmeti, hizmetleri alanlar arası yedekli veya çok bölgeli bir yapılandırmada dağıttığınızda daha yüksek SLA'lar sağlar. Hizmetin dayanıklılığını ve SLA'sını nasıl en üst düzeye çıkarabileceğinizi anladığınızdan emin olmak için kullandığınız her Azure hizmetinin SLA'larını gözden geçirin.

Veri yerleşimi

Bazı kuruluşlar, verilerinin depolanabileceği ve işlenebileceği fiziksel konumlara kısıtlamalar getirmektedir. Bazen bu gereksinimler yasal veya mevzuat standartlarına bağlıdır. Diğer durumlarda, bir kuruluş müşteri endişelerini önlemek için bir veri yerleşimi ilkesi benimsemeye karar verebilir. Katı veri yerleşimi gereksinimleriniz varsa, tek bölgeli bir dağıtım kullanmanız veya Azure bölgelerinin ve hizmetlerinin bir alt kümesini kullanmanız gerekebilir.

Not

Veri yerleşimi gereksinimleriniz hakkında temelsiz varsayımlarda bulunmaktan kaçının. Belirli mevzuat standartlarına uymanız gerekiyorsa, bu standartların gerçekte ne belirttiğini doğrulayın.

Kullanıcı konumu

Kullanıcılarınızın nerede olduğunu anlayarak, gecikme süresini ve güvenilirliği ihtiyaçlarınıza göre iyileştirme konusunda bilinçli bir karar veresiniz. Azure, coğrafi olarak dağınık bir kullanıcı tabanını desteklemek için birçok seçenek sunar.

Kullanıcılarınız tek bir alanda yoğunlaşıyorsa, tek bölgeli dağıtım işlem gereksinimlerinizi basitleştirebilir ve maliyetlerinizi düşürebilir. Ancak, tek bölgeli bir dağıtımın güvenilirlik gereksinimlerinizi karşılayıp karşılamadığını göz önünde bulundurmanız gerekir. Görev açısından kritik uygulamalarda, kullanıcılarınız birlikte konumlandırılmış olsa bile çok bölgeli bir dağıtım kullanmanız gerekir.

Kullanıcılarınız coğrafi olarak dağılmışsa, iş yükünüzü birden çok bölgeye dağıtmak mantıklı olabilir. Azure hizmetleri, çok bölgeli dağıtımı desteklemek için farklı özellikler sağlar ve kullanıcı deneyiminizi geliştirmek ve uygulamalarınızı kullanıcı tabanınıza daha yakın hale getirmek için Azure'ın küresel ayak izini kullanabilirsiniz. Dağıtım Damgaları desenini veya Geodes desenini kullanabilir ya da kaynaklarınızı birden çok bölgede çoğaltabilirsiniz.

Kullanıcılarınız farklı coğrafi alanlarda olsa bile, çok bölgeli bir dağıtıma ihtiyacınız olup olmadığını göz önünde bulundurun. Azure Front Door tarafından sağlanan hızlandırma gibi genel trafik hızlandırmasını kullanarak gereksinimlerinizi tek bir bölgede sağlayıp sağlayamayacağınızı düşünün.

Bütçe

Kısıtlanmış bir bütçe kapsamında çalışırsanız, yedekli iş yükü bileşenlerinin dağıtılmasıyla ilgili maliyetleri göz önünde bulundurmanız önemlidir. Bu maliyetler ek kaynak ücretlerini, ağ maliyetlerini ve daha fazla kaynağı ve daha karmaşık bir ortamı yönetmenin operasyonel maliyetlerini içerebilir.

Karmaşıklık

Çözüm mimarinizde gereksiz karmaşıklığı önlemek iyi bir uygulamadır. Ne kadar karmaşık hale getirirseniz, mimarinizle ilgili kararlar almak o kadar zorlaşır. Karmaşık mimarilerin çalışması daha zordur, güvenliğini sağlamak zordur ve genellikle daha az performanslıdır. Basitlik ilkesini izleyin.

Azure kolaylaştırma

Azure, bölgeler ve kullanılabilirlik alanları sağlayarak gereksinimlerinize uygun bir dağıtım yaklaşımı seçmenizi sağlar. Aralarından seçim yapabileceğiniz birçok yaklaşım vardır ve bunların her biri avantajlar sağlar ve maliyetler doğurır.

Kullanabileceğiniz dağıtım yaklaşımlarını göstermek için örnek bir senaryoyu göz önünde bulundurun. Bir tür depolama alanına veri yazan bir uygulama içeren yeni bir çözüm dağıtmayı düşündüğünüzü varsayalım:

Bu örnek belirli azure hizmetlerine özgü değildir. Temel kavramların gösterilmesi için basit bir örnek sağlamak için tasarlanmıştır.

Bu çözümü dağıtmanın birden çok yolu vardır. Her yaklaşım farklı avantajlar sağlar ve farklı maliyetler doğurır. Yüksek düzeyde yerel olarak yedekli, bölgesel (sabitlenmiş), alanlar arası yedekli veya çok bölgeli dağıtımı düşünebilirsiniz. Bu tabloda bazı önemli sorunlar özetlemektedir:

Yapı Taşı	Yerel olarak yedekli	Bölgesel (sabitlenmiş)	Alanlar arası yedekli	Çok bölgeli
Güvenilirlik	Düşük güvenilirlik	Yaklaşıma bağlıdır	Yüksek veya çok yüksek güvenilirlik	Yüksek veya çok yüksek güvenilirlik
Maliyet İyileştirmesi	Düşük maliyet	Yaklaşıma bağlıdır	Orta maliyet	Yüksek maliyet
Performans Verimliliği	Kabul edilebilir performans (çoğu iş yükü için)	Yüksek performans	Kabul edilebilir performans (çoğu iş yükü için)	Yaklaşıma bağlıdır
İşlem Mükemmelliği	Düşük operasyonel gereksinimler	Yüksek operasyonel gereksinimler	Düşük operasyonel gereksinimler	Yüksek operasyonel gereksinimler

Bu tabloda kullanabileceğiniz yaklaşımlardan bazıları ve bunların mimarinizi nasıl etkilediği özetlenmektedir:

Mimari kaygı	Yerel olarak yedekli	Bölgesel (sabitlenmiş)	Alanlar arası yedekli	Çok bölgeli
Veri yerleşimiyle uyumluluk	Yüksek	Yüksek	Yüksek	Bölgeye bağlıdır
Bölgesel kullanılabilirlik	Tüm bölgeler	Kullanılabilirlik alanları olan bölgeler	Kullanılabilirlik alanları olan bölgeler	Bölgeye bağlıdır

Bu makalenin geri kalanında, önceki tabloda listelenen yaklaşımların her biri açıklanmaktadır. Yaklaşım listesi kapsamlı değildir. Birden çok yaklaşımı birleştirmeye veya çözümünüzün farklı bölümlerinde farklı yaklaşımlar kullanmaya karar vekleyebilirsiniz.

Dağıtım yaklaşımı 1: Yerel olarak yedekli dağıtımlar

Kaynaklarınızı dağıtırken birden çok kullanılabilirlik alanı veya bölge belirtmezseniz, Azure kaynakların tek bir veri merkezine mi dağıtılacağı yoksa bölgedeki birden çok veri merkezine mi bölündüğü konusunda herhangi bir garanti vermez. Bazı durumlarda Azure, kaynağınızı kullanılabilirlik alanları arasında da taşıyabilir.

Çoğu Azure kaynağı, platform tarafından yönetilen bir veri merkezinde yüksek SLA'lar ve yerleşik yedeklilik ile varsayılan olarak yüksek oranda kullanılabilir. Ancak güvenilirlik açısından bakıldığında, bölgenin herhangi bir bölümünde kesinti yaşanırsa iş yükünüzün etkilenme olasılığı vardır. Bu durumda çözümünüz kullanılamıyor olabilir veya verileriniz kaybolabilir.

Yüksek gecikme süresine duyarlı iş yükleri için bu yaklaşım performansın düşmesine de neden olabilir. İş yükü bileşenleriniz aynı veri merkezinde birlikte bulunamayabilir, bu nedenle bölge içi trafik için bazı gecikme süreleri gözlemleyebilirsiniz. Azure ayrıca hizmet örneklerinizi kullanılabilirlik alanları arasında saydam bir şekilde taşıyabilir ve bu da performansı biraz etkileyebilir. Ancak, bu çoğu iş yükü için bir sorun değildir.

Bu tabloda bazı önemli sorunlar özetlemektedir:

Yapı Taşı	Etki
Güvenilirlik	Düşük güvenilirlik. Bir veri merkezi başarısız olursa hizmetler kesintiye maruz kalır. Ancak, diğer hata türlerine dayanıklı olacak bir uygulama oluşturabilirsiniz.
Maliyet İyileştirmesi	En düşük maliyet. Her kaynağın tek bir örneğine sahip olmanız gerekir ve bölgeler arası veya bölgeler arası bant genişliği maliyetlerine sahip olmazsınız.
Performans Verimliliği	Çoğu iş yükü için:Kabul edilebilir performans. Bu yaklaşım büyük olasılıkla tatmin edici bir performans sağlar. Yüksek gecikme süresine duyarlı iş yükleri için:Düşük performans. Bileşenlerin aynı kullanılabilirlik alanında bulunması garanti edilmediğinden gecikme süresine duyarlı bileşenler için daha düşük performans görebilirsiniz.
İşlem Mükemmelliği	Yüksek operasyonel verimlilik. Her kaynağın tek bir örneğini dağıtmanız ve yönetmeniz yeterlidir.

Bu tabloda, mimari açıdan bazı sorunlar özetlemektedir:

Mimari kaygı	Etki
Veri yerleşimiyle uyumluluk	Yüksek. Bu yaklaşımı kullanan bir çözüm dağıttığınızda veriler seçtiğiniz Azure bölgesinde depolanır.
Bölgesel kullanılabilirlik	Yüksek. Bu yaklaşım herhangi bir Azure bölgesinde kullanılabilir.

Bölgeler arasında yedekleme ile yerel olarak yedekli dağıtımlar

Altyapınızın ve verilerinizin düzenli yedeklemelerini ikincil bir bölgeye gerçekleştirerek yerel olarak yedekli bir dağıtımı genişletebilirsiniz. Bu yaklaşım, birincil bölgenizdeki bir kesintiye karşı azaltmak için ek bir koruma katmanı ekler. Şu şekilde görünür:

Bu yaklaşımı uyguladığınızda, RTO ve RPO'nuzu dikkatle dikkate almanız gerekir:

• Kurtarma süresi: Bölgesel bir kesinti oluşursa çözümünüzü kurtarma sürenizi etkileyen başka bir Azure bölgesinde yeniden oluşturmanız gerekebilir. Büyük bir olağanüstü durum oluştuğunda başka bir bölgeye hızla yeniden dağıtabilmeniz için kod olarak altyapı (IaC) yaklaşımını kullanarak çözümünüzü oluşturmayı göz önünde bulundurun. Dağıtım araçlarınızın ve işlemlerinizin uygulamalarınız kadar dayanıklı olduğundan emin olun; böylece kesinti olsa bile çözümünüzü yeniden dağıtmak için bunları kullanabilirsiniz. Çözümünüzü yeniden çalışma durumuna geri yüklemek için gereken adımları planlayın ve prova edin.
• Kurtarma noktası: Yedekleme sıklığınız, karşılaşabileceğiniz veri kaybı miktarını (kurtarma noktanız) belirler. RPO'nuzu karşılamak için genellikle yedeklemelerin sıklığını denetleyebilirsiniz.

Bu tabloda bazı önemli sorunlar özetlemektedir:

Yapı Taşı	Etki
Güvenilirlik	Orta düzeyde güvenilirlik. Bir veri merkezi başarısız olursa hizmetler kesintiye maruz kalır. Veriler coğrafi olarak ayrılmış bir bölgeye zaman uyumsuz olarak yedeklenerek veri kaybını en aza indirerek tam bölge kesintisinin etkisini azaltır. Tam bölge kesintisinde, işlemleri el ile başka bir bölgeye geri yükleyebilirsiniz. Ancak kurtarma işlemleri karmaşık olabilir ve diğer bölgeye el ile geri yüklemek zaman alabilir.
Maliyet İyileştirmesi	Düşük maliyetli. Genellikle, başka bir bölgeye yedekleme eklemek, yerel olarak yedekli bir kaynağın dağıtılmasından yalnızca biraz daha maliyetlidir.
Performans Verimliliği	Çoğu iş yükü için:Kabul edilebilir performans. Bu yaklaşım büyük olasılıkla tatmin edici bir performans sağlar. Yüksek gecikme süresine duyarlı iş yükleri için:Düşük performans. Bileşenlerin aynı kullanılabilirlik alanında bulunması garanti edilmediğinden gecikme süresine duyarlı bileşenler için daha düşük performans görebilirsiniz.
İşlem Mükemmelliği	Bir bölge içindeki herhangi bir kesinti sırasında:Düşük operasyonel verimlilik. Yük devretme sizin sorumluluğunuzdadır ve el ile işlemler ve yeniden dağıtımlar gerektirebilir.

Bu tabloda, mimari açıdan bazı sorunlar özetlemektedir:

Mimari kaygı	Etki
Veri yerleşimiyle uyumluluk	Bölge seçimine bağlıdır. Veriler öncelikle belirttiğiniz Azure bölgesinde depolanır. Ancak yedeklemelerinizi depolamak için başka bir bölge seçmeniz gerekir, bu nedenle veri yerleşimi gereksinimlerinizle uyumlu bir bölge seçmeniz önemlidir.
Bölgesel kullanılabilirlik	Yüksek. Bu yaklaşımı herhangi bir Azure bölgesinde kullanabilirsiniz.

Dağıtım yaklaşımı 2: Bölgesel (sabitlenmiş) dağıtımlar

Bölgesel dağıtımda, kaynaklarınızın belirli bir kullanılabilirlik alanına dağıtılması gerektiğini belirtirsiniz. Bu yaklaşım bazen bölgeye sabitlenmiş dağıtım olarak adlandırılır.

Bölgesel yaklaşım, bileşenleriniz arasındaki gecikme süresini azaltır. Ancak tek başına çözümünüzün dayanıklılığını artırmaz. Dayanıklılığınızı artırmak için bileşenlerinizin birden çok örneğini birden çok kullanılabilirlik alanına dağıtmanız ve her örnek arasında trafiğin nasıl yönlendirılacağına karar vermeniz gerekir. Bu örnekte etkin-pasif trafik yönlendirme yaklaşımı gösterilmektedir:

Önceki örnekte, bir yük dengeleyici birden çok kullanılabilirlik alanına dağıtılmıştır. Bölge kesintisi söz konusu bölgeye dağıtılan ağ kaynaklarını da etkileyebileceğinden, trafiği farklı kullanılabilirlik alanlarındaki örnekler arasında nasıl yönlendirdiğiniz göz önünde bulundurulması önemlidir. Ayrıca, bir bölgeye hiç dağıtılmayan Azure Front Door veya Azure Traffic Manager gibi genel bir yük dengeleyici kullanmayı da düşünebilirsiniz.

Bölgesel dağıtım modeli kullandığınızda birçok sorumluluk alırsınız:

• Kaynakları her kullanılabilirlik alanına dağıtmanız ve bu kaynakları tek tek yapılandırmanız ve yönetmeniz gerekir.
• Kullanılabilirlik alanları arasında verileri nasıl ve ne zaman çoğaltabileceğinize karar vermeniz ve ardından çoğaltmayı yapılandırmanız ve yönetmeniz gerekir.
• İstekleri, örneğin bir yük dengeleyici kullanarak doğru kaynaklara dağıtmak sizin sorumluluğunızdadır. Yük dengeleyicinin dayanıklılık gereksinimlerinizi karşıladığından emin olmanız gerekir. Ayrıca etkin-pasif mi yoksa etkin-etkin istek dağıtım modeli mi kullanacağınıza karar vermeniz gerekir.
• Kullanılabilirlik alanında bir kesinti yaşanırsa, trafiği başka bir kullanılabilirlik alanındaki kaynaklara göndermek için yük devretmeyi işlemeniz gerekir.

Birden çok kullanılabilirlik alanında etkin-pasif dağıtım bazen bölge içi DR veya Metro DR olarak adlandırılır.

Bu tabloda bazı önemli sorunlar özetlemektedir:

Yapı Taşı	Etki
Güvenilirlik	Tek bir kullanılabilirlik alanında dağıtıldığında:Düşük güvenilirlik. Bölgesel dağıtım, veri merkezi veya kullanılabilirlik alanındaki bir kesintiye dayanıklılık sağlamaz. Yüksek dayanıklılık elde etmek için yedekli kaynakları birden çok kullanılabilirlik alanına dağıtmanız gerekir. Birden çok kullanılabilirlik alanına dağıtıldığında:Yüksek güvenilirlik. Hizmetler bir veri merkezine veya kullanılabilirlik alanı kesintisine dayanıklı hale getirilebilir.
Maliyet İyileştirmesi	Tek bir kullanılabilirlik alanında dağıtıldığında:Düşük maliyetli. Tek bölgeli dağıtım, her kaynağın yalnızca tek bir örneğini gerektirir. Birden çok kullanılabilirlik alanına dağıtıldığında:Yüksek maliyet. Kaynakların her biri ayrı olarak faturalandırılan birden çok örneğini dağıtırsınız. Veri çoğaltması için bölgeler arası trafik için de ödeme yapmanız gerekir.
Performans Verimliliği	Yüksek performans. bir isteğe hizmet veren bileşenler aynı kullanılabilirlik alanında bulunduğunda gecikme süresi çok düşük olabilir.
İşlem Mükemmelliği	Düşük operasyonel verimlilik. Hizmetinizin birden çok örneğini yapılandırmanız ve yönetmeniz gerekir. Kullanılabilirlik alanları arasında verileri çoğaltmanız gerekir. Kullanılabilirlik alanı kesintisi sırasında yük devretme sizin sorumluluğunuzdadır.

Bu tabloda, mimari açıdan bazı sorunlar özetlemektedir:

Mimari kaygı	Etki
Veri yerleşimiyle uyumluluk	Yüksek. Bu yaklaşımı kullanan bir çözüm dağıttığınızda veriler seçtiğiniz Azure bölgesinde depolanır.
Bölgesel kullanılabilirlik	Kullanılabilirlik alanları olan bölgeler. Bu yaklaşım kullanılabilirlik alanlarını destekleyen tüm bölgelerde kullanılabilir.

Bu yaklaşım genellikle sanal makineleri temel alan iş yükleri için kullanılır. Bölgesel dağıtımları destekleyen hizmetlerin tam listesi için bkz . Kullanılabilirlik alanı hizmeti ve bölgesel destek.

Bölgesel dağıtım planlarken, kullanmayı planladığınız kullanılabilirlik alanlarında kullandığınız Azure hizmetlerinin desteklendiğini doğrulayın. Örneğin, her kullanılabilirlik alanında hangi sanal makine SKU'larının kullanılabilir olduğunu listelemek için bkz. VM SKU kullanılabilirliğini denetleme.

İpucu

Bir kaynağı belirli bir kullanılabilirlik alanına dağıttığınızda, bölge numarasını seçersiniz. Bölge numaralarının sırası her Azure aboneliği için farklıdır. Kaynakları birden çok Azure aboneliğine dağıtırsanız, her abonelikte kullanmanız gereken bölge numaralarını doğrulayın. Daha fazla bilgi için bkz . Fiziksel ve mantıksal kullanılabilirlik alanları.

Dağıtım yaklaşımı 3: Alanlar arası yedekli dağıtımlar

Bu yaklaşımı kullandığınızda, uygulama katmanınız birden çok kullanılabilirlik alanına yayılır. İstekler geldiğinde, hizmette yerleşik olarak bulunan bir yük dengeleyici (kendisi kullanılabilirlik alanlarına yayılır) istekleri her kullanılabilirlik alanındaki örnekler arasında dağıtır. Kullanılabilirlik alanında bir kesinti yaşanırsa yük dengeleyici trafiği iyi durumdaki kullanılabilirlik alanlarındaki örneklere yönlendirir.

Depolama katmanınız da birden çok kullanılabilirlik alanına yayılır. Uygulamanızın verilerinin kopyaları zaman uyumlu çoğaltma yoluyla birden çok kullanılabilirlik alanına dağıtılır. Uygulama verilerde bir değişiklik yaptığında, depolama hizmeti değişikliği birden çok kullanılabilirlik alanına yazar ve işlem yalnızca bu değişikliklerin tümü tamamlandığında tamamlanmış olarak kabul edilir. Bu işlem, her kullanılabilirlik alanının her zaman verilerin güncel bir kopyasına sahip olmasını sağlar. Kullanılabilirlik alanında bir kesinti yaşanırsa, aynı verilere erişmek için başka bir kullanılabilirlik alanı kullanılabilir.

Alanlar arası yedekli bir yaklaşım, çözümünüzün veri merkezi kesintileri gibi sorunlara karşı dayanıklılığını artırır. Ancak veriler zaman uyumlu olarak çoğaltıldığı için uygulamanızın verilerin bir metropol alanının farklı bölümlerinde olabilecek birden çok ayrı konuma yazılması için beklemesi gerekir. Çoğu uygulama için bölgeler arası iletişimde gecikme süresi göz ardı edilebilir. Ancak, gecikme süresine duyarlı bazı iş yükleri için kullanılabilirlik alanları arasında zaman uyumlu çoğaltma uygulamanın performansını etkileyebilir.

Bu tabloda bazı önemli sorunlar özetlemektedir:

Yapı Taşı	Etki
Güvenilirlik	Yüksek güvenilirlik. Hizmetler, veri merkezi veya kullanılabilirlik alanı kesintisine karşı dayanıklıdır. Veriler zaman uyumlu olarak kullanılabilirlik alanları arasında çoğaltılır ve gecikme olmaz.
Maliyet İyileştirmesi	Orta maliyet. Kullandığınız hizmetlere bağlı olarak, alanlar arası yedekliliği etkinleştirmek için daha yüksek hizmet katmanları için bazı maliyetler veya bazı bölgeler arası ağ maliyetlerine neden olabilirsiniz.
Performans Verimliliği	Çoğu iş yükü için:Kabul edilebilir performans. Bu yaklaşım büyük olasılıkla tatmin edici bir performans sağlar. Yüksek gecikme süresine duyarlı iş yükleri için:Düşük performans. Bazı bileşenler bölgeler arası trafik veya veri çoğaltma süresi nedeniyle gecikme süresine duyarlı olabilir.
İşlem Mükemmelliği	Yüksek operasyonel verimlilik. Genellikle her kaynağın tek bir mantıksal örneğini yönetmeniz gerekir. Çoğu hizmet için, kullanılabilirlik alanı kesintisi sırasında yük devretme Microsoft'un sorumluluğundadır ve otomatik olarak gerçekleşir.

Bu tabloda, mimari açıdan bazı sorunlar özetlemektedir:

Mimari kaygı	Etki
Veri yerleşimiyle uyumluluk	Yüksek. Bu yaklaşımı kullanan bir çözüm dağıttığınızda veriler seçtiğiniz Azure bölgesinde depolanır.
Bölgesel kullanılabilirlik	Kullanılabilirlik alanları olan bölgeler. Bu yaklaşım kullanılabilirlik alanlarını destekleyen tüm bölgelerde kullanılabilir.

Bu yaklaşım Azure Sanal Makine Ölçek Kümeleri, Azure App Service, Azure İşlevleri, Azure Kubernetes Service, Azure Depolama Azure SQL gibi birçok Azure hizmetinde mümkündür. Azure Service Bus ve diğerleri. Alanlar arası yedekliliği destekleyen hizmetlerin tam listesi için bkz . Kullanılabilirlik alanı hizmeti ve bölgesel destek.

Bölgeler arasında yedekleme ile alanlar arası yedekli dağıtımlar

Altyapınızın ve verilerinizin düzenli yedeklemelerini ikincil bir bölgeye gerçekleştirerek alanlar arası yedekli dağıtımı genişletebilirsiniz. Bu yaklaşım, alanlar arası yedekli bir yaklaşımın avantajlarını sunar ve tam bölge kesintisi olasılığının çok düşük olduğu bir olayı azaltmak için bir koruma katmanı ekler.

Bu yaklaşımı uyguladığınızda, RTO ve RPO'nuzu dikkatle dikkate almanız gerekir:

• Kurtarma süresi: Bölgesel bir kesinti oluşursa çözümünüzü kurtarma sürenizi etkileyen başka bir Azure bölgesinde yeniden oluşturmanız gerekebilir. Büyük bir olağanüstü durum sırasında başka bir bölgeye hızla yeniden dağıtabilmeniz için bir IaC yaklaşımı kullanarak çözümünüzü oluşturmayı göz önünde bulundurun. Dağıtım araçlarınızın ve işlemlerinizin uygulamalarınız kadar dayanıklı olduğundan emin olun, böylece bir kesinti yaşansa bile çözümünüzü yeniden dağıtmak için bunları kullanabilirsiniz. Çözümünüzü yeniden çalışma durumuna geri yüklemek için gereken adımları planlayın ve prova edin.

• Kurtarma noktası: Yedekleme sıklığınız, karşılaşabileceğiniz veri kaybı miktarını (kurtarma noktanız) belirler. Genellikle RPO'nuzu karşılamak için yedeklemelerin sıklığını denetleyebilirsiniz.

İpucu

Bu yaklaşım genellikle tüm mimari kaygılar için iyi bir denge sağlar. Hangi yaklaşımı kullanacağınızdan emin değilseniz, bu dağıtım türüyle başlayın.

Bu tabloda bazı önemli sorunlar özetlemektedir:

Yapı Taşı	Etki
Güvenilirlik	Çok yüksek güvenilirlik. Hizmetler, veri merkezi veya kullanılabilirlik alanı kesintisine karşı dayanıklıdır. Çoğu hizmet için veriler bölgeler arasında otomatik olarak ve gecikme olmadan çoğaltılır. Veriler coğrafi olarak ayrılmış bir bölgeye zaman uyumsuz olarak yedekleniyor. Bu yedekleme, veri kaybını en aza indirerek tam bölge kesintisinin etkisini azaltır. Tam bir bölge kesintisi sonrasında, işlemleri el ile başka bir bölgeye geri yükleyebilirsiniz. Ancak kurtarma işlemleri karmaşık olabilir ve diğer bölgeye el ile geri yüklemek zaman alabilir.
Maliyet İyileştirmesi	Orta maliyet. Genellikle, başka bir bölgeye yedekleme eklemek, bölge yedekliliği uygulamaktan yalnızca biraz daha pahalıya mal olur.
Performans Verimliliği	Çoğu iş yükü için:Kabul edilebilir performans. Bu yaklaşım büyük olasılıkla tatmin edici bir performans sağlar. Yüksek gecikme süresine duyarlı iş yükleri için:Düşük performans. Bazı bileşenler bölgeler arası trafik veya veri çoğaltma süresi nedeniyle gecikme süresine duyarlı olabilir.
İşlem Mükemmelliği	Kullanılabilirlik alanı kesintisi sırasında:Yüksek operasyonel verimlilik. Yük devretme Microsoft'un sorumluluğundadır ve otomatik olarak gerçekleşir. Bölgesel bir kesinti sırasında:Düşük operasyonel verimlilik. Yük devretme sizin sorumluluğunuzdadır ve el ile işlemler ve yeniden dağıtımlar gerektirebilir.

Bu tabloda, mimari açıdan bazı sorunlar özetlemektedir:

Mimari kaygı	Etki
Veri yerleşimiyle uyumluluk	Bölge seçimine bağlıdır. Veriler öncelikle belirttiğiniz Azure bölgesinde depolanır, ancak yedeklemelerinizi depolamak için başka bir bölge seçmeniz gerekir. Veri yerleşimi gereksinimlerinizle uyumlu bir bölge seçin.
Bölgesel kullanılabilirlik	Kullanılabilirlik alanları olan bölgeler. Bu yaklaşım kullanılabilirlik alanlarını destekleyen tüm bölgelerde kullanılabilir.

Dağıtım yaklaşımı 4: Çok bölgeli dağıtımlar

Çözümünüzü geniş bir coğrafi alana dağıtmak için birden çok Azure bölgesini birlikte kullanabilirsiniz. Çözümünüzün güvenilirliğini artırmak veya coğrafi olarak dağıtılmış kullanıcıları desteklemek için bu çok bölgeli yaklaşımı kullanabilirsiniz. Birden çok bölgeye dağıtım yaparak, tek bir bölgede geçici bir kaynak kapasitesi kısıtlaması ile karşılaşma riskini de azaltabilirsiniz. Veri yerleşimi çözümünüz için önemli bir konuysa, verilerinizin yalnızca gereksinimlerinizi karşılayan konumlarda depolandığından emin olmak için hangi bölgeleri kullandığınızı dikkatle göz önünde bulundurun.

Aktif ve pasif bölgeler

Çok bölgeli mimariler karmaşıktır ve çok bölgeli bir çözüm tasarlamanın birçok yolu vardır. Bazı iş yükleri için birden çok bölgenin istekleri aynı anda etkin olarak işlemesi (etkin-etkin dağıtımlar) mantıklıdır. Diğer iş yükleri için bir birincil bölge belirleme ve yük devretme için bir veya daha fazla ikincil bölge (etkin-pasif dağıtımlar) kullanmak daha iyidir. Bu bölüm, bir bölgenin etkin, diğerinin pasif olduğu ikinci senaryoya odaklanır. Etkin-etkin çok bölgeli çözümler hakkında bilgi için bkz . Dağıtım DamgaLarı düzeni ve Coğrafi bölge düzeni.

Veri çoğaltma

Bölgeler arasında iletişim kurmak, bir bölge içinde iletişim kurmaktan çok daha yavaştır. Genel olarak, iki bölge arasındaki daha büyük bir coğrafi uzaklık, verilerin seyahat etmesi gereken fiziksel mesafenin daha uzun olması nedeniyle daha fazla ağ gecikmesine neden olur. İki bölge arasında bağlantı kurduğunuzda beklenen ağ gecikme süresi için bkz. Azure ağ gidiş dönüş gecikmesi istatistikleri .

Bölgeler arası ağ gecikme süresi çözüm tasarımınızı önemli ölçüde etkileyebilir çünkü ek gecikme süresinin veri çoğaltmayı ve diğer işlemleri nasıl etkilediğini dikkatle düşünmeniz gerekir. Birçok çözüm için bölgeler arası mimari, bölgeler arası trafiğin performans üzerindeki etkisini en aza indirmek için zaman uyumsuz çoğaltma gerektirir.

Zaman uyumsuz veri çoğaltma

Bölgeler arasında zaman uyumsuz çoğaltma uyguladığınızda, uygulamanız tüm bölgelerin bir değişikliği onaylamasını beklemez. Değişiklik birincil bölgede işlendikten sonra işlem tamamlandı olarak kabul edilir. Değişiklik daha sonra ikincil bölgelere çoğaltılır. Bu yaklaşım bölgeler arası bağlantı gecikme süresinin uygulama performansını doğrudan etkilememesini sağlar. Ancak çoğaltmadaki gecikme nedeniyle bölge genelinde bir kesinti bazı veri kaybına neden olabilir. Bu veri kaybı, birincil bölgede yazma işlemi tamamlandıktan sonra ancak değişiklik başka bir bölgeye çoğaltılmadan önce bir bölgede kesinti yaşanabileceği için oluşabilir.

Bu tabloda bazı önemli sorunlar özetlemektedir:

Yapı Taşı	Etki
Güvenilirlik	Yüksek güvenilirlik. Çözüm bir veri merkezinde, kullanılabilirlik alanında veya bölgenin tamamında kesintiye dayanıklıdır. Veriler çoğaltılır ancak zaman uyumlu olmayabilir, bu nedenle yük devretme senaryosunda veri kaybı olabilir.
Maliyet İyileştirmesi	Yüksek maliyetli. Her bölgeye ayrı kaynaklar dağıtmanız gerekir ve her kaynak dağıtım ve bakım maliyetlerine neden olur. Bölgeler arasında veri çoğaltma da önemli maliyetler doğurabilir.
Performans Verimliliği	Yüksek performans. Uygulama istekleri bölgeler arası trafik gerektirmez, bu nedenle trafik genellikle düşük gecikme süresine neden olur.
İşlem Mükemmelliği	Düşük operasyonel verimlilik. Kaynakları birden çok bölgede dağıtmanız ve yönetmeniz gerekir. Bölgesel bir kesinti sırasında bölgeler arasında yük devretme de sizin sorumluluğunızdadır.

Bu tabloda, mimari açıdan bazı sorunlar özetlemektedir:

Mimari kaygı	Etki
Veri yerleşimiyle uyumluluk	Bölge seçimine bağlıdır. Bu yaklaşım, iş yükünüzün çalışması için birden çok bölge seçmenizi gerektirir. Veri yerleşimi gereksinimlerinizle uyumlu bölgeleri seçin.
Bölgesel kullanılabilirlik	Birçok Azure bölgesi eşleştirilir. Bazı Azure hizmetleri, verileri otomatik olarak çoğaltmak için eşleştirilmiş bölgeler kullanır. İş yükünüzü çifti olmayan bir bölgede çalıştırıyorsanız , verilerinizi çoğaltmak için farklı bir yaklaşım kullanmanız gerekebilir.

Zaman uyumlu veri çoğaltma

Zaman uyumlu çok bölgeli bir çözüm uygularsanız, işlem tamamlandı olarak kabul edilmeden önce uygulamanızın her Azure bölgesinde yazma işlemlerinin tamamlanmasını beklemesi gerekir. Yazma işlemlerinin beklenerek ortaya çıkan gecikme süresi bölgeler arasındaki mesafeye bağlıdır. Birçok iş yükü için bölgeler arası gecikme, zaman uyumlu çoğaltmanın kullanışlı olamayacak kadar yavaş olmasını sağlayabilir.

Bu tabloda bazı önemli sorunlar özetlemektedir:

Yapı Taşı	Etki
Güvenilirlik	Çok yüksek güvenilirlik. Çözüm bir veri merkezinde, kullanılabilirlik alanında veya bölgenin tamamında kesintiye dayanıklıdır. Veriler her zaman bölgeler arasında eşitlenir, dolayısıyla tam bir bölge kaybı yaşansa bile verileriniz başka bir bölgede kullanılabilir ve tamamlanır.
Maliyet İyileştirmesi	Yüksek maliyetli. Her bölgeye ayrı kaynaklar dağıtmanız gerekir ve her kaynak dağıtım ve bakım maliyetlerine neden olur. Bölgeler arasında veri çoğaltma da önemli maliyetler doğurabilir.
Performans Verimliliği	Düşük performans. Uygulama istekleri için bölgeler arası trafik gerekir. Bölgeler arasındaki uzaklık durumuna bağlı olarak, zaman uyumlu çoğaltma isteklere önemli gecikme süreleri ekleyebilir.
İşlem Mükemmelliği	Düşük operasyonel verimlilik. Kaynakları birden çok bölgede dağıtmanız ve yönetmeniz gerekir. Bölgesel bir kesinti sırasında bölgeler arasında yük devretme de sizin sorumluluğunızdadır.

Bu tabloda, mimari açıdan bazı sorunlar özetlemektedir:

Mimari kaygı	Etki
Veri yerleşimiyle uyumluluk	Bölge seçimine bağlıdır. Bu yaklaşım, iş yükünüzün çalışması için birden çok bölge seçmenizi gerektirir. Veri yerleşimi gereksinimlerinizle uyumlu bölgeleri seçin.
Bölgesel kullanılabilirlik	Birçok Azure bölgesi eşleştirilir. Bazı Azure hizmetleri, verileri otomatik olarak çoğaltmak için eşleştirilmiş bölgeler kullanır. İş yükünüzü çifti olmayan bir bölgede çalıştırıyorsanız , verilerinizi çoğaltmak için farklı bir yaklaşım kullanmanız gerekebilir.

Bölge mimarileri

Çok bölgeli bir çözüm tasarlarken, kullanmayı planladığınız Azure bölgelerinin eşlenip eşlenmediğini göz önünde bulundurun.

Bölgeler eşlenmediğinde bile çok bölgeli bir çözüm oluşturabilirsiniz. Ancak, çok bölgeli bir mimari uygulamak için kullandığınız yaklaşımlar farklı olabilir. Örneğin, Azure Depolama'da eşleştirilmiş bölgelerle coğrafi olarak yedekli depolama (GRS) kullanabilirsiniz. GRS kullanılamıyorsa Azure Depolama nesne çoğaltması gibi özellikleri kullanmayı veya uygulamanızı birden çok bölgeye yazacak şekilde tasarlamayı göz önünde bulundurun.

Çok bölgeli ve çok bölgeli yaklaşımları birleştirme

İş gereksinimleriniz böyle bir çözüm talep ederse çok bölgeli ve çok bölgeli deyimleri birleştirmelisiniz. Örneğin, alanlar arası yedekli bileşenleri her bölgeye dağıtabilir ve bölgeler arasında çoğaltmayı yapılandırabilirsiniz. Bazı çözümler için bu yaklaşım çok yüksek düzeyde güvenilirlik sağlar. Ancak, bu tür bir yaklaşımı yapılandırmak karmaşık olabilir ve bu yaklaşım pahalı olabilir.

Önemli

Görev açısından kritik iş yükleri hem birden çok kullanılabilirlik alanı hem de birden çok bölge kullanmalıdır. Görev açısından kritik iş yükleri tasarlarken dikkate alınması gereken noktalar hakkında daha fazla bilgi için bkz . Görev açısından kritik iş yükü belgeleri.

Azure hizmetleri dağıtım yaklaşımlarını nasıl destekler?

Kullandığınız Azure hizmetlerinin belirli ayrıntılarını anlamanız önemlidir. Örneğin, bazı Azure hizmetleri kaynağı ilk dağıttığınızda kullanılabilirlik alanı yapılandırmasını yapılandırmanızı gerektirirken, diğerleri daha sonra dağıtım yaklaşımını değiştirmeyi destekler. Benzer şekilde, bazı hizmet özellikleri her dağıtım yaklaşımında kullanılamayabilir.

Her Azure hizmeti için dikkate alınacak belirli dağıtım seçenekleri ve yaklaşımları hakkında daha fazla bilgi edinmek için Güvenilirlik merkezini ziyaret edin.

Örnekler

Bu bölümde bazı yaygın kullanım örnekleri ve her iş yükü için dikkate almanız gereken temel gereksinimler açıklanmaktadır. Her iş yükü için, bu makalede açıklanan gereksinimlere ve yaklaşımlara göre bir veya daha fazla önerilen dağıtım yaklaşımı sağlanır.

Bir kuruluş için iş kolu uygulaması

Contoso, Ltd. büyük bir üretim şirketidir. Şirket, finansal süreçlerinin bazı bileşenlerini yönetmek için bir iş kolu uygulaması uyguluyor.

İş gereksinimleri: Sistemin yönettiği bilgilerin değiştirilmesi zordur, bu nedenle verilerin güvenilir bir şekilde kalıcı olması gerekir. Mimarlar, sistemin olabildiğince az kapalı kalma süresine ve mümkün olduğunca az veri kaybına neden olması gerektiğini söylüyor. Contoso çalışanları bu sistemi iş günü boyunca kullandığından, ekip üyelerini bekletmemek için yüksek performans önemlidir. Finans ekibinin çözüm için ödeme yapmak zorunda olması nedeniyle maliyet de sorun oluşturur.

Önerilen yaklaşım: Bölgeler arasında yedekleme ile alanlar arası yedekli dağıtım , yüksek performansla birden çok dayanıklılık katmanı sağlar.

İç uygulama

Fourth Coffee küçük bir işletmedir. Şirket, çalışanların zaman çizelgeleri göndermek için kullanabileceği yeni bir iç uygulama geliştiriyor.

İş gereksinimleri: Bu iş yükü için maliyet verimliliği öncelikli bir konudur. Fourth Coffee, kapalı kalma süresinin iş üzerindeki etkisini değerlendirdi ve uygulamanın dayanıklılığı veya performansı önceliklendirmesi gerekmeyen bir karar verdi. Şirket, Azure kullanılabilirlik alanında veya bölgesinde yaşanan bir kesintinin uygulamayı geçici olarak kullanılamaz hale getirme riskini kabul ediyor.

Önerilen yaklaşımlar:

• Bölgeler arasında yedekli yerel olarak yedekli dağıtım en düşük maliyete sahip olmakla birlikte önemli risklere de sahiptir.
• Bölgeler arasında yedekleme ile alanlar arası yedekli dağıtım daha iyi dayanıklılık sağlar, ancak maliyeti biraz daha yüksektir.

Eski uygulama geçişi

Fabrikam, Inc., eski bir uygulamayı şirket içi veri merkezinden Azure'a geçiriyor. Uygulama, sanal makineleri temel alan bir IaaS yaklaşımı kullanır. Uygulama bir bulut ortamı için tasarlanmamıştır ve uygulama katmanı ile veritabanı arasındaki iletişim çok gevevelemeli.

İş gereksinimleri: Performans, bu uygulama için bir önceliktir. Dayanıklılık da önemlidir ve bir Azure veri merkezinde kesinti yaşansa bile uygulamanın çalışmaya devam etmesi gerekir.

Önerilen yaklaşım:

• Fabrikan önce alanlar arası yedekli bir dağıtım denemelidir. Performansın gereksinimlerini karşıladığını doğrulamaları gerekir.
• Alanlar arası yedekli çözümün performansı kabul edilebilir değilse, birden çok kullanılabilirlik alanında (bölge içi DR) pasif dağıtımlarla bölgesel (sabitlenmiş) bir dağıtım düşünün.

Sağlık uygulaması

Lamna Healthcare Company, Azure'da yeni bir elektronik sağlık kayıt sistemi uyguluyor.

İş gereksinimleri: Bu çözümün depolandığı verilerin doğası gereği, veri yerleşimi kritik öneme sahiptir. Lamna, verilerin belirli bir konumda kalmasını zorunlu hale getiren katı bir mevzuat çerçevesinde faaliyet göstermektedir.

Önerilen yaklaşımlar:

• Lamna'nın veri yerleşimi gereksinimlerine uyan birden çok bölge varsa çok bölgeli çok bölgeli dağıtım.
• Gereksinimlerine uyan tek bir bölge varsa alanlar arası yedekli dağıtım veya bölgeler arasında yedekleme ile alanlar arası yedekli dağıtım tek bölgeli bir çözüm sağlar

Bankacılık sistemi

Woodgrove Bank, temel bankacılık işlemlerini Azure'a dağıtılan büyük bir çözümden yürütür.

İş gereksinimleri: Bu görev açısından kritik bir sistemdir. Kesintiler müşteriler için önemli finansal etkilere neden olabilir. Sonuç olarak, Woodgrove Bank çok düşük risk toleransı vardır. Sistemin mümkün olan en yüksek güvenilirlik düzeyine sahip olması ve mimarinin azaltılabilir hata riskini azaltması gerekir.

Önerilen yaklaşım: Görev açısından kritik bir sistem için çok bölgeli çok bölgeli dağıtım kullanın. Bölgelerin şirketin veri yerleşimi gereksinimlerine uygun olduğundan emin olun.

Hizmet Olarak Yazılım (SaaS)

Proseware, Inc., dünyanın her yanında şirketler tarafından kullanılan yazılımlar oluşturur. Şirketin kullanıcı tabanı coğrafi olarak yaygın olarak dağıtılır.

İş gereksinimleri: Proseware'in müşterilerinin her birinin müşteriye yakın bir dağıtım bölgesi seçmesini sağlaması gerekir. Bu seçimin etkinleştirilmesi gecikme süresi ve müşterilerin veri yerleşimi gereksinimleri için önemlidir.

Önerilen yaklaşımlar:

• Çok bölgeli çok bölgeli dağıtım, saas sağlayıcısı için genellikle iyi bir seçimdir, özellikle dağıtım damgaları düzeninde kullanıldığında.
• Azure Front Door gibi genel trafik hızlandırma çözümüyle birlikte tek bölgeli alanlar arası yedekli dağıtım.

İlgili bağlantılar

Aşağıda, çok bölgeli ve çok bölgeli çözümler için bazı başvuru mimarileri ve örnek senaryolar verilmiştir:

• Temel yüksek oranda kullanılabilir alanlar arası yedekli web uygulaması
• Yüksek oranda kullanılabilir, çok bölgeli web uygulaması
• Çok bölgeli N katmanlı uygulama
• HA/DR için oluşturulmuş çok katmanlı web uygulaması

Birçok Azure hizmeti, aşağıdaki örnekler de dahil olmak üzere birden çok kullanılabilirlik alanı kullanma hakkında rehberlik sağlar:

• Azure Site Recovery: Kullanılabilirlik alanları arasında Azure VM olağanüstü durum kurtarmayı etkinleştirme
• Azure NetApp Files: Azure NetApp Files bölgeler arası çoğaltmayı anlama
• Azure Depolama yedekliliği

Güvenilirlik denetim listesi

Önerilerin tamamına bakın.

Güvenilirlik denetim listesi