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

Azure Site Recovery, VM'leri başka bir Azure bölgesine çoğaltarak, kesinti yaşandığında 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 kurtarmayı etkinleştirir.

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 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 devretme sonrasında 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ıma sahip 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

Çoğaltma artık dünyanın dört bir yanındaki iki Azure bölgesi arasında gerçekleştirilebilir. Müşteriler artık kendi kıtaları içinde çoğaltmayı etkinleştirmekle 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.
• Kurtarma süresi hedeflerini (RTO) azaltmak için şirket, SQL Server AlwaysOn, etki alanı denetleyicileri vb. için çoğaltma düğümleri 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 ayrılmış 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 VNet ile aynı kurtarma sanal ağı (Kurtarmasanal 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 VNet , adres alanı 10.2.4.0/24 olan bir alt ağ (Alt ağ 4) içerir.
    • SQL Server AlwaysOn, etki alanı denetleyicisi vb. için çoğaltma düğümleri Alt Ağ 4'te bulunur.
  • Kaynak sanal ağ ve Azure sanal ağı bir VPN siteden 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.

• Yük devretmeden önce hedef IP adresleri zaten mevcutken, Şirket A yük devretmeyi düzenleyebilir ve Kurtarma sanal ağı ile Azure VNet 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 Sanal Ağı 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ı 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ü 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 devretmek için.

• Bu senaryoda, IP adreslemesi korunabiliyor olsa da, bağlantı tutarsızlıkları olasılığını artırdığından genellikle önerilmez. Ayrıca aynı Azure VNet 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ı kaynak bölgeye ayrılmış sanal ağlara 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:

  • Uygulama1 VM'ler VNet Kaynak Sanal Ağ 1: 10.1.0.0/16'da bulunur.
  • Uygulama2 VM'ler Sanal Ağ Kaynağı 2: 10.2.0.0/16'da bulunur.
  • Kaynak VNet 1'in iki alt ağı vardır.
  • Kaynak VNet 2'nin iki alt ağı vardır.

• İkincil (hedef) bölge Azure Güneydoğu Asya- Güneydoğu Asya'da Kaynak VNet 1 ve Kaynak VNet 2 ile aynı olan kurtarma sanal ağları (Kurtarma VNet 1 ve Kurtarma VNet2) vardır. - Kurtarma VNet 1 ve Kurtarma VNet 2'nin her birinde Kaynak VNet 1 ve Kaynak VNet2'deki alt ağlarla eşleşen iki alt ağ vardır- Güneydoğu Asya'da 10.3.0.0/16 adres alanına sahip ek bir VNet (Azure VNet) vardır. - Azure VNet , 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 VNet 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 durumunda (örneğimizdeki **Kaynak VNet 2'de), Şirket A etkilenen uygulamayı şu şekilde 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'leri Kurtarma VNet2'ye yük devretme.

• 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ı modelinin izlendiğinden emin olmak önerilir.
• 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 bölümü 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ğı (Kurtarmasanal ağı) vardır.
• Doğu Asya'daki VM'ler, Azure ExpressRoute veya siteden siteye VPN ile şirket içi veri merkezine bağlanır.
• Şirket B, RTO'yu azaltmak için yük devretmeden önce Azure Güneydoğu Asya'daki 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ölgeyi ve ağ geçitlerini işaret etmek için 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 sanal asına yerleştirmesi gerekir.
• Her uygulama ayrı bir VNet'te olduğunda, Şirket B yalıtılmış uygulamaların yükünü devredebilir ve kaynak bağlantılarını hedef bölgeye yönlendirebilir.

Sonraki adımlar

Kurtarma planları hakkında bilgi edinin.