Volumes espelhados

Ao usar o espelhamento de volume, um volume poderá ter duas cópias físicas. Cada volume pode pertencer a um conjunto diferente e cada cópia tem a mesma capacidade virtual que o volume. Na GUI de gerenciamento, um asterisco (*) indica se a cópia primária do volume espelhado. A cópia primária indica o volume preferencial para solicitações de leitura.

Quando um servidor grava em um volume espelhado, o sistema grava os dados em ambas as cópias. Quando um servidor lê um volume espelhado, o sistema seleciona uma das cópias para ler. Se uma das cópias de volume espelhado estiver temporariamente indisponível; por exemplo, porque o sistema de armazenamento que fornece o conjunto está indisponível; o volume permanecerá acessível aos servidores. O sistema lembra quais áreas do volume são gravadas e ressincroniza essas áreas quando ambas as cópias estão disponíveis.

É possível criar um volume com uma ou duas cópias, e converter um volume não espelhado em um volume espelhado, incluindo uma cópia. Quando uma cópia é incluída dessa maneira, o sistema sincroniza a nova cópia para que ela seja igual ao volume existente. Os servidores podem acessar o volume durante esse processo de sincronização.

É possível converter um volume espelhado em um volume não espelhado, excluindo uma cópia ou dividindo uma cópia para criar um novo volume não espelhado.

A cópia de volume pode ser de qualquer tipo: imagem, dividida ou sequencial. A cópia de volume pode usar thin provisioning ou compactação para economizar a capacidade. Se as cópias estiverem localizadas em conjuntos de redução de dados, também será possível usar a deduplicação para as cópias de volume para aumentar a economia de capacidade. Se você estiver criando um novo volume, duas cópias poderão ser de tipos diferentes, mas, para usar a deduplicação, ambas as cópias devem residir em um conjunto de redução de dados. É possível incluir uma cópia de volume deduplicado em um conjunto de redução de dados em um volume existente com uma cópia em um conjunto padrão. É possível usar esse método para migrar cópias de volume existentes para conjuntos de migração de dados.

É possível usar volumes espelhados pelas seguintes razões:

Melhorar a disponibilidade dos volumes protegendo-os de uma única falha do sistema de armazenamento.
Fornecimento de manutenção simultânea de um sistema de armazenamento que não suporta nativamente a manutenção simultânea.
Fornecimento de um método alternativo de migração de dados com melhores características de disponibilidade. Enquanto um volume é migrado usando o recurso de migração de dados, ele fica vulnerável a falhas nos conjuntos de origem e de destino. O espelhamento de volume fornece uma alternativa porque é possível iniciar com um volume não espelhado no conjunto de origem e, em seguida, incluir uma cópia desse volume no conjunto de destino. Quando o volume estiver sincronizado, é possível excluir a cópia original que está no conjunto de origem. Durante o processo de sincronização, o volume permanece disponível mesmo que haja um problema com o conjunto de destino.
Convertendo volumes totalmente alocados para usar tecnologias de redução de dados, como thin provisioning, compactação ou deduplicação.
Convertendo volumes compactados ou thin-provisioned em conjuntos padrão para conjuntos de redução de dados para melhorar a economia de capacidade.

Ao usar o espelhamento de volume, considere como os discos quorum candidatos são alocados. O espelhamento de volume mantém alguns dados de estado nos discos quorum. Se um disco quorum não estiver acessível e o espelhamento de volume não conseguir atualizar as informações de estado, um volume espelhado talvez precise ser colocado offline para manter a integridade de dados. Para garantir a alta disponibilidade do sistema, certifique-se de que diversos discos de candidato quorum estejam alocados e configurados em diferentes sistemas de armazenamento.

Quando um espelho de volume está sincronizado, uma cópia espelhada pode se tornar não sincronizada se ela fica off-line e se as solicitações de E/S de gravação precisam ser processadas ou se um failover de espelho rápido ocorre. O failover rápido isola os sistemas host de cópias espelhadas de execução lenta temporariamente, o que afeta o sistema com uma breve interrupção na redundância.

Nota: Se a capacidade estiver totalmente alocada, o volume primário será formatado antes da sincronização nas cópias de volume. O parâmetro -syncrate no comando mkvdisk controla o formato e a velocidade da sincronização.

Failovers de gravação rápidos

Com failovers de gravação rápidos, durante o processamento da E/S de gravação de host, o sistema envia gravações (com um valor de tempo limite de 10 segundos) para ambas as cópias. Se uma gravação for bem-sucedida e a outra gravação levar mais do que 10 segundos, a solicitação mais lenta atingirá o tempo limite e terminará. A duração da sequência de término para uma E/S de cópia lenta depende do backend no qual a cópia espelhada está configurada. Por exemplo, se ocorrer a E/S sobre a rede Fibre Channel, a sequência final da E/S geralmente é concluída em 10 a 20 segundos. Entretanto, em raros casos, a sequência poderá levar mais de 20 segundos para ser concluída. Quando a sequência final da E/S for concluída, a configuração do espelho de volume será atualizada para registrar que a cópia lenta agora não está mais sincronizada. Quando as atualizações de configuração forem concluídas, a E/S de gravação poderá ser concluída no sistema host.

O espelho de volume para utilizando a cópia lenta por 4 – 6 minutos; as solicitações de E/S subsequentes são satisfeitas pela cópia sincronizada restante. Durante esse tempo, a sincronização é suspensa. Além disso, o progresso de sincronização do volume mostra menos de 100% e diminuirá se o volume receber mais gravações do host. Depois de a suspensão da cópia ser concluída, a sincronização de espelhamento de volume continua e a cópia lenta começa a ser sincronizada.

Se outra solicitação de E/S atingir o tempo limite na cópia não sincronizada durante a sincronização, o espelhamento de volume parará novamente usando essa cópia por 4 a 6 minutos. Se uma cópia for sempre lenta, o espelhamento de volume tentará sincronizar a cópia novamente a cada 4 a 6 minutos e ocorrerá outro tempo limite de E/S. A cópia não será usada por mais 4 a 6 minutos e se torna progressivamente não sincronizada. O progresso da sincronização gradualmente diminui à medida que mais regiões do volume são gravadas.

Se failovers de gravação rápidos ocorrem regularmente, pode haver um problema de desempenho subjacente no sistema de armazenamento que está processando os dados de E/S para a cópia espelhada que se tornaram não sincronizados. Quando uma cópia está lenta devido ao desempenho do sistema de armazenamento, múltiplas cópias em volumes diferentes são afetadas. As cópias podem ser configuradas a partir do conjunto de armazenamentos que está associado a um ou mais sistemas de armazenamento. Essa situação indica uma possível sobrecarga ou outros problemas de desempenho de backend.

Ao inserir o comando mkvdisk para criar um novo volume, o parâmetro mirror_write_priority é configurado para latency por padrão. O failover rápido é ativado. No entanto, o failover rápido pode ser controlado mudando o valor do parâmetro mirror_write_priority no comando chvdisk. Se mirror_write_priority for configurado como redundancy, o failover rápido será desativado. O sistema aplica um procedimento de recuperação de erro (ERP) da camada do inicializador SCSI completo para toda E/S de gravação espelhada. Se uma cópia estiver lenta, o ERP poderá levar até cinco minutos. Se a operação de gravação ainda for malsucedida, a cópia será colocada no modo off-line. Considere cuidadosamente se manter redundância ou failover rápido e tempo de resposta do host (em detrimento de uma perda temporária de redundância) é mais importante.

Ao definir volumes espelhados em uma configuração de sistema estendido, o valor mirror_write_priority pode precisar ser configurado como redundância. Se houver um atraso temporário na conclusão da operação de gravação, essa configuração manterá a sincronização das cópias.

Atenção: Volumes espelhados podem ser colocados off-line, se não houver nenhum disco quorum disponível. Esse comportamento ocorre porque o status de sincronização de volumes espelhados é registrado no disco quorum. Para se proteger contra os volumes espelhados sejam colocados offline, siga as recomendações para configurar os discos quorum.

Failovers de leitura rápidos

Failovers de leitura rápidos afetam a maneira como o sistema processa solicitações de E/S de leitura. Um failover de leitura rápido determina qual cópia de um volume o sistema tentará primeiro para a operação de leitura. A cópia primária destinada à leitura é a cópia que o sistema tenta primeiramente para a E/S de leitura; ela é determinada por um algoritmo de leitura especificado pelo usuário.

O sistema envia solicitação de E/S de leitura do host para uma cópia de um volume por vez. Se essa solicitação for bem-sucedida, o sistema retornará os dados. Se ela não for bem-sucedida, o sistema tentará a solicitação novamente para o outro volume de cópia.

Com failovers de leitura rápidos, quando a cópia primária para leitura fica lenta para E/S de leitura, o sistema falha na outra cópia. Isto significa que o sistema tentará a outra cópia primeiro para E/S de leitura durante os 4 a 6 minutos seguintes. Após isso, o sistema reverterá para ler a cópia primária para leitura original. Durante este período, se a E/S de leitura para a outra cópia também ficar lenta, o sistema reverterá imediatamente. Além disso, se a cópia primária para leitura mudar, o sistema reverterá para tentar a nova cópia primária para leitura. Isso pode ocorrer quando a topologia do sistema muda ou quando a cópia primária ou local muda. Por exemplo, em uma topologia padrão, o sistema normalmente tenta ler a cópia primária primeiro. Se você mudar cópia primária do volume durante um período de failover de leitura rápido, o sistema reverterá para ler a cópia primária recém-configurada imediatamente.

A função de failover de leitura rápida fica sempre ativada no sistema. Durante esse processo, o sistema não suspende os volumes ou faz cópias fora de sincronização.

Mantendo a integridade de dados de volumes espelhados durante a manutenção do sistema de armazenamento

O espelhamento de volume melhora a disponibilidade de dados permitindo que os hosts continuem a E/S para um volume, mesmo que um dos sistemas de armazenamento de backend tenha falhado. No entanto, este espelhamento não afeta a integridade de dados. Se um dos sistemas de armazenamento de backend corromper os dados, o host estará sob risco de ler esses dados corrompidos da forma que para qualquer outro volume. Portanto, antes de executar a manutenção em um sistema de armazenamento que possa afetar a integridade dos dados de uma cópia, é importante verificar se ambas as cópias do volume estão sincronizadas. Em seguida, remova essa cópia de volume antes de iniciar a manutenção. Por exemplo, o cenário se aplicaria se você precisasse zerar os dados nos discos que o sistema de armazenamento está fornecendo.