Vraag Bestellen: 1. nginx 2. vernis 3. haproxy 4. webserver?


Ik heb gezien dat mensen aanbevelen om al deze dingen in een stroom te combineren, maar ze lijken veel overlappende functies te hebben, dus ik zou graag willen ingaan waarom je misschien 3 verschillende programma's wilt doorlopen voordat je je eigen echte webserver raakt.

nginx:

  • ssl: ja
  • kompres: ja
  • cache: ja
  • back-end pool: ja

vernis:

  • ssl: nee (stunnel?)
  • samenpersen: ?
  • cache: ja (primair kenmerk)
  • back-end pool: ja

haproxy:

  • ssl: nee (stunnel)
  • samenpersen: ?
  • cache: nee
  • back-end pool: ja (primair kenmerk)

Is het de bedoeling om al deze voor uw belangrijkste webservers te ketenen om zo enkele van hun primaire voordelen te krijgen?

Het lijkt nogal fragiel om zoveel daemons samen te laten streamen en soortgelijke dingen te doen.

Wat is uw implementatie- en bestelvoorkeur en waarom?


47
2017-11-19 17:52


oorsprong


Varnish heeft nu SSL-ondersteuning: zie blog.exceliance.fr/2012/09/10/... - MiniQuark
wil je zeggen HAProxy? - Luis Lobo Borobia
Nginx lijkt alles te hebben, dus ik zou zeggen gebruik gewoon Nginx. - Seun Osewa


antwoorden:


Simpel gezegd..

HaProxy is de beste opensource loadbalancer op de markt.
Vernis is de beste cacher voor opensource-statische bestanden op de markt.
Nginx is de beste opensource-webserver op de markt.

(natuurlijk is dit mijn mening en die van veel andere mensen)

Maar over het algemeen gaan niet alle vragen door de hele stapel.

Alles gaat via haproxy en nginx / multiple nginx's.
Het enige verschil is dat u op vernis "bouten" voor statische verzoeken.

  • elk verzoek is uitgebalanceerd voor redundantie en doorvoer (goed, dat is schaalbare redundantie)
  • elke aanvraag voor statische bestanden raakt eerst de verniscache (goed, dat is snel)
  • een dynamisch verzoek gaat rechtstreeks naar de backend (geweldig, vernis wordt niet gebruikt)

Over het algemeen past dit model in een schaalbare en groeiende architectuur (neem haproxy uit als u niet over meerdere servers beschikt)

Ik hoop dat dit helpt: D

Notitie: Ik zal eigenlijk ook pond voor SSL-zoekopdrachten introduceren: D
U kunt een server hebben die is bedoeld voor het decoderen van SSL-aanvragen en standaardverzoeken doorgeeft aan de back-endstack: D (het maakt de hele stapel sneller en eenvoudiger)


59
2017-11-19 18:26



Zeer interessant, vooral het gedeelte over de decryptieserver. 1 - Gerry
Geweldig antwoord. Ik vraag me af wat er voor alles staat? Is het HAProxy of Nginx? - John
@John: [Client -> HAProxy -> Vernis -> Nginx -> Statische inhoud] of [Client -> HAProxy -> Nginx (optioneel) -> Toepassingsserver (dynamische inhoud)] - MiniQuark
Waarom zou u statische gegevens opslaan en dynamisch bedienen? Nginx is razendsnel voor het serveren van statische bestanden. Ik gebruik liever een stapel zoals [HAProxy -> Nginx] voor statische en [HAProxy -> Nginx -> Varnish -> Apache] om een ​​cache op de dynamiek te implementeren. Het beëindigen van SSL bij de load balancer zoals aangegeven met speciale terminating nodes. - Steve Buzonas


Voorwoord

Update in 2016. Dingen evolueren, alle servers worden beter, ze ondersteunen allemaal SSL en het web is verbazingwekkender dan ooit.

Tenzij anders vermeld, is het volgende gericht op professionals in bedrijven en start-ups, die duizenden tot miljoenen gebruikers ondersteunen.

Deze tools en architecturen vereisen veel gebruikers / hardware / geld. Je kunt dit proberen in een thuislab of om een ​​blog te houden, maar dat slaat nergens op.

Over het algemeen onthoudt u dat u dat wilt hou het simpel. Elke bijgevoegde middleware is een ander essentieel stukje middleware om te onderhouden. Perfectie wordt niet bereikt wanneer er niets aan toe te voegen is, maar wanneer er niets meer te verwijderen is.

Enkele algemene en interessante implementaties

HAProxy (balanceren) + nginx (php-applicatie + caching)

De webserver is nginx met php. Wanneer nginx er al is, kan het net zo goed overweg met caching en omleidingen.

HAProxy ---> nginx-php
A       ---> nginx-php
P       ---> nginx-php
r       ---> nginx-php
o       ---> nginx-php
x       ---> nginx-php
y       ---> nginx-php

HAProxy (balanceren) + vernis (caching) + Tomcat (Java-applicatie)

HAProxy kan omleiden naar Vernis op basis van de aanvraag URI (* .jpg * .css * .js).

HAProxy ---> tomcat
A       ---> tomcat
        ---> tomcat
P       ---> tomcat <----+
r       ---> tomcat <---+|
o                       ||
x       ---> varnish <--+|
y       ---> varnish <---+

HAProxy (balanceren) + nginx (SSL naar de host en caching) + Webserver (applicatie)

De webservers spreken geen SSL, hoewel IEDEREEN SSL MOET SPREKEN (vooral deze HAProxy-WebServer-link met privégebruikersinformatie die door EC2 gaat). Het toevoegen van een lokale nginx maakt het mogelijk om SSL naar de host te brengen. Zodra nginx er is, kan het net zo goed worden gedaan voor caching en URL-rewriting.

Notitie: Poortomleiding 443: 8080 gebeurt, maar maakt geen deel uit van de functies. Het heeft geen zin om poort omleiding te doen. De load balancer kan rechtstreeks met de webserver spreken: 8080.

          (nginx + webserver on same host)
HAProxy ---> nginx:443 -> webserver:8080
A       ---> nginx:443 -> webserver:8080
P       ---> nginx:443 -> webserver:8080
r       ---> nginx:443 -> webserver:8080
o       ---> nginx:443 -> webserver:8080
x       ---> nginx:443 -> webserver:8080
y       ---> nginx:443 -> webserver:8080

middleware

HAProxy: DE load balancer

Hoofdfuncties:

  • Load-balancing (TCP, HTTP, HTTPS)
  • Meerdere algoritmen (round robin, source ip, headers)
  • Sessie persistentie
  • SSL-beëindiging

Gelijkaardige alternatieven: nginx (multifunctionele web-server configureerbaar als een load-balancer)
Verschillende alternatieven: Cloud (Amazon ELB, Google load balancer), Hardware (F5, fortinet, citrix netscaler), Other & Worldwide (DNS, anycast, CloudFlare)

Wat doet HAProxy en wanneer moet u het gebruiken?
Wanneer u load balancing nodig hebt. HAProxy is de oplossing.

Behalve wanneer je heel goedkoop OF snel & vies wilt OF je hebt niet de vaardigheden beschikbaar, dan mag je een ELB: D gebruiken

Behalve wanneer u in bankieren / overheid / soortgelijk bent en uw eigen datacenter moet gebruiken met harde vereisten (toegewijde infrastructuur, betrouwbare failover, 2 lagen firewall, auditing dingen, SLA om x% per minuut downtime te betalen, alles in één) dan u mag 2 F5 op het rek plaatsen met uw 30 applicatieservers.

Behalve wanneer je voorbij 100k HTTP (S) [en multi-sites] wilt gaan, dan MOET je dat hebben veelvouden HAProxy met een laag [global] taakverdeling vóór zich (cloudflare, DNS, anycast). Theoretisch zou de global balancer rechtstreeks met de webservers kunnen praten om HAProxy te deactiveren. Gewoonlijk moet u HAProxy (s) echter als openbare toegangspunt (en) naar uw datacenter bewaren en geavanceerde opties afstemmen om een ​​evenwicht te vinden tussen alle hosts en de variantie te minimaliseren.

Persoonlijke mening: Een klein, ingeperkt, open source project, volledig toegewijd aan ÉÉN WELK DOEL. Onder de eenvoudigste configuratie (EEN bestand), de meest bruikbare en meest betrouwbare open source software die ik in mijn leven tegenkwam.

Nginx: Apache die niet zuigt

Hoofdfuncties:

  • WebServer HTTP of HTTPS
  • Voer applicaties uit in CGI / PHP / een andere
  • URL omleiden / herschrijven
  • Toegangscontrole
  • HTTP-headers-manipulatie
  • caching
  • Proxy omkeren

Gelijkaardige alternatieven: Apache, Lighttpd, Tomcat, Gunicorn ...

Apache was de de-facto webserver, ook wel een gigantische clusterfuck van tientallen modules en duizenden regels genoemd httpd.confbovenop een kapotte architectuur voor verzoekverwerking. nginx maakt dit allemaal opnieuw, met minder modules, (enigszins) eenvoudiger configuratie en een betere kernarchitectuur.

Wat doet nginx en wanneer moet u het gebruiken?
Een webserver is bedoeld voor het uitvoeren van applicaties. Wanneer je applicatie is ontwikkeld om op nginx te draaien, heb je al nginx en kun je net zo goed al zijn functies gebruiken.

Behalve wanneer jouw applicatie niet bedoeld is om op nginx te draaien en nginx nergens in je stack te vinden is (Java shop anyone?) dan heeft nginx weinig zin. De webservers-functies zijn waarschijnlijk aanwezig in uw huidige webserver en de andere taken worden beter afgehandeld door de juiste speciale tool (HAProxy / Varnish / CDN).

Behalve wanneer uw webserver / applicatie functies mist, moeilijk te configureren is en / of u liever doodgaat dan ernaar te kijken (Gunicorn anyone?), dan mag u een nginx vooraan plaatsen (dwz lokaal op elk knooppunt) om URL-herschrijving uit te voeren , stuur 301-omleidingen, bewerk de toegangscontrole, verstrek SSL-codering en bewerk HTTP-headers on-the-fly. [Dit zijn de functies die van een webserver worden verwacht]

Vernis: DE caching-server

Hoofdfuncties:

  • caching
  • Geavanceerd cachen
  • Fine Grained Caching
  • caching

Gelijkaardige alternatieven: nginx (multifunctionele web-server configureerbaar als een caching server)
Verschillende alternatieven: CDN (Akamai, Amazon CloudFront, CloudFlare), Hardware (F5, Fortinet, Citrix Netscaler)

Wat doet Varnish en wanneer moet je het gebruiken?
Het caching, alleen caching. Het is meestal de moeite niet waard en het is tijdverspilling. Probeer in plaats daarvan CDN. Houd er rekening mee dat caching het laatste is waar u om moet geven bij het uitvoeren van een website.

Behalve als je een website uitsluitend over foto's of video's draait, moet je grondig naar CDN kijken en serieus nadenken over caching.

Behalve wanneer je gedwongen wordt om je eigen hardware in je eigen datacenter te gebruiken (CDN is geen optie) en je webservers zijn verschrikkelijk in het afleveren van statische bestanden (toevoegen van meer webservers helpt niet), dan is Varnish het laatste redmiddel.

Behalve wanneer u een site hebt met meestal-statische maar toch complexe-dynamisch gegenereerde inhoud (zie de volgende paragrafen), dan kan Varnish veel processorkracht besparen op uw webservers.

Statische caching wordt overschat in 2016

Caching is bijna configuratievrij, geldvrij en tijdloos. Abonneer u op CloudFlare of CloudFront of Akamai of MaxCDN. De tijd die het kost om deze regel te schrijven is langer dan de tijd die nodig is om caching in te stellen EN het bier dat ik in mijn hand heb is duurder dan het mediaan CloudFlare-abonnement.

Al deze services werken out-of-the-box voor statische * .css * .js * .png en meer. Sterker nog, ze eren vooral de Cache-Control in de HTTP-header. De eerste stap van caching is om uw webservers te configureren voor het verzenden van de juiste cacherichtlijnen. Maakt niet uit wat CDN is, wat Varnish, welke browser er in het midden zit.

Overwegingen bij de uitvoering

Varnish is gemaakt in een tijd dat de gemiddelde webservers stikte om een ​​kattenfoto op een blog te plaatsen. Tegenwoordig kan een enkele instantie van de gemiddelde moderne multi-threaded asynchrone door modewoorden aangedreven webserver betrouwbaar kittens leveren aan een heel land. Met dank aan sendfile().

Ik heb een aantal snelle prestatietests gedaan voor het laatste project waaraan ik heb gewerkt. Een enkele tomcat-instance kan 21 000 tot 33 000 statische bestanden per seconde via HTTP verwerken (testen van bestanden van 20B tot 12kB met verschillende HTTP- / clientaansluitingen). Het aanhoudend uitgaand verkeer is meer dan 2,4 Gb / s. De productie heeft slechts 1 Gb / s-interfaces. Kan het niet beter dan de hardware, geen zin om zelfs maar Varnish te proberen.

Caching Complex Veranderen van dynamische inhoud

CDN en caching-servers negeren meestal URL met parameters zoals ?article=1843, ze negeren elk verzoek met sessiecookies of geverifieerde gebruikers en negeren de meeste MIME-typen, inclusief de application/json van /api/article/1843/info. Er zijn configuratie-opties beschikbaar, maar meestal niet fijnkorrelig, eerder "alles of niets".

Vernis kan aangepaste complexe regels hebben (zie VCL) om te definiëren wat cacheerbaar is en wat niet. Deze regels kunnen specifieke inhoud cachen door URI, headers en huidige gebruikerssessie-cookie en MIME-type en inhoud ALLES SAMEN. Dat kan veel processorkracht besparen op webservers voor een heel specifiek laadpatroon. Dat is wanneer Varnish handig en GEWELDIG is.

Conclusie

Het kostte me een tijdje om al deze stukjes te begrijpen, wanneer ze te gebruiken en hoe ze bij elkaar passen. Ik hoop dat dit je kan helpen.

Dat blijkt vrij lang te zijn (6 uur om te schrijven. OMG!: O). Misschien moet ik daarover een blog of een boek beginnen. Leuk feit: er lijkt geen limiet te zijn aan de lengte van het antwoord.


28
2018-05-22 18:37



Er is een limiet op de lengte van het antwoord, maar je moet nog een paar boeken schrijven om het te bereiken. - Michael Hampton♦
Een punt dat het vermelden waard is met betrekking tot caching: het is een krachtige manier om de prestaties van een site te verbeteren wanneer u geen controle over de toepassing hebt; vooral als de applicatie echt stomme cache headers heeft (enterprise apps anyone?). Je moet echter veel meer op de hoogte zijn van geverifieerde bronnen. - Cameron Kerr
@ user5994461 Ik wil je blog graag lezen. Geweldig antwoord! - oxalorg


Het klopt dat de 3 hulpprogramma's gemeenschappelijke functies delen. De meeste instellingen zijn prima met elke combinatie van twee van de drie. Het hangt ervan af wat hun hoofddoel is. Het is gebruikelijk om te accepteren dat je wat caching opoffert als je weet dat je applicatieserver snel is op statica (bijvoorbeeld: nginx). Het is gebruikelijk om een ​​aantal functies voor taakverdeling op te offeren als je tientallen of honderden servers gaat installeren en het niet erg vindt om er het maximale uit te halen, noch voor problemen met het oplossen van problemen. Het is gebruikelijk om een ​​aantal webserverfuncties op te offeren als u van plan bent overal een gedistribueerde toepassing met veel componenten te gebruiken. Toch bouwen sommige mensen interessante boerderijen met allemaal.

Je moet in gedachten houden dat je het over 3 solide producten hebt. Over het algemeen hoeft u de balans niet te laden. Als je front SSL nodig hebt, dan is nginx first als een reverse-proxy prima. Als je dat niet nodig hebt, is vernis aan de voorkant prima. Dan kun je haproxy gebruiken om je apps in balans te brengen. Soms wil je ook naar verschillende server farms overschakelen op de haproxy zelf, afhankelijk van bestandstypes of paden.

Soms moet je je beschermen tegen zware DDoS-aanvallen, en haproxy vooraan zal meer geschikt zijn dan de andere.

Over het algemeen hoef je je geen zorgen te maken over welk compromis te doen tussen je keuzes. Je moet kiezen hoe je ze moet monteren om de beste flexibiliteit voor je behoeften te krijgen, nu en in de toekomst. Zelfs als je meerdere van hen meerdere keren opstapelt, kan het soms goed zijn, afhankelijk van je behoeften.

In de hoop dat dit helpt!


19
2017-11-20 18:45



+1 voor HAProxy - de auteur reageert op vragen over serverstoring. Bedankt. - Joel K
Arenstar: Heb je een van deze tools geschreven? Willy Tarreau is de hoofdontwikkelaar van HAProxy. - Joel K
Bedankt voor deze Willy. Je hebt mijn vraag hierboven aan Arenstar beantwoord. - John
Merk op dat de huidige ontwikkelcode voor HAProxy nu SSL bevat. - Joel K


Alle andere antwoorden zijn vóór 2010 en daarom is er een bijgewerkte vergelijking toegevoegd.

Nginx

  • Een volledige webserver, andere functies kunnen ook worden gebruikt. Bijvoorbeeld: HTTP samendrukking
  • SSL-ondersteuning
  • Zeer licht van gewicht aangezien Nginx vanaf het begin ontworpen was om licht te zijn.
  • Near Varnish caching-prestaties
  • Dicht bij de prestaties van de HAProxy load balancing

Vernis

  • het beste voor complexe caching-scenario's en integratie met de toepassingen.
  • beste statische bestandscacher
  • Geen SSL-ondersteuning
  • Geheugen en CPU-eter

Haproxy

  • beste loadbalancer, voor geavanceerde load balancing-functies, vergelijkbaar met hardware loadbalancers
  • SSL wordt ondersteund sinds 1.5.0
  • Eenvoudiger, gewoon een tcp-proxy zijn zonder een http-implementatie, wat maakt het sneller en minder gevoelig voor fouten.

Dus de beste methode lijkt ze allemaal in een juiste volgorde te implementeren.

Echter voor algemeen doel, Nginx is het beste als je bovengemiddelde prestaties krijgt voor iedereen: Caching, Reverse proxying, Load balancing, met zeer weinig overhead op het gebruik van hulpbronnen. En dan heb je SSL en volledige webserverfuncties.


13
2017-11-30 11:25





Varnish heeft ondersteuning voor taakverdeling: http://www.varnish-cache.org/trac/wiki/LoadBalancing

Nginx heeft ondersteuning voor taakverdeling: http://wiki.nginx.org/NginxHttpUpstreamModule

Ik zou dit eenvoudig configureren met vernis + stunnel. Als ik nginx om een ​​andere reden nodig had, zou ik gewoon nginx + vernis gebruiken. U kunt ervoor zorgen dat nginx SSL-verbindingen accepteert en deze proxy geeft om te vernisten, waarna u met Nginx via HTTP kunt praten.

Sommige mensen gooien nginx (of Apache) in de mix omdat dit iets algemenere tools zijn dan Varnish. Als u bijvoorbeeld inhoud wilt transformeren (bijvoorbeeld met behulp van XDV, apache filters, enz.) Op de proxy-laag, zou u een van deze nodig hebben, omdat Varnish dit niet zelf kan doen. Sommige mensen zijn wellicht meer bekend met de configuratie van deze tools, dus het is gemakkelijker om Varnish als een eenvoudige cache te gebruiken en de taakverdeling op een andere laag uit te voeren, omdat ze al bekend zijn met Apache / nginx / haproxy als een load-balancer.


5
2017-11-19 17:57



Rechts - "back-end pool" was bedoeld om erop te wijzen dat deze drie alle load balancing-functies hebben. Uit mijn eerste onderzoek lijkt het erop dat HAProxy de meest afstembare opties voor taakverdeling heeft. - Joel K
Dat klinkt redelijk, omdat het speciaal is gebouwd als hulpmiddel voor het uitbalanceren van de belasting. Aan de andere kant zijn de load balancing-functies van Varnish behoorlijk goed, en als u één proces uit deze mix verwijdert, krijgt u een eenvoudiger configuratie met minder vertraging. - larsks