Kullanılabilirlik alanlarını ve bölgeleri kullanmak için öneriler

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 | Yedeklilik

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

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 önemli iş gereksinimleri, göz önünde bulundurabileceğiniz yaklaşımlar, her yaklaşımda yer alan dengeler ve her yaklaşımın Azure İyi Tasarlanmış Çerçeve'nin 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ölgede nasıl seçilip çalışıldığı açıklanır. Çözümünüzdeki bölgeleri ve kullanılabilirlik alanlarını nasıl kullandığınız seçiminiz, İyi Tasarlanmış Çerçeve'nin 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ü daha coğrafi olarak 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, verilerin coğrafi olarak ayrılmış kullanılabilirlik alanları veya bölgeleri arasında gönderilmesini 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 bulmanız gerekebilir.
• Operasyonel Mükemmellik: Karmaşık bir mimari dağıtmak, yapılandırmak ve yönetmek için 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önlendirmek, özellikle el ile 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 OE:05 Kod olarak altyapı, OE:09 Görev otomasyonu, OE:10 Otomasyon tasarımı ve OE:11 Dağıtım uygulamaları gibi Operasyonel Mükemmellik sütun kılavuzları bölümüne bakın.

Çözümünüzü tasarlasanız da Güvenlik sütunu geçerlidir. Genellikle, kullanılabilirlik alanlarını ve bölgelerini kullanıp kullanmadığınıza ve nasıl kullandığınıza ilişkin 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 yedeklemesi 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ın farkında olun.

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.
Availability zone	Bir bölge içindeki ayrılmış veri merkezleri grubu. Her kullanılabilirlik alanı kendi gücü, soğutması ve ağ altyapısı ile 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ğ donanımlarını 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 birine 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ürde çok bölgeli çözümleri etkinleştirmek için başka bir tanımlı bölgeye bağlanır. Daha yeni Azure bölgeleri eşlenmez.
Bölge	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şleştirilip eşlenmediği de 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şitleme, trafik dağıtımı 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 coğrafi bir çevredir. Azure bölgelerini ve kullanılabilirlik alanlarını tam olarak anlamanı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ı 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 uzaktır. Kullanılabilirlik alanları bağımsız güç, soğutma ve ağ altyapısına sahiptir. Bunlar, bir bölgede kesinti yaşanması durumunda bölgesel hizmetler, kapasite ve yüksek kullanılabilirlik alanlarının kalan bölgeler tarafından desteklenmesi için 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ını 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 bir kesinti oluşması durumunda, başka bir kullanılabilirlik alanına yük devretmek sizin sorumluluğundadır.
• Alanlar arası yedekli kaynaklar birden çok kullanılabilirlik alanına yayılır. Microsoft, isteklerin bölgelere yayılması ve verilerin bölgeler arasında çoğaltılması işlemini yönetir. Tek bir kullanılabilirlik alanında bir kesinti oluşması durumunda, 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 güncelleştirmeleri hizmetlere 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 sonuçta 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ı bir şekilde 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) düşünebilirsiniz. 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 de eşleştirilmiş bir bölgesi vardır. Eşleştirilmiş bölgeler, çok bölgeli dağıtım yaklaşımlarının belirli türlerini destekler. Bazı yeni 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ı nelerdir?

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, hizmeti çalıştırmak için daha fazla veya daha az sorumluluk alabilirsiniz.

Microsoft, gereksinimlerinizi karşılayacak şekilde çözümünüzü tasarlama konusunda esneklik sağlamak için kullanılabilirlik alanları ve bölgeleri sağlar. Yönetilen hizmetleri kullandığınızda Microsoft, kaynaklarınız için 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çerebilen yönetim sorumluluklarından daha fazlasını üstlenir.

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 devretme 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. Kuruluş içinde 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. Herhangi bir dayanıklılık stratejisi bu riskleri hesaba almalıdır.
Veri merkezi kesintisi	Veri merkezinin tamamında güç, soğutma veya ağ arızası. Metropol alanının 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 gelen 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ı 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 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 dikkate alma yönteminizle 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ı en üst düzeye çıkarmayı 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 dayanır. Diğer durumlarda, 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, gereksinimleriniz için gecikme süresini ve güvenilirliği 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şmışsa, 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ı düşünmeniz gerekir. Görev açısından kritik uygulamalarda, kullanıcılarınız birlikte bulunsa bile çok bölgeli bir dağıtım kullanmanız gerekir.

Kullanıcılarınız coğrafi olarak dağınıksa, 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 sunar ve kullanıcı deneyiminizi geliştirmek ve uygulamalarınızı kullanıcı tabanınıza daha yakın hale getirmek için Azure'ın genel ayak izini kullanabilirsiniz. Dağıtım DamgaLarı desenini veya Geodes desenini kullanabilir veya 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ırmayı kullanarak gereksinimlerinizi tek bir bölge içinde sağlayıp sağlayamayacağınızı düşünün.

Bütçe

Kısıtlanmış bir bütçeyle çalışırsanız, yedekli iş yükü bileşenlerini dağıtmaya ilişkin maliyetleri göz önünde bulundurmanız önemlidir. Bu maliyetler ek kaynak ücretlerini, ağ maliyetlerini ve daha fazla kaynağı yönetmenin operasyonel maliyetlerini ve daha karmaşık bir ortamı içerebilir.

Karmaşıklık

Çözüm mimarinizde gereksiz karmaşıklığı önlemek iyi bir uygulamadır. Ne kadar karmaşık hale gelirseniz, 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ğurabilir.

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ğlamaya yöneliktir.

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ı temel 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
Operasyonel Mükemmellik	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 endişe	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 dağıtılacağı veya bölgedeki birden çok veri merkezine 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ılamayabilir 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 biraz gecikme süresi 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ı temel sorunlar özetlemektedir:

Yapı Taşı	Etki
Güvenilirlik	Düşük güvenilirlik. Bir veri merkezi başarısız olursa hizmetler kesintiye tabidir. Ancak, diğer hata türlerine dayanıklı olacak bir uygulama oluşturabilirsiniz.
Maliyet İyileştirmesi	En düşük maliyet. Her kaynağın yalnızca tek bir örneğine sahip olmanız gerekir ve bölgeler arası bant genişliği maliyetlerine neden 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.
Operasyonel Mükemmellik	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 endişe	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 dağıtımı genişletebilirsiniz. Bu yaklaşım, birincil bölgenizdeki bir kesintiye karşı azaltmaya yönelik 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 de 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şılayabilmek için genellikle yedeklemelerin sıklığını denetleyebilirsiniz.

Bu tabloda bazı temel sorunlar özetlemektedir:

Yapı Taşı	Etki
Güvenilirlik	Orta düzeyde güvenilirlik. Bir veri merkezi başarısız olursa hizmetler kesintiye tabidir. 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 kaynak dağıtmaktan biraz daha pahalıdır.
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.
Operasyonel Mükemmellik	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 endişe	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ındaki trafiğin nasıl yönlendireceğine karar vermeniz gerekir. Bu örnekte etkin-pasif trafik yönlendirme yaklaşımı gösterilmektedir:

Önceki örnekte, yük dengeleyici birden çok kullanılabilirlik alanına dağıtılır. Bölge kesintisi söz konusu bölgeye dağıtılan ağ kaynaklarını da etkileyebileceğinden, farklı kullanılabilirlik alanlarındaki örnekler arasındaki trafiği 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ı ayrı ayrı 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ğundadı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, başka bir kullanılabilirlik alanındaki kaynaklara trafik 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ı temel 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 merkezinde veya kullanılabilirlik alanında 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.
Performans Verimliliği	Yüksek performans. İstek sunan bileşenler aynı kullanılabilirlik alanında bulunduğunda gecikme süresi çok düşük olabilir.
Operasyonel Mükemmellik	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 endişe	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ı dizisi 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 (kullanılabilirlik alanlarını kapsayan) bir yük dengeleyici, istekleri her kullanılabilirlik alanındaki örnekler arasında dağıtır. Kullanılabilirlik alanında 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 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 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 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ı temel sorunlar özetlemektedir:

Yapı Taşı	Etki
Güvenilirlik	Yüksek güvenilirlik. Hizmetler, veri merkezi veya kullanılabilirlik alanı kesintisine dayanıklıdır. Veriler kullanılabilirlik alanları arasında zaman uyumlu olarak çoğaltılır ve gecikme olmaz.
Maliyet İyileştirmesi	Orta maliyet. Kullandığınız hizmetlere bağlı olarak, bölge yedekliliğini etkinleştirmek için daha yüksek hizmet katmanları için bazı maliyetler doğurabilirsiniz.
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. Bölgeler arası trafik veya veri çoğaltma süresi nedeniyle bazı bileşenler gecikme süresine duyarlı olabilir.
Operasyonel Mükemmellik	Yüksek operasyonel verimlilik. Genellikle her kaynağın yalnızca tek bir mantıksal örneğini yönetmeniz gerekir. Çoğu hizmette, 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 endişe	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 Uygulaması Service, Azure İşlevleri, Azure Kubernetes Service, Azure Depolama, Azure SQL, Azure Service Bus ve diğerleri gibi birçok Azure hizmetinde mümkündür. 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 de 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 tür bir dağıtımla başlayın.

Bu tabloda bazı temel sorunlar özetlemektedir:

Yapı Taşı	Etki
Güvenilirlik	Çok yüksek güvenilirlik. Hizmetler, veri merkezi veya kullanılabilirlik alanı kesintisine 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 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. Bölgeler arası trafik veya veri çoğaltma süresi nedeniyle bazı bileşenler gecikme süresine duyarlı olabilir.
Operasyonel Mükemmellik	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 endişe	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ı dikkatlice 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-etkin dağıtımlar) etkin olarak işlemesi 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 uzun olması nedeniyle daha fazla ağ gecikme süresine 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ı temel sorunlar özetlemektedir:

Yapı Taşı	Etki
Güvenilirlik	Yüksek güvenilirlik. Çözüm, veri merkezi, kullanılabilirlik alanı 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 bazı veri kayıpları mümkündür.
Maliyet İyileştirmesi	Yüksek maliyet. 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.
Operasyonel Mükemmellik	Düşük operasyonel verimlilik. Kaynakları birden çok bölgeye dağıtmanız ve yönetmeniz gerekir. Bölgesel bir kesinti sırasında bölgeler arasında yük devretmeden de siz sorumlu olursunuz.

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

Mimari endişe	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ölgeleri 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şlemin tamamlanmış olarak kabul edilmesi için uygulamanızın her Azure bölgesinde yazma işlemlerinin tamamlanmasını beklemesi gerekir. Yazma işlemleri 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 süresi zaman uyumlu çoğaltmanın yararlı olamayacak kadar yavaş olmasını sağlayabilir.

Bu tabloda bazı temel sorunlar özetlemektedir:

Yapı Taşı	Etki
Güvenilirlik	Çok yüksek güvenilirlik. Çözüm, veri merkezi, kullanılabilirlik alanı veya bölgenin tamamında kesintiye dayanıklıdır. Veriler her zaman bölgeler arasında eşitlenir, bu nedenle tam bölge kaybı olsa bile verileriniz başka bir bölgede kullanılabilir ve tamamlanır.
Maliyet İyileştirmesi	Yüksek maliyet. 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 bölgeler arası trafik gerektirir. Bölgeler arasındaki uzaklık durumuna bağlı olarak, zaman uyumlu çoğaltma isteklere önemli gecikme süresi ekleyebilir.
Operasyonel Mükemmellik	Düşük operasyonel verimlilik. Kaynakları birden çok bölgeye dağıtmanız ve yönetmeniz gerekir. Bölgesel bir kesinti sırasında bölgeler arasında yük devretmeden de siz sorumlu olursunuz.

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

Mimari endişe	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ölgeleri 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şleştirilip eşlenmediğini göz önünde bulundurun.

Bölgeler eşlenmemiş olsa bile çok bölgeli bir çözüm oluşturabilirsiniz. Ancak, çok bölgeli 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 için böyle bir çözüm gerekiyorsa çok bölgeli ve çok bölgeli deyimleri birleştirmeniz gerekir. Ö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üklerini 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ınması gereken 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'nun çalışanları 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

Dördüncü Kahve küçük bir işletmedir. Şirket, çalışanların zaman çizelgelerini göndermek için kullanabileceği yeni bir iç uygulama geliştiriyor.

İş gereksinimleri: Bu iş yükü için maliyet verimliliği birincil sorundur. 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 bir kesintinin uygulamayı geçici olarak kullanılamaz hale getirme riskini kabul eder.

Ö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 biraz daha yüksek bir maliyetle.

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 sohbet edicidir.

İş 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ımlar içeren 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 depoladığı verilerin doğası gereği veri yerleşimi kritik önem taşır. Lamna, verilerin belirli bir konumda kalmasını zorunlu hale getiren katı bir mevzuat çerçevesi altında çalışır.

Ö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'ın risk toleransı çok düşüktür. Sistemin mümkün olan en yüksek güvenilirlik düzeyine ihtiyacı vardır 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ılmıştır.

İş gereksinimleri: Proseware'in her müşterisinin 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 açısından önemlidir.

Önerilen yaklaşımlar:

• Çok bölgeli çok bölgeli dağıtım, özellikle Dağıtım Damga Damgaları düzeninde kullanıldığında saas sağlayıcısı için genellikle iyi bir seçimdir.
• Azure Front Door gibi genel bir 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'ın bölgeler arası çoğaltmayı anlama
• Azure Depolama yedekliliği

Güvenilirlik denetim listesi

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

Güvenilirlik denetim listesi