Destinazioni affidabili e scambio di certificati TLS Db2

Dopo aver attivato la replica sui sistemi di origine e di destinazione, è necessario utilizzare l'API REST di replica Q Db2 per accreditare la destinazione e scambiare i certificati TLS (Transport Layer Security) tra i sistemi di origine e di destinazione.

Informazioni su questa attività

Questa attività viene eseguita sull'host cluster per l'origine di replica prima di aggiungere la destinazione di replica. Raccogliere le seguenti informazioni prima di eseguire le chiamate API:
  • Il token di autorizzazione di base del database di origine della replica.
  • Il nome host del database di destinazione della replica.
  • Il nome utente del database di destinazione della replica.
  • La password utente del database di destinazione della replica.
  • Il numero di porta esterna del server API REST di replica per il database di destinazione della replica.
  • L'ambiente di destinazioneDB2U-SA-DB2WH )
1 È necessario creare un token di autorizzazione di base per eseguire una richiesta cURL . Per creare il token, eseguire questo comando:
echo "<source_db_username>:<source_db_password>" | base64
dove source fa riferimento al database di origine o di destinazione.
2 È possibile richiamare il numero di porta esterna del server API REST di replica eseguendo il seguente comando dal sistema di destinazione:
oc get svc -n <your_db2_instance_namespace> | grep <your_db2_instance_id> | grep 9444 | sed 's/.*9444://' | sed 's/\/TCP.*//')
Nota: la replica deve essere eseguita in modalità di applicazione SELinux (Security Enhanced Linux ).

Procedura

  1. Richiedi al database di origine della replica di considerare attendibile il database di destinazione della replica. Questa chiamata API importa il certificato SSL REST del database di destinazione nel truststore del sistema di origine, per l'esecuzione API. La chiamata API scambia anche i certificati IBM MQ tra i sistemi di origine e di destinazione per la codifica dei messaggi IBM MQ .
    curl --insecure -X POST  --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'Authorization: Basic <your_authorization_token>' 'https://source_hostname:{source_rest_external_port}/dr/v2/target/trust-target?targetEnvironment=<target_environment_type>' -H "accept: application/json" -H "Content-Type: application/json" -d '{ "targetDatabaseHost": "<target_hostname>", "targetDatabaseUsername": "<user_name>", "targetDatabasePassword": "<password>", "targetRestServerPort": <target_rest_external_port>}'

    Verificare che lo stato sia TRUSTED nella risposta API prima di procedere con il passo successivo. In caso contrario, esaminare il codice di errore, il messaggio e la risoluzione nella risposta.

  2. scambiare i certificati Db2® tra i database di origine e di destinazione. Questa chiamata API avvia la configurazione del certificato TLS Db2 sia sul sistema locale che su quello remoto. È possibile monitorare l'avanzamento utilizzando il sito URL restituito dalla chiamata. 
    curl --insecure -X PUT --header 'Content-Type: application/json' --header 'Accept: application/json'  --header 'Authorization: Basic <your_authorization_token>'  
'https://<source_hostname>:<source_rest_external_port>/dr/v1/target/configure_db2_ssl/<source_database_name>/<target_database_name>/<target_db2_ssl_external_port>/BLUDB/<target_rest_external_port>?restartOption=Y' -H "accept: application/json" -H "Content-Type: application/json" -d '{ "dbUsername": "<target_database_user_name>", "dbPassword": "<password>"}'

    Se la chiamata ha esito positivo, il server API REST di replica Q Db2 viene riavviato dopo 60 secondi sui contenitori di replica di origine e di destinazione.

    Questa chiamata API restituisce un numero lavoro (id).

    {
  "id": <job_number>,
  "url": "https://<source_hostname>:<source_rest_external_port>/dr/v1/target/progress/<job_number>"
}

    Includi il numero del lavoro nella seguente chiamata API per verificare l'avanzamento dello scambio TLS:

    curl --insecure -X GET --header 'Content-Type: application/json' --header 'Accept: application/json'  --header 'Authorization: Basic <your_authorization_token>'   
'https://<source_hostname>:<source_rest_external_port>/dr/v1/target/progress/<job number>'

    L'esecuzione di questa chiamata API riavvia il server API REST di replica sia sul sistema di origine che su quello di destinazione. Questo riavvio può richiedere fino a 10 minuti.

  3. Pianificare il riavvio dei server di origine e di destinazione Db2 affinché i certificati scambiati diventino effettivi all'interno dei pod Db2 di origine e di destinazione.
  4. Dopo che lo scambio di certificati TLS Db2 ha risposto con executionState=COMPLETED e overallJobResult=PASS, puoi continuare a creare un set di replica. Finché non vengono restituiti questi valori, esaminare il codice di errore, il messaggio e la risoluzione nella risposta per trovare la soluzione.
  5. Verificare che l'API REST di replica sia attivo eseguendo i seguenti comandi: 
    oc exec -i {<source_replication_podname>} -- /opt/ibm/bludr/scripts/bin/bludr-status.sh 
oc exec -i {<target_replication_podname>} -- /opt/ibm/bludr/scripts/bin/bludr-status.sh

Risultati

L'operazione di destinazione sicura è completa quando viene restituito un messaggio di risposta che contiene "state": "TRUSTED" . Il database di origine di replica inizia quindi la comunicazione con il server API REST di destinazione. Finché non viene restituito questo valore, esaminare il codice di errore, il messaggio e la risoluzione nella risposta.

Lo scambio di certificati TLS Db2 è completo quando viene restituito un messaggio di risposta contenente "executionState": "COMPLETED", "overallJobResult": "PASS" . Il database di origine di replica e il database di destinazione di replica possono ora connettersi tra loro per continuare l'impostazione della replica. Finché questi valori non vengono restituiti, esaminare il codice di errore, il messaggio e la risoluzione nella risposta.

La tabella seguente elenca i possibili codici di stato HTTP e i messaggi di risposta per le chiamate API per lo scambio di certificati TLS trust-target e Db2. Include inoltre il codice di esempio per mostrare la sintassi della risposta.
Codice stato HTTP Motivo Modello di risposta

200

 La destinazione è attendibile e il certificato TLS Db2 è stato scambiato La richiesta dell'utente restituisce "state": "TRUSTED" quando l'operazione di destinazione sicura è completa:

{
  "name": "TRUST_TARGET_SUCCESS",
  "message": "Trust Targets process complete.",
  "values": [
    {
      "key": "targetDatabaseHost",
      "value": "dr-target2.ibm.com"
    },
    {
      "key": "targetDatabaseUsername",
      "value": "dradmin1"
    }
  ],
  "state": "TRUSTED"
}
La richiesta dell'utente restituisce un lavoro (id) e URL nello scambio di certificati SSL Db2 ::

{
  "id": 6,
  "url": " https://dr-source1.ibm.com:31023/dr/v1/replicationset/progress/6"
}
La richiesta utente restituisce una risposta corretta per il completamento della chiamata API (valore di esempio):

{
  "id": 6,
  "url": "https://dr-source1.ibm.com:31023/dr/v1/target/progress/6",
  "executionState": "COMPLETED",
  "overallJobResult": "PASS",
  "localJobStatusList": [
    {
      "jobKey": "fetchRemoteDB2SSLCertificate",
      "jobDescription": "Fetches DB2 SSL Certificate from remote system.",
      "execState": "COMPLETED",
      "jobResult": "PASS",
      "values": [
        {
          "key": "dbHost",
          "value": "dr-target2.ibm.com"
        }
      ],
      "errors": []
    },
    {
      "jobKey": "importRemoteDB2SSLCertificate",
      "jobDescription": "Imports remote DB2 SSL Certificate into local QREP and DB2 Client keystore.",
      "execState": "COMPLETED",
      "jobResult": "PASS",
      "values": [
        {
          "key": "dbHost",
          "value": " dr-target2.ibm.com"
        }
      ],
      "errors": []
    },
    {
      "jobKey": "remoteDB2SSLCertificateConfiguration",
      "jobDescription": "Configures local DB2 SSL certificate on remote system. Restarts QREP Rest server on local and remote system if restart option has been selected as 'Y' after this job has been completed.",
      "execState": "COMPLETED",
      "jobResult": "PASS",
      "values": [
        {
          "key": "dbHost",
          "value": " dr-target2.ibm.com"
        }
      ],
      "errors": []
    }
  ],
  "remoteJobStatusList": []
}
4xx Errore di richiesta client La richiesta dell'utente non è stata soddisfatta a causa di una sintassi della richiesta non corretta o di altri problemi del client:
{
  "errorCode": "string",
  "errorMessage": "string",
  "errorResolution": "string"
}
5xx Errore del server La richiesta dell'utente sembrava valida, ma non è stata soddisfatta a causa di un problema con il server:
{
  "errorCode": "string",
  "errorMessage": "string",
  "errorResolution": "string"
}

Esempio

Il seguente esempio mostra la sintassi del comando per richiamare il comando API REST di replica per richiedere al database di origine di replica di considerare attendibile il database di destinazione:
curl –insecure -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'Authorization: Basic ZHNhZG06MDNRVWlMczFhcmoxb3ky' -d '{ "targetDatabaseHost": "dr-target2.ibm.com", "targetDatabaseUsername": "dradmin1", "targetDatabasePassword": "dradminpassword", "targetRestServerPort": 32483 }' 'https://dr-source1.ibm.com:31023/dr/v2/target/trust-target?targetEnvironment=DB2U-SA-DB2WH'
Il seguente esempio mostra la sintassi della risposta per il precedente comando:
{ 
  "name": "TRUST_TARGET_SUCCESS",
  "message": "Trust Targets process complete.",
  "values": [
    {
      "key": "targetDatabaseHost",
      "value": "dr-target2.ibm.com"
    },
    {
      "key": "targetDatabaseUsername",
      "value": "dsadm"
    }
  ],
  "state": "TRUSTED"
}
Il seguente esempio mostra la sintassi del comando per richiamare l'API REST di replica per scambiare i certificati TLS Db2 tra il contenitore di origine dr-source1.ibm.com e il contenitore di destinazione dr-target2.ibm.com:
Curl --insecure -X PUT --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'Authorization: Basic ZHNhZG06MDNRVWlMczFhcmoxb3ky' -d '{ "dbUsername": "dradmin1", "dbPassword": "dradminpassword" }' 
'https://dr-source1.ibm.com:31023/dr/v1/target/configure_db2_ssl/dr-source1.ibm.com/dr-target2.ibm.com/30138/BLUDB/32483?restartOption=Y'
Il seguente esempio mostra la sintassi del comando per controllare lo stato di avanzamento dello scambio di certificati TLS tramite chiamata API utilizzando il job numero 6:
{
  "id": 6,
  "url": "https://dr-source1.ibm.com:31023/dr/v1/target/progress/6"
}

Cosa fare successivamente

Configurazione di target e set di replica con l'API REST di replica Q dell' Db2