Inicializar el clúster de Omnissa Access Control Plane

Siga los procedimientos que se indican a continuación para inicializar el clúster de Omnissa Access Control Plane desde el nodo de arranque. Todos los comandos deben ejecutarse desde el nodo de arranque.

Inicializar el clúster del plano de control

Procedimiento:

• Siga las instrucciones que figuran a continuación para inicializar el clúster del plano de control.

  Nota: Ejecute el siguiente comando, sustituyendo <size_of_your_deployment> por small, medium o large, según el tamaño de OVA que implementó:

  cd /opt/wss/<cluster_name>
  wso access init -n cp-cluster -s <size_of_your_deployment>
  

  Al ejecutar este comando, el resultado será similar al siguiente:

  cd /opt/wss/<cluster_name>
  wso access init -n cp-cluster -s small
  
  # Output
  <timestamp> Control Plane name: cp-cluster
  <timestamp> Created a sample profile.yml file
  <timestamp> Sample Control Plane inventory file created
  <timestamp> Created a sample telemetry config file: /opt/wss/<cluster_name>/telegraf_plugin/prometheus_remote_write.conf.example
  <timestamp> Successfully initialized
  

Resultados:

Este comando crea los siguientes archivos:

• Archivo de inventario de clúster: /opt/wss/<cluster_name>/cp-cluster/cp-cluster.ini
• Archivo de configuración de implementación: /opt/wss/<cluster_name>/profile.yml

Configurar el inventario del clúster

El archivo cp-cluster.ini define los siguientes elementos:

• Nodos de infraestructura/plataforma
• Nodos de Omnissa Access

Generar un archivo de clave privada SSH:

Si tiene previsto utilizar ansible_ssh_private_key_file para conectarse a los nodos del clúster (en lugar de ansible_password), genere el archivo de clave que se indica a continuación antes de rellenar el archivo cp-cluster.ini.

# On bootstrap node follow below steps
# change to configuser
su configuser

# Generate Public and private keys
ssh-keygen -t <cipher>

# Copy public Key to all other machines (Access+Infra+platform)
ssh-copy-id configuser@10.0.0.X 
# Repeat this for all cluster VMs from bootstrap VM

# Test login work with other machines without password
ssh configuser@10.0.0.X
# You should be able to login to 10.0.0.X from bootstrap without credentials

# Exit from 10.0.0.X by using exit command, so that you are in bootstrap machine. 
exit 
# Exit as configuser; run again to return to root

# create a directory in bootstrap machine
mkdir -p /opt/wss/<cluster_name>/cp-cluster/private-key

# Copy the private key to PATH
cp /home/configuser/.ssh/id_<cipher> /opt/wss/<cluster_name>/cp-cluster/private-key

# change the permission of file
chmod 400 /opt/wss/<cluster_name>/cp-cluster/private-key/id_<cipher>

Procedimiento para rellenar automáticamente el archivo cp-cluster.ini:

Ejecute el siguiente comando:

update-cluster-ini INI_FILE=/opt/wss/<cluster_name>/cp-cluster/cp-cluster.ini

# Output

[root@bootstrap configuser]# update-cluster-ini INI_FILE=/opt/wss/<cluster_name>/cp-cluster/cp-cluster.ini
Enter User (this is the user created at OVA deployment): configuser
Use (1) password or (2) ssh_private_key_file?
Enter 1 or 2: 1
Enter password:
Deployment size: (1) small  (2) medium  (3) large
Enter 1, 2, or 3: 1
Enter Omnissa Access Node IPs (2 IPs required, comma or space separated): 10.0.0.x 10.0.0.x
Enter infra and platform node IPs (3 IPs required, comma or space separated): 10.0.0.x 10.0.0.x 10.0.0.x 
Moved existing /opt/wss/<cluster_name>/cp-cluster/cp-cluster.ini to /opt/wss/<cluster_name>/cp-cluster/cp-cluster.ini.bkp.20260714_052152
Written /opt/wss/<cluster_name>/cp-cluster/cp-cluster.ini (small): access=2, infra=3, asset=2.

Nota: Nota: Cuando se le solicite la contraseña, introduzca la misma contraseña que utilizó para la cuenta configuser durante la implementación de la OVA. Esta contraseña debe ser idéntica en todos los nodos de arranque, de Omnissa Access y de infraestructura/plataforma del clúster.

Procedimiento manual para actualizar el archivo cp-cluster.ini:

1. Abra el archivo cp-cluster.ini. Por ejemplo:

   vi /opt/wss/<cluster_name>/cp-cluster/cp-cluster.ini
   

2. Siga las instrucciones que aparecen a continuación para actualizar el archivo.

   Nota: ansible_user siempre debe establecerse en configuser.

   A continuación, seleccione un método de autenticación:

   • ansible_password: confirme que el campo esté establecido en la contraseña de configuser.
   • ansible_ssh_private_key_file: la clave privada SSH generada para configuser (consulte Generar un archivo de clave privada SSH más arriba).

   Utilice uno u otro, no ambos.

   [linux:children]
   asset_server_linux
   consul_server_linux
   general_compute_linux
   kafka_controller_linux
   kafka_server_linux
   nomad_server_linux
   opensearch_leader_linux
   opensearch_data_linux
   postgres_linux
   vault_server_linux
   general_compute_nginx_http
   general_compute_access_linux
   
   # This template includes sample IPs. Please update these to match your specific environment settings.
   
   # Provide IPs to asset server nodes
   [asset_server_linux]
   10.0.0.1
   10.0.0.2
   
   # Provide IPs to all Infrastructure/Platform and Omnissa Access nodes
   [consul_server_linux]
   10.0.0.1
   10.0.0.2
   10.0.0.3
   10.0.0.4
   10.0.0.5
   
   # Provide IPs to all Infrastructure/Platform and Omnissa Access nodes
   [vault_server_linux]
   10.0.0.1
   10.0.0.2
   10.0.0.3
   10.0.0.4
   10.0.0.5
   
   # Provide IPs to all Infrastructure/Platform and Omnissa Access nodes
   [nomad_server_linux]
   10.0.0.1
   10.0.0.2
   10.0.0.3
   10.0.0.4
   10.0.0.5
   
   # Provide IPs to kafka controller nodes
   [kafka_controller_linux]
   10.0.0.1
   10.0.0.2
   10.0.0.3
   
   # Provide IPs to kafka server nodes
   [kafka_server_linux]
   10.0.0.1
   10.0.0.2
   10.0.0.3
   
   # Provide IPs to postgres server nodes
   [postgres_linux]
   10.0.0.1
   10.0.0.2
   10.0.0.3
   
   # Provide IPs to Opensearch leader nodes
   [opensearch_leader_linux]
   10.0.0.1
   10.0.0.2
   10.0.0.3
   
   # Provide IPs to Opensearch data nodes
   [opensearch_data_linux]
   10.0.0.1
   10.0.0.2
   10.0.0.3
   
   # Provide IPs to General compute nodes
   [general_compute_linux]
   10.0.0.1
   10.0.0.2
   10.0.0.3
   
   # Provide IPs to access compute nodes
   [general_compute_access_linux]
   10.0.0.4
   10.0.0.5
   
   # Provide IPs to Nginx HTTP server nodes
   [general_compute_nginx_http]
   10.0.0.4
   10.0.0.5
   
   [linux:vars]
   # Uncomment ansible_user, ansible_password or ansible_ssh_private_key_file below to provide common credentials to connect to each of the specified nodes
   # Only one of password or ssh private key can be provided
   #ansible_user=
   #ansible_password=
   #ansible_ssh_private_key_file=
   

Actualizar el archivo profile.yml

Este procedimiento garantiza que, inicialmente, solo se implementen los servicios básicos de infraestructura.

El archivo profile.yml (/opt/wss/<cluster_name>/profile.yml) contiene los parámetros de configuración a nivel de implementación para el entorno del clúster. Se utiliza principalmente para configurar lo siguiente:

• Sincronización de hora (NTP)

• Almacenamiento compartido (NFS)

• Integración de registro centralizado

  La sección de registro permite a los servicios del clúster reenviar los registros a plataformas de registro centralizadas, tales como:

  • Loki
  • OpenSearch
  • Syslog

  Ejemplo de estructura:

  # logging:
  # loki_server:
  #    url:
  #    username:
  #    password:
  # opensearch:
  #    url: https://10.0.0.x:<port>
  #    username: host-logging-writer
  #    password: *******
  #    index_prefix: access_logs
  # syslog_servers:
  #    host:
  #    protocol: udp
  #    port: 514
  #    syslog_cert_passphrase:   # only if your syslog client key in the logging directory is passphrase-protected  
  

Avisos importantes

• Es posible que, para que los cambios en la configuración de registro surtan efecto tras la implementación, sea necesario volver a implementar el sistema o actualizarlo.
• Quite la marca de comentario y configure únicamente las secciones necesarias.
• Asegúrese de que se pueda acceder a todos los servicios externos (NTP, NFS, servidores de registro) desde los nodos del clúster.
• Este procedimiento no es obligatorio, pero si su organización dispone de un servidor NTP, puede habilitar y actualizar la configuración del servidor NTP con la dirección del servidor.

Procedimiento:

1. Abra el archivo profile.yml. Por ejemplo:

   vi /opt/wss/<cluster_name>/profile.yml
   

2. Quite los comentarios de las configuraciones utilizadas para configurar el almacenamiento compartido basado en NFS (si lo desea) y el servidor NTP (recomendado) para el clúster, de la siguiente manera:

   # Uncomment and provide NTP server to configure for time synchronization on the cluster nodes
   # ntp_server:
   
   # Uncomment and provide NFS server to configure Network File Share on the cluster nodes
   # nfs_host: 10.0.0.x
   # nfs_path:
   # nfs_version: 4
   

3. Revise el resto del archivo profile.yml y actualice otras secciones necesarias, como el registro y las métricas.

4. Guarde el archivo profile.yml.

5. Ejecute el siguiente comando para validar el archivo profile.yml.

   wso cp precheck
   
   # Output
   Cluster Size is (small)...
   The following errors were found in the cluster configuration:
   logging configuration is not set
   telemetry configuration is not set
   nfs backup server info is not set
   
   Please fix the above errors and validate the cluster configuration again.
   

   Nota: Si wso cp precheck informa de que no se ha establecido la información del servidor de registro, telemetría o copia de seguridad NFS, estos errores son esperables si no ha configurado esas opciones opcionales. Puede ignorarlos sin problemas y continuar con wso access validate.

Validar el archivo de inventario del clúster

• Después de actualizar el archivo de inventario (.ini), valídelo. Por ejemplo:

  wso access validate
  
  # OUTPUT
  <timestamp> Inventory file validated successfully.
  

  Nota: wso access validate puede informar de que la validación se ha realizado correctamente aunque wso cp precheck haya informado anteriormente de errores de configuración. Este comportamiento es esperado. Continúe con wso access validate independientemente de las advertencias de precheck.