Giriş bölgesi bölgeleri
Bu makalede giriş bölgelerinin Azure bölgelerini nasıl kullandığı açıklanmaktadır. Azure giriş bölgesi mimarisi bölgeden bağımsızdır, ancak Azure giriş bölgesi mimarinizi dağıtmak için Azure bölgelerini belirtmeniz gerekir. Aşağıdaki kılavuzda, var olan bir giriş bölgesine nasıl bölge ekleneceği açıklanır ve ayrıca Azure varlığınızı farklı bir bölgeye geçirirken dikkat edilmesi gerekenler sağlanır.
Bazı durumlarda, yüksek kullanılabilirlik ve olağanüstü durum kurtarma iş gereksinimlerinizi desteklemek için uygulamaları birden çok Azure bölgesine dağıtmanız gerekir. Çok bölgeli uygulamalara hemen ihtiyacınız olmayabilir, ancak Azure giriş bölgesi platformunuzu, özellikle bağlantı, kimlik ve yönetim hizmetleri için birden çok bölgeyi destekleyecek şekilde tasarlamanız gerekir. Çok bölgeli uygulama giriş bölgelerini hızla etkinleştirip destekleyebileceğinizden emin olun.
Daha fazla bilgi için bkz . Azure bölgelerini seçme.
Giriş bölgeleri ve Azure bölgeleri
Azure giriş bölgeleri bir dizi kaynak ve yapılandırmadan oluşur. Yönetim grupları, ilkeler ve rol atamaları gibi bu öğelerden bazıları Azure giriş bölgesi mimarisinde kiracı veya yönetim grubu düzeyinde depolanır. Bu kaynaklar belirli bir bölgeye dağıtılmaz ve bunun yerine genel olarak dağıtılır. Ancak, Azure bölgesel meta veri deposundaki kaynak meta verilerinin bazılarını izlediğinden yine de dağıtım bölgesi belirtmeniz gerekir.
Diğer kaynaklar bölgesel olarak dağıtılır. Kendi giriş bölgesi yapılandırmanıza bağlı olarak, bölgesel olarak dağıtılan aşağıdaki kaynakların bir kısmına veya tümüne sahip olabilirsiniz:
- Seçili çözümler de dahil olmak üzere bir Azure İzleyici Günlükleri çalışma alanı
- Azure Otomasyonu hesabı
- Diğer kaynaklar için kaynak grupları
Bir ağ topolojisi dağıtırsanız, ağ kaynaklarını dağıtmak için bir Azure bölgesi de seçmeniz gerekir. Bu bölge, önceki listede listelenen kaynaklar için kullandığınız bölgeden farklı olabilir. Seçtiğiniz topolojiye bağlı olarak, dağıttığınız ağ kaynakları şunları içerebilir:
- Sanal WAN hub'ı da dahil olmak üzere Azure Sanal WAN
- Azure sanal ağları
- VPN ağ geçidi
- Azure ExpressRoute ağ geçidi
- Azure Güvenlik Duvarı
- Azure DDoS Koruması planları
- Azure Özel Bağlantı bölgeleri dahil olmak üzere Azure özel DNS bölgeleri
- Kaynak grupları, önceki kaynakları içerecek şekilde
Not
Bölgesel kesintilerin etkisini en aza indirmek için kaynakları kaynak grubuyla aynı bölgeye yerleştirmenizi öneririz. Daha fazla bilgi için bkz . Kaynak grubu konum hizalama.
Mevcut giriş bölgesine yeni bölge ekleme
Bulut yolculuğunuzun başlangıcından itibaren veya Azure giriş bölgesi mimarinizin ilk dağıtımını tamamladıktan sonra daha fazla Azure bölgesine genişleterek çok bölgeli bir strateji düşünmelisiniz. Örneğin, sanal makinelerinizde olağanüstü durum kurtarmayı etkinleştirmek için Azure Site Recovery kullanıyorsanız bunları farklı bir Azure bölgesine çoğaltmak isteyebilirsiniz. Azure giriş bölgesi mimarinize Azure bölgeleri eklemek için aşağıdaki önerileri göz önünde bulundurun:
| Alan | Öneri |
|---|---|
| Yönetim grupları | Herhangi bir işlem gerekli değil. Yönetim grupları bir bölgeye bağlı değildir. Bölgeleri temel alan bir yönetim grubu yapısı oluşturmamalısınız. |
| Abonelikler | Abonelikler bir bölgeye bağlı değildir. |
| Azure İlkesi | "İzin verilen" Azure bölgelerinin listesini belirterek tüm bölgelere kaynak dağıtımını reddetmek için ilkeler atadıysanız Azure İlkesi değişiklik yapın. Bu atamaları, etkinleştirmek istediğiniz yeni bölgeye kaynak dağıtımlarına izin verecek şekilde güncelleştirin. |
| Rol tabanlı erişim denetimi (RBAC) | Herhangi bir işlem gerekli değil. Azure RBAC bir bölgeye bağlı değildir. |
| İzleme ve Günlüğe Kaydetme | Tüm bölgeler için tek bir Azure İzleyici Günlükleri çalışma alanı mı kullanacağınıza yoksa çeşitli coğrafi bölgeleri kapsayacak şekilde birden çok çalışma alanı mı oluşturacağınız konusunda karar verin. Her yaklaşımın, olası bölgeler arası ağ ücretleri de dahil olmak üzere avantajları ve dezavantajları vardır. Daha fazla bilgi için bkz . Log Analytics çalışma alanı mimarisi tasarlama. |
| Ağ | Bir ağ topolojisi, Sanal WAN veya geleneksel merkez-uç dağıtırsanız ağı yeni Azure bölgesine genişletin. Gerekli ağ kaynaklarını yeni Azure bölgesindeki mevcut Bağlan ivity aboneliğine dağıtarak başka bir ağ hub'ı oluşturun. Azure Sanal Ağ Yöneticisi, sanal ağları birden çok bölgede büyük ölçekte genişletmeyi ve yönetmeyi kolaylaştırabilir. Etki Alanı Adı Sistemi (DNS) perspektifinden, ileticileri kullanıyorsanız yeni Azure bölgesine de dağıtmak isteyebilirsiniz. Çözüm için yeni bölgedeki uç sanal ağları için ileticileri kullanın. Azure DNS bölgeleri genel kaynaklardır ve tek bir Azure bölgesine bağlı değildir, bu nedenle herhangi bir eylem gerektirmez. |
| Kimlik | Active Directory Etki Alanı Hizmetleri'ni veya Microsoft Entra Domain Services'i Kimlik aboneliğinize veya bağlı bileşene dağıttıysanız hizmeti yeni Azure bölgesine genişletin. |
Not
Ayrıca, bir bölgede yüksek kullanılabilirlik için kullanılabilirlik alanlarını da kullanmanız gerekir. Bölgelerinizin ve hizmetlerinizin kullanılabilirlik alanlarını destekleyip desteklemediğini denetleyin.
Egemenlik için Microsoft Bulut, hizmetleri ve bölgeleri kısıtlamaya yönelik yönergelere sahiptir. Müşterilerin veri yerleşimi gereksinimlerini karşılamalarına yardımcı olmak için hizmet yapılandırmasını zorunlu kılmak için bu yönergeleri kullanabilirsiniz.
Üst düzey yaklaşım
Azure giriş bölgesini yeni bir bölgeye genişlettiğinizde, bu bölümlerdeki adımları takip etmeyi göz önünde bulundurun. Başlamadan önce, yeni bir Azure bölgesine veya birden çok Azure bölgesine genişlemeye karar vermeniz gerekir.
Ağ
Geleneksel merkez-uç mimarisi
İpucu
Geleneksel merkez-uç mimarisine bakın.
Yeni bir platform giriş bölgesi aboneliğine ihtiyacınız olup olmadığına karar verin. Müşterilerin çoğunun, birden çok bölge kullanırken bile mevcut Bağlan ivity aboneliklerini kullanmasını öneririz.
Abonelik içinde, yeni hedef bölgede yeni bir kaynak grubu oluşturun.
Yeni hedef bölgede yeni bir merkez sanal ağı oluşturun.
Varsa, Azure Güvenlik Duvarı veya ağ sanal gereçlerini (NVA) yeni hub sanal ağınıza dağıtın.
Varsa VPN veya ExpressRoute bağlantısı için sanal ağ geçitleri dağıtın ve bağlantılar oluşturun. ExpressRoute bağlantı hatlarınızın ve şirket içi konumlarınızın Microsoft dayanıklılık önerilerine uygun olduğundan emin olun. Daha fazla bilgi için bkz . ExpressRoute özel eşlemesi ile olağanüstü durum kurtarma için tasarlama.
Yeni merkez sanal ağı ile diğer merkez sanal ağları arasında sanal ağ eşlemesi oluşturun.
Azure Route Server veya kullanıcı tanımlı yollar gibi gerekli yönlendirmeleri oluşturun ve yapılandırın.
Gerekirse, yeni hedef bölge için DNS ileticileri dağıtın ve ad çözümlemesini etkinleştirmek için herhangi bir özel DNS bölgesine bağlanın.
- Bazı müşteriler, Kimlik platformu giriş bölgesi aboneliğindeki Windows Server Active Directory etki alanı denetleyicilerinde ad çözümlemesi yapılandırabilir.
İş yüklerinizi barındırmak için sanal ağ eşlemesini kullanarak uygulama giriş bölgesi uçlarını yeni bölgedeki yeni merkez sanal ağına bağlayabilirsiniz.
İpucu
Sanal Ağ Yöneticisi, birden çok bölgede büyük ölçekte sanal ağları genişletmeyi ve yönetmeyi kolaylaştırabilir.
Sanal WAN mimarisi
İpucu
Mevcut Sanal WAN içinde yeni hedef bölgede yeni bir sanal hub oluşturun.
Azure Güvenlik Duvarı veya desteklenen diğer ağ sanal gereçlerini (NVA) yeni sanal hub'ınıza dağıtın. Trafiği yeni güvenli sanal hub üzerinden yönlendirmek için Sanal WAN yönlendirme amacını ve yönlendirme ilkelerini yapılandırın.
Varsa, yeni sanal hub'da VPN veya ExpressRoute bağlantısı için sanal ağ geçitleri dağıtın ve bağlantılar oluşturun. ExpressRoute bağlantı hatlarınızın ve şirket içi konumlarınızın Microsoft dayanıklılık önerilerine uygun olduğundan emin olun. Daha fazla bilgi için bkz . ExpressRoute özel eşlemesi ile olağanüstü durum kurtarma için tasarlama.
Sanal hub statik yolları gibi ihtiyacınız olan diğer yönlendirmeleri oluşturun ve yapılandırın.
Varsa, yeni hedef bölge için DNS ileticileri dağıtın ve çözümlemeyi etkinleştirmek için herhangi bir özel DNS bölgesine bağlanın.
Bazı müşteriler, Kimlik platformu giriş bölgesi aboneliğindeki Active Directory etki alanı denetleyicilerinde ad çözümlemesi yapılandırabilir.
Sanal WAN dağıtımlarında bu, Sanal hub uzantısı desenini izleyerek sanal hub'a bir sanal ağ bağlantısı üzerinden bağlanan uç sanal ağında olmalıdır.
İş yüklerinizi barındırmak için sanal ağ eşlemesini kullanarak uygulama giriş bölgesi uçlarını yeni bölgedeki yeni merkez sanal ağına bağlayabilirsiniz.
Kimlik
İpucu
Kimlik ve erişim yönetimi için Azure giriş bölgesi tasarım alanını gözden geçirin.
Yeni bir platform giriş bölgesi aboneliğine ihtiyacınız olup olmadığına karar verin. Müşterilerin çoğunun, birden çok bölge kullanırken bile mevcut Kimlik aboneliklerini kullanmasını öneririz.
Yeni hedef bölgede yeni bir kaynak grubu oluşturun.
Yeni hedef bölgede yeni bir sanal ağ oluşturun.
Bağlan ivity aboneliğinde yeni oluşturulan bölgesel merkez sanal ağına sanal ağ eşlemesi oluşturun.
Active Directory etki alanı denetleyicisi sanal makineleri gibi kimlik iş yüklerini yeni sanal ağa dağıtın.
İş yükleri sağlandıktan sonra aşağıdaki yapılandırma adımları gibi daha fazla kurulum gerçekleştirmeniz gerekebilir:
Active Directory etki alanı denetleyicisi sanal makinelerini mevcut Active Directory etki alanına yükseltin.
Yeni Active Directory siteleri ve alt ağları oluşturun.
Koşullu ileticiler gibi DNS sunucusu ayarlarını yapılandırın.
Azure varlığınızı yeni bir bölgeye taşıma
Zaman zaman tüm Azure varlıklarınızı farklı bir bölgeye taşımanız gerekebilir. Örneğin, giriş bölgenizi ve iş yüklerinizi komşu ülke veya bölgedeki bir Azure bölgesine dağıttıktan sonra kendi ülkenizde veya bölgenizde yeni bir Azure bölgesi başlatıldığını varsayalım. İletişim gecikme süresini iyileştirmek veya veri yerleşimi gereksinimlerine uymak için tüm iş yüklerinizi yeni bölgeye taşımayı seçebilirsiniz.
Not
Bu makalede, varlıklarınızın giriş bölgesi bileşenlerini geçirme hakkında bilgi sağlanır. Daha fazla bilgi için bkz . Bulut iş yüklerini yeniden dağıtma.
Genel giriş bölgesi yapılandırması
Bölgeleri taşırken genel olarak dağıtılan giriş bölgesi yapılandırmasının çoğunun değiştirilmesi gerekmez. Ancak, bölge dağıtımlarını kısıtlayan ilke atamalarını denetlediğinizden ve ilkeyi yeni bölgeye dağıtımlara izin verecek şekilde güncelleştirdiğinizden emin olun.
Bölgesel giriş bölgesi kaynakları
Bölgeler arasında bazı Azure kaynaklarını taşıyamadığınız için bölgeye özgü giriş bölgesi kaynakları genellikle daha fazla dikkate alınması gerekir. Aşağıdaki yaklaşımı göz önünde bulundurun:
Hedef bölgeyi giriş bölgenize ek bölge olarak ekleyin: Daha fazla bilgi için bkz . Var olan bir giriş bölgesine yeni bölge ekleme.
Hedef bölgede merkezi bileşenleri dağıtma: Örneğin, iş yüklerinin iş yükünü geçirdikten sonra yeni bileşeni kullanmaya başlayabilmesi için hedef bölgenize yeni bir Azure İzleyici Günlükleri çalışma alanı dağıtın.
İş yüklerinizi kaynak bölgeden hedef bölgeye geçirin: İş yükü geçiş işlemi sırasında, kaynakları hedef bölgenin ağ bileşenlerini, kimlik bileşenlerini, Azure İzleyici Günlükleri çalışma alanını ve diğer bölgesel kaynakları kullanacak şekilde yeniden yapılandırın.
Geçişi tamamladıktan sonra kaynak bölgedeki kaynakların yetkisini alın.
Giriş bölgesi kaynaklarını bölgeler arasında geçirirken aşağıdaki ipuçlarını göz önünde bulundurun:
Altyapıyı kod olarak kullanma: Azure Güvenlik Duvarı kuralları gibi karmaşık yapılandırmaları dışarı aktarmak ve yeniden içeri aktarmak için Bicep, Azure Resource Manager şablonları (ARM şablonları), Terraform, betik oluşturma veya benzer bir yaklaşım kullanın.
Otomasyon: Otomasyon kaynaklarını bölgeler arasında geçirmek için betikleri kullanın.
ExpressRoute: ExpressRoute Yerel SKU'yu hedef bölgenizde kullanıp kullanamayacağınızı göz önünde bulundurun. Şirket içi ortamlarınız Azure bölgenizle aynı metropol bölgesindeyse ExpressRoute Local, diğer ExpressRoute SKU'larına kıyasla daha düşük maliyetli bir seçenek sunabilir.