HA Proxy'i yapılandırırken, zaman aşımlarına hangi değerleri atayacağınıza nasıl karar verirsiniz? Çeşitli bloglarda yarım düzine örnek okudum ve herkes farklı zaman aşımları kullanıyor ve kimse nedenini tartışmıyor.

HAProxy, HAPRoxy'nin tamamen kararsız kalmanız durumunda bir uyarı verdiği istemci, bağlantı ve sunucu hakkında özellikle endişeli görünüyor:

While not properly invalid, you will certainly encounter various problems
with such a configuration. To fix this, please ensure that all following
timeouts are set to a non-zero value: 'client', 'connect', 'server'.

Dokümantasyon bu konuda yardımcı şudur: "3 saniye hafifçe yukarıda katları" önerir ama neden 100 veya 42 vs 1 katlarını seçerdim değil.

Kullandığım RPM (Amazon Linux deposu) şu varsayılanları ayarlar:

timeout connect         10s
timeout client          1m
timeout server          1m

İkisi 3 saniyenin tam katları, gördüğüm tek resmi tavsiyeyi ihlal ediyorlar.

Özel ayar öneriniz yoksa, belki daha kolay bir soru şudur: gerçekten kısa veya çok uzun zaman aşımlarında neyin yanlış gitmesini beklemeliyim?

TCP RTO (alma zaman aşımı) üç saniyede başlar. ( RFC 1122 ) Gönderilen bir paket o zamana geri döndü. Onayının alınmaması durumunda, o zaman kaybolduğu ve yeniden iletildiği kabul edilir. Bu neredeyse kesinlikle yazara atıfta bulunan şeydir. (RTO'nun , bu sorunun kapsamı dışında, çeşitli algoritmalar tarafından dinamik olarak yukarı veya aşağı ayarlandığını unutmayın .)

Bunun gerçekten yalnızca ön uç sunucunuz ve istemciler arasındaki bağlantılar (örneğin web kullanıcıları) için geçerli olduğunu unutmayın. Normal senaryolarda, HAProxy ile arka uç sunucularınız arasındaki bağlantılar bir LAN üzerinde olmalıdır ve daha kısa zaman aşımları kullanmanız gerekir, böylece hatalı çalışan arka uçlar daha erken hizmet dışı kalır.

Web kullanıcılarınıza gelince, bazıları uydu gibi çok yüksek gecikmeli bağlantılarda olabilir ve bu nedenle normal yeniden iletimlerden daha yüksek olabilir. Uydunun kullanıldığı bir bağlantıdaki RTT, her şey yolunda olsa bile 2000 ms'yi aşabilir.

Tüm bunları akılda tutarak, genellikle için çok kısa zaman aşımları timeout connectve çok uzun olanlar için isteyeceksiniz timeout client.

Çünkü timeout serverbu, web uygulamanıza bağlıdır. Zaman aşımını ayarlarken, sunulan web uygulamasının karmaşıklığını ve karmaşık bir isteğin işlenmesi en kötü durumda ne kadar sürebileceğini göz önünde bulundurun. Şüpheniz varsa, değeri yükseltin.

Önsöz

Bir süredir HAProxy'yi ayarlıyorum ve üzerinde çok fazla performans testi yaptım. 100 HTTP isteğinden / s den 50 000 HTTP isteğine / den

İlk tavsiye, HAProxy'deki istatistik sayfasını etkinleştirmektir . İzlemeye ihtiyacınız var, istisna yok. 10.000 istek / s'yi geçmeyi düşünüyorsanız, ince ayar yapmanız gerekecektir.

Zaman aşımları kafa karıştırıcı bir yaratıktır, çünkü çoğu gözlemlenebilir fark bulunmayan çok çeşitli olası değerlere sahiptir. % 5 daha düşük veya% 5 daha yüksek bir rakam nedeniyle bir şeylerin başarısız olduğunu henüz görmedim. 10000 vs 11000 milisaniye, kimin umrunda? Muhtemelen senin sistemin değil.

Yapılandırma

Vicdanımda “herkes için en iyi zaman aşımı” olarak birkaç rakam veremem.

Bunun yerine söyleyebileceğim, HTTP (S) yük dengelemesi için her zaman kabul edilebilir olan MOST agresif zaman aşımları. Bunlardan daha az karşılaşırsanız, yük dengeleyicinizi yeniden yapılandırma zamanı gelmiştir.

timeout connect 5000
timeout check 5000
timeout client 30000
timeout server 30000

zaman aşımı istemcisi:

Hareketsizlik zaman aşımı, müşteriden veri onaylaması veya göndermesi beklendiğinde uygulanır. HTTP modunda, bu zaman aşımı, ilk aşamada, müşteri isteği gönderdiğinde ve sunucu tarafından gönderilen verileri okurken yanıt sırasında göz önünde bulundurmak için özellikle önemlidir.

Oku : Bu, istemciden HTTP istek başlıklarını almak için maksimum süredir .

3G / 4G / 56k / uydu zaman zaman yavaş olabilir. Yine de, HTTP başlıklarını birkaç saniye içinde gönderebilmeleri gerekir, 30 NOT.

Birisinin bir sayfayı istemek için 30 saniyeden daha fazla zaman gerektirecek kadar kötü bir bağlantısı varsa (o zaman 10 gömülü görüntü / CSS / JS istemek için 10 * 30'dan daha fazla), onu reddetmenin kabul edilebilir olduğuna inanıyorum.

zaman aşımı sunucusu:

Etkin olmama zaman aşımı, sunucunun veri onaylaması veya göndermesi beklendiğinde uygulanır. HTTP modunda, bu zaman aşımı, sunucunun yanıtının ilk aşamasında, başlığın gönderilmesi gerektiğinde, sunucunun istek için doğrudan işlem süresini temsil ettiği için dikkate alınması önemlidir. Oraya hangi değeri koyacağınızı bulmak için, kabul edilemez yanıt süreleri olarak kabul edilebilecek şeylerle başlamak genellikle iyidir, ardından yanıt süresi dağılımını gözlemlemek için günlükleri kontrol edin ve değeri buna göre ayarlayın.

Okuma : Bu, sunucudan HTTP yanıt başlıklarını almak için maksimum süredir (tam müşteri isteğini aldıktan sonra). Temel olarak, yanıt göndermeye başlamadan önce sunucularınızdaki işlem süresidir.

Sunucunuz o kadar yavaşsa, cevap vermeye başlamak için 30 saniyeden fazla bir süre gerekir, o zaman ölmüş sayılmasının kabul edilebilir olduğuna inanıyorum.

Özel Durum : Çok ağır işlem yapan bazı RARE servisleri cevap vermek için tam bir dakika veya daha uzun sürebilir. Bu zaman aşımının, bu belirli kullanım için çok arttırılması gerekebilir. (Not: Bu kötü bir tasarım durumu olabilir, bir async tarzı iletişim kullanın veya hiç HTTP kullanmayın.)

zaman aşımı bağlantısı:

Bir sunucunun başarılı olması için bir bağlantı girişimi için beklenecek maksimum süreyi ayarlayın.

Oku : Bir sunucunun bir TCP bağlantısını kabul etmesi gereken maksimum süre.

Sunucular HAProxy ile aynı LAN’dalar, bu yüzden hızlı olmalılar. En az 5 saniye verin, çünkü beklenmedik bir şey olduğunda ne kadar zaman alabiliyorsa (iletimi kaybedilen bir TCP paketi, yeni istekleri almak için yeni bir işlem öngören bir sunucu, trafikte artış).

Özel Durum : Sunucular farklı bir LAN’da veya güvenilmez bir bağlantı üzerindeyken. Bu zaman aşımının çok arttırılması gerekebilir. (Not: Bu kötü bir mimari durum olabilir.)

zaman aşımı kontrolü:

Ek kontrol zaman aşımını ayarlayın, ancak yalnızca bir bağlantı kurulduktan sonra.

Ek kontrol zaman aşımını ayarlama, ancak yalnızca bir bağlantı yapıldıktan sonra ayarlanmışsa, haproxy, kontrol için bağlantı zaman aşımı olarak min ("zaman aşımı bağlantısı", "ara") ve ek okuma zaman aşımı olarak "zaman aşımı kontrolü" olarak kullanır. "Min", çok uzun "timeeout connect" ile çalışan insanların (örn. Kuyruk veya tarpit nedeniyle buna ihtiyaç duyanlar) çeklerini yavaşlatmamaları için kullanılır. (Ayrıca, bu kadar uzun bağlantı zaman aşımına uğramak için geçerli bir neden olmadığını da unutmayın, çünkü "zaman aşımı sırası" ve "zaman aşımı tarpit" i önlemek için her zaman kullanılabilir.)

Oku : Bir sağlık kontrolü gerçekleştirirken, sunucunun yanıtı vermek için timeout connectbağlantıyı sonra kabul etmesi gerekir timeout check.

Tüm sunucular yapılandırılmış bir HTTP (S) sağlık kontrolüne sahip olmalıdır. Yük dengeleyicinin bir sunucunun kullanılabilir olup olmadığını bilmesinin tek yolu budur. Sağlık kontrolü /isaliveher zaman yanıtlayan basit bir sayfadır OK.

Bu zaman aşımına en az 5 saniye süre verin, çünkü beklenmedik bir şey olduğunda ne kadar zaman alabiliyorsa (yeniden iletmek için kaybolan bir TCP paketi, yeni istekleri almak için yeni bir işlem çağıran bir sunucu, trafikte artış).

Savaş Hikayesi : Pek çok kişi yanlış bir şekilde sunucunun bu basit sayfayı 3 msn'de her zaman cevaplayabileceğine inanıyor. Agresif yük devretme ile agresif bir zaman aşımı (<2000ms) ayarladılar (2 başarısız kontrol = sunucu ölü). Bu yüzden tüm web sitelerinin kapandığını gördüm. Genellikle trafikte hafif bir artış olur, arka uç sunucuları yavaşlar, sağlık kontrolleri ertelenir ... aniden hepsi birlikte zaman aşımına uğrayana kadar, HAProxy TÜM sunucuların bir kerede öldüğünü ve tüm sitenin kapandığını düşünüyor.