Risoluzione dei problemi relativi alle configurazioni ad alta disponibilità per SAP

Nelle configurazioni ad alta disponibilità per SAP su Google Cloud, la causa principale dei problemi potrebbe risiedere nel software di clustering, nel software SAP, nell' Google Cloud infrastruttura o in una combinazione di questi elementi.

Analizzare i log di Pacemaker in Cloud Logging

Il seguente video mostra come iniziare a risolvere i problemi relativi alle configurazioni di alta disponibilità per SAP su Google Cloud utilizzando Cloud Logging.

Il nodo non riuscito in un cluster Linux non si riavvia correttamente dopo un failover

Se il cluster ad alta disponibilità Linux utilizza l'agente di recinzione fence_gce e una VM recintata non riesce a rientrare nel cluster dopo un failover, potrebbe essere necessario posticipare l'avvio del software Corosync al riavvio delle VM recintate.

Problema

Durante un failover, l'agente fence_gce esegue il fencing della VM Compute Engine con errore, che si riavvia e si ricollega al cluster prima che Pacemaker registri l'azione di fencing come completata. Poiché l'azione di recinzione non è registrata come completata, la VM riavviata arresta i servizi Pacemaker e Corosync e esce dal cluster.

Diagnosi

Per confermare che si tratta del tuo problema:

• Assicurati che il cluster utilizzi l'agente fence_gce:

  RHEL

  pcs config

  SLES

  crm config show

  La definizione dell'agente di recinzione include fence_gce.

  RHEL

  Stonith Devices:
  Resource: STONITH-example-ha-vm1 (class=stonith type=fence_gce)
  Attributes: port=example-ha-vm1 project=example-project-123456 zone=us-central1-a
  Operations: monitor interval=300s timeout=120s (STONITH-example-ha-vm1-monitor-interval-60s)
  Resource: STONITH-example-ha-vm2 (class=stonith type=fence_gce)
  Attributes: port=example-ha-vm2 project=example-project-123456 zone=us-central1-c
  Operations: monitor interval=300s timeout=120s (STONITH-example-ha-vm2-monitor-interval-60s)
  

  SLES

  primitive fence-example-ha-vm1 stonith:fence_gce \
   op monitor interval=300s timeout=120s \
   op start interval=0 timeout=60s \
   params port=example-ha-vm1 zone=us-central1-a project=example-project-123456
  primitive fence-example-ha-vm2 stonith:fence_gce \
   op monitor interval=300s timeout=120s \
   op start interval=0 timeout=60s \
   params port=example-ha-vm2 zone=us-central1-c project=example-project-123456

• Controlla il log di sistema per verificare la presenza dei seguenti messaggi:

  DATESTAMP> node2 stonith-ng[1106]:  notice: Operation reboot of node2 by node1 for stonith_admin.1366@node1.c3382af8: OK
  DATESTAMP> node2 stonith-ng[1106]:   error: stonith_construct_reply: Triggered assert at commands.c:2343 : request != NULL
  DATESTAMP> node2 stonith-ng[1106]: warning: Can't create a sane reply
  DATESTAMP> node2 crmd[1110]:    crit: We were allegedly just fenced by node1 for node1!
  DATESTAMP> node2 pacemakerd[1055]: warning: Shutting cluster down because crmd[1110] had fatal failure

Soluzione

Configura i sistemi operativi in entrambi i nodi del cluster per ritardare l'avvio di Corosync in modo che l'azione di recinzione abbia il tempo di registrarsi come completata con Pacemaker sul nuovo nodo principale. Imposta inoltre il valore del timeout del riavvio di Pacemaker in modo da tenere conto del ritardo.

Per configurare un avvio ritardato di Corosync:

1. Metti il cluster in modalità di manutenzione:

   RHEL

   pcs property set maintenance-mode=true

   SLES

   crm configure property maintenance-mode="true"

2. Su ogni nodo del cluster come utente root, imposta un ritardo di avvio per Corosync:

   1. Crea un file di plug-in systemd:

      systemctl edit corosync.service

   2. Aggiungi le seguenti righe al file:

      [Service]
      ExecStartPre=/bin/sleep 60

   3. Salva il file ed esci dall'editor.

   4. Ricarica la configurazione del gestore systemd.

      systemctl daemon-reload

3. Su entrambi i nodi del cluster come utente root, verifica che il valore di timeout di Pacemaker per i riavvii sia impostato per entrambi gli agenti di recinzione:

   1. Controlla il valore pcmk_reboot_timeout:

      crm_resource --resource FENCE_AGENT_NAME --get-parameter=pcmk_reboot_timeout

      Sostituisci FENCE_AGENT_NAME con il nome dell'agente di recinzione.

   2. Se il parametro pcmk_reboot_timeout non viene trovato o è impostato su un valore inferiore a 300, imposta il valore su entrambi gli agenti di recinzione:

      crm_resource --resource FENCE_AGENT_NAME --set-parameter=pcmk_reboot_timeout --parameter-value=300

      Sostituisci FENCE_AGENT_NAME con il nome dell'agente di recinzione.

      Il valore pcmk_reboot_timeout deve essere maggiore della somma di:

      • Il timeout di Corosync token
      • Il timeout del consenso di Corosync, che per impostazione predefinita è il prodotto di token * 1,2
      • Il tempo necessario per completare un'operazione di riavvio, incluso qualsiasi attributo di ritardo.

      Su Google Cloud, 300 secondi sono sufficienti per la maggior parte dei cluster.

   3. Conferma il nuovo valore pcmk_reboot_timeout:

      crm_resource --resource FENCE_AGENT_NAME --get-parameter=pcmk_reboot_timeout

      Sostituisci FENCE_AGENT_NAME con il nome dell'agente di recinzione.

4. Rimuovi il cluster dalla modalità di manutenzione:

   RHEL

   pcs property set maintenance-mode=false

   SLES

   crm configure property maintenance-mode="false"

Affinità dei nodi involontaria che favorisce un determinato nodo

Quando sposti manualmente le risorse in un cluster ad alta disponibilità utilizzando i comandi del cluster, scopri che è impostata un'affinità automatica o una preferenza del client per favorire un determinato nodo.

Problema

Nel cluster Linux Pacemaker ad alta disponibilità per SAP HANA o SAP NetWeaver, le risorse come il sistema SAP HANA o i servizi centrali SAP NetWeaver vengono eseguite solo su un determinato nodo del cluster e non eseguono il failover come previsto durante un evento di guasto del nodo.

Di conseguenza, potresti riscontrare problemi come:

• Quando attivi il failover del servizio SAP NetWeaver ASCS emettendo un comando Pacemaker per move una risorsa a un nodo del cluster, la risorsa non si avvia e mostra lo stato stopped.

• Quando emetti il comando standby a un nodo del cluster per forzare il trasferimento di tutte le risorse all'altro nodo, le risorse non si avviano.

Diagnosi

• Controlla i log di Pacemaker per verificare se è presente il messaggio che indica che una determinata risorsa non può essere eseguita da nessuna parte. Ad esempio:

  2021-05-24 21:39:58 node_1 pacemaker-schedulerd (native_color) info:
   Resource NW1-ASCS01 cannot run anywhere

• Controlla la configurazione del vincolo di località di Pacemaker per identificare eventuali vincoli che potrebbero impedire l'esecuzione delle risorse su un determinato nodo del cluster.

  Per controllare la configurazione del vincolo di posizione del pacemaker:

  1. Visualizza i vincoli relativi alla località:

     cibadmin --query --scope constraints | grep rsc_location

  2. Verifica i vincoli di località:

     • Vincolo di località esplicito: puoi trovare i vincoli di località con il punteggio INFINITY (preferisci il nodo) o -INFINITY (evita il nodo). Ad esempio:

       <rsc_location id="loc-constraint" rsc="NW1-ASCS01" score="INFINITY" node="nw-ha-1"/>

       Non devono essere presenti vincoli di località con punteggio INFINITY o -INFINITY diversi dagli agenti di recinzione. In tutti i cluster HA, gli agenti di recinzione sono definiti in un vincolo di località con punteggio -INFINITY per impedire la loro esecuzione sul nodo che è la destinazione della recinzione.

     • Vincolo di posizione implicito: quando emetti il comando Pacemaker per spostare una risorsa in un nodo del cluster o vietare l'esecuzione di una risorsa su un nodo del cluster, viene aggiunto un vincolo di posizione implicito con prefisso cli-ban o cli-prefer all'ID vincolo. Ad esempio:

       <rsc_location id="cli-prefer-NW1-ASCS01" rsc="NW1-ASCS01" role="Started" node="nw-ha-2" score="INFINITY"/>

Soluzione

• Assicurati che i vincoli di località siano specificati come spiegato nelle nostre guide di implementazione:

  • Guida alla configurazione del cluster ad alta disponibilità scalabile verticalmente per SAP HANA su RHEL
  • Guida alla configurazione del cluster ad alta disponibilità scalabile verticalmente per SAP HANA su SLES
  • Guida alla configurazione manuale del cluster ad alta disponibilità per SAP NetWeaver su RHEL
  • Guida alla configurazione manuale del cluster ad alta disponibilità per SAP NetWeaver su SLES

• Per correggere un vincolo di località esplicito, eliminalo:

  RHEL

  pcs constraint remove RESOURCE_LOCATION_ID

  SLES

  crm configure delete RESOURCE_LOCATION_ID

  Sostituisci RESOURCE_LOCATION_ID con l'ID vincolo di località.

• Per correggere una limitazione della località implicita, rimuovi tutti i vincoli definiti sulla risorsa specificata.

  Dopo ogni comando utilizzato per spostare o vietare una risorsa, esegui il seguente comando per rimuovere tutti i vincoli:

  RHEL

  pcs resource clear RESOURCE_NAME

  SLES

  crm resource clear RESOURCE_NAME

  Sostituisci RESOURCE_NAME con il nome della risorsa da spostare.

L'agente di recinzione ha riscontrato un errore operativo

L'agente di recinzione ha segnalato un errore nello stato del cluster.

Problema

Nel cluster ad alta disponibilità Linux Pacemaker per SAP HANA o SAP NetWeaver, l'agente di recinzione ha segnalato un errore nello stato del cluster. Ad esempio:

Failed Resource Actions:
   STONITH-ha-node-01_monitor_300000 on ha-node-02 'unknown error' (1): call=153, status=Timed Out, exitreason='',  last-rc-change='Mon Dec 21 23:40:47 2023', queued=0ms, exec=60003ms

Diagnosi

L'agente di recinzione di cui è stato eseguito il deployment nel cluster ad alta disponibilità SAP HANA o SAP NetWeaver accede regolarmente al server API Compute Engine per controllare lo stato dell'istanza di destinazione del recinto. Se si verifica un ritardo temporaneo nella risposta alla chiamata dell'API o se si verifica un'interruzione della rete, l'operazione di monitoraggio dell'agente di recinzione potrebbe non riuscire o scadere.

Per controllare lo stato dell'agente di recinzione, esegui il seguente comando:

pcs status

crm status

Se lo stato dell'agente di recinzione è stopped, utilizza una delle opzioni di soluzione per risolvere l'errore.

L'errore operativo dell'agente di recinzione potrebbe causare l'interruzione dell'agente, ma Pacemaker chiama comunque gli agenti di recinzione con una direttiva di arresto in un evento di recinzione.

Soluzione

Se lo stato dell'agente di recinzione è stopped, esegui una delle seguenti operazioni:

• Per reimpostare manualmente il conteggio errori e riavviare l'agente di recinzione, esegui il seguente comando:

  RHEL

  pcs resource cleanup FENCE_AGENT_NAME

  SLES

  crm resource cleanup FENCE_AGENT_NAME

  Sostituisci FENCE_AGENT_NAME con il nome dell'agente del recinto.

• Per rimuovere automaticamente l'errore operativo dell'agente di recinzione, configura il parametro failure-timeout.

  Il parametro failure-timeout reimposta il valore failcount al termine della durata specificata ed elimina eventuali errori operativi. L'applicazione di questo parametro non richiede il riavvio del cluster o la sua messa in modalità di manutenzione.

  Per configurare il parametro failure-timeout, esegui il seguente comando:

  crm_resource --meta --resource FENCE_AGENT_NAME --set-parameter failure-timeout --parameter-value DURATION

  Sostituisci quanto segue:

  • FENCE_AGENT_NAME: il nome dell'agente di recinzione.
  • DURATION: la durata che segue l'ultimo errore operativo dopo il quale il conteggio errori viene reimpostato e l'agente di recinzione viene riavviato.

L'agente recinto gcpstonith è deprecato

L'agente di recinzione gcpstonith è attivo nella tua configurazione. Questo agente è stato ritirato e l'Assistenza clienti ti ha comunicato che devi passare a fence_gce.

Problema

Nel cluster ad alta disponibilità Linux Pacemaker per SAP HANA su SUSE Linux viene utilizzato l'agente di recinzione gcpstonith. Ad esempio:

 # crm status | grep gcpstonith
   * STONITH-hana-vm1   (stonith:external/gcpstonith):   Started hana-vm2
   * STONITH-hana-vm2   (stonith:external/gcpstonith):   Started hana-vm1

Diagnosi

L'agente di recinzione di cui è stato eseguito il deployment nel cluster SAP HANA ad alta disponibilità deve essere aggiornato in modo da utilizzare l'agente di recinzione fence_gce incluso nel sistema operativo. Lo script dell'agente gcpstonith è stato pubblicato sui sistemi precedenti ed è stato sostituito da fence_gce. fence_gce è fornito nel pacchetto fence-agents SUSE Linux. gcpstonith è stato fornito solo nell'ambito dei deployment di SUSE Linux HANA.

Soluzione

Per eseguire la migrazione da gcpstonith su SUSE Linux, completa i seguenti passaggi:

1. Installa i seguenti pacchetti aggiuntivi specifici per il tuo sistema operativo:

   • Per SLES 15: python3-oauth2client e python3-google-api-python-client

   • Per SLES 12: python-google-api-python-client, python-oauth2client e python-oauth2client-gce

   Per installare questi pacchetti sul sistema operativo, utilizza il seguente comando:

   SLES 15

   zypper in -y python3-oauth2client python3-google-api-python-client

   SLES 12

   zypper in -y python-google-api-python-client python-oauth2client python-oauth2client-gce

2. Aggiorna il pacchetto fence-agents per assicurarti di avere installato la versione più recente:

   zypper update -y fence-agents

3. Metti il cluster in modalità di manutenzione:

   crm configure property maintenance-mode=true

4. Elimina tutti i dispositivi di recinzione dal cluster. Durante l'eliminazione dell'ultimo dispositivo di recinzione, ti potrebbe essere chiesto di confermare che nel cluster non sono definite risorse STONITH.

   crm configure delete FENCING_RESOURCE_PRIMARY

   crm configure delete FENCING_RESOURCE_SECONDARY

5. Ricrea il dispositivo di recinzione per l'istanza principale:

   crm configure primitive FENCING_RESOURCE_PRIMARY stonith:fence_gce \
    op monitor interval="300s" timeout="120s" \
    op start interval="0" timeout="60s" \
    params port="PRIMARY_INSTANCE_NAME" zone="PRIMARY_ZONE" \
    project="PROJECT_ID" \
    pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30

6. Ricrea il dispositivo di recinzione per l'istanza secondaria:

   crm configure primitive FENCING_RESOURCE_SECONDARY stonith:fence_gce \
    op monitor interval="300s" timeout="120s" \
    op start interval="0" timeout="60s" \
    params port="SECONDARY_INSTANCE_NAME" zone="SECONDARY_ZONE" \
    project="PROJECT_ID" \
    pcmk_reboot_timeout=300 pcmk_monitor_retries=4

7. Imposta i vincoli di località:

   crm configure location FENCING_LOCATION_NAME_PRIMARY \
    FENCING_RESOURCE_PRIMARY -inf: "PRIMARY_INSTANCE_NAME"
   
   crm configure location FENCING_LOCATION_NAME_SECONDARY \
    FENCING_RESOURCE_SECONDARY -inf: "SECONDARY_INSTANCE_NAME"
   

8. Rimuovi il cluster dalla modalità di manutenzione:

   crm configure property maintenance-mode=false

9. Controlla la configurazione:

   crm config show related:FENCING_RESOURCE_PRIMARY
   

10. Controlla lo stato del cluster:

    # crm status | grep fence_gce
      STONITH-hana-vm1   (stonith:fence_gce):   Started hana-vm2
      STONITH-hana-vm2   (stonith:fence_gce):   Started hana-vm1
    

L'agente della risorsa è stato interrotto

L'avvio di un agente delle risorse non è riuscito e rimane nello stato Stopped.

Problema

Nel cluster ad alta disponibilità Linux Pacemaker per SAP HANA o SAP NetWeaver, un agente delle risorse ha segnalato un errore nello stato del cluster. Ad esempio:

Failed Resource Actions:
   rsc_SAPHana_DV0_HDB00_start_0 on ha-node-02 'error' (1): call=91, status='complete', last-rc-change='Wed Oct 18 18:00:31 2023', queued=0ms, exec=19010ms

Diagnosi

Se un agente di risorse in esecuzione non va a buon fine, Pacemaker tenta di interromperlo e riavviarlo. Se l'operazione di avvio non va a buon fine per qualsiasi motivo, Pacemaker imposta il valore failcount della risorsa su INFINITY e tenta di avviare l'agente su un altro nodo. Se l'agente delle risorse non riesce ad avviarsi su nessun nodo, rimane nello stato Stopped.

Per controllare lo stato dell'agente delle risorse, esegui il seguente comando:

pcs status

crm status

Per SAP HANA, l'esempio seguente mostra l'agente delle risorse nello stato Stopped sul nodo hana-b:

Full List of Resources:
  * STONITH-hana-a        (stonith:fence_gce):   Started hana-b
  * STONITH-hana-b        (stonith:fence_gce):   Started hana-a
  * Resource Group: g-primary:
    * rsc_vip_int-primary       (ocf::heartbeat:IPaddr2):        Started hana-a
    * rsc_vip_hc-primary        (ocf::heartbeat:anything):       Started hana-a
  * Clone Set: cln_SAPHanaTopology_DV0_HDB00 [rsc_SAPHanaTopology_DV0_HDB00]:
    * Started: [ hana-a hana-b ]
  * Clone Set: msl_SAPHana_DV0_HDB00 [rsc_SAPHana_DV0_HDB00] (promotable):
    * Masters: [ hana-a ]
    * Stopped: [ hana-b ]
  * STONITH-scaleup-majority    (stonith:fence_gce):   Started hana-b

Soluzione

Se un agente della risorsa è nello stato Stopped:

1. Avvia manualmente l'agente delle risorse reimpostando il valore failcount:

   RHEL

   pcs resource cleanup RESOURCE_AGENT_NAME

   SLES

   crm resource cleanup RESOURCE_AGENT_NAME

   Sostituisci RESOURCE_AGENT_NAME con il nome dell'agente risorsa. Ad esempio rsc_SAPHana_DV0_HDB00.

2. Assicurati che lo stato dell'agente delle risorse raggiunga lo stato Started:

   crm_mon

   Se l'agente delle risorse continua a non avviarsi, raccogli le informazioni di diagnostica pertinenti e contatta l'assistenza.

Errore di comunicazione tra le VM a causa di route di rete locale per gli IP virtuali

Il traffico di rete da una VM di backend a un'altra VM non riesce a causa delle route di rete locale per gli IP virtuali.

Problema

Quando le VM fanno parte di un bilanciatore del carico di rete passthrough interno, la comunicazione di rete di backend all'IP virtuale (VIP) dell'ILB viene considerata locale e gestita dal dispositivo loopback.

Questo comportamento di loopback impedisce a una VM di backend di utilizzare correttamente l'IP virtuale dell'ILB per raggiungere i servizi potenzialmente ospitati su altre VM di backend che utilizzano l'ILB, provocando un errore di comunicazione.

Ad esempio: errore di comunicazione tra ASCS ed ERS in un cluster SAP Netweaver HA configurato come backend del bilanciatore del carico.

Il test telnet genera un errore Connection Refused perché questo routing locale non consente al traffico di raggiungere la VM prevista:

   [root@test-server-ha ~]# telnet IP_ADDRESS_OF_ILB PORT_NUMBER
   Trying IP_ADDRESS_OF_ILB...
   telnet: connect to address IP_ADDRESS_OF_ILB: Connection refused

Diagnosi

Prerequisito:

Le VM interessate sono elencate come membri di un gruppo di istanze non gestite configurato come backend del bilanciatore del carico.

Quando una VM di backend all'interno di un bilanciatore del carico interno (ILB) avvia la comunicazione con l'IP virtuale (VIP) dell'ILB, si verifica un comportamento di routing specifico.

Sebbene l'IP virtuale sia configurato su un'interfaccia di rete standard come eth0 e sia elencato nella tabella di routing locale, il kernel instrada i pacchetti destinati a questo VIP locale utilizzando l'interfaccia loopback lo. Questo loopback interno significa che il pacchetto non esce mai dalla VM di origine per essere elaborato dall'ILB.

Sebbene la comunicazione diretta tra le VM di backend che utilizzano i rispettivi IP funzioni, questo comportamento di loopback impedisce a una VM di backend di utilizzare correttamente l'IP virtuale dell'ILB per raggiungere i servizi potenzialmente ospitati su altre VM di backend utilizzando il bilanciatore del carico di rete passthrough interno.

   [root@test-server-ha ~]# ip route show table local
   local IP_ADDRESS_OF_ILB dev eth0 proto 66 kernel scope host src IP_ADDRESS_OF_ILB
   local IP_ADDRESS_OF_THE_CURRENT_NODE dev eth0 proto kernel scope host src IP_ADDRESS_OF_THE_CURRENT_NODE
   local IP_ADDRESS_OF_THE_OTHER_NODE dev eth0 proto kernel scope host src IP_ADDRESS_OF_THE_OTHER_NODE
   broadcast IP_ADDRESS dev lo proto kernel scope link src IP_ADDRESS
   local IP_ADDRESS dev lo proto kernel scope host src IP_ADDRESS
   broadcast IP_ADDRESS dev lo proto kernel scope link src IP_ADDRESS

   ip route get IP_ADDRESS_OF_ILB

L'output di questo comando mostra un'interfaccia loopback lo:

   [root@test-server-ha ~]# ip route get IP_ADDRESS_OF_ILB
   local IP_ADDRESS_OF_ILB dev lo src IP_ADDRESS_OF_ILB uid 0
   cache <local>

Soluzione

Attiva la comunicazione di backend tra le VM modificando la configurazione di google-guest-agent, che è inclusa nell'ambiente guest Linux per tutte le immagini pubbliche Linux fornite da Google Cloud.

Per abilitare le comunicazioni del backend del bilanciatore del carico, svolgi i seguenti passaggi su ogni VM che fa parte del cluster:

1. Interrompi l'agente:

   sudo service google-guest-agent stop
   

2. Apri o crea il file /etc/default/instance_configs.cfg per la modifica:

   sudo vi /etc/default/instance_configs.cfg
   

3. Nel file /etc/default/instance_configs.cfg, specifica le seguenti proprietà di configurazione come mostrato. Se le sezioni non esistono, creane di nuove. In particolare, assicurati che le proprietà target_instance_ips e ip_forwarding siano impostate su false:

   [IpForwarding]
   ethernet_proto_id = 66
   ip_aliases = true
   target_instance_ips = false
   
   [NetworkInterfaces]
   dhclient_script = /sbin/google-dhclient-script
   dhcp_command =
   ip_forwarding = false
   setup = true
   

4. Avvia il servizio dell'agente ospite:

   sudo service google-guest-agent start
   

Per applicare le modifiche, esegui un riavvio della VM o segui i passaggi riportati di seguito per eliminare il percorso locale

1. Elimina la route locale che restituisce il traffico:

   sudo ip route del table local $(ip route show table local | grep "proto 66" | awk '{print $2}') dev eth0
   

   Il comando precedente è una sequenza di comandi Linux collegati in modo da eliminare il VIP dalla tabella di routing locale. Analizziamoli singolarmente:

   L'indirizzo IP viene identificato utilizzando:

   ip route show table local | grep "proto 66" | awk '{print $2}'
   

   Quindi, invialo al comando di eliminazione effettivo:

   ip route del table local
   

2. Riavvia l'agente ospite Google:

   systemctl google-guest-agent restart
   

Questa modifica non comporta interruzioni. Il riavvio di google-guest-agent ricrea una nuova route di rete che indica al traffico di rete di utilizzare eth0 anziché il dispositivo loopback per inviare il traffico al VIP.

Per verificare le modifiche:

   ip route get IP_ADDRESS_OF_ILB

L'output di questo comando deve mostrare l'interfaccia di rete come eth0 e non l'interfaccia lo di loopback:

   [root@test-server-ha ~]# ip route get IP_ADDRESS_OF_ILB
   IP_ADDRESS_OF_ILB via IP_ADDRESS_OF_ILB dev eth0 src IP_ADDRESS_OF_ILB uid 0
   cache

Prova il test telnet:

   [root@test-server-ha ~]# telnet IP_ADDRESS_OF_ILB PORT_NUMBER
   Trying IP_ADDRESS_OF_ILB...
   Connected to IP_ADDRESS_OF_ILB.
   Escape character is '^]'.