Lastbalancering og høj tilgængelighed af applikationsservere: Tomcat, Jboss og IIS

SENDT AF Zevenet | 24. februar 2017

Oversigt

Formålet med denne artikel er at forklare, hvordan man forstørrer programmets applikationsservere som f.eks Tomcat, JBoss or IIS ved at gøre dem meget web skalerbare og ved at sætte dem op i høj tilgængelighed for at være tolerante over for fejl og hvordan man styrker cybersikkerheden.

Hvad er høj tilgængelighed?

Høj tilgængelighed er en kvalitet af et system eller en komponent, der sikrer et højt niveau af operationel ydeevne, normalt opetid, i en højere end normal tid.

Ved opsætning Application Servers I høj tilgængelighed løser vi følgende problemer:

  1. En enkelt server mister effektivitet, når du håndterer en stor mængde anmodninger
  2. Sessionsdata bevares i tilfælde af serverfejl
  3. Opdatering af applikation uden ophørende service

Hvad er web-skala?

Anvendelse af web-skala principper til Application Servers Alle forretningsprocesser af enhver størrelse er i stand til at vokse, blive optimeret, være automatiseret og effektivt skalerbar.

Hvad er en applikationsserver?

En applikationsserver er en software ramme, der giver forretningslogikken til et applikationsprogram, det betyder, at det administrerer ressourcer til at oprette webapplikationer og et servermiljø for at køre dem.
Selv om denne artikel kan bruges som vejledning til enhver applikationsserver, vil vi forklare nogle detaljer om de mest populære, som er:

  1. Tomcat software (eller også kendt som Apache Tomcat eller Tomcat server): En open source implementering af Java Servlet, JavaServer Pages, Java Expression Language og Java WebSocket teknologier.
  2. JBoss or WildFly: applikationsserveren udviklet af Red Hat.
  3. IIS (Internet Information Services): Applikationsserveren udviklet af Microsoft.

Opsætning af Zevenet Load Balancer

Med Zevenet Load Balancer Vi kan sikre høj tilgængelighed og skalerbarhed for applikationsservere. Bemærk at for at følge disse instruktioner skal det installeres en instans af Zevenet Load Balancer og flere forekomster af applikationsservere. Det miljø, vi skal beskrive, er følgende:

Applikationsservere ordning

Trin 0: Serverreplikation

I vores eksempel bruger vi to backends-servere til hver applikation, men vi kan inkludere så meget som nødvendigt. Det er vigtigt at sikre konsistens, så vi altid ser det samme, når vi forbinder til en applikationsserver, og alle de data, der er gemt i applikationen, går ikke tabt. For at opnå dette skal sessionsreplikation i serverne konfigureres. Vi kalder dette trin 0 da dette skal ske i applikationsservere.

Tomcat giver indbygget replikering i hukommelsessession: DeltaManager og BackUpManager. Hovedforskellen mellem disse to replikatorer er det DeltaManager er langsommere, men mere pålidelig i tilfælde af fiasko.

JBoss giver også en nem måde at aktivere session replikering på: ved at markere applikationen som distribueret i web.xml deskriptor.

Service replikering til IIS kan opnås ved hjælp af DFSR (Distribueret File System Replication).

Trin 1: Opret virtuel IP

Når Zevenet Load Balancer er installeret, er det nødvendigt at oprette en ny virtuel IP, vælg fra hovedmenuen Netværk-> Virtuelle grænseflader-> Handlinger-> Opret

Find den fysiske grænseflade, hvor du vil oprette en virtuel IP

 

Indtast navnet og adressen på din nye virtuelle IP. Gem det derefter ved at klikke på “Opret” -knappen.

Trin 2: Opret http gård

En gård eller klynge er en samling af dataservere, der giver serverfunktionalitet en betydelig stigning i dens kapacitet. Selv om vi bruger vilkårene gård og klynge Som synonymer er der en lille forskel mellem dem. Når man taler om a klynge, redundans er underforstået, men når man taler om a gård, der kan eller måske ikke være nogen redundans. I vores tilfælde, som vi vil have en tolerance mod fejlkonfiguration, kunne vi tale om farm eller klynge som synonymer.

På denne måde vil vi ved at oprette en gård med applikationsservere øge dens ydeevne og svigt tolerante, hvilket er afgørende for høj tilgængelighed. For at opnå dette gå til LSLB-> Gårde-> Opret

Vælg et navn og HTTP som profil. Vi vælger http-profil, fordi det er den bedste mulighed for webtjenester, da vi kan levere indholdsvekslingsindstillinger under den samme virtuelle IP og port.

Der vises to yderligere muligheder. Vælg den virtuelle IP, der er oprettet på trin 1 og en port (i eksemplet vælger vi 80, da det er standard for HTTP-protokollen) og klikker på Gem .

Trin 3: Tilføj tjenesterne

Hovedidéen er at betjene forskellige applikationer fra forskellige applikationsservere fra samme virtuelle IP og port. Så når gården er oprettet, skal vi redigere den for at tilføje nye tjenester. I vores eksempel etablerer vi tre tjenester. En til hver applikationsserver. Venligst klik på knappen rediger farm.

Flere detaljer om gården kan redigeres, i eksemplet skal vi indstille standardværdierne og tjenesterne.

I skærmbilledet ovenfor har vi Tilføjet en tjeneste med servicenavn “app1”.

 

Da vi får adgang til alle tre tjenester gennem samme gård, skal vi skelne mellem disse tjenester. For at gøre dette kan vi indstille en værdi for URL-mønster. Dette felt giver mulighed for at bestemme en webservice i henhold til den URL-adresse, som klienten anmoder om via et bestemt webadressemønster. I vores eksempel skriver vi ^ / App1. *, ^ / App2. * og ^ / App3. *. Klik på Ændre at anvende ændringer.

Vær opmærksom på at backend skal finde adressen http://[VIRTUAL_IP]:[PORT]/[YOUR_SERVICE] (i vores eksempel http://192.168.56.200/app1) for at sikre dette skal konteksten oprettes i din ansøgning. I vores eksempler vil vi oprette konteksten / app1 forum Tomcat, / app2 forum JBoss og / app3 forum IIS. Det Kontekst repræsenterer en webapplikation, der kører inden for en bestemt virtuel vært. I det særlige tilfælde af IISKontekster henvises til ansøgninger.

I dette eksempel har vi to backends-servere pr. Applikation. Vi vælger IP, port (standard 8080 for Tomcat og JBoss, og 80 for IIS), timeout og vægt og klik på gem backend .

Vi ønsker at undgå serverkommutering: hvis vi hopper fra en server til en anden i løbet af vores session, vil der være effektivitet, data og endda kommunikations tab. For at undgå dette Persistens session skal konfigureres. Vi vælger at opretholde en session med session id, så det betyder, at vi i løbet af en session vil forbinde til kun én server.

I service globale parametre kan vi nu ændre persistens sessionsfeltet til COOKIE: en bestemt cookie

Type JSESSIONID som persistens session identifikator for Tomcat og Jboss og Sessions ID for IIS, og klik derefter på Opdatering nederst på siden.

 

Nu, under den samme gård, skal vi 'tilføje 2 flere tjenester på samme måde end app1 til app2 og app3, inklusive persistens-cookien til JBoss (standard kaldes JSESSIONID) og IIS (standard cookie til ASP.NET er ASPXAUTH), men du kan bruge den cookie, der kræves af ansøgningen. Hver tjeneste på gården har deres egne backends, der kunne deles mellem gårde eller gårde.

Bemærk, at rækkefølgen af ​​tjenesterne er vigtige for at matche det korrekte webadressemønster.

Endelig skal vi anvende ændringerne ved at genstarte gården.

Tillykke! du har konfigureret dine applikationsservere i høj tilgængelighed. Du kan få adgang til det ved at skrive http://[VIRTUAL_IP]:[PORT]/[YOUR_SERVICE] (i vores eksempel http://192.168.56.200/app1, http://192.168.56.200/app2 or http://192.168.56.200/app3).

Trin 4: Avanceret kontrol

Vi vil nu oprette gården for at udføre avanceret sundhedskontrol til bagenden, der sikrer, at de er i gang, kører og den korrekte opførsel af applikationen, ikke kun en TCP-portkontrol. Venligst find Farm Guardian inden for din service har vi oprettet i trin 3. Klik på Brug FarmGuardian til at kontrollere Backend-servere, kan du også ændre tiden mellem check og endelig, i Kommando at tjekke tekstboks, skriv følgende kommando.

check_http -I HOST -w 10 -c 10 -t 10 -e 200 -p PORT -s '</html>'

Endelig skal du klikke på Opdatering ved siden af ​​siden.

 

Kommandoen check_http tester HTTP-forbindelser med den angivne vært. I vores tilfælde bruger vi følgende muligheder:

-I HOST: Token HOST vil blive erstattet af den angivne backend IP-adresse.
-w 10: Svarstid for at resultere i advarselsstatus: 10 sekunder
-c 10: Svarstid til kritisk status: 10 sekunder
-t 10: 10 sekunder før forbindelsestider ud
-e 200: Forventer strengen 200 i status for serverresponsen
-P PORT: Token PORT vil blive erstattet af den definerede backend-port.
-s ' '': streng at forvente i indhold er ' ''

Så hvad denne kommando vil gøre er grundlæggende at kontrollere, at vi får et svar på 200 OK, og at svarskommandoen indeholder strengen ' '. Vi vælger denne streng, fordi den er i slutningen af ​​svaret, på denne måde kan vi garantere, at vi får et fuldt svar fra backends.

Trin 5: Høj sikkerhed

Sikker kommunikation kan nemt opstilles med Zevenet Load Balancer, så det næste skridt er at aktivere HTTPS-lytteren: På Rediger farm globale parametre skærm, skal du ændre bedriftslytteren fra HTTP til HTTPS og Virtual Port til 443.

Nu kan man få adgang til tjenesterne ved at skrive https://[Your_virtual_ip]/[yourappservice] i din browser.

Sikker kommunikation kører nu, men vi kan gå videre ved at konfigurere HTTPS-parametrene: Find de globale parametre inden for gården HTTPS-indstillinger afsnit. Vi kan ændre ciphers til HØJ Sikkerhed.

Ciphers-feltet bruges til at opbygge en liste over cifre accepteret af SSL-forbindelser for at hærde SSL-forbindelsen. Ved at vælge HØJ sikkerhed, vil vi som standard indstille cifrene.

kEECDH+ECDSA+AES128:kEECDH+ECDSA+AES256:kEECDH+AES128:kEECDH+AES256:kEDH+AES128:kEDH+AES256:DES-CBC3-SHA:+SHA:!aNULL:!eNULL:!LOW:!kECDH:!DSS:!MD5:!EXP:!PSK:!SRP:!CAMELLIA:!SEED

En anden mulighed er HTTPS-certifikater til rådighed: En liste over certifikater vises for at blive valgt til den aktuelle gård (kun for HTTP-bedrifter, hvilket er vores tilfælde). Vi kan vælge en fra listen og klikke på Tilføj. Endelig skal du klikke på Ændre og genstart bedriften med henblik på at anvende ændringer.

For yderligere information, se venligst HTTP profil gårde.

HTTPS kan også aktiveres i dine applikationsservere, hvis det er tilfældet, skal du aktivere indstillingen HTTPS backends.

Del på:

Dokumentation i henhold til GNU Free Documentation License.

Var denne artikel til hjælp?

Relaterede artikler