Disponibilidade Descrição geral de alta disponibilidade

(1)

IBM i

Disponibilidade

Descrição geral de alta disponibilidade

7.1

(2)

(3)

IBM i

Disponibilidade

Descrição geral de alta disponibilidade

7.1

(4)

Nota

Antes de utilizar estas informações e o respectivo produto suportado, leia as informações em “Avisos”, na página 37.

Esta edição é referente ao IBM i 7.1 (número de produto 5770-SS1) e a todas as edições e modificações

subsequentes, salvo indicação em contrário em novas edições. Esta versão não é executada em todos os modelos de computador de conjunto de instruções reduzido (RISC) nem em modelos CISC.

(5)

Índice

Descrição geral da Alta Disponibilidade

1

Novidades do IBM i 7.1 . . . 1

Ficheiro PDF de descrição geral da Alta Disponibilidade . . . 2

Vantagens da alta disponibilidade . . . 3

Desactivações planeadas . . . 3

Desactivações não planeadas . . . 4

Recuperação de desastres . . . 5

Redução da duração da cópia de segurança . . . 5

Balanceamento de carga . . . 7

Componentes da alta disponibilidade . . . 7

Resiliência de aplicações . . . 8

Resiliência de dados . . . 9

Resiliência do ambiente . . . 13

Simplicidade . . . 14

Critérios de alta disponibilidade . . . 15

Orçamento . . . 15

Requisitos de tempo de actividade. . . 15

Cobertura de desactivação . . . 16

Objectivo de tempo de recuperação (RTO) . . . 17

Objectivo de ponto de recuperação (RPO) . . . 17

Requisitos de resiliência . . . 17

Mudança de recurso e comutação automatizada 18 Requisitos de distância . . . 18

Número de sistemas de cópia de segurança . . 19

Aceder a uma cópia secundária de dados . . . 19

Desempenho do sistema . . . 20

Comparação do método de resiliência de dados 20 Seleccionar uma solução de alta disponibilidade do IBM i . . . 24

Níveis de resiliência de aplicações . . . 25

Comparação das tecnologias de resiliência de dados . . . 25

Gestão de alta disponibilidade . . . 30

Informações relacionadas com a descrição geral da Alta Disponibilidade . . . 34

Apêndice. Avisos . . . 37

Informações da interface de programação . . . . 39

Marcas comerciais . . . 39 Termos e condições . . . 39

Índice Remissivo . . . 41

|| | || || | || ||

(6)

(7)

Descrição geral da Alta Disponibilidade

Continuidade empresarial consiste na capacidade de um negócio em resistir suportar desactivações e

períodos de inactividade e garantir a operação normal dos serviços sem interrupção, de acordo com os acordos de nível de serviço predefinidos. Para assegurar um determinado nível de continuidade do negócio pretendido, é necessário seleccionar um conjunto de software, hardware e procedimentos, descritos num plano devidamente documentado, implementado e revisto regularmente. A solução de continuidade empresarial tem de processar os dados, o ambiente operacional, as aplicações, o ambiente do sistema central da aplicação e a interface de utilizador final. Todos os estes elementos têm de estar presentes para assegurar uma solução de continuidade empresarial fiável e completa.

A continuidade empresarial inclui a recuperação de desastres (DR) e alta disponibilidade (HA) e pode ser definida como a capacidade de suportar períodos de inactividade (planeados, não planeados e desastres) e proporcionar o processamento contínuo para todas as aplicações importantes. O principal objectivo é reduzir o tempo de inactividade e desactivação para menos de .001% do tempo total de serviço. Um ambiente de alta disponibilidade inclui geralmente objectivos de tempo de recuperação mais exigentes (segundos a minutos) e objectivos de ponto de recuperação mais exigentes (interrupção de utilizadores nula) quando comparado com um cenário de recuperação de desastres.

As soluções de alta disponibilidade fornecem mudança de recurso totalmente automatizada para um sistema de cópia de segurança que permite que os utilizadores e as aplicações continuem a trabalhar sem qualquer interrupção. As soluções HA têm de incluir a capacidade de assegurar um ponto de recuperação imediato. Da mesma forma, têm de assegurar uma funcionalidade de tempo de recuperação que seja bastante melhor do que o tempo de recuperação em vigor para a topologia de uma solução não HA.

Novidades do IBM i 7.1

Consulte estas novas informações da colecção de tópicos de descrição geral da Alta Disponibilidade

Detecção de falha de nó avançada

Os Serviços de recursos de conjunto de unidades do IBM®_{i podem agora utilizar uma partição de}

Consola de gestão de hardware (HMC) ou um Servidor E/S virtual (VIOS) para detectar uma eventual falha num nó de conjunto de unidades. Esta nova funcionalidade permite a identificação de mais cenários de falha e evita situações de partição de conjuntos de unidades.

Consulte Detecção de falha de nó avançada para obter informações adicionais sobre este tópico.

Modo de entrega assíncrona para replicação geográfica

O Modo de entrega assíncrona para Replicação geográfica suporta agora um novo modo de entrega que aumenta o valor máximo tolerado de latência (e, consequentemente, distância) para a maior parte das aplicações que utilizam a Replicação geográfica.

Consulte Características da replicação geográfica para obter informações adicionais sobre este tópico.

Comutação ao nível da unidade lógica

As unidades lógicas comutadas permitem que os dados armazenados no conjunto de unidades de disco independentes a partir de unidades lógicas criadas num IBM System Storage DS8000 ou DS6000 sejam comutados entre sistemas, assegurando a alta disponibilidade.

| | | | | | | | | | | | | | | | |

(8)

Consulte Características da unidade lógica comutada para obter informações adicionais acerca deste tópico.

Ficheiro PDF de descrição geral da Alta Disponibilidade

Pode visualizar e imprimir um ficheiro PDF com estas informações.

Para visualizar ou transferir a versão em PDF deste documento, seleccione Descrição geral da Alta

Disponibilidade (cerca de 415 KB).

Pode visualizar ou descarregar estes PDFs que incluem um conjunto de tópicos relacionados:

v _{Tecnologias de Alta Disponibilidade} _{(cerca de 580 KB) contém os seguintes tópicos:} – Tecnologia de conjunto de unidades

– Domínio administrativo de conjunto de unidades – Conjuntos de discos comutados

– Dispositivos comutáveis – Replicação entre sítios

- Replicação geográfica - Replicação metro - Replicação global – FlashCopy

– Gestão de alta disponibilidade

v _{Implementar Alta Disponibilidade} _{(cerca de 4.123 KB) contém os seguintes tópicos:} – Instalar o programa licenciado IBM PowerHA for i (iHASM) (5770-HAS)

– Desinstalar o programa licenciado IBM PowerHA for i (iHASM) (5770-HAS)

– Implementar alta disponibilidade com a abordagem baseada em soluções

– Implementar a alta disponibilidade com a abordagem baseada em tarefas – Gerir alta disponibilidade

– Resolução de problemas da alta disponibilidade

Guardar ficheiros PDF

Para guardar um PDF na estação de trabalho para visualização ou impressão: 1. Faça clique com o botão direito do rato na ligação de PDF no navegador. 2. Faça clique na opção que guarda o PDF localmente.

3. Navegue para o directório no qual pretende guardar o PDF. 4. Faça clique em Guardar.

Transferir o Adobe

®

Reader

Necessita de ter o Adobe Reader instalado no sistema para visualizar ou imprimir estes PDFs. Pode transferir uma cópia gratuita a partir do sítio da Web da Adobe

(www.adobe.com/products/acrobat/readstep.html) . |

(9)

Vantagens da alta disponibilidade

A alta disponibilidade protege as empresas contra a perda de lucros decorrente da interrupção do acesso aos seus recursos de dados e aplicações empresariais críticas.

O ponto de partida para a selecção de uma solução de alta disponibilidade consiste na identificação completa do conjunto de problemas de disponibilidade que está a tentar solucionar. Para continuidade empresarial, estes problemas podem ser agrupados em cinco grandes categorias.

Desactivações planeadas

A alta disponibilidade do IBM i pode reduzir o impacto nos seus clientes e utilizadores, sempre que for necessário desactivar os sistemas ou tornar os dados indisponíveis para realizar tarefas de manutenção necessárias, como por exemplo a realização de cópias de segurança nocturnas ou a instalação de novo hardware ou software.

À medida que o seu negócio cresce, torna-se cada vez mais importante assegurar a actividade contínua. A janela de manutenção dos seus sistemas pode diminuir de forma dramática. Os períodos de desactivação programada incluem actividades como a realização de cópias de segurança para banda, actualizações de aplicações e actualizações do sistema operativo, entre outras. Quantas horas por semana pode a sua aplicação estar indisponível, sem que isso represente um impacto negativo no seu negócio? As

desactivações planeadas são geralmente o evento mais comum para o qual é utilizada uma solução de alta disponibilidade.

A disponibilidade de sistema único do IBM i concentra-se sobretudo na manutenção simultânea de hardware e software e na redundância de hardware, mas existe um limite para o que pode ser feito ao nível de um sistema único. Utilizando as tecnologias de alta disponibilidade do IBM i, como conjuntos de unidades e conjuntos de discos independentes, pode comutar a produção para um segundo sistema ou ter disponível um segundo conjunto de unidades. Estas soluções de alta disponibilidade do IBM i

permitem que o seu negócio permaneça activo enquanto a manutenção do sistema é realizada. O impacto das desactivações não planeadas pode ser minimizado através da utilização destas soluções de alta disponibilidade.

Gravações offline em banda

As gravações em banda podem ser realizadas a partir de um sistema de cópia de segurança com uma segunda cópia dos dados do utilizador.

Correcções ou actualizações a aplicações e ao sistema operativo

É possível realizar uma actualização para permitir a instalação de correcções ou actualizações. As correcções podem ser aplicadas ao sistema de cópia de segurança enquanto o sistema principal executa o ambiente de produção. O volume de trabalho pode então ser comutado para o sistema de cópia de segurança e as correcções podem ser aplicadas ao sistema principal. Após a

conclusão da actualização, a produção pode ser novamente comutada para o sistema principal.

Manutenção de hardware

As alterações que não forem processadas pela manutenção simultânea de hardware requerem geralmente a desactivação do sistema. Possuir uma solução de alta disponibilidade permitirá que a produção seja comutada para um sistema de cópia de segurança e que a manutenção do hardware seja realizada sem qualquer impacto no negócio.

| | | | | | | | | | | | | | | | | | | | | |

(10)

Conceitos relacionados

“Cobertura de desactivação” na página 16

Qual o tipo de desactivação contra o qual pretende implementar protecção? Redução da duração da cópia de segurança, manutenção planeada, desactivações não planeadas ou desastres locais são eventos a considerar ao seleccionar uma solução de alta disponibilidade.

Informações relacionadas

Desactivações de redução planeadas

Desactivações não planeadas

As soluções de alta disponibilidade do IBM i podem assegurar protecção para desactivações não planeadas causadas por erro humano, problemas de software, falhas de hardware e problemas ambientais.

À medida que um negócio cresce, a protecção contra eventos não planeados torna-se cada vez mais importante. Infelizmente, os eventos não planeados não podem ser agendados. O requisito de alta disponibilidade do negócio deve concentrar-se no período de tempo mais importante para o seu negócio. O custo da desactivação no momento mais importante da actividade do seu negócio deve ser considerado no momento de escolher qual a melhor solução de alta disponibilidade a implementar e qual a melhor forma para o fazer.

As desactivações não planeadas pode ser categorizadas da seguinte forma:

Erro humano

Infelizmente, o erro humano é provavelmente o principal factor numa desactivação não planeada. Os procedimentos podem não ser seguidos de forma correcta, os avisos podem ser ignorados, poderá faltar formação ou poderão existir problemas de comunicação e ocorrer eventuais

mal-entendidos entre grupos de trabalho. Estes levam a desactivações não planeadas que afectam negativamente o seu negócio.

Problemas de software

As complexidades das aplacações do sistema operativo, middleware ou das bases de dados podem resultar em desactivações não planeadas. Cada negócio é único e os problemas de interacção entre diferentes componentes de software podem causar problemas.

Falha de hardware

Em algum ponto no tempo, os dispositivos mecânicos irão falhar. Os componente eléctricos estão sujeitos a alterações ambientais, como calor, humidade e descargas electrostáticas, as quais podem causar falhas prematuras. Podem ocorrer danos nos cabos e as ligações podem ficar inutilizadas.

Problemas ambientais

As falhas de alimentação, as falhas de rede e o ar condicionado podem fazer com que um sistema fique indisponível. Podem ser tomadas medidas redundantes para ajudar a lidar com estes problemas, mas existe um limite para o que pode ser feito.

A recuperação de desactivações não planeadas num ambiente de alta disponibilidade é efectuada através de mudança de recurso para um sistema de cópia de segurança. Enquanto o problema é diagnosticado e corrigido, o negócio pode manter-se em actividade no servidor de cópia de segurança.

| | | | |

(11)

Desactivações de redução não planeadas Desactivações de prevenção não planeadas

Recuperar alterações recentes após uma desactivação não planeada Recuperar dados perdidos após uma desactivação não planeada

Recuperação de desastres

A recuperação de desastres abrange o conjunto de recursos, planos, serviços e procedimentos a recuperar e retoma as aplicações fulcrais para a empresa num local remoto, na eventualidade de um desastre.

À medida que o seu negócio cresce, a recuperação de um desastre por bandas num local remoto poderá já não ser exequível dentro do tempo necessário definido para o seu negócio. Todas as localizações têm de preocupar com algum tipo de desastre, ainda que diferentes. Incêndios, tornados, cheias, terramotos e furacões são desastres naturais que podem afectar vastas áreas geográficas. Isto faz com que os locais remotos de desastre fiquem cada vez mais afastados. Em alguns casos, as normas industriais podem também determinar a distância mínima entre locais.

Algumas questões importantes a considerar na concepção de um sistema de recuperação de desastres: v _{Qual o impacto financeiro que um desastre poderia ter no negócio?}

v _{Quão rapidamente pode o negócio retomar a produção?} v _{Qual o ponto no tempo para o qual posso recuperar?}

v _{Qual a largura de banda em comunicações que posso manter?}

v _{Qual a solução de recuperação de desastres mais viável, com base nos meus requisitos de distância?}

As soluções de alta disponibilidade do IBM i podem ser concebidas em torno das respostas a estas perguntas. Isto pode significar tornar um único local mais robusto, contratar a utilização de uma máquina para restaurar bandas e assegurar a continuidade do negócio ou investir numa cópia de segurança activa e actualizada num local remoto, preparada para assumir o controlo da produção.

Planear recuperação de desastres Recuperar o seu sistema

Redução da duração da cópia de segurança

As soluções de alta disponibilidade do IBM i podem reduzir o tempo de inactividade do seu sistema ou dos seus serviços durante as cópias de segurança. O tempo que uma cópia de segurança demora a ser concluída é designado por duração da cópia de segurança. O desafio está em conseguir realizar a cópia de segurança de todos os elementos críticos dentro do período de tempo disponível.

As técnicas mais óbvias para reduzir ou eliminar a duração da cópia de segurança envolvem a

diminuição do tempo para realizar a cópia de segurança ou a diminuição do volume de dados copiados. Isto inclui o seguinte:

Tecnologias de banda melhoradas

As tecnologias de banda mais rápida e robusta podem reduzir o tempo total de cópia de segurança. | | | | | | | |

(12)

Salvaguarda em paralelo

Utilizando vários dispositivos de banda em simultâneo, pode reduzir o tempo de cópia de segurança eliminando ou reduzindo o processamento em série num único dispositivo.

Guardar em suportes não amovíveis

Guardar em suportes é mais rápido do que guardar em suportes amovíveis, por exemplo directamente no dispositivo de memória de acesso directo (DASD), pode reduzir a duração da cópia de segurança. Os dados podem ser migrados para suportes amovíveis numa altura posterior.

Arquivo de dados

Os dados não necessários para a produção normal podem ser arquivados e colocados offline. Serão colocados novamente online quando forem necessários, talvez para processamento no final do mês ou do trimestre. A duração da cópia de segurança diária é reduzida, uma vez que os dados arquivados já não estarão incluídos nos dados a copiar.

Guardando apenas os objectos alterados, as cópias de segurança diárias, não incluem objectos que não tenham sido alterados durante o dia.

A duração da cópia de segurança pode ser dramaticamente reduzida se a percentagem de objectos não alterados for relativamente alta.

Outras técnicas de redução da janela de cópia de segurança incluem a exploração de uma segunda cópia dos dados (real ou virtual). Estas técnicas incluem:

Guardar a partir de um segundo sistema

As tecnologias de resiliência de dados, como a replicação lógica, que disponibilizam uma segunda cópia dos dados, podem ser utilizadas para mudar a janela de cópia de segurança da cópia principal para a cópia secundária. Esta técnica pode eliminar a duração da cópia de segurança no sistema principal. Por este motivo, não afecta a produção, uma vez que o processamento da cópia de segurança é efectuado num segundo sistema.

Guardar enquanto activo

Num ambiente de sistema único, os dados são copiados utilizando o processamento de salvaguarda enquanto as aplicações permanecem em produção. Para garantir a integridade e capacidade de utilização dos dados, é alcançado um ponto de controlo que assegura uma coerência relativamente a esse ponto no tempo. As imagens do objecto no ponto de controlo são guardadas, permitindo que este objecto possa continuar a ser alterado. Os objectos guardados são coerentes entre si, de modo a que seja possível restaurar o ambiente da aplicação para um estado conhecido. A opção para guardar enquanto o objecto está activo pode também ser implementada numa cópia redundante, alcançada através da replicação lógica. A utilização desta técnica pode permitir que a janela de salvaguarda seja, efectivamente, eliminada.

IBM System Storage FlashCopy

Esta tecnologia utiliza a função IBM System Storage do FlashCopy numa base de conjunto de discos independente. É gravada uma imagem definida no tempo do conjunto de discos independente num único servidor do System Storage. A cópia do conjunto de discos

independente é efectuada no servidor do System Storage, e o sistema central não fica a par da cópia. A criação de conjuntos de unidades permite trazer a cópia para o sistema de cópia de segurança para a finalidade de cópias de segurança ou outro tipo de processamento offline. A criação de conjuntos de unidades permite também gerir o segundo sistema, trazendo-o para o conjunto de unidades de uma forma que não afecta o sistema. A criação de conjuntos de unidades suporta vários conjuntos de discos independentes do mesmo sistema ou de vários sistemas de produção anexados à unidade de armazenamento na mesma altura.

(13)

Descrição geral de replicação

Balanceamento de carga

As soluções de alta disponibilidade do IBM i podem ser utilizadas para balanceamento de carga. As tecnologias mais comuns para o balanceamento de carga envolvem a transposição de trabalho para recursos disponíveis. Em oposição, as técnicas de gestão de desempenho comuns envolvem a transposição de recursos que não atingem os objectivos de desempenho.

Alguns exemplos de tecnologias de balanceamento de volume de trabalho (cada uma com as suas implicações próprias ao nível de HA) são:

Encaminhadores principais

Estes encaminhadores processam todos os pedidos recebidos e utilizam um algoritmo para distribuir trabalho de forma mais uniforme através dos servidores disponíveis. Os algoritmos podem ser simples, como uma distribuição sequencial ou complexos, baseados no desempenho real medido.

Servidores de aplicação múltipla

Um utilizador distribui o trabalho com base numa configuração ou política predefinida através dos servidores de aplicação. Geralmente, a associação do solicitador ao servidor é relativamente estática, mas os solicitadores são distribuídos da forma mais uniforme possível através dos vários servidores.

Aplicação de várias partes distribuída

Estas aplicações funcionam em resposta a pedidos do utilizador final que circulam através de vários servidores múltiplos. A forma como o trabalho é distribuído é apresentada ao utilizador. Cada parte da aplicação realiza uma tarefa e, em seguida, passa o trabalho para o servidor seguinte, em sequência. O exemplo mais comum deste tipo de balanceamento do volume de trabalho consiste numa aplicação de três níveis com um servidor de base de dados de programa emissor.

Comutação de aplicação controlada

O trabalho é inicialmente distribuído de forma pré-determinada através de vários servidores. Um servidor pode alojar várias aplicações, várias ocorrências da mesma aplicação, ou ambas. Se um determinado servidor ficar sobrecarregado enquanto outros servidores estão em execução com capacidade em excesso, o pessoal de operações move as aplicações ou ocorrências de aplicações com dados associados do servidor sobrecarregado para o servidor com espaço de capacidade. A transposição do volume de trabalho pode ser manual ou automatizado, com base numa política pré-determinada.

Encaminhamento TCP/IP e equilíbrio do volume de trabalho Criar CRGs de par

Componentes da alta disponibilidade

A alta disponibilidade assegura o acesso a aplicações empresariais críticas e aos dados na eventualidade de uma interrupção do serviço. As soluções de alta disponibilidade do IBM i minimizam e, por vezes, eliminam o efeito de desactivações planeadas e não planeadas e desastres que afectem todo o local, para o seu negócio. A base para as soluções de alta disponibilidade do IBM i é a tecnologia de conjunto de unidades.

(14)

Um conjunto de unidades consiste em dois ou mais sistemas (ou imagens de sistema operativo) que partilham recursos e processamento e que fornecem cópia de segurança na eventualidade de uma

desactivação. Com os conjuntos de unidades, a alta disponibilidade é vista não como uma série de cópias idênticas do mesmo recurso em todos estes sistemas mas um conjunto de recursos partilhados que, continuamente, asseguram serviços essenciais a utilizadores e aplicações.

Os conjuntos de unidades não fornecem uma solução de alta disponibilidade completa apenas por si próprios, mas consistem na tecnologia principal em que se baseiam todas as soluções de alta

disponibilidade do IBM i. A infra-estrutura de conjunto de unidades, denominada serviços de recursos de conjuntos de unidades, fornece os mecanismos fundamentais para criar e gerir vários sistemas e

respectivos recursos com uma única entidade computacional unificada. Os conjuntos de unidades também monitorizam sistemas e recursos definidos no ambiente de alta disponibilidade para falhas e responde em conformidade, dependendo do tipo de desactivação. O conjunto de unidades combina hardware e software para reduzir o custo e os efeitos de desactivações planeadas e não planeadas através dos serviços de restauro na eventualidade destas desactivações. Embora isto não acontece

instantaneamente, o tempo de recuperação dos conjuntos de unidades é bastante rápido.

A secção seguinte define os componentes principais de uma solução de alta disponibilidade.

Tarefas relacionadas

“Seleccionar uma solução de alta disponibilidade do IBM i” na página 24

Após ter determinado os objectivos e requisitos do seu negócio, é necessário seleccionar a solução de alta disponibilidade do IBM i que melhor se adequa ao seu negócio.

Resiliência de aplicações

A resiliência de aplicações pode ser classificada pelo efeito no utilizador. Numa infra-estrutura de conjunto de unidades do IBM i, a resiliência de aplicações é controlada por um objecto de aplicação Cluster Resource Group (CRG). Este CRG assegura o mecanismo, utilizando um programa de saída, para controlar os processos de início, interrupção, reinício e comutação da aplicação para criar cópias de segurança dos sistemas. A totalidade do ambiente de aplicação, incluindo a replicação de dados e os dispositivos comutáveis, pode ser controlada através da infra-estrutura de conjunto de unidades como uma única entidade.

A resiliência de aplicações é classificada de acordo com as seguintes categorias.

Sem recuperação de aplicações

Após uma desactivação ou tempo de inactividade, os utilizadores têm de reiniciar manualmente as suas aplicações. Com base no estado dos dados, os utilizadores determinam o ponto em que pretendem reiniciar o processamento na aplicação.

Reinício automático de aplicações e reposicionamento manual em aplicações

As aplicações activas no momento de desactivação ou inactividade são automaticamente reiniciadas através do programa de saída CRG. O utilizador tem de determinar o ponto em que pretende retomar a aplicação, com base no estado dos dados.

Reinício automático de aplicações e recuperação semi-automática

Para além do reinício automático de aplicações, os utilizadores acedem a um “ponto de reinício” pré-determinado na aplicação. O ponto de reinício pode ser, por exemplo, um menu principal na aplicação. Este ponto é geralmente coerente com o estado dos dados da aplicação resiliente, mas o utilizador poderá necessitar de avançar na aplicação para fazer corresponder o estado dos dados. É necessário efectuar alterações à aplicação para guardar os dados de estado do utilizador. No início de sessão, a aplicação detecta o estado de cada utilizador e determina se é necessário efectuar a recuperação da aplicação desde o estado da última gravação.

Reinício automático da aplicação e recuperação automática da fronteira da última transacção

O utilizador é reposicionado na aplicação, no ponto de processamento coerente com a última transacção efectuada. Os dados da aplicação e o ponto de reinício da aplicação são

| | | | | | | | | | | | | | | | | |

(15)

correspondentes. Esta categoria requer alterações de código na aplicação para guardar estados do utilizador no final de cada ciclo de consolidação para que a aplicação reconheça o ponto em que cada utilizador se encontra, em caso de desactivação ou falha.

Resiliência de aplicação total com reinício automático e mudança de recurso transparente

Para além de ser reposicionado na última transacção consolidada, o utilizador continua a ver exactamente a mesma janela com os mesmos dados que estava a visualizar no momento da desactivação. Não existe qualquer perda de dados, não é necessário efectuar outro início de sessão e não há qualquer percepção de perda de recursos do servidor. O utilizador apenas sentirá algum atraso no tempo de resposta. Esta categoria pode apenas ser obtida numa aplicação com uma relação cliente/servidor.

“Requisitos de resiliência” na página 17

A empresa tem de identificar quais são os elementos que requerem protecção no caso do sistema central das aplicações sofrer uma desactivação. Os requisitos de resiliência consistem no conjunto de ambientes de aplicações, dados e sistemas necessários para preservar em caso de desactivação do sistema de produção. Estas entidades permanecem disponíveis durante uma mudança de recurso, mesmo que o sistema que as aloja sofra uma desactivação.

Níveis de resiliência de aplicações

A resiliência de aplicações pode ser personalizada para o nível de resiliência requerido pelo seu negócio, utilizando as funções do contexto de criação de conjuntos de unidades do IBM i.

Tornar os programas de aplicação resilientes Planear a resiliência de aplicações

Resiliência de dados

Pode utilizar várias tecnologias para endereçar os requisitos de resiliência de dados descritos na secção “Vantagens da alta disponibilidade”. Segue-se uma descrição de cinco tecnologias chave de resiliência de dados multissistema. Tenha em atenção que pode utilizar uma combinação de várias tecnologias para fortalecer ainda mais a sua resiliência de dados.

Replicação lógica

A replicação lógica consiste numa topologia de resiliência de dados multissistema geralmente

implementada para alta disponibilidade (HA) no espaço do IBM i. É geralmente implementada através de um produto fornecido pela IBM ou por um fornecedor independente de soluções de alta disponibilidade (ISV). A replicação é executada (através de métodos de software) em objectos. As alterações aos objectos (por exemplo, ficheiro, membro, área de dados ou programa) são replicadas numa cópia de segurança. A replicação é efectuada em tempo real ou muito próxima disso (registo em diário remoto sincronizado) para todos os objectos registados em diário. Normalmente, se o objecto, tal como um ficheiro, for registado em diário, a replicação é executada ao nível do registo. Para estes objectos, como espaços de utilizador que não são registados em diário, a replicação é processada geralmente ao nível do objecto. Neste caso, a totalidade do objecto é replicada após cada conjunto de alterações ao objecto estar completo.

A maior parte das soluções de replicação lógica permite mais funções, para além da replicação de

objectos. Por exemplo, pode conseguir obter funcionalidades de auditoria adicionais, observar o estado da replicação em tempo real, adicionar automaticamente novos objectos aos objectos a replicar e replicar apenas um subconjunto de objectos numa determinada biblioteca ou directório.

Para criar uma solução de alta disponibilidade (HA) multissistema eficiente e fiável utilizando a replicação lógica, é preferível utilizar a o registo em diário remoto síncrono como mecanismo de transporte. Com o registo em diário remoto, o IBM i move continuamente os dados mais recentes no receptor de diário para o receptor de diário do servidor de cópia de segurança. Neste ponto, é

implementada uma solução de software para “reproduzir” estas actualizações de diário, colocando-as no | | | | | | | | | | | | | | |

(16)

objecto no servidor de cópia de segurança. Após estabelecer este ambiente, existem dois objectos idênticos mas separados, um no servidor principal e outro no servidor de cópia de segurança.

Com esta solução implementada, pode rapidamente activar o seu ambiente de produção no servidor de cópia de segurança através de uma operação de mudança de funções. A imagem abaixo apresenta o funcionamento básico num ambiente de replicação lógica.

Uma vantagem crucial desta categoria de solução consiste no facto do ficheiro da base de dados de cópia de segurança ser processado em tempo real. Ou seja, é possível aceder a este ficheiro em tempo real para operações de cópia de segurança ou para tipos de aplicação só de leitura, como relatórios de criação. Adicionalmente, isso geralmente significa que é necessária uma recuperação mínima ao mudar para a cópia de segurança.

O principal desafio em relação a esta categoria de solução consiste na complexidade que pode estar envolvida na configuração e manutenção do ambiente. Um dos principais desafios reside na não monitorização restrita das alterações potencialmente não autorizadas das cópias activas de objectos que residem no servidor de cópia de segurança. A não insistência no cumprimento desta disciplina pode levar a algumas ocorrências em que os utilizadores e os programadores fazem alterações na cópia activa, pelo que esta deixa de corresponder à cópia de produção. Se isto acontecer, as versões principal e de cópia de segurança dos seus ficheiros já não serão idênticas.

Outro desafio associado a esta abordagem reside no facto dos objectos não registados em diário terem de ser processados através de um ponto de verificação, e depois enviados separadamente para o servidor de cópia de segurança. Por este motivo, a granularidade da natureza de tempo real do processo poderá ser limitada à granularidade do objecto de maior dimensões a replicar para uma determinada operação.

Por exemplo, um programa actualiza um registo que reside num ficheiro com registo de alterações. Como parte da mesma operação, também actualiza um objecto, como, por exemplo, um espaço de utilizador, que não tenha registo de alterações. A cópia de segurança torna-se completamente consistente quando o espaço de utilizador é totalmente replicado para o sistema de cópia de segurança. Em termos práticos, significa que se ocorrer uma falha no sistema principal e o objecto do espaço de utilizador não estiver totalmente replicado, é necessário um processo de recuperação manual para conciliar o estado do espaço de utilizador não registado em diário de modo a corresponder à última operação válida, cujos dados foram totalmente replicados.

Outro desafio possível associado a esta abordagem reside na latência do do processo de replicação. Isto refere-se ao tempo de desfasamento entre o momento em que são efectuadas alterações no sistema origem e o momento em que essas alterações se tornam disponíveis no sistema de cópia de segurança. O registo em diário remoto síncrono pode minimizar em grande medida este tipo de desfasamento.

Independentemente do mecanismo de transmissão utilizado, é necessário projectar de modo adequado o volume de transmissão e planear correctamente as linhas e velocidades de comunicação de modo a garantir a gestão dos volumes de replicação por parte do ambiente quando estes atingirem o valor máximo. Num ambiente com um volume elevado, a reprodução de encomendas em stock e a latência podem constituir um problema no lado destino, mesmo que as instalações de transmissão tenham sido correctamente planeadas.

Dispositivo comutável

Um dispositivo comutável consiste num conjunto de recursos de hardware, como unidades de disco, adaptadores de comunicações e dispositivos de banda que podem ser comutados de um sistema para outro. Para resiliência de dados, as unidades de disco podem ser configuradas numa classe especial de conjunto de memória auxiliar (ASP) independente de um determinado sistema central. O resultado prático desta arquitectura reside no facto da comutação de um conjunto de discos independentes de um sistema para outro envolver menos tempo de processamento do que um carregamento total de programa inicial (IPL). A implementação do IBM i de conjuntos de discos independentes suporta objectos de | | | | | | | | | | | | | | | | | | | | | | |

(17)

directório (como o sistema de ficheiros integrado (IFS)) e objectos da biblioteca (como ficheiros de base de dados). Isto é geralmente referido como discos comutados.

O benefício da utilização de conjuntos de discos independentes para resiliência de dados reside na sua simplicidade operacional. A única cópia de dados está sempre actualizada, o que significa que não existe outra cópia com a qual é necessário sincronizar. Não existem dados em curso que se possam perder, tais como os dados transmitidos de forma assíncrona, e o desempenho do tempo sistema é mínimo. A

mudança de funções ou a comutação são relativamente óbvias, embora possa ser necessário contabilizar o tempo necessário para activar o conjunto de discos independentes.

Outro benefício importante da utilização de conjuntos de discos independentes reside na latência de transmissão nula, que pode afectar qualquer tecnologia baseada na replicação. O principal esforço associado a esta solução envolve a configuração do dispositivo de armazenamento de acesso directo (DASD), dos dados e da estrutura da aplicação. É relativamente fácil comutar um conjunto de discos independentes.

As limitações estão também associadas à solução do conjunto de discos independentes. Em primeiro lugar, existe apenas uma cópia lógica dos dados que reside no conjunto de discos independentes. Este pode tratar-se do único ponto de falha, embora os dados devam ser protegidos através de RAID 5, RAID 6 ou replicação. Não é possível aceder aos dados em simultâneo a partir de ambos os sistemas centrais. Não é possível efectuar operações como o acesso de leitura ou a cópia de segurança para a banda a partir do sistema de cópia de segurança. Alguns tipos de objecto, como os objectos de configuração, não podem ser lidos num conjunto de discos independentes. É necessário outro mecanismo, como a gravação

periódica e operações de restauro, a criação de conjuntos de unidades de domínios lógicos ou a replicação lógica, para assegurar que estes objectos são mantidos de forma adequada.

Outra limitação envolve restrições associadas ao hardware. Alguns exemplos incluem limites de distância na tecnologia de rede em anel de Ligação de alta velocidade (HSL - High Speed Link) e desactivações associadas a determinadas actualizações de hardware. O conjunto de discos independentes não pode ser activado online num sistema anterior. Tendo isto em conta, o design e a análise antecipados do ambiente do sistema são essenciais.

Características da unidade lógica comutada (LUN)

As unidades lógicas comutadas permitem que os dados armazenados no conjunto de unidades

independentes a partir de unidades lógicas criadas num IBM System Storage DS8000 ou DS6000 sejam comutados entre sistemas, assegurando a alta disponibilidade.

Uma unidade lógica comutada consiste num conjunto de discos independentes controlado por um grupo de recursos de conjunto de unidades do dispositivo e pode ser comutada entre nós de um conjunto de unidades. Sempre que unidades lógicas comutadas são combinadas com tecnologia de conjunto de unidades do IBM i, pode criar uma solução de alta disponibilidade simples e com elevada eficiência de custos para desactivações planeadas e não planeadas.

O grupo de recursos de conjunto de unidades do dispositivo (CRG) controla o conjunto de discos independentes que pode ser automaticamente comutado em caso de uma desactivação não planeada, ou que pode ser manualmente comutado através de uma comutação.

Um grupo de sistemas num conjunto de unidades pode tirar partido da funcionalidade de comutação para mover o acesso ao conjunto de unidades lógico comutado de um sistema para outro. Uma unidade lógica comutável tem de estar localizada num IBM System Storage DS8000 ou DS6000 ligado através de uma rede de área de armazenamento. As unidades lógicas comutáveis operam de forma semelhante aos discos comutados, mas o hardware não é comutado entre as partições lógicas. Quando o conjunto de discos independentes é comutado, as unidades lógicas na unidade do IBM System Storage são novamente atribuídas de uma partição lógica para outra.

| | | | | | | | | | | | | | | | | | |

(18)

Replicação entre sítios (XSM)

Replicação geográfica

A replicação geográfica consiste numa função do sistema operativo do IBM i. Todos os dados colocados na cópia de produção do conjunto de discos independentes são replicados num segundo conjunto de discos independentes num segundo sistema, talvez remoto.

Os benefícios desta solução são essencialmente os mesmos da solução básica de dispositivos comutáveis, com a vantagem adicional de fornecer recuperação de desastres a uma segunda cópia, com uma distância potencialmente superior. O principal benefício continua a ser a simplicidade operacional. As operações de comutação são essencialmente as mesmas da solução de dispositivos comutáveis, excepto na medida em que pode comutar para a cópia de replicação do conjunto de discos independentes, fazendo desta uma solução de alta disponibilidade simples para implementar e trabalhar. Tal como acontece na solução de dispositivo comutável, os objectos que não se encontrem no conjunto de discos independentes têm de ser processados através de outro mecanismo e o conjunto de discos independentes não pode ser activado online num sistema anterior. A replicação geográfica permite também o suporte de replicação em tempo real para ambientes integrados de sistema central, como por exemplo o Microsoft®_Windows®_e

Linux®_{. Isto não é, geralmente, possível através da replicação lógica baseada em diário.}

Uma vez que a replicação geográfica é implementada como uma função do IBM i, uma potencial limitação da solução de replicação geográfica reside nos impactos de desempenho em

determinados ambientes de volume de trabalho.

Ao executar trabalhos por lotes intensivos de entrada/saída (E/S), é possível ocorrer alguma degradação do desempenho no sistema principal. Para além disto, tenha em atenção ao tempo sistema da unidade centra de processamento (CPU) necessário para suportar a replicação geográfica, e lembre-se de que a cópia de segurança do conjunto de discos independentes não pode ser acedida enquanto a sincronização de dados está a decorrer. Por exemplo, se pretender gravar a partir da cópia replicada geograficamente, é necessário definir as operações no sistema de origem e desanexar a cópia replicada. Em seguida, terá de activar a cópia desanexada no conjunto de discos independentes no sistema de cópia de segurança, executar o procedimento de de cópia de segurança e, em seguida, anexar novamente o conjunto de discos independente no sistema de central de produção. É então efectuada a sincronização dos dados alterados enquanto o conjunto de discos independente estava desanexado. A sua solução HA encontra-se exposta durante a realização da cópia de segurança e durante a sincronização, o que significa que não existe um segundo conjunto de dados actualizado. Utilizar o rastreio do lado de origem e destino irá minimizar esta exposição.

Replicação metro

A replicação metro consiste numa função do servidor do IBM System Storage. Os dados armazenados nos conjuntos de dados independentes encontram-se em unidades de disco localizadas no servidor do System Storage. Esta solução envolve a replicação ao nível do

hardware para um segundo servidor de armazenamento utilizando os Serviços de cópia do IBM System Storage. Um conjunto de discos independente consiste na unidade básica de

armazenamento para a função de Cópia remota "Peer-to-Peer" (PPRC) do System Storage. A função PPRC fornece replicação do conjunto de discos independente para outro servidor do System Storage. O IBM i fornece um conjunto de funções para combinar a função PPRC,

conjuntos de discos independentes e serviços de recursos de conjunto de unidades do IBM i para comutação coordenada e processamento de mudança de recurso através de um grupo de recursos de conjunto de unidades (CRG).

Possui também a capacidade de combinar esta solução com outras funções de serviços de cópia baseados no System Storage, incluindo FlashCopy, para redução da janela de gravação.

A transferência de dados da replicação Metro é efectuada de forma síncrona. É também

necessário estar atento às limitações de distância e requisitos de largura de banda associados aos tempos de transmissão, tal como em qualquer solução que utilize comunicações síncronas. | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |

(19)

Replicação global

A replicação global utiliza a mesma tecnologia de base da replicação Metro, excepto o facto da transmissão de dados ser efectuada de uma forma assíncrona e o facto de ser necessário

FlashCopy num terceiro conjunto de discos para manter a coerência dos dados. Uma vez que esta transmissão de dados é assíncrona, não existe limite para a distância e dispersão geográfica entre os servidores do System Storage.

“Comparação das tecnologias de resiliência de dados” na página 25

A resiliência de dados permite que os dados permaneçam disponíveis para aplicações e utilizadores, mesmo em caso de falha do sistema que aloja os dados. Optar pelo conjunto adequado de tecnologias de

resiliência de dados no contexto da estratégia de continuidade do seu negócio pode ser um processo complexo e difícil. É importante compreender as diferentes soluções de resiliência de dados que podem ser utilizadas para melhorar a disponibilidade em vários ambientes de sistema. Pode optar por uma única solução ou utilizar uma combinação destas tecnologias para ir ao encontro das suas necessidades. Os tópicos que se seguem comparam e diferenciam as diversas tecnologias de resiliência de dados disponíveis.

“Comparação do método de resiliência de dados” na página 20

Esta tabela proporciona uma breve descrição das principais características da solução que gera uma cópia dos dados no armazenamento auxiliar.

Planear a resiliência de dados

Resiliência do ambiente

A resiliência do ambiente pode ser dividida em duas secções, o ambiente físico e o ambiente lógico. O ambiente físico, que faz realmente parte da disponibilidade do sistema, concentra-se sobretudo em áreas como a redundância de hardware, a topologia de rede, a infra-estrutura de alimentação e as capacidades de refrigeração. O ambiente lógico diz respeito ao ambiente que aloja e executa aplicações. Inclui áreas como as definições do sistema, os perfis de utilizador e os atributos do sistema que permitem a um utilizador executar a aplicação em vários servidores.

Ambiente físico

O ambiente físico consiste em componentes de disponibilidade de sistema único e nos utilitários necessários para manter adequadamente um ambiente operativo de computação. Estes

componentes de disponibilidade de sistema único são fundamentais para manter um ambiente de alta disponibilidade. O sistema tem vários componentes para o proteger contra falhas de

hardware. O primeiro componente a proteger é o subsistema do disco. As tecnologias RAID 5, RAID 6 e replicação do disco asseguravam todas elas vários mecanismos de protecção. Um destes mecanismos de protecção é, basicamente, um requisito para qualquer negócio.

Outro componente que deve ser protegido é a rede. Isto inclui adaptadores de rede redundantes no sistema e vários caminhos através da rede de hardware de rede redundante para ser utilizado por utilizadores e sistemas para finalidades de comunicação.

O ambiente físico inclui também os serviços de utilitários necessários para manter a sala de computadores. O sistema fornece a funcionalidade de execução em cabos de alimentação duplos. Isto significa que cada torre ou bastidor tem dois cabos de alimentação ligados a duas tomadas eléctricas diferentes. Isto permite a um computador ter diferentes painéis de alimentação para

(20)

cada torre ou bastidor. Devido à natureza incerta da rede eléctrica pública, deve considerar seriamente a protecção da alimentação na sala de computadores através de uma fonte de alimentação ininterrupta ou de um gerador.

Outras considerações devem ter em conta as características físicas da sala dos computadores, como o calor, a refrigeração, a humidade do ar e a pureza do ar.

Ambiente lógico

O ambiente lógico consiste no ambiente de tempo de execução da aplicação. Isto consiste nos atributos do sistema, valores do sistema, atributos de configuração de rede, configuração da gestão de trabalho e perfis do utilizador. Estes terão de ser idênticos para que o ambiente de aplicações funcione no sistema de cópia de segurança de forma exactamente idêntica ao sistema de produção principal. Manter estes valores do ambiente lógico coerentes em vários sistemas pode ser conseguido através de um domínio administrativo de criação de conjuntos de unidades, replicação lógica ou de um processo manual devidamente bem definido.

Planear resiliência de ambientes

Simplicidade

A alta disponibilidade do IBM i endereça as três áreas de personalização, controlo e automatização, com o objectivo de alcançar a simplicidade operacional.

Personalização

Cada cliente possui um ambiente único, com requisitos únicos. A arquitectura de alta

disponibilidade do IBM i fornece o contexto a partir do qual cada cliente pode conceber uma solução baseada no seu próprio ambiente de aplicação, de modo a ir ao encontro às suas necessidades.

Controlo

A arquitectura do IBM PowerHA for i fornece controlo simples sobre o seu ambiente de alta disponibilidade. Com algum nível de personalização, a activação, encerramento, comutação e mudança de recurso do ambiente de aplicações completas são controladas através de uma interface de conjunto de unidades de fácil utilização. O operador do sistema torna-se, assim, o operador do conjunto de unidades.

Automatização

A alta disponibilidade do ambiente de produção do cliente requer uma operação cuidada e coordenada de todos os aspectos da aplicação de modo a manter resiliência e a assegurar uma passagem rápida de um servidor para outro sempre que um servidor principal é desactivado. A automatização do ambiente assegura que a pausa na produção é tão curta quanto possível. O principal benefício das funcionalidades de automatização no IBM PowerHA for i é a redução de erros durante os cenários de falha. Um reduzido potencial de erro para os utilizadores melhora o processo de tomada de decisões no caso de uma falha.

(21)

Critérios de alta disponibilidade

A alta disponibilidade do IBM i oferece uma selecção de diferentes tecnologias para resiliência de dados e disponibilidade de aplicações. Cada uma das diferentes tecnologias tem diferentes características. Estas características devem ser correspondidas com os requisitos exclusivos de cada aplicação de negócios individual. Os parâmetros que se seguem devem ser tidos em conta e considerados no momento de optar pela técnica de resiliência de dados que melhor se adequa ao seu negócio.

Orçamento

Cada solução de alta disponibilidade tem um determinado custo associado. O custo para a solução tem de ser comparado ao benefício para o seu negócio. Quando confrontados com uma solução de alta disponibilidade, a maior parte dos clientes dirá que pretende disponibilidade contínua com um tempo de desactivação virtualmente inexistente. Embora isto seja tecnicamente possível, o custo da protecção oferecida pela solução poderá ser demasiado elevado.

A questão fundamental por detrás do número de recursos que deve ser atribuído a uma solução de alta disponibilidade é “Qual é o custo de uma desactivação?” Os sítios de cópia de segurança, os sistemas de cópia de segurança, e os dados de cópias de segurança têm um custo, e um benefício associado a esse custo. Até que o custo real de cada unidade de desactivação seja conhecido, não é possível atribuir um valor correcto e preciso ao valor do benefício adicional da solução de alta disponibilidade.

O custo da solução corresponde ao custo total de propriedade, que inclui o custo inicial de aquisição e implementação, os custos contínuos de utilização e eventuais impactos no custo/desempenho. O custo é geralmente calculado através de uma análise de impacto rigorosa e extensiva. Os valores são:

v _{O custo não é um factor.}

v _{O custo tem algum peso na decisão.}

v _{Com base na análise de desactivação, o custo da solução tem de ser incluído no orçamento.} v _{O custo representa um factor significante na decisão.}

v _{Não quer ou não tem possibilidades para investir numa solução de disponibilidade.}

Requisitos de tempo de actividade

Os requisitos de tempo de actividade dizem respeito ao tempo total em que o sistema permanece disponível para aplicações de utilização final. O valor é indicado em percentagem do total das horas de trabalho planeadas.

Estas correspondem às percentagens de tempo de actividade e valores de inactividade correspondentes para os clientes que necessitam de disponibilidade contínua (24 horas por dia, 365 dias por ano). v _{Menos de 90% (tempo de inactividade de 876 horas ou mais (36 dias por ano)}

v _{90 a 95% (tempo de inactividade de 438 a 876 horas por ano)} v _{95 a 99% (tempo de inactividade de 88 a 438 horas por ano)} v _{99,1 a 99,9% (tempo de inactividade de 8,8 a 88 horas por ano)} v _{99,99% (tempo de inactividade de cerca de 50 minutos por ano)} v _{99,999% (tempo de inactividade de cerca de 5 minutos por ano)}

Geralmente, é utilizado o custo por hora de desactivação como factor determinante para os requisitos de tempo de actividade. Relativamente às desactivações não planeadas, os requisitos de tempo de actividade têm de ser baseados apenas nas horas de trabalho planeadas. Isto significa que o custo de uma

(22)

Cobertura de desactivação

Deve ser dada importância aos tipos de desactivação contra os quais pretende proteger o seu sistema.

Redução da duração da cópia de segurança

Num ambiente de sistema único, a cópia de segurança do sistema é a principal causa de uma desactivação planeada do sistema. À medida que o negócio cresce e as necessidades de tempo de actividade aumentam, a quantidade de tempo necessária para efectuar a cópia de segurança dos dados continuará a ser cada vez menor. Uma solução de alta disponibilidade dá-lhe a capacidade para realizar salvaguardas offline. Uma cópia offline consiste no acto de guardar os dados de uma aplicação a partir de uma cópia de segurança. Cada uma das tecnologias de resiliência de dados pode oferecer diferentes benefícios para a salvaguarda offline dos dados.

Manutenção planeada

A manutenção planeada consiste no período de tempo em que o sistema tem de ser desactivado para aplicação de actualizações às aplicações, ao software e ao hardware. Sempre que não é possível agendar a manutenção planeada para ser efectuada nas horas de expediente, pode ser implementada uma solução de alta disponibilidade para permitir a manutenção offline. Com a manutenção offline, o sistema de cópia de segurança é actualizado primeiro. Após o ambiente de produção ser comutado para o sistema actualizado, o sistema de produção antigo é então

actualizado.

Desactivações não planeadas

Uma desactivação não planeada consiste numa desactivação que ocorre durante as horas de expediente e pode dever-se a erro humano, falhas de aplicações/software, falhas de hardware ou falhas de utilitários, e desactiva o ambiente de aplicações. A solução de alta disponibilidade pode comutar o ambiente de produção para uma cópia de segurança.

Desastres locais

Um desastre local é geralmente concebido em termos de um desastre natural, e origina o

requisito de dispersão geográfica entre os sistemas da solução de alta disponibilidade. Para além de desastres naturais, existem também eventos, como derrames químicos, ataques terroristas e "apagões" eléctricos que podem afectar o local do seu negócio durante longos períodos de tempo. As diferentes soluções de alta disponibilidade possuem características diferentes em termos de tempo e distância. Devem ser tida em conta a importância dos objectivos de tempo de

recuperação (RTO) e da necessidade de executar operações normais num local remoto ou apenas um subconjunto de procedimentos empresariais.

Deve ser tido em conta o nível de interrupções toleráveis por um utilizador. O impacto nas aplicações pode ser definido da seguinte forma:

v _{Não é um problema. A disponibilidade da aplicação é importante. O desempenho pode ser afectado,} desde que a solução de disponibilidade assegure o funcionamento.

v _{É aceitável a ocorrência de alguma degradação do desempenho} v _{Ligeira degradação no desempenho}

v _{Ausência de impacto aparente no desempenho} | | | | | | | | | | | | | |

(23)

“Desactivações planeadas” na página 3

A alta disponibilidade do IBM i pode reduzir o impacto nos seus clientes e utilizadores, sempre que for necessário desactivar os sistemas ou tornar os dados indisponíveis para realizar tarefas de manutenção necessárias, como por exemplo a realização de cópias de segurança nocturnas ou a instalação de novo hardware ou software.

“Desactivações não planeadas” na página 4

As soluções de alta disponibilidade do IBM i podem assegurar protecção para desactivações não planeadas causadas por erro humano, problemas de software, falhas de hardware e problemas ambientais.

Objectivo de tempo de recuperação (RTO)

O Objectivo de tempo de recuperação (RTO) consiste no tempo que demora a recuperar de uma

desactivação (planeada, não planeada ou desastre) e a retomar as operações normais para uma aplicação ou conjunto de aplicações.

O objectivo de tempo de recuperação poderá ser diferente para a recuperação de desactivações planeadas, não planeadas e de desastre. Diferentes tecnologias de resiliência de dados possuem diferentes tempos de RTO. Valores possíveis para o RTO são:

v _{Mais de 4 dias é aceitável} v _{1 a 4 dias}

v _{Menos de 24 horas} v _{Menos de 4 horas} v _{Menos de 1 hora}

v _{Muito perto de zero (recuperação quase imediata)}

Objectivo de ponto de recuperação (RPO)

O objectivo de ponto de recuperação (RPO) consiste no ponto no tempo relativo à falha, em relação à qual é necessário obter a preservação dos dados. As alterações aos dados que precedem a falha ou o desastre em, pelo menos, esse período de tempo, são preservados pelo processamento de recuperação. Zero é um valor válido e é equivalente ao requisito de "perda de dados nula".

Os valores de RPO são:

v _{Última gravação (semanal, diária, ...)} v _{Início do último turno (8 hora)}

v _{Última interrupção significativa (4 horas)}

v _{Último lote de trabalho (1 hora até dezenas de minutos)} v _{Última transacção (segundos a minutos)}

v _{As alterações em tempo real poderão perder-se (coerência da perda de alimentação)} v _{Perda de dados nula}

Requisitos de resiliência

As opções empresariais são: v _{Nada requer resiliência}

(24)

v _{Os dados de aplicações}

v _{Os dados de aplicações e do sistema} v _{Os programas de aplicações}

v _{O estado de aplicações} v _{O ambiente de aplicações}

v _{Preservar todas as linhas de comunicações e de clientes}

“Resiliência de aplicações” na página 8

A resiliência de aplicações pode ser classificada pelo efeito no utilizador. Numa infra-estrutura de conjunto de unidades do IBM i, a resiliência de aplicações é controlada por um objecto de aplicação Cluster Resource Group (CRG). Este CRG assegura o mecanismo, utilizando um programa de saída, para controlar os processos de início, interrupção, reinício e comutação da aplicação para criar cópias de segurança dos sistemas. A totalidade do ambiente de aplicação, incluindo a replicação de dados e os dispositivos comutáveis, pode ser controlada através da infra-estrutura de conjunto de unidades como uma única entidade.

“Resiliência de dados” na página 9

Pode utilizar várias tecnologias para endereçar os requisitos de resiliência de dados descritos na secção “Vantagens da alta disponibilidade”. Segue-se uma descrição de cinco tecnologias chave de resiliência de dados multissistema. Tenha em atenção que pode utilizar uma combinação de várias tecnologias para fortalecer ainda mais a sua resiliência de dados.

“Resiliência do ambiente” na página 13

A resiliência do ambiente pode ser dividida em duas secções, o ambiente físico e o ambiente lógico. O ambiente físico, que faz realmente parte da disponibilidade do sistema, concentra-se sobretudo em áreas como a redundância de hardware, a topologia de rede, a infra-estrutura de alimentação e as capacidades de refrigeração. O ambiente lógico diz respeito ao ambiente que aloja e executa aplicações. Inclui áreas como as definições do sistema, os perfis de utilizador e os atributos do sistema que permitem a um utilizador executar a aplicação em vários servidores.

Mudança de recurso e comutação automatizada

O negócio tem de definir a forma como o controlo é concedido à automatização durante desactivações não planeadas. As soluções de alta disponibilidade do IBM i têm um nível personalizável de interacção no processamento da mudança de recurso. Em caso de falha, a aplicação pode efectuar automaticamente a mudança de recurso para um sistema de cópia de segurança, incluindo o início de todos os ambientes de aplicações.

Alguns clientes pretendem ter o controlo sobre o processamento de mudança de recurso. Nesta situação, o sistema requer uma resposta para o processamento de mudança de recurso. Numa solução em que a interacção com o utilizador seja necessária para a mudança de recurso, o tempo de decisão (ou o tempo necessário para tomar uma decisão em relação à mudança de recurso) é directamente subtraído em relação ao objectivo do tempo de recuperação. A empresa terá de decidir o nível de controlo de automatização a atribuir ao sistema durante uma mudança de recurso. A empresa não deverá demorar mais tempo a tomar a decisão em relação à mudança de recurso para o sistema de cópia de segurança do que o tempo necessário para efectivar a mudança de recurso.

Comutação

Mudança de recurso

Requisitos de distância

A distância entre sistemas, ou dispersão geográfica, apresenta alguns benefícios está limitada por

condicionantes físicas e práticas. Para uma solução de recuperação de desastre, existem sempre benefícios na dispersão geográfica entre os sistemas. Geralmente, quanto maior for a distância entre os sistemas,

(25)

maior será a protecção que terá contra desastres que afectam uma área relativamente grande. No entanto, esta também implica determinados efeitos negativos ao ambiente da aplicação.

Sempre que é adicionada distância a uma solução de replicação de dados, existe uma latência associada. Latência consiste no tempo de demora para um conjunto de dados chegue ao sistema de destino. Quanto maior for a distância entre os sistemas, tanto maior será a latência (tempo) associada à transmissão dos dados. Existem dois tipos de transmissão de comunicações, síncrona e assíncrona.

As comunicações síncronas para resiliência de dados requerem uma confirmação do sistema de destino de que a transmissão de dados foi recebida antes de desta ser continuadas. Este processo garante que não existem perdas de dados em processamento entre a origem e o destino, na eventualidade de uma falha. No entanto, a latência, ou o período de tempo de espera para obter confirmação pode afectar o

desempenho da aplicação.

As comunicações assíncronas para resiliência de dados não requerem uma confirmação do sistema de destino para que a transmissão de dados possa continuar. Devido ao facto deste mecanismo não requerer um protocolo de recepção, os dados enviados muito perto de um eventual momento de falha, poderão perder-se. Isto é conhecido como perda de dados processados em tempo real.

A aplicação, o volume de dados enviado e a dispersão geográfica dos sistemas irão determinar o mecanismo de transporte necessário para a sua solução de alta disponibilidade.

Replicação geográfica

Planear replicação entre sítios

Cenário: Replicação entre sítios com replicação metro Cenário: Replicação entre sítios com replicação global

Número de sistemas de cópia de segurança

Diferentes tecnologias de resiliência de dados oferecem diferentes números de possíveis sistemas de cópia de segurança e cópias de dados da aplicação.

Num ambiente com dois sistemas (cópia de segurança simples), a manutenção planeada deixará o seu negócio bastante exposto. Caso ocorra uma falha durante este período de tempo, não terá a capacidade de assegurar uma mudança de recurso. Nesta situação, a continuidade do negócio pode ser mantida através da adição de outro sistema de cópia de segurança. O número de sistemas de cópia de segurança e conjuntos de dados necessários irá ajudar a determinar a tecnologia de resiliência de dados necessária para o seu negócio.

Aceder a uma cópia secundária de dados

Diferentes tecnologias de resiliência possuem diferentes restrições acerca do conjunto de dados de cópia de segurança. Os requisitos de acesso ao conjunto de dados de cópia de segurança indicam o nível de acesso necessário a cópias secundárias dos dados para outras actividades de trabalho derivadas das cópias principais, como as gravações e consultas/relatórios. Deve sempre considerar a frequência, a duração e o tipo de acesso de que necessita para a cópia de segurança dos dados.

Os possíveis requisitos podem ser: v _Nenhum

v _{Durante os períodos de não produção}

v _{Pouco comuns, mas durante curtos períodos de produção normal (segundos a minutos)} v _{Pouco comuns, mas durante longos períodos de produção normal}

v _{Frequentes, durante curtos períodos de produção} v _{Frequentes, durante longos períodos de produção}

(26)

v _{Quase sempre necessários (quase contínuos)}

Cópia de segurança a partir de uma segunda cópia

Desempenho do sistema

A implementação de uma solução de alta disponibilidade poderá trazer implicações a nível do desempenho. Os requisitos do negócio podem determinar qual a tecnologia de resiliência necessária.

A implementação de alta disponibilidade implica uma grande variedade de custos de desempenho. O registo em diário para o processamento de replicação lógica e geográfica requer recursos do sistema para o tempo de execução normal. Adicionalmente, o registo síncrono em diário remoto e as tecnologias de replicação geográfica em modo de transmissão síncrona e a replicação metro são executadas num modo de comunicações síncronas. Este modo síncrono produz uma latência baseada na distância e na topologia de rede, o que terá impacto no ambiente da aplicação. Os requisitos de negócio, juntamente com o teste, ajudarão a determinar qual a solução mais adequada para o cliente.

A replicação geográfica suporta também um modo de transmissão assíncrono que poderá requerer recursos adicionais, como o armazenamento de CPU e armazenamento principal.

O processamento da comutação e da mudança de recurso não é instantâneo e tem um tempo sistema associado. Cada tecnologia possui características diferentes para activar online um conjunto de dados ou um ambiente de aplicação na sua totalidade, para processamento.

Gerir o desempenho do sistema

Valores do sistema: Descrição geral do desempenho

Comparação do método de resiliência de dados

Esta tabela proporciona uma breve descrição das principais características da solução que gera uma cópia dos dados no armazenamento auxiliar.

Tabela 1. Comparação de tecnologias de resiliência de dados que podem ser utilizadas com conjuntos de unidades. Saiba mais sobre as características de diferentes tecnologias de resiliência de dados para o ajuda a

determinar a melhor solução para o seu conjunto de unidades.

Tecnologias de resiliência de dados Produto de software de replicação

lógica Discos comutados

Replicação entre sítios com replicação geográfica A replicação entre sítios com os Serviços de cópia do IBM System Storage Unidade lógica comutada Utilização principal HA e DR HA HA e DR HA e DR HA | | | | | | | | | | | | | | | |