Soru F5 Büyük IP Cihazlarının Kümelenmesi; Mümkün mü?


Bir web uygulaması geliştirdim. Beş IIS sunucusundan oluşan bir çiftlikte çalışacak. Gruptaki bir sunucuyla bir oturum kurulduğunda, oturumun geri kalanı için söz konusu oturumdaki diğer HTTP taleplerinin aynı sunucuya yönlendirilmesi kesinlikle gereklidir.

Bugün F5'in web sitesini keşfettim ve "yapışkan oturumlar" hakkında bilgi aldım. Kullanıcılarımın çoğunun mobil olması (örneğin iPhone) olması nedeniyle, IP adreslerinin tek bir oturumun ortasında değişmesi mümkündür. Bu, kaynak IP'nin benzersiz oturumları tanımlamak için kullanılamayacağı anlamına gelir. Beyaz kağıtlar, F5 LTM cihazının bunun için bir çözüm sağladığını ve oturum kimliğini belirlemek için HTTP isteğinin kendisi (veya bir çerez) içerisindeki içeriği kullanmamı sağladığını ileri sürüyor.

Çok uzak çok iyi. Ama sonra düşünmeliyim… Bu F5 cihazı tek bir hata noktasıdır. Dahası, kapasiteyi önemli ölçüde artırırsam ve daha fazla F5 aygıtı eklemek istersem? Bir küme kurmak mantıklı. Ancak en iyi şekilde Googling'e rağmen, bir küme "kaputun altında" nasıl işlediğiyle ilgili temel kavramları açıklayan bir beyaz yazı bulamıyorum.

Düşünelim… Diyelim ki iki F5 cihazı aldım. Ağımın harici (Internet'e bakan) arayüzünde ortak bir "sanal" IP paylaşıyorlar. Bir HTTP bağlantısı devreye giriyor ve bir şekilde iki cihaz F5 # 1'in aramayı cevaplaması gerektiğini belirliyor. F5 # 1 şimdi o oturumun kimliğini [çerez aracılığıyla] iç web sunucusu # 4 ile ilişkilendiren bir bellek içi haritasına sahip. İki dakika sonra aynı müşteri aynı oturumun bir parçası olarak yeni bir HTTP bağlantısı başlatır. Hedef "sanal" IP aynıdır ancak kaynak IP adresi değişmiştir. Dünyada F5 # 1'in F5 # 2 yerine bu bağlantıyı alacağını nasıl garanti edebilirim? Eğer önceki kişi bunu alırsa, iyi durumdayız çünkü oturumu tanımlamak için bir bellek içi harita var. Ancak, ikincisi bunu alırsa, oturumun web sunucusu # 4 ile ilişkili olduğunun farkında olmayacaktır.

Bunu yapmak için iki F5 cihazı birbirleriyle bilgi paylaşıyor mu? Ya da bir şeyleri yapmak için pratik / ortak bir yol olmadığını açıkladığım bir yapılandırma mı?

Newb soruları için üzgünüm… bu şey benim için yeni.


5
2017-12-01 02:13


Menşei


Genellikle bu cihazlarda kümelenmenin Yüksek Alabilirlik için olduğunu göreceksiniz, yani # 1 veya # 2 cevap verecek her istek, kalp atışlarını birbirinden ayırana kadar ve daha sonra boştaki cihazlar istekleri sunmaya başlayacaktır. Tüm oturum bilgileri iki cihaz arasında gerçek zamanlı olarak senkronize edilir, böylece diğer cihaz devreye girdiğinde, verilerin güncel bir kopyasına sahip olmalıdır. Bu F5 cihazları hakkında pek bir şey bilmiyorum (fiyat aralığımızın dışında), dolayısıyla milajları farklı olabilir. - Mark Henderson♦
evet, oldukça pahalı olduklarını fark ettim. Muhtemelen kullanılmış bir tane alacağım. Cevap için teşekkürler. - Chad Decker
"Çiftlikte bir sunucuyla bir oturum kurulduğunda, oturumdaki diğer HTTP isteklerinin, oturumun geri kalanı için aynı sunucuya yönlendirilmesi kesinlikle gerekli." Bu alışılmadık bir tasarımın ne mantığıyla sonuçlanabilir? Bana göre daha iyi bir alternatif, müşterilerin mevcut sunucuların bir listesini indirmesini ve belirli bir sunucuya bağlanmasını sağlar. Veya talepler arasında oturum durumunun nasıl korunacağını ve geri yükleneceğini öğrenin. - Greg Askew
Tüm saygımla, Greg, bu konuyu sadece saatlerce araştırdım ve hatta ben Yapışkan oturumların kullanılmasının "alışılmışın dışında bir tasarım" olmadığının farkındayım. Çok yaygın. - Chad Decker
@GregAskew - bu çok, çok yaygın bir uygulamadır. Örneğin, PHP oturumları bir sunucu yerel diskinde depolanır. İsteğiniz başka bir sunucuya taşınırsa, PHP oturumu kaybeder. Bu çok çok normal davranış. - Mark Henderson♦


Cevaplar:


F5'in çoğu HA çiftlerine gelir, bu yüzden bunlar kümelenmiş olur. Bir F5 düştüğünde, IP'ler diğer F5 tarafından çiftin içinde kabul edilir, dolayısıyla herhangi bir arıza süresi yoktur. Sorunuz için, her IP bir seferde yalnızca bir F5'e atanır ve her ikisinde de aktif / aktif değildir.

Bu sizin çözümünüz, şimdi sormanız gereken bir sonraki soru, tüm site F5'in barındırıldığı yere düşerse ne olacak? (Ve sonra küresel yük dengelemeye bakın).


6
2017-12-01 02:21



Ah, evet, ne demek istediğini anladım. Başarısızlık boyutu kritiktir, ancak sanırım artan kapasite açısından geliyordum. Diyelim ki iki yıl sonra tek F5'm bunalmış oluyor. Yükü paylaşmak için başka biriyle "kümelemesem"? Ve eğer öyleyse, devletlerini birbirleriyle paylaşıyorlar mı? Belki de "küme" terimini hatalı kullanıyorum. Üzgünüm durum buysa. Teşekkürler. - Chad Decker
Ben yüksek uçta aktif / aktif kümelemeyi yapabilir ve aktif / aktif olarak gerçekte IP'ler için belirli bir pasif / aktif ve pasif / aktif olan başka bir IP veya IP kümesi için fiili / aktif olabilirsiniz. Herhangi bir zamanda, bir IP sadece bir tane F5 üzerinde aktif olacaktır. Kapasiteniz arttıkça, pratik olarak, F5 donanımınızı daha yüksek performans kutusuna yükseltmeniz yeterli olacaktır. - R D
@ChadDecker - "küme" terimi biraz belirsizdir, bu yüzden genellikle bir HA kümesi veya bir Aktif / Pasif küme veya bir Aktif / Aktif küme olarak adlandırılır. Aradığınız şey, yüksek kullanılabilirlikten ziyade ölçeklendirme için kullanılan bir küme. - Mark Henderson♦
Aha, bu mantıklı. Yanıtınızı beğenmeyi / denemeyi denedim, ancak sistem bunu yapabilmek için on beş itibar noktasına ihtiyacım olduğunu söylüyor. Bu site bana rol yapma oyunu hatırlatıyor. Yine de beğendim. Çok bilgilendirici şeyler! - Chad Decker
@ChadDecker - iyi, şu anda 13 temsilcisiniz. Gitmek için sadece 2 tane daha rep! - Mark Henderson♦


İki F5 içerik anahtarını gerçekten "kümeleyebileceğinizi" sanmıyorum, ancak bu özellik üzerinde çalıştıklarına inanıyorum ama yanılıyor olabilirim. Kümelenme yük dengeleyicileri büyük bir mühendislik sorunudur - katman4 veya katman 7'de bilgiyi nasıl paylaşırlar, katman 2 veya katman 3 üzerinden nasıl iletişim kurarlar ve yük dengeleyicilerinin çalışması gerektiğinden performansı etkilemeden kümeleme ve bilgi paylaşımı nasıl sağlanır? esas olarak tel hızında.

Eski günlerde güvenlik duvarlarını düşünün, proxy tabanlı güvenlik duvarları her zaman bağımsız düğümlerdi, çünkü 7. katmanda bu kadar çok şey yaptılar ve bu bilgiyi performansları öldürmeden düğümler arasında paylaşmak neredeyse imkansızdı. Durumsal paket filtreleri ise yalnızca katman 4'ü aktarmak zorunda kaldı. bilgi ve hatta bu bir yük oldu. Yük dengeleyicileri, VIP'lerinizdeki durumunuzda olduğu gibi, bir son nokta gibi davranan ve böylece tüm TCP oturumu yeniden yazılan ve yük dengeleyicinin sunucuya istemci (yani iki akış ve Bu, gerçek istemcinin, arka uç sunucusuna doğrudan doğruya http pipeline gerçekleştirememesinin bir nedenidir).

HA ile, istediğiniz skalayı elde edemezsiniz, böylece yük dengeleyicinizi yükün üstesinden gelmek için ölçeklendirmeniz gerekir. Satıcılar, ölçeklendirmeyle olduğu gibi, genellikle (her zaman olduğu gibi değil) lisans yükseltme ile ekstra CPU'yu etkinleştirebilir) yeni, daha büyük bir kutu HA'nın açık bir şekilde esneklik ve güvenilirlik sağladığı anlamına gelir. HA ile, genellikle komut yayılımı, konfigürasyon senkronizasyonu ve oturum değişiminin bazı unsurları vardır (bu, yüke neden olabileceği ölçüde yapılandırılabilir).

Yük dengeleyicilerinizi yük dengeleyici (örn. LB -> LB -> Web Çiftliği) ile ölçeklendirmeyi görebilirsiniz, ancak bu harika değildir, gecikmeyi ortaya çıkarabilir, (çok) maliyetlidir ve altyapınızda başka bir arıza noktası vardır. başarıyla uygulandı.

VRRP gibi bir yarı-kümelenme gibi bir şey kullanabilirsiniz Neredeyse bu uygulamada, web grubunuzun önünde iki çift HA yük dengeleyici setine sahip olabilirsiniz, onları HA1 ve HA2 olarak adlandırın. VRRP ile, daha yüksek VRRP önceliği yapılandırması nedeniyle HA1 (vip1) ve diğeri HA2 (vip2) üzerinde canlı olmak üzere iki VIP oluşturulabilir. Vip1 ve vip2, VRRP aracılığıyla otomatik olarak (monitörlere dayalı olarak) veya VRRP önceliğini düşürerek manuel olarak diğer HA çiftine geçebilir.

Çoğu satıcının yukarıdaki yapılandırmalarda KB makaleleri vardır. Ürünlerinde gerçek kümelenme yapan tek bir satıcı olduğuna inanıyorum ama bunun için Google'a izin vereceğim.

Tüm yük dengeleyicileri, arka uç sunucu ilişkilendirmesine uygulayacağınız çeşitli kalıcılık biçimlerine sahiptir. Popüler formlar bugün çerez ve karma (4-tuple ve bir ya da iki başka şey) dayanmaktadır. Yük dengeleyici, senaryoda olduğu gibi bir uç nokta olarak hareket ettiğinde, TCP bağlantısı tam olarak kurulduktan sonra, temelde 4-tuple ve diğer birkaç şey hakkında bilgi içeren bir protokol kontrol arabelleği oluşturacaktır. tekrar). Bağlantının her bir tarafını temsil eden iki arabellek vardır ve bu arabellek, oturum sona erene kadar yük dengeleyicideki bellekte, yeniden kullanım için belleği boşalttıklarında bellekte yaşar.


3
2018-05-10 14:45





Citrix NetScaler, özellikle kümelenme alanında en gelişmiş yük dengeleme çözümü gibi görünüyor. Bir HA çifti yüklemeniz gerekmez, sadece iki kutu kümesi kullanın. Ardından büyümek istediğiniz gibi, kümeye daha fazla kutu ekleyin. Ayrıca VM'lerde çalışan yük dengeleyicileri de kümeleyebilirler.


1
2018-06-20 22:55





Tüm yük dengeleyiciler için, tek bir hata noktasını önlemek için bir HA çifti kurmak mümkündür. Bu her zaman böyle olmuştur. Büyük IP pahalıdır. Citrix NetScaler'ı düşündünüz mü. Çok daha ucuz bir sanal makine sürümü var. Aslında üretim sınırlı üretim hacminde kullanabileceğiniz ücretsiz bir sürüm var. Sadece bu değil, gerekirse NetScaler VPX'i uygulamanızla aynı sunucularda dağıtabilirsiniz. Sadece bir düşünce. daha fazla bilgi isterseniz bana e-posta gönderin.


0
2017-12-06 07:02





Temel olarak, yapılandırmakta olduğunuz VIP türüne bağlı olarak, F5 platformunda iki seçeneğiniz vardır. Bir Katman 4 VIP (etkin bir NAT) üzerinde, bir HA olayı sırasında TCP oturumunun kesintiye uğramamasını sağlayan bağlantı yansıtma yapılandırabilirsiniz. Bu bir Katman 7 VIP için mümkün değildir - Bekleme'ye gerçek zamanlı olarak "yedeklenmek" için çok fazla durum vardır - ancak çerez tekrarlama kayıtlarını yansıtabilir, böylece HA yeniden bağlandıktan sonra istemci yeniden bağlandığında Aynı arka uç sunucusuna yönlendirilecek.

İlk elden bilgiye sahip değilim, fakat Netscaler'in benzer yeteneklere sahip olduğuna inanıyorum.

Bununla birlikte, bu tür bir ısrarla tamamen bağlantılı bir şema, özellikle de herhangi bir düzenli temelde VIP rotasyonuna giren ve çıkan arka uç sunucularınız varsa, sorunlarınız olacaktır. Paylaşılan bir önbellek (bunun için memcached bunun için harika) olup olmadığını araştırmanızı öneririm. Sunucu havuzunuzun herhangi bir üyesi, gelen bir istek üzerine çerezi doğrulamak için sorgulayabilir. Düşündüğünden daha kolay :)


0
2017-08-24 03:19