Instalación de un servidor físico

  • v1.x Escribimos este procedimiento general al re-instalar Hipatia (#2448),
  • v2.x lo revisamos al re-instalar Sabato (#3765)

Inicialización

Se recibe un nuevo servidor, o se decide re-instalar de cero un servidor.

Aspectos materiales

  • localización física: local con adecuación ambiental adecuada,
  • alimentación eléctrica con UPS

Requerimientos:

Para instalar un servidor físico se requerirá:
  • una IP (con máscara y pasarela de salida) asignada de manera fija y permanente por el administrador de la red local del lugar de hospedaje,
  • un nombre, conforme a la nomenclatura del lugar, de preferencia declarado en el DNS.
Será necesario tener los datos de los servicios locales. Al menos:
  • la pasarela de salida (gateway) de la red local ya mencionada, o la configuración de rutas y enritamiento que se requiera,
  • eventualmente el DHCP si así se maneja la red local, pero en principio no configuramos los servidores con DHCP,
  • el o los resolvedores de DNS locales,
Y también serán útiles:
  • él o los servidores de tiempo,
  • el servicio de distribución de mail

Instalación OS

Instalación de una debian.

A partir de debian 7, se pueden instalar arquitecturas UEFI y particiones GPT, lo que será necesario para más de 2Ti de disco.

En principio:
  • utilizamos LVM para todas las particiones, salvo /boot y arranque EFI,
  • separamos /usr, /var, /tmp, pero no /home, dado que no son servidores para cuentas de usuario,
  • prevemos una particion para / un poco más grande que lo estándar...
  • un swap del doble de la memoria,
  • dejamos espacio LVM para discos de virtuales en LVM y funcionalidades específicas del servidor.

Como réplica, mientras no tengamos una en Uruguay... elegimos alguna que esté en la red CLARA (UBA en Argentina o USP en Brasil), y ponemos el apt-cache.

En aptitude, en Opciones->preferencias, desactivamos la instalación automática de paquetes recomendados (algunos paquetes recomiendan de más, y así instalmos lo mínimo y sabemos bien lo que necesitamos y porqué).

Configuración para virtuales kvm

En la Debian se documenta acá, cuando instalamos el servidor madre Barrán, lo documentamos acá.
Y es tiempo de pasarlo a este gestor:

Conviene instalar:

aptitude install qemu-kvm libvirt-bin

reiniciar. Hasta no instalar:

aptitude install virtinst

no pudimos crear máquinas virtuales.

Es importante que las capacidades de virtualización del servidor estén activadas a nivel del BIOS. Ver: #3765#note-6

Luego, desde una máquina con un virt-manager, se puede acceder a la consola de virtualización, con un usuario con los derehos apropiados (grupos libvirt y kvm (o libvirt-qemu)) Conviene primero asegurarse que se ingresa en ssh, y luego desde el virt-manager. (¿¿requiere el luibvirt-bin en el cliente?? --> a priori no)

El servidor madre comparte su tarjeta de red con los virtuales a través de un brigde interno, que conviene configurar, en /etc/network/interfaces (en este caso es la IP de Sabato:
auto br0
iface br0 inet static
address 164.73.68.6
netmask 255.255.255.192
network 164.73.68.0
broadcast 164.73.68.63
gateway 164.73.68.1 # Bridge para kvm
bridge_ports eth0
bridge_fd 9
bridge_hello 2
bridge_maxage 12
bridge_stp off # dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 164.73.68.33 164.73.68.254
dns-search csic.edu.uy

Configuración adicional

Ver las recomendaciones adicionales para todos los servidores (vienen de esta referencia, ver si no hay que fusionar con lo que sigue).

Iptables

Además de estas protecciones, ponermos un iptables adecuado en el servidor (ver ... ).

Sincronización de relojes

Los servidores en internet y las máquinas tienen que tener relojes correctos.

En los servidores madre configuramos ntp, como cliente de nuestra red de servidores de tiempo.

aptitude install ntp ntpdate

En /etc/ntp.conf configuramos:

server ntp.csic.edu.uy iburst
server ntp.cure.edu.uy iburst
server ntp.unorte.edu.uy iburst
#server 0.debian.pool.ntp.org iburst
#server 1.debian.pool.ntp.org iburst
#server 2.debian.pool.ntp.org iburst
#server 3.debian.pool.ntp.org iburst

ver ntp

Conexión a la red SAN/NAS

borradores: #2256 #2448#note-10

Documentación debian para el acceso por iSCSI

Suponemos que disponemos de un disco SAN/NAS en iSCSI, llamado <disco>, con un usuario CHAP <servidor> (y una contraseña compleja <password>). Ver (fixme)

Debemos:
  • conectar físicamente el servidor a la res SAN,
  • configurar una IP en la red SAN: 10.5.1.0/24: el direccionamiento se maneja acá: Gregg,
  • instalar open-iscsi en el servidor. Puede ser necesario reiniciar el servicio:
    /etc/init.d/open-iscsi restart
    
  • Ahora podemos ver los recursos iSCSI que comparte gregg:
    root@barran:/etc/iscsi# iscsiadm -m discovery -t st -p 10.5.1.3
    10.5.1.3:3260,1 iqn.2012-07.com.lenovoemc:ix12.gregg.nube
    10.5.1.3:3260,1 iqn.2012-07.com.lenovoemc:ix12.gregg.respaldos
    
  • ponemos el usuario y la contraseña CHAP en los dos lugares que dice la documentación debian (/etc/iscsi/...):
    # *************
    # CHAP Settings
    # *************
    
    # To enable CHAP authentication set node.session.auth.authmethod
    # to CHAP. The default is None.
    node.session.auth.authmethod = CHAP
    
    # To set a CHAP username and password for initiator
    # authentication by the target(s), uncomment the following lines:
    node.session.auth.username = <servidor>
    node.session.auth.password = <password>
    
    # To set a CHAP username and password for target(s)
    # authentication by the initiator, uncomment the following lines:
    #node.session.auth.username_in = username_in
    #node.session.auth.password_in = password_in
    
    # To enable CHAP authentication for a discovery session to the target
    # set discovery.sendtargets.auth.authmethod to CHAP. The default is None.
    discovery.sendtargets.auth.authmethod = CHAP
    
    # To set a discovery session CHAP username and password for the initiator
    # authentication by the target(s), uncomment the following lines:
    discovery.sendtargets.auth.username = <servidor>
    discovery.sendtargets.auth.password = <password>
    

    Y entonces podemos loguearnos en un recurso, por ejemplo:
    iscsiadm -m node --targetname "iqn.2012-07.com.lenovoemc:ix12.gregg.nube" --portal "10.5.1.3:3260" --login
    

    Y, en respuesta satisfactoria, veremos un nuevo recurso de disco:
    root@barran:/etc/iscsi# ls -la /dev/disk/by-path/
    total 0
    drwxr-xr-x 2 root root 220 ene 31 17:15 .
    drwxr-xr-x 6 root root 120 ene 22 18:49 ..
    lrwxrwxrwx 1 root root   9 ene 31 17:16 ip-10.5.1.3:3260-iscsi-iqn.2012-07.com.lenovoemc:ix12.gregg.nube-lun-0 -> ../../sdc
    
  • se puede utilizar el disco tal cual, o le podemos poner una partición adentro (mejor):
    cfdisk /dev/sdv
    

Se pueden crear particiones, formatear, montar, etc como otros discos.

Desde la consola virt-manager, se pueden poner a disposición de los virtuales los almacenamientos de tipo iSCSI:
Detalles servidor madre almacenamiento

Podemos agregar un nuevo almacenamiento (+ a la izquierda, abajo):

Nuevo iSCSI

En la pantalla siguiente (la próx le sacamos foto...) propone una ruta @/dev/disk/by-pah/, a continuación hay que darle:
  • anfitrion: la IP de gregg,
  • path: el iqn
    "eventualmente tildar iqn

Esta configuración construye la solicitud anterior de login

Barran_vm_detalles_almacenamiento.png - Detalles servidor madre almacenamiento (83.6 KB) Daniel Viñar Ulriksen, 01/31/2014 05:54 PM

Barran_vm_nuevo_almacenamiento_iSCSI.png - Nuevo iSCSI (30.8 KB) Daniel Viñar Ulriksen, 01/31/2014 05:54 PM