Saltar a contenidoSaltar a navegación de páginas: página anterior [tecla acceso p]/página siguiente [tecla acceso n]
Se aplica a SUSE Enterprise Storage 6

12 Instalación de NFS Ganesha Edit source

NFS Ganesha proporciona acceso NFS para Object Gateway o CephFS. En SUSE Enterprise Storage 6, se admiten las versiones 3 y 4 de NFS. NFS Ganesha se ejecuta en el espacio del usuario, en lugar de en el espacio del kernel, e interactúa directamente con Object Gateway o CephFS.

Aviso
Aviso: acceso con varios protocolos

Los clientes nativos de CephFS y NFS no están restringidos por los bloqueos de archivos obtenidos a través de Samba, y viceversa. Las aplicaciones que se basan en el bloqueo de archivos con varios protocolos pueden sufrir daños en los datos si se accede a las vías compartidas de Samba respaldadas por CephFS a través de otros medios.

12.1 Preparación Edit source

12.1.1 Información general Edit source

Para distribuir correctamente NFS Ganesha, debe añadir role-ganesha al archivo /srv/pillar/ceph/proposals/policy.cfg. Para obtener información, consulte: Sección 5.5.1, “El archivo policy.cfg. NFS Ganesha también necesita que role-rgw o role-mds estén presentes en policy.cfg.

Aunque es posible instalar y ejecutar el servidor de NFS Ganesha en un nodo de Ceph ya existente, se recomienda ejecutarlo en un host dedicado con acceso al clúster de Ceph. Los hosts del cliente por lo general no forman parte del clúster, pero deben tener acceso de red al servidor de NFS Ganesha.

Para habilitar el servidor de NFS Ganesha en cualquier momento tras la instalación inicial, añada role-ganesha a policy.cfg y vuelva a ejecutar al menos las fases 2 y 4 de DeepSea. Para obtener información, consulte: Sección 5.3, “Distribución del clúster”.

NFS Ganesha se configura mediante el archivo /etc/ganesha/ganesha.conf, presente en el nodo de NFS Ganesha. Sin embargo, este archivo se sobrescribe cada vez que se ejecuta la fase 4 de DeepSea. Por lo tanto, se recomienda editar la plantilla que utiliza Salt, que es el archivo /srv/salt/ceph/ganesha/files/ganesha.conf.j2 del master de Salt. Para obtener información sobre el archivo de configuración, consulte el Sección 21.2, “Configuración”.

12.1.2 Resumen de requisitos Edit source

Los siguientes requisitos deben cumplirse antes de ejecutar las fases 2 y 4 de DeepSea a fin de instalar NFS Ganesha:

  • Debe haber al menos un nodo asignado a role-ganesha.

  • Solo puede definir un role-ganesha por minion.

  • Para funcionar, NFS Ganesha necesita una instancia de Object Gateway o CephFS.

  • El protocolo NFS basado en kernel debe inhabilitarse en los minions con la función role-ganesha.

12.2 Instalación de ejemplo Edit source

Este procedimiento proporciona una instalación de ejemplo que usa tanto Object Gateway como capas de abstracción del sistema de archivos (FSAL) de CephFS de NFS Ganesha.

  1. Si aún no lo ha hecho, ejecute las fases 0 y 1 de DeepSea antes de continuar con este procedimiento.

    root@master # salt-run state.orch ceph.stage.0
    root@master # salt-run state.orch ceph.stage.1
  2. Después de ejecutar la fase 1 de DeepSea, edite el archivo /srv/pillar/ceph/proposals/policy.cfg y añada la línea:

    role-ganesha/cluster/NODENAME

    Sustituya NODENAME con el nombre de un nodo del clúster.

    Asegúrese también de que hay asignados un role-mds y un role-rgw.

  3. Ejecute al menos las fases 2 y 4 de DeepSea. Se recomienda ejecutar la fase 3 en medio.

    root@master # salt-run state.orch ceph.stage.2
    root@master # salt-run state.orch ceph.stage.3 # optional but recommended
    root@master # salt-run state.orch ceph.stage.4
  4. Verifique que NFS Ganesha funciona comprobando que el servicio NFS Ganesha se está ejecutando en el nodo de minion:

    root@master # salt -I roles:ganesha service.status nfs-ganesha
    MINION_ID:
        True

12.3 Configuración activa-pasiva de alta disponibilidad Edit source

En esta sección se proporciona un ejemplo de cómo establecer una configuración activa-pasiva de dos nodos de los servidores de NFS Ganesha. El programa de instalación requiere SUSE Linux Enterprise High Availability Extension. Los dos nodos se denominan earth y mars.

Importante
Importante: coubicación de servicios

Los servicios que tienen su propia tolerancia a errores y su propio equilibrio de carga no deben ejecutarse en nodos de clúster que se aíslan para los servicios de failover. Por lo tanto, no ejecute los servicios de Ceph Monitor, el servidor de metadatos, iSCSI ni Ceph OSD en configuraciones de alta disponibilidad.

Para obtener información sobre SUSE Linux Enterprise High Availability Extension, consulte https://www.suse.com/documentation/sle-ha-15/.

12.3.1 Instalación básica Edit source

En esta configuración earth tiene la dirección IP 192.168.1.1 y mars tiene la dirección 192.168.1.2.

Asimismo, se usan dos direcciones IP virtuales flotantes que permiten a los clientes conectarse al servicio independientemente del nodo físico en el que se estén ejecutando. 192.168.1.10 se usa para la administración del clúster con Hawk2 y 192.168.2.1 se usa exclusivamente para las exportaciones NFS. De esta forma es más fácil aplicar más tarde restricciones de seguridad.

El procedimiento siguiente describe la instalación de ejemplo. Encontrará más información en https://www.suse.com/documentation/sle-ha-15/book_sleha_quickstarts/data/art_sleha_install_quick.html.

  1. Prepare los nodos de NFS Ganesha en el master de Salt:

    1. Ejecute las fases 0 y 1 de DeepSea.

      root@master # salt-run state.orch ceph.stage.0
      root@master # salt-run state.orch ceph.stage.1
    2. Asigne a los nodos earth y mars la función role-ganesha en el archivo /srv/pillar/ceph/proposals/policy.cfg:

      role-ganesha/cluster/earth*.sls
      role-ganesha/cluster/mars*.sls
    3. Ejecute las fases 2 a 4 de DeepSea.

      root@master # salt-run state.orch ceph.stage.2
      root@master # salt-run state.orch ceph.stage.3
      root@master # salt-run state.orch ceph.stage.4
  2. Registre SUSE Linux Enterprise High Availability Extension en earth y mars.

    root # SUSEConnect -r ACTIVATION_CODE -e E_MAIL
  3. Instale ha-cluster-bootstrap en ambos nodos:

    root # zypper in ha-cluster-bootstrap
    1. Inicialice el clúster en earth:

      root@earth # ha-cluster-init
    2. Deje que mars se una al clúster:

      root@mars # ha-cluster-join -c earth
  4. Compruebe el estado del clúster. Debería observar que se han añadido dos nodos al clúster:

    root@earth # crm status
  5. En ambos nodos, inhabilite el inicio automático del servicio NFS Ganesha durante el arranque:

    root # systemctl disable nfs-ganesha
  6. Inicie la shell crm en earth:

    root@earth # crm configure

    Los comandos siguientes se ejecutan en la shell crm.

  7. En earth, ejecute la shell crm para ejecutar los comandos siguientes a fin de configurar el recurso para los daemons de NFS Ganesha como clones de tipo de recurso systemd:

    crm(live)configure# primitive nfs-ganesha-server systemd:nfs-ganesha \
    op monitor interval=30s
    crm(live)configure# clone nfs-ganesha-clone nfs-ganesha-server meta interleave=true
    crm(live)configure# commit
    crm(live)configure# status
        2 nodes configured
        2 resources configured
    
        Online: [ earth mars ]
    
        Full list of resources:
             Clone Set: nfs-ganesha-clone [nfs-ganesha-server]
             Started:  [ earth mars ]
  8. Cree una IPAddr2 primitiva con la shell crm:

    crm(live)configure# primitive ganesha-ip IPaddr2 \
    params ip=192.168.2.1 cidr_netmask=24 nic=eth0 \
    op monitor interval=10 timeout=20
    
    crm(live)# status
    Online: [ earth mars  ]
    Full list of resources:
     Clone Set: nfs-ganesha-clone [nfs-ganesha-server]
         Started: [ earth mars ]
     ganesha-ip    (ocf::heartbeat:IPaddr2):    Started earth
  9. Para configurar una relación entre el servidor de NFS Ganesha y la dirección IP virtual flotante, utilice la colocación y el orden.

    crm(live)configure# colocation ganesha-ip-with-nfs-ganesha-server inf: ganesha-ip nfs-ganesha-clone
    crm(live)configure# order ganesha-ip-after-nfs-ganesha-server Mandatory: nfs-ganesha-clone ganesha-ip
  10. Utilice el comando mount desde el cliente para asegurarse de que la configuración del clúster está completa:

    root # mount -t nfs -v -o sync,nfsvers=4 192.168.2.1:/ /mnt

12.3.2 Limpieza de recursos Edit source

En caso de que se produzca un fallo en NFS Ganesha en uno de los nodos, por ejemplo en earth, solucione el problema y limpie el recurso. Solo después de que el recurso se haya limpiado, el recurso podrá recuperarse tras el fallo en earth, en caso de que NFS Ganesha falle en mars.

Para limpiar el recurso:

root@earth # crm resource cleanup nfs-ganesha-clone earth
root@earth # crm resource cleanup ganesha-ip earth

12.3.3 Configuración del recurso de Ping Edit source

Puede suceder que el servidor no pueda acceder al cliente debido a un problema de red. Un recurso de ping puede detectar y solucionar este problema. La configuración de este recurso es opcional.

  1. Defina el recurso de ping:

    crm(live)configure# primitive ganesha-ping ocf:pacemaker:ping \
            params name=ping dampen=3s multiplier=100 host_list="CLIENT1 CLIENT2" \
            op monitor interval=60 timeout=60 \
            op start interval=0 timeout=60 \
            op stop interval=0 timeout=60

    host_list es una lista de direcciones IP separadas por caracteres de espacio. Se hará ping a las direcciones IP con regularidad para comprobar si se producen interrupciones de la red. Si un cliente debe tener acceso continuo al servidor de NFS, añádalo a host_list.

  2. Cree un clon:

    crm(live)configure# clone ganesha-ping-clone ganesha-ping \
            meta interleave=true
  3. El siguiente comando crea una restricción para el servicio NFS Ganesha. Fuerza al servicio a moverse a otro nodo cuando no sea posible acceder a host_list.

    crm(live)configure# location nfs-ganesha-server-with-ganesha-ping
            nfs-ganesha-clone \
            rule -inf: not_defined ping or ping lte 0

12.3.4 Alta disponibilidad de NFS Ganesha y DeepSea Edit source

DeepSea no admite la configuración de alta disponibilidad de NFS Ganesha. Para evitar que DeepSea falle después de configurar la alta disponibilidad de NFS Ganesha, excluya el inicio y la detención del servicio NFS Ganesha de la fase 4 de DeepSea:

  1. Copie /srv/salt/ceph/ganesha/default.sls en /srv/salt/ceph/ganesha/ha.sls.

  2. Elimine la entrada .service de /srv/salt/ceph/ganesha/ha.sls de forma que quede como sigue:

    include:
    - .keyring
    - .install
    - .configure
  3. Añada la línea siguiente a /srv/pillar/ceph/stack/global.yml:

    ganesha_init: ha

12.4 Configuración activa-activa Edit source

Esta sección proporciona un ejemplo de configuración activa-activa sencilla de NFS Ganesha. El objetivo es distribuir dos servidores de NFS Ganesha en capas sobre el mismo CephFS existente. Los servidores serán dos nodos de clúster de Ceph con direcciones independientes. Los clientes deben distribuirse entre ellos manualmente. En esta configuración, failover significa desmontar y volver a montar manualmente el otro servidor en el cliente.

12.4.1 Requisitos previos Edit source

Para nuestra configuración de ejemplo, necesita lo siguiente:

  • El clúster de Ceph en ejecución. Consulte la Sección 5.3, “Distribución del clúster” para obtener más información sobre la distribución y configuración del clúster de Ceph mediante DeepSea.

  • Al menos un CephFS configurado. Consulte el Capítulo 11, Instalación de CephFS para obtener más información sobre la distribución y configuración de CephFS.

  • Dos nodos de clúster de Ceph con NFS Ganesha distribuido. Consulte el Capítulo 12, Instalación de NFS Ganesha para obtener más información sobre la distribución de NFS Ganesha.

    Sugerencia
    Sugerencia: uso de servidores dedicados

    Aunque los nodos de NFS Ganesha pueden compartir recursos con otros servicios relacionados con Ceph, se recomienda usar servidores dedicados para mejorar el rendimiento.

Después de distribuir los nodos de NFS Ganesha, verifique que el clúster está operativo y que los repositorios CephFS por defecto están allí:

cephadm@adm > rados lspools
cephfs_data
cephfs_metadata

12.4.2 Configuración de NFS Ganesha Edit source

Compruebe que ambos nodos de NFS Ganesha tengan instalado el archivo /etc/ganesha/ganesha.conf. Añada los bloques siguientes, si aún no existen, al archivo de configuración para habilitar RADOS como back-end de recuperación de NFS Ganesha.

NFS_CORE_PARAM
{
    Enable_NLM = false;
    Enable_RQUOTA = false;
    Protocols = 4;
}
NFSv4
{
    RecoveryBackend = rados_cluster;
    Minor_Versions = 1,2;
}
CACHEINODE {
    Dir_Chunk = 0;
    NParts = 1;
    Cache_Size = 1;
}
RADOS_KV
{
    pool = "rados_pool";
    namespace = "pool_namespace";
    nodeid = "fqdn"
    UserId = "cephx_user_id";
    Ceph_Conf = "path_to_ceph.conf"
}

Puede averiguar los valores para rados_pool y pool_namespace comprobando la línea ya existente en la configuración del formulario:

%url rados://rados_pool/pool_namespace/...

El valor para la opción nodeid corresponde al nombre completo de la máquina. Los valores de las opciones UserId y Ceph_Conf se pueden encontrar en el bloque RADOS_URLS ya existente.

Debido a que las versiones heredadas de NFS impiden levantar el período de gracia antes de tiempo y, por lo tanto, prolongan el reinicio del servidor, se han inhabilitado las opciones correspondientes a versiones de NFS anteriores a la 4.2. También se ha inhabilitado la mayor parte del almacenamiento en caché de NFS Ganesha, ya que las bibliotecas de Ceph ya realizan un almacenamiento en caché agresivo.

El back-end de recuperación "rados_cluster" almacena su información en objetos RADOS. Aunque no es una gran cantidad de datos, queremos que tenga alta disponibilidad. Con este objetivo se usa el repositorio de metadatos de cephFS y se declara en él un nuevo espacio de nombres "ganesha" para mantenerlo diferenciado de los objetos CephFS.

Nota
Nota: IDs de nodo de clúster

La mayor parte de la configuración es idéntica entre los dos hosts, sin embargo, la opción nodeid del bloque "RADOS_KV" debe ser una cadena exclusiva para cada nodo. Por defecto, NFS Ganesha define en nodeid el nombre de host del nodo.

Si necesita utilizar valores fijos diferentes a los nombres de host, puede por ejemplo definir nodeid = 'a' en un nodo y nodeid = 'b' en el otro.

12.4.3 Relleno de la base de datos de gracia del clúster Edit source

Necesitamos verificar que todos los nodos del clúster son conscientes de los demás. Eso se hace mediante un objeto RADOS que se comparte entre los hosts. NFS Ganesha utiliza este objeto para comunicar el estado actual en relación a un período de gracia.

El paquete nfs-ganesha-rados-grace contiene una herramienta de línea de comandos para consultar y manipular esta base de datos. Si el paquete no está instalado en al menos uno de los nodos, instálelo con:

root # zypper install nfs-ganesha-rados-grace

El comando se usa para crear la base de datos y añadir ambos nodeid. En nuestro ejemplo, los dos nodos NFS Ganesha se denominan ses6min1.example.com y ses6min2.example.com. En uno de los hosts de NFS Ganesha, ejecute:

cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha add ses6min1.example.com
cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha add ses6min2.example.com
cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha
cur=1 rec=0
======================================================
ses6min1.example.com     E
ses6min2.example.com     E

Esto crea la base de datos de gracia y le añade "ses6min1.example.com" y "ses6min2.example.com". El último comando vuelca el estado actual. Los hosts recién añadidos siempre se consideran que aplican el período de gracia, por lo que ambos tienen el indicador "E" definido. Los valores "cur" y "rec" muestran las épocas actuales y de recuperación, que es cómo se realiza un seguimiento de qué hosts pueden realizar la recuperación y cuándo.

12.4.4 Reinicio de servicios de NFS Ganesha Edit source

En ambos nodos de NFS Ganesha, reinicie los servicios relacionados:

root # systemctl restart nfs-ganesha.service

Después de reiniciar los servicios, compruebe la base de datos de gracia:

cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha
cur=3 rec=0
======================================================
ses6min1.example.com
ses6min2.example.com
Nota
Nota: se ha borrado el indicador "E"

Tenga en cuenta que en ambos nodos se ha borrado el indicador "E", lo que indica que ya no están aplicando el período de gracia y ahora están en modo de funcionamiento normal.

12.4.5 Conclusión Edit source

Después de completar todos los pasos anteriores, puede montar el NFS exportado desde cualquiera de los dos servidores de NFS Ganesha y realizar operaciones NFS normales en ellos.

En la configuración de ejemplo se supone que si uno de los dos servidores de NFS Ganesha se apaga, se reiniciará manualmente en 5 minutos. Después de 5 minutos, el servidor de metadatos puede cancelar la sesión del cliente de NFS Ganesha y todo el estado asociado a él. Si las capacidades de la sesión se cancelan antes de que el resto del clúster entre en el período de gracia, es posible que los clientes del servidor no puedan recuperar todo su estado.

12.5 Más información Edit source

Encontrará más información en Capítulo 21, NFS Ganesha: exportación de datos de Ceph a través de NFS.

Imprimir esta página