Muitas vezes estamos acostumados a vermos discos apresentados em nossos servidores, porém nem sempre lembramos de onde eles vem. Hoje em dia, muitos servidores e muitos ambientes que precisam de performance e redundância dos dados, é difícil encontramos aplicações rodando e sendo salvas em discos locais. Temos ainda outro cenário, servidores sendo inicializados com discos de boot que não são do servidor. Isso mesmo, discos que não são fisicamente do servidor.
Mas de onde vem estes discos?
Pois bem eles vem de storage.
Um storage nada mais é do que um hardware parrudo a nível de estrutura física, contendo controladoras, fontes de energia, portas ethernet, portas FC, portas ISCSI e o componente mais importante discos. É claro que aqui estou falando de uma forma simplificada dos componentes do storage.
Vejam que pelos componentes que compõem um storage, ele é de certo modo uma estrutura semelhante a de um servidor. Isso mesmo, um servidor. Ele também tem um SO próprio seja ele customizado ou desenvolvido pela empresa que o comercializa. O software tem o mesmo propósito de um software de servidor como Windows ou Linux. Administrar todos os recursos da caixa e prover interfaces de administração para o administrador storage.
Agora como um host consegue ter acesso a estes discos? Como configuro estes discos?
Cada storage tem sua peculiaridade em termos de configuração de recursos, utilização dos discos (os storages podem conter discos SATA, FC e SSD), redundância e entrega dos recursos configurados para os hosts, que para o storage são chamados de initiators.
Initiator nada mais é do que o seu servidor Windows, Linux, AIX, etc.
Os initiators precisam de uma placa para ter comunicação com a estrutura SAN. É a tão famosa HBA: Host Bus Adapter.
As HBAs podem ser dual ou single. Quando single, temos apenas um caminho de comunicação do initiator até a rede SAN, quando dual ele possui dois caminhos de comunicação com a SAN.
Esta placa independente do SO, tem como objetivo receber e transmitir sinais infra-vermelho dos dados do inicio ao fim, ou seja, do initiator ao storage e do storage ao initiator.
Não vou entrar em muitos detalhes neste assunto de como funciona uma placa HBA, isto pode ficar para um outro material.
Agora que nosso servidor está com sua HBA instalada e com o seu driver funcionando corretamente (isso mesmo, as vezes é necessário a instalação de algum driver para a HBA funcionar corretamente no SO), vou mostrar um exemplo de conexão single primeiro e depois o dual.
O initiator irá receber uma cabo de fibra que será conectados na HBA e a outra ponta será conectado em um switch de SAN. Aqui temos uma questão interessante que muitas pessoas de field acabam esquecendo ou não sabem verificar. Se a conexão do initiator com o switch está UP (com o sinal do switch verde).
Se olharmos na HBA quando o host está ligado, veremos que nos dois canais de comunicação teremos um apagado e o outro com um lazer vermelho. Estes sinais são chamados de RX/TX.
RX/TX são os sinais de transmissão e recebimento, vamos dizer assim.
Agora olhando na porta do switch que deve estar configurada como ˜no shut" para estar disponível a conexões, ela também ter um lado do conectar com sinal de lazer e o outro sem. Com isso é necessário que ao realizarmos a conexão, devemos faze-la de forma que a ponta que está no initiator com o sinal fique conectada no switch na entrada que não tem sinal e a porta do initiator que estiver sem sinal do lazer conectado a porta do switch que esteja com o sinal de lazer.
Alguns fabricantes de fibra tentam ajudar e mandam as fibras com um suporte que mantêm as pontas firmes, porém as vezes temos que desmontá-lo para corrigir a conexão (eu mesmo já tive que fazer isso várias vezes).
Agora o administrador storage pode conectar no storage e ver se a porta conectada está UP de fato, e assim ver o WWN.
WWN? Mas o que é WWN?
WWN é o World Wide Name da HBA. Uma identificação de 8 bytes (semelhante ao Mac Address de sua placa de rede).
Segue um exemplo:
21:00:00:e0:8b:05:05:04 ( este exemplo é de um WWN de uma HBA modelo Qlogic)
Esta informação é de extrema importância em uma estrutura de SAN, pois esta é e sempre será a principal identificação do seu servidor no storage e na estrutura de SAN.
Mas como eu vou guardar esta numeração e como vou lembrar de qual servidor ela pertence?
Bem, cada switch de SAN proporciona que você crie um nome amigável e vincule ao initiator. É o chamado host.
Então vamos supor que meu servidor web tenha o seguinte nome: srv_web01
Ele pode ter o seguinte nome/host na minha SAN: srv_web01_HBA0
Isso mesmo, eu posso mudar o nome original do servidor na SAN sem que isso tenha impacto no hostname original do servidor. Como eu falei, os switches SAN proporcionam que você configure um nome amigável ao WWN, mas nada impede que eu coloque qualquer nome.
Nossa mas isso não pode gerar uma enorme confusão?
Não só pode como causa e muita confusão.
Agora como podemos ter sempre a certeza de que estamos falando do mesmo host/initiator seja para uma nova configuração ou para uma alteração?
Vocês se lembram que eu falei que para SAN o mais importante é o WWN do servidor? Sempre que formos fazer uma alteração ou criação é necessário que tenhamos em mãos o WWN, somente com isso podemos diminuir uma falha de configuração.
Porém eu recomendo fortemente que estes nomes sejam padronizados e que tentem ser seguidos. Mas como em um mundo corporativo estamos sempre limitados a irmos até certo ponto, nada impede que o administrador do SO altere o hostname do mesmo depois de toda uma configuração feita. Mas vejam, o WWN continua o mesmo.
Posso mudar o WWN?
Não. O WWN só será alterado quando mudar a placa HBA no servidor. Então logo podemos ver que o WWN sempre será único.
Mas nada impede que o administrador de storage também mude o nome do host/initiator, certo? Isso mesmo.
Mas vejam que uma alteração no hostname no nosso caso, administradores de storage, serve para nossa administração.
Ao adicionar no nome do host/initiator o final como HBA0, eu identifico na minha SAN a primeira WWN do servidor ou mesmo se está é a única que ele irá possuir.
Então com uma única HBA, ainda é possível ter acesso ao storage por mais de um caminho?
Sim. Isso é possível deste que toda nossa estrutura de SAN esteja ligada de forma redundante e nosso storage ligado nestas duas estruturas.
Vou tentar exemplificar um cenário.
Imagem que eu tenho um prédio e no meu CPD eu tenho ele como se fosse dividido em dois. Eu ficaria então com o lado A e com o lado B.
Bem, no lado A eu tenho uma estrutura de elétrica independente da estrutura elétrica do lado B, pois vamos imaginar que eu tenha algum problema no circuito do lado A, eu ainda tenho o B para segurar o ambiente no ar ou vice-versa.
Então eu preciso ter um switch SAN ligado do lado A e outro do lado B.
Como meu initiator possui apenas uma fibra, eu só posso ligá-lo em um dos switches, seja ele do lado A ou do lado B.
Porém meu storage tem uma fibra saindo de uma das SPs (storage processor) e indo para o switch A e outra fibra de outra SP indo para o switch B.
Então aqui se minha configuração na parte lógica da SAN estiver correta, meu único caminho de falha passar a ser o host/initiator, a fibra ou o switch.
Agora vamos imaginar que meu storage possui quatro SPs, como eu faço essa conexão de forma redundante com a SAN?
Exemplo:
SPa1
SPb1
SPa2
SPb2
Meu storage também é dividido ao meio, fazendo assim como se o mesmo fosse duas caixas. Por isso eu tenho os nomes SPA e SPB.
Minha conexão ficaria da seguinte forma:
SPa1 - switch do lado A
SPb1 - switch do lado A
SPa2 - switch do lado B
SPb2 - switch do lado B
Note que se eu tiver um problema em alguma das SPs eu ainda tenho outra que irá atender as solicitações do host/initiator. Ou seja, neste modelo para que o ponto de falha seja o storage é necessário que o storage inteiro fique indisponível.
Bom então recapitulando até aqui, nossa estrutura está ativa da seguinte forma:
- Meu initiator: srv_web01_HBA0 ligado no switch do lado A e por sua vez este switch do lado A recebe uma SP do lado A do storage e outra do lado B do storage;
Ótimo, agora meu servidor já consegue enxergar o storage, certo? Ainda não.
O que eu preciso fazer agora é configurar uma regra para que eu agrupe em um mesmo objeto o meu initiator e as SPs do storage disponíveis.
Os switches sejam eles Brocades ou CISCO possuem uma interface web/java para que possamos fazer essas configurações. São os chamados Fabrics.
Quando eu abri a interface do Fabric eu tenho acesso a praticamente todos os recursos de configuração da mesma forma que eu tenho pela linha de comando, claro, cada switch com sua peculiaridade de comandos.
Então, para que meu initiator tenha comunição com o storage eu tenhos os seguintes passos:
Initiator do servidor: srv_web01_HBA0
Initiator do storage: stg_SPa1_SPb1
Mas espera aí… O que compõe este initiator do storage, chamado de stg_SPa1_SPb1?
Ele é composto pelos initiators do storage, que é nada mais nada menos do que as WWNs do storage.
Veja que cada storage possui uma certa identificação que com o passar do tempo ao batermos o olho podemos identificar de qual storage se trata. Veja alguns exemplos:
00:17:38
IBM, formerly XIV.
00:1B:32
QLogic HBAs. new identifier space starting to be used in 2007
00:90:66
QLogic formerly Troika Networks
00:11:75
QLogic formerly PathScale, Inc
00:60:B0
Hewlett-Packard - Integrity and HP9000 servers. WWIDs begin with 5006.0b0
00:17:A4
Hewlett-Packard - MSL tape libraries. Formerly Global Data Services. WWIDs begin with 200x.0017.a4
Então vamos supor que este initiator stg_SPa1_SPb1 venha de um storage EMC Clarrion:
00:60:16:00:00:00:00:01
00:60:16:00:00:00:00:02
É claro que no meu exemplo os últimos octetos eu iventei a fim de ilustrar como ficaria o WWN completo.
Agora eu tenho dois objetos identificados para saber quem é meu servidor e quem é meu storage. Mas eles ainda não se comunicam.
Eu preciso criar um zoning. Um zoning é um objeto que será composto pelos WWNs que eu quero que tenha comunição.
Nome do meu zoning: srv_web01_HBA0_stg_SPa1_SPb1
Composto por quem?
srv_web01_HBA0
stg_SPa1_SPb1
Agora é necessário que eu habilite essa configuração e por fim salve para que caso o meu switch reboot ele não perca essa configuração.
Feito isso e tendo o retorno de que a configuração foi ativada e salva com sucesso, efetivamente meu initiator enxerga meu storage e meu storage enxerga meu initiator. Esse enxergar é ter condições de se comunicar e propagar informações entre ambos.
Agora eu preciso falar para meu storage quem é este initiator pois ele irá ler o initiator como sendo apenas o WWN.
Aqui também cada storage tem sua forma de configuração para isso, que não serão abordados aqui. Mas é de certo modo o processo é semelhante ao que fizemos com o initiator na SAN.
srv_web01:21:00:00:e0:8b:05:05:04
Que bom, agora depois de tudo isso posso começar a usar os discos do storage!!! Opa!!! Ainda não.
Imagine a bagunça e o problema que seria para todo mundo se todo host conectado ao storage quisesse sair usando todos os discos ou mesmo assim, que cada host tentasse usar o mesmo disco?
Cada storage tem um jeito de configurar essa "política" de utilização dos discos, bem como os discos são dispostos para utilização.
Eu tenho que criar um objeto para agrupar os discos e o initiator para assim, apenas este host enxergar os discos adicionados dentro deste mesmo storage group. Então veja que seu storage group deve ser composto por initiator mais discos.
Agora para que meu initiator possa ver os discos no SO eu preciso fazer um rescan na minha HBA e por fim realizar a formatação do(s) disco(s).
No Windows eu posso ir no gerenciador de discos e fazer um rescan. Caso ele não reconheça, podemos baixar um aplicativo de cada fornecedor da HBA para fazer o rescan, mesmo se ele não reconhecer os discos com este procedimento, basta um reboot no servidor.
O mesmo vale para o linux e outros SOs derivados dele ou do Unix, lembrando que eu posso forçar este rescan sem necessidade de reboot. (Em outra matéria eu mostro um pouco mais de rescan de discos).
Agora é só executar um fdisk para podermos ver o disco apresentado. Mas espera um minuto, por que eu estou exergando dois discos?
Cuidado, estes "dois" discos são na verdade o mesmo disco, porém com mais de uma caminho para acesso. Neste caso o que eu preciso ter instalado e configurado em meu servidor é um gerenciador de multipath como o MPIO no Windows ou o multipathd do Linux.
Então feito isso, eu irei enxergar via fdisk um único disco, mas que na verdade tem redundância de acesso.
Agora imaginem uma estrutura onde meu servidor possui duas HBAs (HBA dual)?
Todo processo será exatamente o mesmo, mudando apenas que eu terei que ligar uma HBA no switch lado A e a outra no switch lado B.
Na hora de fazer meu zoning (objeto que contem os initiators/host e wwns do storage) eu preciso fazer uma para o lado A e o outro para o lado B.
Vamos lá então:
srv_web01_HBA0 (primeira WWN ligada no switch lado A);
srv_web01_HBA1 (segued WWN ligada no switch lado B);
SPa1 - ligada no switch lado A
SPb1 - ligada no switch lado A
SPa2 - ligada no switch lado B
SPb2 - ligada no switch lado B
Zoning para o lado A:
srv_web01_HBA0_SPa1_SPb1
Zoning para o lado B:
srv_web01_HBA1_SPa2_SPb2
Agora olha que légal, eu terri quatro canais de comunicação pois vou utilizar 4 SPs do storage.
Então agora no meu SO sem o multipath configurado eu enxergaria 4 caminhos para o mesmo disco.
Vejam que aqui eu tentei explicar bem superficialmente um pouco da estrutura e de como as partes se comunicam para vocês poderem entender um pouco mais de como funciona esta estrutura, que as vezes parece simples, mas que na maioria das vezes é complicada ainda mais quando temos problemas e precisamos fazer um troubleshooting.
Eu vou tentar ao longo de algumas matérias que tenho em mente de explicar alguns pontos um pouco mais específicos, mas é claro para isso também preciso preparar melhor um conteúdo e alguns desenhos para ajudar.
Segue algumas fontes consultadas:
Até a próxima.
