Como utilizar o laboratório de virtualização (II)

Retomando o trabalho onde o deixei, era altura de fazer algumas alterações. O primeiro passo foi a criação de uma outra MV no Hyper-V com o fim de ser utilizada como armazenamento iSCSI alternativo. Consegui isto instalando o Microsoft iSCSI Target 3.3 numa nova MV Server 2008 R2 x64. Criei esta MV com dois ficheiros .vhd; um para o SO e outro para o armazenamento iSCSI e vou agora mostrar os passos necessários para criar e adicionar três novos discos iSCSI ao cluster.
Criação do iSCSI Target:

Ler mais »

Como configurar um laboratório de virtualização (III)

Redes no failover cluster

O primeiro passo na instalação do failover cluster é a criação de um domínio visto que todos os nós que integram o cluster têm que pertencer ao mesmo domínio. E antes de fazer isto, voltei a alterar a configuração de rede de todas as MV de modo a adaptá-las a um melhor funcionamento neste novo ambiente.

LAB-DC:IP: 192.168.1.10
Gateway: 192.168.1.1 (Router Físico)
DNS: 127.0.0.1
DNS Alternativo: 192.168.1.1

LAB-NODE1:
IP: 192.168.1.11
Gateway: 192.168.1.1
DNS: 192.168.1.10 (DC)
DNS Alternativo: 192.168.1.1 (Router Físico)

LAB-NODE2:IP: 192.168.1.12
Gateway: 192.168.1.1
DNS: 192.168.1.10
DNS Alternativo: 192.168.1.1

LAB-NODE3:
IP: 192.168.1.13
Gateway: 192.168.1.1
DNS: 192.168.1.10
DNS Alternativo: 192.168.1.1

LAB-STORAGE:IP: 192.168.1.14
Gateway: 192.168.1.1
DNS: 192.168.1.10
DNS Alternativo: 192.168.1.1

Assim, fiquei com um domínio com 5 máquinas; um controlador e dois servidores como MVs do Hyper-V, um servidor como MV do VMware e outro servidor como MV do VirtualBox.

Até aqui já demonstrei que é possível integrar na mesma infra-estrutura servidores virtualizados sobre diferentes plataformas e técnicas de virtualização porque neste caso temos MVs em hipervisores de Tipo 1 (Hyper-V) e de Tipo 2 (VMware Workstation e VirtualBox).

A opção pela criação de uma rede com IP estático é tão válida quanto a da utilização do DHCP. Mais à frente irei explorar as potencialidades de rede dos clusters em Windows 2008 mas por agora mantive a rede assim e continuei a instalação do laboratório.

Ler mais »

Como configurar um laboratório de virtualização (II)

Tal como referi no final do meu anterior artigo, continuei a instalação do meu laboratório com a criação de máquinas virtuais no PC desktop. Mas desta vez utilizei o VMware e o VirtualBox para explorar a possibilidade de utilizar um conjunto de servidores virtualizados através de tecnologias de virtualização diferentes e rivais.

Insisti no detalhe de configuração das redes porque essa é a base do todo o trabalho que se segue; uma máquina virtual isolada pode ser importante mas eu quero mostrar como elas podem trabalhar em conjunto e, por isso mesmo, a configuração correcta das redes é de grande importância.

Importar uma Máquina Virtual para o VMware

Comecei por instalar uma MV no VMware Workstation. Ou melhor, aproveitei o trabalho que já tinha feito e utilizei o ficheiro .vhd generalizado com o sysprep, que tinha guardado. Uma vez que o VMware não suporta directamente a utilização de ficheiros .vhd foi necessário converter o ficheiro em causa do formato utilizado pelo Hyper-V (Virtual Hard Disk, ou seja, .vhd) para o formato utilizado pelo VMware (Virtual Machine Disk, ou seja, .vmdk).

O utilitário gratuito VMware vCenter Converter Standalone, que se pode obter directamente a partir do site oficial da VMware, não resolve o problema visto que não faz este tipo de conversão, embora possa converter a partir de outros formatos e até directamente a partir de servidores de Hyper-V a funcionar. Mas o que me interessava era utilizar a trabalho que já tinha realizado e por isso recorri à ferramenta WinImage.

O processo foi simples:

Seleccionei a opção correcta a partir do menu Disk e seleccionei o ficheiro de origem;

Ler mais »

Como configurar um laboratório de virtualização (I)

Agora que terminei a explicação do panorama geral da maior parte da teoria relacionada com Alta Disponibilidade e Virtualização é altura de começar a testar alguns desses conceitos e vê-los em acção.

O meu objectivo para os próximos artigos é produzir uma série de guias mostrando como qualquer pessoa pode facilmente instalar um punhado de máquinas virtuais e explorar as possibilidades maravilhosas fornecidos por esta tecnologia. Eu vou usar um velho laptop com uma CPU Turion 64 X2 CPU, um disco SSD de 250 Gb e 4 Gb de RAM combinado com um desktop com o Windows 7 num Athlon 64 X2 4800 + com 4 Gb de RAM e muito espaço livre em disco espalhado por três discos rígidos SATA.

Criação das Máquinas Virtuais

Não vou perder tempo com os detalhes da instalação do sistema operativo porque estou a assumir que os leitores destes artigos estarão muito à frente dessa fase.

Comecei por instalar uma nova cópia do Windows Server 2008 R2 SP1 Standard numa partição secundária no meu laptop. Uma vez concluída a instalação de todas as actualizações disponíveis no Windows Update e a activação do sistema operativo, estava pronto para adicionar a função Hyper-V, a fim de ser capaz de instalar as máquinas virtuais (MVs). Para isso bastou ir ao Server Manager/Roles, iniciar o Add Roles Wizard, seleccionar Hyper-V e seguir os procedimentos. Nada de especial até agora, certo?


Nota: Todas as imagens são clicáveis e vão abrir uma versão maior numa janela separada.

Ler mais »

Virtualização (II)

Virtualização de Redes

Quando pensamos em virtualização de redes, pensamos sempre em VLANs, mas há muito mais na virtualização de redes do que apenas VLANs. Virtualização de rede é quando todos os recursos separados de uma rede são combinados, permitindo que o administrador possa partilhá-los entre os utilizadores da rede. Assim, é um método de combinar os recursos disponíveis numa rede, dividindo-se a largura de banda disponível em canais, cada um dos quais é independente dos outros, e cada um dos quais pode ser atribuído (ou transferido) para um determinado servidor ou dispositivo em tempo real. Isso permite a cada utilizador aceder a todos os recursos de rede do seu computador sejam ficheiros e pastas no computador, impressoras ou discos rígidos, etc.

A teoria por trás da virtualização de rede é pegar em muitos dos tradicionais serviços cliente/servidor e colocá-los "na rede". Determinados fornecedores anunciam a virtualização e a colocação na rede como um veículo para serviços adicionais e não apenas como uma forma de agregar e alocar recursos de rede. Por exemplo, é prática comum os routers e switches suportarem segurança, armazenamento, voz sobre IP (VoIP), mobilidade e entrega de aplicações.

Um fornecedor de redes tem um cartão que é inserido num router. No cartão está um servidor Linux plenamente funcional que tem uma ligação com o backbone do router. No servidor Linux, podemos instalar aplicações como sniffers, VoIP, aplicações de segurança, e muitas mais.

A virtualização de rede fornece uma camada de abstracção que separa os dispositivos físicos de rede de sistemas operativos, aplicações e serviços prestados através da rede, permitindo que eles sejam executados num único servidor ou que desktops sejam executados como máquinas virtuais em centros de dados seguros, criando uma infra-estrutura mais ágil e eficiente. Esta abordagem simplificada torna a vida do administrador de redes muito mais fácil, e faz o sistema parecer muito menos complicado para o olho humano do que realmente é.

A virtualização de rede é uma tecnologia versátil. Permite que se combinem várias redes numa única rede lógica, se separe uma única rede em várias redes lógicas e até mesmo criar redes só de software entre máquinas virtuais (VMs) num servidor físico. Virtualizar redes normalmente começa com software de rede virtual, que é colocado fora de um servidor virtual (externa) ou dentro de um servidor virtual - dependendo do tamanho e tipo da plataforma de virtualização.

Ler mais »

Alta Disponibilidade – Redes (II)

Protocolos Redundantes

Se leu os artigos anteriores a sua rede já tem ligações redundantes e portanto resta agora decidir como irão os pacotes seleccionar os caminhos na rede de forma a evitar loops. Isto não é um problema novo; caminhos redundantes foram abordados por protocolos como o Spanning Tree Protocol (STP) na camada 2 e protocolos de endereçamento como o Open Shortest Path First ( OSPF) na Camada 3. Mas esses protocolos podem levar 40 segundos ou mais para convergir e isto é inaceitável para redes críticas, especialmente aquelas com aplicações em tempo real, como VoIP e vídeo.

O STP é um protocolo de gestão de ligações (comutação) que fornece redundância de caminhos, evitando loops indesejáveis na rede. Para uma rede Ethernet funcionar correctamente, apenas pode existir um caminho activo entre duas estações. Este protocolo deve ser utilizado em situações onde se querem ligações redundantes, mas não loops. Ligações redundantes são tão importantes como backups em caso de falha numa rede. Uma falha do router principal activa as ligações de backup para que os utilizadores possam continuar a usar a rede. Sem STP nas bridges e switches, tal falha pode resultar num loop.

Para fornecer redundância de caminhos, o STP define uma árvore de ligações que abarca todos os switches numa rede e força determinados caminhos redundantes a ficarem em estado de espera (bloqueados). Se um segmento de rede no protocolo STP se tornar inacessível, ou se o STP alterar os custos dessa ligação, o algoritmo spanning-tree reconfigura a topologia da árvore de ligações e restabelece a ligação activando um dos caminhos em espera.

Uma versão actualizada do STP é o chamado RSTP (Rapid Spanning Tree Protocol) que reduz o tempo de convergência do STP para cerca de um segundo. Uma das desvantagens deste RSTP (e do STP) é que apenas uma das ligações redundantes pode ser colocada em "espera activa", outra é que quando o STP muda o caminho activo para outro router, então os endereços de gateway dos clientes também têm que mudar.

Para evitar esses problemas, deve ser utilizado o Virtual Router Redundancy Protocol (VRRP) em conjunto com o STP ou o RSTP nos routers, que simula um endereço virtual de encaminhamento para os routers principais e leva cerca de três segundos para fazer o failover.A vantagem de usar VRRP é que se ganha uma maior disponibilidade para o caminho padrão, sem necessidade de configuração de protocolos de encaminhamento dinâmico ou de descoberta de routers em cada host.

Os routers VRRP vistos como um "grupo de redundância" partilham a responsabilidade do encaminhamento de pacotes, como se fossem proprietários do endereço IP correspondente ao gateway padrão configurado nos hosts. Um dos routers VRRP actua como mestre e os outros como backups; se o router mestre falhar, um dos backups torna-se o novo mestre. Desta forma, a redundância do router é sempre garantida, permitindo que o tráfego na rede local seja encaminhado sem depender de um único router.

Mas como o VRRP e o RSTP trabalham de forma independente, é possível que o VRRP designe um router como mestre e o RSTP determine que o caminho para o router de backup é o caminho preferencial. No pior caso, isto significa que se o router backup receber tráfego, vai enviá-lo imediatamente para o router mestre para processamento, acrescentando assim um router ao caminho.
O Common Address Redundancy Protocol (CARP) é uma melhoria sobre o VRRP e é também uma ferramenta para ajudar a criar redundância, por ter vários computadores a criar uma única interface de rede virtual entre eles, de modo que se qualquer máquina falhar, o outro pode responder em vez disso, permitindo ainda um grau de partilha de carga entre os sistemas.

Ler mais »

Alta Disponibilidade – Redes (I)

Dispositivos redundantes

 
As redes actuais são de alta tecnologia e, na maioria dos casos, de alta velocidade. Todos os projectos de WAN (Wide Area Network) necessitam ter uma ligação alternativa em caso de qualquer tipo de falha na ligação principal. Um cenário simples será o de ter uma única ligação T1 para cada escritório remoto ou filial se ligar à sede da empresa. E se essa ligação cair? Como continuar as operações nessas circunstâncias?
 
Criação de redundância é a forma mais comum de aumentar a disponibilidade. Primeiro devemos garantir que há redundância no núcleo do router; CPUs redundantes, fontes de alimentação e ventoinhas podem ser adicionados aos routers e switches montados em rack. Com CPUs redundantes pode-se forçar um failover numa placa enquanto se actualizar a segunda, ao invés de ter que desligar completamente o router para efectuar a actualização.
 
O objectivo das topologias redundantes é eliminar as interrupções da rede causadas por um único ponto de falha. Todas as redes necessitam de redundância para maior fiabilidade e isto é conseguido através de um equipamento fiável e projectos de rede que são tolerantes a falhas e defeitos e as redes devem ser projectadas de modo a convergirem rapidamente contornando a falha.
 
A redundância de rede é um conceito simples de entender; se existir um ponto único de falha e ele falhar, então não há nada a fazer. Se forem colocados métodos de acesso secundários (ou mesmo terciários), então, quando a principal ligação falhar, existirá uma forma alternativa de interligar os recursos e manter a empresa operacional.
 
O ponto crítico é que os equipamentos de rede altamente fiáveis são caros porque são projectados para não falharem e isso geralmente inclui coisas como duas fontes de energia, os CPUs de reserva e sistemas de disco redundantes.
 
Um sistema altamente disponível pode ser construído a partir de produtos de rede menos caros mas esses componentes podem não ter as fontes de alimentação redundantes ou outras características dos equipamentos de alta fiabilidade e, portanto, eles podem falhar com mais frequência do que os equipamentos mais caros. No entanto, se o projecto da rede geral tiver em consideração o facto de que o equipamento pode falhar, então o utilizador final ainda será capaz de aceder à rede, mesmo se algo falhar.
 

Ler mais »

Alta Disponibilidade – Soluções

Todas as grandes empresas estão actualmente sob crescente pressão para manterem os seus sistemas a funcionar de modo a disponibilizarem os seus dados e serviços continuamente. Assim, sendo os padrões de exigência para a disponibilidade cada vez mais elevados, a solução passa por projectar sistemas de armazenamento e servidores altamente disponíveis e quase à prova de balas contra a inactividade não planeada.
 
A fim de atingir os mais altos níveis de disponibilidade, uma empresa tem que implementar uma solução completa que cubra todos os possíveis pontos de falha. Mas quais são as opções disponíveis para criar uma solução de alta disponibilidade?

Podem ver no gráfico as principais soluções para as três áreas a ser abordadas, armazenamento, serviços e redes:
 

Nos próximos artigos vou explicar estas soluções em detalhe. Continuem a ler ok?

Alta Disponibilidade–Medição (II)

Parâmetros da Fiabilidade

Taxa de falhas

A fiabilidade pode ser quantificada em termos do Tempo Médio Entre Falhas (MTBF), para um produto reparável, ou em termos do Tempo Médio Para Falhas (MTTF) para um produto não reparável.

Segundo a teoria que suporta a estatística dos intervalos de confiança, a média estatística torna-se o valor médio real à medida que aumentamos o número de amostras. Assim, dizer que uma fonte de alimentação tem um MTBF de 50.000 horas não significa que essa fonte deve durar uma média de 50.000 horas, porque o MTBF de 50.000 horas, ou um ano para 1 fonte, torna-se 50.000/2 para duas fontes e 50.000/4 para quatro fontes. Somente quando todas as fontes falharem com a mesma falha é que o valor do MTBF converge para MTTF.
Se o MTBF é conhecido, pode calcular-se a taxa de falha (l) como o inverso do MTBF. A fórmula para l é:   


Uma vez calculado o MTBF, qual é a probabilidade de que qualquer dispositivo em particular esteja operacional no intervalo de tempo igual ao MTBF? Para componentes electrónicos, temos a seguinte equação:
 
  

Mas quando t = MTBF   
 
  
Isto diz-nos que a probabilidade de qualquer dispositivo em particular sobreviver ao seu MTBF é calculada apenas em 36,8%, ou seja, há 63,2% de probabilidade que um único dispositivo avarie antes do MTBF!

Ler mais »

Alta Disponibilidade - Medição (I)

Medida da disponibilidade

A necessidade de disponibilidade é regida pelos objectivos do negócio e os principais objectivos da sua quantificação são os seguintes:

• Fornecer e manter um referencial de disponibilidade (baseline);
• Ajudar a identificar onde melhorar os sistemas;
• Monitorizar e controlar projectos de melhoria.

A evolução tecnológica dos últimos anos tornou possível que a maioria dos sistemas possa atingir 90% de disponibilidade com pouco mais que alguma redundância e disciplina no departamento de TI, em vez de qualquer hardware ou software específicos para atingir esse objectivo. Porém, para atingir mais de 90% de disponibilidade do sistema, há que ter em conta algumas considerações especiais e nós vamos olhar para isso nos próximos posts.
É importante reconhecer que números como estes podem ser difíceis de alcançar uma vez que é necessário algum tempo para a recuperação de interrupções. A duração do tempo de recuperação correlaciona-se com os seguintes factores:

• Complexidade do sistema: Quanto mais complicado for o sistema, mais tempo levará a ser reiniciado o que significa que as interrupções que exigem desligar e reiniciar o sistema podem afectar drasticamente a sua capacidade de atingir uma desafiadora meta de disponibilidade. Por exemplo, aplicações a ser executadas num servidor de grande porte podem demorar até uma hora só para reiniciar quando o sistema foi desligado normalmente, e mais ainda se o sistema foi encerrado de forma anormal e houver necessidade de recuperar dados e ficheiros;

• Gravidade do problema: Geralmente, quanto maior a gravidade do problema, mais tempo é necessário para resolvê-lo totalmente, incluindo a recuperação de dados ou trabalho perdidos;

• Disponibilidade de pessoal de apoio: Consideremos que a interrupção ocorre após o expediente. Uma pessoa de apoio que seja chamada fora de horas poderá facilmente demorar uma ou duas horas só para diagnosticar o problema;

• Outros factores: Muitos outros factores podem impedir a resolução imediata de uma interrupção. Às vezes, uma aplicação pode sofrer uma interrupção simplesmente porque não suporta que o sistema seja desligado enquanto está a ser executada. Outros casos podem envolver a falta de hardware de substituição pelo fornecedor do sistema, ou mesmo a falta de pessoal de apoio.

Parâmetros da Disponibilidade

• Tempo Médio para Reparação (MTTR)
• Defeitos por Milhão (DPM)
• Tempo Médio entre Falhas (MTBF)
• Desempenho (por exemplo, latência, quebras de serviço)

A disponibilidade é geralmente expressa como uma percentagem de tempo de actividade num determinado ano. A tabela a seguir mostra o tempo de inactividade que será permitido para uma determinada percentagem de disponibilidade, partindo do pressuposto que o sistema opera continuamente. Os níveis de serviço acordados referem-se geralmente aos tempos de inactividade ou disponibilidade mensais de modo a calcular os créditos de serviço para combinar com os ciclos de facturação mensal. A tabela mostra a equivalência entre uma dada percentagem de disponibilidade e o correspondente tempo que um sistema estaria disponível por ano, mês ou semana.

Ler mais »

Alta Disponibilidade – Objectivos

O principal objectivo na criação de qualquer estratégia de Alta Disponibilidade (AD) e Recuperação de Desastres (RD) é garantir a continuidade do negócio (Business Continuity). Cada empresa tem o seu próprio nível de tolerância a falhas do sistema e interrupções de serviço e é exactamente em função dessa mesma tolerância que pode ser planeada e implementada uma estratégia adequada. Se uma empresa pode aceitar uma disponibilidade do sistema de 90%, então não há necessidade de construir uma infra-estrutura de alta disponibilidade.

Embora as soluções de AD sejam mais frequentemente discutidas em ambientes empresariais, estas considerações aplicam-se a qualquer tipo de organização em que a AD seja necessária, independentemente de ser na área educacional, sem fins lucrativos ou mesmo no âmbito da defesa. Quando se trata de organizações sem uma perspectiva comercial, não é muito fácil calcular os custos associados à inactividade e assim os sistemas de AD e RD nestas organizações tornam-se mais uma exigência do ponto de vista do serviço sem estarem necessariamente relacionados com custos associados à inactividade.

A disponibilidade dos sistemas deve ser vista sob a perspectiva do utilizador final. Cada vez que um utilizador não se conseguir ligar ao sistema é considerado como tempo de inactividade mas isto não significa necessariamente que o servidor central está em baixo porque, em muitos casos, um sistema com muito baixo desempenho também é considerado um sistema indisponível.

Assim, alta disponibilidade não implica apenas criar redundância num único sistema, base de dados ou aplicação, mas sim combinar várias redundâncias em todas as áreas do processo. Para cada negócio ou organização, as bases de dados têm um papel importante, tudo é construído em torno delas, portanto, a maioria dos esforços para alta disponibilidade estão orientados de forma a tornar a base de dados "altamente disponível."
Mais especificamente, uma arquitectura de alta disponibilidade deve ter as seguintes características:

• Tolerar falhas para que o processamento continue ininterruptamente ou apenas com interrupções mínimas;
• Ser transparente ou tolerante a alterações de sistema, dados ou aplicações;
• Conter medidas preventivas embebidas na própria arquitectura;
• Proporcionar monitorização proactiva e rápida detecção de falhas;
• Possibilitar recuperabilidade rápida;
• Automatizar operações de detecção e recuperação;
• Proteja os dados de modo a minimizar ou anular completamente a perda de dados;
• Implementar as melhores práticas operacionais para a gestão de toda a infra-estrutura;
• Alcançar os objectivos estabelecidos nos níveis de serviço estabelecidos (por exemplo, o RTO e o RPO) pelo menor custo possível.

Os projectistas de sistemas habitualmente introduzem fiabilidade nas suas arquitecturas através da implementação de mecanismos de correcção para os defeitos latentes que os preocupam. Estes defeitos, quando corrigíveis, não produzem erros ou falhas, uma vez que fazem parte das margens de segurança incorporadas no sistema. Ainda assim, devem ser monitorizados para medir a sua ocorrência real em relação aquilo que foi antecipado, uma vez que a ocorrência excessiva de alguns defeitos corrigíveis é frequentemente um indicador de um defeito latente potencialmente mais catastrófico.

Fiabilidade, recuperabilidade, detecção atempada de erros e a capacidade de operação contínua são as principais características de uma solução altamente disponível.

Alta Disponibilidade –Terminologia (II)

Interrupção planeada

Interrupções planeadas incluem a manutenção, backups offline e actualizações. Estas muitas vezes podem ser agendadas fora dos períodos de alta disponibilidade, quando é necessário.

 

Interrupções não planeadas

Embora as interrupções planeadas sejam um mal necessário, uma interrupção não planeada pode ser um verdadeiro pesadelo para um negócio. Dependendo do negócio em questão e da duração do tempo de inactividade, uma interrupção não planeada pode resultar em perdas tão avassaladoras que a empresa seja forçada a fechar. Independentemente da sua natureza, as interrupções são algo que as empresas normalmente não toleram. Há sempre pressão sobre a TI para eliminar totalmente estas paragens não planeadas e de reduzir drasticamente, se não eliminar, o tempo de inactividade planeado.

Note-se que uma aplicação ou sistema de computador não precisa estar totalmente em baixo para se considerar inactivo. É possível que o desempenho de uma aplicação se degrade de tal forma que é inútil. Do ponto de vista do utilizador empresarial ou final está em baixo, embora esteja disponível.

As paragens não planeadas podem ter várias causas e podem ser categorizadas em:

• Falhas de Hardware - Falha de componentes principais sistemas, tais como processadores e memória ou periféricos, discos, controladores de disco, placas de rede, ou equipamentos auxiliares, tais como módulos de alimentação e ventiladores, e equipamentos de rede, como switches, hubs, cabos, etc, podem ser as causas de falhas de hardware.

•  Falhas de Software - As possibilidades de falha de software dependem principalmente do tipo de software utilizado. Uma das principais causas de falha de software é aplicar um patch. Às vezes, se um patch não corresponde ao tipo de aplicação, o software aplicacional pode começar a comportar-se de maneira estranha, trazendo para baixo a aplicação e revertendo as alterações, se possível. Às vezes, uma actualização também pode causar um problema. Os principais problemas com as actualizações serão relacionados com o desempenho ou o comportamento inadequado de qualquer produto de terceiros, que depende dos upgrades.

• Erros Humanos - Uma acção acidental de qualquer utilizador pode causar uma falha grave no sistema. Apagar um ficheiro necessário, apagar os dados ou uma tabela, actualizando a base de dados com um valor errado, etc, são alguns exemplos.

 

Ler mais »

Alta Disponibilidade - Terminologia (I)

Alguns dos termos foram traduzidos de forma livre numa tentativa de transmitir as correctas noções que lhe estão subjacentes. Noutros casos, embora tenham sido traduzidos os significados, as siglas mantêm-se no inglês porque é sempre assim que surgem na literatura especializada.

Sistema

Um sistema é composto por uma colecção de componentes interactivos. Um componente pode ele próprio ser um sistema, ou pode ser apenas um componente singular. Os componentes são o resultado da decomposição do sistema, principalmente motivada para assistir na separação de sistemas complexos por razões técnicas, ou muitas vezes, por razões organizacionais ou de negócios. A decomposição de sistemas em componentes é um exercício recursivo e os componentes são geralmente delineados pela especificação cuidadosa das suas entradas e saídas.

Serviço

Um sistema fornece um ou mais serviços aos seus consumidores. Um serviço é a saída de um sistema que corresponde à especificação para a qual o sistema foi elaborado, ou que está de acordo com a percepção que os utilizadores do sistema têm de quais devem ser os valores correctos.

Falha

Uma falha num sistema ocorre quando o consumidor (humano ou não humano) de um serviço é afectado pelo facto de o sistema não ter entregue o serviço esperado. As falhas são resultados incorrectos em relação a uma especificação ou um comportamento inesperado percebido pelo consumidor ou utilizador de um serviço. A causa de uma falha é considerada um defeito.

Tempo Médio Para Falha

A fiabilidade do hardware pode ser prevista pela análise estatística dos dados históricos. Quanto mais tempo um componente funciona, mais é provável que falhe devido ao envelhecimento. O Tempo Médio Para Falha (Mean Time to Failure - MTTF) de um componente é apenas isso: uma previsão estatística que mede o tempo médio entre falhas assumindo um modelo teórico no qual o sistema que falhou não é reparado. Quanto maior o MTTF de um componente, menos provável é a sua falha. O MTTF de um componente (se for conhecido) pode usar como informação útil para o estabelecimento de procedimentos de manutenção preventiva e o seu valor global num sistema pode ser melhorado através de uma cuidadosa selecção de hardware e software.

O MTTF é o número total de horas de serviço de todos os dispositivos dividido peolo número total de dispositivos.

Ler mais »

Alta Disponibilidade - Introdução

Definição de Alta Disponibilidade

Alta Disponibilidade (AD) é a capacidade de um sistema para executar a sua função de forma contínua (sem interrupção) por um período de tempo significativo e superior ao que a fiabilidade dos seus componentes individuais poderia sugerir. Então, a AD é um equilíbrio entre o custo da inactividade e o custo das medidas de protecção que estão disponíveis para evitar ou reduzir o tempo dessa mesma inactividade.

O termo Alta Disponibilidade, quando aplicado a sistemas informáticos, significa que a aplicação ou serviço em questão está permanentemente disponível, independentemente da hora do dia, local ou outros factores que possam influenciar a disponibilidade de tal recurso.

Em geral, a AD é a capacidade de continuar o serviço por períodos muito longos sem interrupções. Assim, AD é uma abordagem ao planeamento e implementação de sistemas e dos serviços a eles associados, que assegura um nível de desempenho operacional previamente combinado será cumprido durante um período de medição contratual.

Os sistemas de AD devem proteger as empresas de dois tipos de possíveis falhas: falhas no sistema e falhas do site. Embora as verdadeiras soluções AD devam proteger contra estes dois tipos de falhas, os sistemas AD são normalmente considerados como os que tratam da protecção contra as falhas no sistema, enquanto as falhas no site são normalmente tratadas por um sistema de Disaster Recovery (DR).

Ler mais »