Porque sí, porque con el magnífico servidor que tenemos nos lo podemos permitir.
jueves, 1 de octubre de 2020
Tras recibir (y criticar) el informe del servidor actual hecho por el muchacho externo decidimos que de momento sólo nos podíamos permitir comprar un disco SSD y realizar allí una instalación de una máquina (una Debian 10) con el servidor de bases de datos que se nos pedía.
La instalación del disco físico fue como siempre: incómoda. La caja es grande y cómoda pero la placa base es de servidor y tiene conectores SATA de datos muy especiales. Menos mal que quedaba uno libre y pude situar el disco (con su adaptador) en lo alto de la pila de los otros. La máquina arranca y lo reconoce sin problemas.
Luego vino el proceso de creación de la máquina virtual. Al ser una versión antigua de Ubuntu pensé que podría tener problemas en encontrar una versión de libvirtd que funcionase, pero no, el entorno es funcional y muy práctica. Como mi usuario pertenece al grupo libvirtd pues he podido conectarme con el programa virt-manager sin problemas en remoto.
Con respecto al almacenamiento entonces sólo decir que tuve que crear un recurso específico (silo lo llaman en la traducción) de tipo disco, crear una partición en el disco nuevo (/dev/sda1) y asignarlo a dicho silo.
Ahora tengo una duda curiosa sobre este montaje. La máquina virtual está empleando un esquema de disco virtual sobre una partición de un disco físico real SSD. Dudé al principio si aplicar todas las medidas que suelen recomendar con estos dispositivos porque no estaba seguro de que funcionasen siendo, en el fondo, un disco virtual. Al final me decanté con definir las opciones siguientes en el montaje porque se quiera o no está trabajando sobre un SSD:
- noatime
- Desactivamos la escritura de la fecha de acceso en el disco
- discard
- Mecanismo TRIM contínuo
- nodelaloc
- Desactivar asignación de espacio vacío sin escribirlo.
- barriend=0
- Reducción del número de barridos de escritura
- commit=30
- Retrasa la escritura de metadatos
Y ya veremos cómo funciona o si tenemos algún problema. Lo terrible de estos discos SSD es que se mueren de forma repentina y más te vale haber creado copias completas o será muy complicado volver a ponerlo en marcha.
La red presentaba otro problema. Generalmente qemu y derivados crean su propia red interna para las máquinas, con su puente, su servidor DHCP y algunas cosas más. Eso funciona bien excepto cuando quieres que la máquina virtual nueva tenga su IP dentro de la red normal para que los demás le vean como un igual y tenga acceso directo a él. De la otra forma qemu crea un NAT y la cosa se complica.
Siguiendo las recomendaciones de Fabian Lee he creado un puente de red y le he añadido al entorno libvirt. Primero creo un archivo con lo básico de la definción:
<network>
<name>host-bridge</name>
<forward mode="bridge"/>
<bridge name="br0"/>
</network>Luego creo el puente de red en la configuración del sistema porque me interesa que tanto el interfaz físico como el virtual permitan tránsito entre ellas.
auto br0
iface br0 inet static
address 192.168.100.9
netmask 255.255.255.0
network 192.168.100.0
broadcast 192.168.100.255
gateway 192.168.100.1
dns-nameservers 192.168.100.1 192.168.100.3 192,168.100.7
dns-domain venexma.net
bridge-ports eno1
bridge-stp off
bridge-maxwait 0
bridge-fd 0
Después configuro libvirtd para la red:
$ sudo virsh net-define host-bridge.xml
$ sudo virsh net-start host-bridge
$ sudo virsh net-autostart host-bridge
$ sudo virsh net-list --all
Nombre Estado Inicio automático Persistente
----------------------------------------------------------
host-bridge activo si si
$ Cuando pongo en marcha la creación de la red previsamente he descargado la útlimoa ISO (Debian 10.6) y le digo que arranque de allí.
No ha habido problemas. Red con IP fija (ya retoqué el servidor DNS antes) y enrutado directo a cualquier parte de la red.
El desempeño es muy, pero que muy bueno. Como me ha falta una cable SATA interno no he podido poner el disco mecánico para guardar archivos auxilares de Postgres como los WAL.
He tomado algunas medidas básicas de seguridad como anular acceso como root y anular la entrada de contraseñas también por ese medio. Instalar mi fiel etckeeper para controlar el directorio /etc y poco más.
Respecto al servidor de bases de datos PostgreSQL he seguido las indicaciones de este artículo y activado los repositorios propios de Postgres. No ha habido problemas en tener la versión 12 correctamente instalada.
Así que el servidor principal tiene un puente de red con su interfaz físico y el virtual y la máquina virtual puede tener IP fija y tránsito en todos los sentidos.