Aclass – Infraestructura IT Gestionada para Empresas

Servidores Odoo

Un servidor Odoo es el entorno donde se ejecutan el ERP, su base de datos PostgreSQL y sus documentos. Aclass ofrece alojamiento sobre VMware en Madrid, instalación y mantenimiento técnico de Odoo. Dimensionamos el servidor según usuarios simultáneos, módulos y procesos, y acordamos por escrito la gestión, las copias y las actualizaciones. La consultoría funcional y el desarrollo a medida no forman parte de esta oferta.

Qué incluye el servicio de servidores Odoo

El objetivo no es entregar una máquina virtual y dejar al cliente solo. Aclass prepara el entorno de sistemas, instala Odoo y se ocupa de su mantenimiento técnico conforme al alcance acordado. Revisamos la versión de Odoo, el sistema operativo, PostgreSQL, las dependencias y los módulos que utiliza la empresa antes de decidir la arquitectura.

La propuesta distingue infraestructura, administración del sistema e intervención sobre la aplicación. También concreta la política de copias, la monitorización, las ventanas de mantenimiento y el procedimiento de recuperación. Así sabe quién actúa cuando aparece una incidencia y qué tareas requieren autorización previa.

Este servicio no incluye consultoría funcional, configuración contable, adaptación de procesos ni desarrollo de módulos a medida. Si dispone de un implantador o partner Odoo, coordinamos con él la infraestructura y las intervenciones técnicas. No nos presentamos como partner oficial de Odoo ni atribuimos certificaciones no acreditadas.

Qué recursos necesita Odoo y cómo dimensionarlos

El número de usuarios dados de alta no equivale al número de usuarios concurrentes. Diez personas haciendo pedidos e importando datos a la vez pueden generar más carga que muchas cuentas que entran ocasionalmente. Por eso empezamos por los procesos: inventario, venta, facturación, portal web, informes, integraciones y tareas programadas.

Los workers atienden peticiones de la aplicación. La documentación de Odoo propone reglas orientativas para configurarlos, pero no son una garantía de capacidad. El número de procesos debe caber en la CPU y en la memoria disponibles, dejando margen para PostgreSQL, el sistema operativo y los trabajos programados. Una consulta lenta o un módulo ineficiente no se resuelve siempre añadiendo CPU.

La memoria sostiene workers, cachés y consultas; el disco almacena PostgreSQL, documentos, registros y espacio temporal. El filestore puede crecer rápidamente con adjuntos. Los discos NVMe de nuestra plataforma ayudan en operaciones de entrada y salida, pero medimos el rendimiento de la aplicación completa antes de prometer un resultado.

Solicitamos volumen de base de datos y adjuntos, usuarios simultáneos, módulos, integraciones, picos de actividad y crecimiento previsto. Si existe un servidor anterior, revisamos sus métricas. Si el proyecto es nuevo, validamos una carga representativa y revisamos capacidad tras la puesta en marcha. No publicamos una tabla de usuarios garantizados ni una configuración universal.

Servidor propio, Odoo Online u Odoo.sh

No todas las empresas necesitan la misma modalidad. Odoo Online simplifica la administración en el servicio del fabricante. Odoo.sh incorpora un entorno de despliegue orientado a proyectos con desarrollos, con sus propias condiciones. Un servidor gestionado por Aclass permite acordar la arquitectura de sistemas y la operación con nuestro equipo; no sustituye automáticamente todas las funciones de esas plataformas.

Community y Enterprise también son decisiones distintas del alojamiento. Community dispone de funcionalidades y licencia propias; Enterprise añade módulos y requiere una licencia válida del fabricante. La instalación de Enterprise en un servidor de Aclass depende de los derechos de uso del cliente. Su licencia no se considera incluida en el presupuesto de infraestructura salvo que se indique expresamente.

Antes de trasladar una instalación comprobamos edición, versión, módulos adicionales y compatibilidad. No todos los desarrollos se pueden mover entre modalidades sin adaptación. La decisión debe considerar mantenimiento futuro, acceso a código y bases de datos, necesidades del implantador y condiciones de las licencias, además del coste del servidor.

Migración, copias y recuperación sin improvisaciones

Migrar Odoo exige conservar juntos la base de datos y el filestore donde se guardan los adjuntos, además de los módulos y la configuración necesarios. Una copia solo de PostgreSQL puede recuperar registros sin recuperar todos sus documentos. Las copias deben ser coherentes y el procedimiento tiene que contemplar los permisos, las dependencias y la versión exacta de la aplicación.

El traspaso comienza con un inventario y una copia de ensayo en un entorno aislado. Validamos acceso, documentos, informes, correo saliente e integraciones con el responsable del cliente. Durante las pruebas evitamos que el entorno duplicado envíe mensajes o ejecute operaciones reales. El cambio definitivo requiere una ventana acordada y un procedimiento para volver atrás si las comprobaciones no se cumplen.

En las actualizaciones distinguimos parches técnicos y saltos de versión de Odoo. Un cambio mayor puede exigir migración de datos y adaptación de módulos; no se aplica a ciegas sobre producción ni se presupone incluido en cualquier mantenimiento. Revisamos su alcance y lo validamos antes en pruebas.

La retención de copias, su ubicación, el objetivo de pérdida máxima de datos (RPO) y el objetivo de tiempo de recuperación (RTO) se acuerdan por proyecto. Una instantánea VMware facilita ciertas operaciones técnicas, pero no sustituye una estrategia independiente de backup. Probar una restauración es la forma de saber si el procedimiento es útil cuando realmente se necesita.

Seguridad, acceso remoto y protección del dato

La aplicación se publica mediante HTTPS y un proxy configurado para la versión utilizada, incluidas las conexiones websocket cuando proceda. PostgreSQL no debe quedar expuesto innecesariamente a Internet. Revisamos credenciales, permisos, filtrado de base de datos, acceso al gestor de bases y separación de cuentas administrativas.

El acceso de los empleados se organiza por roles dentro de Odoo; el acceso de sistemas sigue un circuito distinto y limitado. Una VPN puede ser adecuada para tareas administrativas o aplicaciones de uso exclusivamente interno. Conservamos trazabilidad de cambios y revisamos qué integraciones tienen permisos de lectura o escritura.

Alojar el servidor en Madrid permite conocer la ubicación de esa infraestructura, pero el RGPD no se cumple solo por elegir un CPD español. Correo, conectores, pagos y otros proveedores pueden tratar datos fuera de ese servidor. Se deben revisar encargados del tratamiento, contratos, minimización, accesos y transferencias cuando existan. La configuración funcional también influye en quién puede ver información personal.

Experiencia técnica que acompaña a su ERP

Aclass trabaja en infraestructura y sistemas desde el año 2000. Esa trayectoria importa cuando un ERP depende de varias capas a la vez: aplicación, base de datos, sistema operativo, virtualización, red y almacenamiento. Nuestro equipo técnico no se limita a comprobar que la máquina está encendida: busca en qué capa está el problema y coordina la intervención.

Administramos nuestra plataforma VMware y conocemos el entorno donde se ejecuta su instalación. La experiencia del equipo en servidores, redes y almacenamiento permite interpretar métricas, distinguir falta de recursos de errores de configuración y planificar cambios con un criterio de continuidad. No trasladamos esa experiencia a cifras de proyectos Odoo ni certificaciones que no hemos documentado.

La relación se apoya en un alcance claro, inventario técnico, registro de cambios y coordinación con sus responsables. Su empresa conserva la dirección funcional del ERP; Aclass aporta instalación y mantenimiento técnico. Cuando una incidencia afecta a un módulo de terceros, aportamos el diagnóstico de sistemas para que su desarrollador o implantador pueda actuar con contexto.

Qué necesitamos para preparar su propuesta Odoo

Envíenos edición y versión de Odoo, usuarios simultáneos estimados, módulos, tamaño de PostgreSQL y filestore, integraciones y objetivos de continuidad. Si va a migrar, indique proveedor actual y restricciones de horario. No envíe contraseñas, copias de datos personales ni credenciales por el formulario.

El presupuesto separa recursos del servidor, instalación, mantenimiento técnico, copias y actuaciones extraordinarias. Las licencias Enterprise y los módulos de pago se revisan aparte. La calculadora de VPS sirve para explorar recursos de infraestructura, pero su resultado no representa el precio completo de una instalación Odoo gestionada. La propuesta definitiva se adapta al alcance real.

Servidores para IA

Un servidor para IA no siempre ejecuta un gran modelo: también aloja integraciones, herramientas, colas y agentes que utilizan servicios externos. Aclass ofrece servidores CPU sobre VMware en Madrid para esas cargas empresariales. No ofrecemos servidores GPU. Revisamos proceso, datos, concurrencia y proveedores para decidir qué se ejecuta en el servidor y qué se envía a una plataforma externa.

Qué ofrecemos y qué no en servidores para IA

Nuestra oferta actual es infraestructura CPU e integraciones. Es adecuada para alojar servicios que conectan aplicaciones empresariales con proveedores de inteligencia artificial, ejecutar reglas, preparar datos, mantener colas y registrar la actividad de agentes. El modelo puede operar en la plataforma del proveedor mientras el servidor de Aclass mantiene la lógica de integración.

No ofrecemos GPU, tarjetas NVIDIA dedicadas ni capacidad comercial de entrenamiento de grandes modelos. Tampoco presentamos un VPS CPU como equivalente a un servidor GPU. Si el requisito es entrenar un modelo de gran tamaño o servir inferencia intensiva acelerada, ese requisito no queda cubierto por esta oferta y debe abordarse con otra infraestructura.

El alcance de implantación y mantenimiento se acuerda por proyecto. Separar servidor, software de integración y proveedor del modelo evita presupuestos incompletos: pagar una máquina no incluye automáticamente licencias, tokens, suscripciones ni el desarrollo de todos los conectores. Explicamos esas dependencias antes de proponer una configuración.

CPU, GPU e inferencia: elegir por carga, no por etiqueta

La CPU resuelve lógica general: recibir peticiones, transformar documentos, consultar bases de datos, ejecutar herramientas, controlar permisos y coordinar servicios. La GPU acelera determinados cálculos paralelos de modelos compatibles. Aunque un proyecto utilice un gran modelo externo, muchas de sus tareas de integración siguen siendo cargas CPU.

Inferencia significa utilizar un modelo para obtener una respuesta. Entrenamiento significa ajustar sus parámetros a partir de datos, y el ajuste fino es una forma de adaptación. No son necesidades equivalentes. Un sistema que llama a una API no entrena ni aloja localmente ese modelo por el mero hecho de disponer de un servidor.

Algunos modelos compatibles pueden ejecutarse en CPU, pero la viabilidad depende de tamaño, formato, memoria, contexto y latencia aceptable. No garantizamos tokens por segundo ni concurrencia de modelos sin pruebas. El autoalojamiento CPU, cuando tenga sentido para una prueba acotada, exige comprobar licencia del modelo y software, calidad y carga real; no sustituye nuestra oferta principal de integraciones.

Para inferencia acelerada, la memoria de GPU debe cubrir no solo los pesos del modelo sino también otros consumos, como el contexto y la ejecución concurrente. La cuantización reduce el tamaño de ciertos componentes, pero puede cambiar calidad y compatibilidad. Es información para tomar decisiones, no una promesa de que Aclass suministre GPU o cualquier modelo en cualquier configuración.

ChatGPT, Claude y Perplexity: integración no es autoalojamiento

ChatGPT y Claude son servicios y productos de sus respectivos proveedores. Su uso empresarial y sus APIs tienen condiciones, capacidades y facturación específicas. Una integración autorizada puede conectarse a las APIs de OpenAI o Anthropic, pero no instala ChatGPT o Claude dentro de un VPS de Aclass. La cuenta del servicio y la cuenta de API tampoco deben considerarse intercambiables sin revisar sus condiciones.

Perplexity aporta servicios de investigación y APIs según su oferta vigente. Microsoft Copilot trabaja dentro de productos y permisos del ecosistema Microsoft; no es una aplicación genérica que instalemos en un servidor CPU. Evaluamos las integraciones que cada proveedor permite y las licencias necesarias, sin afirmar que cualquier función de la interfaz comercial esté disponible mediante API.

OpenClaw es una plataforma de agentes, no un modelo de lenguaje. El modelo que utilice, sus herramientas y sus permisos son decisiones separadas. Los proyectos con agentes requieren aislamiento, credenciales mínimas, restricciones de ejecución y revisión humana; una instalación sin esos controles puede abrir acceso innecesario a datos o sistemas.

Modelos de pesos disponibles para despliegue propio constituyen otro escenario: requieren verificar licencias, memoria, compatibilidad y rendimiento. No todos son software libre ni todos admiten uso comercial bajo las mismas condiciones. Nuestra recomendación se basa en el objetivo y las restricciones del cliente, no en confundir marcas conocidas con software autoalojable.

Arquitectura para agentes, documentos e integraciones

Un entorno empresarial útil separa entrada de datos, procesamiento, consulta al proveedor, validación y acción final. Las colas absorben picos; los límites controlan llamadas y gasto; los registros permiten investigar fallos. Los reintentos tienen que ser seguros: volver a ejecutar un proceso no debe crear dos pedidos ni enviar el mismo mensaje varias veces.

En una solución de recuperación aumentada, o RAG, el sistema busca fragmentos relevantes en fuentes y se los proporciona al modelo. No garantiza que la respuesta sea correcta. Es necesario preservar los permisos de los documentos, validar fuentes y evaluar preguntas sin respuesta. Una búsqueda vectorial que devuelve información de otro departamento es un fallo de acceso, aunque la respuesta parezca útil.

El servidor puede alojar conectores y servicios de búsqueda compatibles, pero el diseño concreto depende del tamaño documental, la frecuencia de actualización, los usuarios y las tecnologías elegidas. Determinamos qué componentes se necesitan realmente para evitar una arquitectura demasiado compleja para un piloto pequeño.

Cuando una integración afecta al ERP, conviene desacoplar sus tareas del servidor de producción para que un pico de consultas de IA no compita con facturación o inventario. La página de servidores Odoo explica el mantenimiento técnico del ERP; la integración de IA se analiza con sus propios permisos, límites y criterios de aceptación.

Cómo dimensionamos un servidor CPU para IA

Pedimos solicitudes por periodo, usuarios simultáneos, tamaño de los documentos, pasos del proceso y tiempo máximo aceptable. Una API lenta no se arregla añadiendo memoria al VPS, del mismo modo que un proceso bloqueado por límites del proveedor no mejora ampliando CPU. Monitorizamos cada tramo para identificar el verdadero cuello de botella.

La CPU se decide por el trabajo local; la memoria, por servicios, índices y documentos en proceso; el almacenamiento, por fuentes, registros y crecimiento. También se revisan transferencia, conectividad y capacidad de la base de datos. El entorno se despliega sobre la plataforma VMware de Aclass, con discos NVMe, y se prueba con una carga representativa.

Para una estimación económica separamos infraestructura, implantación, operación y consumo externo. Medimos coste por tarea útil, errores, excepciones y tiempo humano de revisión, no solo número de llamadas. El consumo de una API o una licencia del proveedor no está incluido automáticamente en el precio del servidor.

Datos, seguridad y continuidad: lo que hay que verificar

El servidor de Aclass está en Madrid. Si una integración envía información a una API externa, ese tratamiento no pasa a ocurrir en España por tener el conector alojado aquí. Documentamos las fuentes, los destinatarios, las ubicaciones y las condiciones del proveedor para cada proyecto. No ofrecemos una garantía general de residencia europea para todas las plataformas.

Aplicamos el principio de acceso mínimo en la arquitectura acordada: cuentas diferenciadas, credenciales protegidas, herramientas permitidas y separación de entornos. Revisamos qué se conserva en registros y evitamos incluir datos personales o secretos innecesarios. Un texto recibido en un documento no debe poder convertirse en una instrucción para cambiar permisos o extraer información.

Las acciones sensibles, como pagos, cambios de datos o comunicaciones definitivas, requieren reglas explícitas y aprobación humana cuando corresponda. Se establecen límites de coste, tiempos de espera, circuitos de excepción y parada. La trazabilidad permite saber qué pidió el usuario, qué fuentes se consultaron y qué acción se autorizó sin almacenar más datos de los necesarios.

La continuidad contempla copias de configuración y datos, recuperación de servicios y dependencia del proveedor externo. Si su API falla, el proceso debe poder esperar, informar o volver a un procedimiento manual. Retenciones, RPO y RTO se acuerdan por proyecto. Ni el RGPD ni otras obligaciones legales quedan resueltas automáticamente por instalar un servidor: deben revisarse contratos, finalidad y riesgos.

El conocimiento técnico de Aclass, detrás de cada integración

Desde el año 2000, Aclass acompaña a empresas en la operación de servidores e infraestructura. Esa experiencia es especialmente valiosa en proyectos de IA que combinan servicios, bases de datos, almacenamiento, permisos y redes. La calidad de una integración no depende solo del modelo: depende también de que los componentes funcionen de forma mantenible.

Nuestro equipo conoce y administra la plataforma VMware donde se alojan las cargas. Aporta diagnóstico de sistemas, planificación de capacidad y criterio para separar fallos del servidor de errores del conector o límites del proveedor. Coordinamos los cambios y documentamos responsabilidades en lugar de atribuir todos los problemas a la inteligencia artificial.

La experiencia histórica es en infraestructura y sistemas; no la convertimos en años de trabajo con plataformas recientes ni en certificaciones de fabricantes no acreditadas. En IA partimos de un caso definido, pruebas y métricas. El cliente debe poder comprender los límites de la solución, el mantenimiento necesario y cómo detener un proceso si deja de ser útil o seguro.

Del caso de uso al presupuesto de infraestructura IA

Cuéntenos qué proceso necesita mejorar, qué aplicaciones intervienen, qué datos se pueden utilizar y quién aprueba el resultado. Añada volumen aproximado de tareas, plataforma elegida si existe y requisitos de privacidad. No envíe claves API ni documentación confidencial en el formulario inicial.

La propuesta identifica componentes locales, servicios externos, responsables, coste de infraestructura y alcance de implantación. Si la necesidad requiere GPU, se indicará expresamente que nuestra oferta actual no la cubre. Si encaja con CPU e integraciones, definimos pruebas de aceptación y un camino hacia producción con controles y mantenimiento acordados.