Oversigt #

Målet med denne artikel er at forklare, hvordan man kan forstørre applikationsserveres muligheder, f.eks. Tomcat, JBoss or IIS ved at gøre dem yderst web-skalerbare og ved at sætte dem op med høj tilgængelighed for at være tolerante over for fejl, og hvordan man kan styrke 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 oppetid, i en længere periode end normalt.

Ved at sætte op Applikationsservere I høj tilgængelighed løser vi følgende problemer:

1. En enkelt server mister effektivitet, når den håndterer et stort antal forespørgsler
2. Sessionsdata gemmes i tilfælde af serverfejl
3. Opdatering af applikation uden at afbryde tjenesten

Hvad er webskala? #

Ved at anvende webskalaprincipper på applikationsservere kan alle forretningsprocesser af enhver størrelse vokse, optimeres, automatiseres og effektivt skaleres.

Hvad er en applikationsserver? #

En applikationsserver er et softwareframework, der leverer forretningslogikken til et applikationsprogram. Det betyder, at det administrerer ressourcer til at oprette webapplikationer og et servermiljø til at køre dem.
Selvom denne artikel kan bruges som en 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-teknologierne.
2. JBoss or WildFly: applikationsserveren udviklet af Red Hat.
3. IIS (Internetinformationstjenester): Applikationsserveren udviklet af Microsoft.

Opsætning RELIANOID Load Balancer #

Med RELIANOID Load Balancer Vi kan sikre høj tilgængelighed og skalerbarhed for applikationsservere. Bemærk, at det for at følge disse instruktioner kræves, at du installerer en instans af RELIANOID Load Balancer og flere instanser af applikationsservere. Miljøet, vi skal beskrive, er følgende:

Trin 0: Serverreplikering #

I vores eksempel bruger vi to backend-servere til hver applikation, men vi kan inkludere så mange som nødvendigt. Det er afgørende at sikre konsistens, så vi altid ser det samme, når vi opretter forbindelse til en applikationsserver, og alle data, der er gemt i applikationen, ikke går tabt. For at opnå dette skal sessionsreplikering inden for serverne konfigureres. Vi kalder dette trin 0 da dette skal gøres på applikationsserverne.

Tomcat giver indbygget replikering af sessioner i hukommelsen: DeltaManager og BackUpManagerDen primære forskel mellem disse to replikatorer er, at DeltaManager er langsommere, men mere pålidelig i tilfælde af fejl.

JBoss giver også en enkel måde at aktivere sessionsreplikering på: ved at markere applikationen som distribuerbar i web.xml deskriptor.

Servicereplikering for IIS kan opnås ved hjælp af DFSR (Replikation af distribueret filsystem).

Trin 1: Opret virtuel IP #

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

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

 

Indtast navnet og adressen på din nye virtuelle IP-adresse. Gem den derefter ved at klikke på knappen "Opret".

Trin 2: Opret http-farm #

En farm eller klynge er en samling af computerservere, der leverer serverfunktionalitet, hvilket øger dens kapacitet betydeligt. Selvom vi bruger udtrykkene gård og klynge som synonymer er der en lille forskel mellem dem. Når man taler om en klynge, redundans er underforstået, men når man taler om en gård, der kan være eller ikke være nogen redundans. I vores tilfælde, da vi vil have en konfiguration, der tolererer fejl, kunne vi tale om farm eller cluster som synonymer.

På denne måde, ved at oprette en farm af applikationsservere, vil vi øge dens ydeevne og fejltolerance, 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 tilbyde muligheder for indholdsskift under den samme virtuelle IP og port.

Yderligere to muligheder vil blive vist. Vælg den virtuelle IP oprettet på trin 1 og en port (i eksemplet vælger vi 80, da det er standard for HTTP-protokol), og klik på Gem .

Trin 3: Tilføj tjenesterne #

Hovedideen er at betjene forskellige applikationer fra forskellige applikationsservere fra den samme virtuelle IP-adresse og port. Så når farmen er oprettet, skal vi redigere den for at tilføje nye tjenester. I vores eksempel vil vi oprette tre tjenester. En for hver applikationsserver. Klik venligst på knappen redigere gård.

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 tjenestenavnet “app1”.

 

Da vi vil tilgå alle tre tjenester gennem den samme gård, er vi nødt til at skelne mellem disse tjenester. For at gøre dette kan vi sætte en værdi for URL-mønsterDette felt giver mulighed for at bestemme en webtjeneste i henhold til den URL, klienten anmoder om via et specifikt URL-mønster. I vores eksempel skriver vi ^/app1.*, ^/app2.* og ^/app3.*. Klik på Ændre at anvende ændringer.

Husk at backend'en skal finde adressen http://[VIRTUAL_IP]:[PORT]/[YOUR_SERVICE] (i vores eksempel http://192.168.56.200/app1), for at garantere dette, skal konteksten være konfigureret i din applikation. I vores eksempler vil vi konfigurere 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 specifikke tilfælde af IIS, kontekster kaldes applikationer.

I dette eksempel har vi to backend-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 under vores session hopper fra én server til en anden, vil der være effektivitets-, data- og endda kommunikationstab. For at undgå dette Vedholdenhed session skal konfigureres. Vi vil vælge at vedligeholde en session efter sessions-id, så det betyder, at vi under en session kun vil oprette forbindelse til én server.

I tjenestens globale parametre kan vi nu ændre persistenssessionsfeltet til COOKIE: en bestemt cookie

Type JSESSIONID som persistenssessionsidentifikator for Tomcat og Jboss og Sessions ID for IIS, og klik derefter på Opdater nederst på siden.

 

Nu skal vi under den samme farm tilføje 2 ekstra tjenester på samme måde end app1 til app2 og app3, inklusive persistenscookien til JBoss (standard kaldes JSESSIONID) og IIS (standardcookien til ASP.NET er ASPXAUTH), men du kan bruge den cookie, som applikationen kræver. Hver tjeneste i farmen har sine egne backends, der kan deles mellem farme eller farm-tjenester.

Bemærk at rækkefølgen af ​​tjenesterne er vigtig for at matche det korrekte URL-mønster.

Endelig skal vi anvende ændringerne ved at genstarte bedriften.

Tillykke! Du har konfigureret dine applikationsservere til høj tilgængelighed. Du kan få adgang til dem 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 konfigurere gårdens værge for at udføre avancerede sundhedstjek til backends og sikre, at de er oppe, kører og applikationens korrekte opførsel, ikke kun et TCP-porttjek. Find venligst Gårdværge inden for din tjeneste, vi har oprettet i trin 3. Klik på Brug FarmGuardian til at tjekke backend-servere, kan du også ændre tiden mellem check og endelig i Kommando for at kontrollere tekstboksen, skriv følgende kommando.

check_http -I HOST -w 10 -c 10 -t 10 -e 200 -p PORT -s ' '

Klik til sidst på Opdater nederst på siden.

 

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

-Jeg VÆR: Token-HOST vil blive erstattet af den definerede backend-IP-adresse.
-w 10: responstid for at resultere i advarselsstatus: 10 sekunder
-c 10: responstid på kritisk status: 10 sekunder
-t 10: 10 sekunder før forbindelsen timeout
-e 200: forventer strengen 200 i status for serversvaret
-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 200 OK-svar, og at svarkommandoen 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 fuldstændigt svar fra backend-systemerne.

Trin 5: Høj sikkerhed #

Sikker kommunikation kan nemt oprettes med RELIANOID Load Balancer, så næste trin er at aktivere HTTPS-lytteren: På Rediger gårdens globale parametre skærm, skal du ændre farmlytteren fra HTTP til HTTPS og den virtuelle port til 443.

Nu kan tjenesterne tilgås 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 inden for farmens globale parametre HTTPS-indstillinger sektion. Vi kan ændre ciphers til HØJ Sikkerhed.

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

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 tilgængelige: en liste over certifikater vil blive vist for at blive valgt for den aktuelle farm (kun for HTTP-farme, hvilket er vores tilfælde). Vi kan vælge en fra listen og klikke videre Tilføj. Endelig skal du klikke på Ændre og genstart gården for at anvende ændringer.

For yderligere information, se venligst HTTP-profilfarme.

HTTPS kan også aktiveres på dine applikationsservere. Hvis dette er tilfældet, skal du aktivere denne funktion. HTTPS-backends.