Scale-Out File Server – (SOFS) – Cluster de Failover de Servidor de Arquivos de uso geral

A chegada o Windows Server 2012 trouxe uma grande evolução em servidores de arquivos, pois servidores de arquivos de Scale-Out File Server- (SOFS) estão um passo além do servidor de arquivos tradicional

A essência do SOFS e do SMB 3.0 permite que seja implementada uma plataforma de armazenamento escalável. Essa plataforma pode lidar com os desafios de armazenamento dentro de organizações de todos os tamanhos a partir de uma arquitetura básica. A SOFS, juntamente com o SMB 3.0, traz uma oportunidade para as organizações que procuram diminuir o custo do armazenamento do Windows enquanto fornecem alta disponibilidade.

 

Visão Geral da Arquitetura

Um SoFS assegura a disponibilidade contínua de dados para aplicativos que a demandem. Quando um nó fica inativo devido a uma falha de hardware, a um ciclo de manutenção ou a qualquer outra razão, os dados permanecem disponíveis. Isso acontece por intermédio dos compartilhamentos nos outros nós. Mesmo se um nó perder o acesso à SAN (Storage Area Network), o CSV (Cluster Shared Volumes) poderá redirecionar o tráfego de I/O pela rede para outro nó.

O SoFS também aumenta a eficiência do cluster usando a largura de banda combinada de todos os nós para o I/O do sistema de arquivos. Para aumentar a largura de banda disponível, os administradores podem adicionar mais nós ao cluster. Por fim, o SoFS reequilibra automaticamente as conexões e assegura que cada cliente seja direcionado para o nó com melhor acesso aos dados solicitados.

Os pré-requisitos da criação de um Scale-out File Server (Servidor de Arquivos de Expansão) são basicamente os mesmos do Failover Clustering. A configuração de hardware dos nós do cluster deve ser o mais parecida possível. Além disso, todos os nós devem ter acesso ao armazenamento compartilhado usando o iSCSI, o SAS, o Fibre Channel ou uma tecnologia semelhante. Como o SoFS é uma função clusterizada, o recurso Failover Clustering deve ser instalado em todos os seus nós e o cluster deve ser criado antes da instalação. Também é necessário alocar o armazenamento disponível como volumes compartilhados de cluster (CSV), já que eles são requeridos por um Scale-Out File Server.

 

Pré-Requisitos

Não há uma lista longa de pré-requisitos para implementar o Servidor de Arquivos de Escalabilidade Horizontal. Apenas os seguintes itens devem ser observados:

  • Armazenamento compatível com Cluster de Failover do Windows Server.
  • Função de Servidor de Arquivos instalada em seus hosts SOFS.
  • SMB 3.0 (deve ser o Windows Server 2012 ou superior para que o SMB 3.0 esteja disponível).
  • Infraestrutura de Active Directory.

Observação: Se você estiver usando a versão anterior ao Windows Server 2019, não há suporte para configurações de loopback. Isso significa que você terá que hospedar o Hyper-V e o servidor de arquivos SOFS no mesmo servidor.

 

 Benefícios oferecidos pelo Servidor de Arquivos em expansão

Você pode estar se perguntando: Mas quais são os benefícios que em obter o SOFS (Scale-Out File Server)?

São vários:

  • Compartilhamentos de arquivos ativos-ativos – Isso significa que todos os nós do cluster podem aceitar e atender solicitações de clientes SMB. Um benefício tremendo da topologia ativo-ativo do cluster SOFS. Os failovers são transparentes para nós de cluster alternativos que assumem o compartilhamento de arquivos. Então, se você tiver um cluster Hyper-V usando SOFS, a VM permanecerá online durante um failover.
  • Largura de banda e desempenho aprimorados – A largura de banda e, por extensão, a quantidade de desempenho que você obtém dos compartilhamentos de arquivos suportados por SOFS são lineares ao número de nós adicionados ao cluster. Em um cluster de arquivos tradicionais, a largura de banda total não é mais restrita à largura de banda de um único nó do cluster. É possível aumentar a largura de banda simplesmente adicionando hosts ao cluster.
  • O CHKDSK não requer tempo de inatividade – O CHKDSK geral exige ter acesso exclusivo ao sistema de arquivos. No entanto, o aspecto Volume compartilhado de cluster do SOFS elimina o tempo de inatividade por não precisar mais da fase offline. O CSVFS (Cluster Shared Volume File System) pode usar o CHKDSK sem afetar os aplicativos com identificadores abertos no sistema de arquivos.
  • Cache CSV – O cache de volume compartilhado de cluster é um cache de leitura introduzido no Windows Server 2012. Ele melhora significativamente o desempenho em certos cenários, como infraestruturas de VDI.
  • Gerenciamento mais fácil – O gerenciamento é simplificado. Não é necessário criar vários servidores de arquivos em cluster com discos de cluster separados para depois desenvolver políticas de posicionamento. Neste caso é possível criar o SOFS, e também adicionar os CSVs e compartilhamentos de arquivos.
  • Rebalanceamento automático dos clientes do servidor de arquivos de expansão – Com o Windows Server 2012 R2, o rebalanceamento automático melhora a escalabilidade e a gerenciabilidade do SOFS. As conexões SMB são rastreadas por compartilhamento de arquivo. Em seguida, os clientes são redirecionados para o nó do cluster com o melhor acesso ao volume usado pelo compartilhamento de arquivo. Isso ajuda a melhorar a eficiência.

 

Novos Recursos de Expansão de servidor de arquivos no Windows Server 2019

O Windows Server 2019 trouxe muitos aprimoramentos ao servidor de arquivos de expansão. Isso torna o SOFS no Windows Server 2019 a versão SOFS mais resiliente e com melhor desempenho até o momento.

Mas quais aprimoramentos são encontrados no SOFS do Windows Server 2019?

Tradicionalmente, o SOFS depende muito do rodízio de DNS para as conexões que chegam aos nós do cluster. Isso pode resultar em algumas operações ineficientes. Por exemplo, se uma conexão é roteada para um nó de cluster de failover que não é o proprietário de um volume compartilhado de cluster (CSV), os dados são redirecionados pela rede para outro nó antes de retornar ao cliente. O serviço SMB Witness detecta a falta de I/O direto e move a conexão para um nó coordenador (proprietário do CSV), o que pode ocasionar em atrasos no retorno de dados.

O Windows Server 2019 fornece um comportamento muito mais eficiente quando se trata de retornar dados. O serviço SMB Server determina se é possível I/O direto no volume. Se for possível, a conexão passa. Se não for possível (I/O redirecionado), a conexão será direcionada com o coordenador antes do início da I/O. Há uma limitação na qual as conexões de clientes/servidor podem usar essa nova funcionalidade. Atualmente, está limitado aos clientes Windows Server 2019 e Windows 10 Fall Creators Update, lançado em 2017.

Uma nova função SOFS no Windows Server 2019 é chamada de Servidor de Arquivos de Infraestrutura. Quando criado, o Infrastructure File Server cria um único compartilhamento de namespace automaticamente para a unidade CSV. Em configurações hiperconvergentes, a função SOFS de infraestrutura permite que clientes SMB como um host Hyper-V se comuniquem com a CA (Continuous Available – CA) com o servidor SMFS de infraestrutura SOFS.

Outro aprimoramento no Windows Server 2019 é o SMB Loopback. Com ele o SMB pode funcionar corretamente com o loopback local do SMB. Isso não era suportado anteriormente.

A CA de loopback SMB hiperconvergente é obtida por meio de máquinas virtuais acessando seus arquivos de disco virtual (VHDx), onde a identidade da VM proprietária é encaminhada entre o cliente e o servidor.

Os conjuntos de clusters podem tirar proveito disso. Sendo o caminho para o VHD/ VHDX colocado como um único compartilhamento de namespace, o caminho pode ser utilizado independentemente de ser local ou remoto.

Com o Windows Server 2016, os hosts de computação do Hyper-V precisam receber permissão para acessar os arquivos VHD/VHDX no compartilhamento SOFS. No entanto, com o Windows Server 2019, um novo recurso chamado Identity Tunneling foi introduzido para permitir que as permissões sejam serializadas e encapsuladas no servidor. Isso reduz bastante a complexidade das permissões para acessar o compartilhamento SOFS para cada host Hyper-V.

Ao instalar a função de cluster File Server haverá duas opções. Criar um servidor de arquivos de uso geral (servidor de arquivos tradicionais) ou um Scale-Out File Server (SOFS), projetado para fornecer armazenamento para aplicativos como o Hyper-V e o SQL Server. As duas funções permitem criar compartilhamentos de disponibilidade contínua com o uso do protocolo SMB 3.0.

(Scale-Out File Server – (SOFS) – Windows Server 2019)

 

Vídeo

Finalmente, chegou a hora de aprender a configurar um cluster de servidor de arquivos de uso geral (servidor de arquivos tradicionais). Este é o famoso servidor de arquivos que toda empresa tem, mas com um diferencial: ele está altamente disponível! Se acontecer alguma falha em um dos servidores nós do cluster, este servidor de arquivos ainda continuará “de pé”, algo muito útil pois toda empresa, seja ela pequena ou grande, necessita de utilizar um servidor de arquivos.

Share

    Comments

    1. O Gabriel, excelente video. Fiquei com uma duvida, perdendo o SRV STORAGE, vc perde tudo certo? esse seria o ponto central de falha? Pois em um cenário com dois hosts fisico de virtualização, com dois storages ISCSI, que podemos utilizar como discos para o pool, se for fazer nesse modelo, usando uma vm para criar o pool, essa vm vai estar em um host, se perder o host onde está essa vms vamos perder o SOFS inteiro, perdendo só 1 dos hosts sem perder os storages ou o servidores virtuais membro do cluster. Podemos montar os discos direto nos servidores membros do cluster? Utilizando 2 hosts de virtualização e 2 storages, eu consigo criar um ambiente onde eu poso perder 1 host e storage que ainda vou funcionar? como faria isso? muito obrigado!!!

      • Boa tarde. Muito obrigado por prestigiar o nosso trabalho. Vamos a sua dúvida. O cenário demostrado foi feito usando virtualização aninhada apenas para demonstração, mas em um cenário real seria um servidor físico como storage, com fonte redundante e tudo mais para pode ficar em “pé”, dois servidores físicos de nós e um servidor físico ou virtualizado para active diretory. Entendeu?

    2. Gabriel

      gostei muito da sua aula

      ajudou bastante.

      Ricardo.

    3. Avatar for Gabriel Luiz Alexandre Hackenhaar : 24 de março de 2021 at 12:15 pm

      Boa tarde Gabriel, hoje tenho uma estrutura com 2 servidores de arquivos físicos, cada um com seus discos fazendo replicação de arquivos por DFS, uso essa estrutura para se um dos servidores cair o outro assumir.
      Tem como eu fazer isso usando cluster de failover, não sem em relação a replicação dos arquivos entre os 2 servidores como que ficaria?

    4. Bom dia Gabriel, parabéns pelo conteúdo, só uma dúvida. Quando fala que “se eu tiver um um cluster Hyper-V usando SOFS, a VM permanecerá online durante um failover.” O failover é do host hyperv ou do host do file server?

    Deixe um comentário

    O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

    © 2019 All Rights Reserved. Cooperati. 

    %d blogueiros gostam disto: