Skip to main content
BeeGFS on NetApp with E-Series Storage
La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Creare l'inventario Ansible

Collaboratori
PDF

Per definire la configurazione per i nodi di file e blocchi, creare un inventario Ansible che rappresenti il file system BeeGFS che si desidera implementare. L'inventario include host, gruppi e variabili che descrivono il file system BeeGFS desiderato.

Fase 1: Definire la configurazione per tutti gli elementi di base

Definire la configurazione che si applica a tutti gli elementi di base, indipendentemente dal profilo di configurazione che è possibile applicare singolarmente.

Prima di iniziare

  • Scegliere uno schema di indirizzi di sottorete per la distribuzione. A causa dei vantaggi elencati nella "architettura del software", si consiglia di utilizzare uno schema di indirizzamento a subnet singola.

Fasi

  1. Nel nodo di controllo Ansible, identificare una directory che si desidera utilizzare per memorizzare i file dell'inventario Ansible e del playbook.

    Se non diversamente specificato, tutti i file e le directory creati in questa fase e nelle fasi successive vengono creati in relazione a questa directory.

  2. Creare le seguenti sottodirectory:

    host_vars

    group_vars

    packages

Fase 2: Definire la configurazione per i singoli nodi di file e blocchi

Definire la configurazione che si applica ai singoli nodi di file e ai singoli nodi building block.

  1. Sotto host_vars/, Creare un file per ogni nodo di file BeeGFS denominato <HOSTNAME>.yml Con il seguente contenuto, prestare particolare attenzione alle note relative al contenuto da compilare per gli IP del cluster BeeGFS e i nomi host che terminano con numeri dispari e pari.

    Inizialmente, i nomi dell'interfaccia del nodo del file corrispondono a quelli elencati qui (ad esempio ib0 o ibs1f0). Questi nomi personalizzati sono configurati in Fase 4: Definire la configurazione da applicare a tutti i nodi di file.

    ansible_host: “<MANAGEMENT_IP>”
eseries_ipoib_interfaces:  # Used to configure BeeGFS cluster IP addresses.
  - name: i1b
    address: 100.127.100. <NUMBER_FROM_HOSTNAME>/16
  - name: i4b
    address: 100.127.100. <NUMBER_FROM_HOSTNAME>/16
beegfs_ha_cluster_node_ips:
  - <MANAGEMENT_IP>
  - <i1b_BEEGFS_CLUSTER_IP>
  - <i4b_BEEGFS_CLUSTER_IP>
# NVMe over InfiniBand storage communication protocol information
# For odd numbered file nodes (i.e., h01, h03, ..):
eseries_nvme_ib_interfaces:
  - name: i1a
    address: 192.168.1.10/24
    configure: true
  - name: i2a
    address: 192.168.3.10/24
    configure: true
  - name: i3a
    address: 192.168.5.10/24
    configure: true
  - name: i4a
    address: 192.168.7.10/24
    configure: true
# For even numbered file nodes (i.e., h02, h04, ..):
# NVMe over InfiniBand storage communication protocol information
eseries_nvme_ib_interfaces:
  - name: i1a
    address: 192.168.2.10/24
    configure: true
  - name: i2a
    address: 192.168.4.10/24
    configure: true
  - name: i3a
    address: 192.168.6.10/24
    configure: true
  - name: i4a
    address: 192.168.8.10/24
    configure: true
    Nota Se il cluster BeeGFS è già stato implementato, è necessario arrestare il cluster prima di aggiungere o modificare gli indirizzi IP configurati staticamente, inclusi gli IP del cluster e gli IP utilizzati per NVMe/IB. Ciò è necessario per garantire che queste modifiche abbiano effetto corretto e non interrompano le operazioni del cluster.

  2. Sotto host_vars/, Creare un file per ogni nodo del blocco BeeGFS denominato <HOSTNAME>.yml e compilarlo con il seguente contenuto.

    Prestare particolare attenzione alle note relative ai contenuti da inserire nei nomi degli array di storage che terminano con numeri pari o dispari.

    Per ogni nodo del blocco, creare un file e specificare <MANAGEMENT_IP> Per uno dei due controller (di solito A).

    eseries_system_name: <STORAGE_ARRAY_NAME>
eseries_system_api_url: https://<MANAGEMENT_IP>:8443/devmgr/v2/
eseries_initiator_protocol: nvme_ib
# For odd numbered block nodes (i.e., a01, a03, ..):
eseries_controller_nvme_ib_port:
  controller_a:
    - 192.168.1.101
    - 192.168.2.101
    - 192.168.1.100
    - 192.168.2.100
  controller_b:
    - 192.168.3.101
    - 192.168.4.101
    - 192.168.3.100
    - 192.168.4.100
# For even numbered block nodes (i.e., a02, a04, ..):
eseries_controller_nvme_ib_port:
  controller_a:
    - 192.168.5.101
    - 192.168.6.101
    - 192.168.5.100
    - 192.168.6.100
  controller_b:
    - 192.168.7.101
    - 192.168.8.101
    - 192.168.7.100
    - 192.168.8.100

Fase 3: Definire la configurazione da applicare a tutti i nodi di file e blocchi

È possibile definire la configurazione comune a un gruppo di host in group_vars in un nome di file che corrisponde al gruppo. In questo modo si evita di ripetere una configurazione condivisa in più posizioni.

A proposito di questa attività

Gli host possono trovarsi in più di un gruppo e, in fase di esecuzione, Ansible sceglie le variabili da applicare a un determinato host in base alle regole di precedenza delle variabili. Per ulteriori informazioni su queste regole, consultare la documentazione Ansible per "Utilizzo delle variabili".)

Le assegnazioni host-to-group sono definite nel file di inventario Ansible effettivo, creato verso la fine di questa procedura.

Fase

In Ansible, qualsiasi configurazione che si desidera applicare a tutti gli host può essere definita in un gruppo chiamato All. Creare il file group_vars/all.yml con i seguenti contenuti:

ansible_python_interpreter: /usr/bin/python3
beegfs_ha_ntp_server_pools:  # Modify the NTP server addressess if desired.
  - "pool 0.pool.ntp.org iburst maxsources 3"
  - "pool 1.pool.ntp.org iburst maxsources 3"

Fase 4: Definire la configurazione da applicare a tutti i nodi di file

La configurazione condivisa per i nodi di file viene definita in un gruppo chiamato ha_cluster. La procedura descritta in questa sezione illustra la configurazione da includere in group_vars/ha_cluster.yml file.

Fasi

  1. Nella parte superiore del file, definire le impostazioni predefinite, inclusa la password da utilizzare come sudo utente sui nodi del file.

    ### ha_cluster Ansible group inventory file.
# Place all default/common variables for BeeGFS HA cluster resources below.
### Cluster node defaults
ansible_ssh_user: root
ansible_become_password: <PASSWORD>
eseries_ipoib_default_hook_templates:
  - 99-multihoming.j2   # This is required for single subnet deployments, where static IPs containing multiple IB ports are in the same IPoIB subnet. i.e: cluster IPs, multirail, single subnet, etc.
# If the following options are specified, then Ansible will automatically reboot nodes when necessary for changes to take effect:
eseries_common_allow_host_reboot: true
eseries_common_reboot_test_command: "! systemctl status eseries_nvme_ib.service || systemctl --state=exited | grep eseries_nvme_ib.service"
eseries_ib_opensm_options:
  virt_enabled: "2"
  virt_max_ports_in_process: "0"
    Nota In particolare per gli ambienti di produzione, non memorizzare le password in testo normale. Utilizzare invece il vault Ansible (vedere "Crittografia del contenuto con Ansible Vault") o il --ask-become-pass quando si esegue il playbook. Se il ansible_ssh_user è già root, quindi è possibile omettere il ansible_become_password.

  2. Facoltativamente, configurare un nome per il cluster ad alta disponibilità (ha) e specificare un utente per la comunicazione intra-cluster.

    Se si sta modificando lo schema di indirizzamento IP privato, è necessario aggiornare anche il valore predefinito beegfs_ha_mgmtd_floating_ip. Questo valore deve corrispondere a quello configurato in seguito per il gruppo di risorse BeeGFS Management.

    Specificare una o più e-mail che devono ricevere avvisi per gli eventi del cluster utilizzando beegfs_ha_alert_email_list.

    ### Cluster information
beegfs_ha_firewall_configure: True
eseries_beegfs_ha_disable_selinux: True
eseries_selinux_state: disabled
# The following variables should be adjusted depending on the desired configuration:
beegfs_ha_cluster_name: hacluster                  # BeeGFS HA cluster name.
beegfs_ha_cluster_username: hacluster              # BeeGFS HA cluster username.
beegfs_ha_cluster_password: hapassword             # BeeGFS HA cluster username's password.
beegfs_ha_cluster_password_sha512_salt: randomSalt # BeeGFS HA cluster username's password salt.
beegfs_ha_mgmtd_floating_ip: 100.127.101.0         # BeeGFS management service IP address.
# Email Alerts Configuration
beegfs_ha_enable_alerts: True
beegfs_ha_alert_email_list: ["email@example.com"]  # E-mail recipient list for notifications when BeeGFS HA resources change or fail.  Often a distribution list for the team responsible for managing the cluster.
beegfs_ha_alert_conf_ha_group_options:
      mydomain: “example.com”
# The mydomain parameter specifies the local internet domain name. This is optional when the cluster nodes have fully qualified hostnames (i.e. host.example.com).
# Adjusting the following parameters is optional:
beegfs_ha_alert_timestamp_format: "%Y-%m-%d %H:%M:%S.%N" #%H:%M:%S.%N
beegfs_ha_alert_verbosity: 3
#  1) high-level node activity
#  3) high-level node activity + fencing action information + resources (filter on X-monitor)
#  5) high-level node activity + fencing action information + resources
    Nota Anche se apparentemente ridondante, beegfs_ha_mgmtd_floating_ip È importante quando si scala il file system BeeGFS oltre un singolo cluster ha. I cluster ha successivi vengono implementati senza un servizio di gestione BeeGFS aggiuntivo e puntano al servizio di gestione fornito dal primo cluster.

  3. Configurare un agente di scherma. (Per ulteriori informazioni, vedere "Configurare la scherma in un cluster Red Hat High Availability".) Il seguente output mostra esempi di configurazione di agenti di scherma comuni. Scegliere una di queste opzioni.

    Per questa fase, tenere presente che:

    • Per impostazione predefinita, la funzione di scherma è attivata, ma è necessario configurare un Agent di scherma.

    • Il <HOSTNAME> specificato in pcmk_host_map oppure pcmk_host_list Deve corrispondere al nome host nell'inventario Ansible.

    • L'esecuzione del cluster BeeGFS senza scherma non è supportata, in particolare in produzione. In questo modo si garantisce in gran parte che quando i servizi BeeGFS, incluse eventuali dipendenze di risorse come i dispositivi a blocchi, si verifichi un failover a causa di un problema, non vi sia alcun rischio di accesso simultaneo da parte di più nodi che si traducono in un danneggiamento del file system o in altri comportamenti indesiderati o imprevisti. Se la scherma deve essere disattivata, fare riferimento alle note generali nella guida introduttiva e nel set del ruolo BeeGFS ha beegfs_ha_cluster_crm_config_options["stonith-enabled"] a false in ha_cluster.yml.

    • Sono disponibili più dispositivi di scherma a livello di nodo e il ruolo BeeGFS ha può configurare qualsiasi agente di scherma disponibile nel repository dei pacchetti Red Hat ha. Se possibile, utilizzare un agente di scherma che lavori attraverso l'UPS (Uninterruptible Power Supply) o l'unità di distribuzione dell'alimentazione rack (rPDU), Perché alcuni agenti di scherma, come il BMC (Baseboard Management Controller) o altri dispositivi di illuminazione integrati nel server, potrebbero non rispondere alla richiesta di fence in determinati scenari di errore.

      ### Fencing configuration:
# OPTION 1: To enable fencing using APC Power Distribution Units (PDUs):
beegfs_ha_fencing_agents:
 fence_apc:
   - ipaddr: <PDU_IP_ADDRESS>
     login: <PDU_USERNAME>
     passwd: <PDU_PASSWORD>
     pcmk_host_map: "<HOSTNAME>:<PDU_PORT>,<PDU_PORT>;<HOSTNAME>:<PDU_PORT>,<PDU_PORT>"
# OPTION 2: To enable fencing using the Redfish APIs provided by the Lenovo XCC (and other BMCs):
redfish: &redfish
  username: <BMC_USERNAME>
  password: <BMC_PASSWORD>
  ssl_insecure: 1 # If a valid SSL certificate is not available specify “1”.
beegfs_ha_fencing_agents:
  fence_redfish:
    - pcmk_host_list: <HOSTNAME>
      ip: <BMC_IP>
      <<: *redfish
    - pcmk_host_list: <HOSTNAME>
      ip: <BMC_IP>
      <<: *redfish
# For details on configuring other fencing agents see https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/configuring_and_managing_high_availability_clusters/assembly_configuring-fencing-configuring-and-managing-high-availability-clusters.

  4. Abilitare l'ottimizzazione delle performance consigliata nel sistema operativo Linux.

    Mentre molti utenti trovano che le impostazioni predefinite per i parametri delle performance funzionino generalmente bene, è possibile modificare le impostazioni predefinite per un particolare carico di lavoro. Di conseguenza, questi consigli sono inclusi nel ruolo BeeGFS, ma non sono abilitati per impostazione predefinita per garantire che gli utenti siano a conoscenza della messa a punto applicata al file system.

    Per attivare l'ottimizzazione delle performance, specificare:

    ### Performance Configuration:
beegfs_ha_enable_performance_tuning: True

  5. (Facoltativo) è possibile regolare i parametri di ottimizzazione delle performance nel sistema operativo Linux in base alle esigenze.

    Per un elenco completo dei parametri di ottimizzazione disponibili che è possibile regolare, vedere la sezione Impostazioni predefinite prestazioni del ruolo BeeGFS ha in "Sito e-Series BeeGFS GitHub". I valori predefiniti possono essere sovrascritti per tutti i nodi nel cluster in questo file o per il host_vars file di un singolo nodo.

  6. Per consentire la connettività 200GB/HDR completa tra nodi di blocco e file, utilizzare il pacchetto Open Subnet Manager (opensm) di NVIDIA Open Fabrics Enterprise Distribution (MLNX_OFED). La versione MLNX_OFED in elenco "requisiti dei nodi file" viene fornita con i pacchetti opensm consigliati. Sebbene l'implementazione tramite Ansible sia supportata, è necessario prima installare il driver MLNX_OFED su tutti i nodi di file.

    1. Compilare i seguenti parametri in group_vars/ha_cluster.yml (regolare i pacchetti in base alle esigenze):

      ### OpenSM package and configuration information
eseries_ib_opensm_options:
  virt_enabled: "2"
  virt_max_ports_in_process: "0"

  7. Configurare udev Regola per garantire la mappatura coerente degli identificatori di porta logici InfiniBand ai dispositivi PCIe sottostanti.

    Il udev La regola deve essere univoca per la topologia PCIe di ciascuna piattaforma server utilizzata come nodo di file BeeGFS.

    Utilizzare i seguenti valori per i nodi di file verificati:

    ### Ensure Consistent Logical IB Port Numbering
# OPTION 1: Lenovo SR665 V3 PCIe address-to-logical IB port mapping:
eseries_ipoib_udev_rules:
  "0000:01:00.0": i1a
  "0000:01:00.1": i1b
  "0000:41:00.0": i2a
  "0000:41:00.1": i2b
  "0000:81:00.0": i3a
  "0000:81:00.1": i3b
  "0000:a1:00.0": i4a
  "0000:a1:00.1": i4b

# OPTION 2: Lenovo SR665 PCIe address-to-logical IB port mapping:
eseries_ipoib_udev_rules:
  "0000:41:00.0": i1a
  "0000:41:00.1": i1b
  "0000:01:00.0": i2a
  "0000:01:00.1": i2b
  "0000:a1:00.0": i3a
  "0000:a1:00.1": i3b
  "0000:81:00.0": i4a
  "0000:81:00.1": i4b

  8. (Facoltativo) aggiornare l'algoritmo di selezione dei metadati.

    beegfs_ha_beegfs_meta_conf_ha_group_options:
  tuneTargetChooser: randomrobin
    Nota Durante i test di verifica, randomrobin In genere, è stato utilizzato per garantire che i file di test fossero distribuiti in modo uniforme tra tutti gli obiettivi di storage BeeGFS durante il benchmarking delle performance (per ulteriori informazioni sul benchmarking, visitare il sito BeeGFS per "Benchmarking di un sistema BeeGFS"). Con un utilizzo reale, questo potrebbe causare il riempimento più rapido dei target con un numero inferiore rispetto ai target con un numero superiore. Omettere randomrobin e utilizzando solo il valore predefinito randomized è stato dimostrato che il valore offre buone performance pur continuando a utilizzare tutti gli obiettivi disponibili.

Fase 5: Definire la configurazione per il nodo a blocchi comune

La configurazione condivisa per i nodi a blocchi viene definita in un gruppo chiamato eseries_storage_systems. La procedura descritta in questa sezione illustra la configurazione da includere in group_vars/ eseries_storage_systems.yml file.

Fasi

  1. Impostare la connessione Ansible su locale, fornire la password di sistema e specificare se i certificati SSL devono essere verificati. (In genere, Ansible utilizza SSH per connettersi agli host gestiti, ma nel caso dei sistemi storage NetApp e-Series utilizzati come nodi a blocchi, i moduli utilizzano l'API REST per la comunicazione). Nella parte superiore del file, aggiungere quanto segue:

    ### eseries_storage_systems Ansible group inventory file.
# Place all default/common variables for NetApp E-Series Storage Systems here:
ansible_connection: local
eseries_system_password: <PASSWORD>
eseries_validate_certs: false
    Nota Si sconsiglia di elencare le password in testo non crittografato. Utilizzare Ansible vault o fornire il eseries_system_password Quando si esegue Ansible utilizzando --extra-vars.

  2. Per garantire prestazioni ottimali, installare le versioni elencate per i nodi a blocchi in "Requisiti tecnici".

    Scaricare i file corrispondenti da "Sito di supporto NetApp". È possibile aggiornarli manualmente o includerli in packages/ Directory del nodo di controllo Ansible, quindi popolare i seguenti parametri in eseries_storage_systems.yml Per eseguire l'aggiornamento utilizzando Ansible:

    # Firmware, NVSRAM, and Drive Firmware (modify the filenames as needed):
eseries_firmware_firmware: "packages/RCB_11.80GA_6000_64cc0ee3.dlp"
eseries_firmware_nvsram: "packages/N6000-880834-D08.dlp"

  3. Scaricare e installare il firmware dell'unità più recente disponibile per le unità installate nei nodi di blocco dal "Sito di supporto NetApp". È possibile aggiornarli manualmente o includerli nella packages/ directory del nodo di controllo Ansible, quindi popolare i seguenti parametri nel eseries_storage_systems.yml per l'aggiornamento utilizzando Ansible:

    eseries_drive_firmware_firmware_list:
  - "packages/<FILENAME>.dlp"
eseries_drive_firmware_upgrade_drives_online: true
    Nota Impostazione eseries_drive_firmware_upgrade_drives_online a. false Accelera l'aggiornamento, ma non deve essere eseguito fino a quando non viene implementato BeeGFS. Questo perché questa impostazione richiede l'interruzione di tutti i/o sui dischi prima dell'aggiornamento per evitare errori dell'applicazione. Sebbene l'esecuzione di un aggiornamento online del firmware del disco prima della configurazione dei volumi sia ancora rapida, si consiglia di impostare sempre questo valore su true per evitare problemi in un secondo momento.

  4. Per ottimizzare le performance, apportare le seguenti modifiche alla configurazione globale:

    # Global Configuration Defaults
eseries_system_cache_block_size: 32768
eseries_system_cache_flush_threshold: 80
eseries_system_default_host_type: linux dm-mp
eseries_system_autoload_balance: disabled
eseries_system_host_connectivity_reporting: disabled
eseries_system_controller_shelf_id: 99 # Required.

  5. Per garantire un provisioning e un comportamento ottimali dei volumi, specificare i seguenti parametri:

    # Storage Provisioning Defaults
eseries_volume_size_unit: pct
eseries_volume_read_cache_enable: true
eseries_volume_read_ahead_enable: false
eseries_volume_write_cache_enable: true
eseries_volume_write_cache_mirror_enable: true
eseries_volume_cache_without_batteries: false
eseries_storage_pool_usable_drives: "99:0,99:23,99:1,99:22,99:2,99:21,99:3,99:20,99:4,99:19,99:5,99:18,99:6,99:17,99:7,99:16,99:8,99:15,99:9,99:14,99:10,99:13,99:11,99:12"
    Nota Il valore specificato per eseries_storage_pool_usable_drives È specifico per i nodi a blocchi NetApp EF600 e controlla l'ordine in cui i dischi vengono assegnati a nuovi gruppi di volumi. Questo ordine garantisce che l'i/o per ciascun gruppo sia distribuito uniformemente tra i canali di dischi back-end.