none
Acesso a pasta ClusterStorage RRS feed

  • Pergunta

  • Pessoal, boa tarde.

    Acabei de configurar um cluster em 4 servidores. O ambiente está em funcionamento, mas quando tento acessar a pasta clusterStorage, ela não me dá acesso.

    Fica em não respondendo e me trava a conexão. Preciso liberar alguma permissão para ter acesso a esta pasta ???

    Obrigado.

    segunda-feira, 7 de janeiro de 2013 18:27

Respostas

  • Carlos, bom dia.

    Pelo comportamento inicial e agora, com a mensagem de erro, o problema parece estar mesmo na conectividade dos hosts com a storage. Em geral existe uma tendência/preconceito em apontar o ISCSI como culpado (muita gente prefere fibra), mas trabalho com ISCSI há algum tempo e posso te garantir que funciona bem, desde que configurado de maneira adequada.

    Vou dizer para você o que funciona para mim, e se eu esquecer algo, convido aos demais para complementar:

    • Dedique duas interfaces de rede para ISCSI e habilite MPIO, questão de redundância e também de desempenho pois o MPIO faz balanceamento de carga.
    • Configure jumbo frame nas interfaces de rede dos hosts, portas de switches e interfaces de rede (controladoras) de sua sotrage.
    • Utilize vlans diferentes para cada placa ISCSI e conecte cada uma delas em switches diferentes (redundância), exemplo: NIC ISCSI 1, VLAN 10, SWITCH01 e NIC ISCSI 2, VLAN 11, SWITCH02. Faça o mesmo com a storage. (Caso não tenha dois switches, pelo menos utilize duas VLANS).
    • Estude como funciona o RAID em sua storage, talvez o RAID50 não atenda a sua necessidade. Veja, também, com o fabricante qual é quantidade de discos recomendada em cada conjunto RAID que você criar. 
    • Veja se as interfaces de rede ISCSI dos hosts, possuem recursos avançados como ISCSI Offload, TCP Offload, RSS, TCP Chimney. Se tiver habilite nas propriedades de rede e no windows, através do comando netsh (importante atualizar os drivers e firmwares das interfaces de rede e das controladoras da storage).
    • Ao se usar Cluster Shared Volumes, a storage precisa ter suporte a feature ISCSI-3 Persistent Reservation.
    • Por questão de desempenho, é importante determinar o block size que você vai usar para cada LUN (Volume CSV).

      Num cluster Hyper-V, que lida com arquivos VHDs grandes, costumo usar blocos de 4K.
      Para um cluster File Server, que são arquivos menores, uso blocos de 512B.

      Mas não vá na minha onda, esse assunto é muito delicado pois não há uma regra geral, para decidir você precisa conhecer bem os arquivos que você guarda na storage. Por exemplo: Num escritório que trabalha com CAD, pode não ser boa idéia usar blocos de 512B no servidor de arquivos, pois os eles costumam ser grandes... Neste exemplo, quebrei a regra acima.

      Blocos maiores vão lhe dar um desempenho melhor (menor fragmentação), porém se seus arquivos forem pequenos você terá uma maior perda de espaço (pois um arquivo de 300B, vai ocupar 4KB na storage (é o tamanho do bloco).

      Blocos menores vão lhe dar a possibilidade de usar melhor o espaço (tamanho do bloco mais perto do tamanho do arquivo), porém, dependendo do perfil de arquivo que você guarda, você pode ter um pouco de impacto no desempenho por causa de uma fragmentação considerável.

    Obs.: No passado tive uma experiência ruim com as placas de rede Broadcom BCM5708C, BCM5708S e modelos semelhantes do mesmo fabricante. Ao usar estas interfaces, do nada o meu cluster perdia comunicação com a storage. Depois de muito investigar, descobri (lendo o readme.txt da placa), que o driver não estava maduro (isso foi em 2011) e em caso de problemas, era preciso desabilitar todas as features avançadas da placa (TCP Offload, RSS, ISCSI Offload e etc)... Depois que fiz isso, não tive mais problemas. Se você estiver usando placas deste fabricante, dê uma olhada na documentação e veja se tem algo relacionado com o problema que você está enfrentando.

    Abraços,


    Uellington Santos - MCSE Server Infrastructure/Private Cloud









    quinta-feira, 17 de janeiro de 2013 13:54

Todas as Respostas

  • Carlos, boa tarde.

    Não é preciso uma permissão ou liberação de acesso para abrir a pasta C:\Clusterstorage. (presumindo que você esteja logado como Domain Administrator)

    Eu já vi este tipo de comportamento ocorrendo quando havia um problema de conectividade com a storage ou quando a mesma não estava com bom desempenho. Dê uma olhada no Event Viewer, procure por logs que possam evidenciar algum problema de conectividade com a storage.

    Obs.: Podemos ajudar mais se você explicar como é sua infraestrutura:

    • Tipo de storage (SAN, NAS)
    • Tipo de discos (SATA ou SAS)
    • Tipo de RAID utilizado
    • Tipo de conectividade com os hosts e velocidade (ISCSI ou FIBRA)
    • etc.

    Att.


    Uellington Santos - MCSE Server Infrastructure/Private Cloud



    segunda-feira, 7 de janeiro de 2013 20:51
  • Cara, obrigado.

    Vou fazer os testes no equipamento e informo o ocorrido.

    Obrigado.

    segunda-feira, 7 de janeiro de 2013 22:07
  • Olá Carlos.

    Você já fez os testes que você comentou acima? Ainda está com o problema?

    Nos avise para continuarmos ajudando.

    Leandro Carvalho 
    Certified Ethical Hacker | MCSA+S+M| MCSE+S | MCTS | MCITP | MCBMSS | MCT | MVP Virtual Machine 
    My Blog | MSVirtualization (pt-BR) | Technet Wiki Articles | MVP Profile
    TwitterLeandroEduardo | LinkedInLeandroesc

    segunda-feira, 14 de janeiro de 2013 04:23
    Moderador
  • Cara ainda não consegui fazer os testes, está agendado para quinta feira, depois eu coloco o que foi feito. Valeu !!!
    segunda-feira, 14 de janeiro de 2013 21:14
  • Uelington, bom dia.

    Segue os dados:

    • Tipo de storage (SAN)
    • Tipo de discos ( SAS)
    • Tipo de RAID 50
    • Tipo de conectividade com os hosts e velocidade (ISCSI ).

    Tenho 4 máquinas neste cluster, desliguei 2 e consegui acessar.

    Nos logs aparece esse erro, mas eu já tenho o compartilhamento de pastas ativado.

    Cluster Shared Volume 'Volume2' ('Cluster Disk 3') is no longer accessible from this cluster node because of error 'ERROR_TIMEOUT(1460)'. Please troubleshoot this node's connectivity to the storage device and network connectivity.

    Obrigado

    quinta-feira, 17 de janeiro de 2013 11:34
  • Carlos, bom dia.

    Pelo comportamento inicial e agora, com a mensagem de erro, o problema parece estar mesmo na conectividade dos hosts com a storage. Em geral existe uma tendência/preconceito em apontar o ISCSI como culpado (muita gente prefere fibra), mas trabalho com ISCSI há algum tempo e posso te garantir que funciona bem, desde que configurado de maneira adequada.

    Vou dizer para você o que funciona para mim, e se eu esquecer algo, convido aos demais para complementar:

    • Dedique duas interfaces de rede para ISCSI e habilite MPIO, questão de redundância e também de desempenho pois o MPIO faz balanceamento de carga.
    • Configure jumbo frame nas interfaces de rede dos hosts, portas de switches e interfaces de rede (controladoras) de sua sotrage.
    • Utilize vlans diferentes para cada placa ISCSI e conecte cada uma delas em switches diferentes (redundância), exemplo: NIC ISCSI 1, VLAN 10, SWITCH01 e NIC ISCSI 2, VLAN 11, SWITCH02. Faça o mesmo com a storage. (Caso não tenha dois switches, pelo menos utilize duas VLANS).
    • Estude como funciona o RAID em sua storage, talvez o RAID50 não atenda a sua necessidade. Veja, também, com o fabricante qual é quantidade de discos recomendada em cada conjunto RAID que você criar. 
    • Veja se as interfaces de rede ISCSI dos hosts, possuem recursos avançados como ISCSI Offload, TCP Offload, RSS, TCP Chimney. Se tiver habilite nas propriedades de rede e no windows, através do comando netsh (importante atualizar os drivers e firmwares das interfaces de rede e das controladoras da storage).
    • Ao se usar Cluster Shared Volumes, a storage precisa ter suporte a feature ISCSI-3 Persistent Reservation.
    • Por questão de desempenho, é importante determinar o block size que você vai usar para cada LUN (Volume CSV).

      Num cluster Hyper-V, que lida com arquivos VHDs grandes, costumo usar blocos de 4K.
      Para um cluster File Server, que são arquivos menores, uso blocos de 512B.

      Mas não vá na minha onda, esse assunto é muito delicado pois não há uma regra geral, para decidir você precisa conhecer bem os arquivos que você guarda na storage. Por exemplo: Num escritório que trabalha com CAD, pode não ser boa idéia usar blocos de 512B no servidor de arquivos, pois os eles costumam ser grandes... Neste exemplo, quebrei a regra acima.

      Blocos maiores vão lhe dar um desempenho melhor (menor fragmentação), porém se seus arquivos forem pequenos você terá uma maior perda de espaço (pois um arquivo de 300B, vai ocupar 4KB na storage (é o tamanho do bloco).

      Blocos menores vão lhe dar a possibilidade de usar melhor o espaço (tamanho do bloco mais perto do tamanho do arquivo), porém, dependendo do perfil de arquivo que você guarda, você pode ter um pouco de impacto no desempenho por causa de uma fragmentação considerável.

    Obs.: No passado tive uma experiência ruim com as placas de rede Broadcom BCM5708C, BCM5708S e modelos semelhantes do mesmo fabricante. Ao usar estas interfaces, do nada o meu cluster perdia comunicação com a storage. Depois de muito investigar, descobri (lendo o readme.txt da placa), que o driver não estava maduro (isso foi em 2011) e em caso de problemas, era preciso desabilitar todas as features avançadas da placa (TCP Offload, RSS, ISCSI Offload e etc)... Depois que fiz isso, não tive mais problemas. Se você estiver usando placas deste fabricante, dê uma olhada na documentação e veja se tem algo relacionado com o problema que você está enfrentando.

    Abraços,


    Uellington Santos - MCSE Server Infrastructure/Private Cloud









    quinta-feira, 17 de janeiro de 2013 13:54
  • Camarada, boa noite.

    Por incrivel que pareça o problema estava no BACS que eu havia gerado para criar o team de rede nas placas Broadcom, após remoção o acesso normalizou e consegui acesso a pasta sem erros.

    Obrigado.

    segunda-feira, 21 de janeiro de 2013 21:42
  • Carlos,

    Também tive problemas com ao usar o TEAM do BACS para criar meu virtual switch no Windows 2008 R2 SP1. No meu ambiente, eu via o MAC Address da interface da VM aparecendo numa porta do switch, quando eu simulava a desconexão desta porta, o TEAM não chaveava o MAC da VM para a outra interface dele (era um TEAM de duas interfaces) e a VM ficava sem rede. Mesmo usando os vários algoritimos de balanceamento do BACS, eu observava o mesmo sintoma ocorrendo.

    Como falei anteriormente, as minhas interfaces de rede Broadcom só funcionaram corretamente após desabilitar todos os seus recursos avançados e, complementando agora, não usando o TEAM.

    Enfim, quem puder, fuja dessas interfaces de rede. As que já testei e recomendo são Intel Pro 1000 e Emulex, onde o Team e os recursos avançados funcionam a contento.

    Obs.: Fiz testes com o Windows Server 2012 com seu Team Nativo (protocolo Hyper-V Ports) em cima das interfaces Broadcom (driver que vem com o Windows), e não observei os problemas que tive com o BACS.

    Abraços,


    Uellington Santos - MCSE Server Infrastructure/Private Cloud





    terça-feira, 22 de janeiro de 2013 10:33