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.
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).
İ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.
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.
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.
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 :)