Início / dba / Perguntas / 134398
Accepted
kudlatiger
Asked: 2016-04-06 04:57:18 +0800 CST

Posso acessar a pasta compartilhada do fluxo de arquivos usando Ouvintes no caso do ambiente de cluster AlwaysOn?

  • 772

Uma das maneiras mais eficazes de estender o fluxo de controle do SQL Server Integration Services ( SSIS ) é usar uma tarefa Script para escrever um código personalizado que execute tarefas que você não pode executar com os componentes integrados. Mas não é direto no caso do AlwaysOn nós configurados

Abaixo está a configuração do meu ambiente atual, que ajuda você a entender o problema.

meu ambiente

  • Estou tendo o NÓ 1 e o NÓ 2 como cluster configurado
  • SQL Server sempre ativado e grupo de disponibilidade configurado
  • O fluxo de arquivos do SQL Server está habilitado no nó 1 e no nó 2 com direito a MYSHAREDNAME
  • Ouvinte de balanceamento de carga interno configurado e autorizado como MYACTIVENODE

Declaração do problema Um dos nós entre os clusters (nó 1 ou nó2) pode ficar inativo a qualquer momento. Não teremos certeza de qual deles se tornará PRIMÁRIO. Estou tentando acessar a pasta compartilhada da seguinte forma

\NODE1\MYSHAREDNAME - Funciona se o NÓ 1 for o nó primário \NODE2\MYSHAREDNAME - Funciona se o NÓ 2 for o nó primário

Mas é difícil codificar o caminho acima, pois qualquer nó pode cair. Então, usei o nome LISTENER para que ele detecte automaticamente o nó PRIMARY para fazer o trabalho desejado, conforme mostrado abaixo

Então, usei o nome LISTENER para que ele detecte automaticamente o nó PRIMARY para fazer o trabalho desejado, conforme mostrado abaixo

  \\MYLISTENERNAME\MYSHAREDNAME

Mas não estou conseguindo acessar

Como posso corrigir isso? As portas 1433, 5022, 59999 estão habilitadas.

Extrair de https://msdn.microsoft.com/en-in/library/dn385720.aspx

Grupos de disponibilidade AlwaysOn são suportados desde que você não adicione novos arquivos de banco de dados ao banco de dados primário. Se uma operação de banco de dados exigir a criação de um novo arquivo no banco de dados primário, primeiro desabilite os grupos de disponibilidade AlwaysOn no nó secundário. Em seguida, execute a operação de banco de dados no banco de dados primário e faça backup do banco de dados no nó primário. Em seguida, restaure o banco de dados para o nó secundário e habilite Grupos de Disponibilidade AlwaysOn no nó secundário. Observe que instâncias de cluster de failover AlwaysOn não são suportadas ao usar o recurso SQL Server Data Files no Windows Azure

Mas eu não entendi o que significa a afirmação acima?

sql-server sql-server-2012

2 respostas

  1. Não acredito que sua citação extraída seja relevante para o seu problema.

    Seu problema pode ser que seu ouvinte tenha vários endereços IP. Na configuração padrão, o ouvinte terá vários registros A no DNS e seu cliente armazenará em cache apenas um deles. Cada vez que o cache expira, ele pega aleatoriamente um dos endereços IP e às vezes pega o IP ativo e outras vezes pega o que está offline.

    Este é o propósito por trás do parâmetro MultiSubnetFailover que o ouvinte reconhece.

    • 2
  2. Best Answer

    Após longa luta e captura de rastreamento de rede, tenho os seguintes pontos de dados

    • Você pode acessar a pasta compartilhada do fluxo de arquivos usando o nome da máquina local.
    • Você pode acessar a pasta compartilhada do fluxo de arquivos usando o nome do ouvinte da máquina local que faz parte do cluster.
    • Você não pode acessar a pasta compartilhada de qualquer máquina que não faça parte do cluster .
    • Você pode acessar o servidor SQL usando o nome do ouvinte, mas não pode acessar a pasta no explorador de arquivos de qualquer dispositivo que não faça parte do cluster

    Atualizar

    Podemos acessar o compartilhamento de arquivos de outra VM que faz parte de outro serviço de nuvem

    Para que isso funcione, precisamos estabelecer o ponto final na porta 445 (SMB 2.0)

    Script de shell de energia

    Primeiro obtenha o nome do ouvinte interno

        Get-AzureInternalLoadBalancer -servicename $servicename

    Em seguida, use o nome do ouvinte interno no script abaixo

           $ServiceName = "ABCCS" # the name of the cloud service that contains the availability group nodes
       $AGNodes = "VM01","VM02" 
       $ILBName = "ListenerLB" //get using Get-AzureInternalLoadBalancer
       ForEach ($node in $AGNodes)
       {
         Get-AzureVM -ServiceName $ServiceName -Name $node | Add-AzureEndpoint -Name "ListenerEndpointFSL" -LBSetName "ListenerEndpointLBFSL" -Protocol tcp -LocalPort 445 -PublicPort 445 -ProbePort 59999 -ProbeProtocol tcp -ProbeIntervalInSeconds 10 -InternalLoadBalancerName $ILBName -DirectServerReturn $true | Update-AzureVM
     }
    • 0

relate perguntas