Cómo crear servicios en la nube utilizando OpenStack, Docker y Spark

Esta vez quiero compartir con ustedes principalmente los problemas que encontramos al construir una nube privada basada en Docker el año pasado, cómo resolverlos y nuestra experiencia. Me gustaría compartir mi experiencia y pensamientos con todos.

Existen algunas experiencias y lecciones aprendidas al utilizar Docker en un entorno de producción. El proyecto de nube privada se lanzó durante el período navideño de 2014. Comenzó desde cero después de más de medio año de desarrollo y tres promociones importantes, y gradualmente ha adquirido una cierta escala.

Arquitectura

Gestión de clústeres

Como todos sabemos, en las condiciones de ese momento, las capacidades de gestión de clústeres de Docker aún eran muy inmaduras, por lo que no Elija simplemente aparecer. En su lugar, Swarm utiliza el OpenStack más maduro de la industria, que puede administrar Docker y KVM al mismo tiempo. Para satisfacer las necesidades comerciales, ejecutamos Docker como una máquina virtual. Ejecutamos Docker como una máquina virtual para satisfacer las necesidades empresariales de virtualización. Nuestra idea futura son los microservicios, dividir y convertir aplicaciones en microservicios individuales para permitir la implementación y el lanzamiento de aplicaciones basadas en PaaS.

¿Cómo gestionar Docker a través de OpenStack? Adoptamos el modelo de arquitectura OpenStack nova-docker Docker. Nova-docker es un proyecto de código abierto en StackForge. Como complemento de nova, controla el inicio y la parada de contenedores llamando a la interfaz RESTful de Docker.

Hemos desarrollado de forma independiente componentes como la orquestación y la programación basados ​​en IaaS, admitiendo funciones como el escalado elástico de aplicaciones y la expansión en escala de grises, y respaldando ciertas estrategias de programación, logrando así las funciones principales de la capa PaaS.

Al mismo tiempo, se implementa la integración continua (CI) basada en Docker y Jenkins. Si Git en el proyecto realiza operaciones como git push, activará la compilación automática de Jenkins Job. Si la compilación se realiza correctamente, se generará una imagen de Docker y se enviará al almacén de imágenes. Con base en la imagen Docker generada por CI, puede actualizar las instancias de los entornos de desarrollo y prueba a través de la API o interfaz PaaS y, finalmente, actualizar las instancias del entorno de producción, logrando así una integración y entrega continuas.

Red y almacenamiento

En términos de red, no utilizamos el modo de red NAT proporcionado por Docker de forma predeterminada, lo que provocará una cierta pérdida de rendimiento. Con OpenStack, admitimos Linux Bridge y Open vSwitch sin iniciar iptables, y el rendimiento de Docker se acerca al 95% del rendimiento de las máquinas físicas.

Monitoreo de contenedores

En términos de monitoreo, hemos desarrollado herramientas de contenedores de forma independiente para realizar el cálculo de los valores de carga del contenedor, reemplazando los comandos originales top, free, iostat, uptime y otros. De esta manera, cuando la parte empresarial utiliza comandos comunes en el contenedor, lo que ve es el valor del contenedor, no el valor de toda la máquina física. Actualmente estamos portando Lxcfs a nuestra plataforma.

También hemos agregado múltiples alertas y monitoreo de umbrales en el host, como monitoreo de procesos críticos, monitoreo de registros, recuentos de pid en tiempo real, recuentos de seguimiento de conexiones de red, alertas de contenedores, etc.

Redundancia y aislamiento

En términos de redundancia y aislamiento, hemos realizado mucha planificación de redundancia y preparativos técnicos. Pudimos restaurar datos en Docker sin conexión sin iniciar el demonio de Docker.

Al mismo tiempo, admitimos la migración en frío entre máquinas físicas de Docker, la expansión/reducción dinámica de la CPU y la limitación de la velocidad de E/S del disco de red IO.

Problemas encontrados y soluciones

En menos de un año de producción y uso real, hemos encontrado varios problemas, y el proceso de uso de Docker también es el proceso de optimización continua de Docker. localizar y resolver problemas.

Nuestro entorno de producción actual utiliza CentOS 6.5. Una vez, un socio comercial confundió el contenedor Docker que estaba usando con una máquina física e instaló otro Docker dentro del contenedor Docker. Como resultado, el kernel falló instantáneamente. otros contenedores Docker en la misma máquina física.

Después del análisis, descubrí que la versión 2.6.32-431 del kernel no admite bien los espacios de nombres de red y la creación de un puente dentro de Docker provocará que el kernel falle. Este error se solucionó en sentido ascendente y el kernel se actualizó de 2.6.32-431 a 2.6.32-504 para resolver el problema.

Un programa escrito por otro usuario tenía un error en el que los subprocesos creados no se reciclaban a tiempo, creando así una gran cantidad de subprocesos en el contenedor y, en última instancia, provocando la imposibilidad de ejecutar comandos o iniciar sesión ssh en el host informó que el error es "bash: fork: no se puede asignar memoria", pero hay suficiente memoria disponible, lo que se puede ver con free.

Después del análisis, descubrí que el soporte del kernel para el aislamiento de pid es imperfecto. pid_max(/proc/sys/kernel/pid_max) es un dios global. Cuando la cantidad de pids en un contenedor alcanza el límite superior de 32768, el host y otros contenedores no podrán crear nuevos procesos. Solo la última versión 4.3-rc1 admite límites de pid_max por contenedor.

También observamos que los registros del kernel del host de Docker estaban confusos. Después del análisis, descubrimos que esto se debe a que solo hay un búfer log_buf en el kernel, y todos los registros impresos por printk se colocarán primero en este búfer. rsyslogd en los hosts y contenedores de Docker obtendrá registros del búfer log_buf del kernel a través de syslog, lo que generará registros desordenados. Esto se puede resolver modificando la configuración de rsyslog en el contenedor para permitir que el host solo lea el registro del kernel.

Además de esto, también hemos solucionado un problema con el descarte de dm-thin en el asignador de dispositivos que provocaba un fallo del kernel.

Experiencias y pensamientos

Finalmente, nos gustaría compartir nuestras experiencias y pensamientos contigo. En comparación con la tecnología de virtualización KVM más madura, los contenedores todavía tienen muchas imperfecciones. Además de la administración de clústeres, la red y el almacenamiento, lo más importante sigue siendo la estabilidad. El principal impacto sobre la estabilidad es el aislamiento imperfecto. Los problemas causados ​​por un contenedor pueden afectar a todo el sistema.

El contenedor memcg no puede reciclar el caché de la sección y no limita la cantidad de cachés sucios, lo que aumenta la probabilidad de que ocurran problemas de OOM. Además, algunas interfaces de archivos en procfs no se pueden dividir por contenedor, como pid_max.

Otro punto es el impacto en las herramientas de operación y mantenimiento y la experiencia de operación y mantenimiento debajo del contenedor. Algunas herramientas de mantenimiento del sistema (como ss, free, df, etc.) no se pueden usar en contenedores o los resultados no son consistentes con la máquina física. Esto se debe a que las herramientas de mantenimiento del sistema generalmente acceden a archivos en procfs y estas herramientas necesitan hacerlo. ser modificado o el Ajuste.

Aunque los contenedores aún no son perfectos, todavía somos muy optimistas sobre el desarrollo futuro de los contenedores. Nuestro enfoque es el software de código abierto relacionado con contenedores, como Kubernetes, Mesos, Hyper, CRIU, runC, etc.

Preguntas y respuestas

Pregunta: ¿Cómo se logra el equilibrio de carga entre contenedores?

Respuesta: El equilibrio de carga entre contenedores se refleja más en los niveles PaaS y SaaS. Nuestra capa P admite enrutamiento dinámico en las Capas 4 y 7, exponiendo interfaces externas a través de nombres de dominio o servicios de nombres. Podemos realizar expansión en escala de grises y expansión elástica basada en contenedores.

P: ¿Su OpenStack se ejecuta en CentOS 6.5?

Respuesta: Sí, pero actualizamos los paquetes de dependencia de OpenStack y Docker. Mantenemos una fuente interna de yum.

P: ¿La IP del contenedor se coordina estáticamente o se obtiene dinámicamente?

Respuesta: Esto está relacionado con el modelo de red de gestión de operaciones. No tenemos un servicio DHCP en nuestra red interna, por lo que para la capa IaaS, las IP del contenedor se asignan estáticamente. Para la capa PaaS, si hay un servicio DHCP, la IP y los puertos expuestos por la aplicación contenedora pueden ser dinámicos.

P: ¿Ha intentado utilizar Ubuntu durante la implementación, ha investigado las diferencias entre los dos sistemas y cómo monitorea las máquinas virtuales en OpenStack?

R: No intentamos usar Ubuntu porque estamos usando CentOS en producción. Nuestro equipo de middleware es responsable de monitorear las máquinas de la empresa. Trabajamos con el equipo de monitoreo para integrar los agentes utilizados para la implementación. al host y a cada contenedor para que puedan ser monitoreados como máquinas virtuales.

Por supuesto, los datos del contenedor deben obtenerse de cgroups y completaremos esta parte del trabajo de extracción de datos.

P: ¿Alguna sugerencia sobre opciones de redes entre contenedores? Se dice que el uso de una tarjeta de red virtual provocará una pérdida de rendimiento considerable en comparación con el uso de una tarjeta de red física. ¿Pueden el propio Docker Weaver y OVS hacer el trabajo?

Respuesta: No se recomienda utilizar el método NAT predeterminado en redes de contenedores porque NAT provocará una cierta pérdida de rendimiento. Como mencioné en mi intercambio anterior, sin iniciar iptables, el rendimiento de Docker es cercano al 95% del rendimiento de la máquina física. El tejedor de Docker aún debería usar un puente o Open vSwitch en la parte inferior. Se recomienda que consulte el código fuente de nova-docker, que será más fácil de entender.

P: ¿Se puede implementar IP estática a través de LXC?

Respuesta: La IP estática se implementa en novadocker/virt/docker/vifs.py en nova-docker. El principio de implementación es agregar un par veth mediante el comando ip y luego usar una serie de comandos como ip link set/ip netns exec. El principio de instalación es similar al de los tejidos.

P: ¿Cómo obtener el proceso gdb en el contenedor? ¿Gdb está empaquetado en el contenedor?

Respuesta: No habrá ningún problema con gdb en el contenedor. Puede instalar yum gdb directamente.

P: *** ¿Se puede montar el almacenamiento Enjoy directamente en el contenedor?

Respuesta: No lo he probado, pero no debería haber ningún problema a través de docker -v.

P: ¿Cómo recuperar datos de Docker sin conexión sin iniciar el demonio de Docker?

Respuesta: El principio de la recuperación fuera de línea es utilizar el comando dmsetup create para crear un dispositivo dm temporal, asignarlo al número de dispositivo dm utilizado por la instancia de Docker y luego montar el dispositivo temporal para restaurar el datos originales.

P: ¿Cómo se implementan la migración en frío entre máquinas físicas de Docker, la compatibilidad con la expansión/reducción dinámica de la CPU, el límite de velocidad de E/S del disco de red y otras funciones?

Respuesta: La migración en frío de Docker implementa la interfaz de migración de OpenStack modificando nova-docker. Específicamente, utiliza docker commit y docker push entre dos máquinas físicas al registro interno, y luego docker pull snapshot para completar.

La frecuencia dinámica de subida/bajada de la CPU y el límite de velocidad de IO del disco IO de la red se implementan principalmente a través de novadocker, que puede modificar parámetros como cpuset, iops, bps y TC en cgroups.

P: ¿Considerarás utilizar el proyecto Magnum en el futuro o elegirás Swarm?

R: Estas son nuestras alternativas. Podemos considerar Swarm, porque la parte inferior de Magnum todavía llama a una solución de administración de clústeres como Kubernetes. Podemos elegir directamente Swarm o Kubernetes. Por supuesto, esta es sólo mi opinión personal.

P: ¿Su negocio se basa en la misma imagen? Si es una imagen diferente, ¿cómo garantiza el nodo informático que el contenedor pueda iniciarse rápidamente?

Respuesta: El departamento de operaciones mantendrá un conjunto unificado de imágenes básicas. Se realizarán imágenes de otros servicios en base a esta imagen. Cuando inicializamos el nodo informático, extraeremos la imagen básica localmente a través de Docker Pull. Esta es una práctica común entre muchas empresas. Hasta donde yo sé, Tencent y 360 también tienen prácticas similares.

P: Si desea realizar una migración en vivo, ¿ha considerado continuar usando el almacenamiento compartido tradicional?

Respuesta: Se están considerando el almacenamiento distribuido y el almacenamiento compartido. Nuestro siguiente paso es realizar la migración en vivo del contenedor.

P: ¿Vincula la IP pública directamente al contenedor o la asigna a la IP privada del contenedor a través de otros métodos? Si es así, ¿cómo resolver el aislamiento de VLAN de capa 2 original?

R: Debido a que somos una nube privada, no hay ninguna IP flotante involucrada, puedes tratarla como una IP pública. El aislamiento de capa 2 de las VLAN se puede realizar completamente en el conmutador. Usamos Open vSwitch para dividir diferentes VLAN y lograr el aislamiento de la red entre los contenedores Docker y las máquinas físicas.

P: ¿Puede darnos más detalles sobre el problema de caída delgada del mapeador de dispositivos?

Respuesta: En abril, dos hosts se reiniciaban con frecuencia de forma inexplicable. Lo primero que pensé fue comprobar el registro /var/log/messages, pero no encontré ningún mensaje relacionado con el reinicio cerca de la hora de reinicio. En cambio, encontré el registro de fallas del kernel vmcore-dmesg.txt en el directorio /var/crash. El registro se generó al mismo tiempo que el reinicio del host, lo que podría usarse para indicar que el host experimentó un pánico en el kernel, lo que luego resultó en un reinicio automático. "¡ERROR del kernel en drivers/md/persistent-data/dm-btree-remove.c:181!". Se puede ver en la pila que la operación de descarte de dm-thin (el proceso se está preparando para descartar) está en progreso. Si bien no conocemos la causa raíz de este error, la causa directa es una operación de descarte y desactivar el soporte de descarte puede evitar el error.

Desactivamos el descarte en todas las configuraciones de host y no hemos tenido el mismo problema desde entonces.

En la CNUTCon de este año, Tencent y Dianping también mencionaron este problema de bloqueo cuando compartieron su uso de Docker, y sus soluciones fueron exactamente las mismas que las nuestras.

P: Con respecto al monitoreo de umbrales y las alarmas, ¿hay tres niveles de alarmas alto, medio y bajo? Si ocurre una alarma de nivel bajo, ¿se tomarán medidas para restringir el acceso de los usuarios o cortar el negocio? ¿Está usando el usuario actual o se dejará solo?

Respuesta: Para las alarmas, el departamento de operación y mantenimiento cuenta con un PE dedicado responsable de la estabilidad de los servicios en línea. Cuando ocurre una alarma, la parte comercial y el PE recibirán la información de la alarma al mismo tiempo. Si una sola máquina virtual se ve afectada, PE notificará a la parte comercial y, si la situación es grave, la empresa puede incluso abandonarse a tiempo. Trabajaremos con PE para permitir que la parte comercial migre el negocio de manera oportuna.

P: ¿Sus herramientas de contenedor de desarrollo propio son de código abierto? ¿Su código está disponible en GitHub? ¿Se espera que sea de código abierto en el futuro? ¿Seguimiento detallado de los contenedores?

Respuesta: Aunque todavía no lo hemos abierto, creo que está bien abrirlo. Espere nuestras buenas noticias. Con respecto a la granularidad del monitoreo de contenedores, la idea principal es monitorear el estado de salud del contenedor a nivel de host, mientras que el lado comercial completa el monitoreo dentro del contenedor.

P: ¿La capa contenedora se preocupa por el número de capas? ¿Existe una estrategia de optimización?

Respuesta: Por supuesto que nos importa, optimizamos el tiempo que Docker extrae la imagen fusionando capas de imágenes. En Docker Pull, cada capa tarda mucho en verificarse. Al reducir el número de capas, no solo el tamaño se vuelve más pequeño, sino que el tiempo de Docker Pull también se reduce considerablemente.

P: El memcg del contenedor no puede reciclar el caché de losa ni limita la cantidad de cachés sucios, por lo que es más probable que ocurran problemas de OOM. ---- ¿Cómo solucionar este problema de almacenamiento en caché?

Respuesta: Calculamos una parte del caché como memoria utilizada en función de valores empíricos reales e intentamos acercarnos lo más posible al valor de uso real. Además, los umbrales de alerta de memoria se reducen adecuadamente para los contenedores. Al mismo tiempo, también agregamos alertas OOM de contenedores. Si actualiza a CentOS 7, también puede configurar kmem.limit_in_bytes para algunas restricciones.

P: ¿Puede contarnos más sobre el aislamiento de la red de contenedores?

Respuesta: Para el aislamiento de acceso, actualmente utilizamos principalmente VLAN para el aislamiento de Capa 2 y consideraremos usar VXLAN para el aislamiento en el futuro. Para el control del flujo de la red, utilizamos la QoS basada en puerto que viene con OVS. La capa subyacente sigue siendo TC. El control de flujo basado en el tráfico se considerará en el futuro.

P: ¿Este sistema utiliza CentOS 6.5? ¿Cómo se implementa la tecnología? ¿Está más involucrado el personal de operaciones o los desarrolladores?

Respuesta: La estabilidad es la primera prioridad en el entorno de producción. CentOS 6.5 es el principal responsable del mantenimiento unificado de toda la empresa. Durante las actualizaciones importantes de la versión, brindaremos sugerencias de operación y mantenimiento. Al mismo tiempo, haga un buen trabajo en la estabilidad de la virtualización misma.

P: ¿Cómo comunicarse directamente entre contenedores? ¿Cómo está configurada la red?

Respuesta: ¿Quieres decir en la misma máquina física? Actualmente todavía nos comunicamos a través de IP. La red específica puede estar en modo puente o modo VLAN. Usamos Open vSwitch para admitir el modo VLAN, que permite el aislamiento o la comunicación entre contenedores.

P: ¿Utiliza nova-api para integrar Docker? ¿Es posible utilizar funciones avanzadas de Docker como docker-api? ¿Por qué no utilizar Heat para integrar Docker?

Respuesta: Utilizamos el software de código abierto nova-docker para lograr esto. nova-docker es un software de código abierto en StackForge.

Docker es un proyecto de código abierto en StackForge. Como complemento para nova, reemplaza el libvirt existente y controla el inicio y la parada de contenedores y otras operaciones llamando a la interfaz RESTful de Docker.

El uso de Heat o NOVA para integrar Docker ha sido controvertido en la industria y estamos más centrados en el problema que queremos resolver. La relación en la que se basa Heat es más complicada. De hecho, no se usa mucho en la industria; de lo contrario, la comunidad no lanzaría Magnum.

P: ¿Tiene algún enfoque de contenedor a través de DC o dirección similar?

Respuesta: Hemos implementado múltiples clústeres en múltiples salas de computadoras, y cada sala de computadoras tiene un clúster independiente. En base a esto, hemos desarrollado nuestra propia plataforma de administración para lograr la unificación de múltiples clústeres. Al mismo tiempo, hemos establecido Docker Registry V1 y nos estamos preparando internamente para actualizar a Docker Registry V2, que puede implementar la función de duplicación entre DC de las imágenes de Docker.

P: También estoy promoviendo la integración continua y la administración de clústeres de Docker, pero encuentro que la administración también es un problema cuando hay demasiados contenedores, como la administración elástica y el monitoreo de recursos de los contenedores. , Kubernetes o Mesos? En términos de negocios, ¿cómo resolver el nombre de dominio externo? Porque toda la comunicación se realiza a través del host y solo tiene una IP externa.

Respuesta: Para Kubernetes y Mesos, todavía estamos en la etapa de investigación previa. Nuestra programación actual de la capa P es de desarrollo propio. Usamos etcd para mantener el estado de la instancia, los puertos y otra información. Para la capa 7, la resolución se puede realizar a través de Nginx, mientras que para la capa 4, debe confiar en los servicios de nombres. Tenemos nuestro propio servicio de nombres interno para poder solucionar estos problemas. Externamente solo hay una IP, pero los puertos expuestos son diferentes.

P: ¿Has considerado usar Hyper Hypernetes? ¿Aislar contenedores del kernel host mientras se mantiene la velocidad de inicio?

R: Hemos estado trabajando en Hyper, lo cual es una buena idea y no descartaremos la posibilidad de usarlo en el futuro, pero realmente nos gustaría que Hyper implemente la migración en vivo y Docker actualmente no hace menos que eso.

P: ¿Qué configuración de hosting sueles utilizar? ¿Hosting dedicado o servidor en la nube?

Respuesta: Disponemos de nuestra propia sala de ordenadores y utilizamos servidores y máquinas físicas independientes.

P: ¿Qué solución se utiliza para la comunicación entre hosts entre contenedores?

Respuesta: La comunicación entre hosts del contenedor debe utilizar la Capa 3, que es IP. Los contenedores pueden tener IP independientes o pueden implementarse a través del mapeo de puertos IP del host. Actualmente utilizamos métodos de propiedad intelectual más independientes para facilitar la gestión.

P: Parece que el uso de Docker por parte de su empresa se parece más a una máquina virtual. ¿Por qué no considerar usarlo desde la perspectiva de los contenedores?

Respuesta: Nuestra primera consideración es la aceptación del usuario y los costos de transformación. Desde la perspectiva del usuario, no le importa si el negocio se ejecuta en un contenedor o en una máquina virtual. Le preocupa más la eficiencia de implementación de la aplicación y el impacto en la estabilidad y el rendimiento de la aplicación en sí. Desde la perspectiva de los contenedores, algunos aspectos comerciales de las aplicaciones existentes pueden requerir modificaciones importantes. Por ejemplo, sistema de registro, monitoreo de enlace completo, etc. Por supuesto, lo más importante es que tendrá un impacto relativamente grande en el sistema de operación y mantenimiento existente. La gestión de contenedores es un desafío para la operación y el mantenimiento, y la aceptación de la operación y el mantenimiento también es un proceso.

Por supuesto, nuestro objetivo es utilizar Docker como contenedor para empaquetar aplicaciones para lograr la implementación de PaaS y la programación dinámica, y de hecho estamos trabajando en esta dirección. Esto también requiere que las unidades de negocio divida las aplicaciones para habilitar microservicios, lo cual es un proceso.

P: En realidad queremos utilizar contenedores como máquinas virtuales.

¿Qué tipo de middleware utilizas para ejecutar máquinas virtuales? ¿Queremos resolver el problema de las claves de prueba que entran en conflicto con una gran cantidad de entornos WebLogic relativamente independientes?

R: Ejecutamos una variedad de servicios, desde la web principal en el front-end hasta servicios middleware en el back-end. Nuestro servicio de middleware es un producto desarrollado independientemente por otro equipo, que realiza la separación de la lógica empresarial front-end y back-end.

P: ¿Su empresa utiliza OpenStack para administrar tanto Docker como KVM? ¿Tiene su propia interfaz de configuración web o simplemente usa la API para la administración?

Respuesta: Tenemos una plataforma de administración web de desarrollo propio. Esperamos administrar múltiples clústeres a través de una plataforma, conectar operación y mantenimiento, registro, monitoreo y otros sistemas, y exponer una interfaz API unificada al exterior. mundo.

P: Arriba se compartió un caso sobre un error en el espacio de nombres del kernel 2.6. Esta versión inferior del kernel puede instalar un entorno Docker. Actualmente, Docker no puede aislar perfectamente procfs. en la capa de aplicación?

Respuesta: No debería haber ningún problema con la instalación y el uso, pero si se coloca en un entorno de producción, se deben tomar consideraciones integrales. La razón principal es que la estabilidad y el aislamiento no son suficientes y son bajos. Es más probable que los kernels de versión causen fallos del sistema o varios problemas graves. Algunos en realidad no son errores, sino funciones imperfectas. Por ejemplo, crear un puente en un contenedor provocará un fallo. La creación de un puente en un contenedor provocará un bloqueo. Esto se debe al soporte incompleto del kernel para los espacios de nombres de red.

Hemos desarrollado herramientas contenedoras basadas en aplicaciones que no requieren modificación del kernel.

P: ¿Hay más detalles sobre la redundancia, como por ejemplo cómo lograr la recuperación de datos sin conexión?

Respuesta: Cómo recuperar datos sin conexión. Ya respondí esto antes. Específicamente, use el comando dmsetup create para crear un dispositivo dm temporal y asignarlo al dm utilizado por la instancia de Docker. Al montar este dispositivo temporal, se pueden restaurar los datos originales. Otra organización puede compartir otros escenarios redundantes debido a la gran cantidad de contenido. Puedes seguir http://mogu.io/ y lo compartiremos cuando llegue el momento.

P: ¿El actual sistema de contenedores en línea de su empresa es principalmente sin estado o con estado? ¿Cuáles son las consideraciones o dificultades en la selección de escenarios?

Respuesta: Las aplicaciones de las empresas de Internet son en su mayoría apátridas. Las empresas con estado en realidad pueden transformarse desde el nivel empresarial en aplicaciones parcialmente con estado o completamente sin estado. No entiendo muy bien a qué te refieres con selección de escena, pero haremos todo lo posible para satisfacer las diversas necesidades del lado comercial.

Para algunas IO que tienen altos requisitos de estabilidad o son particularmente sensibles a la latencia, como redis business, que no pueden estar completamente aisladas o sin estado, no recomendamos el uso de contenedores.

Multiproceso o multihilo es mejor, etc. No significa que debas usar Spark porque hace mucho calor. Cuando nos encontramos con estos problemas, actualmente continuamos trabajando en esta área: como tecnología de procesamiento de big data actualmente popular, la computación gráfica puede crear rápidamente un clúster Spark para que todos lo usen. ¿Usamos OpenStack? Lista. P: Optimización colaborativa de software y hardware de Hadoop, análisis de rendimiento de Spark y optimización en servidores de arquitectura OpenPOWER: ¿Qué temas compartirá en este discurso? preguntar. Participe en las discusiones de la comunidad Spark. Ha compartido muchos artículos en "Programmer Magazine" sobre computación distribuida, Docker y Spark construyen la nube pública de big data de SuperVessel, y contribuir con código a upstrEAM es una muy buena manera de comenzar, SQL, y tiene 8 patentes de tecnología en el campo de las grandes. datos, herramienta de ajuste y análisis de rendimiento MapReduce. Por ejemplo, muchas empresas todavía utilizan Impala para el análisis de datos: las empresas esperan adoptar la tecnología Spark y optimizar el rendimiento del almacenamiento de objetos Swift.

Por ejemplo, para integrarse mejor con Docker Container, Spark, el líder tecnológico en la dirección de la nube de big data, ¿todavía tiene mucho trabajo por hacer? ¿Cómo deberían empezar las empresas que quieran aplicar Spark rápidamente? Las opciones tecnológicas específicas deben basarse en sus propios escenarios comerciales. Docker Container ha atraído mucha atención por sus ventajas para mejorar la utilización de recursos en la nube y la eficiencia de producción. Se aplican pedales aceleradores FPGA de alto rendimiento a proyectos como plataformas de big data y luego se ajustan los parámetros relevantes para optimizar estos cuellos de botella de rendimiento. Cuando algunas empresas utilizan Storm y Samaza para la computación de flujo, descubren que: en comparación con MapReduce, ¿el rendimiento ha mejorado enormemente? .