D'alguna manera, històricament, la indústria informàtica es divideix en dos camps condicionals per qualsevol motiu: els que estan "a favor" i els que estan "en contra". A més, el tema de les disputes pot ser completament arbitrari. Quin sistema operatiu és millor: Win o Linux? Amb un telèfon intel·ligent Android o iOS? Hauríeu d'emmagatzemar-ho tot als núvols o posar-lo en un emmagatzematge RAID en fred i posar els cargols en una caixa forta? Les persones de PHP tenen dret a ser anomenades programadors? Aquestes disputes són, de vegades, de caràcter exclusivament existencial i no tenen cap altre fonament que l'interès esportiu.
Va passar que amb l'arribada dels contenidors i tota aquesta cuina estimada amb docker i k8 condicional, van començar els debats "a favor" i "en contra" de l'ús de noves capacitats en diverses àrees del backend. (Fem una reserva per endavant que encara que Kubernetes s'indicarà més sovint com a orquestrador en aquesta discussió, l'elecció d'aquesta eina en particular no té una importància fonamental. En canvi, podeu substituir-ne qualsevol que us sembli més convenient i familiar. .)
I, sembla, això seria una simple disputa entre les dues cares de la mateixa moneda. Tan sense sentit i despietat com l'eterna confrontació entre Win vs Linux, en què hi ha gent adequada en algun lloc del mig. Però en el cas de la contenidorització, no tot és tan senzill. Normalment, en aquestes disputes no hi ha costat dret, però en el cas dels contenidors "utilitzar" o "no utilitzar" per emmagatzemar bases de dades, tot es capgira. Perquè en cert sentit, tant els partidaris com els contraris a aquest plantejament tenen raó.
Part bona
L'argument del Light Side es pot descriure breument en una frase: "Hola, 2k19 és fora de la finestra!" Sembla populisme, és clar, però si aprofundeixes en la situació, té els seus avantatges. Anem a ordenar-los ara.
Suposem que teniu un gran projecte web. Es podria haver construït inicialment sobre la base d'un enfocament de microservei, o en algun moment va arribar-hi a través d'un camí evolutiu; això no és molt important, de fet. Heu repartit el nostre projecte en microserveis separats, heu configurat l'orquestració, l'equilibri de càrrega i l'escala. I ara, amb la consciència tranquil·la, prens un mojito en una hamaca durant els efectes d'habra en comptes d'aixecar servidors caiguts. Però en totes les accions has de ser coherent. Molt sovint, només l'aplicació en si, el codi, està en contenidors. Què més tenim a més del codi?
Així és, dades. El cor de qualsevol projecte són les seves dades: poden ser un SGBD típic - MySQL, Postgre, MongoDB, o emmagatzematge utilitzat per a la cerca (ElasticSearch), emmagatzematge de clau-valor per a la memòria cau, per exemple, redis, etc. Actualment no som. parlarem d'opcions d'implementació de backend tort quan la base de dades es bloqueja a causa de consultes mal escrites i, en canvi, parlarem de garantir la tolerància a errors d'aquesta mateixa base de dades sota la càrrega del client. Després de tot, quan contenitzem la nostra aplicació i li permetem escalar lliurement per processar qualsevol nombre de sol·licituds entrants, això naturalment augmenta la càrrega de la base de dades.
De fet, el canal per accedir a la base de dades i el servidor on s'executa es converteixen en l'ull de l'agulla del nostre bonic backend en contenidors. Al mateix temps, el principal motiu de la virtualització de contenidors és la mobilitat i la flexibilitat de l'estructura, la qual cosa ens permet organitzar la distribució de pics de càrrega per tota la infraestructura de què disposem de la manera més eficient possible. És a dir, si no contenitzem i despleguem tots els elements existents del sistema al clúster, estem cometent un error molt greu.
És molt més lògic agrupar no només l'aplicació en si, sinó també els serveis encarregats d'emmagatzemar les dades. Agrupant i desplegant servidors web que funcionen de manera independent i distribueixen la càrrega entre ells en k8s, ja estem resolent el problema de la sincronització de dades: els mateixos comentaris a les publicacions, si prenem com a exemple algun mitjà o plataforma de blocs. En qualsevol cas, tenim una representació intra-clúster, fins i tot virtual, de la base de dades com un Servei Extern. La pregunta és que la base de dades en si encara no està agrupada: els servidors web desplegats al cub prenen informació sobre els canvis de la nostra base de dades de combat estàtica, que gira per separat.
Sentiu una captura? Utilitzem k8s o Swarm per distribuir la càrrega i evitar que es bloquegi el servidor web principal, però no ho fem per a la base de dades. Però si la base de dades es bloqueja, tota la nostra infraestructura agrupada no té sentit: de què serveixen les pàgines web buides que retornen un error d'accés a la base de dades?
És per això que cal agrupar no només els servidors web, com es fa habitualment, sinó també la infraestructura de bases de dades. Només així podrem garantir una estructura que funcioni plenament en un equip, però alhora independent entre si. A més, fins i tot si la meitat del nostre backend "es col·lapsa" sota càrrega, la resta sobreviurà, i el sistema de sincronització de les bases de dades entre si dins del clúster i la capacitat d'escalar i desplegar nous clústers sense parar ajudaran a assolir ràpidament la capacitat necessària. si només hi hagués bastidors al centre de dades.
A més, el model de base de dades distribuït en clústers permet portar aquesta mateixa base de dades on calgui; Si estem parlant d'un servei global, aleshores és bastant il·lògic crear un clúster web en algun lloc de l'àrea de San Francisco i, al mateix temps, enviar paquets en accedir a una base de dades a la regió de Moscou i tornar.
A més, la contenidorització de la base de dades permet construir tots els elements del sistema al mateix nivell d'abstracció. El que, al seu torn, permet gestionar aquest mateix sistema directament des del codi, per part dels desenvolupadors, sense la implicació activa dels administradors. Els desenvolupadors van pensar que es necessitava un SGBD separat per al nou subprojecte: fàcil! va escriure un fitxer yaml, el va penjar al clúster i ja està.
I, per descomptat, el funcionament intern es simplifica molt. Digues-me, quantes vegades has tancat els ulls quan un nou membre de l'equip posa les mans a la base de dades de combat per treballar? Quin, de fet, és l'únic que tens i està girant ara mateix? Per descomptat, aquí tots som adults, i en algun lloc tenim una nova còpia de seguretat, i encara més lluny, darrere de la prestatgeria amb els cogombres de l'àvia i els esquís vells, una altra còpia de seguretat, potser fins i tot en un magatzem frigorífic, perquè la vostra oficina ja estava en flames. Però, de totes maneres, cada introducció d'un nou membre de l'equip amb accés a la infraestructura de combat i, per descomptat, a la base de dades de combat és una galleda de validol per a tothom. Bé, qui el coneix, un novell, potser és creuat? Fa por, hi estaràs d'acord.
La contenidorització i, de fet, la topologia física distribuïda de la base de dades del vostre projecte ajuda a evitar aquests moments de validació. No confies en un novell? D'ACORD! Donem-li el seu propi clúster per treballar i desconnectar la base de dades dels altres clústers: sincronització només mitjançant l'empenta manual i la rotació sincrònica de dues tecles (una per al líder de l'equip, l'altra per a l'administrador). I tothom està content.
I ara és el moment de convertir-se en opositors a l'agrupació de bases de dades.
Costat fosc
Argumentant per què no val la pena contenidor la base de dades i continuar executant-la en un servidor central, no ens abastarem a la retòrica d'ortodòxies i declaracions com "els avis van executar bases de dades amb maquinari, i nosaltres també!" En comptes d'això, intentem trobar una situació en què la contenidorització realment pagués dividends tangibles.
D'acord, els projectes que realment necessiten una base en un contenidor es poden comptar amb els dits d'una mà per no el millor operador de fresadora. En la seva majoria, fins i tot l'ús de k8s o Docker Swarm és redundant; sovint es recorre a aquestes eines a causa del bombo general de les tecnologies i les actituds del "totpoderós" en la persona dels gèneres per empènyer-ho tot a la núvols i contenidors. Doncs perquè ara està de moda i ho fa tothom.
En almenys la meitat dels casos, utilitzar Kubernetis o només Docker en un projecte és redundant. El problema és que no tots els equips o empreses d'externalització contractats per mantenir la infraestructura del client en són conscients. És pitjor quan s'imposen contenidors, perquè costa una certa quantitat de monedes al client.
En general, hi ha l'opinió que la màfia docker/cube està aixafant estúpidament els clients que subcontraten aquests problemes d'infraestructura. Al cap i a la fi, per treballar amb clústers necessitem enginyers capaços d'això i que en general entenguin l'arquitectura de la solució implementada. Una vegada ja vam descriure el nostre cas amb la publicació Republic: allà vam formar l'equip del client per treballar en les realitats de Kubernetis i tothom va quedar satisfet. I va ser decent. Sovint, els "implementadors" de k8 prenen com a ostatge la infraestructura del client, perquè ara només ells entenen com funciona tot allà; no hi ha especialistes per part del client.
Ara imagineu que d'aquesta manera externalitzem no només la part del servidor web, sinó també el manteniment de la base de dades. Vam dir que la BD és el cor i la pèrdua del cor és fatal per a qualsevol organisme viu. En resum, les perspectives no són les millors. Per tant, en comptes de l'hype Kubernetis, molts projectes simplement no haurien de preocupar-se amb la tarifa normal d'AWS, que solucionarà tots els problemes amb la càrrega del seu lloc/projecte. Però AWS ja no està de moda i les exhibicions valen més que els diners, malauradament, també en l'entorn informàtic.
D'ACORD. Potser el projecte realment necessita clúster, però si tot està clar amb les aplicacions sense estat, llavors com podem organitzar una connectivitat de xarxa decent per a una base de dades agrupada?
Si estem parlant d'una solució d'enginyeria perfecta, que és la transició a k8s, el nostre principal mal de cap és la replicació de dades en una base de dades agrupada. Alguns DBMS són inicialment força lleials a la distribució de dades entre les seves instàncies individuals. Molts altres no són tan acollidors. I sovint, l'argument principal a l'hora d'escollir un DBMS per al nostre projecte no és la capacitat de replicar amb uns costos mínims de recursos i d'enginyeria. Sobretot si el projecte no es va plantejar inicialment com un microservei, sinó que simplement va evolucionar en aquesta direcció.
Creiem que no cal parlar de la velocitat de les unitats de xarxa: són lentes. Aquells. Encara no tenim una oportunitat real, si passa alguna cosa, de reiniciar una instància de DBMS en algun lloc on hi hagi més, per exemple, potència del processador o RAM lliure. Ens trobarem molt ràpidament amb el rendiment del subsistema de disc virtualitzat. En conseqüència, el SGBD s'ha de connectar al seu propi conjunt personal de màquines situades molt a prop. O cal refredar d'alguna manera per separat una sincronització de dades prou ràpida per a les suposades reserves.
Continuant amb el tema dels sistemes de fitxers virtuals: Docker Volumes, malauradament, no estan lliures de problemes. En general, en una qüestió com l'emmagatzematge de dades fiable a llarg termini, m'agradaria conformar-me amb els esquemes més senzills tècnicament. I afegir una nova capa d'abstracció del FS del contenidor al FS de l'amfitrió principal és un risc en si mateix. Però quan el funcionament del sistema de suport a la contenidorització també troba dificultats per transmetre dades entre aquestes capes, és realment un desastre. En aquests moments, la majoria dels problemes coneguts per la humanitat progressista semblen haver estat eradicats. Però entens, com més complex és el mecanisme, més fàcil es trenca.
A la llum de totes aquestes "aventures", és molt més rendible i fàcil mantenir la base de dades en un sol lloc, i fins i tot si necessiteu contener l'aplicació, deixeu-la funcionar sola i a través de la passarel·la de distribució rebreu comunicació simultània amb el base de dades, que es llegirà i es redactarà només una vegada i en un sol lloc. Aquest enfocament redueix al mínim la probabilitat d'errors i de desincronització.
A què estem conduint? A més, la contenidorització de bases de dades és adequada quan hi ha una necessitat real. No podeu omplir una base de dades d'aplicacions completa i girar-la com si tinguéssiu dues dotzenes de microserveis; no funciona així. I això s'ha d'entendre clarament.
En lloc de la sortida
Si esteu esperant una conclusió clara "per virtualitzar la base de dades o no", aleshores us decebrem: no estarà aquí. Perquè a l'hora de crear qualsevol solució d'infraestructura s'ha de guiar no per la moda i el progrés, sinó, en primer lloc, pel sentit comú.
Hi ha projectes per als quals els principis i les eines que vénen amb Kubernetis encaixen perfectament, i en aquests projectes hi ha pau almenys a l'àrea de backend. I hi ha projectes que no necessiten containerització, sinó una infraestructura de servidor normal, perquè fonamentalment no poden reescalar al model de clúster de microserveis, perquè cauran.
Font: www.habr.com