Yük devretme sırasında IP adreslerini koruma

Azure Site Recovery , VM'leri başka bir Azure bölgesine çoğaltarak, kesinti oluşursa yük devrederek ve her şey normale döndüğünde birincil bölgeye geri dönerek Azure VM'leri için olağanüstü durum kurtarma sağlar.

Yük devretme sırasında IP adresini hedef bölgede kaynak bölgeyle aynı tutmak isteyebilirsiniz:

• Varsayılan olarak, Azure VM'leri için olağanüstü durum kurtarmayı etkinleştirdiğinizde, Site Recovery kaynak kaynak ayarlarına göre hedef kaynakları oluşturur. Statik IP adresleriyle yapılandırılmış Azure VM'leri için Site Recovery, kullanımda değilse hedef VM için aynı IP adresini sağlamaya çalışır. Site Recovery'nin adreslemeyi nasıl işlediğine ilişkin tam bir açıklama için bu makaleyi gözden geçirin.
• Basit uygulamalar için varsayılan yapılandırma yeterlidir. Daha karmaşık uygulamalar için, yük devretmeden sonra bağlantının beklendiği gibi çalıştığından emin olmak için ek kaynak sağlamanız gerekebilir.

Bu makalede, daha karmaşık örnek senaryolarda IP adreslerini korumaya yönelik bazı örnekler sağlanmaktadır. Örnekler şunlardır:

• Azure'da çalışan tüm kaynaklara sahip bir şirket için yük devretme
• Karma dağıtımı olan bir şirket ve hem şirket içinde hem de Azure'da çalışan kaynaklar için yük devretme

Azure'daki kaynaklar: tam yük devretme

A şirketinin tüm uygulamaları Azure'da çalışır.

Yük devretmeden önce

Not

Artık dünyanın dört bir yanındaki iki Azure bölgesi arasında çoğaltma yapılabilir. Müşteriler artık kendi kıtalarında çoğaltmayı etkinleştirmeyle sınırlı değildir.

Yük devretmeden önceki mimari aşağıdadır.

• A şirketi, kaynak ve hedef Azure bölgelerinde aynı ağlara ve alt ağlara sahiptir.
• Şirket, kurtarma süresi hedeflerini (RTO) azaltmak için SQL Server AlwaysOn, etki alanı denetleyicileri vb. için çoğaltma düğümlerini kullanır. Bu çoğaltma düğümleri hedef bölgede farklı bir sanal ağda yer alır, böylece kaynak ve hedef bölgeler arasında VPN siteden siteye bağlantı kurabilirler. Kaynakta ve hedefte aynı IP adresi alanı kullanılıyorsa bu mümkün değildir.
• Yük devretmeden önce ağ mimarisi aşağıdaki gibidir:
  • Birincil bölge Azure Doğu Asya'dır
    • Doğu Asya'da adres alanı 10.1.0.0/16 olan bir VNet (Kaynak VNet) vardır.
    • Doğu Asya'da, sanal ağda üç alt ağa bölünmüş iş yükleri vardır:
      • Alt ağ 1: 10.1.1.0/24
      • Alt ağ 2: 10.1.2.0/24
      • Alt ağ 3: 10.1.3.0/24
  • İkincil (hedef) bölge Azure Güneydoğu Asya bölgesidir
    • Güneydoğu Asya'da Kaynak sanal ağ ile aynı kurtarma sanal ağı (Kurtarma sanal ağı) vardır.
    • Güneydoğu Asya'da adres alanı 10.2.0.0/16 olan ek bir sanal ağ (Azure VNet) vardır.
    • Azure sanal ağı, adres alanı 10.2.4.0/24 olan bir alt ağ (Alt ağ 4) içerir.
    • SQL Server Always On, etki alanı denetleyicisi vb. için çoğaltma düğümleri Alt Ağ 4'te bulunur.
  • Kaynak sanal ağ ve Azure sanal ağı bir VPN sitesinden siteye bağlantı ile bağlanır.
  • Kurtarma sanal ağı başka bir sanal ağa bağlı değil.
  • Şirket A , çoğaltılan öğeler için hedef IP adreslerini atar/doğrular. Hedef IP, her vm için kaynak IP ile aynıdır.

Yük devretmeden sonra

Kaynak bölgesel kesinti oluşursa, A Şirketi tüm kaynaklarını hedef bölgeye devredebilir.

• Hedef IP adresleri yük devretmeden önce zaten mevcutken, A Şirketi yük devretmeyi düzenleyebilir ve Kurtarma sanal ağı ile Azure sanal ağı arasında yük devretmeden sonra otomatik olarak bağlantılar kurabilir. Bu, aşağıdaki diyagramda gösterilmiştir..
• Uygulama gereksinimlerine bağlı olarak, hedef bölgedeki iki sanal ağ (Kurtarma VNet ve Azure VNet) arasındaki bağlantılar yük devretme öncesinde, sırasında (ara adım olarak) veya sonra kurulabilir.

  • Şirket, bağlantıların ne zaman kurulacağını belirtmek için kurtarma planlarını kullanabilir.

  • Sanal ağ eşleme veya siteden siteye VPN kullanarak sanal ağlar arasında bağlantı kurabilirler.

    • Sanal ağ eşlemesi VPN ağ geçidi kullanmaz ve farklı kısıtlamalara sahiptir.
    • Sanal ağ eşleme fiyatlandırması , sanal ağdan sanal ağa VPN Gateway fiyatlandırmasından farklı şekilde hesaplanır. Yük devretme işlemleri için genellikle öngörülemeyen ağ olaylarını en aza indirmek için bağlantı türü de dahil olmak üzere kaynak ağlarla aynı bağlantı yöntemini kullanmanızı öneririz.

    

Azure'daki kaynaklar: yalıtılmış uygulama yük devretmesi

Uygulama düzeyinde yük devretme yapmanız gerekebilir. Örneğin, ayrılmış bir alt ağda bulunan belirli bir uygulama veya uygulama katmanına yük devretme.

• Bu senaryoda, IP adreslemesine devam edebilirsiniz, ancak bağlantı tutarsızlıkları olasılığını artırdığından genellikle önerilmez. Ayrıca aynı Azure sanal ağı içindeki diğer alt ağlara alt ağ bağlantısını da kaybedersiniz.
• Alt ağ düzeyinde uygulama yük devretmesi gerçekleştirmenin daha iyi bir yolu, yük devretme için farklı hedef IP adresleri kullanmak (kaynak VNet'teki diğer alt ağlara bağlanmanız gerekiyorsa) veya her uygulamayı kaynak bölgedeki kendi ayrılmış sanal ağındaki yalıtmaktır. İkinci yaklaşımla, kaynak bölgedeki ağlar arasında bağlantı kurabilir ve hedef bölgeye yük devrettiğinizde aynı davranışa öykünebilirsiniz.

Bu örnekte Şirket A, uygulamaları ayrılmış sanal ağlarda kaynak bölgeye yerleştirir ve bu sanal ağlar arasında bağlantı kurar. Bu tasarımla yalıtılmış uygulama yük devretmesi gerçekleştirebilir ve hedef ağda kaynak özel IP adreslerini koruyabilirler.

Yük devretmeden önce

Yük devretmeden önce mimari aşağıdaki gibidir:

• Uygulama VM'leri birincil Azure Doğu Asya bölgesinde barındırılır:

  • App1 VM'leri Sanal Ağ Kaynağı Sanal Ağ 1: 10.1.0.0/16'da bulunur.
  • App2 VM'leri Sanal Ağ Kaynağı sanal ağı 2: 10.2.0.0/16'da bulunur.
  • Kaynak sanal ağ 1'in iki alt ağı vardır.
  • Kaynak sanal ağ 2'nin iki alt ağı vardır.

• İkincil (hedef) bölge Azure Güneydoğu Asya'dır - Güneydoğu Asya'da Kaynak VNet 1 ve Kaynak VNet 2 ile aynı olan kurtarma sanal ağları (Kurtarma VNet 1 ve Kurtarma VNet 2) vardır. - Kurtarma VNet 1 ve Kurtarma VNet 2'nin her birinin Kaynak VNet 1 ve Kaynak Sanal Ağ 2'deki alt ağlarla eşleşen iki alt ağı vardır- Güneydoğu Asya'da adres alanı 10.3.0.0/16 olan ek bir sanal ağ (Azure VNet) vardır. - Azure sanal ağı, adres alanı 10.3.4.0/24 olan bir alt ağ (Alt ağ 4) içerir. - SQL Server Always On, etki alanı denetleyicisi vb. için çoğaltma düğümleri Alt Ağ 4'te bulunur.

• Bir dizi siteden siteye VPN bağlantısı vardır:

  • Kaynak VNet 1 ve Azure VNet
  • Kaynak VNet 2 ve Azure VNet
  • Kaynak VNet 1 ve Kaynak VNet 2 , VPN siteden siteye bağlı

• Kurtarma VNet 1 ve Kurtarma VNet 2 diğer sanal ağlara bağlı değildir.

• Şirket A, RTO'yu azaltmak için Kurtarma Sanal Ağı 1 ve Kurtarma VNet 2'de VPN ağ geçitlerini yapılandırır.

• Kurtarma VNet1 ve Kurtarma VNet2 başka bir sanal ağa bağlı değildir.

• Kurtarma süresi hedeflerini (RTO) azaltmak için VPN ağ geçitleri yük devretmeden önce Kurtarma VNet1 ve Kurtarma VNet2'de yapılandırılır.

  

Yük devretmeden sonra

Tek bir uygulamayı etkileyen bir kesinti veya sorun olması durumunda (örneğimizdeki **Kaynak VNet 2'de), Şirket A etkilenen uygulamayı aşağıdaki gibi kurtarabilir:

• Kaynak VNet1 ile Kaynak VNet2 arasında ve Kaynak VNet2 ile Azure VNet arasında VPN bağlantılarını kesin.
• Kaynak VNet1 ile Kurtarma VNet2 arasında ve Kurtarma VNet2 ile Azure VNet arasında VPN bağlantıları oluşturun.
• Kaynak VNet2'deki VM'lerin yük devretmesini Kurtarma VNet2'ye yapın.

• Bu örnek, daha fazla uygulama ve ağ bağlantısı içerecek şekilde genişletilebilir. Kaynaktan hedefe yük devredilirken mümkün olduğunca benzer bir bağlantı modelini izleme önerisinde bulunur.
• VPN Gateway'ler, bağlantı kurmak için genel IP adreslerini ve ağ geçidi atlamalarını kullanır. Genel IP adreslerini kullanmak istemiyorsanız veya ek atlamalardan kaçınmak istiyorsanız, desteklenen Azure bölgelerindeki sanal ağları eşlemek için Azure VNet eşlemesini kullanabilirsiniz.

Karma kaynaklar: tam yük devretme

Bu senaryoda B Şirketi, Azure'da çalışan uygulama altyapısının bir parçası ve geri kalanı şirket içinde çalışan karma bir işletme çalıştırır.

Yük devretmeden önce

Yük devretmeden önce ağ mimarisi şöyle görünür.

• Uygulama VM'leri Azure Doğu Asya'da barındırılır.
• Doğu Asya'da adres alanı 10.1.0.0/16 olan bir VNet (Kaynak VNet) vardır.
  • Doğu Asya'da, Kaynak VNet'te üç alt ağa bölünmüş iş yükleri vardır:
    • Alt ağ 1: 10.1.1.0/24
    • Alt ağ 2: 10.1.2.0/24
    • Alt ağ 3: 10.1.3.0/24, adres alanı 10.1.0.0/16 olan bir Azure sanal ağını kullanır. Bu sanal ağın adı Kaynak Sanal Ağ
• İkincil (hedef) bölge Azure Güneydoğu Asya'dır:
  • Güneydoğu Asya'da Kaynak sanal ağ ile aynı kurtarma sanal ağı (Kurtarma sanal ağı) vardır.
• Doğu Asya'daki VM'ler Azure ExpressRoute veya siteden siteye VPN ile şirket içi bir veri merkezine bağlanır.
• RTO'yu azaltmak için Şirket B, yük devretmeden önce Azure Güneydoğu Asya'da Kurtarma Sanal Ağı'nda ağ geçitleri sağlar.
• Şirket B, çoğaltılan VM'ler için hedef IP adreslerini atar/doğrular. Hedef IP adresi, her vm için kaynak IP adresiyle aynıdır.

Yük devretmeden sonra

Kaynak bölgesel kesinti oluşursa, B Şirketi tüm kaynaklarını hedef bölgeye devredebilir.

• Yük devretmeden önce hedef IP adresleri zaten mevcutken, Şirket B yük devretmeyi düzenleyebilir ve Kurtarma sanal ağı ile Azure sanal ağı arasında yük devretmeden sonra otomatik olarak bağlantılar kurabilir.
• Uygulama gereksinimlerine bağlı olarak, hedef bölgedeki iki sanal ağ (Kurtarma VNet ve Azure VNet) arasındaki bağlantılar yük devretme öncesinde, sırasında (ara adım olarak) veya sonra kurulabilir. Şirket, bağlantıların ne zaman kurulacağını belirtmek için kurtarma planlarını kullanabilir.
• Azure Güneydoğu Asya ile şirket içi veri merkezi arasında bağlantı kurulmadan önce Azure Doğu Asya ile şirket içi veri merkezi arasındaki özgün bağlantı kesilmelidir.
• Şirket içi yönlendirme, yük devretme sonrasında hedef bölgeye ve ağ geçitlerine işaret eden şekilde yeniden yapılandırılır.

Karma kaynaklar: yalıtılmış uygulama yük devretmesi

B şirketi, yalıtılmış uygulamaların yükünü alt ağ düzeyinde devredemez. Bunun nedeni kaynak ve kurtarma sanal ağlarında adres alanının aynı olması ve şirket içi bağlantı için özgün kaynağın etkin olmasıdır.

• Uygulama dayanıklılığı için Şirket B'nin her uygulamayı kendi ayrılmış Azure VNet'ine yerleştirmesi gerekir.
• Her uygulama ayrı bir sanal ağda olduğunda, Şirket B yalıtılmış uygulamaların yükünü devredebilir ve kaynak bağlantıları hedef bölgeye yönlendirebilir.

Sonraki adımlar

Kurtarma planları hakkında bilgi edinin.