As nubes son como unha caixa máxica: pregúntas o que necesitas e os recursos aparecen da nada. Máquinas virtuais, bases de datos, rede: todo isto só pertence a vostede. Hai outros inquilinos de nubes, pero no teu Universo ti es o único gobernante. Estás seguro de que sempre recibirás os recursos necesarios, non tes en conta a ninguén e determinas de xeito independente como será a rede. Como funciona esta maxia que fai que a nube asigne recursos de forma elástica e illa completamente aos inquilinos uns dos outros?
A nube de AWS é un sistema mega-super complexo que foi evolucionando desde 2006. Parte deste desenvolvemento produciuse Vasily Pantyukhin - Arquitecto de Amazon Web Services. Como arquitecto, obtén unha visión interna non só do resultado final, senón tamén dos desafíos que supera AWS. Canto maior sexa a comprensión de como funciona o sistema, maior será a confianza. Polo tanto, Vasily compartirá os segredos dos servizos na nube de AWS. A continuación móstrase o deseño de servidores físicos de AWS, a escalabilidade de bases de datos elásticas, unha base de datos personalizada de Amazon e métodos para aumentar o rendemento das máquinas virtuais ao mesmo tempo que se reducen o seu prezo. O coñecemento dos enfoques arquitectónicos de Amazon axudarache a utilizar os servizos de AWS de forma máis eficaz e pode darche novas ideas para crear as túas propias solucións.
Sobre o orador: Vasily Pantyukhin () comezou como administrador de Unix en empresas .ru, traballou en hardware de gran tamaño Sun Microsystem durante 6 anos e predicou un mundo centrado nos datos en EMC durante 11 anos. Evolucionou naturalmente cara ás nubes privadas, e en 2017 pasou ás públicas. Agora ofrece asesoramento técnico para axudar a vivir e desenvolverse na nube de AWS.
Descargo de responsabilidade: todo a continuación é a opinión persoal de Vasily e pode non coincidir coa posición de Amazon Web Services. O informe no que se basea o artigo está dispoñible na nosa canle de YouTube.
Por que falo do dispositivo Amazon?
O meu primeiro coche tiña unha transmisión manual. Foi xenial pola sensación de que podía conducir o coche e ter control total sobre el. Tamén me gustou que entendín polo menos o principio do seu funcionamento. Por suposto, imaxinei que a estrutura da caixa era bastante primitiva, algo así como unha caixa de cambios nunha bicicleta.
Todo foi xenial, excepto por unha cousa: atrapado nos atascos. Parece que estás sentado sen facer nada, pero estás constantemente cambiando de marcha, presionando o embrague, a gasolina ou o freo: realmente cansache. O problema do atasco resolveuse parcialmente cando a familia conseguiu un coche automático. Mentres conducía, tiven tempo para pensar en algo e escoitar un audiolibro.
Outro misterio apareceu na miña vida, porque deixei por completo de entender como funciona o meu coche. Un coche moderno é un dispositivo complexo. O coche adáptase simultaneamente a decenas de parámetros diferentes: presión do gas, freo, estilo de condución, calidade da estrada. Xa non entendo como funciona.
Cando comecei a traballar na nube de Amazon, tamén foi un misterio para min. Só este misterio é unha orde de magnitude maior, porque hai un condutor no coche, e en AWS hai millóns deles. Todos os usuarios conducen, presionan o acelerador e frean ao mesmo tempo. É incrible que vaian onde queiran, é un milagre para min! O sistema adáptase, escala e axústase elásticamente a cada usuario para que lle pareza que está só neste Universo.
A maxia desapareceu un pouco cando máis tarde vin a traballar como arquitecto en Amazon. Vin a que problemas nos enfrontamos, como os resolvemos e como desenvolvemos os servizos. Co aumento da comprensión de como funciona o sistema, aparece máis confianza no servizo. Entón, quero compartir unha imaxe do que hai baixo o capó da nube AWS.
De que falaremos
Escollín un enfoque diversificado: seleccionei 4 servizos interesantes dos que paga a pena falar.
Optimización de servidores. Nubes efémeras cunha encarnación física: centros de datos físicos onde hai servidores físicos que zumban, quentan e parpadean con luces.
Funcións sen servidor (Lambda) é probablemente o servizo máis escalable da nube.
Escalado de bases de datos. Vouvos falar sobre como construímos as nosas propias bases de datos escalables.
Escalado da rede. A última parte na que abrirei o dispositivo da nosa rede. Isto é unha cousa marabillosa: todos os usuarios da nube cren que están sós na nube e non ven a outros inquilinos.
Nota. Este artigo discutirá a optimización do servidor e o escalado da base de datos. Consideraremos a escala da rede no seguinte artigo. Onde están as funcións sen servidor? Publicouse unha transcrición separada sobre eles "" Fala de varios métodos de escalado diferentes e analiza en detalle a solución Firecracker: unha simbiose das mellores calidades dunha máquina virtual e dos contedores.
Servidores
A nube é efémera. Pero esta efímera aínda ten unha plasmación física: os servidores. Inicialmente, a súa arquitectura era clásica. Chipset x86 estándar, tarxetas de rede, Linux, hipervisor Xen no que se executaron as máquinas virtuais.
En 2012, esta arquitectura afrontou bastante ben as súas tarefas. Xen é un gran hipervisor, pero ten un gran inconveniente. Ten suficiente alta sobrecarga para a emulación do dispositivo. A medida que están dispoñibles tarxetas de rede ou unidades SSD novas e máis rápidas, esta sobrecarga faise demasiado alta. Como tratar con este problema? Decidimos traballar en dúas frontes á vez: optimizar tanto hardware como hipervisor. A tarefa é moi seria.
Optimización de hardware e hipervisor
Facer todo á vez e facelo ben non funcionará. O que era "bo" tampouco estaba claro inicialmente.
Decidimos adoptar un enfoque evolutivo: cambiamos un elemento importante da arquitectura e lanzámolo á produción.
Pisamos cada rastrillo, escoitamos queixas e suxestións. Despois cambiamos outro compoñente. Entón, en pequenos incrementos, cambiamos radicalmente toda a arquitectura en función dos comentarios dos usuarios e do soporte.
A transformación comezou en 2013 coa cousa máis complexa: a rede. EN С3 casos, engadiuse unha tarxeta de acelerador de rede especial á tarxeta de rede estándar. Conectouse literalmente cun cable loopback curto no panel frontal. Non é bonito, pero non se ve na nube. Pero a interacción directa co hardware mellorou fundamentalmente o jitter e o rendemento da rede.
A continuación decidimos mellorar o acceso para bloquear o almacenamento de datos EBS - Elastic Block Storage. É unha combinación de rede e almacenamento. A dificultade é que, aínda que existían tarxetas Network Accelerator no mercado, non había opción para mercar simplemente hardware Storage Accelerator. Así que recorremos a unha startup Laboratorios Annapurna, que desenvolveu chips ASIC especiais para nós. Permitiron que os volumes EBS remotos se montasen como dispositivos NVMe.
En casos C4 resolvemos dous problemas. O primeiro é que implementamos unha base para o futuro dunha tecnoloxía NVMe prometedora, pero nova naquel momento. En segundo lugar, descargamos significativamente o procesador central transferindo o procesamento de solicitudes a EBS a unha nova tarxeta. Saíu ben, polo que agora Annapurna Labs forma parte de Amazon.
En novembro de 2017, decatámonos de que era hora de cambiar o propio hipervisor.
O novo hipervisor foi desenvolvido baseándose en módulos de núcleo KVM modificados.
Permitiu reducir fundamentalmente a sobrecarga da emulación do dispositivo e traballar directamente con novos ASIC. Instancias С5 foron as primeiras máquinas virtuais cun novo hipervisor funcionando baixo o capó. Puxémolo nome Nitro.
Evolución das instancias na liña do tempo.
Todos os novos tipos de máquinas virtuais que apareceron desde novembro de 2017 execútanse neste hipervisor. As instancias de Bare Metal non teñen hipervisor, pero tamén se lles chama Nitro, xa que usan tarxetas Nitro especializadas.
Durante os dous anos seguintes, o número de tipos de instancias de Nitro superou un par de ducias: A1, C5, M5, T3 e outros.
Tipos de instancia.
Como funcionan as modernas máquinas Nitro
Teñen tres compoñentes principais: o hipervisor Nitro (discutido anteriormente), o chip de seguridade e as tarxetas Nitro.
Chip de seguridade integrado directamente na placa base. Controla moitas funcións importantes, como controlar a carga do sistema operativo host.
Tarxetas Nitro - Hai catro tipos deles. Todos eles están desenvolvidos por Annapurna Labs e están baseados en ASIC comúns. Algúns dos seus firmwares tamén son comúns.
Catro tipos de tarxetas Nitro.
Unha das tarxetas está deseñada para funcionar redeVPC. Isto é o que é visible nas máquinas virtuais como unha tarxeta de rede ENA - Adaptador de rede elástico. Tamén encapsula o tráfico cando o transmite a través dunha rede física (diso falaremos na segunda parte do artigo), controla o firewall de Security Groups e é responsable do enrutamento e outras cousas da rede.
As tarxetas seleccionadas funcionan con almacenamento en bloque EBS e discos que están integrados no servidor. Aparecen á máquina virtual convidada como Adaptadores NVMe. Tamén son responsables do cifrado de datos e do seguimento do disco.
O sistema de tarxetas Nitro, hipervisor e chip de seguridade está integrado nunha rede SDN ou Rede definida por software. Responsable da xestión desta rede (plano de control) tarxeta controladora.
Por suposto, seguimos desenvolvendo novos ASIC. Por exemplo, a finais de 2018 lanzaron o chip Inferentia, que permite traballar de forma máis eficiente coas tarefas de aprendizaxe automática.
Chip do procesador Inferentia Machine Learning.
Base de datos escalable
Unha base de datos tradicional ten unha estrutura en capas. Para simplificar moito, distínguense os seguintes niveis.
- SQL — O cliente e os despachadores de solicitudes traballan nel.
- Disposicións transaccións - todo está claro aquí, ÁCIDO e todo iso.
- caché, que é proporcionada por grupos de tampón.
- Rexistro — proporciona traballo con rexistros de refacer. En MySQL chámanse Bin Logs, en PosgreSQL - Write Ahead Logs (WAL).
- Almacenamento - Gravación directa en disco.
Estrutura de bases de datos en capas.
Existen diferentes formas de escalar bases de datos: sharding, arquitectura Shared Nothing, discos compartidos.
Non obstante, todos estes métodos manteñen a mesma estrutura de base de datos monolítica. Isto limita significativamente a escala. Para resolver este problema, desenvolvemos a nosa propia base de datos − Amazona Aurora. É compatible con MySQL e PostgreSQL.
Amazona Aurora
A idea arquitectónica principal é separar os niveis de almacenamento e rexistro da base de datos principal.
De cara ao futuro, direi que tamén fixemos independente o nivel de caché. A arquitectura deixa de ser un monolito e gañamos graos de liberdade adicionais ao escalar bloques individuais.
Os niveis de rexistro e almacenamento están separados da base de datos.
Un DBMS tradicional escribe datos nun sistema de almacenamento en forma de bloques. En Amazon Aurora, creamos un almacenamento intelixente que pode falar idiomas redo-logs. No interior, o almacenamento converte os rexistros en bloques de datos, supervisa a súa integridade e fai copias de seguranza automaticamente.
Este enfoque permítelle implementar cousas tan interesantes como a clonación. Funciona fundamentalmente máis rápido e máis económico debido ao feito de que non require crear unha copia completa de todos os datos.
A capa de almacenamento implícase como un sistema distribuído. Está formado por un gran número de servidores físicos. Cada rexistro de repetición procédese e gárdase simultaneamente seis nós. Isto garante a protección de datos e o equilibrio de carga.
A escala de lectura pódese conseguir utilizando as réplicas adecuadas. O almacenamento distribuído elimina a necesidade de sincronización entre a instancia de base de datos principal, a través da cal escribimos datos, e as réplicas restantes. Os datos actualizados están garantidos para estar dispoñibles para todas as réplicas.
O único problema é almacenar en caché os datos antigos nas réplicas de lectura. Pero este problema estase solucionando transferencia de todos os rexistros redo a réplicas a través da rede interna. Se o rexistro está na caché, márcase como incorrecto e sobrescríbese. Se non está na caché, simplemente descartarase.
Resolvemos o almacenamento.
Como escalar os niveis de DBMS
Aquí, a escala horizontal é moito máis difícil. Entón, imos polo camiño trillado escala vertical clásica.
Supoñamos que temos unha aplicación que se comunica co DBMS a través dun nodo mestre.
Ao escalar verticalmente, asignamos un novo nodo que terá máis procesadores e memoria.
A continuación, cambiamos a aplicación do antigo nodo mestre ao novo. Xorden problemas.
- Isto requirirá un tempo de inactividade importante da aplicación.
- O novo nodo mestre terá caché fría. O rendemento da base de datos só será máximo despois de que se quente a caché.
Como mellorar a situación? Configure un proxy entre a aplicación e o nodo mestre.
Que nos dará isto? Agora todas as aplicacións non precisan ser redirixidas manualmente ao novo nodo. O cambio pódese facer baixo un proxy e é fundamentalmente máis rápido.
Parece que o problema está resolto. Pero non, seguimos sufrindo a necesidade de quentar o caché. Ademais, apareceu un novo problema: agora o proxy é un posible punto de falla.
Solución final con Amazon Aurora sen servidor
Como resolvemos estes problemas?
Deixou un proxy. Non se trata dunha instancia separada, senón de toda unha flota distribuída de proxies a través dos cales as aplicacións se conectan á base de datos. En caso de falla, calquera dos nodos pode substituírse case ao instante.
Engadiuse un conxunto de nodos quentes de varios tamaños. Polo tanto, se é necesario asignar un novo nodo de tamaño maior ou menor, está dispoñible inmediatamente. Non hai que esperar a que se cargue.
Todo o proceso de escalado está controlado por un sistema de vixilancia especial. A supervisión monitoriza constantemente o estado do nodo mestre actual. Se detecta, por exemplo, que a carga do procesador alcanzou un valor crítico, notifica ao grupo de instancias cálidas a necesidade de asignar un novo nodo.
Proxies distribuídos, instancias cálidas e seguimento.
Dispoñible un nodo coa potencia necesaria. Copiáronse nel os grupos de búfer e o sistema comeza a esperar un momento seguro para cambiar.
Normalmente o momento de cambiar chega bastante rápido. A continuación, a comunicación entre o proxy e o antigo nodo mestre está suspendida, todas as sesións cámbianse ao novo nodo.
Traballar coa base de datos currículos.
O gráfico mostra que a suspensión é moi curta. O gráfico azul mostra a carga e os pasos vermellos mostran os momentos de escalado. Os descensos a curto prazo no gráfico azul son precisamente ese breve atraso.
Por certo, Amazon Aurora permítelle aforrar diñeiro por completo e desactivar a base de datos cando non está en uso, por exemplo, os fins de semana. Despois de parar a carga, o DB reduce gradualmente a súa potencia e apágase durante algún tempo. Cando a carga volva, volverá a subir suavemente.
Na seguinte parte da historia sobre o dispositivo Amazon, falaremos sobre o escalado da rede. Subscríbete e estade atentos para non perder o artigo.
En Vasily Pantyukhin dará un informe "" Que patróns de deseño para sistemas distribuídos utilizan os desenvolvedores de Amazon, cales son os motivos dos fallos do servizo, que é a arquitectura baseada en células, o traballo constante, o Shuffle Sharding, será interesante. Menos dun mes para a conferencia - . 24 de outubro aumento de prezo final.
Fonte: www.habr.com