Er zijn al veel woorden over dit onderwerp gezegd, zowel op mijn blog als daarbuiten. Het lijkt mij dat het moment is aangebroken om van het specifieke naar het algemene te gaan en te proberen dit onderwerp los van elke succesvolle implementatie ervan te bekijken.

Laten we beginnen?

Om te beginnen is het logisch om te beslissen waar we het over gaan hebben. In deze context heeft de webapplicatie drie hoofddoelen:

• schaalbaarheid- het vermogen om tijdig te reageren op voortdurende groei van de belasting en onverwachte toestroom van gebruikers;
• beschikbaarheid- het verlenen van toegang tot de applicatie, zelfs in geval van nood;
• prestatie- zelfs de kleinste vertraging bij het laden van een pagina kan een negatieve indruk achterlaten bij de gebruiker.

Het belangrijkste gespreksonderwerp zal, zoals je misschien al vermoedt, schaalbaarheid zijn, maar ik denk niet dat de andere doelen buiten beschouwing zullen blijven. Ik zou meteen een paar woorden willen zeggen over de toegankelijkheid, om hier later niet op terug te komen, in de zin van “het spreekt voor zich”: elke site streeft er op de een of andere manier naar om zo stabiel mogelijk te functioneren, dat wil zeggen toegankelijk te zijn aan absoluut al zijn potentiële bezoekers op absoluut elk moment, maar soms gebeuren er allerlei onvoorziene situaties die tijdelijke onbeschikbaarheid kunnen veroorzaken. Om de potentiële impact op de beschikbaarheid van de applicatie te minimaliseren, is het noodzakelijk om te voorkomen dat er componenten in het systeem zitten waarvan het potentiële falen zou leiden tot het niet beschikbaar zijn van functionaliteit of gegevens (of in ieder geval van de site als geheel). Elke server of elk ander onderdeel van het systeem moet dus ten minste één back-up hebben (het maakt niet uit in welke modus ze zullen werken: parallel of de een maakt een back-up van de ander terwijl deze zich in de passieve modus bevindt), en de gegevens moeten gerepliceerd in ten minste twee exemplaren (en bij voorkeur niet op RAID-niveau, maar op verschillende fysieke machines). Het opslaan van meerdere back-upkopieën van gegevens ergens anders dan het hoofdsysteem (bijvoorbeeld op speciale services of op een afzonderlijk cluster) zal ook veel problemen helpen voorkomen als er iets misgaat. Vergeet de financiële kant van het probleem niet: verzekering in geval van storingen vereist extra aanzienlijke investeringen in apparatuur, en het is zinvol om te proberen deze te minimaliseren.

Schaalbaarheid wordt doorgaans in twee gebieden verdeeld:

Verticale schaalbaarheid Het verhogen van de prestaties van elk systeemonderdeel om de algehele prestaties te verbeteren. Horizontale schaalbaarheid Het systeem opsplitsen in kleinere structurele componenten en deze verdelen over afzonderlijke fysieke machines (of groepen daarvan) en/of het aantal servers vergroten dat dezelfde functie parallel uitvoert.

Op de een of andere manier moet je bij het ontwikkelen van een systeemgroeistrategie zoeken naar een compromis tussen prijs, ontwikkeltijd, uiteindelijke prestaties, stabiliteit en een groot aantal andere criteria. Vanuit financieel oogpunt is verticale schaalbaarheid verre van de meest aantrekkelijke oplossing, omdat de prijzen voor servers met een groot aantal processors altijd vrijwel exponentieel groeien in verhouding tot het aantal processors. Daarom is de horizontale aanpak het interessantst, aangezien deze in de meeste gevallen wordt gebruikt. Maar verticale schaalbaarheid heeft soms bestaansrecht, vooral in situaties waarin de hoofdrol wordt gespeeld door de tijd en de snelheid van het oplossen van een probleem, en niet door een financieel vraagstuk: het kopen van een BIG-server is immers veel sneller dan het praktisch ontwikkelen van applicaties van scratch, waardoor het wordt aangepast om te werken op een groot aantal parallelle servers waarop servers draaien.

Nu de algemeenheden achter de rug zijn, gaan we verder met een overzicht van mogelijke problemen en oplossingen bij horizontaal schalen. Bekritiseer alstublieft niet te veel - ik beweer geen absolute juistheid en betrouwbaarheid, ik denk alleen maar "hardop", en ik zal zeker niet eens alle punten over dit onderwerp kunnen noemen.

Applicatieservers

Bij het schalen van de applicaties zelf doen zich zelden problemen voor als je tijdens de ontwikkeling altijd in gedachten houdt dat elk exemplaar van de applicatie op geen enkele manier rechtstreeks verbonden mag zijn met zijn “collega’s” en absoluut elk gebruikersverzoek moet kunnen verwerken, ongeacht waar de eerdere verzoeken van deze gebruiker zijn verwerkt en wat hij op dit moment precies wil van de applicatie als geheel.

Door de onafhankelijkheid van elke individuele actieve applicatie te garanderen, is het bovendien mogelijk om steeds meer verzoeken per tijdseenheid te verwerken door eenvoudigweg het aantal parallel werkende applicatieservers dat aan het systeem deelneemt te vergroten. Alles is vrij eenvoudig (relatief).

Load-balancering

De volgende taak is het gelijkmatig verdelen van verzoeken over de beschikbare applicatieservers. Er zijn veel benaderingen om dit probleem op te lossen en nog meer producten die hun specifieke implementatie bieden.

Apparatuur Netwerkapparatuur waarmee u de belasting over meerdere servers kunt verdelen, kost meestal een behoorlijk bedrag, maar naast andere opties biedt deze aanpak meestal de hoogste prestaties en stabiliteit (vooral vanwege de kwaliteit, en dergelijke apparatuur wordt soms in paren geleverd en werkt volgens het principe). Er zijn behoorlijk wat serieuze merken in deze branche die hun oplossingen aanbieden - er is genoeg om uit te kiezen: Cisco, Gieterij, NetScalar en vele anderen. Software Er is op dit gebied een nog grotere verscheidenheid aan mogelijke opties. Het is niet zo eenvoudig om softwareprestaties te verkrijgen die vergelijkbaar zijn met hardwareoplossingen, en HeartBeat zal softwarematig moeten worden geleverd, maar de apparatuur voor de werking van een dergelijke oplossing is een reguliere server (mogelijk meer dan één). Er zijn nogal wat van dergelijke softwareproducten, meestal zijn het eenvoudigweg HTTP-servers die verzoeken omleiden naar hun collega's op andere servers in plaats van ze rechtstreeks naar de programmeertaaltolk te sturen voor verwerking. U kunt bijvoorbeeld mod_proxy vermelden. Daarnaast zijn er meer exotische opties op basis van DNS, dat wil zeggen dat tijdens het bepalen door de klant het IP-adres van de server met de internetbronnen die hij nodig heeft, het adres wordt uitgegeven rekening houdend met de belasting van de beschikbare servers, evenals enkele geografische overwegingen.

Elke optie heeft zijn eigen assortiment aan positieve en negatieve kanten. Daarom bestaat er geen eenduidige oplossing voor dit probleem: elke optie is goed in zijn eigen specifieke situatie. Vergeet niet dat niemand u beperkt tot het gebruik van slechts één ervan; indien nodig kan een bijna willekeurige combinatie ervan eenvoudig worden geïmplementeerd.

Resource-intensief computergebruik

Veel applicaties gebruiken een aantal complexe mechanismen, dit kan het converteren van video, afbeeldingen, geluid zijn of eenvoudigweg het uitvoeren van een aantal resource-intensieve berekeningen. Dergelijke taken vereisen speciale aandacht als we het over internet hebben, omdat het onwaarschijnlijk is dat een gebruiker van een internetbron het leuk vindt om een ​​​​paar minuten lang naar een pagina te kijken en alleen maar een bericht te zien als: "Bewerking succesvol voltooid!"

Om dergelijke situaties te voorkomen, moet u proberen de prestaties van resource-intensieve bewerkingen synchroon met het genereren van internetpagina's te minimaliseren. Als een bepaalde bewerking geen invloed heeft op de nieuwe pagina die naar de gebruiker wordt verzonden, kunt u deze eenvoudig ordenen wachtrij taken die moeten worden voltooid. In dit geval voegt de applicatieserver, op het moment dat de gebruiker alle acties heeft voltooid die nodig zijn om de bewerking te starten, eenvoudigweg een nieuwe taak aan de wachtrij toe en begint onmiddellijk met het genereren van de volgende pagina zonder op de resultaten te wachten. Als de taak daadwerkelijk erg arbeidsintensief is, kunnen dergelijke wachtrijen en taakbehandelaars op een aparte server of cluster worden geplaatst.

Als het resultaat van de bewerking betrokken is bij de volgende pagina die naar de gebruiker wordt verzonden, moet u, wanneer deze asynchroon wordt uitgevoerd, een beetje vals spelen en de gebruiker op de een of andere manier afleiden terwijl deze wordt uitgevoerd. Als we het bijvoorbeeld hebben over het converteren van video naar flv Vervolgens kunt u bijvoorbeeld snel een schermafbeelding genereren met het eerste frame tijdens het samenstellen van een pagina en deze vervangen in plaats van de video, en de weergaveoptie dynamisch aan de pagina toevoegen nadat de conversie is voltooid.

Een andere goede methode om met dergelijke situaties om te gaan, is door de gebruiker simpelweg te vragen 'later terug te komen'. Als een dienst bijvoorbeeld schermafbeeldingen genereert van websites vanuit verschillende browsers om de juistheid van de weergave ervan aan eigenaren of eenvoudigweg geïnteresseerden aan te tonen, kan het genereren van een pagina daarmee minuten, zelfs geen seconden duren. Het handigst voor de gebruiker in een dergelijke situatie zou zijn om aan te bieden de pagina binnen zoveel minuten op het opgegeven adres te bezoeken, in plaats van voor onbepaalde tijd aan zee te wachten op het weer.

Sessies

Bijna alle webapplicaties hebben op de een of andere manier interactie met hun bezoekers, en in de overgrote meerderheid van de gevallen is het nodig om gebruikersbewegingen over sitepagina's te volgen. Om dit probleem op te lossen wordt meestal een mechanisme gebruikt sessies, die bestaat uit het toekennen van een uniek identificatienummer aan elke bezoeker, dat aan hem wordt doorgegeven om in cookies te worden opgeslagen of, bij ontstentenis daarvan, via GET voortdurend met hem te worden “meegesleept”. Nadat de server bij het volgende HTTP-verzoek een bepaald ID van de gebruiker heeft ontvangen, kan hij de lijst met reeds uitgegeven nummers bekijken en ondubbelzinnig bepalen wie deze heeft verzonden. Elke ID kan worden gekoppeld aan een bepaalde set gegevens die de webapplicatie naar eigen inzicht kan gebruiken; deze gegevens worden doorgaans standaard opgeslagen in een bestand in een tijdelijke map op de server.

Het lijkt erop dat alles eenvoudig is, maar... maar verzoeken van bezoekers van dezelfde site kunnen door meerdere servers tegelijk worden verwerkt. Hoe kun je dan bepalen of de ontvangen ID op een andere server is uitgegeven en waar de gegevens ervan doorgaans worden opgeslagen? ?

De meest voorkomende oplossingen zijn centralisatie of decentralisatie van sessiegegevens. Een enigszins absurde zin, maar hopelijk kunnen een paar voorbeelden de zaken verduidelijken:

Gecentraliseerde sessieopslag Het idee is simpel: creëer een gemeenschappelijke ‘spaarpot’ voor alle servers, waar ze de sessies die ze uitgeven kunnen opslaan en meer te weten kunnen komen over de sessies van bezoekers van andere servers. Theoretisch zou de rol van zo'n 'spaarvarken' eenvoudigweg een bestandssysteem kunnen zijn dat over het netwerk wordt gemonteerd, maar om bepaalde redenen lijkt het gebruik van een soort DBMS veelbelovend, omdat dit veel problemen elimineert die verband houden met het opslaan van sessiegegevens in bestanden. Maar vergeet in het geval van een gedeelde database niet dat de belasting ervan gestaag zal toenemen met de toename van het aantal bezoekers, en het is ook de moeite waard om vooraf opties te bieden voor het oplossen van problematische situaties die verband houden met mogelijke mislukkingen in de operatie van de server met dit DBMS. Gedecentraliseerde sessieopslag Een goed voorbeeld is het opslaan van sessies in , een systeem dat aanvankelijk is ontworpen voor gedistribueerde gegevensopslag in RAM, waardoor alle servers snel toegang hebben tot alle sessiegegevens, maar tegelijkertijd (in tegenstelling tot de vorige methode) zal er geen enkel centrum zijn om deze op te slaan. Dit voorkomt knelpunten op het gebied van prestaties en stabiliteit tijdens periodes van verhoogde belasting.

Als alternatief voor sessies worden soms mechanismen met een vergelijkbaar doel gebruikt, gebouwd op cookies, dat wil zeggen dat alle gebruikersgegevens die de applicatie nodig heeft, aan de clientzijde worden opgeslagen (waarschijnlijk in gecodeerde vorm) en indien nodig worden opgevraagd. Maar naast de voor de hand liggende voordelen die gepaard gaan met het niet hoeven opslaan van onnodige gegevens op de server, doet zich een aantal beveiligingsproblemen voor. Gegevens die aan de clientzijde zijn opgeslagen, zelfs in gecodeerde vorm, vormen een potentiële bedreiging voor het functioneren van veel applicaties, aangezien iedereen kan proberen deze voor eigen voordeel te wijzigen of om de applicatie te schaden. Deze aanpak is alleen goed als er vertrouwen bestaat dat absoluut elke manipulatie van door gebruikers opgeslagen gegevens veilig is. Maar is het mogelijk om 100% zeker te zijn?

Statische inhoud

Hoewel de hoeveelheden statische gegevens klein zijn, neemt niemand de moeite om ze op te slaan in het lokale bestandssysteem en er eenvoudigweg toegang toe te verlenen via een aparte lichtgewicht webserver zoals (ik bedoel voornamelijk verschillende vormen van mediagegevens), maar vroeg of laat zal de server De limieten voor schijfruimte of de bestandssysteemlimiet voor het aantal bestanden in één map zullen worden bereikt, en u zult moeten nadenken over het opnieuw distribueren van de inhoud. Een tijdelijke oplossing zou kunnen zijn om gegevens per type over verschillende servers te verdelen, of misschien een hiërarchische directorystructuur te gebruiken.

Als statische inhoud een van de hoofdrollen speelt in de werking van de applicatie, is het de moeite waard om na te denken over het gebruik van een gedistribueerd bestandssysteem om deze op te slaan. Dit is misschien een van de weinige manieren om de hoeveelheid schijfruimte horizontaal te schalen door extra servers toe te voegen zonder fundamentele wijzigingen aan te brengen in de werking van de applicatie zelf. Ik wil op dit moment geen advies geven over welk clusterbestandssysteem ik moet kiezen. Ik heb al meer dan één recensie van specifieke implementaties gepubliceerd - probeer ze allemaal te lezen en te vergelijken, als dit niet genoeg is, de rest van het netwerk ook; tot uw beschikking.

Misschien is deze optie om de een of andere reden niet haalbaar, dan zul je “het wiel opnieuw moeten uitvinden” om op applicatieniveau principes te implementeren die vergelijkbaar zijn met datasegmentatie in relatie tot een DBMS, die ik later zal noemen. Deze optie is ook behoorlijk effectief, maar vereist aanpassing van de applicatielogica, wat extra werk voor ontwikkelaars betekent.

Een alternatief voor deze benaderingen is het gebruik van zogenaamde Netwerk voor inhoudlevering- externe diensten die de beschikbaarheid van uw inhoud voor gebruikers garanderen tegen een bepaalde materiële beloning voor de dienst. Het voordeel ligt voor de hand: het is niet nodig om uw eigen infrastructuur te organiseren om dit probleem op te lossen, maar er komt wel een extra kostenpost bij. Ik zal geen lijst van dergelijke diensten geven, maar als iemand deze nodig heeft, zal het niet moeilijk te vinden zijn.

Caching

Caching is zinvol in alle fasen van de gegevensverwerking, maar slechts enkele cachingmethoden zijn het meest effectief voor verschillende soorten toepassingen.

DBMS Bijna alle moderne DBMS'en bieden ingebouwde mechanismen voor het in de cache opslaan van de resultaten van bepaalde zoekopdrachten. Deze methode is behoorlijk effectief als uw systeem regelmatig dezelfde gegevensmonsters maakt, maar heeft ook een aantal nadelen. De belangrijkste daarvan zijn het ongeldig maken van de cache van de hele tabel bij de kleinste verandering, evenals de lokale locatie van de tabel. cache, wat niet effectief is als er meerdere servers in de systeemgegevensopslag zijn. Sollicitatie Op applicatieniveau worden objecten van welke programmeertaal dan ook meestal in de cache opgeslagen. Met deze methode kunt u een aanzienlijk deel van de query's aan het DBMS volledig vermijden, waardoor de belasting ervan aanzienlijk wordt verminderd. Net als de applicaties zelf moet een dergelijke cache onafhankelijk zijn van het specifieke verzoek en de server waarop deze wordt uitgevoerd, dat wil zeggen dat hij tegelijkertijd beschikbaar moet zijn voor alle applicatieservers, en nog beter: hij moet over verschillende servers worden verdeeld. machines voor een efficiënter gebruik van RAM. Je kunt met recht een leider worden genoemd op dit aspect van caching, waar ik het ooit al over had. HTTP-server Veel webservers hebben modules voor het cachen van zowel statische inhoud als de resultaten van scripts. Als de pagina zelden wordt bijgewerkt, kunt u met deze methode voorkomen dat de pagina wordt gegenereerd als reactie op een vrij groot deel van de verzoeken, zonder dat er wijzigingen zichtbaar zijn voor de gebruiker. Omgekeerde proxy Door een transparante proxyserver tussen de gebruiker en de webserver te plaatsen, kunt u de gebruiker voorzien van gegevens uit de proxy-cache (die zich in het RAM-geheugen of op schijf kan bevinden), zonder zelfs maar verzoeken naar HTTP-servers te sturen. In de meeste gevallen is deze aanpak alleen relevant voor statische inhoud, voornamelijk verschillende vormen van mediadata: afbeeldingen, video's en dergelijke. Hierdoor kunnen webservers zich alleen concentreren op het werken met de pagina's zelf.

Caching vereist van nature vrijwel geen extra hardwarekosten, vooral als u het RAM-gebruik door andere servercomponenten nauwlettend in de gaten houdt en alle beschikbare “overtollige” cachevormen gebruikt die het meest geschikt zijn voor een bepaalde toepassing.

In sommige gevallen kan het ongeldig maken van de cache een niet-triviale taak worden, maar op de een of andere manier is het niet mogelijk om een ​​universele oplossing te schrijven voor alle mogelijke problemen die ermee gepaard gaan (althans voor mij persoonlijk), dus laten we deze kwestie bewaren tot betere tijden. Over het algemeen ligt de oplossing voor dit probleem in de webapplicatie zelf, die meestal een soort ongeldigverklaringsmechanisme implementeert door middel van het verwijderen van een cacheobject via een bepaalde periode na de creatie of het laatste gebruik ervan, of “handmatig” wanneer dit zeker is evenementen van de gebruiker of andere systeemcomponenten.

Databases

Ik liet het meest interessante deel over aan het voorgerecht, omdat dit integrale onderdeel van elke webapplicatie meer problemen veroorzaakt als de belasting toeneemt dan alle andere samen. Soms lijkt het er zelfs op dat je de horizontale schaalvergroting van het gegevensopslagsysteem volledig moet opgeven ten gunste van verticale schaalvergroting - koop gewoon diezelfde BIG-server voor een bedrag van zes of zeven cijfers aan niet-roebels en val jezelf niet lastig met onnodige problemen.

Maar voor veel projecten is zo'n radicale oplossing (en over het algemeen een tijdelijke oplossing) niet geschikt, wat betekent dat er nog maar één weg voor hen overblijft: horizontale schaalvergroting. Laten we over haar praten.

Het pad van vrijwel elk webproject vanuit databaseoogpunt begon met één eenvoudige server waarop het hele project draaide. Dan ontstaat op een goed moment de behoefte om het DBMS naar een aparte server te verplaatsen, maar na verloop van tijd begint het de belasting ook niet aan te kunnen. Het heeft geen zin om gedetailleerd in te gaan op deze twee fasen; alles is relatief triviaal.

De volgende stap is meestal meester-slaaf bij asynchrone gegevensreplicatie is de manier waarop dit schema werkt al meerdere keren in de blog genoemd, maar misschien herhaal ik het: met deze aanpak worden alle schrijfbewerkingen slechts op één server (master) uitgevoerd en de overige servers (slave ) gegevens rechtstreeks van de “master” ontvangen, terwijl alleen verzoeken om gegevens te lezen worden verwerkt. Zoals u weet groeien de lees- en schrijfbewerkingen van elk webproject altijd evenredig met de belasting, terwijl de verhouding tussen beide soorten verzoeken vrijwel vast blijft: voor elk verzoek om gegevens bij te werken, worden er gewoonlijk gemiddeld ongeveer een dozijn gelezen verzoeken. In de loop van de tijd groeit de belasting, wat betekent dat het aantal schrijfbewerkingen per tijdseenheid ook groeit, maar slechts één server verwerkt ze, en dan zorgt deze ook voor het maken van een bepaald aantal kopieën op andere servers. Vroeg of laat zullen de kosten van gegevensreplicatiebewerkingen zo hoog worden dat dit proces een zeer groot deel van de processortijd van elke server in beslag zal nemen, en dat elke slaaf slechts een relatief klein aantal leesbewerkingen zal kunnen verwerken. en als gevolg daarvan zal elke extra slave-server de totale productiviteit slechts in geringe mate gaan verhogen, en voor het grootste deel ook alleen zijn gegevens bijhouden in overeenstemming met de “master”.

Een tijdelijke oplossing voor dit probleem kan zijn om de masterserver te vervangen door een productiever exemplaar, maar op de een of andere manier zal het niet mogelijk zijn om de overgang naar het volgende ‘niveau’ van de ontwikkeling van gegevensopslagsystemen eindeloos uit te stellen: "scherven", waaraan ik onlangs heb gewijd. Laat ik er dus maar kort bij stilstaan: het idee is om alle data in delen te verdelen op basis van een bepaald kenmerk en elk deel op te slaan op een aparte server of cluster, waarbij een dergelijk deel van de data samenwerkt met het dataopslagsysteem waarin het zich bevindt. bevindt zich en wordt een segment of genoemd scherf'om. Met deze aanpak kunt u de kosten die verband houden met gegevensreplicatie vermijden (of deze vele malen verlagen). aanzienlijk verhoog de algehele prestaties van het opslagsysteem. Maar helaas brengt de transitie naar dit dataorganisatiesysteem veel andere kosten met zich mee. Omdat er geen kant-en-klare oplossing bestaat voor de implementatie ervan, moet je de applicatielogica aanpassen of een extra "laag" toevoegen tussen de applicatie en het DBMS, en dit alles wordt meestal geïmplementeerd door de projectontwikkelaars. Kant-en-klare producten kunnen hun werk alleen eenvoudiger maken door een raamwerk te bieden voor het bouwen van de basisarchitectuur van het gegevensopslagsysteem en de interactie ervan met de rest van de applicatiecomponenten.

In dit stadium eindigt de keten meestal, omdat gesegmenteerde databases horizontaal kunnen schalen om volledig te voldoen aan de behoeften van zelfs de zwaarst belaste internetbronnen. Het zou passend zijn om iets te zeggen over de feitelijke datastructuur binnen databases en de organisatie van de toegang daartoe, maar elke beslissing is sterk afhankelijk van de specifieke toepassing en implementatie, dus ik sta mezelf toe slechts een paar algemene aanbevelingen te doen. :

Denormalisatie Query's die gegevens uit meerdere tabellen combineren, vereisen doorgaans meer CPU-tijd om uit te voeren, als alle overige factoren gelijk blijven, dan een query die slechts één tabel beïnvloedt. En prestaties zijn, zoals aan het begin van het verhaal vermeld, uiterst belangrijk op internet. Logische gegevenspartitionering Als een deel van de gegevens altijd afzonderlijk van de bulk wordt gebruikt, is het soms zinvol om deze te scheiden in een afzonderlijk, onafhankelijk gegevensopslagsysteem. Zoekopdrachtoptimalisatie op laag niveau Door verzoeklogboeken bij te houden en te analyseren, kunt u de langzaamste bepalen. Het vervangen van de gevonden zoekopdrachten door efficiëntere zoekopdrachten met dezelfde functionaliteit kan helpen om de rekenkracht efficiënter te gebruiken.

In deze sectie is het de moeite waard om een ​​ander, specifieker type internetprojecten te noemen. Dergelijke projecten werken met gegevens die geen duidelijk geformaliseerde structuur hebben. In dergelijke situaties is het gebruik van relationele DBMS als gegevensopslag, op zijn zachtst gezegd, ongepast; In deze gevallen gebruiken ze meestal minder strikte databases, met primitievere functionaliteit op het gebied van gegevensverwerking, maar ze zijn in staat grote hoeveelheden informatie te verwerken zonder fouten te vinden in de kwaliteit ervan en de naleving van het formaat. Een geclusterd bestandssysteem kan dienen als basis voor een dergelijke gegevensopslag, en in dit geval wordt een mechanisme gebruikt dat wordt genoemd om de gegevens te analyseren. Ik zal u slechts kort het principe van de werking ervan vertellen, aangezien het op volledige schaal iets verder gaat de reikwijdte van dit verhaal.

We hebben dus een aantal willekeurige gegevens aan de invoer in een formaat dat niet noodzakelijkerwijs correct wordt nageleefd. Als gevolg hiervan moet u enige definitieve waarde of informatie verkrijgen. Volgens dit mechanisme kan vrijwel elke data-analyse in de volgende twee fasen worden uitgevoerd:

Kaart Het hoofddoel van deze fase is het representeren van willekeurige invoergegevens in de vorm van tussenliggende sleutel-waardeparen die een bepaalde betekenis hebben en geformaliseerd zijn. De resultaten worden gesorteerd en gegroepeerd op sleutel, en vervolgens overgebracht naar de volgende fase. Verminderen Ontvangen na kaart de waarden worden gebruikt voor de uiteindelijke berekening van de benodigde totalen.

Elke fase van elke specifieke berekening wordt geïmplementeerd als een onafhankelijke mini-applicatie. Deze aanpak maakt een vrijwel onbeperkte parallellisatie van berekeningen op een groot aantal machines mogelijk, waardoor u in een mum van tijd volumes van vrijwel willekeurige gegevens kunt verwerken. Het enige wat u hoeft te doen is deze applicaties tegelijkertijd op elke beschikbare server te laten draaien en vervolgens alle resultaten bij elkaar te verzamelen.

Een voorbeeld van een kant-en-klaar raamwerk voor het implementeren van gegevensverwerking volgens dit principe is het opensource-project van de Apache Foundation, waar ik al meerdere keren over heb gesproken en zelfs ooit over heb geschreven.

In plaats van een conclusie

Eerlijk gezegd vind ik het moeilijk te geloven dat ik zo’n uitgebreid bericht heb kunnen schrijven en bijna geen energie meer had om het samen te vatten. Ik zou alleen willen zeggen dat bij de ontwikkeling van grote projecten elk detail belangrijk is, en dat een onopgemerkt detail tot mislukking kan leiden. Daarom moet je in deze kwestie niet leren van je eigen fouten, maar van anderen.

Hoewel deze tekst er misschien uitziet als een soort generalisatie van alle berichten in de serie, is het onwaarschijnlijk dat dit het laatste punt zal worden. Ik hoop dat ik in de toekomst iets over dit onderwerp zal zeggen, misschien zal het ooit gebaseerd zijn op persoonlijke ervaring, en niet alleen het resultaat zijn van het verwerken van de massa informatie die ik ontving. Wie weet?...

Schaalbaarheid is een eigenschap van een computersysteem dat voorspelbare groei in systeemkenmerken biedt, bijvoorbeeld het aantal ondersteunde gebruikers, reactiesnelheid, algehele prestaties, enz., wanneer er computerbronnen aan worden toegevoegd. In het geval van een DBMS-server kunnen twee schaalmethoden worden overwogen: verticaal en horizontaal (Fig. 2).

Met horizontale schaling neemt het aantal DBMS-servers toe, die mogelijk transparant met elkaar communiceren en zo de totale systeembelasting delen. Deze oplossing zal waarschijnlijk steeds populairder worden naarmate de ondersteuning voor losjes gekoppelde architecturen en gedistribueerde databases groeit, maar is doorgaans moeilijk te beheren.

Verticale schaalvergroting omvat het vergroten van de kracht van een afzonderlijke DBMS-server en wordt bereikt door hardware (processor, schijven) te vervangen door snellere of door extra knooppunten toe te voegen. Een goed voorbeeld is de toename van het aantal processors in symmetrische multiprocessor (SMP) platforms. In dit geval mag de serversoftware niet worden gewijzigd (in het bijzonder kan de aanschaf van extra modules niet vereist zijn), omdat dit de complexiteit van het beheer zou vergroten en de voorspelbaarheid van het systeemgedrag zou verslechteren. Ongeacht welke schaalmethode wordt gebruikt, de winst wordt bepaald door hoe volledig de serverprogramma's de beschikbare computerbronnen gebruiken. Bij verdere beoordelingen zullen we rekening houden met verticale schaalvergroting, die volgens analisten de grootste groei doormaakt op de moderne computermarkt.

De schaalbaarheidseigenschap is om twee belangrijke redenen relevant. In de eerste plaats veranderen de moderne zakelijke omstandigheden zo snel dat langetermijnplanning, die een uitgebreide en langdurige analyse van reeds verouderde gegevens vereist, onmogelijk wordt, zelfs voor organisaties die het zich kunnen veroorloven. In ruil daarvoor komt een strategie om geleidelijk, stap voor stap, de kracht van informatiesystemen te vergroten. Aan de andere kant leiden veranderingen in de technologie tot de opkomst van steeds meer nieuwe oplossingen en lagere hardwareprijzen, wat de architectuur van informatiesystemen potentieel flexibeler maakt. Tegelijkertijd nemen de interoperabiliteit en openheid van software- en hardwareproducten van verschillende fabrikanten toe, hoewel hun inspanningen om aan de normen te voldoen tot nu toe slechts in beperkte sectoren van de markt zijn gecoördineerd. Zonder rekening te houden met deze factoren zal de consument niet kunnen profiteren van nieuwe technologieën zonder dat hij geld bevriest dat is geïnvesteerd in technologieën die niet open genoeg zijn of weinig belovend zijn gebleken. Op het gebied van dataopslag en -verwerking vereist dit dat zowel het DBMS als de server schaalbaar zijn. Tegenwoordig zijn de belangrijkste schaalbaarheidsparameters:

• ondersteuning voor multiverwerking;
• architectonische flexibiliteit.

Multiprocessorsystemen

Voor verticale schaalvergroting worden steeds vaker symmetrische multiprocessor (SMP)-systemen gebruikt, omdat het in dit geval niet nodig is om het platform te veranderen, d.w.z. besturingssysteem, hardware en beheervaardigheden. Voor dit doel is het ook mogelijk om systemen met massief parallellisme (MPP) te gebruiken, maar tot nu toe is het gebruik ervan beperkt tot speciale taken, bijvoorbeeld computationele taken. Bij het evalueren van een DBMS-server met een parallelle architectuur is het raadzaam om aandacht te besteden aan twee hoofdkenmerken van de uitbreidbaarheid van de architectuur: geschiktheid en transparantie.

De adequaatheidseigenschap vereist dat de serverarchitectuur in gelijke mate één of tien processors ondersteunt zonder herinstallatie of significante wijzigingen in de configuratie, evenals aanvullende softwaremodules. Een dergelijke architectuur zal even nuttig en effectief zijn, zowel in een systeem met één processor als, naarmate de complexiteit van de op te lossen taken toeneemt, op meerdere of zelfs meerdere (MPP) processors. Over het algemeen hoeft de consument geen nieuwe softwareopties aan te schaffen of te leren.

Het bieden van transparantie aan de serverarchitectuur maakt het op zijn beurt mogelijk om wijzigingen in de hardwareconfiguratie voor applicaties te verbergen. garandeert portabiliteit van applicatiesoftwaresystemen. Met name in nauw gekoppelde multiprocessor-architecturen kan de applicatie via een gedeeld geheugensegment met de server communiceren, terwijl in losjes gekoppelde multiserversystemen (clusters) voor dit doel een berichtenmechanisme kan worden gebruikt. De applicatie mag geen rekening houden met de implementatiemogelijkheden van de hardwarearchitectuur - de methoden voor gegevensmanipulatie en de software-interface voor toegang tot de database moeten hetzelfde en even effectief blijven.

Hoogwaardige ondersteuning voor multiprocessing vereist dat de databaseserver in staat is om onafhankelijk de uitvoering van veel te bedienen queries te plannen, wat de meest volledige verdeling van de beschikbare computerbronnen tussen servertaken zou garanderen. Verzoeken kunnen opeenvolgend worden verwerkt door verschillende taken of worden onderverdeeld in subtaken, die op hun beurt parallel kunnen worden uitgevoerd (figuur 3). Dit laatste is optimaal omdat een juiste implementatie van dit mechanisme voordelen biedt die onafhankelijk zijn van verzoektypen en applicaties. De verwerkingsefficiëntie wordt sterk beïnvloed door het granulariteitsniveau van de bewerkingen die door de plannertaak worden overwogen. Met grove granulariteit, bijvoorbeeld op het niveau van individuele SQL-query's, zal de verdeling van computersysteembronnen (processors, geheugen, schijven) niet optimaal zijn - de taak zal inactief zijn en wachten op het einde van de noodzakelijke I/O-bewerkingen om de SQL-query te voltooien, tenminste in de wachtrij voor Er waren andere query's die aanzienlijk rekenwerk vereisten. Met een fijnere granulariteit vindt het delen van bronnen zelfs binnen één enkele SQL-query plaats, wat nog duidelijker wordt wanneer meerdere query's parallel worden verwerkt. Het gebruik van een planner zorgt ervoor dat grote systeembronnen worden gebruikt om de daadwerkelijke databaseonderhoudstaken op te lossen en de downtime tot een minimum beperkt.

Architecturale flexibiliteit

Ongeacht de mate van draagbaarheid, ondersteuning voor standaarden, parallellisme en andere nuttige kwaliteiten, kunnen de prestaties van een DBMS, dat aanzienlijke ingebouwde architecturale beperkingen heeft, niet vrijelijk worden verhoogd. De aanwezigheid van gedocumenteerde of praktische beperkingen op het aantal en de grootte van databaseobjecten en geheugenbuffers, het aantal gelijktijdige verbindingen, de recursiediepte van aanroepprocedures en subquery's of het afvuren van databasetriggers is dezelfde beperking op de toepasbaarheid van het DBMS, zoals , bijvoorbeeld de onmogelijkheid om over te zetten naar verschillende computerplatforms. De parameters die de complexiteit van databasequery's beperken, vooral de grootte van dynamische buffers en de stapelgrootte voor recursieve oproepen, moeten dynamisch configureerbaar zijn en vereisen niet dat het systeem wordt gestopt voor herconfiguratie. Het heeft geen zin om een ​​krachtige nieuwe server aan te schaffen als de verwachtingen niet kunnen worden waargemaakt vanwege de interne beperkingen van het DBMS.

Het knelpunt is doorgaans het onvermogen om de kenmerken van databaseserverprogramma's dynamisch aan te passen. Mogelijkheid om on-the-fly parameters te bepalen, zoals de hoeveelheid verbruikt geheugen, het aantal drukke processors, het aantal parallelle taakthreads (of het nu echte threads, besturingssysteemprocessen of virtuele processors zijn) en het aantal fragmenten van databasetabellen en indexen, evenals hun distributie op fysieke schijven ZONDER het systeem te stoppen en opnieuw op te starten, is een vereiste die voortkomt uit de essentie van moderne applicaties. Idealiter zou elk van deze parameters dynamisch kunnen worden gewijzigd binnen gebruikersspecifieke grenzen.

Naarmate de populariteit van een webapplicatie groeit, begint de ondersteuning ervan onvermijdelijk steeds meer middelen te vergen. In eerste instantie kan (en moet) de belasting worden aangepakt door de algoritmen en/of architectuur van de applicatie zelf te optimaliseren. Maar wat te doen als alles wat geoptimaliseerd kan worden al geoptimaliseerd is, maar de applicatie de belasting nog steeds niet aankan?

Optimalisatie

Het eerste dat u moet doen, is gaan zitten en bedenken of u alles al heeft kunnen optimaliseren:

• Zijn databasequery's optimaal (EXPLAIN-analyse, gebruik van indexen)?
• worden de gegevens correct opgeslagen (SQL versus NoSQL)?
• wordt er gebruik gemaakt van caching?
• Zijn er onnodige zoekopdrachten naar het bestandssysteem of de database?
• Zijn algoritmen voor gegevensverwerking optimaal?
• Zijn de omgevingsinstellingen optimaal: Apache/Nginx, MySQL/PostgreSQL, PHP/Python?

Over elk van deze punten zou een afzonderlijk artikel kunnen worden geschreven, dus een gedetailleerde beschouwing ervan in het kader van dit artikel is duidelijk overbodig. Het is alleen belangrijk om te begrijpen dat voordat u begint met het schalen van een applicatie, het zeer wenselijk is om de werking ervan zoveel mogelijk te optimaliseren - misschien is dan misschien geen schaalvergroting nodig.

Schalen

En dus, laten we zeggen dat de optimalisatie al is uitgevoerd, maar de applicatie kan de belasting nog steeds niet aan. In dit geval kan de oplossing voor het probleem uiteraard zijn om het over verschillende hosts te verdelen om de algehele prestaties van de applicatie te verbeteren door de beschikbare bronnen te vergroten. Deze aanpak heeft de officiële naam: de applicatie ‘schalen’. Preciezer gezegd verwijst ‘schaalbaarheid’ naar het vermogen van een systeem om zijn prestaties te verbeteren naarmate het aantal toegewezen bronnen toeneemt. Er zijn twee schaalmethoden: verticaal en horizontaal. Verticale schaling impliceert een toename van de applicatieprestaties bij het toevoegen van bronnen (processor, geheugen, schijf) binnen één knooppunt (host). Horizontaal schalen is typisch voor gedistribueerde applicaties en impliceert een toename van de applicatieprestaties bij het toevoegen van een ander knooppunt (host).

Het is duidelijk dat de eenvoudigste manier zou zijn om simpelweg de hardware (processor, geheugen, schijf) bij te werken - dat wil zeggen verticale schaalvergroting. Bovendien vereist deze aanpak geen aanpassingen aan de applicatie. Het verticaal schalen bereikt echter al snel zijn limiet, waarna de ontwikkelaar en beheerder geen andere keuze hebben dan over te gaan tot horizontaal schalen van de applicatie.

Applicatie architectuur

De meeste webapplicaties zijn a priori gedistribueerd, omdat er in hun architectuur minstens drie lagen kunnen worden onderscheiden: webserver, bedrijfslogica (applicatie), data (database, statisch).

Elk van deze lagen kan worden geschaald. Daarom, als in uw systeem de applicatie en de database op dezelfde host staan, zou de eerste stap natuurlijk moeten zijn om ze over verschillende hosts te distribueren.

Knelpunt

Wanneer u begint met het schalen van het systeem, is de eerste stap het bepalen welke laag het “knelpunt” is; dat wil zeggen dat deze langzamer werkt dan de rest van het systeem. Om te beginnen kun je banale hulpprogramma's zoals top (htop) gebruiken om het processor-/geheugenverbruik te schatten en df, iostat om het schijfverbruik te schatten. Het is echter raadzaam om een ​​aparte host toe te wijzen met gevechtsbelastingemulatie (met behulp van of JMeter), waarop het mogelijk is om de werking van de applicatie te profileren met behulp van hulpprogramma's zoals xdebug, enzovoort. Om beperkte zoekopdrachten in de database te identificeren, kunt u hulpprogramma's zoals pgFouine gebruiken (het is duidelijk dat het beter is om dit te doen op basis van logbestanden van de productieserver).

Het hangt meestal af van de architectuur van de applicatie, maar de meest waarschijnlijke kandidaten voor een knelpunt in het algemeen zijn de database en de code. Als uw applicatie met een grote hoeveelheid gebruikersgegevens werkt, zal de bottleneck waarschijnlijk statische opslag zijn.

Schalen van databases

Zoals hierboven vermeld, is de database vaak het knelpunt in moderne toepassingen. Problemen ermee zijn meestal onderverdeeld in twee klassen: prestaties en de noodzaak om een ​​grote hoeveelheid gegevens op te slaan.

U kunt de belasting van de database verminderen door deze over meerdere hosts te verspreiden. Tegelijkertijd wordt het probleem van de synchronisatie daartussen acuut, wat kan worden opgelost door een master/slave-schema met synchrone of asynchrone replicatie te implementeren. In het geval van PostgreSQL kunt u synchrone replicatie implementeren met Slony-I, en asynchrone replicatie met PgPool-II of WAL (9.0). Het probleem van het scheiden van lees- en schrijfverzoeken, evenals het verdelen van de belasting tussen bestaande slaven, kan worden opgelost door een speciale databasetoegangslaag (PgPool-II) op te zetten.

Het probleem van het opslaan van grote hoeveelheden gegevens bij het gebruik van relationele DBMS's kan worden opgelost met behulp van het partitioneringsmechanisme ("partitionering" in PostgreSQL), of door databases in te zetten op gedistribueerde bestandssystemen zoals Hadoop DFS.

Voor het opslaan van grote hoeveelheden gegevens is data-sharding echter de beste oplossing, wat een ingebouwd voordeel is van de meeste NoSQL-databases (bijvoorbeeld MongoDB).

Bovendien werken NoSQL-databases over het algemeen sneller dan hun SQL-broers vanwege het ontbreken van overhead voor het parseren/optimaliseren van query's, het controleren van de integriteit van de datastructuur, enz. Het onderwerp van het vergelijken van relationele en NoSQL-databases is ook behoorlijk uitgebreid en verdient het.

Afzonderlijk is het de moeite waard om de ervaring van Facebook te vermelden, die MySQL gebruikt zonder JOIN-selecties. Deze strategie stelt hen in staat de database veel gemakkelijker te schalen, terwijl de belasting van de database wordt overgebracht naar de code, die, zoals hieronder zal worden beschreven, gemakkelijker schaalt dan de database.

Codeschaling

De moeilijkheid bij het schalen van code hangt af van het aantal gedeelde bronnen dat de hosts nodig hebben om uw applicatie uit te voeren. Zullen het alleen sessies zijn, of zijn er gedeelde cache en bestanden nodig? In ieder geval is de eerste stap het draaien van kopieën van de applicatie op meerdere hosts met dezelfde omgeving.

Vervolgens moet u de taak-/verzoekverdeling tussen deze hosts configureren. Dit kan zowel op TCP-niveau (haproxy), als op HTTP (nginx) of DNS.

De volgende stap is ervoor te zorgen dat statische bestanden, cache en webapplicatiesessies op elke host beschikbaar zijn. Voor sessies kunt u een server gebruiken die over het netwerk draait (bijvoorbeeld memcached). Het is heel redelijk om dezelfde memcached als cacheserver te gebruiken, maar uiteraard op een andere host.

Statische bestanden kunnen worden aangekoppeld vanuit een gedeelde bestandsopslag via NFS/CIFS of met behulp van een gedistribueerd bestandssysteem (HDFS, GlusterFS, Ceph).

U kunt ook bestanden opslaan in een database (bijvoorbeeld Mongo GridFS), waardoor de problemen van beschikbaarheid en schaalbaarheid worden opgelost (rekening houdend met het feit dat voor NoSQL-databases het schaalbaarheidsprobleem wordt opgelost door sharding).

Afzonderlijk is het de moeite waard om het probleem van de implementatie op meerdere hosts te vermelden. Hoe kan ik ervoor zorgen dat de gebruiker, wanneer hij op “Update” klikt, geen verschillende versies van de applicatie te zien krijgt? De eenvoudigste oplossing zou naar mijn mening zijn om niet-bijgewerkte hosts uit te sluiten van de load balancer-configuratie (webserver) en ze opeenvolgend in te schakelen zodra ze worden bijgewerkt. U kunt gebruikers ook aan specifieke hosts koppelen via cookies of IP. Als de update aanzienlijke wijzigingen in de database vereist, is de eenvoudigste manier om het project tijdelijk helemaal te sluiten.

FS-schaling

Als het nodig is om een ​​grote hoeveelheid statische gegevens op te slaan, kunnen er twee problemen worden geïdentificeerd: gebrek aan ruimte en snelheid van gegevenstoegang. Zoals hierboven al geschreven, kan het probleem van ruimtegebrek op minstens drie manieren worden opgelost: een gedistribueerd bestandssysteem, gegevens opslaan in een database met ondersteuning voor sharding, en sharding “handmatig” organiseren op codeniveau.

Het moet duidelijk zijn dat het verspreiden van statische elektriciteit ook niet de gemakkelijkste taak is als het gaat om hoge belastingen. Daarom is het heel redelijk om veel servers te hebben die zich toeleggen op het distribueren van statische bestanden. Bovendien, als we een gedeelde gegevensopslag hebben (gedistribueerd bestandssysteem of database), kunnen we bij het opslaan van een bestand de naam ervan opslaan zonder rekening te houden met de host, en de hostnaam willekeurig vervangen bij het genereren van de pagina (de belasting willekeurig verdelen tussen webservers die statische bestanden distribueren). In het geval dat sharding handmatig wordt geïmplementeerd (dat wil zeggen dat de logica in de code verantwoordelijk is voor het kiezen van de host waarnaar de gegevens worden geüpload), moet informatie over de uploadhost worden berekend op basis van het bestand zelf, of worden gegenereerd op basis van op derde gegevens (informatie over de gebruiker, hoeveelheid ruimte op opslagschijven) en samen met de bestandsnaam opgeslagen in de database.

Toezicht

Het is duidelijk dat een groot en complex systeem constante monitoring vereist. De oplossing is naar mijn mening hier standaard: zabbix, dat de belasting/werking van systeemknooppunten bewaakt en controleert op daemons voor back-up.

Conclusie

Het bovenstaande bespreekt kort vele opties voor het oplossen van de problemen bij het schalen van een webapplicatie. Elk van hen heeft zijn eigen voor- en nadelen. Er is geen recept om alles goed en in één keer te doen - voor elke taak zijn er veel oplossingen met hun eigen voor- en nadelen. Welke u kiest, is aan u.

Enz., als ze de mogelijkheid nodig hebben om onder zware belasting te werken. Het systeem wordt gebeld schaalbaar, als het in staat is de productiviteit te verhogen in verhouding tot de extra middelen. Schaalbaarheid kan worden beoordeeld aan de hand van de verhouding tussen de toename van de systeemprestaties en de toename van de gebruikte bronnen. Hoe dichter deze verhouding bij één ligt, hoe beter. Schaalbaarheid betekent ook de mogelijkheid om extra bronnen te vergroten zonder structurele veranderingen aan het centrale knooppunt van het systeem.

In een systeem met slechte schaalbaarheid leidt het toevoegen van bronnen slechts tot een kleine prestatieverbetering, en na een bepaald “drempelpunt” heeft het toevoegen van bronnen geen enkel gunstig effect.

Verticale schaling

Het verhogen van de prestaties van elk systeemonderdeel om de algehele prestaties te verbeteren.

Horizontale schaling

Het systeem opsplitsen in kleinere structurele componenten en deze verdelen over afzonderlijke fysieke machines (of groepen daarvan) en/of het aantal servers vergroten dat dezelfde functie parallel uitvoert.

Opmerkingen

Zie ook

Koppelingen

Stichting Wikimedia.

2010.

schaalbaarheid Kijk wat "Schaalbaarheid" is in andere woordenboeken:

schaalbaarheid- uitbreidbaarheid Het kenmerk van een applicatie die op verschillende platforms draait en in grootte varieert (bijvoorbeeld op een pc met Windows en op een Sun-werkstation met Unix). Voor hardware: voorspelbare groei in systeemprestaties met... ... - 3.1.43 schaalbaarheid: de mogelijkheid om functionaliteit te bieden op en neer binnen een geordende reeks applicatieplatforms die variëren in snelheid en middelen. Bron …

Woordenboek-naslagwerk met termen van normatieve en technische documentatie Het vermogen van software om correct te werken op kleine en grote systemen, met prestaties die toenemen in verhouding tot de verwerkingskracht van het systeem. In het Engels: Schaalbaarheid Zie ook: Open systemen Software…

Financieel woordenboek systeemschaalbaarheid (in SCADA) - systeemschaalbaarheid [Intent] Systeemschaalbaarheid. Dit betekent dat het ontwikkelde project kan worden getest op één computer of een klein netwerk en vervolgens het systeem kan uitbreiden (conform het ontwikkelprogramma, budget, etc.) zonder... ...

Handleiding voor technische vertalers schaalbaarheid (in informatietechnologie) - systeemschaalbaarheid [Intent] Systeemschaalbaarheid. Dit betekent dat het ontwikkelde project kan worden getest op één computer of een klein netwerk en vervolgens het systeem kan uitbreiden (conform het ontwikkelprogramma, budget, etc.) zonder... ...

- Het vermogen van een IT-dienst, proces, configuratie-item, etc. om de eerder overeengekomen functie uit te voeren wanneer de werklast of omvang verandert. [ITIL Verklarende woordenlijst versie 1.0, 29 juli 2011] NL schaalbaarheid Het vermogen van een IT... ... schaalbaarheid (applicaties) - systeemschaalbaarheid [Intent] Systeemschaalbaarheid. Dit betekent dat het ontwikkelde project kan worden getest op één computer of een klein netwerk en vervolgens het systeem kan uitbreiden (conform het ontwikkelprogramma, budget, etc.) zonder... ...

- schaalbaarheid uitbreidbaarheid Kenmerken van een applicatie die op verschillende platforms draait en in grootte varieert (bijvoorbeeld op een pc onder Windows en op een Sun-werkstation onder Unix). Voor hardware: voorspelbare groei in systeem... ... schaalbaarheid (netwerken en communicatiesystemen) - systeemschaalbaarheid [Intent] Systeemschaalbaarheid. Dit betekent dat het ontwikkelde project kan worden getest op één computer of een klein netwerk en vervolgens het systeem kan uitbreiden (conform het ontwikkelprogramma, budget, etc.) zonder... ...

- Een criterium voor een kosteneffectief automatiseringssysteem voor onderstations, waarbij rekening wordt gehouden met verschillende functionele kenmerken, verschillende intelligente elektronische apparaten, de grootte van het onderstation en het spanningsbereik van het onderstation. [GOST R 54325 2011... ... Breed schaalbaar - systeemschaalbaarheid [Intent] Systeemschaalbaarheid. Dit betekent dat het ontwikkelde project kan worden getest op één computer of een klein netwerk en vervolgens het systeem kan uitbreiden (conform het ontwikkelprogramma, budget, etc.) zonder... ...

- - [L.G. Sumenko. Engels-Russisch woordenboek over informatietechnologie. M.: State Enterprise TsNIIS, 2003.] Onderwerpen informatietechnologie in het algemeen EN terabyte schaalbaarheid ... horizontale schaalbaarheid - systeemschaalbaarheid [Intent] Systeemschaalbaarheid. Dit betekent dat het ontwikkelde project kan worden getest op één computer of een klein netwerk en vervolgens het systeem kan uitbreiden (conform het ontwikkelprogramma, budget, etc.) zonder... ...

- Vergroten van de systeemcapaciteit door knooppunten aan het cluster toe te voegen.- een van de basisprincipes van het bouwen van open systemen, garandeert het behoud van investeringen in informatie en software bij de overstap naar een krachtiger hardwareplatform... E-Business woordenboek

Boeken

• Microsoft SharePoint 2010. The Complete Guide, A. Morgunova, Colin Spence, Michael Noel, Y. Volkova, Het boek behandelt alle nieuwe functies van SharePoint - van nieuwe componenten voor sociale netwerken tot verbeterde zoekmogelijkheden - waarmee u het meeste uit beide kunt halen SharePoint... Categorie: Computertechnologie Uitgever: Williams,
• Orakel Kern. Interne structuur voor beheerders en dataontwikkelaars, Lewis Jonathan, In dit boek geeft de auteur alleen de meest noodzakelijke informatie over de interne structuur van het Oracle DBMS, die elke databasebeheerder zou moeten kennen om succesvol om te kunnen gaan met ... Categorie:

Het vermogen om een ​​informatiesysteem te schalen – zowel horizontaal als verticaal – is een van de belangrijkste factoren waar u op moet letten bij het kiezen van een manier om de activiteiten van elke organisatie te automatiseren. Als de gekozen oplossing niet kan worden geschaald, of elke fase van de bedrijfsgroei zal leiden tot problemen met het onderhoud en de ontwikkeling van een dergelijk softwareproduct, dan moet u het niet eens gaan gebruiken. We hebben het LETOGRAF EDMS ontwikkeld rekening houdend met hoge schaalvereisten.

De behoefte aan horizontale of verticale schaalvergroting ontstaat in verband met de creatie van zwaarbelaste IT-systemen van bedrijven die duizenden of zelfs tienduizenden gebruikers in dienst hebben. Niet alle EDMS kunnen echter de gelijktijdige werking van een groot aantal gebruikers ondersteunen. Alleen als het EDMS op architectonisch niveau de mogelijkheid bevat om het aantal gebruikers te vergroten zonder prestatieverlies - alleen in dit geval zal de schaalvergroting succesvol zijn. Het LETOGRAF-systeem dat we hebben gemaakt, is ontworpen om zowel horizontaal als verticaal ideaal schaalbaar te zijn. Dit wordt zowel bereikt door de architectuur van het systeem zelf en de applicatiecode die we hebben ontwikkeld, als door de functionaliteit van het InterSystems Caché DBMS, waarop ons EDMS is gebouwd.

Caché DBMS is een modern databasebeheersysteem en omgeving voor snelle applicatieontwikkeling. Dit DBMS is gebaseerd op technologie die snelheid en hoge prestaties, schaalbaarheid en betrouwbaarheid biedt. Tegelijkertijd blijven de hardwarevereisten van het systeem vrij bescheiden.

Het Caché DBMS behoudt hoge prestaties, zelfs bij het werken met grote hoeveelheden gegevens en een groot aantal servers in gedistribueerde systemen. In dit geval worden gegevens benaderd via objecten, krachtige SQL-query's en via directe verwerking van multidimensionale datastructuren.

Verticale schaling

Bij verticale schaalvergroting gaat het om het vergroten van de kracht van de server en de mogelijkheden die verband houden met het schijfsubsysteem. LETOGRAF ondersteunt moderne processorarchitectuur, waarmee u grote hoeveelheden gegevens in meerdere threads kunt verwerken. Tegelijkertijd zijn de gegevens zelf in het EDMS zo georganiseerd dat ze eenvoudig over het opslagsysteem naar verschillende schijven kunnen worden gedistribueerd. Met deze aanpak kunt u de belasting van de gegevensopslag gelijkmatig verdelen en minimaliseren wanneer u gegevens rechtstreeks uit de database leest, wat betekent dat een daling van de systeemprestaties kan worden voorkomen, zelfs als een groot aantal gebruikers tegelijkertijd werkt.

Zelfs in de ontwikkelingsfase van het platform begrepen we dat verticale schaalvergroting een van de belangrijkste mogelijkheden van het systeem is, waarvan de behoefte in de loop van de tijd alleen maar zal toenemen. We hebben het systeem zo ontwikkeld dat de werkprocessen van elke gebruiker werden gescheiden in afzonderlijke systeemprocessen die elkaar niet kruisen, omdat de databases effectief de toegang tot informatie delen. Tegelijkertijd wordt het aantal datalocks in het LETOGRAF EDMS geminimaliseerd en is er geen knelpunt bij het lezen of schrijven van gegevens.

Dankzij de architectuur van EDMS LETOGRAF kunt u gegevens distribueren over verschillende fysieke of virtuele servers. Dankzij deze distributie werkt elke gebruiker in een geïsoleerd proces en worden de vereiste gegevens efficiënt in de cache opgeslagen met behulp van Caché DBMS-technologieën. De vergrendelingstijd van gegevens wordt geminimaliseerd: alle transacties zijn zo gestructureerd dat gegevens slechts voor een zeer korte tijd in de exclusieve toegangsmodus worden gezet. Tegelijkertijd worden zelfs zulke zwaarbeladen gegevens in termen van het aantal schijftoegangen, zoals logs, indexen, objectgegevens, streams en logs van gebruikersacties, zo verdeeld dat de gemiddelde belasting van het subsysteem uniform blijft en leidt niet tot vertragingen. Met deze aanpak kunt u het systeem effectief verticaal schalen, waarbij de belasting wordt verdeeld over servers of virtuele schijven.

Horizontale schaling

Horizontaal schalen is de distributie van gebruikerssessies over verschillende servers (zelfs het laden van applicatieservers en de mogelijkheid om extra applicatieservers aan te sluiten), evenals de distributie van gegevens over verschillende databaseservers, wat hoge systeemprestaties garandeert zonder de fouttolerantie te verminderen. Voor horizontaal schalen biedt het LETOGRAF-systeem een ​​aantal mogelijkheden.

Allereerst is dit load-scaling dankzij het Enterprise Cache Protocol (ECP, gedistribueerd cacheprotocol), het protocol dat wordt gebruikt in het InterSystems Caché DBMS. Het voordeel van ECP is de innovatieve benadering van datacaching. Onder dit protocol krijgen gebruikersprocessen die draaien op applicatieservers (of ECP-clients) van het DBMS en die query's bedienen, toegang tot een lokale cache met recent gebruikte gegevens. En alleen als deze gegevens niet voldoende zijn, krijgt de ECP-client toegang tot de database. ECP voert automatisch cachebeheer uit: de meest gebruikte gegevens worden in de cache opgeslagen en regelmatig bijgewerkte gegevens worden periodiek gerepliceerd, waardoor de gegevensintegriteit en correctheid voor alle ECP-clients te allen tijde wordt gegarandeerd. In dit geval gaat het interne InterSystems Caché-algoritme ervan uit dat de databases zijn gesynchroniseerd tussen de ECP-client en de ECP-server.

Dankzij het gebruik van Caché DBMS-technologieën kunt u de belasting eenvoudig en snel over de applicatieservers schalen, waardoor de verbinding van een groot aantal gebruikers met één databaseserver wordt gegarandeerd door het gebruik van het ECP-protocol.

Omdat de door een bepaalde gebruiker opgevraagde informatie op meerdere ECP-clients kan worden gebruikt, is het noodzakelijk om de gegevens voor een korte periode te blokkeren en snel transacties uit te voeren zonder interne berekeningen uit te voeren. En we hebben het met succes geïmplementeerd. Met deze technologie kunnen we het systeem effectief schalen in een situatie waarin één databaseserver en meerdere servers waarop gebruikersprocessen worden uitgevoerd, worden gebruikt. Het technologische kenmerk van het Caché DBMS is dat het de juistheid van transacties binnen één ECP-server handhaaft, ongeacht het aantal ECP-clients dat erop is aangesloten. In het geval dat we één ECP-server en veel ECP-clients hebben, is dit probleem perfect opgelost, omdat alle transacties plaatsvinden op één databaseserver.

De ervaring leert dat het zelfs in zwaarbelaste systemen altijd mogelijk is om gegevens tussen databaseservers duidelijk te scheiden op basis van bepaalde kenmerken. Als meerdere organisaties bijvoorbeeld verenigd zijn in een holding, is het onwaarschijnlijk dat gebruikers van de ene structurele eenheid ooit gegevens nodig hebben die betrekking hebben op een andere eenheid. Dit maakt het op algoritmeniveau mogelijk om dergelijke gegevens te scheiden en op verschillende databaseservers op te slaan, waardoor de mogelijkheid van horizontale schaalvergroting wordt vergroot.

EDMS LETOGRAF implementeert een sharding-mechanisme, waardoor we het op het niveau van systeeminstellingen (zonder het gebruik van programmering) mogelijk maken om de regels en principes te beschrijven van het distribueren van de gegevens zelf over verschillende databaseservers. Ondanks het feit dat, vanuit het oogpunt van de databasestructuur, de informatie die op elke server is opgeslagen hetzelfde is, verschilt de informatie zelf fundamenteel, afhankelijk van de organisatie of andere kenmerken die van belang zijn voor een bepaalde taak. Met behulp van sharding-technologie is het mogelijk om te bereiken dat gebruikers in 95-99% van de gevallen alleen met hun ‘gegevensgedeelte’ zullen werken en dat het niet nodig is om binnen een sessie toegang te krijgen tot verschillende databaseservers.

De schaalmogelijkheden van het LETOGRAF EDMS worden ook beïnvloed door het feit dat gegevens anders kunnen worden verwerkt. Er kunnen bijvoorbeeld wijzigingen worden aangebracht in documenten (zelfs documenten die enkele jaren geleden zijn gemaakt), maar vermeldingen kunnen alleen worden toegevoegd aan het gebruikersactiviteitenlogboek (geen enkele vermelding kan worden verwijderd of gewijzigd). De mechanismen die in het LETOGRAF EDMS worden gebruikt, maken het mogelijk om de systeemprestaties verder te verhogen en de schaalbaarheid te verbeteren door dergelijke logs op afzonderlijke databaseservers bij te houden - zowel in het geval van configuraties met één server als met configuraties met meerdere servers. Deze aanpak is gericht op het verminderen van de belasting van de belangrijkste databaseservers.

Een soortgelijke situatie doet zich voor met de inhoud (“informatie-inhoud” van het EDMS). Omdat het LETOGRAF-systeem met een grote hoeveelheid inhoud werkt - terabytes aan gegevens, miljoenen bestanden en documenten - is het redelijk om aan te nemen dat de inhoud die het systeem binnenkomt onder geen enkele omstandigheid mag worden beschadigd. Daarom verplaatsen we de bestandsopslag naar afzonderlijke databaseservers en zorgen zo voor extra horizontale schaling.

Front-endsoftware

Het LETOGRAF EDMS gebruikt Apache en HAProxy als front-end. HAProxy is verantwoordelijk voor de taakverdeling tussen Apache-webservers. HAProxy heeft zich, zoals de ervaring van het systeem heeft geleerd, bewezen als de meest effectieve oplossing die ondersteuning kan bieden aan een groot aantal gebruikers en de nodige controle over fouttolerantie.

Wanneer een gebruiker een browser opent en verbinding maakt met het systeem, ‘distribueert’ HAProxy deze naar een van de applicatieservers. Bovendien worden alle verzoeken die van deze gebruiker afkomstig zijn, in hetzelfde proces naar dezelfde applicatieserver verzonden.

We hebben verschillende systemen geprobeerd en uit tests is gebleken dat HAProxy de meest effectieve load balancer is, die een gelijkmatige verdeling van gebruikers over vrije slots van applicatieservers garandeert. HAProxy beschikt over alle noodzakelijke mechanismen om de status van elke applicatieserver te controleren en geen nieuw verkeer te distribueren naar een applicatieserver die om de een of andere reden uitvalt. Bovendien biedt HAProxy bovendien een aantal mogelijkheden op het gebied van het cachen van statische (onveranderlijke tijdens het werk van de gebruiker) gegevens - bijvoorbeeld stijlen, pictogrammen, enzovoort - waarmee u de interface kunt organiseren.

Voorbeeld van projectimplementatie

Met de LETOGRAF-architectuur kunt u significante resultaten bereiken door de responstijd te verkorten en de systeemprestaties te verhogen. Als onderdeel van een van onze projecten wordt 23,5 TB aan data opgeslagen in het EDMS. Hiervan zijn 14,7 TB (63%) streams (“bestanden die aan kaarten zijn gekoppeld”), 3,5 TB (15%) zijn rapportageformulieren, zoals rapporttabellen, die in asynchrone modus worden gegenereerd en zowel op schema als op het verzoek van de gebruiker en vertegenwoordigen een samenvattende tabel, waarin alle gegevens tot op het object kunnen worden gedetailleerd. Nog eens 1,6 TB (7%) bestaat uit het gebruikerstransactielogboek, en de rest (16%) bestaat uit kaartgegevens en indexen.

Dit systeem heeft meer dan 11.000 gebruikers in dienst, waarvan er 2.000 tegelijkertijd werken, en op piekdagen is het aantal werknemers dat tegelijkertijd in het EDMS werkt groter dan 3.000 registratiekaarten heeft bijna een half miljard bereikt.

In dit project wordt een fouttolerant cluster van twee fysieke servers met drie DBMS-installaties en een backupserver geïnstalleerd als databaseserver. Tien applicatieservers (en één back-up) verwerken gebruikerssessies en bieden asynchrone rapportage. 2 HAProxy-servers fungeren als balancers. Bij problemen met een van de servers wordt het IP-adres automatisch overgedragen naar een andere server. Er is ook een bestandsindexeringsserver en een herkenningsserver (die tekstherkenning biedt van gescande papieren documenten bij het plaatsen van elektronische afbeeldingen in het systeem).

Cv

EDMS LETOGRAF biedt een groot aantal verschillende schaalmechanismen. Wij bieden een soort taart aan, die gebaseerd is op een server (fysiek of virtueel) waarop het besturingssysteem is geïnstalleerd. Daarbovenop bevindt zich het InterSystems Caché DBMS, waarin de platformcode zich bevindt. En al daarboven bevinden zich de instellingen van het LETOGRAF-systeem, waardoor het EDMS volledig is geconfigureerd. En zo'n taart wordt op elke server geplaatst. Door de gekozen configuraties zijn de servers op een bepaalde manier met elkaar verbonden. En de laatste laag is HAProxy, dat gebruikersverzoeken tussen servers verdeelt. Deze architectuur stelt ons in staat schaalbaarheid te ondersteunen en alle noodzakelijke monitoringmechanismen te bieden. Het resultaat is dat eindgebruikers een snel werkend EDMS ontvangen en IT-specialisten een uniform systeem dat gemakkelijk te beheren en te onderhouden is, zonder een groot aantal componenten die, in het geval van zwaarbelaste applicaties, voortdurend moeten worden gemonitord en beheerd. . Bovendien kan het LETOGRAF EDMS, afhankelijk van de veranderende behoeften van de organisatie, eenvoudig opnieuw worden geconfigureerd door nieuwe servers of schijfmogelijkheden toe te voegen.

Dit materiaal is een privépost van een lid van de Club.CNews-gemeenschap.
De redactie van CNews is niet verantwoordelijk voor de inhoud ervan.