Op de een of andere manier is de IT-industrie historisch gezien om welke reden dan ook verdeeld in twee voorwaardelijke kampen: degenen die ‘voor’ zijn en degenen die ‘tegen’ zijn. Bovendien kan het onderwerp van geschillen volkomen willekeurig zijn. Welk besturingssysteem is beter: Win of Linux? Op een Android- of iOS-smartphone? Moet je alles in de cloud opslaan of op koude RAID-opslag zetten en de schroeven in een kluis steken? Hebben PHP-mensen het recht om programmeur genoemd te worden? Deze geschillen zijn soms uitsluitend existentieel van aard en hebben geen andere basis dan sportieve belangen.
Het gebeurde zo dat met de komst van containers en al deze geliefde gerechten met docker en voorwaardelijke k8's, de debatten 'voor' en 'tegen' het gebruik van nieuwe mogelijkheden op verschillende gebieden van de backend begonnen. (Laten we vooraf reserveren: hoewel Kubernetes in deze discussie meestal als orkestrator zal worden aangeduid, is de keuze voor dit specifieke hulpmiddel niet van fundamenteel belang. In plaats daarvan kunt u elk ander hulpmiddel vervangen dat u het handigst en vertrouwdst lijkt. .)
En het lijkt erop dat dit een eenvoudig geschil zou zijn tussen twee kanten van dezelfde medaille. Even zinloos en meedogenloos als de eeuwige confrontatie tussen Win en Linux, waarin adequate mensen ergens in het midden bestaan. Maar in het geval van containerisatie is niet alles zo eenvoudig. Meestal is er bij dergelijke geschillen geen goede kant, maar in het geval van 'gebruik' of 'niet gebruiken' containers voor het opslaan van databases staat alles op zijn kop. Want in zekere zin hebben zowel voor- als tegenstanders van deze aanpak gelijk.
Positieve kant
Het argument van de Light Side kan kort worden beschreven in één zin: “Hallo, 2k19 staat buiten het raam!” Het klinkt natuurlijk als populisme, maar als je de situatie gedetailleerd verdiept, heeft het zijn voordelen. Laten we ze nu uitzoeken.
Stel dat u een groot webproject heeft. Het had in eerste instantie kunnen worden gebouwd op basis van een microservice-aanpak, of op een gegeven moment via een evolutionair pad tot stand kunnen komen - dit is eigenlijk niet zo belangrijk. Je hebt ons project verdeeld over afzonderlijke microservices, de orkestratie, taakverdeling en schaalvergroting opgezet. En nu drink je met een zuiver geweten een mojito in een hangmat tijdens habra-effecten in plaats van gevallen servers op te tillen. Maar in alle acties moet je consistent zijn. Heel vaak is alleen de applicatie zelf (de code) gecontaineriseerd. Wat hebben we nog meer behalve code?
Dat klopt, gegevens. Het hart van elk project zijn de gegevens: dit kan een typisch DBMS zijn - MySQL, Postgre, MongoDB, of opslag die wordt gebruikt voor zoeken (ElasticSearch), sleutelwaardeopslag voor caching - bijvoorbeeld redis, enz. Momenteel zijn we dat niet we zullen het hebben over kromme backend-implementatieopties wanneer de database crasht als gevolg van slecht geschreven queries, en in plaats daarvan zullen we het hebben over het garanderen van de fouttolerantie van juist deze database onder clientbelasting. Wanneer we onze applicatie in een container plaatsen en deze vrij laten schalen om een willekeurig aantal inkomende verzoeken te verwerken, verhoogt dit uiteraard de belasting van de database.
In feite wordt het kanaal voor toegang tot de database en de server waarop deze draait het oog van de naald in onze prachtige gecontaineriseerde backend. Tegelijkertijd is de belangrijkste drijfveer van containervirtualisatie de mobiliteit en flexibiliteit van de structuur, waardoor we de verdeling van piekbelastingen over de gehele voor ons beschikbare infrastructuur zo efficiënt mogelijk kunnen organiseren. Dat wil zeggen: als we niet alle bestaande elementen van het systeem in een container plaatsen en over het hele cluster uitrollen, maken we een zeer ernstige fout.
Het is veel logischer om niet alleen de applicatie zelf te clusteren, maar ook de diensten die verantwoordelijk zijn voor het opslaan van gegevens. Door webservers te clusteren en in te zetten die onafhankelijk werken en de belasting onderling verdelen in k8s, lossen we het probleem van gegevenssynchronisatie al op - dezelfde opmerkingen over berichten, als we een media- of blogplatform als voorbeeld nemen. In ieder geval hebben we een intra-cluster, zelfs virtuele, representatie van de database als een ExterneService. De vraag is dat de database zelf nog niet is geclusterd: de webservers die in de kubus zijn ingezet, halen informatie over wijzigingen uit onze statische gevechtsdatabase, die afzonderlijk roteert.
Voel je een vangst? We gebruiken k8s of Swarm om de belasting te verdelen en te voorkomen dat de hoofdwebserver crasht, maar we doen dit niet voor de database. Maar als de database crasht, heeft onze hele geclusterde infrastructuur geen zin: wat heb je aan lege webpagina's die een databasetoegangsfout retourneren?
Daarom is het noodzakelijk om niet alleen de webservers te clusteren, zoals meestal wordt gedaan, maar ook de database-infrastructuur. Alleen zo kunnen we zorgen voor een structuur die volledig in één team werkt, maar tegelijkertijd onafhankelijk van elkaar. Bovendien zal de rest overleven, zelfs als de helft van onze backend onder belasting “instort”, en het systeem voor het synchroniseren van de databases met elkaar binnen het cluster en de mogelijkheid om eindeloos te schalen en nieuwe clusters te implementeren zullen helpen om snel de vereiste capaciteit te bereiken - Waren er maar racks in het datacenter.
Bovendien kunt u dankzij het in clusters gedistribueerde databasemodel deze database daar brengen waar hij nodig is; Als we het hebben over een mondiale dienst, dan is het volkomen onlogisch om ergens in de regio San Francisco een webcluster op te zetten en tegelijkertijd pakketten te verzenden bij toegang tot een database in de regio Moskou en terug.
Bovendien kunt u door de containerisatie van de database alle elementen van het systeem op hetzelfde abstractieniveau bouwen. Wat het op zijn beurt weer mogelijk maakt om dit systeem rechtstreeks vanuit code te beheren, door ontwikkelaars, zonder de actieve betrokkenheid van beheerders. De ontwikkelaars dachten dat er voor het nieuwe deelproject een apart DBMS nodig was - eenvoudig! schreef een yaml-bestand, uploadde het naar het cluster en je bent klaar.
En natuurlijk wordt de interne bediening aanzienlijk vereenvoudigd. Vertel eens, hoe vaak heb je je ogen gesloten toen een nieuw teamlid zijn handen in de gevechtsdatabase stak voor werk? Welke is in feite de enige die je hebt en die momenteel draait? Natuurlijk zijn we hier allemaal volwassenen, en ergens hebben we een verse back-up, en nog verder weg – achter de plank met oma’s komkommers en oude ski’s – nog een back-up, misschien zelfs in de koelcel, want jouw kantoor stond al een keer in brand. Maar toch is elke introductie van een nieuw teamlid met toegang tot de gevechtsinfrastructuur en natuurlijk tot de gevechtsdatabase een emmer validol voor iedereen in de buurt. Nou, wie kent hem, een nieuweling, misschien is hij crosshanded? Het is beangstigend, dat zult u met mij eens zijn.
Containerisatie en, in feite, de gedistribueerde fysieke topologie van de database van uw project helpt dergelijke validatiemomenten te voorkomen. Vertrouw je een newbie niet? OK! Laten we hem zijn eigen cluster geven om mee te werken en de database loskoppelen van de andere clusters - synchronisatie alleen door handmatig indrukken en synchrone rotatie van twee sleutels (één voor de teamleider, de andere voor de beheerder). En iedereen is blij.
En nu is het tijd om te veranderen in tegenstanders van databaseclustering.
Duistere kant
Als we beargumenteren waarom het niet de moeite waard is om de database in containers te stoppen en deze op één centrale server te blijven draaien, zullen we ons niet beperken tot de retoriek van orthodoxe ideeën en uitspraken als “grootvaders draaiden databases op hardware, en wij ook!” Laten we in plaats daarvan proberen een situatie te bedenken waarin containerisatie daadwerkelijk tastbare voordelen zou opleveren.
Mee eens, de projecten die echt een basis in een container nodig hebben, zijn door niet de beste freesmachine-operator op de vingers van één hand te tellen. Voor het grootste deel is zelfs het gebruik van k8s of Docker Swarm zelf overbodig - vaak wordt er gebruik gemaakt van deze tools vanwege de algemene hype van technologieën en de houding van de ‘almachtige’ in de persoon van de geslachten om alles in de kast te duwen. wolken en containers. Nou, omdat het nu in de mode is en iedereen het doet.
In zeker de helft van de gevallen is het gebruik van Kubernetis of alleen Docker op een project overbodig. Het probleem is dat niet alle teams of outsourcingbedrijven die zijn ingehuurd om de infrastructuur van de klant te onderhouden zich hiervan bewust zijn. Nog erger is het als er containers worden opgelegd, omdat dit de klant een bepaald aantal munten kost.
Over het algemeen is men van mening dat de docker/cube-maffia op domme wijze klanten verplettert die deze infrastructuurproblemen uitbesteden. Om met clusters te kunnen werken hebben we immers engineers nodig die daartoe in staat zijn en in grote lijnen de architectuur van de geïmplementeerde oplossing begrijpen. We hebben onze zaak ooit al beschreven in de Republic-publicatie - daar hebben we het team van de klant getraind om in de realiteit van Kubernetis te werken, en iedereen was tevreden. En het was redelijk. Vaak gijzelen k8s-‘implementanten’ de infrastructuur van de klant – omdat nu alleen zij begrijpen hoe alles daar werkt; er zijn geen specialisten aan de kant van de klant.
Stel je nu voor dat we op deze manier niet alleen het webservergedeelte, maar ook het databaseonderhoud uitbesteden. We zeiden dat BD het hart is, en het verlies van het hart is fataal voor elk levend organisme. Kortom: de vooruitzichten zijn niet best. Dus in plaats van de hype Kubernetis zouden veel projecten zich simpelweg niet moeten bezighouden met het normale tarief voor AWS, wat alle problemen met de belasting van hun site/project zal oplossen. Maar AWS is niet langer in de mode, en opschepperij is meer waard dan geld - helaas ook in de IT-omgeving.
OK. Misschien heeft het project echt clustering nodig, maar als alles duidelijk is met stateless applicaties, hoe kunnen we dan fatsoenlijke netwerkconnectiviteit organiseren voor een geclusterde database?
Als we het hebben over een naadloze technische oplossing, wat de transitie naar k8s inhoudt, dan is onze grootste hoofdpijn de gegevensreplicatie in een geclusterde database. Sommige DBMS'en zijn aanvankelijk behoorlijk loyaal aan de distributie van gegevens tussen hun individuele instanties. Vele anderen zijn niet zo gastvrij. En vaak is het belangrijkste argument bij het kiezen van een DBMS voor ons project niet de mogelijkheid om te repliceren met minimale resource- en engineeringkosten. Vooral als het project aanvankelijk niet als microservice was gepland, maar simpelweg in deze richting was geëvolueerd.
We denken dat het niet nodig is om over de snelheid van netwerkschijven te praten: ze zijn traag. Die. We hebben nog steeds geen echte mogelijkheid om, als er iets gebeurt, een DBMS-instantie ergens opnieuw op te starten waar er meer is, bijvoorbeeld processorkracht of vrij RAM-geheugen. We zullen zeer snel de prestaties van het gevirtualiseerde schijfsubsysteem tegenkomen. Dienovereenkomstig moet het DBMS worden vastgespijkerd aan zijn eigen persoonlijke set machines die zich in de directe nabijheid bevinden. Of het is noodzakelijk om op de een of andere manier een voldoende snelle gegevenssynchronisatie voor de veronderstelde reserves afzonderlijk af te koelen.
We gaan verder met het onderwerp virtuele bestandssystemen: Docker Volumes zijn helaas niet probleemloos. Over het algemeen zou ik, als het gaat om langdurige betrouwbare gegevensopslag, genoegen moeten nemen met de technisch meest eenvoudige schema's. En het toevoegen van een nieuwe abstractielaag van de FS van de container aan de FS van de bovenliggende host is op zichzelf een risico. Maar als de werking van het containerisatie-ondersteuningssysteem ook problemen ondervindt bij het verzenden van gegevens tussen deze lagen, dan is het echt een ramp. Op dit moment lijken de meeste problemen die de progressieve mensheid kent, uitgeroeid te zijn. Maar je begrijpt: hoe complexer het mechanisme, hoe gemakkelijker het kapot gaat.
In het licht van al deze ‘avonturen’ is het veel winstgevender en gemakkelijker om de database op één plek te houden, en zelfs als je de applicatie in een container moet plaatsen, laat hem dan zelfstandig draaien en ontvang via de distributiegateway gelijktijdige communicatie met de database, die slechts één keer en op één plek kan worden gelezen en geschreven. Deze aanpak reduceert de kans op fouten en desynchronisatie tot een minimum.
Waar leiden we naartoe? Bovendien is databasecontainerisatie geschikt als daar een reële behoefte aan is. Je kunt een volledige app-database niet vullen en draaien alsof je twintig microservices hebt; zo werkt het niet. En dit moet duidelijk worden begrepen.
In plaats van output
Als u wacht op een duidelijke conclusie ‘de database virtualiseren of niet’, dan zullen we u teleurstellen: die zal er niet zijn. Omdat je bij het creëren van een infrastructuuroplossing je niet moet laten leiden door mode en vooruitgang, maar in de eerste plaats door gezond verstand.
Er zijn projecten waarvoor de principes en tools die bij Kubernetis horen perfect aansluiten, en bij zulke projecten heerst er in ieder geval rust op het backend-gebied. En er zijn projecten die geen containerisatie nodig hebben, maar een normale serverinfrastructuur, omdat ze fundamenteel niet kunnen herschalen naar het microserviceclustermodel, omdat ze zullen vallen.
Bron: www.habr.com