Azure DNS ortak bölgelerde güvenilirlik

Azure DNS, Microsoft Azure altyapısını kullanarak ad çözümlemesi sağlar. Bu makale, genellikle sahip olduğunuz etki alanları için oluşturduğunuz ve İnternet'te bulunan uygulama ve hizmetlerin kayıtlarını yayımlamak için kullandığınız genel DNS bölgelerine odaklanır. Çözümlediğiniz ana bilgisayar adları genel olarak erişilebilir DNS adlarıdır ve çözümlenen IP adresleri genellikle İnternet'ten erişilebilen genel IP adresleridir.

Azure DNS, belirli bir kullanılabilirlik alanına veya Azure bölgeye bağlı olmayan, bölge dışı bir hizmettir.

Azure'ı kullandığınızda güvenilirlik paylaşılan bir sorumluluktır. Microsoft, dayanıklılık ve kurtarmayı desteklemek için çeşitli özellikler sunar. Bu özelliklerin kullandığınız tüm hizmetler içinde nasıl çalıştığını anlamak ve iş hedeflerinize ve çalışma süresi hedeflerinize ulaşmak için ihtiyacınız olan özellikleri seçmek sizin sorumluluğunuzdadır.

Bu makalede Azure DNS ortak bölgelerin geçici hatalara, kullanılabilirlik alanı hatalarına, bölge genelindeki hatalara, hizmet kesintilerine, güvenlik tehditlerine ve yanlış yapılandırmaya, portal ve yönetim aracı kesintilerine ve hizmet bakımına nasıl yanıt verdiği açıklanır. Ayrıca bölge yapılandırmanızın nasıl korunup geri yükleneceği açıklanır ve temel hizmet düzeyi sözleşmesi (SLA) gereksinimleri açıklanır.

Güvenilirlik için üretim dağıtımı önerileri

Azure DNS ortak bölgelerin üretim dağıtımları için güvenilirliği artırmak için şu önerileri izleyin:

  • Tüm ad sunucularına temsilci atama: Azure DNS her genel DNS bölgesine dört ad sunucusu atar. Etki alanı temsilcinizi dört ad sunucusunun tümünü kullanacak şekilde yapılandırın. Bu yapılandırma hata yalıtımı sağlar ve Azure DNS SLA'ya hak kazanmak için gereklidir.

  • Uygun TTL değerlerini yapılandırın: Sorgu hacmini istemcilerin kayıt değişikliklerini ne kadar hızlı aldığıyla dengeleyen yaşam süresi (TTL) değerlerini ayarlayın. Daha düşük TTL değerleri, istemcilerin değişiklikleri daha erken almasına, ancak sorgu hacmini artırmasına olanak tanır. Daha yüksek TTL değerleri sorgu hacmini azaltır, ancak bir kaydı değiştirdikten sonra otomatik geçişi geciktirebilir.

  • Desteklenen Azure kaynakları için diğer ad kayıtlarını kullanma:Diğer ad kayıtları, DNS çözümlemesi sırasında temel alınan Azure kaynağındaki değişiklikleri otomatik olarak yansıtır ve eski DNS kayıtlarının önlenmesine yardımcı olur.

Güvenilirlik mimarisine genel bakış

Bu bölümde, hizmetin nasıl çalıştığına ilişkin güvenilirlik açısından en uygun olan bazı önemli yönler açıklanmaktadır. bölümünde dağıttığınız ve kullandığınız bazı kaynak ve özellikleri içeren mantıksal mimari tanıtılır. Ayrıca, hizmetin kapaklar altında nasıl çalıştığına ilişkin ayrıntılar sağlayan fiziksel mimariyi de ele alır.

Mantıksal mimari

Dağıttığınız birincil kaynak, bir etki alanı için DNS kayıt kümelerini içeren bir bölgedir. Kayıt kümesi, BIR DNS adını IP adresi veya uç nokta gibi bir değerle ilişkilendirir. Genel DNS bölgesinin çözümlediğini adlara İnternet üzerinden erişilebilir.

Azure DNS’yi etki alanınız için yetkili duruma getirmek amacıyla, etki alanını devredin; bunu, bölgeyi oluşturduğunuzda Azure’un atadığı ad sunucularına yapın. Temsilci seçme işlemi tamamlandıktan sonra, Azure DNS destekleyen DNS kayıt türleri için kayıt kümeleri oluşturursunuz. DNS kaydının hedef kaynakla eşzamanlı kalması için, genel IP adresleri, Traffic Manager profilleri ve Azure Front Door uç noktaları gibi Azure kaynaklarını işaret eden takma ad kayıtları da oluşturabilirsiniz.

DNS çözümlemesi sırasında özyinelemeli DNS çözümleyicileri, bölgenizin Azure DNS yetkili ad sunucularına ulaşmak için DNS hiyerarşisini izler.

Important

Azure DNS adları çözümler ancak uç nokta durumunu izlemez veya uygulama trafiğini yönlendirmez. Genel çözümünüzün güvenilirliği, SANAL makineler ve yük dengeleyiciler gibi DNS kayıtlarınızın başvurduğunu kaynakların yapılandırmasına bağlıdır.

Bu makale bu kaynakları kapsamaz, ancak kullanılabilirlik yapılandırmaları uygulamanızın dayanıklılığını doğrudan etkiler. Her hizmetin güvenilirlik gereksinimlerinizi nasıl desteklediğini öğrenmek için çözümünüzdeki Azure hizmetlerinin güvenilirlik kılavuzlarını gözden geçirin.

Fiziksel mimari

Azure DNS, bölge dışı bir hizmet olarak çalışır ve altyapısını dünya çapındaki birden çok Azure bölgede birden çok kullanılabilirlik alanına dağıtır. Bu tasarım, başka bir bölgedeki veya bölgedeki altyapı çözüm isteklerine yanıt vermeye devam ettiğinden, kullanılabilirlik alanı veya bölge kesintisi sırasında Azure DNS dayanıklı kalmasını sağlar.

Anycast, DNS ve BGP gibi genel internet protokolleri, gelen DNS çözümleme isteklerini otomatik olarak en yakın iyi durumdaki Azure DNS altyapısına yönlendirir.

Azure DNS sunum düzlemi, biri Linux üzerinde, diğeri de Windows üzerinde çalışan iki bağımsız hizmet yığınında etkin-etkin bir yapılandırmada çalışır. Bu yığınlar hiçbir kodu ve temel alınan donanımı paylaşmaz. Bağımsız olduklarından, bir yığını etkileyen bir hata, güvenlik açığı veya hata diğerini etkilemez. Bu bağımsızlık, tek bir hata noktasının neden olduğu eksiksiz bir hizmet kesintisi riskini azaltır ve belirli sıfır günlük güvenlik açıklarına karşı korunmaya yardımcı olur.

Geçici hatalara dayanıklılık

Geçici hatalar, bileşenlerde kısa ve aralıklı hatalardır. Bunlar genellikle bulut gibi dağıtılmış bir ortamda gerçekleşir ve işlemlerin normal bir parçasıdır. Geçici hatalar kısa bir süre sonra kendilerini düzeltmektedir. Uygulamalarınızın genellikle etkilenen istekleri yeniden deneyerek geçici hataları işleyebileceği önemlidir.

Bulutta barındırılan tüm uygulamalar, bulutta barındırılan API'ler, veritabanları ve diğer bileşenlerle iletişim kurarken Azure geçici hata işleme yönergelerini izlemelidir. Daha fazla bilgi için bkz Geçici hataları ele alma önerileri.

Azure DNS, genel DNS altyapısı aracılığıyla geçici hataları işler.

DNS çözümlemesi sırasında geçici bir hata oluşursa, istemci veya ara çözümleyici yapılandırılmış DNS yeniden deneme davranışına göre yeniden denemelidir. 2 ile 5 saniye arasında bir DNS istemcisi için genellikle yeterli zaman aşımı olur.

Her DNS kaydının yaşam süresi (TTL), çözümünüzün hataları işleme şeklini de etkiler. TTL çok düşükse istemcilerin Azure DNS için daha fazla istekte bulunmaları gerekir ve geçici hataların ortaya çıkması için daha fazla olası fırsat vardır. TTL çok yüksekse, arka uç sunucusunda farklı bir IP adresine yeniden yönlendirmenizi gerektiren gerçek bir hata durumunda, istemciler TTL'nin süresi dolana kadar yük devretmede gecikmeler yaşayabilir. Kullanılabilirlik, gecikme süresi ve yanıt hızını dengelemek için TTL'leri dikkatli bir şekilde yapılandırın.

Kullanılabilirlik alanı hatalarına dayanıklılık

Kullanılabilirlik alanları , bir Azure bölgesi içindeki veri merkezlerinin fiziksel olarak ayrı gruplarıdır. Bir bölge başarısız olduğunda hizmetler kalan bölgelerden birine devredilebilir.

Azure DNS, bölge dışı bir hizmet olarak çalışır. Microsoft altyapısını birden çok Azure bölgesinde birden çok kullanılabilirlik alanına dağıtır ve değişiklikleri bu altyapı genelindeki genel DNS bölgelerinize çoğaltır. Kullanılabilirlik alanlarını seçmez veya alanlar arası yedekliliği yapılandırmazsınız. Kullanılabilirlik alanı kesintisi sırasında, başka bir bölgedeki veya bölgedeki altyapı çözüm isteklerine yanıt vermeye devam eder.

Sanal makine (VM) gibi tek bir kullanılabilirlik alanına dağıttığınız bir kaynak, bölge hatası sırasında kullanılamaz duruma gelirse Azure DNS uç nokta durumunu izlemediğinden kaynağın yapılandırılmış IP adresini döndürmeye devam eder. İyi durumdaki bir bölgedeki bir kaynağa yük devrediyorsanız, istemcilerin iyi durumdaki kaynağı kullanması için DNS kaydını güncelleştirmek sizin sorumluluğundadır. Alternatif olarak, kaynakları trafiği sağlıklı bölgelerdeki VM’lere yönlendiren bölge yedekli bir yük dengeleyicinin arkasına yerleştirin.

Bölge genelindeki hatalara dayanıklılık

Bölge verileri genel olarak kullanılabilir ve birden çok Azure bölgeye dağıtıldığından DNS bölgeleri bölge kesintilerine karşı dayanıklıdır. Bir bölgede kesinti varsa, bu bölgeye dağıttığınız sanal ağlar ve VM'ler gibi kaynaklar kullanılamayabilir, ancak Azure DNS bölgenizdeki kayıtları çözümlemeye devam eder.

Olağanüstü durum kurtarma amacıyla birden çok bölge arasında geçiş yapması gereken bir çözümünüz varsa Azure Traffic Manager veya Azure Front Door kullanmayı göz önünde bulundurun. Bu hizmetler, bir bölge iyi durumda değilse kullanabileceğiniz otomatik yük devretme özellikleri sağlar.

Güvenlik tehditlerine dayanıklılık ve yanlış yapılandırma

Güvenlik saldırıları ve yapılandırma hataları, DNS bölgeleri için en önemli güvenilirlik risklerinden ikisidir. Çeşitli saldırı sınıfları özellikle DNS çözümlemesini hedefler ve yanlışlıkla yanlış yapılandırma iş yüklerinizi de ciddi şekilde kesintiye uğratabilir.

Genel DNS bölgelerine özgü kapsamlı güvenlik yönergeleri için bkz. Azure DNS dağıtımınızın güvenliğini sağlama ve DNS Bölgelerini ve Kayıtlarını Koruma.

Hizmet kesintilerine dayanıklılık

Azure DNS, uygulamanız belirli koşulları karşıladığında 100% kullanılabilirlik SLA'sı ile son derece dayanıklı bir hizmettir. Hizmet kesintileri son derece olağan dışıdır, ancak ağ sorunları veya diğer altyapıyla ilgili sorunlar Azure DNS hizmetine bağlantıyı kesintiye uğratabilir.

Azure DNS dayanıklılığı kısmen küresel olarak dağıtılmış, etkin-etkin sunum düzlemi mimarisinden kaynaklanır.

Birden çok ad sunucusu kullanma

Azure DNS her genel DNS bölgesine dört ad sunucusu atar. Alan adınız için yetki devri yaptığınızda, dört ad sunucusunun tamamını yapılandırın. Çözümleyici bir ad sunucusuna ulaşamıyorsa, başka bir ad sunucusu sorgulayabilir.

Hizmet kesintilerini izleme

Azure DNS durumunu izlemek için Azure Hizmet Durumu kullanın. Hizmet Durumu uyarılarını, hizmet olayları hakkında sizi bilgilendirecek şekilde yapılandırın.

Hizmet kesintilerini test edin

Azure Chaos Studio, bazı test iş yükü türlerinin içinden DNS çözümleme başarısızlıklarını simüle eden arızalar sağlar. Bu hatalar Azure DNS bir kesintiyi tetiklemez. Chaos Studio aracısı DNS Hatası hatasını, AKS Chaos Mesh ise DNS Chaos özelliğini sağlar. Kısmi ağ hatası gibi DNS çözümlemesi başarısız olduğunda uygulamalarınızın ve altyapınızın nasıl yanıt verdiğini test etmek için bu hataları kullanın.

Portal ve yönetim aracı kesintilerine dayanıklılık

Azure portalında genel DNS bölgenizi yönetiyorsanız, özellikle de kesinti sırasında bölgeyi yeniden yapılandırmanız gerekebilirse portala erişememe senaryoları için alternatif bir yönetim yolu hazırlayın.

Azure portalı kullanılamıyorsa, genel DNS bölgenizi yönetmek için Bicep veya Terraform gibi Azure CLI,Azure PowerShell veya kod olarak altyapıyı (IaC) kullanın. Azure portalının düzeyi düşürülmüş olsa bile bu araçlar çalışır durumda kalır.

Yedekleme ve geri yükleme

Azure DNS durum bilgisi olmayan bir hizmettir. Ortak DNS bölgeleri için yönetilen yedeklemeler veya belirli bir zamandaki noktaya geri yükleme sağlamaz.

Tüm Azure kaynak yapılandırmasını korumak için, Bicep veya Terraform gibi IaC kullanarak genel DNS bölgelerinizi tanımlayın ve tanımları kaynak denetiminde depolayın. Yapılandırmanızı yeniden dağıtmak için bunları kullanabilmek için tanımları düzenli aralıklarla test edin.

Ek kayıt düzeyi kurtarma seçeneği olarak , BIND uyumlu bir bölge dosyasını dışarı aktarın. Bölge dosyasını içe aktarmanın sınırlamaları vardır ve Azure’a özgü her kaynak ayarını korumaz; bu nedenle dışarı aktarılan bir bölge dosyasını tek kurtarma öğeniz olarak kullanmayın. Belgelenen içeri aktarma sınırlamalarını gözden geçirin ve bir bölgeyi geri yükledikten sonra kayıtları doğrulayın.

Hizmet bakımına dayanıklılık

Microsoft düzenli olarak hizmet güncelleştirmeleri uygular ve başka bakımlar gerçekleştirir. Azure platformu bu etkinlikleri otomatik olarak işleyerek bakımın sizin için sorunsuz ve şeffaf olmasını sağlar. Azure Hizmet Durumu planlı bakım aracılığıyla size bildirilmedikçe, bakım olayları sırasında kapalı kalma süresi olmayacağı öngörülmektedir.

Hizmet düzeyi sözleşmesi

Azure hizmetleri için hizmet düzeyi sözleşmesi (SLA), her hizmetin beklenen kullanılabilirliğini ve bu kullanılabilirlik beklentisini elde etmek için çözümünüzün karşılaması gereken koşulları açıklar. Daha fazla bilgi için bkz. çevrimiçi hizmetler için SLA’lar.

Azure DNS, belirli koşullar karşılandığı sürece geçerli DNS sorgu yanıtları için 100% kullanılabilirlik SLA'sı sağlar. Bu koşullar, başarısız istekleri en az 60 ardışık saniye boyunca tekrar tekrar denemeyi ve Azure DNS bölgenize atayan tüm ad sunucularını kullanmayı içerir. Ayrıntılı koşullar için SLA belgesini gözden geçirin.

İlgili içerik

  • Last updated on