Links de longa distância para parcerias Metro Mirror e Global Mirror

Os links entre pares do sistema em cluster que executam espelhamento remoto devem atender requisitos específicos de configuração, latência e distância.

Figura 1 mostra um exemplo de uma configuração que usa malhas redundantes duais que podem ser configuradas para conexões Fibre Channel (FC). Parte de cada malha está no sistema local e no sistema remoto. Não há nenhuma conexão direta entre as duas malhas.

A figura mostra um sistema local e um remoto — Figura 1. malhas redundantes

É possível usar extensores Fibre Channel ou roteadores da SAN para aumentar a distância entre dois sistemas. Os extensores Fibre Channel transmitem pacotes Fibre Channel através de links longos sem alterar o conteúdo dos pacotes. Os roteadores SAN fornecem N_ports virtuais em duas ou mais SANs para estender o escopo da SAN. O roteador da SAN distribui o tráfego de uma N_port virtual para outra. As duas malhas Fibre Channel são independentes umas das outras. Portanto, N_ports em cada uma das malhas não podem efetuar login diretamente entre si. Consulte o website a seguir para os níveis de firmware específico e o hardware mais recentes suportados:

www.ibm.com/support

Se você usar extensores Fibre Channel ou roteadores SAN, deve-se atender aos seguintes requisitos:

A latência de roundtrip máxima suportada entre os sites depende do tipo de parceria entre os sistemas, da versão do software e do hardware do sistema que é usado. Essa restrição se aplica a todas as variantes de espelhamento remoto.

A tabela a seguir lista a latência de roundtrip máxima para cada tipo de parceria.

Tabela 1. Latência máxima de roundtrip suportada entre sites
Parceria
FC	IP de 1 Gbps	IP de 10 Gbps
250 ms	80 ms	10 ms

O Metro Mirror e Global Mirror requerem uma quantidade específica de largura da banda para o tráfego de pulsação intersistema. Quando o sistema usa uma parceria do Fibre Channel, a quantidade de tráfego depende do número de nós que estão no sistema local e no sistema remoto. Tabela 2 fornece uma diretriz para o tráfego de pulsação intersistema entre o sistema primário e o sistema secundário. Esses números representam o tráfego total entre dois sistemas quando nenhuma operação de E/S é executada nos volumes copiados. Metade dos dados é enviada pelo sistema primário e metade dos dados é enviada pelo sistema secundário. Portanto, o tráfego é dividido uniformemente entre todos os links intersistêmicos disponíveis. Se você possui dois links redundantes, metade do tráfego é enviado por cada vínculo.

Tabela 2. Tráfego de pulsação de intersistema em Mbps
Sistema 1	Sistema 2
Sistema 1	2 nós	4 nós	6 nós	8 nós
2 nós	5	6	6	6
4 nós	6	10	11	12
6 nós	6	11	16	17
8 nós	6	12	17	21

Em um relacionamento do Metro Mirror ou não cíclico do Global Mirror, a largura da banda entre dois sites deve atender aos requisitos de carga de trabalho de pico e manter a latência de roundtrip máxima entre os sites. Ao avaliar o requisito de carga de trabalho em um relacionamento do Global Mirror de múltiplos ciclos, será necessário considerar a carga de trabalho de gravação média e a largura da banda da cópia de sincronização necessária. Se não houver cópias de sincronização ativas e nenhuma operação de E/S de gravação para volumes que estão no relacionamento de Metro Mirror ou Global Mirror, os protocolos do sistema operarão com a largura da banda indicada em Tabela 2. No entanto, é possível determinar apenas a quantidade real de largura de banda que é necessária para o link por considerando a largura da banda de gravação de pico para volumes que estão participando da Metro Mirror ou Global Mirror relacionamentos e, em seguida, incluindo a largura da banda de pico de gravação para a largura da banda de sincronização de pico.
Se o link entre dois sites estiver configurado com redundância de modo que ele possa tolerar falhas únicas, o link deverá ser dimensionado de modo que as instruções de largura da banda e latência estejam corretas durante condições de falha única.
O mesmo canal não deve ser utilizado para links entre nós em um único sistema. As configurações que usam links de longa distância em um único sistema são suportadas como sistemas estendidos, mas sistemas estendidos requerem canais dedicados para tráfego de nó para nó intrassistema.
A configuração é testada para confirmar se algum mecanismo de failover nos links intersistemas interopera satisfatoriamente com os sistemas.
Todos os outros requisitos de configuração são atendidos.

Requisitos de configuração para sistemas que executam espelhamento remoto em distâncias estendidas (maior que a latência de roundtrip de 80-ms entre os sites)

Se você usar o espelhamento remoto entre sistemas com latência de roundtrip de 80-250-ms, você deverá atender aos seguintes requisitos adicionais:

Todos os nós que são usados para replicação devem ser de um modelo suportado.
Uma parceria Fibre Channel deve existir entre os sistemas, não uma parceria de IP.
Todos os sistemas na parceria devem ter um nível de software mínimo de 7.4.0.
A configuração de tamanho do buffer de RC deve ser 512 MB em cada sistema na parceria. Esta configuração pode ser alcançada ao executar o comando chsystem -rcbuffersize 512 em cada sistema.
Nota: Alterar essa configuração interrompe as operações de Metro Mirror e Global Mirror. Use esse comando somente antes da parcerias serem criadas entre sistemas ou quando todas as parcerias com o sistema são paradas.
Duas portas Fibre Channel em cada nó usado para a replicação devem ser dedicadas para o tráfego de replicação usando o zoneamento de SAN e a máscara de porta.
O zoneamento de SAN deve ser aplicado para fornecer zonas intersistêmicas separadas para cada par de grupos de E/S local-remoto usado para replicação. A Figura 2 ilustra esse tipo de configuração.
Figura 2. Zoneamento da SAN Intersistema

Além da lista anterior dos requisitos, as diretrizes a seguir são fornecidas para otimizar desempenho para espelhamento remoto, usando o Global Mirror:

Os sistemas parceiros devem usar o mesmo número de nós em cada sistema para replicação.
Para rendimento máximo, todos os nós em cada sistema devem ser usados para replicação, em termos de balanceamento da designação de nó preferencial para volumes e para fornecer conectividade Fibre Channel intersistema.
No sistema, o fornecimento de portas de nó dedicadas para o tráfego de nó para nó local (usando o mascaramento de porta) isola o tráfego nó para nó do Global Mirror entre os nós locais de outro tráfego de SAN local. Consequentemente, os tempos de resposta ideais podem ser alcançados. Essa configuração de mascaramento da porta de nó local é um requisito menos significativo em sistemas da família Storwize, em que o tráfego entre as caixas do nó em um grupo de E/S é atendido pelo link entre caixas dedicado no gabinete.
Quando for possível, use o número mínimo de parcerias entre sistemas. Por exemplo, suponha que o site A contenha os sistemas A1 e A2, e o site B contenha os sistemas B1 e B2. Nesse cenário, criar parcerias separadas entre os pares de sistemas (como A1-B1 e A2-B2) oferece um desempenho maior para a replicação do Global Mirror entre locais do que a configuração com parcerias definidas entre todos os quatro sistemas.

Limitações de distâncias do host para sistema

Não há limite na distância óptica do Fibre Channel entre os nós do sistema e os servidores host. É possível conectar um servidor a um comutador de borda em uma configuração de borda principal com o sistema no núcleo. O sistema pode suportar até três hops ISL na malha. Portanto, o servidor host e o sistema podem ser separados por até cinco links do Fibre Channel. Se você usar transceptores small form-factor pluggable (SFP) de ondas longas, quatro dos links de Fibre Channel poderão ter até 10 km de comprimento.