Load Balancer durum araştırmaları

Azure Load Balancer ile yük dengeleme kuralları kullanırken, arka uç uç noktası durumunu algılamaya Load Balancer izin vermek için sistem durumu araştırmalarını belirtmeniz gerekir. Durum araştırması ve araştırma yanıtlarının yapılandırması, hangi arka uç havuzu örneklerinin yeni akışlar alacağını tespit eder. Bir arka uç uç noktasındaki uygulamanın başarısızlığını algılamak için sistem durumu araştırmalarını kullanabilirsiniz. Ayrıca, bir sistem durumu araştırmasına özel bir yanıt oluşturabilir ve yük veya planlanan kapalı kalma süresini yönetmek için akış denetimi için sistem durumu araştırması ' ni kullanabilirsiniz. Bir sistem durumu araştırması başarısız olduğunda, Load Balancer ilgili sağlıksız örneğe yeni akış göndermeyi durdurur. Giden bağlantı etkilenmez, yalnızca gelen bağlantı etkilendi.

Durum araştırmaları birden çok protokolü destekler. Belirli bir sistem durumu araştırma protokolünün kullanılabilirliği Load Balancer SKU 'ya göre değişir. Ayrıca, hizmetin davranışı, bu tabloda gösterildiği gibi Load Balancer SKU 'ya göre farklılık gösterir:

Araştırma yapılandırması

Durum araştırma yapılandırması aşağıdaki öğelerden oluşur:

• Tek yoklamalar arasındaki Aralık süresi
• Araştırmanın Protokolü
• Araştırmanın bağlantı noktası
• Http (S) yoklamaları kullanılırken HTTP GET için kullanılacak HTTP yolu

Uygulama sinyalini anlama, sinyalin algılanması ve platformun yeniden eylemi

Aralık değeri, arka uç havuzu örneklerinizin bir yanıtı için sistem durumu araştırmasının ne sıklıkta araştıracağını belirler. Sistem durumu araştırması başarısız olursa, arka uç havuzu örneklerinizi hemen uygun değil olarak işaretler. Benzer şekilde, sonraki sağlıklı sonda, sistem durumu araştırması arka uç havuz örneklerinizi hemen sağlıklı olarak işaretler.

Durum araştırma aralığın 5 saniyeye ayarlandığı bir örnekle daha fazla davranış gösteririz. Bir araştırmanın gönderildiği zaman uygulamanızın durumu değiştirebileceğinden, sistem durumu araştırmanız için gereken toplam süre, aşağıdaki iki senaryodan birine ayrılabilir:

1. Uygulamanız bir sonraki araştırma ulaşmadan önce bir zaman aşımı araştırma yanıtı oluşturmaya başlarsa, bu olayların algılanması 5 saniye ve uygulamanın, araştırmanın ulaştığı zaman bir zaman aşımını sinyalden başlayan süresi kadar sürer. Bu algılamanın 5 saniyeden biraz uzun sürdüğünü varsayabilirsiniz.
2. Uygulamanız bir sonraki araştırma alındıktan sonra bir zaman aşımı araştırma yanıtı oluşturmaya başlarsa, bu olayların algılanması, araştırma (ve zaman aşımına uğrayana kadar) ve başka bir 5 saniyeye kadar başlamacaktır. Bu algılamanın yalnızca 10 saniye içinde geçmesi gerektiğini varsayabilirsiniz.

Bu örnekte, algılama gerçekleştiyse, platform bu değişikliğe tepki vermek için kısa bir süre sürer. Bu, buna bağlı olarak

1. uygulama durumu değiştirme başladığında ve
2. Bu değişiklik algılandığında (bir sonraki sistem durumu araştırması gönderildiğinde) ve
3. algılama, platform genelinde iletildiğinde

bir zaman aşımı araştırma yanıtı için yeniden eylemin, uygulamadan gelen bir değişikliğe yanıt vermek için en az 5 saniyelik ve en fazla 10 saniyelik bir süre arasında geçmesi gerektiğini varsayabilirsiniz. Bu örnek, ne olduğunu göstermek için verilmiştir, ancak bu örnekte gösterilen yukarıdaki kaba kılavuzun ötesinde tam bir süre tahmin etmek mümkün değildir.

Araştırma türleri

Sistem durumu araştırması tarafından kullanılan protokol aşağıdakilerden birine yapılandırılabilir:

• TCP dinleyicileri
• HTTP uç noktaları
• HTTPS uç noktaları

Kullanılabilir protokoller, kullanılan Load Balancer SKU 'suna bağımlıdır:

TCP araştırması

TCP araştırmaları, tanımlı bağlantı noktasıyla üç yönlü bir açık TCP el sıkışması gerçekleştirerek bir bağlantı başlatır. TCP araştırmaları bir bağlantıyı dört yönlü bir kapalı TCP el sıkışması ile sonlandırır.

En düşük araştırma aralığı 5 saniyedir ve en az sağlıksız yanıt sayısı 2 ' dir. Tüm aralıkların toplam süresi 120 saniyeyi aşamaz.

Şu durumlarda bir TCP araştırması başarısız olur:

• Örnekteki TCP dinleyicisi, zaman aşımı süresi boyunca hiç yanıt vermez. Araştırma, araştırmadan önce yanıtlanmak üzere yapılandırılan zaman aşımına uğramış araştırma istekleri sayısına göre aşağı işaretlenir.
• Araştırma, örnekten bir TCP sıfırlaması alır.

Aşağıda, Kaynak Yöneticisi şablonunda bu tür bir araştırma yapılandırmasını nasıl ifade ettiğiniz gösterilmektedir:

    {
      "name": "tcp",
      "properties": {
        "protocol": "Tcp",
        "port": 1234,
        "intervalInSeconds": 5,
        "numberOfProbes": 1
      },

Http/https araştırması

HTTP ve HTTPS araştırmaları TCP araştırmasına dayanır ve belirtilen yola sahip bir HTTP GET oluşturur. Bu yoklamaların her ikisi de HTTP GET için göreli yolları destekler. HTTPS araştırmaları, bir Aktarım Katmanı Güvenliği (TLS, eskiden SSL olarak bilinen) sarmalayıcı ekleme ile HTTP araştırmaları ile aynıdır. Durum araştırması, örnek zaman aşımı süresi içinde bir HTTP durumu 200 ile yanıt verdiğinde yapılır. Sistem durumu araştırması, varsayılan olarak her 15 saniyede bir yapılandırılan durum araştırma bağlantı noktasını denetlemeye çalışır. En düşük araştırma aralığı 5 saniyedir. Tüm aralıkların toplam süresi 120 saniyeyi aşamaz.

Araştırma bağlantı noktası Ayrıca hizmetin kendisi için de dinleyici olan yük dengeleyici rotasyondan örnekleri kaldırmak için kendi mantığınızı uygulamak üzere, HTTP/HTTPS araştırmaları da yararlı olabilir. Örneğin, %90 CPU üzerinde bir örneği kaldırmaya karar verebilir ve 200 olmayan bir HTTP durumu döndürebilir.

Cloud Services kullanırsanız ve w3wp.exe kullanan Web rollerine sahipseniz, Web sitenizin otomatik olarak izlenmesini de elde edersiniz. Web sitesi kodunuzda oluşan hatalarda yük dengeleyici araştırmasına 200 olmayan bir durum döndürülür.

Şu durumlarda bir HTTP/HTTPS araştırması başarısız olur:

• Araştırma uç noktası 200 dışında bir HTTP yanıt kodu döndürür (örneğin, 403, 404 veya 500). Bu, sistem durumu araştırmasını hemen işaretleyecek.
• Araştırma bitiş noktası, en az yoklama aralığı ve 30 saniyelik zaman aşımı süresi boyunca yanıt vermez. Araştırma çalışmıyor olarak işaretlenmeden ve tüm zaman aşımı aralıklarının toplamına ulaşılıncaya kadar birden çok araştırma isteği yanıtlanmayabilir.
• Araştırma uç noktası, TCP sıfırlaması ile bağlantıyı kapatır.

Aşağıda, Kaynak Yöneticisi şablonunda bu tür bir araştırma yapılandırmasını nasıl ifade ettiğiniz gösterilmektedir:

    {
      "name": "http",
      "properties": {
        "protocol": "Http",
        "port": 80,
        "requestPath": "/",
        "intervalInSeconds": 5,
        "numberOfProbes": 1
      },

    {
      "name": "https",
      "properties": {
        "protocol": "Https",
        "port": 443,
        "requestPath": "/",
        "intervalInSeconds": 5,
        "numberOfProbes": 1
      },

Araştırma davranışı

TCP, HTTP ve HTTPS durum yoklamaları iyi olarak kabul edilir ve aşağıdakiler olduğunda arka uç uç noktasını iyi olarak işaretlemektedir:

• VM'nin başlatması sonrasında sistem durumu yoklama başarılı olur.

Sağlıklı bir durum elde edilen tüm arka uç uç noktaları yeni akışlar almaya uygundur.

Yoklama aşağı davranışı

TCP bağlantıları

Yeni TCP bağlantıları sağlıklı arka uç uç noktasının kalana kadar başarılı olur.

Arka uç uç noktasının durum yoklama işlemi başarısız olursa, bu arka uç uç noktasına kurulan TCP bağlantıları devam eder.

Arka uç havuzunda bulunan tüm örnekler için yapılan tüm araştırmalar başarısız olursa arka uç havuzuna yeni akış gönderilmez. Standart Load Balancer TCP akışlarının devam edt edr. Temel Load Balancer, arka uç havuzuna var olan tüm TCP akışlarını sonlandıracak.

Load Balancer bir geçiş hizmetidir (TCP bağlantılarını sonlandırmaz) ve akış her zaman istemci ile VM'nin konuk işletim sistemi ve uygulaması arasında olur. Tüm yoklamaların kapalı olduğu bir havuz, akışı almak ve SYN-ACK ile yanıt vermek için iyi bir arka uç uç noktası yoktur ve ön ucun TCP bağlantısı açma girişimlerine (SYN) yanıt vermesine neden olur.

UDP veri birimleri

UDP veri birimleri sağlıklı arka uç uç noktalarına teslim edilir.

UDP bağlantısızdır ve UDP için izli akış durumu yoktur. Herhangi bir arka uç uç noktasının durum yoklama işlemi başarısız olursa, mevcut UDP akışları arka uç havuzunda başka bir iyi durumdaki örneğine taşınacak.

Arka uç havuzu üzerindeki tüm örnekler için yapılan tüm araştırmalar başarısız olursa, mevcut UDP akışları Temel ve Standart Load Balancer'lar için sonlandırılır.

Araştırma kaynağı IP adresi

Load Balancer iç durum modeli için dağıtılmış bir yoklama hizmeti kullanır. Yoklama hizmeti VM'lerinin bulunduğu her konakta yer almaktadır ve müşterinin yapılandırmasına göre sistem durumu araştırmaları oluşturmak üzere isteğe bağlı olarak programlanabilir. Durum yoklama trafiği, durum yoklamasını oluşturan yoklama hizmeti ile müşteri sanal makinesi arasında doğrudan olur. Tüm Load Balancer yoklamalarının kaynağı 168.63.129.16 IP adresidir. RFC1918 alanı olan bir sanal ağ içinde IP adresi alanı kullanabilirsiniz. Genel olarak ayrılmış bir Microsoft IP adresi kullanmak, IP adresinin sanal ağ içinde kullanmakta olduğu IP adresi alanıyla çakışma ihtimalini azaltır. Bu IP adresi tüm bölgelerde aynıdır ve değişmez ve yalnızca iç Azure platformu bileşeni bu IP adresinden bir paket kaynağına sahip olduğundan güvenlik riski oluşturmaz.

AzureLoadBalancer hizmet etiketi, bu kaynak IP adresini ağ güvenlik gruplarınıza tanımlar ve sistem durumu yoklama trafiğine varsayılan olarak izin verir.

Aşağıdaki işlemler, Load Balancer yoklamalarına ek olarak bu IP adresini kullanır:

• VM Aracısı'nın platformla iletişim kurarak "Hazır" durumda olduğunu haber verir
• Özel DNS sunucuları tanımlamamış müşterilere filtrelenmiş ad çözümlemesi sağlamak için DNS sanal sunucusuyla iletişimi sağlar. Bu filtreleme, müşterilerin yalnızca dağıtımlarının ana bilgisayar adlarını çözümleyene kadar devam eder.
• VM'nin Azure'daki DHCP hizmetlerinden dinamik BIR IP adresi elde yapılandırmasını sağlar.

Tasarım kılavuzu

Durum yoklamaları, hizmetinizi daha iyi bir şekilde ve ölçeklendirilen bir şekilde ölçeklendirmek için kullanılır. Yanlış yapılandırma veya hatalı tasarım deseni, hizmetinizin kullanılabilirliğini ve ölçeklenebilirliğini etkiler. Bu belgenin tamamını gözden geçirin ve bu yoklama yanıtı işaretlenirken veya işaretlenirken senaryonun etkisini ve uygulama senaryonun kullanılabilirliğini nasıl etkile olduğunu düşünün.

Uygulamanıza göre durum modelini tasarlarken, arka uç noktası üzerinde ilgili örneğin ve sağlanıyor olan uygulama hizmetinin durumunu yansıtan bir bağlantı noktasını yoklamanız gerekir. Uygulama bağlantı noktasının ve araştırma bağlantı noktasının aynı olması gerekmez. Bazı senaryolarda, yoklama bağlantı noktasının, uygulamanın hizmet sağladığı bağlantı noktasından farklı olması tercih edilebilir.

Bazen, yalnızca uygulama durumunu algılamak için bir durum yoklama yanıtı oluşturmanın yanı sıra örneğinizin yeni akışlar ala mı yoksa alma mı Load Balancer doğrudan da sinyal oluşturması yararlı olabilir. Durum yoklamasını başarısız karak veya uygulama bakımına hazırlanarak ve senaryoyu boşaltmayı başlatarak, uygulamanın bir örnek için baskı oluşturmasına ve yeni akışların teslimini kısıtlamasına olanak vermek için yoklama yanıtını işebilirsiniz. Bir Standart Load Balancer yoklama sinyali her zaman tcp akışlarının boşta kalma zaman aşımına veya bağlantı kapatılana kadar devamsına izin verir.

UDP yük dengelemesi için, arka uç noktalarından özel bir durum yoklama sinyali oluşturmalı ve UDP uygulamanın durumunu yansıtmak için ilgili dinleyiciyi hedef alan bir TCP, HTTP veya HTTPS durum araştırması kullanabilirsiniz.

HA Bağlantı Noktaları yük dengeleme kurallarını Standart Load Balancer, tüm bağlantı noktaları yük dengelidir ve tek bir durum yoklama yanıtı örneğin tamamının durumunu yansıtıyor olması gerekir.

Durum yoklamasını alan örnek aracılığıyla bir durum yoklamasını sanal ağınız içinde başka bir örneğine çevirmeyin veya ara sunucuya atamaz, çünkü bu yapılandırma senaryonda basamaklı hatalara yol açabilir. Aşağıdaki senaryoyu göz önünde bulundurabilirsiniz: Gereçler için ölçek ve yedeklilik sağlamak üzere bir Load Balancer kaynağının arka uç havuzuna üçüncü taraf gereç kümesi dağıtılır ve durum yoklama, üçüncü taraf gereçlerin alete ekli olduğu veya aletin arkasındaki diğer sanal makinelere çeviren bir bağlantı noktasını yoklamak üzere yapılandırılır. Ya da istekleri aletin arkasındaki diğer sanal makinelere çevirmek için kullanmakta olduğu bağlantı noktasını yoklarsanız, aletin arkasındaki tek bir sanal makineden gelen yoklama yanıtları aletin kendisini kullanım dışı olarak işaret eder. Bu yapılandırma, aletin arkasında tek bir arka uç uç noktasının sonucu olarak uygulama senaryosunun tamamına basamaklı bir hataya yol açabilir. Tetikleyici aralıklı bir yoklama hatası olabilir ve Load Balancer hedef (alet örneği) işaretlendiğinden ve bu durumda uygulama senaryonun tamamını devre dışı bırakabilirsiniz. Bunun yerine aletin durumunu yoklar. Durum sinyalini belirlemek için yoklama seçimi, ağ sanal gereçleri (NVA) senaryolarında önemli bir konudur ve bu tür senaryolar için uygun durum sinyalinin ne olduğunu uygulama satıcınıza danışmanız gerekir.

Güvenlik duvarı ilkeleriniz içinde yoklamanın kaynak IP'sine izin vermezse, örneğinize ulaşamadığından durum yoklama başarısız olur. Buna karşılık Load Balancer yoklama hatası nedeniyle örneğinizi işaretlemektedir. Bu yanlış yapılandırma, yük dengeli uygulama senaryonun başarısız olmasına neden olabilir.

Örneğinizin Load Balancer için durum yoklamasını kullanmak için bu IP adresine tüm Azure ağ güvenlik gruplarında ve yerel güvenlik duvarı ilkelerinde izin vermelisiniz. Varsayılan olarak, her ağ güvenlik grubu, durum yoklama trafiğine izin vermeleri için AzureLoadBalancer hizmet etiketini içerir.

Bir durum yoklama hatasını test etmek veya tek bir örneği işaretlemek isterseniz, durum yoklamasını (hedef bağlantı noktası veya kaynak IP)açıkça engellemek ve yoklama hatasının benzetimini yapmak için ağ güvenlik gruplarını kullanabilirsiniz.

VNet'inizi 168.63.129.16 içeren Microsoft'a ait IP adresi aralığıyla yapılandırmazsanız. Bu tür yapılandırmalar durum yoklamanın IP adresiyle birlikte çalışır ve senaryonun başarısız olmasına neden olabilir.

VM'niz birden çok arabirime sahipse, vm'yi aldığı arabirimde yoklama yanıtını vermenizi sağlar. Kaynak ağ adresinin vm'de bu adresi arabirime göre çevirmesi gerekebilir.

TCP zaman damgasını etkinleştirme. TCP zaman damgasının etkinleştirilmesi, VM'nin konuk işletim sistemi TCP yığını tarafından bırakılan TCP paketleri nedeniyle durum yoklamalarının başarısız Load Balancer neden olabilir. TCP zaman damgası, güvenliği sağlamlaştırılmış VM görüntülerindeki varsayılan olarak düzenli olarak etkinleştirilir ve devre dışı bırakılmıştır.

İzleme

Hem genel hem de Standart Load Balancer uç nokta başına ve arka uç durumu yoklama durumu, Azure İzleyici. Bu ölçümler diğer Azure hizmetleri veya iş ortağı uygulamaları tarafından kullanılabilir.

Azure İzleyici günlükler hem genel hem de iç Temel Yük Dengeciler için kullanılamaz.

Sınırlamalar

• HTTPS araştırmaları, istemci sertifikasıyla karşılıklı kimlik doğrulamasını desteklemez.
• TCP zaman damgası etkinleştirildiğinde Durum yoklamalarının başarısız olduğunu varsaymalısınız.
• Temel bir SKU yük dengeleyici durum araştırması, sanal makine ölçek kümesiyle birlikte desteklenmemektedir.

Sonraki adımlar

• Daha fazla bilgi Standart Load Balancer
• Kullanmaya başlayın PowerShell kullanarak Resource Manager yük dengeleyici oluşturma
• REST API yoklamaları için REST API
• Load Balancer Uservoice ile yeni durum yoklama özellikleri isteği