Hardware Load Balancer voor SSL-sites *

[relaxteb]

Wij hosten een site op aantal webservers in een NLB cluster met daarachter een sql server.
Op de webservers draait een .NET applicatie en de site maakt gebruik van SSL.

Ons NLB draait met een affinity mode van “single”. Dit betekend dat het afzender adres gebruikt wordt voor het balancen in het cluster.

Voor gebruikers die van het web afkomen is dit een prima oplossing.

Echter als er een bedrijf is met meerdere gebruikers achter een proxy server (met dus 1 ip adres) gebruikt maakt van onze diensten, dan komen dus alle gebruikers op dezelfde server terecht.

Wat wij eigenlijk willen is dat we “no affinity” kunnen gebruiken. Zo wordt iedere request naar een volgende server in het NLB gesluist.

Een SSL beveiligde site gebruiken met affinity “single” geeft geen problemen omdat de SSL sessie maar 1 keer hoeft worden opgebouwd. Een volgende connectie gaat snel omdat er een “SSL session state” wordt bij gehouden.

Als we echter een SSL beveiligde site willen gebruiken met “no affinity” dan zal dus bij elke request de SSL verbinding opnieuw moeten worden opgebouwd. Dit geeft een stuk meer overhead en de performance zal dus flink dalen.

Op de microsoft site staat zelfs een stukje “The overhead for obtaining a new SSL session ID is five times more than for reusing a session ID”


Nou zijn er voor zover ik weet weinig oplossingen voor dit probleem :

Meer servers in het NLB: Dit heeft niet zoveel zin, als er een grote partij op 1 server uitkomt wordt de load dan nog niet verdeeld.

Meer ip addressen klanten : Als een klant met een grote groep gebruikers erachter meerdere ip adressen zou gebruiken in de communicatie naar onze site zou het “NLB algoritme” met “Single Affinity”deze addressen kunnen herleiden naar verschillende servers.

Ik ben bang dat er geen oplossing voor is maar heeft iemand hier nog ervaringen mee ?
Ik weet dat er voor ASP.NET “state servers” zijn, is er ook zoiets voor SSL ?

[axis]

relaxteb schreef op maandag 11 juli 2005 @ 11:49:
Echter als er een bedrijf is met meerdere gebruikers achter een proxy server (met dus 1 ip adres) gebruikt maakt van onze diensten, dan komen dus alle gebruikers op dezelfde server terecht.

Hmm.. vind je dit ook echt een probleem? Ik kan me voorstellen dat je dit risico gewoon op de koop toe neemt.. Weet ook niet wat voor applicatie het is, daar niet van..

Als je 50k sessies per dag hebt, en er komen eens 1000 mensen via 1 proxy binnen, gaan die inderdaad bijvoorbeeld naar server 1 (en dan is dan 2% van je bezoekers). Misschien komen er daarna wel 750 mensen via een andere proxy, en gaan die naar server 2. Of ook naar server 1, dat weet je dan niet echt van te voren, maar is dat erg?

[relaxteb]

Ja dat is erg, alleen al om het feit dat wij direct aangesloten klanten hebben, die dus een aantal duizend machines erachter hebben staan. Deze klanten voeren hele batches op met opdrachten die door onze webservers worden opgepikt. Vandaar dat we hier voor naar mogelijkheden aan het kijken zijn.

[axis]

Hmm.. da's duidelijik.. zo te zien zijn er nog meer met hetzelfde probleem.

[Anoniem: 87586]

Hebben jullie gekeken naar een load balancing mechanisme dat gebruik maakt
van een hardware appliance? M.a.w. een hardware load balancer die i.p.v. NLB
werkt? Deze kunnen over het algemeen goed overweg met firewall/proxy omgevingen
omdat ze SNAT/PAT kennen. Elke nieuwe sessie die achter eenzelfde adres vandaan
komt krijgt een unieke IP/port combinatie.

Dit betekent echter wel dat er geld neergeteld moet worden t.o.v. het NLB mechanisme
omdat deze laatste in het besturingssysteem is meegeleverd.

[axis]

En je zou die hw load balancer ook als SSL eindpunt kunnen gebruiken (en verkeer tussen load balancer en webservers is unencrypted), scheelt ook weer flink in de resources op je webservers..

Maarja, dan ben je wel een behoorlijk bedrag kwijt aan een hw oplossing.

[relaxteb]

Van wat ik heb gelezen op diverse forums zou een Hardware Loadbalancer geen verschil uit maken.
Ik zal hier toch nog eens dieper in duiken.
Of het technisch voor onze applicatie oplossing mogelijk is het SSL endpoint te verplaatsen weet ik niet. Ik ken dit principe niet dus als je daar nog links voor hebt, graag
Geld is niet zo'n groot probleem als zoiets echt een oplossing zou betekenen.

[axis]

Nou ja, het eindpunt van de SSL connectie verplaatsen kan in principe wel, ik weet dat MS ISA server, een software firewall, die kan ook verschillende scenarios aan, waarbij alle communicatie met de webserver over HTTP gaat, en dat die zelf alle links replaced naar HTTPS. Kan me voorstellen dat dit ook met een hardwaredoos kan.

En wat Liquid zegt klinkt opzich logisch, als er een request door een NAT router gaat, gebruikt ie meestal een andere TCP source port. Kan me voorstellen dat je load balancer daarop onderscheid kan maken, in plaats van ip-adres. Maar weet hier ook niet zoveel over, en hoe dit in de HTTP(S)standaard zit..

[Anoniem: 87586]

Ik zie even niet waarom een hardware LB geen oplossing zou bieden, voor de
situatie waarin mensen vanachter een proxy/firewall omgeving komen. Met het
gebruik van een hardware LB, vervang je het NLB mechanisme en krijg je ook
een zuiverdere werking van balanceren. Wij zijn zelf van een NLB omgeving
overgestapt naar een hardware oplossing om diverse redenen:

- NLB test niet op beschikbaarheid van de applicatie (alleen netwerktechnisch)
- NLB kent alleen het Round Robin principe, dus er is geen meting op load e.d.
- NLB werkt niet goed met MAC adressen zodat de NLB interface aangesloten
moest worden op een aparte hub i.p.v. een switch.

Bovendien kunnen we met onze LB SSL sessies termineren, zowel richting
de client, als de server. En dit gebeurt met een SSL accelerated functie, zodat
er van vertraging geen sprake zal zijn zoals de factor 5, door Microsoft genoemd.
Met het wegvallen van de NLB, is affinity ook niet meer een struikelblok.

De webservers van Microsoft maken zelf geen gebruik van NLB (vraag me af
waarom ), maar hebben ook hardware LB's. De dozen waar ik het over
heb zijn van het bedrijf F5, en de productlijn die je moet hebben is BIG-IP. Wij
gebruiken ze naar volle tevredenheid.

Neem eens een kijkje op http://www.f5.com, en bel eens met die mensen. Wanneer
geld niet echt een rol speelt voor een goede oplossing is het de moeite waard om
in ieder geval een telefoontje te wagen. Bij serieuze interesse kun je ze ook een
tijdje in bruikleen gebruiken, kwestie van afspreken

Succes!

[relaxteb]

tnx ! ik gaat zeker een kijkje nemen.

[Anoniem: 116859]

F5 heeft mooie producten.
Heb er al eens over gesproken met een Dell specialist, deze gaf aan dat de Big IP range uitstekende producten bevatte. F5 schijnt ooit ook onderdeel van Dell geweest te zijn?

[Anoniem: 57365]

axis schreef op donderdag 14 juli 2005 @ 10:48:
Nou ja, het eindpunt van de SSL connectie verplaatsen kan in principe wel, ik weet dat MS ISA server, een software firewall, die kan ook verschillende scenarios aan, waarbij alle communicatie met de webserver over HTTP gaat, en dat die zelf alle links replaced naar HTTPS. Kan me voorstellen dat dit ook met een hardwaredoos kan.

op dat moment is je isa geen proxy meer maar reverse proxy. Als je reverse proxy gebruikt, dan zal je idd de ssl tunnel termineren, maar je kan wel weer een nieuwe tunnel opzetten vanaf de proxy naar de webserver. Dit zou ook de oplossing zijn omdat je dan ook nog kan aangeven of het request bij de webserver aan moet komen als request van de reverse proxy of als een request van de client (aka unique ip).

[Anoniem: 31605]

** Schup **

Relaxteb, Ik ben benieuwd of je dit probleem nu opgelost hebt

[relaxteb]

Hoi !

Op dit moment gaan we in ieder geval onze "applicaties" splitsen.
Dus we krijgen een aantal verschillende NLB's :
1 voor de website
1 voor de webservices
1 voor de webservices van "heavy use" klanten.

De hardware load balancer gaat misschien nog in de toekomst mee doen maar voorlopig nog niet.

Helaas is er geen andere oplossing voor handen.

[relaxteb]

Een tijd terug heb ik in een topic al eens gevraagd naar een oplossing voor het load balancen van SSL websites. Er kwam daar uit dat het beste een hardware load balancer gebruikt kon worden.

Nou zijn er een aantal verschillende leveranciers van deze apparaten :
F5 --> Big IP
Cisco --> CSS series
En nog overige die ik nu nog niet ken.

Wat ze allemaal kunnen is SSL offloading, dus het termineren van de SSL tunnel op de load balancer en niet meer op de server.
Ook zijn er tal van andere mogelijkheden waarmee ik nog niet helemaal bekend ben.

Wat zijn jullie ervaringen met de verschillende hardware load balancers.

Zit er veel verschil tussen bijvoorbeeld Cisco en F5 ?

[zenith]

De nieuwe series van Foundry ServerIron kunnen dit nu ook.
http://www.foundrynet.com

De CSS en de SI van Foundry kunnen nagenoeg hetzelfde, voordeel van de CSS is dat die ook ondersteuning heeft voor DFP. Maar als je dat niet gebruikt zou ik naar het prijskaartje gaan kijken.

De CSS heeft diverse manieren van SSL offloading, dus afhankelijk van wat je nodig hebt zou ik een keuze maken tussen de drie.

Die van F5 heb ik nog weinig mee gedaan helaas.

[ Voor 80% gewijzigd door zenith op 08-10-2005 15:28 ]

[Anoniem: 35417]

Berichten uit nieuwe topic hier naar verplaatst. Zal nog even de titel aanpassen.