Cómo instalar Microsoft Garnet en Ubuntu 24.04

Garnet es un servidor de caché en memoria desarrollado por Microsoft Research que habla el protocolo RESP de Redis, así que funciona con redis-cli y con las librerías cliente de Redis que ya usas. Está escrito en C# sobre .NET y destaca por su rendimiento con muchas conexiones concurrentes. En este tutorial instalarás Garnet en Ubuntu 24.04 como herramienta .NET, lo ejecutarás como servicio systemd con un usuario propio, protegerás el acceso con contraseña, activarás la persistencia y medirás su rendimiento con redis-benchmark.

Requisitos previos

Un servidor con Ubuntu 24.04 LTS, por ejemplo un VPS de CubePath.
Un usuario no root con privilegios sudo.
Al menos 2 GB de RAM. Garnet reserva la memoria que le indiques, así que dimensiónala según los datos que vayas a guardar.
El puerto 6379 libre. Si tienes Redis instalado, detenlo o usa otro puerto para Garnet.

Paso 1: Instalar el SDK de .NET 8

Garnet se distribuye como herramienta .NET (garnet-server) en NuGet y para instalarla necesitas el SDK. Ubuntu 24.04 incluye .NET 8 en sus repositorios oficiales, así que no hace falta añadir el repositorio de Microsoft:

sudo apt update
sudo apt install dotnet-sdk-8.0

Comprueba que el SDK está disponible:

dotnet --list-sdks

8.0.120 [/usr/lib/dotnet/sdk]

El número de versión exacto variará. Lo importante es que aparezca un SDK 8.0 instalado en /usr/lib/dotnet, la ruta que usan los paquetes de Ubuntu.

Paso 2: Instalar Garnet

Instala la herramienta en un directorio fijo del sistema, /opt/garnet, en lugar de en el perfil de tu usuario. Así el servicio podrá ejecutarla con un usuario sin privilegios:

sudo dotnet tool install garnet-server --tool-path /opt/garnet

You can invoke the tool using the following command: garnet-server
Tool 'garnet-server' (version '1.0.x') was successfully installed.

Instala también redis-tools, que trae redis-cli y redis-benchmark sin instalar el servidor de Redis:

sudo apt install redis-tools

Haz una prueba rápida en primer plano. La variable DOTNET_ROOT indica al ejecutable dónde está el runtime de .NET:

DOTNET_ROOT=/usr/lib/dotnet /opt/garnet/garnet-server --bind 127.0.0.1 --port 6379

Garnet muestra su logotipo y los parámetros con los que arranca. Desde otra terminal, comprueba que responde:

redis-cli ping

PONG

Vuelve a la primera terminal y detén Garnet con Ctrl+C.

Paso 3: Crear el usuario, los directorios y la configuración

Crea un usuario de sistema para Garnet y el directorio donde guardará los checkpoints y el registro AOF:

sudo useradd --system --home-dir /var/lib/garnet --shell /usr/sbin/nologin garnet
sudo install -d -o garnet -g garnet -m 750 /var/lib/garnet
sudo install -d -m 755 /etc/garnet

Garnet acepta un archivo de configuración en formato JSON con la opción --config-import-path. Guardar ahí la contraseña evita que aparezca en la lista de procesos. Crea el archivo:

sudo nano /etc/garnet/garnet.conf

{
  "Port": 6379,
  "Address": "127.0.0.1",
  "AuthenticationMode": "Password",
  "Password": "your_strong_password",
  "CheckpointDir": "/var/lib/garnet",
  "LogDir": "/var/lib/garnet",
  "EnableAOF": true,
  "Recover": true
}

Sustituye your_strong_password por una contraseña larga y aleatoria; puedes generar una con openssl rand -base64 32. Estas son las claves que usas:

Clave	Función
`Address`	IP en la que escucha. Por defecto Garnet escucha en todas las interfaces, por eso la limitamos a `127.0.0.1`.
`AuthenticationMode` y `Password`	Obligan a los clientes a enviar `AUTH` con la contraseña.
`CheckpointDir`	Directorio donde se guardan los checkpoints creados con `SAVE` o `BGSAVE`.
`EnableAOF`	Activa el registro de escritura anticipada (append-only file) para no perder escrituras tras un reinicio.
`Recover`	Al arrancar, recupera el último checkpoint y reproduce el AOF.

Como el archivo contiene la contraseña, restringe sus permisos para que solo root y el grupo garnet puedan leerlo:

sudo chown root:garnet /etc/garnet/garnet.conf
sudo chmod 640 /etc/garnet/garnet.conf

Paso 4: Crear el servicio systemd

Crea la unidad del servicio:

sudo nano /etc/systemd/system/garnet.service

[Unit]
Description=Garnet cache server
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=garnet
Group=garnet
Environment=DOTNET_ROOT=/usr/lib/dotnet
WorkingDirectory=/var/lib/garnet
ExecStart=/opt/garnet/garnet-server --config-import-path /etc/garnet/garnet.conf --memory 1g --index 64m
Restart=on-failure
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

Los tamaños de memoria se pasan como parámetros de línea de comandos porque sus nombres en el archivo JSON han cambiado entre versiones de Garnet, mientras que --memory (memoria del registro principal) e --index (tamaño del índice hash) se mantienen. El valor por defecto de --memory es alto, así que ajústalo a la RAM de tu servidor. Consulta todas las opciones de tu versión con /opt/garnet/garnet-server --help.

Carga la unidad y arranca el servicio:

sudo systemctl daemon-reload
sudo systemctl enable --now garnet

Comprueba su estado:

systemctl status garnet --no-pager

● garnet.service - Garnet cache server
     Loaded: loaded (/etc/systemd/system/garnet.service; enabled; preset: enabled)
     Active: active (running) since Thu 2026-09-24 10:12:03 UTC; 5s ago

Verifica que solo escucha en localhost:

sudo ss -tlnp | grep 6379

LISTEN 0      512        127.0.0.1:6379       0.0.0.0:*    users:(("garnet-server",pid=4121,fd=180))

Paso 5: Conectarse y probar la compatibilidad con Redis

Sin contraseña, cualquier comando devuelve un error de autenticación. Para no escribir la contraseña en la línea de comandos, redis-cli la lee de la variable REDISCLI_AUTH:

export REDISCLI_AUTH='your_strong_password'
redis-cli ping

PONG

Prueba los tipos de datos más habituales. Una clave con caducidad, como una sesión de usuario:

redis-cli set sesion:1001 '{"user":"ana"}' EX 3600
redis-cli ttl sesion:1001

OK
(integer) 3600

Un contador, un hash y una lista:

redis-cli incr visitas:home
redis-cli hset usuario:1001 nombre Ana plan pro
redis-cli hgetall usuario:1001
redis-cli lpush cola:emails msg1 msg2
redis-cli rpop cola:emails

(integer) 1
(integer) 2
1) "nombre"
2) "Ana"
3) "plan"
4) "pro"
(integer) 2
"msg1"

Garnet también soporta sets, sorted sets, pub/sub, transacciones y scripts Lua (este último con la opción --lua). Antes de migrar una aplicación, revisa en la documentación de Garnet la lista de comandos soportados, ya que no implementa el 100 % de los comandos de Redis.

Paso 6: Comprobar la persistencia

Con EnableAOF y Recover activos, los datos deben sobrevivir a un reinicio. Crea un checkpoint, reinicia el servicio y consulta una clave:

redis-cli save
sudo systemctl restart garnet
redis-cli get visitas:home

OK
"1"

Los ficheros del checkpoint y del AOF quedan en /var/lib/garnet. Inclúyelo en tus copias de seguridad si los datos de Garnet no se pueden regenerar desde otra fuente.

Paso 7: Medir el rendimiento con redis-benchmark

redis-benchmark sirve igual contra Garnet. Esta prueba lanza 100 000 operaciones SET y GET con 50 clientes y pipelines de 16 comandos:

redis-benchmark -h 127.0.0.1 -p 6379 -a "$REDISCLI_AUTH" -t set,get -n 100000 -c 50 -P 16 -q

SET: 892857.12 requests per second, p50=0.767 msec
GET: 1111111.12 requests per second, p50=0.599 msec

Las cifras dependen de los núcleos de CPU del servidor. Para comparar con Redis, ejecuta la misma prueba contra un Redis en otro puerto y con los mismos parámetros.

Paso 8: Permitir conexiones desde otros servidores (opcional)

Si tus aplicaciones se ejecutan en otro servidor, no expongas Garnet a Internet. Haz que escuche en la IP de tu red privada, por ejemplo 10.0.0.10, cambiando la clave Address en /etc/garnet/garnet.conf:

"Address": "10.0.0.10",

Reinicia el servicio y abre el puerto en UFW solo para la IP del servidor de aplicaciones:

sudo systemctl restart garnet
sudo ufw allow from 10.0.0.20 to any port 6379 proto tcp

Desde el servidor de aplicaciones, comprueba la conexión:

redis-cli -h 10.0.0.10 -a 'your_strong_password' ping

PONG

Si el tráfico tiene que salir de una red privada, activa TLS con las opciones --tls y --cert-file-name descritas en garnet-server --help.

Solución de problemas

El servicio no arranca y el log dice que no encuentra .NET: falta la variable DOTNET_ROOT o apunta a una ruta incorrecta. Confirma la ruta con dotnet --list-runtimes y revisa la línea Environment= de la unidad.

Address already in use: otro proceso ocupa el puerto 6379, normalmente un redis-server. Identifícalo con sudo ss -tlnp | grep 6379 y detenlo con sudo systemctl disable --now redis-server, o cambia Port en la configuración.

Error al leer la configuración: el JSON no es válido (una coma de más, comillas tipográficas) o el usuario garnet no puede leer el archivo. Consulta el motivo con sudo journalctl -u garnet -n 50 --no-pager.

Se acaba la memoria: reduce --memory en la unidad, recarga con sudo systemctl daemon-reload y reinicia. Usa TTL en las claves de caché para que no crezcan sin límite.

Conclusión

Tienes Garnet funcionando como servicio systemd en Ubuntu 24.04, escuchando solo en local, con contraseña, persistencia mediante checkpoints y AOF, y verificado con las herramientas estándar de Redis. Cualquier aplicación que use un cliente de Redis puede apuntar a él sin cambios de código.

Como siguientes pasos puedes:

Sustituir la contraseña única por usuarios con permisos distintos usando el modo ACL y un archivo --acl-file.
Probar el modo clúster (--cluster) con varios nodos si necesitas repartir los datos.
Medir el rendimiento con tu carga real (tamaños de valor y proporción de lecturas) antes de sustituir un Redis en producción.

On this page