Este guia fornece uma visão geral das opções, recomendações e conceitos gerais que você precisa conhecer antes de implantar um sistema SAP HANA de alta disponibilidade (HA, na sigla em inglês) no Google Cloud. Show
Presume-se que você já tenha uma compreensão dos conceitos e práticas geralmente necessários para implementar um sistema de alta disponibilidade do SAP HANA. Portanto, o guia se concentra principalmente no que você precisa saber para implementar esse sistema no Google Cloud. Para saber mais sobre os conceitos e práticas gerais necessários para implementar um sistema de alta disponibilidade do SAP HANA, consulte:
Este guia de planejamento é voltado exclusivamente à alta disponibilidade do SAP HANA e não de sistemas de banco de dados. Para informações sobre alta disponibilidade do SAP NetWeaver, consulte o Guia de planejamento de alta disponibilidade para SAP NetWeaver no Google Cloud. Este guia não substitui nenhuma documentação fornecida pela SAP. Opções de alta disponibilidade para SAP HANA no Google CloudÉ possível usar uma combinação de recursos do Google Cloud e do SAP no design de uma configuração de alta disponibilidade para SAP HANA que possa lidar com falhas nos níveis de infraestrutura ou de software. As tabelas a seguir descrevem os recursos do SAP e do Google Cloud usados para fornecer alta disponibilidade.
Clusters de alta disponibilidade nativos de SO para SAP HANA no Google CloudO cluster do sistema operacional Linux fornece reconhecimento de aplicativo e convidado para o estado do aplicativo e automatiza ações de recuperação em caso de falha. Os princípios de cluster de alta disponibilidade que se aplicam a ambientes que não são de nuvem geralmente se aplicam ao Google Cloud, mas existem diferenças na implementação de alguns elementos, como IPs de isolamento e virtuais. É possível usar as distribuições Linux de alta disponibilidade de Red Hat ou SUSE para seu cluster de alta disponibilidade para o SAP HANA no Google Cloud. Para instruções sobre como implantar e configurar manualmente um cluster de alta disponibilidade no Google Cloud para SAP HANA, consulte:
Para as opções de implantação automatizada fornecidas pelo Google Cloud, consulte Opções de implantação automatizada para configurações de alta disponibilidade do SAP HANA. Agentes de recursos de clusterO Red Hat e o SUSE fornecem aos agentes de recursos do Google Cloud as implementações de alta disponibilidade do software de cluster do Pacemaker. Os agentes de recursos do Google Cloud gerenciam isolamentos STONITH, VIPs que são implementados com rotas ou IPs de alias e ações de armazenamento. Para disponibilizar atualizações que ainda não estão incluídas nos agentes de recursos do SO de base, o Google Cloud fornece periodicamente agentes de recursos complementares para clusters de alta disponibilidade para SAP. Quando esses agentes de recursos complementares são necessários, os procedimentos de implantação do Google Cloud incluem uma etapa de download deles. Agentes de isolamentoO Isolamento, no contexto do clustering de SO do Google Cloud Compute Engine, assume a forma de STONITH, que fornece a cada membro em um cluster de dois nós a capacidade de reiniciar o outro nó. O Google Cloud fornece dois agentes de isolamento para uso com sistemas operacionais SAP no Linux: o agente fence_gce, incluído nas distribuições Red Hat e SUSE Linux mais recentes, e o agente gcpstonith legado, disponível para download para uso com distribuições Linux que não incluem o agente fence_gce. Permissões do IAM necessárias para agentes de isolamentoOs agentes de isolamento reiniciam as VMs fazendo uma chamada de redefinição para a API Compute Engine. Para autenticação e autorização para acessar a API, os agentes de isolamento usam a conta de serviço da VM. A conta de serviço que um agente de isolamento usa precisa receber um papel que inclua as seguintes permissões:
O papel predefinido de Administrador da instância do Compute contém todas as permissões necessárias. Para limitar o escopo da permissão de reinicialização do agente ao nó de destino, configure o acesso baseado em recursos. Para mais informações, consulte Como configurar o acesso baseado em recursos. Endereço IP virtualOs clusters de alta disponibilidade para SAP no Google Cloud usam um endereço IP virtual ou flutuante (VIP) para redirecionar o tráfego de rede de um host para outro no caso de um failover. Implantações comuns fora da nuvem usam uma solicitação gratuita do protocolo de resolução de endereços (ARP, na sigla em inglês) para anunciar o movimento e a realocação de um VIP para um novo endereço MAC. No Google Cloud, em vez de usar solicitações ARP gratuitas, use um dos variados métodos para mover e realocar um VIP em um cluster de alta disponibilidade. Recomenda-se usar um balanceador de carga TCP/UDP interno, mas, dependendo das suas necessidades, também é possível usar uma implementação de VIP baseada em rota ou uma implementação de VIP baseada em IP de alias. Para mais informações sobre a implementação de VIP no Google Cloud, consulte Implementação de IP virtual no Google Cloud. Armazenamento e replicaçãoUma configuração de cluster de alta disponibilidade do SAP HANA usa a replicação síncrona do sistema SAP HANA para manter os bancos de dados primário e secundário do SAP HANA sincronizados. Os agentes de recursos padrão fornecidos pelo SO para SAP HANA gerenciam a replicação do sistema durante um failover, iniciando e interrompendo a replicação e alternando quais instâncias estão sendo veiculadas como instâncias ativas e em espera no processo de replicação. Para armazenamento de arquivos compartilhado, os arquivadores baseados em NFS ou SMB poderão fornecer a funcionalidade necessária. Para uma solução de armazenamento compartilhado de alta disponibilidade, use o Filestore ou uma solução de compartilhamento de arquivos de terceiros, como NetApp Cloud Volumes Service para Google Cloud. O nível empresarial do Filestore pode ser usado para implantações em várias zonas, e o nível Básico do Filestore pode ser usado para implantações em zona única. Os discos permanentes regionais do Compute Engine oferecem armazenamento em blocos replicado de forma síncrona nas zonas. Os discos permanentes regionais não são compatíveis com o armazenamento do banco de dados em sistemas de alta disponibilidade do SAP, mas é possível usá-los com servidores de arquivos NFS. Para mais informações sobre as opções de armazenamento no Google Cloud, consulte:
Configurações de clusters de alta disponibilidade no Google CloudO Google Cloud recomenda alterar os valores padrão de determinados parâmetros de configuração de cluster para valores mais adequados a sistemas SAP no ambiente do Google Cloud. Se usar os modelos do Deployment Manager fornecidos pelo Google Cloud, os valores recomendados serão definidos para você. Considere os valores recomendados como um ponto de partida para ajustar as configurações do Corosync no seu cluster de HA. Confirme se a sensibilidade da detecção de falhas e do acionamento de failover é apropriada para seus sistemas e cargas de trabalho no ambiente do Google Cloud. Valores do parâmetro de configuração do CorosyncNos guias de configuração do cluster de alta disponibilidade para SAP HANA, o Google Cloud recomenda valores para vários parâmetros na seção totem do arquivo de configuração corosync.conf que são diferentes dos valores padrão definidos pelo Corosync ou pelo distribuidor distributor. A tabela a seguir mostra os parâmetros totem para os quais o Google Cloud recomenda valores diferentes, além dos valores recomendados e do impacto da alteração do valor. Para os valores padrão dos parâmetros, que podem diferir entre distribuições do Linux, consulte a documentação da distribuição do Linux.
Para mais informações sobre como configurar o arquivo corosync.conf, consulte o guia de configuração para sua distribuição do Linux:
Configurações de tempo limite e intervalo para recursos de clusterAo definir um recurso de cluster, você define valores interval e timeout (em segundos) para várias operações de recurso (op). Por exemplo: primitive rsc_SAPHanaTopology_HA1_HDB00 ocf:suse:SAPHanaTopology \ operations \$id="rsc_sap2_HA1_HDB00-operations" \ op monitor interval="10" timeout="600" \ op start interval="0" timeout="600" \ op stop interval="0" timeout="300" \ params SID="HA1" InstanceNumber="00" clone cln_SAPHanaTopology_HA1_HDB00 rsc_SAPHanaTopology_HA1_HDB00 \ meta is-managed="true" clone-node-max="1" target-role="Started" interleave="true"Os valores de timeout afetam cada uma das operações de recursos de maneira diferente, conforme explicado na tabela a seguir.
Além de outras configurações de cluster, as definições de interval e timeout dos recursos do cluster afetam a rapidez com que o software do cluster detecta uma falha e aciona um failover. Os valores timeout e interval sugeridos pelo Google Cloud nos guias de configuração de cluster para SAP HANA consideram os eventos de manutenção de migração em tempo real do Compute Engine. Independentemente dos valores timeout e interval usados, você precisa avaliá-los ao testar o cluster, especialmente durante os testes de migração em tempo real, porque a duração desses eventos pode variar um pouco, dependendo do tipo de máquina que você está usando e de outros fatores, como a utilização do sistema. Como testar seu cluster de alta disponibilidade no Google CloudDepois que o cluster for configurado e os sistemas do cluster e do SAP HANA forem implantados no ambiente de teste, será preciso testar o cluster para confirmar se o sistema de HA está configurado corretamente e funcionando conforme o esperado. Para confirmar que o failover está funcionando como esperado, simule vários cenários de falha com as ações a seguir:
Além disso, simule um evento de migração em tempo real do Compute Engine no host primário para confirmar que ele não aciona um failover. É possível simular um evento de manutenção usando o comando gcloud compute instances simulate-maintenance-event da Google Cloud CLI. Geração de registros e monitoramentoOs agentes de recursos podem incluir recursos de geração de registros que propagam registros para o pacote de operações do Google Cloud para análise. Cada agente de recurso inclui informações de configuração que identificam as opções de geração de registros. No caso de implementações bash, a opção de geração de registros é gcloud logging. Também é possível instalar o agente do Cloud Logging para capturar a saída do registro de processos do sistema operacional e correlacionar a utilização de recursos com eventos do sistema. O agente do Logging captura registros do sistema padrão, que incluem dados de registro do Pacemaker e dos serviços de clustering. Para mais informações, consulte Sobre o agente do Logging. Para informações sobre como usar o Cloud Monitoring para configurar verificações de serviço que monitoram a disponibilidade de endpoints de serviço, consulte Como gerenciar verificações de tempo de atividade. Contas de serviço e clusters de alta disponibilidadeAs ações que o software de cluster pode realizar no ambiente do Google Cloud são protegidas pelas permissões concedidas à conta de serviço de cada VM de host. Para ambientes de alta segurança, é possível limitar as permissões nas contas de serviço das VMs de host para obedecer ao princípio do menor privilégio. Ao limitar as permissões da conta de serviço, lembre-se de que o sistema pode interagir com os serviços do Google Cloud, como o Cloud Storage. Portanto, talvez seja necessário incluir permissões para essas interações de serviço na conta de serviço da VM do host. Para as permissões mais restritivas, crie um papel personalizado com as permissões mínimas necessárias. Para informações sobre papéis personalizados, consulte Como criar e gerenciar papéis personalizados. É possível restringir ainda mais as permissões limitando-as a instâncias específicas de um recurso, como as instâncias de VM no cluster de alta disponibilidade, adicionando condições nas vinculações de papel da política de IAM de um recurso. As permissões mínimas necessárias dependem dos recursos do Google Cloud que os sistemas acessam e das ações que eles executam. Consequentemente, determinar as permissões mínimas necessárias para as VMs do host no cluster de alta disponibilidade pode exigir que você investigue exatamente quais recursos os sistemas acessam na VM do host e as ações que esses sistemas executam com tais recursos. Como ponto de partida, a lista a seguir mostra alguns recursos do cluster de alta disponibilidade e as permissões associadas exigidas:
Implementação de IP virtual no Google CloudUm cluster de alta disponibilidade usa um endereço IP flutuante ou virtual (VIP, na sigla em inglês) para mover a carga de trabalho de um nó do cluster para outro no caso de falha inesperada ou para manutenção programada. O endereço IP do VIP não muda. Portanto, os aplicativos cliente não sabem que o trabalho está sendo atendido por um nó diferente. Um VIP também é chamado de endereço IP flutuante. No Google Cloud, os VIPs são implementados de modo um pouco diferente do que nas instalações no local, porque, quando ocorre um failover, não é possível usar solicitações ARP gratuitas para anunciar a alteração. Em vez disso, é possível implementar um endereço VIP para um cluster de alta disponibilidade do SAP usando um dos seguintes métodos:
Implementações de VIP do balanceamento de carga TCP/UDP internoUm balanceador de carga normalmente distribui o tráfego do usuário em várias instâncias dos aplicativos, tanto para distribuir a carga de trabalho em vários sistemas ativos quanto para proteger contra uma lentidão ou falha de processamento em qualquer instância. O serviço de balanceamento de carga TCP/UDP interno também oferece suporte de failover que pode ser usado com as verificações de integridade do Compute Engine para detectar falhas, acionar o failover e redirecionar o tráfego para um novo sistema SAP principal em um cluster de alta disponibilidade nativo do SO. Há diversos motivos para a implementação de VIP recomendada ser o suporte de failover do balanceamento de carga TCP/UDP interno, incluindo:
Ao criar uma verificação de integridade para uma implementação de balanceador de carga de um VIP, especifique a porta do host sondada pela verificação de integridade para determinar a integridade do host. Para um cluster de alta disponibilidade do SAP, especifique uma porta de host de destino que esteja no intervalo particular 49152-65535, evitando, assim, conflitos com outros serviços. Na VM do host, configure a porta de destino com um serviço auxiliar secundário, como o utilitário socat ou o HAProxy. Para clusters de banco de dados em que o sistema secundário em espera permanece on-line, o serviço auxiliar de verificação de integridade permite que o balanceamento de carga direcione o tráfego para o sistema on-line que está atuando como o sistema principal no cluster. Com o uso do serviço auxiliar e do redirecionamento de porta, é possível acionar um failover de manutenção planejada de software nos sistemas SAP. Para mais informações sobre o suporte a failover do balanceamento de carga TCP/UDP interno, consulte Como configurar o failover para balanceamento de carga TCP/UDP interno. Para implantar um cluster de alta disponibilidade com uma implementação de VIP do balanceador de carga, consulte:
Implementações de VIP de rota estáticaA implementação de rota estática também fornece proteção contra falhas de zona, mas exige o uso de um VIP fora dos intervalos de IP das sub-redes VPC existentes em que as VMs residem. Consequentemente, também é necessário garantir que o VIP não entre em conflito com nenhum endereço IP externo na sua rede expandida. As implementações de rota estática também podem gerar complexidade quando usadas com configurações de VPC compartilhada, que se destinam a separar a configuração de rede em um projeto host. Para usar uma implementação de rota estática para seu VIP, consulte o administrador da rede para determinar um endereço IP adequado para uma implementação de rota estática. Implementações de VIP do IP de aliasAs implementações de VIP do IP de alias não são recomendadas para implantações de alta disponibilidade em várias zonas porque, em caso de falha da zona, pode haver atraso na realocação do IP de alias para um nó em uma zona diferente. Implemente seu VIP com um balanceamento de carga TCP/UDP interno compatível com failover. Se você estiver implantando todos os nós do cluster de alta disponibilidade do SAP na mesma zona, use um IP de alias para implementar um VIP no cluster de alta disponibilidade. Para clusters de alta disponibilidade do SAP de várias zonas que usam uma implementação de IP de alias para o VIP, é possível migrar para uma implementação de balanceamento de carga TCP/UDP interno sem precisar alterar seu endereço VIP. O IP de alias e o balanceamento de carga TCP/UDP interno usam intervalos de IP da rede VPC. Embora os endereços IP de alias não sejam recomendados para implementações de VIP em clusters de alta disponibilidade em várias zonas, eles têm outros casos de uso em implantações do SAP. Por exemplo, eles podem ser usados para fornecer um nome de host e atribuições de IP lógicos para implantações flexíveis do SAP, como as gerenciadas pelo SAP Landscape Management. Práticas recomendadas gerais para VIPs no Google CloudPara mais informações sobre VIPs no Google Cloud, consulte Práticas recomendadas para endereços IP flutuantes. Failover automático do host do SAP HANA no Google CloudO Google Cloud é compatível com o failover automático de host do SAP HANA, a solução local de recuperação de falhas fornecida pelo SAP HANA. A solução de failover automático do host usa um ou mais hosts em espera que são mantidos em reserva para assumir o trabalho do host mestre ou worker em caso de falha no host. Os hosts em espera não têm dados nem processam trabalhos. Após concluir um failover, o host com falha é reiniciado como um host em espera. O SAP é compatível com até três hosts em espera em sistemas de escalonamento horizontal no Google Cloud. Os hosts em espera não contam para o máximo de 16 hosts ativos que o SAP suporta em sistemas de escalonamento horizontal no Google Cloud. Para mais informações da SAP sobre a solução de failover automático de hosts, consulte Failover automático de hosts. Quando usar o failover automático de host do SAP HANA no Google CloudO failover automático de host do SAP HANA protege contra falhas que afetam um único nó em um sistema de escalonamento horizontal do SAP HANA, incluindo falhas dos seguintes itens:
Em relação a falhas da VM do host, no Google Cloud, a reinicialização automática, que normalmente restaura a VM do host do SAP HANA mais rápido que o failover automático do host, e a migração em tempo real, protegem contra interrupções em VMs planejadas e não planejadas. Então, para proteção da VM, a solução de failover automático de host do SAP HANA não é necessária. O failover automático de host do SAP HANA não protege contra falhas zonais, porque todos os nós de um sistema de escalonamento horizontal do SAP HANA são implantados em uma única zona. O failover automático de host do SAP HANA não pré-carrega dados do SAP HANA na memória dos nós de espera. Então, quando um nó de espera assume o controle, o tempo total de recuperação do nó é determinado principalmente pelo tempo que leva para carregar os dados na memória do nó de espera. Use o failover automático de host do SAP HANA nos cenários a seguir:
O gerenciador de armazenamento do SAP HANAOs volumes /hana/data e /hana/log são ativados apenas nos hosts mestre e de trabalho. Quando ocorre a tomada de controle, a solução de failover automático do host usa a API do conector de armazenamento do SAP HANA e o gerenciador de armazenamento do Google Cloud para que os nós de espera do SAP HAPA movam as montagens de volume do host com falha para o host em espera. No Google Cloud, o gerenciador de armazenamento do SAP HANA é necessário para sistemas SAP HANA que usam o failover automático de host do SAP HANA. Versões com suporte do gerenciador de armazenamento para SAP HANAAs versões 2.0 e posteriores do gerenciador de armazenamento do SAP HANA recebem suporte. Todas as versões anteriores à 2.0 foram descontinuadas e não recebem mais suporte. Se você estiver usando uma versão anterior, atualize o sistema HANA da SAP para usar a versão mais recente do gerenciador de armazenamento do SAP HANA. Consulte Como atualizar o gerenciador de armazenamento do SAP HANA. Para determinar se a sua versão foi suspensa, abra o arquivo gceStorageClient.py. O diretório de instalação padrão é: /hana/shared/gceStorageClient A partir da versão 2.0, o número da versão é listado nos comentários na parte superior do arquivo gceStorageClient.py, conforme mostrado no exemplo a seguir. Se o número da versão estiver ausente, você está vendo uma versão descontinuada do gerenciador de armazenamento para SAP HANA. """Google Cloud Storage Manager for SAP HANA Standby Nodes. The Storage Manager for SAP HANA implements the API from the SAP provided StorageConnectorClient to allow attaching and detaching of disks when running in GCE. Build Date: Wed Jan 27 06:39:49 PST 2021 Version: 2.0.20210127.00-00 """Como instalar o gerenciador de armazenamento para SAP HANAO método recomendado para instalar o gerenciador de armazenamento do SAP HANA é usar o modelo do Deployment Manager fornecido pelo Google Cloud para implantar um sistema de escalonamento horizontal do SAP HANA que inclui o gerenciador de armazenamento mais recente do SAP HANA. Se você precisar adicionar o failover automático de host do SAP HANA a um sistema de escalonamento horizontal do SAP HANA no Google Cloud, a abordagem recomendada é semelhante: use o modelo do Deployment Manager fornecido pelo Google Cloud para implantar um novo sistema de escalonamento horizontal do SAP HANA e, em seguida, carregue os dados no novo sistema a partir do sistema atual. Para carregar os dados, use procedimentos padrão de backup e restauração do SAP HANA ou a replicação do sistema SAP HANA, o que pode limitar a inatividade. Para mais informações sobre a replicação do sistema, consulte a Nota SAP 2473002 - Como usar a replicação do sistema HANA para migrar o sistema de escalonamento horizontal. Se não for possível usar o modelo do Deployment Manager, entre em contato com um consultor de soluções da SAP ou com os serviços de consultoria do Google Cloud, para receber ajuda na instalação manual do gerenciador de armazenamento. para SAP HANA. No momento, a instalação manual do gerenciador de armazenamento do SAP HANA em um sistema de escalonamento horizontal SAP HANA novo ou atual não está documentada. Para mais informações sobre o modelo do Deployment Manager para failover automático de host do SAP HANA, consulte Implantação automatizada de sistemas de escalonamento horizontal do SAP HANA com failover automático de host do SAP HANA. Como atualizar o gerenciador de armazenamento do SAP HANAPara atualizar o gerenciador de armazenamento para SAP HANA, primeiro faça o download do pacote de instalação e execute um script de instalação, que atualiza o gerenciador de armazenamento para o executável do SAP HANA na unidade /shared do SAP HANA. O procedimento a seguir é apenas para a versão 2 do gerenciador de armazenamento do SAP HANA. Se você estiver usando uma versão do gerenciador de armazenamento para SAP HANA que foi baixada antes de 1 de fevereiro de 2021, instale a versão 2 antes de tentar atualizar o gerenciador de armazenamento para o SAP HANA. Para atualizar o gerenciador de armazenamento do SAP HANA:
Parâmetros de configuração no arquivo global.iniAlguns parâmetros de configuração do gerenciador de armazenamento do SAP HANA, incluindo se o isolamento está ativado ou desativado, são armazenados na seção de armazenamento do arquivo global.ini do SAP HANA. Ao usar o modelo do Deployment Manager fornecido pelo Google Cloud para implantar um sistema SAP HANA com a função de failover automático do host, os scripts de implantação adicionam os parâmetros de configuração ao global.ini para você. O exemplo a seguir mostra o conteúdo de um global.ini criado para o gerenciador de armazenamento do SAP HANA: [persistence] basepath_datavolumes = %BASEPATH_DATAVOLUMES% basepath_logvolumes = %BASEPATH_LOGVOLUMES% use_mountpoints = %USE_MOUNTPOINTS% basepath_shared = %BASEPATH_SHARED% [storage] ha_provider = gceStorageClient ha_provider_path = %STORAGE_CONNECTOR_PATH% # # Example configuration for 2+1 setup # # partition_1_*__pd = node-mnt00001 # partition_2_*__pd = node-mnt00002 # partition_3_*__pd = node-mnt00003 # partition_*_data__dev = /dev/hana/data # partition_*_log__dev = /dev/hana/log # partition_*_data__mountOptions = -t xfs -o logbsize=256k # partition_*_log__mountOptions = -t xfs -o logbsize=256k # partition_*_*__fencing = disabled [trace] ha_gcestorageclient = infoAcesso sudo para o gerenciador de armazenamento do SAP HANAPara gerenciar os serviços e o armazenamento do SAP HANA, o gerenciador de armazenamento do SAP HANA usa a conta de usuário sidadm e exige acesso sudo para determinados binários do sistema. Se você usar os scripts de automação fornecidos pelo Google Cloud para implantar o SAP HANA com failover automático do host, o acesso sudo necessário vai ser configurado para você. Se você instalar manualmente o gerenciador de armazenamento do SAP HANA, use o comando visudo para editar o arquivo /etc/sudoers e conceder para a conta de usuário sidadm acesso sudo aos seguintes binários necessários. Clique na guia do seu sistema operacional:
O exemplo a seguir mostra uma entrada no arquivo /etc/sudoers. No exemplo, o ID do sistema do sistema SAP HANA associado é substituído por sid. A entrada de exemplo foi criada pelo modelo do Deployment Manager fornecido pelo Google Cloud para escalonamento horizontal do SAP HANA com failover automático do host. A entrada criada pelo modelo do Deployment Manager inclui binários que não são mais necessários, mas que são retidos para compatibilidade com versões anteriores. Você deve incluir apenas os binários que estão na lista anterior. sidadm ALL=NOPASSWD: /sbin/multipath,/sbin/multipathd,/etc/init.d/multipathd,/usr/bin/sg_persist,/bin/mount,/bin/umount,/bin/kill,/usr/bin/lsof,/usr/bin/systemctl,/usr/sbin/lsof,/usr/sbin/xfs_repair,/sbin/xfs_repair,/usr/bin/mkdir,/sbin/vgscan,/sbin/pvscan,/sbin/lvscan,/sbin/vgchange,/sbin/lvdisplay,/usr/bin/gcloud,/sbin/dmsetupArmazenamento NFS para failover automático de host do SAP HANAUm sistema de escalonamento horizontal do SAP HANA com failover automático de host requer uma solução NFS, como o Filestore, para compartilhar os volumes /hana/shared e /hanabackup entre todos os hosts. Você mesmo precisa configurar a solução de NFS. Ao usar o Deployment Manager, você fornece informações sobre o servidor NFS no arquivo de configuração template.yaml para que ele possa montar os diretórios NFS durante a implantação. O volume NFS usado precisa estar vazio. Qualquer arquivo existente pode entrar em conflito com os scripts do Deployment Manager, especialmente se os arquivos ou pastas fizerem referência ao código do sistema SAP (SID). Os scripts de implantação não podem determinar se os arquivos podem ser substituídos. O Deployment Manager armazena os volumes /hana/shared e /hanabackup no servidor NFS e monta o servidor NFS em todos os hosts, incluindo os hosts em espera. O host mestre gerencia o servidor NFS. Se você estiver implementando uma solução de backup, como o agente do Backint do Cloud Storage para SAP HANA, será possível remover o volume /hanabackup do servidor NFS depois que o Deployment Manager concluir a implantação. Para mais informações sobre as soluções de arquivos compartilhados disponíveis no Google Cloud, consulte Soluções de compartilhamento de arquivos para o SAP no Google Cloud. Suporte ao sistema operacionalAtualmente, o Google Cloud é compatível com o failover automático de host do SAP HANA apenas nos seguintes sistemas operacionais:
Para ver as imagens públicas disponíveis pelo Compute Engine, consulte Imagens. Arquitetura de um sistema SAP HANA com failover automático de hostO diagrama a seguir mostra uma arquitetura de escalonamento horizontal no Google Cloud que inclui o recurso de failover automático de host do SAP HANA. No diagrama, o gerenciador de armazenamento do SAP HANA é representado pelo nome do executável dele, gceStorageClient. O diagrama mostra o nó de trabalho 2 falhando e o nó em espera assumindo o controle. O gerenciador de armazenamento do SAP HANA funciona com a API SAP Storage Connector (não exibida) para remover os discos que contêm os volumes /hana/data e /hana/logs do nó de trabalho com falha e para montá-los novamente no nó de espera, que se torna o nó de trabalho 2 enquanto o nó com falha se torna o nó de espera.  Opções de implantação automatizadas para configurações de alta disponibilidade do SAP HANAO Google Cloud fornece modelos do Deployment Manager que podem ser usados para automatizar a implantação de sistemas de alta disponibilidade do SAP HANA. Caso prefira, é possível implantar e configurar seus sistemas de alta disponibilidade do SAP HANA manualmente. Os modelos do Deployment Manager fornecidos pelo Google Cloud incluem um arquivo de configuração template.yaml concluído. O Deployment Manager lê o arquivo de configuração e implanta um sistema SAP HANA para você que tenha suporte total do SAP e que adere às práticas recomendadas do SAP e do Google Cloud. Implantação automatizada de clusters de alta disponibilidade do Linux para SAP HANAPara o SAP HANA, o Deployment Manager implanta um cluster Linux de alta disponibilidade e desempenho otimizado que inclui:
Para instruções de implantação automatizadas, consulte Implantação automatizada de alta disponibilidade do SAP HANA com implementação VIP do balanceador de carga. Implantação automatizada de sistemas de escalonamento horizontal do SAP HANA com failover automático de host do SAP HANAPara um sistema de escalonamento horizontal do SAP HANA com recurso de failover automático de host do SAP HANA, o Deployment Manager implanta:
Um sistema de escalonamento horizontal do SAP HANA com failover automático de host requer uma solução NFS, como o Filestore, para compartilhar os volumes /hana/shared e /hanabackup entre todos os hosts. Para que o Deployment Manager possa montar os diretórios NFS durante a implantação, configure a solução NFS antes de implantar o sistema SAP HANA. É possível configurar as instâncias do servidor NFS do Filestore de maneira rápida e fácil, seguindo as instruções em Como criar instâncias. Para implantar um sistema de escalonamento horizontal com hosts em espera, consulte o Guia de implantação do sistema de escalonamento horizontal do SAP HANA com failover automático de host do SAP HANA. A seguirO Google Cloud e o SAP fornecem mais informações sobre alta disponibilidade. Mais informações do Google Cloud sobre alta disponibilidadePara mais informações sobre a alta disponibilidade do SAP HANA no Google Cloud, consulte o Guia de operações do SAP HANA. Para informações gerais sobre como proteger sistemas no Google Cloud contra vários cenários de falha, consulte Como projetar sistemas robustos. Mais informações da SAP sobre os recursos de alta disponibilidade do SAP HANAPara mais informações do SAP sobre os recursos de alta disponibilidade do SAP HANA, consulte os documentos a seguir:
Que tecnologia implementaria para fornecer alta disponibilidade para armazenamento de dados?Tecnologias como GIS e OIE contribuem para o crescimento de grandes armazenamentos de dados. Quais são os dois motivos pelos quais essas tecnologias aumentam a necessidade de especialistas em segurança cibernética? (Escolher dois.) Eles contêm informações pessoais. Elas coletam informações confidenciais.
Qual tecnologia pode ser usada para garantir o sigilo dos dados?R: Instalações físicas 78- Qual tecnologia pode ser usada para garantir o sigilo dos dados? R: Criptografia 79- Os funcionários de uma empresa recebem um e-mail informando que a senha da conta irá expirar imediatamente, e que é necessário redefinir uma senha dentro de 50 minutos.
Quais das opções são dois métodos que garantem à confidencialidade?Quais das opções são dois métodos que garantem a confidencialidade? (Escolher dois.) autenticação criptografia Refer to curriculum topic: 2.2.1 Confidencialidade significa que as informações serão visualizadas apenas por aqueles que precisam saber delas.
Quais são os três dispositivos que representam exemplos de controle de acesso físico?É composto, basicamente, por uma barreira perimetral (muro, cerca, alambrado ou combinação desses), um ou mais pontos de acessos (portarias), controlados por dispositivos mecânicos (ex.: portões e cancelas) ou eletrônicos (ex.: catracas e fechaduras eletrônicas) e por políticas e procedimentos de segurança física.
|
Qual tecnologia você implementaria para fornecer alta disponibilidade para o armazenamento de dados?
Postagens relacionadas
direito autoral © 2024 paraquee Inc.
