Olá pessoal, tudo bem?
Quando começamos a trabalhar com storage/armazenamento de dados, é importante conhecermos bem algumas tecnologias, poder recomendar algumas marcas e fabricantes, inclusive poder sugerir e escolher qual o melhor equipamento e infraestrutura iremos utilizar em determinado ambiente.
- Mas como isso é possível?
O primeiro passo é sempre ter em mente o conceito, a ideia geral de como tudo funciona e deve funcionar.
De um modo geral, a ideia e o conceito por trás de qualquer tecnologia tende à ser igual. Quando falamos de armazenamento o conceito é o mesmo, porém cada fabricante trabalha em cima de uma determinada essência, se o assunto for sistema operacional, a mesma coisa, cada um atende uma determinada especificação melhor que o outro S.O, backup também, um atende uma determinada criptografia, retenção, forma de tratar os dados, etc.
O que não muda de uma para o outro é que, a estrutura por trás do conceito storage deve ser a mesma, o S.O deve trabalhar e pensar de uma forma básica e igual assim como a ferramenta de backup deve pensar em fazer backup e restore, como uma estrutura de conexões e redundância que atenda seu propósito.
Quando essa essência, essa base é esquecida, costuma-se aparecer erros que são tratados como "primários".
Vamos ver alguns exemplos dessa situação quando falamos de storage:
- Fazer zoning com apenas uma porta HBA do servidor para comunicação com o storage.
É fato que fazendo essa configuração teremos comunicação com o storage, no entanto, vamos imaginar que essa porta da HBA queime ou apresente alguma falha. A comunicação com os discos do seu storage será perdida. Ambiente indisponível.
Beleza! Então agora eu vou fazer o zoning das duas HBAs para uma das portas do storage. Perfeito!
- Mas vamos supor que essa porta do storage venha a apresentar alguma falha ou mesmo a porta do switch SAN ao qual ela está conectada venha a falhar?! Ambiente indisponível novamente.
Repare que aqui, acabamos apenas nos preocupando com as duas portas HBA do servidor e pensamos em apenas uma das portas do storage, mas temos que lembrar que um único componente vira ponto de falha.
Ok! Então vou fazer zoning das duas portas HBA do servidor e as duas portas de comunicação do storage. E agora tenho certeza que não terei problema nenhum.
- Bem, nem sempre. Nesse ponto dependemos muito da estrutura e a forma do storage trabalhar. Alguns modelos como o EMC VNX, trabalham com o conceito de SPA e SPB (Storage processor A e storage processor B). São as portas de front-end da comunicação entre o servidor (portas HBA) com os discos que residem dentro do VNX. Só que além de SPA e SPB, ainda temos SPA-0, SPA1, SPB-0 e SPB-1. Ou seja, quatro portas de comunicação.
Imaginando que pela arquitetura deste storage as LUNS podem ser migradas automaticamente por qualquer uma das SP's, se nosso servidor não tiver zoning para as 4 portas, em algum momento poderemos ter problemas e falha de acesso para alguma LUN.
Então, o que teremos?
Ambiente parcialmente indisponível ou totalmente indisponível.
Agora deixei tudo certo! As duas HBAs do servidor possuem zoning configurado para as quatro portas do storage. Eu valei tudo no meu único switch SAN.
Opa!!! Único switch SAN???
Vamos analisar esse cenário:
- Redundância no servidor quanto as HBAs (dual pelo menos): OK
- Redundância quanto as portas do storage: OK
- Zoning entre as HBAs e todas as portas do storage: OK
- Switches redundantes: No_OK
Imagine se este switch queimar, reiniciar, apresentar problema em alguma ou uma das GBICs responsáveis por esta comunicação, falha de fibra, etc?!
Não vai adiantar nada nosso zoningo ter todas as comunicações necessárias.
Lembre sempre que zoning nada mais é do que configurações lógicas de recursos para que estes possam fazer parte de uma comunicação lógica através de conexões físicas.
Um outro fator que é muito comum em termos de problema quando falamos de storage é o tipo de configuração do multipath e como este deve ser configurado no servidor e no storage (quando aplicável).
Alguns storages trabalham como ativo-ativo, ativo-passivo, então para saber qual configuração utilizar no servidor, devemos sempre obedecer a forma que o storage trabalha.
Não vai adiantar muito eu colocar na configuração do multipath do meu servidor que ele é ativo-ativo, se meu storage for ativo-passivo, assim como eu também estarei perdendo recurso se eu colocar meu host como ativo-passivo e meu storage é ativo-ativo.
Claro que esse tipo de configuração dependerá da infraestrutura que eu estiver trabalhar, pois mesmo sabendo o certo, entendendo como tudo deveria funcionar, as vezes não temos condições de ter este cenário.
O tipo de configuração no multipath também pode ser responsável por lentidão no ambiente, falha de acesso, perda parcial ou total de acesso aos recursos de storage.
Então o que é importante tomarmos cuidado?
- Quantidade de HBAs do servidor
- Como funciona meu storage em relação as portas e movimentação de LUNS entre elas
- Zoning do servidor para o storage
- Configuração de multipath no servidor e no storage
- Redundância entre a camada de SAN (Switches)
Vamos ter em mente todas as comunicações que precisamos e a relação que uma tem com a outra.
Não adianta nada sabermos fazer zoning, criar alias para a identificação das portas do storage, do servidor, rodar um comando aqui e outro alí, se não conseguimos garantir que tudo o que está por trás disso está correto.
É sempre importante conhecermos bem o nosso storage, como está nossa SAN e o que temos de recursos no nosso servidor, para assim desenharmos mesmo que mentalmente nosso ambiente de ponta-a-ponta e saber onde podemos ter pontos de falha, se temos como corrigir ou contornar.
Espero que essas dicas inciais ajude para tomarmos cuidado ao sair configurando ambientes de forma desenfreada e correndo riscos desnecessários.
Mais para frente irei elaborar mais algumas dicas que irão servir como ponto de atenção na camada de storage e SAN.
Abraços e até a próxima!
:wq!
Nenhum comentário:
Postar um comentário