A figura a seguir mostra uma instalação padrão na qual o agente SnapCenter, juntamente com o plug-in do banco de dados, foi instalado localmente no servidor de origem e no servidor de banco de dados de destino. Na configuração do laboratório, instalamos o plug-in SAP HANA, além disso, o trabalhador LSC também foi instalado no servidor de destino. Para simplificar e reduzir o número de servidores virtuais, instalamos o mestre LSC no servidor SnapCenter. A comunicação entre os diferentes componentes é ilustrada na figura seguinte.

A figura a seguir mostra a configuração usando um host de comunicação central. Nessa configuração, o agente SnapCenter junto com o plug-in SAP HANA e o cliente do banco de dados HANA foram instalados em um servidor dedicado. Nesta configuração, usamos o servidor SnapCenter para instalar o host de comunicação central. Além disso, o trabalhador LSC foi novamente instalado no servidor de destino. Para simplificar e reduzir o número de servidores virtuais, decidimos também instalar o mestre LSC no servidor SnapCenter. A comunicação entre os diferentes componentes é ilustrada na figura abaixo.

Esta seção descreve as etapas de configuração necessárias ao usar uma instalação padrão onde o agente SnapCenter e o plug-in de banco de dados necessário estão instalados nos sistemas de origem e destino. Ao usar uma instalação padrão, todas as tarefas necessárias para montar o volume do clone e restaurar e recuperar o sistema de destino são realizadas a partir do agente SnapCenter que está sendo executado no sistema de banco de dados de destino no próprio servidor. Isso permite o acesso a todos os detalhes relacionados a clones que estão disponíveis por meio de variáveis ambientais do agente SnapCenter. Portanto, você só precisa criar uma tarefa adicional na fase de cópia do LSC. Essa tarefa realiza o processo de cópia Snapshot no sistema de banco de dados de origem e o processo de clone e restauração e recuperação no sistema de banco de dados de destino. Todas as tarefas relacionadas ao SnapCenter são acionadas usando um script do PowerShell que é inserido na tarefa LSC NTAP_SYSTEM_CLONE .

A imagem seguinte mostra a configuração da tarefa LSC na fase de cópia.

A imagem a seguir destaca a configuração do NTAP_SYSTEM_CLONE processo. Como você está executando um script do PowerShell, esse script do Windows PowerShell é executado no sistema de satélite. Neste caso, este é o servidor SnapCenter com o mestre LSC instalado que também atua como um sistema de satélite.

Como o LSC precisa saber se a operação de cópia, clonagem e recuperação do Snapshot foi bem-sucedida, é necessário definir pelo menos dois tipos de código de retorno. Um código é para uma execução bem-sucedida do script, e o outro código é para uma execução falha do script, como mostrado na imagem a seguir.

A imagem a seguir mostra parte do script do PowerShell que deve ser executado para executar um backup baseado em Snapshot no sistema de banco de dados de origem e um clone no sistema de banco de dados de destino. O script não se destina a ser concluído. Em vez disso, o script mostra como a integração entre o LSC e o SnapCenter pode parecer e como é fácil configurá-lo.

Como o script é executado no mestre LSC (que também é um sistema de satélite), o mestre LSC no servidor SnapCenter deve ser executado como um usuário do Windows que tenha permissões apropriadas para executar operações de backup e clonagem no SnapCenter. Para verificar se o usuário tem permissão apropriada, o usuário deve poder executar uma cópia Snapshot e um clone na IU do SnapCenter.

Não há necessidade de executar o mestre LSC e o satélite LSC no próprio servidor SnapCenter. O mestre LSC e o satélite LSC podem ser executados em qualquer máquina Windows. O pré-requisito para executar o script do PowerShell no satélite LSC é que os cmdlets do SnapCenter PowerShell foram instalados no Windows Server.

Para integração entre LSC e SnapCenter usando um host de comunicação central, os únicos ajustes que devem ser feitos são executados na fase de cópia. A cópia Snapshot e o clone são criados usando o agente SnapCenter no host de comunicação central. Portanto, todos os detalhes sobre os volumes recém-criados estão disponíveis apenas no host de comunicação central e não no servidor de banco de dados de destino. No entanto, esses detalhes são necessários no servidor de banco de dados de destino para montar o volume do clone e realizar a recuperação. Esta é a razão pela qual duas tarefas adicionais são necessárias na fase de cópia. Uma tarefa é executada no host de comunicação central e uma tarefa é executada no servidor de banco de dados de destino. Estas duas tarefas são mostradas na imagem abaixo.

A imagem a seguir destaca a configuração da tarefa NTAP_SYSTEM_CLONE_CP. Este é o script do Windows PowerShell que é executado no sistema de satélite. Neste caso, o sistema de satélite é o servidor SnapCenter com o mestre LSC instalado.

Como o LSC precisa estar ciente de que a operação de clonagem e cópia Snapshot foi bem-sucedida, você deve definir pelo menos dois tipos de código de retorno: Um código de retorno para uma execução bem-sucedida do script e o outro para uma execução com falha do script, como mostrado na imagem abaixo.

A imagem a seguir mostra parte do script do PowerShell que deve ser executado para executar uma cópia Snapshot e um clone usando o agente SnapCenter no host de comunicação central. O script não deve estar completo. Em vez disso, o script é usado para mostrar como a integração entre o LSC e o SnapCenter pode parecer e como é fácil configurá-lo.

Como mencionado anteriormente, você deve entregar o nome do volume do clone para a próxima tarefa NTAP_MNT_RECOVER_CP para montar o volume do clone no servidor de destino. O nome do volume clone, também conhecido como caminho de junção, é armazenado na variável $JunctionPath. A transferência para uma tarefa LSC subsequente é conseguida através de uma variável LSC personalizada.

Como o script é executado no mestre LSC (que também é um sistema de satélite), o mestre LSC no servidor SnapCenter deve ser executado como um usuário do Windows que tenha permissões apropriadas para executar as operações de backup e clonagem no SnapCenter. Para verificar se ele tem as permissões apropriadas, o usuário deve poder executar uma cópia Snapshot e clonar na GUI do SnapCenter.

A figura a seguir destaca a configuração da tarefa NTAP_MNT_RECOVER_CP. Como queremos executar um script Linux Shell, este é um script de comando executado no sistema de banco de dados de destino.

Como o LSC deve estar ciente da montagem dos volumes de clone e se a restauração e recuperação do banco de dados de destino foi bem-sucedida, devemos definir pelo menos dois tipos de código de retorno. Um código é para uma execução bem-sucedida do script, e um é para uma execução falha do script, como é mostrado na figura a seguir.

A figura a seguir mostra parte do script Linux Shell usado para parar o banco de dados de destino, desmontar o volume antigo, montar o volume clone e restaurar e recuperar o banco de dados de destino. Na tarefa anterior, o caminho de junção foi escrito em uma variável LSC. O comando a seguir lê essa variável LSC e armazena o valor na $JunctionPath variável do script Linux Shell.

O trabalhador LSC no sistema de destino é executado como <sidaadm>, mas os comandos de montagem devem ser executados como o usuário raiz. É por isso que você deve criar o central_plugin_host_wrapper_script.sh. O script central_plugin_host_wrapper_script.sh é chamado a partir da tarefa NTAP_MNT_RECOVERY_CP usando o sudo comando. Usando o sudo comando, o script é executado com o UID 0 e podemos executar todas as etapas subsequentes, como desmontar os volumes antigos, montar os volumes clone e restaurar e recuperar o banco de dados de destino. Para ativar a execução de script usando sudo, a seguinte linha deve ser adicionada em /etc/sudoers: