Armazenamento de Alta Disponibilidade (II)

Storage Area Network

Uma Storage Area Network (SAN) é uma sub-rede de alto desempenho dedicada que oferece acesso a armazenamento de dados consolidado ao nível de bloco, e é usada principalmente para a transferência de dados entre sistemas de computadores e elementos de armazenamento e entre os próprios elementos de armazenamento, fazendo com que dispositivos de armazenamento, como conjuntos de discos, bibliotecas de fitas, e torres de armazenamento óptico estejam acessíveis aos servidores de modo a que os dispositivos apareçam como dispositivos locais ligados ao sistema operativo.



Uma SAN normalmente tem a sua própria infra-estrutura de comunicação, que geralmente não é acessível por outros dispositivos através da rede de área local. A SAN move dados entre vários dispositivos de armazenamento, permitindo a partilha de dados entre servidores diferentes, e fornece um meio de ligação rápido para backup, restauro, arquivo e recuperação de dados. Os dispositivos da SAN são normalmente instalados numa sala individual, mas também podem ser ligados a longas distâncias, tornando-os muito úteis para grandes empresas.

Benefícios das SAN

Os principais benefícios de uma SAN são:

• Alta Disponibilidade: Uma cópia de quaisquer dados está sempre acessível a todos e quaisquer clientes via múltiplos caminhos;
• Fiabilidade: O transporte de dados fiável assegura uma baixa taxa de erro e capacidades de tolerância a falhas;
• Escalabilidade: Servidores e dispositivos de armazenamento podem ser adicionados de forma independente uns dos outros e de quaisquer sistemas proprietários;
• Desempenho: Fibre Channel (o método padrão para a interligação nas SAN) tem agora mais de 2000MB/seg de largura de banda e separa as E/S de armazenamento e de rede.

Ler mais »

Armazenamento de Alta Disponibilidade (I)

Conceitos sobre RAID

A sigla RAID significa Redundant Array of Inexpensive Disks e é uma tecnologia que fornece funções de armazenamento e fiabilidade através de redundância. Foi desenvolvida utilizando um grande número de discos rígidos de baixo custo unidos para formar um único dispositivo de armazenamento de grande capacidade que oferecia um desempenho, capacidade de armazenamento e fiabilidade superiores em relação aos sistemas mais antigos de armazenamento. Isto foi conseguido através da combinação de múltiplas unidades físicas numa única unidade lógica onde os dados foram distribuídos entre as unidades, numa de várias formas conhecidas como níveis de RAID.

Este conceito de virtualização de armazenamento foi inicialmente definido como Redundant Array of Inexpensive Disks (conjunto redundante de discos baratos) mas o termo mais tarde evoluiu para Redundant Array of Independent Disks como forma de dissociar a tecnologia RAID das expectativas de baixo custo.
Há duas principais razões pelas quais o RAID foi desenvolvido:

• Redundância: Este é o factor mais importante no desenvolvimento de RAID para ambientes de servidor. Um sistema RAID típico vai garantir algum nível de tolerância a falhas, fornecendo recuperação de dados em tempo real com acesso ininterrupto no caso de ocorrer uma falha de disco; 

• Aumento de desempenho: O aumento de desempenho só ocorre nalgumas versões específicas de RAID e será sempre dependente do número de unidades utilizadas e do controlador;

RAID baseado em software

Muitos sistemas operativos oferecem funcionalidades para a implementação de sistemas de RAID baseado em software onde o OS gera os algoritmos de RAID usando a CPU do servidor. Na verdade, a carga de processamento do RAID é suportada pela unidade de processamento central, em vez de ser pelo controlador RAID em si, o que pode limitar severamente o desempenho do RAID. Embora de implementação barata, estes sistemas não garantem qualquer tipo de tolerância a falhas; se um servidor falhar todo o sistema RAID é perdido.

RAID baseado em hardware

Ao usar controladores RAID de hardware, todos os algoritmos são gerados na placa controladora RAID, libertando assim a CPU do servidor. Num sistema desktop, um controlador RAID de hardware pode ser uma placa de expansão PCI ou PCIe placa ou um componente integrado na motherboard. Estes são mais robustos e tolerantes a falhas que o software RAID, mas requerem um controlador RAID dedicado a essa tarefa. Implementações de hardware fornecem um desempenho garantido, não acrescentam sobrecarga computacional para o computador e podem suportar muitos sistemas operativos; o controlador apresenta o conjunto RAID como apenas mais uma unidade lógica.

Unidade “Hot Spare”

Tanto os RAIDs de hardware como os de software podem suportar a utilização das chamadas drives “hot spare”, ou seja, uma unidade fisicamente instalada no conjunto mas que fica inactiva até que uma unidade activa falhe. O sistema automaticamente substitui a unidade que falhou com a de reserva, reconstruindo o conjunto com a unidade de reserva incluída. Isso reduz o tempo médio de recuperação (MTTR), mas não o elimina completamente porque uma falha adicional subsequente no mesmo grupo de redundância RAID antes deste ser totalmente reconstruído, pode resultar em perda de dados. A reconstrução pode levar várias horas, especialmente em sistemas muito carregados.

Ler mais »

Failover Clustering (IV)

 

Configurações dos Nós do Cluster

O tamanho mais vulgar para um cluster de alta disponibilidade é um cluster de dois nós, já que esse é o mínimo necessário para garantir redundância, mas muitos clusters consistem de muitos mais, às vezes dezenas de nós e essas configurações podem ser categorizados num dos seguintes modelos:

Cluster Activo/Passivo

Numa configuração Activo/Passivo (ou assimétrica), as aplicações são executadas num servidor primário, ou mestre. Um servidor redundante dedicado está presente para o substituir em caso de falha mas, para além disso, não está configurado para desempenhar qualquer outra função. Assim, a qualquer momento, um dos nós é activo e o outro é passivo. Esta configuração fornece uma instância totalmente redundante de cada nó, que só é colocada online quando o seu nó primário associado falhar.

O cluster activo/passivo geralmente contém dois nós idênticos. As instâncias das aplicações de base de dados são instaladas em ambos os nós, mas a base de dados está localizada no armazenamento partilhado. Durante a operação normal, a instância da aplicação de base de dados é executada somente no nó activo. No caso de uma falha do sistema activo principal, o software de clustering vai transferir o controlo do subsistema de disco para o sistema secundário. Como parte do processo de failover, a instância da aplicação de base de dados no nó secundário é iniciada, retomando assim o serviço.
 

 
Esta configuração é mais simples e mais fiável, mas normalmente exige mais hardware extra.

Ler mais »

Failover Clustering (III)

 

Configurações de Quórum do Cluster

Em termos simples, o quórum de um cluster é o número de elementos que devem estar online para que o cluster continue em funcionamento. Os servidores de um cluster necessitam de um recurso de quórum para funcionarem e este, como qualquer outro recurso, é um recurso que só pode ser possuído por um servidor de cada vez e pelo qual os servidores podem negociar a sua posse. Com efeito, cada elemento pode lançar um "voto" para determinar se o cluster continua a funcionar. Os elementos votantes são nós ou, nalguns casos, um disco testemunha ou ficheiro partilhado testemunha. O recurso de quórum é usado para armazenar a cópia definitiva da configuração do cluster de modo que, independentemente de qualquer sequência de falhas, a configuração do cluster será sempre consistente. Cada elemento votante (com excepção do ficheiro partilhado testemunha) contém uma cópia da configuração do cluster e o serviço de cluster trabalha de modo a manter todas as cópias constantemente sincronizadas.

Quando ocorrem problemas de rede, estes podem interferir na comunicação entre os nós do cluster. Um pequeno grupo de nós pode ser capaz de comunicar em conjunto através de uma parte da rede mas não ser capaz de comunicar com outro grupo diferente de nós noutra parte da rede. Isso pode causar problemas sérios. Nesta situação dividida, pelo menos um dos conjuntos de nós deve parar de funcionar como um cluster.A negociação pelo recurso de quórum permite que os servidores do cluster evitem situações de divisão (split-bain) em que os servidores estão activos e julguem que os outros servidores estão em baixo.

Para evitar os problemas que são causados por uma divisão no cluster, o software do cluster exige que qualquer conjunto de nós a funcionar como um cluster tem que usar um algoritmo de votação para determinar se, num dado momento, esse conjunto tem quórum. Como um determinado cluster tem um conjunto específico de nós e uma configuração de quórum específica, o cluster saberá quantos "votos" constitui uma maioria (ou seja, um quórum). Se o número cair abaixo da maioria, o cluster pára de funcionar. Os nós continuarão a ouvir a presença de outros nós, no caso de outro nó aparecer novamente na rede, mas os nós não começarão a funcionar como um cluster até que o quórum exista novamente.

Ler mais »

Failover Clustering (II)

O mecanismo de failover

No cluster, os recursos partilhados podem ser vistos por todos os computadores, ou nós. Cada nó detecta automaticamente se outro nó no cluster falhou e os processos em execução no nó que falhou continuam a ser executados num que fica operacional. Para o utilizador, o failover é normalmente transparente. Retratado na figura seguinte está um cluster de dois nós em que ambos têm discos locais e existem recursos partilhados disponíveis para ambos os computadores. A ligação de heartbeat permite que os dois computadores comuniquem e detecta quando um falha; se o Nó 1 falhar, o software do cluster irá transferir todos os serviços de forma transparente para o Nó 2.
 

 
O serviço do Windows associado ao serviço de cluster, chamado Cluster Service, tem alguns componentes:

• Processador de eventos;
• Gestor de Base de Dados;
• Gestor de Nó;
• Actualizador Geral;
• Gestor de Comunicações;
• Gestor de Recursos ou de Failover.

O gestor de recursos comunica directamente com um monitor de recursos que utiliza uma DLL específica que torna uma aplicação apropriada para ser utilizada num cluster (cluster-aware). O gestor de comunicações fala directamente com o Winsock do Windows (um componente do nível de rede do Windows).
 
O processo de failover é o seguinte:

Ler mais »