Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
Azure DNS özel bölgeler, Azure sanal ağlarda güvenli ad çözümlemesi sağlar. Özel DNS bölgelerinin kapsamını bir veya daha fazla sanal ağ olarak ayarlayabilirsiniz ve kuruluşlar bunları genellikle iç uygulamalar için kullanır. Çözümlediğiniz ana bilgisayar adları, İnternet üzerinden genel olarak erişilmeyecek yerel DNS adlarıdır. Çözümlenen IP adresleri genellikle İnternet'ten erişililmeyen özel IP adresleridir. Azure DNS, belirli bir kullanılabilirlik alanına veya tek bir bölgeye bağlı olmayan genel 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 özel bölgelerin geçici hatalar ve bölge genelindeki hatalar da dahil olmak üzere çeşitli olası kesintilere ve sorunlara karşı nasıl dayanıklı hale getirildiği açıklanmaktadır. Ayrıca Azure DNS özel bölgeler hizmet düzeyi sözleşmesi (SLA) hakkında önemli bilgiler sağlar.
Güvenilirlik için üretim dağıtımı önerileri
Üretim iş yükleri için şu önerileri izlemenizi öneririz:
Uygun TTL değerlerini yapılandırın: Kurtarma süresiyle performansı dengeleyen yaşam süresi (TTL) değerlerini ayarlayın. Düşük TTL değerleri daha hızlı yük devretmeyi sağlar ancak sorgu hacmini artırır. Üretim iş yükleri için başlangıç noktası olarak 300 saniye (5 dakika) düşünün.
Büyük DNS bölgelerini parçala: Büyük bir DNS bölgeniz varsa, genel güvenilirliğinizi ve operasyonel verimliliğinizi artırmak için bölgenizi parçalama seçeneğini göz önünde bulundurun.
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, ana bilgisayar adlarını (etki alanı adları) IP adresleriyle eşleyen bir DNS kayıtları kümesini temsil eden bir bölgedir. Bölgenin çözümlediği ana bilgisayar adları genellikle internet üzerinden herkese açık olarak erişilemeyen yerel DNS adlarıdır.
Özel DNS bölgelerini tek başına kaynaklar olarak oluşturur ve sanal ağ bağlantıları oluşturarak bunları belirli sanal ağlara bağlarsınız. DNS istekleri bu sanal ağlardaki istemcilerden geldiğinde, özel DNS bölgeleri çözüm sürecine katılır. Bir DNS bölgesinde el ile girdi oluşturabilir veya sanal ağ bağlantılarındaki VM'lerin otomatik kaydını yapılandırabilirsiniz. Azure DNS özel bölgeler, sanal ağları açıkça eşlemeden bile Azure bölgelerdeki sanal ağlar arasında DNS çözümlemesini destekler. Ancak, tüm sanal ağlar özel DNS bölgesine bağlanmalıdır.
DNS ad çözümleme işlemi , yetkili DNS sunucularına ulaşmadan önce istekleri işleyen DNS çözümleyicileri ve ara katmanlar da dahil olmak üzere birden çok bileşeni içerir. Özel bölgeler, TTL değerleri ve önbelleğe alma mekanizmaları dahil olmak üzere ortak bölgelerle aynı DNS protokollerini ve davranışlarını kullanır.
Important
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 hizmettir. Microsoft 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 Border Gateway Protocol (BGP) gibi genel İnternet protokolleri, gelen DNS çözümleme isteklerini otomatik olarak en yakın iyi durumdaki Azure DNS altyapısına yönlendirir.
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 isteği yeniden denemelidir. Zaman aşımı değerlerini uygun şekilde yapılandırın. Bir DNS istemcisi için genellikle 2 ile 5 saniyelik bir zaman aşımı yeterlidir.
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, istemciler Azure DNS için daha fazla istekte bulunur ve bu da geçici hatalar için daha fazla fırsat oluşturur. 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 özel 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
Azure DNS özel bölgeler, bölge verileri genel olarak kullanılabilir olduğundan bölge kesintilerine karşı dayanıklıdır. Bir bölgede kesinti varsa sanal ağları ve VM'ler gibi kaynaklar kullanılamayabilir, ancak ad çözümlemesi çalışmaya devam eder.
Aşağıdaki örnekte, özel bölge verilerinin birden çok bölgede nasıl kullanılabilir kaldığı gösterilmektedir. Özel bölge azure.contoso.com üç bölgedeki sanal ağlara bağlanır: bölge A, bölge B ve bölge C. Otomatik kayıt, A ve B bölgelerinde etkinleştirilir. Diyagramda kesinti yaşayan A bölgesi gösterilmektedir:
A bölgesinde geçici bir kesinti olduğunu varsayalım. B ve C bölgelerindeki VM'ler, A bölgesinden otomatik olarak kaydedilen adlar da dahil olmak üzere özel bölgedeki DNS adlarını sorgulamaya devam edebilir. VM1 kullanılamasa bile A bölgesindeki VM1'in IP adresini çözümlemeye devam edebilir. A bölgesindeki hizmet kesintisi diğer bölgelerdeki ad çözümlemesini etkilemez.
Önceki örnek, çözümünüzün başka bir bölgedeki VM1’in yerine geçen bir sanal makineye yük devrettiği bir olağanüstü durum kurtarma senaryosunu göstermez. Ancak, özel bölgeler genel olduğundan, iş yükünü devralmak için vm1'i başka bir bölgenin sanal ağında yeniden oluşturabilirsiniz.
Birden çok bölgede sanal ağlar ve ağ kaynakları oluşturuyorsanız bölgeler arası yük devretme gerektiren uygulamalar için çok bölgeli stratejinizi planlamanız ve uygulamanız gerekir.
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.
Özel DNS bölgelerine özgü kapsamlı güvenlik yönergeleri için bkz. Özel 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ğ veya diğer altyapı sorunları Azure DNS hizmetine bağlantıyı kesintiye uğratabilir.
Hizmet kesintilerini izleme
Microsoft, bölge kapatıldığında sizi otomatik olarak bilgilendirmez. Bununla birlikte, tüm bölge hataları dahil olmak üzere hizmetin genel durumunu anlamak için Azure Hizmet Durumu'nı kullanabilir ve sorunları size bildirmek için Hizmet Durumu uyarıları ayarlayabilirsiniz.
Hizmet kesintilerini test edin
Azure Chaos Studio, DNS çözümlemesiyle ilgili sorunların benzetimini yapmak için bir hata kümesi sağlar. Örneğin, Chaos Studio aracısı DNS Hatası hata türünü ve Azure Kubernetes Service (AKS) Chaos Mesh de DNS Chaos özelliğini sağlar. Uygulamalarınızın ve altyapınızın DNS çözümleme istekleri başarısız olduğunda nasıl yanıt verdiğini test etmek için bu hata türlerini kullanabilirsiniz. Bu durum kısmi bir ağ hatası sırasında ortaya çıkabilir.
Portal ve yönetim aracı kesintilerine dayanıklılık
DNS bölgenizi Azure portalında yönetiyorsanız, özellikle de bir platform kesintisi sırasında DNS bölgenizi yeniden yapılandırmanız gerekiyorsa, buna erişememe senaryolarına hazırlanın.
Azure DNS özel bölgeleri dağıtmak ve yönetmek için çeşitli araçları kullanabilirsiniz. Özel bölgenizi yönetmek için Azure CLI veya Azure PowerShell kullanmayı öğrenin. Alternatif olarak, özel bölgenizi dağıtmak ve yapılandırmak için Bicep veya Terraform gibi altyapıyı kod olarak tanımlama (IaC) araçlarını 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. Özel DNS bölgeleri için yönetilen yedeklemeler veya belirli bir noktaya geri yükleme sağlamaz.
Tüm Azure kaynak yapılandırmasını korumak için, Bicep veya Terraform gibi IaC kullanarak özel 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.
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şıladığınızda geçerli DNS sorgusu 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 yeniden denemeyi içerir. Ayrıntılı koşullar için SLA belgesini gözden geçirin.