Exemplo de implementação
Sugerir alterações
PDFs
Devido ao grande número de opções disponíveis para configurações de sistema e armazenamento, o exemplo de implementação deve ser usado como um modelo de configuração do seu sistema individual e requisitos de configuração.
|
Os scripts de exemplo são fornecidos como estão e não são suportados pelo NetApp. Você pode solicitar a versão atual dos scripts via e-mail para mailto:ng-sapcc em NetApp.com[ng-sapcc em NetApp.com]. |
Configurações e limitações validadas
Os seguintes princípios foram aplicados à implementação do exemplo e podem precisar ser adaptados para atender às necessidades dos clientes:
-
Os sistemas SAP gerenciados usaram o NFS para acessar volumes de storage do NetApp e foram configurados com base no princípio do design adaptável.
-
Use todas as versões do ONTAP compatíveis com os módulos do NetApp Ansible (ZAPI e API REST).
-
As credenciais para um único cluster NetApp e SVM foram codificadas como variáveis no script do provedor.
-
A clonagem de storage foi realizada no mesmo sistema de storage usado pelo sistema SAP de origem.
-
Os volumes de storage para o sistema SAP de destino tinham os mesmos nomes que a origem com um apêndice.
-
Não foi implementada clonagem no armazenamento secundário (SV/SM).
-
A divisão FlexClone não foi implementada.
-
Os números das instâncias eram idênticos para os sistemas SAP de origem e destino.
Configuração do laboratório
A figura a seguir mostra a configuração do laboratório que usamos. O sistema SAP de origem HN9 usado para a operação de clone do sistema consistiu no banco de dados H09, no SAP CS e no SAP AS serviços executados no mesmo host (sap-lnx32) com instalado "design adaptável" habilitado. De acordo com a documentação, foi elaborado um nó de controle do Ansible "Playbooks do Ansible para NetApp ONTAP".
O agente host SAP também foi instalado nesse host. O script do fornecedor do NetApp e os playbooks do Ansible foram configurados no nó de controle do Ansible, conforme descrito na ""Apêndice: Configuração de script do provedor.""
O host sap-lnx49 foi usado como destino para as operações de clonagem do SAP lama, e o recurso pronto para isolamento foi configurado lá.
Diferentes sistemas SAP (HNA como origem e HN2 como destino) foram usados para operações de cópia e atualização do sistema, porque a automação pós-cópia (PCA) estava ativada lá.
As seguintes versões de software foram usadas na configuração do laboratório:
-
SAP lama Enterprise Edition 3,00 SP23_2
-
SAP HANA 2.00.052.00.1599235305
-
PATCH 27 DO SAP 7,77 (S/4 HANA 1909)
-
Patch 56 do SAP Host Agent 7,22
-
SAPACEXT 7,22 Patch 69
-
Linux SLES 15 SP2
-
Ansible 2. 13,7
-
NetApp ONTAP 9.8P8
Configuração do SAP lama
Definição do provedor SAP lama
A definição do provedor é executada no Automation Studio do SAP lama, conforme mostrado na captura de tela a seguir. A implementação de exemplo usa uma única definição de provedor que é usada para diferentes etapas de provisionamento personalizado e ganchos de operação, conforme explicado anteriormente.
O provedor netapp_clone é definido como o netapp_clone.sh script registrado no agente host SAP. O agente de host SAP é executado no host central sap-jump , que também atua como nó de controle do Ansible.
A guia usado em mostra para quais operações personalizadas o provedor é usado. A configuração para o provisionamento personalizado NetAppClone e os ganchos personalizados Delete NetAppClone e Delete NetAppClone Refresh são mostrados nos próximos capítulos.
Os parâmetros ClonePostFix e SnapPostFix são solicitados durante a execução do fluxo de trabalho de provisionamento e são usados para os nomes de volume Snapshot e FlexClone.
Provisionamento personalizado do SAP lama
Na configuração de provisionamento personalizado do SAP lama, o provedor de cliente descrito anteriormente é usado para substituir as etapas de fluxo de trabalho de provisionamento Clone volumes e PostCloneVolumes.
Gancho personalizado do SAP lama
Se um sistema for excluído com o fluxo de trabalho de destruição do sistema, o gancho Excluir NetAppClone será usado para chamar a definição do provedor netapp_clone . O gancho Delete NetApp Clone Refresh é usado durante o fluxo de trabalho de atualização do sistema porque a instância é preservada durante a execução.
É importante configurar Use o Mount Data XML para o gancho personalizado, para que o SAP lama forneça as informações da configuração do ponto de montagem ao provedor.
Para garantir que o gancho personalizado seja usado e executado somente quando o sistema foi criado com um fluxo de trabalho de provisionamento personalizado, a seguinte restrição é adicionada a ele.
Mais informações sobre o uso de ganchos personalizados podem ser encontradas no "Documentação do SAP lama".
Ative o fluxo de trabalho de provisionamento personalizado para o sistema de origem SAP
Para ativar o fluxo de trabalho de provisionamento personalizado para o sistema de origem, ele deve ser adaptado na configuração. A caixa de verificação Use Custom Provisioning Process com a definição de provisionamento personalizado correspondente deve estar selecionada.
