Azure Site Recovery ile Azure Traffic Manager

Azure Traffic Manager, uygulama uç noktalarınızdaki trafiğin dağıtımını denetlemenize olanak tanır. Uç nokta, Azure içinde veya dışında barındırılan İnternet'e yönelik bir hizmettir.

Traffic Manager, bir trafik yönlendirme yöntemine ve uç noktaların durumuna bağlı olarak istemci isteklerini en uygun uç noktaya yönlendirmek için Etki Alanı Adı Sistemi'ni (DNS) kullanır. Traffic Manager, farklı uygulama ihtiyaçlarına ve otomatik yük devretme modellerine uyan farklı trafik yönlendirme yöntemleri ve uç nokta izleme seçenekleri sunar. İstemciler doğrudan seçilen uç noktaya bağlanır. Traffic Manager bir ara sunucu veya ağ geçidi değildir ve istemci ile hizmet arasında geçen trafiği görmez.

Bu makalede, Azure Trafik İzleyicisi'nin akıllı yönlendirmesini Azure Site Recovery güçlü olağanüstü durum kurtarma ve geçiş özellikleriyle nasıl birleştirebileceğiniz açıklanır.

Şirket içi ortamdan Azure'a yük devretme

İlk senaryo için, tüm uygulama altyapısı şirket içi ortamında çalışan Şirket A'yı göz önünde bulundurun. A Şirketi, iş sürekliliği ve uyumluluk nedenleriyle uygulamalarını korumak için Azure Site Recovery kullanmaya karar verir.

A Şirketi , genel uç noktaları olan uygulamalar çalıştırıyor ve bir olağanüstü durum olayında trafiği sorunsuz bir şekilde Azure'a yönlendirebilmeyi istiyor. Azure Traffic Manager'daki Priority traffic-routing yöntemi, Şirket A'nın bu yük devretme düzenini kolayca uygulamasına olanak tanır.

Kurulum aşağıdaki gibidir:

• A Şirketi bir Traffic Manager profili oluşturur.
• Öncelik yönlendirme yöntemini kullanan Şirket A, şirket içi için birincil ve Azure için Yük Devretme olmak üzere iki uç nokta oluşturur. Birincile Öncelik 1, Yük Devretmeye öncelik 2 atanır.
• Birincil uç nokta Azure dışında barındırıldığından, uç nokta dış uç nokta olarak oluşturulur.
• Azure Site Recovery ile Azure sitesinde yük devretme öncesinde çalışan sanal makine veya uygulama yoktur. Bu nedenle , Yük Devretme uç noktası bir Dış uç nokta olarak da oluşturulur.
• Varsayılan olarak, bu uç noktayla ilişkilendirilmiş en yüksek önceliğe sahip olduğundan kullanıcı trafiği şirket içi uygulamaya yönlendirilir. Birincil uç nokta iyi durumdaysa Azure'a hiçbir trafik yönlendirilir.

Olağanüstü bir durumda, A Şirketi Azure'a yük devretmeyi tetikleyebilir ve Azure'daki uygulamalarını kurtarabilir. Azure Traffic Manager , Birincil uç noktanın artık iyi durumda olmadığını algıladığında, DNS yanıtında otomatik olarak Yük Devretme uç noktasını kullanır ve kullanıcılar Azure'da kurtarılan uygulamaya bağlanır.

A Şirketi, iş gereksinimlerine bağlı olarak olağanüstü bir durumda şirket içi ile Azure arasında geçiş yapmak ve kullanıcılar için en düşük kapalı kalma süresini sağlamak için daha yüksek veya daha düşük bir olasılık sıklığı seçebilir.

Olağanüstü durum olduğunda, A Şirketi Azure Site Recovery kullanarak Azure'dan şirket içi ortamına (VMware veya Hyper-V) yeniden çalışma yapabilir. Traffic Manager, Birincil uç noktanın yeniden iyi durumda olduğunu algıladığında, DNS yanıtlarında Otomatik olarak Birincil uç noktayı kullanır.

Şirket içi ortamdan Azure'a geçiş

Azure Site Recovery, olağanüstü durum kurtarmanın yanı sıra Azure'a geçişleri de etkinleştirir. Müşteriler, Azure Site Recovery'nin güçlü yük devretme testi özelliklerini kullanarak şirket içi ortamlarını etkilemeden Azure'da uygulama performansını değerlendirebilir. Müşteriler geçişe hazır olduğunda iş yüklerinin tamamını birlikte geçirmeyi veya aşamalı olarak geçirmeyi ve ölçeklendirmeyi seçebilir.

Azure Traffic Manager'ın Ağırlıklı yönlendirme yöntemi, gelen trafiğin bir bölümünü Azure'a yönlendirirken çoğunluğu şirket içi ortama yönlendirmek için kullanılabilir. Bu yaklaşım, iş yüklerinizin her geçen gün daha fazlasını Azure'a geçirirken Azure'a atanan ağırlığı artırmaya devam edebilirsiniz ve ölçek performansını değerlendirmenize yardımcı olabilir.

Örneğin, Şirket B , uygulama ortamının bir bölümünü taşırken geri kalanını şirket içinde tutarak aşamalar halinde geçirmeyi seçer. Ortamın çoğunun şirket içinde olduğu ilk aşamalarda, şirket içi ortama daha büyük bir ağırlık atanır. Traffic Manager, kullanılabilir uç noktalara atanan ağırlıkları temel alan bir uç nokta döndürür.

Geçiş sırasında her iki uç nokta da etkindir ve trafiğin çoğu şirket içi ortama yönlendirilir. Geçiş devam ettikçe Azure'da uç noktaya daha büyük bir ağırlık atanabilir ve son olarak geçiş sonrasında şirket içi uç nokta devre dışı bırakılabilir.

Azure'da Azure'a yük devretme

Bu örnekte, tüm uygulama altyapısı Azure çalıştıran Şirket C'yi düşünün. İş sürekliliği ve uyumluluk nedenleriyle C Şirketi, uygulamalarını korumak için Azure Site Recovery kullanmaya karar verir.

C şirketi genel uç noktaları olan uygulamalar çalıştırıyor ve bir olağanüstü durum olayında trafiği farklı bir Azure bölgesine sorunsuz bir şekilde yeniden yönlendirebilmeyi istiyor. Öncelik trafik yönlendirme yöntemi, C Şirketinin bu yük devretme düzenini kolayca uygulamasına olanak tanır.

Kurulum aşağıdaki gibidir:

• C Şirketi bir Traffic Manager profili oluşturur.
• Öncelik yönlendirme yöntemini kullanan C Şirketi iki uç nokta oluşturur: Kaynak bölge için birincil (Azure Doğu Asya) ve kurtarma bölgesi (Azure Güneydoğu Asya) için yük devretme. Birincile Öncelik 1, Yük Devretmeye öncelik 2 atanır.
• Birincil uç nokta Azure'da barındırılırken uç nokta bir Azure uç noktası olabilir.
• Azure Site Recovery ile kurtarma Azure sitesinde yük devretme öncesinde çalışan sanal makine veya uygulama yoktur. Bu nedenle Yük Devretme uç noktası dış uç nokta olarak oluşturulabilir.
• Varsayılan olarak, kullanıcı trafiği kaynak bölge (Doğu Asya) uygulamasına yönlendirilir, bu uç nokta onunla ilişkilendirilmiş en yüksek önceliğe sahiptir. Birincil uç nokta iyi durumdaysa kurtarma bölgesine hiçbir trafik yönlendirilir.

Bir olağanüstü durumda, C Şirketibir yük devretme tetikleyebilir ve kurtarma Azure bölgesinde uygulamalarını kurtarabilir. Azure Traffic Manager Birincil uç noktanın artık iyi durumda olmadığını algıladığında, OTOMATIK olarak DNS yanıtında Yük Devretme uç noktasını kullanır ve kullanıcılar kurtarma Azure bölgesinde (Güneydoğu Asya) kurtarılan uygulamaya bağlanır.

İş gereksinimlerine bağlı olarak, C Şirketi kaynak ve kurtarma bölgeleri arasında geçiş yapmak ve kullanıcılar için en düşük kapalı kalma süresini sağlamak için daha yüksek veya daha düşük bir yoklama sıklığı seçebilir.

Olağanüstü durum olduğunda C Şirketi, Kurtarma Azure bölgesinden kaynak Azure bölgesine Azure Site Recovery kullanarak yeniden çalışma yapabilir. Traffic Manager, Birincil uç noktanın yeniden iyi durumda olduğunu algıladığında, DNS yanıtlarında Otomatik olarak Birincil uç noktayı kullanır.

Çok bölgeli kurumsal uygulamaları koruma

Küresel kuruluşlar genellikle uygulamalarını bölgesel ihtiyaçları karşılayacak şekilde uyarlayarak müşteri deneyimini geliştirir. Yerelleştirme ve gecikme süresinin azaltılması, uygulama altyapısının bölgeler arasında bölünmesine neden olabilir. Kuruluşlar ayrıca belirli alanlardaki bölgesel veri yasalarına bağlıdır ve uygulama altyapılarının bir bölümünü bölgesel sınırlar içinde yalıtmayı tercih eder.

D Şirketinin uygulama uç noktalarını Almanya'ya ve dünyanın geri kalanına ayrı ayrı hizmet verecek şekilde böldüğü bir örneği ele alalım. Şirket D , bunu ayarlamak için Azure Traffic Manager'ın Coğrafi yönlendirme yöntemini kullanır. Almanya'dan kaynaklanan tüm trafik Uç Nokta 1'e , Almanya dışından gelen tüm trafik ise Uç Nokta 2'ye yönlendirilir.

Bu kurulumdaki sorun , Uç Nokta 1'in herhangi bir nedenle çalışmayı durdurması durumunda trafiğin Uç Nokta 2'ye yeniden yönlendirilmemesidir. Almanya'dan kaynaklanan trafik uç noktanın durumu ne olursa olsun Uç Nokta 1'e yönlendirilmeye devam eder ve Alman kullanıcıları Şirket D'nin uygulamasına erişimsiz bırakır. Benzer şekilde, Uç Nokta 2 çevrimdışı olursa trafiğin Uç Nokta 1'e yeniden yönlendirmesi olmaz.

Bu sorunla karşılaşmamak ve uygulama dayanıklılığını sağlamak için Şirket D, Azure Site Recovery ile iç içe Traffic Manager profillerini kullanır. İç içe profil kurulumunda trafik tek tek uç noktalara değil, diğer Traffic Manager profillerine yönlendirilir. Bu kurulum şu şekilde çalışır:

• Şirket D, coğrafi yönlendirmeyi tek tek uç noktalarla kullanmak yerine Traffic Manager profilleriyle Coğrafi yönlendirmeyi kullanır.
• Her alt Traffic Manager profili birincil ve kurtarma uç noktasıyla Öncelik yönlendirmesini kullanır, bu nedenle Coğrafi yönlendirme içinde Öncelik yönlendirmesi iç içe yerleştirilmiştir.
• Uygulama dayanıklılığını etkinleştirmek için her iş yükü dağıtımı, olağanüstü durum durumunda kurtarma bölgesine yük devretmek için Azure Site Recovery kullanır.
• Üst Traffic Manager bir DNS sorgusu aldığında, sorguya uygun bir uç noktayla yanıt veren ilgili alt Traffic Manager'a yönlendirilir.

Örneğin, Orta Almanya'daki uç nokta başarısız olursa uygulama hızla Kuzeydoğu Almanya'ya kurtarılabilir. Yeni uç nokta, Kullanıcılar için en düşük kapalı kalma süresiyle Almanya'dan gelen trafiği işler. Benzer şekilde Batı Avrupa'daki bir uç nokta kesintisi, uygulama iş yükünün Kuzey Avrupa'ya kurtarılması ve Azure Traffic Manager'ın kullanılabilir uç noktaya DNS yönlendirmelerini işlemesi ile işlenebilir.

Yukarıdaki kurulum, gereken sayıda bölge ve uç nokta bileşimi içerecek şekilde genişletilebilir. Traffic Manager en fazla 10 iç içe profil düzeyine izin verir ve iç içe yapılandırma içinde döngülere izin vermez.

Kurtarma Süresi Hedefi (RTO) ile ilgili dikkat edilmesi gerekenler

Çoğu kuruluşta DNS kayıtlarını ekleme veya değiştirme işlemi ayrı bir ekip veya kuruluş dışındaki bir kişi tarafından gerçekleştirilir. Bu, DNS kayıtlarını değiştirme görevini çok zorlaştırır. DNS altyapısını yöneten diğer takımların veya kuruluşların DNS kayıtlarını güncelleştirme süresi kuruluştan kuruluşa değişir ve uygulamanın RTO'sunu etkiler.

Traffic Manager'ı kullanarak DNS güncelleştirmeleri için gereken işi önyükleyebilirsiniz. Gerçek yük devretme sırasında el ile veya betikli eylem gerekmez. Bu yaklaşım, hızlı geçişe (ve dolayısıyla RTO'yu düşürmeye) yardımcı olur ve bir olağanüstü durum olayında yüksek maliyetli zaman alan DNS değişiklik hatalarını önler. Traffic Manager ile yeniden çalışma adımı bile otomatiktir ve aksi takdirde ayrı olarak yönetilmesi gerekir.

Temel veya hızlı aralık sistem durumu denetimleri aracılığıyla doğru yoklama aralığının ayarlanması, yük devretme sırasında RTO'yu önemli ölçüde düşürebilir ve kullanıcılar için kapalı kalma süresini azaltabilir.

Traffic Manager profili için DNS Yaşam Süresi (TTL) değerini de iyileştirebilirsiniz. TTL, bir DNS girişinin istemci tarafından önbelleğe alınacağı değerdir. Kayıt için DNS, TTL'nin yayılması içinde iki kez sorgulanmaz. Her DNS kaydının kendisiyle ilişkilendirilmiş bir TTL'leri vardır. Bu değerin azaltılması Traffic Manager'a daha fazla DNS sorgusuyla sonuçlanır, ancak kesintileri daha hızlı keşfederek RTO'yu azaltabilir.

İstemci ile yetkili DNS sunucusu arasındaki DNS çözümleyicilerinin sayısı arttığında istemci tarafından karşılaşılan TTL de artmıyor. DNS çözümleyicileri TTL'yi 'sayar' ve yalnızca kayıt önbelleğe alındıktan sonra geçen süreyi yansıtan bir TTL değerini geçirir. Bu, zincirdeki DNS Çözümleyicilerinin sayısından bağımsız olarak TTL'nin ardından istemcide DNS kaydının yenilenmesini sağlar.

Sonraki adımlar

• Traffic Manager yönlendirme yöntemleri hakkında daha fazla bilgi edinin.
• İç içe Traffic Manager profilleri hakkında daha fazla bilgi edinin.
• Uç nokta izleme hakkında daha fazla bilgi edinin.
• Uygulama yük devretmeyi otomatikleştirmek için kurtarma planları hakkında daha fazla bilgi edinin.