Cómo correr dos servidores de MU Online en la misma máquina

Correr dos servidores de MU Online completamente independientes en la misma máquina es una necesidad común: alojar un servidor "principal" y uno de "pruebas", operar un servidor Season 6 clásico al lado de un servidor de rates altas, o simplemente aprovechar una VPS robusta para dos proyectos distintos. La buena noticia es que MU Online es perfectamente capaz de esto — la arquitectura de procesos (DataServer, JoinServer, GameServer, ConnectServer) es modular y cada instancia puede tener sus propios puertos, sus propios archivos de configuración y su propia base. La mala noticia es que cualquier descuido en puertos duplicados, DSN compartida por error o base cruzada genera conflictos frustrantes, con procesos que no levantan, personajes desapareciendo o dos servidores grabando en la misma base. Esta guía muestra cómo montar dos instancias verdaderamente aisladas, cubriendo puertos distintos, bases/instancias de SQL, ConnectServer y GameServer separados, dimensionamiento de recursos y cómo diagnosticar los conflictos más comunes.

Diferencia entre "dos servidores" y "subservers"

Antes que nada, alinea el concepto, porque las dos cosas se confunden frecuentemente:

• Subservers / channels (multi-server): varios GameServers que comparten la misma base y aparecen juntos en la pantalla de selección. El personaje es el mismo en cualquier channel. Esto trata sobre capacidad y balanceo de un único proyecto.
• Dos servidores independientes (este tutorial): dos proyectos separados, cada uno con su propia base, sus cuentas, sus personajes y su ConnectServer. Un jugador con cuenta en el Servidor A no tiene nada en el Servidor B.

Si tu objetivo es aumentar la capacidad de un solo servidor, quieres subservers. Si quieres dos mundos separados, es esto de aquí.

Requisitos previos

• Una máquina (VPS o dedicado) con holgura de recursos — correr dos servidores exige, en la práctica, casi el doble de RAM y CPU de uno. Trata 4 GB y 2 vCPUs como el mínimo absoluto para dos servidores pequeños; más es mejor.
• Windows Server (2016/2019/2022 son comunes) con acceso administrativo.
• SQL Server instalado y funcional, con permiso para crear una segunda base (o una segunda instancia).
• Dos packs/emuladores ya descargados — pueden ser de la misma Season o de Seasons diferentes.
• ODBC Data Source Administrator (32-bit) accesible, pues la mayoría de los emuladores usa DSN de 32 bits.
• Backup de cualquier servidor ya existente antes de tocar nada.
• Un buen control mental (o en planilla) del mapa de puertos, que es el corazón de este proceso.

> La causa número uno de fracaso aquí es reutilizar archivos de configuración del Servidor A en el Servidor B sin cambiar los puertos y la DSN. Siempre revisa config por config en el segundo servidor.

Planeando el mapa de puertos

Como los dos servidores viven en el mismo IP, cada puerto en uso necesita ser único entre ellos. Planea esto antes de tocar cualquier archivo. Los puertos exactos varían según el emulador, así que trata la tabla de abajo como un ejemplo de organización — lo importante es el principio de rangos separados:

Una buena práctica es desplazar el segundo servidor por un bloque fijo (ej.: +10 o +100) en todos los puertos, para que sea fácil de recordar. Los valores anteriores son ilustrativos; usa el encabezado de los archivos de tu emulador para saber los nombres reales de las claves.

Paso 1 — Estructura de carpetas aislada

Nunca mezcles los dos servidores en la misma carpeta. Crea árboles completamente separados:

E:\MU\
├── ServidorA\
│   ├── DataServer\
│   ├── JoinServer\
│   ├── GameServer\
│   └── ConnectServer\
└── ServidorB\
    ├── DataServer\
    ├── JoinServer\
    ├── GameServer\
    └── ConnectServer\

Cada carpeta tiene su propio conjunto de binarios y configs. Esto evita que una actualización en uno afecte al otro y hace que el backup sea trivial (basta copiar la carpeta raíz de cada uno).

Paso 2 — Bases de datos separadas

Tienes dos opciones:

Opción A — Dos bases en la misma instancia (recomendado para la mayoría)

Más simple y ligero. En la misma instancia de SQL Server, restaura/crea dos bases con nombres distintos:

-- Crear las dos bases (o restaurar de backups de tu pack)
CREATE DATABASE MuOnlineA;
CREATE DATABASE MuOnlineB;
GO

-- Verifica que ambas existen
SELECT name, database_id, create_date
FROM sys.databases
WHERE name IN ('MuOnlineA', 'MuOnlineB');

Después configura dos DSNs ODBC 32-bit distintas, una apuntando a cada base:

ODBC (32-bit):
- DSN "MuOnlineA"  ->  base MuOnlineA
- DSN "MuOnlineB"  ->  base MuOnlineB

Opción B — Dos instancias de SQL Server

Vale la pena si necesitas aislamiento fuerte de recursos, versiones diferentes de SQL Server, o límites de memoria por instancia. Cada instancia tiene su propio puerto (ej.: instancia predeterminada en 1433, instancia nombrada SQLEXPRESS2 en otro puerto). Es más pesado y más complejo de mantener — solo elígelo si tienes un motivo concreto.

> Cuidado clásico: apuntar las dos DSNs (o los dos DataServers) a la misma base por error. Si eso pasa, los dos servidores graban personajes en la misma base y tendrás corrupción lógica de datos. Verifica DSN por DSN.

Paso 3 — Configurar el Servidor A

Ajusta los archivos del Servidor A con sus puertos y su DSN. Ejemplos genéricos (las claves varían según el emulador):

; ServidorA\DataServer\DataServer.ini
[DataServer]
DataServerPort=55557
[Database]
DSN=MuOnlineA

; ServidorA\GameServer\GameServer.ini
[Network]
GameServerPort=55901
[JoinServer]
JoinServerIP=127.0.0.1
JoinServerPort=55555
[Database]
DSN=MuOnlineA

; ServidorA\ConnectServer\ConnectServer.ini
[ConnectServer]
Port=44405
[GameServer1]
IP=SEU_IP_PUBLICO
Port=55901

Paso 4 — Configurar el Servidor B (el paso donde todos se equivocan)

Ahora repite para el Servidor B, pero cambiando todos los puertos y la DSN. Es aquí donde la mayoría de los principiantes falla al copiar los archivos del A sin revisar:

; ServidorB\DataServer\DataServer.ini
[DataServer]
DataServerPort=55567         ; <- diferente del A
[Database]
DSN=MuOnlineB                ; <- base diferente

; ServidorB\GameServer\GameServer.ini
[Network]
GameServerPort=55911         ; <- diferente del A
[JoinServer]
JoinServerIP=127.0.0.1
JoinServerPort=55565         ; <- diferente del A
[Database]
DSN=MuOnlineB

; ServidorB\ConnectServer\ConnectServer.ini
[ConnectServer]
Port=44415                   ; <- diferente del A
[GameServer1]
IP=SEU_IP_PUBLICO
Port=55911

Revisa línea por línea: si cualquier puerto coincide con el del Servidor A, el proceso del B no levantará.

Paso 5 — Firewall y puertos públicos

Abre en el firewall solo los puertos que los jugadores necesitan alcanzar (ConnectServer y GameServer de cada servidor). Los puertos de DataServer y JoinServer son internos y deben permanecer cerrados para internet:

# Servidor A - puertos públicos
netsh advfirewall firewall add rule name="MU-A Connect" dir=in action=allow protocol=TCP localport=44405
netsh advfirewall firewall add rule name="MU-A Game"    dir=in action=allow protocol=TCP localport=55901

# Servidor B - puertos públicos
netsh advfirewall firewall add rule name="MU-B Connect" dir=in action=allow protocol=TCP localport=44415
netsh advfirewall firewall add rule name="MU-B Game"    dir=in action=allow protocol=TCP localport=55911

# DataServer/JoinServer (55557,55555,55567,55565): NO abrir para internet

Paso 6 — Orden de inicialización

Cada servidor levanta en el orden canónico, y arrancas un servidor completo antes del otro para facilitar el diagnóstico. Un .bat por servidor ayuda:

@echo off
echo Iniciando Servidor A...
start "" "E:\MU\ServidorA\DataServer\DataServer.exe"
timeout /t 3
start "" "E:\MU\ServidorA\JoinServer\JoinServer.exe"
timeout /t 3
start "" "E:\MU\ServidorA\GameServer\GameServer.exe"
timeout /t 5
start "" "E:\MU\ServidorA\ConnectServer\ConnectServer.exe"
echo Servidor A en el aire.

Haz un IniciarB.bat equivalente apuntando a la carpeta ServidorB. Levanta el A, confirma que está estable, y solo entonces levanta el B.

Dimensionamiento de recursos y conflictos

Dos servidores en la misma máquina compiten por CPU, RAM, disco y red. Puntos de atención:

• RAM: cada GameServer y el SQL Server consumen memoria. Configura el max server memory del SQL Server para que no engulla toda la RAM y ahogue a los GameServers.
• CPU: en VPS con pocas vCPUs, un evento pesado en el Servidor A puede causar lag en el B. Si es posible, usa afinidad de CPU para separar cargas.
• Disco: las dos bases graban en el mismo disco; un SSD es prácticamente obligatorio para dos servidores.
• Puertos efímeros/DSN: revalida que no haya solapamiento alguno. Usa netstat -ano | findstr LISTENING para verificar qué ya está escuchando antes de levantar el segundo servidor.

Errores comunes y soluciones

Lista de verificación de lanzamiento

• Máquina dimensionada con holgura de RAM/CPU/disco para dos servidores
• Backup de cualquier servidor preexistente hecho
• Mapa de puertos planeado y documentado (sin solapamiento)
• Carpetas totalmente separadas para Servidor A y Servidor B
• Dos bases creadas (o dos instancias) y verificadas
• Dos DSNs ODBC 32-bit distintas, cada una en la base correcta
• Configs del Servidor A revisadas (puertos + DSN A)
• Configs del Servidor B revisadas línea a línea (puertos + DSN B)
• Firewall abriendo solo ConnectServer y GameServer de cada servidor
• Puertos internos (DataServer/JoinServer) cerrados para internet
• .bat de inicialización para cada servidor, en el orden correcto
• Servidor A levanta y se estabiliza solo antes de levantar el B
• Prueba de cuenta: crear personaje en el A y confirmar que NO aparece en el B
• Prueba de carga: evento en uno sin tumbar al otro
• max server memory del SQL Server limitado para no ahogar a los GameServers

Con puertos únicos, bases separadas y carpetas aisladas, dos servidores de MU Online conviven tranquilamente en la misma máquina. El secreto es la disciplina: planea el mapa de puertos antes, revisa el segundo servidor archivo por archivo y valida el aislamiento con pruebas reales de cuenta y de carga antes de abrir a los jugadores.

Preguntas frecuentes