Azure Site Recovery ile Azure Traffic Manager

Azure Traffic Manager, uygulama uç noktalarınızda trafiğin dağıtımını denetlemenizi sağlar. 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'nin güçlü olağanüstü durum kurtarma ve geçiş özellikleriyle nasıl birleştirebileceğiniz açıklanır.

Şirket içinde Azure yük devretmesi

İ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ç noktalarla uygulama çalıştırıyor ve olağanüstü bir olayda 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. Birincil için Öncelik 1 ve Yardımcı için Ö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, kullanıcı trafiği şirket içi uygulamaya yönlendirilir çünkü bu uç nokta onunla ilişkilendirilmiş en yüksek önceliğe sahiptir. Birincil uç nokta iyi durumdaysa Azure'a hiçbir trafik yönlendirilmemiştir.

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 üzerinde yeniden çalışır duruma getirilen uygulamaya bağlanır.

A Şirketi, iş gereksinimlerine bağlı olarak bir olağanüstü 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 yoklama sıklığı seçebilir.

Felaket kontrol altına alındığında, A Şirketi Azure Site Recovery'yi kullanarak Azure'dan şirket içi ortamına (VMware veya Hyper-V) geri dönüş 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 Azure'a geçiş

Olağanüstü durum kurtarmanın yanı sıra Azure Site Recovery, Azure'a geçişleri de etkinleştirir. Azure Site Recovery'nin güçlü yük devretme testi özelliklerini kullanan müşteriler, ş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 daha fazlasını Azure'a geçirirken, Azure'a atanan ağırlığı artırmaya devam edebileceğiniz için ölçek performansını değerlendirmeye yardımcı olabilir.

Örneğin, B Şirketi, uygulama ortamının bir kısmını taşırken geriye kalanları şirket içinde tutarak geçişi aşamalar halinde yapmayı 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ş işlemi 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'dan Azure'a yük devretme

Bu örnekte, tüm uygulama altyapısı Azure çalıştıran Şirket C'yi göz önünde bulundurun. İş 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 olağanüstü durum olayında trafiği farklı bir Azure bölgesine sorunsuz bir şekilde yeniden yönlendirme olanağı istiyor. Priority traffic-routing yöntemi, Şirket C'nin bu hata toleransı 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 Şirket C, kaynak bölge (Azure Doğu Asya) için birincil ve kurtarma bölgesi (Azure Güneydoğu Asya) için yük devretme olmak üzere iki uç nokta oluşturur. Birincil için Öncelik 1 ve Yardımcı için Öncelik 2 atanır.
• Birincil uç nokta Azure'da barındırılıyor olduğundan, uç nokta bir Azure uç noktası olarak olabilir.
• Azure Site Recovery ile kurtarma için Azure sitesinde yük devretmeden önce çalışan sanal makine veya uygulama yoktur. Bu yüzden, Yük Devretme uç noktası Harici bir 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 hiçbir trafik kurtarma bölgesine yönlendirilmez.

Bir olağanüstü durumda, C Şirketi bir hata toleransı işlevi tetikleyebilir ve kurtarma Azure bölgesinde uygulamalarını geri yükleyebilir. 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 kurtarma Azure bölgesinde (Güneydoğu Asya) kurtarılan uygulamaya bağlanır.

C Şirketi, iş gereksinimlerine bağlı olarak 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.

Afet kontrol altına alındığında, Şirket C Azure Site Recovery'yi kullanarak kurtarma Azure bölgesinden kaynak Azure bölgesine geri dönebilir. 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üresini azaltma, uygulama altyapısının bölgeler arasında bölünmesine neden olabilir. Kuruluşlar ayrıca belirli alanlarda 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ı seçer.

Şirket D'nin 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 yönlendirilir ve Almanya dışından gelen tüm trafik Uç Nokta 2'ye yönlendirilir.

Bu kurulumdaki sorun, Uç Nokta 1 herhangi bir nedenle çalışmayı durdurursa 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.

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

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

Örneğin, Batı Avrupa'da bir uç nokta arızalanırsa, uygulama Kuzey Avrupa'ya geri getirilebilir. Yeni uç nokta, bölgesel trafiği kullanıcılar için minimum kesinti süresiyle yönetiyor. Azure-to-Azure bölgesi destek matrisinden kaynak ve kurtarma bölgelerini seçin.

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ırmada 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 ekiplerin 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 betik bazlı herhangi bir müdahale gerekmez. Bu yaklaşım, hızlı geçişe (ve dolayısıyla RTO'yu düşürmeye) yardımcı olur ve olağanüstü durum olaylarında yüksek maliyetli zaman alan DNS değişiklik hatalarını önler. Traffic Manager ile geri dönüş adımı bile otomatiktir, aksi takdirde ayrı olarak yönetilmesi gerekir.

Temel veya hızlı aralıklarla yapılan sağlık kontrolleriyle doğru yoklama aralığının ayarlanması, failover sırasında RTO'yu önemli ölçüde azaltabilir ve kullanıcılar için kesinti süresini düşürebilir.

Ayrıca Traffic Manager profili için DNS Yaşam Süresi (TTL) değerini de iyileştirebilirsiniz. TTL, bir DNS girişinin bir istemci tarafından önbelleğe alınacağı değerdir. Kayıt için DNS, TTL'nin yayılma alanı 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'da daha fazla DNS sorgusuna neden olur, ancak kesintileri daha hızlı keşfederek RTO'yu azaltabilir.

İstemci ile yetkili DNS sunucusu arasındaki DNS çözümleyicilerinin sayısı artarsa, 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.