Server Load Balancer:CLB server groups

Sunucu grubu türleri

Ağırlık yapılandırması

Zamanlama algoritması, gelen isteklerin birden fazla arka uç sunucusu arasında nasıl dağıtılacağını belirler. Ağırlık, her sunucuya atanan trafik oranını kontrol etmek için ağırlıklı algoritmalar kullanılan bir parametredir.

• Kapsam: Yalnızca ağırlıklı bir zamanlama algoritması kullanıldığında geçerlidir. Round-robin algoritması ile etkisi yoktur.

• Aralık: 0–100, varsayılan değer 100'dür.

• Ağırlık 0 olduğunda davranış: Sunucu yeni istek trafiği almayı durdurur. Mevcut bağlantılar normal şekilde kapanana kadar devam eder ve sağlık kontrolleri çalışmaya devam eder. Bu durum genellikle sorunsuz kapatma işlemleri için kullanılır.

• Ağırlık değişikliklerinin etkisi: Ağırlık ayarlamaları yalnızca yeni bağlantıları etkiler ve mevcut bağlantıları etkilemez. Kalıcı bağlantı senaryolarında, ağırlık değişikliğinden sonra trafiğin yeniden dağıtılması yavaş gerçekleşir.

• Trafik dağıtım oranı: Ağırlıklı Round Robin (WRR) algoritması altında, her arka uç sunucusu ağırlığıyla orantılı olarak trafik alır. Örneğin, iki sunucunun ağırlıkları sırasıyla 100 ve 1 ise (toplam ağırlık: 101), ağırlığı 1 olan sunucu tüm isteklerin yaklaşık 1/101'ini (%1'den az) alır.

  Not

  Sunucu grubunda zaten yüksek ağırlığa sahip bir arka uç sunucusu (örneğin, ağırlık 100) varsa, düşük ağırlığa sahip (örneğin, ağırlık 1) yeni eklenen bir sunucu uzun bir süre boyunca görünür trafik alamayabilir. Bu beklenen WRR davranışıdır; düşük trafikli koşullarda, düşük ağırlıklı sunucuya ayrılan birkaç istek uzun süre gözlemlenmeyebilir.

• Öneri: Yeni bir arka uç sunucusu eklerken, başlangıç ağırlığını en az 10 olarak ayarlayın. Sunucunun normal şekilde trafik aldığını onayladıktan sonra, iş ihtiyaçlarınıza göre ağırlığı ayarlayın.

Hizmet yüksek kullanılabilirliği

Sunucu durumunu doğrulamak ve düzenli olarak istek göndermek için CLB sağlık kontrollerini etkinleştirin.

• Sağlık kontrolü başarılı: Sunucu sağlıklıdır ve CLB trafiği ona iletir.

• Sağlık kontrolü başarısız: Sunucu sağlıksızdır ve CLB, sunucu toparlanana kadar ona yeni istek trafiği göndermeyi durdurur.

CLB sağlık kontrolleri 100.64.0.0/10 CIDR bloğundan kaynaklanır. Arka uç sunucularınızın iptables veya diğer üçüncü taraf güvenlik yazılımlarının bu CIDR bloğunu engellemediğinden emin olun. Aksi takdirde, sağlık kontrolleri başarısız olur ve hizmet kesintisine neden olur.

Birincil/ikincil sunucu grupları, otomatik yük devretme için sağlık kontrollerine güvenir:

• Birincil sunucu sağlık kontrolünü geçemezse, trafik ikincil sunucuya geçer. Varsayılan olarak, ikincil sunucu sağlık kontrollerine tabi tutulmaz, bu nedenle kesintisiz yük devretmeyi sağlamak için kullanılabilirliğini manuel olarak sağlamalısınız.

• Yük devretme süresi, yapılandırılmış sağlık kontrolü yanıt zaman aşımı süresine bağlıdır. Birincil sunucu toparlandığında, trafik otomatik olarak tekrar ona geçer.

CLB örneği çalışırken ECS örneklerinin sayısını ayarlayabilir miyim?

• Varsayılan sunucu grubu ve vServer grubu: Arka uç ECS örneklerini istediğiniz zaman ekleyebilir veya kaldırabilir ve farklı ECS örnekleri arasında geçiş yapabilirsiniz. Hizmet kararlılığını sağlamak için, bu işlemleri gerçekleştirmeden önce sağlık kontrollerini etkinleştirin ve arka uçta en az bir sağlıklı ECS örneğinin bulunduğundan emin olun.

• Birincil/ikincil sunucu grubu: Desteklenmez.

Arka uç ECS örnekleri farklı işletim sistemleri kullanabilir mi?

Farklı olabilirler.

CLB, uygulama hizmetleri ve veriler tutarlı olduğu sürece arka uç ECS örneklerinin işletim sistemlerini kısıtlamaz. Daha kolay yönetim ve bakım için aynı işletim sisteminin kullanılmasını öneririz.

Farklı bölgelerdeki ECS örneklerini arka uç sunucusu olarak kullanabilir miyim?

CLB, çapraz bölge arka uç sunucularının doğrudan eklenmesini desteklemez. Çapraz bölge dağıtımı uygulamak için aşağıdaki çözümlerden birini kullanın:

• CLB'nin üzerine Global Traffic Manager dağıtın ve birden fazla CLB örneğini bölgeler arasında dağıtın. CLB örnekleri arasında geçiş yaparak çapraz bölge eklemeyi gerçekleştirin.

• Çapraz bölge arka uç eklemeyi destekleyen Application Load Balancer (ALB) veya Network Load Balancer (NLB) kullanın.

Neden ECS örneğime 100 ile başlayan IP'lerden sık sık istek geliyor?

Bu istekler, yük dengeleyicinin sağlık kontrolleri ve kullanılabilirlik izlemesinden kaynaklanır.

• Kaynak: Alibaba Cloud ayrılmış CIDR bloğu 100.64.0.0/10.

• Güvenlik: Bu CIDR bloğu Alibaba Cloud tarafından ayrılmıştır ve diğer kullanıcılara atanamaz, bu nedenle güvenlik riski oluşturmaz.

• Öneri: Hizmet kullanılabilirliğini korumak için arka uç sunucularınızın iptables veya diğer üçüncü taraf güvenlik yazılımlarının bu CIDR bloğunu engellemediğinden emin olun.

Sağlık kontrolleri başarısız olursa, bkz. Sağlık kontrolü hatalarını nasıl gideririm?

ECS örneğimde sıkıştırma etkin değil, ancak CLB'den gelen HTTP yanıtları sıkıştırılmış. Neden?

• Neden: CLB dinleyici yapılandırmasında Gzip sıkıştırma etkindir ve istemci tarayıcısı sıkıştırmayı destekler.

• Eylem: Devre dışı bırakmak için, CLB konsolu dinleyici ayarlarında Gzip sıkıştırmayı kapatın veya bir TCP dinleyicisine geçin.

HTTP/1.0 kullanan bir ECS örneği parçalı aktarım kodlamasını destekler mi?

Evet.

Neden CLB arka uç ECS örneğim sık sık User-Agent KeepAliveClient içeren istekler alıyor?

• Gözlem: Arka uç ECS, User-Agent değeri KeepAliveClient olan dahili IP adreslerinden çok sayıda GET isteği alır.

• Neden: Dinleyici protokolü TCP'dir, ancak sağlık kontrolü protokolü HTTP olarak ayarlanmıştır. Bir TCP dinleyicisi HTTP sağlık kontrollerini kullandığında, varsayılan olarak GET yöntemini kullanır.

• Çözüm: Dinleyici protokolü ile sağlık kontrolü protokolünü hizalayın (örneğin, her ikisini de TCP veya her ikisini de HTTP olarak kullanın).

Varsayılan sunucu grubundaki sunucu bağlantı noktasını değiştirebilir miyim?

Doğrudan değiştirme desteklenmez.

• Kısıtlama: Varsayılan sunucu grubu için bağlantı noktası yalnızca dinleyici oluşturulurken ayarlanabilir ve aynı dinleyici altındaki tüm arka uç sunucuları aynı bağlantı noktasını kullanmalıdır.

• Çözüm: Aynı dinleyici için farklı arka uç bağlantı noktaları yapılandırmak üzere bir vServer grubu kullanın.

CLB Katman 4 dinleyicisi, hem arka uç sunucusu hem de istemci olarak aynı ECS örneğinin kullanılmasını destekler mi?

Hayır. Bu yapılandırma bir döngüye neden olur.

Alternatifler:

• Bir CLB Katman 7 dinleyicisi (HTTP/HTTPS) kullanın.

• Bir NLB örneği kullanın ve sunucu grubu için istemci IP korumasını devre dışı bırakın. Bkz. NLB'de bir ECS örneği hem arka uç sunucusu hem de istemci olarak nasıl hizmet verebilir?

Neden CLB arka ucumda çok sayıda TIME-WAIT bağlantısı varken ALB'de çok az var?

Classic Load Balancer (CLB) ve Application Load Balancer (ALB), arka uç sunucularıyla etkileşimde farklı bağlantı mekanizmaları kullanır.

• Classic Load Balancer (CLB): Varsayılan olarak HTTP kısa ömürlü bağlantıları kullanır. CLB, HTTP isteklerine Connection: close üst bilgisini ekler. İstek işlendikten sonra, arka uç sunucusu bu üst bilgiye dayanarak bağlantıyı kapatmak için bir FIN paketi gönderir. Her kapatma işlemi TIME-WAIT durumuna girer (varsayılan 60 saniye), bu da yüksek eşzamanlılık altında hızlı birikime yol açar.

• Application Load Balancer (ALB): Varsayılan olarak HTTP kalıcı bağlantılarını (keep-alive) destekler. Tek bir TCP bağlantısı birden fazla isteği işler, bu da bağlantı kapatmalarını ve dolayısıyla TIME-WAIT bağlantılarını azaltır.

TIME-WAIT birikimini azaltmak için şu seçenekleri göz önünde bulundurun:

• Bir CLB Katman 4 (TCP) dinleyicisine geçin. Katman 4 sağlık kontrolleri, başarılı el sıkışmadan sonra TIME-WAIT'e girmeden bağlantıyı kapatmak için bir RST paketi gönderir.

• Varsayılan HTTP kalıcı bağlantı yeniden kullanım mekanizmasından yararlanmak için ALB'ye geçiş yapın.

Neden trafik arka uç sunucuları arasında eşit olmayan şekilde dağıtılıyor?

Bir arka uç ECS örneğini CLB'den güvenli bir şekilde nasıl kaldırırım?

Bir ECS örneğini doğrudan kaldırmak geçici bağlantı kesintilerine neden olabilir. İlk olarak, ECS örneğinin ağırlığını 0 olarak ayarlayın. Örneği kaldırmadan önce mevcut bağlantıların tamamlanmasını bekleyin. Ağırlığın 0 olarak ayarlandığında davranışı hakkında ayrıntılar için yukarıdaki Ağırlık yapılandırması bölümüne bakın.

ECS örneğini kaldırdıktan sonra iş istekleri devam ediyorsa, şunları kontrol edin:

• ECS örneğinin başka CLB örneklerine de ekli olup olmadığı.

• ECS örneğinin doğrudan başka hizmetler sağlayıp sağlamadığı. Bağlantı noktası dinleme durumunu kontrol etmek için netstat komutunu kullanın.

Neden yeni eklenen bir arka uç sunucusuna trafik iletilmiyor?

CLB trafiği yeni eklenen bir arka uç sunucusuna iletmiyorsa, şunları kontrol edin:

• Sağlık kontrolü başarısız: Arka uç sunucu bağlantı noktasına ulaşılamıyor veya uygulama beklenen bağlantı noktasında dinleme yapmıyor, bu da sağlık kontrolü hatasına neden oluyor. CLB konsolunda sunucunun sağlık kontrolü durumunu onaylayın ve arka uç sunucuda bağlantı noktası dinleme ve uygulama durumunu doğrulayın. Sağlık kontrolleri başarısız olursa, bkz. Sağlık kontrolü hatalarını nasıl gideririm?

• Ağırlık 0 olarak ayarlandı: Ağırlığı 0 olan sunucular yeni istek trafiği almaz. Sunucu grubundaki sunucunun ağırlığını kontrol edin ve 0'dan büyük olduğundan emin olun. Ayrıntılar için yukarıdaki Ağırlık yapılandırması bölümüne bakın.

• Yanlış sunucu grubuna eklendi: Her CLB dinleyicisi belirli bir sunucu grubuna (varsayılan veya vServer grubu) bağlanır. Yeni sunucu, hedef dinleyiciye bağlı olmayan bir gruba eklenirse, o dinleyici için trafik almaz. Dinleyiciye gerçekten bağlı olan sunucu grubunu onaylayın ve sunucuyu doğru gruba ekleyin.

• iptables veya üçüncü taraf güvenlik yazılımı sağlık kontrolü CIDR bloğunu engelliyor: CLB sağlık kontrolleri 100.64.0.0/10 CIDR bloğunu kullanır. Arka uç sunucudaki iptables veya diğer üçüncü taraf güvenlik yazılımları bu CIDR bloğunu engellerse, sağlık kontrolleri başarısız olur ve CLB sunucuyu sağlıksız olarak değerlendirir. İlgili kuralların bu CIDR bloğunu engellemediğinden emin olun.

• Sağlık kontrolü penceresine ulaşılmadı: Bir arka uç sunucusu eklendikten sonra, CLB trafik iletmeden önce başarılı bir sağlık kontrolü bekler. Kısa bir süre bekleyin ve ardından trafiğin normal akıp akmadığını doğrulayın.

• Tutarlı hashing (CH) zamanlama algoritması trafik tahsisini engelliyor: Bir dinleyici, kaynak IP tabanlı tutarlı hashing (CH) zamanlama algoritmasını kullandığında, istekler kaynak IP hash sonucuna göre belirli sunuculara atanır. Yeni bir sunucu eklendikten sonra, yalnızca kaynak IP hash'i yeni sunucuya eşlenen istekler ona iletilir. İstemci sayısı azsa veya kaynak IP'ler yoğunlaştıysa, yeni sunucu uzun bir süre boyunca trafik almayabilir. CLB konsolunda, örnek ayrıntıları sayfasına gidin, Listener sekmesine tıklayın ve ilgili dinleyici için zamanlama algoritmasını kontrol edin. Consistent Hashing (CH) olarak ayarlanmışsa, Weighted Round Robin (WRR) veya Round Robin (RR) seçeneğine geçmeyi düşünün.

CLB, Katman 7 dinleyicileri için istekleri arka uç sunucularına hangi protokolle iletir?

Katman 7 dinleyicisinin HTTP mi yoksa HTTPS mi kullandığına bakılmaksızın, CLB istekleri arka uç sunucularına her zaman HTTP protokolünü kullanarak iletir. HTTP sürüm eşlemesi aşağıdaki gibidir:

• İstemci isteği HTTP/1.1 veya HTTP/2.0 kullanıyorsa, Katman 7 dinleyicisi arka uç sunucularına HTTP/1.1 kullanarak erişir.

• İstemci isteği HTTP/1.1 veya HTTP/2.0 dışındaki bir sürüm kullanıyorsa, Katman 7 dinleyicisi arka uç sunucularına HTTP/1.0 kullanarak erişir.