Cómo desarrollar su propio sistema de gestión de servidores

A primera vista, se trata de un sistema de gestión distribuido basado en el método B/S, pero en realidad la arquitectura subyacente se basa en el método C/S. ¿Crees que es un zapato? De hecho, es secador de pelo. Como sistema de interfaz, el marco del navegador es indispensable, pero lo más importante está en Socket.

Primero, es necesario resolver el problema de comunicación entre la consola central y cada servidor de nodo.

Esto en realidad implica un protocolo de comunicación. Cada idioma tiene su propia biblioteca de sockets y subprocesos, a los que se puede llamar directamente. Pero este protocolo de comunicación debe completarse individualmente. No puede ser demasiado simple. Si es demasiado simple, se transmitirá en texto sin formato. Si otros conocen la interfaz, será fácil realizar algunas operaciones molestas. No puede ser demasiado complicado, porque demasiada complejidad le causará problemas, por lo que se necesita un trabajo simple de codificación y decodificación de paquetes o el uso de autenticación de token. Debe haber al menos dos protocolos de comunicación, uno para transmitir la ejecución de comandos y otro para transmitir archivos.

2. Comunicación por socket entre idiomas

¿Por qué se necesita la comunicación entre idiomas, maestro y agente? En realidad, no importa qué idioma se utilice para el desarrollo. Pero para evitar problemas, intente usar el idioma predeterminado que ya está en el servidor. No es imposible que Ambari use phppuppet para administrar el clúster. Puppet resuelve el problema del protocolo de comunicación del socket y la transferencia de archivos, pero debe usarlo. cada vez. Ruby debe estar instalado en cada servidor para habilitar Puppet. Soy un poco fanático de los servidores y de la limpieza de códigos. Si tienes que instalar Ruby para un títere, lo siento por los recursos del servidor. Entonces escribí mi propio agente Python. Todos los sistemas Linux vienen con Python instalado. Entonces, la comunicación de control principal se puede implementar en Python o PHP. Sin embargo, considerando que para más usuarios, cambiar PHP puede ser mucho más simple que cambiar Tornado, por lo que no es necesario desarrollar en Python. Hay muchas versiones secundarias de hadoop. Después del lanzamiento, los usuarios deben modificar e instalar su propia versión de la distribución de hadoop. El código fuente de PHP es obviamente más PHP que Python. mientras que Python es solo un agente operativo.

Por lo tanto, esto también se extiende a una pregunta, es decir, qué lenguaje es más adecuado para usar en el lado del agente de este sistema de gestión distribuido. Personalmente creo que usar Python es más adecuado, porque Python viene con. el sistema operativo. y las funciones del paquete local son básicamente suficientes. También puede escribir agentes usando java y php, pero debe configurar de antemano el entorno de ejecución jre o php en el nodo. Es por eso que la mayoría de la gente escribe mapred en Python y Java. Nadie le impide escribir mapeado usando nodejs, puede hacerlo, pero debe instalar el motor de interpretación v8 en cada nodo, lo cual no es una molestia. Consulte el mapa/documento de registro para conocer el fundamento, no la explicación. Perl también es el idioma nativo del sistema operativo, pero la capacidad de mantenimiento de Perl es muy pobre y es mejor olvidarse de él.

Esto plantea la cuestión de los sockets entre idiomas, lo cual no es un problema en teoría. Pero esto es solo teórico. De hecho, existen problemas en el proceso de desarrollo real, como conexiones de socket largas y diferentes métodos de encapsulación de paquetes de datos de comunicación en la parte inferior. Una de las razones por las que no utilicé xml-rpc es que escuché que xmlrpc de php es diferente de otros lenguajes y debe modificarse antes de poder usarse. Al principio, yo mismo definí el protocolo de operación. Más tarde, encontré estos problemas, así que adopté directamente el método de ahorro. Básicamente, no hay ningún problema de comunicación por socket entre idiomas.

3. Resultados de la ejecución en el lado del agente

No importa si el comando o archivo se ejecuta correctamente en el lado del agente, debemos devolver los resultados de la ejecución al centro.

Entonces también está el problema de leer stdout y stderr en el nodo. En términos generales, esto no es difícil y existen paquetes de software ya preparados que pueden resolver este problema. Por supuesto, en este punto es necesario bloquear la ejecución en lugar de utilizar una devolución de llamada asincrónica.

Otro problema es que quiero utilizar los paquetes de software predeterminados que vienen con Python tanto como sea posible y tratar de evitar que el servidor acceda a Internet para descargar paquetes de software de terceros.