|
|
|
# Agregar un nuevo servidor como nodo del cluster Proxmox
|
|
|
|
|
|
|
|
Para responder a la carga de servicios y en función de la disponibilidad de recursos, se pueden agregar nuevos servidores a la plataforma de la Red de Unidades Informátivas del Interior. La presente guí se inicia en ocasión de la configuración del nuevo servidor `guyunusa.interior.edu.uy` adquirido por la Comisión Sectorial de Extensióon y Acción en el Medio (CSEAM).
|
|
|
|
|
|
|
|
* Primero se le asignan la IPv4 e IPv6 en la VLAN NUBE de conexión a internet, así como la IPv6 de la red de cluster y se configuran los nombres de dominio:
|
|
|
|
```
|
|
|
|
<new_serv>.interior.edu.uy has address 164.73.XX.YYY
|
|
|
|
<new_serv>.interior.edu.uy has IPv6 address 2001:1328:ZZ::YYY
|
|
|
|
|
|
|
|
<new_serv>-10g.interior.edu.uy has IPv6 address 2001:1328:ZZ:TT::YYY
|
|
|
|
```
|
|
|
|
* luego, en datacenter, se instala físicamente el servidor, con cables UTP categoría 6, entre una intefaz ethernet 1Gb/s del servidor y una del VLAN NUBE del switch así como entre una interfaz 10Gb a una de la VLAN NAS del switch.
|
|
|
|
* se instala el sistema operativo de virtualización Proxmox desde la última versión de patch de la versión menor utilizada en el cluster (Proxmox 6.1, a la hora de escribir este mnanual), configurando:
|
|
|
|
* la IPv4 asignada,
|
|
|
|
* una contraseña root temporaria recordada por quién instala el servidor
|
|
|
|
* Eso es todo en datacenter: verificado el acceso por ssh, se podrá seguir on-line.
|
|
|
|
|
|
|
|
* Se puede terminar la configuración a distancia, por ssh. Pero OjO: pusimos sólo la IPv4, si accedemos desde una máquina con IPv6 (por ejemplo desde el VPN) si no se especifica IPv4 el servidor parece no existir (con ping por ejemplo). Será necesario explicitar un acceso IPv4:
|
|
|
|
```
|
|
|
|
ssh -4 root@<new_serv>.interior.edu.uy
|
|
|
|
```
|
|
|
|
* Conviene en primer lugar completar la configuración de la red, con la IPv6 y la segunda interfaz. Modificamos `/etc/network/interfaces`:
|
|
|
|
```
|
|
|
|
auto lo
|
|
|
|
iface lo inet loopback
|
|
|
|
|
|
|
|
iface eno1 inet manual
|
|
|
|
|
|
|
|
iface eno2 inet manual
|
|
|
|
|
|
|
|
iface ens2f0 inet manual
|
|
|
|
|
|
|
|
iface ens2f1 inet manual
|
|
|
|
|
|
|
|
# iface enp0s20f0u1u6 inet manual
|
|
|
|
|
|
|
|
auto vmbr0
|
|
|
|
iface vmbr0 inet static
|
|
|
|
address 164.73.XX.YYY
|
|
|
|
netmask 255.255.255.0
|
|
|
|
gateway 164.73.XX.1
|
|
|
|
bridge_ports eno1
|
|
|
|
bridge_stp off
|
|
|
|
bridge_fd 0
|
|
|
|
|
|
|
|
iface vmbr0 inet6 static
|
|
|
|
address 2001:1328:ZZ::YYY
|
|
|
|
netmask 64
|
|
|
|
gateway 2001:1328:ZZ::1
|
|
|
|
|
|
|
|
auto vmbr1
|
|
|
|
iface vmbr1 inet6 static
|
|
|
|
address 2001:1328:ZZ:TT::YYY
|
|
|
|
netmask 64
|
|
|
|
bridge-ports ens2f1
|
|
|
|
bridge-stp off
|
|
|
|
bridge-fd 0
|
|
|
|
```
|
|
|
|
Pudiendo cambiar los nombres de interfaz en función de lo que determina el firmware del servidor. Reiniciamos con un reboot, y luego constatamos el ping desde todas y hacia todas las interfaces:
|
|
|
|
```
|
|
|
|
root@<new_serv>:~# ping guri
|
|
|
|
PING guri(guri.interior.edu.uy (2001:1328:ZZ::A)) 56 data bytes
|
|
|
|
64 bytes from guri.interior.edu.uy (2001:1328:ZZ::A): icmp_seq=1 ttl=64 time=0.337 ms
|
|
|
|
^C
|
|
|
|
--- guri ping statistics ---
|
|
|
|
1 packets transmitted, 1 received, 0% packet loss, time 0ms
|
|
|
|
rtt min/avg/max/mdev = 0.337/0.337/0.337/0.000 ms
|
|
|
|
root@<new_serv>:~# ping guri-10g
|
|
|
|
PING guri-10g(2001:1328:ZZ:TT::A (2001:1328:ZZ:TT::A)) 56 data bytes
|
|
|
|
64 bytes from 2001:1328:ZZ:TT::A (2001:1328:ZZ:TT::A): icmp_seq=1 ttl=64 time=0.293 ms
|
|
|
|
64 bytes from 2001:1328:ZZ:TT::A (2001:1328:ZZ:TT::A): icmp_seq=2 ttl=64 time=0.138 ms
|
|
|
|
^C
|
|
|
|
--- guri-10g ping statistics ---
|
|
|
|
2 packets transmitted, 2 received, 0% packet loss, time 12ms
|
|
|
|
rtt min/avg/max/mdev = 0.138/0.215/0.293/0.078 ms
|
|
|
|
root@<new_serv>:~# ping -4 guri
|
|
|
|
PING guri.interior.edu.uy (164.73.XX.A) 56(84) bytes of data.
|
|
|
|
64 bytes from guri.interior.edu.uy (164.73.XX.A): icmp_seq=1 ttl=64 time=0.164 ms
|
|
|
|
64 bytes from guri.interior.edu.uy (164.73.XX.A): icmp_seq=2 ttl=64 time=0.150 ms
|
|
|
|
^C
|
|
|
|
--- guri.interior.edu.uy ping statistics ---
|
|
|
|
2 packets transmitted, 2 received, 0% packet loss, time 2ms
|
|
|
|
rtt min/avg/max/mdev = 0.150/0.157/0.164/0.007 ms
|
|
|
|
|
|
|
|
|
|
|
|
root@guri:~# ping <new_serv>
|
|
|
|
PING guyunusa(<new_serv>.interior.edu.uy (2001:1328:ZZ::YYY)) 56 data bytes
|
|
|
|
64 bytes from <new_serv>.interior.edu.uy (2001:1328:ZZ::YYY): icmp_seq=1 ttl=64 time=0.198 ms
|
|
|
|
64 bytes from <new_serv>.interior.edu.uy (2001:1328:ZZ::YYY): icmp_seq=2 ttl=64 time=0.187 ms
|
|
|
|
^C
|
|
|
|
--- <new_serv> ping statistics ---
|
|
|
|
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
|
|
|
|
rtt min/avg/max/mdev = 0.187/0.192/0.198/0.014 ms
|
|
|
|
root@guri:~# ping <new_serv>-10g
|
|
|
|
PING <new_serv>-10g(2001:1328:ZZ:TT::YYY (2001:1328:ZZ:TT::YYY)) 56 data bytes
|
|
|
|
64 bytes from 2001:1328:ZZ:TT::YYY (2001:1328:ZZ:TT::YYY): icmp_seq=1 ttl=64 time=0.194 ms
|
|
|
|
64 bytes from 2001:1328:ZZ:TT::YYY (2001:1328:ZZ:TT::YYY): icmp_seq=2 ttl=64 time=0.201 ms
|
|
|
|
^C
|
|
|
|
--- <new_serv>-10g ping statistics ---
|
|
|
|
2 packets transmitted, 2 received, 0% packet loss, time 1ms
|
|
|
|
rtt min/avg/max/mdev = 0.194/0.197/0.201/0.014 ms
|
|
|
|
root@guri:~# ping -4 <new_serv>
|
|
|
|
PING <new_serv>.interior.edu.uy (164.73.XX.YYY) 56(84) bytes of data.
|
|
|
|
64 bytes from <new_serv>.interior.edu.uy (164.73.XX.YYY): icmp_seq=1 ttl=64 time=0.288 ms
|
|
|
|
^C
|
|
|
|
--- <new_serv>.interior.edu.uy ping statistics ---
|
|
|
|
1 packets transmitted, 1 received, 0% packet loss, time 0ms
|
|
|
|
rtt min/avg/max/mdev = 0.288/0.288/0.288/0.000 ms
|
|
|
|
```
|
|
|
|
* Podemos entonces proceder, si necesario, a definir en `host_vars/<new_serv>/vars/20_usuarios_y_grupos.yml` las variables `usuarios` y `os_grupos` específicas para el nuevo servidor (las personas que tendrán una cuenta linux en el servidor y podrán conectarse a través de éste como consola proxmox).
|
|
|
|
|
|
|
|
* Corremos entonces la configuración del servidor con Ansible:
|
|
|
|
```
|
|
|
|
ansible-playbook --limit <new_serv>.interior.edu.uy site.yml
|
|
|
|
```
|
|
|
|
|
|
|
|
* Estamos listos para agregar el nuevo servidor al cluster. Siguiendo [este manual de Proxmox](https://pve.proxmox.com/wiki/Cluster_Manager#pvecm_join_node_to_cluster), ingresamos en consola al nuevo servidor:
|
|
|
|
```
|
|
|
|
ssh root@<new_serv>.interior.edu.uy
|
|
|
|
```
|
|
|
|
Si 2001:1328:ZZ:TT::A es la IP de uno de los nodos existentes de la red del cluster LINK0 y 2001:1328:ZZ:TT::YYY la IP en la misma red del nuevo servidor, corremos el utilitario de enrolamiento de un nuevo servidor:
|
|
|
|
```
|
|
|
|
pvecm add 2001:1328:ZZ:TT::A -link0 2001:1328:ZZ:TT::YYY
|
|
|
|
```
|
|
|
|
* Podemos entonces eventualmente proceder a ajustar las variables `pve_usuarios`, `pve_grupos` y `pve_permisos` que se definen, para todo el cluster, en `group_vars/seciu/vars/20_pve_users.yml`. Una vez agregado el servidor al cluster, se pueden agregar ahí usuarios, grupos y permisos específicos al nuevo servidor. Y correr la definición de los nuevos permisos:
|
|
|
|
```
|
|
|
|
ansible-playbook --limit seciu_nodos site.yml
|
|
|
|
``` |
