Dalgún xeito, historicamente, a industria das TI está dividida en dous campos condicionais por calquera motivo: os que están "a favor" e os que están "en contra". Ademais, o tema das disputas pode ser completamente arbitrario. Que sistema operativo é mellor: Win ou Linux? Nun teléfono intelixente Android ou iOS? Deberías gardar todo nas nubes ou colocalo nun almacenamento RAID frío e poñer os parafusos nunha caixa forte? A xente de PHP ten dereito a ser chamado programador? Estas disputas teñen, en ocasións, un carácter exclusivamente existencial e non teñen outro fundamento que o interese deportivo.
Aconteceu que coa chegada dos contedores e toda esta querida cociña con docker e k8 condicional, comezaron os debates "a favor" e "en contra" do uso de novas capacidades en varias áreas do backend. (Fagamos unha reserva de antemán de que aínda que Kubernetes se indicará a maioría das veces como orquestrador nesta discusión, a elección desta ferramenta en particular non é de importancia fundamental. Pola contra, pode substituír por calquera outra que lle pareza máis conveniente e familiar. .)
E, ao parecer, esta sería unha simple disputa entre dúas caras da mesma moeda. Tan insensato e despiadado como o eterno enfrontamento entre Win vs Linux, no que hai persoas adecuadas nalgún lugar do medio. Pero no caso da contenerización, non todo é tan sinxelo. Normalmente, en tales disputas non hai un lado dereito, pero no caso de "utilizar" ou "non usar" contedores para almacenar bases de datos, todo se volve. Porque en certo sentido, tanto os partidarios como os contrarios a este enfoque teñen razón.
Lado bo
O argumento do lado lixeiro pódese describir brevemente nunha frase: "Ola, 2k19 está fóra da fiestra!" Parece populismo, claro, pero se afondas na situación en detalle, ten as súas vantaxes. Imos resolvelos agora.
Digamos que tes un proxecto web grande. Inicialmente podería terse construído a partir dun enfoque de microservizos, ou nalgún momento chegou a el a través dun camiño evolutivo; isto non é moi importante, de feito. Distribuíches o noso proxecto en microservizos separados, configuraches a orquestración, o equilibrio de carga e a escala. E agora, coa conciencia tranquila, bebes un mojito nunha hamaca durante os efectos de habra en lugar de levantar servidores caídos. Pero en todas as accións debes ser coherente. Moitas veces, só a propia aplicación (o código) está contenedora. Que máis temos ademais do código?
É certo, datos. O corazón de calquera proxecto son os seus datos: este pode ser un DBMS típico (MySQL, Postgre, MongoDB) ou o almacenamento utilizado para a busca (ElasticSearch), o almacenamento de clave-valor para almacenar en caché, por exemplo, redis, etc. Actualmente non estamos. falaremos de opcións de implementación de back-end tortas cando a base de datos falla debido a consultas mal escritas e, no seu lugar, falaremos de garantir a tolerancia a fallos desta mesma base de datos baixo a carga do cliente. Despois de todo, cando contenerizamos a nosa aplicación e permitímoslle escalar libremente para procesar calquera número de solicitudes entrantes, isto naturalmente aumenta a carga da base de datos.
De feito, a canle de acceso á base de datos e o servidor no que se executa convértense no ollo da agulla do noso fermoso backend en contenedores. Ao mesmo tempo, o principal motivo da virtualización de contedores é a mobilidade e flexibilidade da estrutura, o que nos permite organizar a distribución dos picos de carga en toda a infraestrutura á que dispoñemos da forma máis eficiente posible. É dicir, se non contenerizamos e implementamos todos os elementos existentes do sistema en todo o clúster, estamos cometendo un erro moi grave.
É moito máis lóxico agrupar non só a aplicación en si, senón tamén os servizos encargados de almacenar os datos. Ao agrupar e despregar servidores web que funcionan de forma independente e que distribúen a carga entre eles en k8s, xa estamos resolvendo o problema da sincronización de datos: os mesmos comentarios sobre as publicacións, se tomamos como exemplo algún medio ou plataforma de blogs. En calquera caso, temos unha representación intra-clúster, incluso virtual, da base de datos como un Servizo Externo. A cuestión é que a propia base de datos aínda non está agrupada: os servidores web despregados no cubo toman información sobre os cambios da nosa base de datos de combate estática, que xira por separado.
Sentes unha captura? Usamos k8s ou Swarm para distribuír a carga e evitar fallar o servidor web principal, pero non o facemos para a base de datos. Pero se a base de datos falla, toda a nosa infraestrutura agrupada non ten sentido. De que serven as páxinas web baleiras que devolven un erro de acceso á base de datos?
Por iso é necesario agrupar non só os servidores web, como se fai habitualmente, senón tamén a infraestrutura de bases de datos. Só así poderemos garantir unha estrutura que funcione plenamente nun equipo, pero ao mesmo tempo independentes entre si. Ademais, aínda que a metade do noso back-end "colapsase" baixo carga, o resto sobrevivirá, e o sistema de sincronización das bases de datos entre si dentro do clúster e a capacidade de escalar e implantar novos clústeres sen parar axudará a alcanzar rapidamente a capacidade necesaria. se só houbese racks no centro de datos.
Ademais, o modelo de base de datos distribuído en clústeres permite levar esta mesma base de datos ata onde sexa necesaria; Se estamos a falar dun servizo global, entón é bastante ilóxico crear un clúster web nalgún lugar da área de San Francisco e, ao mesmo tempo, enviar paquetes ao acceder a unha base de datos na rexión de Moscova e viceversa.
Ademais, a contenerización da base de datos permítelle construír todos os elementos do sistema ao mesmo nivel de abstracción. O que, á súa vez, fai posible xestionar este mesmo sistema directamente desde o código, por parte dos desenvolvedores, sen a implicación activa dos administradores. Os desenvolvedores pensaron que se necesitaba un DBMS separado para o novo subproxecto - doado! escribiu un ficheiro yaml, cargouno ao clúster e xa está.
E, por suposto, o funcionamento interno simplifícase moito. Dime, cantas veces pechaches os ollos cando un novo membro do equipo meteu as mans na base de datos de combate para traballar? Cal, de feito, é o único que tes e está a xirar agora mesmo? Por suposto, todos somos adultos aquí, e nalgún lugar temos unha copia de seguridade nova, e aínda máis lonxe -detrás do andel cos pepinos da avoa e os esquís vellos- outra copia de seguridade, quizais mesmo nunha cámara frigorífica, porque a túa oficina xa estaba en chamas unha vez. Pero, de todos os xeitos, cada introdución dun novo membro do equipo con acceso á infraestrutura de combate e, por suposto, á base de datos de combate é un balde de validol para todos. Ben, quen o coñece, un novato, quizais sexa cruzado? Da medo, estarás de acordo.
A contenerización e, de feito, a topoloxía física distribuída da base de datos do teu proxecto axudan a evitar tales momentos de validación. Non confías nun novato? OK! Dámoslle o seu propio clúster para traballar e desconectar a base de datos dos outros clústeres: sincronización só mediante inserción manual e rotación sincrónica de dúas teclas (unha para o xefe do equipo, a outra para o administrador). E todos están contentos.
E agora é o momento de converterse en opositores á agrupación de bases de datos.
Lado escuro
Argumentando por que non paga a pena contener a base de datos e seguir executándoa nun servidor central, non nos rebaixaremos á retórica de ortodoxias e afirmacións como "os avós executaban bases de datos en hardware, e nós tamén!" En vez diso, imos tentar chegar a unha situación na que a contenerización pagaría dividendos tanxibles.
De acordo, os proxectos que realmente necesitan unha base nun recipiente pódense contar cos dedos dunha man por non ser o mellor operador de fresadora. Na súa maior parte, mesmo o uso de k8s ou Docker Swarm é redundante; moitas veces recórrese a estas ferramentas debido ao bombo xeral das tecnoloxías e ás actitudes do "todopoderoso" na persoa dos xéneros para empuxar todo ao mundo. nubes e contedores. Pois porque agora está de moda e todo o mundo o fai.
Polo menos na metade dos casos, usar Kubernetis ou só Docker nun proxecto é redundante. O problema é que non todos os equipos ou empresas de subcontratación contratados para manter a infraestrutura do cliente son conscientes diso. É peor cando se impoñen envases, porque lle custa unha certa cantidade de moedas ao cliente.
En xeral, existe a opinión de que a mafia do docker/cube está esmagando estúpidamente os clientes que subcontratan estes problemas de infraestrutura. Despois de todo, para traballar con clusters, necesitamos enxeñeiros que sexan capaces diso e comprendan en xeral a arquitectura da solución implementada. Unha vez xa describimos o noso caso coa publicación Republic: alí adestramos ao equipo do cliente para traballar nas realidades de Kubernetis e todos quedaron satisfeitos. E foi decente. Moitas veces, os "implementadores" de k8 toman como refén a infraestrutura do cliente, porque agora só eles entenden como funciona todo alí; non hai especialistas do lado do cliente.
Agora imaxina que deste xeito subcontratamos non só a parte do servidor web, senón tamén o mantemento da base de datos. Diciamos que a BD é o corazón, e a perda do corazón é fatal para calquera organismo vivo. En resumo, as perspectivas non son as mellores. Entón, en lugar de hype Kubernetis, moitos proxectos simplemente non deberían preocuparse coa tarifa normal de AWS, que resolverá todos os problemas coa carga do seu sitio/proxecto. Pero AWS xa non está de moda, e as exhibicións valen máis que o diñeiro, por desgraza, tamén no entorno informático.
OK. Quizais o proxecto realmente necesite agrupación, pero se todo está claro con aplicacións sen estado, entón como podemos organizar unha conectividade de rede decente para unha base de datos agrupada?
Se estamos a falar dunha solución de enxeñería sen fisuras, que é o que é a transición a k8s, entón a nosa principal dor de cabeza é a replicación de datos nunha base de datos agrupada. Algúns DBMS son inicialmente bastante leais á distribución de datos entre as súas instancias individuais. Moitos outros non son tan acolledores. E moitas veces o principal argumento para elixir un DBMS para o noso proxecto non é a capacidade de replicar cuns custos de enxeñería e recursos mínimos. Sobre todo se o proxecto non foi inicialmente planificado como un microservizo, senón que simplemente evolucionou nesta dirección.
Pensamos que non hai que falar da velocidade das unidades de rede: son lentas. Eses. Aínda non temos unha oportunidade real, se ocorre algo, de reiniciar unha instancia de DBMS nalgún lugar onde haxa máis, por exemplo, potencia do procesador ou RAM libre. Atoparemos moi rapidamente o rendemento do subsistema de discos virtualizados. En consecuencia, o DBMS debe estar cravado no seu propio conxunto persoal de máquinas situadas nas proximidades. Ou é necesario arrefriar por separado a sincronización de datos suficientemente rápida para as supostas reservas.
Continuando co tema dos sistemas de ficheiros virtuais: Docker Volumes, por desgraza, non está exento de problemas. En xeral, nun asunto como o almacenamento de datos fiable a longo prazo, gustaríame conformarme cos esquemas tecnicamente máis sinxelos. E engadir unha nova capa de abstracción desde o FS do contedor ao FS do host principal é un risco en si mesmo. Pero cando o funcionamento do sistema de apoio á contenerización tamén atopa dificultades para transmitir datos entre estas capas, entón é realmente un desastre. Polo momento, a maioría dos problemas coñecidos pola humanidade progresista parecen estar erradicados. Pero entendes, canto máis complexo é o mecanismo, máis fácil rompe.
Á vista de todas estas "aventuras", é moito máis rendible e doado manter a base de datos nun só lugar, e aínda que necesites contener a aplicación, déixaa funcionar por si mesma e a través da pasarela de distribución reciba comunicación simultánea co base de datos, que será lida e escrita só unha vez e nun só lugar. Este enfoque reduce ao mínimo a probabilidade de erros e desincronización.
A que estamos levando? Ademais, a contenerización de bases de datos é apropiada onde hai unha necesidade real. Non podes encher unha base de datos de aplicacións completa e xirala coma se tiveses dúas ducias de microservizos; non funciona así. E isto debe entenderse claramente.
En lugar da saída
Se estás esperando unha conclusión clara "para virtualizar a base de datos ou non", entón decepcionarémosche: non estará aquí. Porque á hora de crear calquera solución de infraestrutura hai que guiarse non pola moda e o progreso, senón, ante todo, polo sentido común.
Hai proxectos para os que os principios e ferramentas que veñen con Kubernetis encaixan perfectamente, e nestes proxectos hai paz polo menos na área de backend. E hai proxectos que non precisan de contenerización, senón dunha infraestrutura de servidor normal, porque fundamentalmente non poden reescalar ao modelo de clúster de microservizos, porque caerán.
Fonte: www.habr.com